Wednesday, June 20, 2007

Another IBM Article

It's not exactly part five of the four part GWT series, but it is closely related. Please check out my newest article on IBM Developerworks: Simplify Ajax development using Cypal Studio for GWT.

I actually wrote this a few months ago, when the tool was still called Googlipse, and the final publication was delayed a bit while I rechecked all the code and instructions, and changed the name throughout.

One note: it seems as though the GWT 1.4 release candidates do not currently work with Cypal -- you have to use the GWT 1.3 version.

Enjoy.

Thursday, June 14, 2007

Didn't I Say I Wouldn't Compare Languages?

I posted a version of this to JJ Behrens' Blog post about Ruby, and decided it was probably worth also posting here.

I use and like both Ruby and Python, here's why...

Things I like about Ruby with respect to Python



  1. I think Ruby is the only language that gets accessors right. The thing you want to do 95% of the time -- simple access -- is trivial, and the thing you want to do 5% -- something fancy in your accessor -- of the time is a pretty easy override. Plus, it's nicely encapsulated, and you never have to wonder if that thing in another class is accessed directly or via a method.

  2. Blocks. I find that my kind of functional style flows pretty easily in Ruby. It's also not hard to pass named functions. When I first started with Ruby, it used to bother me that you couldn't tell from a method signature if it took a block, but I've since managed to deal.

  3. Being able to add method to existing classes. Although I know this really bugs some people, sometimes adding a method to String cleans up the code significantly.

  4. Expression-based syntax. The implicit return in Python always causes me at least one error per sessions. Plus I like writing a ternary operator as an actual if statement.



Things I like about Python with respect to Ruby



  1. Consistency. Python enforces it. As a result, my Python code is more likely to be readable by me six months later. Ruby tends to be more concise, but some parts of Ruby are still a little too Perlish...

  2. Real keyword arguments (coming to Ruby soon). The Ruby syntax magic of gathering up map pairs into a hash is sort of annoying.

  3. I find Python's multiple inheritance mechanism to be easier to understand then the Ruby package/module setup. It always seems like I'm messing up the difference between 'require' and 'include'...

  4. On balance, I prefer Python immutable strings to Ruby's mutable string/symbol split.

Monday, June 11, 2007

WWDC Keynote, 2007

I think I'll have to join in the general chorus of the underwhelmed. Bullet points:

  • The new desktop and finder sure look shiny. The dock stacks do look kind of useful, and having a dedicated downloads folder strikes me as a classic kind of Apple UI move.

  • Having the finder be visually similar to iTunes strikes me as, on balance, a good idea. And, although I don't find Cover Flow tremendously useful in iTunes, I can see a place for it in the Finder. Especially if you can page through PDF files and other similar tricks.

  • I don't think the power-user critics of the Finder are going to be much impressed, though. For one thing, no tabs. (Come to think of it, I'd like tabs in iTunes, too...)

  • It was really weird to see so much time spent on features that have already been demoed and known for a year. I was definitely hoping for more new stuff.

  • Core Animation looks really cool, and if it's half as easy to use as advertised, there's going to some very pretty Mac apps coming down the road.

  • Safari for Windows, which initially sounded kind of weird, actually makes sense to me. It's probably not a very large development effort, and anything that makes Safari more valuable as a development platform for web developers makes Safari more useful, and by extension, the Mac platform more useful.

  • I did not have good luck with the Safari betas, though. Windows side, the beta crashes when I try to set my proxy. Mac side, the address bar doesn't do anything when you enter an address. Worse, it broke the nightly WebKit builds that I've been increasingly using as my primary browser, so I had to uninstall.

  • As far as I can tell, developers seem to be downright irritated by the non-SDK announcement for the iPhone. The thing that's not clear to me is whether the webapps would have any hooks at all into the iPhone OS -- at least one of the liveblogs I was following on made it seem like there'd be some nod to tighter integration that a typical web app. Anybody else get that? Because otherwise, to go up and make the big announcement that the web, you know, still works even on an iPhone, that's just strange.

  • They placed the iPhone announcement for 6PM, which feels more humane than making people stand in line for a 9AM open

  • A lot of notable non-mentions: ZFS, iLife, iWork, any hardware, resolution independence, and so on...


Saturday, June 09, 2007

Programming Perl, Personal Edition

