The Basement Coders

I’m a big fan of the site Stack Overflow, albeit I find it tough with my schedule to fully contribute to the site but before the site was even live I was a faithful listener to their podcast.

I listened to them a lot when I was traveling last year, this was when Jeff and the gang were creating Stack Overflow. I’m done traveling and hadn’t really made the time in my life to catch up on podcasts until now. And it’s kind of nice doing it this way because you get “full seasons” of podcasts and don’t have to wait eagerly for the next. That’s how I watch TV for the most part, watching one episode a week is for the dogs. So although I’m still a few episodes behind, I managed to get through two I feel need a “rebuttal” of sorts. The two I speak of are episode 38 and episode 41

Episode 38

In this episode it’s Joel and Jeff talk about Test Driven Development and how they don’t get why it’s so useful because really if you are a software company you should just hire awesome programmers who don’t need to write unit tests. This position is pretty much born out of ignorance, and I’m not being a jerk here, I love Jeff and Joel, I just recognize their ignorance for what it is.


For instance, Joel says at one point:

It doesn’t seem like you could actually get any code written if you’re spending all your time writing 8,000,000 unit tests, and every single dinky little class that you need to split a URL into four parts becomes an engineering project worthy of making a bridge, where you spend six months defining 1000 little interfaces. They’ve just gone off the deep end, and I don’t think these people write very much code if they’re coming up with these principles, to be honest, it doesn’t even make sense.

Joel essentially explains that TDD is akin to the Object Oriented Architect who is operating up in his ivory tower, dictating what should be a really good idea in theory, but essentially is impractical in the real world and should be left to the academics to debate.

Episode 41

Episode 38 spawned a rebuttal from “Uncle Bob” — one of the pioneers of the Agile methodology — he’s also a big proponent of TDD. The episode includes Uncle Bob himself, however he’s unable to convince Joel and Jeff that TDD is for the real world and the episode essentially re-iterates Joel and Jeff’s stance that if you just hire “awesome programmers”, these time-wasting unit tests aren’t worth it.

I must admit I was left disappointed, I really thought Uncle Bob would give them the what-for, show them that TDD is alive and well outside their island code base. Uncle Bob, in my opinion doesn’t do a super job trying to convince them of why TDD make sense. I got the feeling that he didn’t want to bring into question Joel and Jeff’s coding practices. For instance, Joel brings up several times how “there is lots of code in the UI layer that you simply can’t unit test”. That should signal alarm bells for the astute programmer who has grown accustom to the Model View Controller paradigm (or Separation of Concerns in general). I really think the problem is that .NET people (I was one briefly) are trapped in the Vendor Vacuum which is Microsoft. If Microsoft doesn’t have a unit testing framework that is bundled in with .NET, then it’s probably something not worth looking into is the mantra. I base this opinion primarily on what I hear Jeff talk about during the podcasts, specifically how early on in development of Stack Overflow they weren’t sure if they were going to implement the site using this new “MVC” thing. For a person like me that’s been doing MVC web development since the 1.x versions of Struts (circa 2000), I cringed. It all goes back to Joel’s comment about all the little pieces of logic in the UI, that just shouldn’t be the case. I won’t go on about it ad nauseum, I’ll just hug Wicket and let others experience the pains of <% logic here %> programming (or “bee sting” tag programming as Jeff might say) in the UI until they too have their “ahah” moment (or until Microsoft has it for them).

On “A Hah!” moments…

I’ve done what they’ve done though; forming opinion on things that I have no experience with. I did it with the Mac, Sushi and of course technical things like distributed source control. I’ve taken a position now that if I haven’t tried it, I probably don’t have an opinion on it that is worth a hill of beans. I got the feeling that after all was said in done Joel and Jeff still weren’t convinced that TDD was for people who “really coded”…

There are just some things like DSCM and TDD that you just have to try for yourself to get that “ah hah” moment. Without that moment, you really have to be a special person to grasp firstly the concept and secondly why it’s important and useful. When I first discovered git (thanks to fellow basementcoders Marc and Alex) I didn’t really know why this was any better than svn. Then I started using it, and discovered how much more agile I could be, for instance I could be merrily working away on some future feature of a software app and instantly be able to code an emergency fix for a released branch. I can do all that without switching directories and without loosing any work I was doing on my feature.

Make Unit tests, not User testers

