Sunday, December 30, 2007

Professional Rails Online?

In response to the commenter who asked if there was going to be a beta book.

UPDATE: Clearly I should ask about these things before I post. Jim Minatel from Wrox added the following in comments:

  • There will be a PDF about six weeks after the print book, meaning end of March or thereabouts. There will also be an Amazon Kindle version, eventually.

  • Also after 6 weeks, the book will be available via Wrox's online subscription service: http://wrox.books24x7.com.

  • It won't be on Safari, apparently Wrox books aren't part of the deal there (which I actually was kind of wondering about). Meaning I still haven't placed a book there)

I now return you to my earlier, ill-informed, blather...

Unfortunately, I'm pretty sure the answer is no. Not only doesn't Wrox tend to do that kind of thing, at this point, the book is do to go to press in about two weeks, so the amount of time to get feedback would be sharply limited.

At one point, I was told that sample chapters would be available online before release, but I don't have any information on whether there will be an e-book available. I don't think there will be a direct purchase of a PDF, but it seems as though Wiley just joined the Safari book store, and the book might be available there. I'll try and find out for sure this week.

Tuesday, December 25, 2007

Another Publication Update

Just got the next version of the book chapters for my examination. I'm not 100% sure exactly where these fit in the process. It looks like they've had a good look-see from a copyeditor, largely for style, clarity, and consistency. (Any lingering "we" sentences seem to have been pruned, for example).

They produced a book-specific style guide, which is a listing of canonical forms for things like plugin names, capitalization of commands or tools and the like. It's kind of interesting to see if I can remember where each name or command was used.

Anyway, I'm supposed to have these turned around by Jan 2, so I'm reasonably sure we're still good to go to press in mid-January, and be released in mid-February.

Sunday, December 09, 2007

Things I Learned

Some things I learned about Rails and writing while working on this book:

  • The great benefit of working on a project like this book is that it enabled me to compress about two years worth of research into Ruby and Rails tools into six months. In my case, this was a great opportunity to really dig into some tools to find that I've only been using a fraction of their power and also really get a sense of how elegant and flexible the tools are.

  • Ever since I learned how to type back on an actual typewriter in the mid 80s, I've always followed the old-time typographical convention of two spaces following a period. Which was burned into my fingers despite multiple people telling me that was a silly and counterproductive thing to do in the brave new world of proportional fonts. In fact, on the wx book, I actually did a global search and replace for a period followed by two spaces to get the manuscript to correspond with the publisher's expected conventions. Somehow, I managed to break that habit while writing this book.

  • The hardest stylistic thing for me to get around was avoiding using "we" and "us". In other books and articles, I tend to introduce examples by saying things like "Now we should type the following" or "Let's see how that's implemented". Wiley/Wrox house style, though is to avoid "we" and write the examples as "Now you should type the following" or "I'll show you how that's implemented". Even more preferred is avoiding the pronoun altogether with "Here's how that's implemented" or "type the following". I'm not saying one way is better or worse -- I find the "we" style to be conversational, the Wiley editors clearly disagree. It did take some getting used to, though.

Thursday, November 29, 2007

We're In Production Now...

I turned in the last chapter of Author Review on Monday, and Professional Ruby On Rails is now in production. Target release date is still mid-February, final page count will be in the range of 450.

I was able to keep the test-first nature of the code going through nearly all of it, which I'm really happy with.

The table of contents looks something like this (in theory, still subject to change...)

Chapter 1: Setting up a new Rails project using REST

Chapter 2: Using Subversion on a Rails project

Chapter 3: Users, secure logins, email authorization, etc...

Chapter 4: Rake, writing build tasks, and using CruiseControl.rb

Chapter 5: Navigation elements, including menus, tagging, search, and pagination

Chapter 6: Database topics, including legacy databases, relationships, and security

Chapter 7: Testing tools: RCov, RSpec, ways to test views and helpers, and so on.

Chapter 8: Rails and JavaScript. Using Rails and Ajax plugins for some common tasks. RJS. Testing RJS.

Chapter 9: ActiveResource, generating and reading XML data, including RSS feeds

Chapter 10: Time and Space. Managing time and time zones, using Globalize for internationalization

Chapter 11: RMagick, ImageMagick, MiniMagick, and other graphic tools. Gruff and Sparkline charts.

Chapter 12: Deployment with Capistrano and Mongrel

Chapter 13: Performance benchmarking and optimization

Chapter 14: Using Ruby metaprogramming in your Rails application

Chapter 15: Using and creating plugins. Testing plugins and generators

Chapter 16: ERB replacements and JRuby

Appendix A: Things to download

Appendix B: Other tools inspired by or similar to Rails

Two Pathfinder Blog Posts

Two things on the Pathfinder blog.

  • Agile Publishing, on publishing experiences and agile methods.

  • Live Ruby: Testbed, an attempt to work through a small test and metaprogramming problem live and on the blog.

Enjoy.s

Saturday, November 10, 2007

Heads Up

Wow, I haven't been here for a while. Sorry about that. Here's the deal...

The Rails book initial draft went in about a week ago, more or less on time. (Well, on time for a slightly revised schedule). My understanding of the current schedule is that the author review phase will continue through November. After that, it goes to production, where I get another crack at revising thing that have changed. It goes to press toward the end of January for publication mid-February. If everything continues smoothly.

I'm pretty happy with how it turned out. I think I said almost everything I was hoping to. The main constraint was the tight schedule -- I'm hoping to get some newer features and plugins in during author review.

Oh, and I had another Pathfinder blog entry a few weeks ago. This one is about the CDBaby Rails/PHP thing that was kind of a flap way back then.

That's all for now, I'll try to get back updating the Twitter feed and get back to writing here and on the Pathfinder blog more regularly... Thanks.

Monday, September 24, 2007

Quick Book Update

Couple quick things while I have a minute...

  • Just turned in Chapter 10 (of 16) of the Rails book. Still mostly on schedule for a turn in on October 26, not quite sure what that implies for a print date

  • As I write this, the wxPython book is at 11 thousand and change on Amazon, the highest I've seen in months, which is probably a fluke. Weirdly Amazon says it's the #15 book on "Website Architecture & Usability", which would be great if it was, you know, actually about website architecture usability...

  • New article up on the Pathfinder blog. This one is about Rails RJS templates and how to test them. It's partially a book preview, but really only an overlap of subject mat

There's more, but I'll get it when I have a chance.

Monday, September 10, 2007

Apple Fanboy Stuff

