-[ MaGaLoMa ]-

Pharo 1.4 with Tiling Window Manager and more

2012-04-18T23:07:00.001+02:00

With the release of Pharo 1.4 I've created my new custom image with TWM, Nautilus, Autotest and ProfStef. Here's the download link

FOSDEM 2012

2012-02-11T22:33:00.000+01:00

This was my first FOSDEM and with no hesitation that's the most fun event I've ever participated. The Hackerspace Bytenight was amazing, listening 8-bit remixed music from 90's video games, drinking good Belgian beers and talking with fun people.

I found a place to sleep for four days through CouchSurfing (I've also discovered BeWelcome recently), it seems the best way to enter Brussel's life.

On sunday John Thornton and I gave a talk on Amber Smalltalk - you can view slides online. Johnny arrived from the USA only five minutes before the talk, he's definitely an agile developer ;) We had some fun presenting Amber and the room was almost filled. We wanted to show real working code, integration with Javascript and Nodejs goodies. It's nice to use dynamic slides with Amber.

Photo by Damien Pollet

Marcus explained Pharo's vision before our talk. Huge work has been done, huge work ongoing. I'm looking forward to the Pharo Consortium.

After talking with several people we went back to the Smalltalk devroom. I discovered the Spoon project by Craig Latta. It's a minimal Smalltalk that can be remotely browsed from Squeak.

Then took place an introduction to Smalltalk workshop. Experienced Smalltalkers paired with newcomers to test and add new features to a Seaside application. The idea is nice and allows to listen to people feelings while discovering a new tool.

I finally put real faces on people only known on mailing-lists. Sad we did not managed to have more discussion. One day is short and so much to see...

Thank you Stephan. So nice things can emerge from a single tweet :)

Photo by Adriaan van Os

Emacs and J2EE on OSX notes

2011-10-07T09:16:00.001+02:00

Here's how I've managed to setup Emacs for J2EE / Tomcat / Maven application development on OSX.

Install Emacs

I use Emacs 23.3 from Emacs for OSX.

Malabar mode

Malabar mode offers easy code navigation, Maven, JUnit and Groovy integration. Download release 1.4 and extract in a directory to build it.

As the build will invoke emacs in batch mode, be sure that Emacs 23.3 is in your path (instead of using the one packaged with OSX).

What works on my machine:

unzip espenhw-malabar-mode-malabar-1.4.0-0-g35e1e5e.zip
cd espenhw-malabar-mode-1daaee4
export PATH=/Applications/Emacs.app/Contents/MacOS:$PATH
mvn package -DskipTests=true

Now in target directory there's a malabar-1.4.0-dist.zip. Unzip it where you put all your emacs librairies:


cd ~/.emacs.d/
unzip /path/to/malabar/target/malabar-1.4.0-dist.zip

Configure Emacs for Malabar

Open your .emacs and add:

(add-to-list 'load-path (expand-file-name "~/.emacs.d/malabar-1.4.0/lisp/")) 

(require 'cedet)
(require 'malabar-mode)
(setq malabar-groovy-lib-dir "/path/to/malabar/lib")
(add-to-list 'auto-mode-alist '("\\.java\\'" . malabar-mode))

(semantic-mode 1)
(require 'malabar-mode)
(setq malabar-groovy-lib-dir "~/.emacs.d/malabar-1.4.0/lib"
      malabar-load-source-from-sibling-projects t
      malabar-extra-source-locations
      '( "/absolute/path/to/project1/src" 
        "/absolute/path/to/project2/src" ) ) ;; you need to setup this 

(add-to-list 'auto-mode-alist '("\\.java\\'" . malabar-mode))

(add-hook 'malabar-mode-hook
     (lambda () 
       (add-hook 'after-save-hook 'malabar-compile-file-silently
                  nil t)))

Now open a .java file within Emacs.

Try malabar-jump-to-thing on one of your class and it should open the corresponding file.

Open a test file and try malabar-run-test. It should run maven test for this file. If all tests OK but finished with "BUILD FAILURE", then see next section

Java troubleshooting

Malabar should use java from jdk, not jde. I've tried setting JAVA_HOME and configure malabar without success. So quick dirty hack is:


cd /usr/bin
mv java java.jre
ln -s  /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home/bin/java

Ressources

Entreprise Java Development With Emacs

Debugging Tomcat

Install JDIBug. In jdibug-expr.el, change the line (and to forget to byte-recompile or remove .elc):

(require 'semantic-java)

(require 'semantic/java)

Configure emacs:


(add-to-list 'load-path "~/.emacs.d/jdibug-0.5")
(setq jdibug-connect-hosts (quote ("localhost:8000"))
      jdibug-use-jde-source-paths nil
      jdibug-source-paths
      (list
			 "/path/to/project1/src" 
			 "/path/to/project2/src"  ))
(require 'jdibug)

Start Tomcat like with debugger enabled:

./bin/catalina.sh jpda start

Then try jdibug-connect to attach Emacs to tomcat.

TWM: Docking Windows

2011-07-12T23:49:00.000+02:00

Using Pharo 1.4 and latest TWM packages, you can now group windows as tabs.

Use:

(ConfigurationOfTilingWindowManager project 
    version: #bleedingEdge) load

My Pharo image

2011-06-28T08:01:00.002+02:00

Backup of my preferences:

Gofer it
   squeaksource: 'MetacelloRepository';
   package: 'ConfigurationOfPhexample';
   package: 'ConfigurationOfAutotest';
   squeaksource: 'TilingWindowManager';
   package: 'ConfigurationOfTilingWindowManager';
   load.
 
(Smalltalk at:#ConfigurationOfTilingWindowManager) perform: #loadDevelopment.
(Smalltalk at:#ConfigurationOfPhexample) load.
((Smalltalk at:#ConfigurationOfAutotest) project version: #development) load: 'OB'.

(Smalltalk at:#TWMUITheme) beCurrent. 
TaskbarMorph  showTaskbar: false.
TasklistMorph keepOpen: true.
(Smalltalk at:#TWMBar) perform: #showTWMBar: with: true.
(Smalltalk at: #AutotestDashboard) perform: #showAutotestDashboard: with: true.

Albaaaaaator, Albaaaaaaator, capitaine au coeur d'or ......

2011-06-11T13:40:00.002+02:00

Le papa d'Albator / Captain Harlock, Lieji Matsumoto, était à Annecy pour le festival d'animation.... on a la dédicace !!!

Nostalgie ....

Générique Albator 84 par MigXIII

Multiple Worlds for TWM

2011-06-07T22:29:00.001+02:00

With the help of my local developper group, I've integrated Sean DeNigris work and now Tiling Window Manager supports Multiple Worlds.

Here's a screencast that shows the progress. (My English seems a little less catastrophic than the previous screencast :)

Note: The tests failing on the screencast (Pharo 1.2) are green on Pharo 1.3.

Load TWM with:

Gofer it
  squeaksource: 'TilingWindowManager';
  package: 'TWM';
  load.

And ConfigurationOfKeyMapping 1.7 (TWM do not work with 1.8 actually) with:

Gofer it
    squeaksource: 'ShortWays';
    package: 'ConfigurationOfKeymapping';
    load.
    
(ConfigurationOfKeymapping project version: '1.7') load.

Tiling Window Manager

2011-05-28T00:03:00.003+02:00

I love Emacs because of editing speed and fast buffer switching among a lot neat features.

This week I've tried to make Pharo a little better on window management. This video shows the progress (thanks Gastón and Patrick for help and ideas).

Next step: KeyMapping integration + history à la Emacs winner-mode.

Sorry for my soooooooo awful english (tired ....).

Update 05/31/2011: you can load last version with colored theme with:

Gofer it
  squeaksource: 'TilingWindowManager';
  package: 'TWM';
  load.
(Smalltalk at: #StandardUITheme) beCurrent.
(Smalltalk at: #TWMBar) showTWMBar:true.

Tested on PharoCore 1.2 and Pharo 1.3.

Now this has support for world snapshot, that means you can arrange the windows and take a snapshot of the layout. Then you can restore these layouts later. (icons camera, <, > and trash). I'm not entirely satisfied with this, thanks for feedback.

In Pharo 1.3 there's initial integration with KeyMapping. To load:

Gofer it
  squeaksource: 'ShortWays';
  package: 'ConfigurationOfKeymapping';
  load.

(Smalltalk at: #ConfigurationOfKeymapping project version: '1.7') load.

Then in settings browser > Keymappings > Tiling Window Managers you have all actions of the dock mapped.

You can choose a Layout Strategy in settings.

Actually there's Horizontal (default) and Vertical (last used windows fills all remaining space) strategies.

To add your own just subclass TWMLayoutStrategy and implement #tileWindows:

To load TWM:

Gofer it
 squeaksource: 'TilingWindowManager';
 package: 'TWM';
 load.

I also think the UI theme Patrick has cleaned fits better with TilingWM:

Gofer it
 squeaksource: 'PBASandbox';
 package: 'PBSandbox';
 load.
 
StandardUITheme beCurrent.

Pomodoro scripts

2011-04-14T09:22:00.000+02:00

Sous OSX j'utilise ce logiciel comme chronomètre qui a l'avantage de pouvoir exécuter des scripts lorsque le Pomodoro démarre, s'arrête, ....

Au travail on utilise beaucoup la messagerie instantanée. J'utilise Adium comme client.

Besoins:

je ne veux pas être dérangé pendant mon Pomodoro (passer mon état à indisponible)
je veux que mes collaborateurs sachent quand se termine mon Pomodoro pour me contacter

Solution:

Dans Adium créer un statut indisponible avec comme titre'Pomodoro en cours'

Dans les préférences de Pomodoro, onglet script, configurez comme ceci:

Start:

tell application "Adium" to set the status of every account whose status type is available to the first status whose title is "Pomodoro en cours"

Reset et End:

tell application "Adium" to set the status of every account whose status type is away to the first status whose title is "Disponible"

Every 2 mins:
tell application "Adium" to set status message of every account to "Pomodoro en cours, fin dans $time mn"

Tout le long du Pomodoro votre statut sera mis à jour:

Et dès que quelqu'un ose vous contacter, réponse automatique !

Petite Horloge revisited

2011-04-13T16:08:00.006+02:00

Another Pharo Smalltalk snippet with temp classes (I like this :)

(Class new
    superclass: StringMorph;
    setFormat: StringMorph format;
    compile: 'step self contents: Time now printString';
    new)
        openInWindowLabeled: 'Petite Horloge'.

Don't forget the setFormat: or the VM will crash.Some explanations.

Polymorph counter example

2011-04-13T13:44:00.006+02:00

I've discovered that I can write this in Pharo:

"This creates a class and one instance on the fly"
counter := Class new 
              superclass: Object; 
              addInstVarNamed: 'counter'; 
              compile: 'initialize 
                           counter := 0';
              compile: 'counterString 
                           ^ counter asString';
              compile: 'increment 
                           counter := counter + 1. 
                           self changed:#counterString';
              compile: 'decrement 
                           counter := counter - 1. 
                           self changed:#counterString';
              new.

(UITheme builder newColumn: {
  UITheme builder newLabelFor: counter getLabel: #counterString getEnabled: nil.
  UITheme builder newRow: {
    UITheme builder newButtonFor: counter action: #increment label: '+' help: nil.
    UITheme builder newButtonFor: counter action: #decrement label: '-' help: nil.
  }
}) openInWindowLabeled: 'Counter example'.

Coooooooooooooool ;)

Multiple worlds for Pharo

2011-03-19T09:28:00.001+01:00

Sean DeNigris submitted a changeset to get multiple worlds in Pharo.

I've played a little with it to get a world switcher. If you want it, first file in the changeset file (download it the drag the file on an opened image).

Then the following code add three worlds named 2,3,4 and create a dock in each world.

|wm|
wm := WorldManager instance.
#('2' '3' '4') do: [:aString| wm createOrSwitchToWorldNamed: aString].

wm worlds keysAndValuesDo:  [:aWorldName :aWorld| |dock|
  dock := DockingBarMorph new
          adhereToTop;
          openInWorld: aWorld.

  wm worlds keysAndValuesDo: [:aWorldName2 :aWorld2|
    dock addMorph: (SimpleButtonMorph new
                    label: aWorldName2;
                    target: [wm createOrSwitchToWorldNamed: aWorldName2];
                    actionSelector: #value) ].
                    
  dock addMorph: (StringMorph contents: aWorldName).
].

Work on Mocketry

2011-02-28T22:23:00.000+01:00

Mocketry is a Mocketry is Smalltalk mock object framework.

To load it in Pharo:

Gofer it
  squeaksource: 'MetacelloRepository';
  package: 'ConfigurationOfMocketry';
  load.

(Smalltalk at:#ConfigurationOfMocketry) project latestVersion load.

I've done the first part of the Picasa screencast in a TDD way using Mocketry to prevent external HTTP requests.

Gofer it
 squeaksource: 'LaurentLSandbox';
 package: 'Picasa';
 load.

As the requests are done using HTTPSocket class>>httpGet:, one way is to give a mock to PicasaSearch so we can check (and stub) the HTTP request:

PicasaSearchTwoRoughSeaTest>>setUp
  [:mockHTTPSocketClass|
    [photos := PicasaSearch new
        httpSocketClass: mockHTTPSocketClass;
        addKeyword: 'rough';
        addKeyword: 'sea';  
        maxResult: 2;
        photos.] 
 
     should strictly satisfy: [
        (mockHTTPSocketClass httpGet: 
          'http://picasaweb.google.com/data/feed/api/all?q=rough+sea&max-results=2')
        willReturn: self fixtureXMLResponseForTwoRoughSea] 
  ] runScenario.

#fixtureXMLResponseForTwoRoughSea will return an XML string and test methods will check that it is correctly parsed.

In PicasaSearch:

httpGetDocument 
  |url| 
  url := String streamContents: [:aStream|
  aStream 
    nextPutAll: 'http://picasaweb.google.com/data/feed/api/all?q=';
    nextPutAll: ('+'  join: self keywords);
    nextPutAll: '&max-results=';
    nextPutAll: self maxResult asString.    
  ].  

  ^ (self httpSocketClass httpGet: url).

See that mocketry extends BlockClosure to create mocks:

[:myFirstMock :mySecondMock|
"do stuff with mocks"
] runScenario

and set up expectations:

[:myFirstMock :mySecondMock|
  [ "do stuff with mocks" ] 
  should strictly satisfy: 
  [ "what is expected on mocks" ]  
] runScenario

See HelpSystem book loaded with Mocketry for several examples.

Comments and better code propositions are welcome.

XML Browser with Pharo

2011-02-21T18:37:00.001+01:00

I've written a little tool to help me browse xml. If you want to try it:

Gofer new
 squeaksource: 'LaurentLSandbox';
 package: 'XML-GUI';
 load.
 
((Smalltalk at:#XMLBrowser) labelled: 'Picasa search')
  browseAtUrl: 
   'http://picasaweb.google.com/data/feed/api/all?q=lighthouse&max-results=10'.

See XMLBrowser comment for examples.

FizzBuzz Kata: minimal solution

2011-02-18T07:57:00.004+01:00

Trying to find a minimal solution for the FizzBuzz Kata in Smalltalk:

fb := [:counter| |rules|
       rules := {15->'FizzBuzz'. 5->'Buzz'. 3->'Fizz'. 1->counter}.
       rightRule := rules detect: [:aRule| counter \\ aRule key == 0].
       rightRule value].  

self assert: (fb value: 7) == 7.
self assert: (fb value: 3) == 'Fizz'.
self assert: (fb value: 5) == 'Buzz'.
self assert: (fb value: 15) == 'FizzBuzz'.

1 to: 100 do: [:counter | 
               Transcript 
                 show: (fb value: counter) asString;
                 cr]

Update: Little variant from Alexandre:rightRule := rules detect: [:aRule| counter isDivisibleBy: aRule key]

Smalltalk tiny exercise for TDD newbies

2011-02-08T07:45:00.002+01:00

Done in course:

Create the category Exercise in the Browser. All classes you create will be placed in this category.

Implement the class Operation (using Test-Driven Development) which should work like this:

a := Operation new. a result.Should return 0.

b := Operation new.
b add: 2.
b add: 3.
b result.

Should return 5.

Operation new
  add: 2;
  add: 4;
  divideBy: 2;
  result.

Should return 3.

Add the message Operation>>#multiplyBy by yourself.

new funny ProfStef lesson

2011-02-06T19:31:00.002+01:00

Update to last ProfStef (on Pharo 1.2 only):

Gofer it
 squeaksource: 'MetacelloRepository';
 package: 'ConfigurationOfProfStef';
 load.
 
ConfigurationOfProfStef project latestVersion load.

ProfStef 
  go;
  tutorial: SmalltalkSyntaxTutorial lesson: #instanciation.

Why technology matters

2011-02-02T09:12:00.000+01:00

Life is very short. You have a limited amount of time in which to realize your dreams, in which to do your projects. If you’re like me, you probably have dozens and dozens of ideas for apps, sites, portals, that you want to implement. Most of those ideas will suck. But you don’t know which ones, you won’t know until you try them. Your goal, in this life, is to iterate faster. To fail more, to fail quicker, until you get to the brilliant ideas and brilliant projects that can change the world, or at least make you a dollar or two.

From A Secret: Passion and Your Choice of Web Framework by Dmitri Zagidulin

Smalltalk à l'OSDC.fr 2010

2011-01-28T08:07:00.000+01:00

Et là j'ai peur en me voyant en vidéo ....

Pharo GUI with Polymorph

2011-01-25T22:06:00.005+01:00

I've written a tiny address book to prepare a screencast on Polymorph basis. If you want to look at it:

Gofer it
 squeaksource: 'Pharocasts';
 package: 'ContactManager';
 load.
 
(Smalltalk at:#ContactListEditor) open.

Start by looking how the contact list is built:

ContactListEditor>>open
  |builder content|
  builder := UITheme builder.
  content := builder newColumn: {   
        builder 
                newListFor: self   
                list: #contacts
                selected: #contactSelectedIndex
                changeSelected: #contactSelectedIndex:
                help: 'contacts'.
        builder newRow: {
                builder newButtonFor: self 
                        action: #addButtonClick 
                        label: 'Add' 
                        help: 'Create a new contact'.
                builder newButtonFor: self 
                        action: #removeButtonClick 
                        getEnabled: #hasSelectedContact 
                        label: 'Remove' 
                        help: 'Remove selected contact'.
                builder newButtonFor: self 
                        action: #editButtonClick 
                        getEnabled: #hasSelectedContact 
                        label: 'Edit' 
                        help: 'Edit selected contact'  }}.
   
  (content openInWindowLabeled: 'Contacts') extent: 400@500.

#newRow: and #newColumn: are an easy way to align elements on the window.

When the Add button is clicked, message #addButtonClick is sent on the ContactListEditor object:

ContactListEditor>>addButtonClick
  |newContact|
  newContact := Contact new.
 
  ContactEditor new
        contact: newContact;
        onOK: [ Contact database add: newContact.  
                selectedContactIndex := Contact database size.
                self 
                        changed: #contacts;
                        changed: #hasSelectedContact];
        openModal.

The closure given to onOK: adds the new Contact and tells the view to refresh components which depends on #contacts and #hasSelectedContact selectors - that means the contact list and the Remove and Edit buttons.

ContactEditor defines a modal dialog to edit the firstName and lastName of a Contact:

ContactEditor>>openModal
  |builder dialog content firstName|
  
  builder := UITheme builder.
  content := (builder newLabelGroup: {
                'First name' -> (
                       firstName := (builder
                         newTextEntryFor: contact
                         getText: #firstName
                         setText: #firstName: 
                         help: 'Enter the first name of the contact')
                       acceptOnCR: false;
                       minWidth: 200).
                'Last name' -> (
                       (builder
                          newTextEntryFor: contact 
                          getText: #lastName 
                          setText: #lastName: 
                          help: 'Enter the last name of the contact')
                        acceptOnCR: false;
                        minWidth: 200) }).
 
  dialog := builder 
              newPluggableDialogWindow:'Edit contact' 
              for: content.
  dialog rememberKeyboardFocus: firstName.
  builder openModal: dialog.
 
  dialog cancelled ifFalse: [self doOnOK].

From Gary Chambers (and thanks !):

Disabling the acceptOnCR for each text frield allows the default dialog handling for the return key (defaults to OK).

Normally the initial keyboard focus for a dialog is the default button, if specified. Remembering the first name field prior to opening will give that field focus.

Now it should be easier to understand Polymorph examples found in
UITheme class>>exampleBasicControls and friends (in examples protocol).

CodeRetreat à Grenoble

2011-01-24T10:35:00.007+01:00

Vendredi dernier je me suis rendu au premier CodeRetreat en France organisé par Johan Martinsson, Remy Sanlaville et Miguel Moquillon, avec le soutien du CARA et Alpes JUG - merci tout le monde !

En résumé, le CodeRetreat consiste à enchaîner des itérations d'une heure en pair-programming et Test-Driven Development sur le même problème tout au long de la journée. Le problème choisi était le jeu de la vie, qui a les avantages d'offrir plusieurs approches possibles et d'être assez complexe pour ne pas être résolu en 45mn.

Chaque itération se déroule de la manière suivante:

Constitution des binômes (on change à chaque itération).
45mn de programmation.
15mn de rétrospective.

C'est agile, le temps est chronométré (belle organisation).

A la fin des 45mn de programmation, le code est effacé. Comme l'a répété Johan, ce n'est pas le résultat qui compte, mais la démarche, l'approche du développement qu'on doit s'efforcer de faire le plus parfaitement. C'est à dire:

développement piloté uniquement par les tests
pas de duplication de code
noms clairs et significatifs
code le plus simple possible

Côté langages nous avions beaucoup de Java. Miguel et moi en avons profité pour faire découvrir Pharo / Smalltalk et faire une session ensemble en Haskell. Il y a aussi eu un peu de Ruby.

Les 15mn de rétrospective permettaient d'échanger sur les différentes approches, les difficultés rencontrées, succès. On voit bien qu'il y a plusieurs manières d'attaquer le problème. Au fur et à mesure des automatismes se mettent en place ce qui permet de gagner du temps pour aborder d'autres aspects du problème.

Suit ce que j'en retire.

Pair-programming:

Chaque session se déroulait avec un binôme différent et chaque expérience, démarche a du coup été significativement différente. J'ai rencontré plusieurs cas:

une personne qui a l'idée et une autre qui suit: c'est du coup souvent la personne qui veut voir son idée réalisée qui pilote et qui tape. La personne qui suit dépense beaucoup d'énergie pour rester dans le coup (j'ai été dans cette position sur une session). Il est nécessaire que la personne qui pilote temporise.
deux personnes qui ont des idées: cela amène assez vite a quelques débats sympathiques mais c'est l'expérience qui me semble la plus enrichissante, d'où émerge des solutions de type "waouh, ça c'est cool".
deux personnes ont la même idée, suivent la même route: dans ce cas c'est plus la volonté de bien faire qui ressort et la recherche de qualité / perfection dans la démarche est vraiment élevée

Dans tous les cas, il y a toujours une bonne ambiance à coder avec des inconnus :)

Test-Driven Development:

Je suis convaincu de la démarche et la pratique depuis que j'ai lu eXtreme Programming de Kent Beck vers 2002/2003. Donc je fais partie des gens qui ont des automatismes assez arrêtés sur le sujet :). Pour avoir vu d'autres façons de faire au cours de la session, je reste persuadé que la manière la plus claire est d'avoir:

un TestCase par contexte. Le setUp établit le contexte, les tests font les vérifications.
un assert par test. Avoir plusieurs assert doit rester exceptionnel car ça complexifie les tests (ce n'est pas interdit, mais il faut avoir conscience du compromis).

Un exemple concret est la règle: "Si une cellule a exactement deux voisines vivantes, elle reste dans son état actuel à l’étape suivante".

Avec Rémy nous avons codé comme suit (grosso modo, le code a été effacé :)

ALivingCellWithTwoOrThreeLivingNeighbours>>#testShouldLive
  |aliveCell|
  aliveCell := Cell new revive.
  self assert: aliveCell isAlive.

  2 to: 3 do: [:numberOfNeighbours|
    aliveCell numberOfNeighbours: numberOfNeighbours.
    self assert: aliveCell shouldLive.
  ]

Le soucis c'est que quand le test est en échec, il faut débugger pour savoir si ça coince pour deux ou trois cellules.

Dans ce cas je préfère avoir deux cas:

ALivingCellWithTwoLivingNeighbours
ALivingCellWithThreeLivingNeighbours

Ceci dit cela risque d'amener une duplication de code, vu que les tests sont identiques dans chaque cas. Une solution codée avec Aline est d'utiliser des Traits pour définir les tests de manière générique puis de mettre seulement les différences dans les TestCase.

Trait named: #TCellIsAliveAndShouldLive

TCellIsAliveAndShouldLive>>#testIsAlive
  self assert: self aliveCell isAlive

TCellIsAliveAndShouldLive>>#testShouldLive
  self assert: self aliveCell shouldLive

TCellIsAliveAndShouldLive>>#aliveCell
   self explicitRequirement

Du coup pour nos cas de test:

TestCase subclass: #ALivingCellWithTwoLivingNeighbours
  uses: TCellIsAliveAndShouldLive

ALivingCellWithTwoLivingNeighbours>>#aliveCell
  ^ Cell new
       revive;
       numberOfNeighbours: 2.

de même:

TestCase subclass: #ALivingCellWithThreeLivingNeighbours
  uses: TCellIsAliveAndShouldLive

ALivingCellWithThreeLivingNeighbours>>#aliveCell
  ^ Cell new
        revive;
        numberOfNeighbours: 3.

Approches

Les deux approches principales consistaient à commencer par implémenter la Cellule ou bien la Grille / Univers. Il était aussi possible de passer par une classe Neighbours intermédiaire.

Haskell qui est un langage fonctionnel permet d'avoir une approche par les ensembles.

Une solution liée à l'imagerie en travaillant en binaire a été évoquée mais pas implémentée à ma connaissance.

Pour simplifier l'algorithme qui calcule si la cellule doit vivre ou mourir en connaissant son état actuel et le nombre de ses voisins vivants, deux variantes:

avoir deux classes LiveCell et DeadCell qui ont chacune leur algorithme
implémenter le pattern strategy et donc un objet Cell utiliserait soit un DeadCellStrategy, soit un LiveCellStrategy. Ceci à l'avantage de ne pas avoir à changer le type des instances dans la grille

Avec Smalltalk une solution utilisée pour implémenter le pattern strategy se basait sur les Closures et évitait de créer des classes supplémentaires:

  Cell>>#liveCellStrategy
    ^ [(liveNeighbours < 2) or: [ liveNeighbours > 3 ]]

  Cell>>#deadCellStrategy
    ^ [(liveNeighbours = 3) not]

  Cell>>die
    shouldDieStrategy := self deadCellStrategy

  Cell>>revive
    shouldDieStrategy := self liveCellStrategy

  Cell>>#shouldDie
    ^ shouldDieStrategy value

Bilan

Journée enrichissante et éreintante. La retrospective finale en a un peu pâti vu que tout le monde était fatigué. Une proposition d'amélioration qui me plaît est de découper la session de 45mn en deux pomodoro de 20mn pour ménager notre énergie.

Quelques "Smalltalk c'est cool" font plaisir ;)

En tout cas je reste convaincu par l'approche pair-programming qui est trés enrichissante et donne du courage pour explorer de nouvelles pistes et aller plus vite (car on se perds moins).

C'est dans ces moments là qu'on sent que la programmation est un artisanat au sens noble du terme, où la beauté du résultat est une source de motivation.

Par @bootis quality = you know why it works

Le compte-rendu de Johan

PharoConf Annecy 2011

2011-01-14T07:56:00.000+01:00

La première PharoConf Annecy aura lieu le jeudi 10 février à l'IMUS.

Site web de l'évènement: http://pharoconf-annecy.seasidehosting.st/

Les interventions seront plus tournées vers des coding-dojo et ateliers, développer du vrai code qui tourne :)

Deux points forts:
- Randori Test-Driven Development animé par Miguel Moquillon du Club Agile Rhône Alpes
- PharoSprint animé par Stéphane Ducasse

Entrée gratuite, mettez à jour vos agendas !

(Et merci de faire passer le message :)

Petite horloge

2011-01-10T22:42:00.000+01:00

Morphic basics with a little Watch (Horloge in french).

Add the class:

StringMorph subclass: #Horloge
 instanceVariableNames: ''
 classVariableNames: ''
 poolDictionaries: ''
 category: 'Sandbox'

One method called periodically thanks to stepping mechanism of Morphic:

Horloge>>step
 self contents: Time now printString.

Then evaluate in a Workspace: Horloge new openInWorld.

Stop the watch: Horloge allInstances last stopStepping

Start it again:Horloge allInstances last startStepping

Finally close it:Horloge allInstances last delete

My cat is a Linux geek :)

2010-12-04T09:30:00.000+01:00

Revenge of Smalltalk

2010-11-28T09:41:00.008+01:00

(Joke inside)

In Paul Graham's essay Revenge of the Nerds (Read it, good ideas there):

Appendix: Power

As an illustration of what I mean about the relative power of programming languages, consider the following problem. We want to write a function that generates accumulators-- a function that takes a number n, and returns a function that takes another number i and returns n incremented by i.

(That's incremented by, not plus. An accumulator has to accumulate.)

In Common Lisp this would be

(defun foo (n)
  (lambda (i) (incf n i)))

In Smalltalk the code is slightly longer than in Lisp:

foo: n                              
  |s|                      
  s := n.                          
  ^[:i| s := s+i. ]

because although in general lexical variables work, you can't do an assignment to a parameter, so you have to create a new variable s.

Well, the Lisp code has 34 significant characters while the Smalltalk code has only 25 significant characters (we can remove the last dot). So the Smalltalk code is 26% shorter than the Lisp code :)

Perl example: 32 characters
Javascript example: 46 characters
Python example: 54 characters

Yeah, Smalltalk is really powerful ;P

Update:
Looking at Parser code we can easily remove the temp. variable limitation and write:

foo: n               
  ^[:i| n := n+i]

One power of Smalltalk is to be able to change the system.
17 significant characters: Smalltalk 100% more powerful than Lisp :D

Why this design decision ? Some explanation from Nicolas and Adrian.