Which kind of stuff every programmer should do

I think every programmer should:

- write a language and a compiler for it

He had to study a bunch of language concepts, automata theory, syntax and features trade-offs, etc.

- write a game

He would gain a good AI notion, multithread programming, really interactiveness, performance skills.

- write an OS

He would face low level programming, concurrency, scheduling, memory management, hardware interface.

- write a DBMS

Data structure and algorithms, SQL parsing, optimizing, caching strategies.

Each of them using a distinct language from different paradigms. Of course your software has not to be new Ruby, Linux, Oracle or Half Life. But it really has to be serious. You have to build the best software you can and improve it everyday as an exercise. Though, your regular job is gonna be a bit easier.

And you, what’s your suggestion?

No, I had never write any of them yet. Yeap, it’s a shame. But I am going to start it this year.

Fluent interfaces

At a recent project, we need to write code for extract some data from another system. Data come like a fixed-length text file. It’s not a file at all but for sake of simplicity let it be. It’s not a new problem to be solved. Alias, since more than ten years ago at same company programmers have to deal with few hundreds of different file formats everyday. They are used to do it this way:

...

Customer c = new Customer();

c.setName = outputString.substring(10,70);

c.setAge = Integer.parseInt(outputString.substring(80,82));

...

Some fields need to be trimmed. Some need to be formatted, like a date for example. So, it’s not hard to guess how many code has been repeated. And come on, it’s not human-friendly put a lot of x.substring in all the code.Then, I wrote this way:

Definition File Example

...

output()

.field("name",60)

.field("age", 2).integer().valid(new RangeValidator(18,65))

.field("customer_since", 8).date()

.field("tags",30).occurs(10)

;

...

Of course,

...

.field("age", 2).integer().valid(new RangeValidator(18,65))

...

can be more fluent:

...

.field("age", 2).integer().valid().range(18,65)

...

But it requires change in API at each new validator. It’s a trade-off. At a range, for example, I prefer second way. In case of MyJustOnceUsedFancyValidator, I prefer first one. My API has both cases.Once it was defined, you could invoke that and get a Map:

...

Map output = myDefs.connect(inputparams);

Customer c = new Customer();

c.setName((String)output.get("name")); //No, we don't have JDK5

c.setCustomerSince((LocalDate)output.get("customer_since"));

c.setAge(Integer.parseInt((String)output.get("age")));

...

Now, definitions are separated from client code. Extracting code are isolated too. This code need to be wrote just once. Client don’t know what is going behind the scenes. It sees just a Map. Abstraction was improved. Code is now a bit more human-friendly.Better?

Hello World!

This is my hello world to blogosphere. I will write my thoughts about software and everything else just here. I always want to know your opinion about. So, I will be glad for that. And, as English is not my first language, grammars tips are welcome too. Then, let’s blog.