Naturally, I did have a thought or two about the new Apple products and the other announcements this week:

  • While I certainly understand why somebody who had purchased an iPhone early would be annoyed by the price cut, I did find it kind of funny that many of the same analysts who said the iPhone would never sell at its original price were then jumping on Apple for dropping the price.

  • Every now and then, you'll see an economist writing about how online stores should do more variable pricing -- charging a premium price to customers who are more willing to pay it. This week should be an object lesson in why companies don't do that. Since the people who are willing to pay more are usually your best customers, you run the risk of really ticking them off by making them feel like chumps. Which is generally not considered a good business strategy, I hear.

  • My read on the price cut is that it comes from three factors:

    1. To keep the price in line with the new iPods, particularly the iPod touch.

    2. Taking advantage of lowered manufacturing costs since they are now making more of the touchscreens.

    3. Really try to drive sales this quarter to take advantage of what Apple perceives as a key moment -- not so much that sales have been disappointing, but that the really are trying to seize the moment.

  • It could work, although the analogy to Motorola's strategy with the RAZR (gain market share at the expense of profits) is a little disquieting. On the other hand, Apple has a lot of benefits that Moto's cell division didn't, but it's probably not a good idea for me to list them...

  • As for the products themselves, they seem pretty cool. Like just about everybody, I wish they had merged the two iPod models and combined a hard drive with the touch screen. I need to see what the iPod Touch reviews look like in a couple of weeks. It is annoying that Apple seems to have made video out a proprietary cable.

Saturday, September 08, 2007

Boring Software Manifesto

Another blog post up on the Pathfinder site. This one is about Agile in general, and features what I think is the World Blog Premiere of the soon to be famous Boring Software Manifesto.

Enjoy.

Thursday, August 30, 2007

The Rails Edge

I was fortunate enough to attend Pragmatic's Rails Edge mini-conference here in Chicago last week. I have two blog posts up on this at Pathfinder, the first is made up of quotes from my notebook, and the second is some general thoughts. Enjoy.

Pro Rails Book Related Things

A few things I forgot to put in the last book update:

  • The Amazon listing has the book at 600 pages. That's almost certainly optimistic. The contract calls for 400-500.

  • As far as the schedule goes, I'm currently hoping to turn the complete draft in on October 26th, which is about ten days after the original date. The publisher says that pushes publication out to April, six to eight weeks after the original date. I don't quite understand the math, but I suspect that it has to do with the logistics of availability of printing equipment and the like.

  • Chapter Seven appears to be on track to be delivered this week, which makes the book just a smidge less than halfway done.

Monday, August 20, 2007

More On Test-Driven Development

My first post to one of Pathfinder's official blogs is up, it's a companion piece to the blog post here on Test-Driven Development, and you can find it here.

Sunday, August 19, 2007

Book Update

Here's a couple notes on the current status of the Rails book and life in general.

  • The Rails book is presently just about 30% done -- first payment triggered (yay!). I'm reasonably happy about it so far, though definitely too close to it at the moment to have a clear sense of its quality. I do like the way the test integration is working out -- it seems to help my descriptions of functionality to have the tests there.


  • The book is now available for preorder on Amazon. Here's the 10 print "hello" affiliate link, which will conveniently linger in the sidebar of this blog forever.


  • I don't think I ever mentioned this, but the last results I got on the wxPython book (for Q1 2007), showed that sales were starting to slump. Although the data was weird -- US sales were down to about 1/3 of the previous quarter, and US returns were way up, such that net sales were almost zero. At the same time, international sales were way up, with the total affect being a drop to about 1/2 or slightly less from the previous quarter. We've now passed the 6700 mark in total sales.


  • Apple fanboy stuff: One of the nice features of my new job is that my work computer is now a MacBook Pro. Very nice machine, well designed, very fast. Battery life is decent. Lots of the little design details you've come to expect -- I particularly like the magnetic power cord. Now if only I could use the thing without wearing oven mitts, I think I'd be in business.

Monday, August 13, 2007

And Now, A Special Announcement

Sorry for the radio silence for the last week or so, but I was waiting to be able to announce this:

Today I started a new job at Pathfinder Associates, as a senior software engineer in charge of Ruby on Rails projects. Needless to say, I'm thrilled to be back in the Web game professionally, and even more thrilled to be working on Rails projects.

Everybody at Pathfinder has been super great so far, and I'm looking forward to doing exciting and fun things.

I'll also be blogging on their web site roughly once a week, either at their Technical Development blog or their Agile/Ajax blog.

If you happen to be one of the maybe five people who read this blog regularly, don't worry, I'll continue to post here with updates about the book and thoughts about programming and technical publishing that wouldn't quite fit on the Pathfinder site.

Friday, July 27, 2007

A Customer!

Well, that's a pleasant surprise. Somebody named Stephen has left a comment. And not one of those spam thingies, but some actual relevant questions about tech publishing. Answering them seemed like it might be fun..

1. I noticed there is a pdf version available of your books. Is this something you or the publisher insisted on? Have people shown an interest for this version or are they still overwhelmingly favouring the hard copy? Aren't you or the publisher afraid that the pdf will end up on shady torrents?


I honestly don't remember an explicit decision being made over whether or not an e-book edition would exist. As far back as I can remember, they wanted one and we wanted one, so no problem. I'd imagine that the publisher's wishes would override the author's in this respect if it came down to it.

I don't have the Manning contract for the wxPython book in front of me, but the Wiley contract for the Pro Rails book says "the Publisher shall publish the Work in such style and manner as the Publisher deems appropriate", and I think the Manning contract had similar language.

I'm in favor of offering e-books because they are easy to store, easy to update, and easy to search. From the publisher's standpoint, they have a relatively low cost to produce and people want to buy them, so it's a potentially large win.

As of the most recent statement I have on the wxPython book, e-book sales are just under 10% of total sales. I suspect that some publishers have much higher percentages -- Pragmatic, for example, really promotes their e-book sales. The Jython book is not available for sale in an e-book form, not even on O'Reilly's Safari Bookshelf. Which is weird, because they (at least used to) offer a competitors Jython book on there...

While I'm on the subject, I don't know right now if the Pro Rails book will be available via pdf. Wrox doesn't seem to do pdf much, and I don't know if they plan on starting.

Funny you should mention torrents, because I relatively recently got an email from Manning that they were trying to get the book removed from a torrent site. So I know it is, or at least has been, out there. I'd say Manning takes this kind of thing pretty seriously, but it obviously hasn't stopped them from providing pdf files. So far, I haven't seen any evidence that this kind of thing is affecting sales, and I'd be very surprised if such evidence presents itself. (Standard Disclaimer -- I don't speak for Manning, and I don't speak for Robin Dunn. If you broadcast a torrent of the book Manning will try and stop you.)

