michi bloggt!

I must admit, that i tend to neglect looking at other systems/platforms/applications when it comes to programming. Not that i am totally blind and not aware of whats going on, but I am just not the type of guy who dives into some esoteric languages in his spare time, or who evaluates 3 different programming frameworks on a foggy november sunday. Well, but i guess, i SHOULD. Fortunately i am surrounded by smart people (in the blogosphere, as well as in the company) who actually do stuff like that, and also share their opinions openly.

Last week a highly interesting discussion was going on the helma-dev mailing list (helma-dev), last friday most of the company (incl myself) attended a presentation by mihi and ferrari on Ruby on Rails, and yesterday i finally took my time for catching up with some reading that i should have done earlier ([smi], [ferrari], [smi again], [Jürg Lehni on 'Helma vs Rails'], [wikipedia on 'Rapid Application Development'], [wikipedia on 'Agile Software Development']). Well, it seems about the right time for a (self-)reflective look at how programming can be improved, and for me to write down some thoughts and experiences.

Knallgrau's development team has seen a tremendous growth over the last year. But not just the number of projects were increasing, but also the size of projects tended to get bigger. Let's pretend that there is this big project 'XYZ' we are working on :-), having five/six people write code for that same project is just a whole different sport than we were used to. (Readers in charge of development-teams bigger than 10 or 100 are allowed to smirk on such tiny numbers.) 'Programming in the large' is the name of the game!

Lessons we learned from project XYZ (for Helma projects in general):

• Separation, separation, separation (also known as 'modularity'):
  The first thing we did, before starting with the project, was to make extensive use of Helma's (back then) new repository logic, which allowed to separate code into several repositories/directories. I would go that far and claim, that without this separation the project could have never been completed. We got helma-libraries, java-libraries, core logic, modules (modBloggerApi, modJCaptcha, and 18 others), custom logic and custom modules. Next time, we would probably go even further and also separate skins and logic into different repositories as it is done in gobi, and also (finally) start a knallgrau-library.
  Separation on the other hand will lead to dependencies of the components. Avoid them as much as you can!
  Seperation also includes separating actions (=web-accessible functions) and model logic. Helma allows you to put all your logic into actions, but keep them separated.
• Readable code (also known as 'maintainability'):
  
  • Stick to the coding conventions (resp. write down coding conventions before you even start :-) [see here for a good start for JavaScript])!
  • Define a coding framework
    After having taught Helma to about ten people this year, the biggest struggle for Newbies is imo the freedom of choice of how to do things. Especially when it comes to writing a new application from scratch. Conventions over Configuration is a good claim, but you don't necessarily need Ruby On Rails to accomplish this. Just write them down.
  • Use self-explaining names for everything (methods, properties,..)! Don't be afraid of being verbose.
  • Write JavaDocs and inline comments!
  • Break up your logic into small pieces, 'cause methods with more than 50 lines are just not readable anymore.
  • Also the importance of "Don't repeat yourself" and of "lean coding" can't be stressed enough. The less code it takes you to perform a certain task the better it is (sthg that should not be taken too literally).
• Use the power of inheritance
  In project XYZ we ended up with 82 (!) defined prototypes. But 68 of these are simply thin extension of the main 14 prototypes. Using inheritance seems to contradict readability, but cuts down the number of code lines. And if you understand the main prototypes and their purpose, you already grasp the whole application. The other downside of this is, that your Helma application will get cluttered with directory folders.

Mmh, i am not too content with my structuring of the above list. It turned out a bit random, and a lot of the things mentioned are correlated to each other, and some of them also contradict each other. But i hope you get some ideas out of it. Others already have put by far more thought into these problems, and i will just bluntly point to the core elements of Rapid Application Development, and state that 'this is the way, it should be'. Dooh! (Time-to-market and iterative development are imo still getting more and more important.)

Discussions on the future of Helma development are right now going on, and it's very interesting following these discussions. The incredibly fast rise of Ruby on Rails certainly leads to the question for 'what is in for me (resp. Helma)?'.

My wish list is sthg like the following:

1. Try to be even more JS standard compatible then before. Use common JavaScript syntax for defining prototypes, and their type-mappings.
2. Smarter JavaDoc generation of applications, that can be triggered as ant-task.
3. Automated (my)sql-script generation (including indexes).
4. Move all configurations away from apps.properties
5. Allow a pluggable templating engine (in order to allow for example Velocity to be used)
6. Establish 3 environments (development/testing/production) similar to RoR
7. Establish testing as an integral part of development
8. Finish and maintain documentation! (oops, thats actually my task anyways)
9. ...i definitely forgot sthg here...

Common Framework for how Helma apps should be written? It would be great if the Helma community could decide on one, but i am not too optimistic that this will happen anytime soon. Hopefully i will be proven wrong.

An IDE for Helma? This is sthg that has been asked for over and over again. But imo we might get this for free at some point, if we become more 'JavaScript compliant'. JavaScript is getting more and more attention, and code written in JavaScript becomes more complex. Tools will appear to handle this complexity, and hopefully these are then easily adaptable for Helma.

So, thats about five times longer then the longest blog entry i have ever written before. And i better hit the 'save'-button now, before i change my mind again. Time to market! Also for blog-entries :-)