random.out

The Times They Are A-Changin'

2012-01-25T11:03:00.000-05:00

"Apple reports record revenue, profit for fiscal first quarter."

It's hard to believe it, but this month marks the 15th Anniversary of Steve Jobs' official return to Apple following his ouster in 1985. At the time he was just considered an adviser to CEO Gil Amelio, but it wasn't too long before he was back in control of the company that he and Woz founded.

In that 15 years, Apple has gone from being in such dire straights that it struck a deal with Microsoft to stay afloat, to being the single most profitable technology company in the world.

That has to be the single most impressive accomplishment ever for a CEO to achieve.

"We have done the impossible, and that makes us mighty."

2012-01-18T20:48:00.000-05:00

PIPA Support collapses.

Congressmen Begin to Abandon SOPA Ship.

Score one for the Geeks.

Kindle Fire

2012-01-14T11:32:00.000-05:00

I was given a Kindle Fire by the wife and kids this past Christmas, and I've spent the past few weeks playing around with it reading some books, running apps and whatnot. I haven't fully exercised all the capabilities of the device - I've just been going about my normal day-to-day activities with tablet in tow. So, this isn't a very thorough evaluation.

It's not an iPad
I won't even waste time doing a comparison - the iPad is still far and away a better general-purpose tablet than the Kindle Fire - no question about it. And after working with the Fire for a while, I'm pretty sure that these two devices aren't really intended to compete directly with each other, anyway. The Fire feels more like a souped up eReader than it does a full-fledged tablet.

That being said, I do think the Kindle Fire is better than the iPad in one respect...

Form Factor
While the late Steve Jobs may have felt that the iPad display size was what everyone wanted, I personally find the smaller size of the Kindle Fire to be better. The device feels like something I want carry around wherever I go, and more like something that augments my daily life (like carrying a day planner, for example), where the iPad feels closer to carrying around a small-ish laptop. The Fire easily fits in the pockets of several of my coats and doesn't feel uncomfortable carrying around that way, either. Even with a thick case over it, the Kindle Fire feels like a natural fit for carrying around wherever I go.

The Carousel Sucks
Rather than the typical home screen and launcher you see on most Android devices, the Carousel is what greets you the moment you power on the Kindle Fire. It's a Cover Flow-like interface that shows you the most recent books/apps/whatever you've been using and allows you to quickly page through and open them. It's a cross between the standard launcher and app switcher (long-pressing the home button) that most Android phones have.

I'm personally finding the Carousel more of a nuisance than anything. While it seems to work OK if you find yourself going back and forth between a couple of books/apps/whatever, if you're someone that might constantly switch through a large number of items on the device it starts to get a bit cumbersome to use. I've found it easier to just select the category tab at the top and go right to what I want rather than sit there paging through the Carousel.

The Carousel UI also seems a bit buggy: It doesn't always pick up when you're trying to select the item being viewed and will sometimes rotate to the next item. Rather annoying.

Amazon Integration
The Kindle Fire's greatest strength is its integration with the Amazon store: Once you've signed in to your Amazon account, the device basically becomes a direct link to Amazon.com (assuming your WiFi connection is active, anyway), allowing you to browse and buy new apps, books, or even non-Kindle items quickly and easily. The experience is pretty seamless - it's almost scary how easy it is to buy stuff through the Kindle Fire.

It's pretty clear to me that this is Amazon's big reason for making the device - it's an extension of the Amazon shopping experience. And if it's true that Amazon is selling the Kindle Fire at a loss, I can totally understand why they would chose to do that: The increased revenue they'll have from reducing the barriers to the Amazon shopping experience more than makes up for any loss they might take from selling these things below the cost of manufacture. It is very well done.

WiFi
WiFi-only works well for me since I'm almost always within reach of a WiFi hot-spot these days. That being said it will be interesting to see what kind of sales Amazon gets for a 3G/4G version of the Fire: Having a device so tightly integrated with the Amazon store that's accessible anywhere would be a huge boon for Amazon.

