thought-tracker

API Design & Closures

2010-03-15T12:59:00.004+01:00

In a recent design discussion, I've noticed that the preferred java-ish approach is rather verbose.

Suppose we want to create an expression tree and evaluated-it:

solution1:
ExpressionTreeBuilder b = new ExpressionTreeBuilder();
b.newExprY(a,b);
b.newExprX(c,d);
....
ExpressionTree t = b.toTree();
interpreter.eval(t);

I find this solution rather difficult for 'beginners', the people who see the API for the 1st time. As a 1st time user of the API, I discover the interpreter as a service, and I start searching for the ExpressionTree to give it to the interpreter. I find the class, but it is immutable. I finally, redirect myself to the ExpressionTreeBuilder and I realize how can I use all the parts properly. IMO the above approach has a detective-trying-to-solve-a-puzzle feeling, exposing too much of the implementation mechanism.

A much cleaner solution would be:
interpreter.eval { |b|
b.newExprX()
b.newExprY()
}

This solution has a single point of entry and the user is directed to the correct API usage. The intermediate build/transform steps are hidden. It reminds me of scala loan pattern, or ruby html builder.

Java language EOL

2010-02-16T09:41:00.002+01:00

via InfoQ, link to the original ThoughtWorks paper:

The authors mention the fact that Java has been slow in adopting new features lately, the initiative being taken by other languages built on JVM, “languages such as Groovy, JRuby, Scala and Clojure.” They expect enterprises to “begin to assess the suitability of reducing the amount of Java-specific code developed in their enterprise applications in favor of these newer languages.” Because of that, the authors suggest assessing the end of Java as a programming language.

This boils down to closures. If you start a new project, you could start with a project which allows you to do much more then just java. Related presentation: Language Parity: Closures & JVM.

Lambda, Linq, Dynamic Proxies

2009-08-17T11:08:00.008+02:00

In the current project I've introduced some closure/function definitions: functions, actions. The usual stuff. (for reference look at the Scala API, or the google collections, or the Linq Func, or the functional java).

One problem with the current state of closures in java is that, even though objects are closures, and they can be realized with anonymous classes (that's how scala compiler does it), we still have an interface impedance: my function definitions (interfaces) don't match google one's which don't match scala's, which don't match functional javas. So we'll have to write adapters (scala reduces the adapter overhead).
The other problem is that writing closures with anon-classes is a pain: probably that's why Doug Lea is looking into scala. In my project's context we basically/mostly have operations on collections, a sort of
google collections dsl. The only 'ugly' part is the function definition: how the predicates/transformers are defined.

It remindes me of Scala Query & Formal Language Processing in Scala.

I thought of the idea of creating proxies in order to define a function: e.g.
Funcs.on(A.class).getB().create() will create a proxy, will record the method call, and will create a function, which could be called on A objects. I didn't implement that because it seemed such an overkill to create a proxy in order to have a closure.
But now I see that it has been implemented in lambdaj (query collections), and for jpa in liquidform.

What I've missed is that through dynamic proxies we might provide enough information to build queries a la LINQ. (i.e. the information which the c#/vb.net compiler provides on parsing the query,
could be built, manually, by means of dynamic proxies, in java).
---
Update: Looking at Linq/query for java frameworks:
- one does byte code analysis in order to generate the query expression
- one does dynamic proxy
- one uses APT to generate query expressions from entities (something which people wished for jpa 2.0)

Overall I fear/see that the syntax used to build a query-expression-tree might get rather clunky. Maybe in this area Scala could shine.

Rx Framework

2009-08-05T15:15:00.003+02:00

A new addition to the .Net platform, the Rx framework, aka 'reactive programming', aka 'linq to events'.

Here is the lang.net presentation, the theoretical discussion/explanation/proof about the relation between the Iterator & Observer pattern, and another very good explanation.

The .Net approach is very elegant and reminded me of Glazed Lists and of F# Reactive Programming.

Other thought associations were to F# async workflows, and ruby gui frameworks: bowline based on Titanium, and MonkeyBars based on swing.

Enjoy!

Variations on the visitor pattern

2009-08-04T10:11:00.007+02:00

In the current project I've written so far at least 20 class hierarchies (+ their visitors) representing ADTs.

The common scenario is that we have some data which is created by one module and consumed by others. Since the data is shared by 2+ modules, most operations on it require several services from several modules.
So we're out of luck with the Interpreter Pattern, we use the Visitor Pattern/Double Dispatch:

abstract class Expression {
....static class Number extends Expression {
........public final int n;
........Number(int n) { this.n = n; }
....}
....static class Plus extends Expression {
........// since the data is immutable, there makes no sense to create getters
........public final Expression left;
........ public final Expression right;
........Plus(left, right) { this.left = left; this.right = right; }
....}

....// toString, equals, hashCode are implemented with apache commons-lang, based on reflection up to the Expression class
....}

The classic Visitor pattern says:

interface Visitor {
....void visit(Number n);
....void visit(Plus plus);
}

and

abstract void Expression#accept(Visitor v);
....void Number#accept(Visitor v) { v.visit(this); }
....void Plus#accept(Visitor v) { v.visit(this); }
// noticed the copy-paste !? (imagine doing that 40+ times...)

In this example the visitor is a stateful closure which encapsulates a computation its initial data and its final (accumulated) result.

The problem which might arise is how do we handle adding more data type (i.e. classes) to our hierarchy. See the Expression Problem, Extensible Visitor/book (more on google ;).
The proposed solution is to drill a hole in the type safety, in order to make old code compatible with new code:

interface Visitor {
....void visit(Number n);
....void visit(Plus plus);
....void otherwise(Expression x);
}

Now we want to make the visitor stateless, maybe some visitors could be injectable services, eg: ExpressionPrinter, ExpressionEvaluator etc. In this scenario we want to extract the initial data & the result from the visitor:

interface Visitor[A,R] {
....R visit(Number n, A args);
....R visit(Plus plus, A args);
....R otherwise(Expression x, A args);
}

we also need to change the signature of the Expression#accept

abstract [A,R] R Expression#accept(Visitor v, A args);
....[A,R] R Number#accept(Visitor v, A args) { v.visit(this, args); }
....[A,R] R Plus#accept(Visitor v, A args) { v.visit(this, args); }
// noticed the copy-paste !? (imagine doing that 40+ times...)

In this scenarion we can pass the initial data as args , the Expression will pass that to the visitor, which computes the final result R.

Another variation is when the visitor returns an element of the type which he visited. For that we need to modify the Expression:

interface Expression {
....E accept(Visitor v, A args);
....static class Number implements Expression { ... }
}

In this case we might use the A args in order to accumulate other results than the specified E type (we use the A as an accumulator).

If we want to really keep things clean and separate input from output, we could return on accept a tuple[R, E], but that's not needed in 90% of the cases.

Compare that with pattern matching on case-classes:
* no need for toString, equals, hashCode since they are generated by the compiler
* no need for visitors due to pattern matching
** no issues with statefull visitors
* no need for manual written ctors since they are written by the compiler,
* we get cca 50% less code to maintain.

Now scale that to 20+ class hierarchies...

Why Scala

2009-07-20T11:01:00.009+02:00