2. Technical books typically have a short shelf life and would probably benefit from frequent updates (e.g. incorporation of errata, version updates etc.). Wouldn't a more flexible way of publishing, with small, frequent runs (or even an outright on demand model a-la-Lulu) be better?


Yes, I could see where having small, frequent updates could be better for the book reader -- this is essentially what Pragmatic does with their e-books.

However, the infrastructure and overhead for doing this in printed books would be pretty significant, even with some kind of publish on demand model. At the very least, the cost to print a copy would go up, probably dramatically. Then you have the secondary problems of managing which errata went into which revision, continually updating the layout when needed, dealing with people who want printed books upgraded. The headaches get big quickly.

That said, something along that model is inevitable, at least for e-books. Eventually, other publishers will have processes as streamlined for this kind of thing as Pragmatic seems to.

This concludes todays episode of Ask A Guy Who Once Wrote A Book. Tune in next time. I hope there's a next time...

Thursday, July 19, 2007

A Little Birdie Told Me

In the interests of being able to push out quick updates on the book's progress, I've created a Twitter account for the book. You can follow that account on the sidebar of this here blog, or at http://twitter.com/noelrappinbook -- there's also an RSS feed.

Please remember that any and all information about the book is subject to change at whim. Enjoy.

Book Updates

It's been about a week or so of continued radio silence, so I thought I'd pop in with an update.

I'm in the middle of chapter three of the Rails book. I think it's going well, but nobody other then me has read the chapters yet, so that's easy to say. My first milestone date is the end of the month, and four chapters done -- that's about one-quarter of the entire book.

I did want to say a few things about how somebody like me comes to be writing a book like this. I was first contacted with this idea in early February. If you're keeping score, that means that this project spent about five months going from a gleam in an editors eye to a signed contract, and it will spend about five months going from a manuscript to a printed book, but only about four months for me to actually spend on the writing.

Anyway, I have an agency (Studio B) that represents me for technical writing. Sometime in early February, I received an email from them saying that an unnamed major publisher was looking for a writer for a Rails book, and was I interested. I don't know exactly what happened between the agency and the publisher before that, but Studio B is often approached by publishers looking to match an author with a topic.

I was very interested -- I'd been kind of hoping to do a book on Rails for some time. I talked to an editor at Wiley about what kinds of things they were hoping for and put together a proposal. At the same time, they also expressed interest in a proposal on a different topic, and I did that as well. The proposal contains a description of the market for the book, and a description of the outline. The goal is to convince the publisher that the book is worth doing, and that the author is a good person for the job. In this case, since the publisher had initiated the process, making the case for the book was easier than it might otherwise have been.

The publisher liked the proposal. But if you were wondering who pays attention to Amazon reviews, I was specifically asked about the difference between the ratings for the Jython book versus the wxPython book, to reassure them that the higher ratings for the wx book were not solely due to the co-author.

After that, there was some time spent waiting on the two proposals, and which one the publisher wanted to do. At various times, all four possible answers were given (the Rails book, the other book, both, and neither). Eventually, they settled on doing the Rails book. I was informed of that decision in early May, and then my agent and the publisher began negotiating over contract details. I don't think I can really say much about that, but most of the time is not spent on money, but rather on details of which side is responsible for various parts of the finished product beyond the text itself, and who is liable for what if things go wrong (hint: the author is usually liable...) We also settled the length of the book and the schedule.

Oh, and you know the author pictures that appear on the cover of a Wrox book? Rest assured that the pictures are one very well covered topic in the Wiley/Wrox contract.

And that's how a bill becomes a law. I'm enjoying working for Wiley so far, the people I've dealt with have been enthusiastic and helpful. Now, I think this is long enough and I should probably get back to the book itself...

Tuesday, July 10, 2007

Announcing: Professional Ruby on Rails

I'm pleased to be able to say that I've contracted for a new book, Professional Ruby on Rails, scheduled to be available in "early 2008", hopefully February or March. The publisher is Wiley, through the Wrox imprint -- the ones with the red covers and the author's picture on them. Wiley wanted me to be sure and mention that the ISBN number is 9780470223888, so you'll be ready to pre-order it the second that becomes possible.

The imagined reader of the book is somebody who just finished a beginners book on Rails and is suddenly asked to build a complete public web application. The idea is to cover the kinds of topics that nearly every Rails site will deal with -- things like users and security, performance, deployment, navigation, team development. For each topic, I'll be discussing common solutions, existing tools, emerging standards and so on. There will also be a strong focus on writing tests throughout the book. Hopefully, I'll be able to go into more detail as more of the book is written.

I'm excited and scared. This is my first solo book, which both simplifies logistics and leaves me without a co-author to catch me when I'm totally off base. I know Rails pretty well, but there's nothing like facing a skeleton book outline to impress upon you exactly how much you don't yet know. Research has been lots of fun, though -- the Rails online community is fantastic.

Watch this space for more info about the book, the writing process, and anything else related. If you have a question, or if there's a specific feature that you think should be included, please do leave a comment or send me an email.

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.


Wednesday, May 30, 2007

Text Auditor

I hate Microsoft Word. I feel that I came by this rightfully, after a whole book's worth of numbered lists that refused to line up, images that refused to stay put, and the truly irritating indexing interface.

For a long time I'd sort of rant about how word processing was this core user task and we still couldn't figure out the right UI for it. I'm not totally backing off that, although I've also read people ranting that text editing was solved 20 years ago by Emacs and Vi, and there's no point in looking at anything new, which achieves a level of crankiness that makes me look calm.

What occurred to me as I was thinking about writing about text entry and UI was the sheer number of different programs that I use for various kinds of word processing or text editing. Most of these are optimized for a specific set of activities, and do that particular job well enough that it's worth learning a new program in order to get that benefit.

More and more, I find myself also using tools that help me with text cross-applications, like generic text expansion tools, or clipboard history tools, or even monster aggregators like Quicksilver. Put that way, it sounds a little bit like the OpenDoc dream, where your spell checker would come from one place, and your text editor from another, and the font manager in from another. But OpenDoc was about components instead of applications and looking at the list below, it's pretty clear that applications aren't going away anytime soon...

So here's a list of all the apps I can think of that I do some kind of text edit in, with some comments.