Just imagine: Customers walking through the local mall checking out products, only to whip out their Kindle Fire 2 (or whatever it's called), punch up the product (or take a picture with the built-in camera, maybe?) and buy directly from Amazon instead. Brick-and-mortar stores won't stand a chance in this kind of environment. It'll be interesting to see what happens.

eReader/Books
Prior to the Kindle Fire, I've never owned an eReader: I came close to buying one of the original Kindle models a few years back, but unlike most people I wasn't particularly fond of the E Ink display (it looks really good, but I just wasn't happy with it when I saw it). I'm likely one of the few people that actually prefers a bright, back-lit screen like the Fire has over the ones on the original Kindles (it's probably all those years as a developer constantly reading on a computer screen that has warped my preference that way).

After reading a few books on the device, I can say that, for the most part, I'm happy with the eReader on the Fire. The only exception would be the one technical/programming -related book that I've looked at so far: I have noticed some elements - code samples in particular - aren't formatted properly and can be hard to follow. I'm not sure if this is necessarily the Fire's fault or just the eBook in question not being formatted well for the device, but it is a slight annoyance.

Viewing PDFs (I've accumulated quite a few PDF-formatted eBooks over the years) on the Fire isn't particularly great: The built in viewer seems to work well enough, but many of the PDFs I have require adjusting the zoom level in order to read properly (which is really the fault of the PDF creator), and the built-in viewer doesn't seem to provide a way to pin the zoom level while paging through a document, so I'm constantly doing: "zoom, read, change page, zoom, read". It's possible that a third-party app might work better for these files, but I haven't explored that just yet.

Web
Web browsing is pretty good on the Fire: With one exception, I've not run into any serious issues browsing whatever I want on the device and the Silk browser doesn't seems to have any real issues with any sites that I've hit so far, and overall the browser is very responsive.

My only issue has been that I can't seem to access my Safari Books Online account worth a damn on the Fire through the web browser: I've been greeted with glitched behavior and poor visibility of books, which has made the Fire all but useless for one of my most important resources online. This is more than likely something that O'reilly has to fix on their end since it's likely their website that is causing the issue, but it is a real downside for me currently as I make use of the site a lot for reference and it would be really nice to access that on the Fire rather than constantly switching between windows on my PC.

Apps
I admit I haven't really exercised this part of the device much, but I've found the Kindle Fire runs most of the apps I've looked at pretty well. The Amazon App Store has a pretty solid selection to chose from, although it still feels a little sparse compared to the Android Market. I've checked out a few free games and they all run well (better than on my Android phone) and I haven't encountered any issues with any apps I've run so far.

Also, despite being locked out of Android Market it is possible to side-load apps if you wish: It's a little cumbersome to do, but it's not really difficult at all. I have yet to try to side-load anything, so beyond knowing it's possible I'm not sure what kind of issues there might be.

As a developer, I would like the ability to either unlock or otherwise have a way that makes it easy for me to load and test my own apps on the Kindle Fire. This seems like something that Amazon should have available, particularly if they want to encourage developers to release their apps on their app store.

Data Cable
My single biggest gripe with the Kindle Fire is that Amazon chose not to provide a data cable for transferring files to/from a PC. This is likely because they are expecting people to make use of their cloud services (and they do provide a convenient way to push documents to the device via a custom email address to send documents to), but for people with a large number of files to move it's much easier to just plug the device into a PC and move things that way.

Fortunately I already had a data cable available to me thanks to the combination charger/data cable that was provided with my cell phone, but seriously Amazon...give us a damn data cable.

Conclusion
Overall, I'm happy with the Kindle Fire. It's a solid device with a capable eReader, web browser, and the integration with Amazon makes it a pretty compelling device to use. It's no iPad, for sure, but I think it's more than capable of fulling the needs of someone who can't afford to shell out the money for Apple's tablet.

Government Work

2011-11-08T21:43:00.000-05:00

Last week I came across the Confessions of a $600 Hammer on Slashdot. As a former member of the Overpriced Tools of the Federal Government Club, I couldn't help but nod in agreement with a lot in that post. All the same, I think it doesn't necessarily paint a complete picture of the situation when it comes to government contracting, or government IT in general.

It's definitely true that incentives are completely out of whack when it comes to the bill rate/pay rate disparity for contractors, but this isn't a problem unique to the U.S. Government, either. In fact, it's prevalent in the private sector as well: I once worked with someone whose previous job was working for a large, well-known tech company as an on-site tech servicing many of their customers, and while the pay rate this individual received was pretty damn good, it paled in comparison to the billing rate that this company charged their customers, and makes the disparity commonly seen in Federal contracts look quaint by comparison -- and mind you this individual wasn't working on Federal contracts at the time.

Nevertheless, this doesn't really excuse the situation: It's a travesty that the U.S. Government (or more appropriately, U.S. Taxpayers) will get overcharged to such a high degree, and doubly so when the contracting companies turn around and either hire sub-standard labor to fill the positions (the most common approach, based on my experience), or force out anyone competent enough to do the job by refusing to pay whatever the going rate is for the work being done (in which case they simply leave for greener pastures), thereby guaranteeing that any work done will be sub-par at best.

But the flip side of this is that you have plenty of individuals on the government side of the equation that have no business being paid for doing same kind of work the contractors do, either. Many of them are paid considerably more than the contractors (albeit less than the bill rate of the contracting companies). In fact, while the work the contractors do might be sub-par, sometimes it's leaps and bounds better than what the people on the government side are even capable of.

I have personally witnessed individuals -- government employees -- who were supposed to be Software Developers yet were unable to understand basic logic, could not solve problems at all, and couldn't write a simple "Hello World" program even if you gave them the code to type into the editor. I once waited months for a single "database developer" to code up one simple stored procedure to save a record to the database (I wasn't permitted to do it myself because I wasn't classified as a "Database Developer"...but that's a whole other story...); The individual barely understood how a database even worked. Thankfully there was someone else -- a contractor -- that was able to complete the work and thereby allowed me to get my own work done.

Even in the cases where people on the government side actually knew what they were doing, their experience was woefully outdated: In my time as a contractor, there were people on the government side having fits about getting rid of ColdFusion....in 2007! I've had to spend far too much time having to convince people to use tried-and-tested technologies that were already years past their prime just to try to drag them into the 21st-century way of developing software...many times failing in the process.

I'm certainly not trying to paint all government employees as incompetent (they most certainly are not), but only trying to illuminate some of the other issues around government contracting that people don't think about: When people hear how the badly the Federal Government gets overcharged for contracting work, they cry foul (as they should), but they never see that taxpayers might be getting overcharged on the government side as well -- through over-paid and under-qualified workers who really have no business doing the work they do, or through deliberate internal politics...not just the contractor-in-the-back-pocket-of-the-politicians kind.

Of course, I haven't even gotten into the internal politics part of the equation...but that's a story for another day...

Changes

2011-11-07T21:37:00.002-05:00

I finally broke down and set up a custom domain for the blog, and as a result the name of the blog has changed.

Welcome to my wonderful new/old blog!

I didn't really have a problem with the blog being under the original Blogger domain, but it felt like I needed a kick in the pants to get myself posting again and this seemed like a good way to do it (and I wasn't particularly happy with the original blog name, either. That's what I get for not putting much thought into it, I guess...)

I thought about moving off of the Blogger platform altogether, but decided to stick with it -- it's about the simplest platform to use and it's served me well over the years...and I'm patiently awaiting the integration with Google+, which will make things more interesting I think.

At any rate, the updates should get more frequent now that I'm getting things situated.

Bye Steve

2011-10-05T23:22:00.000-04:00

Steve Jobs had already secured his place in the annals of computer history long ago with his initial founding and stewardship of Apple Computer and essentially creating an industry from scratch by bringing the Personal Computer to the masses, then pushing that nascent industry even farther with the creation of the Macintosh at a time when things were just getting started.

It was just icing on the cake that he was provided the opportunity to do it all again in the modern world of mobile computing.

Steve Jobs wasn't a superhero, or a god. He was just a guy with a vision, strength and willingness to bring us all along on his journey towards the realization of his ideas...whether we liked it or not. Even those that have not used a single Apple product in their lives have been touched by that vision in some way or another.

Not many people get the opportunity to have that kind of impact on the world.

I truly wish we could have seen some more of those insanely great ideas.

Damn.

A Gamble? I don't think so...

2011-10-03T18:36:00.002-04:00

This story (found via Daring Fireball) made me chuckle.

Throwing all of your resources behind getting the most popular electronic device in the modern era isn't a gamble...it's betting on a sure thing.

No one in Sprint's upper management is ever going to get fired for choosing the iPhone.

Timeline: What's the Point?

2011-09-24T11:54:00.000-04:00

I personally can't seem to get worked up as much as everyone else has with Facebook's latest enhancements. Timelines certainly look interesting, and the engineers behind it appear to have done a pretty impressive job designing and creating the new feature, but I just can't seem to get all that excited about it.

I think perhaps a lot of it has to do with the way I (and in fact most of my friends and family) interact with Facebook: We all treat it mostly as just a communications platform -- a way for us to quickly and effectively get in touch when we need to. Sure, we'll share photos and videos or what have you, but for the most part we use Facebook for it's core feature: Communication.

That's why I've found myself asking, "What's the point?" when I look at the possibility of creating a Timeline. I'm not the kind of person that really feels the need to put my entire life's history out there on display, and the majority of the people I interact with on Facebook are the same way -- I'm sure there are a few that tend towards being a bit narcissistic and would revel in showing off all the great things they've done in their lives, but the rest of us just don't care that much to do something like that. We just prefer talking to each other more than anything else.

This is why I have a hard time accepting that Timelines are such a great feature: It has nothing to do with enhancing Facebook's core -- and extremely powerful -- ability to get people to connect and communicate with each other in an efficient and effective manner, and instead tries to get them to show off their lives...

...the problem is most people aren't show-offs.

Java Lambdas

2011-09-09T11:00:00.000-04:00

So, we finally have the syntax figured out for Lambdas in Java. My thoughts:

Kudos for avoiding the "not invented here" syndrome, and choosing a syntax that's intuitive and in wide use already, rather than inventing something from scratch like they were originally trying to do.
That being said, it's about damn time. It shouldn't have taken this long just to decide on the syntax. I shouldn't be too aggravated, though, since the lack of progress in advancing the Java language has contributed to the rise of alternative JVM-based languages, and allowed me to work with languages like Groovy and Clojure, which are vastly more pleasant to work with on the whole than Java is at this point.
This is only half the battle: The other (and in my view more important) half is how this gets implemented under the covers: I've always felt that a big issue with implementing Lambdas in Java is the fact that functions aren't first-class objects (you currently cannot create a function/method independent of a class), and trying to get them there would likely require some breaking of backwards compatibility...assuming they want to go in that direction at all. This is the same kind of issue Sun faced when implementing generics for Java 5 (and pretty much everyone thinks Sun bungled that pretty bad).

At least they're making progress.

Finally.

Code Reviews, SD Processes, and Using Your Damn Brain

2011-07-08T11:41:00.000-04:00

Maybe I'm just in a bit of a mood today or something, but I came across this on Slashdot today, and it kinda made me mad.

Now, I want to be clear here: I don't have any problems with what he's saying about Code Reviews. There are good reasons for doing them, and in fact I'm in the process of helping to establish just such a review at my new job. In our particular case, I'm not coming at it from a "you must justify the code you wrote" approach -- because honestly I think that's an insult to most developers, and it tends to create a situation that's hostile to new ideas (and developers) or changes that might actually be necessary. Instead, we're doing it more as a way for everyone on the team to communicate ideas, because currently too much development happens in isolation.

What I have a problem with is the attitude that something (be it code reviews, unit testing, or whatever) has to be done when performing software development.

Um...no.

This attitude tends towards Silver Bullet thinking, and it's a mistake to think that what you do should be applied everywhere.

Are code reviews good to do? It depends.

It depends on the developers: Are they open-minded about new ideas and ways of writing code? Are they willing to share their ideas?

It depends on the management: Are they willing to let their developers get together regularly and share these ideas, or do they just want code monkeys?

It depends on a lot of things about the organization that you work in whether something like code reviews is even possible to do, to say nothing of whether it'll be productive at all.

This goes for any software development process: Not everything works for every organization. You have to think and see and evaluate, not try to blindly implement processes because I (or anyone else) say it's necessary for a project to succeed.

And more importantly: You have to not be so presumptuous as to think that your way of doing things will work everywhere.

Ping

2011-06-15T21:53:00.000-04:00

Well...things got a bit dusty around here...again....

This past year has been...interesting...in both the personal and professional spheres of my life.

I moved on from my previous job of six-and-a-half years (nearly an eternity compared to many software developers I know) to a small company doing Groovy and Grails development, a technology that I've previously raved about.

I'm soooo happy to be away from the XML Soup that is the typical Spring/Hibernate stack - that alone has made the move worth it. (Granted, it's still hiding there under the covers in Grails, but I have yet to mess with it for any reason whatsoever...and I hope it stays that way)

I am also busier than I've been in a long time - something that was a big motivator for me to move on from my previous job. I've come to realize that sitting idle is a serious problem for me, and there was simply too much of it in my previous workplace.

There were other factors at play in my decision to move on that I won't get into (and some I will, but another day. Don't worry there's no ranting involved, and I have no axes to grind, and have no ill will toward anyone involved there).

At any rate, I'm going to try to get a regular posting schedule going again...wish me luck :-)

Android and Harmony

2010-10-14T10:09:00.000-04:00

So. Oracle and IBM make nice and agree to support OpenJDK over Apache Harmony. Stephen Colebourne gives a good rundown on why this seems to make sense for IBM, and I have no real reason to argue with his assessment.

There's been grumblings that this is a "Screw Google" move, since Google leverages Harmony in it's implementation of Android, and that this may have a serious impact on the Android platform. There may be some validity to the claim that Oracle is trying to stick it to Google in some way, but I seriously doubt this will impact Android in any real way.

There are two reasons why:

The first is the simple fact that Apache Harmony is open source. There is really nothing stopping Google from just picking up the project and throwing their own resources at it (it's Google...they have no shortage of people they could put on this if they chose to). Given the current lawsuit by Oracle, I'm not entirely sure Google would do this...but it is certainly possible.

The second is that, given that Harmony is licensed under the much more liberal Apache License, rather than the GPL, Google can simply fork the project as they see fit. In fact, I'd bet this is really what they've done for the Android platform already -- Most sources I've read regarding Android mention that parts of the Android platform are based on Harmony, a choice of words that seems to imply that it has been customized specifically to Google's requirements for the Android platform. And it seems to make make sense that Google would do this given both the fact that the Dalvik VM isn't a Java VM (and hence the Harmony code would likely have to be tailored to that VM in some ways) and the fact that mobile devices have constraints that a standard PC doesn't, which is what Harmony was originally intended to run on.

So, unless I'm missing something, I don't see where this will have any serious impact on the Android platform at all. The outcome of the lawsuit by Oracle is likely to have a bigger impact than this turn of events.

Apple Gets a Clue

2010-09-10T10:40:00.000-04:00

I had planned to write a post back when Apple changed their developer agreement and basically barred anything but Apple's own tools, and how horrendously stupid and short-sighted it was. Thankfully now I don't have to: Apple finally wised up and removed the restrictions.

It's one thing to tell developers what kind of apps they should make (which is a perfectly reasonable thing to try and set down rules for), but it's something else entirely to try to tell developers how they should be creating those apps, and what tools they should use. The limitations Apple put in place made about as much sense as it would for a furniture shop to start dictating to the carpenters that build its products they can only use specific tools to craft their chairs and tables.

It's more important to be focused on the end product, not the means used to create it.

Consequences of Oracle v. Google

2010-08-28T10:46:00.000-04:00

We're a long way from any kind of resolution in the Oracle v Google suit, so it's really anyone's guess how the case will unfold. Regardless of the ultimate outcome, I think the consequences of Oracle's actions will likely have far reaching implications for Java development.

The future is not looking bright for Java.

I understand that Oracle now has a mobile platform they are trying to protect, but lets be honest here: Regardless of the revenue Java ME may or may not provide, it can't compete with either Android or iOS in terms of capabilities and its decline is all but certain given current trends. Java ME will likely die in its current form, and it would take years for Oracle to even come close to making it competitive against either of the current popular platforms. And if by some small chance Oracle managed to have Android taken off the market, it would just end up having handed Apple the entire mobile space -- lock, stock and barrel. Java ME is dead meat either way.

Of course, it's highly unlikely that Android will get pulled from the market completely (not without an extremely long and protracted fight with Google), so by all appearances Oracle is just trying to get some cash out of Google over the patents in question. As others have already pointed out, it's more likely that they'd go after some sort of large sum payout rather than licensing fees for the patents: If Oracle succeeded in getting some form of licensing agreement out of Google -- either via settlement or court ruling -- that would only be a short-term victory since in all likelihood Google would just change Android to avoid those patents completely and kill any opportunity for Oracle to suck money out of future versions of the platform.

So, all indications are that this is Oracle trying to shake down Google for succeeding with Android where Java ME (mostly under Sun's stewardship) failed.

No good deed goes unpunished.

There's another angle to this lawsuit as well: In addition to trying to extort some money from Google, Oracle may be signaling its intent to exert more control over Java than even Sun had dared. The lawsuit has already raised a few questions regarding the impact it may have on current open-source implementations of the Java platform. Coupled with Oracle's latest move in their decision to effectively kill OpenSolaris, and given Oracle's general lack of enthusiasm (if not outright hostility) towards open-source in general, it wouldn't be hard to imagine them trying to lock up the Java platform in a similar way for their own business needs and trying to make it more of an Oracle-centric technology.

This would obviously have dire consequences for the Java community if it were to come to pass. It's no secret that a lot of developers are already starting to question Java's future, given the rediculously long time between major updates to the platform (Java 7 is years overdue) and the alternative technologies that have gained mind share in areas where Java once dominated. This lawsuit has only added more uncertainty to the mix for many in the community. And, if Oracle is really trying to move Java into more of a closed system than it is currently, we could be looking at a dramatic shift in the landscape for Java development. I wouldn't be surprised if we started to see a massive migration away from Java as a result of Oracle's recent moves, because many developer simply don't want to be a part of this sort of arrangement...particularly if it's coming from the likes of Oracle.

And If that's not enough to make Java developers worry, there is another potential wrinkle that seems to have been overlooked that's tied to this whole mess: Google's future path for Android post-lawsuit. Putting Oracle's possible locking-up of Java aside, the choices made by Google following this lawsuit could potentially signal a decline in Java all on its own.

The rise of mobile computing has already started a shift away from the web -- a place where Java has enjoyed the most success. But since Android leverages Java (the language, not the platform as a whole) for application development, it has still managed to enjoy some success, and stay on developers' radar, despite the major changes going on in computing.

But, if Google executes "The .NET Option", all of this could come screeching to a halt. And developers will have no choice but to abandon Java completely as the mobile computing revolution marches on.

No, I'm not talking about Miguel de Icaza's wishful suggestion that Android move to .NET. The likelyhood of that happening is exactly zero: Google would not willingly partner with one of their biggest competitors in the industry. It's foolish to ever think they would.

What I'm talking about is something that's been mentioned frequently since Oracle's lawsuit was announced: The similarity to the lawsuit that Sun launched against Microsoft back in 2000. Many in the blogosphere have focused on the similarities between that case and the current one as an example of how Oracle may be successful in their suit against Google.

But what seems to have been overlooked is what happened after the lawsuit back in 2000: It's the consequences of Microsoft's loss and their course of action afterward that are more interesting, and could portend the future for the Android platform, and for Java development as a whole. Because, unlike the Sun v Microsoft suit -- where Sun managed to save Java from fragmentation and possible failure in the marketplace -- this suit could at the very least marginalize Java to the point of irrelevance.

I haven't really seen anyone consider that Google could very well do what Microsoft did following their loss in 2000: Ditch Java completely and create their own tailor-made language and runtime from the ground up.

By all accounts, Google already has a key piece in place: The Dalvik VM is Google's own custom virtual machine, built from scratch, that runs it's own bytecode and is (patent challenges notwithstanding) completely different from the Java platform's JVM. Java programs written for Android already get compiled to this new bytecode format in order to run on the system, so in all likelihood the only thing Google would have to do is create a new programming language -- different enough from Java to avoid legal problems, but close enough to be familiar to existing developers (just like Microsoft did with C#)-- that could be used in place of the Java that's currently written, and build a compiler for this new language that targets the Dalvik VM.

Google has already tried their hand at creating a new language before, and given that Microsoft managed to be fairly successful with C# and the CLR, I'm pretty confident that Google could succeed as well if they chose this path. And considering the amount of time that this lawsuit will take to wind its way through the courts (several years at best) it's possible that Google could make the move off of Java completely and shift Android development into a new direction before everything is even settled, thereby bypassing any attempts by Oracle to either extract money from them, or lock up the Java platform.

Now, I admit that there's very little evidence that Google would go this route, but it seems pretty clear that this option is available and has a high likelihood of success -- and it would probably be even easier for Google than it was for Microsoft, since they already have the runtime in place.

Unfortunately, a move like this would likely have a huge negative impact on Java development: As stated before, the shift to mobile computing is well underway. And if Google ditches Java in favor of their own home-grown language, then it's a pretty good bet that Java will be relegated to the world of legacy systems, targeted at servers and the enterprise, and not much else. This would play right into Oracle's potential plans for Java, since this appears to be what they want for the platform given all that's happened up until now, but it would be a bit sad to see Java relegated to an enterprise-only existence given the platform's remarkable life in so many areas of computing.

No matter what happens between Google and Oracle, the future for Java development isn't looking all that good right now. I won't say that Java is going to die, or is dying, but I can't really see where people will want to continue using Java with the uncertainties Oracle has (intentionally or not) introduced as a result of this lawsuit against Google. And unlike Sun -- a company that always tried to do the right thing for developers (even if they stumbled a bit) when it came to Java -- it's become clear to many at this point that Oracle will not have the same approach towards the Java platform as they did. And that alone is enough to make many developers consider alternatives.

The really sad part is, with Android's quick rise in popularity this past year, Java development got a much-needed shot in the arm in terms of attention and mind share -- something that was not only to Google's benefit but Oracle's as well. Now, Oracle's move threatens to kill that mind share completely, and scare a lot of people away from Java development.

Way to go, Oracle.

In Which I Retract What I Said About Larry Ellison....

2010-08-17T12:30:00.000-04:00

Yeah...

That little thing I said last year?

Never mind.

Colored Views

2010-05-14T09:13:00.002-04:00

Go read Ted Neward's latest blog post.

Now do this: Replace everything regarding print screen functionality with the topic of Flash and HTML 5.

This is a big reason why I doubt any real progress will be made between these two technologies for a long time.

Apple, Flash and Developers' Rights

2010-05-06T15:48:00.002-04:00

Via Slashdot comes a blog post by Ian Bogost arguing that Flash is not a Right.

In general, I don't see anything wrong with what he's saying. He's correct in asserting that developers don't necessarily have a right to use their favorite language/platform/technology where ever they go. As a developer, you just have to adapt to the demands of the systems you're working with.

But I can't help but feel that everyone's missing the bigger issues surrounding the Apple/Flash discussion.

Most of the attention has been on Apple's changing of section 3.3.1 of the iPhone developer agreement, which explicitly barred the use of Adobe's planned cross-compiler for Flash CS5. This system would have allowed developers to create native iPhone applications using Flash, rather than having to learn or use Objective-C (the native language used for iPhone development).

Now, without wading too much into that mess, I don't think that Apple was necessarily in the wrong for doing this -- the short version is that it's their platform, their rules, and if you don't want to play by those rules, you are free to explore opportunities elsewhere. Apple wants to ensure a certain level of quality of the user experience for the apps that run in the iPhone ecosystem, and this is how they want to do it. And really it is within their rights to do so.

The bigger issue -- the area that is giving a lot of Flash (and other) developers cause for concern -- comes not from the banning of the Flash-to-native-iPhone development, but from the fact that Apple refuses to allow Flash as a plug-in to the Safari browser on the iPhone. This has effectively cut off a rather significant number of websites from a rather large potential user base simply because Apple, for whatever reason, thinks that people should not use Flash for their websites.

The end result has been that Apple has given a lot of developers the impression that they are trying use their dominance in the mobile sphere (via their rather significant iPhone/iPad user base) to force web developers into ditching Flash on their websites. The question then becomes: Does Apple have a right to tell web developers -- developers not specifically developing for the iPhone -- what technology with which to build their own websites?

That is what has many developers at least a little concerned, and some extremely upset. All things being equal, Apple is in no position to dictate to any web developer what technologies they should or shouldn't use when building their own website. Yet, by all appearances, that's what Apple seems to be trying to do.

Now, keep in mind that Steve Jobs' suggestions in his Thoughts on Flash post of using HTML 5/H.264 aren't bad, either. Far from it. I think there's still some room for improvement where HTML 5 (and the technologies surrounding it) is concerned, but I'm definitely not going to call Mr. Jobs an idiot for suggesting them.

The problem is in the heavy-handed way in which Apple have tried to push their position, and seem to be using the iPhone/iPad user base as a Really Big Stick with which to dictate the direction of the web. They're basically saying to web developers, "You want to reach our users? Then you need to do things our way."

Other companies have tried that kind of approach before...

...it didn't work out too well for them, either.

Kicking off the Dust

2010-04-30T08:00:00.002-04:00

It's been way too long since I've posted anything.

One reason is just that I've been really busy. I know...everyone is busy, and that's not really much of an excuse. But my focus has just been way over there somewhere and not over here. That's just how life is sometimes.

Another big reason is that I tend to the antisocial side of the spectrum: I can go long periods without saying anything to anyone, be it writing or talking. And when I don't feel like I have anything interesting to say (or worth reading in this case), I just simply don't do it.

(Incidentally, it's amazing how much this drives people nuts. I can't count the number of times people have either felt offended, or thought I was a snob, or whatever, simply because I don't say anything. It's nothing personal...I just don't feel compelled to engage in chit chat.)

So, since I didn't feel like I had anything interesting to say/write I just didn't do it.

At any rate I'm kicking off the dust. Things have settled down a bit, and I have a few things I'd like to blog about again.

For starters, I'm going back through my posts and going about fixing the broken code snippets I blogged about last year (took me long enough to address that, didn't it?). I'll update with a new post on how to use the syntax highlighter for code snippets on Blogger as well, since the library I was using has changed significantly since I last used it.

Stay tuned.

Contrary to popular belief, Brooks' Law has not been disproved

2010-03-11T07:51:00.004-05:00

I came across this Slashdot story (and it's popped up in a few other places as well) claiming that the Fred Brooks' well-known idea that adding more programmers to a late project only makes it later has been disproved based on this blog post from Ksplice.

In brief: Ksplice had a lot of work to be done and not enough time to do it. Since they were within close proximity to MIT, they decided to bring on a bunch of students as paid interns to help them out. The result was a huge boon for them and they got themselves back on schedule.

How were they able to do this despite the oft-quoted Brooks' Law? Here's the key bit from the post:

Divide tasks to be as loosely-coupled as possible. Our internship program would never have worked if we had assigned a dozen new people to hack on our kernel code—the training time and communication costs that drive Brooks’ Law would have swallowed their efforts whole. Fortunately, like any growing business, we had a constellation of tasks that lie around the edges of our core technology: infrastructure upgrades, additional layers of QA, business analytics, and new features in the management side of our product. These had manageable technical interfaces our existing software, so our interns were able to become productive with minimal ramp-up and rely on relatively little communication to get their projects done.

So, for all intents and purposes, each student was working on their own project and not as part of a single monolithic project (as Brooks was referring to when he wrote The Mythical Man-Month). Even the blog post admits that if they had they would not have realized the gains in productivity they boast about.

Admittedly, you could probably still make arguments that this particular instance applies to Brooks' Law, but I think it might be stretching the intent of what Brooks was getting at in the Mythical Man-Month.

Brooks' Law is more about the dynamics of communication than it is about any specific type of project. Whenever a project requires lots of meetings, IMs, emails, and whatnot to get things done, it's only going to get worse when you throw more programmers into the mix later, as your now adding their chatter to the already-large cacophony of communication going on. That is what Brooks was concerned about.

A Question of Design

2009-10-14T10:32:00.002-04:00

So I'm working on this project at the office: It's basically a rewrite of an existing system that is nothing short of a mess: Poorly designed and poorly implemented based on shaky requirements...basically everything that qualifies a project for the title of "Complete and Utter Failure".

Of course, the powers-that-be don't want to call this a rewrite -- they prefer "refactoring" or something, anything, that doesn't use the word "rewrite" in it, for fear of upsetting the users of said shoddy system. The system was just put into service a few years ago and there's a fear that those in charge of the purse strings will freak out if they found out that their current system isn't exactly the best they could get for the amount of time and money that has already been sunk into the system.

So, here we are, doing a rewrite that isn't a rewrite.

I was specifically requested to be a part of this project, and to take a "lead role" (whatever the hell that is...I still haven't figured it out, yet) given my rather strong desire to build stuff "The Right Way", and the fact that I had knowledge of the existing system...

See, I helped build the current system. Yes, I contributed to the problems that we are currently trying to correct, but not before trying desperately to improve the situation while I was involved. I eventually left the project out of frustration (a topic for a whole blog post itself), since I was unable to make any headway and certain members of the team at the time didn't seem all that interested in improving the situation. Fortunately, those individuals are not involved now, which at least makes the move towards a better system easier to accomplish.

So anyway, I've basically been given the task of redesigning the system the way I think is best (with some restrictions, which I cover below), given my rather vocal disagreements on how things were done on the existing system and given the fact that I'm a rather smart guy (their words, not mine).

We've hammered out a bunch of requirements, pulling both from the existing system (which does meet some of the needed requirements of the users) and feedback from the users on how they currently work. So far so good.

With this information in hand, I've been working with some proof-of-concept code to get a general feel for how the system should go together -- experimenting with Spring MVC, which I'm just starting to get a feel for, playing around with Spring Web Flow, and so on. This has been going on for a couple months while the project manager and some other higher-ups have worked out a few additional changes that need to be made to the system to accommodate some coming business changes.

At this point, I basically have a good feel for how the system needs to be built. And, quite frankly, if given a few weeks of uninterrupted work I could probably hammer out a good portion of the system on my own.

The problem I'm encountering now is that the powers-that-be want to take a more...formal...approach to the system this time around. They basically want to have a design laid out first, then have that design implemented -- either by me or some other team members that can understand the design. And they want me (and a few others) to work out the design artifacts -- class diagrams, activity diagrams, and so on. Also, they've decided that I shouldn't be the only one designing the system (for fear that I might do something "wrong" or something, I guess), and so have teamed me up with another developer so that we can work out an agreeable shared design.

My issue with this is that the time it would take me to work out all of this stuff would be better spent actually...you know...building the damn system.

Now, lest this sound like I'm against any kind of design, I'm not. I understand perfectly the desire to have a solid design for the system in place, and making sure everyone understands what that design is and being on the same page.

The problem I'm seeing, however, is that there's this expectation that the design is going to be first, then the coding. Where for me, both tend to happen hand-in-hand: I'll code a bit, then analyze what I've created. I'll then refactor whatever I think needs changing in the interests of keeping the system simple and maintainable, reanalyze, and so on. The design is eventually exposed through my working of the code into a form that make sense.

Also, I personally tend to see the design artifacts -- class and activity diagrams and such -- as communication mechanisms to get people to understand the implementation, not as a means to an implementation.

There's also the small fact that it's hard to come up with a solid design when you are working with architectures/frameworks that you are not completely familiar with. For example, I wouldn't know where to start with trying to design a system running in Ruby when I've never used Ruby before. Yet this is the kind of approach they are asking me to take here: Design everything first, have agreement on that design, then move to implementation.

Yea...there's that whole Waterfall feel about it isn't there?

Unfortunately, I can't seem to get the powers-that-be to understand this: They seem to think that there can't be any code without a design first. They've been taught/conditioned/whatever to expect that I will work up a detailed design using whatever design tools they've given me and then they'll just hand it off to some other developers to implement. What they don't seem to understand is that I can actually write the code according to the design I've envisioned faster than I could actually draw up all of these detailed design documents.

There's also the fact that, given the approach toward design I'm being asked to use here, I'm being pushed into a role that effectively takes writing code completely out of my hands, which I seriously have no desire for. I like writing code. It's what I'm good at, and I see no reason to move into some other designer/architect/whatever role that takes me away from it.

There's also a bit of the fact that I've been writing code for damn near 10 years now, and I've never been in an organization where these explicit designer/architect/coder roles have worked out in practice. In my experience, all software developers take on all three roles during the course of a project, and in fact need to take on those roles from time to time as a project evolves. Taking those roles out of the hands of the people actively working on the code does nothing but slow a project down to a crawl, as now any question about the design or architecture that a coder might question necessarily involves other parties who very likely have no interest in having a lowly coder (who couldn't possibly know anything about good design/architecture in their view) question their judgment. It's been a roadblock toward good software in my experience.

Maybe this is just a case where I'm not seeing the light or something, but I'd be surprised if I'm the only one that looks at the the whole design/architecture/coding differently from what I've been encountering here recently.

It's not a case where I think proper design and architecture are bad. Far from it. Just that I think that perhaps the conventional wisdom regarding them as explicit roles to be filled by specific individuals is somewhat flawed.

In Which I Respect Larry Ellison Just A Bit More...

2009-10-03T10:47:00.003-04:00

Larry Ellison isn't exactly the most-liked individual in the tech industry. Heck, I've never been a fan of the guy personally, and I've never found anything in particular to like about anything he's said in the past. And the war stories I've heard from former Oracle employees have only reinforced my dislike of the man.

But dammit, I can't help but respect him for what he says in the clip:

My favorite part is at the 3:54 mark, where Mr. Ellison says:

Our industry is so bizarre. You know, you just change a term and they think they've invented technology.

Getting the Job Done.

2009-09-24T13:43:00.003-04:00

Seems like it's been an eternity since Joel Spolsky has written an actual full-blown post on his site, but his latest is a really good one.

I'm a huge fan of pragmatism over idealism, and as others have already pointed out you do have to be able to balance the two in order to be a successful developer in this day and age.

I don't have much more to add, other than I find it slightly amusing that in describing a certain kind of programmer, Joel has also actually provided a good reason why Java -- A language and community that Joel himself has focused some disdain -- rose to prominence the way it did.

It ain't pretty, but it get's the job done.

Broken Code Snippets

2009-07-23T10:58:00.003-04:00

Google has decided to discontinue Google Pages and has started migrating users over to Google Sites. As a result of this (and some of my own messing around with the site design) most of the code snippets I have on this blog no longer display properly. I've updated my post on syntax highlighting in blog posts to warn people away from trying to use the approach I've described there, and which is the one I had be using for code on this blog.

I plan to address the problem soon enough -- when my schedule allows, that is.

I guess this is a good argument for hosting my blog on it's own server (which I've been considering), which would have obviated the need for the Google Pages approach.

Oh well...live and learn.

Grails Kicks Ass

2009-07-21T08:00:00.000-04:00

God how I wish I had discovered this framework sooner...

I decided last month, following the suspension of my previous project, that I'd take a look at Grails while I wait for some more work to come my way. I've read and heard some good things about it, so I grabbed The Definitive Guide to Grails (one of the authors, Jeff Brown, was at the NFJS conference I attended last year) via my Safari Books account, and have spent the past several weeks working with the framework and just seeing what it can do.

And so far I'm loving Grails...I mean I'm really loving it.

Why do I love it so much?

Well, for starters, let's say I'm creating a new project from scratch using the typical Java stack -- we'll say Spring/Hibernate with a sprinkle of JSPs -- I'd usually set up a project more or less like this:

Create a web project in Eclipse.
Grab the Hibernate and Spring libraries and put then in the WEB-INF/lib directory for the project.
Create a skeleton Spring configuration in XML
Create one or more domain classes.
Create Hibernate mapping files for each of the above domain classes.
Set up some tables in the target database for the above domain classes.
Set up the DB connection info (more XML configuration, usually...)
Create some initial DAOs (interfaces and implementations) to service the domain classes.
Create a basic Service (interface and implementation, of course) to handle the DAO access.
Create a simple Spring MVC controller.
Wire up the DAOs, Service and Controller in the Spring configuration file(s)
Create a couple simple JSPs and maybe even a basic HTML page or two that works with my controller.
Test it all to make sure I didn't screw up any of the configuration.
Create some unit tests
And so on...

I've probably missed a few steps in here, but you get the idea: Getting up and running with a typical Java web stack takes a lot set up -- most of it ending in ".xml".

And this is just to get started. I don't know about anyone else, but once I've been rolling along on even a moderately-sized project that uses Java technologies I find myself getting into a pretty ugly tangle of XML and Java eventually. It's not hard to do.

Meanwhile, here's what it's like getting started in Grails-land:

   grails create-app foo
   grails create-domain-class bar
   grails generate-controller bar
   grails generate-views bar
(repeat last three commands as needed for each domain class...)

It just gets easier from there...

And the best part: You're still using Spring and Hibernate.

The Grails developers did the single smartest thing possible: Rather than reinvent the wheel, they leveraged existing Java frameworks under the covers and provide what has to be the cleanest interface to those tried-and-true systems you could come up with. The "convention over configuration" approach means that a bunch of boilerplate that rarely changes from project to project disappears, and when it comes to actually changing the configuration, using actual Groovy code rather than XML (or annotations) just looks a hell of a lot cleaner. Working with Hibernate and Spring is incredibly easy in Grails -- much easier than I even thought possible.

Grails also deploys just fine to most major app servers, making it super-easy to leverage in an existing Java infrastructure, so working with it doesn't require contorting your entire infrastructure to support it -- just make a war file and off you go!

I really can't say enough good things about Grails at this point. I've already been working on a proof-of-concept at work to see how well it operates within our existing infrastructure and so far it's passed with flying colors. Transitioning to this framework is a breeze.

I've also been comparing the level of effort required compared to the usual Java Spring/Hibernate stack using the traditional approach and I'm amazed at just how incredibly fast I've been able to work with Grails -- what would have taken me days to get working normally took me mere hours with Grails.

Given the choice between the usual Java stack and Grails, I will pick Grails hands down in a heartbeat...it's that good. You can bet your ass I'll be pushing hard to use this in my future projects.

Moment of Reflection

2009-06-15T16:32:00.004-04:00

A little more than 20 years ago, I was getting my first taste of programming on my brother's Commodore 64. The only information available to me were a few books my brother had that contained code listings, written in BASIC, for a bunch of computer games. It was all the information I had available to me at the time. I must've read and re-read those books a million times...

About 15 years ago, I rediscovered the joy of programming and began looking at, and buying (when I could afford them), whatever books and magazines I could get my hands on at the local computer store that covered computer programming. Aside from the library, I didn't have many other avenues for information on the field of software development. And since going to college was a decidedly expense avenue for me at the time, these were my only options for learning.

Today -- after upgrading my Safari Books account a few weeks ago -- I now have immediate access to every book currently in their library, which has a total count of books somewhere in the 8,000 range, last I checked, and includes just about every book on software development that I might ever want to read.

And even when I can't find what I'm looking for on there, I have Amazon.com as backup for cases where the book I want isn't available via my Safari account.

And on top of that I have The Web/Internet, with any answer to just about any question I could think of being a mere Google away...

Technology is so cool sometimes...

Java IDE Performance

2009-06-15T09:23:00.008-04:00

An interesting discussion popped up on DZone last week. In a discussion of this link on DZone, the author of the post in question mentioned the poor performance of most Java IDEs, and I think he has a valid gripe: Most (if not all) Java IDEs are performance hogs, sucking up a lot of CPU and RAM.

Before anyone gets all hot under the collar about their favorite IDE and starts flaming me, let me be clear: All of the major players in the Java IDE world -- Eclipse, Netbeans, and IntelliJ IDEA -- are fantastic pieces of software from a feature standpoint and I've used just about every one of them at one time or another, with Eclipse being the mainstay for my day-to-day work currently. Given the current state of the art in Java IDEs compared to my early days in Java development (late '90s) I will take what we have now without question.

But I don't think any Java developer out there can say that these IDEs don't suck up system resources like crazy. Regardless of the hardware I've run on, I still run into long load times, laggy auto-complete when I type, and just general slowness...to say nothing of memory consumption. And the larger a project gets, the worse the situation becomes.

As far as I can tell, performance is still an issue for most of the major IDEs in the Java development world.

Now, maybe it's not a terribly big deal for a lot of Java developers out there -- I don't see a lot of discussion about IDE performance in the Java community these days. Perhaps everyone's just learned to live with it. Or perhaps it's just an issue for those of us in software development that don't have the luxury of monster-sized Quad-Core systems with 8+ Gigs of RAM, and sporting a Solid-State Disk for maximum performance. In other words: All us lowly enterprise developers who are at the mercy of our IT departments.

At any rate, even if you're sporting the best development system money has to offer, odds are you've had to deal with IDE performance at some point or another when doing Java development. The question is what's causing all of our favorite IDEs to perform so poorly in terms of both speed and memory footprint?

A few thoughts come to mind...

Java
Of course, we can't have a discussion of performance without thinking of the underlying VM upon which the major IDEs run. Despite the heretical nature of the "Java is slow" argument within the Java community, this is certainly a valid argument to make here since all of the major players in this space are written in Java, as far as I can tell. We could spend days arguing over whether Java really is slow compared to native code (and there's been plenty of arguments about it since Java's inception), but the fact is that you are running bytecode in a VM, which no matter how you slice it is going to be slower than native code in a lot of cases. And given the relative size and complexity of the pieces of software in question, I think it's a valid point to consider when it comes to IDE performance.

Of course, a question I have here is this: Why aren't there any popular natively-compiled IDEs for Java? I know it flies in the face of Java's overarching premise of being platform-neutral, but wouldn't having some form of high-performance, compiled IDE be useful to developers? Couldn't the free software or open-source communities get something going along these lines, creating an open-source, natively-compiled Java IDE that could be ported to the various platforms?

Thinking about this further, Eclipse itself leverages the widget set of the underlying OS via SWT, which means it's effectively leveraging native code to improve performance already (and this was in fact a major motivation for SWT's creation to begin with), so why not just take it a step further and make a native-code IDE?

The closest thing I've ever seen to a resource-friendly IDE that wasn't written in Java is the Java Development Environment for Emacs (JDEE) which, despite being a nice and speedy environment to work in, is still somewhat lacking in its feature set and is a bit hard to just jump into for most developers -- especially when you need to learn Emacs in order to use it effectively.

Anyone that's familiar with Emacs, however, will point out something interesting here: The JDEE isn't a natively-compiled IDE either -- it's written in elisp -- which actually raises more questions about the possibility of whether the Java platform itself really is a performance problem or not. Since elisp is interpreted code, yet the JDEE performs exceptionally well, perhaps the whole interpreted code thing might not be such a big deal after all.

Architecture
This, of course, brings us to the subject of the underlying architecture upon which these IDEs are built. It is certainly possible that the architecture of the IDEs themselves are just lacking, making them inherently slow. And with the growing list of languages and technologies that many of them try to support, it makes it more likely that the underlying architectures of the various IDEs can only handle so many things before they begin to buckle under the weight of it all.

Based on my own look into the Eclipse RCP architecture, I'd have to say that this is certainly a possibility. It's designed to be as generic as possible and support a wide range of possible uses, and as a result may not be perfectly tuned for software development the way it once was. I haven't looked at the Netbeans architecture, and can only guess that it would face a similar situation as Eclipse in terms of design.

IntelliJ IDEA may be the one with the advantage in this regard as I don't see anything to indicate that it's tried to be anything more than a feature-filled IDE. But nevertheless, it's still trying to support a lot of uses, which can affect performance.

I'd also like to think that since most of the major Java IDEs have been around for a decade or more, they'd have at least some focus on performance in their respective architectures for at least part of that time and have kept that at the forefront of all of their design decisions. Still, there is the possibility (at least in the case of Eclipse and Netbeans) that they've overextended by trying to be too generic.

Java Project Complexity
Another possibility -- and one that I think warrants some attention -- is the very nature of most Java projects and their sometimes dizzying amount of complexity and the array of tools that can be required to easily navigate and maintain such projects.

When a "simple" web project is using the likes of Spring, with Hibernate linking the database, along with any number of JSPs, or perhaps even some GWT or other AJAX-like technology in the web pages, all tied together by a multitude of libraries, XML files, property files, i18n support, and various bits of technology, it's no wonder the IDE might start having spasms. There's a lot of parsing that has to go on.

Of course, this touches on a bit of the other two points -- if the IDEs are designed and architected right then they should be able to handle this sort of thing. But since these days a lot of these IDEs are not necessarily optimized for just one type of project, or even one type of language for that matter, this might not be something that's easily addressed.

Maybe the IDEs are a little over-generalized to support too many things at once...?

Etc...
I'm sure there's something else out there that I'm missing, so feel free to jump in and add in your own theories.

I don't really have any solutions here, just some thoughts about the current state of Java IDEs. I think all the development platforms we have now are great in their own ways, and give us plenty of options.

But I can't help but feel that maybe we've all just settled for what works, without thinking about if we could be getting more out of our IDEs in terms of performance. Have we just accepted that things are as good as they're going to get?

I actually managed to use the JDEE on a project a few years ago and found it immensely more productive compared to Eclipse -- aside from the production boost that I got just from using Emacs (which I do miss these days), the performance of the environment in general was considerably faster than Eclipse, and I felt that I was able to be a lot more productive on that project than had I been using one of the other popular IDEs.

Unfortunately, I had to abandon the environment when I switched to a web application project -- the JDEE doesn't do web app development very well from what I've seen. Nevertheless, I still miss the amount of productivity I had.

I guess the question is...does anyone else?

Maybe this is a case where a developer who hasn't explored Java outside of the popular IDEs, who has spent most (or all) of a career working with the likes of Eclipse and such, just doesn't know any better and thinks that Java development is as fast as it can be based on those environments -- They basically don't know what they don't know.

At any rate, I think this are all valid questions we should be asking: Can Java IDEs get any better on the performance side? Should we accept the current status quo? Would we be better served by a native IDE client?

I'm curious to know what other developers think about this.

A Long Slumber

2009-06-08T16:46:00.005-04:00

The project I mentioned in a previous post a few months back -- the one where my team and I were faced with a complete rewrite as a result of some very bad decisions made long ago -- is going into hibernation as it were: It's being put on hold for at least a few years.

I'm not privy to the details, but as I understand the group we were developing the application for is going to undergo significant changes to their business processes -- not so much a reorganization as a complete reevaluation of how the group actually operates. This is part of a larger effort that's been underway for a while now to streamline the business as a whole (and began well before anyone was thinking about the economy), so the powers-that-be believe it doesn't make a whole lot of sense to try to continue to develop a new system while the business requirements will be changing not just beneath us but the end users as well.

The bright side for the team is that we won't be getting pink slips: There's still plenty of work to be done elsewhere in the organization. Not a lot of people out there can say that, so I'm at least thankful in that regard. Of course, there's no guarantee my teammates and I will all be working on the same project, either (it's highly unlikely, as a matter of fact), but we'll still be in the office together...hopefully still picking each others' brains for vital info.

Another plus is that it'll give whomever picks this project back up ample time to reevaluate the choices we were making from a technology standpoint...as we ended up discovering another very bad decision made by our predecessors that trumped all the other bad decisions...

I already noted in the aforementioned post about our investigating Eclipse RCP, which we began to move forward with once we realized it was suited to our needs and would allow for a faster turnaround than the poorly designed, scratch-built system we had up to that point. Unfortunately (or fortunately depending on your point-of-view...), it came to the team's attention not long after moving forward with Eclipse RCP that due to choices that had been made in business infrastructure long ago we needed to provide a web application and not a desktop solution. This became pretty obvious to the team following a meeting with the infrastructure guys (and should have been obvious to those same guys that started work on this project years ago). By trying to create a desktop app we were effectively doing the programmer's equivalent of fitting a square peg into a round whole -- the infrastructure and policy decisions that were already in place screamed "Web Application" all over the place. And yet here we were trying to cobble together a desktop system.

Sometimes I wonder about the sanity of my colleagues in this industry...hell it's a wonder I'm not insane yet...

So another change in direction was needed...this time to a web application. Fortunately everyone involved in the project had web development experience and we had no trouble getting up and running again with a web app. In a lot of ways this made our work vastly easier, since there wasn't a steep learning curve that everyone had to overcome (as we had with Eclipse RCP).

The downside was that we had little time to evaluate options when moving to a web application -- we were forced to chose the path of least resistance and go with what everyone (or the majority at least) had experience with. In this case it was Spring MVC and Hibernate. Because we had already lost so much time up to that point -- with our evaluation and initial work using Eclipse RCP -- we just didn't have the luxury of check out the options available to us in the web development sphere (and lord knows there's plenty of options out there for web development...).

So at least in this regard the project being put on hold is a good thing: Whomever gets to pick things back up (hopefully one of us will still be involved) can take time to reevaluate the technology choices and will have plenty of opportunity to check out the options available. Heck, in a few years there might be some new super-cool technology that'll be even better than what's available now...who knows...

So, anyway, at this point the project has been shelved until the higher-ups get things in order. My coworkers and I have already started wrapping things up before we get tossed into some other project, which likely won't happen for a few weeks from the looks of it.

So we'll get some time to catch our breath, which is fine by me. All of this course changing, learning new technologies, and moving at breakneck speeds to get the project finished has left me thoroughly exhausted. My brain hurts from all the information I've been trying to cram into my head as quickly as possible over the past few months so it's a bit of a blessing that I'll get some downtime before moving on to the next project.

Of course, it's likely that I'll get to learn something else entirely for my next project as well...so the learning never really stops. That's what I like about software development: Never a dull moment. Well...not too many of them, anyway...

I'm already studying up on a few technologies now: Groovy and Grails in particular. I'll be looking at GWT as well soon, too. I've got a long list of stuff I want to catch up on. Fortunately I'm not in a big hurry to learn it all now.

But more than anything, I think I'll catch up on one thing I know I could use...

Sleep.

Spring Cleaning

2009-06-08T11:06:00.002-04:00

OK, maybe more like early summer cleaning...but anyway...

The old blog layout just wasn't doing it for me, so I'm going to be messing around yet again.

I'll have more things to talk about soon as well.

My Growing Interest in Clojure

2009-05-08T07:02:00.001-04:00

When I see stuff like this regarding Clojure, my interest continues to grow.

Like the article says: This is pretty frickin' cool.

Geek Programming Humor

2009-05-08T06:57:00.002-04:00

A funny retelling of the history of programming languages.

Clojure hits the 1.0 mark

2009-05-04T11:25:00.002-04:00

I'm always exploring the world of alternative programming languages - both on the JVM and off. I might not get as much of an opportunity to put these languages through their paces in my normal day-to-day work (which is predominately Java development), but I like looking at programming from new angles, which learning other languages certainly helps with.

One language that'll definitely get you looking at things from a new angle is Clojure, which just hit 1.0 - Rich Hickey (the creator of Clojure) made the announcement today both in the Clojure Group on Google and on his blog.

Clojure's gotten a lot of buzz from the Lisp community (a good example being this post from lispy's series of Lisp50 notes), and I think even the Java community is starting to take notice as well since it is a JVM-based alternative to Java. Of course, the learning curve is a bit steeper for Clojure than other JVM-based langauges like maybe Groovy, but developers bold enough to learn something like Lisp will certainly want to give Clojure a try.

I looked at Clojure briefly last year sometime, and after sitting in on a talk given by Stuart Halloway (whose upcoming book on Clojure will probably be the go-to book for new users of the language -- like me -- for the forseeable future) at last year's Northern Virginia Software Simposium I've been eager to give Clojure another spin. Having a 1.0 version to play with makes me more eager than ever to give it another spin.

I hope that we see many good things -- and many new versions (but not too many :-) -- from the Clojure community in future.

Aversion to Rewrites

2009-04-16T07:00:00.000-04:00

For the past few months I, along with a few of my colleagues, have been working in overdrive attempting to salvage the project we're working on...

The project is not yet complete, is already several years into it's multi-year budget, and before we've even gotten to a release at all we're already faced with the situation where the current codebase we have has accrued way too much technical debt: It has been poorly designed, which is a result of many bad architecture decisions, and really the only way through this situation is to simply jettison the codebase altogether and start from scratch.

We didn't come to this conclusion quickly. In fact, we tried to come up with ways to not do a rewrite at all. But the more we examined the mess we had in front of us the more we all began to realize that there wasn't much we could do to improve the existing code (to say nothing of actually finishing the project).

What it all came down to was the fact that many of the base assumptions that were made early on in the project we flat-out wrong, and the early choices in how to architect the system were made by people who had neither the experience nor expertise to make such decisions. And it was those initial choices that eventually caused the pain we were in. We had to correct those initial choices if we were going to make any progress.

Being faced with such a situation, the team decided that if we're going to reevaluate all of our assumptions and decisions on the project, we might as well look at everything. So we began evaluating an alternative to the core technology we're currently using: We started to consider moving from a Swing-based desktop client over to using Eclipse RCP for our GUI.

(Given that I've been a Swing developer for most of my professional career, I'll have more to say about the whole Swing/SWT/Eclipse RCP thing later. Suffice it to say that it's been an interesting exploration of the technology.)

When the team decided to begin evaluation of Eclipse RCP, I thought it might be a good idea to ask a few of my contacts outside the office if perhaps any of them had any experience using this particular platform. So, I explained the situation we were facing with the potential (and highly-probable) rewrite and asked for some feedback on this particular piece of technology -- I was interested to know if there were any particular pitfalls or gotchas that anyone may have run into during the course of working with the platform.

Of course, I wasn't sure if any of the people I knew were familiar with Eclipse RCP -- a lot of the work most of these guys do is typically Web-based -- but I figured it was worth a shot anyway. I'd rather get someone telling me upfront that it was a mistake before I start frying my brain learning about the platform and discovering problems the hard way, thereby wasting even more precious time that we already don't really have.

It turned out that none of them were familiar with the technology, which was no big deal -- it was a long shot, after all. But somewhat troubling to me (and slightly annoying, too) was that I ended up getting a lot of responses along the lines of "You should really consider a thorough evaluation and refactoring of your existing code."

Effectively, I got preached to about "The Evils of The Rewrite."

Now, I'm appreciative of bits of wisdom as much as the next guy -- and I do appreciate the concern and advice to some degree -- but this isn't what I was asking for. All I wanted to know was whether anyone had any experience using Eclipse RCP. Quite simply, if I wanted this kind of advice I would have asked for it to begin with.

At any rate, it got me thinking about how we as an industry have become averse to the idea of a rewrite. Yes, I know the Bible According the Joel on this topic: Rewrite == bad. But if you've ever listened to Joel talk on the Stack Overflow podcasts (yes I'm one of their twelve listeners :-), he himself has mentioned -- rather frequently, I might add -- that we all like to take anecdotes we read about, or experience ourselves, and try to turn them into some Truism of Software Development and Joel is no less a victim of this line of thinking than anyone else. He's a smart guy, for sure...but he's not perfect. And there are exceptions to just about every so-called rule we've tried to establish for ourselves in the world of software development.

In our particular case we're not dealing with a terribly complex piece of software. In fact, if the right choices had been made early on in the project we would already have been finished years ago -- this project is simply not that complicated.

But nobody seems to consider that. Instead we're told "No don't rewrite it! Rewrites are bad!" without any consideration of the fact that it might actually be necessary, and easier than a refactoring.

In the past decade it seems that we as an industry have adopted these blanket assumptions and ideas that actively discourage a rewrite completely, with little exception. In a lot of ways this is a very good thing -- we don't want people to just come in and start making wholesale changes to perfectly good (or at least good enough) code. But at the same time it also makes it extremely difficult to convince people of the need for a rewrite in the case where it may actually be necessary. When everyone simply says "No" because they've been conditioned to believe that rewrites are just bad bad bad, without considering the particular situation the project is in, exactly how does that improve our profession?

In our particular case, we've been fortunate in that the we've been able to explain the situation clearly to all parties involved and point out concrete problems with our current codebase, and through our evaluations and demonstrations of alternatives we've been able to show them better ways to accomplish the goals of the project without being unnecessarily complex (as the current codebase is).

As such we are doing a rewrite, and it's most definitely the right way to go in our case.

But despite the circumstance of our project, I just kept picking up this vibe from everyone that rewrites are just wrong in and of themselves, period. What I find equally wrong is the idea that we should flatly ignore the possibility outright, even when it may actually be the best way to succeed. Yes, there are many very good reasons to avoid a rewrite, but there are many good reasons to embrace it as well. It all comes down to your particular situation.

Taking the approach that a rewrite is bad just because someone like Joel, or some other highly regarded figure in our industry says so, isn't a good reason to outright ignore the possibility that starting from scratch may actually be the best option. You should at least be willing to consider it when the time comes, and not just beat the "Rewrites are bad" drum.

Swing's Future

2009-02-19T07:45:00.004-05:00

Not long ago ago I happened upon Jonathan Giles' post on Swing 2.0, discussing what Sun should do to take the Swing API to the next level. It's an interesting read, and I like a lot of the ideas he shares there. Sun's Danny Coward also chimed in regarding the post, and there was a follow up by Jonathan, so there's been an interesting dialogue forming around the idea of reworking Swing.

As a developer who has spent most of his professional career working with Swing^*, I admit that the idea of leveraging some newer ideas and Java language features does have a certain amount of appeal -- Swing has definitely started to show its age and could use some improvements. I personally have been working with Swing since the Java 1.2 days (basically from it's early days), and after having so many opportunities to build Swing GUIs I can probably rattle off a hundred different ways that Swing could be improved/fixed/modernized/whatever. And, in fact, I was ready to add to Jonathan's ideas in his initial post and tick off a few ideas that I think would go a long way towards making Swing better.

Then I changed my mind.

After thinking about the future of Swing, I've come to the realization that realistically there's only one real solution to improving Swing:

Sun needs to just kill it.

For one thing, it's obvious from Danny Coward's post that Sun is totally focused on JavaFX at this point, which means that while Swing will see some improvements, those changes will only be made to support Sun's push for JavaFX which leverages some of the existing Swing technology. Beyond that, we can't expect much else.

Second, there's the fact that Swing has always been a lackluster widget set at best: It was quickly put together to address the deficiencies of AWT 1.1, which itself had to be completely re-engineered since AWT 1.0 was an absolute nightmare to work with (but then, I'm probably one of only two people out there that remembers it). Swing developers have been paying the price for the poor (and sometimes inconsistent) design choices made with Swing from the beginning. And realistically no amount of improvement is going to get around the fact that Swing is still suffering from some of those poor decisions from it's birth.

Keep in mind here that I'm not trying to put down Swing: Despite it's problems it's still proven to be an amazingly resilient API over the years, and I've personally used it in everything from retail Point-of-Sale equipment to flight safety software^**.

Finally, there's the fact that any serious improvements to Swing are going to require some rather significant changes to the underlying architecture, particularly if we want to leverage things like Generics and some improved thread handling (adding SwingWorker to the API was a good start, but I think Sun could do better than just adding some convenience classes to help deal with multi-threading in Swing). Given the amount of effort that is likely required to make major changes to Swing, one has to wonder if it would just be better to start with a new widget set altogether and perhaps come up with something completely new.

But then, that's basically what JavaFX is, isn't it?

Swing has come a long way in the last ten years it's been around, and it has certainly served me well for that time. But I think it's a fair question to ask if maybe we should just consider letting it go completely and moving on to other technologies or ideas completely. I'm not sure if JavaFX is that technology (it certainly leaves a bit to be desired...at least for me), but it's obvious at this point that there are better options than Swing.

Maybe it's time we just moved on.

* - By some wierd twist of fate, just about every job or project that I've worked on in my career has had some Swing-based component involved with it. This wasn't by choice...I just seem to get sucked into these projects somehow.

** - Yes, despite what some people might have you believe, Java does get used in some rather serious, life and death type shit out there.

Rediscovering Emacs

2009-01-22T07:48:00.003-05:00

The odds are pretty good that if you're a Java developer you're going to be using an IDE of some sort -- the big kid on the block in this area is Eclipse, of course. There's also a possibility that you're using IntelliJ IDEA too, which is a very good IDE in it's own right (and one that I got for free for a year after attending the No Fluff Just Stuff conference, but have yet to fully evaluate in any capacity). Whatever the case, during the day-to-day programming work you'll be staring at project package directories, hierarchy windows, class browsing, and on and on and on....it's just the way it goes these days.

Most of my days for the past several years have been spent staring at the Eclipse IDE -- it's the standard tool for the shop I'm at now. It's certainly not a bad IDE, and I think Java's continued success over the past decade can probably be directly attributed to Eclipse's existence. I think if we were still struggling with project management and builds the way we were in 10 years ago, Java would have fallen off the map long ago.

And while Eclipse is powerful and a pleasure to work with, I found myself recently yearning for a more basic tool stack after revisiting my old favorite: Emacs.

I had some extra time the past few days -- thanks to both Martin Luther King's Birthday observance and the Inauguration giving me some extra days off -- to do some reading and play around a bit with Flex/Flash/ActionScript stuff. Mostly I just wanted to explore some of the animation stuff that Flash is capable off, and toyed around with things like making a ball bounce around the screen and even working on some rudimentary collision detection stuff (which didn't work quite as well as I'd hoped...oh well). Mostly just creative exploration.

I didn't bother using Flex Builder, which is Adobe's Eclipsified IDE for Flex development -- the freebie version only lasts 30 days and I don't have a lot of cash to throw out for the standard version...especially when I may not get to use it that often. The accounting department (i.e. The Wife) would not approve such a purchase.

This also puts Adobe's Flash CS4 considerably out of my price range, too: If I can't foot the bill for Flex Builder, which is around $250, I definitely can't afford Flash CS4 at almost seven hundred dollars.

So what was a poor guy to do?

I did what any respectable hacker would do: I pulled out Emacs and started hacking some code.

It's been some time since I last fired up "ye ole hacker's editor", and I was a bit rusty at first as I fumbled trying to remember some of the keystroke commands for various basic editing functions. But once I started getting familiar with it again I started to notice how much more fluid my programming was. Code just flowed through the editor with such ease that I found myself really starting to have fun with programming again.

I'll admit that I'm not an Emacs poweruser -- what I know barely touches the surface, and I've forgotten quite a bit too -- but after only a few short coding sessions hacking out some ActionScript code (using a nice actionscript-mode module to help with code formatting and highlighting) I couldn't help but notice how much more productive I felt using Emacs over Eclipse.

In fact, I felt much more willing to write code when using Emacs than I do with Eclipse, and maybe that's where the distinction is between the two platforms: IDEs add lots of tools and automation and put an emphasis on having developers write less code; Editors like Emacs, on the other hand, provide functionality to allow developers to write more code in a quick an easy manner.

I enjoy working in the code itself and not working in the tools, so that's probably why Emacs appeals to me so much.

After my little ActionScript hack session, I really want to work with Emacs more now. Unfortunately, I don't think I could convince the powers-that-be at my current job to let me use it. They are good people, but very resistant to change...especially when it comes to something they may not be familiar with at all. I have used the JDEE before to work with Java, but I remember it being a bit weak when it came to web development, which might be a bit of a problem, too. Of course, it's possible I just hadn't learned the necessary parts to get that working.

For now I'll have to slog it out with Eclipse.

But in my off hours, it's Emacs all the way.

We Can't Win...

2009-01-13T08:48:00.006-05:00

We're not that far into the new year, but already I have a front-runner for Old Programmer Curmudgeon of the year in one Alexander Wolfe, whose recent article over at InformationWeek bashes modern software developers for...well...pretty much all crappy software.

The article is in response to the SANS Insitute's Top 25 Most Dangerous Programming Errors. This list covers a bunch of fairly common, mostly security-related, errors that have been found in most modern applications.

I can't comment much on the list itself as I have not yet had the chance to review the problems that they cover in detail just yet. At the moment, I'm more interested in Mr. Wolfe's article, which I find to be way off the mark in it's observations about modern software development:

You old-timers -- programmers who worked in the business before the PC industry kicked the waterfall development model to the curb -- know what I'm talking about. That waterfall model was replaced by a process (and I use that word loosely) where the modus operandi was to cram in as many features as possible before the shipping cut-off date, and then fix the problems in beta. (Sure, I know time pressures mean waterfall wasn't rigidly adhered to, and also that it had deficiencies, leading to the 1980s flowering of alternatives like agile-development and object-oriented programming. But at least we had a model.)

