A slideshow for educational blogs

I read and gladly report a slideshow with many links to very interesting educational blogs:

| View | Upload your own

Should IT projects be insured?

I recently posted a comment on a discussion whose topic was similar to the above; the the initial question was related to the very high failure rate of IT projects.

Most of my experience refers to IT product development, so I'm not talking about other things such as insuring an IT project against political instability. As other contributors have pointed out, insurance companies will consider all the risks involved, which means that with such a low success rate software projects are not so likely to be insured, at least as a rule of thumb.

Most of the times the problem lies in the process used to manage the projects, so a better process - which can result in a more motivated team - is often the best insurance you can get.

More on this on this great book by Craig Larman.

A flexibility contest

The introduction in the Hibernate documentation reports that

A relational database is more flexible than a network programming language, so it doesn't need anything like a navigation direction - data can be viewed and retrieved in any possibile way.

As this is quite a statement, I stopped to consider it a while.

In a programming language you have to consider navigability, so if you have - as in the example - a Person class and an Event class and you want to get all events associated to a person you'll have to ask the person with something like person.getEvents(), but if you also want to get all persons associated to an event you'll have to ask the event with event.getPersons(), i.e. you have to provide accessors to both classes. And both classes hold a reference to a collection of their companion class. Moreover, when you add a person to an event you have to make sure that also the event gets modified, and vice versa.

In an RDBMS you can compose all the queries you like, starting from persons or events; the only thing you'll need is a well defined relation between the tables, which tipically translates into a bridge table. You don't even need to enforce referential integrity, though this is the path to the dark side (or is it?), as long as everybody knows how the tables should be connected. So when you add a person to an event you only have to insert a row in the bridge table.

In this sense databases are more flexible than programming languages. You can write

select *
from person p
left outer join person_event pe
on p.id = pe.person_id
left outer join events e
on pe.event_id = e.id

as well as

select *
from event e
left outer join person_event pe
on e.id = pe.event_id
left outer join person p
on pe.person_id = p.id

but this comes at a cost. You need keys. And you need indexes to manage them (even if this relates to the phisical aspect rather than to the logical one). And a bridge table to manage the many-to-many relationship, which doesn't belong in the domain at all but is a pure fabrication used to represent the model. This clutters things a bit, even if we're so used to it that we don't even notice.

The Java language gives a much clearer representation of the domain (at least, the signatures of the method do):

public class Person {
  // stuff
  public List getEvents() {...}
  public void addEvent(Event event) {...}
}

public class Event {
  //stuff
  public List getPersons() {...}
  public void addPerson(Person person) {...}
}

The language shields you from how the model is represented (that's where the rigidity is hidden), and it is more natural to use.

Databases can use views to simplify data retrieval, but they don't work for inserts and updates. That's where stored procedures come in handy, but... aren't they written in a programming language? Should the latter be considered part if the database or as an external means to get a higher abstraction over SQL (which in turn is a language of its own)? How far should we push this?

My conclusion? Everyone should get their act together to make sure that the quality of what they build is the highest that they can get, either when designing a good database schema or when implementing a bidirectional association. The problem is that "the highest they can get" can sometimes be a low standard, so everyone should always try to improve, no matter how high the standard. I think this rule applies not only to programmers in their own field of competence, but to men in the broader sense.

Moving your quick wiki

Little by little our VQWiki test installation become our VQWiki production environment; it is not enough for some project management activities, but it's great as a collaborative repository.

Should you decide to move the directory in which you store the files (we did), it is enough to modify the filesystem directory in the admin page; this creates a new folder in the specified position, in which you can copy your existing files. As an alternative, you can modify the homeDir parameter in the vqwiki.properties file located in the WEB-INF/classes folder.

In the same folder you can find the ApplicationResources.properties file, in which you can give your virtual wikis a friendly name.

Here we are again

And this does not surprise me... all this hullabaloo about switching the LHC on, when no actual collisions had been planned, as only one path was active in a given moment... Was it just a rush to catastrophical news? Thanks to that, a teenager has committed suicide. I hope somebody will clean up their act and think before they talk or write.

See you tomorrow... LHC permitting?

This morning the LHC (Large Hadron Collider) at CERN, the most powerful particle accelerator in the world, was finally switched on, and a beam of protons was successfully fired around the 27 km tunnel. This is a great milestone in research, because it could lead to several breakthroughs about the "internal working" of the Universe.


The LHC is composed by thousands of elements that have to work together with great precision and very small (I mean it) tolerances. Today the system was released in a production environment, well after its components had been tested in isolation and several integration testings have taken place. I think I'll analyse thoroughly the testing process adopted in the building of the the accelerator to compare it with the software testing process, and I'm sure this will lead to interesting results. More on this to come.

As always, when dealing with things such as this, many opponents arised, concerned about the high risk involved with the experiments that could lead - they say - to the complete destruction of life on Earth (well, to say it all, of Earth itself).

A commission has been instituted by CERN to study all the possibile risks related to the use of LHC, but the results of their work still did not seem enough to alarmists.

Up to now, alarmists were wrong.

Where's my CTRL+F?

I can't believe it... when I post a blog entry in Chrome the internal search (CTRL+F) brutally ignores all the content I'm writing...

Faster than light

Probably Superman was carrying it...

Teach Yourself Programming in Ten Years part II

Ok, back to the comments on the recipe for programming success.

Know how long it takes your computer to execute an instruction, fetch a word from memory (with and without a cache miss), read consecutive words from disk, and seek to a new location on disk.

Unlunckily the great amount of resources brought us to forget the art of good programming. I know I might sound old fashioned, but I can remember more than a hell of a program running on a C64, on which only 38k were actually available, the remaining 26 being occupied by the operating system itself. Nowadays too many resources are wasted, nothing is optimized and a lot of programs are lousy. A word of caution: optimization should not be the first thing you look at, as you should first try to have an understandable and maintenable codebase, and you should really measure and optimize only when it's needed, but there's a limit for everything... Anyway, back to the subject of university, one of the exams I've seated (computer and network architecture) represents a good example of something I've really never used in a direct way but dramatically changed the way I look at software, as now I know how the underlying hardware works, and I know many programmers for which this statement doesn't hold true: e.g. you can see it from the way they write inner loops: if you know how words are stored in memory and in cache you'll chose the order which best fits the underlying physical system.

Get involved in a language standardization effort

mrghmr....

Have the good sense to get off the language standardization effort as quickly as possible.

Now this is more like it!

With all that in mind, its questionable how far you can get just by book learning.

Book learning is not enough. You must try, and try, and try. Well, better yet... Try not. Do, or do not, there is no try. And this comes from the wisdom of Master Yoda, so it should not be questioned :-) Nevertheless, IMHO books play a very important part, because they can start you up and serve as a reference, but there must be a "deliberate effort to improve", so you must bang your head on that wall: that's where my look comes from, it has nothing to do with my 15 years of rugby. And it is fundamental to share your experience with others: you have something to learn from them, they have something to learn from you.