The funny thing is, in later episodes Jeff laments about a certain badge for which faulty logic caused the badge to be awarded when it shouldn’t have been. Instead of making his users be his unit testers, he could have caught this up front with a set of unit tests for the badging system.

It’s actually, when you think of it, pretty surprising that Stack Overflow works as well as it does. This is primarily due to the community which supports and makes Stack Overflow a success, they find the bugs early enough and the bugs get fixed fast enough that on a whole the site works. But there will come a day where the site becomes a complex set of features which start to become coupled to one another. Jeff or one of his partners will change some innocuous piece of code, and because of the lack of unit tests to support regression testing, 5 other bugs will be introduced. That’s not a “maybe it will come to that”, it’s pretty much a fact and users will only put up with so many bugs before they’ll get frustrated.

Cover your ass - the blame game goes away…

This is where Uncle Bob, I think, kinda dropped the ball. What’s one of the worst situations to be in on a project? I would say it’s when someone changes code and that change breaks the functionality you are responsible. Who gets blamed? You do, because to the others on the team, QA, Business people, it looks to them like your stuff doesn’t work.

This is precisely the problem that lead me to have my “a hah” moment with TDD: it’s inherit ability to “cover your ass”. What you do is you build up a set of programmatic tests which exercise the functionality of your unit (most likely a service, or set of services). You then set your build system to execute these unit tests anytime your program is built. If the unit tests fail, the build fails. If the build fails, it means the last change set you made “broke the build”. That is the key, you must enforce a protocol upon your developers that states “before you check anything into SCM, you build it and run the unit tests. If the build fails for any reason, unit test failures included, you fix it before you check in.
This needs to be a commandment of your development process that is enforced with extreme prejudice. I learned that from Jeff Genender, the hard way a few times. If you checked in code that broke the build, he came down on you like a sack of hammers.

The accountability comes into play if you also incorporate Continuous Integration tools. For instance any time we checked in source code at Leap Frog, our Continuous Integration server would build the code and run our unit tests. If a unit tests or compilation failed a big nasty email went around to the team, and to the directors stating “${name_of_jerk} broke the build”.

It also really helped that we had top notch QA personal, Chas Schley and Brad Epranian would not tolerate source code which wasn’t properly unit tested. They themselves were writing a series of automated testing against various parts of the system and it pissed them off to no end when all of a sudden their tests weren’t working anymore because of your change.

Knowledge Transfer

The fact of the matter is, disregarding everything else, TDD makes you better at understanding your program. If some developer on your team doesn’t know anything about how the “badging system” works, I guarantee you if you pointed him to a set of unit tests which exercise the ins and outs of badging complete with the happy paths and corner cases, he’ll have a much better chance at understanding it and being able to contribute fixes and new functionality than if you just set him loose on the code base itself.

Conclusion

I really hope I’ve made my point and I hope this helps somebody, somewhere (if not Joel and Jeff), to understand why TDD isn’t just an academic pursuit or a masochistic technique that only “obsessive compulsive” programmers partake in (as Joel might say). It adds real value, and real quality while broadening your team’s understanding of your product.

To Joel and Jeff….

I don’t know if Joel and Jeff are sick of this topic, maybe it’s been beaten into the ground too much already, but I’d love if either they would join us on our podcast or us on theirs to rehash some of the issues. So Joel/Jeff if you are up for it, let me know, I’d love to talk further.

craig Craig, General opinion, TDD

Slashdot recently ran a story on yet another “Why Linux isn’t ready for the desktop.”

This one was rather nice. It contained a nice technical analysis with only a few errors. It’s not this one that I’ll be complaining about today, it’s the millions of others of these types of articles that seem to be written by long-time Windows users that just happened to have tried Linux and need something to blog about.

Most of the time these users list install issues or driver support as their biggest issue, then conclude that because Photoshop or some other specific applications aren’t available (and assume never will be) that Linux is doomed and its users should just give up.

Unfortunately, these arguments are flawed on several fronts. First, Linux can’t do anything about the lack of availability of certain commercial applications. This is just a fact of smaller market share. As market share increases, these applications will come on board. Linux can be the perfect operating system, but if it only has 1% of the market share, your specialized accounting application that you bought five years ago still isn’t going to run (ignoring wine and virtualization solutions here). Linux is sometimes able to offer you alternatives (for example, the GIMP), but if you really need Photoshop then yeah, Linux isn’t an option to you. Only Adobe can rectify this.