I wanted to write a post 'Why Scala is such a nice/great language', but after I've seen the Martin Odersky presentations at google, and at FOSDEM 2009, Bonas Joner at QCon 2009 'Pragmatic Real-World Scala)', Evan Weaver with 'Improving Running Components at Twitter' and the James Strachan's (of groovy fame) post, an impressive collection of learning Scala resources, I had the impression that there is nothing more to be said (that hasn't be said before).

There is even an online and offline ScalaTour.

Nevertheless, we could/should mention

Java-Basics:

* seamless java integration
* IDE support, build support (maven, ant, sbt, buildr)
* java code coverage

OO-Basics:
* objects all-way-down (see ScalaOverview) (the Smalltalk way)
** primitives are efficiently wrapped & handled by the compiler
* closures/functions are objects too
* multiple trait inheritance (e.g. utility-belt, logging, ...)

Fun-Stuff:
* extensible pattern matching (i.e. switch on steroids on objects)
* functional idioms allowed
* type inference (Hindley-Milner)
* reified generics
* type classes
* elegant solution to the Expression Problem

Moved Code Snippets to Mercurial

2009-07-13T14:03:00.004+02:00

I've just moved the tip of the svn trunk to mercurial.
In order to make a push without a password you'll need to modify the .hgrc (specify your google code username, password :

[paths]
thought-tracker = https://username:password@thought-tracker.googlecode.com/hg/

In order to get it:
hg clone https://thought-tracker.googlecode.com/hg local_folder

In order to push/publish it (after a local hg ci -Am"some msg"):
hg push thought-tracker

DVCS(hg) vs SVN workflows

2009-07-09T09:35:00.003+02:00

Suppose we work in an international company, remote sites, not so good connection between those sites.
We have the following scenarios:

1. We have to do a rather big refactoring, which will take several weeks.
- With svn: we create a 'feature branch' where we'll do the refactoring. We update daily from trunk, we push to trunk regularly/at the end. The feature branch is allowed to be CI-red. (Due to an svn issue merging back-and-forth became a problem for svn-merge-tracking, and we had to do a tree-diff on 2 local sandboxes)
- With hg: you just create a clone-branch, you work on it, you can merge with<->from trunk regularly,
whithout any merging problems.
- Guerilla tactics: shadow the svn trunk/branch with some hg repositories and to the merges with hg (no tree-diff), at the end push the changes to svn

2. Junior (remote) developer needs help fixing a unit-test.
- With svn: do a branch, svn switch to it, push the code with the broken tests, fix them, merge back to trunk.
- With webex: do a remote session an explain the fix
- With hg: just pull the changes, make a fix, push them back to the remote developer. (hint: hg is more network-friendly then svn)

3. An interface between 2 components is changed radically. Both the user & the implementation must be changed.
- With svn: do a branch, do all the changes, merge to trunk
- With hg: change the interface in a cloned repository, then share this repository between the user & implementer. They can work in parallel, the last one finishing pulls the changes from the other one and does the integration.

4. Junior developer, friday@17.00, before a 3 week holiday, wants to commit his _weekly_ changes. He cannot create a local ci build within 1 hour so he doesn't commit anything.
- He shouldn't integrate friday@17.00. (but he did)
- With svn: create a branch, svn switch, push your changes to the server
- With hg: a colleague could pull the changes an do the integration + push the changes, without the need to go through the server.

5. Always keep the code green.
- With svn: run the CI on the pre-commit hook (TeamCity does it). The code get's in the repository only if the build is green
- With hg: maintain 2 repositories: in the 1st one we push the changes, which are peeked by the CI, validate, and on success pushed to another repository. (or just do a rollback; much easier with hg)

A lot of the hg power comes from the fact that is changeset-based (unlike svn) and merges are really easy. Another big plus point goes to the distributed nature of hg: it enables more flexible workflows; in a centralized vcs all the communication is done through the server.

links: hg, git

15 Min. Null

2009-05-07T15:13:00.000+02:00

15 Minutes Null

View more presentations from andrei.pamula.

15 Min. IoC

2009-05-04T10:15:00.002+02:00

From my series, '15 minutes Lessons Learned', a short introduction to Inversion of Control

15 Min IoC

View more presentations from andrei.pamula.

Programming Abstractions

2009-02-23T13:35:00.002+01:00

Great post by Brian Hurt: Programming Doesn't Suck! Or At Least It Shouldn't.

Abstraction helps up the percentage of interesting code vr.s boring grunt work code, by minimizing the amount of boring grunt work code. If you can turn five lines of code, replicated ten thousand times, into one line of code, replicated ten thousand times, you’ve just turned a 50 KLOC project into a 10KLOC project, doable at least 5 times faster (and probably more like 25 times faster). Get the crap work out of the way fast, so you can get on to the more interesting stuff.

I’m not even talking about leaving your language of choice, I’m talking about thinking outside the box, or even just thinking. But learning new languages is an advantage in making programming not suck, because if nothing else, it gives you new tools for your tool box, new ways to consider abstracting the code. And some languages are better than others, and the more you know, the more likely you are to know a good one. And if you don’t know the better language, you can’t use it.
My initial response to the DailyWTF post was that it was another classic example of the starving child in Africa syndrome. You’ve seen the pictures. A child in some hell-hole of a third world, generally Africa but parts of Asia and South America qualify as well. The child is hungry, maybe starving, disease ridden, bug infested, and destined for a life that was nasty, brutish, and short. But they’re smiling away, happy as can be, simply because they don’t know any better. Everyone they’ve ever known, seen, or even heard of has been in exactly the same boat they are. That’s just what life is like. I often times think that many programmers are just like that staving child. They put up with, indeed don’t even see anything wrong with, having to write half a dozen lines of code just to set some UI properties, because they’ve never known any better. Bug ridden, virus invested, bloated, slow, impossible to maintain, that’s just what programming is.

The second post is convincing me that the situation is much, much worse than that. That it’s not just ignorance is the problem. It’s not just that many programmers don’t know any better, it’s that many programmers don’t want to know any better, and are looking for an excuse, any excuse, to stay ignorant. It’s as if that starving child doesn’t want food, and would reject food if offered.

The reason that post is causing to me think this is because I’ve heard this argument before. All of them. See, I lived through the last great paradigm shift, when the industry moved from Procedural to Object Oriented- and heard the dying remnants of the one before that, from unstructured to procedural programming. I’ve heard all these arguments, or should I say excuses, before- from people trying to avoid learning C++ and Java.

Slightly related: Erik Meijer @ JAOO2008: 'Why Functional Programming (Still) Matters'

Failure, take two

2009-02-06T09:34:00.002+01:00

Regarding the Agile/Scrum failure, it has been a lot of buzz in the community:

James Shore - The Decline and Fall of Agile
Martin Fowler - Flaccid Scrum
Ron Jeffries - Context My Foot

Want to succeed at software? Then it can’t be business as usual.

pet project idea

2009-01-28T09:33:00.002+01:00

Implement a 'bean-mapper' a la Dozer, but instead of using the xml files, use dynamic proxies, a la LiquidForm.

Failure

2009-01-27T11:44:00.003+01:00

Failure

"The only failure is the failure to learn from failure" -- Kevin Everett FitzMaurice

A friend of mine notice that in a big company, which recently decided to embrace agile and use Scrum, the Scrum practices are applied in a mechanical way. Actually he called it a 'theater', and he said that the 'agile principles' are important. A colleague had a similar observation, that Scrum is applied in an american-indian-ceremony kind-of way, expecting that the results will fall out of the sky.

Maybe this is related to the 'Shu Ha Ri' training cycle, which:

TheThreeExtremos lately seem to be recommending a ShuHaRi approach to XP: First, follow all the practices. Then, realize TheyreJustRules, and change them (i.e. break some of the original rules). Finally, you don't need to think about the rules anymore. -- GeorgePaci

But in day-to-day business, it is just sloppiness. People don't understand that they are on a learning journey, they don't understand why are they following the practices/rules. Some don't want to learn, they just one to get the job done and go home. Many people are just happy with Ship-It. We've done, it, we are happy, let's go home. No retrospection, no how-can-we-do-it-better-next-time, no 5-whys. There is no striving towards elegance, to do things better. No passion, no motivation. Probably that's why retrospective are the first to be dropped/disregarded.

Does this mean that Agile/(Scrum?) is a culture-thing? How can we change a 'not-my-problem' culture? How can we stop sinking in a pool of problems? How can we start carrying?

ps. via rangawald's delicious, I found Taming Perfectionism.

The Membrane

2009-01-16T13:12:00.002+01:00

Suppose we have 4 coupled/chained objects: A, B, C, D, accessible through the properties A.B.C.D, and the objects have the following properties:

A: B, A1, A2
B: C, B1, B2, B3
C: D, C1, C2
D: D1, D2, D3

Usually within a certain area/component, we don't need all that object tree, but just a projection/subset of it: eg. IView { A1, B1, C1, D1. }
In practice, the problem is that most of the people will use/scatter these properties all over their code, leading to maintenance monsters:
- navigation is all over the place, violating the 'Law of Demeter'.
- Testing is getting a lot more difficult: in order to test a user of IView you need to instatiate A, B, C, D, these might have good constructors which force you to instatiate other X objects, etc.
- The amount of code using chained objects/train wrecks will crush future refactorings: if you'll want to reverse the navigation from B.C to C.B, you'll have to change all the usage points, the same goes for changing a data type.

Possible solutions:
a. Define the projection as required by that component/use case, eg IView { A1, B1, C1, D1 } (properties, or getter/setter, etc.)
- Define a repository service IRepository.get(...) -> IView
- Work against your abstraction IRepository/IView

The IView/IRepository could build through:
- DTOs mapping (a la dozer & co.)
- wrap & lazy fetch:
View {
ctor(A a) { _a = a; }
A1 { _a.A1 }
B1 { _a.B.B1}
C1 { _a.B.C.C1 }
D1 { _a.B.C.D1 }
}
(a pretty slick solution might be build with LINQ expressions)
In this way we have isolated our component from external changes, we are depending only on our IRepository/IView, future refactorings will afect only that area.
The IRepository/IView abstractions represent the membrane to the external world. (Ralf refers to the pattern as 'external adapter', probably refering to Alistair Cockburn's 'Hexagonal Architecture' paper, I prefer the Alan Kay's metaphor).

b. Instead of defining the projection IView we could add the required operations on A. This has the benefit of aggregating/reusing common operations on A (usually a root entity).
In some cases it might lead to the polution of A: all the properties/operations beneath the A will emerge into A, transforming the tree into a list. Class A will become too big, containing its data, and n+ operations (C# has region-folding, smalltalk has protocols for organizing big classes)

Final thoughts:
- it is not about DDD/Tell don't Ask vs EJB/DTOs vs XXX, but is about isolation/visibility.
- (Unit) Testing asap helps a lot identifying architecture/design smells.

toString or not toString

2009-01-09T10:04:00.002+01:00

suppose we have an Id class, which used as a 'pointer' to some persistent entities.

abstract class Id {
T _raw;
Id(T raw) { _raw = raw; }
@Overrride void toString() { return _raw.toString(); }
}

And the Object#toString() documentation says:
/**
* Returns a string representation of the object. In general, the
* #toString method returns a string that
* "textually represents" this object. The result should
* be a concise but informative representation that is easy for a
* person to read.
* It is recommended that all subclasses override this method.
*
* The #toString method for class Object
* returns a string consisting of the name of the class of which the
* object is an instance, the at-sign character `@', and
* the unsigned hexadecimal representation of the hash code of the
* object. In other words, this method returns a string equal to the
* value of:
* getClass().getName() + '@' + Integer.toHexString(hashCode())
**/

What is the problem?

* we heavily use these Ids in a *lot* of places
* id.toString() is used both for Id -> String conversion, as a part of our design and as textual representation for debugging/logging
* to subclasses AID and BID will have the same textual representation, making future debugging/logging more confusing then necessary
* if we enrich the Id with more data (eg. a timestamp, or entity version, etc.) we can no longer not add this extra data to its textual representation (eg. logging), since toString() is also used for conversion
** it is very hard to find all the usages of the toString method, since every IDE (and the compiler too) considers this method belonging to the Object and not to the abstraction Id (that's why the @Override is there)
*** if we would have worked in a TDD kind-of way, we probably would have started with an interface, IUniqueId, to which we probably would have added a method asString()

concluding advice: when you model your own domain language/design, be careful what you override.

Pragmatic Compromise

2008-11-27T12:48:00.002+01:00

Have you noticed that all the guys who are advocating a compromise code quality vs. speed,
are not the guys who are going to maintain that code? Have you noticed that these guys bully you into delivering features fast, and later they come complaining ' Why is the quality so poor? '.
Even if quality is not seen as corporate asset, make it a part of your professional ethics.

DynamicQuery

2008-11-11T09:55:00.004+01:00

Has anybody tried to do an EJB DynamicQuery implementation a la groovy, using a DynamicProxy ?
(post inspired by AutoBoundary proxymatic)
Apparently yes: check-out the LiquidForm.
There are some other alternatives, but java is not there yet.

Scrum Log

2008-11-10T09:50:00.002+01:00

After reading/watching an impressive amount of presentations from Henrik Kniberg: parleys, slides, technical-debt, bootstraping scrum and xp in a crisis, scrum checklist, and more, I've decided to keep a personal iteration log.
It's amazing how much clarity you get at the end of an iteration: the retrospective.

Dark Syntax Highlight

2008-11-03T10:45:00.001+01:00

(in RGB)
Brackets: 128,255,0
Keywords: 217,167,15
Comments: 0,185,0
Tasks,ToDos: 0,255,0

API Usability

2008-10-23T15:01:00.003+02:00

The success of an API/component largely depends on its usability: is it easy to create, is it easy to handle, is it easy to wire? Is it easy to make a mistake? Are some contracts unclear ?

The first feedback we get from (unit-)tests. Unfortunately a lot of people don't do that.
Another point is that the tests (partially) lie about how the component is used: they represent how the author assumes the component will be used. Feedback from customers and refactorings should follow...

Filter support for PropertyConfigurator

2008-10-22T16:41:00.002+02:00

The PropertyConfigurator class in log4j does not support filters and few other advanced configuration options. There was a need to add logging filters to a legacy Java app, but modifying the application code to use DomConfigurator was out question. The alternate approach was to directly add filter support to the PropertyConfigurator class in log4j.

Filters are chained to an appender in a specified order. However, the runtime representation of a .properties files is basically a hashtable, and there is no ordering defined on the keys of a plain hashmap. Any implicit ordering of the lines in the properties file is lost when it is parsed. To overcome this, filters are identified by unique IDs, and filters are added to the appender in the lexicographic order of the IDs.

Keeping the notations used by the log4j source code, filters are configured as follows:

log4j.appender.appenderName.filter.ID=fully.qualified.name.of.filter.class
log4j.appender.appenderName.filter.ID.option1=value1
...
log4j.appender.appenderName.filter.ID.optionN=valueN

You can download the patch directly from the log4j bug tracker. It can be applied to the current HEAD of the 1.2 branch, more exactly to 1.2.15.

Coder

2008-10-10T09:52:00.001+02:00

Written code is a cost, since it has to be maintained. Less code, less maintenance.
Maybe we should call developers 'anti-coders'.

Option/Maybe monad is a generic NullObject

2008-08-19T12:45:00.003+02:00

I've just reviewed the NullObject and Visitor post. It is so similar with the Option/Maybe monad.
ps. Thought's on Validation: Scala/liftweb has an nice Can.

Scala Marketing Challenge

2008-08-11T18:33:00.006+02:00

Josh Suereth would like to improve the Scala's marketing strategy.
This is a tough sell. If we look at the Change Function:

ChangeFunction = F(PerceivedCrisis/PerceivedPainOfAdoption).

(btw. read Erik Meijer's paper: 'Confessions of a Used Programming Language Salesman', it's really, really good.)

So we'll have to ask ourselves what problem is Scala trying to solve, and how much it'll cost. IMHO, Scala is trying to make programming easier. It partially addresses the concurrency problem, but it is not its main-focus, I would say is the ScalaActors are a good side-effect of Scala's good (language + library) design.

What we'll have to pay in order to make the 'switch': the syntax is slightly different. Functions are 1st level citizens. (but functions/closure are scary). Operator overload is also scary (funny enough, method overload is not scary: we are afraid of symbols but we are not afraid of words). Then we have for a good generic support we have 'Generics of a Higher Type', type covariance/contra-variance. Pretty scary... booh! Did I say that IDE support is not yet at java's level?

On the other side we have a huge number of java developers. They are satisfied. Not really happy, not really sad. Ok, java is not that great, but it has been like this for years, why change? To be more effective? Probably to sell that to a manager you'll need 5 independent studies to show that scala is better then java and you'll need at least one big company to push the language. ('if they use it, we could use it too')

Regarding concurrency: a lot of java developers have problems to right correct code, so probably concurrency is the least of their problems. Other developers we'll say 'we have java.util.concurrency'.
If you look at the package you'll see they offer concurrency primitives, and to write shared-state concurrent programs is very hard. You'll have to think a lot more about object isolation and the threading context.

In conclusion:
- UserPerceivedCrisis: small
- PerceivePainOfAdoption: big
ChangeFunction -tends-to-> small.

sorry, scala...

Poka-yoke API Design

2008-08-08T19:43:00.004+02:00

API Design should be Poka-yoke.
And if we look what zen aesthetic means to people, a good design is zen: clean, simple, minimalistic.

hg vs git, pull+merge vs rebase

2008-07-31T23:39:00.001+02:00

@pastebin

GIT encourages rebasing, which leads to rebasing of your public and other people's
code. This is bad.

Mercurial, which hashes a changeset's place in history as well as it's
content, discourages rebasing. Rebasing happens in private with mq patch queues.
Public trees are merged. This is good.

Either style is possible with both tools. The difference is the default emphasis.

Defaults matter.

Linus Torvalds on rebasing:

* http://kerneltrap.org/Linux/Git_Management
* http://lwn.net/Articles/291302/
* http://lwn.net/Articles/291303/
* http://lwn.net/Articles/291304/

Matt Mackall on synchronizing (pull + merge, don't push, don't rebase):

* http://www.selenic.com/pipermail/mercurial/2008-July/020116.html
* http://www.selenic.com/pipermail/mercurial/2008-July/020131.html

Scala Roman Numbers

2008-07-30T13:20:00.001+02:00

kata

Scala Exercises

2008-07-24T16:36:00.002+02:00

I have completed Tonny Morris Scala exercises. (maybe I'll put them on the svn as well, or maybe mercurial ?)...
Anyway some observations:
- it felt like doing the 'Little Schemer' in Scala.
- after doing 3-4 exercises, you feel the need to use/implement fold_left/fold_right.
- maximum is buggy: what's the maximum on an empty list? (the maximum found must be contained in the list;reasoning related to 'Noumenal Null'). I believe that this exercise is a 'tricky question' and instead of throwing an exception, or returning Nothing or Int.NaN, probably the signature should be changed to : maximum(x: List[Int]) : Option[Int]

- In the List's implementation of map/filter/... they use instead of pattern matching if x.isEmpty ... else ( do_something(x.head, x.tail). Probably it's faster than pattern decomposition.

Lack of Fit

2008-06-12T20:22:00.002+02:00

Over the J. Paul Morrison's article I found the following quotation:

In the early part of his book "Notes on the Synthesis of Form", Alexander describes the concept of "fit". He makes the point that, as humans, we find it very hard to detect "fit", but are well-adapted to detecting "lack of fit". Think of trying to decide if the edge of a piece of wood is straight: the natural thing to do is to put it against a straight surface and see if any gaps show in between. As we try to improve things by reducing the misfit factors, we soon discover that these factors tend to be interrelated: fixing one may exacerbate another, so there is a continuous process of compromise between a number of less than ideal solutions. Intuitively, the less interrelated the misfit items are, the easier it will be to reach a state of acceptable fit. This means that our only hope of reducing misfit factors is if these factors occur in clusters such that the connections between clusters are relatively loose. In application development, this works best if the infrastructure software components also define boundaries between misfit factors.

maybe that's why I'm so critical....
btw. I've started reading J. Paul Morrison's book. I like it, I recommend it.

LanguageFear

2008-05-22T19:34:00.005+02:00

I've just read Martin Fowler's article ParserFear. So, Why Not a Parser for a DSL?
Martin didn't quite specified why we need a DSL:
- Is it for business people to specify their requirements?
- Is it just 'readable' code, for programmers ?
I assume that in both cases we are trying to solve a customer's problem, by building an easy to maintain.

Let's say we use XML. Well that is a bad idea, and Martin knows it: XML is not the answer. It is not even the question. And to write XML is a difficult thing to sell, to a business-man.

Let's say that we go the ANTLR way. Which means from all the languages which are out there, none fits our needs, so we have to build our own. Ok, let's say we've build one. But now we need for our users an editor. We might need good error messages, syntax highlight, the possibility to reuse blocks of code from our programming language. Later we will need to extend our language, without hurting the users. And on the other side, the code generated will be difficult to maintain or to build abstractions on it. That's because code generation is just a raw, automatic, copy-paste machine: it doesn't build any higher-order abstractions. And the direction seems to be wrong: instead of helping our customer, we are baby-sitting our language/editor/infrastructure.

Or we go with embedded DSLs: some languages are better then others. And some languages can be easily integrated with others. Some have heavier syntax making more difficult to create a clean DSL, some are more lightweight, making a perfect match for DSLs.

Or we can go with a 'building material', a 'programmable programming language', or something similar.

Why do people fear of learning of a new language, but they invest uncountable hours in building sand-castles. Even Martin agrees: be a polyglot.

Validation Combinators, a F# prototype

2008-05-02T17:30:00.001+02:00

Suppose we have the following situation: we have a bag/set of named objects which have to be validated. These objects are primitives, let's say strings, for our sample.
Some strings can be validated as 'standalone' some need to be validate against each other. This validation doesn't belong to the domain for several reasons.
Regrettably, the existing frameworks don't suite our needs.

Trying to decompose the problem, we need:
- a way to get object out of the bag, by name
- a validation method/function which can validate one or more objects
- if the validation fails, we want to collect a 'failed validation message'
- we want to compose these validations: and, or, not, xor, etc...

Let's put that in code:

#light
open System
open System.Collections.Generic
open System.Text

type get_by_name = String -> String
type accumulate_message = String -> unit
type validator = get_by_name -> accumulate_message -> bool

We use F# light syntax, and open some .Net namespaces, define the required function types: I really like this kind of 'aliasing': give name to a type, since being based on type inference, is not obtrusive.It is not like a java/c# Interface, where the interface must be implemented. In our case, if we have another function with a signature matching our type, we can use that function as the required type. (we could say is a type-safe duck-typing)

let _and_ (x : validator) (y : validator) = (fun (get_value_from_bag : get_by_name) (accumulate_validation_message : accumulate_message) -> 
      let ok_x = lazy x get_value_from_bag accumulate_validation_message
      let ok_y = lazy y get_value_from_bag accumulate_validation_message
      Lazy.force ok_x && Lazy.force ok_y)

let _or_ (x : validator) (y : validator) = (fun (get_value_from_bag : get_by_name) (accumulate_validation_message : accumulate_message) -> 
      let ok_x = lazy x get_value_from_bag accumulate_validation_message
      let ok_y = lazy y get_value_from_bag accumulate_validation_message
      Lazy.force ok_x || Lazy.force ok_y)

let _not_ (x : validator) = (fun (get_value_from_bag : get_by_name) (accumulate_validation_message : accumulate_message) -> 
      let ok_x = x get_value_from_bag accumulate_validation_message
      not ok_x)

let _xor_ (x : validator) (y : validator) = ((_not_ x) |> _and_ y ) |> _or_ (y |> _and_ (_not_ x) ) 

Having defined what a validator is, we have defined functions to combined them: and, or, xor. In order to simulate the behavior (a and b -> b is evaluated only if a is false), we cache the result of a validator in
a lazy value: the value is computed only once, delayed, on demand. In the xor combinator we have used another DSL-friendly feature: partial-function application: ie. if we have a function f(x, y) -> z we could write this as: y |> f x.

Ok, let's see how it works. We define a validator:

let is_starting_with (start : String) (name : String) = (fun (get_value_from_bag : get_by_name) (accumulate_validation_message : accumulate_message) ->
   let value = get_value_from_bag name
   let ok = value.StartsWith(start)
   if not ok then 
       let msg = string.Format("{0} '{1}' doesn't start with {2}", name, value, start)
       accumulate_validation_message msg
   ok)

Lets define a map of name -> values, and a message accumulator:

let map = new Dictionary()
map.Add("customer","ali")
map.Add("buyer", "baba")
map.Add("vendor", "nono")

let get_value (key : String) : String = map.Item(key)

let acc = new StringBuilder()
let accumulate (msg: String) : unit = acc.AppendLine(msg) |> ignore

Lets create a more complex validator:

   46 let x = ("customer" |> is_starting_with "a") |> _and_ ("buyer" |> is_starting_with  "b") |> _and_ ("vendor" |> is_starting_with "v")

That's really readable, isn't it?

And we can evaluate it:

printfn "evaluation: %b messages: %s" (x get_value accumulate) (acc.ToString())

System.Console.ReadKey()

ps. Look at a better example in a Good Video: "Composing Contracts: An Adventure in Financial Engineering".
pps. here is the code.

they've killed it

2008-04-18T11:34:00.002+02:00

dilbert.py and dilbert.fsx. they...
:(

Maybe, me too

2008-04-10T13:02:00.002+02:00

After my previous post, I've found another one blogging about Option as 'explicit null'.
If you think about, Java/C# always had that Option, is only called Iterable[T]/IEnumerable[T]: either you have one element inside or not.

So I've done another implementation in java. In comparison with the 'other' implementation:
- instead of the slower 'instanceof' matching, we use a boolean hasValue()
- almost as in F#, the Option implements the Iterable interface, allowing the filter/map/reduce operations. (in F# those operations are directly in the Option type)

ps. A lot of people like the 'scala Option' or the 'F# Option'.
pps. My favorite 'What is a Monad?' explanations are the Brian Beckman - "Don't fear the Monads" video, and the Wes Dyer "The Marvels of Monads" blog-entry. Here the other links.

Thoughts on Validation Patterns

2008-03-31T13:37:00.002+02:00

During my worked at project X, I've looked for several validation patterns.

The use case is: you have a view with several fields, you need to validate them all, collect all the error messages and focus on the 1st erroneous file.

Since the View represents of a view (projection) over the Domain (Model) the right thing to do is to put the validation in the Model.

The problem arises from the fact the in an ActiveController-PassiveView (aka Model-View-Presenter)
neither the Model nor the View have access to each other:

PassiveView <-- Presenter --> Model.

The latest frameworks use annotations/validators & reflection to map validations ViewField <->
ModelField. (it gets hairier if you need to validate accross several fields, or several objects).

Project X was a .Net project, and .Net 2.0 has a nice feature: implicit type inference for delegates.
Let me explain: if you define an delegate
public delegate R Func<R, A1>(A1 arg1);

and a method
void DoSomething<R,A1>(Func<R,A1> converter) {
... }

then you can pass *any* method which matches the signature of the delegate to the
DoSomething(...) method.

public R MyConverter<R,A1>(A1 arg);
...
DoSomething(MyConverter) // this is valid
Basically, starting with .Net 2.0, closures/functions are 1st class citizens in C#, like any other 'normal' objects. (closures are objects, afterall), with some remarks:

- .Net/C# properties are not methods and cannot be used as such
- in java you have to write a *lot* of anonymous classes, making more difficult to see any benefit. (that's also why an Enumerating component is not appealing in java, in C# the compiler writes the anon. classes for you)

Having said that, we can do a 'manual' binding in Presenter:

ValidationService.bind(PassiveView.GetField(), Model.ValidateField, PassiveView.SetErrorOnField)

the function signature of bind would be
bind<T>(T candidate, Func<bool, T> validate, Action signalError) {
if (! validate(field)) signalError();
}

We can do some more variations on the thema, where the ValidateField will also give us a message saying what was wrong with the candidate.

Variation within variation: message in several languages, should the model be responsible for that, maybe should provide the id to an message which will be translate...

One smell is that, after we have validated the field, by the Model, we pass again the value back to
the model in order to update/create some objects/fields.

Another discussion we had is that a constructor/factory using exceptions for validating arguments is expensive and it fails too fast, since we want to collect all error messages.

So we could replace that with a 2-step process:
maybeValidArgs = factory.Validate(args);
factory.create(maybeValidArgs);
but this is too 'manual'.

Some static typing functional languages have a construct to explicitely define a nullable value. In a c#/java would be:

interface Option<T> {
boolean HasValue();
T GetValue();
}

class Some<T> {
boolean HasValue() -> always true;
T GetValue() -> always the value;
}

class None<T> {
boolean HasValue() -> always false;
T GetValue() -> always throws an exception;
}

Note: In java we have type erasure, so for None<?> we can use a Singleton object.

Now for validation use case we might:

interface Option<T> {
boolean HasValue();
T GetValue();
IEnumerable<String> Errors();// Danger in using Strings !!! String is a 'primitive/sealed' type, which you cannot extend.
}

class Some<T> {
boolean HasValue() -> always true;
T GetValue() -> always the value;
IEnumerable<String> Errors() -> always Empty;
}

class None<T> {
boolean HasValue() -> always false;
T GetValue() -> always throw;
IEnumerable<String> Errors() -> always the errors;
}

Basically HasValue() has the same semantic with IsEmpty(Errors()).
We could change the pull - with a push:
instead of IEnumerable<String> Errors() (pull errors)
we push the errors in a handler
DoWithErrors(Action<IEnumerable<String>> errorHandler) -> Some will call the the action, None will do not

so we could use it like this:

Option<T> maybe = factory.TryCreate(args);
if (maybe.HasValue()) { ... do something with it }
else {
maybe.doWithErrors(View.DisplayErrors);
}

It is not difficult to associate an extra validation action for each arg/candidate field.

We just add optional args to TryCreate(args, params IAction[] actions) which we'll define as
mapping arg1 -> action1, arg2 -> action2. (if we have more args then actions, we don't call any action for them)

eg.

Option<Address> maybe = addressFactory.TryCreate(street_candidate, number_candidate, city_name_candidate, view.SignalErrorStreetName, view.SignalErrorValidateNumberCandidate, view.SignalValidateCityName)

...probably this will evolve to a 'framework', but at least a safe-type one, not string/reflection-based... And probably the annotation/reflection based are more AOP/crosscutting then this will be.

I don't get Spring

2008-03-27T21:26:00.009+01:00

Like CrazyBob, of guice fame, I also don't get Spring. Hammet also doesn't get it.
I mean what is the whole idea of wiring by xml? To decouple the wiring from the model.
But if you put the wiring.xml in the jar, so that it lands in the maven repository, to be used by others then it's not really decoupled.

Suppose I have 2 services, with their corresponding interfaces

class Producer implements IProducer { ... }
class Consumer implements IConsumer {
____Consumer(IProducer producer) { ... }
____...
}

what do we put in the xml file ? Basically we repeat the code-lines.
[bean id="..." class="Producer][/bean]
[bean id="..." class="Consumer"]
____[constructor-arg ref="..." index="0"/]
[/bean]

So not only we write again the required dependency, but we do it in xml so that we don't get
the benefit of refactoring (any changes due to renaming are lost).
I've intentionally left the ids unspecified. What should we put in there? The name of the class or the name of the interface?
- If we put the name of the class, then the Consumer-owner must know which class implements the IProducer interface, so a large part of the benefit of using interfaces is lost.
- If we put the name of the interface, in a declarative way, 'I am an IConsumer and I need an IProducer' then we have really duplicated the constructor line and the class declaration line in XML.

And now what about setter-injection. When I look at a class, I look at the interface it implements and what services it needs (in the constructor) to fulfill that contract. But Spring favors 'Setter Injection'.

The Spring team generally advocates the usage of setter injection, since a large number of constructor arguments can get unwieldy, especially when some properties are optional. The presence of setter methods also makes objects of that class amenable to being re-configured (or re-injected) at some later time (for management via JMX MBeans is a particularly compelling use case).

Constructor-injection is favored by some purists though (and with good reason). Supplying all of an object's dependencies means that that object is never returned to client (calling) code in a less than totally initialized state. The flip side is that the object becomes less amenable to re-configuration (or re-injection).
There is no hard and fast rule here. Use whatever type of DI makes the most sense for a particular class; sometimes, when dealing with third party classes to which you do not have the source, the choice will already have been made for you - a legacy class may not expose any setter methods, and so constructor injection will be the only type of DI available to you.

What does it mean for me, as a maintainer: I have to visually scan the file for the setters, wrap each of the private fields in a getter, and put in the getter a check for != null.

What about the argument that a class has too many args in constructor? Isn't that a smell which you should do something about it? (Well actually there are 2 smells: TwoMany-Parameters and ExpensiveSetUp)

What about the argument about 'optional arguments'. Isn't that a NullObject pattern?
So what was the Spring-solution? Autowiring? No, that came later. The Spring-developers said: we need an IDE to manage all that xml. WTF? Instead of getting rid of all that shit, you get a bigger shovel in order to dig deeper?

Now, the world is a little better. Now we have annotations and auto-wiring. But where are these annotations? Probably, declaratively, in a small component, so that other IoC containers could use these annotations for wiring? ... No, they are in the spring-core !!! (the logic is that if you were that smart/stupid to choose spring, then for sure you don't want to change your mind. And if you change your mind, than you should take every file and manually change the annotation and its import).

I really don't get the "significant benefits for many projects, increasing development productivity and runtime performance while improving test coverage and application quality".

ps. I had an argument about 'writing boiler-plate code isn't really that bad, since there are tools/IDEs to help you to write that'. I still strongly disagree: if 80% of the life of a software project is spend in maintenance, that means that we read/bug-fix code much more often then we write it. We must strive to READ LESS USELESS CODE.

pps. 'getter/setter methods are evil'

ppps. 'xml wiring is for girls'

ppps. from 'python is not java' : 'XML is not the answer. It is not even the question. To paraphrase Jamie Zawinski on regular expressions, "Some people, when confronted with a problem, think "I know, I'll use XML." Now they have two problems."'

ppps. A more detailed criticism on Spring.

blog marketing

2008-03-26T16:55:00.002+01:00

I've received a link about how-to make my blog more popular. (thanks Andi ;)
There are good tips in there but I'm not sure I want to go aggressive in 'active marketing':

it is more important that my readers say 'hey this is a cool guy with a good blog' that I say 'I am the greatest'
more time on marketing means less time on something else (this is probably weak, since I'm not a very effective blogger, but I compensate that by being an avid reader)
I would prioritize 'more, better content' higher than 'more aggressive marketing'. (I should really write more)
On the other side is really important to reach people and bring them something. An architect said that the real important think to do is to spread knowledge. Know imagine: instead of sitting here and doing a bad copy of bile-blog, without being even funny, winning about how java is crap, C# is crap, (btw. C# is better than java, sic!), I could/should put some interesting stuff in here and move at least a hand of developers to a better programming world. So if I can reach/teach at least 3 people, and every 'student' will reach at most 3 people and so on, maybe we can reach the critical mass, and move something.... (...or maybe this was just a naive rant)

Making it short: help me make the blog more popular: reddit, technorati, dzone me.

Memoization in Java

2008-03-18T16:51:00.002+01:00

OnJava in 2003, Tim White gave us generic way to build a memoize in java.
IMHO, Mr. White is trying to use big guns (dynamic proxy, reflection) on a small problem: function composition.

If we use/declare an interface:
public interface IFunc1 {
____R apply(A1 arg1);
}

then we can do implement Memoize1 (on 1 argument) as: (I use the Scala notation for generics [,] since blogger cuts out the xml devil quotes \<,\>)

public class Memoize1[A1, R] implements IFunc1[A1, R] {
____private final IFunc1[A1, R] func;
____private final Map[A1, R] cache;

____public Memoize1(IFunc1[A1, R] func) {
________this(func,new HashMap[A1, R]());
____}

____public Memoize1(IFunc1 func, Map[A1,R] cache) {
________this.func = func;
________this.cache = cache;
}

public R apply(A1 arg1) {
____R result = cache.get(arg1);
____if (result == null) {
________result = func.apply(arg1);
____cache.put(arg1, result);
____}
____return result;
____}
}

That's it. Generic. Composable. Reusable. No schnick-schnack.
Similar memoizer could be provide for IFunc2, IFunc3...
Notice that the Memoize has the same signature as the function it encapsulates.

ps. here is the F# version.

sooo '98

2008-02-26T11:20:00.002+01:00

from maven-surefire-plugin:

By default, the surefire plugin will automatically include all test classes with the following wildcard patterns:
"**/Test*.java" - includes all of its subdirectory and all java filenames that start with "Test".
"**/*Test.java" - includes all of its subdirectory and all java filenames that end with "Test".
"**/*TestCase.java" - includes all of its subdirectory and all java filenames that end with "TestCase".
If the test classes does not go with the naming convention, then configure surefire plugin and specify the tests you want to include.

ahh, those romantic days.
Apparently annotations and specifications are too 'exotic'.

Code Snippets Project

2008-02-21T21:42:00.001+01:00

I've published the C#, F# and python snippets in the code-snippets project.
Check-out get_dilbert_strips in py and F#.

Type Inference in F# & Scala (pointers)

2008-02-19T15:30:00.004+01:00

Here are some just some links about type inference in F# and Scala.

1st. from F# manual:

F# is statically typed, but frequently code will not contain many type annotations. This is because F# uses type inference to automatically determine the types of expressions. Type inference checks that types "match up" in obvious ways, i.e., that a function definition is consistent and that the definition of a function is sufficiently general to match all the ways in which it is used. Type inference is a global process over an entire source file, or, in the case of entries to F# Interactive, over the scope of a single entry delimited by ';;' terminators.

Type inference automatically generalizes code to be as generic as possible. To see the types inferred for the top-level definitions in your program use the -i compiler switch, or hover your mouse over definitions in a supported interactive environment such as Visual Studio.

Calls and accesses to .NET and F# methods and properties (collectively known as members) involve a form of type-directed overload resolution, resolved based on left-to-right, outside-to-in analysis of a file, i.e., type information subsequent to the use of an overloaded member is not taken into account for its resolution.

In addition, some operators such as + are overloaded. Operator overloading is resolved over the same scope as type inference, typically an entire file. Where operator overloading is not resolved the overloading typically defaults to work over 32-bit integers.

Code that uses .NET library calls (and in particular libraries which make heavy use of the dot-notation) will need to be annotated with extra type annotations in order to assist the type inference process. The F# type checker will indicate when further type annotations are needed.

(for F# I can also recommend the F# books)

2nd Scala: besides the type-inference, has a very nice generic system, with focus on components & scalability, see 'Generics of a Higher Kind', the google-talk (slides here), and the other scala-docs (for the studious). (you can feel a flavor of Haskell in scala (traits, implicits) , bringing the high-order-function elegance)

What's the probability of at least two persons among 20 to have the same birthday?

2008-01-23T10:13:00.000+01:00

I'm an anti-virus engineer. Recently, we've detected a mobile phone worm that spreads by attaching itself to MMSs that it sends to various phone numbers. Our contact at the mobile phone operator harvested about 1000 MMSs. Some MMSs were sent to the same phone numbers.

The question was: does the worm generate the phone numbers randomly or are the phone numbers hard-coded in its code?

A related question is: IF the numbers are randomly generated, which is the probability to have several identical numbers among a set of 1000 numbers?

The variable part in the 11-digit phone numbers consists of 5 digits. We assume that the phone numbers are equally probable.

There are 10^5 equally probable possible phone numbers. Let us consider each phone number as a letter of alphabet that contains 10^5 letters. There are (10^5)^1000 distinct 1000-letter strings that we can write in this alphabet. (To convince yourself, think that the alphabet is our normal 10-digit decimal system and we want to build a 3-letter string. How many distinct strings can we build? 1000. 000, 001, ..., 009, 010, 011, ..., 019, 020, ..., 999.)

How many strings do we have such that each string contains only distinct letters? In order to answer, think how to build such a string. You pick the first letter from the 10^5 available. Then you pick the second from the 10^5-1 available, etc. If you remember your combinatorics classes, then you'll recognize the "variations". How many variations of 1000 elements from a set of 10^5 are there? (10^5) * (10^5 - 1) * ... * (10^5 - 999).

To summarize, we have an alphabet of 10^5 letters, they are equally probable. We have (10^5)^1000 possible 1000-letter strings. These strings are also equally probable. We have (10^5) * (10^5 - 1) * ... * (10^5 - 999) equally probable strings such that each string contains only distinct letters.

Thus, the probability to pick a randomly build a 1000-letter string that contains only distinct letters (i.e. the probability that all phone numbers among the 1000 harvested phone numbers be different) is

(10^5 / 10^5) * ((10^5 - 1) / 10^5) * ((10^5 - 2) / 10^5) * ... * ((10^5 - 999) / 10^5) = 0.0066594036

The probability that at least two numbers are identical among the 1000 numbers is 1 minus the probability computed above, i.e. 0.9933405964.

As I was not very sure of my reasoning, I wrote a small simulation:

#include <stdio.h>
#include <stdlib.h>

#include <strings.h>
#include <unistd.h>
#include <time.h>
#include <errno.h>
#include <signal.h>

#define DFLT_N 100000
#define DFLT_K 1000
#define DFLT_MAX_ITER 1000000


static unsigned int max_iter, iter, equals, N, K;

static unsigned int *a;

static double
uniform_distrib(double a, double b) {

  return a + (b - a) * ((double)random() / (double)RAND_MAX);
}

static void
onUSR1(int dummy) {
  printf("%f\n", (double)equals / iter);
}

static void
parse_cmd_line(int argc, char *argv[]) {

  int c;
  char *endp;
  extern char *optarg;

  while ((c = getopt(argc, argv, "hN:K:i:")) != EOF)

    switch (c) {
    case '?':
      /* error */
      break;

    case 'h':
      /* help message */
      break;
    case 'N':

      errno = 0;
      if (optarg == NULL) {

 /* error */
      }
      N = (unsigned int)strtoul(optarg, &endp, 0);

      if (errno != 0 || *endp != '\0') {

 /* error */
      }
      break;
    case 'K':
      errno = 0;

      if (optarg == NULL) {
 /* error */
      }

      K = (unsigned int)strtoul(optarg, &endp, 0);
      if (errno != 0 || *endp != '\0') {

 /* error */
      }
      break;
    case 'i':
      errno = 0;

      if (optarg == NULL) {
 /* error */
      }

      max_iter = (unsigned int)strtoul(optarg, &endp, 0);
      if (errno != 0 || *endp != '\0') {

 /* error */
      }
      break;
    }
  if (N == 0)

    N = DFLT_N;
  if (K == 0)

    K = DFLT_K;
  if (max_iter == 0)

    max_iter = DFLT_MAX_ITER;
}

int
main(int argc, char *argv[]) {

  unsigned int i, picked;
  struct sigaction act;

  parse_cmd_line(argc, argv);

  srandom(time(NULL));

  if ((a = malloc(N * sizeof(unsigned int))) == NULL) {

    /* error */
  }

  act.sa_handler = onUSR1;
  act.sa_flags = 0;

  sigemptyset(&act.sa_mask);
  sigaction(SIGUSR1, &act, NULL);

  for (iter = 0; iter < max_iter; ++iter) {

    bzero(a, N * sizeof(unsigned int));
    for (i = 0; i < K; ++i) {

      picked = (unsigned int)uniform_distrib(0.0, (double)N);
      if (a[picked] == 1) {
 ++equals;

 break;
      }
      a[picked] = 1;
    }
  }
    
  onUSR1(SIGUSR1);

  return 0;
}

It can be used to answer the question in the title. The simulation says 0.411308. The "theory" says 0.4114383836.

If we were to be pedantic, the fact that we make some observations coherent with the predictions of a model does not imply that the model is indeed true, especially when we can easily imagine other models that make the same predictions. Thus, we called three distinct phone numbers out of the 1000 harvested. Two of them were not allocated. But this second method looks like the ultimate solution to measuring the height of a building with a barometer.

F# Algorithm Sample

2007-08-31T18:56:00.000+02:00

But here is a "short description" of a problem:
Both the computer and the user have a row of units, each unit has a value. The rows are aligned face to face (like in a 2xn chess table). Each unit fights the unit in front of it. The unit with the biggest value wins. If 2 units have the same value, the computer wins. If the user knows how the computer will position its units in the row, how can the user position his units in order to minimize his loses. Write a program which computes this win/loss score. (some test data is provided).

And here is my sample:

let rec without_max ascending_sorted_list = 
   match ascending_sorted_list with
       | [] -> []
       | x::[] -> []
       | x::y::xs -> x::without_max(y::xs) 

let rec acc (me:list<int>, computer:list<int>, saved:int) =
   match me, computer with
   | x::xs, y::ys -> if x <= y then acc(xs, without_max(computer), saved)
                     else acc(xs, ys, saved+x)
   | [], [] -> saved
   | _ -> failwith "unequal arrays"

let save_creatures (me:list<int>) (computer:list<int>) =
   let ascending_sort = List.sort(fun (x:int) (y:int) -> x.CompareTo y) in 
   acc(ascending_sort(me), ascending_sort(computer), 0) 

let _ = 
   let a = save_creatures [5;15;100;1;5] [5;15;100;1;5] in
   let b = save_creatures [15;15;15;15;15] [15;15;15;15;15] in
   let c = save_creatures [1;3;5;7;9;11;13;15;17;19] [2;4;6;8;10;12;14;16;18;20] in 
   let d = save_creatures [2;3;4;5;6;7;8;9;10;11] [10;9;8;7;6;5;4;3;2;1] in
   print_int a; print_int b; print_int c; print_int d

I had fun ;)

Injection Doctor

2007-08-08T17:45:00.000+02:00

We use in project X a slightly wrapped PicoContainer. The implementation of several service are registered in the container explicitely. Sometimes people forget to register it, and unfortunately the container fails with an "UnsatisfiedConstructor" error. The error appears only at run-time (we don't have test-coverage for container configuration), and it's misleading: if we need a class A which needs B,
and we forgot to register B, we get the error on class A (which is, per se, OK).

The solution (proposed) is to instantiate recursively all the services, and to build for each (failed) instantiation a histogram: the more points we get for a service, the "more" needed it is, the probability to
have there the "injection-problem" will be bigger. For the previous example A will get 1 point and B 2 points.

And here is the source:

    public class Memoize {
        private readonly Func _func;
 
        public Memoize(Func func) {
            _func = func;
        }
 
        private IDictionary _cache = new Dictionary();
 
        public R Call(T value) {
            R result;
            if (_cache.ContainsKey(value)) {
                result = _cache[value];
            } else {
                result = _func(value);
                _cache[value] = result;
            }
            return result;
        }
    }

    class InjectionExplorer {
        private Func<IEnumerable<Type>, Type> _greediest_ctor_params;
 
        public InjectionExplorer() {
            _greediest_ctor_params = new Memoize<IEnumerable<Type>, Type>(GreediestConstructorParametersWorker).Call;
        }
 
        public IEnumerable<Type> RequiredTypes(Type t) {
            return _greediest_ctor_params(t);
        }
 
        private ConstructorInfo Greediest(Type t) {
            ConstructorInfo greediest = null;
            int greediest_param_length = -1;
            foreach (ConstructorInfo ctor in t.GetConstructors()) {
                if (ctor.GetParameters().Length > greediest_param_length) {
                    greediest = ctor;
                    greediest_param_length = ctor.GetParameters().Length;
                }
            }
 
            if (greediest == null) { throw new Exception("No ctor was found"); }
            return greediest;
        }
 
        private IEnumerable<Type> GreediestConstructorParametersWorker(Type t) {
            ConstructorInfo ctor = Greediest(t);
            return Enumerables.Do.Map<Type, ParameterInfo>(ctor.GetParameters(), delegate(ParameterInfo info) { return info.ParameterType; });
        }
    }
 
    class InjectionDoctor {
        private readonly IEnumerable<Type> _types;
        private readonly Func<object, Type> _instantiate;
        private readonly InjectionExplorer _explorer;
        private readonly IDictionary<Type, int> _failed_instantiations;
 
        public InjectionDoctor(IEnumerable<Type> types, Func<object, Type> instantiate) {
            _types = types;
            _instantiate = instantiate;
            _explorer = new InjectionExplorer();
            _failed_instantiations = new Dictionary<Type, int>();
        }
 
 
        public void Examine() {
            Enumerables.Do.ForEach(_types, TryInstantiate);
        }
 
        public void PrettyPrint() {
            string print_format = "{0} -> {1}";
 
            Console.WriteLine(print_format, "Type", "Failed Instatiation Count");
            foreach (KeyValuePair<Type, int> failed_instantiation in SortFailedInstatiationsByFailedCount()) {
                Console.WriteLine(print_format, failed_instantiation.Key, failed_instantiation.Value);
            }
        }
 
        private IEnumerable<KeyValuePair<Type,int>> SortFailedInstatiationsByFailedCount() {
            List<KeyValuePair<Type, int>> pairs = new List<KeyValuePair<Type, int>>();
            foreach (KeyValuePair<Type, int> failed_instantiation in _failed_instantiations) {
                pairs.Add(failed_instantiation);
            }
 
            pairs.Sort(delegate(KeyValuePair<Type, int> x, KeyValuePair<Type, int> y) { return y.Value.CompareTo(x.Value); });
            return pairs;
        }
 
        private Type Instantiable(Type candidate) {
            if (candidate.IsArray) {
                return Instantiable(candidate.GetElementType());
            }
            return candidate;
        }
        private void TryInstantiate(Type candidate) {
            Type instantiable = Instantiable(candidate);
 
            if (HasFailedInstatiations(instantiable)) {
                CountFailedInstantiation(instantiable);
                return;
            }
 
            try {
                _instantiate(instantiable);    
            } catch (Exception) {
                CountFailedInstantiation(instantiable);
                TryInstatiateRequiredTypes(instantiable);
            }
        }
 
        private void TryInstatiateRequiredTypes(Type candidate) {
            Enumerables.Do.ForEach(_explorer.RequiredTypes(candidate), TryInstantiate);
        }
 
        private bool HasFailedInstatiations(Type candidate) {
            return _failed_instantiations.ContainsKey(candidate);
        }
 
        private void CountFailedInstantiation(Type candidate) {
            if (! HasFailedInstatiations(candidate)) { _failed_instantiations[candidate] = 0; }
            _failed_instantiations[candidate] += 1;
        }
 
        public int FailedInstatiations() {
            if (! HasFailedInstatiations(typeof(T))) { return 0; }
            return _failed_instantiations[typeof (T)];
        }
    }

Unit-Test sample:

    class B {
        private readonly C _c;
 
        public B(C c) {
            _c = c;
            throw new Exception("poof");
        }
    }
 
    class C {
        public C() {
            throw new Exception("poof");
        }
    }
 
    class D {
 
    }
 
    class E {
        private readonly C[] _cs;
 
        public E(C[] cs) {
            _cs = cs;
        }
    }
 
    class A {
        private readonly B _b;
        private readonly D _d;
 
        public A(B b, D d) {
            _b = b;
            _d = d;
        }
    }
 
 
    [TestClass]
    public class InjectionDoctorSpecifications {
        private DefaultPicoContainer _container;
        private InjectionDoctor _doctor;
 
        [TestInitialize]
        public void BeforeEachTest() {
            _container = new DefaultPicoContainer(); 
        }
 
        private void Register(IEnumerable<Type> types) {
            foreach (Type t in types) {
                _container.RegisterComponent(new CachingComponentAdapter(new ConstructorInjectionComponentAdapter(t)));
            }
        }
 
        [TestMethod]
        public void should_detect_instantiation_failures() {
            IEnumerable<Type> types = new Type[] {typeof (A), typeof (B), typeof (C), typeof (D), typeof(E)};
            Register(types);
            _doctor = new InjectionDoctor(types, _container.GetComponentInstanceOfType);
 
            _doctor.Examine();
            //_doctor.PrettyPrint();
            Assert.AreEqual(1, _doctor.FailedInstatiations<A>());
            Assert.AreEqual(2, _doctor.FailedInstatiations<B>());
            Assert.AreEqual(3, _doctor.FailedInstatiations<C>());
            Assert.AreEqual(0, _doctor.FailedInstatiations<D>());
            Assert.AreEqual(1, _doctor.FailedInstatiations<E>());
        }
 
 
 
    }

The output of the PrettyPrint looks like:
Type -> Failed Instatiation Count
Tests.C -> 3
Tests.B -> 2
Tests.E -> 1
Tests.A -> 1

Additionally we could add a method bool InjectionDoctor.HaveAllInstantionsSucceded()
ps. The Blogger Code Formatter is not playing nice with the generics: the InjectionDoctor takes as parameter in constructor a function f(Type) -> object. In this way we make the InjectionDoctor container-agnostic.
pps. source-code on request.

Mixing Peer (extension objects in c# 2.0)

2007-08-01T09:50:00.000+02:00

In project X we have a big hierarchy of objects/interfaces:
Eintrag
- Artikel
- NeuFormArtikel
- NormalArtikel
- AbdaArtikel
- Verweis
- AbrechnungsEintrag

(The hierarchy is bigger, but this is enough for our purpose.)
We have a case, where in a View we must display a union of fields from this hierarchy. i.e. AbdaArtikel.Preis if the object has such a property, otherwise null/string.Empty.

We have several options:
- use a visitor for the whole hierarchy
- use a PropertyMapper (reflection-fluent-interface-based machinery) (looks pretty slick, enables a very declarative way of mapping, maybe I will post about it)
- extend/pull the AbdaArtikelPreis into the Eintrag (if we need it there)
- mix in a generic visitor:

Since the objects/interfaces in the hierarchy are Nhibernate BOs, they are proxied, i.e., in our configuration, we cannot use generic methods in BOs. But we can extend the BO with an object which can:

we define Eintrag.Peer() { return new EintragPeer( this ); }
now we can extend the peer/mixing with generics

public class EintragPeer {
    private readonly Eintrag _extended;
 
    public EintragPeer( Eintrag extendable ) { _extended = extendable; }
 
    public R TryMap(Func func, R otherwise_default) where T : Eintrag {
        if ( _extended is T ) { return func( _extended as T ); }
        return otherwise_default;
    }
 
    public void TryApply(Action action) where T : Eintrag {
        if (_extended is T) { return action(_extended as T); }
    }
}

Now we can use it as:

Preis eintrag_preis = eintrag.Peer().TryMap(
    delegate(Artikel artikel) { return artikel.Preis; },
    Preis.Null);

Other variations can be build on that.

"Agile" Process Disentanglement

2007-07-19T13:17:00.000+02:00

How FUBAR can an "agile" process be, that this book is needed?
How deep in the jungle is the team, that we need a silver-magic-map to bring it back on the driving-road?

Functional idioms, Take Three

2007-07-18T09:49:00.000+02:00

In a hypothetical project in which the Law of Demeter is completely ignored navigation through objects is allowed: we can do A.B.C.D.E.DoSomething(). This has a lot of negative effects, already spoken/written, I'm not going into details.

My 1st suggestion would be to play by the rules, and pull the DoSomething(...) through the hierarchy up to A, where you need it.
But what if you cannot do it ("it is not the way we do it in this project") ? What if, to make the matters worse, every element in the chain could be null (and not a NullObject) ? The chain would explode in a cascade of if-then-else-s to check every element for null, etc...

Comega has something like int? = A.B.C.GetSomeIntValue(...)
We (C#) could do:

created.PackungsgroessenEinheitText = Chain.On.Nullables<IArtikel, INormalArtikel, Packungsgroesse, string>(
                artikel,
                delegate(IArtikel x) { return x as INormalArtikel; },
                delegate(INormalArtikel x) { return x.Packungsgroesse; },
                delegate(Packungsgroesse x) { return string.Format("{0} {1}", x.Menge, x.Einheit); }
            );

we navigate throught the chain with delegates. The navigation is interrupted on the 1st null hit.
If we watch the "chain" implementation:

   public class Chain {
        private Chain() {}
 
        public static Chain On { get { return new Chain(); } }
 
        public  R Nullables(S input, Func fun_1)
            where S : class
            where R : class {
 
            if (input == null) {
                return null;
            }
 
            return fun_1(input);
        }
 
        public R Nullables(S input, Func fun_1, Func fun_2) 
            where S : class 
            where R1 : class
            where R : class {
            return Nullables(Nullables(input, fun_1), fun_2);
        }
 
        public R Nullables(S input, Func fun_1, Func fun_2, Func fun_3)
            where S : class
            where R1 : class
            where R2 : class
            where R : class {
            return Nullables(Nullables(Nullables(input, fun_1), fun_2), fun_3);
        }
    }

we see that this could be very nicely implemented with some C++ metaprogramming templates (see compile-time factorial).

F# has function composition through pipelining, offering some optimizations for it
Tail Call Optimization !?

Functional Idioms, Take Two

2007-07-09T10:51:00.000+02:00

My friend Ralf has extended the Enumerating module, adding a fluent interface.

Since the mini-project lives, I think we should create a sourceforge acount for it.

I have extended the interface with IsEmpty, Count, ApplyOnce, ...

I really like the fluent interface. SelectThenCollect is no longer necessary, we can do Select(...).Collect(...)

if in the initial Enumerable we have m elements and we select n from them, SelectThenCollect is O(m). Select(...).Collect(...) will take O(m)+O(n). (in the current implementation).

Open Question: the current implementation does eager-evaluation: the select is computed when the method is called. Do we need a lazy-implementation? It could look like a query definition, and the code will be more declarative:

IEnumerating query = Enumerating.On(several_things).Select(IsEven).Collect(ItsColor);
IEnumerable result_items = query.Eval();
The solution might cache, the specified delegates, for a later (lazy), usage. This might lead to some unwanted side-effects: the garbage collector will not release the objects referenced in the delegates in the query definition, until ... (the query is released).
Through laziness we could work on very large (infinite) data streams.

Sudoku Solver: TDD or not

2007-07-03T17:17:00.000+02:00

In this blog people are comparing Peter Norvig's solution with Ron Jeffries TDD tries. (read the post, [some] good comments, other links to reddit comments, etc.)

It is a nice problem to chew on, for me, as Unit-Test/TDD agilist: I think that a TDD approach does not lead to discover constraint satisfaction algorithms, it should lead to a clean, testable, SRP driven architecture. If I remember well, the XP books say that you should start with a "metaphor", a design starting point.

disclaimer: this an echo post, i just wanted to link to AIMA.

Logging and Unit-Testing

2007-06-28T21:09:00.000+02:00

Imagine the following situation:

public class SomeService {
   private static ILogger _logger = new Logger<SomeService>();
   //...
   public void DoSomething() {
       _logger.Debug("I log something cheap {0}", _service.DoSomething());
       //...
       if (_logger.IsDebugEnabled()) {
           _logger.Debug("I log something expensive {0}", _service.DoSomethingElse());
       }
   }

How do we want to test that logging works in this situation?
A proposed solution was:

 [Test]
   public void should_log_something() {
       using(disable_appenders_and_introduce_new_appender = new MagicStringAppender()) {
           _service_under_test.DoSomething();
           Assert(disable_appenders_and_introduce_new_appender.AllMessages.Contains("I log ...");
       }
   }

And here is what I don't like about it:

Static creation of ILogger: by this we make ourselves dependent of the concrete implementation of Logger class. This will pull other dependencies (like log4net) in the environment, despite the fact that these are irrelevant for the test. The logger will be created when the class(type) is instantiated.
The check-before logging for expensive log operations, is too low-level. A macro might help (TRY_LOG_DEBUG(...)), or maybe delaying the expensive operation into a lazy delegate: _logger.Debug(Func a_delayed_string_generator). The only objection might be that wrapping the costly operation in a delegate creates an extra object, making in the worst case scenario, the logging even more expensive. (From what I know, delegates & closures are pretty cheap).
Maybe we don't know which operations are cheap and which are expensive, maybe in time a cheap log call will evolve to an expensive one. I would prefer a uniform lazy_delegate or macro solution.
We are trying to unit-test a scope which is too big: if the service sends a message to the logger interface, if log4net (and its wrapper) receive the message, if according to the configuration, the log message is sent to the right appender, etc... Suppose that we change the config, and log4net, and the test fails. Then we have a lot of fun debugging. We will say: "why isn't working, I haven't changed anything in months". Because the scope is too big, we have no chance to do a binary chop.
We have built another big machinery to manipulate log4net at the wrong end. This machinery must be maintained and support (for example when we want to switch to another log engine)

What I would do (probably better):

Explicitly specify that we want to log in constructor. Either inject an ILogger or an ILoggerFactory.
Test only that the service sends a message to the ILogger interface (a mock or a stub recorder)
Try to use a delegate for delayed/expensive computations.
Use a main logger for the critical exceptions (like OutOfMemory)

---
Update:
- the post it is not about what am I trying to log, it is about "how" I am trying to log. (suppose the expensive operation is dumping a complex object tree to a human-readable-not-xml representation)
- I am not a proponent for logging-testing, but some people would like to do that (logging gives a chill-fuzzy feeling: "I don't know what I have implemented, QA also doesn't have a clue, and now we are relying on log files, on a production-customer-machine. hmmm..."

F# FizzBuzz

2007-06-15T09:16:00.000+02:00

I'm trying to learn F# as the "pragmatic-learn-a-new-changing-the-way-you-think-programming-language-every-year" (sorry about that, it must be the german influence).

Here are my FizzBuzz exercises, based on F# Active Patterns:

First try:

let (| fizz|_ |) x = if x % 3 = 0 then Some("fizz") else None

let (| buzz|_ |) x = if x % 5 = 0 then Some("buzz") else None

let (| fizzbuzz|_ |) x = if x % 15 = 0 then Some("fizzbuzz") else None

let print_fizzbuzz (x:int) =

let display text = print_string text; print_newline() in

match x with

| fizzbuzz text -> display text

| fizz text -> display text

| buzz text -> display text

| _ -> x.ToString() |> display

let _ = for i = 1 to 20 do print_fizzbuzz i done

Second try: refactor the recognizers to a single parameterized recognizer:

let (| is_multiple|_ |) n text x = if x % n = 0 then Some(text) else None

let print_fizzbuzz (x:int) =

let display text = print_string text; print_newline() in

match x with

| is_multiple 15 "fizzbuzz" text -> display text

| is_multiple 5 "fizz" text -> display text

| is_multiple 3 "buzz" text -> display text

| _ -> x.ToString() |> display

let _ = for i = 1 to 20 do print_fizzbuzz i done

(* we do get a warning that the syntax for the parameterized recognizers is under review and it might change in the future release *)

Please post or backlink for improvements :D

APIs, handling dependencies, agile architecture

2007-06-05T13:23:00.000+02:00

Somebody said recently that Resharper is "not so lovely" since it cannot handle thousand of files... My argument is that the need to work simultaneously (in a solution) is a smell, and the fact that Resharper crashes at type-parsing with a "System.OutOfMemoryException" exception should amplify the smell (increase our awareness).

I think we have only two cases: inside the membrane, or outside the membrane. The core of the cell represents a service implementation, the membrane represents service definition, outside the membrane are the service consumers/users. Actually outside the membrane, is inside another membrane: the whole architecture should be splitted in components.

If we are inside we are working on the implementation of a certain service(object, component). Inside a component we have limited visibility, up to a component interface (the membrane). Maybe some other interfaces, or stand-alone components (without external dependencies, for examples enumerating). All refactorings, type-parsing should occur without problem in this component.

If we are outside, we are service consumers. But we cannot talk to the "core" of the cell, we see only the membrane: the component interface. So we are not influenced by the changes in the implementation of the service (aka the "core").

What happens if you are a producer and you need to modify service definition. If we don't have a few consumers, we could load all the required components in a solution (producer + all consumers), and refactor the whole thing. If we have many consumers, we need to use public API techniques: we declare the whole interface as obsolete, we declare and implement the new one. After x weeks we delete the old interface (the consumers are responsible for refactoring their own code).

Isolating the change, is a fundamental principle in designing maintainable architectures. In a world without membranes, we are just hurting each other.

Higher-Level Abstractions on Enumerations

2007-04-10T10:55:00.000+02:00

I am not the only one missing a higher-level of abstraction in .Net.
I feel that I wrote thousand times find, select, collect as foreach ...
statement, without the clarity (declarativeness) needed.
Here is my shot
(very lightweight at it):

Static Considered Harmfull

2007-02-01T10:59:00.000+01:00

Let's imagine the following situation:

static class Service {
static void DoSomething(...)
}

class Client {
Client() {}

void Action() {
Service.DoSomething(...)
}
}

We have the following smells:

1. Tight-Coupling
- The client object is tight-coupled with the Service class.
- We cannot exchange, polymorphically, the Service.DoSomething(...)
with another service FunkyService?.DoSomething.

2. "Lying" Constructor
- The client's constructor doesn't declare all the dependecies.

3. Tight-Coupling Propagation
- If the class Service has dependencies to other static classes
(methods, instances, properties), than these dependencies propagate into
the client. The "inoffensive" Service.DoSomething(...) is just the tip of an iceberg of singletons.

Proposed Solution:
In an OO world, responsabilities are realized by objects.
Unfortunately in static-typed langugages classes ARE NOT objects.
(in smalltalk/ruby they are, we don't have this problem)

So let's do it right from the beginning:

interface IService {
void DoSomething(...)
}

[Inject]
class Service {
void DoSomething(...)
}

class Client {
Client(IService service) { _service = service }
void Action(service.DoSomething(...));
}

Benefits:
- we are unattached from the implementation of the IService.DoSomething
- we have explicitely defined the responsability of the client to delegate/ask a
query to the IService implementor
- We can provide different implementations to the IService
- UnitTesting is easier: if the implementation of the IService has been tested,
then in the Client's unit-tests we are only interested in the call to IService,
which we can mock.
- Instance creation is handled by dependency injection container
(if you need only one, create just only one)

An example in ruby (classes are factory objects):
http://onestepback.org/articles/depinj/

2006-10-04T12:22:00.000+02:00

A bile on the the death of agile and an other post about the flip side of agile as religion vs. agility at google: Good Agile, Bad Agile

Agile Project Management Planning and Budgetting

2006-09-14T16:42:00.000+02:00

Great presentation via InfoQ by David Hussman.

Liskov Substitution in Dynamic Languages

2006-09-11T10:20:00.000+02:00

A nice discussion on Michael S. Feathers blog.

Jim Weirich observes:

The original LSP is defined in terms of types and subtypes, not classes and subclasses. In Ruby, we try to remind people that type is not related to class. It seems to me that LSP still applies to dynamic languages, even if there is no direct language construct for type.

Also a link to dynamic/static type contracts (interfaces).

Gmail Tricks

2006-09-07T10:36:00.000+02:00

found here:

Gmail has an interesting quirk where you can add a plus sign (+) after your Gmail address, and it'll still get to your inbox. It's called plus-addressing, and it essentially gives you an unlimited number of e-mail addresses to play with. Here's how it works: say your address is pinkyrocks@gmail.com, and you want to automatically label all work e-mails. Add a plus sign and a phrase to make it pinkyrocks+work@gmail.com and set up a filter to label it work (to access your filters go to Settings->Filters and create a filter for messages addressed to pinkyrocks+work@gmail.com. Then add the label work).

More real world examples:

Find out who is spamming you: Be sure to use plus-addressing for every form you fill out online and give each site a different plus address.

Example: You could use
pinkyrocks+nytimes@gmail.com for nytimes.com
pinkyrocks+freestuff@gmail.com for freestuff.com
Then you can tell which site has given your e-mail address to spammers, and automatically send them to the trash.

Automatically label your incoming mail: I've talked about that above.

Archive your mail: If you receive periodic updates about your bank account balance or are subscribed to a lot of mailing lists that you don't check often, then you can send that sort of mail to the archives and bypass your Inbox.

Example: For the mailing list, you could give pinkyrocks+mailinglist1@gmail.com as your address, and assign a filter that will archive mail to that address automatically. Then you can just check in once in a while on the archive if you want to catch up.

Software Development as Turkey

2006-09-06T15:27:00.000+02:00

from Darren Hobbs entry:

You can't achieve the same effect when roasting a turkey by doubling the temperatuire and halving the cooking time. Similarly a project cannot have the number of people doubled and the duration halved and get the same result. The rate of knowledge crunching is not increased by adding more people.

Closures in Java

2006-09-06T11:48:00.000+02:00

Another post with links.

From Debasish blog, a link to Gilad Bracha's blog entry (with some nice comments)
Pick from post:

One question that naturally arises is "what took you so long?".
...
Since the late 90s, I've brought the topic up now and again. At times, even I have reluctantly been convinced that it is too late, because we've done so many things that would have been easy with closures in different ways. This means the benefits aren't as high as in a language like Scheme, or Self, or Smalltalk. The cost is non-trivial, to be sure.

Pick from the comments:

SUN never cared to implement Closures in Java.The reason why they are caring about now is Microsoft introduced them in C#.

So the funda is IF YOU WANT A NEW FEATURE IN JAVA DONT ASK SUN,(ITS TIME WASTE), BETTER ASK MICROSOFT, ONCE MS IMPLEMENTS THAT FEATURE IN THEIR LANGUAGE, THE NEXT YEAR SUN WILL CONSIDER THAT FEATURE. (This is also the quickest way of getting your favourite feature in JAVA).

(1st enums, support for dynamic languages, now closures...) :D

And a link to jaggregate examples.

Myths, Lies, and Truths about the Linux kernel

2006-07-27T09:46:00.000+02:00

Greg Kroah-Hartman's slides.

Google Tech Talk: Cornelia Brunner - 'On Girls, Boys and IT Careers'

2006-07-26T16:36:00.000+02:00

google video

Comments in code

2006-07-26T16:17:00.000+02:00

from wiki: 'to need comments' and 'too much documentation'

Class comments - OK.
Method comments - NO
Comments in code - NO

If you need a comment to specify the behaviour of an object/method, specify that behaviour in some unit-tests. In that way you get runnable, automatic, one-click behaviour testing. If your test cases have good names, than you won't need to actually read the code in the tests, a brief look at the method names should say how an object/method reacts.

Tim Ottinger writes here:

A comment is an apology for not choosing a more clear name, or a more reasonable set of parameters, or for the failure to use explanatory variables and explanatory functions. Apologies for making the code unmaintainable, apologies for not using well-known algorithms, apologies for writing 'clever' code, apologies for not having a good version control system, apologies for not having finished the job of writing the code, or for leaving vulnerabilities or flaws in the code, apologies for hand-optimizing C code in ugly ways. And documentation comments are no better. In fact, I have my doubts about docstrings.

If something is hard to understand or inobvious, then someone *ought* to apologize for not fixing it. That's the worst kind of coding misstep. It's okay if I don't really get how something works so long as I know how to use it, and it really does work. But if it's too easy to misuse, you had better start writing. And if you write more comment than code, it serves you right. This stuff is supposed to be useful and maintainable, you know?

Is there any use of comments that are not apologies? I don't think so. I can't think of one. Is there any good reason to write a comment? Only if you've done something "wrong".

Podcast: Scott Ambler - Advanced Agile Techniques

2006-07-26T12:53:00.000+02:00

mp3 here

Interview with Andy Hunt - Practices of an Agile Developer

2006-07-25T16:43:00.000+02:00

on perlcast

no null

2006-07-25T14:20:00.000+02:00

I've seen too many NullPointerExceptions.
Apparently I am not the only, see the post from Michael Feathers:

Passing null in production code is a very bad idea. It’s an example of what I call offensive programming – programming in way that encourages defensive programming. The better way to code is to deal with nulls as soon as they happen and translate them to null objects or exceptions. Unfortunately, this isn’t common knowledge.

Keith Ray explains how it is done in Objective-C:

In Cocoa / Objective-C programming, I still prefer an empty string over a null pointer, or an empty container-object over a null object, but the language does have a key difference: calling object methods on null-pointers does not normally crash! (But sometimes method parameters being null can cause a crash.)

Foo* aFoo = nil;
Bar* aResult = [aFoo someMethod: anArgument ];

calling someMethod (as above) on a nil object DOES NOTHING (it does not crash or throw an exception) and returns nil.

The Cocoa UI frameworks take advantage of this. For example, the objects that implements a Button or a Menu item would have two members variables: a pointer to an object, and a "selector" that identifies what method to call on the object. The method that handles a click (or whatever) would be written something like this:

[ targetObject performSelector: actionSelector withArgument: self ];

instead of like this:

if ( targetObject != nil ) {
[ targetObject performSelector: actionSelector withArgument: self ];
}

No need to check for a null targetObject. There would be a need to check for a null-selector (in the performSelector:withArgument: method), since the selector isn't actually an object.

People have objected that null acting like the "null object pattern" hides bugs, but too many times have I gotten web-apps sending me messages that a "null pointer exception has occurred" so I assert that null-pointer exceptions are not helping people find bugs as well as test-driven development, or thorough code-reviews and testing, would do. I expect that if null had the "null object" behavior, the web-app would have returned an partial or empty result rather than a crashing message, and that would be fine for a most users.

If the "null = null object pattern" behavior is an expected and documented part of the language, it can work quite well. Cocoa and NextStep programmers are, and have been, very productive using a language with this behavior.

Achileas Margaritis makes a very good point:

No, the problem with nulls is not their existence, but that there are not separate types.

This is the real problem: null is no object, you cannot send any message to it (you cannot call any method on it). So if I declare a function: doSomethingWith(Object somethingElse), than it is clear that I expect an object (and null is no object !!!) as argument for the method. (the same goes for the result of a function: object provideSomething()).

A colleague said that null is like a "joker" when playing cards. Nice metaphor, but null is an "evil" jocker.

Misstating the Evidence for Agile and Iterative Development

2006-07-24T17:09:00.000+02:00

got the link from this post (an interesting read, as well).
and the extra link

Java "new" for non-static iinner classes

2006-07-12T16:03:00.000+02:00

By (over) using non-static inner-classes, I came to the following code:

InnerClass created = outer_class_instance.new InnerClass(...);
The "new" operator is completely misleading: is no method(message) of the OuterClass.
It just couples the creation to the outer_class_instance scope.

strange...

Functional Programming

2006-07-12T15:58:00.000+02:00

Peter Norvig's "Python for Lisp Programmers"
Another "comparison of Python and Lisp"
James Edward Gray "Higher Order Ruby"

Lisp Scripting for .Net
F# ML/OCaml variant for .Net (nice sample here)

First feelings:
- Python is more functional than object oriented (watch-out for lambdas cannot contain statements)
- Ruby is more smalltalk-ish (I found it easier to use than Python)
- Lisp is more readble than ML/OCaml

Java 4s

2006-06-23T16:55:00.000+02:00

Try this in java:

(4 == 4)
(new Integer(4) == new Integer(4))

well the first one is true, the second one is false. Why do I need 2 instances of the number (integer) 4 in java I don't know. I couldn't find any example (excuse). After all 4 is immutable, I cannot change it's state, I cannot make a 5 out of it.

I could say that in Smalltalk, or ruby, where everything is an object, yada, yada.... But Sun owns Java,
they own the Integer class, so when I call the constructor I should always get the same instance.

and we have the same symptoms (changed behaviour) with booleans:

(false == false)
(new Boolean(false) == new Boolean(false))

WTF !? I can have a million false objects in java. And for What? To be garbage collected, from autoboxing/unboxing? How hard is it to create a pool inside the Boolean class and to return always the FALSE object for Boolean(false) ?

Finally, there is another guy who feels my pain: "Java's new Considered Harmful . The problem stems from memory allocation and polymorphsim". Well actually he feels more pain, but that's his problem :D

Google Hiring Strategy

2006-06-08T16:25:00.000+02:00

Via Peter Norvig, from Google Research Labs: "The Lake Wobegon Strategy".

Java Generics Aren't

2006-06-08T11:54:00.000+02:00

Via Steve Dekorte, from Bruce Eckel:

So [java] generics are really "autocasting."

NUllObject and Visitor

2006-06-06T13:37:00.000+02:00

I have a problem with nulls: they are not objects. I cannot handle a null like any other object: I have to stop, check if it is null or not, and only after that, go on.

The problem is partially solved by throwing (checked) exception: now I have to handle an exception, instead of a null, which might have been propagated, unseen, unheard, through the stack, god-knows-where.

To the rescue comes NullObject: special object, implements the interface, does nothing.
But how do we close the implementation, but still we leave room from improvements: the Visitor: "Visitor lets you define a new operation without changing the classes of the elements on which it operates." (Actually the NullObject should be provided, in my case, by an O/R mapping layer, but I want to extend this object, for my needs). In this case, every "normal" object should do the double dispatching:

accept(Visitor v) { v.visit(this); }

only the NullObject should do nothing:

NullObject.accept(Visitor v) { }

And in C# where we have delegates, the Visitor could be a function/delegate.

-- apparently I am not the first one which thought of NullObject and Visitor.

No Pain, No Gain

2006-05-29T14:46:00.000+02:00

jmockit is cool, but if "hacking" around a clean solution is so easy, when are we going to learn to avoid final classes, and API calls ("My Application Is All API Calls"), when are we going to refactor our code to a clean OO solution: objects represent roles/responsabilities (one-to-one relationship).

If you are climber, you take care of your equipment, you don't ducktape your cord !!!

Play And Learn

2006-05-24T17:29:00.000+02:00

from RubyQuiz you could learn something about the use of continuations and Amb operator for Constraint Processing. This is so much fun !!!

Arc Suggestions

2006-05-24T17:18:00.000+02:00

Paul Graham posted the collected suggestions for (his) "new Lisp" here. Some nice points: concurrency continuations, OO, macros... But I liked:

*** Dan Milstein: Concurrency

One problem which, IMHO, no popular language has come even
close to solving well is allowing a programmer to write multithreaded
code. This is particularly important in server-side programming, one of
Arc's major targets. I've written a good deal of multithreaded Java, and
the threading model is deeply, deeply wrong. As a programmer, there's
almost no one way to write the kind of abstractions which let you forget
about the details. You're always sitting there, trying to work through
complicated scenarios in your head, visualizing the run-time structure of
your program.

I didn't see another way until I read John H. Reppy's "Concurrent
Programming in ML". Instead of building his concurrency constructs around
monitored access to shared memory, he builds them around a message passing
model (both synchronous and asynchronous). What's more, he provides
powerful means of capturing a concurrent pattern in an abstraction which
hides the details.

I highly recommend giving that book a read. Here's an example of some of
what you get (not the abstraction, actually, just the basic power of
message-passing over shared memory). The abstraction facilities are
complex enough that, like Lisp macros, a small example doesn't really
capture their power. I'm in no way familiar with concurrent extensions to
Lisp, so I'm not able to provide the code for how much harder it would be
in CL or Scheme. Assuming they were augmented with a shared memory model
(as Java is), which forces the programmer to deal with synchrnoized access
to memory, I can only imagine it would be significantly more complex.

A producer/consumer buffer. You want a buffer with a finite number of
cells. If a producer tries to add an element to a full buffer, it should
block until a consumer removes an element. If a consumer tries to remove
an element from an empty buffer, it should block until a producer adds
something.

In Concurrent ML:

datatype 'a buffer = BUF of {
insCh : 'a chan,
remCh : 'a chan
}

fun buffer () = let
val insCh = channel() and remCh = channel()

fun loop [] = loop [recv inCh]
| loop buf = if (length buf > maxlen)
then (send (remCh, hd buf); loop (tl, buf))
else (select remCh!(hd buf) => loop (tl buf)
or insCh?x => loop (buf @ [x]))

in
spawn loop;
BUF{
insCh = insCh,
remCh = remCh
}
end

fun insert (BUF{insCh, ...}, v) = send (insCh, v)

fun remove (BUF{remCh, ...}) = recv remCh

---------------

Translated into a Lisp-ish syntax (very easy to do from ML), this would
look something like:

(defstruct buffer
ins-ch
rem-ch)

(defun create-buffer ()
(let ((ins-ch (make-channel))
(rem-ch (make-channel)))
(labels ((loop (buf)
(cond ((null buf)
(loop (list (recv ins-ch))))
((> (length buf) maxlen)
(send rem-ch (car buf))
(loop (cdr buf)))
(t
(select
(rem-ch ! (car buf) => (loop (cdr buf)))
(ins-ch ? x => (loop (append buf (list x)))))))))
(spawn #'loop)
(make-buffer :ins-ch ins-ch :rem-ch rem-ch))))

(defun insert (b v)
(send (buffer-ins-ch b) v))

(defun remove (b)
(recv (buffer-rem-ch b)))

Key things to notice:

1) Language features:

Communication between threads *only* occurs over channel objects, which can
be thought of as one-element queues. In CML, channels are typed, but in
Lisp they probably wouldn't be.

send/recv: synchronous (blocking) communication over the channel. A thread
can attempt to send an object over the channel, and will then block until
another thread does a recv on the channel.

Creating a new thread is done via 'spawn', which takes a function as its
argument. (I can't remember what the signature of that function is
supposed to be -- clearly, in this case it can't be a function of no
arguments, but imagine it to be something like that).

Selective communication: the call to 'select' is one of the very powerful
features. It is like a concurrent conditional -- it simultaneously blocks
on a list of send/recv calls, and executes the associated code with
whichever call returns first (and then drops the rest of the calls). The !
syntax means an attempt to send, the ? means an attempt to receieve. In
both cases, the '=>' connects the associated code to execute. (I haven't
really come up with a Lispy translation of that syntax).

I don't think select could be efficiently implemented without language
support. It requires a sort of 'partial blocking', which is tricky to
implement on top of normal blocking.

2) The Idiom

The buffer is implemented as a separate thread which has connections to two
channels and an internal list to keep track of the elements of the buffer.
This thread runs through a loop forever, taking the current state of the
buffer as its argument, and waiting on the channels in the body of its
code. It is tail-recursive.

Note the absolute lack of any code to deal with synchronization or locking.
You might notice the inefficient list mechanism (that append is going to
get costly in terms of new cons cells), and think that this is only safe
code because of the inefficient functional programming style. In fact,
that's not true! The 'loop' function could desctructively modify a list
(or array) to which only it had access. There would still be no potential
for sync'ing problems, since only that one thread has access to the
internal state of the buffer, and it automatically syncs on the sends and
receieves. It's only handling one request at a time, automatically, so it
can do whatever it wants during that time. It could even be safely
rewritten as a do loop.

What I find so enormously powerful and cool about this is that the
programmer doesn't need to worry about the run-time behavior of the system
at all. At all. The lexical structure of the system captures the run-time
behavior -- if there is mutating code inside of the 'loop' function, you
don't have to look at every other function in the file to see if it is
maybe modifying that same structure. This is akin to the power of lexical
scoping over global scoping. I have never seen concurrent code which lets
me ignore so much.

This really just scratches the surface of Concurrent ML (and doesn't touch
on the higher-level means of abstraction). But I hope it gives a sense of
how worthwhile a language it is to learn from.

3) Issues

I think that channels themselves would be fairly easy to implement on top
of the usual operating system threading constructs (without needing a
thread for each one). However, the style which this message-passing model
promotes can easily lead to a *lot* of threads -- if you have a lot of
buffers, and each of them has its own thread, things can get out of hand
quickly. I believe that Mr. Reppy has explored these very issues in his
implementation of CML.

http://cm.bell-labs.com/cm/cs/who/jhr/sml/cml/

Insofar as I have time (which, realistically, I don't) I would love nothing
more than to play around with implementing CML'ish concurrency constructs
in a new version of Lisp like Arc.

Google engEDU

2006-05-24T17:13:00.000+02:00

A list with "all" (!?) educational videos from google

One More Thing

2006-05-23T17:50:00.000+02:00

I really enjoyed the "Behaviour Driven Development" presentation which Dave Astels did at Google. And here is the "one more thing":

"I always thought that Smalltalk would beat Java, I just didn't know it would be called 'Ruby' when it did." - Kent Beck

Speed Kills

2006-05-22T14:17:00.000+02:00

Found an UncleBob's blog entry:

Speed is the prime destroyer of software systems. In our rush to get something to execute we make mess upon mess. We push and shove the code around in a frenzied effort to make something work. And then, once we achieve the desired behavior, we consider ourselves to be done, and move on to the next urgent task.

Of course we all realize that this is self-destructive behavior. We know that the more we rush the deeper the messes become, and the slower and slower we will go. We know that the only way to keep development going fast is to work carefully, deliberately, and slowly. We know that if we do this, we will keep our systems clean and well structured. We know that clean and well structured systems are easy to change. We know this. Yet we find it difficult to act on this knowledge.

The traditional productivity curve for software projects is a sigmoid. It starts very high, and remains high for the first few months. This is the honeymoon period when the team is cranking. They get lots of good work done, and they get it done quickly. But then the messes begin to build. Those messes slow us down. The productivity curve enters a steep and sudden decline. A few months later productivity has bottomed out and asymptotically approaches zero. This is the phase of the project where it takes forever to do even the simplest thing. This is the phase of the project in which the smallest possible estimate is 3 weeks or more.

As productivity slows to a near halt, the business responds in the only way it can - it adds more people to the project in the forlorn hope of increasing productivity. But these new people, eager to please their employers and peers, continue to rush, thereby adding even more corruption to the existing steaming pile. Productivity continues to decline as the sigmoid approaches zero at the limit.

The solution to this nearly ubiquitous problem is to act upon what we already know. That speed kills projects. Slow down. Do a good job. Keep the code clean. Write unit tests. Write acceptance tests. And watch how fast you go!

Saturday Reading

2006-05-20T22:40:00.000+02:00

actually watching videos, from TechTalk@Google

Peter Seibel, "Practical Common Lisp":

In the late 1920's linguists Edward Sapir and Benjamin Whorf hypothesized that the thoughts we can think are largely determined by the language we speak. In his essay "Beating the Averages" Paul Graham echoed this notion and invented a hypothetical language, Blub, to explain why it is so hard for programmers to appreciate programming language features that aren't present in their own favorite language. Does the Sapir-Whorf hypothesis hold for computer languages? Can you be a great software architect if you only speak Blub? Doesn't Turing equivalence imply that language choice is just another implementation detail? Yes, no, and no says Peter Seibel, language lawyer (admitted, at various times, to the Perl, Java, and Common Lisp bars) and author of the award-winning book _Practical Common Lisp_. In his talk, Peter will discuss how our choices of programming language influences and shapes our pattern languages and the architectures we can, or are likely to, invent. He will also discuss whether it's sufficient to merely broaden your horizons by learning different programming languages or whether you must actually use them.

Dave Astels, "Beyond Test Driven Development: Behaviour Driven Development":

Test Driven Development (TDD) has become quite well known. Many developers are getting benefit from the practice. But it is possible that we can get even more value. A new practice is getting attention these days: Behaviour Driven Development (BDD).

BDD removes all vestiges of testing and instead focuses on specifying the behaviour desired in the system being built. This talk will be focus on Ruby and will introduce a new BDD framework: rSpec. The ideas, however, are language independent

Architects Must Write Code

2006-05-17T10:32:00.000+02:00

I found a blog entry here.

The comments are pretty interesting:

Bell-Labs has a pattern repository: WebInde of OrgPatterns (see ArchitectAlsoImplements, DevelopingInPairs).And my favorite:

Architecture, like war plans, do not last longer than the first minute of the battle: the architect must be in the front line, coding, spiking, re-architecturing...

Working Effectively with Legacy Code III

2006-05-16T13:26:00.000+02:00

Jeremy D. Miller has some notes about the book.

Tip #1: Yes, go buy the book, and put it next to "Refactoring" (you know: beware of code smells)

Tip #2:

On most of the XP projects I've been on we've used an "Idea Wall," just a visible place to write down or post technical improvements. Anytime we have some slack time we start pulling down tasks from the idea wall. Occasionally we're able to outpace either testing or requirements analysis and we aren't really able to push any new code. Whenever that happens we immediately pull things off of the idea wall. One way to judge if your technical debt is piling up is to watch how crowded the idea wall is getting. On the other hand, if something stays on the idea wall for a long time, it might not be that important after all.

Design never stops, not even for an older codebase

nice

2006-05-11T17:33:00.000+02:00

Virtual Street Reality

Martin Fowler evaluates Ruby

2006-05-11T16:49:00.000+02:00

here:

It's still early days yet, but I now have a handful of project experiences to draw on. So far the results are firmly in favor of Ruby. When I ask the question "do you think you're significantly more productive in Ruby rather than Java/c#", each time I've got a strong 'yes'. This is enough for me to start saying that for a suitable project, you should give Ruby a spin. Which, of course, only leaves open the small question of what counts as 'suitable'.

Is Smalltalk (sorry, I meant ruby) having a coming back?

Lambda the Ultimate - thread

2006-05-10T17:30:00.000+02:00

What do you believe about Programming Languages (that you can't prove (yet))?

Interesting thread.You can find some nice gems, in the flame-war dirt.

Should Mock Objects be considered harmful?

2006-05-10T12:44:00.000+02:00

Robert Collins asks the question:

Should Mock Objects be considered harmful? As an optimisation for test suites they are convenient, but they mean you are not testing against the something which can be verified to behave as the concrete interface is meant to, which can lead to Interface Skew.

Let's says we have an object A which uses an object B. In OO A and B represent roles: object A does something in collaboration with B. A behaves "right" only if B behaves "right". So we have a behaviour contract between A and B. This normally represented by some unit-tests for the B role which specify its behaviour. Based on that, we can test A: we "mock" the B role, and see how A reacts. If we want to keep our implementation clean, A knows nothing about B implmentation, it knows only about its behaviour. (B is an interface, or A and B are implemented in a dynamic language).

Once we have tested B's behaviour and A's behaviour they "should" work together without errors. This doesn't happen: usually B is not throughly tested, the behviour contract is broken. for this case we should have integration-tests: A and B play nicely together.

Testing.Kata: unit-test role B, unit-test role A, integration test A and B.

Getters And Setters are Evil

2006-05-08T15:49:00.000+02:00

Setters are evil because they allow you to have inconsistent objects, which they cannot work until they have set their collaborators (see PicoContainer/Good Citizen).

Getters are evil because they allow you to extract the data from the object, instead of putting the action where the data is. (see violating encapsulation, or Martin Fowler's "GetterEradicator").

So everything goes round and back to Allen Holub: "Why getter and setter methods are evil".

Violating Encapsulation

2006-05-04T14:27:00.000+02:00

Dave Astels blogs about it.

Something I see all the time, on every team I've been involved with, is code like the following (classes are generalized from examples):

MyThing[] things = thingManager.getThingList();
for (int i = 0; i < things.length; i++) {
MyThing thing = things[i];
if (thing.getName().equals(thingName)) {
return thingManager.delete(thing);
}
}

This code is tightly coupled to the implementation of myThing in that it gets the name property, knows that it's a string, etc. This is a classic approach from the old days or procedural programming. It is NOT OO.

How about:

MyThing[] things = thingManager.getThingList();
for (int i = 0; i < things.length; i++) {
MyThing thing = things[i];
if (thing.isNamed(thingName)) {
return thingManager.delete(thing);
}
}

I've seen this procedural approach thousand times. The problem is that a lot of developers think "procedural": they never met smalltalk/lisp with its closures. That's why learning a new programming language is good: you will think different, even if you will never get a chance to use the "newly acquired" programming language.

Startup School

2006-05-04T14:01:00.000+02:00

Paul Graham on "the hardest lessons for startups to learn".

java class loading

2006-05-03T16:36:00.000+02:00

Andrew C. Oliver hates it.

To interface or not to interface

2006-04-30T20:07:00.000+02:00

I've posted some comments on Troy Brumley's blog here . He liked the metaphor interface is a "firewall": we use it in order to isolate "changes": I don't want to be affected by your changes, and you don't want to be affected by my changes.

Actually an interface is a "wall", a very thin layer, which hides implementation details. And we should use is at framework, package and object level. In practice it doesn't happen: we "trust" our object within an package, or within a framework.

An interface defines a "contract": somebody understands this set of messages. Why don't we have interfaces in dynamic languages? Because we don't need this wall, we are always talking to a duck.The implementation is always hidden.The contract resides in the UnitTests.

Qumana

2006-04-30T14:55:00.000+02:00

I tried to download wbloggar, but the site is down. Let's see how is this working...

Powered by Qumana

Before and After Ruby

2006-04-21T09:33:00.000+02:00

found on the "journal of jess".

Also Torsten is wondering here:

What I dont understand is that people complain about Java and start with Ruby right after it.
What if they would take the next step and directly start using Smalltalk. I'm sure they will enjoy the wonderfull world full of objects.

Well I think that Smalltalk environment is too scary for a java developer: no code files, no cvs/subversion, everything is in an image file, etc.

When a java developer plunges in Smalltalk, he has a "What now" moment: everything is there, but he does not know where to start.

Ruby is the "way" to Smalltalk: easier to learn, but OO imperfect (ruby has "syntax" and not everything is an object)

The Quality of Many Eyes

2006-04-18T23:51:00.000+02:00

here:

Linux kernel development model implies that the developers can't directly add their changes to the main code branch, but publish their changes. Other developers can review and provide comments, and, more importantly, there is a dedicated person who reviews all the changes, asks for corrections or clarifications, and finally incorporates the changes into the main code branch. This model is extremely rare in producing commercial software, and in the open source software world only some projects use it. Linux kernel has been using this model from the beginning quite effectively.

Raise your hand: Who's doing code-reviews? Who's doing pair-programming?

saturday reading

2006-04-16T00:15:00.000+02:00

Lisp is Not an Acceptable Lisp
and
Steve is Not an Acceptable Lisper

from reddit.

Smalltalk Flexible Exception Handling

2006-04-14T19:22:00.000+02:00

when *everything* is an object
- via James Robertson

Ruby and Lisp

2006-04-12T10:06:00.000+02:00

found here:

So, Ruby was a Lisp originally, in theory.
Let's call it MatzLisp from now on. ;-)
– Matz

Larry Wall never understood Lisp
Guido Van Rossum once read a book on Lisp
Yukihiro Matsumoto once read a book on Lisp and understood some of it
– Keith Playford

Code Generation

2006-04-11T12:15:00.000+02:00

Bill Veners here
Dave Thomas here

I don't like code generation. It feels to me as a step backwards and not forwards to a solution.

Instead of saying: "let's write a class/object with this functionality", we say: "let's write another class and a template, to generate a file, which compiled, gives us the needed object and functionality". Hmmm....

If the algorithm is so generic that we can express it in a template/file generator, why can't we write a class which through reflection generates the needed functionality?

How do you unit-test generated files? Do you test the output code, or do you test the new object? If you test the created object (the new functionality), than you have one additional step in unit-testing: compilation.

My point is that:

Ruby is dynamic enough to let be do what I want without leaving the language

Smalltalk is more "extreme" than ruby. There you don't have source files !!!

Java/C# should be "dynamic" too. I think they already are, through reflection and dynamic code generation, almost as flexible/generic as Ruby. But the developers are always scare of the performance loss. So they prefer an "immature" optimization, instead of a "clean" solution.

SPA 2006

2006-04-10T09:30:00.000+02:00

James Robertson blogs about spa 2006.

chaos = order

2006-04-05T14:49:00.000+02:00

hmmm