Ruby on Rails
Ta-da List


December 28, 23:26 | Comments (3)

Three benefits of digital schedules

Fafner seems to believe that I enjoy digital gizmos for their own sake. Well, that's true to some extend, but the greater reason is that I'm a sucker for productivity improvements. Especially when they come with all the benefits inherent in digital schedules.

While the list of benefits that digital schedules have over their paper-based counterparts undoubtedly is longer, I have here three reasons:


December 28, 21:55 | Comments (34)

Keeping omni schedules

If you're doing Painless Software Schedules on OSX, think about doing them in the $29.99 OmniOutliner. It's incredibly easy and, unlike Spolsky's recommendation of $1,099 Microsoft Excel, let's you manage subtasks effortlessly. This leds to more detailed schedules, which in turn leds to more precise and reusable scheduling.


December 21, 14:31 | Comments (11)

Language applicability

PHP Everywhere heralds the coming of an scripting era that will consume all:

Looking down at scripting languages because it lacks this or that is short sighted because it is the now and the future of computing

Questioning the applicability of a scripting language to solve all the programming problems of the world is anything but a label of failure. Languages and environments that tries to do everything will have little value to for anything.


December 17, 11:21 | Comments (10)

The rain, darkness, and beauty of London

(Now featuring captions)

December 12, 13:38 | Comments (9)

In London until Monday

The girl and I will depart for London at 19:30 tonight and not return until Monday morning. It'll be strictly a trip of pleasure, so I expect lavish spending, splendid eating, and enormous fun to be had.

My Canon S30 has been charged and is ready to snap her sixty-something pictures before running low on battery, so I'll be sure to capture some Loud Visuals.

Oh, and I'll try to prepare a few of my backlog arguments to the questions raised in the PHP vs Java debate while I'm away.

December 12, 13:27 | Comments (5)

The merits of strong typing

Like most of the advanced OO features available to Java programmers, strong typing is often labeled superfluous by proponents of weakly typed languages, such as PHP.

The argument is the same as that used against interfaces and abstract classes. It's unnecessary language fluff when all you need is common sense programming techniques.

But the problem with "common sense" is that your idea of what that entrails is different than mine. In lack of language support, every programmer is forced to develop his own work-arounds. That makes it harder for programmers to work together (although coding standards can relieve this problem somewhat within a single organization).

Anyway, here's two primary and one minor benefits inhabiting strong typing:

Explicit statements of intent
If you believe that programming is done for "humans first, machines second" then it follows that languages that promote explicit statements of intent are more efficient.

Strong typing is a communication tool for explicit statements of intent backed by the guard of compilation.

Method signatures with strong typing tells you exactly what kind of input they expect and what kind of output they return. And the compiler doesn't allow you to break those rules.

Weakly typing, on the other hand, requires you to be verbose about in- and output requirements in comments and vigilant about checking parameters manually.

Error prevention by failing at compile time
Having the compilation guard ensure that methods aren't exposed to types that doesn't meet their signature requirements. It's about failing fast.

In weakly typed languages, you won't be alerted to programming errors, such as parsing a method a string when it expected an array, before a problem arises at runtime. That's expensively late.

Overloading on type
It's often the case that you want to differentiate method behavior depending on the parameter type passed. Strong typing makes that very easy and simple.

Imagine you have a method that's supposed to act in one way if it's passed an object and another if it's passed a string. The weakly typed solution is having a single method and manually checking the parameter type and then delegating the action. The strongly typed solution does all of that for you.

December 11, 20:08 | Comments (24)

Tricking Google into putting me first

Noting that I was ninth on a PHP vs Java googling has bought me the top spot. Lesson: Want to climb Google on a specific topic? Just talk about climbing and your current ranking.

December 10, 16:30 | Comments (9)

Effects of Apple evangelism

