I got my copy of Obie Fernandez' The Rails Way a couple of weeks ago, but I've been so busy with work (we're down a sysadmin, a web designer, a tester, and now a developer... sigh), that I just dropped it on a shelf and almost forgot about it. Today our new sysadmin started, so I had a little breathing space (ha!). Another coworker/developer, Hal, reminded me about the book by pointing out that we'd met one of the contributors at RailsConf 2007 last year. Hi Jodi! Thanks for helping me debug our production Rails app during one of the sessions!

Anyway, I turned off the TV tonight, and pulled out The Rails Way. Since I've been using Rails for over two years in a quasi-enterprise application, I'm not expecting a tonne of grand revelations, but I'm certain that there will be a lot of tips and tricks that will improve my Rails usage, and my understanding of Rails internals.

As I started reading the introduction and chapter 1, it occurred to me that there was something else quite useful I could get out of this book. I've been nagged (in the nicest possible way) on and off for months about blogging about CodeGear's 3rdRail, which I use every day in my Rails development. Turns out, as I was reading, I kept thinking stuff like... "oh, yes, but in 3rdRail it's even easier to do..."

So, that's what I'm going to do. Chapter by chapter, as I go through the book, I'll be posting about the ways in which 3rdRail makes my life easier, as an enterprise Rails developer. Expect the first installment before the end of this week. I look forward to hearing what you think, so gimme some comments as I go!

Having recently acquired an iPhone (yes, yes, hacked to work in Canada), I've been drawn to all these iPhone SDK articles. I mean, it's a realy cool device, so who wouldn't want to develop apps for it?

But different developers have really different ideas about it. Here are a few that I've read:

The iPhone is Now THE Platform for the Future of Mobile Computing

Lest you think me an Apple "fan boy", for the record I don't yet own a Mac. However, after watching the video of how the iPhone SDK works and since that SDK only plays on Macs, I'm going to drop a thousand on a Mac Book. It's well worth the investment just to play in the iPhone world.

The apparent quality of the SDK is so superior to anything out there in the ME world that I'll easily recoup the investment in development time alone and that includes learning from scratch Cocoa and Objective C (not that big a challenge for a Java jock.) Yes. I'd like to be able to code in Java to save myself a bit of learning curve but when you consider how much time is spent in UI coding vs the rest of the app, my gut tells me that being able to leverage all of the built in iPhone widgets and built in APIs (which is unlikely in Java) will more than make up for the little bit of Cocoa that I'll have to learn to do the things that are the unique value add of my code.

If you haven't watched the Apple iPhone SDK tutorials, give them a look and then compare them to what you know in the J2ME space. If you are like me, you'll want the full package and not some "slap a JVM into the iPhone so we can do SWT apps" solution.

Prohibiting background processing is not just a question of one feature being left off a long list of otherwise very well executed features. The issue of background processing is *the* issue for a mobile device because it is key to two things:

• telling the world about your status in some ongoing way
• receiving notification of important events

These two things are the key to most new real innovations in the mobile space. To be clear, by innovation, I mean creating functionalities that have not been possible before. I do not believe that Apple’s beautiful new iPhone UIs or visual metaphor’s allows for the creation of truly new application categories. Apple’s tools are great, but they just make apps that were already possible, easier to build and easier to use. But as a developer, I want to create things that have been bottled up in my head but without the right platform, were fundamentally impossible to do.

Craig Hockenberry is the man, the myth, and the legend behind the absolute best Twitter application on the Mac (he works for the Iconfactory). We would all love to see Twitterrific on the iPhone, but Craig offers up a "healthy dose of reality" regarding the iPhone SDK and backgrounding services (applications that run in the background even though the phone is running a different foreground app).

In a recent blog post, Craig attempts to explain why Apple will not be giving developers access to backgrounding services on the iPhone. He points out that in a mockup design of "Mobile Twitterrific," based on the jailbreak/community toolchain, refreshing the XML data from Twitter every 5 minutes led to a dead iPhone battery in only 4 hours.

"The heart of the problem [is] the radios. Both the EDGE and Wi-Fi transceivers have significant power requirements," he says. "Whenever that hardware is on, your battery life is going to suck."

He also reiterated what Apple said about the "Core Location" feature that Apple provided in the SDK: use it only on an "as-needed" basis. Craig said that the issue of backgrounding services may get addressed later on, but right now Apple is preventing iPhone developers from "shooting themselves in the foot." He said that it will take months before the desktop developers have gotten the mindset of an iPhone developer, and that thinking like a desktop developer will lead to bad designs.

For some reason, all of this reminded me of a panel I attended, at a science fiction convention in Edmonton, some time ago. The title of the panel was "Collecting... Tool of Satan, or just a really, really, bad idea?" I think the people who are the most bent out of shape in iPhone land, are the collectors. They want their cool new toy, and they want it to be perfect, and it has to be NOW. The platform will evolve, and some day they will be able to do every cool thing that they can think of. But for now, let's all be calm and realize that the iPhone and iPhone SDK are not evil. The collection is just... incomplete.

Open-source history: See Multics source code | Underexposed – CNET News.com

In a move more likely to appeal to technology historians than coders, the Massachusetts Institute of Technology has published the source code of Multics (Multiplexed Information and Computing Service), a precursor to the Unix operating system begun as a research project at the university in 1965.

Many people probably haven’t even heard of Multics. At the time I attended the University of Calgary, Multics was the “Big Iron” system where we learned about designing secure operating systems. UofC had the second largest Multics installation in the world, second only to the DoD in the US. It was also where we learned PL/1. Ah, the good old days.

Ok, here’s mine!

Vote for Java6 on Leopard!

As mentioned previously a lot of Java developers on OSX are upset at Apple’s silence as to its intentions with respect to the release of Java 6. There used to be a developer preview available, which was pulled recently with no indication as to when a replacement would be available. People like me who upgraded in the hope of having the latest and greatest – which we have been very patiently waiting for over a year for – are very disappointed. Some who are working on Java 6 projects cannot use their computer easily, without resorting to installation of a separate OS in a virtual machine, to do their job. We all like OSX: its a beautiful easy to use Unix that usually really helps us get our work done. I have been very happily using it since 2004.

The solution of course is to have our voice heard. One way to do this is to file a bug with Apple. Please do this! The only problem I have with it is that as opposed to the Java bug database which is completely open, the Apple bug database is completely closed. So there’s no real way of verifying how many people have posted a report. We must therefore complement that action with an equal Open action. Following the noble example given to us by Nova Spivack, when he asked for people to make their voice heard in support of the Burmese people and got some real results, let us do the same to help Apple make the right decision. Anybody who would like to support this issue in the blogosphere, should help post a blog with the string

13949712720901ForOSX

I have posted a zip file containing my presentation, and the source code for the various demos, on the Calgary Ruby User Society – CRUserS Yahoo group. So, join up and you can download! ;-)