Leaving out his mention of OO programming -- which is a language construct that was created to help manage software complexity and not a software development methodology in and of itself -- he seems to think that waterfall was the ideal way to develop software and a sure-fire way to avoid the mistakes that were iterated by SANS.

Even more disturbing, is that he later laments that more developers should read Fred Brooks' The Mythical Man-Month, which leads me to believe he didn't really read the book very thoroughly. If anything that book actually works against the very argument he's trying to make here.

Brooks' entire premise in The Mythical Man-Month was managing complexity: As software systems grow, they become harder to design and build. He was exploring methods and organizational approaches to deal with that complexity in an efficient and cost-effective manner, because his observations from working on IBM's OS/360 had shown him that modern methods of software development just weren't cutting it.

Remember, this book was written thirty years ago.

And what was most common software development methodology used back then? Waterfall.

Granted, Brooks' focused more on the organizational side of the equation -- how to organize teams of developers to manage communication and help with the systems integration -- but he recognized that current approaches just weren't working as well as was needed...and he saw this over three decades ago.

Now here we are in modern times and software systems haven't gotten any less complex than they were back then -- in fact they've gotten much more complex as technology as advanced. And the pace at which technology advances just multiplies the difficulties modern developers face. And anyone that's even tried to take the BDUF approach (as I have) has seen how horribly bad it can be in practice in this day and age. Now I'm not going to sit here say that Agile, or any other methodology, is the absolute answer to this problem. But at this stage in the game, most software developers have recognized that waterfall is woefully inadequate to modern software development.

But even with the "right" methodology in place, that won't stop the crappy software that Mr. Wolfe is complaining about. Because it's not just the process, but the execution of that process that needs to be addressed.

And this is where I think Mr. Wolfe completely misses the mark on where the problems of crappy software really lie. As a software developer currently (which puts me in a much better position to make these observations) I can say without a doubt most of the problems that he has with current software systems lie not with software developers, but with management.

Just about every software developer I've known in my life is smart, intelligent, driven and above all desires to do a good job. They all want to write great software.

The problem is that, in far too many cases, they're not allowed to.

When a developer insists on doing more testing (or refactoring, or redesigning) of some batch code, only to have his manager tell him he's wasting valuable time, exactly who is at fault for this?

When managers don't care about anything but the bottom line, or being first to market, or say "just get it done", is that the developer's fault?

When managers insist on focusing developer efforts on less vital features, or tell them to ignore stuff like security, or usability, is that the developer's fault?

When managers concern themselves only with lines of code, or hours worked, and not on features completed, or play political games with their project in an effort to make themselves look good, or their developers look bad, rather than ensure that a piece of software actually works right, is that the developer's fault?

According to Mr. Wolfe it is.

No wonder so many of us are getting burned out.

Java and Closures

2008-12-17T07:00:00.006-05:00

A lot of people in the Java development community were hoping that closures would be coming to the Java langauge in the next major release, but with each passing day it's looking less likely that Java 7 will have closures included alongside it's many other improvements and bugfixes. And, based on some of the rumblings in the community, it seems more than a few developers aren't very happy about it. Some are even starting to whisper that dreaded "Java's Dead" meme, believing that Java development cannot last without closures as a part of the language.

Of course, they forget about the fact that Java's been doing just fine without this feature for over a decade....but anyway....

Before developers start reaching for their shovels and heading out to bury Java once and for all, I think it's a good idea to really sit back and consider for a moment what's likely holding back the inclusion of closures in the Java language. There is no doubt that getting closures into the Java language has been slower than a lot of people would have liked, but overall this is probably a good thing. It gives everyone involved a chance to really think through the options and ensure that closures are done right.

What The $%&! is a Closure?!?!?
If your programming experience hasn't ventured beyond Java, you might not have a clear understanding of what all of the fuss is about.

When programmers talk about closures, they're usually talking about two features of a programming language together.

First is the ability to create anonymous functions in-line. Think Java's anonymous inner classes only more flexible, and without that annoying need to define a class to contain the function you're creating. In fact, the proliferation of lots of annoying little anonymous inner classes in Java code (Swing, anyone?) is often used as an argument in favor of having closures in the langauge. Being able to declare a small, in-line function would streamline a lot of Java code and make a whole lot of developers' lives happier (and we all like happy developers, don't we?).

Second is the actual "closure" involved with closures: sometimes called variable capture. This is a little more complicated concept to wrap your head around, but it comes down to being able to retain references to variables that are accessed (but not declared) within a closure function, but which have actually gone out of scope.

For example, in Javascript (or ECMAScript) you can do something like this:


function foo() {
  var x = 2;
 return function() { return x*x; };
}

var f = foo();
print(f()); // "4"

In the above code, x has already gone out of scope by the time f (which is a reference to the function returned by foo) is called, yet the value of x is still retained.

Now you're probably asking: "What the hell would I need this for?"

Well, a lot of stuff. I won't go into iterating all the ways that closures can be used, because that would take all day and my poor fingers get enough of a workout from banging out code all day. Let's just say that closures provide ways to create vastly simpler code over what the Java language currently offers for similar functionality. And the fact is Java currently can't even do all of what a proper closure implementation can in languages such as...say...Ruby, for example.

The bottom line is that closures are an immensely useful feature to have in any programming language.

Sticking Point
The problem with the closure implementations that have been proposed for Java so far is that they don't (or can't) address the key feature that you typcially find in languages that support closures: Functions as first-class entities of the langauge.

When I say "first-class entity", I'm using the SICP definition¹ of what constitutes some element of a language as having first-class status:

They may be named by variables.
They may be passed as arguments to procedures.
They may be returned as the results of procedures.
They may be included in data structures.

Basically, if it can be assigned to a variable, passed as a function parameter, returned from a function or be part of some data structure it's a first-class entity in the language.

So, having functions as first-class entities in the languages means that you can declare them on their own and assign them to variables. This is something that you cannot do in Java.

Java is strictly an object (or, if you prefer, class) based language: When writing a program, nothing can exist outside the context of an class definition. As far as the language is concerned, everything must be an object.

So, you can't do something like this:


public String someFunction(int x, int y) {
 //...do something...
}

Instead, you have to do this:


public class SomeClass {

  public String someFunction(int x, int y) {
     //...do something...
  }

}

And you can't assign a function (or method) to it's own variable and call it, like you would with something like JavaScript:


var something = function(x) { return x*x };

var result = something(10);

Now, technically you can do something similar if you use reflection in Java. You can call getClass() to get the Class of the object in question, then get a reference to the Method object for whatever method of the class we want and then assign that to a variable, thereby allowing us to work directly with a method. But unless the method is static, you can't actually invoke the method without a reference to an actual instance of the class it's defined in, so you're right back where you started. Plus, you're not actually working directly with the method itself, but a representation of that method. You can't directly invoke the Method instance like you can in the above example -- you have to explicitly call invoke() and pass in an instance of the class, along with whatever parameters the method is supposed to accept. This is considerably clumsier than just being able to define a function, assign it to a variable, and then calling it as though it's just any other function.

The Workaround
This lack of functions as first-class entities in the language necessarily limits the implementation options for Java, because being able to easily define functions, assign them to variables, pass them around and otherwise treat them like any other data type is at the core of working with closures.

So, if we can't do any of this with functions in Java, how can we have closures?

The simple answer would be to change the language and compiler (and probably even the JVM) to support the ability to have stand-alone functions...which would basically break all existing code. While Python may have gotten away with breaking backward compatibility in 3.0, I think at this point it's highly unlikely we'd see something similar happen in Java.

This leaves us with the only option available: Provide some syntax elements in the language itself that make defining functions simple and give the appearance within the code that you are only defining in-line functions, but have the compiler do some translation and actually convert the syntax to the equivalent Java object notation. Essentially we have to have some syntactic sugar that the programmer can use, while behind the scenes the Java compiler is creating code that's identical to what you would get normally if you tried to do something similar without the special syntax.

Now, if you've been working with Java for a long time this probably sounds strangely familiar to you. It should: It's a similar approach to what was done to add Generics to the language. In order to ensure backward compatibility, Generic notation in Java is (for all intents and purposes) syntactic sugar added to the language to hide all the ugly casting that developers always had to deal with before². The bytecode you get when you compile Generic code is virtually identical to what you would get with non-Generic code that used the old casting-all-over-the-damn-place coding style.

The choice to take the "syntactic sugar" approach to Generics means that the power of Java's Generics is somewhat limited compared to what is possible in other languages. Mind you they don't completely suck, but there are just enough irritations with using Generics that a lot of Java developers -- even the very ones that were pushing heavily for the feature -- have not been particularly happy with the implementation.

And I think this is a the heart of why we haven't seen a big push to get closures into Java. A lot of people working on this feature know how much grief has been caused by the push for Generics and the nagging issues it caused. And I'd find it hard to believe that they aren't keeping those issues in the back of their mind as they work hard to bring closures to Java. It's no easy task trying to retrofit something like this into a language after the fact, and taking the time to get it right (or at least more acceptable than Generics are) is preferable to rushing headlong into a hacked implementation.

I'll admit that I'm not particularly enthused with any of the implementations that have been proposed to date -- none of them adequately address the functions as first-class entities problem I mentioned, so any implementation of closures we get for Java is going to be substandard at best. Nevertheless, I am looking forward to having closures in the language.

And if I have to wait a bit longer to allow the guys working on it plenty of time to get it right then so be it. The alternative will be a lackluster implementation that leaves everyone unhappy.

That's what we got with Generics, and we don't need that for closures, too.

1 - Found on page 76, or on the SICP website here.

2-Yes, this is an oversimplification. There were some changes made at the bytecode level (from what I remember), but for the most part that's all Generics are currently.

Northern Virginia Software Symposium - Day 3

2008-11-21T09:00:00.000-05:00

The final day of the conference awaited, and after two days of having all kinds of developer knowledge crammed into my head in quick 90-minute bursts of exposition, I was starting to approach information overload.

I was both happy and sad that this would be the final day: Happy because I would actually get a chance to digest some of what had already been thrown at me thus far, but sad because there was so much more I knew I could learn from some of the guys giving these talks. All of them were incredibly smart and really knew their stuff...it's hard not to want to be around these kinds of people.

Gettin' Googly
First up on my list were the two consecutive sessions on the Google Web Toolkit (GWT). The sessions were headed up by David Geary, who had given the JSF talk I sat in on the previous day.

Prior to stepping into the first session, I knew what the GWT was, but had very little knowledge beyond that. For instance, I knew that it was a toolkit that allowed developers to write AJAX applications in Java, and I also knew that the Java code you wrote looked like Swing, since the goal was to create RIAs that had desktop GUI-like properties. I also knew there was some sort of compiler/translator involved in there somewhere that turned the Java code into JavaScript. Beyond those basic features I had little knowledge of the toolkit.

My biggest problem when I first heard about the GWT is that, quite frankly, I thought the entire idea sucked. For one thing, I've been working with Swing for almost 10 years now and I can't stand it. Using Swing to create AJAX code just didn't excite me that much, so I never really made an attempt to delve further into using GWT. Also the whole Java-to-JavaScript translation just didn't sit too well with me for some reason either, but I can't say for sure why that was the case.

Well...after sitting in on these two sessions, I can say with certainty that I was completely sold on the Google Web Toolkit.

First off, the fact that the GWT used a Java-to-JavaScript compiler turns out to be a huge benefit to developers. As David explained during his talk, there's no need to worry about custom-coding JavaScript to support multiple browsers, since the GWT's compiler generates code that will support all the various browser idiosyncrasies for you, saving you loads of time and avoiding the potential errors that trying to roll your own JavaScript solution would typically entail. I totally missed this point when I first learned about the GWT...silly me.

The second is that, while the code does in fact look a lot like Swing, it's not actually Swing. As was explained during the talk, the Java code really only acts as a thin wrapper around the underlying DOM, providing a much simpler way to work with the page. Yes, there are the standard listeners and events and whatnot that you'd expect had you been writing regular Swing code, but it appears to be a much more slimmed down version of Swing programming. It also doesn't prohibit you from working with existing JavaScript frameworks, as there are ways to integrate those within the Java code you write.

Another part of the Swing stuff is that...quite frankly...writing your AJAX applications using Java and Swing, rather than just the usual straight JavaScript is actually a lot easier to do. Anyone that's worked with JavaScript knows how much of a pain in the ass it can be, and despite my own massive amounts of disgust from working with Swing all these years, I realized after attending these sessions that I'd much rather be able to write my AJAX apps using something like Swing than plain JavaScript. The GWT provides a nice mechanism for this, and makes creating something like a RIA significantly easier.

Asynchronous calls are handled pretty easily, and they seem to map really well to the Java language in the way that the GWT offers. It's pretty easy to set up a call, and provide a listener for the response.

The other really mind-blowing thing about this toolkit is that it has full support for debugging your GWT code...even after you've compiled your Java code into JavaScript. David gave a demonstration of this by actually setting breakpoints in some GWT-based Java code and stepping through each line in the Java code in his IDE as the application was running on a deployed web server and had been compiled to JavaScript. This was JavaScript running in the browser, and the IDE was stepping through the Java code that it was generated from. This was a really cool feature to see in action.

This actually tackles a problem that I hadn't totally thought about when David was first talking about the GWT: Debugging JavaScript isn't terribly difficult with something like FireBug to work with, but after you compile your GWT Java code into JavaScript you'll likely lose track of which parts of your Java code are associated with what in the JavaScript. This would normally make debugging a GWT app a nightmare unless you have some way to link the two after after you've compiled the Java into JavaScript for deployment. Google has provided a very nice way to deal with this problem and the value of this feature cannot be understated.

I think web developers working in Java already can benefit the most from this toolkit, especially if they are looking to inject some kind of AJAX-style features in their web applications. Being able to keep all (or most) of your code on both the server and client as Java, and still be able to leverage AJAX is a huge benefit to a project. This is obviously where the GWT is targeted, but I got the impression from a lot of people sitting in on these sessions that they weren't really expecting GWT to be as full-features and powerful as it is, which makes me think that it's a seriously misunderstood technology.

Google should be doing a better job promoting the GWT, as I think it's a pretty significant leap in AJAX development for Java developers.

I was extremely impressed with the GWT following the these two sessions David Geary.

More Groovy
For the next talk, I decided to sit in on another Groovy session. This time, it was Jeff Brown giving a talk on Groovy's metaprogramming capabilities. Jeff had sat in on the Birds of a Feather session at the end of the previous day's festivities, and after hearing what he had to say there I thought it would be worth it to hear more of his thoughts about Groovy.

Scott Davis had covered some of Groovy's metaprogramming capabilities back on the first day of the conference, so I had a basic understanding of some of what Groovy could do in this regard. Jeff, however, when into significantly more detail in how to work with Groovy's metaprogramming features, and provided a great number of examples on how these capabilities could be leveraged in a real project.

Starting with the Expando class, Jeff went on to cover things like Closure delegates, and the ExpandoMetaClass, which is used to dynamically add behavior to the existing core Java classes.

Jeff also covered the implementation of builders for various uses -- a builder to easily construct XML based on Groovy code, for example.

One example he showed that resonated with me was the SwingBuilder. This builder class made constructing GUI widgets in Swing significantly easier, and has made me consider adopting this for my current project (provided I can make a good case for it...and maybe get a proof of concept going). Working with SwingBuilder appeared to be significantly easier than anything I've seen anyone try to implement, and I'm all for making my code simpler. Groovy really shines at this, for sure.

Jeff also covered ways that the dynamic method dispatch in Groovy can be leveraged to make more meaningful queries to a database. For example, by being able to call methods like .findByKey("foo") directly on a class when those methods don't actually exist until runtime, and are dynamically generated based on the name of the method itself. There is some really powerful concepts here that can make a lot of Java projects easier to work with, and this is really where I started to see Groovy's capabilities shine.

Between this talk and the two previous ones, I've been pretty well convinced that Groovy has a lot of potential, and I look forward to trying out some of these features for myself.

Black Hats
For the final session of the day, I attended another talk by Ken Sipe. This time he talked about Hacking...as in the breaking-into-phishing-scamming-doing-bad-things kind.

Once again this was more of a overview, and sadly there were some technical difficulties during this talk that prevented Ken from really being able to demonstrate some of the things that he was talking about (seems the internet connection for the conference was cut off prematurely). Nevertheless, it was a fun and informative talk, and what things Ken could show us were fascinating.

Ken gave lots of good bits of information during this talk. And while I'm not going to iterate everything he was talking about here, for obvious reasons (if you're smart you can probably figure them out yourself), one thing I took away from this talk was this:

We're all incredibly naive about security.

I think I finally understand why Bruce Schneier changed his point-of-view about security from that of a purely technological solution, to that of a psychological/sociological problem that cannot be easily fixed. Far too many people out there either just don't understand, refuse to acknowledge, or are overconfident in their security measures when it comes to software development. And there is definitely not enough critical analysis going on that there really should be.

The End
And with the end of this last session came the end of my time at the conference. I had a blast attending all of these talks, and learned so much in such a short time that I'm going to be spending months evaluation all of the options that have been opened up before me. I'm amazed at home much I picked up here, and I'm looking forward to attending this again next year.

Hell...I may actually try to pay my own way if I have to...

Northern Virginia Software Symposium - Day 2

2008-11-20T09:00:00.000-05:00

The second day of the conference got off to a bit of a slow start for me as I was trying to recover from the previous day: I was still processing the flood of information that was tossed at me from those first sessions, and since the schedule for the previous day ran well into the evening hours (past 8pm) I had a pretty late night -- an hour's drive home from the conference, then taking care of things around the house meant that I didn't hit the bed until around midnight. I then had to turn around and get up early in the morning and drive back and do it all over again.

Going to this conference felt just like work...only more entertaining.

JavaSever Faces
After getting some food...and plenty of coffee...into my system, I headed off to David Geary's talk on JSF. While JSF has been around for a while now, I hadn't done much of anything with the platform before. Most of my work on the web side of the universe has been primarily with Struts 1.x (which surprisingly still gets plenty of use out there), and I've since jumped straight over into learning the various RIA platforms -- Flex/Flash for example -- and never really bothered to work with anything else, other than a brief foray into SpringMVC. So I thought it might be worth it to at least see how JSF compares to "ye ole decrepit web framework".

I'd heard or read various competing viewpoints about JSF -- some saying it was great, others that it sucked. Of course, a ninety-minute talk isn't going to make a very good case either way, but I figured that if I didn't get very excited about it in that time frame like I did about Groovy then odds were that it wasn't going to be worth pursuing much further.

