- Pharo-users - lists.pharo.org

Re: [Pharo-users] How are people doing TDD?

by Benjamin

In Pharo 2.0 Nautilus have a better integration of test and of shortcuts. Because of a lack of time (or of people) Nautilus is not maintained in 1.4, since the focus is 2.0 since a while. About the combination with AutoTest, it's really possible (and could be really cool) to implement a AutoTest plugin for Nautilus (the whole plugin mechanism has been designed for AutoTest actually ^^) Can you try in 2.0 and give some feedback ? :) Thanks in advance, Ben On Dec 18, 2012, at 3:32 AM, Stuart Herring wrote: > On 18 December 2012 13:10, Tim Mackinnon <tamackinnon(a)gmail.com> wrote: >> I really like the new Toggle from Class to Test (cmd-j) option that got >> introduced - someone has definitely been writing tests in Pharo - however it >> does my head in that pressing it after editing a method doesn't jump me >> back. I also find the same problem when editing a test - that pressing cmd-t >> to run it, just puts a "t" in my source code and doesn't run the test. >> > I have the same frustration with alt/cmd-t it kind of defeats the > purpose of a keyboard shortcut if you've got to click somewhere on the > screen first before you can use it. > > Have you looked at Autotest? http://squeaksource.com/Autotest.html > It will run tests whenever you save them, and also tries to determine > which tests to run when you modify model classes. The only thing > that's a little bit disappointing is that it doesn't update the test > indicators in the browser. > > I wonder if in Pharo 2.0 someone could combine the concepts of the > in-browser test runner and Autotest. So that accepting changes in the > browser uses the same heuristics autotest does to run the tests, and > then uses the Growl style notifications for failures, with the > green/red/yellow test indicators being updated. > > Regards, > Stuart >

Dec. 18, 2012

Re: [Pharo-users] What makes code unreadable ( was Re: Nautilius Method Source Pane Coloring )

by Attila Magyar

Yes, bad names, long methods, mixed level of abstractions for example Sent from my ASUS Eee Pad dimitris chloupis <thekilon(a)yahoo.co.uk> wrote: > > >you mean by "unreadable code" , bad choice of naming methods and variables or something more than that , or something else ? > > >From: Attila Magyar <m.magyar3(a)gmail.com> >To: dimitris chloupis <thekilon(a)yahoo.co.uk>; A friendly place where any question about pharo is welcome <pharo-users(a)lists.gforge.inria.fr> >Sent: Tuesday, 18 December 2012, 15:46 >Subject: Re: [Pharo-users] Nautilius Method Source Pane Coloring > > >On Tue, Dec 18, 2012 at 10:42 AM, dimitris chloupis <thekilon(a)yahoo.co.uk> wrote: > >Another example would be not to allow accepting a method if is not commented. Could annoy some people , but I wonder if there is any real benefit in the long ru > > >I think, using comments inside methods and documenting libraries and projects are fairly different topics. I found people often using lots of comments as an excuse for writing unreadable code. But documenting the usage of a library is unarguably important. > > >

Dec. 18, 2012

What makes code unreadable ( was Re: Nautilius Method Source Pane Coloring )

by dimitris chloupis

you mean by "unreadable code" , bad choice of naming methods and variables or something more than that , or something else ? ________________________________ From: Attila Magyar <m.magyar3(a)gmail.com> To: dimitris chloupis <thekilon(a)yahoo.co.uk>; A friendly place where any question about pharo is welcome <pharo-users(a)lists.gforge.inria.fr> Sent: Tuesday, 18 December 2012, 15:46 Subject: Re: [Pharo-users] Nautilius Method Source Pane Coloring On Tue, Dec 18, 2012 at 10:42 AM, dimitris chloupis <thekilon(a)yahoo.co.uk> wrote: Another example would be not to allow accepting a method if is not commented. Could annoy some people , but I wonder if there is any real benefit in the long ru I think, using comments inside methods and documenting libraries and projects are fairly different topics. I found people often using lots of comments as an excuse for writing unreadable code. But documenting the usage of a library is unarguably important.

Dec. 18, 2012

Re: [Pharo-users] Nautilius Method Source Pane Coloring

by Attila Magyar