Second, no one ever has to install Windows - it comes with their computers. The hardware maker has already made sure everything (hardware-wise) works out of the box. Testing and judging Linux’s install process but not Windows’ seems unfair.

As a full-time Linux user and programmer, I can’t ignore Windows and still must boot it up occasionally to compile and test my software. Every time I go back to Windows to do this work, I’m constantly reminded of the flaws Windows has, flaws that are probably ignored and invisible to the veteran Windows-only user. In fact, the flaws are so glaring, that I sometimes wonder how this crappy operating system became (and stays) the leader (answer: momentum: PC builder support and 3rd party software support). After I’m done a typical session, I snidely conclude that Windows (XP in this case, lets not get started on Vista) isn’t yet ready for the desktop, and here’s why:

Poor installer - not usable by average users (luckily they don’t have to). Lacks drivers and poor auto-detection of hardware, often leaves the computer installed without network, sound or 3D video card support. Had to go to another computer with network access to download network card drivers for the first machine. Have to search the backwater download areas of various sites, running random (and dangerous) executable installers hoping that I have the right one for my particular hardware adapter. Lots of reboots between driver installed wasting boatloads of time. Older hardware often completely unsupported in new versions of operating systems. No live CD. Unfriendly to non-Windows partitions.

Auto upgrades seems slow. Asks a lot of questions, and is very intrusive. Tries to sneak in and install additional software (WGA, IE, etc). Sometimes forgets previous refusals and nags some more. Can scare new users easily, especially when asking about installing new software or displaying EULAs. No nice (central, Internet) package management system. Add/remove programs panel in Control panel sometimes doesn’t work and doesn’t include all software. Updater sometimes reboots the computer automatically, abruptly terminating any running programs that the user may have delivery left running.

No central upgrading system for 3rd party software. Why doesn’t the add/remove program window in control do this? 3rd party (or even 1st party Microsoft like Media player) seems to do their own updating, constantly nagging the user with update and restart requests. New users can be surprised by these queries. Highly intrusive. Upgrades can easily break stuff (no proper dependency tracking) as upgrades may not just include version patches, but completely new versions of software. Not user friendly at all.

Requires virus scanner. Base operating system demands it, yet doesn’t provide one. Can be disabled though. Virus scanner makes computer much slower. Without such a scanner though, machine is highly vulnerable, especially since many required utilisation and software packages come from the Internet via the web browser as executables - not the safest delivery vector. Some kind of chmod +x system should be required - software should come in packages and/or package repositories.

No nice repository for additional software. Must find them developer’s web sites. This however can be dangerous as if you aren’t familiar with the developer, there is a risk of getting malware. There is some kind of signing system for executables, but the user can (too) easily dismiss the queries/warnings, rendering the system ineffective.

The default web browser, IE, is still quite insecure, has (had) poor web standards support and still supports ActiveX, an insane idea (from a security standpoint).

Lacks lots of basic software. PDF viewer, ssh clients, GUI ftp client, torrent client, decent zip-client, decent photo editing, CD/DVD burning software, CD-to-MP3 ripping, etc. Some stuff can be downloaded from Microsoft’s site, but this requires knowing about it, finding it and other hassles. Sometimes add-on software can wreck havoc, like after-market firewall or wifi network management software. New users would need the advice of experienced users to avoid installing malware, who have set up realistic-looking mock sites to trap and ensnare users.

Lacking lots of codecs out of the box (like DivX) with no obvious method of getting them. Media player won’t rip to MP3 by default, insisting on WMA, even though MP3 is the de-facto standard (to be fair, iTunes is guilty of this too)

The basic software that is there is not polished. The picture viewer doesn’t do EXIF rotation. Notepad doesn’t support UNIX or mac line endings. WebDAV client support is just broken.

Very unfriendly environment to developers or system admins (and other such power users). Poor command line (shell), no ssh system, non standard build tools (like make), no scripting languages out of the box, lacks many basic command line utilities. This would seem easy to fix, but Microsoft seems to like to make Windows drastically different (i.e. dislikes anything command line related or anything it didn’t invent) in this respect. This results in Windows being a difficult platform to use when working with many open source projects or languages. Developers pretty much have to be using full IDEs and packages, but even in those cases, assembling libraries and build systems is still a pain with lots of trial and error. Cygwin is a half-solution at best. A Microsoft sanctioned shell, ssh client/server and collection of utilities would be best. Apple seemed to have done it, why can’t Microsoft?