Adium/Pidgin -- IM Clients (Adium Mac side, Pidgin in Windows, plus another couple for internal work things). None of these has a ton of text editing support, although I do wind up typing a fair amount of text into them over the course of day. Pidgin has a great name, but I really wish it had one piece of AIM functionality, namely the ability to read text in a different size then you send it.

Eclipse -- Currently it's my Windows side Ruby/Rails editor of choice, although I'll probably change my mind six more times before I settle on something. It's also my Windows Perl editor of choice, as it seems to be the only free editor that does syntax checking.

GMail/Google Docs -- Gmail, obviously, used for email, although I do sometimes use it as quick storage for text I want to be able to work on from multiple locations. You're supposed to use Google Docs for that kind of thing, and I do, sometimes. It's great for collaborating (we used it for final notes on the manuscript for the wx book, for example). But for normal use, it's just a hair too unresponsive, and the UI is just a touch awkward within the browser.

IntelliJ IDEA -- Java editor of choice. Still the most fully featured of the big Java IDE's, although the other's are catching up. A big memory hog, though.

jEdit -- Window's side default text editor, especially for Python. Been using it for years. Very nice feature set, I'm used to the controls, decent syntax coding for the languages I use.

Jer's Novel Writer -- I don't use this as much as I'd like, but I'm putting it in here as a great example of tuning a text entry program to a specific use. In this case, writing fiction. Nice features include easy annotating and the ability to specify separate display and printing formats -- very useful for keeping your print document in manuscript format.

MarsEdit -- Well, I'm writing this post in it. Mac side editor of choice for blog posts. Why did I spend $25 on this when it's functionality is pretty easily replicated from TextMate? Good question. It's got a very clean UI, and I like that it previews while you type. And if I need to do something fancy, it interfaces with TextMate.

MS Word -- Windows word processor when forced to use it. Word actually isn't that that bad if you stay within the confines of a four-page office memo. Once you add styles, though, it's a mess. Actually, I don't think anybody's really solved the UI for a WYSWIG styles system -- which is one reason why I use HTML, Textile, or Markdown where I can. I feel like I have much greater control over the styling if it's all in text.

NeoOffice -- Mac side word processor of choice, although I rarely use it for the reasons given above. I've gone through all the free or free-to-try alternative word processors on the Mac, and NeoOffice is the one I keep coming back to (especially since the newest version, which fixed some performance issues).

Outlook -- Windows email program. Possibly the worst styled text email editor around. I think it's the only one that, if you insert a paragraph in the middle of a quote from a previous email, keeps the quote formatting on your new text. This is, shall we say, not helpful.

PowerPoint -- I guess it's a text editor, of sorts. This is here mostly for a mini-rant... I know that everybody says that effective presentations should have minimal text on each slide. I even agree. But... in many environments, including lectures and a lot of corporate situations, the slides become a de facto deliverable to people who are unable to make the original meeting. If you don't have enough text for those people to follow along, they will get angry...

TextMate -- Mac side programmer editor of choice. I tried a number of different editors when I switched to Mac and realized that jEdit didn't really play nicely with OS X. I find the TextMate UI to be unusually clean, and it's the most powerful and extensible text editor not written in Lisp.

VoodooPad Lite -- Mac desktop Wiki application. I'd probably use this more if my daily work were Mac side. It's very nicely done.

That's a lot of applications. I'm pretty sure I missed some, at that. I think my point is that specialization is the way to solve the text UI dilemma. Still, needing 13+ apps to solve my basic text entry needs.... seems less than optimal somehow.

Monday, May 28, 2007

A Program Note

This is for the two or three of you that are subscribed to this blog via RSS feed -- I've just added a FeedBurner feed, and if it's not too much trouble, it'd be great if you could switch over to it at:

http://feeds.feedburner.com/10Printhello.

The "Subscribe" link in the sidebar will also work.

Thanks.

Friday, May 25, 2007

An Agile Musing

Of course, since I muse in an agile way, I reserve the right to change my mind based on future developments...

Software development usually takes place in a complex environment where your goal can change quickly. In general, there are two ways to deal with a complex environment. One is to try to anticipate, in advance, every possible permutation you might need to deal with, and the other is to manage your environment with the flexibility to respond to new challenges with minimum effort. Software is just a specific case where that challenge plays out.

Of course, being software engineers, we've given these approaches names. They are nicely defined by James Bach:

agile methodology: a system of methods designed to minimize the cost of change, especially in a context where important facts emerge late in a project, or where we are obliged to adapt to important uncontrolled factors.

A non-agile methodology, by comparison, is one that seeks to achieve efficiency by anticipating, controlling, or eliminating variables so as to eliminate the need for changes and associated costs of changing.


It seems worth pointing out that, at least in theory, there's no reason why you can't both make a reasonable effort to find potential changes up front, and still make your working environment as flexible as possible.

In practice, of course, this is kind of difficult to do well. There's a logistics problem -- the kinds of things you do when you're trying to control change up front generally involve creating a lot of models and documentation and the like. This is exactly the kind of thing that works against minimizing the cost of change. But it seems to me that a group determined to do some up front analysis of what will largely be an agile process could manage to work around that.

The bigger problem is an issue of mindset -- if you think that you can solve all your design problems up front, then you start to look at any change to the design or implementation with suspicion. At that point, any change is, by definition, a mistake of some kind. Which leads to suspicion of all changes and can mean all kinds of tracking and procedural overhead that pushes up the cost of change. The sort of organic, bottom-up design that you get from test-first and tight iterations doesn't fit in this model at all.

Although I should say that in my experience trying to get groups to adopt XP or agile practices over several different companies is that nearly all programmers and managers agree that automated tests are a good thing. Most programmers are at least willing to consider the idea of test-first, although getting somebody to do it consistently is tough (hey, it's tough even for somebody who's totally bought into it).

The resistance I do get tends to be around the idea that you can start programming with an incomplete design without it leading to disaster.

Waterfall-style up front design can be incredibly seductive. You're brainstorming with other smart people, you're solving all your problems before they even come up. It certainly feels like you are doing something vitally important to the success of your project. Even if you know that many of the decisions will later be revised in implementation, it still feels good to have that crisp UML diagram. You can't have bugs in a UML diagram. The issues that do get solved in design are assumed to justify the time cost of the design, because the assumption is that the time cost of later improvements will be much larger (which is true, in part, because of the amount of design work).

In contrast, starting coding with incomplete information can feel risky, especially the further you get from the actual implementation team. Any issue that gets changed later can be blamed on the relative lack of design, true or not, and the time savings from not doing as much design can be invisible. It's very hard to let go of the idea that all your design problems can be solved up front. But once you are willing to allow that some problems can only be solved in the moment, you're much better equipped to deal with the inevitability of change.

