…have you ever noticed that you can assign one job to one person, and they’ll do a great job, but if you assign two jobs to that person, they won’t really get anything done? They’ll either do one job well and neglect the other, or they’ll do both jobs so slowly you feel like slugs have more zip. That’s because programming tasks take so long to task switch.

Yeah, that’s how it is. An old posting but still true – programmers are less productive if they have to constantly switch between tasks that are all super-mega-important for management. In fact each developer should only worry about the task at hand right now and leave it up to the project manager to decide upon the next task.

The full article from Joel is worth reading.

Wow, I can hardly believe it… In Dojo 1.6.0 my very old bug has finally been fixed…. it supports scheme less URLs, after almost 2 years, wow!

Bug closed.

I love how bugs are filed these days….

So eeMNee – this has been fixed, thanks for reporting!

After writing about Taco Bell Programming I discovered that there is a new movement called “DevOps” which goes into the same direction:

Let’s face it – where we are right now sucks. In the IT industry, or perhaps to be more specific, in the software industry, particularly in the web-enabled sphere, there’s a tacit assumption that projects will run late, and when they’re delivered (if they’re ever delivered), they will underperform, and not deliver well against investment. It’s a wonder any of us have a job at all!

The Devops movement is bold enough to believe that there’s a better way – a way of building teams, and building software that can solve these problems.

Read the full DevOps article.

And the saga continues… I reported a Dojo bug about scheme-less URLs in March (filed against 1.4.2)… now the brand new 1.5 has been released and the (simple-to-fix bug)… was not fixed.

Why? Well, I don’t know. Maybe because they don’t care? The comment in bug 8546 is:

It’s been open for 18 months, and it was pointed out to me as a bug by a large user of Dojo and jQuery. They reported the issue to jQuery, and it was fixed in 2 weeks, and we’re going on 18 months.

Sorry dojo, speed-wise you already lost, no matter what you do!

Long long time ago I wrote about The Hit List – that it is going to be the best GTD software on earth.

A little after that I wrote about how to not write software and especially about how to not communicate with users.

Finally it is time to say that The Hit List is not going to be a hit…. let me quote some statistics from CAS:

Last tweet: December, 2009
Last forum post: December, 2009
Last blog post: September, 2009
Last significant (non-fix) upgrade to THL: May, 2009

To me this looks like THL is finally dead…. too bad, would have had a great future!

RIP, The Hit List!

Sometimes I have the feeling that the only large Web site that uses scheme-less URLs is the one I work with during office hours… because not a lot of Web sites use this handy feature which allows to include resources independent of the protocol (i.e. <link type=”text/css” rel=”stylesheet” media=”all” href=”//www.domain.com/styles/main.css” /> – note the missing protocol). This works cross browser and is perfectly valid – and saves the hassle of security warnings in IE in case of secure Web sites.

Anyhow, when I used the jQuery library it turned out that these scheme-less URLs confused the .getScript function. The bug was easy to find and report and after some whining it got fixed. I mean, how hard is it? Fix the simple bug, add a test case to the unit tests (you do unit test, don’t you?), run the tests done.

Does not seem to be the case with Dojo, which experiences the same bug (already reported here and here). Not only that the bug is open since 14 month, this simple bug was reported in version 1.2.3 and won’t be fixed until version 2.0? Come on, you must be kidding! Signing up and submitting a comment or patch (1/2 line of code: || relpath.indexOf(‘//’) === 0 appended to the first if in the function _xdIsXDomainPath) is also not possible because the user sign-up leads to a 404 page. Uuups.

So I’ll end up with maintaining my local patch file, and hopefully I remember to apply the patch in case there is a future Dojo upgrade…

Recently Blogger announced that they are going to shut down their FTP publishing service. On one side I think this is not a very smart move as they’ll loose a lot of customers, but on the other hand I fully understand why they are doing this. FTP is really old, causing them a lot of troubles and prevents Google from implementing cool stuff (i.e. a mobile view for the blog).

So, what to do with my (this) blog? Initially I migrated over to a custom domain (still with Blogger), which required me to setup some redirects (mbaierl.com/blog -> blog.mbaierl.com). Not a big deal, no need to wait for the FTP migration tool, worked great and smoothly. But suddenly I had to display the Blogger Bar on top of my blog. Drawback 1. And I did not see statistics within my known Webalizer interface. Drawback 2. And: I want control!

So I started to look for alternatives – and as I manage 3 blogs in total I stumbled across WordPress MU and started the migration:

1. Installing WordPress is super-simple, I’m really impressed! Just needed to make sure it is secure by setting a few file permissions correctly.
2. WordPress can import all data (posts, comments) from Blogger – and it really works! Only Youtube videos don’t come through, so I had to re-add them manually (check out the “Smart Youtube” plugin!)
3. Luckily I did not post a lot while being on the Blogger custom domain as this required a migration of the image files.
4. Migrating the template was the hardest part – yes, there are tons of themes available, but I wanted to keep my own for this blog… but the documentation is really good and it was just a matter of hours to get a working template that integrates into my site.
5. There are tons of useful plugins – i.e. Akismet for Spam protection or WordPress Mobile Edition. That’s great and gives me way more flexibility and freedom than Blogger did! There is even an iPhone App!

Right now I’m very satisfied with the features and the performance and highly recommend having a look at WordPress if you need to migrate away from Blogger because of their FTP shutdown or for any other reason….

iBatis for Java is a good way of abstracting away the SQL statements from the business logic; it relies on XML files which contain all SQL statements and it is pretty simple to access a database. Because accessing DB2 from Java is pretty new for me I had some troubles finding a sample to setup a “insert” statement which returns the last inserted ID.
With PHP I’d use my_insert_id(), but how does it work with Java and DB2? Unfortunately all samples I could find where either based on Oracle or on the Microsoft SQL Server…. no luck.

So here is the XML required for an INSERT statement with iBatis on DB2:

<insert id=”insertTABLE” parameterclass=”TABLE”>
INSERT INTO TABLE
(…)
VALUES
(#…#)
<selectkey resultclass=”int” keyproperty=”id”>
SELECT IDENTITY_VAL_LOCAL() as ID FROM SYSIBM.SYSDUMMY1
</selectkey>
</insert>

After that the insert statement can be used like follows:

TABLE_BEAN table_bean = new table_bean();
table_bean.setXXX(…);
mySqlMapClient.insert(“insertTABLE”, table_bean);
// now table_bean.getId() returns the correct id

From now on iBatis works like a charm and the object value is automatically updated… nice!

Today I stumbled across a very strange IE issue. Again. Basically the code that was working fine in all real browsers – the code loaded some HTML fragment containing script tags using AJAX and added it to the page. Nothing complicated, except that those script tags require some special handling in Internet Explorer, as they do not execute automatically when being added to the page:

if(IE) {
var scripttags = NewlyAddedDomViaAjax.getElementsByTagName(“SCRIPT”);
var head = document.getElementsByTagName(“head”)[0];
for(var i=0, j=scripttags.length; i < j; i++)
{
var scripttag = document.createElement(“SCRIPT”);
scripttag.src = scripttags[i].src;
head.appendChild(scripttag);
}
}

No big magic and works fine. Except for the case that the script tag comes as first element in the newly inserted HTML code. In this case the getElementsByTagName is *not* returning the script node at all – it just returns an empty result set. This means that the JavaScript code is not executed in IE….

Luckily this problem is quite easy to solve – just move some other HTML code in front of the HTML snippet that is returned via AJAX – place all the script tags at its end and everything will work fine!

btw, how about Google? Not of great help, the closest I could find was this unanswered forum post.

(Image from Flickr)