Based on David's presentation, JSF seems like an incremental improvement over Struts, and in fact it was mentioned that several of the people involved in the creation of JSF were also involved in the development of Struts back in the day. It's definitely a nice improvment over the way Struts does things...but that's probably not saying much these days as anything is an improvement over Struts. Struts was great when it first was released, but it has not kept up with the times well, and other frameworks have done a much better job at managing complexity in web development. The fact that JSF is only an incremental improvement means that JSF isn't necessarily keeping up with the times either.

This seemed evident when I started hearing a lot of "coming soon" talk later on during the presentation -- various features or ideas that haven't been added to JSF, but are slated for the next major release. I don't necessarily hold that against the framework -- at least it's trying to evolve -- but it's obvious that it's showing it's age compared to other options out there.

I just couldn't get too excited about JSF.

GIS in a nutshell
The second session of the day was another one with Scott Davis, this time covering GIS -- the location-based techonology underlying applications like Google Maps, and those wonderful little in-car navigation systems we've all come to rely on lately. As usual, Scott gave a very entertaining and engaging presentation, as he demonstrated his own work with GIS technologies and covered all the important parts that most developers need to know when it comes to dealing with georeferenced data.

I've dealt with GIS-related technologies on previous projects, and I know how absolutely frustrating and maddening it can be trying to sort it all out when getting started. There are so many technologies and concepts that you have to learn and figure out that it can be a bit overwhelming to anyone making their first foray into the realm of GIS. I personally struggled figuring out a lot of it (and based on this session there was still plenty that I was missing), so this session was a welcome way to ease into GIS development. It covered all the important points and gave enough information to let even the most novice GIS developer dive in and start working with the technology.

Scott is obviously an big fan of open-source technologies, as he mentioned plenty of great OSS options for developers like uDig and PostGIS for getting up and running with GIS development. Not only that, but he pointed out places on the interenet where developers can find freely available GIS data -- something I never even considered in my GIS development days -- that can be downloaded and used for your own projects.

He also covered some of the pitfalls in working with this freely available data -- things like getting data that uses different coordinate systems to work together, which is something that just about anyone will run into when working with GIS at some point or another. He explained some of the different coordinate systems, and pointed out what was necessary to reproject data from one system to another.

Scott talked about OGC Web Feature Service (WFS) and Web Mapping Service (WMS) specifications as well. These are basically standard ways to take GIS data and present it through a web service so outside entities can use that data for their own application. I've had some experience with these myself (not all good, but I won't get into that here), so it's something that developers may want to get familiar with at some point.

Once again, I really enjoyed another talk by Scott. He presented lots of useful information in such a short time, and gave me plenty of stuff to look at...if I ever get any time to do so, that is.

Java's Dead!
Following the lunch break I attended Stuart Halloway's java.next talk, which covered a lot of material he talked about in this blog post. This talk was a continuation of the theme that started with Scott Davis' talk on Groovy, covering some of the alternative languages available for the JVM. While Stuart did talk a bit about Groovy as well, he also covered JRuby, Scala and Clojure.

Stuart started off this talk with everyone's favorite meme: Java's Dead.

That's always a great way to get Java developers' attention :)

When Stuart made this remark, I wasn't totally sure if he was being serious or just trying to be provocative. Maybe it was a little bit of both. Either way, I think he was trying to get the people in the room to understand that programming exclusively in the Java language wasn't going to last for much longer. It's not a case of Java being bad (although it does get some things wrong, as Stuart explained during the talk) but simply the needs of software developers have evolved and Java is ill-equipped to deal with them in its current form. The only question has been what language(s) would take its place.

Of course, trying to answer the question, "which language is better" is a fools errand, and this session wasn't really about figuring that out. The talk was really about pointing out the things that the Java language got right along with the things that made developer's lives harder, and how these languages could potentially help ease the pain by leveraging the good and avoiding the bad. It was really a fascinating topic to listen to.

There was some discussion about the JVM itself, which covered the features that, while enforced by the Java language, were not enforced by the JVM -- checked exceptions being a particular one that I remember Stuart mentioning. I found some of this interesting, as I had always thought that the Java language and the JVM were closely tied to each other. And while they do share some commonality, it appears that there are enough differences that other languages can potentially leverage those difference to their advantage, which is something that several of these newer JVM languages do.

What also piqued my interest during this talk was Stuart's mention of the work he's been doing with Clojure, and the fact that he's working on a book on the language (the book is available in beta form currently) -- something that I'm actually anxiously awaiting. As I mentioned before, I've played around only briefly with the language, but it's a lot of work to get off the ground when you a) Haven't worked with any Lisp-like language in a while and b) Only have the various documents and wiki's on clojure.org and group discussions to work with.

Stuart mentioned something he did while learning the Clojure that I was actually considering myself prior to the conference: He started working through the examples in the book, Practical Common Lisp, using Clojure instead of Lisp. I've read the book (and it's a great book for learning the Lisp language) and I think this is actually be a pretty good way to learn Clojure since there are very few sources of information currently available.

Overall, this was a great experience. I could tell from his presentation that Stuart is a fantastically smart guy, and listening to him talk about next generation languages for the JVM was a lot of fun.

7 Habits
Of course, rather than sit in on the second part of Stuart Halloway's talk (which I kind of regret), I opted to sit in on Ken Sipe's talk about the "7 Habits of Highly Effective Developers". I wanted to get a chance to listen to more than just one or two speakers for the day, and Kevin's talk seemed like a nice subject to listen to, since I'm always looking to improve my skills as a developers...not just through code, but through proper habits.

The name of the talk was obviously a play on the book The 7 Habits of Highly Effective People, and much of the talk was framed within the context of those original habits that Steven Covey presents, with references to each of those same habits adapted to the world of software development. Basically anyone familiar with Covey's book would immediately be able to pick up on the points that Ken was making during this talk.

In fact, this talk seemed almost like a mashup between the 7 habits book and The Pragmatic Programmer, since there's a lot of similarity in the philosophies between the two. So anyone that's read either of these two books would know much of the subject matter covered in Ken's talk.

(Thinking about it...every developer should have the PragProg book on their shelf...if you don't GO GET IT NOW!)

Anyway, this talk was another great one amongst many so far. And I was anxious to see what kind of information I could cram into my brain the following day...

But there was still one more thing to do...

Flocking Together
After the last session, I attended the Birds of a Feather session on alternative languages for the JVM (noticing a theme, here?). Both Stuart Halloway, and Jeff Brown (coauthor of The Definitive Guide to Grails, 2nd Edition) headed up this session, which wasn't really a presentation so much as an informal talk and Q/A session for developers. It was basically a way for everyone to just chit-chat about stuff they know, and to ask questions of each other.

One question I tossed out there was how either of them felt about having so many languages running on the JVM, and whether that might actually be a bad thing for developers. While I certainly see the potential benefits of multiple languages, my one fear about having so many languages is that someone's going to get it in their head that they can use 4 or 5 different languages on a project, and ends up creating a codethulu-like application of epic proportions. I'm a little worried that this might reflect badly on all JVM languages.

Of course, both thought that in the long run it was a good thing having all these options. But Jeff also pointed out that people have to really just not be stupid, and it's up to the project managers to really make sure that things don't get out of hand.

I also threw out a question to Stuart regarding his experience doing the Lisp-to-Clojure translation of the Practical Common Lisp code samples, and mentioned how there seems to be a lot of buzz circling Clojure these days (of course, this is based solely on what I've read from the Lisp50 talks). Stuart is a big fan of Clojure (he's writing a book about it, after all), and he said that there's not only a lot of stuff that the language does really well, but he's found very few things to dislike about Clojure so far -- and any time he's thought something was odd about the language, Rich Hickey (the creator of Clojure) has provided a really good reason for why Clojure does things the way it does. To Stuart, Clojure does it's job in a clear and concise way, and just makes a lot of sense.

Since I haven't delved too deeply into Clojure yet, I can't really agree or disagree with his sentiment, but I could definitely tell that Stuart finds the language fascinating. It's given me more motivation to delve a bit deeper into the language, and I'll be keeping an eye out for that Clojure book when I take the time to look closer at the language.

Another topic that popped up was a discussion about migration paths for developers in moving to another JVM-based language. I don't remember the details specifically, but I do remember both Jeff and Stuart mentioning that they think Groovy provides the easiest migration path out of any of the alternative JVM languages available thus far. And based on what I had seen at the conference up to that point, I'd have to agree -- Groovy is remarkably easy to work with for existing Java developers, and it's interoperability with existing Java code is remarkable.

Overall, I really got the impression from both of them that they think that Groovy is likely going to be the next big step in JVM development. Of course, Jeff might be a little partial to Groovy, due to his extensive involvement with it, but I can still merit to this argument. I think there may be some obstacles to starting a migration (which I won't get into here), but I certainly wouldn't complain if Groovy gained widespread adoption.

We wrapped up the session, and I headed home to get some rest.

Day 3 awaits...

Northern Virginia Software Symposium - Day 1

2008-11-11T09:07:00.012-05:00

Groovy
Early on I had made up my mind that I would check out the two sessions on Groovy. These would be the first two sessions of the conference that I would attend, and both set the tone for the rest of my experience there. Scott Davis gave two great presentations regarding Groovy: The first -- called "Groovy: The Blue Pill" -- covered the basics of what Groovy was and its relation to Java, while the second -- "The Red Pill" -- dove into Groovy's metaprogramming capabilities.

I have to say that watching Scott Davis give a presentation on anything (I sat in on another presentation he gave later in the conference) is a lot of fun. He's a true geek in every way you could think, and his love of the subjects he talked about shows. He's smart, witty, and downright fun to listen to. I could listen to this guy talk all day.

Prior to these first two sessions, I hadn't really investigated alternative languages on the JVM other than a brief look at Clojure a few weeks beforehand, which arose out of curiosity following my reading of Lispy's notes on attending Lisp50, where Clojure was mentioned in the last part of his account. Like Lispy, I hadn't really been too receptive to alternative langauges on the JVM, but unlike him I wasn't totally closed off to Java since I use it in my current work.

Scott started off the first talk with comparisons between Java's syntax and Groovy's. From a syntax standpoint, Groovy reminds me of Python, with a few bits of Ruby mixed in here and there. According to Scott, the Groovy language was designed to leverage the strengths of those (and other) languages, while also improving upon existing conventions that Java developers are already familiar with. For instance, Groovy takes care of many things automatically that Java developers normally are forced to do themselves, either through hand-coding or by making heavy use of their IDE. Conventions like class variables being private by default, and methods public unless otherwise specified with the usual keywords are examples of where Groovy saves a developer a lot of extra typing. Also, there is no need to manually code getters and setters as Groovy takes care of adding those when a class is compiled.

Groovy is also a dynamically-typed language, which further reduces the amount of code that a developer has to worry about slapping down. I know a lot of developers aren't too keen on the idea of dynamic typing, but it's hard to ignore the amount of up-front coding effort it reduces. When I watched Scott bang out 30+ lines of standard Java code for a class, then turn around and create another identical class using only dozen lines of Groovy -- if that -- it's hard to ignore the benefit of using a dynamic language. I was amazed at how just these few simple conventions made classes extremely easy to both read and maintain -- lots of complexity disappears.

The other significant feature of Groovy is that when you are creating Groovy code, you are actually creating Java code, or more specifically Java bytecode, since Groovy's compiler compiles everyting into standard JVM bytecode. This provides an amazing amount of interoperability between the two languages, as anything you can code in Java you can do in Groovy...just much simpler. Groovy provides such seamless integration between the two languages that you can literally switch back and forth between them both in the same project, leveraging Groovy's capabilities where you need to without sacrificing Java performance.

Scott gave a good example of this interoperability in his demonstration comparing Java and Groovy's syntax I mentioned above: He seamlessly created both Java and Groovy code within the same project, and they both worked perfectly with each other. The seamless way these two languages work with each other is something that I think is huge for Java development.

The metaprogramming portion of Scott's talk was equally fascinating. He went into details about Groovy's more advanced capabilities: Method pointers and operator overloading, the ability to monkey patch the core Java classes, and Closures.

Both method pointers and operator overloading were interesting in and of themselves, but combined with the ability to monkey patch the core Java classes (something that Ruby developers are already familiar with) and it's implementation of Closures -- something that Java developers have been patiently awaiting for a while now -- makes all of these features very powerful to have. The ways in which they can be used together (and Scott gave a few examples) is very cool, and doesn't fill me with dread like it did when I first listened to him explain how they work.

After these two talks, I felt that there was a whole world of Java development that I've been completely missing out on. The power that a language like Groovy can provide is astounding considering that it's simply leveraging the existing capabilities of the JVM. Why this language hasn't gotten more attention is beyond me.

I'll definitely be keeping an eye on Groovy...and I'll probably start finding ways to leverage it in future projects.

The Fit Client
It's hard to follow up such a great batch of talks like the Groovy sessions were, but I sat in on a session by Richard Monson-Haefel on the rise of the "Fit Client" and still had a good time.

Unless you've been living under a rock as a Java developer, odds are you probably know who Richard Monson-Haefel is by way of his well-known book, Enterprise Java Beans. He started off his talk jokingly apologizing for making this book, as it was the impetus for many to dive into EJB development (myself included -- I still find it to be one of the best technical books I've ever read...despite the subject matter), which in turn caused so many people to hate EJB forever.

This session was an overview for what Richard called "Fit Clients": Technologies that have a hybrid thin client/thick client configuration such as Adobe AIR, Java Web Start, Google Gears and so on -- all of which allow parts of applications to reside locally, while accessing data and updates via the internet (that's obviously grossly over-simplified, but you get the idea). Admittedly, I was already familiar with some of these technologies -- either through my own projects at work or through my own experimentation -- so I really didn't get as much out of this talk as I would have liked.

Nevertheless, I did still glean something interesting from the session...

What was interesting was that, despite the mention of Java Web Start early on in the talk, Richard made very little reference to it after that. He also made no mention of JavaFX (that I recall, anyway). This indicates to me that Sun has a lot of headway to make in this area -- come on...if friggin' Richard Monson-Haefel isn't talking about something like this, then there is definitely a image problem for Java on the RIA/Fit Client front. And after attending this conference I know he's not the only one. That's a huge hurdle in my book. I personally feel that a big reason for this is JavaFX and (to a lesser extent) Web Start being tied to Swing, which is dreadful for most developers to work with (and this is coming from someone that's been a Swing developer for damn near 10 years now).

In fact, Richard did say pretty explicitly that Adobe seems to have the clear advantage with it's AIR platform (at this point, at least), which I can certainly agree with based on my own experience with Flex/Flash. He also mentioned that Microsoft's Silverlight will probably be making a play for this space in the future as well (although nobody has any details on this as yet).

At any rate, despite already knowing the subject matter a bit, I definitely enjoyed Richard's presentation...and it was neat to be able to see the author of one of the best books I've ever read up close and personal, too.

Career 2.0
Jared Richardson gave the keynote to cap off the end of the day's events, and it covered the tools and techniques that software developers need to leverage to stay on top of their game in today's world. It's a timely topic, given the implosion that is the U.S. economy right now, and I'm sure many developers out there have been scratching their heads wondering what the best ways to jump start their career could be in this kind of economic climate. Everyone knows that the best developers are always in demand and gainfully employed...so how do you become "that guy" that people look for?

Jared covered quite a few areas that most developers are likely familiar with: Participating in user groups, networking with fellow geeks, and the like. Of course, he mentioned attending a conference, too...but that one's a bit redundant, probably.

He also made a really good case for blogging, and not only using it as a means for improving your own ability to communicate (by improving your writing and your ability to formulate arguments), but also as a means to get noticed by writing something useful to others. A good example would be something along the lines of this post I made some time ago. This has a much higher likelihood of increasing your visibility to the larger community out there than trying to pontificate about various aspects software development (although this does work for some people...just not most of us).

The keynote was very enjoyable, and made me wish I had sat in on some of Jared's other talks during the conference that day as he was a very entertaining speaker. He gave me quite a few things to think about (and probably pointed a few ways I've gone wrong with this blog) and that I'll remember as I try to further my software development career.

I learned quite a bit on that first day...and there were still two more days to go...

Northern Virginia Software Symposium - Intro

2008-11-10T10:42:00.009-05:00

In the almost ten years that I have been developing software professionally, I've never had the opportunity to attend any kind of conference -- technology-related or otherwise. For one, I could never convince an employer to foot the bill to send me to an event that, as far as they were concerned, was just a bunch of geeks goofing off: Any time I'd bring it up I would be met with a resounding "NO," followed by a detailed explanation of how I get paid to sit in my cube and bang out code, not to go schmooze with other developers...so I better get my butt back in there and keep on writing code and stop all this crazy talk.

Of course, the alternative would have been to simply pay my own way, but when you do the math and look at the combined price of admission, lodging, travel and so on to most of the well-known conferences it's just too much damn money out of my own pocket -- and nowadays I could never get approval from my accounting department (A.K.A. my wife), anyway. It's kind of hard to convince the wife to spend that kind of money when there's a mortgage to be paid, kids to feed, etc...go figure.

At this point in my career, I'd just resigned myself to the fact that I would likely never get to go to a conference.

So earlier this year I received a bit of a surprise from my current employer when it was suggested that they would be willing to send a few developers to a local conference. They didn't have a huge budget to send us to something like JavaOne, or some other equally high-profile (and expensive) conference, but the suggestion was made to us to attend a No Fluff Just Stuff conference, which had come highly recommended by a few other developers in the organization. It was also reasonably priced, and rather than being a big conference in someplace like California, it was actually a series of smaller conferences held throughout all parts of the country, making it more accessible to the average schmo that can't afford to hop on a plane and stay in a hotel room for a week.

For those that have never heard of, or attended a No Fluff Just Stuff conference, the name pretty-much says it all: It's a conference where presentations are given with little embellishment or market-speak, or crazy pie-in-the-sky promises that a technology will end world hunger, save the whales, cure diseases, do the dishes, put the kids to bed, blah blah blah...you get the idea. It's real geeks talking about real-world technology to fellow geeks. The topics covered are all related to various new or up-and-coming Java technologies, along with many discussions covering project management-related stuff like Agile processes, Test-Driven Development, and so on, each of which are also covered within the context of various Java technologies.

So, not being one to look a gift horse in the mouth, I said "what the hell, let's give it try." I'll take whatever opportunity I can to listen to, and possibly pick the brains of, some of the guys in the Java world that are way smarter than I am. So my colleagues and I were given an initial verbal agreement that we would be able to attend the Northern Virginia Software Symposium, held in Reston, Va. on November 7-9.

Now, in all honestly, I still was not completely sure my employer wasn't just blowing a bunch of smoke up our collective butts when they first told us this -- just holding out the possibility of attending the conference like the proverbial carrot-on-a-stick -- until the day I received confirmation of the ticket purchase in my email. It's not that my employer is terribly untrustworthy or anything...it's just that I've been around the industry long enough to know that some like to play those kinds of games with their employees -- I'd grown a bit cynical.

So, after getting the email confirmation that we were most definitely attending, and (thankfully) having my cynical mind put at ease, we were all set to go to the Northern Virginia Software Symposium.

At this point, I just needed to get prepared...which really only involved me trying to figure out which presentations to sit in on based on the schedule that I'd received. There were quite a few topics that piqued my interest and several were in the same time slot together, which meant I really had to figure out which ones were worth my time. I'd recognized many of the speakers' names, as I'd either read or knew of the books they had written: Brian Goetz, Richard Monson-Haefel, and Jared Richardson, were just a few of the many smart guys in the Java realm that would be speaking during the conference.

Sadly, I couldn't sit in everyone's presentations, but once I had a general idea of what topics I wanted to hear about, all that was needed was for me to hop in the car and head to Reston for each day of the conference.

And so, I arrived in Reston on the first day of the conference with my agenda set (for the most part) and eager to start learning what some true geeks of the Java world were up to...

Whoops...Nothing to See Here....Move Along....

2008-11-10T10:31:00.004-05:00

In the process of trying to create a new post, I inadvertently published the darn thing before I actually had finished it (hate it when that happens)...

So if you happened to see a half-finished post about the Northern Virginia Software Symposium pop up, please ignore that one...can't have those half-finished thoughts floating around. I've removed the post from the main page until I can actually...you know...finish it.

I will repost it shortly.

DZone Woes

2008-10-10T16:16:00.005-04:00

DZone -- along with Reddit, Hackernews and a few others -- has been one of my favorite places to check out software development news and blog posts for a while now. Despite my initial misgivings about the site when it first came online some time ago, I've found it to be an indispensible tool for information on anything programming language, or computer science related.

Over the past week or two, I've started to get a little worried about what I'm seeing coming through the new links feed at the site: Lots and lots of spam. Basically everything that you'd typically find dumped to a spam folder (or deleted entirely) by an email filter is showing up in the new links feed.

I'm guessing this likely is due to the recent breaking of both Microsoft's and Google's Captcha -- I've seen a lot of links showing up with a blogspot.com address in the feed.

Whatever the reason, I'm hoping the guys at DZone can figure out a way to deal with this. I'd hate to see such a useful tool get bogged down by rediculous garbage like this.

Oh...and the people that do this crap should burn in hell, too.

A Moment of Awe and Terror

2008-09-29T13:01:00.002-04:00

Caught this over on YouTube -- Global Air Traffic over a 24-hour period (time-lapsed):

I find stuff like this immensely cool, particularly when you think about the innumerable systems, technologies, and people that have to work together in concert to ensure that all of those little dots shown get from A to B without running into each other...or anything else, for that matter.

I also find myself feeling a slight tinge of terror, because I also realize that when I look at the flowing swarm of blips (particularly in the U.S.), and despite what certain professors may think, some of them are very likely using software that I wrote...

...in Java...

...by myself.

Holy Shit.

Design Patterns Aren't From Hell: They Were Driven There by Developers

2008-09-25T09:39:00.003-04:00

Got a link to a post via Raganwald's feed the other day (he doesn't post anymore, but he does still throw out links to great posts via his feed), which in turn reference another post titled "Design Patterns are From Hell!"

Both of the posts make plenty of good points, and I don't find myself particularly at odds with anything specific that's been said. Nevertheless, I'm a little worried about some of the ire that's been directed at Design Patterns in general lately. There's been a great deal of anti-patterns ranting these days, and it has me a little worried that the entire point of Design Patterns (as I see them at least) has been completely lost on the developer community. I think a lot of the backlash is equally as bad as the rah-rah attitude that got us into a mess with Design Patterns to begin with.

I'm not a huge advocate for Design Patterns, but I don't hold them in such low regard as most developers now seem want to do. When I first read the Design Patterns book, I understood the premise behind the Gang of Four's writing to be them saying something along the lines of this:

"Hey there! We've been developing software for so many years now that we've noticed a few things that consistently pop up in the structure of our code -- here's the patterns we've found so far. Check 'em out. You might recognize some in your code, too, but if you don't it's really no big deal. We just thought we'd jot them down and see if anyone else has seen similar patterns in their own code."

Like building architecture and that other patterns book that many people reference, the GoF guys looked at a bunch of recurring patterns in their software architecture and decided to catalog them. They thought it might be useful to point them out and perhaps find ways that code might be similar across different projects, and maybe use this knowledge in some way to help push software development forward.

Unfortunately, our industry -- with it's silver bullet mentality -- looked at Design Patterns the way we first looked at things like Object-Oriented programming and Agile Software Development: As the Ultimate Solution To All Problems.

Basically a lot of people read the book and saw this:

"Hey There! We've been doing software development for many years now and have noticed some patterns popping up in the architectures of our big, successful projects. We think that if you use these patterns in your projects that you'll succeed as well! Even better, there won't be any need to actually think about your software's architecture! Just plug in that Visitor with a Singleton and a Strategy Pattern and you'll be well on your way to project nirvana!"

Which resulted in the kind of thinking that got us projects being considered a total failure if they didn't use all of the GoF patterns explicitly, or that a project could not be successful without these patterns in it.

Design Patterns are not evil, but our use (and abuse) of them certainly has been.

The purpose of Design Patterns was never to be the answer to any specific problem, but simply as a method for recognizing similarities across projects in the hope of perhaps finding some points of commonality that could be exploited in some way, making all developers lives easier. Unfortunately, the industry never saw them that way: Instead of looking for ways that our code was already similar, we tried to shoehorn our code into the patterns so that it would be similar, regardless of whether it really made sense to do so.

And now that software developers have turned their projects (and potentially the industry) into a mess by trying to adapt code to fit the patterns, the patterns have gotten the blame for the results. Design Patterns were merely meant as a means to an end -- to try to come up with ways to make software development easier by examining commonality -- not an end unto themselves. It's not the patterns that should get the blame, but the developers that misunderstood and/or misused them.

The only reason Design Patterns have gone to hell is because we drove them there ourselves.

My Stack Runneth Over

2008-09-15T18:35:00.004-04:00

So Stackoverflow went into public beta today and I finally decided to take it for a short spin. I'd been following the development of the site via the podcasts from the founders, Jeff Atwood and Joel Spolsky, since their first episode, so I've been curious how everything would turn out based on the conversations about the project they were attempting to have in the podcasts. I say attempting because their podcasts regularly veered off into other topics...which wasn't a bad thing as I like to hear about other topics developers have interest in, and those topics have been equally enjoyable.

I almost signed up for the close beta, but decided to wait until the site went live, and Jeff and Company had time to work out some of the more pressing issues with the site. Of course, the fact that I've had a fairly limited amount of free time as of late also meant singing up wouldn't have been very useful, too, but that's neither here nor there.

At any rate, I like what I see so far. It's a nice simple site (simplicity is always a good thing in my book), and searching and asking questions is fairly easy to do. All in all, I think this site will be very handy for a lot of developers out there.

I do have a few nitpicks, though. Nothing major. Just some general observations:

The site still has a bit of an unrefined felling to it. It functional, but just seems...I don't know...rough in places. I guess a good example is the display of reputation badges: Currently they are just a fairly plain-looking graphical block with text, so they look kind of ugly. A nice graphical icon for each badge would look nicer. This is minor, of course, and I'm sure it'll be improved upon in the future.

Also, browsing the current crop of questions, it seems that a lot of the questions are there for no other reason than to farm reputation. I see plenty repeated questions, all phrased differently, that would have popped up in a simple search had the person asking the question bothered to do a search at all before posting. This signals to me that people are trying to flood the system to build rep as quickly as possible (Admittedly, you could probably use me as an example of this, since the question that I posted was pretty simplistic...but I had another reason for posting it, too, as I'll explain later).

I think early on this is going to be an issue, as people try and toss out as many questions as they can to get reputation quickly. Of course, as time goes on, this won't be as much of an issue, so I'm happy to just wait this problem out. The design of the system itself should help weed this problem out, as the more useful and meaningful questions will be reference and voted upon more frequently.

As I said...minor issues. And they won't stop me from making use of the site.

As for my own question: It was fairly rudimentary one to try out the system (which I'm sure many people did for similar reasons, which would explain a lot of the repetition I mentioned )-- it was a fairly simple question regarding Flex that I could have simply looked up without going to Stackoverflow, but I felt it was worth adding to the site. One of the things that Jeff and Joel (I think it was Joel more than Jeff) were worried about in the podcasts was wether the site would become a haven for C# and .NET, or Microsoft technology in general (which they both work closely with on a regular basis), and not have much material for other technologies and languages. So I figured throwing questions in the mix that were outside that realm would help spur others to do the same (I should note that they both seem to not like Flash/Flex and similar technologies...which makes asking the question on Stackoverflow that much more interesting :-) and otherwise help keep the site from getting pigeonholed into a Microsoft-centric place.

At any rate, I can see where one could easily spend a lot of time reading and answering questions on Stackoverflow...so if you go there beware! A days work could easily be wasted.

But the rewards will probably make it well worth it.

A Good API is Hard to Find

2008-09-12T09:33:00.002-04:00

So someone's saying that the Flash and Flex APIs lack quality.

Based on the first sentence of the blog post, the author is basing his quality assessment of Flash/Flex with Java's API, but anyone that's been using the Java API for more than a year or two knows that such a comparison is ridiculous on its face. Java has tons of glaring problems in it's APIs. I've been using Java since the 1.1/1.2 days and I can say without a doubt that there are some atrocious problems with Java's API -- inconsistencies just being my own personal annoyances within. You can probably add to that the annoying fact that the Java API is littered with deprecated classes and methods dating back to Java 1.1 that have yet to be removed .

And if you think Java's immune from the poor use of inheritance, I gladly present to you the JavaDoc for java.sql.Timestamp.

I'm not defending the poor choices Adobe may have made in their APIs, nor am I trying to knock Java's sometimes-annoying API problems, but lets be realistic here shall we. No API is perfect. Be it Adobe, Sun, Microsoft, Apple....the list goes on. Everyone has made some sort of annoying idiotic choice within their APIs that make developers the world over that use it want to scream in holy terror at the mere sight of such poor design.

Getting an API perfect is virtually impossible. Especially when your evolving your platform at blinding speed to meet the sometimes-impossible demands of developers clamoring for your product. That's no excuse to make a bad API, either, but it's a good reason for why APIs aren't as high a quality as we would all like. API development is just as complicated as any ol' software project...probably more so.

Personally, given my limited time using Flash/Flex, I've found Adobe's platform API much cleaner and easier to work with compared to Java's. Is it perfect? Heck no. But it's a step in the right direction. They do enough stuff right to make me forgive them for the things they may have gotten wrong.

But the real key here is to see how well the Flash/Flex APIs can stand the test of time. Platform API don't usually age well. When you have to factor in backwards compatibility for existing software with trying to move a platform forward, you get all sorts of wonderful ugliness in APIs. Microsoft understands this all too well, I'm sure.

Also, if Adobe can keep the APIs from reaching the ginormous size that Java's has become (which makes it a real turn-off for aspiring developers, let me tell you), that alone will be a big win in my book.

This is the one lesson (among many) that I hope they learn from Java.

WOW...

2008-07-27T12:16:00.003-04:00

This news is buzzing through the 'net so fast it's going to make Disney's head spin...

I first picked up on it over at Ain't it Cool News, when a post on Thursday indicated that Disney had shown something interesting at the San Diego Comic Con.

Now, anyone that's a part of my generation -- the Generation-X crowd...especially those of us born in the early-to-mid 70s, whose formative years that encompassed most of the 1980s -- were heavily influenced by many movies during our youth. Star Wars is an obvious one. Those famous movies from Lucas made us believe that technology could be bad-ass, and useful, and made space travel seem awesome. And like them, many other movies helped push the idea that technology was cool in various ways, and we've taken that to heart in our adulthood.

Tron was different.

Tron didn't just show us that tech was cool, but brought in the idea of a world inside the computer. A world that opened up the imaginations of many kids. While today the movie might seem quaint, or outdated, at the time of it's release is triggered inside many kids the ideas that have brought us what has now become the billion-dollar industry of computer games.

It also showed us that the world of the computer could be ours to command and control, and planted the seeds in many of us (myself included) that would inspire us to become programmers.

I cannot understate just how influential this movie was to many geeks from my generation.

Tron wasn't a smash hit when it was released, but it's become such an iconic movie of the Gen-X crowd that there's been talk of a sequel going back now since at least the mid-90s, if not farther. I've seen various ideas and comments from Disney, Steven Lisberger, and others talking about plans for the movie over the years, and ultimately it seemed that the passage of time, and the march of technology, had made it far too difficult to make a more modern adaptation that could even do the original credit. It just seemed that our modern world had made the idea of a sequel too difficult to pull off.

And then Gizmodo showed this, along with Autoblog, and of course Ain't it Cool News had it (but they had to pull it).

Oh...my...god...

Judging by the buzz from the super-crappy video footage, this movie may have the goods and then some. I can't wait to see this in full digital glory (hurry up already, Disney, and let the rest of us see it like it was meant to be seen!)

I honestly didn't think Disney could pull off a Tron sequel, but if this clip (even in it's crapified form currently) is any indication of what they are going to do for the sequel, this looks damn good. And I will likely be the first one in line to see it...and I haven't seen a movie on opening night in loooong time. I cannot wait to see this in a theater.

There's just one thing missing...

End of Line.

Observing the RIA Landscape

2008-07-26T11:13:00.005-04:00

Following up on my JavaFX and Flex post, I've been following some of the commentary coming from developers about JavaFX, Flex, and even Silverlight. Since I haven't been able to investigate any of these technologies in any real depth myself, it's been informative seeing what other's have been experiencing with these RIA platforms.

Based on what I've been reading and the brief experiences I've had so far with these platforms, I'm going to give my general opinion of the JavaFX/Flex/Silverlight landscape at this point. Now before anyone decides to get evangelical on me, keep in mind that everything is still very much up in the air with regard to these technologies, and it's anyone's game to win/lose. As I stated at the end of my JavaFX/Flex comparison post, these platforms still have a lot of potential and I look forward to continuing to explore them in the future.

I also what to point out that I really have no preference between any of these technologies at this point -- a big reason being that I'm not currently involved in any project that even requires such technologies. This is just my point of view being someone whose just starting to get their feet wet and trying to figure out which direction to go.

In general, between the three technologies I think currently Flex is clearly in the driver's seat. They already have a big head start over JavaFX and Silverlight: Flex 4 is already around the corner, while JavaFX and Silverlight are really just coming out of the gate. Flex is stable and there's a huge installed base to work with through leveraging Flash as the deployment platform.

Just the same the other platforms aren't looking too shabby. Silverlight seems to have a good deal of similarities in development style as Flex, providing a clean separation between interface and code. Also, they have the advantage of the Windows platform, which opens up an even larger installed base for Silverlight beyond what even Adobe has and could give Microsoft's RIA platform the edge in the long run.

Meanwhile, Sun's JavaFX seems very similar to regular Java programming (which isn't a bad thing if you looking to leverage the existing Java developer community). However, from what I can tell there's not as clean of a separation between interface and code like you have with Flex and Silverlight. There's also the issue of deployement, which puts them at a disadvantage I think -- they have a large JVM deployment base, but it's likely that people will still need to deploy a JVM that has JavaFX support in the future, which could be a problem.

So far I think the XML-style syntax of both Silverlight and Flex makes interface development vastly easier, and this gives both platforms a clear advantage over JavaFX, which seems to use it's own stripped-down Java-like syntax, which I'm not so sure I like.

Regarding JavaFX specifically, I agree what this post has to say regarding the name:

Why does it have to have “Java” in it? The end customer doesn’t care how the application is written. He cares that it’s easy to install. He cares that it starts fast. He cares that it runs fast. He cares that it doesn’t crash on him. He cares that it doesn’t lose his data. He cares that it does what it is supposed to be doing.

It's a small quibble, but it might work against the platform in the long run. Java's settled pretty comfortably into a server-side niche at this point, and trying to force the Java name into other areas of development...again...could actually work against JavaFX. Many developers are tired of seeing Sun try to push Java into every facet of software development.

Of course, the mere mention of Microsoft will turn plenty of people away from Silverlight, so they're not totally alone on this I think.

On the plus side, JavaFX seems to be making a good choice as far as development tools go. They're leveraging the existing NetBeans and Eclipse platforms by releasing development tools that work on both that are free. This could help speed adoption of JavaFX once they get the ball rolling, since development shops won't have to shell out any cash to get working with the technology.

On the Silverlight side, you can get the development tools for free currently, but I'm willing to bet that developers will likely have to part with some cash to get a full suite of tools that give you the full range of development options that Silverlight will have to offer. This shouldn't be a problem for most Microsoft-centric shops, but could work against adoption by those that prefer lower-cost options.

Flex development tools are between these two extreme: You have to buy Flex Builder, but it's built on the Eclipse platform which means it's easy to get up-to-speed if you already know Eclipse. I think if Adobe freed up Flex Builder it would push them further in the lead. They've already slashed the price on it once, but Adobe makes a significant amount of money on their dev tools so this might be wishful thinking. To their credit, they still provide a way to do Flex development without Flex Builder (and I've done just that...using Emacs, their command-line compiler and their Ant plug-in, too), so there are still some options.