COSSFEST 2007 – Maps on Rails Presentation and source code

You are a web developer, and your web application is up and running at last.  You can only hope it will become popular.  But are you ready for when it happens?  These two ticket selling operations didn’t have to wait and wonder if they would “become” popular, they KNEW exactly when the flood would arrive… And still, they were unprepared.

High demand crashes Beijing Olympics ticket website

On Tuesday, organizers were working to fix the problem, the BOCOG website said. It asked ticket buyers to be patient and to avoid constantly refreshing the online ticketing site. Within the first hour of sale, the website was visited eight million times and received more than 200,000 ticket requests per second, BOCOG said. It’s unclear how many tickets were sold Tuesday, but BOCOG said 9,000 were sold within the first two hours.

On Monday, there were 8.5 million attempts to connect with the Rockies’ computers in the first 90 minutes after sales started, he said, and only several hundred tickets had been sold before the system had to be shut down.

An excellent posting, countering some of the FUD spreading out there in Mac/Java developer land.

The Fishbowl: Java on Apple is dooooooomed

This puts Apple behind Sun (duh), on a par with IBM, slightly ahead of the remainder of Unix-land and, it’s worth mentioning in passing, light-years ahead of Microsoft and the Linux vendors who don’t even maintain their own JDKs any more (hands up if you remember waiting for the Linux Java ports from blackdown.org).

I couldn’t comment on David’s blog ( must be logged in… no way to log in provided :-( )

David Orriss Jr – The Delusion That People Care About What I Think » Blog Archive » How Ruby Finds Libraries

In Ruby not library management is not always as simple as running gem install. Some Ruby code is distributed simply as libraries. So where do you put these libraries? The clue is in the Ruby $LOAD_PATH variable.
<br /> irb(main):001:0&gt; puts $LOAD_PATH<br /> /usr/local/lib/ruby/site_ruby/1.8<br /> /usr/local/lib/ruby/site_ruby/1.8/i686-darwin8.10.1<br /> /usr/local/lib/ruby/site_ruby<br /> /usr/local/lib/ruby/1.8<br /> /usr/local/lib/ruby/1.8/i686-darwin8.10.1<br /> . =&gt; nil<br /> irb(main):002:0&gt; <br />
This tells you that you can put your library code in any of the above listed directories and if Ruby still can’t find the code it will try the current directory you’re running code in before giving up. Personally I end up using the /usr/local/lib/ruby/1.8 folder.