Wednesday, May 16, 2007

State of the Art

O'Reilly Radar has been analyzing the state of the computer book market on a quarterly basis for a couple of years now.

This link is to a drill-down into the Q1 2007 results for programming languages. The information is of some passing interest to me, both as an author and as language geek.

Things that jumped out at me.

  • Ruby is up a ton, and is now selling more than Perl and Python combined. There are now as many Ruby books in print as there are Python books.


  • Two of the top five books are Rails, with number one being PragProg's Agile Web Development with Rails. Two of the remaining five are Head First books.


  • But Javascript sells almost twice as many books as Ruby, and is also growing quite a bit. I still see the occasional thought that Javascript will escape the browser and become the language of the future. It certainly seems to be gathering the base.


  • The numbers have just under 10,000 Python books sold in Q1 2007. I don't have the wxPython book numbers for that quarter yet -- results to authors are delayed a quarter, but that means that the wx book was roughly 10% of the overall Python market. I can't decide if that surprises me or not.


  • It's funny how your personal perspective skews expectations. In the abstract, I know there have to be a lot of Microsoft shops out there, but I've never worked at one, so it's surprising to see C# and .NET so high on the list. I'm currently surrounded by a lot of IT Perl experts, so it surprises me a little to see Perl so low, even though it probably shouldn't.

Sunday, May 13, 2007

from internet import *

Three posts that caught my eye today.

Ruby School


Gregory Brown over on O'Reilly net has an article about using Ruby in Computer Science courses, at least in later algorithm classes. It's not a bad argument, but I think it'd be more convincing if the Ruby example was a little cleaner and easier to read compared to the pseudo-code.

Let's see... The last time I had to care about this issue was about eight years ago when my grad institution was going through a somewhat controversial revamp of the CS curriculum. The fight, as always, is between the theorists and the pragmatists. The theorists want to teach a lot of "pure" CS up front -- Turing machines, big "O" analysis, computational theory, that kind of thing. The pragmatists want the students to be able to get jobs.

You should know that I spent the better part of three years as part of a group working with an object-oriented class that we taught in Squeak Smalltalk. Lovely language, to be sure, but we had to spend part of every course explaining to some nervous students why we weren't teaching them C++ or Java...

At the time, the initial CS classes were moving to Java, with some relief. This is because a) nobody wanted to inflict C or C++ on unsuspecting new CS majors, and b) the previous most common language, Pascal, was woefully obsolete. Java is reasonably straightforward to teach and is actually used in real programs, both high points.

Personally, I think you can make a pretty nice case for a scripting language like Python or Ruby in the initial CS class. They are both pretty easy to get started with, the syntax is clean enough that algorithms are easy to visualize (which was Brown's original point). In Python you can do it without introducing objects (which most CS1 classes didn't do eight years ago, don't know if that's changed). In Ruby it's easy to teach meta-programming.

Cha-Ching


Paul Julius of ThoughtWorks about how CruiseControl can save you $12,535 per broken test. The money coming from the difference between the cost of fixing a bug immediately versus not catching the bug until integration testing.

I dunno. I love continuous integration, and would shout about it from the rooftops if they'd let me on the roof, and that number still sounds a bit more "look what I can do with numbers" than "look what I can do with Continuous Integration". But then I'm skeptical of nearly every numerical analysis of programming productivity.

Plus, Marshmallows


Over at Roughly Drafted, Daniel Eran goes on about the smooth, harmonious relationship between Apple and Sun. Naturally, I want to talk about one of his sidebars...

The name of Apple's Mac OS X frameworks was even named Cocoa in part to associate it with Sun's Java. The other reason was that Apple already owned the Cocoa trademark, having using it earlier for a children's programing environment.


You know, I've always wondered about that. The original Cocoa was a project that was being worked on in Apple's Advanced Technology Group the summer I interned there, plus it some buzz in Educational Technology circles for a while. Internally, it was called KidSim, but the name was changed to Cocoa when it was being prepared for release. Java was programming for grown-ups, so Cocoa was programming for kids. It seems like Apple isn't really using that connotation of the name anymore.

The project (now called Stagecast Creator) is a graphical rule-based programming language, something like a cellular automata program. The user specifies an initial arraignment of sprites on the screen, then specifies how that arrangement should change in the new time slice. Complex programs could be created with almost no typing (although, like all such programs, you still had to use drawing tools to create your own sprites -- that was still hard). Stagecast still seems to be around, although it's been ages since I tried the software. It was pretty cool, though.

Thursday, May 03, 2007

Comment On This

So the other day I'm looking over some code, and I see this... (slightly paraphrased to protect the innocent -- in the original, the declaration and the getter were, of course, separated.)


/**
* The name of the user
*/
private String m_userName;

/**
* @return The name of the user
*/
public String getUserName() {
return m_userName;
}

And I thought, "I really hope some of that was generated by the editor"

And then I thought, "This is why other languages make fun of Java"

And I finally ended up with, "Most of what beginning programmers are taught about comments is useless". At least that was true when I was in school.

For the moment, I'll put aside the Java issue, to talk more generally about comments.

First though -- we're agreed the example is absurd, right? In that it repeats that the user name is, in fact, the user name five times. Which is at least four more than strictly necessary (I realize that Java more or less forces some of this duplication).

I realize that this is hardly the worst coding sin you can commit, but when I look at code like that I do think that either the programmer isn't quite sure which parts of his code are most important or that the person is rigidly following an overly formal standard. Neither of which is all that flattering.

About 95% of the time, it seems like you either get no comments, or the kind of useless comments in the example. Given the choice, I'd rather have no comments -- it's less distracting, and you can see more code at once.

However, you can do comments effectively. Here's what I think, which should not ever be confused with what I actually do.


  • The best commenting is clear and accurate names for your variables, functions, and classes.


  • The "No Duplication" rule applies to comments at least as much as it does to code.


  • Possibly more, since no compiler is ever going to catch if your comments fall out of sync with your code.


  • Therefore, under normal circumstances, comments should avoid repeating what the code does.


  • However, limitations on input or output values that are not apparent from the code should be included in comments. If the user name was guaranteed to be under ten characters because of the underlying database, that would be a useful comment.


  • Rationales for choosing a particular implementation are often good comments, as is the code's place within the larger program.


  • If you find yourself commenting inline within a long method to explain what the next section does, odds are you'd be better of extracting that to a well-named method and skipping the comment.


  • There is a cost to commenting -- it takes time to do well, and it can be distracting. It also limits the amount of code you can read at once.


  • The most obvious exception to all of the above is when you are in a situation where people will read your comments without ready access to the source code. Writing an API or a framework, for example. In that case, most of the issue about duplication doesn't apply and you need to be descriptive for the benefit of users who will only see your JavaDoc or RDoc.


  • However, none of that excuses writing a one line comment for getUserName().