I think another big advantage Adobe has with Flex going forward is the fact that they basically own the design tools market with Photoshop and Illustrator, and they seem to be using this fact to help push integration with them. Their upcoming Flex 4 enhancements seem to be focused on giving designers the facilities they need for doing interface design while maintaining a clean separation between developers and designers, and given their almost total lock on the design tools market they're in a unique position to be able to do this well.

Sun seems to recognize this, and (at least according to javafx.com) they look like they're going to try to leverage the existing design tools with JavaFX. I'm not sure how much success they'll have given that the company they are now directly competing with owns the very tools they're trying to integrate with, but at least they're giving it a shot.

Microsoft is taking a completely different route here, and working on their own design tools for Silverlight development. And while it's still a bit early to see how well this works, it seems that this might work against them in the long run. Serge Jespers has said something similar in this regard:

It’s a fact that designers work with tools such as Photoshop, Illustrator, and Fireworks and they’re not going to use the Expression tools any time soon. So adding standard design tools to the workflow is a must. To some extent, it is possible to import artwork from Photoshop or Illustrator in to Expression Design but that’s about it.

This could be a big negative for Silverlight, unless they make their design tools nearly identical to what designers are already familiar with. As some comments on that post point out, designers are going to want to work with what they already know, and many shops aren't going to be willing to make a major transition to a completely new design tool.

I think Microsoft is suffering from a bit of "Not Invented Here" syndrome with the design tools. Whether that's the right choice we'll have to wait and see. They have the resources to pull it off, but I'm not so sure it's the right way to go.

From a developer's perspective, as I already mentioned I think Flex is the more robust solution at this point in time. My impressions with working with Flex so far seem to indicate that Adobe has gone to great length to make sure that their Flex development APIs are simple and consistent. Working with Flex is extremely easy from what I can see so far.

JavaFX also doesn't seem to terribly difficult to work with, especially if you're already familiar with GUI development via Swing or AWT which seems to be at the core of JavaFX development (I could be wrong here...it seems JavaFX code is organized almost identially to Swing code from a interface construction standpoint). My concern with JavaFX would be if it relies too much on Swing (or AWT) under the hood. Swing's not bad, but there's enough idiosyncrasies of working with Swing that could make it a huge turnoff for developers.

Silverlight also seems pretty easy to work with, and Microsoft seems to following a similar design paradigm as Flex in using XAML as the main interface design language. I've not yet delved into Silverlight, but based on my reading from their Getting Started info on the Silverlight site, and a few other places it doesn't seem too far removed from how Flex does things.

Nevertheless, both Silverlight and JavaFX have some catching up to do, I think. Given the resources at Microsoft's disposal, they are best positioned to gain ground the fastest on Flex. They're already working on Silverlight 2 currently.

Meanwhile JavaFX is still working on their first release, which doesn't bode well for Sun. There's also been some question as to what Sun is really trying to accomplish with JavaFX, and whether they really understand the challenge they're facing in getting people to use it. As I said, Flex already has a large installed base to work with by being based on Flash, and it's decidedly more lightweight than most any Java technology, which is a big deal. And Silverlight will be trivially easy for Microsoft to get deployed since so many people use Windows. I can't help but feel that JavaFX is going to be the odd man out between all of these platforms, but I'm more than willing to be proven wrong here.

Anyway that's my view of the landscape at this point. I invite anyone else out there to add your own assesment of these technologies in the comments. I'd like to see what other developer's think of these technologies that I may have missed.

Logo Fun

2008-07-24T21:20:00.005-04:00

Since I changed the layout of the blog I wanted to come up with a new logo that matched properly.

The logo I had up originally:

Just didn't suit me at all. It's nice a simple (which is always a plus), but I just wasn't happy with it.

So I wanted to come up with something different. And for some odd reason, the idea of this logo popped up in my mind today:

It's obviously a bit more involved than the other, simpler logo, but I like it a lot more than the old one.

I created this from scratch using Adobe Photoshop CS2. It blends with the background nicely to give the appearance of being embedded in the blog page itself, which I kind of like. This is probably the most complicated image I've tried to make from scratch so far -- I typically don't do much with Photoshop other than the occasional icon and whatnot. I do experiment once in a while, but usually stick to simple images.

It turned out a lot nicer than I thought it would when I originally pictured it. Usually what I imagine doesn't translate exactly the way I hope when I start making an image like this, so I end up scrapping the whole idea. Looks like I'm getting better with each try.

I may still tweak the image a bit later, but for now I'm much more satisfied with this logo.

Syntax Highlighting and Code Snippets in a blog

2008-07-24T09:11:00.012-04:00

Update (4/30/2010): The SyntaxHighlighter package has changed significantly since I posted this. Check out the SyntaxHighligher Wiki for the latest information. I'll be posting new Blogger-specific directions soon.

Update: As of July 2009, Google has started migrating it's users of Google Pages to Google Sites. As a result, my section referencing putting the relevant files on Google Pages will no longer work, and per an email I received from Google about the migration Google Sites will not support the capability that I've described below either. This will effectively break code snippets on any blog that uses this approach (including this one). I'll update this post with a new approach once I have one in place. In the mean time, keep this in mind when you read this post.

Of course, none of this will be an issue for those that host their own blog site -- you can just host the files locally.

I'm sure a lot of developer-types out there might want to know how I got my code snippets to look so nice in my JavaFX and Flex comparison.

So here ya go...

I'm using SyntaxHighlighter -- it's a freely available package that allows code snippets to be posted so that they actually look like code, rather than just a jumble of monospaced text, including doing syntax highlighting for most popular languages.

If you like posting code snippets on your blog this is a must-have add-on. It saves you a lot of time trying to get code samples to look pretty.

Here's a sample:


/**
* Foo class
*/
public class Foo {
private String bar;

public Foo(String bar) {
   this.bar = bar;
}

public String getBar() {
   return this.bar;
}
}

Major kudos go to Alex Gorbatchev for making this package. It's pretty easy to install and set up, and only requires you to wrap your code snippets in <pre> tags, with a few additional attributes in the tag like this:


<pre name="code" class="java">
...some code in here...
</pre>

The name attribute is always "code", and the class attribute is used to identify whatever type of code your snippet is, be it Java, C++, JavaScript, etc.

The package is meant to be placed on the server where you host your blog, and requires some changes to your blog's template -- you need to add a few lines to include some JavaScript so that the <pre> tags get parsed and the code formatted properly whenever a page is displayed (note that if a reader of your blog is using something like NoScript, the code won't get formatted)

For most self-hosted blogs, you should be able to follow the instructions from the SyntaxHighlighter project's website to get up and running quickly.

Blogger-specific stuff
I discovered this via this blog post. I'm repeating what's been covered there, but I've also included some changes that have been made to SyntaxHighlighter to deal with some blogger-specific issues. I've also changed where the files are hosted, since it seems easier to do the way I have (but that's just me...do whatever works best for you).

If your using blogger (like I obviously am) you have to jump though a few extra hoops the get this package working. For one thing, you can't actually put the files on the server hosting your blog.

The best way around this is to use something like Google Page Creator to host the all the relevant files for you. Just upload all of SyntaxHighlighter's .js files, along with the .swf file and .css file to your own Google Page Creator space.

Once you do that, you have to add some extra code to your blogger template. Open up the the template in the "Edit HTML" section to add the following somewhere in the <head> section:


<link href='http://youraccount.googlepages.come/SyntaxHighlighter.css' rel='stylesheet' type='text/css'/>
<script language='javascript' src='http://youraccount.googlepages.com/shCore.js'/>

...add a <script> tag like the last one for each .js file from the package...

After you do that, at the end of your template, right before the </body> closing tag, you put the following:


<script language='javascript'>
dp.SyntaxHighlighter.ClipboardSwf =
  'http://youraccount.googlepages.com/clipboard.swf';
dp.SyntaxHighlighter.BloggerMode();
dp.SyntaxHighlighter.HighlightAll('code');
</script>

In both of these samples, you'll need to replace the youraccount with whatever your Google Page Creator account is.

Note that you don't have to include all of the .js files if you don't want to -- just include the ones that you think you will be needing for whatever type of code snippets you plan to post.

Once that's done, you can insert your code snippets in your blog posts using the <pre> tag as described previously.

Have fun :-)

Please Stand By...

2008-07-23T22:09:00.002-04:00

After posting my little JavaFX vs Flex fun, I kinda realized I wasn't totally happy with the blog layout. Seems code snippets get to be a wee bit uglified when all the text is smashed up into one narrow column of text.

So I've switched to a wider layout template, and I'll be tweaking things here and there until things look acceptable to me -- the default settings of this layout still aren't quite to my liking, but it's going to take me some time to get things just right.

Quick Comparison of JavaFX and Flex

2008-07-23T19:33:00.016-04:00

A while back, I read this post over on Javalobby (via DZone, of course) showing a brief example of data binding using JavaFX. I haven't really followed the JavaFX scene much, but since I had played around with Flex a bit and liked how data binding was done using Adobe's platform I found this brief little synopsis by Jim Weaver enlightening.

So, since I have been messing around a bit with Flex (among other things) I thought it might be neat to slap together a little Flex version of the same example from that blog post.

Now, this is by no means a thorough comparison of either language. It's just a quick little comparison of the syntax they both use, and I think shows a nice contrast in the way both platforms do things.

I should also note that I'm still quite a bit of a novice when it comes to using Flex, so there's likely a better way to do things in Flex than what I'm doing here (in fact I know there are several ways to get the same result than what I have shown). I tried to make my example as close as possible to the JavaFX implementation.

So here we go...

The first thing we need is our model class -- our version of the HelloJFXModel.

Flex doesn't allow for defining classes directly in our MXML file, so unlike the JavaFX example we have to define our model in a separate file. In this case, we define ours in HelloFlexModel.as (big surprise, huh?):


package {

  [Bindable]
  public class HelloFlexModel {
    public var greeting:String;
  }

}

