The Day My iPod Became Just Another Appliance

This is today as my iPod officially joined the rank of my electronic appliances that need to be reset from time to time. The screen had a bizarre circular shift of 15% to the left, showing part of the left side of the screen on its right part. Everything was frozen with the backlight on.

For the record, so far only my oven and my dishwasher needed a little reboot from time to time. Now they are three in the club! Interestingly, they are all reset using an odd combination of front panel keys. Appliance makers do what they can with what they have, but only a few keys are needed for this maintenance operation (look on Windows: Ctrl + Alt + Del do the trick).

My wild guesses concerning the cause of failure for these diverse but similar software controlled appliances:

• Oven: heat excess in the control panel,
• Dishwasher: humidity too high in the control panel,
• iPod: overall system too cold as it stayed overnight in my entrance.

Oh the true happiness of modernity.

Busy Buzz For Lazy Bees

After Sony, who really screwed up their buzz marketing for the PSP3, Microsoft does the same stuff for Vista.

Mmmh, what could be the reason for these two companies (not the tiniest or dumbest on earth) to miserably fail a marketing campaign? What can make them so desperate to have people talk about their glimmering new products?

The answer might be in the common points between the PSP3 and Vista: expensive, unattractive, deja vu.

Do you find I am tough? Well, let's get tougher: guys, next time, ask a buzz specialist to advise you, else drop the idea. A failed campaign is not something you want to experiment. Again.

NxBRE 3.1.0Beta1 Is Out

I have just posted a beta release of NxBRE 3.1.0, which is mainly intended for those interested in testing one of these two new features:

• A regular expression matcher operator has been added to the Flow Engine (which is also available in the Inference Engine),
  
  
• The implication scheduling in the agenda has been improved to limitate the number of fired implications, hence yield to better performances with large rule bases.
  

There is also a preview implementation of the RuleML 0.91 Naf Datalog adapter. So far, this implementation does not support the cool features of the new version of RuleML (like multiple named rulebases in one rule file or retract operations), then it is not worth using it. Hey, it's a beta after all!

Unexpected Performances Can Occur (Sometimes)

I just can not believe the message Khalid Khalil has just posted on NxBRE's open discussion forum!

Using object pooling, Khalid has reached a throughput of 2000 requests per second with the Flow Engine, one of the two engine flavors available in NxBRE. It is far beyond the performances I was expecting for my tiny business rules engine: way too cool!

Behind Closed Doors

My friend Stuart Hogue, Strategy Director of frog design inc. in NYC, has published a pretty interesting article about hyper exclusive social networks.

I find significant that his article comes at a time when Metcalfe's law is under criticisms. In different replies to IEEE Spectum, Robert Metcalfe stands by his law stating that the value of a network is equal to the square of the number of users. His opponents are mainly saying that: "The fundamental flaw underlying (...) Metcalfe's (...) law is in the assignment of equal value to all connections or all groups".

So the key and maybe the mathematical justification of hyper exclusive social networks might lie in this principle: not all connections have similar value, hence dedicated selective network will maximize their value by selecting only people who will engage in high value relationships.

In practice, it is true that I have quickly dropped Orkut and Friendster to favor the more selective LinkedIn network. I am still waiting to see returns from the highly selective Blue Chip Expert network, to which I have recently been invited. If you visit their homepage, you will appreciate the main picture: a closed door that looks very serious!

Is the true value of social networks waiting behind closed doors?

All I'm askin'

A recent and insightful Computer article from Stephen Jenkins (Concerning Interruptions) led me to rethink my authoritative position on working with headsets (read Kindly Kill That Headset).

I think the crux of the problem is not about knowing if programmers need isolation to avoid frustrating and concentration killing interruptions (this is granted), but actually respecting this need for isolation.

If everybody would respect this need by refraining from asking out-of-context questions (the most brain resources consuming ones) and by saving interruptions for better times (like planned meetings, lunch time or pit stops), programmers would need less to stick headsets on their ears and would therefore be more available for direct in-context questions from fellow team members.

Aretha was right: it's all about respect!

Proxy That Proxy

One day or the other, you will wake up with the bold idea of deploying several EAR files in your JBoss 4.0.x Application Server. Why bold? Because it is almost sure that:

• you will need to isolate the class loaders of the EAR files (for example to load different versions of the same class in the different applications),
  
  
• you will want EJBs to communicate between the different EAR files.