Not very customizable or tunable by hardware makers, making it an ill fated choice for netbooks. Depending on how the netbook market goes, this may or may not resolve itself. If netbooks get more powerful for the same price, then they can more easily handle Microsoft’s operating systems. However, if they get cheaper by using even lower cost components (ARM CPUs, for example), then Microsoft’s operating system will be completely shut out.

Windows, on the surface, seems like it would be a complete failure as a desktop operating system. However, it has the world’s momentum behind it. All system builds prep their products for it, all corporate technicians are trained to care and feed Microsoft’s offerings, a large software ecosystem is ready to fill its gaps and everyone has just plain gotten used to its quirks. This tolerance for crappy software is often misconstrued as being easy to use, when in fact it’s simply the devil-you-know vs the devil-you-don’t phenomena. People don’t so much think Windows is easy to use as they’re just used to its crapulence and don’t want to bother with anything else. They might even know it’s a crappy system, but at least they’re comforted in knowing that their system isn’t any crappier than their neighbours - everyone’s in the same boat.

Suffice to say, there will be no distinct “year of the Linux desktop”. It’ll be a gradual process, as Linux slowly grows into markets (netbooks, corporate desktops, servers, devices) and slowly encroaches into general desktops. Linux lacks all kinds of software, but every year, it gets a few more (free and commercial) apps (or the apps move to the web) and a few more converts.

alex Alex, General

Recently, the Scala language was brought to my attention.

Now, I’ve been around the language block a few times, having seen my share of languages. I’m aware and suspicious of the siren-like call new languages have for programmers. They tickle our programming curiosities to the core, offering silver-bullet, paradigm-shifting opportunities for increased productivity. Unfortunately, they require lots of commitment, community, support libraries and momentum to become useful, so one has to be pragmatic when adopting new languages. I tend to error more on the conservative side, but Scala beckoned me to have a closer look. These are my cursory observations.

What first drew me to Scala was its offering of type-safe and concise programming models, based on generics and functional programming. Although the key reason I use C++ is performance, it’s the type safety and concise power of templates that keeps me there. I find type-safe languages provide for more readable and maintainable code bases, something that is critical for large and aging projects. Scala seems to push for some of these same ideals.

The first benefit of Scala is immediate: it compiles to Java byte code and is able to utilize Java libraries. This means you can integrate with your existing Java code, use the plethora of existing Java libraries and reuse the man-centuries of work that went into Java VMs. This is somewhat analogous to how C++ can use C. However, C code can (mostly) be compiled as C++ code, Scala code is not anywhere near valid Java code. Although this affords the Scala designers more freedom, it creates another learning curve for Java programmers.

I may have overestimated Scala’s intended integration with Java though, as they also have a preliminary link up with .NET working. This could be interesting, or it could split its community focus.

The language itself is very functional and recursive. Functions are first class objects, specialization/type searching is handled via a powerful pattern-matching system and generics seem to be on the right track. This kind of stuff lets you build very interesting DSLs (domain specific languages), something that I think will vital for the future. This means you can build stuff like C#’s LINQ SQL query system into a programming language, without having to update the language — all done as a library. New web presentation mark-up languages, mini-programming/scripting languages, XML query/processing, etc. could all be done as libraries. Neat stuff.

My very cursory inspections with “javap”, the Java class disassembler, shows that Scala is not doing the type specific in-lining I thought it would be (for example, instantiating functions for each specific type T that is used). This means I won’t get my performance wishes out of Scala, which is too bad, since that would be more interesting that providing yet another deferred-to-runtime type system (even if it has a nice type-safe compile time checker).

It’s an interesting project, and I wish them the best of luck. Programming languages require large investments in time, community and libraries, and they’re just beginning this long road and still have a ways to go before I’d commit any large projects to them. This segways into my final, not-really-Scala observation:

Why are the Twitter guys all hot for it?

Twitter (via programmer Alex Payne) seem to be claiming that their notorious problems with scalability and reliability can be traced back to Ruby on Rails. RoR haxxor Obie Fernandez attempts to refute this. Whether RoR can handle the load or the Twitter programmers just don’t know how to use it, I don’t know or care. What I do know is that if you’re going to switch to something else, especially for your critical messaging queuing core, don’t jump to something even more obscure and untested.