Due to circumstances somewhat beyond my control, I find myself working in the largest Perl project I've ever done. Now, I'm not in the least interested in a "my language is better than your language" deal because a) this strikes me as very well covered territory, and b) it seems particularly pointless as the Perl 6 team appears to be doing a nice job of taming Perl's more rococo features.

There are, of course, some things I did want to mention...

  • I'd be totally lost without the very large assistance of Damian Conway's Perl Best Practices book. It's an excellent guide to the minefield of all the things Perl lets you do, pointing you to the things you actually should do (especially on a large program). It's also refreshing to see a Perl book that doesn't treat the ability to write unreadable code as some kind of rite of passage or inalienable right.

  • I didn't actually intend to use all three homonyms of "write" in that last sentence, but I think I'll leave it in...

  • As a result of reading Conway's book, and somewhat in self-defence against my own Perl skills, I seem to be writing the most verbose Perl in the history of the known universe. I think I may have written more compact Java.

  • This is also the first time I've worked this closely with a code-tidy utility, and I think I like it. Usually, I advise against doing things like lining up equal signs because it's too much work to maintain, but with perl tidy, that's not an issue, and it is more readable.

  • Perl's cultural insistence on using plain non-jargon words is usually kind of charming, and only occasionally irritating (quick, rank "carp", "cluck", and "croak" in order of severity...)

  • My most consistent error to date? Forgetting to dereference the argument to grep or map, which I've been doing at the rate of about twice a day for the past two weeks. Since the reference gets promoted to a single-element array, this is a little annoying to track down. Luckily, unit tests were designed for this kind of thing...

  • I wanted to quick mention a couple of formatting things that Conway recommends in his book that I've never seen in other language's style guides (maybe I should get out more...). First is the "cuddled else", which is the placement of an else line on the same line as both the close of the if block and the start of it's block: } else {. A quick google on the phrase confirms that it's mostly a Perl thing -- I've never seen a non-Perl style guide comment on this. Conway, and I see that he seems not to be alone in the Perl world, recommends dropping the else to the next line. The idea being that it's more visually clear because the else is now in line with it's close bracket just like any other block. I had always thought that the Java/C style was there to visually connect the else to the if that had just closed.

  • Conway also recommends breaking up long lines before the operator, rather than right after an operator. I'm reasonably sure that's different from almost any other style guide I've ever seen, but I have to say, it works for me. The idea is that you are more likely to see the visual cue that the line is a continuation if the hanging operator is at the very left of a line rather than the right. I think it's working for me partially because the split lines look so weird to me that I look more closely to see what's going on. Whatever the reason, it does seem to be making the code more readable for me.

Sunday, June 03, 2007

iTunes Plus... A Fresh Lemony Scent, Perhaps?

Couple thoughts on Apple's first foray into the brave world of non-DRM'd music:

  • I think the most of the user experience in iTunes is handled nicely. There had been some worry about this -- I seem to recall some speculation before the EMI announcement that Apple would only take out DRM if they could do it store-wide, and keep things simple. Anyway, the iTunes Plus branding and the simple option to either always or never see the plus songs seems to work just fine.


  • That said, it's very odd that the upgrade songs feature does not allow you to select individual albums or tracks -- it's all or nothing. That's not a good user experience.


  • I'm a little surprised by the album upgrade, as well. Since they seem to have mostly held the line on the $9.99 album even for Plus albums, it's not completely clear to me why I have to spend $3.00 to upgrade my old $9.99 album to a new $9.99 album.


  • I do hear some difference in sound quality on the new tracks. Granted that a) I know that there's supposed to be a difference, b) I have really cheap sound equipment and c) not exactly professional-quality audiophile ears. Even so, it seemed to me that sharp sounds like percussion and acoustic guitar seem to pop out of the background a little more. The effect is more obvious in my car than on my cheap headphones. Go figure.


  • The big controversy, of course, is the fact that account information is still embedded in the non-DRM files. (Unless I'm mistaken, that information was in the DRM files, so before we get all conspiracy theory we should at least consider the possibility that it was either overlooked, or a pain to remove for some reason). I was amused to see two different blogs where the blogger breathlessly posted this dastardly information only to have commenter after commenter say it isn't that big a deal. Which it isn't — it's not like Apple removing DRM from the music somehow changed copyright law... I'll grant that it's always a little creepy to find a personal infobit somewhere you don't expect it, but I'm having a hard time getting worked up over it, especially since I expect it'll be fully hacked by the time I finish typing this sentence.