It will then be the day you will meet the often challenged allways challenging Unified Class Loader (a disciple of Dolph Lundgren) and its scoped deployment configuration options, get a few ClassCastException and finally opt for switching all your EJB calls to the "by value" semantics. Then you will start drinking to forget about not only the amount of pain involved in the process, but also the loss of performance induced by passing all parameters by value.

If your EJBs only take and return classes from the JDK, rejoice! There is hope for you! Indeed, you can remove this problematic casting:

HomeInterface hi = (HomeInterface) lookedUpHome;

which generates exceptions because the looked-up interface has been loaded by a different class loader than the one you cast to, by using a dynamic proxy that directly implements the business interface of your remote EJB.

To simplify this, you can leverage Spring Framework's SimpleRemoteStatelessSessionProxyFactoryBean, which will lookup your EJB, create it for you and return a dynamic proxy that implements the business methods. By this mean, the need for casting is removed.

Of course, as I said before, this only works if you exchange primitives or objects from the JDK (because they are loaded from a common hierachy of class loaders that includes the system class loader). But it is a viable alternative to keep in mind...

Hetero-Genius

In the November issue of Computer, there is an interesting article from David Alan Grier, titled "The Benefits of Being Different", which talks about a subject I am currently particularly sensitive to: the dangers of uniformity in IT systems.

My reflection started a few weeks ago when IEEE Spectrum published a seminal article (Shrink the Targets). Indeed, after the rise and establishment of Microsoft supremacy on personal computers, we are in a great need of diversity because homogeneity has many hidden catches we have to pay one day or the other.

Homogeneity makes IT systems fragile because the same flaw or weakness is reproduced on hundred of thousands (if not millions) of machines, making all of them sensitive to a well targeted attack. The discussions about the superiority of a particular OS or tool (like a browser) that end up with plans for the worldwide replacement of one by another, are childish and futile. All these pieces of software have reached such a great level of quality that you can not select them on pure technical basis. So there is no supremacy to target, as replacing one domination by another one, would leave us with a situation as fragile as before. We must see the advent of non-geeky tribes who will recognize themselves in the usage of a particular combination of OS and tools, who will be empowered so they can assume their choice without being exposed to nasty technical problems or being pointed as originals.

Homogeneity carries another risk: the supremacy of a particular tool or vendor always induce the usage of proprietary file formats. Being locked-in a vendor tool because its features are so above the competitors is nothing bad: it benefits the user and, moreover, it never lasts. Competition always catch up. Then open source tools come in, disrupt the model and force everybody to think harder about increasing the quality of the tools and the services that gravitate around them. But being locked-in because your own personal data are locked-in a proprietary file format is nothing that can be accepted anymore. Diversity forces vendors and tool makers to enable data exchange, freeing the content that was held captive.

In a time when our most precious material assets are mainly digital (does not this feel like a quasi oxymoron?), homogeneity is no longer an issue. Let us be hetero-genius!

Mapping panacea

To paraphrase the golden hammer saying, I have the feeling that nowadays, because you have object mapping frameworks, everything looks like an object!

What is it with developers who seem to get infatuated with such tools? Does everything need to be mapped to objects? Of course not! Here two recent cases that kind of drive me nuts:

• Why reading XML files when I can map them to objects? Well, maybe because what you are looking for is actually... data. So please save your application from the miseries of JAXB 1.x (which does not even care to mandate a clear concurrent behavior in its API) and use SAX, XPath or any other efficient XML reading tool!
  
  
• Why querying the database when I can map it to objects? Well, maybe because you are performing batch operations that are mainly data retrieving oriented and the overhead your O/R mapper will add plus its memory consumption will put your virtual machine on its knees. So please take the fast lane!
  

End Of Rant.

Feeding the White Rabbit

So now that, for my birthday, I got my own Nabaztag, a white WIFI rabbit that can move its ears, display light signals on 5 RGB LEDs and play digitized sounds, the big question is: how to keep the funny bunny happy?

I guess by feeding it properly.

The default services offered for free by the vendor are pretty basic: weather, stock exchange, email account watcher... And the coolest: rabbit Tai Chi! Hey, what do you expect: they are free, right?

Since the animal has an HTTP based API that allows controlling its ears, lights and sounds (including a nice TTS feature), I do not see any reason to subscribe for the advanced paying services! It will be much more fun to write services for it!