Simple enough. The [Bindable] basically tells Flex that the class (and it's attributes) can be bound to a component, which in our case -- just like the JavaFX version -- is going to be a text field.

Now that we have the model, we need to use it in our main application MXML file. There are actually several ways to do this -- for instance, we can use the <mx:Script> to create a local variable using ActionScript embedded in the MXML file if we want. However, for this example I'm going to use a nice feature of the MXML language that allows for importing custom classes and using them just like native MXML tags in Flex. This allows for a much cleaner looking MXML file:


<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml"
               xmlns:local="*"
               width="400"
               height="150">

<local:HelloFlexModel id="helloFlexModel" greeting="Hello Flex Developer!"/>

<mx:Style>
      Text {
         fontFamily: Sans Serif;
         fontSize: 24;
         fontWeight: bold;
         color: red;
         verticalAlign: top;
      }
</mx:Style>

<mx:Panel title="Flex example that binds a model" width="95%" height="95%">
   <mx:Canvas>
      <mx:Text x="10" y="10" text="{helloFlexModel.greeting}"/>
   </mx:Canvas>
</mx:Panel>
</mx:Application>

If you didn't pick up on it, the xmlns:local="*" is how the HelloFlexModel gets imported. Since it's not really defined in a separate package, we only have the "*", but if we had placed the class in another package, we'd have used something like "org.foo.*" instead. Packages in Flex follow the same conventions as Java (package org.foo would be in a /org/foo directory), which by now most developers are familiar with.

The model class itself is then used via the <local:HelloFlexWorld> tag. The local prefix can actually be whatever you wish it to be, as long as it matches whatever you used in the xmlns import I talked about in the last paragraph.

What's nice about importing our class this way is that it allows the class to be cleanly integrated into the MXML syntax. Instead of having some ActionScript code like var model:HelloFlexModel = new HelloFlexModel(); muddying up our MXML, we have something less intrusive and probably a bit easier to read.

Also note that the attributes of the class we're using (in this case, greeting) are accessible via XML-style attributes in the MXML syntax. You could also do this via nesting of tags, like this:


<local:HelloFlexModel id="helloFlexModel">
   <greeting>Hello Flex Developer!</greeting>
</local:HelloFlexModel>

It's really a matter of personal preference. Like traditional XML, both ways are correct...just be consistent in your usage.

Another nice thing is that the font style and appearance we use for our text field can be defined via CSS syntax, which I think is a nice touch. It also helps keep the look and feel separated from the application (you can actually put all the style-related code in a separate file as well, just like traditional CSS, but I've included it in the MXML file to keep things simple).

So after all of that, we get something that looks like this:

I think both JavaFX and Flex look pretty decent. Flex appears to be the more complete platform at this point, and I personally think that Flex has the upper hand when it comes to it's MXML syntax -- It seems to provide for much cleaner organization of interface components. Just the same, I won't count JavaFX out just yet, either.

There seems to be plenty of room for improvement in both camps, and I'll be keeping an eye on both of them as much as I can.

Bad Apples

2008-07-22T10:54:00.002-04:00

You should never be afraid to remove -- or even fire -- people who do not have the best interests of the team at heart. You can develop skill, but you can't develop a positive attitude. The longer these disruptive personalities stick around on a project, the worse their effects get. They'll slowly spread poison throughout your project, in the form of code, relationships, and contacts.

- Coding Horror

I agree with this wholeheartedly. But you also have to ask yourself whether there's something you could have done to prevent things from getting to this point.

I've experienced a few bad apple incidents in my career: In one situation I readily admit that I could have been labeled as a bad apple myself (and rightly so). Having been on both sides of such a situation I've seen where it's not just the individual that's deemed the bad apple who can be at fault for letting things get so bad: In some cases the team itself can cause the bad apple to emerge.

I won't try to pass blame onto anyone for me being a bad apple: I realize now the mistakes that I made and use them as a learning experience. And I learned long ago that my way isn't always the right way and that sometimes just going along with what's been decided is better than trying to change things mid-stream.

That being said, their are situations where the team itself can be at fault for the emergence of a bad apple. For instance, a developer might get the impression that their input on the project isn't wanted, or even desired. This isn't a situation where a developer is just being pig-headed about some idea and being shot down continuously, but where a developer's ideas just aren't even being discussed or considered. If a developer gets the impression that the team simply doesn't want their input, that developer may isolate themselves and simply stop engaging with the team like they should. The situation then starts to head down the road to "rotten developer."

The key to avoiding this is to maintain solid communication within the project. This is the one thing that helps both prevent accidental bad apples from emerging, as well as finding the real bad apples like Jeff describes in his post.

Whenever a bad apple is discovered on your team, you should always consider the possibility that it could have been prevented. In many cases there's nothing you can do -- it's simply a conflict of personalities. But if you find situations where the bad apple could have been prevented, that means there's something in the management of the team that needs to be addressed.

Pigeonholing Programmers

2008-07-16T09:33:00.006-04:00

Much like The Pragmatic Programmer advocates, I try to "Invest Regularly in My Knowledge Portfolio", which usually involves reading books (unlike most programmers), various programming-related blogs, and listening to a few podcasts as well.

In addition, I also make it a point to try to learn other programming languages. I think this one activity goes a along way towards making me a better programmer, as it opens my mind up to new concepts and ideas that I may not have otherwise considered while using Java, which tends to be the predominant language used in my everyday work.

So over the past few years I've made it a point to learn Python and Lisp, beefed up my skills with JavaScript (which had been waning a bit since I hadn't used it for many years), and dove into using regular expressions (regex is really an ancillary language -- a language that is typically used with some other programming language in order to process text data -- but it's still a language in and of itself and well worth learning). I've also started exploring Flex/Flash development as well.

My big concern about learning these languages is that, while I may be able to apply some of the concepts toward my own development work, which almost always involves Java, I have very limited ways in which to apply the languages themselves, which in some cases I've found far and away superior to Java for certain situations. And I'm starting to see this as a point of frustration for trying to expand my skillset as a software developer.

I think that most people agree that in order to truly understand the language paradigms, concepts, strengths and weaknesses behind many of the programming languages available nowadays, programmers really need to be able to work with a languages on a regular basis. And while I do try to work with whatever languages I choose to learn on my own time as much as I possibly can, being able to use these languages in a real-world development situation would go a long way towards helping me fully understand them. Coding examples from a book, or working on some simple toy application has indeed helped me immensely, and exposed me to new ideas, but without really being able to take the language for a spin on a substantial project I don't feel like I'm getting the full picture of what these languages can really do.

I see the potential...but I can't fully explore and exploit it.

My other fear is that, after all that effort to learn a new language, that knowledge will atrophy...resulting in wasted effort. Sure it won't be a total waste, as I'll have applied some of the knowledge to my Java work, but how will I ever know that I've been doing things the right way if I haven't really had the opportunity to fully explore alternatives?

One solution is to find some way to apply these languages in the workplace so I can really see what kind of capabilities they have. But in order to do this I have to convince the stakeholders or project managers that it's worth it to explore these alternatives, rather than just stick with the tried-and-true Java stuff...and I think we can all predict how well that will work.

It's difficult to convince people to take a risk on something they don't know for sure is going to be the best option, when they know that something like Java has a better chance (although by no means a guarantee) of success. It's always easier to go for the sure thing, and I understand this completely. But a consequence of this is that, as a developer, I feel as though I'm being limited in my growth opportunities by default -- I can't convince people there might be a better way without exploring the alternatives fully, but I can't explore the alternatives fully without having some substantial application within which to apply the technology. Chicken...meet egg....

Sure, I can try to sneak the language in somewhere, but there's a big risk in doing that...especially if you're working with a rather hard-assed client or company. They don't take kindly to being tricked and I might find myself kicked to the curb for my troubles.

An alternative is to find a place to work that allows for this kind of technology exploration -- someplace like, say Google, that sets aside time for developers to really explore programming. But I'm realistic enough to know that I have no hope of ever working at Google, and finding any other company that does the same thing seems almost impossible.

And speaking of moving on to other opportunities: This too presents some interesting points of frustration along the same lines...

Lets say that, after so many years of working with language X, I want to move into something different -- programming language Y. It may be that I'm just tired of working in X, or -- as I explained above -- I want to simply see what it's like to work with Y in an actual project. So, I throw my resume out there to some prospective companies working with Y.

(Of course, this is assuming that anyone is even currently using language Y for a project, as it could be something so new that it hasn't shown up on anyone's radar yet. In which case I'd be wasting my time even looking for a new job at all.)

At any rate, some company doing Y projects gives my resume a look, and either sees my extensive background in language X and says, "no way" (maybe because they think that my experience with X works against me in some way), or at the very least sees that I haven't worked on any substantial Y projects (aside from typical toy learning projects) and doesn't give me a second thought. They want people with so many years of Y experience, or something along those lines.

Meanwhile, because of my long extensive background using X, I get pelted by every recruiter from here to Abu Dhabi asking me if I want to work on some X project, which I don't find particularly fun...and only serves to further my frustrations. But because I can't get the time of day from the companies using Y, my choices are either: A) Stay with my current employer and continue to use language X (if they haven't tossed me out on my ear for trying to sneak Y in the back door, that is), or B) Take a job with another company that's also using language X.

I'm effectively pigeonholed into being an X programmer, whether I like it or not. And despite my best efforts to get out of the rut, various factors -- current work environment, the job market, experience -- have effectively killed any hope of moving up and out of X programming.

I've actually encountered this type of situation in my own career, albeit in a slightly different form: For many years prior to my first gig as a programmer, I was involved pretty heavily on the hardware-side of the computer world: Troubleshooting, repair, installations, upgrades, help desk, and stuff like that. Basically most of the traditional IT-type work people think of. I was one of those guys that people would call when they had a problem, or needed some piece of hardware set up or installed and whatnot.

Now, I enjoyed the work for a time, but it became fairly mundane work eventually: Once you've solved the same hardware or configuration problem 18,000 times it gets a little boring. And that's where I ended up -- very...very...very bored. So I decided to move over into software development, which I enjoyed non-professionally for quite some time working on my own little toy projects. So I headed back to school...

Now, fast-forward several years: I've still been doing the hardware stuff during that time at school, but now I decide to start throwing my resume out there to get a programming gig.

What I found was that, despite my explicit desire to move over to the software development side of world, I was met with a shitload of resistance. It seemed that everywhere I interviewed people were either surprised, or otherwise just couldn't comprehend why I wanted to do software development. It's like the idea of branching out into other areas of the computer industry, or changing professions was somehow impossible to do in their eyes. As far as they were concerned, because I had all that experience doing the hardware stuff that's where I belonged.

Now, I obviously did eventually get that first programming gig, but it took a long time to find someone willing to accept the fact that I actually enjoyed programming more than doing all the hardware work, and that I was (and still am I think) much better suited for programming.

This isn't exactly the same kind of situation I see when trying to move from one language to another, but I do see a similar mentality emerging whenever I explore the possibility of moving outside my current job to do work with another technology or company. Perhaps it's just the area that I currently live in, or just bad luck on my part, but I am definitely picking up a similar vibe that I had when trying to move from the hardware world into software development. I'm hearing a lot of "well...you're an X programmer...why the heck would you want to work with Y?"

After experiencing this kind of situation now in two different -- yet oddly similar -- ways, I can't help but get the feeling that there are probably a good number of developers out there that have gotten themselves pigeonholed into being a blub programmer in some form or another...despite their best efforts to not end up that way.

Many companies, both in their desire to stick with what works (which is not wrong in any way, mind you), and with their insistence in looking more at what developers have done, rather than what they have the potential to do for a company seem to have inadvertently worked to limit developers' opportunities for growth in this regard.

(And I won't even touch the fact that there are companies out there that actively work against their own employee's attempts to learn and grow and move on to bigger and better things...which I have also witnessed, I'm sad to say).

I don't think it's all doom and gloom. I think the opportunities for engaging and using new technologies on a regular basis on-the-job are probably out there, and I'm sure there are plenty of employers that will look at more than just "X years with blub" on a resume. At least...I hope there are.

Because otherwise I have a bad feeling about the future of programming...

The Programming Apocalypse...

2008-07-14T13:22:00.005-04:00

Raganwald pulled the following quote from the latest Coding Horror post:

Try to imagine a world where every programmer you know is a wannabe language designer, bent on molding the language to their whims. When I close my eyes and imagine it, I have a vision of the apocalypse, a perfect, pitch-black storm of utterly incomprehensible, pathologically difficult to debug code.

Hmmm. When I close my eyes I see something a little different...

...I see Lisp.

What Hath Java Wrought: The Long Version - Part II

2008-07-07T17:00:00.000-04:00

[Part I is here]

Java is popular because of one rather simple reason:

It's easy to use.

Java was touted as being a "simpler C++" when it was released: No pointers, no memory management (for the most part)...basically nothing that could over complicate the language, or make developers lives a living hell. This helped both existing C and C++ developers get up to speed with the language (due to similar syntax) and also allowed lesser experienced developers work out solutions with minimal fuss, and not have to concern themselves with complicated concepts.

Now, whether Java's simpler syntax was a good idea or not isn't what I want to get into. There are quite obviously trade offs to having a simple syntax (the big one being that solutions tend to get complicated as they grow...as some have already discovered). And at this point in time we're all well aware of the various strengths and weaknesses of the language.

The bigger issue I see is that the popularity of the Java language that came about from its ease of use now plays a major factor in how the language can, and should, evolve.

The Good
Having Java, or any language, gain popularity means that with the increasing interest in solving problems with it comes more basic grunt work getting done for people ahead of time. More developers solving the same problems results in patterns emerging from those solutions. Those patterns become libraries that other developers can leverage to solve even bigger problems.

As more libraries get created, other interesting problems get tackled. Frameworks emerge that allow developers to quickly work up solutions in entire problem domains, and not just some specific component of it. The frameworks evolve to work together, allowing for solutions that are almost trivially easy to put together. Development time drops considerably, as much of the boilerplate that would normally have to be constantly rewritten has been taken care of ahead of time.

Also, with such a large pool of developers to draw from, it's also very easy for companies to find developers that can hit the ground running with Java.

All of this makes good sense for businesses, as time-to-market is important. Currently, we've started to reach the limitations of what Java can do for us, and many have moved to other languages like Ruby and Python to further reduce that time to get a product out. And while those languages aren't nearly as popular currently, they may very well take that top spot from Java.

But in the meantime, Java tends to be the smart business choice as much of that grunt work has already been taken care of in the Java world.

Suffice it to say that I think popularity is a "good thing" overall for any language.

The Bad
The problem I see at this point is that since Java is so popular it can not really move forward without making things worse. Unless Sun, or whomever starts maintaining the Java language once it goes Open Source, are willing to take drastic measures, they're going to continue to suffer from I would call Windows Syndrome...

Everyone knows Microsoft's Windows OS. Company shenanigans aside, it's become the single most dominant operating system on the planet. It's not the best out there, but it gets the job done for most people.

For years now, Microsoft has been struggling to move the operating system forward, adding new features and improvement wherever it can. In many cases they've succeeded, but they've stumbled quite a few times as well. And some have pointed out that a big reason for the stumbling is because of Microsoft's need to maintain backward compatibility with older programs and systems.

Microsoft's OSes have become so popular, and the market so large that they can't ignore situations where people are using older version of both their OS and applications. This ends up putting limits on how much they can change each subsequent version, since as long as people need those older programs to run (and sometimes it's a large number of people) they have to hold back the OS to support it in some way.

Basically, they're own popularity is working against their need to evolve.

Meanwhile, you have a company like Apple, whose systems are not nearly as popular as Windows-based systems (based on market share), which took a drastic step and broke backward compatibility with their older operating system when they introduced OS X, which was a major evolutionary leap from the previous versions. Arguably this has allowed the company to gain both market and mind share, and position their systems as being far more reliable and well designed than their Windows counterparts.

A big reason Apple could do this is because they don't have nearly the same size market as Windows -- they could afford to take the risk.

Now back to language-land...

Sun has made a conscious decision both on past language enhancements (Generics) and it seems on future ones (Closures) to maintain backward compatibility with both existing code and JVMs. This puts it in the ugly position of having to ensure that any change made to the language works within the framework of what's already being used by developers.

A big reason for wanting to maintain this backward compatibility is because of the large market for Java development: Breaking backward compatibility means they risk alienating a significant chunk of the community.

Meanwhile, you have other languages with a smaller market share/less popularity (Python and Ruby, for example) that are able to evolve and make changes quickly due to the fact that any changes they make aren't going to have as significant of an impact on its user base.

Hmm...this sounds familiar, doesn't it?

Maintaining backward compatibility for Java is a worthy goal to reach for, but for some of the changes that get considered, you can't necessarily take that option off the table. At the same time, Sun can't afford to break backward compatibility if the language is to continue to be popular, so we end up with some non-optimal solution added to the language that potentially makes things worse for the developers. It's a no-win situation.

This is where other, less popular languages have an advantage: Python in particular has broken backward compatibility several times in previous versions of the language. One big reason it could do this was because the market for Python developers is smaller than it is for Java.¹ If Python were in Java's position, I doubt such decisions to break compatibility would be so easy.

Much like Windows, Java's extreme popularity prevents it from evolving in necessary ways.

More Bad
With all of these changes that are trying to be made to the language, there is also the potential risk of decreasing the adoption of the language. Java's already widely in use throughout the industry, but if we expect new developers coming into the programming field to adopt the language it has to continue to be both useful and approachable. Adding complexity (as I think Generics and Closures do) works against this very goal, as it makes it harder for newer developers to get up and running with the language, and understand existing code.

(Of course, the ever-growing Java API also has this effect on new developers as well. Trying to navigate the disgustingly huge number of APIs in the Java SE is a daunting task even for seasoned developers...)

There's already evidence that Java is failing at this approachability, as there are colleges teaching Java that don't even try to talk about Generics when presenting the language to their students.² If this is the case, then how do we expect these developers to work with features like Closures?

Another facet of this is that, with the added complexity we will undoubtedly add to the language when tacking on new functionality (either through trying to maintain backward compatibility or otherwise), we're forgetting a whole swath of current Java developers who, whether we like it or not, are going to severely impact the overall productivity of the community. And making the language more complex is just going to exacerbate an already bad problem these developers represent.

The Ugly
One thing I've grown to understand while being involved with Java-related projects is why there's so much hate towards the Java language and perhaps the community itself: The bulk of it comes down to the overall makeup of the Java "community". I use quotes here because the community I'm referring to isn't just the vast number of intelligent, enthusiastic people that inhabit places like JavaLobby, or DZone, or TheServerSide.com, but the entire group of developers out there that have made a career using the Java language.

The unfortunate consequence of having a language that's so easy to use is that, while there's plenty of very capable and smart software developers using the language, there is a vastly larger group of people that have been using Java out there who are...shall we say...less than enthusiastic about the whole art and science of software development. You know who I'm referring to: Those unfortunate (and aggravating) souls that have no desire to really learn anything more about programming than what is necessary to earn them a paycheck - the ones from whom we regularly get our laughs on sites like The Daily WTF.

Let's face it: There are a lot bad programmers in the Java world.

It's the result of the combination of the language being both approachable, and the community so large (since the more people using the language, the more likely the chances of lesser-skilled developers using it). There are quite a few of these programmers using Java, and they are not going to go away as long as having "Java" on the resume is a guaranteed chance at snagging an interview, and possibly a job. In my career as a developer working on Java-based projects, I don't think I've ever had a job where there wasn't at least one of these guys involved in a project I was on.

Now, granted this isn't necessarily a Java problem so much as an industry problem. As someone's recently pointed out rather astutely, the software development world seems to have a interesting characteristic of allowing those of both lesser capability and ambition to coast along doing programming work. So it stands to reason that since Java is so popular, the bulk of these lackadaisical programmers end up working with Java as opposed to some other language.

Unfortunately for Java, this ends up painting the language in a bad light, as there are so many of these developers using the language. The fact is that you could substitute some other language as the most popular and probably have the same result. Yes, the Java language itself does deserve some of the ridicule it receives, but I think the bulk of the ridicule is more a case of disliking this specific segment of it's user base.

At any rate, this is the group that comes to mind whenever I read about adding something like Closures to the language. It is this crop of developers that has the potential to do the most harm when new features get added to the language. Especially when those features add additional complexity.

Because what happens is that any code these non-enthusiastic, non-creative, unthinking lackey programmers create is likely going to be some bastardization of what was originally intended as the use for said features. They will drop generic classes (and possibly even closures) into their code like it's nobody's business...and turn what could have been a simple project into a nightmare.

They will basically use said features just for the sake of using them...without any clear understanding of why or how they really should be used. And they won't care either, because to them it's just a job.

And imagine that situation repeated over thousands of projects.

Of course, I realize that "because it'll be abused by bad programmers" isn't the best of arguments against adding new language features to Java. For one thing, there are ways to mitigate this sort of problem: Code reviews, good hiring practices, etc. But considering the size of the Java developer base, the odds of weeding all of these kinds of programmers out is about the same as the chances of wiping every cockroach off the face of the earth...about nil.

While the best of us out there will be able to work very intelligently with any new additions to Java, these types of bad programmers appear to be so prevalent in the Java world that it can have a very real impact on productivity for everyone - including the smart ones - since somebody will ultimately have to deal with the code that these developers produce at some point.

Eventually, the misuse of these new features (good or bad) could end up working against the Java community as a whole - resulting in Java gaining a bad reputation for creating solutions that are unnecessarily complex.³ And the reason for this may only be because developers - the bad ones - didn't use the features the way they were intended and made things much worse than had they not had the functionality available at all.

Sometimes the only solution to making sure that people don't shoot themselves in the foot is to make sure they don't have the gun in the first place.

One Step Forward...
Overall, I'm not opposed to improving Java, even if those of lesser skill can't quite get their heads wrapped around the concepts that get included in the language. And I'd rather see some improvements over none at all.

But I'd much rather have these improvements to Java done right. And in some cases, I think that means breaking backward compatibility. It's not an easy decision to make, but I think those in charge of Java's stewardship should consider the option. We all want to see Java continue to be successful, but if we insist on trying to contort additions to the language to fit the existing system we're going to end up making things harder on developers, not easier.

And we have to be cognizant of the fact that, despite our best efforts to make programmers' lives easier, we're potentially giving them something that they won't fully understand how to use properly and may make things much worse overall for the Java community.

(Stay tuned for Part III)

1 - I am not trying to make a "Java is better than Python" argument here, so save the ranting and raving. It's just a simple fact that Java is more popular than Python. That doesn't make Java better than Python. And I would certainly not try to make that argument...as I actually believe quite the opposite.

2 - Of course, the subject of teaching Computer Science in colleges is just as complicated as this whole discussion over Java...and I don't want to diverge too far from the point here. Let's just say that the fact that Generics aren't taught is both because of the complexity it introduces and because students aren't necessarily taught everything they should be, and leave it at that for now.

3 - Yes, I know, people could argue that Java already has a reputation for resulting in complex solutions...but doesn't that make the situation just that much important? If the Java is already considered to make solutions that are too complex, then what's going to happen when we add further complexity to the language?

Know Your Limits...

2008-07-02T21:47:00.005-04:00

I regularly listen to the podcasts on stackoverflow. They're not the top of developer entertainment, but I've found them generally interesting in that hearing discussions by Jeff Atwood and Joel Spolsky about software development (particularly when they're discussing building a new website from scratch) provides a nice point of comparison for my own work both professionally and personally. It's nice to hear what other people in the industry are working on, without hearing too much market-speak.

So, today I see on the stackoverflow blog a link to this post, basically knocking Jeff for not being experienced enough for what he's doing.

The last sentence sums up the whole post pretty well:

But you have to know your limits, and Jeff Atwood repeatedly shows that he doesn’t.

Now, I realize that Jeff is quite capable of defending himself, but come on...you've got to be kidding me here...

I understand the argument that perhaps Jeff Atwood may not currently have the requisite chops to build stackoverflow and make it successful, but how is he supposed to learn how to undertake such a task unless he...oh I don't know...tries to build the damn website.

People don't learn to be more than what they are unless they push their limits...even if they may not know what their limits are. If someone told me when I graduated high school that I'd be developing software in 2008, I'd have called them nuts because at that time I didn't think I had what it took. But I am now, and for no other reason than I made the effort to constantly learn and grow and improve myself -- which often involved me doing things I had never done before.

Talk like that smacks of elitism...that because someone didn't have the proper education or learning environment that's somehow "proper" for software development, or that just because he's never done this type of thing before, that he shouldn't even bother trying.

Just because Jeff doesn't know what he's doing doesn't mean he shouldn't try. It's his choice, and his failure to make. And I am certain that even if he does fail (which I hope he doesn't) he'll know better what to do the next time.

And if there's something wrong with his approach to the project, why not a) try to make something better yourself, or b) suggest to him what's wrong? Complaining that he just "doesn't have what it takes" doesn't improve his chances at all of making stackoverflow a success.

I respect Jeff for making the effort to do what he is doing...especially because he's moving beyond his own comfort zone. Not many people are willing to take that step, and are more content to just stick with what they know...and I find that a far more career-limiting move than pushing beyond your capabilities.

So let's leave the guy alone and see what becomes of his efforts, OK?

Programmer Compentency

2008-06-30T09:54:00.003-04:00

Found a post on IdianGeek (via DZone) for a Programmer Competency Matrix.

I was a little skeptical about it at first, but after reviewing all the boxes in the matrix, this could actually be a pretty useful evaluation tool for developers. Granted it's not perfect, but it's better than some other ways I've seen developers evaluated.

Evaluating my own skills against the matrix reveals that I'm pretty solidly in the Level 2- Level 3 range...which means that either I'm a better developer than I thought, or the matrix needs a little more tweaking. I'm going to lean more towards the latter possibility...

Nevertheless it's pretty useful to evaluate one's own skills against what people are looking for out there, and I do see a few places where I could expand my knowledge and abilities listed in that matrix.

And looking at the first item on the matrix listed under Level 3 for books, I seem to already be on my way towards improvement :-)

SICP

2008-06-27T08:12:00.003-04:00

At about the same time every year - sometime between April and June - I end up buying a bunch of books from Amazon. I don't plan it that way...that just seems to be the time of year that I always get the urge to plunk down some cash for something to read. Maybe it's the weather or something.

Anyway, it usually works like this: Throughout the year, every so often I'll pop onto Amazon and see what stuff comes up in my recommendation list (I've bought so much from those guys they they probably know my every habit by now -- beyond the same-time-of-year-book-buying thing -- so the recommendations I get are usually pretty solid). If I see something that interests me I'll add it to my shopping list. The book doesn't have to be particularly engaging...just something that looks a bit interesting at that moment. This is basically the first pass through my is-it-worth-buying filter.

When I feel the need to buy some books I'll peruse the list and see which ones are really worth buying. I inevitably will buy more than one book -- even though Amazon has free shipping on most of their stuff, I like buying in bulk since it's decidedly more efficient to ship that way. I'm not a particularly eco-conscious person...but I do seem to have a preference for efficiency, and having a bunch of books shipped together in one big chunk seems more efficient to me than buying one here and one there throughout the year.

Hmm...chalk that up as another possible reason for the same-time-of-year-book-buying thing.

So anyway, I've had one book in particular that's been sitting in my shopping list for quite a while: Structure and Interpretation of Computer Programs (known as SICP to most people familiar with the book). I had learned of the book through various sources on the web, as it's been recommended by the likes of Ragawald and Joel Spolsky (who's mentioned the book here and here, and also mentioned it on the first or second stackoverflow podcast...which is worth checking out, btw), and over at learning lisp there's some good posts about the book that made me think about getting it.

I was on the fence about buying the book for some time. The book can be read for free on MIT's website here, so for a while it didn't seem like it made much sense to buy it when I could read it for free. But my preference is to actually have books (especially technical books) physically in my hand when I'm reading them. And, despite the fact that a lot of programmers don't read technical books...I actually enjoy reading them. And for all the craze over Kindle and electronic books, there's a lot to be said for actually having the book in your hand to read.

So finally, with this last batch of books I purchased I said, "screw it" and bought SICP.

And I haven't regretted it.

I haven't finished reading it yet, but I would certainly rank this book up there on my list of must-have books (one of these days I'll make a "Best of" book list here...but I'm a programmer...and I'm lazy...so it can wait). SICP does have a fair amount of math-related material in it, but I'd have to say it's way easier to follow than, say, The Art of Computer Programming Series, which lean very heavily on mathematics (at least Vol 1 does...I haven't delved into Vols 2 or 3).

SICP also uses Scheme -- a variation of Lisp -- for all of the code in the book. What's great, though, is that the book explains the Scheme language early on in such a seamless manner it's almost like you're not actually learning the language at all...which is really the point, since the focus of the book is on the concepts and not the language used.

And so far this has been the biggest point I've taken from the book: It's not the language you're using that's important. It's the concepts a language embodies and uses that are far more important. This is the very essence of computer science that many people don't see, or simply choose not too -- instead they simply focus on the quickest way to solve a problem in Blub. There is some merit to that approach...but it sacrifices long-term gain for short-term results.

And after diving into this book, I really think I'm beginning to understand this more that I ever did before. I had always felt that developers (myself included) should concentrate on learning and understanding the underlying science of our profession, as it is so much more enduring than the solving-a-problem-with-the-language-of-the-day that commonly goes on. In some ways we seem to be stuck on a treadmill of reinventing the wheel when it comes to the craft of software development, without advancing much.

SICP has really begun to open my mind up to other areas of software development that I really wasn't seeing, or saw but didn't fully appreciate.

This book is worth it's not-too-insignificant weight in gold, as far as I'm concerned.

Not Sure if I like This Idea...

2008-06-26T09:13:00.004-04:00

Gizmodo mentioned this months ago, and Wired's got an article about it again...

Chrysler wants to turn your car into a rolling WiFi hotspot where you check your Facebook profile, upload pictures to Flickr, and eventually be part of a nationwide traffic-control network.

I like the idea of adding new technology to cars as much as any other geek - and having some mobile network connectivity in a car is certainly a nice idea - but I'm just not sure if I like the idea of turning a car into a wifi hotspot.

People have a hard enough time driving as it is.

And, while I know they'll market this as something for passengers, or in some way to encourage drivers to not use it while driving, you know someone's going to do it...whether Chrysler intends it to be used that way or not.

I like Chrysler personally: Even though their sales have taken a big hit like Ford and GM, I still prefer their cars over those two companies. I like the styling of their cars, and I've owned a few in the past (Dodge specifically - I call myself the accidental Mopar guy...I'll save that story for another day), and all of them have been solid cars that have lasted longer than anything I've ever owned previously.

I see this more as a marketing gimmick...which is a shame. I think Chrysler needs to stay focused on building quality, well-styled vehicles rather than gadgetry. I think they'd also be better off not going integration crazy, like Techdirt mentions:

Automakers love to build new technology into their cars in order to control the experience, but that's not what consumers want. Having an MP3 player is nice, but it's easier if you can just use your iPod. Having a built in GPS system is cool, but the new Garmin has a lot more features. Working with consumer electronics devices that people buy seems like it may be a lot more sensible than trying to recreate the wheel.

I think in the near futures, automakers that provide solid integrating for existing gear will attract buyers. In the current economic climate, people aren't going to want to ditch their existing equipment when they buy a car...so why not leverage it and help them save a few some cash?

I've seen some high-end concepts from the likes of BMW that provide seamless plug-in capabilities for iPods...but these are way out of the price range for most people. This technology isn't that expensive (hell, I've actually considered hacking connections into my own car...which isn't really that hard), so this should be a no-brainer as far as I'm concerned.

Nevertheless...I just hope in the future I don't get rear-ended by some super-busy-marketing-guy because he decided to check his email while going 90 MPH down I-95...

update: And on a related note - A desk setup that fits on the passenger side of the car.

This takes driving while distracted to a whole new level...

The Real Reason Microsoft is Doomed...

2008-06-25T07:37:00.004-04:00

The lack of attention to usability represented by these experiences blows my mind.

Raganwald linked to an epic Bill Gates e-mail rant, from which came the above quote.

That one sentence best sums up why I've never been a fan of Microsoft. Sure they have plenty of hardworking, amazingly-smart people there (or at least they did before Google came along), but for all the efforts put into the likes of Windows by the army of developers in their employ, Microsoft just never seemed to get usability figured out.

Of course, this probably proves just how hard usability can be, too.

But it must not be too hard when you have other companies of somewhat lesser stature figuring it out, and profiting rather handsomely from it.

But there's something that bugs me about that email...

Throughout his time as Microsoft's CEO, Bill Gates gained a reputation both inside and outside of the company as being a ruthless manager. Whether there's any real truth to it I'm not sure, but I doubt so many would think of him as being ruthless had there not been some truth to it. Joel Spolsky has a nice little anecdote of his time at the company that makes Bill Gates appear more methodical and calculating than ruthless.

Nevertheless, at Microsoft everyone knew who was in charge.

Getting back to that rant article. When asked about the email, Bill Gates says, "There's not a day that I don't send a piece of e-mail ... like that piece of e-mail. That's my job."

OK, let me get this straight: Bill Gates, founder and CEO of Microsoft has been sending rants like this to people down the chain of command at the company he founded for - I would assume - a rather long time...

...why the hell hasn't anyone been listening?

What Hath Java Wrought: The Long Version - Part I

2008-06-24T07:00:00.001-04:00

Well...it took longer than I was hoping to get the ball rolling on this, but here we go: My extended, less anger filled post about Java...

I've received mostly favorable feedback about my rant regarding some of the issues I have with the evolution of the Java language. However, I obviously wasn't very detailed in explaining the problems as I see them, and rather than just leave a bunch of incomplete thoughts hanging out there (and giving the appearance of bitchiness) I think it's more appropriate to spell out the problems I see in a clearer manner.

A big reason I want to expand on this topic is the fact that if Java is to continue to be a popular and useful language, those of us that use the language on a regular basis need to discuss the implications of making changes to it. Adding features is not necessarily a bad thing, but there doesn't appear to be much coherent discussion about the implications such language changes can have. Or, if there is, it quickly degrades into a "Java Sucks"/"No it doesn't" back-and-forth crapfest.

The post on Jeff Campbell's blog I previously mentioned stated something along these lines, too: We've got to make it a point to shine some light on the issues surrounding Java's future. When we devolve into a mindless raving over whether Java is worth a damn or not (which I obviously did with my rant) we lose sight of the goal, which is making sure that Java remains a useful solution for developers' problems.

And sometimes, achieving this goal means telling those that want to make changes to the Java language "No."

A Little Context
Before I get ahead of myself, I want to explain what prompted my little tirade...

I've been a using the Java language for a long time: I started using the language professionally during the 1.1 days and have used every version up to and including the latest (Java 6 as of this writing). And, while the language certainly isn't perfect, it's been an enjoyable experience for me to use for the most part. I've written all manner of application with it, ranging from simple to complex, desktop to web, and so on.

Over the last couple of years of working with Java, I've begun to notice a trend in the projects that I've worked on: The code seems to have grown increasingly more complex and difficult for developers to both comprehend and maintain. Now some of this complexity is a result of Java being a wordy language (the Kingdom of Nouns, as it were), which results in more complex solutions than you might get out of some alternative programming languages. And some of this also was probably due to programmer error as well (as is too often the case). But I've noticed that a good portion of the problems seemed to correlate with extensive use of newer language features in Java, such as Generics - basically, any project that made extensive use of Generics seemed to turn into a maintenance nightmare. Quickly.

Now, I personally think I understand Generic Programming - and specifically Java's implementation of Generics - pretty well: I've used it successfully in many situations and to good effect. I'm sure there's more I can learn...but I at least know enough to not get myself in trouble.

Also, being that I've used Java for so long now, I've spent a whole lot of time without this feature in Java. As a result, I'm just as familiar with solving problems in Java without using Generics in my code at all. This has proven valuable, as it has given me insight into which solutions (Generic or non-generic) work best for a given situation. Unfortunately, I think I'm probably an exception to the rule¹.

The fact is Generic Programming as a concept can be difficult for the average developer to understand - it requires a certain level of abstract thinking over and above what's typical in Object-Oriented Programming. Having Generics in Java - a widely used and popular language - means that a whole lot of average Java developers have now been given a tool they very likely don't fully understand how to use, which has the unfortunate result of decreasing productivity in a project when it's used improperly².

And this is exactly what I'm starting to notice: Lots of code that is getting progressively harder to maintain and comprehend because of either too much, or simply incorrect, use of Generics.

Now this may only be anecdotal, but I've started seeing it frequently enough that it's caused me a bit of concern. And combined with my experiences with annotations - a feature that I've yet to find very useful - and with the upcoming proposal to add Closures, and with the idiocy of JSR-308 (yes, I think it's a ridiculous idea as I'll get into later on), I've started to wonder what the future holds for Java developers.

The Big Picture
Right now it doesn't look good.

For one thing, what are we really trying to accomplish by adding some of these features - and in some cases entire new concepts - to the language? Are these changes actually meant to address serious flaws with Java, or are they just for the sake of trying to keep the language relevant in the face of competition from the likes of C#, Ruby, Python, and so on?

I realize there are many factors at play when wishing to add features to Java, but if we don't take the time to look at the big picture and analyze what we really are trying to accomplish we're going to end up doing more harm than good - adding features to any language should never be undertaken lightly.

Now, I realize that there probably are people thinking about the problems inherent in changing a language, but unfortunately for Java, the process in place for considering changes to the language - the Java Community Process (JCP) - seems far too amenable toward adding to the language from what I can tell. This isn't so much a situation where there are bad apples in control of the process, or anything such notion - I'm sure there are many smart people (far smarter than me, in fact) helping to manage Java's evolution both as a language and a platform. My feeling is more that the process itself is to blame, making for a situation where adding features is all too easy to do.

Not Hating the Language
Even with all the issues I'm seeing with Java, I don't want people to get the idea that I hate the language, the community, or anything or anybody associated with it. I've spent a good part of my professional career in the Java world - and I'll likely continue to do so for the foreseeable future.

And contrary to what my original rant may have indicated, I want to see Java continue to be useful for software development. I've invested a great deal of my own time and energy in both learning and using Java and it's related technologies throughout my career...and I'd very much prefer that knowledge to not waste away due to what I see as misguided attempts to "improve" the language.

At the same time I'm also not a Java evangelist: Java may be the most popular language in use out there today, but I'm realistic enough to know that it is not the Golden Hammer. There are other programming languages better suited to using for certain tasks, and I'm more than willing to use - and in fact I have used - other languages when the need or opportunity has presented itself.

If anything, I'm a pragmatist: I use what works, and I continue to learn new concepts, technologies, languages, and tools in the hopes of creating the simplest solution possible that both solves the problem at hand and is easy for developers to understand and maintain.

If Java happens to fit the situation, I'll use it...if not then I'll try something else.

Killing The Golden Goose
But whether Java continues to be a part of my tool set will be largely dependent on what changes are made (or not made) to the language in the future and their potential effects on the developer community.

If the cumulative effect of language changes results in projects growing more complex and harder to maintain, or even if Java develops (or continues to develop) a reputation of being more difficult to use compared to alternatives, I (along with many developers, I'm sure) will start distancing myself from the language, and push for alternatives in the workplace. This is the scenario that I see unfolding across the industry if the powers-that-be ultimately decide to continue to mess around with core aspects of the Java language.

It's not so much that the concepts or features individually are bad in and of themselves - in many cases they appear to be sound ideas worth adding to Java - but the cumulative effect of all of these new features will result in Java becoming more difficult to work with as more projects make use of new features in ways that weren't originally considered, or possibly even desired. It's the unintended consequences that worry me, and that "road paved with good intentions" that we're all too familiar with.

I should also note that I'm not so close-minded to believe that the Java language should never be improved, either. There have been some successes in changing the language in the past (the improved for-loop, for example), and I think there will likely be some good ideas in the future as well.

My main concern is that if we continue down the "improvement" path blindly, or too eagerly, Java will eventually get bogged down under isn't own feature set - which will have been expanded under the the misguided premise of making the language "simpler" or "easier" for developers to work with. It will essentially get turned into an "everything language" - trying to incorporate all features and concepts from all languages.

This is obviously an impossible goal for any language to reach for, and no programming language that I've ever used has even come close to trying to accomplish such a thing. Programming languages are designed to address some specific area of concern, not every one imaginable. But Java's current course puts it squarely along this path: Trying to absorb ideas from other languages currently in use in the hopes of maintaining market dominance.

The irony of all of this to me is that the very people pushing to "improve" the Java language - all in an effort to keep it relevant and useful for developers - will cause it's eventual disfavor in the industry...for no other reason than because they didn't fully understand why Java came to be so popular to begin with.

[update: Part II is here]

¹ - No, I am not trying to stroke my own ego here. I am just trying to point out that, from my own personal observations both on the job and elsewhere that I seem to have a much firmer grasp of the concept of Generic Programming than many other Java developers -- particularly when to not use it.

² - If you are offended by this then odds are you are not an average developer. The very fact that you are reading this blog likely indicates that are a in the above average bracket - see this blog post.

IT in Corporate America

2008-06-19T07:36:00.004-04:00

A new blog, Tales of an IT Director, just popped up with a fantastic first post. The comments are well worth reading, too.

Here's what he (or she?) has to say in general:

IT in Corporate America (herein after referred to as CA) doesn't have to suck. But by and large, it does. Why don't the smart people who work in CA get the opportunity to show how good they can be? Part of it comes by being saddled with inferior tools: bad version control, bad testing tools, bad test data, bad languages, bad platforms. However, these are technological problems that have good technological solutions. Why aren't they embraced? Why use Serena or Harvest for version control when there's svn and git? Why does it take 4 hours to find a user id in development to test a change that took you 30 minutes to implement when a daily refresh of test data would solve the problem? Why buy expensive monitoring software that accomplishes nothing more than sending out snmp messages to a blackberry when you can use nagios for the same thing? And finally, why do the people who propose these changes never, ever, ever get listened to?

The post then goes through quite a few other issues, but I think this one paragraph basically sums up most people's frustrations with working in large organizations and/or large IT departments.

As many of the comments on that post make evident, there are many reasons for this phenomenon. In fact in any one organization that has a stifled IT department, there could be many reasons ranging from bad management to office politics to greed and so on.

But for the most part, no matter where you look in Corporate America, you'll see the typical reason being that IT is simply considered a cost center - somewhere that money has to be spent - not so much to improve the business in any way, but rather to simply keep things running smoothly. The prevailing reason for this is usually that IT is not central to the company's business: If you're selling widgets, you don't care if you have the best computer hardware and software out there. As long as the company can sell widgets and turn a profit, it's just fine with what it has.

If nothing else, Corporate America (and much of American society as well) by and large is pragmatic - it's not about having the best, so long as whatever you have gets the job done. This has worked extremely well throughout our history, and it's likely not going to go away anytime soon. This is something techies need to keep in mind when dealing with Corporate America.

Of course, this doesn't excuse businesses simply ignoring their IT department completely, nor does it make it any less frustrating to work in an environment where IT can't influence change in an organization. And in many cases I think this is to the detriment of the company in question, as you could potentially be ignoring a significant number of people that work for you...for no other reason than you can.

There has to be a balance between the two extremes, of course. Unless you're working in an IT-centered business, IT shouldn't be running your organization. At the same time, IT shouldn't simply be ignored and just treated as a money sink. Either extreme is bad.

Of course, trying to convince a company that's ignoring IT to listen isn't easy either. About the only thing you can usually do is try to influence change under the radar - using tools or technologies you know are better than what the company insists on using. But you have to be careful to pick and choose your battles here, as one wrong decision can blow up in your face big time.

But, if no matter what you do you can't seem to convince the powers-that-be to change their ways, sometimes you just have to walk away. I think those companies that fail to listen to their IT departments at all will be the ones that suffer in the future as other companies come along and clean their clocks with either better organized, or more efficiently run operations thanks to leveraging their IT departments strengths.

That first post was damn good...and I look forward to reading more. And I wish him (or her) luck on the new job.

Perfectionism

2008-06-13T07:36:00.002-04:00

Via DZone: A post about Programmer Insecurity.

It starts:

I want to chat about something that I’ve never noticed before, but probably should have. There’s always been a stereotype out there of programmers being nerdy, anti-social people (Q: How do you know when an engineer is outgoing? A: He looks at your shoes!). But my revelation of the week is that most programmers seem to be really insecure about their work. I mean: really, really insecure.

The post then goes on to list some examples of ways that developers try to hide code from (or at least not show the code to) their peers on projects, all of which certainly reinforce the idea that there's quite a few people out there in developer-land that are insecure.

However, I think some situations in the post that are being interpreted as insecurity are actually cases of something else entirely: Perfectionism.

At first glance they can both appear to be similar, but where an insecure developer would likely say, "Nobody's going to like my code, I'm going to release it", a perfectionist developer would say to himself, "I don't like this code, I'm not going to release it." Perfectionists make a choice based on code quality, while insecure developers make a choice based on fear.

On the surface they both appear to be the same kind of behavior to an outsider, but I think it's important to be aware of exactly which behavior you're dealing with - insecurity is typically bad since it's usually coming from the inexperienced developer who will never really learn the "right way" to do things without getting feedback, where perfectionism can actually be a benefit since the developer is focused on writing quality code and typically already has a good deal of experience under their belt.^*

In either case, however, the overall argument that the post is making - avoiding walling oneself off from the rest of a team, or not communicating - is very much on-the-money. You've got to be communicating and working with your team no matter what. Otherwise you're asking for trouble.

This requires both the insecure developer to learn to have some confidence in their abilities, and the perfectionist to not try so hard to be perfect...and for project managers to keep them both in line.

^*- Of course, perfectionists can get a bit carried away, too. Sometimes they'll have unrealistic expectations and get caught up in pursuing an impossible goal....not that I know anything about this, of course :-)

What Hath Java Wrought - Follow Up

2008-05-20T17:10:00.002-04:00

Seems my little rant drew some attention over the past week. Perhaps I should try blogging while tired and grumpy more often...

...OK, maybe not.

After reviewing the comments here and on DZone (thanks, bloid, for the link there, btw), and after having time to think things through a bit more, I want to follow up on my line of thinking about these changes to the Java language, and perhaps explain myself a little clearer too, as it seems that a few people mistook some of my comments - particularly about generics.

Unfortunately it has to wait a little while longer: I've been too busy to really put my thoughts down in a post, and I'm thinking it may take more than one, as many of the points I want to cover are intertwined and I think matter a great deal to the future of the Java language.

Admittedly, my rant wasn't very complete and I feel that I didn't do a very good job explaining myself - a consequence of not taking the time to really think through the whole subject, obviously. Fortunately, Joe Campbell did a nice job explaining things, and his post matches much of my own thinking on this subject, but there are a few other points I'd like to get across as well that he doesn't cover.

Stay tuned. And hopefully I can do a better job of explaining myself in future posts.

Architect Angst

2008-05-13T09:53:00.003-04:00

Joel doesn't like architects too much, it seems...and neither do I...

While I've worked on a few projects of varying sizes, my current project is the only one that actually had a full-fledged architect on the team. Sure, there were people with "Architect" in their title, but it was really just that: A title. It was more of an indicator of seniority/experience than one of actual duties in most cases. Except for this project, I've never had someone dictating system architecture up front.

And as far as I'm concerned it works just fine without someone doing that.

With my current project - a Java Swing application - the architect decided that it was necessary to design a method of binding our data model objects to GUI components: Basically a JTextField (or other component) could be "bound" to specific attribute of a data model class. This is done through an elaborate binding framework that the architect designed, which I won't go into details about as it would take too long. The framework looked great on paper (as most probably do), but once implemented it resulted in an amazingly complex design that ends up making even simple tasks - such as setting an attribute value for an object in the data model to some value selected from a drop-down list - require an enormous amount of code to implement.

Now I realize that Swing is not the best GUI toolkit to work with, but when you architect something that actually makes working with Swing more difficult then there's a problem.

To the architect, this binding framework didn't seem like such a big deal, but what he didn't realize is that this wasn't a problem that really needed to be solved. You can use Swing's built-in MVC design to work with your own data model. It's not perfect, but it works and it's already there and there's no need to create a whole separate layer of abstraction to get around it.

Unfortunately for me, the project has been under development for a while now (and before I came aboard), so we're basically stuck with this elaborate framework...at least until I can convince someone that it's crap. I'm not holding my breath, though.

There's something else that bothers me about the whole need for a "Software Architect" person on a team: Many in the industry advocate more "Agile" ways of developing software, yet there still seems to be a call to have some architect-type person on the team dictating certain design decisions, which still smells like BDUF thinking. I may be completely wrong here, but if your whole idea of software development is more of a collaboration between developers/stakeholders/etc shouldn't design decisions be more collaborative and less dictated by the whims of an architect? Just a thought.

Anyway, that's my two cents on Software Architects.

What Hath Java Wrought

2008-05-07T22:16:00.002-04:00

(Ok...my first rant post...here goes...)

I have to say that if Java picks up JSR-308 (which I found out about from here), then you can consider me the first one to jump off the Java train.

Seriously...do we really need this in the Java language?

Now I'm a little biased toward annotations in general - I've never been a fan of them. I've always considered them to be a hack that was dumped into the Java SE platform for no other reason than to help deal with problems in Enterprise Java. Seeing this just further solidifies my longstanding discomfort with them.

Seeing code littered with little @-signs all over the damn place is going to remind me of my days looking at code that abused the C and C++ preprocessor with all those #define this and #ifdef that that would drive any sane developer straight to wherever crazy programmers go when the lose their minds.

Ugh.

There's a reason people flocked to Java in those early days: it was easy to use. None of those crazy idiosyncrasies from C++ to deal with. It was nice and simple to learn and nice and simple to use.

Now we have a bunch of people thinking we need to over complicate the language...for no understandable reason other than "just because."

First we got Generics. We all know how that went. While it's passably better than what was originally there, it's still not worth a damn. Granted, if Sun wasn't so damn worried about preserving backward compatibility we probably could have had a cleaner implementation, but it is what it is and we're stuck with it. I'm still not so sure we really needed it - my coding was getting along just fine without. Yes, all those casts were a pain in the ass, but I learned to deal with it, as did many other developers.

Now there's the whole closure debate going on. Quite frankly I'm still having a hard time trying to figure out whether the average developer is really going to make any use of it. Sure, closures are a handy thing to have, but the simple fact that the Java development segment of the industry has been chugging along for 10+ years just fine without it tells me that it's not really all that important.

There's also the fact that the Java languages wasn't designed with closures in mind to begin with, which means that whatever implementation we end up with is going to be some tacked-on hack job that's going to end up making the language even more incomprehensible than we've already managed to make it.

And I have little doubt that the implementation of closures is going to suck - especially if Sun (or whomever is in control since Java is open-sourced now) tries to maintain backward compatibility with the previous platform versions just like they did with Generics. I have zero faith in the idea that closures will get implemented in a clean way.

Now I see this annotation insanity, which isn't guaranteed to be implemented, and I'm wondering exactly who the hell comes up with some of this stuff, and why the purveyors of the Java language even allow such ideas to get consideration for inclusion in the langauge.

It's no wonder we have Rubyists singing the praises their language and regaling us with ideas like andand, looking at us Java idiots and wondering when we're going to wise up. We're turning the language into an insane pile of unusable crap.

We've somehow deluded ourselves into thinking that Java's greatest strength - it's simplicity compared to previous popular languages like C++ - is somehow a hindrance to it now, so we've decided to tack on all these other features that came from C++ and the like - features that were not included for a reason, remember - to try to "make it better." On top of that, we've got this weird language envy thing going on: We want to add all the ideas from our dynamic language friends out there and try to dress up Java and pretend it's something it's not.

Here's a tip for everyone. I can't take full credit for it: I got it from a hot rod magazine, of all places. It's as true today as it was when I first read it back in my teenage years, and just as relevant:

A universal part universally doesn't fit anything.

Java is not a universal part - it will not - and should not - work for all solutions. The sooner we stop trying to twist it into some monster super-solution that's all things to all developers the better off we all will be.

It's the Information, not the Medium, That's Important

2008-05-06T08:12:00.008-04:00

So Jeff Atwood and Joel Spolsky are working on a new idea that both hope will deal with the fact the programmers don't read books. It's an interesting idea, albeit a little vague in the details currently (hopefully that'll change soon), and I hope they get something worthwhile going with this. I'm all for giving programmers easier ways to find information and that basically helps them "get stuff done."

So anyway, the fact that Jeff mentions the whole "programmers don't read books" thing opened up a big discussion in the programming blogosphere about the pros and cons of reading books. Most of the commentary is along the lines of either "you suck if you don't read books" or "I don't have time for this book reading sh*t."

When I first started seeing this discussion unfolding, I was ready to hop up on my high horse and ride right on into the "you suck if you don't read books" camp. As can be seen by anyone that walks into my office at home, I have quite a significant number of programming books in my collection currently. I've spent major sums of money on the likes of Knuth, and McConnell. I have books on specific languages like Java, Ruby, Python, and C++. I have many books on Linux administration and application development. And I have plenty of "general programming" books - Code Complete, The Pragmatic Programmer, and so on. And this covers only the books I currently have - I've gotten rid of tons of books through the years, mostly due to their obsolescence or just lack of real need anymore. I could run my own library with the number of programming books I've had over the years.

But after some thought, there's something that a lot of people (including myself, until I thought about it) have missed in this discussion: Not everyone likes reading books.

Here's an example: My brother, who's also a fairly computer-savvy technical guru, hates reading books. He doesn't have the patience for it. Never did. That hasn't stopped him from being the absolute best at his work, though. He's still quite capable of learning whatever he needs to in order to get the job done...he just doesn't do it by shoving his nose in books.

He's not alone out there - many people just don't have the desire to pick up a book and start reading. Be it genetics, or whatever, they just don't like reading books.

This doesn't prevent them from learning about things like Design Patterns, or Inversion of Control, or Scala, Ruby, Closures and whatnot - they just chose a different path to get the information they need, be it the Internet, PUGs, or just walking over to the next cube and talking to a coworker.

The important thing is they get the information needed do the job at hand, improve their skills and expand their knowledge. How they get that information is simply a matter of personal choice.

The medium isn't important.

I personally will continue to read books on whatever subject interest me, or that will help me to be a better developer. And I will continue to recommend some of my favorite books to fellow developers that I think are worth reading. But I won't begrudge anyone their choice to not do the same.

BASIC Days

2008-04-22T06:59:00.003-04:00

Jeff Atwood is reliving his early programming days in this latest article.

For me, it was the Commodore 64 that got me started on the road to coding...

My brother was given a Commodore 64* (either as a Christmas or birthday gift...can't remember which) when he was just barely a teenager. Him and I both spent many, many hours on that computer. We messed around with GEOS - a Windows-like GUI system that ran various applications like word processing (my brother eventually got a printer to hook up to the system) - and ventured into the very early online scene through a blazing-fast 300 baud modem.

Those were the days.

But as you would expect, most of our time was spent playing games - we had a rather large collection to pick from as we'd take every opportunity we could to buy a new game when we had the money to do so. Eventually, out of either boredom or curiosity or both, I ventured a look into one of the books my brother had for programming BASIC games (he wasn't much into programming...didn't have the patience for it). I then began to learn the ins and outs of how to make the computer do my bidding.

That was pretty-much when I caught the programming bug.

I was about 10 years old.

I have a very vivid memory seared into my brain from that time programming BASIC on the Commodore 64:

I remember sitting in my room with a stack of loose leaf paper, meticulously thinking about, and writing down, every single instruction for a program I was working on. I wrote it all down by hand first. All of it. At least several pages of loose leaf paper - front and back - were filled with BASIC instructions.

Once all of that code had been written down, I needed to make sure that it was all correct, error-free code. After expending all of that effort writing everything down the way I did, I didn't want to spend time entering the program into the computer, only to meet failure square in the face because I didn't do something right in the code.

So I used the only method I had available to me at the time: I sat there and - starting with the first instruction on page one - followed the program logic to ensure that it was correct. I ran through the entire program in my head to ensure that it was correct before I entered anything into the computer. If any problems jumped out at me I would fix them right then and there, before the code was entered into the computer, and avoid any unnecessary headaches.

The big reason I did it this way was necessity: It's hard to write a reasonably long BASIC program entirely from one's head when you're only about 10 years old (I was smart...but not that smart).

Also, at the time it just made sense to me to do it that way. And thinking about it now, I realize it was a very smart thing to do...even for a 10-year-old.

Looking back, I'm still amazed at the effort I put into making that program. At the time I was determined to make that program work, and work right the first time it was run on the computer. I spent an enormous amount of thought looking for the best way to accomplish the task I had set out to create, and did everything in my power to ensure that the final result was correct.

It was the best damn BASIC game I ever made :-)

The determination I had when making that program has stayed with me throughout the years: I put that same kind of effort into the projects I work on to this day. I am always striving to do the absolute best I can as a developer, and a big part of that comes from the trials and tribulations I went through back in those early days, some 20 years ago.

Learning BASIC was one of most influential moments of my life...I can't imagine what my life would have been like had I never had the curiosity to explore the wonders the Commodore 64 had to offer way back then.

*That Commodore 64 (and a VIC-20) has been stowed away at my parents' house (in it's original box, too), along with countless games and accessories, for some 20 years now. My brother keeps saying he's going to come get it, but sooner or later I'm going to beat him to it :-)

Data Overload

2008-04-14T09:49:00.003-04:00

Like Jeff Atwood, I think developers should be able to build their own PCs. It can give you a better understanding of computer systems in general, which is always a good thing. With the exception of a laptop I had previously, I've alway built my own PC: I have never owned a name brand computer...ever.

When I built my latest PC last year, the 250GB secondary hard drive (I have two drives in my system: a fast 10K RPM boot drive and a 250GB data drive. Yes, I got that idea from Jeff too :-) was far above the paltry single 40GB that I previous had in my old system. It wasn't the largest I could have gotten - I could easily have popped in a 500GB or even one terabyte - but it's been more than enough for my needs.

But one thing I've discovered is how much of a pain in the ass it is to manage all the data that's accumulated on it.

Granted, I've had problems managing excessive amounts of data in the past - especially, when I had more data than could fit on my hard drive. I've used Zip Drives, CDRs, recordable DVDs, USB drives...and so on. Whenever I was on the verge of running up against the storage limit on whatever drive I had, I'd take the time to sort through the data and dump whatever I could to some other media.

But now that problem doesn't really exist: Instead I'm faced with an ever-growing pile of data that doesn't need to be dumped as was necessary before. It just sits on the drive. Now, remembering the old days of cramming data onto minuscule twenty megabyte drives, this isn't necessarily a bad situation to be in: I'd rather have too much storage than not enough.

But in some ways I miss those days where I was forced to deal with the capacity shortage. For one thing, it's typically easier to manage data when you're forced to move it to some other storage medium: When your hard drive is overflowing with data, you typically find yourself playing "survival of the fittest" with what you have stored. Basically the junk gets deleted, leaving only the most important data, then whatever doesn't need to stay stored locally on your hard drive gets dumped onto some other medium - be it CD, DVD, USB drive, etc.

What I have going on now is that I don't play "survival of the fittest" anymore: The data just sits on the drive, being that the 250 gigs has been more than enough storage for me (at least right now...). I really just don't bother deleting much, since there's no real need.

I will occasionally go through and delete some junk now and then - typically any miscellaneous downloads, temporary files/directories, or other stuff that's easily replaceable - but I now have an ever-growing pile of stuff stored on the drive that's getting harder to manage. It's becoming more difficult to figure out ways to keep the stuff organized in a way that I am satisfied.

I'm almost afraid to imagine what things will be like when I'll be sporting multi-terabyte - or even petabyte - storage capacity in the coming years. How the heck will I manage all of the data that I'll likely accumulate then?

There's no easy solution, so it really comes down to a matter of just trying my best to stay organized (which I admittedly am not particularly good at). But as storage capacity continues to grow and I (and others like me) continue to find ways to use it, it'll become more and more difficult to manage all of the data that accumulates. It'll literally become a full time job just trying to keep data organized and manageable.

Of course, I never thought I'd ever find myself in a situation where I would complain about having too much storage...so I'll continue to muddle along :-)