Monday, April 23, 2007

Fame and Fortune 2

To continue on the fame and fortune theme, I just got the first part of the statement wrapping up the first year of the wxPython book. (Since the book came out at the end of March, we got a first quarter statement which covered the first 10 days of the release). Anyway, I'm pleased. The fourth quarter statement was only about 5% down from the third quarter (I don't have the exact numbers). This is rather amazing to me, since the Jython book dropped about 50% from quarter to quarter over its first year. I think, but am not 100% sure, that the wx book has now outsold the Jython book. If it hasn't now, it will next quarter.

Which makes this a good place to again thank all the people who have bought the book, read the book, and said nice things about the book. It's all appreciated.

Tuesday, April 10, 2007

Fame And Fortune

Well, the Jython Book celebrated it's fifth anniversary with a royalty statement showing that it had sold the grand total of two copies over the previous quarter.

I think it might be played out. O'Reilly's statements don't give total accumulated sales count, just total accumulated royalties. I think it sold just on the low side of 6,000 copies, and is something like 500 short of earning out.

Meantime the wxPython book still seems to be holding it's Amazon rank, so I'm very curious what the next sales total is going to be.

Wednesday, March 28, 2007

Posting to Blogger via Ruby

TextMate has what seems to be a very nice blogging bundle for programmatically sending posts to your blogging engine of choice. Except that it doesn't work for the new Blogger API. Or at least it didn't the last time I checked. Mostly I just wanted to see if I could write my own script to send to Blogger.

This is a Ruby script based on the Python script located at http://djcraven.blogspot.com/2006/10/success-posting-to-blogger-beta-using.html -- the author of that script did the heavy lifting in terms of the GData API calls, what I did was translate it into Ruby in a somewhat more flexible structure. At least I hope so. I also hope this will look like decent, idiomatic Ruby and not like a horrific hack. And I'd like a pony. If you're asking.

Let's do this in pieces. The first piece of the puzzle is using the Google ClientLogin API to get an authentication token. The token is then passed as a parameter to later calls when we actually want to post something. Google says that the lifespan of the token is dependent on the application being used, but I don't see where they specify how long Blogger keeps them.

Here's the start of our class. We're in a module called Blogger and a class called Blog. I've got an external dependency here on BlueCloth because I'm also going to automatically translate Markdown later, but that's not something you need to do...


module Blogger

require 'net/https'
require 'net/http'
require "uri"
require "bluecloth"

class Blog

attr_accessor :account, :password, :blogid

@@auth_url = "www.google.com"
@@auth_path = URI.parse('/accounts/ClientLogin')

def http
http = Net::HTTP.new(@@auth_url, 443)
http.use_ssl = true
http
end

def request_data
["Email=#{account}",
"Passwd=#{password}",
"service=blogger",
"service=TestCompany-TestApp-0.0"].join("&amp")
end

def auth_headers
{'Content-Type' =>
'application/x-www-form-urlencoded'}
end

def auth_token
response, data = http.post(@@auth_path,
request_data, auth_headers)
return nil unless response.code == '200'
data.match(/Auth=(\S*)/)[1]
end


After the setup lines, we've got three methods here. The first two define the data objects. The first one creates a Ruby HTTP object, set up for an HTTPS connection to the Google ClientLogin URL. The second builds the request data string, tying together the four pieces of data into a single string. They are both used in the auth_token method -- I'm taking advantage of one of my favorite features of Ruby, which is the lack of distinction between local variables, no-argument methods, and data field getters.

So, http, request_data, and auth_headers are just dropped into the auth_token code as if they were local, even though they are separate methods. To me, that makes the code read cleanly, and encourages moving small bits out to separate methods where they can be separately tested and documented.

The auth_token itself takes the path, the request_data, and the headers, and uses the HTTP object to make a secure post call. Request data, by the way, has account and password information that I'm assuming would be defined in an abstract subclass of this Blog class. If the response code is 200, we're good to go, and we do a little regular expression magic to extract and return the authentication token.

We use the authentication token in our actual post call, the one that contains the blog post itself. We need to build up the XML Atom document to send to the Blogger server. Step one is to get the data. Since I'm going to be doing this from TextMate, I'm going to assume we're going to start with the file name that will eventually be provided by the TextMate command. First, we'll convert it to an array of lines.


def read_data(filename)
text = open(filename) { |f| f.readlines }
end


In case it's not already clear, this method and the ones that follow are all parts of the
Blog
class. We're splitting this into lines to facilitate some processing of the text. I'm assuming that the first line of my file will be the title of the post, the second line will be a comma-delimted list of category labels, and the remainder of the file will be the body, written in Markdown. Obviously, that specific format is a weird quirk of the particular blog I'm posting to, which is set up to take XML and not to preserve blank lines. In your case, do whatever you need to do. Building that data structure
is quite simple in Ruby.


def build_data(lines)
categories = lines[1].split(",").map {|c| c.strip}
body = BlueCloth.new(lines[2..-1].join(" ")).to_html
data_xml(lines[0], categories, body)
end


The last line of build_data calls the data_xml method that builds up the XML document:


def data_xml(title, categories, body)
result = []
result << "<entry xmlns='http://www.w3.org/2005/Atom'>"
result << " <title type='text'>#{title}</title>"
for cat in categories
result << " <category scheme='http://www.blogger.com/atom/ns#' "
result << " term='#{cat.strip}'/>"
end
result << " <content type='xhtml'>"
result << body.to_s
result << " </content>"
result << "</entry>"
result.join("\n")
end


I was going to use the REXML library for this -- normally I'm a big fan of building XML programatically. However, REXML really, really didn't like it when the included content contained HTML tags. So I decided it'd be much less aggravating to build the XML from scratch. Details on the syndication format can be found in the GData and Atom online docs.

Once we can create the data, we can finally make our post:


def post_headers
{'Content-Type' => 'application/atom+xml',
'Authorization' =>"GoogleLogin auth=#{auth_token}"}
end

def uri
"http://www.blogger.com/feeds/#{blogid}/posts/full"
end

def post(lines)
response, content = http.post(uri, build_data(lines), post_headers)
while response.code == '302'
response, content = http.request(response.location, entry.headers)
end
return response.code == '201'
end