About the three-part plan proposed by Fred Brooks: see the "Work on projects with other programmeres" part. When you work in a small firm with a small IT department it is very unlikely that there exist the conditions to follow the plan, at least inside the firm itself.

Teach Yourself Programming in Ten Years

Peter Norvig, Director of Research at Google, has published a very interesting article about the huge amount of IT-related books titled something like "Teach yourself XXX in Y days". Having read my share when I was younger, so much younger than today, I really agree with him, today more than ever.

"Day" is not the correct unit of measure when you talk about mastering something - as the article quotes, researches talk about ten years of effort: that's why you must (should) have fun with programming, because it will take you a huge amount of time. To get along with Mr. Sang Shin, you need passion.

Peter proposes a recipe for programming success, and I'd like to comment about it (I'll skip the parts on which I completely agree and I don't have anything else to add).

Program. The best kind of learning is learning by doing.

I'd like to stress the "deliberate efforts to improve" part: spending ten years programming does not necessarily mean you have ten years of experience, because you could as well count each day as the first one. I know many so-called experienced professionals who are in this situation, some of them because I caught them in the act. 

About the education: it is true that with a lot of work you could skip it, but university exposes you to a wide series of subjects, many of which might not look appealing at first glance (some of them not even after many glances), but it really pays off, as many things will come out useful later or help you to lay the foudations of your future professional growth. Moreover, you get exposed to the judgment of many experts on the field, talented people who can counsel and guide you. It's not that easy when you get to your workplace, where many people only look after their own interests (hey it just so happens that not everybody works at Google!). Unluckily (or luckily, it depends...), there's no direct relation between academic achievements and salary (sigh!). 

Work on projects with other programmers.

That sounds easy. Unluckily, sometimes you just have to rely on yourself, or on a very few other people: many customers of ours have just one to three developers, one of which is tipically a "legacy programmer". But it is a great advice, and this is where external groups (e.g. JUGs or XPUGs) come in use.

Work on projects after other programmers.

Far too easy not to follow this one. Browncode represents a huge percentage of a programmer's job, so everybody should know what we're talking about. But crap is not always the best source for knowledge, so it is also important to study and try good code - there's plenty of good open source projects out there, and if you have the time getting involved in one of them you get a very good opportunity to learn a lot.

Learn at least a half dozen programming languages.

IMHO that's hardly feasible or doesn't have the right ROI, particularly in small realities such as ours. My idea is based on the fact that a language that does not need a shift of paradigm is not worth studying (as quoted in the article) and on the necessity to optimize costs and resources. How much does it take to really understand and correctly use a functional language? is it worth the effort? In my particular case it is not, at least for the time being. Should there arise a different need, things would obviously be different. So, I would translate into "have a look at not less than half a dozen programming languages, so that you can select the one that best fits your needs on a case by case basis".

Sorry really have to go... to be continued!

Google Chrome

Google has just released the beta version of the Chrome Browser, which I've obviously downloaded and installed; pity there only exists the version for Windows Vista and XP... at least it's open source, so that everyone can get in on the act.

The Google team has prepared a comic book, which you can find here, in which they present the technical choices and the design of the browser.

The first and overall impression is quite good, it seems faster than Firefox but still occupies a lot of memory, even if (and this is good news) each tab has its own process.

The idea of the first page with the nine most visited pages is very interesting, as the shortcuts to the applications; I have got used to Firefox categories and I'm missing them, even if Chrome provides the so-called "omnibox" with increased functionalities. I will explore the different features and maybe decide to change my default... we shall see!

BTW I'm using Chrome to post this entry...

Always watch your steps

Back to work! A long time ago, in a galaxy not far away, one of my peers dropped a couple of the most important production tables in the most important application of our most important customer. I thought it would be a tough act to follow... till today, even if I was only working on small and relatively unimportant tables. So, when you are testing a system, ALWAYS double check which one you are working on.

Luckily, we believe in the three divinities of software: backup, backup and backup, so everything went back to normal unnoticed.