Ars Subtilior

Resurrection

It's been more than three and a half years since my last blog post here. 

The last message was about the birth of our son, now he's already three and a half and going to the kindergarten. A year after his birth I started working part-time, and since a little more than one year I'm self employed. We have moved to our new house. A lot of things have changed.

Now that is absolutly no reason not to blog. All those changes would have been wonderful reasons to do fantastic blog posts! I was just too lazy, to occupied with doing busy work or whatever else crossed my mind.

Well, I've decided to blog again and will try to keep a somewhat regular schedule. I'll try to blog mainly on programming topics, which currently will be mostly concerned with iOS and Ruby on Rails.

The first post is on its way, so stayed tuned.

David Zikai

Three weeks ago today, on January the 9th, at 14:50 CET, our son David 子凯 was born. We are very happy to have him with us and wish him a happy and peaceful life.

Blogging has changed, now that he is here:

Apache, mod_proxy_ajp, Tomcat, SSLpache, mod_proxy_ajp, Tomcat, SSL

Just because I had to fight with it today and did not find the solution spelled out elsewhere (I found all parts, but not the definitive answer):

If you have an apache server that uses modproxyajp to proxy requests to tomcat and you want to use https as schema, even when you do redirects, you have to massage the ajp connector settings of tomcats server.xml.

Only when you add the following attributes to the connector, a redirect (for example a Spring RedirectView) will stay in https and not jump to http:

• scheme=”https”
• secure=”true”
• proxyPort=”443”

The scure attribute might not really be necessary, but it did no harm.

This is actually from Robin Johnson, but he did not mention the connector it has to be on.

If you think about it, it’s clear that it has to be the ajp connector, since apache is using that one to talk to tomcat.

Well, took me some nerves to get this into production today, so I thought I mention it, maybe it will help someone else. For me, I hope I won’t have to deal with tomact and jsp anymore…

Greener Hosting

Yesterday evening (GMT) it came to my mind that I don’t know about a dedicated “green” hosting provider. There are a lot of cheap hosting providers, but cheap often means that they use cheap energy to power their servers, and cheap energy currently translates to coal or nuclear power. Now after our last move to a new apartment two and a half years ago my wife and I decided to select the “regio”-energy program of our local energy service company. In this program we pay 1.8ct (Euro, approx. 2.7 ct US Dollar) more for each kWh, which is used to support the construction and operation of renewable energy sources.

I would pay more for my web hosting, if I knew that the increase price would mean less CO2 emissions. http://www.co2stats.com is making a case of purchasing carbon offsets for your website. It’s a good idea, but it would be even better if I knew that my site wasn’t producing any CO2 to start with. My thought yesterday evening was that there could be market for “green hosting”, and it either isn’t tapped yet, or I haven’t found the ISP’s who are committed to our environment.

And then, this morning I see Google’s announcement, which shows that I’m not the only one who is thinking about this.

The question is: Would you pay more for web hosting, if it would reduce the CO2 emissions produced by your web site?

Changes

I haven’t been blogging lately, simply because I have been busy, not so much at work (I’ve been busy there as well), but more in my private live.

Not only are we (my wife and I) building a house (in an unconventional way, more on that in a later post), which takes a lot of time for planing and decision making. We are also expecting our first child to be born this year or at the beginning of next year.

Like falling (and being) in love, expecting a child is testing your point of view on almost everything. There are three questions, which are not new to me, but which I now think about more often:

• What have you done with your life? Where (and doing what) have you spent your time?
• Haven’t you seen what was happening to our planet?
• What have you done to make the world a better place?

My wife an I try to live in a sustainable way. We don’t have a car but rather take the train, we live in a low energy building (and the house we are building right now will be a low energy building as well), we buy food produced within 30 km of our home when possible (bananas tend to be difficult, though) and we by organic food, mostly Bioland and Demeter. Since my wife is Chinese and her family is in China, we try to fly to China once every year (but currently only manage to get there every second year), but we are trying to offset the CO2 we are producing on these flights. The amount of CO2 we are producing lies well below the average german citizen.

