GoIT-Postal - Programming Nowadays

Installing PHP 5.2.10 on CentOS 5.5 in 6 steps

2011-02-17T03:26:00.000-08:00

Recently I ran into the problem to update PHP on a CentOS 5.5 server from version 5.1.6 to 5.2 or higher. The reason was that I wanted to test Drupal 7 on a virtual machine the first time.

As a fact for Drupal, Drupal 7 needs PHP 5.2.5 or higher as a requirement. But a simple "php -version" revealed that CentOS only comes with version 5.1.6. Understandably, because CentOS is a server operating system an only provides stable packages in their repositories.

Anyway, a simple "yum update php" only says "nothing to do", so here is the hack to get a more recent PHP on the server:

Get root.
Make sure that you are only using standard PHP packages, remove the other ones (for now). You can get a list of installed php packages using the commands "rpm -qa |grep php".
Add the deployment repositories through (editing) creating the file "/etc/yum.repos.d/CentOS-Testing.repo". Insert the following lines (without spaces at the start):
[c5-testing]
name=CentOS-5 Testing
baseurl=http://dev.centos.org/centos/$releasever/testing/$basearch/
enabled=1
gpgcheck=1
gpgkey=http://dev.centos.org/centos/RPM-GPG-KEY-CentOS-testing
includepkgs=php*
Update PHP through the command "yum update".
Resart the Apache web server (or any webserver you use) through "service httpd restart" or "apachectl restart".
Test the version of PHP:
[root]# php -version
PHP 5.2.10 (cli) (built: Nov 13 2009 11:44:05) Copyright (c) 1997-2009 The PHP Group Zend Engine v2.2.0,
Copyright (c) 1998-2009 Zend Technologies

That pretty was it. If you had non-standard-packages, reinstall them now.

Video: Opera response to Google Chrome's speed test video

2010-05-29T05:53:00.000-07:00

Remember the Google Chrome speed / performance test video? Well, Opera responded with an own performance test video as a reply to Google.

As known, the Opera browser and Google's Chrome are fighting for the fastest-browser-in-the-world crown and Opera is catching up right now with a faster Javascript engine in Opera 10.50. Time do do a little performance testing:

But though both tests do compare the respective performance using the all-known-potato-method, you cannot be exactly sure if a comparison can be done really accurately. Judge yourself.

Chrome performance better than lightning (or a potato canon)

2010-05-17T16:24:00.000-07:00

Well, everyone already had the idea that Google's Chrome browser is one of the fastest browser out there. Be it rendering (by using the WebKit) or JavaScript (with the V8 engine), even giving every tab an own process seems to help.

But, until today, I did not know that Chrome is faster than sound or a flash (thunder and lightning). Or even... an ordinary potato gun.

Evidence needed? Watch this video, it explains how that is possible (scientifically).

Who would have thought that a browser outranges a potato canon? Well, now we know.

Five reasons why Apple can/should/could create a tablet-PC (and five why not)

2009-12-30T15:05:00.000-08:00

So there are many rumours (or should we say "reasons"?) why Apple will release a kind of tablet PC on Jan 26th. No one knows, everyone speculates, but let us be honest: Technically, they could. And for me to look into the glass ball: At Jan, 26th, Steve will introduce a device pretty the same like the iPod Touch with a 7" display, having wireless and a OS X. But that is just the beginning.

Marketing and the name will be important

Most rumours go for the name. May it be iSlate, or iGuide (here too), no one knows (despite the fact that both seem to be aquired / protected by Apple's employe "Regina Porter" and Apple's commissioned lawyers). I, personally, go for something else. "iSlate" or "iGuide" does not sound like Apple for me. Better would be "iTouch" or "iBook Touch", something like that. But here, iThink, we will have to wait for Apple's last call.

Apart from the good kind of selection depending on names, Apple's congeniality is not ultimately found in technical reasons. It is founded in design and pretty useable products. And their placement in the market.

Other markets emerge, existing markets got complex

Having the netbook market exploding these days and (for a newbee at the phonie-thingies) some drawbacks at the mobile market which might, on the long tail, get serious for production costs and/or customer revenues, Apple is smart enough to engage new markets. So let us have a look on why Apple should expand their market introducing a complete new device to the market.

Five reasons why Apple can/should/could create a tablet-PC (and five why not):

1. Technically they have OS X for iPhone and therefore "Cocoa Touch" which is needed to run a successful tablet PC nowadays (fast enough multitouch applications).

2. Rumours say that Apple worked four years on something like a touch-PC, if they are not ready yet with their experience on Cocoa Touch, they never will be.

3. Rumours say that Apple is asking software deliverers to not only work for the resolution of iPhone/iPod Touch but to modify their software to work on bigger screen resolutions.

4. Having 100.000 "Apps" in their market place that might be easily modified would help a lot to implement a new platform.

5. After the success of the iPhone everyone will listen to a new device, even if it is "yet another touch PC" - marketing is on their side.

Where there is much light, there is shadow, too. Five reasons against:

1. A tablet PC needs to cope with all functionalities of a normal PC. Can Cocoa Touch be married with OS X at a glance? Windows 7 has it built in.

2. You never can copy a success story in IT-world. After the success of the iPhone, the Apple touch-PC should be a burner, having much more functionality than the iPhone (else it would only fill an niche).

3. Apple is (at the moment) forced to get functionalities to the iPhone other mobile companies have, should they open a second front at tablet-PC's or concentrate to what they have/need to do?

4. Pricing will be critical. Selling an iPhone at $199 which then is partly payed by a telecommunication partner is cheaper than selling a new kind of device at Apple's own [risk] (rumours say it should be well under $1000)

5. January 26th is a date the media knows (now). Steve Jobs has to deliver (something - read the link tot he end). Hopefully he is not taking his mouth too full (or didn't at the past without saying something... ).

Words from the editor (please only read if you want to):

Well, I would not call it "words from the editor" here at the end of this blog. I'd call it: Rumours. I researched a lot depending the Apple-tablet-thingie going on. My opinion is that Apple will - at best - deliver a gizmo working with a 7" touch display on Jan, 26.

On the other hand I read that they will only get new gadgets 'n gizmos for the iPhone on this date. No one can tell, but one thing is clear: Apple does, let's says since mid 2007, not always move fast enough. Nowadays they have to move. Kind of fast. Others do.

So my guess for the future is: On Jan, 26th, Steve introduces iPhone 4.0 :) or something like a "iBook Touch". Starting at 7", getting to 10.1" (promised middle of 2010).

Quotes for large software projects

2009-10-28T10:49:00.000-07:00

Again it is time to talk about larger software projects. This time not only about the "how's" and "where's", let us take a more... humorous approach. Let us have some famous qoutes you could use to get some brains straight back to line.

If someone shows off a very complicated software design to you, consider to quote the following:

"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult."

C.A.R. Hoare

Let's say everything in a huge project is clear - theoretically. Why should implementing it be difficult? Because...

"In theory, theory and practice are the same. In practice, they're not."

Yogi Berra

Long-year-experience and wisdom from my friends:

"Frameworks like Ruby on Rails exist to make simple things even more simple and complex things impossible."

A colleague of mine

A deadline bites. But again, time - while developing in a large project - is somewhat relative:

"The first 90% of the code accounts for the first 90% of the development time. The remaining 10% of the code accounts for the other 90% of the development time."

Tom Cargill

Cutting the development time by throwing more developers into a project? Reply this:

"Nine people can't make a baby in a month."

Fred Brooks

Not exactly valueable for large projects, but, alas, said by a great man:

"Whereas Europeans generally pronounce my name the right way ('Nick-louse Veert'), Americans invariably mangle it into 'Nickel's Worth.' This is to say that Europeans call me by name, but Americans call me by value."

Niklaus Wirth

Something every programmer of a large project at least said once in his life:

"It works on my machine."

Anonymous Programmer

And, one of my favourites, not exactly from a programmer (but a wise man):

"Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away."

Antoine de Saint Exupéry

Look out for some more quotes at "Quotes: 5 different views on computers and programs".

About a stackoverflow-comment I wrote: Best practices, summaries and Zen

2009-09-10T16:39:00.000-07:00

Once upon a time... I answered a question on stackoverflow.com (What do you consider the 1st principle(s) of programming?) a little bit zen-likely. The standard answers were "kiss", "dry" and "yagni" which I not only like but try to embrace wherever possible. Nevertheless, there is much more to say about that and therefore here is my little "zen-garden" of programming tips in 4 parts:

Zen, part I: Programming is only the road, not the way.

Programming is only the technique to teach a computer what it's gotta do. To be successful in creating fast, reliable software means to know your algorithms, best-practices and all the other stuff not necessarily connected to your programming (language).

Zen, part II: If you are in a hurry, stroll along. If you really are in a hurry then take a detour.

Sounds silly but do not let yourself get into compromises that (really) may trouble you afterwards. "Stroll along" when the project is in a total hurry? It works if done right.

For this I got a rule: In case you are at the core of a program, try to be as precise and good as possible. If you are using methods from the core that are deep in your software, try to be faster in coding. If you are coding above these two, you can even get a little bit more sloppy. This way you will prevail headaches by not spending time to trace "unexpected behaviour" of core functionalities (and all relying parts to them).

Remember: Design errors are the hardest to find and/or fix. Next step on the ladder are programming errors in parts everyone relies on, then the "real showing-off software parts" (like UI or web interfaces). If you need to fix a design error at the end of a project, it means to fix it through the persistence layer, the protocols, the client... ahem. Not good at all.

Zen, part III: Know your path, Neo.

Know your environment, tools and the stuff you rely on on a daily basis and get it sorted so that it works for you. Best if you use your programming "environment" so natural that you do not even have to think of it. If you have to get a job done do not introduce "fancy new stuff" but do your work. This stuff can be introduced in a new project, namely then when you have time to prepare and use it.

Which leads to the thought that you "should stay onto the stuff you ultimately know. Anytime." Right?

Completely wrong. Try to learn something new every day. At least try to inform youself about new thingies out there, not in detail, not remotely complete but open minded.

I am sure you accomplish this, because to learn something new you are reading this blog right at this moment. Aren't you?

Zen, part IV: Do you think that's air you're breathing?

Never, ever, think you're the best in what you are doing, if so, you only could get worse;-). And never be satisfied with the techniques you know and therefore stop listening or learning to new ideas.
At least try to be open minded enough to listen to new concepts, strategies or - even - programming languages and paradigms. That advice is the most necessary - and most valuable- I might give to you for your (programmers) life at all.

Microsoft releases code to Linux. Why that?

2009-07-21T12:41:00.000-07:00

No, the hell doesn't freeze and pigs don't fly. But Microsoft released source code to the Linux open source community. Earnestly.

Well, old news, you might say. Microsoft did release parts of their code using (more or less real) open source licenses and started doing so years ago. They released code under the MS Public/Reciprocal License (Ms-PL/Ms-RL). They even released code for their Web Sandbox Source under the Apache 2.0 license.

So what is different?

According to Microsofts speaksman Tom Hanrahan it is the first time Microsoft contributes source code for inclusion in the Linux source tree. It's not that they never, ever before commited code to the strict GPL. The real news is that they commited it directly to Linux, the operating system that competes more than well in server technologies Microsoft wants to get and hold a grip on. And trying to be conform with Linus Torvalds, Microsoft released the code under the GPLv2 - notGPLv3.