On Tue, Dec 18, 2012 at 10:42 AM, dimitris chloupis <thekilon(a)yahoo.co.uk>wrote: > Another example would be not to allow accepting a method if is not > commented. Could annoy some people , but I wonder if there is any real > benefit in the long ru I think, using comments inside methods and documenting libraries and projects are fairly different topics. I found people often using lots of comments as an excuse for writing unreadable code. But documenting the usage of a library is unarguably important.

Dec. 18, 2012

Re: [Pharo-users] Nautilius Method Source Pane Coloring

by dimitris chloupis

good point . I have to agree. ________________________________ From: Igor Stasenko <siguctua(a)gmail.com> To: dimitris chloupis <thekilon(a)yahoo.co.uk>; A friendly place where any question about pharo is welcome <pharo-users(a)lists.gforge.inria.fr> Sent: Tuesday, 18 December 2012, 15:22 Subject: Re: [Pharo-users] Nautilius Method Source Pane Coloring On 18 December 2012 10:42, dimitris chloupis <thekilon(a)yahoo.co.uk> wrote: > ah sorry I missed "worse even".Â I thought you suggesting that writting long > comments should be counted as negative. > > Also I never asked anybody to start documenting Morphic, I only said I would > prefer if focus was more on documentation than improving existing features. > > Also I dont find that red color thing an importan feature anyway. Though I > do find writting small readable well commented methods extremely important. > If a coder cant figure out what clean code is and why he should do it, I > don't think some red color in the side is going to stop him. > > The problem is that most people start "dirty" with the desire to clean > later, of course they realise that cleaning the code later is actually a lot > of work and never do it. > I did see that happen a lot when I was doing python for blender addons. > Fortunately the situation with pharo is a lot better. > > I am actually considering forcing clean code , with my project . Because I > will be redesigning all those tools of course basing it in the existing > great > work that there is . And was wondering how much a bad idea that is. For > example moving comments outside the method source code using something like > meta tags and forcing the method never to exceed 10 lines. Sound like a bad > idea to me, but still makes me think if there is potential. > > Another example would be not to allow accepting a method if is not > commented. Could annoy some people , but I wonder if there is any real > benefit in the long run. > this mode would be not very nice for quick prototyping. About the topic: yes, counting the number of AST elements would be better metric for determining whether code "stinks" or not :) -- Best regards, Igor Stasenko.

Dec. 18, 2012

Re: [Pharo-users] Nautilius Method Source Pane Coloring

by Igor Stasenko

On 18 December 2012 10:42, dimitris chloupis <thekilon(a)yahoo.co.uk> wrote: > ah sorry I missed "worse even". I thought you suggesting that writting long > comments should be counted as negative. > > Also I never asked anybody to start documenting Morphic, I only said I would > prefer if focus was more on documentation than improving existing features. > > Also I dont find that red color thing an importan feature anyway. Though I > do find writting small readable well commented methods extremely important. > If a coder cant figure out what clean code is and why he should do it, I > don't think some red color in the side is going to stop him. > > The problem is that most people start "dirty" with the desire to clean > later, of course they realise that cleaning the code later is actually a lot > of work and never do it. > I did see that happen a lot when I was doing python for blender addons. > Fortunately the situation with pharo is a lot better. > > I am actually considering forcing clean code , with my project . Because I > will be redesigning all those tools of course basing it in the existing > great > work that there is . And was wondering how much a bad idea that is. For > example moving comments outside the method source code using something like > meta tags and forcing the method never to exceed 10 lines. Sound like a bad > idea to me, but still makes me think if there is potential. > > Another example would be not to allow accepting a method if is not > commented. Could annoy some people , but I wonder if there is any real > benefit in the long run. > this mode would be not very nice for quick prototyping. About the topic: yes, counting the number of AST elements would be better metric for determining whether code "stinks" or not :) -- Best regards, Igor Stasenko.

Dec. 18, 2012

Re: [Pharo-users] CQRS and Event Sourcing in Smalltalk

by Norbert Hartl