After suffering months of intense Apple propaganda performed by yours truely, two of my study buddies caved in today and purchased iBooks (12" DVD models). One of them even got his older brother to buy one as well. Another study buddy is strongly considering getting one.

When you create fantastic products and price them reasonably marketing can at times be had for free.

December 09, 18:40 | Comments (0)

Get IDEA 3.0 running on OS X

IDEA 2.6 runs out of the box on OS X, but who wants that when the Windows and Linux people are enjoying the truckload of 3.0 features.

Here's how to get IDEA 3.0 running on OS X:

  1. Get OS X 10.2.2
  2. Get JDK 1.4.1 Developer Preview 6: Sign up for the free Apple Developer Connection. Then login and go Download Software > Java > Java 1.4.1 Developer Preview 6
  3. Get IDEA 3.0.1 (build 688)
  4. Create a symbolic link to JDK: Go to the directory you unpacked idea688.tar.gz in and create a symbolic link to JDK 1.4.1. With the terminal in the IDEA dir: ln -s /System/Library/Frameworks/JavaVM.framework/Versions/CurrentJDK jre
  5. Run IDEA 3.0: From the terminal in the IDEA dir run "bin/".
  6. Get a evaluation key (optional): Fill out the IDEA evaluation form and wait a few minutes.

Please note that IDEA on OS X use CTRL+C/V for copy'n'pasting (instead of COMMAND+C/V). This is especially frustrating to forget on the license screen. All other hotkeys are CTRL-based as well. Hopefully IntelliJ will conform to the standard Apple way of hotkeys in the future somehow.

December 08, 23:44 | Comments (14)

Shady methods in the battle for balance

Michael Kimsal (PHP app framework vendor) gives his blessing of means in justification of the end:

...certainly there's enough FUD from both Java and .NET folks about what PHP *CAN NOT* do that pieces like this are welcomed if only to attempt to present a bit of balance.

I believe the exact opposite is true. Stooping to the level of FUD and adopting its shady tactics renders your argument untrustworthy. It robs it of usefulness for anything else than reinforcing misguided zealous pride in the pre-believers, who feel a need to be validated in their choice of language.

Worse than merely being useless, it's actively damaging the attraction of attention from the .NET and Java camps. You could claim to care little about the opinion held in those camps of PHP, but it would be foolish.

Now I'm going to walk out on a limp here, and likely draw the anger of my fellow expert PHP programmers. But I believe that the programmers in the J2EE and .NET camps are generally better educated, more experienced, and certainly larger in numbers than those of the PHP camp.

(Note that I spoke of generalities. Some PHP programmers are better than some Java and .NET programmers.)

This is a natural consequence of ease of use. PHP requires little programming prowess to get started. You don't have to know much about OOP, type-casting, class loaders, and what have you. You don't even have to compile. It's available at almost any webserver and integrates nicely with HTML from the get go. It's forgiving and informative in error.

Hence, it's perfect for and attracts learners, kind to intermediates, and selectively useful for experts (as is most tools and languages).

But I digress. The important thing is that I believe the world of PHP would do good by approaching Java and .NET in a more peaceful and non-confrontational manner. Show by execution the problems that can be solved simply with PHP -- not by vague and anecdotal comparison.

It's okay to pick common problems, such as a Pet Store, but let the reader deduce his own comparison. It's more creditable.

But I guess it depends on your motivation. If your need for validation in your language of choice is great then the road of spite is tempting. If your desire is to inspire, inform, or even persuade would-be PHP programmers, it certainly is not.

(So it's language bashing and comparison week at Loud Thinking. May I recommend tuning in next week if this bores you endlessly?)

December 06, 14:25 | Comments (0)

Compensating productivity

Additional thoughts on compensating programmer productivity all collected from the Why some programmers are 2+ times more productive? thread on Joel on Software forum:

  • X. J. Scott: "Forgot to mention that the best (top 5% or so) are ten times better than average, not better than bad. So an average 'best' programmer is worth 10 average programmers (at least). An average 'best' programmer is worth 100 average 'bad' programmers (or infinitely more if the bad ones have negative productivity which is the usual case.)"
  • Anonymous: "I don't think that figure is unique to programming. There are surgeons who are 28 times better than other surgeons. There are writers 28 times better than other writers. There are pro basketball players (Michael Jordan) who are 28 times better than other pro basketball players."
  • Anonymous: "One issue is that a programmer who is 10 times more productive than average, typically only makes 10% more money than an average programmer."
December 05, 18:41 | Comments (40)

Ranked nine on PHP vs Java

Google quickly picks hot spots. The last few days of pro-ing and con-ing PHP vs Java on Loud Thinking has boasted me to the rank of nine on a "PHP vs Java" googling. Yay!

December 05, 18:29 | Comments (0)

Chosing a platform depending on criticality

Robert Byrne writes:

Read your article on PHP vs. Java and you stated that PHP is good if the '...loss of data isn't fatal...'. I was wondering what you ment by that and if you could give an example of such a thing happening that would be great because I've never heard of such a thing.

No problem, Robert.

Different projects have different levels of criticality, which is basicly a way to define the cost of error in a given project.

Different kinds of criticality
In projects with low criticality, such as a small content management system or community discussion boards, the cost of error is small. If there's a bug that causes data loss, such as the system rejecting a discussion post because it contains invalid characters, it's not a big problem. You fix the bug and move on.

Data loss on projects with low criticality functions in a way as a testing aid. When you loose data, there's a bug. It's not worth testing every minutia.

In projects with medium criticality, such as an invoice system, the cost of error rises, but it's still possible to revert any problems that bugs create. When the system sends out a wrong invoice, the customer complains, the bug can be fixed, and a new invoice is send.

Projects with medium criticality generally require you to restore the situation after fixing the bug. It's not enough to fix the bug and then say by-gones.

In projects with high criticality, such credit card processing, it's very expensive to correct errors. If a bug causes every tenth transaction in the VISA processesing computer to round the numbers wrong, it'll be dfficult, time-consuming, and expensive to patch the wrong-doings of the bug.

High criticality projects must pay great attention to avoiding bugs because they're so costly to correct.

In projects with extreme criticality, such as nuclear reactor control systems, space shuttle launch programs, or pacemaker, bugs can be deadly. The user isn't likely to be around if a serious bug slips by.

Projects dealing with life or dead criticality needs to pay an extreme amount of care to how they handle the development process. Few measures to prevent bugs from slipping by will be deemed too expensive.

The above is largely based on principle four of the seven general design principles of methologies in Alistair Cockburn's Agile Software
detailed on page 151-153

Picking a platform based on project criticality
And it goes straight to the language debate with the question of what kind of platform you should pick to support a given project depending on criticality.

PHP certainly qualifies for projects of low criticality. Many projects have low criticality and hence will do good with PHP. It's more debatable when you move above low criticality. With strong care and forceful resolution, PHP can probably also serve projects of medium criticality. It'll require you to do a lot of work yourself, though, building mature testing frameworks that are already available in high quality for Java.

In examining criticality, as in most every thing else, it's important to pick a platform that offers the right amount of bug prevention, detection, and correction at the right price.

December 04, 16:55 | Comments (13)

Arch-PHP apologist turns FUD-monger

In yet another misguided attempt (read about the former) to prove that PHP is "The Perfect Choice" for all things web development, Harry Fuecks brings around his FUD-cannon and blasts away with the best of them.

Attacking J2EE
According to Fuecks, chosing JSP/Servlets for the presentation layer in a web application will bind you in darkness with "Vendor 'lock in' through use of inter-tier messaging protocols only supported by the J2EE standard".

The reference implementation for JSP and servlets is the completely free and open source Tomcat server. And J2EE web-apps, especially if they're primarily JSP/Servlets-based, can easily be moved between the other open source and commercial implementations of the standard. Where's the vendor lock-in?

It's arguably even easier to move a properly packaged J2EE web-application from one engine to another than it is to do the same with a PHP web-app. As the latter is easily affected by different settings in Apache configs and the Linux/Windows differences.

Attacking Tomcat and JBoss
There's apparently a "Lack of cheap, reliable and well supported platform for web deployment". First of all, PHP doesn't even offer a choice. There's one implementation of the language running on the Zend engine. Why not complain about that?

Developing against J2EE provides both excellent and heavily supported open source platforms (Tomcat, Jetty, JBoss) along with a string of commercial alternatives (BEA's WebLogic, IBM's WebSphere, and more). These allegations are outrageous, untrue, and unfounded.

But it gets worse.

The most promising platform for J2EE development is both open source and free, so of course Fuecks can't let that slide without a good FUD-blast: "...taking a risk on open source projects like JBoss which have yet to prove their mettle".

JBoss currently enjoys a succesful run in it's third major version with a fourth scheduled for Java One 2003. It had two million downloads in 2002. Where Fuecks highlights Yahoo as a major reference for PHP, JBoss can list McDonald's, Motorola, Nortel Networks, Worldcom, Dow Jones, and many more among its major references.

Tomcat apparently also deserves a good punch, despite it's incredible free and open source offering: "And before you say it, would you really want to run your business on Tomcat?"

Zealots from any language camp is bad news
Harry Fuecks is exactly what the world of PHP doesn't need. A FUD-mongering zealot that viciously attacks other open source projects and does his best to scare away any skilled Java programmers who might consider PHP as another tool in their box.

We don't need this.

Fuecks, please stick to explaining how patterns can be used in PHP (a very interesting subject), and leave the blasting alone.