And why would Microsoft put source under GPL for their competitor?

Microsoft is business and the definition of "business" - excuse my sarcastic but nevertheless realistic view - is to earn money. As a corporation you have to bill something to earn something to pay something (e.g. your own bills and employees). Simple as that. So they try to bode themselves well from GPLing.

Looking behind the gifted 20.000 lines of code it is not that difficult to find out why they did it, at least if one looks at the purpose the source-gift should fulfill: Microsoft is releasing three device drivers for Linux which should enhance the performance of the Linux operating system when virtualized on Windows Server 2008 Hyper-V or Windows Server 2008 R2 Hyper-V.

That's the news? Um, yeah, any afterthoughts?

Yes, there are some and they - obviously/hopefully - have to do with a kind of change of what Microsoft does and how they behaved lately. A new OS is comming (Windows 7) where they finally listened to the users and firstly, radically and totally changed their programming paradigms to implement it. And bing is doing well (actually only because they have a huge advertising budget, as I think, but time will tell).

Not that Microsoft changed from ground to bottom but it seems like a little peace of white flag (a very, very little piece in their own manor, - "corporation" - you remember?) and that it is not only about fighting (FUDing) anyone totally down to the ground anymore. Not even Microsoft can live without an eco-system surrounding them. Perhaps, and for god's sake, they understood. At least a little, little bit.

Hope so.

[Update] Read http://www.virtualization.info/2009/07/microsoft-releases-hyper-v-linux.html, it's a more technical approach but reveals another view on the topic.

Trying to kill creativeness in programming: Why a "Programsmith" would fail

2009-02-26T06:16:00.000-08:00

Ever wanted to be a great musician but cannot read notes? No problem, using a computer program will help you getting along and famous: Microsoft Songsmith.

Songsmith composes music for you, the only thing to do is to adjust some sliders and sing into a microphone. From that moment on music will fill your laptop, quick and easy, nice and dandy, for every occasion in every phase of your life.

Why there is no "Programsmith"...

So much for the idea the creators of Songsmith try to sell. But, as we all know, in real life it is not so easy to just create an algorithm that scans sound and spits out world-class music. The idea surely is appealing. And it is not really new: Many customers and project managers dream of an IT-service-provider/programmer/administrator that exactly solves problems in the same way: Best would be to "sing" a little requirement into the phone so that the complete and working program can be deliverd a week later. And do not technologies like RAD, XML, EJB, Webservices suggest the possibility of a Programsmith? Simply connecting the modules and you are done?

... and why a "Programsmith" would fail

Certainly not, projects in IT do not work that way. You have to communicate and get the requirements right, make project plans, split the workload into functional points and instruct the programmers, involve third-party-modules and interfaces. All in all it is a creative process and we all know that. But our customers (and quite a hand full of programmers) would like a "Programsmith" to exactly do that: Draw a little plan, involve some kind of magic compiler (UML, anyone?) and deploy the program.

Well I had fun scanning through the results of Songsmith videos on youtube viewing classical hits interpreted by the program like "Roxanne" from "The Police". I think that this is the hearable pendant of a (more sophisticated) program how a kind of Programsmith would compose it. It will not work out in the end, at least not as long as the to-be-written-program is a counterpart to the complexity of a "Stock Aitken Waterman" tune simple enough to be more or less replicated by Songsmith. But even that one crackles and creaks a lot.

I wonder if there is a similar video out there treating programming in such a way (videos like singing to be successful selling "Glow In The Dark Towels") using the sliders "XML", "Webservices", "Cloud-computing" and such. Would be funny to see the results of them. Well, let me search a bit... .

Are programmers open minded enough in technical opinions? Why not?

2009-01-06T04:41:00.000-08:00

Today I checked an entry on stackoverflow.com to see how the answers were doing and which answer the questioner selected for himself to be valid. Again I was totally disappointed because the answer selected was in my opinion far away from being the best answer, rather it seemed to be the most convenient answer for the guy who asked at first place.

Are we open minded enough?