So I came with the first one today, an appetizer for the white rabbit: the service connects to the GMail accounts of the family members and builds a vocal summary of the emails waiting to be read. And that's already cool ;-)

There are many other funny things to do: a service that would report the daily statistics of my open source projects could be fun. Another one that would connect Maven to the animal and that color the poor thing in red whenever a build is broken or unit tests are not A-OK, would be terrific.

You might wonder what is the moniker of this new family member? Knowing that if you know his name, you can make it speak and that the thingy sits in the middle of our living room, where any sentence rated above G are not welcome, I would say that we will call it "secret". For now.

Centralized Configuration Management for JBoss

NOTE 12-MAY-2009: This particular post is driving a lot of traffic on my blog. Even if the JBoss Properties Service is still worth using, nowadays, I would not advocate the management of properties in SVN, as it is problematic security wise and requires the need of an HA repository. I would rather embed default properties values in my project and allow the overriding of some values (passwords...) via a simple file created in a well known location on the server.

Managing configuration of application servers and the applications they host in a centralized and rationalized way is a requirement for any corporate doing its own hosting. Not only configuration differs between server instances and the applications they host but also between the different environments they exist in (ie. development, integration, QA, pre-production and production).

JBoss 4 user guide shows how to leverage the Service Binding Manager to handle server configuration in a central way. This is a great approach but I think we can go further by leveraging Java system properties in conjunction with two other features of the server: the Properties Service and the fact that JBoss parses all XML configuration files (including J2EE deployment descriptors) and resolves ${references} to system properties. Moreover, if you use the Spring Framework in your application, you can also leverage its PropertyPlaceholderConfigurer to retrieve configuration information from Java system properties.

As shown above, the main idea is to store configuration information as properties files in a Subversion repository and have the different JBoss Application Server retrieve these configurations through HTTP and thanks to this kind of configuration of the Properties Service (in properties-service.xml):

<br /><attribute name="URLList"> http://intranet.company.org/svn/*checkout*/jbprops/trunk/${some.discriminant}/system.properties<br /></attribute><br />

These system properties will then be loaded at JBoss startup time (or on any modification, like a touch, of the properties-service.xml file) and will be available for use in many different places like:

• XML server configuration files that configure ports and host names (for web server, invokers, JNDI tree...),
  
  
• J2EE deployment descriptors to avoid hardcoding of parameters (like user name and password used to connect an MDB to a remote JMS destination),
  
  
• application parameters provided they are read from Java system properties (which is easy and nice to do if you use Spring).
  

Of course, there should be a way to find the right configuration in the SVN repository. As you surely have noticed it in the previous configuration fragment, since the Properties Service is configured by an XML that is parsed, it is possible to use a system property to configure it (now this is eating your own dog food!). The system property used to select the proper configuration can be either ad hoc (a custom one added in the startup script or run.conf of the particular JBoss instance) or standardized (for example, if each JBoss instance is run with a specific user, the system property can then be user.name).

Another interesting feature of the Properties Service to leverage is the fact you can provide a list of URLs: all the properties will be loaded from these URLs, the latest ones having the precedence on the first ones. This can be used to organize configuration in a hierarchy, with global settings, server specific settings and application level settings loaded from a common place and mixed together in the Java system properties. Here is an example of such a configuration:

<br /><attribute name="URLList"><br />http://intranet.company.org/svn/*checkout*/jbprops/trunk/${some.discriminant}/system.properties,<br />http://intranet.company.org/svn/*checkout*/jbprops/trunk/serverA/system.properties,<br />http://intranet.company.org/svn/*checkout*/jbprops/trunk/global/system.properties<br /></attribute><br />

As you can see, not only is JBoss a versatile application server, but it is also an extremely configurable one that can be easily tuned to fit the needs of large companies with complex deployment constraints.

New Position: File Name Manager at Oracle Corp.

Goals:

• Rename Oracle JDBC driver file names so they actually differ between different versions,
  
  
• If possible, improve the manifest files so there is more difference than the "Implementation-Time" attribute between two different versions.
  

Required skills:

• A true desire to help developer teams and production departments making sense of the different driver releases.
  

Disclaimer for the slow brained: This is a hoax. I took the decision to create this position simply because someone had to do something.

To fully enjoy this post, go to these pages (9i, 10g & 10gR2) and download the different versions of the JDBC driver: you can not miss them, they are all named ojdbc14.jar. You can then try your skills by figuring out sensible names for these files!