def post_file(filename)
post(read_data(filename))
end
end
end # of module


Couple things to point out here. First, we call auth_token directly when we're building up our header in preparation for the call -- so that's when we perform the HTTPS login shown above. The while loop takes care of following along if Blogger decides to redirect the post. Finally, we return true if Blogger sends us an OK response code 201, meaning the post has been successfully added.

To use this, you need to set up your own subclass of Blog with the expected information, for example.


class MyBlog < Blog
def initialize
@account = "YOUR_GMAIL_HERE"
@password = "YOUR_PASSWORD_HERE"
@blogid = "YOUR_BLOG_ID"
end
end


As written, that would be included in the Blogger module, otherwise, you'd need to qualify the name Blog. The invocation of the whole thing looks like this. This assumes that the filename with the post is in ARGV[0], placed there by TextMate.


p Blogger::MyBlog.new.post_file(ARGV[0])


One problem, though. We're making an HTTPS connection for authentication to keep our password secure, but including the password in plain text in the script file. Good point. There's a cool way around that in TextMate, and probably

Wednesday, March 21, 2007

Rubies in My Coffee

Now two of the big Java IDE's are promoting Ruby language tools as a big thing. IntelliJ has a plugin in early beta, and NetBeans is also making a big deal of their new early beta support. Eclipse has had a Ruby/Rails plugin for about a year or so.

This is weird, weird, weird, that suddenly all the Java tools would feel the need to grow into somewhat ill-fitting Ruby IDE's (Eclipse has always styled itself as more of a meta-IDE, so that's a little less strange). But do we really need all these Windows Ruby IDE's to be attached to big, memory hogging, Java tools. (And in IntelliJ's case, I say that with love...)

I've played with all three now -- I've used Eclipse for Windows-side Ruby editing for a while, and for the last few days I've been going back and forth between IntelliJ and NetBeans checking them out on an existing Rails project. None of the three are going to make me ditch TextMate yet (although I'd say the big tools all have somewhat more developed project support that TextMate).

IntelliJ's plugin really strikes me as Not Ready Yet. For one thing, there's no syntax checking on .rhtml files, which is a big problem. Also, there's a cool Rails project view, that associates the .rhtml files with the appropriate controller method, but there didn't seem to be an obvious way to get to partial .rhtml files. Another minor frustration is that the Ruby syntax layout is not customizable yet, the way the Java one is. It's even hard to keep a separate setup so that Ruby files only have a two character indent. (And there's a good sociology of programmers paper, on why Ruby is canonically a two character indent, not four).

This seems like a good place to point out that I still haven't spent all that much time with any of the new tools, so it's entirely possible I just missed something. For instance, even though the IntelliJ docs say there are Live Templates for Ruby, my installation didn't seem to have them.

There's some nice stuff in the IntelliJ tool -- all the ctrl-N navigation works on Ruby classes and methods. It's very easy to run arbitrary Rake tasks from the UI (although they seem to run kind of slowly) I don't think syntax completion is there yet, but it does syntax check .rb files on the fly I'd like to see this one a few revs down the line.

The NetBeans tool is in their beta for version 6 (you have to download the tool, then grab Ruby support via the update center). I was kind of amazed to be liking this because I fled NetBeans in a huff around version 3 and haven't had any success in trying it since. The syntax coloring and layout seems to be a bit stronger. It appears to be using JRuby not just for internal parsing, but also as the default external engine for running, say, WEBrick. Which makes everything feel a little slow. There is some syntax-completion -- I found it a little hit-and-miss in terms of getting useful alternatives. The project view is nice -- it flattens out all the /app subdirectories, but I couldn't see an obvious way to run arbitrary rake tasks or the test suite. Although there is a keyboard shortcut to run an individual file, and if you try it in a view page, it attempts to open that action in a browser. My app has a slightly nonstandard route configuration, though, so it didn't quite work for me.

I also had some stability problems, mostly with trying to run the server from NetBeans, it either hung or took a really long time to load. Development on this seems to be progressing rapidly -- they are releasing new versions much more quickly than IntelliJ, so all these things could be fixed by Thursday.

Right now, NetBeans would be my pick of the three if I couldn't use TextMate. I'm as surprised as anybody by that conclusion, but it felt pretty good as I was using it. Adding easy test hooks would help. All three tools are still under development (RDT for Eclipse just released a new version, and RadRails just passed to a new owner with new development promised). So, watch this space, I guess.

Update: Looks like NetBeans has a bug in reformatting code -- it kind of messed up some of my source files. Nothing permanent, just kept indenting and not noting the end to outdent so the file kept creeping to the right.

Sunday, March 18, 2007

Wow, There Are Comments

It's true -- the way to get comments on your blog is to mention Apple... I do something like one substantive post in three months, and then two apple posts in 48 hours, and bang! Four comments within a day. I'm surprised, not least because I really wasn't sure anybody was out there.

Anyway, interesting points have been made, and I thought I'd pull them up to either agree, or whine defensively.

On the Win 95 post, Massive writes:


My observation at the time was that the 'competitve analysis' of the OS features and capabiltiies was basically bogus and totally irrelevant. I felt that Apple wasn't whistling past the graveyard so much as completely lying to itself.


You say "tomato", I say "tomahtoe". There was a lot of denial in the air, that's for sure.

Still Massive, about the impact of Win95 on end users:


You could already, with Windows 3.1, show demos rigged to look identical between Mac and the Windows apps. And people were sufficiently ignorant about computers at the time that they would actually buy Windows 3.1 and tell people that it was 'just like the Mac'.


I can't really disagree with that, but I still think the general point that Windows 95 brought the two platforms much, much closer together holds. I certainly remember that to be the theme of much of the Win95 press coverage. I also remember Apple's slogan "Windows 95 = Macintosh 89". Y'know, Apple's marketing also kind of stunk in that period...

Massive also mentions that Apple had a poor relation with the dealer channel and that didn't help. Also true. As far as I can tell, still kind of true.

On to the internet posting, a couple of people comment on some other facets of how Microsoft eventually took over after they decided to start competing in browsers. Right, but there was a time when it was not yet clear that they were going to be willing and able to do that.

One anonymous poster did bring up a long-buried memory:


Nonesense. Apple's initial 'internet strategy' was CyberDog, which was a fantastic set of tools (web browser, mail client, etc ) unfortunately chained to the technological boat anchor that was OpenDoc.


