tyPouypOblOg

Voilà que Shoes se pare d’une nouvelle fonctionnalitée: xmlHttpRequest. En gros, et pour reprendre sont exemple, vous pouvez lancer une opération de download tout en continuant à travailler…

Je vous laisse voir cela plus en détail sur le blog d’hackety.org: threadedDownloadsInShoes

Merci qui ? Merci _Why !

La nouvelle version de JRuby viens de sortir: Jruby 1.1.4 .

Au programme, pas mal de chose dont

• Un gros refactoring de la couche d’intégratiohn java.
• de 2 à 20 fois plus rapide sur la plus part des fonctionnalitées
• Les exceptions java peuvent être maintenant récupérer directement dans Ruby
• Amélioration de la gestion mémoire
• Début du support de Ruby 1.9 (vivement les fibres dans jruby ! je veux voir ça)
• Amélioration des performances
• Pool de Thread amélioré
• Accès concurent sur les tableaux amélioré
• Et 72 bug résolu depuis la version 1.1.3

Dans les prochain mois, l’équipe va travailler pour essayer de sortir des release plus fréquement (quelque chose comme une fois par mois). Le but étant de corriger au plus vite les divers problème, et apporté les évolutions plus rapidement aux utilisateurs.

Un bon projet toujours sur un bon rythme :)

Le micro framework graphique initié par _Why Shoes a un nouveau site dédié: http://shoooes.net/

Un petit rappel également pour le très intessant The Shoebox qui est une gallerie d’application Shoes.

On en reparlera plus tard ;-)

Quand on a l’habitude d’utiliser une bonne grosse tour avec un écran gigantesque, un bon clavier et de la place autour de tout ça, c’est dur de choisir un ordinateur portable correctement, voici quelque pièges dans lesquels je suis tombé, et comment j’ai eu l’occassion de rectifié le tir.

Il y a quelque mois, me voici dans l’obligation de choisir un ordinateur portable. Le contexte, c’est important pour le choix d’une machine: un nouveau job dans une SSII qui m’amènera à me déplacer souvent.

Ok, alors il me faut un bon processeur et de la ram, il ne faut pas déconner, je vais quand même faire un peu de developpement sur cette machine ! Un bon disque dur aussi, les portable sont souvent équipé d’un disque qui tourne pas très vite, je vais prendre un 7200 tours/minutes, comme ça, ça va envoyer la purée. Il me faut un belle écran aussi, je vais me prendre un truc trop bien en utlra bright view wild très large avec tout plein de pixels affiché et l’écran qui brille ! Je me restreint à un beau 15 pouces en écran large quand même. Bien sur niveau connectique, il me faut tout, et le lecteur/graveur de cd/dvd aussi.

A tiens ils (dans mon cas, Dell) fournissent un sac à dos ? C’est original (c’est là que ça aurait du me mettre la puce à l’oreille).

Bon, je vous passe le prix de la configuration, et je vous montre ce que j’ai du coup (fait) acheter:

ps: C’est celui de droite bien sur

Alors la super configue qui va bien, c’est sur, posé sur le bureau c’est top de chez top. Mais alors dès que je part en déplacement, c’est la misère. Je me retrouve avec une carapace de tortue géante sur le dos de pas loin de 5 kilos. Je ne parle même par de l’autonomie, a peine plus de 2 heures...

Au bout de 3 déplacements, j’ai commencé à raler sur mon choix… Une opportunité plus loin, et voilà que je peut changer de machine ! On me propose de refaire une commande !

Bien, cette fois je ne vais pas utiliser les même critères, mon contexte c’est le mobilité. Quitte à prendre moins puissant, avec un écran moins grand, il me faut de la légèreté, un faible encombrement, de l’autonomie

Me voilà cette fois dans le coin des 12 pouces de chez Dell, ou plutôt dans la catégorie des moins de 2 kilos. Voilà, je craque pour le petit là, oui oui le tout petit…

ps: toujours celui de droite hein :)

Alors c’est sur j’ai pas un écran brillant machin truc qui fait 3 kilomètres de large. Jai pas de lecteur/graveur cd/dvd intégré, c’est un lecteur externe qui est fourni avec, d’ailleurs je le laisse à la maison en général. Mais le gros avantage, le grand trip c’est quand je le glisse dans la house du MacBookAir (ben oui c’est ce que j’ai trouvé de mieux adapté) et que je met ça entre deux pochettes dans mon sac habituel. Avec ça et presque 4 heures d’autonomie, je suis tranquille, et la machine me suit partout ! :)