Questions of programmers mostly divide in two parts: The technical questions (i.e. questions which provoke solutions that either work or won't) and questions which - at least - elict to give an opinion in the answers because they cannot be answered that simple (i.e. "which framework is best", "what is the fastest method to..."). The latter kind of questions troubles me here.

When we ask for opinions of the community we should stay as open minded as possible judging the answers, but this, alas, is very difficult. Let me state some points why this is so.

Why aren't we open minded enough regarding our technical opinions?

So, why is it so? I gathered some reasons and their descriptions I stumbled upon in my life and wrote them down:

Projects, timelines, customers and change requests to be done "until yesterday". In a perfect world we would have enough time to evaluate different approaches for a programming project or problem. But in the real world you often have to just get the job done and have no time to rely on fancy stuff like other opinions. This may get a habit that is hard to be dealt with so that finally the own opinion counts (more).
Experience vs. half knowledge. Every programmer has a certain experience in a certain moment in his life. You certainly cannot have a (completely) valid opinion of things you didn't "experience" until now, be aware that half knowledge is a bad judge. Anyway, many people in cs trust their half knowledge more than (other) opinions from more experienced people, often even without really recognizing that they do so.
Sticking with own tools / frameworks / languages. Regarding their languages, tools and frameworks most programmers are very conservative and do not want to change them. That is not bad per se, things that worked out should be kept and experience gathered stays preserved, but it leads to programmers who do not try (or accept) new ways and therefore being "open minded" gets really hard.
Only the newest tools / frameworks / languages are the best. This seems to be the opposite of the argument above but it merely isn't. Someone who only relies on the latest techniques may not be aware that a problem can be solved better using an "old" technology. This perhaps because he never got deep enough using something (long enough) to see the advantages that are not obvious at first place. On the other hand the drawbacks of a new technology are not known at the beginning so everything looks more simple than before. That creates prejudices which constrain to be open minded.
It worked fine in my project so it works fine for everyone else. Generalization. Nearly everyone fails on this and it is perfectly human to do so. But in cs all project are, more or less, different. Be it because of the (slightly) different requirements or the environments or specifications a program has to run in. Even small varieties may make the great difference and everyone should keep this in (an open) mind.

This all is not really new and there are many slogans that reflect them like: "A fool with a tool is still a fool", "If all you have is a hammer then everything looks like a nail", "Use the right tool for the right job" or "Some tools make simple things even more simple and complex things impossible". Anyway, every time I answer a "technical opinion question" I lean back and try to evaluate my answer against the points I mentioned above. I think this improves my answers a lot.

Related posts:
Different types of programmers
How to choose the best programming language

Google Chrome without data sniffing: Iron is here.

2008-12-20T05:09:00.000-08:00

A german software company named srware took the GPLed source code of Google's chrome and ironed it down to create a browser that does not phone home to Google any more. The latest release of Iron (1.0.155.0) from December 14 already contains WebKit version 528.5 and JavaScript engine V8 version 0.4.4.1 and therefore is slightly newer than the respective versions in Chrome.

Your data is private again

The goal creating a Chromeclone was simple: Although Google Chrome delivered fantastic rendering and JavaScript speed from scratch and is pretty stable and compatible, criticism arose because the new browser shared it's data with Google.

Every time a new URL is entered this data is sent to Google. And Google can match these with the browser because every browser gets a unique id when it is installed. Furthermore, the Google Updater is installed and runs in background every time you start your computer (check your Task-Manager for "GoogleUpdate.exe"). This and more is deactivated in Iron, according to this page.

BSD-licensed, USB-stick version and source available

The browser identifies itself as "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/528.7 (KHTML, like Gecko) Iron/1.0.155.0 Safari/528.7". The geeks at srware provide downloads for an Iron-Installer, an Iron-USB-version (without installation) and the source code they altered. The source is available under a BSD-license, so everyone can use it completely free even for commercial products.

Conclusion, language tips and full incognito

The rendering and JavaScript performance of Chrome attracted us from the beginning, alas the privacy drawbacks stopped us from using it. Iron does a good job here and comes, as a bonus, wit a USB-stick version and without installation but preconfigured with the german language.

To change the language choose the "SRware Iron anpassen" icon (top right in the tab of the browser) and click "Optionen". Then click the third button ("Schriftart- und Spracheinstellungen ändern"), choose the tab "Sprachen" and select your language in the "Iron language" - dropdown.

One more option at startup is the "--incognito" parameter. Start Iron with this (i.e. like "IronPortable.exe --incognito" to immediately switch into the anonymous mode. Have fun!

Google Chrome: A first little test with highly complex AJAX/Javascript web applications

2008-09-02T16:19:00.001-07:00

Google Chrome - what is it's real performance for highly AJAX-based web applications?

Some five hours ago Google introduced Google Chrome and put it on their site for download. Google Chrome is a stand-alone web browser and therefore has to compete with browsers like Internet Explorer, Firefox, Opera and Safari. Here at first a core Javascript test (as stated in a previous Javascript-post):

Chrome 0.2	FF 2.0.0.14	FF3 RC1	IE 7.0.5730.13	Opera 9.27	Safari 3.1.1
3471,8	26271,4	5447,0	40846,2	12358,2	6318,8

Time in milliseconds the browsers needed in this performance test

But Google Chromes main goal is (according to Google) an other goal than that of other browsers: Highly AJAXed Javascript "web applications" shall run faster and more safe with Google Chrome, thus enabling a new era of web based applications like Google Maps, Google Mail or others. Time to look at speed and compatibility issues with more complex applications, even though the browser is stated as a "Google beta". Again.

YAWB or not YAWB, that is the question.

Yet Another Web Browser? Or: Why is Google in the web browser market? Because that is Googles business, the idea fits. Why not presenting the browser as a gift and earning money with the applications they run?

Internas and testing environment

Time to do a kind of real life test using an internal application that makes heavy use of Javascript and AJAX. At the moment Google Chrome is too much of an early bird to do this excessively, but we can have a look under the hood and run a fairly complex application on it.

The new features include

A new Javascript Engine called V8 is in use.
Better performance through compiled Javascript, it is compiled into machine code and not necessarily always interpreted.
The new Javascript VM has a better garbage collection included to preserve memory.
Browser tabs or new browser windows run in dedicated threads.

The testing application has some thousands of lines of self-written Javascript-code and relies on Prototype and other frameworks. It (re)opens different "windows" as DOM-elements and is able to switch through them via ctrl-tab and shift-ctrl-tab. Data is drawn from the background via AJAX, the usability allows drag-and-drop of single (or multiple) elements from one window into others. The application "runs" on IE, Firefox and Safari. Pretty complex stuff for a first test.

Compatibility will be the key...

What use is a new browser if the sites you want to visit will not work with it? Right, none. So the browser has to be as compatible as possible. I was fairly surprised and impressed as I saw the application running smooth and dandy. There was no itch regarding the Javascript-compatibility, every function I tested simply worked. The whole Javascript-code ran without the need to apply a single patch or something similar from our side. You know the moments where you hope "ah, come on, it will work out somehow. I believe, I strongly believe..." and you run it and it works out? That was one of that rare moments. Impressive.

... and performance will be the door-opener.

So it seems to be pretty compatible, right, but the second side is, is it faster, more useable than other browsers? The rendering engine seems to be partly from the webkit.org - project, rendering was pretty fast and compatible (to say the pages looked like in other browsers). From the look and feel of the thing I would say Google Chrome is at least one of the fastest rendering browsers if not the fastest, anyway.

And the Javascript-performance was astonishing (see here for numbers of a normal Javascript test suite). The application, running pretty fast in Firefox 3 and Safari 3.1 got a little extra speed-kick. That way it really feels like a real application on the computer rather than rendered web results. The clear separation of tabs and windows into threads does its additional work: Because no tab has to wait until an other tab releases the processor you have the feeling that it works faster or smarter.

So is it worth the hassle?

I think it is worth giving it a try. I do not think that I will use it yet as a browser-user, because I need my Firefox-plugins or IE-updating. But I will definitely test it with/for Javascript and AJAX-driven pages and our own developments. The gain in there is definitely worth the hassle.

How to choose the best programming language

2008-06-15T11:58:00.000-07:00

Inspired by a new blog-article "Best programming language" there are some more open points to discuss on how to choose the best programming language for life, universe and everything. Let me give 5 of them.

First things first: Is choosing the right language even remote possible? And if so, how can it be done? Well, to set things clear let's have a real-world-example: Which (spoken) language shall I learn to succeed at most? If it's only a matter of understanding and talking to the most people this would be chinese. Do you achieve your goals with that? Most probably not.

Why wise selection is necessary

You can speak with one billion people in case you choose to learn chinese, but you could not read this blog (in case you prefered learning chinese before learning english). And how many people in your neighbourhood do speak chinese? Is it worth learning (under respect of this argument)?

Choosing a programming language too depends on many factors which you have to name and select with care. You want to show the best performance in programming (be it in programming-speed, stability, scalability ...), here is how:

5. Complexity of setup is not counting for evaluation

So, setting up an environment to evaluate the new programming language will last one to two hours (or even more)? Be honest: Setting up a testing environment for two hours is more easy than living with a not at all appropriate programming language for the next 6 month on a eight-hour-per-day-working-base in your new project. And of course you have to think about administration workload later on (which too reflects in evaluation, of course), but there are tools, workflows etc. which, done right, may help you to get rid of this point. Test the availability of tools, too.

4. The most hyped language may not be the best to choose

What is a hype (spoken in language selection)? Well, there is a new language out in the market. All people talk how easy and neat it is to work with it. Pretty cool so far. The drawback is that these languages are not widely "broadcasted" out there, mostly information is sparse on both the language and the usage/projects done with it. Of course you may use it, but be sure not to see things through rose-colored glasses.

3. Programming for fun is one, doing a project the other thing

Think of team-working, releasing, "changing one little bit might affect many others (and how can I prevent/check this)". This will help a great lot in case the project gets bigger and you will have to hire new people.

2. Prototyping and "getting things done (as fast as possible)" is not your daily work

Of course, most bosses and clients want to see what you do as fast as possible. They are more eager to compare your work with their business plan than to hear "no, we are setting up servers/software/configurations - please stand by". But on the long trail, as a programmer, you only can win if your work is profound and, in best case, solves problem other peoples like your bosses and clients do not even think of now. Test your desired language(s) if they fulfill your own personal claims on that regard, then test the language if it serves well in a programmers team and client-centric manner.

1. A fool with a tool is still a fool

Do not blame the programming language if you run in first problems (at first sight). Search for other ways if your goal cannot be reached with your first shot. Use Google to find new ways and thoughts (a good test to show if enough people using it / documentation on how to use it is out there, too). And even if you used the language for some years and think that the new project does not fit to it, give it a try on Google/the community. There are other people who might help you to solve a brain-nut-problem, sometimes on-the fly.

Not sure what langauge to choose now?

Watch out! There are a couple of languages on the market. And there is no easy answer to this question, if someone provides you with an easy answer, be most careful! Evaluate some languages, program some more in the languages that reach the "inner circle" for you and never forget the old but true saying: Use the right tool at the right time.

Other "Thoughts on" and "how to" articles:

Different types of programmers

Javascript core performance in actual browsers

2008-05-24T11:54:00.000-07:00

Today more and more sites do use JavaScript excessively. Be it because of Ajax-functionality or CSS/JavaScript hacks, disabling JavaScript does not work on a daily based surfing any more. On the other side all major browsers got a new version released in the last two month or do have beta versions in the queue. Time to sum up some Javascript core performance tests to show which browser vendors/developers did their homework (right).

webkit.org's sunspider performance test

Result of Javascript performance tests in short

The graph above shows the time needed by every browser for the webkit test suite (running in a loop, time in milliseconds):

FF 2.0.0.14	FF3 RC1	IE 7.0.5730.13	Opera 9.27	Safari 3.1.1
26271,4	5447,0	40846,2	12358,2	6318,8

Time in milliseconds the browsers needed in this performance test

See the details of every webkit test in the graph below.

As stated the graph above shows the overall results of webkit.org 's sunspider performance test. webkit.org is an open source project which provides the source code the Safari browser (from Apple) and Adobe Air (from, well... Adobe) are based on. It hosts an online Javascript performance test under http://webkit.org/perf/sunspider-0.9/sunspider-driver.html (caution, this link automatically starts the test).

Why "yet another Javascript test"?

In this test the five browsers "Firefox 2.0.0.14", "Firefox 3 RC1", "Internet Explorer 7.0.5730.13", "Opera 9.27" and "Safari 3.1.1 (on Windows)" were tested, technically spoken pretty simple because: Firefox 3 RC1 was released some week ago along with the XP Service Pack 3 (system and/or Internet Explorer 7) updates and a valid performance comparison should be done with every major update.

Browser usage of goit-postal.blogspot.com: Remember, it's a website for technicians

So this test shall give an expression about the core performance of Javascript in yet available mainstream-browsers (and no, thank you, no flame wars intended). That is the reason why, for example, Opera 9.27 as last stable was tested and not the faster Opera 9.5beta (according to this place) and IE7 despite of IE8beta, so called nightly builds of the browsers were abandoned for the same reason. Compatibility and conformity is not an issue here, either.

That, too, is the reason the sunspider performance test was chosen for this benchmark: Sunspider mostly tempers with core JavaScript functionality, namely some mathematics or date calculations and string manipulations. That is why it is highly limited in its characteristics i.e. for "graphical" Ajax websites using DHTML and manipulating DOM (see "Limitations of the test" below). On the other hand this performance tests nature serves to test the base performance of the Javascript engines (i.e. low-level scripting speed and the speed of the interpreter / number crunching) from the mentioned browsers.

The performance test in detail

The test was done on the following machine/circumstances:

Intel PC with Pentium D 3.4GHz Dual Core (so environmental task do not play such a huge role becaus they may run on the other core), 2GB RAM (just used 380M of them), GeForce8600GT (this too means the graphics system did not really interfere that much ;-)
Windows XP SP 3 (SP3 freshly installed)
Internet Explorer Version 7 (patched through SP 3)
Forefox 2.0.0.14 and (more interresting) Firefox 3 Release Candidate 1
Opera 9.27
Safari 3.1.1 (Windows edition, of course ;-)
The browser was the only running application (despite the TaskManager)
All unnecessary services of Windows XP (or other vendors than MS) were stopped
The caches of the browsers where empty, the internet connection was dedicated (for the test)
All browsers were opened with the same resolution (1280x1024 on a 1900x1200 panel)
Browser plugins were not installed or, if so, disabled (if you installed Firebug on Firefox remember to disable it for testing purposes!)

At the end of this article you will find links which help to compare the results with your own computer/environment.

The webkit-tests themselves split into "3d", "access", "bitops", "controlflow", "crypto", "date", "math", "regexp" and "strings". Below is a graph showing these (without "strings" for better visualisation).

Single performance tests on webkit.org the browsers needed to complete

The graph above shows the time needed by the browsers to complete the tests (in milliseconds):

	FF 2.0.0.14	FF3 RC1	IE .0.5730.13	Opera 9.27	Safari 3.1.1
3d	3.596,6	722,0	1.890,6	1.218,4	753,0
access	2.531,8	827,4	2.489,6	1.868,2	981,2
bitops	4.668,2	641,0	2.152,8	1.750,4	762,6
controlflow	225,2	75,8	663,0	265,6	171,8
crypto	1.505,8	387,8	1.381,2	593,0	497,4
date	4.859,4	481,8	1.266,0	619,0	668,8
math	2.643,8	652,4	1.697,0	1.312,8	775,6
regexp	1.115,8	327,4	406,2	0,0	362,4
string	5.124,8	1.331,4	28.899,8	4.730,8	1.346,0

Detailed time in milliseconds the browsers needed to perform the tests

The "string" - test is an exception in two ways: Firstly it is not visualized above because it would spoil the graph (the bar of the IE would be too long making other results more or less unreadable) and secondly it shows that the Internet Explorer at least has problems with strings and, probably, memory management (depending on strings and the testing-code).

Noteable, too, is the fact that the Opera-test on "regexp" delivers a timeline of zero milliseconds. Assumable there is a Javascript-error in Opera preventing the counter to count the time correctly.

Memory and CPU usage on webkit's test

One word about the memory: The memory was released after every test (webkit runs the tests more than once) by every browser as expected, because the tests are loaded separately in frames. All browsers (despite FF2 who nevertheless did aparently well in this test) do release memory of non-needed frames, nowadays.

Another word about the CPU-usage: This is not totally empirical but I measured CPU usage from the lowest to the max utilization of usage like this:

Safari
Firefox3
Opera
Firefox 2
Internet Explorer 7

I had no good tool on Windows XP to take an absolute accurate measure of the CPU usage but could survey the usage with a process messaging tool plus my ears: The computer I sat next to and tested this really sounds bad if an application needs only a little bit more performance than others. I definitely should buy another cooler for that processor if I want to keep it ;-).

Nevertheless, noteably is that only the Internet Explorer utilized (and needed) more than 50% of the overall CPU performance on the system (up to 80%): Seems that it is the only system that can utilize more than one CPU (and needs it, anyway ;-). But to be honest, Firefox 2 didn't sound good, either... .

Limitations of the test

Never forget that this is no "real-life-performance-testing". The tests driven here are, to say the least, mostly academical. At least they are not realistic as long as someone wants to write a ray-tracer in a scripting language. But they are intended (and pretty accurate) to give a feeling of the Javascript engines working in the tested browsers.

Additionally, the test was done only regarding "stable" versions of the tested browsers in the given environment. A well-used real-life-existing test like webkit served well because my interests are real life scenarios. I am sure someone can pimp up the string-tests of webkit.org for IE or install another version of Opera (not to mention the performance of Safari running native on Mac OS X, who knows), but that is not the essence of this test, that would be something different (like a performance tuning test). This test only shows the direction.

This means (of course): This test says (nearly) nothing about real-life-performance of, let's say, heavily used Ajax-features. It does in no way measure the speed how DOM/DHTML or even graphical rendering is done by the browsers. Or garbage collection of Javascript in general (perhaps in special :), and therefore, in the real browser world. This would be a complete other kind of testing (Upcoming soon! Watch out your theatre or this site for more details!).

Conclusion: Why this test has been done and what I learned from it

Of course, testing done right needs time. Preparing the machine, restarting, emptying the cache, providing in any way you can think of that the data is as valid and correct as possible. Why did I waste my time although there are so many Javascript-testing-scenarious and results out there? Because the world keeps on changing. If you only change one single component (in computer life that normally is a new browser or [minor] operating system version), all other components (like speed, memory etc.) may behave in an other kind.

One thing I learned (and was more than eager to test) was that Firefox 3 is using a new memory management, system wide (and for Javascript). I know that the old memory management was not at it's best, not to speak about Javascript memory leaks. Not the best base to throw in a long running RIA application. Another thing was that I heard that FF 3 competes better than Safari on the webtoolkit - test.

webkit.org provides the source code for the Safari browser. I tested some very complex Ajax framework on a Safari browser and was astonished about it's speed. Some day I heard that Firefox 3 slew Safari on it's own battleground: The webkit sunspider performance test. Time to figure that out.

Nevertheless, (as you surely guessed till now) providing a so called "RIA" Application based on Javascript with my colleagues, it was time to make detailed and own-experienced performance testings for the existing possibilities out there. The surprising parts (some seen at the charts above) are, more or less that

Webkit (Apple) astounded me because our (JS/Ajax-)applications ran recognizable three to four times faster using Safari on Mac, I saw this month ago (and though compatibility issues are a problem we really think to deploy this platform)
Firefox 2 was beginning to be not as slow as Firefox 1.0/1.5 (or Mozilla, but it is still sometimes too slow) and then started to get slower again (memory usage "degregaded")
Firefox 3 came with a new memory management and the capability to also resolve memory of Javascript-objects of certain depths (an old known Firefox 2 bug), so Firefox 3 definitely was/is an option
The crown of performance is not the Internet Explorer any more (webkit, anyone?)
Safari scared the hell out of me being that performant in ("graphical") Javascript (DHTML/DOM/Javascript-performance)
I read that Firefox 3 should be faster than Safari at webkit.org which - frankly - I could not believe (and did not test on the longtrail. But I will.)

What is missing

Testing the core performance of Javascript in todays browsers is okay. But it does not give real facts or benchmark results you may rely on deploying complex Javascript-based Rich Internet Applications. Even so, every application is different.

The next performance test on Javascript will try to clearify DOM/DHTML - changes and the performance-behaviour respective to the used browsers and browser rendering engines. My guess at the moment is that webkit (Safari) is top-notch there, but who am I to say that in a changing world?

Appendix: Performance-Links webtolkit.org (alphabetically):

Performance of Firefox 2.0.0.14
Performance of Firefox 3 RC1
Performance of Internet Explorer 7.0.5730.13
Performance of Opera 9.27
Performance of Safari 3.1.1

extjs - when open source kills community progress

2008-04-26T05:00:00.000-07:00

Two days ago, Jack Slocum from extjs announced a license change for the JavaScript/Ajax framework extjs (http://www.extjs.com). The previously "dual-licensed" frameworks stays dual-licensed - for open source and closed source software. This is no real news, mainly only one letter changed, the letter "L". "L" like in (large) big. I recognized the change because I was on the page to buy 5 developer licenses. I am not sure to do so now.

GPL vs. LGPL - the difference

extjs 2.1 and later is licensed under the GPL now, earlier versions (up to 2.0.2) are under the LGPL. The "lesser" or better "library" GNU general public licence is less restrictive than the original GPL. In short words, the LGPL was created to grant the user of a program/framework the right to use it without giving the complete source code back. Using any GPL source code or part of it requires you to open source all your code, the LGPL only requires you to publish the changes you did to the LGPL-code. So using extjs in a, let's say commercial application, was okay until now.

extjs dual licensing model

Software development is expensive, to pay your rent you have to sell something. In the open source world often training, proprietary licenses, special programming or consulting is available from the "vendors" of the software, companies like RedHat show that it is possible to earn money with GPL-software if you have a good business model. extjs (additionally) used the approach by selling development licenses. It is forbidden to build a framework or development base from extjs unless you meet certain circumstances. Anyway, having the library under the LGPL granted you the permission to sell your own work with extjs built in. The new dual licensing model including the GPL passage now forces the developers to buy developer licenses. This is not a bad thing per se, as mentioned before, this is no problem for me. The problem is that I do not exactly know what I buy with a development license, which was no problem as long as the LGPL-fallback was effective. But now other questions are important: Can I give away extjs as often / where / when I want to do it? Are my customers bound to buy a developer license too, if they simply want to improve the JavaScript of my application or is my application then completely GPLed? Do I need to forbid this explicitely?

The consequences I: extjs and the community

Putting extjs under the LGPL helped to build the community which is very active, as seen in the forums of extjs. The word was spread, the framework used. And the product thrived and prospered from large companies and/or many programmers using it. Not at least because of the license. extjs is a good framework, but what is it good for if nobody uses or extends it?

Reading the forum at the moment is no fun. It reflects many of my own thoughts and worries about the future of extjs. Many people relied on the framework, built software with it, extended their own programs and are not sure what is happening at the moment or how the future will go on. This decision may kill the community, many users request a fork of extjs based on the last LGPL version (2.0.2).

The consequences II: extjs and the fork

"Forking" is a process where someone takes the open source part of a software to create a new open source project. One of the most known forks is Joomla, a content management system that forked from Mambo by taking the source code and advancing it from that base.

extjs up to version 2.0.2 - technically - is under the LGPL. In principle it is possible to take this code base and create a new branch (or fork) of it. Anyway, the old license too tried to avoid that by prohibitting derivative work that is a framework or development toolkit. But the download of the version 2.0.2 includes a LICENSE.txt which says that you may use the LGPL if you "Are using Ext in a commercial application that is not a software development library or toolkit, you will meet LGPL requirements and you do not wish to support the project" which is, in my opinion, not hard enough to avoid forking. The fork then needs to derive from version 2.0.2 and under the LGPL, thats all.

So it is GPL then, GPL is a good thing, why the hassle?

The uncertain future (any license changes again, anyone?). The imprecise actual commercial license (please, please, please, make it clear!). The community that will perhaps not forget or forgive and most certainly shrink from now on. The unknown handling/procedures, i.e. developing plug-ins for extjs (is it then GPL? Commercial? May I post it, because then its derivative work and I may need a developer license? If I submit the code, who possesses it - do I need to GPL my other code if I "use it back"?). This very last point - the uncertainty - prevents me from sharing my experiences with extjs in their forum at the moment.

I develop software and live for and from it. Ergo I pay for software that I need to do my on-a-daily-base-job. We integrated extjs and spent some hundreds of hours to develop (with) it, so we wanted to buy the licenses without any real need (because we meet the LGPL/extjs license agreement). This should have been a contribution for the excellent work of Jack Slocum and his team. But I am not willing and not obliged to support uncertain business decisions, especially when they compromise my own software and business. I'll stay with extjs 2.0.2 and keep an eye open to their policies. Or other frameworks. A pitty, I thought I do not need to do that for some two years or so.

Quotes: 5 different views on computers and programs

2007-12-27T11:47:00.000-08:00

Oldies but goldies: Gathering famous quotes on computers, programs, users and programmers. Have fun!

The users view on computers and programs:

Homer Simpson: "The Internet? Is that thing still around?"
Ted Nelson: "Any fool can use a computer. Many do."
Jeremy S. Anderson: "There are two major products that come out of Berkeley: LSD and UNIX. We don't believe this to be a coincidence."
Dennie van Tassel: "I've finally learned what 'upward compatible' means. It means we get to keep all our old mistakes."

The programmers view on computers and programs:

Anonymous: "The best thing about a boolean is even if you are wrong, you are only off by a bit."
Stan Kelly-Bootle: "Should array indices start at 0 or 1? My compromise of 0.5 was rejected without, I thought, proper consideration."
Robert Sewell: "If Java had true garbage collection, most programs would delete themselves upon execution."
Alan J. Perlis: "There are two ways to write error-free programs; only the third one works."

The meta view on computers and programs:

Edsger W. Dijkstra: "The question of whether computers can think is like the question of whether submarines can swim."
Bjarne Stroustrup: "There's an old story about the person who wished his computer were as easy to use as his telephone. That wish has come true, since I no longer know how to use my telephone."
Dave Barry: "Computers are getting smarter all the time. Scientists tell us that soon they will be able to talk to us. (And by 'they', I mean 'computers'. I doubt scientists will ever be able to talk to us.)"
Oktal: "I think Microsoft named .Net so it wouldn't show up in a Unix directory listing."

The worlds view on Computers and programms:

Seymour Cray: "The trouble with programmers is that you can never tell what a programmer is doing until it's too late."
Eagleson's Law: "Any code of your own that you haven't looked at for six or more months might as well have been written by someone else."
Edsger W. Dijkstra: "If debugging is the process of removing bugs, then programming must be the process of putting them in."
Paul Ehrlich: "To err is human, but to really foul things up you need a computer."

The artists view on computers and programs:

Pablo Picasso: "Computers are useless. They can only give you answers."

More quotes to read at "Quotes for large software projects".

10 thoughts on successful server programming

2007-08-12T18:27:00.000-07:00

What defines succesful server software and how can it be programmed?

How to program server software successfully

Everyone uses server software nowadays, at least in the internet, but most time people are not aware of it. Therefore "successful" server software is boring. Not the technology or the creation process itself, but server software is succesful when it behaves boring. Or, in other words, it simply works. Most times you do not know it's there and if it behaves as it should one tends not to see it.

So at first, a definition of "server software" would be helpful. Server software(s) are programs that do not run on your computer directly. Results of input are computed on another peace of hardware but then the results are shown in your own program (or internet browser, this very page you are reading is nothing else than a computed result from the servers of blogspot.com).

But how are programs prepared to work in the daily server world? Just a few (apparently obvious) thoughts to achieve this goal.

10 thoughts on successful server programming

Be aware that a server program or script is not comparable with software running on your computer at home. Server software has to run self-sufficient to a high degree.
Think of an appropriate logging to relieve later-on forensic fault diagnostics. Better to log too much than nothing, users who access your server will do this in ways you never thought of while programming it. And there is a good chance that you need to narrow down what exactly happened.
Use all features your programming language provides to write solid software. If exception handling is available, use it. Finally-blocks to clean up your code? Definitely. And there is much more you can utilize, from assertions to the usage of complete testing systems etc.
In any case avoid memory leaks. If you program C / C++ be very careful, but even if you use Java / .NET or scripting languages this may get an issue for long running server software (just assume that a collection of data in Java / .NET will only get longer and longer and never shorter).
When you use external resources (i.e. databases, networks or file systems) be aware that they may fail. The least should be an explanative error message for your users. The best would be an email notification to the administrator and a retry / recover of the failing system automatically (to a second database, for example). The parts in programming I need to rely on external resources are the parts I spend the most time developing them, create fallbacks for or even use logging at most.
Try to get the configuration as precise as possible. The configuration(s) of your systems are the base your software is running on, keep it as simple as possible and as complex as necessary. To ease your way changing your configuration later on simply follow an old saying from Antoine de Saint Exupery: "Perfection is reached not when there is nothing left to add, but when there is nothing left to take away."
If possible try to set up a test system. If you do not have a spare server for that, do it on your own (development) computer. The moment you notice erratical behaviour is the moment where you do not want to mess around setting up a system to replay and find the error.
Make Backups. Nobody wants backup but everyone cries for recovery. Do not forget that you write server software and, in case something bad happened, you have to be up and running as fast as possible. Backups may help to recover fast, then you got time to search for the problem.
If you follow all these steps do not forget that "releasing" has other implications for server software. The good news is that you may not need to release client-software on hundreds or thounsands of computers. The bad news is that you might have to take your server down to release new program(part)s and believe it or not: Users don't like that ;-) . So releasing should be as fast and stable as possible. Best would be that it is rollback-able to an older (working) release.
Alas, there is one very unpopular thought left: Document it. Start documenting the structure (i.e. involved server machines, a top-down documentation of the different modules/parts of your software etc.) and the programming code inline itself. There are many guides and tools out there that help you get your documentation right, search and follow the ones that help you most here.

Though this all sounds pretty obvious it is astounding that you nearly never see systems that follow all this tips. Even if you want to you may not be able to follow all of them because of restrictions from the outer world (timelines, new "prio zero" features needed yesterday etc.). But often it helps just to keep them in mind in your daily work and introduce them eventually. And now, happy server-software-coding!

Thoughts on successful exception handling

2007-05-28T12:47:00.000-07:00

In the last article, a (very) brief introduction to the benefits of exceptions, we saw that exception handling may produce more efficient and stable code. The example was kept simple enough to provide an operation breakdown on how exceptions basically work. This article will explain how exceptions may be used for greater benefits, how programs and program parts get more stable using exception handling and how exceptions and parts of the programming efficiently interact with error handling and each other.

Why exceptions?

As stated before, many coding efforts directly flow into error handling in general. In case a simple "or die" expression is not enough when an error occurs ("or die" just stops processing of the program-code at once), exception handling provides useful mechanisms to write code that may handle the erroneous behaviour or helps finding the cause of it.

Following the IPO principle, errors in programs or program parts do occur because of a flaw in programming or incorrect input to the program / program part. Assuming we only take a single method call retrieving parameters, the following conditions which result in wrong output can be classified:

The parameters given to the method are not well defined (i.e. are wrong or empty / null where they must not be)
The "constellation" of the parameter values are not expected in the given way by the method (because if parameter "a" has a certain value, "b" must not be of another certain value)
The caller of the method simply calls it in an improper way (i.e. the environmental conditions are not correct, needed resources are not allocated yet etc.)
The method allocates external resources (i.e. open connections, file handles etc.) and does not free them (thus leading to an invalid internal state of the program, the operating system or other components like databases)
The method relies on external resources (i.e. file system, database etc.) which are not available at the moment they are needed
The method and therefor it's programming trusts on an internal state that is not correct (i.e. corrupt data/instances needed to compute the result)
The method contains a programming error

Looking at the points above reveals that only the last two arguments deal with programming faults in our method, the other five describe errors that depend on the usage or environmental states the method runs in. So while exception handling can help to identify purely written code while development, it often is used to keep the code up and running correctly in productive systems.

How exception handling is done (right).

Using exception handling is as simple as that: If you write a method and you are able to handle the behaviour without breaking the flow of your code or stressing external logic through "workarounds", you do not need exceptions at that place. The time you wonder about how you may "get this check of a variable/state into an if-then-else" - construct or you rely on methods or (external) resources which may throw exceptions of their own it's another part of the story.

Before your code gets overly complicated throw an exception. You then surely can determine the place where the exception will be thrown and, because of try-catch - blocks, you always have a defined place where your exception and the execution of your code will lead to.

And you cannot handle every error, better: exceptional behaviour, at the place it (immediately) occurs. If you write a method that, say, reads some file content and returns it as a string, and you do not exactly know from which routines this method will be called in the future, then you should let pass or (re)throw the input/output exception as it occurs in your method. What good is it to return an empty/null string if an error happens? Firstly, you will have to check for a null pointer reference anyway, otherwise the surrounding code will not work properly either. Most times checking for a null reference is as verbose as catching an exception. On the other hand, if you don't throw an exception, does returning an empty (not null-) string mean that an error occured or that the file was "empty"?

Take your time and rethink if the method where the error happens really has all informations to react accordingly or handle that error. Else (or if you are not sure how to handle this kind of exceptional behaviour at that place) throw an exception.

And never forget: If you decide to throw an exception, be as precise about the error as you can be. If your language accepts an error message to pass with the exception, make it as accurate as possible. If the language allows to specify different exceptions or even subclass exceptions, be as precise in selecting the type of the exception as possible.

Somewhere ... by and beyond exeptions?

Do not listen to people who argue that exceptions are (time-)expensive. Firstly they are right, no argument needed. But the benefit of clear, more stable and readable code leaves enough time for you to optimize your algorithms on other places more needed. Remember that exceptions represent "exceptional behaviour", they represent erronous states which only happen in special erronous cases. Ordinary spoken: If you do not throw exceptions to just simply leave a loop or code block you will be fine on the performance side of life.

And there are a couple of open points and additional benefits introducing concepts like exceptions. Some of them, more or less tightly married with exceptions, are thingies like stacktraces where you can follow the whole way of the exception through the complete code (in most languages introducing exceptions), finally-blocks and (in a certain way) assertions and closures. But handling these issues would blast this article.

Alas, one controversially discussed exception technique, the so called checked exceptions of the programming language Java, should at least be mentioned here to round off.

Checked exceptions are exceptions you have to catch or, via definition, throw up to the next ("calling") instance. A method, for instance, that does not want to catch the exception on it's own has to declare that the exception which then has to be catched from the caller of the method by default - if not, the compiler will not compile the code. This is a very controversial issue within the (Java-) community because the need to catch checked exceptions naturally leads to more programming overhead. But again, the compiler tells you that the programmer of the method wanted you to explicitely respect that this kind of exception(s) may occur - and you have to deal with it. Integration might be tough, but at least you know about the possible exceptions without consulting the documentation simply by compiling your code. I, personally, had my difficulties accepting this feature, but at least the advantages had beaten the "programming verbosity" pants off for me and I think you will love this feature as it follows your way in larger projects.

So, go on throwing exceptions, and may the catch be with you!

A brief introduction to benefits of exceptions

2007-03-30T09:35:00.000-07:00

Every programmer of a programming language has to cope with errors/exceptions and error/exception handling on a "it's all in a job" - base nowadays. But astoundingly often, exception handling and it's (more or less) proper or inteded usage is highly discussed all over and over again. This brief introduction wants to show that exception handling is a powerful tool and may be a shortcut for normal error handling. By using exception handling, programs even get more robust and less error-prone.

A tiny example without exception handling.

A program works using the IPO-principle: Input-Processing-Output. If the input is well defined and the processing is correct, the output is correct too. The following example is a little program that reads three numbers (line by line) from a text file with a given name, adds them up and prints the sum as a result, "written" step by step:

Read the name of the file as parameter of the program into variable "fileName"
Assing a variable "sum" with the value "0" (zero)
Open the file "fileName"
Repeat steps 5 and 6 for 3 times
- Read one line into the variable "line" as text
- Convert the text "line" into a number and add it to "sum"
Close the file "fileName" (the resource handler needs to be freed)
Print "sum" on the screen

The processing of this simple excample is correct, but there are pitfalls that might stop our program from working correctly depending on the input:

The program did not get a parameter to store it in "fileName"
The file "fileName" does not exist or cannot be opened
There is nothing in the file, or, more precisely, there are not at least three lines in the file
One of the three lines is/are not numerical and cannot be converted into a number

Programming this example without exception handling means that you have to check each of these error sources step by step (check-list):

if no parameter is given, go to "exit" with error "No parameter given" (1.)
if the file "fileName" does not exist, go to "exit" with error "File does not exist" (3.)
if the file cannot be opened, go to "exit" with error "File cannot be opened" (3.)
if the next line cannot be read, go to "exit" with error "Cannot read number" (5.)
if the line is not a number, go to "exit" with error "Cannot read number" (6.)
write the sum
"exit": if the file is open, close it.

This example is written in a defensive kind and shows that the most part of programming often is not the program-logic itself. Moreover it is error handling and reporting, because the user wants to know why he did not get the sum.

Using exception handling.

Using a language that utilizes exception handling will help a lot in this example. At first, the methods provided by the language will provide you with (more or less) reasonable built-in exception handling, i.e. the method "open file" will raise an (input/output) exception if the file cannot be opened or does not exist or even if the parameter for the file name is invalid. This way you will not have to check for the file of your own (though you could) but rather catch an appropriate exception and print an according error message. You define the range where an exception will be "inspected" through the try-catch - block (pseudo-code):


try {
 openFile()
 do(3-times) {
   try {
     readNumberAndAddToSum // Assuming that an exception is thrown if no number is applicable
   }
   catch(NotANumberException) {
     closeFile() // because it already is open
     printNaNError
     exit
   }
 }
 closeFile()
 printSum
}
catch(IOException) {
 printIOError
}

Wherever an input/output exception occurs (here in the method "openFile()"), the code will stop at this line and jump into the "catch(IOException) { ... }" - block. This is especially true in case the "readNumberAndAddToSum" will throw an IOException (i.e. end of file). The handling of a type of exceptions can be centralized for the whole algorithm this way.

Additionally, a NotANumberException is catched in this example too, the program then terminates. If the IO - routines and the number converting routines work correctly (i.e. throw the right exceptions), this little snippet fulfills all the "if / exit" - assumptions done earlier, without writing more lines of code.

That's all folks?

As shown above, exception handling can shorten and, in a way, clarify the source code. A detailed "which-errors-happen-if" matrix does not need to be as detailed as a matrix that shows all possibilities when only using "if ... then ... else if ..." - constructs (the check-list above). Simply try to write the program with complete error handling using the check-list and you will see the difference.

Let us enhance the original purpose: The little example of reading three numbers matured and needs to be integrated in a larger program. This way the program cannot simply be stopped via "exit" if an error occurs, we have to re-write it as a method returning the sum as a number to fit into the whole program. The question is, case an error occurs, which value should be returned? Normally, errors are indicated using the "-1" - value. But the sum could be "-1" which then will be interpreted as an error.

Throwing an exception or letting an exception through (by not catching it explicitely) is the answer to this problem. By changing the intention of the algorithm ("simply printing the sum" to "returning the sum as a subpart of a larger program"), the scope of the method changed from a single program to a part of a program. So the algorithm cannot come to a conclusion on how to react on errors any more, because it does not know the exact state it was called from (compute - print - terminate is not an option any more). Anyway, the calling instance of the algorithm can do this because it knows why it called the method, it may print an error message or show an error dialog, it may ignore the error or create a file for later processing etc. . So the caller of our newly created method needs to know what exactly went wrong and will get this information from the exception thrown: "Couldn't I read the file? IOException". "The input went wrong because there was no number? NotANumberException".

So, exception handling is ...

... an additional possibility to handle exceptional behaviour and errors in an efficient, readable and maintainable way, if used correctly. It provides you from getting headaches by declaring detailed error matrixes or by providing the possibility to even catch errors you didn't think of in first place. And remember: A segmentation fault only is an exception never catched.

Why Java might lose against Ruby (or Python, or PHP ...) in web development

2007-02-05T16:28:00.000-08:00

There I said it...

There I said it, Java might lose its rank in web development. Sun GPL'd Java and integrates scripting languages. Ruby is going on with JRuby, Python has it's JPython pendant, nowadays PHP runs/compiles on Java. But that is not enough, Java may lose the struggle for the #1 internet language.

I always thought that a language like C# will accomplish the task to overthrow the "heir to the throne", but that was a little bit naive and sounds ridiculous: Java and .NET are way too similar for that. Lisp? SML? OCaml? Haskell? No, these languages need (damn) good programmers to complete the task, and there are not enough good people out there. To shift the workload needed in IT-business kind of standardized people are needed (no offense meant!): People only thinking in mathematics, functional programming and definitions, or simply only programming recursions seem to be the wrong way to work this load. The industry needs standard tasks to be done in standard ways by standard workers. If it wouldn't be that way, no-one would program Perl/PHP/Java/C# or similiar languages/scripts any more, they would program such complex algorithms like Shell-sort in only four lines (as I did in SML more than one and a half decades ago).

The three frontier war

Many people are complaining about Java, it is fighting a three-frontier-war. The arguments:

Java is losing against Perl or PHP because they "get things done". Perl is "quick in programming". PHP is a starters programming language, fast and simple (be honest: nearly no good known project uses PHP5 with objects and Exception-handling) and, moreover, it's good for small to medium sized projects and has (like Perl) not to deal with the (typing and casting) overhead of strong typing.
Java is losing against Ruby or Python because they "get things done faster". Ruby on Rails seems to rock for (small to medsize) projects and Python seems at first glance to be a good replacement for all.
Java has, because of the mature kind and popularity, to match (or: to be a target of comparisons) with functional programming languages like Lisp and Haskell, for example, which "know what the programmer wants" without explicitely explaining it by syntax.

I do not even mention runtime behaviour, everyone knows that C (or even C++ compared to an old JVM) is magnitutes faster than Java and everyone thinks that Java still is slow. So, Java is dead, isn't it?

Let us, just for a minute, forget the discussions and the pro's and con's of the points mentioned above, all this was discussed endlessly all over the internet before. Let us not talk about the verbosity of Java programs compared with dynamic language A or the fact that programs can be written so much more elegant using language B, because in B there are not all those conventions which clog the programmer using Java.

Who is killing Java?

Though having the best intentions, Java programmers are killing Java. I know that sounds weird, but I watched that for nearly 5 years now. The fact that Java people, (better: Java software / better: Java frameworks) cannot simply "be simple" discourages. And directs programmers and projects got the train: Ruby on Rails, as an example, is the exact opposite by just being simple. Just "getting the thingies done" is what people want to see after endless fussing around with XML and EJB, hoping that it will work out anyhow. Having hundreds of pages of documentation explaining complex frameworks, who cares? Ever started a new experimental web container in Tomcat and not simply copied the web.xml without exactly knowing what's in there? It got far too complicated.

The world is watching

Continue doing complicated stuff and you will see the people running away from Java. The problem about Java is not the language, the problem about Java is that Java does not provide a "simple start" anymore, not with all the programmers using these fancy frameworks nowadays. I'm not talking J2EE - that is too complicated, too. But that's only interfacing, at least partly. Looking at the frameworks deriving from J2EE and even if you have an IDE like NetBeans or Eclipse installed, you cannot have a web/http-service up and running in 2 minutes. Too much configuration - which needs too much knowledge of how to be configured. And, yes, surely, you cannot simply talk to a database, that would not be 1337 enough, you need a second (third, fourth ...) layer like EJB/Hibernate etc., all XML / annotations configured. At least we can do it, who bothers if we need it? And who cares for SQL, anyway? There are so much frameworks, why bothering with the simple thingies 'round there?

C'mon. I heard of a project where four (practicvally immutable) database tables had to be filled with logging informations and they used the XML-ORM-Mapping iBatis framework for that. Be honest, ever heard of the word "overkill"? Nooooo, you are right: Better configuring it using XML, or even better, let the software write the configuration! Write your makefiles in XML (including self-injected file commands). Keep it unreadable, that's a kind of job-security, too! Why typing some 10 lines of code when we simply may let the preparser generate it by configuring all in fourty lines of XML?

Never mind. Just keep on killing Java.

Totally secure internet-browsing in 15 minutes

2007-02-02T02:03:00.000-08:00

Browsing the internet without fear

Nowadays, the internet is a hazardous place. There are viruses, trojans, Cookies that store and reveal your data, people phishing your money from your bank account with special worms and so forth. The problem is, you never can be sure if your computer is suffering from malware and re-routes your online-banking-request to some russia servers. Hell, I am not sure myself (and at least I am supposed to know such things).

The old solution: Rebooting your computer

In former times I solved the problem pretty easy: I downloaded a bootable Linux CD, i.e. the Knoppix Live CD. All I had to do was to insert the CD, reboot the computer and, eventually, setup the network so I could browse the internet. The advantage of such Live CDs is obvious: They start a complete and fresh operating system every time, and because they do it from CD, malware can not change the programs or data and install unwanted software on the computer. But, be honest, do you want to reboot your computer (twice, you have to start your original OS again afterwards) to simply transfer some money via online banking? Because this all was to time-consuming I stopped doing it.

The next step was to split responsibilities between different Browsers. "Daily surfing" with IE and "secure surfing" with Firefox. But again, this is not totally safe. I used Firefox more and more and because of that I had to at least empty the caches/cookies/passwords from time to time to regain a little bit of security and privacy. That was no fun, either. And you never know when security holes will be exploited in the future, even if it's Firefox.

The new solution: Virtually, no security holes

Yesterday, I hit on something in the web that sounded promising to solve these problems. It is an article about setting up a virtual machine as a window, just like any other program you use on your computer on a daily basis. The punchline is that you do not have to restart your computer to start an other operating system from a so called Live CD image, no you run the complete OS in a separate window on your desktop. Then you can use Firefox in there to browse the web. And it is easily done, too.

All you have to do is download and install the virtual machine VMWare, get a Live CD - iso-file and setup the VM environment. A so called iso-file is nothing more or less than an image from a CD named "blahblah.iso".

The steps for that (in short form, for more information please visit lifehack.org) :

Download and install VMWare for your operating system from this place. You need administrative access to install it, though.
Download an iso-image of Linux. You can find Fedora Core here (approx. 700mb), Ubuntu Linux here (approx. 715mb) and, the smallest of all, Puppy Linux here. Fedora and Ubuntu will be easy to get up and running and have Firefox in their package, Puppy Linux will need less resources but a little hands-on experience shown below.
Download the prepared VMWare configuration files from here and unzip them into a new folder. Open the file "OS.vmx" in this folder and edit the line that starts with "ide1:0.fileName =", this option must point to your iso-file. For example, if you downloaded Ubuntu and stored it in "C:\Linux" the line should be - ide1:0.fileName = "C:\Linux\edgy-desktop-i386.iso"
Doubleclick on the file "OS.vmx" (to start VMWare) and wait.

Fedora Core's Firefox is clickable as small icon left from the "System" - menue or in "Applications -> Internet -> Firefox", but this Fedora only serves resolutions up to 800 x 600

What happens is that VMWare starts the operating system from the iso-file as if it were an ordinary CD. That bears the advantage that malware cannot install itself on the "operating system in a window". Every time you restart VMWare will be as if you start it the first time. You now are safe to surf whatever you want, after shutting down VMWare your computer is in the same state than before.

The screen resolution of Ubuntu and Fedora Core can be changed via menue "System -> Preferences -> Screen Resolution", this Ubuntu serves up to 1024 x 768

Ubuntu and Fedora Core automatically get the network connection from VMWare via DHCP. If you prefer Puppy Linux (because it's smaller, does not use that much resources and therefore starts faster) you will have to run the network wizzard, select the interface by pressing on the button "eth0" and then press the button "Auto DHCP". After this you can browser via the "Browse" - icon left on the desktop.

Puppy loves the network: Start the network wizzard to connect. For me Puppy only ran using the Xvesa and not Xorg window system and does not have the Gnome desktop installed.

Some words on usability and needed resources: I prefer Ubuntu over Fedora Core because it starts faster and provides you with a screen resolution up to 1024 x 768. But this merely is a matter of taste. A Pentium IV with 2GHz (AMD 2500+) and some 512 megabyte of RAM should suffice to run the virtual machine fluently on your computer. You can "suspend" the OS using a VMWare feature, this is like normal going in suspend mode and means that the "operating system window" will be stored on your hard disk. Starting it afterwards keeps your preferences and running programs. But it keeps the cookies, too.

So, happy safe surfing and remember: The fact that you are not paranoid does not mean, that they do not chase after you... .

How to successful log in programming

2007-01-27T07:47:00.000-08:00

In a previous article, "Thoughts on successful logging", I wrote about why and how logging is done and, rudimentarily, about best practices in logging. This article now shows how successful logging can be done: Where and what should be logged and how the impact of logging on the overall performance (meaning: usage of resources and time to interpret log-messages) can be optimized.

Where and what to log or: What happens if logging goes wrong.

The simple answers to these two questions "Where?" and "What?" would be: Log everywhere, log all, then you have all the informations about your program in your log at any time. But most times, alas, there are no simple answers in life (or especially: in programming) and following these two answers will result in a couple of problems:

The log will explode with log messages, finding crucial messages will become difficult.
The log will get verbose because one incident raising a log condition might be logged more often than once (see below for an explanation).
The verbosity might be misleading. This can be the case when one incident is logged in different places in the code and therefore seems to deliver different meanings (at first sight).
Logging methods will be called more often than actually necessary and (thereby) increase the size of memory usage / log files etc. .
Gathering the informations more often than needed for the log message (i.e. retrieving additional informations, concating the message from them ...) and calling the log method will decrease the overall performance of the program or of parts of it.

Taking these problems serious and pondering a little about them will reveal that successful logging also demands a certain programming style, namely the kind that allows programmers to put the logging lines onto the right place. So let's first talk about the "where" to log, finding this answer will additionally help to clear how to log, seen from a programmers point of view.

A first example: Where to log or not to log. That is not the question.

Logging is like error (exception) handling: If you do it in the wrong place, you get too much or, alternatively, too less information. So the question you have to ask yourself is: Am I in a state of "misbehaviour" (or success) at this point that justifies a log message and - even more important - do I have all informations in this place to produce a log message I can read and am sure what exactly happened? Remember: The moment you do not work on the program every day you should be able to interpret the log message in a couple of seconds, too.

Let us assume we have methods openFile() and createFile() which return a file handle if the file could be opened / created or null if this is not possible. Then, owning a file handle we have the following methods on it: fileHandle.readContent(), fileHandle.writeContent() and fileHandle.deleteFile(). We then want to write the methods emptyFile() and moveFile(). The pseudo.code for this might look like:

function fileHandle prepareFile(String fileName) {
fileHandle = openFile(fileName);
if(fileHandle == null) {
logError("Cannot open a file.");
fileHandle = createFile(fileName);
if(fileHandle == null) {
 logError("Cannot open a file.");
}
return null;
}
// Eventually do some additional action here which justifies this method
return fileHandle;
}

function boolean emptyFile(String emptyFileName) {
fileHandle = prepareFile(emptyFileName);
if(fileHandle!=null) {
fileHandle.writeContent("");
fileHandle.close();
return true;
}
return false;
}

function boolean moveFile(String source, String destination) {
sourceFileHandle = prepareFile(source);
destinationFileHandle = prepareFile(destination);
if(sourceFileHandle==null || destinationFileHandle==null) {
return false;
}
else {
destinationFileHandle.writeContent(sourceFileHandle.readContent());
sourceFileHandle.deleteFile();
sourceFileHandle.close();
destinationFileHandle.close();
return true;
}
}

Obviously, this code will also produce misbehaviour (just look at the moveFile() - method and imagine what will happen if the source file cannot be opened). But moreover the log messages will not help you finding an error. At first, you only get the message "Cannot open file." - which file? But only changing the log line to logError("Cannot open file " + fileName + "."); will not do the trick either, though it is a lot better.

That obviously is because you can call one of the methods (emptyFile() or moveFile() ) and always only get the same log message. You do not exactly know where the error happened. The method prepareFile() is not the right place to log the message because it has not all informations needed ("am I emptying or moving a file?") to create a significant conclusion of the error that happened. The scope of the method prepareFile() is not suffice to log enough information to be precise.

Let us rewrite the methods for the sake of better logging:

function fileHandle prepareFile(String fileName) {
fileHandle = openFile(fileName);
if(fileHandle == null) {
fileHandle = createFile(fileName);
// Do not log here - this would be verbose!
return null;
}
// Eventually do some additional action here which justifies this method
return fileHandle;
}

function boolean emptyFile(String emptyFileName) {
fileHandle = prepareFile(emptyFileName);
if(fileHandle==null) {
logError("emptyFile: File " + emptyFile + "could not be prepared.");
return false;
}
else {
fileHandle.writeContent("");
fileHandle.close();
return true;
}
}

function boolean moveFile(String source, String destination) {
sourceFileHandle = prepareFile(source);
if(sourceFileHandle==null) {
logError("moveFile: Cannot prepare source file " + source + ".");
return false;
}
destinationFileHandle = prepareFile(destination);
if(destinationFileHandle==null) {
logError("moveFile: Cannot prepare destination file " + destination + ".");
sourceFileHandler.close();
return false;
}
destinationFileHandle.writeContent(sourceFileHandle.readContent());
sourceFileHandle.deleteFile();
sourceFileHandle.close();
destinationFileHandle.close();
return true;
}

As you can see, two things happened: Firstly, the logging will create better error messages, that kind you really know what happened. And secondly, more astonishing, the error handling improved. This, clearly, is based on the fact that logging and error-handling often go hand-in-hand (and you surely could do better code using exception handling and finally blocks). Or, asked in an other way: Why does anybody in 90 percent of all cases want to log? Yes: In case errors happened.

The improvement, of course, has it's price too: We needed an additional five lines to accomplish it. But this should only show one thing: Next time you think of the whereabouts of logging, simply think of the whereabouts of error-handling.

What to log.

The answer of the "where to log" already gave some answers to the "what to log" question. Errors, better said exceptional behaviour of the code (or the state of the program) surely is worth to be logged. As listet in the previous article, the purpose of logging changes as the programming work changes too. From simple checks if the program code works as desired to maintainance of the program, i.e. performance logging and logging of the proper (or improper) working of complete modules. This kind of logging should be added from the beginning on too, to a certain degree. It helps you to better understand your code at develop time and maintain the program later on in one big shot. Only make sure that verbosity will not be an issue at any time.

This can be achieved in quite a few ways and always depends on the functional blocks you want to monitor with logging. Let us assume you want to watch the processing time of a page created by your web application. A good idea would be to define a maximum time you allow the page to be rendered. Log only if this time-limit is exceeded, this way your log will only get flooded in case the program works too slow. In other cases, when performance is not an issue, try to get the basic conditions on how logging is useful (like "used time" while logging the performance) and follow them, this will keep your log slim and dandy.

Logging: A conclusion.

Let us conclude with a list of "best practices" for logging. These points merely are explained in the article and summarized in the following six points:

Try to formulate your logging messages that way that you can quickly recall the cause for the logging only by reading the message.
Treat logging like error (or success) handling: Find the right place for your logging message that has all informations you want to know. Improving the error/exceptional code handling will naturally create the places you can log easy and good. Don't log at every opportunity.
Often, less is more. Try to concentrate on vital log messages and avoid verbosity.
Sometimes, more is more. Think of the life-cycle of your program not only the time you code it, your program will go productive and certain logging messages (i.e. performance logging for memory or speed or database usage etc.) can too be very useful later on.
Use a logging (logging-API or Framework, self-written logging) that has different on-and-offswitchable log levels ("debug", "info", "error", "fatal") and is able to log into a kind of persistence layer, be it files, databases or something similar. The moment your program goes productive you will love this option for latter error analysis.
Use a logging (API, Framework, self-written) that interferes as little as possible with the rest of your code. It must not use too much resources or be overcomplex to use. Anyway, it should be able to be configured at run-time, i.e. switching debug-levels on or off, switching file logging on or off etc. .

So, happy logging! And might the information be with you... .

Thoughts on successful logging

2006-12-09T08:01:00.000-08:00

Dealing with logging the last days, again, I thought it would be time to b-log about it too. So let us dive into the questions why programmers log, how programmers log and what the best and worst practices are on how to log.

Why logging?

Nearly every program and nearly every programmer does logging. And because of that, the purpose of logging changes through the lifecycle of a program.

At first, in "programming mode", logging normaly serves as status output and is used to validate the functioning of the newly written code. The simplest example for this would be a log-line in a block of code that is placed there to prove that the block is called anyway.
Introspection is another important thing at this point: If a programmer is not sure about the variables and values of a program at a certain point, he may simply output the values, the "state" of his program, using a log.
Logging also is useful to show off errors that do not directly occur in the programming code, such as a subsystem (like a database connection) went down etc. To know about these things is vital while programming: You never can be sure that your program works fine and dandy if the environment it works in isn't.

But as the program and the programming code evolves and grows more and more to a productive system, the intention of logging changes. The goal is not to monitor the code precisely any more but rather the modules of a program and their proper functionality. The main task of logging changes to: Survey the duration of operations, their failing or their success. This kind of log-mutation often comes smoothly and not abrupt or as a sheer matter of choice because the newly needed informations are usually already needed while programming, too.

How logging is done.

Logging exists as long as programming itself does. It starts by an ordinary output to the console via "println" and does not even end with high-level logging engines that are retrievable via network connections or external logging-client programs.

It always starts the same way. At first, just a couple of informations are merely printed to the console, after that, a little package is written that fulfills this task. Then, with rising complexity, the informations need to be categorized, otherwise crucial facts are lost in too many log-lines. By the way, logging means to trace the activity of a program over time, so the output has to be preserved in files or databases or repositories of any kind. And what about distributed systems on more than one computer, shouldn't they log to one place so that surveillance of only this log-source is possible? What started fairly simple can get pretty complex over time.

To not reinvent the wheel at this stage, there are a lot of logging APIs out there in the world. But they all boil down to some base functionality:

The methods to log are - more or less - simple to call
Different log-levels are introduced such as "debug", "trace", "info", "warn", "error", "fatal" so that the importance of a log-line can be classified
Most loggings have different channels that can be switched on or of for observations
Often, the log output can be canalized into a file or similiar data sinks

Anyway, fulfilling these preconditions do not define a good logging mechanism or API.

Best (and worst) practices doing the logdance.

Inserting a line of code that logs something always arises the same question: Is this correct, at this place, this time? Will this spam the log later on or is it accurately set here?

In first sight it is a good thing to log. If you create a system that will work for some time or reaches a certain degree of complexity it always is good to (at least vaguely) know what the system is doing right now. Or which conditions might have led to a failure of the code. Computer programs are systems that react on user or data and interact with their environment on many different variables and states. To write a program without logging is like having a black box you put input in and expect the correct output to be delivered. But then if something doesn't work proper you only have that black box to look at, without any further information why your program did not work.

But, as mentioned before, logging all and everything will not work out, either. Here are some suggestions on logging successful:

Try to log a state or error just once. Log (only) at the end of an action or an error-handling block. This will reduce verbosity and makes the log much more readable.
Think about to introduce prefixes to the log messages which will give a hint where the log message is placed in the code. Example: You have a module that parses URLs, so every message might start with "ParseURL:...". This way you directly know where the logging message comes from.
Do not only think of the place in the program code where you want to log a message, but consider the environment (variables, states, etc.) to be logged, too. This way it is more easy to recollect not only the place but the circumstances from a log message itself.
Keep in mind that the intention of logging will change as the program matures (described above). Sometimes spending 10 seconds more for a log message (i.e. to additionally show variables and states in the message) will greatly pay off later on.

So much for the "where to log" and "when to log", let's determine "how to log". As mentioned before, you can use own code or prebuild logging packages. Anyway logging should be made easy for the programmer (otherwise no one will use it) and treat computer ressources with respect (otherwise it will draw the performance of the program down).

Using prebuild packages is not a bad idea. Many functions that will be needed are available and can be used later on, even if at the start you are not aware that they will be useful. But be careful selecting the logger you want to use: It's use will spread through the whole program and changing it afterwards is nearly impossible. In general the development history of logging packages displays the idea what logging really should achive a little bit: From very simple modules to "all-in-one device suitable for every purpose" loggers, they nowadays return to a k.i.s.s-approach. Doing the log dance? Sure! But keep it simple, fast and easy-to-use, otherwise it will be counterproductive and no one will use it.

This article is continued at "How to successful log in programming"

Different types of programmers

2006-10-13T06:04:00.000-07:00

Being a while in "the IT business" I saw nearly every kind of programmer you can imagine. Well, time to sum up! And pondering a little bit about that whole thing, there are kind of four types I clearly recall: The Starter, The Coder, The Programmer and The Generalist. Oddly enough, these types are not only bind to their educational background or experience, I saw developers with an academic degree and some years of experience who still were Coders or even Starters. And i saw Generalists who were career changers with just some real experience.

So, lets start to sum up.

The Starter

The Starter, as his name suggests, is more or less starting to develop programs. At the beginning often he has a kind of success hacking some code and producing quick results. If a solution works, it is a good solution for him, regardless if that solution is working fine or just la-la. This also means that he is not really interested in code-reuse, maintainability or performance at first sight. He knows that there is more 'round there in the world of programming and he knows that he is not quite there yet.

Typical programming languages: PHP, VBA, Access or similar systems.

The Coder

In contrast to The Starter, the coder diggs deeper into the concepts of programming. He is a kind of matured Coder, knows what a pointer is and (merely) understands recursion or some concepts of functional programming. Often he speaks more than one programming language but he certainly is addicted to "his favourite one" which he then defends at all means. The coder writes programs which, more or less, do what they are intended to do and therefore tends to think he is a good programmer (which naturally leads to problems because often he simply isn't).

Typical programming languages: Scripting languages, C/C++, Java or C#

The Programmer

Being an IT-specialist who understands not only the concept of one part of a program, the Programmer also understands the environment his code runs in. He not only knows that changing a part of a system does not only affect this single part, but a whole lot more like refering code, other parts of the system or complete environments. Actually, he seems to "see" the dependencies a change may affect on the overall system before he starts coding.
Furthermore, he is looking for more elegant and sophisticated solutions and thinks a lot about reusable, performant ways to solve the problems he is faced with. Typically, a programmer is a "lazy code writer", he re-thinks the problems and tries to put them into as less lines of code as possible. This leads to problem,s because he then often develops complex solutions for simple problems.

Typical programming languages: Object oriented or functional programming languages, sometimes meta-languages (like XML, UML etc.)

The Generalist

He not only sees the problem to be solved, rather he nearly has a solution to it at an instance taking dependencies in account others did not even think of. At least he was a good programmer and knows what he is talking about. Normally he speaks more than one programming language fluently and he understands the concepts behind them. Often he is used as an architect, but he likes to code some snippets on his own, too. The systems he is working on are an open book for him.

Typical programming languages: You name it... .

Of course there are more Starters than Coders, more Coders than Programmers and only a view good Generalists available in this world. But for medium sized projects my advice would be to stick with one Generalist and one or two programmers at least. This will be extremely helpful creating a product that is well-designed and maintainable.

What technology do you need?

2006-07-14T09:26:00.000-07:00

In times where IT-projects are cancelled or are never really doing what they meant to do, one question arises more often than others: What kind of technology do you really need to fullfil your tasks? In principle, this is a very simple question. In practise, this is one of the tough ones.

Well, as stated above, in principle the question is pretty simple to answer: "It is the technology that solves your problems.". If so, why does not everybody simply use the technology suited to the problem? There are a number of reasons, let me try to state some of them:

"We always used X and it was apropriate till now."
"You can solve every problem using X."
"X is better than Y, because of ..."
"We (only) have knowledge of X and cannot simply switch to Y."
"Our (co)workers know X and not Y."

Some of the above listed statements are more true (or wrong) than others. Let's have a look at them.

We always used X and it was apropriate till now.

Having a new project or problem to solve, this sentence cannot be wronger than any other, as long as the new problem is not of similiar kind like the older ones. The fact that problems were solved in the past does not really take in account that new kinds of problems may arise that can be programmed easier using another programming language or other tools. It only depends on the problem.

You can solve every problem using X.

This sentence mostly bases on the fact that programmers are much more conservative selecting their tools and programming languages than often expected. In theory, every problem can be solved unsing any computer language. But nobody nowadays would write a website using machine code or a very complex workflow system that connects to other systems around a business only using scripting languages.

X is better than Y, because of ...

Well thats a knocker. I cannot remember how often I heared that argument before and I cannot count the numbers it still was wrong then. Do listen carefully to this argument, then compare it to the needs your new project has to fulfill. You will surely find an argument against it in an instance.

We (only) have knowledge of X and cannot simply switch to Y.

This argument often is true. It often does not make sense to switch to a complete new programming paradigm if no one ever worked with it. Nevertheless, working in business programming you should always be aware of technology changes and perhaps you have a chance to spit in some new paradigms on small/lesser extensive problems and projects. This will invalidate the argument a little bit in the future and broaden the view.

Our (co)workers know X and not Y.

True too, but a little bit like the argument before. If you never give Y a chance, you will never collect knowledge in that region. And we talked about that the technique used should at least match the problem.

So what to do?

Taking the arguments from above here is a brief (of course incomplete) list what everyone should bare in mind:

Evaluate your tasks for the new problem.
Try getting open-minded, if all arguments say "Y" is better than "X", evaluate your options about "Y"
Get a background on the technologies you want/have to use. Often this may help to make a decision on how/what to use more simple.
If you got a complex problem you might want to use a complex environment. Otherwise if you got a simple problem, you might to want a simple environment.
The tougher the problem, the more tough it is to "computerize" it, meaning that simple environments may not fullfil your needs there.

This all sounds pretty simple or even flat? True. On the other hand advice needs not to be complex to work. And be honest, how often in your daily life do you really ask yourself the questions stated above when deciding how to go on in IT and project managment?

You know YAGNI? Well, here is YRGNI!

2006-07-03T13:09:00.000-07:00

A little ago I wrote about TLA's (three letter acronyms). Well, I think we all agree that pressing the world into three letters is not enough and would not work. And computer work is so much more complicated than normal work... .

Therefore (and to show that computerization is geeky) the computer industry and nerds had to top three letters. The first well known computer more-than-three-letters acronym widely known was "wysiwig" - What You See Is What You Get - which only meant that what you see on the screen is what you (mostly) get printed on the printer. I'm sure IBM hated it.

Nowadays the nerd-gossip is, as example, about words like YAGNI. And to be honest, I love YAGNI. It's an abbreviation of "You Ain't Gonna Need It". A new project starts and the client is full of ideas what might be done. Mostly he has no idea what he wants but - aren't that computers? Can they not simply do everything one imagines? As how to build an interface for department "x" smartly transfering data to department "y"? And may the workflow not simply be shown by using "z"? "At least I get all the data/workflow/oversight I need, if (or if not) ... and it's simple when ... having ..." buzzing bingo. The client is freely associating all the possibilities and opportunities even (or because?) he does not really know what he wants. At this point being a project manager, you have two ways. Nod or tell them YAGNI.

Doing the first and nod you should really be aware of what you promise. You should be aware of the implications and programming/integrational work that might follow your promise, if that all fits into your project plan and if it fits into your available data structures. Not every thing that might be done can be done in a simple way - often the time schedule does not suffice to implement it or data is not availabe to fulfill the task. That is why I love YAGNI: Tell it to the client, listen to their argumentation (perhaps it really is reasonable? If it is reasonable: drop YAGNI). And despite of what you tell them look what you can do backstage as a preparation without too much effort. This way you stay prepared and, heck, being aware of them you sometimes might realize their wishes on the fly. Both (the client and you) will not come into troubled water and believe it or not, both will prosper from that. You can concentrate on the work that has to be done and your client can concentrate on the functionality he really needs.

What a surprise for me to find an article which teaches me a new acronym (YRGNI) and tells me that YAGNI is confused with YRGNI. YRGNI means You aRe Gonna Need It. So which one is correct? Reading the article splitted the responsibilities for these two philosophies for me. And as mentioned before both are no contradictions: The one (YAGNI) seems more the "management" level, the other one (YRGNI) more the "fulfillment" part of the story. After I read the article completely I was even more astonished that I found myself in both worlds.

So, as I technician I'd say one should "think YRGNI and act YAGNI". Best of both worlds.

http://blog.qualityaspect.com/2006/06/30/when-yagni-is-confused-with-yrgni/

What, exactly, is XML?

2006-06-13T17:01:00.000-07:00

This seems a dumb question: What, exactly, is XML? But, being honest to yourself, can anybody out there explain to me in a few words what XML really is? Or, to be more precise, what is XML all about?

For a couple of years I tried to just listen to the guys 'n ladies who should know the answer and, believe it or not, I got a couple of answers depending on whom I asked for:

Listening to consultants it is the one-and-only salvage to our new computer-century, solving all problems you ever had. Not even enough, it is capable to solve problems you are not yet aware of ever to have.

Listening to the techies you might learn that all you want to achieve technically may be done using XML.

Listening to the decision-makers it is the answer to life, the Universe and everything, and that all doing one big shot.

But, honestly, can anyone out there answer the simple question: "What, exactly, is XML"? Doubt so. This is because merely (in first sight) it only is a format but then (in second sight) everyone put their hopes in it to solve problems XML never was ment to solve. I still can remember the hype in IT where, at a meeting, someone simply said: "Well to solve this problem we provide a XML interface, that should do.". Needless to say that it didn't.

And it is easy to process. There are so much frameworks, tools and API's to cover all that unconvenient stuff of "reading", "parsing" and "testing" XML (configurations) that most people may suggest to you that using XML is pretty more simple than doing without it. Never had the sensation that you needed one hour to do something in XML which could have been done in a couple of minutes without? I had.

To be more precise, the troubles I have with XML are the following:

- It is not defined which element (or tag) to use if there are more than one in one realm. As far as I know all the tools and API's take the first value they find, but it might be a source for errors, especially if you insert a new element which overrides (or better: does not override) the previous value.

- XML is not human readable. It is an exchange format with fault-tolerancy. This is the one advantage XML has (compared to, say, a fixed size record-driven format): In case an elenment is not defined, the structure is kept (mostly). But reading XML as a human reader is painful.

- XML is a format and no programming language. XSLT is a cute way to transform XML into another XML (or text or u-name-it), but XSLT is no programming language either. The moment you stop thinking of XML as a language is the moment you will better recognize how often it is misused nowadays.

- XML produces overhead. Huge overhead. Only think of SOAP-WebServices (or BLOBs represented in XML): To send one bit of information you will need to process, assemble and send some kilobytes round the corner. Agreed, SOAP-WebServices are well-defined and can simply be extended. But do you need XML-ish things for each and every problem?

So what, exactly is XML? An all-intention-problem-solver? Definitely not. An extensible exchange-format with fault-tolerancy and many available tools to deal with and transform or show it? I bet on that one.

Fuukin TLA's

2006-06-06T17:55:00.000-07:00

CEO. OOA. OOD. PHP. ROI. SOA. TTM. XML. I hate fuukin TLA's.

Do not understand me wrong: Though pressing the world in three letters nowadays seems far too easy and I do not have something personal against Three-Letter-Acronyms, they are in no way cabable to describe the world we live in today. And I don't reckon that tla's are capable to describe the days "spirits were brave, the stakes were high, men were real men, women were real women and small furry creatures from Alpha Centauri were real small furry creatures from Alpha Centauri"*.

Three letter acronyms are... three letter acronyms. It always depends on what you are doing with (or on) them, or what you might tell the world using them or what the world is telling you using them. Please understand me right: No "tla" is - as such - good or bad at first sight, but they stand for ideas and are highly able to create prejudice simply by mentioning them and activating the assotiations they create (the selection chosen at top of this article was randomly chosen, you might as well replace the abbreviations through your favourite ones instead).

How ridiculous the above mentioned conglomeration of buzz-words really is may simply be shown by building a brief job-description with them:

"Central Executing Officer is searching an Object-Oriented-Architect/Designer to build pages delivered with PHP**. In your future job you need to be able to create a vast Return-On-Investment by building a Service-Oriented-Architecture which helps us getting our products available "Time-To-Market". eXtended-Markup is no foreign -Language for you."

Buzzing-Bingo! - and I did it in alphabetical order, too. Me having to deal with that kind of fancy stuff all day you perhaps understand why I sometimes really wonder who's doing all the programming work... .

So my advice for the day: Don't rely on guys using only buzzing-bingo-words all day long. And, if possible, start to not use them for yourself.

* Stolen from Douglas Adams. Could not resist. Sorry.
** I know I did not "translate" the three letter acronym PHP because nobody would do so in a job description (PHP originally stands for "Private Home Page Tools").

At least. The web got me. Catch-22.

2006-06-06T15:52:00.000-07:00

So at least the web got me involved. And it's a little bit of a catch-22 situation for me: I do not want to blog. Well, said that you can simply prove me wrong. "Why, oh why, is he blogging then? He already said he doesn't want to do it and he did so at his very first sentence at blogger.com! Blame him, he's lying to us." And who am I to argue that, it is more than true. Not the "he's lying" point, I hope, but alas I am not a blogging kind of guy daily spreading my thoughts to the webworld, why am I doing it anyway?

The reason is as simple as the reason anyone is blogging nowadays: I think I got to say something (more or less) important to the world. And because my job does not always allow me to publish my opinion as straightforward as I'd like to do, this webspace is a place I may let off some steam gathered reading dumb commentaries or simply things I think that are not true. Writing commentaries, as I now recognize, is not the same thing as writing an article and commenting the commentaries that are the result of your own thoughts. You can learn a lotta bunch more through the latter way.

"To blog or not to blog" was the decision I had to make now. Catch 22. Well, let us see how deep the bloggin-hole goes.