A 16 Months Iteration

I have finally been able to release a first alpha version of jinFORM, 16 months after the project started. The title is voluntarily provocative: it was not an iteration but a slow maturation!

Why did it take so long? As explained in jinFORM news, part of the time has been spent waiting for a presentation server able to render some much needed features of XForms 1.1. Initially, Chiba was targeted as the presentation server but testing and experiments have finally pushed the project to use Orbeon Presentation Server, which offers a more stable XHTML + JavaScript rendering, a better compliance to standards (XForms, XML Pipelines...) and the much needed XForms 1.1 features mentioned before.

So, what is jinFORM 0.1.0 worth? Not much for production: you can only fill simple forms with repeating sections, but without computation or logic. The only submission that is currently supported is for saving the XML instance built by the form behind the scene.

Then, was it worth the effort and why should anyone care about this project? Well, anyone with a slight interest in the intimates of Microsoft Infopath file format (aka XSN) should be interested to see how jinFORM transforms this proprietary form definition to XForms.

Because an XSN file is simply a CAB stuffed with XML, XSL and extra files, described with a documented manifest, groking its content is fairly easy. Doing anything with it is another thing. Take the XSL for view rendering (usually named view1.xsl) that is generated by Infopath. Because this XSL relies on implicit MSXML objects for supporting many extension function calls, jinFORM has to pre-chew it and implement similar functions in order for anything to work.

When designing this XSL, Microsoft, of course, had anything but elegance or portability in mind. It is cluttered with prescriptive commands like xsl:for-each, traps like testing for the existence of a function and using another one and oddities like using a function to retrieve the current document on which this XSL applies. Surprising approach from Microsoft? After they love functions and procedural programming: why would they embrace the template concept that is underlying XSL transformation?

There are still many things to add in jinFORM to make it really usable but it is a good first step. Foundations have been laid, now let's build on it!

Vive le ROI!

Please excuse my French but I could not resist the pun!

Agile proponents, including me, often use an improved return on investment (ROI) as an argument for avoiding traditional software development methodologies in favor of agility. The scope considered for this ROI usually concerns the financial investment made for the particular project and the result the stakeholders are expecting from it.

There is another ROI that I think is important to consider and that is also heavily impacted by the adoption of agile practices: the intellectual return on investment.

Indeed, developers involve a lot of themselves when working on a software project. The most obvious investment is the time spent at their desks but there is also a tremendous part of the job that is done after hours, outside of the office.

Ever zombie drove from work while mentally exploring the arcane of a new system's architecture? Ever had the light bulb that turns on while revisiting the latest written code under your shower? If yes, you probably see what I mean when I say that software development is pretty mind invasive.

Pecuniary compensation is often considered as the just compensation for this invasion: I pretend this is not enough. Money only buys time. The intellectual investment must be compensated by a specific ROI. What could be this specific ROI?

From my experience:

satisfaction in the quality of work

a sustainable elevated productivity and

an increased confidence in the system that is under construction

 

is a combination that forms a good intellectual ROI.

 

Knowing that this is the kind of conditions that agile methodologies can create, it can be used as an argument to sell them to programmers, who can sometimes get convinced of the benefits for their company (or the project stakeholders or their managers) but are not always convinced of the benefits for themselves.

 

The Roots of a Bias

A few weeks ago, Kubuntu released an upgrade that crashed the OS: this was a major goof and they promised they will never do it again. When my machine refused to boot after the upgrade, I frowned, grumbled, downgraded the faulty package and kept going until a new update restores the situation a few hours later.

Now, when I work on Microsoft Windows, I almost instantly go fuming and ballistic for the smallest glitch. Should the Explorer freeze for ages because I clicked on a network resource, I see red. Should I have to defragment the mess that has become my drive after a few months of work, there is smell of a burning martyr in the air.

Could I be somewhat biased against Windows? This would be a subject of shame because any prejudice is a reduction of reality that leads to unfair behavior. Yuck! Nothing to be proud of...

What could be the roots of such a bias? I do not particularly care about Windows supremacy on the desktop computers (except that such a global uniformity is a security problem), nor about the personal fortune of such Microsoft big hat. In fact, Windows XP Professional is probably the best Microsoft operating system I have ever used, so where is this wrath coming from?