Rafael, Am 17.12.2012 um 20:38 schrieb Rafael Luque <rafael.luque.leiva(a)gmail.com>: > Thank you for your responses, > > StÃ©phane, I think Fowler is not the best source for this topic, in spite of his fame. Sorry, but I'm a bit iconoclastic and my impression about him changed after the "prevalence case" [1]. I think Greg Young coined the term and is the main evangelist about CQRS and Event Sourcing. > > Norbert, I find your descriptions really interesting, but I assume that you have implemented all the required infrastructure: event bus, event store, snapshotting mechanism, etc. > I had a look at the axon framework. In order to cope with a lot of stuff the axon thing sounds utterly complex. Unless you have a project that is really complex it is probably not a good idea to go for something like axon. Smaller problems are easier and more suitable to solve. What you said that I "implemented all the required infrastructure: event bus, event store, snapshotting mechanism, etc." might be true. But - there is no event bus. Events get emitted at the most important object in the domain model (you'd probably call that aggregate root) - the event store is a collection. - commands also do not need a CommandBus because there is a central registry for handlers and commands are dispatched at the very same place - the snapshotting mechanism is implemented by me. But I would guess this is quite normal because use cases are hard to generalize. So my general advize would be to start small. Think about the central concepts of CQRS and what you need from. If you are looking at the java API and do a solution in smalltalk you just need some confidence that you didn't forget a ton of stuff only because it is much smaller and easier :) I really like the topic. If you have other inquiries or insights regarding this topic I'm always interested. If you can tell what you need I can think about what of the stuff I did might be useful to others. Norbert > What I'd like to know is if there is an Smalltalk project similar to the Axon framework for Java [2] providing implementations of the most important building blocks in CQRS architecture, such as aggregates, repositories and event buses. For instance, I think it would be specially useful a framework to build webapps after the CQRS architecture. > > [1] https://gist.github.com/1186975 > [2] http://www.axonframework.org/ > > Rafa > > 2012/12/14 Norbert Hartl <norbert(a)hartl.name> > > Am 13.12.2012 um 20:36 schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: > > > On 13 Dec 2012, at 17:56, Norbert Hartl <norbert(a)hartl.name> wrote: > > > >> Am 13.12.2012 um 17:27 schrieb StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > >> > >>>> Hi all, > >>>> > >>>> Please, anyone knows a Pharo framework to implement CQRS and/or Event Sourcing? > >>> > >>> I read in diagonal the paper of martin fowler and I would say just some command patterns? > >>> + some meta modeling? > >>> no? > >> > >> Well, you can give that particular answer to _a lot_ of problems :) I think the important part is the "event store" and how you snapshot state. So it is more or less a persistence question. Staying in-image it is rather easy. I use an approach where I still have the business objects holding state. But state is altered through commands and every command emits a set of events that get written to a timeline. The objects analyzing the timeline are more CQRS like because the state evolves out of the timeline. So I have an > >> > >> Event class with instVar time (aDateAndTime) > >> A timeline is a sorted collection (by time) of events. > >> An object has a stream on the timeline. Its position is the positional information about the snapshot state. > >> Snapshot state is updated by following the stream (next: 100, upToDate: â¦ upToEventType:â¦) > >> > >> Altogether you have sources that put events on the timeline. Separated from that you have the consumer that reads the snapshot state and updates it. > >> > >> Norbert > > > > Sounds really cool and exciting, Norbert. > > I think many people including myself are thinking along those lines. > > Next time we meet you'll have to show me ;-) > > > Sure :) I think this approach has some benefits. Normal objects can be seen as the only and most actual snapshot of a state changing history. The history gets discarded immediately. But this history has a great value in itself being able to replay/undo things or develop new values that can be applied at a later moment. We just need to look at the debugger. A stack or context chain is just a collection of moments in time. If you go up the stack we go back in time. But objects stay in the now. It would just be perfect if the object state would go back in time as well. > > Let's take a networked service as an example. If we look more closely we can see a snapshot of data is about actuality and consistency. We always like to have consistent data. But actuality is ambiguous in a concurrent media with non-deterministic latencies like the internet. If we separate these we find the need to have data that is consistent at any point in time. But reading the data does not have to return the newest state available. > So we divide the process into three things: adding state change, updating state snapshot, reading state snapshot. The adding is an append-only operation that can be done in a very fast way by the persistence and has less issues when it comes to concurrency. Updating the state snapshot from the state change events can be done according to the needs for actuality or performance. Just to make it clear: In this approach there is also just one entity that is updating the state, so more concurrency problems solved. Finally reading the state can be done in multiple ways. Either you read the provided snapshot or you update the snapshot to the newest value in your private copy of a state holder. This time again you are not changing something concurrent. > > A more real life example is one of our products. I changed to model to emit events 6 month ago. Well, using GemStone I didn't have to think about persistence. It is just a persisted collection with a few million events in it. 3 month _after_ I started to collect events I started to think about what data I actually need to show on the web UI. Having all the history in my hand I can derive plenty of different values just afterwards. Every value has a stream on the events collection. So every value has its own cursor in history. New values just start at the beginning of the collection and catch to now. Old ones have just little to update. > > I hope this is useful somehow, > > Norbert > > > >