Alex Payne says Scala is fun and gives him the fuzzies, which is all fine and dandy, but for god’s sake man, think about the business here and not the Scala book you’re penning. You need something scalable and tested, which usually means old and boring. That’s just business. Make Twitter work, sell it, and get (even more?) rich.

alex Alex, General c++, java, linq, scala, twitter

Those of us who have created more than our fair share of javascript widgets, who have grown to love their favourite frameworks like jQuery, prototype and script.acul.us, think we’ll simply whip off a widget for our Facebook application in no time flat. Hell, we’ll probably just use some existing ones, add a few tweaks and be off to the races. Then we come up against a daunting reality…. FBJS is Javascript, but it’s Javascript running within the framework of a Sandbox

Read more…

craig Craig, General facebook, fbjs

Checkout this series of articles I’m involved in over at Mystic Coders called The Five Days of Wicket. The purpose of the article is to show how to create a properly layered Wicket application complete with complimentary frameworks such as Spring and Hibernate.

craig Craig, General

I recently came across this C++ Soup post, which demonstrates some cute C++ tricks. Now by cute, I mean stupid, similar to Dave Letterman’s segment “stupid pet tricks” (you can google that if you’ve never seen this). It’s a useless language exercise with little practical application except to show how obfuscated one can make C++. Are there any benefit to these tricks? Lets explore.

Now all C++ programmers do this (myself included) just to see if they understand template programming, so keep in mind that this is NOT a critique of this particular author, who I’m sure is a C++ Ninja. It’s just a recent example that triggered this rant. No, just have a look at half the boost libraries to see this thinking taken to the extreme. Or even the C++ standard library; does anyone really use the cumbersome std::for_each function or any of that bind stuff? They all feel like they’re unfinished ideas: they’re onto something, but they’re not quite there yet.

These (what I’m calling) C++ tricks are often segments of templated C++ code that push generic programming to solve some kind of basic problem, that is typically solved using simpler (but more verbose) code. A trick author is often amazed (and proud) at how small or flexible the code is, but hopefully realizes that the amount of work or expertise required to make the trick outweighs most benefits. The code is then shelved. Lets cut this silliness out.

Furthermore, most application developers will steer clear (or be ignorant) of such tricks, and popular C++ libraries do well to not require such expertise from their users.

Is there any benefit to these tricks? Yes, only to show what could be possible with C++.

C++ is an extremely powerful language, giving you compile time dynamic/generic programming with no loss of runtime performance. No other language does this so fully and completely, and C++ is still the only language option in many demanding areas.

However, the language needs to grow, and it needs to grow fast. We must look at what these tricks are trying to do, and then think how we can change the language to do the same thing in a sane, logical fashion. C++0x is working on this with lambdas, type inference, better error reporting and some other niceties. But we needed these features yesterday, and get people using them. Lets steal more features from other languages. Lets turn up the meta programming capabilities so we can extend the language without meta-compilers and preprocessors, which until now provide the bulk of the useful new language extensions.

There is no reason why C++ can’t offer easy to use and powerful compile-time dynamic programming, resulting in code that looks like a dynamic scripting language, but with safer types and kick-ass performance, memory use and code size.

Lets get to work

alex Alex c++, tricks

If you are like me, I have a “central” git repository on a computer I backup regularly. On my laptop/desktop I do all my work and make sure to do constant pushes to the “central” repository.

Just thought I would mention that I follow the method listed here to do this. His post is spot on and he gives a really good dissection of what is going on behind the scenes.

Great job Toolman Tim!

craig General

