Comments for Better Software Development

Comment on On LEGO Powered Time-Tracking; My Daily Column by Julien

Julien — Mon, 30 Aug 2010 07:57:58 +0000

I love the physical-digital mix that is the trend today. Nice idea. :-)
(even though it wouldn’t work for me, I love being only digital)

How about 2D codes on each lego piece, with color and size encoded?
Once they are fixed, your image is easier to decode, and less error-prone.

I’m aware that you can do without, but easyness and reliability are nice to have…

Comment on On LEGO Powered Time-Tracking; My Daily Column by Lego is tops

Lego is tops — Tue, 24 Aug 2010 02:41:05 +0000

Time to get your Lego shares!!

Comment on On LEGO Powered Time-Tracking; My Daily Column by links for 2010-08-23 « AB's reflections

links for 2010-08-23 « AB's reflections — Mon, 23 Aug 2010 20:03:50 +0000

[...] On LEGO Powered Time-Tracking; My Daily Column | Better Software Development Interesting way to track your time using lego bricks to make graphs. Who says you need software to do this… (tags: lego time management selfhelp) [...]

Comment on On LEGO Powered Time-Tracking; My Daily Column by Daily Stack – Design zur Organisation | SHOUTing GORIlla

Daily Stack – Design zur Organisation | SHOUTing GORIlla — Sun, 13 Jun 2010 23:34:52 +0000

[...] Da man es leider noch nicht kaufen kann, kann man sich hier umschauen, wo Michael Hunger lärt, wie er ein ähnliches System mit Lego für sich gebaut [...]

Comment on On LEGO Powered Time-Tracking; My Daily Column by On LEGO Powered Time-Tracking; My Daily Column « Justin Joshua

On LEGO Powered Time-Tracking; My Daily Column « Justin Joshua — Sat, 22 May 2010 17:01:46 +0000

[...] On LEGO Powered Time-Tracking; My Daily Column LEGO Powered Time-Tracking [...]

Comment on About by Michael Hunger

Michael Hunger — Sat, 10 Apr 2010 10:32:09 +0000

Sure go for it, thanks for mentioning it there.

I’d be interested in the feeback you get from your teachers.

Comment on About by Kristie Brown

Kristie Brown — Fri, 09 Apr 2010 14:25:48 +0000

Do you mind if we post your time management with LEGO to our LEGO Smart blog for teachers?
Thanks

Comment on Keynote at 4developers: The Game Of Life – Java‘s Siblings and Heirs are populating the Ecosystem by Peter Horsten

Peter Horsten — Wed, 07 Apr 2010 19:55:04 +0000

Hi Michael, great to read I could give you some nice insights. Meeting you was a pleasure as well. Besides I believe you gave more good answers than just the IDE one :)

Comment on On LEGO Powered Time-Tracking; My Daily Column by Andre

Andre — Tue, 16 Mar 2010 10:13:36 +0000

Hi,

very nice Idea… If you’d like to try a Time Tracking Software, look here: Log My Time

Andre

Comment on 97TESPK: Scoping Methods by Jens Nerche

Jens Nerche — Wed, 10 Mar 2010 14:21:59 +0000

Hi Michael,
it seems your discussion misses some details. Let me play devils advocate and to formulate some protest notes:

Scoping Methods lead to anemic domain models. Because one logical class is spread over some physical classes, each containing some methods, there is no hidden information with public operations on it anymore just like in service-dto-dao-architectures. The former private methods, which operate on the class data, now need dto’s for input and output, no real internal hidden state anymore.

Not only the data isn’t protected anymore, there is also no private method anymore. Things may become visible to far more objects than they should, and it unsafer to change things.

In the same namespace are now far more classes than before, which leads to fat namespaces (packages). And because the lack of any naming convention its not obvious which code belongs together. Before scoping the cohesive code was in one class, now its spread over all the namespace.

The code is now much less readable, now you have to switch between files instead of having it on one screen or scroll some pages up and down. There is also much more syntactic sugar to write and read.

“Transit dependencies” are common: that are dependencies that are injected in the original class – not for the own use, but only to pass them to the newly created method objects (which in turn may pass them only to their method objects and so on…)

There is no real point for having method objects – static utility methods could also do the job. They could be imported statically and are in the original class as readable as private methods. And its a heaven for utility methods collection classes. We could also define abstraction levels 1-10 and have a utility method class per abstraction level just as we could have a database table per data type and spread the entity over them ;-> Well, not really….

Perhaps the object oriented paradigm is the wrong one for the abstraction hierarchies you are seeking for. In the described form Scoping Methods is more one of the “97 Bad Ideas Every Programmer Should Know”.

Don’t get me wrong, I’m not trying to bash you or so, I’m just playing the devil to point out some antitheses.

live long and prosper
jens