Doing a little introspection and exploring the depths of my psyche, I think I have found out the event that triggered this anger: it was in the mid-90s so this is surely a case of unfinished business!

My first application that went into production was a modem hub for the Belgian branches of a pharmaceutical distributor. The application was written in C and, the most important factor, developed and executed on OS/2. Coming from Atari TOS, I really fell in love with OS/2!

Then I finished school and started to work in the professional world, dub it, the world of Windows for Workgroups 3.11. Coming from a world of sessions, processes and threads, WfW seemed to me like a castle of cards waiting for the faintest breath of wind to fall down in pieces. And it was. Rebooting was a big part of a developer's activity of this time.

When Windows 95 started to be announced, I was certain the industry will make the right decision based on the misery of WfW and move to OS/2 Warp. Yes, I was so naive to believe that technical soundness and robustness would help reverting the trend towards Windows to what I considered a better professional operating system.

History proved me deeply wrong and left me frustrated for the many years it took Microsoft to build an operating system as stable and usable as OS/2. I think this old frustration that has turned into bitterness is the root of my bias. I need to work on it and restore pacified relationships with Windows. And I will keep using Kubuntu as my main operating system, just in case... A relapse is always possible!

Gnosis of Diagnosis

For a few days, I have been procrastinating writing about the ill distribution of debugging skills among developers, then I have read a letter sent to Computer and published in the September 2006 issue under the evocative title of "Deskilling Software Engineering".

The author states that "diagnosing a problem remains an art and requires skill". I like the fact that he evokes art because there is truly a part of instinct in the difficult task of figuring out why a system fails or refuses to do what it is supposed to. Instinct is hard to define and quantify, so what else a developer would need to be successful when chasing bugs?

From my experience, I have retained what I consider the three topmost traits that helps in the art of diagnosis:

• Systematic thinking: software being complex systems, they take a lot of various inputs (configuration, data, user entries...) and turn them into various outputs, with usually one being the desired one. Modifying too much inputs at the same time does not allow to figure out the impact of each modification on the output. Programmers without rigor or a varnish of scientific method will often try to modify many parameters at the same time, which will ruin any attempt to empirically figure out what is causing the issue.
  
  
• Pugnacity and thoroughness: some problems are hard to tackle, especially the ones that require a long setup time before being able to test what is happening (think of rebooting a server to release a particular resource before testing). Others require to be able to read through extensive traces without panicking! I have seen many non-rookie developers unable to read a stack trace and I understand why: it is intimidating and requires an effort of will to delve into.
  
  
• Hands-on experience: as the saying goes "once bitten twice shy", nothing replaces years of experience, dub it, the numerous blows and slaps you get creating then solving bug after bug. With the current trend of devaluing hands-on experience in favor of managerial skills, hourly rates for programmers are a clear signal that there is nothing good in keeping writing code. Hence when someone gets good at its job of writing code, he is kindly asked to stop doing it and moved to a more desirable (and rewarded) position, leaving projects with rookies who will have to go through years of blows and slaps to become efficient bug killers.
  

Off course, these traits can help in other software development activities as well. But their lack always impairs any diagnosis endeavor.

The price of common sense

In "Agile Software Development with Scrum", Ken Schwaber stated that:

 

"Scrum demands the liberal application of common sense".

 

I think this applies to any agile methodology: common sense is a driving force for any practice that relies on empirical management and self-organizing teams.

 

Now, I have just read "Unsystematic Engineering", an IEEE Spectrum article where Robert W. Lucky dares saying out loud what everybody knows:

 

"(...) systems engineering is often based on experience and common sense, and we know where common sense fits in the hierarchy of things that justify a high salary."

 

Okay, we all work for the beauty and love of our craftsmanship and not for the bottom line, but is not this pattern of under-valuing the qualities we have learnt to be the right ones, something that gets harder and harder to accept?

 

So, what should be the true price of common sense? Could not it be evaluated by measuring the cost of projects that failed because of a lack of it?

 

Dependable Dependencies

With the advent of human friendly build platforms like Maven 2 or Buildix, I am expecting to see improvements in the way programmers manage their dependencies. Of course, I might be too candid but proper tools can give enough incentive for developers to consider dealing with their dependencies in a less hip-shooter style and therefore benefit from more predictable, reproducible and automated build sequences.

Classical patterns of classpath quagmire I have noticed include:

• Deployment of libraries needed only at compile time: this is the usual rookie error, where you typically end up with things like servlet.jar in WEB-INF/lib. A little explanation is usually enough for this to not happen again.
  
  
• Deployment of libraries needed only at unit test time: less harmful than the previous error, it is simply disturbing to have applications deployed with unit test and mock libraries merrily packaged altogether.
  
  
• Deployment of platform libraries in excess or in different versions: this is typically the case for applications that are designed to be deployed on "any" J2EE compliant server. Very often, it will contain libraries that are already present in the server, sometimes in different versions, which will lead to hard to track issues. This is usually done just in case your particular server does not support a particular version of a J2EE sub-component, and, unless you run on the exact same server the vendor is using, you will typically end-up shaving a dozen of useless jar files off the libraries' folder!

To my sense, when it comes to dependencies, a NoClassDefFoundError is much better than a ClassCastException, or, in other words, too little is better than too much. It is indeed easier to figure out what are the missing libraries rather than what are the version conflicting ones.

Anyway, as build tools help us to formalize what is the role of each of the library used by our projects (compile? test? deploy?), we can expect to see better handled and dependable dependencies around us in the near future.

A Simple Pattern for Prevayler

While implementing Prevayler in a cool project I will detail in a near future, I of course met the need of doing it in a way that will allow me to unit test my prevalent system independently from the persistence mechanism. This would allow me to exercise all the code implied in the business logic of my domain without actually bootstrapping the prevalence engine.

I came to the simple pattern shown below:

The IDomainManager interface exposes all the domain related methods. The MemoryDomainManager implements this interface and contains all the serializable data: it is the actual root of the prevalent system and the only object to thoroughly unit test.

The PrevalentDomainManager is merely an empty shell that delegates all calls to the MemoryDomainManager, wrapped in Prevayler transactions. It also contains the basic code to bootstrap the persistence engine.

Note that the MemoryDomainManager object does not implement any synchronization mechanism: Prevayler, thanks to its support for transactions, blissfully takes care of this.

Having unified MemoryDomainManager and PrevalentDomainManager behind the IDomainManager interface naturally allows to unit test all the components relying on the domain objects without using actual persistence and to deploy the productive application by designing it to use the prevalent implementation of the said interface.

So, how about dropping your prejudices and jump head first into the jolly world of Prevayler?

________
* For those of you who wonder, Prevayler is a purely object oriented persistence framework that offers a solid alternative to the now classic "RDBMS+O/R mapping framework" pair. It received a well deserved Productivity Award in 2004.

Surfing the expansion wave

Software development is a very demanding professional field of activity. Anyone who caresses the desire to make a living of it should be very aware of this in order to take a well informed decision before plunging into this business. It is sometimes best to decline the red pill and take the blue one.

I vividly remember my 1989 student project leader who, after introducing the exhilarating objectives of the Celesstin research project that was done in cooperation with IBM and Dassault, opened the door and took the time to explain the challenges of software development: there would be no shame to leave the room before the project started, but after, it would be a world of pain for everyone. I wish all computer science teachers could do such an introductory speech: many people would have a better fitted job and would stop making passionate developers mad (on the other hand, what would then happen to the Daily WTF?).

For me, the most demanding aspect of our job is to stay current with what is going on out there. Software development, unlike most of jobs, has a constantly growing body of knowledge. All the difficulty is to stay somewhere close to the border of this constantly expanding universe. This is an exhausting and sometimes frustrating endeavor:

• exhausting because on top of our daily paid-for activities, we have to explore this growing universe, very often using our free time and what is left of our brain power after a long day of work to read, download, test, wander and sometimes wade in terra incognita that others have pioneered for us,
  
  
• frustrating because it expands in all directions and it is therefore virtually impossible to stay close to the border all around this sphere of knowledge: everyday brings its wealth of new technologies, new releases, new frameworks, new tools, new methodologies, new fundamental discoveries... We can only chose an area we feel comfortable with and surf the expansion wave as much as we can.
  

Once you have accepted that every morning you will wake up, the universe will have expanded a little and the border will have moved further so it will be another day of learning and discovery, life will be easier. No more dreams of "being at the top" but, instead, the simple path of the craftsman who learns and improves everyday and everyday realizes that the amount of things to learn and practices to improve has grown a littler bigger than the day before.

Now what is the fuel for doing this, if not passion?