One Job Perk That Nobody Talks About...

2008-04-12T09:35:00.007-04:00

I've read plenty of blog posts covering the things that will keep developers happy: Individual offices, top of the line computer hardware (including perhaps a multi-monitor setup), short work weeks, flexible hours and so on.

All nice to have - and go a long way to keeping us hackers motivated and happy. But I've come to see there's another important perk that nobody talks about:

Commute Time.

I recently took on a new position with my employer, which resulted in me commuting to a new location every day. My commute time is now down to half of what it was previously...and has it ever made a difference for me.

I work near the Washington D.C. metro area - an area that's now the second worst in average commute time in the country (just behind New York, but catching up fast at the rate of growth in this area). My home is outside the immediate metro area of D.C. - it's about a 35-mile drive from my home to the office I was in before I took on the new job. That 35 miles took at minimum an hour on the road.

That's one hour to get to work and one hour to get home. Two hours of my life stuck in the car every day. That's ten hours a week!

And remember: This is when traffic isn't bad.

Most of the heavy traffic is concentrated right near the office, which sits near the western portion of Interstate 495 (the Capital Beltway) which, for anyone that's familiar with it, is the worst part of the entire beltway. Getting around that area is pure torture.

Well now I don't have to deal with that anymore. Thank God.

The switch to the new office took me away from that dreaded part of the beltway: I'm now just outside the eastern part of the Interstate, which is decidedly less congested. I can otherwise avoid the beltway entirely, too, since there are good alternate routes down to the new office which I normally take now. I'm now dealing with a commute that takes a maximum of 30 minutes (Of course, I'd love to have a commute of zero...but I'll take what I can get).

It's amazing how much commute time affects your well-being. After spending a little over 3 years doing the long commute, I was constantly feeling....well I don't know how to put it, but I wasn't happy most of the time. I just was in a constant state of feeling run down, irritated and otherwise kinda-sorta-crappy.

While I knew the commute was getting to me, I didn't really appreciate how much until I switched to the new office: I'm noticeably more cheery, energetic and otherwise happier than I was before.

What boggles my mind now is that I managed to handle it for so long. I've done long commutes (did a 2-hour commute - that's 2 hours one way) in the past, but not for more than two or three months. How people manage to commute longer than I did for many many more years than I have boggles my mind. How the hell do they stay sane?

Well given all the road rage out there...I guess they don't.

Getting Your Customers To Change Their Ways

2008-03-24T09:05:00.007-04:00

We programmers talk about getting rid of accidental complexity so that our code contains only essential complexity. And business processes are what we think of as essential complexity. Fair enough. But business processes have accidental complexity as well. Business processes suffer from poor maintenance over time. Business processes need to be refactored as well, and when you have a project to automate a process, you have a certain amount of freedom to challenge the process, to prod and poke it, to question it. Don’t assume that you have to take it as entirely given, a set of requirements cast in stone.

-Raganwald

I've mentioned the whole accidental complexity thing before, although not in terms of business processes. Reg's post is a great read (and well worth a look), but the post points to an even deeper issue in software development: Trying to convince your customers (or stakeholders if you prefer) to change their business processes.

Now all software developers, in the course of working on some project or another, have always come against some workflow issue and said to themselves, "why the hell do they do that?" I have had plenty of those situations (far more than I'd like to admit, I think) - especially on a recent project. In many cases, instead of trying to point out the problem, we'll happily plod along and do what the customer asks rather than tell them they need to change how they do things. In this sense, we're just as liable for the problems of process complexity as the customer since we don't point them out when we see them.

But one big reason we're content to just shut up and code is because the customer pays the bills: They ask us to build something and we build it. In a lot of situations, they don't want us telling them how to do whatever it is they do - they just want us to build them something. Period. End of story.

Sidebar: This is especially the case in the government sector - where trying to get some organizational unit to change it's business process can take years to do, and may even require action by congress. This is a big reason we get projects like Virtual Case File as results - not enough critical attention is focused to the business processes, since nobody really has the capability to make immediate changes. A bureaucratic (or otherwise complex) process will result in a bureaucratic software system (if it can ever actually be implemented in software, which is not very likely).

So how do we tell the customer/stakeholder to change their business process?

I don't think there's an easy answer to that, since every situation is different: Some customers are simply more receptive to such suggestions than others. I guess the first part of the solution is to make sure you're working with the more receptive customers before you start the project...that way you can avoid the headaches altogether.

Probably the best way to get a customer to change a process is to show them: If you're developing a software solution that follows the business process in question, than being able to show the customer a prototype of a more streamlined business process might help get the point across in a better way than simply saying, "Hey, you're process is flawed. We should look at improving that first" ( and if you're following some rapid development process like XP, or other agile method, this shouldn't be too hard to do.)

If nothing else, this should at least help open a dialog between you and the customer (And we all know how important communication is around here, don't we? :-).

Having that kind of dialog with the customer is the key to getting the customer what they actually need, rather than just what they want.

Adobe moving to Flex-ify the mobile market?

2008-03-20T08:47:00.005-04:00

After my last posts about the iPhone, now comes word that Adobe's moving forward with an iPhone version of the Flash player. This, despite the fact that the iPhone SDK license prohibits interpreted code (which has put the brakes on Sun's aspirations for an iPhone JVM).

How is Adobe going to reconcile the licensing issue? I'm not entirely sure. But it seems that Adobe probably has a good deal of leverage in getting Flash support on the iPhone. For one, given Adobe's extensive track record on the Macintosh platform - an entire suite of applications that have long been associated with Macs - they may have a little more sway over getting the Flash VM (or some variation of it) on the iPhone than perhaps Sun would have in getting the JVM supported. Adobe has a long standing history of support for Apple's systems, so I don't think Steve Jobs would want to piss off one of his biggest supporters.

Also, considering the large number of sites nowadays that take advantage of Flash in some way or another, not having the Flash player available on the iPhone effectively cuts off the user base from a significant portion of useful services. I'm sure the users might also put pressure on Apple in to support Flash (if they haven't been already): Being cutoff from popular sites such as YouTube, for no reason other than some licensing snafu, is likely nothing short of irritating.

Coupled with the iPhone situation is the recent deal Adobe made to put Flash on the Windows Mobile platform. Of course, the web experience reason given for the iPhone also applies here: User don't want to be limited simply by not having a Flash player on the system. Windows Mobile already has a pretty large user base - it's been around for much longer than the iPhone - so having Flash available on Windows Mobile devices definitely make sense.

This all seems to signal the intention of Adobe to move into the mobile development marketplace: Having Flash on the likes of the iPhone and Windows Mobile opens up both of those platforms for Flex, since it's a fairly small extension to the existing Flash platform. And since Adobe has no real presence in the mobile space, it has a lot to gain by extending it's Flex application development into the mobile market.

Whether they are more successful than Sun has been with Java Micro Edition is anyone's guess. Sun has enjoyed limited success in the mobile market - they've made inroads, but as this article I linked to in a previous post explains, it hasn't been what Sun would ultimately have hoped for.

The good part of Adobe's push seems to be that they are focusing on the Windows Mobile and iPhone platforms, rather than the individual mobile phone suppliers themselves (at least currently). iPhone licensing aside, both of these platforms are considerably more open to 3rd party development than other phone systems that are directly in the control of the mobile manufacturers. Of course, both of these platforms are used on phones that are significantly more sophisticated (and higher priced) than a standard mobile phone, so the user experience would be limited to those that can afford the more expensive smart phones. But as the devices become more widespread, this obviously will open up the user base even more. I think the iPhone has helped in this regard, as it's clearly shown what's possible in a smart phone and has expanded interest in the smart phone market.

And adding both Java (including JavaFX) and Silverlight to the picture also opens up the competition for the mobile development marketplace. Should these technologies make significant inroads into the mobile market (which I would expect them to if Adobe continues it's push) it means nothing but good things for future mobile applications as all three companies compete to bring the best development capabilities to mobile devices.

More iPhone Musings

2008-03-17T09:10:00.002-04:00

Following up on my previous post about Java on the iPhone, I came across this (via Raganwald...again).

I liked the article on the whole, as it provides a good deal of background information. Many of the articles I've read on RoughlyDrafted previously contain a nice amount of history in each article. But in this particular case it seems they go through a great deal of back story just to say "Apple doesn't need Java on the iPhone". That's all well and good: But the license accompanying the SDK pretty much makes the idea of Java on the iPhone a non-issue, since it doesn't allow for code interpreters (This probably also explains why Jobs stated that there'd be no Flash on the iPhone: If he allowed for Flash then released the SDK with a license disallowing applications running interpreted code, all hell would have broken loose).

Of course, being a rather Apple-centric site, I can't say I'm surprised by their take on the idea of Java on the iPhone. I do certainly agree with most of what the article says - Sun has had a hard time with Java Micro (and Java on the Mac is in disarray at the moment, too) - but I think they're making a mistake by assuming that Sun would have simply ported Java Micro over to the iPhone. Based on the comments made by some people at Sun, it sounded more like they were interested in making a more robust VM for the iPhone and not just a JME clone.

Of course all of this is irrelevant at the moment: Apple's license for the iPhone SDK currently forbids something like Java.

I still think that removing the idea of Java and Flash/Flex for use on the iPhone is a mistake: Apple may not need to have these technologies for continued success, but artificially limiting what can be run only removes additional avenues of innovation for the iPhone as platform. For one thing the shear number of developers working on both Java and Flash/Flex could be leveraged to Apple's advantage.

Just because you don't like something doesn't mean it can't be useful in some way.

The Job Interview as a Game

2008-03-13T07:21:00.010-04:00

One weakness that I've come to recognize in myself is that I'm terrible at interviewing for a job. I mean seriously...I suck. Always Have. And it's not like I don't know how to do the job for which I'm interviewing, it's just that when it comes to face-to-face interviews I tend to struggle and have a hard time getting the point across that I'm a damn good software developer.

Part of it may be that I don't have that salesman mindset - that mindset that requires you to be able to at least bullshit your way through some part of an interview. Maybe not bullshit...maybe just the personality traits that allow someone to properly convince others of their great programming skills (When it comes to software development you rarely want to have someone that can bullshit their way through an interview, and most interviewers - the competent interviewers, anyway - have some form of BS detector with which to weed them out.)

In either case, being of the software developer mindset - that of constantly trying to figure out the "right way" to do things - I've tried to analyze the problems I've had with interviews and improve my interviewing skills...to varying degrees of success.

Over the course of a few interviews I've managed to uncover and...well..."hack" at least one problem, which is my shy nature: I have a hard time talking to people I don't know well, or am not familiar with in some way. I think many times I've done interviews my shyness has made me come off as having an anti-social personality...perhaps even made me appear arrogant (I've never confirmed this for sure. It's just a feeling I get from the interviews I've done.) Definitely not good qualities to show during an interview.

