Hi,
Again, long time since the last entry. Ok, so let's make this clear in case someone did not notice, this is a low activity blog. And the activity will remain low in the foreseeable future.
Now, some news from Barcelona.
We are still active: Marina has almost finished her modification of the Scratch image (no kidding, she is developing with Squeak 2.8) to program Arduino robots with Scratch, Joan tried to port Scratch to Pharo, but it is not easy at all and not a one-person job, so this project is delayed until more people join (but he is learning quite a lot on the inner workings of Squeak!), some of us are still developing the FluidDB API, though the main work up to now has been made by Sergio Garcia, Bernat is in Beijing (China) trying to promote Smalltalk-Pharo among chinese Linux programmers, and Gerard keeps the good work on his UIBuilder. On the other hand, the organization of ESUG'10 has left the back of our head to get a prominent position in our frontal cortex. I mean, we already are working on it.
Besides, the translation of Pharo by Example to spanish has already started, coordinated by Gabriela Arevalo. I am sure we will finish before ESUG'10. It will be a nice novelty.
In a couple of weeks Stéphane Ducasse will visit us, and he will teach a postgraduate course at the UPC (Technical University of Catalonia). Of course, if you are interested in Smalltalk, you are invited to attend.
The course will take place from Monday Feb. 8th to Friday Feb. 12th (every day, 10am to 12am) in the Omega Building, room S216, Campus Nord UPC, Barcelona.
Advanced Object-Oriented Design
Abstract: This lecture will cover advanced design aspect of object-oriented programming, using concrete examples. We will think about what polymorphism deeply implies and its effect on application design. We will revisit the exact semantics of self and super and their impact on frameworks construction. We will present the law of demeter, criteria to assess inheritance versus inheritance, the difference interfaces that a class present, double dispatch as well as some other design points such as the right way to handle preferences in large system. We will also discuss design pattern but in a non traditional way.
I am pretty sure we will have a great time!
Next wednesday, October 14th, there will be a Smalltalk hackaton in Barcelona. It is a joint event with Citilab Breakout and it will take place at WTC Almeda Park in Cornella (here) from 9am to 6pm.
After the summer break, the Smalltalk workgroup in Barcelona decided to invest the spare time of its members (almost none of them is paid to program in Smalltalk) building a Pharo API for a new kind of database: FluidDB. After that, our plans include to develop a Smalltalk application using this new API to make clear the advantages of using FluidDB. The main purpose of this, our first, hackaton will be to push forward this project.
Here you can see a screenshoot of a simple GUI for our first preliminary FluidDB classes that, among other things, allow us to query the sandbox. The GUI was made by Raimon Grau, with Jose Garcia's FluidDB classes and Gerard's -aka nullPointer- UIBuilder. We are a team!
Terry Jones (founder of FluidDB) made clear yesterday, in a private e-mail, his willingness to join us at the hackaton. That would be great, since grasping the full potential of FluidDB is far from trivial.
Anyway, if you are around and want to join us, just do it...
Long time since I wrote something in here, but I've been very busy. With Smalltalk, of course. Anyway, that does not matter. Nothing matters right now, except that, as announced in Brest past friday, the next ESUG Conference will be organized by... US!! The Smalltalk group in Barcelona!! Nothing matters because at the current level of excitement it is very difficult to pay attention to anything else.
First of all, I would like to thank Stéphane Ducasse, the ESUG board and the Brest conference organizers for such a great event. It was my first ESUG conference, but if people attending next ESUG at Barcelona enjoys the conference as much as I enjoyed the conference at Brest, I will be very, very happy.
We are a very young and strongly motivated group of Smalltalk enthusiasts, though I know that that does not compensate our lack of experience with Smalltalk. This lack of experience was clearly apparent at Brest, where I could see what Smalltalk experts are currently doing. That was amazing! Just let me mention the submissions to the Innovation Technology Awards, and the winner, Retrobjects by Gabriel Honoré. However, just seeing what we can accomplish if we keep on learning and programming gave a boost to our enthusiasm.
Of course, I am aware that the place, Barcelona, and not my/our Smalltalk merits, was what mostly determined the choice of the next ESUG event. That, and the delicious dinner we had with some of the members of the ESUG board, where I guess they realized that our proposal was not completely crazy. I thank them a lot the trust they have put in our group.
We'll be back with a small document introducing ourselves to the Smalltalk community.
No ha hagut massa activitat des del post del Bernat (gràcies Bernat!) però això nomès ha estat al blog. Dins del món real, el GTS ha continuat treballant com sempre, o més si cal.
L'Scorer del Bernat ja es fa servir a l'Escola Mestral de Sant Feliu de Llobregat. Així doncs, ja tenim nens aprenent música gràcies a Squeak! A més, continua treballant fort en el seu TFC basat en Seaside: EduTech. Els que hem vist els seus progressos estem certament impressionats pel que es pot fer amb una bona eina (vull dir Seaside) si ets prou hàbil (vull dir en Bernat).
La Marina encara no ho sap, però un munt de nens i no tan nens aprendran Smalltalk gràcies a ella. Al Citilab estem planejant tota una renovació dels nostres cursos de programació basada en la seva feina. De moment, i fent servir les darreres versions de Pharo (Closures Inside), els nostres robots Arduino es mouen sobre rodes, detecten parets, encenen leds i xiulen melodies, diguèssim, tolerables. Tot plegat es farà públic durant el curs 2009/10. Abans, però, ho ha de defensar en forma de projecte fí de carrera.
Les sessions del GTS han continuat sent molt interessants. En Ray ens va explicar nocions bàsiques d'AIDA, l'altre framework Web per a Smalltalk. Molt interessant. A mi personalment m'agradaria poder tenir temps per conèixer bé tots dos frameworks. En Jose va dedicar una sessió més a insistir sobre Polymorph. Aquesta, lamentablement, me la vaig perdre, però considerant la nostra descarada preferència per Pharo, conèixer bé Polymorph és una necessitat.
Vaig començar una sèrie de sessions dedicada als processos dins d'Squeak, basant-me sobre tot en el capítol 9 del llibre francès Squeak programmation de Xavier Briffault, i també en el capítol 15 del llibre blau. Una cosa és certa, des de que les closures estan implementades com cal, jugar amb processos és molt més agradable. A un Squeak amb les closures sense arreglar proveu d'executar (al workspace per exemple):
| s p1 p2 |
s := SharedQueue new: 20.
p1 := [1 to: 10 do: [:i | s nextPut: i. Processor yield.]] newProcess.
p2 := [11 to: 20 do: [:i | s nextPut: i. Processor yield.]] newProcess.
p1 priority: Processor activePriority - 1.
p2 priority: Processor activePriority - 1.
p1 resume. p2 resume.
s inspect.
i compareu el resultat que obteniu amb el que veieu desprès de fer:
| s p1 p2 |
s := SharedQueue new: 20.
p1 := [(1 to: 10) do: [:i | s nextPut: i. Processor yield.]] newProcess.
p2 := [(11 to: 20) do: [:i | s nextPut: i. Processor yield.]] newProcess.
p1 priority: Processor activePriority - 1.
p2 priority: Processor activePriority - 1.
p1 resume. p2 resume.
s inspect.
i vinga, a pensar!
La cosa té a veure amb l'implementació defectuosa de les closures a Squeak (com vaig saber gràcies a alguns membres de la comunitat Squeak, que van respondre dins d'squeak-dev als meus dubtes; moltes gràcies a tots ells). Naturalment aquest codi no suposa cap mal de cap quan l'executem a les darreres versions de Pharo. Ens vam deixar per explicar un exemple clàssic, el del sopar dels filòsofs. No sé quan podré tornar-m'hi a posar, però ho acabaré explicant.
Un correu del Juan Miguel a la llista del grup va propiciar una sessió sobre la Reflexió en Smalltalk, amb èmfasi especial en la interceptació de missatges. Basant-nos en les transparències Reflection, del curs open source del Prof. Oscar Nierstrasz vam estar fent un repàs a la darrera lliçó del curs de POOS, que alguns membres del grup tenien (ejem!) una mica oblidada. Les característiques reflexives d'Smalltalk són sorprenents (fixeu-vos en aquest article de fa vint anys!) i, encara que pertanyen clarament al coneixement avançat del llenguatge, posar-s'hi com abans millor fa que l'experiència Smalltalk sigui molt més divertida. I d'això es tracta, no?
Finalment, deixeu-me recordar-vos que, si us interessa l'ensenyament de la programació per a nens i nenes, no us perdeu les nostres activitats del dissabte dia 16 de maig al matí (vegeu l'anunci): el congrès Programa 2009 i la festa del Dia d'Scratch.
English:
There hasn't been too much activity since the post from Bernat (cheers Bernat!) but that has only been on the Blog. Within the real world, the GTS has gone on working as usual...
Bernat's Scorer is already getting well used at the school Escola Mestral de Sant Feliu de Llobregat. Thus, we already have kids learning music thanks to Squeak! On top of that, he's continuing to work hard in his final project degree based in Seaside: EduTech. Those of us that have seen his work-in-progress are certainly well impressed with what can be done with a good tool (a.k.a Seaside) if you are clever enough (a.k.a. Bernat).
Marina doesn't know it yet, but a horde of adults and kids will learn Smalltalk thanks to her. At Citilab we're planning a total overhaul of our programming courses based on her work. So far, and using the latest versions of Pharo (Closures Inside), our Arduino robots can move around on wheels, they detect walls, they light LED's and whistle - let's just say - tolerable, melodies. All in all, we'll make it public sometime during 2009/10. However, beforehand, it has to be defended as her final project degree.
The GTS sessions have continued being very interesting. Ray outlined to us basic notions of AIDA, the other web framework for Smalltalk. Very interesting. I personally would be pleased to have the time to get to grips with both of the frameworks. Jose dedicated another session to pushing Polymorph even further. Unfortunately I missed that one, but considering our barefaced and cheeky preference for Pharo, getting to grips with Polymorph is a necessity.
I began a series of sessions dedicated to processes within Squeak, with the thrust of it being based on chapter 9 of the french book Squeak programmation by Xavier Briffault, and also chapter 15 of the blue book. One thing is certain, since closures are implemented as it needed to be, playing with processes is a whole lot more agreeable. For a Squeak with closures without fixing have a go at executing:
| s p1 p2 |
s := SharedQueue new: 20.
p1 := [1 to: 10 do: [:i | s nextPut: i. Processor yield.]] newProcess.
p2 := [11 to: 20 do: [:i | s nextPut: i. Processor yield.]] newProcess.
p1 priority: Processor activePriority - 1.
p2 priority: Processor activePriority - 1.
p1 resume. p2 resume.
s inspect.
and compare the result that you end up with after doing:
| s p1 p2 |
s := SharedQueue new: 20.
p1 := [(1 to: 10) do: [:i | s nextPut: i. Processor yield.]] newProcess.
p2 := [(11 to: 20) do: [:i | s nextPut: i. Processor yield.]] newProcess.
p1 priority: Processor activePriority - 1.
p2 priority: Processor activePriority - 1.
p1 resume. p2 resume.
s inspect.
and there you are, get your head round that!
It all has something to do with defective implementing of closures in Squeak (as I found out thanks to some members of the Squeak community, who replied within squeak-dev to my queries; many thanks to them all). Naturally that code doesn't cause a headache executed to the latest versions of Pharo. We ended up leaving out a classic example, the dining philosophers problem. I don't know when I'll be able to put it again but I'll end up telling it.
An email from Juan Miguel to the group-list instigated a session on Reflection in Smalltalk, with a special emphasis on intercepting messages. Based on the slides Reflection, from Prof. Oscar Nierstrasz open source course, we were going back over the last lesson of the POOS course, which was lost in the mists of time by some members of the group (mentioning no names!). The reflexive characteristics of Smalltalk are surprising (pay attention to this twenty years old paper!), even though they clearly belong to advanced knowledge of the language, getting down to it at the earliest possible opportunity makes the Smalltalk experience a whole lot more fun. And that surely is the point, isn't it?
Finally, let me remind you that, if you are interested in the teaching of programming for kids, do not miss our activities for Saturday 16th May in the morning (see this ad): the Programa'09 congress and the Scratch Day fiesta.
HOWTO: Build a simple Seaside website in 30 minutes
Guest author: Bernat Romagosa Carrasquer
So you have 30 minutes to spare and a website to code. Don't panic, keep reading!
This is a very quick guide to get your first Seaside website running, I'm guessing you've already read both A walk on the Seaside and (at least some of) An Introduction to Seaside, so I'm gonna omit some basic concepts you should already be familiar with by now. Oh, and yes, it's really gonna take 30 minutes.
Our first website is going to have a couple of tabs, a header and some random contents. Just what you need.
FIRST STEP: A root component and some empty "tabs"
Open the class browser, create a new category, name it whatever.
Create a new subclass of WAComponent, name it WhateverRoot:
WAComponent subclass: #WhateverRoot
instanceVariableNames: 'aCoupleOfTabs selectedTab'
classVariableNames: ''
poolDictionaries: ''
category: 'Whatever'
Now get to the class side and add the following methods:
WhateverRoot class >> canBeRoot
^trueWhateverRoot class >> initialize
(self registerAsApplication: 'whatever')
WhateverRoot class >> description
^ 'A website about whatever'
I'm guessing you already know what the first method is for, the second one just tells your Seaside configuration this is an App [1]. I think the third one is quite self-explanatory.
Alright, we're done with the class side, let's get back to instance and add the following methods:
WhateverRoot >> title
^ 'Whatever Website'WhateverRoot >> updateRoot: aHtmlRoot
super updateRoot: aHtmlRoot.
aHtmlRoot title: self title
Again, the first method is obvious. The role of the second one is -in a nutshell- to allow you to use CSS styles, JavaScript and other fancy stuff in each one of your components. Actually, I'm afraid it's a little bit more complex than this, but we don't care right now. Let's go on:
WhateverRoot >> states
^ Array with: self
"states" is the method that allows you to use the famous back-button feature. It's up to you to implement it, but you might need it later on, and since we still have a minute to spare we can add it now ;)
Adding the next method is going to ask you what do you want to do with some selectors we haven't defined yet, just tell Seaside to create new classes and click "Yes" to whatever it asks you for.
WhateverRoot >> initialize
super initialize.
aCoupleOfTabs := OrderedCollection new
add: 'Welcome' -> (Array
with: 'Hey this is my website' -> WhateverHey new
with: 'What is this all about' -> WhateverWhat new);
add: 'Nice frameworks' -> (Array
with: 'Seaside' -> WhateverSeaside new);
yourself.
selectedTab := aCoupleOfTabs first value
You probably guessed it right, we initialize the website by creating an OrderedCollection of tabs, which we assign to our aCoupleOfTabs instance variable. Step by step:
- This collection contains the names of the tabs we will need in our website.
- Each of those tabs contain an array of assignations.
- Each of those assignations link a string (which will be displayed later) to a component (which we will create later on).
How long did that take? 10 minutes? Your duin it purrfect!
SECOND STEP: Actually printing something
We go on adding instance methods to our Root component (WhateverRoot):
WhateverRoot >> renderContentOn: html
self renderHeaderOn: html.
html div id: 'tabs'; with: [self renderTabsOn: html].
self renderChildrenOn: html
This method, as you may know, is called every time we access the root component (that is... pretty much all the time). We've added three renderers, each of which is going to print out a different section of our root page, namely: a header, some tabs, some content.
But wait! We should tell Seaside how to actually render all this:
WhateverRoot >> renderHeaderOn: html
html div id: 'header';
with: [html heading: self title]
WhateverRoot >> renderTabsOn: html
html unorderedList id: 'tabs'; with: [
aCoupleOfTabs do: [ :each |
html listItem: [
html anchor
class: (selectedTab = each value
ifTrue: [ 'active' ]);
callback: [ selectedTab := each value ];
with: each key ] ] ]
WhateverRoot >> renderChildrenOn: html
html div id: 'content'; with: [
selectedTab do: [ :each |
html heading: each key.
html paragraph; render: each value.
html paragraph ] ]
The first method is too short to deserve an explanation. Let's take a quick look at the second one: We are creating an unorderedList (Pay attention! An HTML unorderedList, not a Smalltalk one...) of links (anchors) each of which corresponds to an item of our aCoupleOfTabs collection and setting it to link the selected tab with the instance variable we named after that purpose.
About the third method, you're probably wondering what a child is (seasidely speaking, of course). To put it simple, a child is nothing but a branch of the root component. Our website has a main structure defined in our root component, and as we go navigating through anchors, some parts of the website keep changing. Those changing parts are called children. So, when we select a tab, selectedTab will become a reference to that tab, and renderChildrenOn will print out a heading with that tab's name, its contents and an empty paragraph. It probably looks complicated. It's not. Just wait until the end of the tutorial.
Believe me, there's only 10 minutes left and that's more than enough.
THIRD STEP: Filling the website with info
This is the easiest task of them all, we just need to create a new component for each piece of information (remember WhateverHey, WhateverWhat, WhateverSeaside?). You might have asked Seaside to create them automatically when you accepted the "initialize" method of the Root Component, in that case you'll just need to change their superclasses. Let's go!
WAComponent subclass: #WhateverHey
instanceVariableNames: ''
classVariableNames: ''
poolDictionaries: ''
category: 'Whatever'
WAComponent subclass: #WhateverWhat
instanceVariableNames: ''
classVariableNames: ''
poolDictionaries: ''
category: 'Whatever'
WAComponent subclass: #WhateverSeaside
instanceVariableNames: ''
classVariableNames: ''
poolDictionaries: ''
category: 'Whatever'
And now we should type something into the RenderContentOn method of these new classes:
WhateverHey >> renderContentOn: html
html paragraph: 'Hi, this is my website. It only took me 30 minutes to build it. Cool huh?'
WhateverWhat >> renderContentOn: html
html paragraph: 'This website has no useful content whatsoever...'.
html paragraph: 'I just needed to type some nonsense to see it working :)'.
WhateverSeaside >> renderContentOn: html
html paragraph: 'This framework is very nice because:'.
html orderedList with: [html listItem: 'It is fast';
listItem: 'It is easy';
listItem: 'It is Smalltalk'].
TIME!
We're done! Go to http://localhost:8080/seaside/config and follow the next steps:
- In the "Add entry point" form, "Name" inputfield, type "whatever".
- Click "Add".
- In the "Configuration" form, choose "WhateverRoot" from the "Root Component" dropdown menu.
- Click "Save".
- Go to http://localhost:8080/seaside/whatever
Okay, I cheated. I said we were gonna build a website in 30 minutes and we actually did, but we're gonna need like 10 more minutes for an acceptable CSS, which I'm not going to explain because it's pretty easy to read, I know as much CSS or less than you do, and it's definitely out of the matter anyway.
FOURTH STEP: Making it less ugly
CSS can be edited directly online on the fly by toggling halos and clicking on the RootComponent's CSS icon, or by coding it inside a method called style. We're choosing the second way.
WhateverRoot >> style
^ '
body{
background-color: #aeeeee;
}
#header{
width: 100%;
height: 40px;
padding-left: 5px;
background-color: #d7eeee;
}
#content{
font-family: arial;
text-align: justify;
margin-left: 5px;
margin-right: 5px;
padding-left: 5px;
padding-right: 5px;
padding-top: 5px;
padding-bottom: 5px;
background-color: #f7eeee;
}
#tabs{
list-style-type: none;
}
#tabs li{
display: inline;
}
#tabs li a{
text-align: center;
width: 100%;
height: 25px;
color: #000;
background-color: #d7eeee;
margin: 0.5em;
padding: 0.5em;
font-size: 12px;
text-decoration: none
; }
#tabs li a:hover{
font-weight: bold;
}
'
I HAS A WEBSITE KTHXBYE!
Bernat Romagosa Carrasquer
Smalltalk WorkGroup 2009
smalltalk.cat
[1] This method is deprecated in Seaside 2.9, instead we'd use:
WhateverRoot class >> initialize
WAAdmin register: self asApplicationAt: 'whatever'
Thanks to Torsten Bergmann for pointing this out and for other details.