But what we do are mostly passive decisions on what we consume and how we travel. Currently we are not actively engaged in making a change. Which brings me back to the questions:

• Haven’t you seen what was happening to our planet? Yes I have, and I have tried our best to live in a sustainable way.
• What have you done with your life? Where (and doing what) have you spent your time? I want to be able to answer something like: I have tried to make the world a better place.
• What have you done to make the world a better place? I’d like to say that I have actually actively engaged in making a change.

But is what I’m doing now, where I’m spending most of my time, satisfying this? I guess I will have go on changing my life.

Large Scale JSF Projects Revisited

Seven months ago I asked the question Who has done large scale JSF projects?. Now Alain O’Dea took the time to answer those questions and shares his experience with a large JSF project. Since his comment provides very useful and interesting information, I thought I do a fresh post that links directly to his comment:

Alain O’Dea on his large scale JSF project

Chiming in: JSP - Innocence Lost

Yesterday Angsuman Chakraborty wrote about his feelings concering JSP.

I totally agree with him. 7 to 8 years ago I was on several projects which used JSP. These projects ranged from one month with 2 developers to 1 year with 10+ developers. And they actually were fun to do.

Starting this year I was (and still am) involved in two projects which again used Java technology for the web frontend.

The first was using JSF. No real support for POST says all.

The current project is using plain JSP with Spring. I admit that Spring is a lot easier than EJB 2.1, but for me it still goes tha Java framework way of making difficult things possible but at the same time making easy, “default” behavior difficult.

Expression Language is something which was introduced to Java web development which I wouldn’t want to miss. But the whole setup of a JSP project using the current stack is, imho, too difficult. When Angsuman says that the current JSP technology is not usable for rapid prototyping he is right. I guess it will take most programmers between two days to a week to set up the infrastructure and build support for an JSP project.

OK, if you use tools for RAD, you might be faster, but I always like to know what is getting generated, just in case that it might not work as it should (which will happen, that is sure).

When the customer is not forcing me to use java for a web application, I would never use it. But then I guess I really have already departed.

Less code revisited

Came across this today:

Erlang: The Movie via Jared Richardson which expresses some of the thoughts I wrote down a few days ago.

Less Code

It is a fact that the code we write today is tomorrows legacy. Have you been working with legacy code? I guess all of us have already refactored, rewritten or translated legacy code in their professional career. It can be painful. It might also open up a new view on programming topics (like when I learned about COBOL for one of the projects I was involved in).

But since our own code, written today, will soon be legacy, what should we consider when we write that code?

For me, the documentation of the code is only a part. I’m a big fan of documenting the interface level contract of code. At the same time I’m all against documenting the body of functions (which imho is a violation of DRY). I mean, where is the sense of:

#Update each item <- stupid comment!!!
items.each { |item| item.update }

And that example brings me to this post’s title: writing less code will make life for those who have to deal with the legacy we are producing easier.

Less code can in my opinion be achieved by using the right programming language for the right job. The snippet in ruby above is self explanatory (even for someone who doesn’t know ruby well, all he/she has to learn here is the syntax for passing parameters into blocks). It can get more efficient with DSLs. Rails style of declaring associations is about as succinct as it can get.

For concurrent programs, using a language that supports concurrency on the language level like Erlang will make your code more terse.

I am not claiming that programs written in Ruby or Erlang or Scala or Haskell are easier to read than programs written in C# or Java. But I think that choosing the right language for the job can keep a lot of boilerplate out of your code. Some people claim that about 80% of the legacy code of any given system is boilerplate and infrastructure and only 20% are of business value (I would disagree in the case of COBOL though, my feeling is that it is more like 50/50 there). And exactly this is what makes working with legacy code annoying, tons of infrastructure to step through to find the few business parts your interested in.

Try to keep as much boilerplate and infrastructure out of your code, and the coders coming after you will thank you for this.

P.S.: Sure, you can write Java with that goal as well, keeping classes that contain business logic separated from classes that contain boilerplate, but most people don’t do it, because tha language doesn’t encourage it.