Nevertheless, that's one issue that I've been able to deal with in a few recent interviews by giving myself sufficient motivation to open up and engage in conversation more freely (job interviews in themselves are usually good motivation, since I'm trying to increase my personal income by looking for a new job).

So that's one problem down...

Another problem I have to overcome is my somewhat cynical nature about the interview process: I've come to regard the whole thing as a rather lame song and dance (or whatever metaphor you think fits) where I basically have to stand in front of people and say "Hey! Look at meeee! I'm the awesomest developer out there!" And...way too often...the people I'm pandering too have no flipping idea what I'm talking about when I mention technology X or framework Y during the interview, cuz they're not the technical people and I'm just supposed to convince them that I'm good based on how I act rather than what I actually know.

The simple solution: Stop interviewing with lame-ass people like that. I've basically tried to avoid the whole recruiter mess (which is kind of difficult since the area I'm in seems to be bursting at the seams with more recruiters than actual jobs).

But my overall attitude about the process hasn't changed much: I think it's stupid and aggravating and annoying and...well you get the idea.

So then yesterday Stevey talks about getting that job at Google in his latest blog post, and gives some advice for would-be interviewees.

Best. Advice. Ever.

For those too lazy to read through one of Stevey's post (they do tend to be rather long...but well worth reading), here it is in a nutshell: Treat the job interview as you would a final exam - study and prepare beforehand. Expect just about every damn question ranging from the basics to the advanced stuff and leave nothing to chance. Practice, practice, practice before the interview.

I'd maybe even go further than this and say that perhaps you could even treat it as a game or a puzzle. One where you're trying to figure out the best solution as quickly as possible in hopes of "winning" a job. In this way, you need to prepare for the exam/game/puzzle by boning up on all manner of subjects that would give you that extra edge.

Thinking about it...maybe you'd want to treat the interview as though you're going on the game show Jeopardy: You'd want to study and test yourself on all manner of subjects ranging from the obvious to esoteric before getting on stage with good ol' Alex, wouldn't you? Based on Stevey's suggestions it seems like you should prepare in a similar manner for an interview as a software developer, too.

I think that's a damn good idea.

I like the perspective that Steve provides in his post: It's a welcome change from the usual "cheat sheet" style of most interviewing-related blog posts, which show a list of common questions that some interviewers like to ask. Knowing the typical questions that interviewers like is certainly nice, but understanding the underlying question of why those particular questions get asked is not usually so clear.

Plus I like the idea of preparing for an interview they way he describes. I think this is an area in my own job interviewing that I feel could help a a lot. I'm traditionally the type of person that likes to wing it, which after reading Steve's post I'm realizing isn't a very good idea.

Hmm....Be Prepared....I remember hearing that during my childhood somewhere...

One again: Communicate!

2008-03-11T09:20:00.002-04:00

This blog post (found via Raganwald) reiterates what I've said previously: It's all about communication.

This is the single most important reason why projects succeed or fail.

This is also why I think The Mythical Man-Month is one of the most important books that any developer can read...even so many years after it's initial publication.

Seeing the "adding programmers to a late project makes it later" quote explained in detail is certainly interesting and worth reading, as is reading No Silver Bullet which also has some important points as well (and which I've even talked about previously, too).

But the single most import discussion in The Mythical Man-Month is about effective communication.

Fred Brooks recognized that maintaining effective communication is what separates successful projects from failures. The amazing (or distressing) thing is that he understood this well over thirty years ago. It sometimes seems like that message got lost while everyone focused on his discussion of complexity and the whole "adding programmers to a late project" that everyone loves to quote so much.

As developers, we have a habit of finding ways to shut out the world...which is certainly necessary sometimes to get the job done. But we have to be careful to not cut ourselves off so much that we're not keeping key people on the team out of the loop about our work. It's a delicate balance that has to be maintained, but it's important that everyone involved in a project has an idea of what's going on - whether you're a manager, architect, developer, or user.

To do otherwise is to invite failure.

iPhone SDK Could Mean Big Things for Java (and Flex?) Developers

2008-03-10T09:27:00.007-04:00

So I saw a little blurb this weekend on Slashdot pointing out this InfoWorld article. It talks about Sun's intention to port the JVM to the iPhone.

At first I was a bit ambivalent towards it: Sun certainly has the experience and capability with the Java Micro Edition to make this happen, so I have no doubt it will (unless Steve Jobs tries to put up roadblocks for Sun...which would be monumentally stupid if you ask me). But since most of my own work has never really touched the mobile space, I wasn't particularly overjoyed by the announcement. I thought it interesting, but that was about it.

Of course, I didn't initially RTFA, either. So after taking a closer look, I think this could be the start of some big things for the iPhone. And not just in terms of Java development.

For one, the article quotes Sun's desire for developers to port ERP and CRM apps to the iPhone. While I'm not sure how feasible that may be (depends on the JVM implementation, and the nature of the applications themselves, of course), it signals a desire by Sun to help make the iPhone a full fledged platform for businesses to take advantage of. And also considering the number of Java developers out there, this could provide a huge boost to iPhone's dominance in the future with having such large developer pool to draw from.

But something else that caught my attention in the above article was the possible implementation of JavaFX on the iPhone. Even though a release of a JavaFX implementation is further down the road than just a usable JVM, this could prove to be a huge boost for Sun's framework.

And this would obviously get the attention of Adobe, opening up the likelihood that they will step in and deploy a version of Flex for the iPhone as well. Even with Steve Jobs' mentioning that he didn't have plans to include Flash (which is what Flex uses) on the iPhone, there would be nothing stopping Adobe from doing something similar to what Sun is doing with the JVM and implementing it's own streamlined VM for the iPhone (or even just some performance tweaks so it runs acceptably).

So, with the release of the SDK , you have Sun - and potentially Adobe - both battling in iPhone-space to develop mobile applications. The future of iPhone development could be huge for both Java and Flex.

Of course, it's just speculation whether Adobe would jump into the iPhone world, but I think if Sun's heading down that road it's a good bet they will, too. The potential market there is probably hard for anyone to ignore (which is probably why Sun's even considering a Java version for the iPhone in the first place).

But this is all contingent on whether Steve Jobs attempts to quash what Sun is planning for the JVM. I think it would be a big mistake if he does that, though: Shutting out new avenues of innovation on the iPhone (not to mention the huge developer base there is in the Java world) would unnecessarily hamstring further popularity of the platform.

I'm anxious to see where this goes now. The iPhone has a huge following and having Java (and possibly JavaFX and Flex) development in the mix opens up all kinds of potential for the iPhone as a platform.

One of My Favorite (and Most Productive) Developer Tools

2008-03-06T07:49:00.012-05:00

In my career as a developer, I've constantly tried to work with new - or just different - tools: I've jumped editors from Emacs to Netbeans to Eclipse and back again (and still do when I have an itch for something different), worked with build tools the likes of Ant, Maven and make, and messed around with just about every popular (and not-so-popular) programming language out there at one point or another. All in an effort to both explore technologies and to find ways to be as productive as I can.

But I've realized recently that, over the past several years, there's been one tool that has consistently allowed me to be the most productive possible.

My MP3 Player.

First and foremost, being able to focus on my work is the first step toward getting anything done. And, seeing as I currently inhabit a cubicle, I'm forced to find ways to deal with a large number of distractions around me (and recently it's become increasingly necessary: Seems a rather obnoxious group of people has recently relocated to an area near my cube...lucky me).

Of course, every one of us knows that, as developers, we need more productive accommodations than a cube. I would love to have the type of work environment the likes of developers at Fog Creek or Google have, and the likes Jeff Atwood, and Joel Spolsky advocate - I have had that type of workplace previously, so I know how wonderfully productive it can be - but realistically not many companies out there provide such a workspace. It's unfortunate, but that's the way it is and many of us just have to deal with it.

So I do what any other code jockey out there would: I tune everyone out. Literally.

Currently, I use an iRiver H320 (Although certainly good players, I tend to avoid the more mainstream choices like iPods or Zunes...if nothing else than to just be different). So far the iRiver unit has been a worthwhile purchase: It meets my current needs (i.e. drowning out the commotion around me) and I'm happy with it.

Player choices aside, even if I had a private office with no distractions at all, I'd likely still pop in the earbuds and listen to my music player. I've found that my best coding work has been done while listening to a steady stream of music. Usually, with the right music playing, I'm able get myself into the zone and stay there for extremely long periods of time.

This might not work for everyone, but for me it's been an invaluable asset to my productivity and one of the best tools I could ever have when developing software.

Re-Flex

2008-02-29T08:48:00.006-05:00

With various events in my life conspiring to make most of my plans go out the window in the month of February, I was forced to neglect my Flex-related adventures for a while. However, I'm hoping to pick back up some steam on this front...especially since Adobe has released Flex 3 and Air. I still haven't gotten through my reading of these two books, but since things have settled down a bit I have some time to pick up where I've left off and do some experimentation.

In the meantime, in case you haven't seen 'em, ThinkFast's Blog has the remaining parts of their Flex vs JSF comparison that I mentioned previously, which are worth looking at: here are Part 2, Part 3 and Part 4. They aren't terribly in-depth, but give a nice overview of how Flex compares to your traditional Java-based web development using something like Struts, Spring, etc.

Some observations from the comparison (and some of my own experimentation):

Flex application development seems to follow a more traditional GUI application development paradigm, and as such business logic and interface tend to get intertwined in some ways. Now, some of this is mitigated by using MXML which helps keep the GUI layout and behavior separated from the business logic, but I can still see where you might end up with some business logic getting mixed in with the interface-related code. Traditional GUI developers (like me) are probably a bit used to this already, but developers that are more web-centered might be a little put-off by it since they are used to having a much cleaner separation between presentation layer and business logic when designing and developing a web application.

That being said, from what I've seen so far with Flex, it still has more flexibility in providing a more traditional desktop application style interface for a web application. My experience with web development so far has shown me that this is something users are continually wanting when they run a web application. Trying to make a web app behave like a desktop app can get complicated using things like HTML, Javascript, Ajax, JSPs, etc., and in some cases can be downright ugly.

Also, as the web pages that comprise the user interface get more complex, the difficulty of maintaining individual web pages that support complex interactions begins to get bogged down: What would be an almost trivial change to an interface in a more traditional desktop application can turn into a major pain in the butt in a web interface. As you gain experience with web development it gets easier do deal with this, but sometimes it's nice to have a more traditional, desktop GUI paradigm to work with.

Anyway, these are my thoughts so far. I'm hoping to really get down and dirty with Flex again (barring anymore events that screw up my plans again...life has a funny way of doing that) and see what it can do.

Swing: I'm not dead!

2008-02-27T06:19:00.007-05:00

I've been actively using Java Swing since the Java 1.2 days...back when the ol' "Swing is slow" ranting and raving was in full force. I've become so comfortable (or uncomfortable, depending on the circumstances) with the toolkit's ins and outs that it's almost trivially easy for me to slap together a GUI using it (I don't use a GUI editor at all when I do this: Years of being burned by poor implementations that whipped out miserable code just turned me off to Swing GUI builders. Matisse is certainly a big improvement...but I've just been turned off by GUI builders so much that I don't care to use them now).

Of course, it seems that from the moment I started using Swing to do anything substantial people were already talking about the imminent demise of the toolkit.

Seriously...Swing's end has been coming any day now for the past 10 years...

And yet...here it is still chugging along.

Reminds me of the scene in Monty Python and the Holy Grail, where a guy's trying to convince the collector of the dead to take the old man who's constantly saying "I'm not dead".

So, when I see posts like this and this, I keep asking myself: What's the deal?

Repeat after me, folks: Swing is not dead.

Swing is not perfect - Anyone that's used it for more that a few months to build any application can tell you that. No GUI toolkit is. Each has it's own quirks, be it Java toolkits like Swing or SWT, Python's Tkinter, QT, or whatever other GUI toolkit you wanna throw out there.

I, for one, certainly have my own list of gripes for Swing that I wish were fixed (inconsistent API is one...but that goes for not just Swing, but big chunks of the Java API as a whole), as well as features I'd like to see added. But just because there's no significant movement toward adding new features to Swing doesn't mean that Swing is "finished", "dying" or "drowning" in any way - if anything that tells me that the toolkit is relatively stable. Sure, I'd like to see some changes, but I'm not going to start shouting doom and gloom when they don't show up.

And yes, there are new alternatives coming around now like Flex and Air, but quite frankly I don't want to see Swing get contorted to hell just to try and be more like the alternatives, because if I want to use something that's like Flex...I'll just...oh, I don't know...use Flex.

Swing has matured to the point that significant changes either aren't necessary, or aren't in the best interests of the community.

And since when is that a bad thing?

Where Would You Like to be in Five Years?

2008-02-13T09:58:00.004-05:00

After reading a blog post on How Not to Interview Programmers - which mentions the question in the title - it reminded me of how disgustingly often I've been asked this question in an interview.

My answer: I haven't a goddamn clue.

Of course, I don't phase it like this when doing an interview...that's just the thought that immediately comes to mind every time I hear the question.

One big reason I don't have any clue on where I want be in five years, is because I've tried to answer that question seriously, and every time I've been wrong.

The way the computer industry moves (i.e. rapidly) just compounds the problem even more. It's bad enough when you try to plan out your career five years down the road, but with the way things change from year to year...to say nothing of five years...is mind boggling. It's damn near impossible to predict where you'll be.

Of course, I realize why hiring managers like to ask this question: To ensure that your goals line up with that of the company you're interviewing with. But this just makes it more annoying of a question for me, because nobody's actually going to answer the question in a way that doesn't align with the company's goals. Seriously, if you're looking for a job are you really going to give an answer to this question that makes you less appealing of a hire to the interviewer?

Another annoying aspect of this question is that it has the same kind of result as asking "what do you want to be when you grow up?" Typically when you ask any youngster this question you get plenty of good answers, but when all is said and done and the kid grows up, he or she ends up doing something that wasn't even mentioned: Future astronauts end up being auto mechanics, because they discovered one day that they loved to work on engines.

It might make for good chit-chat, but anyone asking this question in an interview should really stop and think about whether it's really necessary...odds are it's not.

The Talented Developer

2008-02-12T09:19:00.000-05:00

A recent Coding Horror article talks about the "experience filter" that many hiring managers tend to employ when selecting candidates for a software development position:

This toxic, counterproductive years of experience myth has permeated the software industry for as long as I can remember. Imagine how many brilliant software engineers companies are missing out on because they are completely obsessed with finding people who match-- exactly and to the letter-- some highly specific laundry list of skills.

I'd add that in many cases I've seen, you could also add the "BS in Computer Science" degree requirement to the myth as well.

Now, I don't want to get into a discussion of whether a CS degree is worth it or not: That discussion has been going on for years and there doesn't seem to be any clear answer one way or the other. And with the recent (and very worthwhile) discussions taking place about Computer Science, I don't think the matter will be settled anytime soon.

My point is, much like the The Years of Experience Myth that Coding Horror discusses, there are plenty of great developers out there that get tossed aside because they do not have "BS in Computer Science" stamped on their resume somewhere. And these aren't developers that don't understand data structures, algorithms, or any of your typical Computer Science material, either: Some of them in fact have - many even have quite a bit of - CS education under their belt. But because they don't have that piece of paper that says "Degree" on it, they get dismissed out of hand as being unqualified.

I always get frustrated by this, because it's a sign that the people that make this decision are confusing knowledge with talent.

Of course, trying to define "talent" in and of itself is hard to do...which is probably why some out there mistakenly rely on the knowledge side of the equation to help them get at the people that may have talent: Basically, they're taking a gamble and hoping that it works out in their favor.

And unfortunately this works against far too many talented people out there. I've come across many developers in my career - many with no degree whatsoever - having the ability to work with some of the most amazingly complex systems and concepts you can imagine. They've written some of the best code I could ever hope to work on, and were some of the best people one could ever hope to work with.

I've also run into my fair share of degreed individuals that couldn't program their way out of a paper bag.

My own experience might be anecdotal, but it begs the question: What makes a developer talented?

I've never seen any clear-cut idea of what makes someone "talented" - in this, or any other, field. Is it passion? Probably. Ability to learn? I'm sure that's in there, too. But is there some characteristic that's easily observable in people that can rightfully convey talent one way or the other?

After reading articles like this recent Raganwald post - which is best summed up as "Finding talented developers is pretty damn hard to do" - it seems to me there's no simple answer. And Reg's post makes mention of the fact that you need talented hiring managers in order to find talented developers (and who finds the talented hiring managers? Nice little recursive problem we have there).

Of course, we can all find examples of talented developers out there: Someone like Linus Torvalds (and probably a most of the Linux kernel developers), Matz, John Carmack...and so on. But is there some shared characteristic between them all that you can use to say: "This guy (or gal) has it"?

Whoever figures that out will corner the market on talent, I'm sure.

Becoming a Computer Programmer: Rule Zero - You Better Love The Work

2008-01-24T08:40:00.000-05:00

While starting my list of Becoming a Computer Programmer Rules, I neglected the most important one of all, so I'm making it "Rule Zero":

You absolutely, positively, must love computer programming in order to have a successful career in it.

This pretty-much goes for any career path you choose, but it seems to be a vital point that gets missed by many people in this country nowadays. The dot-com boom days showed that there's way too many people out there focused more on making big bucks over doing what they truly enjoy in life...and our industry is still paying the price for that now.

So do yourself a favor and make sure you really, truly enjoy programming before you do anything else.

If don't you have a burning desire to make your code "perfect" in some way (code size, readability, performance, etc.) on a regular basis, or don't find yourself constantly working out new ideas with your code, then odds are your heart really isn't into the work. If you've never gotten that burning desire to fix some chunk of ugly code that went into production recently because it's just "not right", or you just think "it works, so the hell with it" and move on, then odds are you're not as passionate about the work as you thought you were.

Passion for programming is what drives the best out there - from the Open Source world with projects like Linux and Apache, to the big corporations like Microsoft and Google - and constantly compels those that develop that software to do the best work possible. In every aspect of their work they strive for perfection in some way.

Passion compels the best programmers out there to work into the wee hours of the morning on some pet project on their own personal time, tracking down some subtle bug in code that nobody likely will ever see. Passion is what compels programmers to write 500,000-line programs all on their own.

So while thinking about programming as a career path, make sure you're not thinking "hey I could make a good deal of money doing that." If you are, then please...slowly step away from the keyboard.

Don't spend a career doing something you're not truly passionate about.

A Geek For President

2008-01-18T06:27:00.000-05:00

Since we're full-swing into the presidential race here in the US (and since I live not too far away from the largest Reality Distortion Field in the world that is Washington, D.C.), I was thinking about the various candidates from both sides of the isle and how none of them seem to have much in the way of technological savvy. Well...they don't really seem to talk about technology much anyway. About the only stuff I've heard from any candidate regarding technology is one candidate's policy proposals (well at least someone has an idea of what they'd do on the technology side) and the myriad and various ways that the candidates want to regulate the video game industry.

But after thinking about it, I started wondering: Could a Geek ever become President?

Now when I say "Geek" I mean someone truly into technology, or some technology-related field. Someone that fits the traditional "hacker" moniker - a Linus Torvalds, Steve Wozniak...hell even a Bill Gates (yes we all cringe at that last one, but love 'em or hate 'em Mr. Gates was - and still is - a hacker-style geek). Could someone with that kind of mentality ever achieve the highest office in America?

(Note: Yes, I know Bill Gates could just throw gobs of money out there and probably successfully run for office, thereby making this question irrelevant rather quickly. Modern politics is all about having the cash to run a campaign, after all...but lets ignore that bit for now, shall we?)

From my perspective in the geek world, I think it would be enormously difficult - both in achieving the goal of becoming President and in making policy in that office as well.

For one, the common trait I've found in myself that matches most of my fellow geeks is our insatiable need for efficiency: We look for the quickest and easiest way to achieve some goal. Shortest distance between A and B. End of story. This kind of attitude almost runs contrary to what you would expect in government specifically and politics in general: Say what you will about the bureaucracy, but efficient it certainly is not.

I think the lack of efficiency would drive a geek nuts (and there are some geeks working in or with the government now that would agree with me on this). That reason alone would probably keep a great many from even trying to run for elected office.

Of course, that's not to say I wouldn't love to see a techno-savvy person as President (or even in congress, for that matter) - hell I'd be giddy as most of the geeks out there if that were to ever happen. At least then we might not have someone that uses bad analogies when describing the Internet to the general population...

Java Swing Improvements

2008-01-15T13:48:00.000-05:00

I've been actively using Java Swing in real world projects for many years now, dating all the way back to the Java 1.2 days. And while Swing has garnered a reputation for not being a particularly good choice for GUI development compared to more modern alternatives, it's come a long way from those early Java releases.

Of course, my time now is spent between an actively-used Swing project (which pops back onto my radar once and a while with some maintenance issue) and more Web-centered work involving the usual Java Web technologies of JSPs, Spring, Hibernate, etc. Add to that my own investigations into alternatives like Flex, Ruby, Python, etc and it's easy to see how one might miss some of the current goings-on in the Swing development world.

So I was pleasantly surprised to see, via java.net, things like the Swing Application Framework and Beans Binding. Both nice ideas for improving Swing development.

From looking at the brief introduction, it looks like they're making a real effort to eliminate a lot of the repetitive boilerplate that typically goes into most Swing applications. I especially like how they're trying to integrate background thread spawning (which every Swing developer must deal with at some point in their application) into the framework: I like how the framework can automatically deal with multi-threading, without having to touch SwingWorker or manually spawning any threads by hand.

Using annotations to handle generation of Actions is also a nice touch, too. That eliminates a significant amount of boilerplate code in a Swing app. Handling resource bundles is also vastly simpler in the framework from the looks of it, too.

Beans Binding is certainly a nice idea as well. And while the current proposal for binding isn't nearly as cleanly implemented as how something like Flex handles data binding with components, it's certainly an improvement over the rather ugly listener interfaces that tended to be needed to propagate changes between components and data in a loosely-coupled fashion.

The framework looks promising: It eliminates a lot of unnecessary complexity that typically pervades Swing application code.

I'll be keeping a closer eye on this in the future: There might not be a skyrocketing need for Swing development nowadays, but there's still enough going on that improvements like this could really help make Swing development at least more pleasant that it currently is.

Cult of the Damned

2008-01-04T09:44:00.000-05:00

Funny post at mikeash.com (via raganwald) on various cults in programming.

I'd just add one more to the list:

Cult of the Damned

One word: Management.

Turning a Screwdriver into a Hammer

2008-01-03T19:08:00.000-05:00

Use the right tool for the job.

From shop class in Junior High, to my drafting days in high school, and in learning about carpentry, car maintenance and so on, it was made painfully obvious to me - through my own faltering or the teacher's direction - that if you don't use the right tool for the job, you're just asking for trouble.

Now, in software development it's usually not so easy to figure out exactly what the "right tool" is. In this case, I'm referring to programming language when I say "tool." Often it's a fairly subjective choice. One in which you typically end up choosing what you are more familiar with rather than what's necessarily right for the task. Developers usually can avoid the trap of preference by constantly investigating new programming languages in order to better gauge what works and what doesn't for some particular problem. The more you work with new ideas and concepts, the better equipped you tend to be in choosing the "right tool" for the task at hand.

Of course, choosing to use a programming language you are familiar with, or one that is popular, is not always a bad thing: It may be preferable to go with what language you are intimately familiar with in order to get something out the door quickly, rather than taking the time to explore some new language. There may also be situations where you can't avoid using an less-flexible language than you would prefer since the existing system might be written in it, or it's been dictated from higher-ups that it be used for some reason or another.

In these cases, you simply have to use the tool you're given. It's not necessary the "wrong" tool, it's just a different, perhaps less-flexible one than you would prefer.

These are the situation that can cause problems.

Some developers out there, having gained experience using other languages and recognizing that there are better ways to solve some problems over and above what a specific language is capable of, start pining for the features of their preferred language (in their mind, the "right tool") when forced to use some "inferior" language. So they start to contort the code to the way the "right tool" is able to perform, resulting in code that is...shall we say...ugly as hell.

They're basically trying to use the screwdriver as a hammer.

Just about every developer worth a damn out there recognizes the situation I just laid out and knows that it's bad bad bad. Many of you out there probably go through great pains to avoid such situations.

With that in mind, let me ask a question:

Why the hell are we trying to contort the Java language into something else?

In this case, I'm specifically referring to the changes that seem to keep coming for the Java language. The most recent is (of course) closures. Before that it was generics. Who knows what other idea will get tossed around next.

There seems to be a desire to turn Java into a decidedly non-Java language these days...am I missing something here? If we all recognize that trying to program in language X as though it's language Y as bad form, then why on earth would we literally try to turn language X into language Y? Why not just try to convince the powers that be that using language Y would be more preferable in the first place? It may be an uphill battle, but I think it would be a better solution than twisting a language into some unrecognizable heap of bad language constructs that very few people are going to be able to figure out because they weren't built into the language to begin with.

We're no longer trying to use the screwdriver as a hammer, but trying to turn the screwdriver into a hammer.

Closures aren't necessarily a bad thing, and I certainly won't complain too much if they're added (as long as the implementation doesn't suck...but considering how generics ended up I'm not too hopeful). But I can't help but ask my self why are we doing this to begin with? Are there really that many people out there that need closures in Java to warrant tacking it onto the language after the fact? I don't know about anyone else, but I've managed just fine without them so far, so Java's not broken in any way without them.

If we keep going in this direction with Java - tacking on more features that are better implemented in other languages - eventually we'll end up with a tool that nobody can use.

Then what will I do when I need a screwdriver?

Mr. Yegge meets Mr. Brooks

2007-12-21T10:19:00.000-05:00

What does a high-level language accomplish? It frees a program from much of its accidental complexity. An abstract program consists of conceptual constructs: operations, datatypes, sequences, and communication. The concrete machine program is concerned with bits, registers, conditions, branches, channels, disks, and such. To the extent that the high-level language embodies the constructs wanted in the abstract program and avoids all lower ones, it eliminates a whole level of complexity that was never inherent in the program at all.

- No Silver Bullet - Fred Brooks

By now everyone out there has probably read, or seen snippets of Stevey's post, Code's Worst Enemy. It's a great post, and I recommend reading it thoroughly if you haven't already.

Of course, there's a lot of people - in the Java community especially - that are probably looking at it as a "Java Sucks" rant, which it certainly seems to be in some ways. For the record, I do think he's a bit harsh toward the Java development community out there: Most Java developers - myself included - know that Java (as well as it's accompanying frameworks and tools) can make a software system unnecessarily complex. The problem is we're not much in a position to do anything about it. I'd love to be using a language like Ruby or Python that mitigate this. Hell, I'd love to be able to use Lisp on a project, but I'd be flogged for trying to in my current position

It's not all the community's fault, ya know.

But, Java ranting aside, what Steve's (rather long) post is really about is dealing with complexity - more specifically, accidental complexity. If you don't know what accidental complexity is, go follow that link on the last sentence and come back. Or, better yet, go read The Mythical Man-Month. Either way you'll be a better developer if you know what the heck it is. Trust me.

There's a good example of the accidental complexity issue in this post on Raganwald.

The Java language does have it's fair share of accidental complexity. Nevertheless, the industry made the big transition to Java because it removed some accidental complexities that other languages, such as C++, had. A good example is memory management: Java removed this problem from the programmer's mind (not completely, but enough that we don't have to actively think about it) so that he or she can focus on solving the core problems at hand.

What we're seeing now is that, as Java gets thrown at more and more complex problems, the flaws in the language are becoming more apparent: The accidental complexity of the language itself is getting mixed up in the essential complexity of the systems being developed. There are also new problems that have arisen as a result of the Internet and Web development that weren't known (or at least, not readily addressed) at the time of Java's inception. The result is that these problems are dealt with via complicated frameworks for Java (which add to the accidental complexity of a system, causing code base "bloat"), but in much simpler ways in other languages like Ruby.

This is also a reason why we see discussions about new languages constructs in Java like closures: People are trying to find ways to solve these accidental complexity issues in the language, without having to retool entire code bases in a new language.

But ultimately, we're looking at a situation now where developers are looking for better ways to solve the really complex problems out there and aren't finding a viable option. The industry is ripe for a new language to step in a take over the reins from Java, removing another bit of accidental complexity from our lives and allowing us to focus our minds just a little bit more on the problems we're trying to solve.

The sooner, the better.

update 01/03/08: Little slow noticing (took a long holiday break), but I got a link from Raganwald. That's usually a sign that you've written something intelligent (or at least interesting). I didn't think I had it in me :-).

Belated thanks to Mr. Braithewaite for the link.