June 2011 - Esug-list - lists.esug.org

we should all put this logo on our web sites :)
by Stéphane Ducasse June 7, 2011

June 7, 2011

Stef

2 1

International Workshop on Smalltak Technologies
by Loic Lagadec June 5, 2011

June 5, 2011

IWST @ ESUG 2011 International Workshop on Smalltalk Technologies ACM In-Cooperation August 23th, 2011 Edinburgh, Scotland http://www.esug.org/Conferences/2011/International-Workshop-on-Smalltalk-Te… SUBMISSION DEADLINE : June 17, 2011 Authors of the best accepted papers will be invited to submit extended versions of their papers for publication in a special issue of 'Software: Practice and Experience' ------------------------------------------------------------------------ ESUG 2011 Smalltalk joint event IMPORTANT DATES * Submission deadline: June 17, 2011 * Notification deadline: July 15, 2011 GOALS AND SCOPE We are proud to invite submisssions to the International Workshop on Smalltalk Technologies which is held as part of the ESUG 2011 joint event at Edinburgh. The goals of the workshop is to create a forum around advances or experience in Smalltalk and to trigger discussions and exchanges of ideas. Participants are invited to submit short and not-so short research articles. We will not enforce any length restriction. However we expect papers of two kinds: * Short position papers describing emerging ideas. * Long research papers with deeper description of experiments and of research results. TOPICS We welcome contributions on all aspects, theoretical as well as practical, of Smalltalk related topics such as: * Aspect-oriented programming, * Meta-programming and Meta-modeling, * Frameworks, * Interaction with other languages, * Implementation, new dialects or languages implemented in Smalltalk, * Tools, * Design patterns, * Experience reports PUBLICATION Both submissions and final papers must be prepared using the ACM SIGPLAN 10 point format. Templates for Word and LaTeX are available at http://www.acm.org/sigs/sigplan/authorInformation.htm; this site also contains links to useful informations on how to write effective submissions. PROGRAM CHAIRS: * Loïc Lagadec (Labsticc, University of Brest, France) * Alain Plantec (Lisyc, University of Brest, France) PROGRAM COMMITTEE: * Gabriela Arevalo * Marcus Denker * Johan Fabry * Lukas Renggli * Hernan Wilkinson * Damien Cassou * Alexandre Bergel * Jordi Delgado * Johan Brichau

3 2

Call For Papers: IWST@ESUG2011
by Alain Plantec June 4, 2011

June 4, 2011

IWST @ ESUG 2011 International Workshop on Smalltalk Technologies ACM In-Cooperation August 23th, 2011 Edinburgh, Scotland http://www.esug.org/Conferences/2011/International-Workshop-on-Smalltalk-Te… SUBMISSION DEADLINE : June 17, 2011 Authors of the best accepted papers will be invited to submit extended versions of their papers for publication in a special issue of 'Software: Practice and Experience' ------------------------------------------------------------------------ ESUG 2011 Smalltalk joint event IMPORTANT DATES * Submission deadline: June 17, 2011 * Notification deadline: July 15, 2011 GOALS AND SCOPE We are proud to invite submisssions to the International Workshop on Smalltalk Technologies which is held as part of the ESUG 2011 joint event at Edinburgh. The goals of the workshop is to create a forum around advances or experience in Smalltalk and to trigger discussions and exchanges of ideas. Participants are invited to submit short and not-so short research articles. We will not enforce any length restriction. However we expect papers of two kinds: * Short position papers describing emerging ideas. * Long research papers with deeper description of experiments and of research results. TOPICS We welcome contributions on all aspects, theoretical as well as practical, of Smalltalk related topics such as: * Aspect-oriented programming, * Meta-programming and Meta-modeling, * Frameworks, * Interaction with other languages, * Implementation, new dialects or languages implemented in Smalltalk, * Tools, * Design patterns, * Experience reports PUBLICATION Both submissions and final papers must be prepared using the ACM SIGPLAN 10 point format. Templates for Word and LaTeX are available at http://www.acm.org/sigs/sigplan/authorInformation.htm; this site also contains links to useful informations on how to write effective submissions. PROGRAM CHAIRS: * Loïc Lagadec (Labsticc, University of Brest, France) * Alain Plantec (Lisyc, University of Brest, France) PROGRAM COMMITTEE: * Gabriela Arevalo * Marcus Denker * Johan Fabry * Lukas Renggli * Hernan Wilkinson * Damien Cassou * Alexandre Bergel * Jordi Delgado * Johan Brichau