Alors faite attention quand vous choississez un ordinateur portable. Prenez bien en considération le contexte d’utilisation de votre machine. Vous allez pas me dire qu’il n’y a que moi pour m’être planté de la sorte ?

Pour information:

• La première machine que j’avais commandé est un Dell Precision M4300 , une très belle machine, mais il ne faut pas avoir à trop ce déplacer. Pour l’heure elle fait le bonheur d’un collègue sédentaire :)
• La seconde est un Dell Latitude D430 machine que j’utilise aujourd’hui depuis un gros mois et qui me convient très bien :)

Ruby bénéficie comme beaucoup d’autres langages modernes de son framework de test. Voici donc une petite documentation sur comment écrire un test unitaire pour Ruby.

Pour ceux qui ne savent pas ce qu’est un test unitaire, je vous renvoie sur l’article Test Unitaire [wikipedia]

Pour commencer il nous faut importer la librairie “Test::Unit”

require "test/unit" 

Rien que cela nous permet déjà de faire un premier test en executant notre script.

yannick@libellule:~/Code/RubyFrance/testUnit $ ruby testUnit.rb
Loaded suite testUnit
Started

Finished in 0.000607 seconds.

0 test, 0 assertions, 0 failures, 0 errors

Le fait d’inclure la librairie de test unitaire permet d’avoir un comportement par défaut qui va:

• Charger la suite de test à executer
• lancer les tests
• faire l’affichage des resultats de test
• faire un compte rendu de cette execution

Ajoutons un test maintenant

require "test/unit" 

class StringTest < Test::Unit::TestCase
  def test_length
    s = "Bon test à tous !" 
    assert_equal(17, s.length)
  end
end

Nous avons défini une classe, celle-ci doit étendre TestCase. Cela permet au framework de test de s’y retrouver. Chaque méthode de test définie ensuite doit contenir test en début de nom (le caractère _ n’est placé que pour une meilleur lisibilité et selon les conventions couramment appliquées en Ruby)

Les méthodes assert (ici assert_equal, mais il en existe beaucoup d’autres) permettent d’effectuer un test. Ici un test d’égalité, mais nous pourrions également vérifié une différence, un bouléen répondant vrai ou faux et d’autres encore (voir la documentation sur le module Test::Unit::Assertions).

Après execution, voici le résultat:

yannick@libellule:~/Code/RubyFrance/testUnit $ ruby testUnit.rb
Loaded suite testUnit
Started
.
Finished in 0.000802 seconds.

1 test, 1 assertions, 0 failures, 0 errors

Un test a été executé avec succès.

Ajoutons encore un test pour avancer:

require "test/unit" 

class StringTest < Test::Unit::TestCase
  def test_length
    s = "Bon test à tous !" 
    assert_equal(17, s.length)
  end
  def test_expression_substitution
    assert_equal("", "#{'ah! ' * 3}")
  end
end

Après exécution nous obtenons:

yannick@libellule:~/Code/RubyFrance/testUnit $ ruby testUnit.rb
Loaded suite testUnit
Started
F.
Finished in 0.000827 seconds.

  1) Failure:
test_expression_substitution(StringTest) [testUnit.rb:12]:
<""> expectedbut was
<"ah! ah! ah! ">.
2 test, 2 assertions, 1 failures, 0 errors

Et voilà, comme vous l’aviez deviné, nous avons une erreur. Dans notre cas, l’erreur viens de notre test.

On vois ici l’interêt de mettre chaque test sur un domaine différent dans une méthode différente: on vois facilement quel type de test nous voulions effectuer. Dans le développement d’une application complète, avec plusieurs dizaines d’objets à tester, et plusieurs dizaines de méthodes sur chacun d’eux, les erreurs d’exécution de test peuvent devenir un vrai casse-tête.

Effectuons la correction:

require "test/unit" 

class StringTest < Test::Unit::TestCase
  def test_length
    s = "Bon test à tous !" 
    assert_equal(17, s.length)
  end
  def test_expression_substitution
    assert_equal("ah! ah! ah! ", "#{'ah! ' * 3}")
  end
end

exécution du test:

yannick@libellule:~/Code/RubyFrance/testUnit $ ruby testUnit.rb
Loaded suite testUnit
Started
..
Finished in 0.001273 seconds.

2 test, 2 assertions, 0 failures, 0 errors

Et voilà. Vous devriez être capables de commencer à écrire quelques tests, mais ce n’est qu’un début !.

Cet article a été écrit pour le site de l’association RubyFrance, vous pourrez le retrouver dans les documentations proposées par l’association: RubyFrance: TestUnitaire