Mike, is that you? Mike Pinkerton, who went on to create Camino, was the only person I knew who used CyberDog. I remember him as being very enthusiastic about it, but it was about 10 years ago, so I could easily be wrong. It did indeed look cool, but I recall the setup as being kind of daunting, and OpenDoc was kind of a pain in the neck. Also, CyberDog came out in 1996, and by then Microsoft had already moved in.

Thanks to the commenters -- I like responding, and it's a good way to get a post, so by all means, keep writing.

Saturday, March 17, 2007

Apple Dot Net

What is it about us tech fanboys and Apple... I've always found them interesting, even when I wasn't a regular Mac user. Infuriating, sometimes. But interesting.

So here's another thing about Apple, circa 1995... That was right about the end of something like a two-year period where Apple was way ahead on internet integration and didn't really make anything out of it. By the time the internet really started to escape out of academia, the Windows world was well on it's way to catching up, and by the time it all really went mainstream, Macs would be a fading memory. (I remember as late as 1995 impressing non-techy visitors to my grad school office with demos of a web browser. But a year later, the cat was largely out of the bag.)

But in 1994/1995 it was all Macish. Just accessing the internet was much easier (although it was a separate software purchase initially). And all the best software was on Macs (well, some of it was Unix, too) Eudora was the standard email client, and it was still Mac-only, for some reason the Windows version remained ugly forever. The Mac version of Netscape (and before that Mosaic) were much prettier than the Windows versions. (In my memory, the Mac versions came out sooner, particularly for early Netscape, but I can't find a source that backs that up).

On top of which, Microsoft was in the middle of a totally clueless stage. Win 95 did not, by default, ship with a web browser, and the big Microsoft internet initiative of 1995 was something called Blackbird, which was going to be a proprietary replacement for HTML. That worked out about as well as you'd expect, evidenced by the fact that Blackbird doesn't even have a Wikipedia article. Making it less important than even the most minor anime character...

Putting that all together, in the months before the Win95 launch, Mac had about a 12-18 month lead in Internet apps and Microsoft was distracted by an attempt to privatize the nascent WWW. There's clearly some room there for Apple to have maneuvered themselves into a better position than they wound up in. Being the best internet platform around would have been an interesting counterweight to the Win 95 launch, and while I doubt they could have stopped the upcoming onslaught, they probably could have mitigated it somewhat.

Instead, Apple didn't really do anything in the space, except release an email client (Claris Emailer -- which does have a Wikipedia article, which charitably refers to it as "popular"). Microsoft, on the other hand, turned on a dime, and gave up the futile attempt to take over the internet by co-opting the authoring tools. They switched instead to the more lucrative method of taking over the internet by co-opting the client tools. Apple wandered around in a fog for a few years, until they attacked the opportunity to go after digital media. But you probably know that part...

Apple Summer of 95

As I may have mentioned here, back in 1995 I spent three months as a summer intern at Apple HQ in Cupertino.

I was buried deep in the educational technology research group so, trust me, I didn't work on anything you've heard of. It was a fun summer, though. They stuffed about 15 of us, a mix of grad students and contractors, in a room that was really long and narrow. They tried to make up for the cramped office space by supplying us with Nerf toys (the admin assistant for our group would sometimes come in and announce a Toys R' Us run, and did anybody want anything). I got about a dozen free T-shirts in three months. I also experienced my first earthquake, which went like this:

A slow rumble, like a truck going down a slowdown strip

All the non-California people: What was that?

All the California people: What was what?

None of which is why I brought this up. 1995 was near a low point for Apple, but even at that there were three or four good-sized company parties during the few months I was there. I'm talking about food, music, drinks, some entertainment, all in the inner courtyard of the Infinite Loop campus. I may be slightly exaggerating in memory, and I was assured that it was small-scale by later Valley standards, but it sure seemed elaborate to me.

In August 1995, Apple held what you'd have to describe as an anti-Windows 95 launch party. More of a morale booster, I guess. The thing I remember most is a screen projecting Windows 95, while some Apple guy pointed out it's flaws. As in, "Windows 95 will only let you have 256 characters in a path name, but if you have more than 15 directory levels, you can cause it to give you a really weird error message." Thin stuff, but enthusiastically received by a lot of people who wanted to whistle in the dark together.

Everybody there, I think, knew that Apple lost something big that day. Prior to Win95, the visual differences between Mac and PC were so clear that you could see the difference in a store just by looking at the two. Afterwards, you actually had to use them both for a while to learn the difference. This was a big change in the Mac/PC dynamic, and it took Apple about five years of flailing before they would come up with a decent response.

Sunday, February 25, 2007

GWT part 3 and 4

Sorry for not mentioning this earlier, but part three of the GWT series is now up on the IBM site at:

http://www-128.ibm.com/developerworks/opensource/library/os-ad-gwt3/

This one is about remote procedure calls, and I'm pleased with how it turned out.

I just got the proofs for the fourth and final article in this series, about deployment. I expect it to be online Tuesday, Feb 27th at:

http://www-128.ibm.com/developerworks/opensource/library/os-ad-gwt4/

Friday, February 02, 2007

Clearing The Decks

A collection of small things, half-finished posts, and pure whatnot that hopefully will lead to more posts in the future:

  • Got my first Amazon affiliate statement with no less than $1.55 heading my way. Thanks to the person who clicked through...

  • There's a new sidebar, for small links, via del.icio.us. The sidebar has it's own RSS feed, on the off chance somebody is interested. UPDATE: It doesn't appear to work on Safari, which is a problem... Weird, because I did the preview using Safari, and it showed up fine, but not in the actual blog. Until I figure that out, Safari users can still click on the RSS icon and see the items.

  • I had a half-finished post on the iPhone that got buried by the trillions of electrons poured on this story. So, I'll distill it to this: that was one cool demo.

  • I also had a half-finished post on using XML as a scripting language, as in Ant scripts. Distilled: Don't do it. It's hard to read and nigh impossible to maintain. The thing I most like about Groovy is that it lets you actually script an Ant target. Although I think the JRuby/Rake combo is going to be pretty powerful here.

  • Hey, another half-finished post. This one was about the lack of list or hash literals in Java. Which bothers me just about every day that I work with Java.

Decks now cleared. Hoping to get some new content here soon.

Thursday, January 25, 2007

GWT Article Now Online, Part Two

The second part of my IBM Developerworks series on Google Web Toolkit is now online at http://www-128.ibm.com/developerworks/library/os-ad-gwt2/. This one focuses mostly on the Derby database, and features a really quick and dirty database-to-Java conversion tool.

Enjoy.