1 0

Fwd: [Pharo-project] Smalltalk in Geneva, anyone?
by Stéphane Ducasse June 4, 2011

June 4, 2011

Begin forwarded message: > From: Hilaire Fernandes <hilaire.fernandes(a)gmail.com> > Date: June 4, 2011 8:51:47 AM GMT+02:00 > To: pharo-project(a)lists.gforge.inria.fr > Subject: [Pharo-project] Smalltalk in Geneva, anyone? > Reply-To: Pharo-project(a)lists.gforge.inria.fr > > > -- > Education 0.2 -- http://blog.ofset.org/hilaire > >

1 0

Fwd: Re: Proposal for Mock Objects at ESUG 2011
by Joseph Pelrine June 3, 2011

June 3, 2011

Hi all, I took the liberty of forwarding this mail to Tim Mackinnon and Steve Freeman, who invented the original Mock Objects. Here's Steve's answer. I'll forward further mails to this list. -------- Original Message -------- Subject: Re: [Esug-list] Proposal for Mock Objects at ESUG 2011 Date: Fri, 27 May 2011 09:25:30 +0100 From: Steve Freeman <steve(a)m3p.co.uk> To: Joseph Pelrine <jpelrine(a)metaprog.com> You should talk to Tim, he wrote a mocks library in about 3 classes (which is what it should take). He also has some interesting experience from the Kapital project that doesn't have unit tests. I hadn't realised that the ST world was behind in this respect. S. On 27 May 2011, at 05:41, Joseph Pelrine wrote: > FYI > > -------- Original Message -------- > Subject: [Esug-list] Proposal for Mock Objects at ESUG 2011 > Date: Fri, 27 May 2011 08:36:27 +0400 > From: Dennis Schetinin <chaetal(a)gmail.com> > To: ESUG Mailing list <esug-list(a)lists.esug.org> > > > > Hello! > > I'd like to explore interest to Mock Object in Smalltalk society. I'm > currently working on the topic, preparing a paper and presentation > targeting at ESUG 2011. > > I plan to present Mock Objects technique itself and a framework named > Mocketry as a tool helping to apply it in practice. Of course I'll > provide a small example to illustrate some of the ideas. > > Apparently, Mocks technique is not popular tool among Smalltalkers. It > even seems (to me), TDD is not as widely used as it could and should be > (despite the fact it was born in Smalltalk). I have been using TDD and > Mocks for many years in different projects with Smalltalk and other > languages. Sometimes it was hard, sometimes I was even giving it up, but > by now I think I have sufficient experience to state that TDD in general > and Mock Objects specifically do deserve (at least) more attention by > smalltalkers. Yes, Smalltalk is great language and it has great tools. > This damps some aspects of the problems TDD and Mocks address, but for > sure does not remove them totally. More than that, I can say I was most > productive in Smalltalk when I used "classic TDD" and mocks in conjunction. > > > So, are other Smalltalkers interested in this topic? Do you think it > worth to be presented at the conference? What are the problems you'd > like to discuss there? > > TIA > > -- > Dennis Schetinin > <Attached Message Part.txt> Steve Freeman Winner of the Agile Alliance Gordon Pask award 2006 Book: http://www.growing-object-oriented-software.com +44 (0) 797 179 4105 M3P Limited. http://www.m3p.co.uk Registered office. 2 Church Street, Burnham, Bucks, SL1 7HZ. Company registered in England & Wales. Number 03689627

9 12

Re: [Esug-list] ESUG SummerTalk - Fuel, binary object serializer
by Marcus Denker June 1, 2011