Dec. 18, 2012

Re: [Pharo-users] Nautilius Method Source Pane Coloring

by StÃ©phane Ducasse

Good remark. We plan to have AST support for code editing and navigation in 3.0 so we could really change the metric and use a complexity metric. Counting the number of if statements Stef > Hi, > > The way Nautilus colors method source panes is absolutely great: if reminds you of paying attention to long methods in a gentle way. > > However, right now the metric is 'number of characters in method source', while it should be more related to complexity. > > For example, using long names for variables or messages will be counted as negative towards this metric. Worse even, lots of comments, which is good most of the time, also counts as negative. > > Number of nodes in the AST would be one solution, but maybe a too expensive one. > > Maybe quickly scanning for tokens while skipping whitespace and comments and then counting the tokens would be doable ? > > Sven > > -- > Sven Van Caekenberghe > http://stfx.eu > Smalltalk is the Red Pill > > > >

Dec. 18, 2012

Re: [Pharo-users] How are people doing TDD?

by StÃ©phane Ducasse

I do not know. I know that hernan wilkinson was using pahro for doing TDD. There was a package for TDD. Now we are ready to improve but we need people to submit code because we are busy. Stef > I am curious how people are doing TDD in Pharo? I just tried a session with > some of the guys at the UK Smalltalk meetup and I was finding it a bit > frustrating in the Pharo 1.4 image. > > I really like the new Toggle from Class to Test (cmd-j) option that got > introduced - someone has definitely been writing tests in Pharo - however it > does my head in that pressing it after editing a method doesn't jump me > back. I also find the same problem when editing a test - that pressing cmd-t > to run it, just puts a "t" in my source code and doesn't run the test. > > On a related theme - I also find it a bit awkward that I often have to click > in the source pane to get focus there to enter some code, I'm kind of > missing some easy keystroke to put focus there so I can just start typing in > a new method. in nautilus I think that you have tab. > > Am I missing some tricks here? Will the new 2.0 help with some of this (I > wanted to try it to see but the one click link is broken). I did try the CI > link - but I couldn't see where the 1-click job was running. As an aside - > there seem to be lots of red balls on Jenkins? > > Tim > > > > -- > View this message in context: http://forum.world.st/How-are-people-doing-TDD-tp4659726.html > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. >

Dec. 18, 2012

Re: [Pharo-users] Who's in charge of the Pharo Website - some corrections might help.

by StÃ©phane Ducasse

Tim I created to an issue: http://code.google.com/p/pharo/issues/detail?id=7138 Stef On Dec 18, 2012, at 2:59 AM, Tim Mackinnon wrote: > Guys - who's in charge of the Pharo website as there are some small > corrections that might help. > > It took me ages to realise that the Large font items on the left hand nav > are clickable (not sure if there is an easy way to indicate this?) - but > anyway I was looking for the Nabble link and I notice that the link to > Nabble in the FAQ page (http://www.pharo-project.org/documentation/faq) is > incorrect where'as the one on the Community page is correct. > > Also the Pharo-2.0 One Click link on > (http://www.pharo-project.org/pharo-download/beta-2-0) is broken. > > Tim > > > > -- > View this message in context: http://forum.world.st/Who-s-in-charge-of-the-Pharo-Website-some-corrections… > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. >

Dec. 18, 2012