The Linux Outlaws Podcast recently (in ep. #75) had an interview with Miguel de Icaza on the topic of Mono. Since this is often a heated topic among Linux hackers, I figured I’d chime in with my two cents.

Miguel is well know in Linux land, having started the GNOME desktop and countless other desktop applications for Linux. He’s done more for Linux in the past decade than most (including myself) will ever dream of doing, so critiquing such a leader can’t be done lightly.

Miguel unfortunately started out as a typical C-only guy who looked on C++ as large and useless. For years with GNOME he and application developers (myself included) slaved away using the C-based GTK+ library to make graphical applications. Man-centuries were wasted dealing with cumbersome C and its unforgiving API style. C++ was ignored, almost laughed at, despite the fact commercial C++ GUI libraries have been the norm. To this day, GTK+ is still an utter failure with respect to commercial application adoption.

Eventually, even Miguel realized that C was not the language for desktop application development as it was hurting GTK+ adoption. Rather than embrace C++, he threw out the baby with the bath water and embraced C# itself for GNOME application development with the Mono project.

The Mono project is an open source implementation of Microsoft’s C# language and runtime for Linux and other operating systems. Although one goal of this project is very honourable (allowing custom/vertical/boring applications from Windows-centric shops to be usable under Linux), I think in general Microsoft is making a sucker out of the Mono developers and users, and here’s why:

Microsoft was once an innovative, competitive company. That however, was along time ago. They’re now a convicted monopoly who still to this day function primary to lock people into their various technologies. I don’t want to sound like a typical “Microsoft is evil” parrot but this is what a monopoly does. I can’t fault them for it, but let’s not be naive. I can spend a blog post alone on Microsoft’s various transgressions, but for now I’ll simply rat off areas which they really like to maintain their monopoly lock-ins: file servers/smb, office formats, web browsers/ActiveX, web browsers/IE stagnation, media formats/codecs, flash/Silverlight. Heck, I can’t even access my company’s MS Exchange web interface in Firefox without getting a substandard interface to email. They can’t (well, don’t want to) even make a website without trying to lock-in you into Internet Explorer on Windows.

Microsoft is not stupid and understands that platforms are really about capturing and holding developer mind share. Java and similar truly multi-platform technologies that they didn’t control was viewed as a huge threat to the Windows empire. So Microsoft “embraced and extended” Java-principles, gave it a new name (C#) and injected a boat load of Windows-specific stuff into it. We can debate the finer differences between the languages until the cows come home, but fundamentally, at their core, they’re identical languages, except that C# isn’t multi-platform and is very Windows-centric. By the way, Adobe’s flash/Actionscript is the next threat and target after Java, so look out for a serious assault on that front from Silverlight.

Given this, it’s easy to see why Microsoft likes the Mono project. They get to pretend C# is multi-platform (”see, we’re not a monopoly!”) and friendly towards Linux and open source, but they don’t have to devote any of their own resources to it. Furthermore, Mono on Linux will never be a first class citizen (like in Java) and will always be a version or three behind, lacking in proprietary features. To get the “true” C# experience you’ll still be sold a Windows system. Microsoft gets to point to Mono and claim that C# is multi-platform, but will then tell you you must run their version on Windows to get the true, modern and full experience. This basically relegates Mono to (using the colloquial term) being Microsoft’s bitch.

Although I used to code a lot of Java, I’m not really a Java proponent. But honestly, if the Linux desktop needs a garbage-collected, byte code-interpreted, type safe and object-oriented language, then Java is hard to beat. Decade or two of testing, mature IDEs, plethora of libraries and truly multi-platform (first class citizenship for Linux) and now open source (I hear?) are all features that would be stupid to ignore. But for some reason, Novell decides to chase Microsoft’s ever changing specs while having to rebuild everything from the ground up.

Miguel ends off the interview with what I think is a little Stockholm syndrome. He says that most people unfairly demonize Microsoft, ignoring the specific points (like the above) those people make. Heck, he excuses Balmer’s public demonization of Linux as the spouting of a sales man, ignoring the fact that this is the CEO of the big ship Microsoft. One simply needs to use non-Microsoft operating systems and applications in a Microsoft-based shop to truly understand the breadth and effect of their monopolistic lock-in.

But alas, I realize that there are other factors here in Novell’s decision to fund Mono. Novell is scrambling for money and business opportunities, looking for any edge against Red Hat, even if that means dancing with the monopoly Microsoft. Although you can’t fault Novell for doing what they think is in their best business interests, let’s not get delusional into thinking Mono is on some level playing field with Microsoft.

alex Alex, General c++, gtk, microsoft, mono

Integration–the process of porting ones build artifacts from a development to end production environment–in my mind is the biggest unknown for a software project. Production environments are usually locked down, log files are hard to get to and requests for provisions or server resets — long to wait for. What’s even worse? When your integration process involves not only the end goal of “hosting” your application, but also incorporates build and deploy processes and policies that directly affect your code base.

For instance, a client I worked for needed a site. They provided a nice set of requirements and wireframes, in fact they provided all visual aspects for the site mocked as ASP pages (including the AJAX elements). What more could I ask for? It seemed like the perfect storm, a developer I hired would swoop in and add the dynamic elements to the site and we would be done in no time.

We weren’t limited in the frameworks we chose in fact early on it was assumed the client only cared that the end result ran fine under IBM WAS. No problem (I thought), WAS is a servlet container and that’s the beauty of Java web development, there is actually a spec describing the functionality of application servers. This means that the application being produced should operate in a bubble of sorts, it should know nothing (well that’s not always possible) of where it’s living, it’s just a war and it needs a place to live.

Then reality kicked in. About a few weeks into the project the client presented a “Build and Deployment process for the <insert internal acronym> environment” document. As far as the build document was concerned Ant was the only real requirement. Their continuous integration (CI) tool however did support Maven which was great because Maven is what I used. So, with too much trust in the reasonability of clients we continued on our development path.

Read more…

craig Craig maven

In about a month, Nokia, owners of Troll Tech, makers of the Qt widget library will release Qt 4.5 under the LGPL license. In a web centric world desktop application programming may seem unhip and uninteresting but rest assured, this is huge news, especially for desktop app developers and potentially mobile app developers (Nokia’s primary intent here is to build a platform, after all).

Qt, for those that don’t know is a very nice, well polished, comprehensive graphical application building toolkit. It’s a complete C++ toolkit done right: multi-platform, easy to use and well thought out. It shows to the Java/C#/etc crowd that C++ development can be fun again, it just needed a unified, nice and easy to use “standard library” that covers ALL of the things developers want to do, on all platforms. The C++ “Standard Library” only covers the most basic of things, like strings and files, leaving the C++ developer to go hunt down other libraries to fill in that last 90%.

Prior to the LGPL version, you had to use either the GPL version (requiring your software to be also under the GPL, i.e. free) or you had to buy some commercial licenses, that aren’t cheap (a few thousand dollars, usually). The LGPL basically lets you have your cake and eat it too: use the free downloadable library to make applications under any license, for free. This will undoubtedly destroy Troll Tech’s income, but the mothership (Nokia) views this as a cheap sacrifice, if it gets them developer mindshare.

As a Linux (well really, multi-platform) desktop app developer, this is a godsend.

Unless you were willing to cough up the dough for the expensive commercial Qt licenses, you where left with few choices, each with their own downsides:

GTK+: poor support under Windows, missing lots of mature features, verbose/cumbersome API and worst off all: it’s a C library. Now, I know it’s cool to hate on C++, especially from people who don’t know the language (especially C programmers who’ve just dipped their toes in the language), but C++ is still the best way to write compiled-to-native code across multiple platforms with full performance. Period. Full stop. GTK+ programming tends to be so tedious, that everyone seems to do their own light C++ wrappers around the core classes, which has to tell you something. Heck, the GNOME desktop people are trying to push Mono (i.e. C# & GTK) as the new solution, because even they admit C & GTK+ is too messy. For the record, even though I like and use the GNOME desktop, the developer side of me hates the GTK+ library API.

GTK- -: a C++ wrapper around GTK+. Good idea, but it’s still cumbersome under Windows and dealing with a framework around another framework is frought with issues. It’s also not that popular, leading to less community support, application examples, testing, etc. You don’t want to commit your large application to a toolkit that isn’t supported, well tested, etc.

FLTK: never used it personally, but it seems small (in community and support), similar to GTK- -.

wxWidgets: After getting fed up with GTK+, I moved to wxWidgets. wxWidgets is a decent library, that seems to work for the most part with a few rough edges, nothing that can’t be worked around. These rough edges, a few missing features (database support, for example) and slower development progress is all simply a result of it being a fully volunteer effort. It’s a great library, and I’d still be using it if Qt wasn’t going LGPL.

So to sum up, Qt is awesome. It’s multi-platform, well documented, wildly adopted, broad in features and is joy to use. LGPL licensing will boost the quality and quantity of apps on the Linux desktop: by lowering the barrier to entry and by ported applications coming from Windows. Windows application developers will now be enticed with a free toolkit, which they can then later use to quickly bring their applications to Linux or Mac OS X. Finally, this same API can be used on mobile phones, making Nokia’s dream of “Qt Everywhere” come true.

alex Alex, General c++, gtk, qt, wxwidgets