June 1, 2011

On May 25, 2011, at 7:35 PM, Yoshiki Ohshima wrote: > At Wed, 25 May 2011 15:28:00 +0200, > Mariano Martinez Peck wrote: >> >> One of the most important uses we want to do with Fuel (in a future) is to be able to use it for Monticello (to replace mzc). >> The idea in addition is to be able to boostrap a really small pharo image (hetzel) and be able to load stuff without needing a compiler. > > Sounds interesting! Can I learn about "hetzel" somewhere? > We are working on how to build minimal Pharo kernels (with the goal of a declarative bootstrap so you can build your own version of Smalltalk running in the normal Pharo image to experiment with new language features, as one example, or create a minimal image for deployment). There is some information from Nicolas Paez who worked on this when visiting RMOD last year: http://www.fast.org.ar/smalltalks2010/videos/Seed+project%3A+The+challenge+… http://rmod.lille.inria.fr/archives/talks/2010-Smalltalks-Paez-Seed.pdf The status is that we learned a lot and continue to work on it... more to come later ;-) Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

7 22

Re: [Esug-list] Proposal for Mock Objects at ESUG 2011
by Colin Putney June 1, 2011

June 1, 2011

On Fri, May 27, 2011 at 12:42 PM, Frank Shearar <frank.shearar(a)gmail.com> wrote: > You miss the point of mocks. Mocks are there to allow you to test your > code quickly and cheaply against things that may not work in a quick > manner. Not likely. Hernán has been around the block and he speaks from long experience and deep thinking on software design. If you read his post a little more carefully, you'll see that he distinguishes between test doubles in general and mocks as a particular form of test double. He uses test doubles - you don't get 23,000 tests to run in 7 minutes without them. It's just *mocks* that are mostly unnecessary. Personally, I find that mocks are *very* useful in a few very specific situations, but they can cause problems it other situations. They're like a very specialized tool - invaluable when you need it, but kept in the bottom of the toolbox and not used very often. Where I find them useful is in testing communication. For example, I'll use a MockWritestream to throw an exception if the code under test writes something unexpected into the stream. It's handy when testing code that writes out files in a particular format, or communicates with remote systems over the network. It might also be useful to test communications across formal module boundaries, where it's particularly important that a specific protocol be used - eg, for something like Prevalayer. My favourite testing pattern is TrivialImplementation. Instead of using a test double or an expensive "real" object, I often create a cheap/trivial implementation of the objects that collaborate with the objects I'm testing. For example, Monticello2 has several repository classes. There are implementations that store code in a single file, in a directory of files, on a remote machine via sockets, on a web server via HTTP etc. There's also a trivial implementation that just uses an in-memory Dictionary for storage. It's a complete implementation of the repository protocol, and Monticello can use it "for real", but it's not as robust as the other kinds of repository. All the repository implementations, including MemoryRepository, have a suite of tests that ensure that they work correctly. But when I'm testing other parts of Monticello that interact with a repository, those tests use a MemoryRepository. I know that BDD folks like to talk about testing behaviour rather than state, but I don't find the distinction useful. Testing state breaks the encapsulation of the objects under test, and couples the test too closely to their internal implementation. Testing behaviour using mocks *does the same thing*; it just restricts the implementation in a different way. I find it's better to give the implementation a degree of freedom by testing "results". Figuring out what result you're looking for can be difficult - it requires thinking about what a passing test really tells you. Here's an example - let's say we we're testing an implementation of Set. Here's the version that tests state: | set | set := Set new. set add: 3. self assert: (set instVarNamed: 'array') = #(nil nil nil 3 nil) Here we test behaviour: | set | mock := MockArray new: 5 mock expect: (Message selector: #at:put: arguments: #(4 3)). set := Set withArray: mock. set add: 3. I prefer this approach. It gives the implementation a lot of freedom, while ensuring that it does what we really want: | set | set := Set new. set add: 3. self assert: (set includes: 3). In short, I agree with Hernán. Mocks can be useful, but they're often overused. In most cases, they're unnecessary. Colin

4 5