Turns out that it’s made w/ the Mozilla application framework and that the whole thing is written in Javascript and XUL.

So you’re basically working in a self-contained web app, and the coolest thing is that you never would’ve known — the interface is smooth, even if the textures and colors aren’t as polished and pleasing as the interface on an OS X/iOS app.

I’ve been working with the web for long enough to have done a decent amount of JavaScript. I’ve got a reasonable understanding of the language itself, and I know how to get around in a number of the big frameworks. I’ve also been to a couple of JavaScript meetups. Most of the people at those meetups have been web-oriented. Most of the JavaScript talks I’ve been around have seemed to center on usability, cross-browser issues, etc.

If you like programming for the web with Javascript, HTML, CSS, my advice is to find an XULRunner app that you like, download the source, and check it out. You’ll be challenged, but it won’t be gobbledygook to you when you start reading the code, and you’ll almost certainly get something from the experience of figuring out how it’s put together.

I wouldn’t have made the switch if not for carlhuda’s Janus, which I promptly forked so I can customize it for my own needs. This thing is extremely cool — Vim config managed w/ one big Rakefile.

What I like so far

• Split screens — I think this is the number-one “general editor features” thing that people using TextMate are missing out on. Sure, you can have multiple windows, but it’s not that easy to do. You can’t even easily convert an existing open tab into a separate editor window (as you can pull a tab out with Safari, Firefox, and Terminal on OS X). With Vim, I routinely fill a 24″ monitor up with one window split into 4 buffers, each remaining large enough for me to see a significant amount of code.

• Sophisticated class/method name completion — This is what pushed me over the edge from TextMate. At work we have a bunch of different Rails apps and gems that we are constantly moving in and out of. Watching co-worker Vim users auto-complete from the whole galaxy of method/class names while I typed out every letter like a chump was just too much for me. About 10 seconds after the first time I hit tab and got an auto-complete list including an instance method I had added to a class in another file seconds before, I threw TextMate out of my OS X Dock and Login Items. I am never going back to using an editor that doesn’t include this.

• C and t — ©hange to end of line and (T)ill (usually used in combination with ©hange) are great for doing edits to text that has already been written.

• O and o — Vim is famous for making it easy for you to type and use the mouse less. These insert a new line fabove or below the one you’re on and take you into insert mode. For me at least, this saves a surprising amount of time.

What I dislike

• For some reason, with Janus, arrow keys don’t work at all in visual mode.

• No automatic matching of ‘ ” ( { [ characters

• Running the buffer through an interpreter is not nearly as simple. In TextMate, it’s built in — if you hit Command-R, it will use the filetype to choose an interpreter and execute the buffer’s text as code for that language. This is really nifty for trying to do small things like remember if some standard library method works the way you think it does. I’ll figure this out eventually w/ Vim, but it’s nice that it comes out-of-the-box w/ TextMate.

• I miss the blogging bundle. Once I’ve typed this up in Vim, I’ll probably move over to TextMate just so I can shoot the post straight to my blog the way I always have before. I’m sure such a thing exists for Vim, but again, it’s out-of-the-box behavior for TextMate.

• Wrapping seems unsophisticated — it breaks in the middle of words, and it doesn’t let you traverse the pseudo-lines like you can in TextMate. If one logical line is broken into four pseudo-lines, you’re not able to up-arrow amongst them like you’d hope –it jumps you up to the top and bottom of the logical line.

• Customization seems much less straightforward — without something like Janus to pull lots of things together that already made sense and to make some decent assumptions (e.g. “project drawers” are nice; I’d want to have snippets for Ruby, Javascript, etc), I would’ve had to spend days just learning how to customize the editor for my needs. In a practical sense, this means I’d have never started using it. Not a knock at Vim really so much as praise for the Janus guys.

• Modal editing– I’m torn about this. I railed against it for years, and I still kind of think that it’s stupid. I hate hitting Esc constantly. If there had been a Janus equivalent for Emacs, (which is much more like TextMate in terms of key bindings, etc), I’d probably have switched over to that. That being said, modal editing is the only way that you can have this huge number of single-key functions. In Emacs or TextMate, you’re “chording” all the time (hitting a modifier key and multiple other keys simultaneously), and that can be really rough on the wrists.

All of these are basically nits (other than the wrapping, which is really obnoxious), and I understand that Vim and TextMate are trying to do two different things (actually, TextMate doesn’t seem to be doing much of anything these days, which is a big part of why I switched). I just list them here because they’ve been on my mind as part of the process of switching.

Overall, I’m pleased. I’m pretty sure that I’ve learned to stop worrying and love Vim. My hand will tire of hitting Esc, I’m sure, but my left wrist will be thankful that it no longer has to do so much contortionistic chording.

One thing I found interesting is that since Safari triggers updates of your Top Sites when you make a new tab, you can end up doing a request for something like Facebook by accident. That happened to me today, and it kind of spooked me because it took me a second to connect the Firesheep capture to the tab opening. I used Wireshark to confirm that Safari does indeed kick off a bunch of HTTP connections on every tab opening, seeming to correspond to the Top Sites host-wise. So you could be at the rogue’s gallery coffee shop not signed out of Facebook but thinking you’re safe because you aren’t going there, and popping open a new tab hands some creep your account.

I’m really impressed that someone took the time to put this together. Guerilla action like this seems to be the only way to get people to take notice and protect themselves. It’s going to be sad if it causes divorces on Facebook or something, but everything you should be cautious of needs cautionary tales; it’s the ugly stuff in driver’s ed that gets you to wear your seat belt and know your booze limit as a licensed driver.

Nevertheless, implementation/knowledge will remain relatively low — how many internet users can’t install a plugin or aren’t sure what a firefox is? Lots of people will remain vulnerable. So HTTPS usage for web services will naturally need to increase. Anything you pay for should be HTTPS. Anything you don’t… well that should be up to the company and its PR people and lawyers. For a lot of things it probably makes sense, for others it doesn’t. Facebook and GMail are two that definitely need to do HTTPS by default. GMail already does, and Firesheep doesn’t work on it. But if you are as big as Facebook, you are making robber-baron money from the traffic and you have an implied obligation to provide secure access to the people who are making that happen for you.

That being said, I’m not in favor of any legislative action trying to force more services to use HTTPS or anything like that. Banks and other financial entities already do, and there may be some regulation somewhere that requires it for them, and that’s a good thing. But the more we’re using web services in our daily lives, the more we need to simply be aware of our environment. People need to learn how encryption works and why it matters. They need to have a hands-on experience so that communicating via computers is less about shouting into magic black boxes and more about having a deliberate conversation with an audience you choose.

The two things to keep in mind when making an admin area are

1. you can create namespaces for routes to get the /admin URLs you’re looking for and
2. you can have controllers inherit from other descendants of ActionController

So to make an admin area, you’d want to have RESTful resources declared in a namespace (assumes Rails 3 routes):

The top set is the public ones and the bottom set gives you the admin routes like /admin/users/new and /admin/posts/1, etc. I’m also assuming you might want a “dashboard” so I’m setting up a route to the index method of an Admin::DashboardController

Then you create an admin base controller that descends from ApplicationController. Use it to hold your admin area layout and your authentication filters:

Now make a directory in app/controllers called “admin”. Make controllers in there as normal, but have them inherit from your base controller:

Make a corresponding directory in app/views for “admin” and you’re good to go — everything is namespaced out and views/controllers would behave like you think.

You can always run “rake routes” to see all the admin routes.

Now is a piece of software designed to do something as prosaic as dependency management going to get you hot and bothered all by itself? Probably not. It’s not going to be like when you discovered the beauty of Ruby’s iterators, or how to get the QBasic interpreter to give you the exploding banana game in MSDOS 5.x+.

But along those same lines, Bundler will help you reserve more of your mental compute cycles for things that matter and fill you with wonder, secure in the knowledge that you’ve chopped off a few big boulders from the pile of computational entropy constantly threatening to avalanche everyone in our industry into oblivion.

Examples:

Kids should come with “bundle install”.

Apps are complicated because you need all sorts of specific stuff to deal with them. That’s why Bundler was originally invented, obviously. But real-world scenarios are always valuable, and today I had to get a development version of the app I’m building for my main client running on the designer’s machine, and do it as fast as possible. While the designer is good w/ HTML/CSS, she doesn’t know thing one about Rails, rubygems, or the RVM-based sequestering of different Ruby versions, etc (another hymn another time for RVM). I got all that going for her, and then, with a mere two commands (one of which checked out the source code from the repo and therefore didn’t really even count), I bootstrapped the entire app at once, while surfing the web. “bundle install” for the win. That same process would’ve taken me (just for the app’s dependencies) about 45 minutes or so in previous incarnations of Rails. This way, it took less than three. And almost all of that was completely automated.

Specifying refs is a thing of beauty

Rails 3 rc1 came out a couple days ago. Like every other RoR cultist, I upgraded as soon as I heard. A bunch of crap promptly broke. Those wacky core team members! They love to make a boatload of commits on something and then call it a release candidate, just to keep us all sharp.

One of the things that broke was state_machine, which I rely on extensively in this the aforementioned app. So one upgrade from Rails 3b4 to Rails 3rc1 and I’m sitting there in a puddle of my own tears, with all my specs broken and no ability to run my seeds.rb file.

Thankfully, the gem maintainer rapidly came up with a patch. But he didn’t have a release ready yet. So what did I do? In the old days, I’d have to download his code at that Git reference and then put together a new gem on my own, keeping a vendored version that was seperate from the other versions of the gem I might’ve been using, etc etc. I’m sure there’s probably a better way to do it even under the old regime, but with Bundler, you simply pass in a reference to the commit where it’s been fixed!

So this

Becomes this:

That blew my mind even more than the dead-simple bootstrapping of my colleague’s development system. For working with libraries that are still in frequent development, and for fixing things like the myriad breakages that can occur when one version jumps up to be something else, this is a godsend.

So don’t bitch about Bundler, even if you’re tempted to in the beginning. Like everything else surrounding Ruby/Rails, it’s new and it takes some getting used to. But in the end, you’re likely to love it, and to wonder how you ever got along without it. Plus, this gives us yet another reason to laugh at Pythonistas, who still lack even a Rubygems equivalent.

I wish I had more to say than this right now, but RailsConf is going on right now, so I’m tired and need to go get ready for day 2.

Fart Battles. It’s out there. It’s crude. It’s gaining on you. Don’t be left behind.

And that’s a daunting idea, because much is riding on it. Getting attention in the iPhone space isn’t easy or cheap. Fart Battles is a fun app that straddles the line between game and entertainment novelty. There are tons of these kinds of things in the store, and we believe that we’ve made one of the better ones, but getting it in front of people means getting their attention, famously difficult to do. On June 5th, we’re scheduled to be on freeappaday.com. We’re racing to finish the last bits of stuff on our promo video for the website and we’re working on stuff for our Facebook fan page and our Twitter stream and our YouTube channel. All of this takes time and coordination, but without it, we can’t see how we’d be able to get any sales for this thing that we’ve worked on for six months. It seems trying to gain even a small chance of rising above the considerable level of noise surrounding the app store is expensive, and knowing how to time those efforts with the rhythms of the submit/approval process is a big part of any given iPhone developer’s chance for success.

I’ve put it on GitHub as a Gist — you can get it here. Download the file and then put it in ~/Library/Application Support/XCode/Color Themes. Activate it in your preferences and then feel your cool factor morph to “red-hot-insane”.

If you’re wondering what Blackboard looks like, it’s like this (except the method names are supposed to be orange, dagnabit):

Anyway, now the color theme is out there, downloadable from the Gist, for all who want to use it in XCode. Viva Blackboard!

But I have had time to be impressed, once again, at the awesome power of open source and the game-changing nature of Amazon Web Services.

Open Source — HTTPriot and delayed_job

Without going into too much detail, the iPhone app I’m working on (codenamed “Pedro”) records audio files and uploads them to a server. Naturally I’m using Rails for the backend, so I needed something to help me communicate easily with the server. After trying both an ASIHTTPrequest with TinyXML solution and Objective Resource, I eventually settled on HTTPriot. HTTPriot is a Goldilocks solution. ASI/Tiny are just too cumbersome since you end up having to write parsing methods yourself (and really, who the hell wants to do that when the entire point of structured serialization formats is that something should be able to turn them into native data structures (hashes/dictionaries) for you?), and ObjectiveResource seemed to do just a little too much and to rely on Objective-C categories a bit much for my comfort.

HTTPriot sits right between these solutions and is just right (had to complete the Goldilocks thought) for talking to REST services IMO. You serialize something out as an NSDictionary and POST or PUT it to the server, and you get back a response you can treat as a dictionary. GET requests are a one-liner (though to do it right you need a few methods so you can have a ViewController delegate handle the eventual response). The only drawback I’ve found so far to HTTPriot is that it requires you to cram all your processing logic for any given resource into a single method, as one and only one delegate method handles a successful server response. But that’s a small gripe. Using this excellent library, I was able to re-write the entire ASI/Tiny solution in a few hours. That’s versus a few days getting it set up in the first place. If you need to talk to a REST service with an iPhone, I highly recommend HTTPriot. As a bonus, the inimitable Geoffrey Grossenbach (@topfunky) uses it in one of Peepcode’s iPhone screencasts, enabling you to get both a step-by-step tutorial on creating a non-trivial working application with HTTPriot, and a good bit of explanation on how the library ought to be used.

When HTTPriot is done pushing an audio file to my app server, a Ruby library called delayed_job does the background processing required to send it to Amazon S3, where it will live and respond to GET requests via Amazon Cloudfront. delayed_job was created by the redoubtable Rubyists behind Shopify, the coolest turnkey e-commerce solution I’ve found so far. I’ve made a site or two for clients using Shopify, so I was excited to discover that they’d opened up the library they wrote to do background processing. delayed_job is a database-backed persistent job queue that runs in its own process and makes backgrounding a task dead simple. You can do all sorts of fancy things with prioritization and whatnot, but the thing that made me fall in love (even though my use cases eventually got a bit too complex to use it very much) is the fact that you can run any method with send_later — as in:

That one-liner will bop it into the queue, and delayed_job will handle it as it can. It’s really that easy. I’m using dj for sending emails and pushing binary files to Amazon, but I might start using it for other things as well. EngineYard (where we’re hosting this opus) supports it for production, and for development, you get a nice Rake task to help you manage it and keep an eye on the tasks as they happen.

The point of all this exposition is to say that I feel fortunate to have come up as a code dunce during a time in which open source software is mature enough to be able to provide even a relative n00b like me with documented, real-world-tested, helpful stuff that does exactly what I need it to — whether on the server side or on the client side. It’s worth mentioning as well that both of these things are arguably direct offshoots of the Rails community (delayed_job is in Ruby and was built to serve a Rails app, and HTTPriot was built with REST interactions in mind, which Rails has done a lot to help popularize), which continues to astound me in its breadth, creativity, and helpfulness.

AWS – cheaper than dirt, more valuable than gold

Have you ever seen anything as cheap as the stuff offered by Amazon Web Services? I don’t think I have. Or to put it more directly, AWS are the cheapest things I’ve ever seen someone try to put a price tag on:

- S3, Amazon’s storage service, charges $.015 per GB for the first 10 TB of transfer bandwidth you use in a month. And the prices go down from there. Get out your calculator and do the math to see how much data you have to be moving around before this starts to cost you more than you have in your change jar, and you’ll likely spend 20 minutes or so cackling to yourself about just how inexpensive mind-blowing web power is these days.

- Cloudfront, Amazon’s CDN charges $.01 for every 10,000 GET requests. Do the calculator thing on that one (realizing that it’s basically an add-on to the above), and you’ll be laughing even longer.

- We buy EC2, Amazon’s scalable-on-demand computing service, through a reseller (EngineYard) who really doesn’t add all that much to the $0.085/hour cost that Amazon themselves charge. EngineYard is able to offer hosting solutions optimized for Rails based on EC2, along with monitoring and Rails-oriented deployment and management tools, for so little extra on top of what Amazon themselves charge that for the first few weeks you’ll feel like you’re getting away with a crime.

Without the open source libraries I mentioned above, Pedro would take much, much longer to build and would be necessarily a bit less stable, simply because my team and I would be building everything from scratch. But without Amazon Web Services, there’s no way we could even entertain the notion of making this app. Pedro is a game: a funny, 99-cent App Store novelty that we hope will go viral and make us some cash. Apple gives us a great way to distribute the app, but without Amazon, we’d have show-stopping cost barriers to actually building a backend capable of meeting rapid, viral demand. A few years ago, just standing up unused production infrastructure to handle these use cases would’ve cost us thousands of dollars a month in rents, to say nothing of what it would cost in time and/or people-hours to have a qualified sysadmin lurking on our payroll. Now because of Amazon, those barriers are gone — replaced by a giggle-inducing cost structure for computing resources that back one of the most powerful retailer/supply chains on Earth.

With the preponderance of open source libraries and the rise of commoditized enterprise-scale computing, the utopia really is now — the only things holding anyone back are time, creativity, and will.

Speaking of which, I need to dive back down my code hole. See you in a month or so.

I’d still love to see the iPad enable some cool peripheral needs. I understand why they didn’t showcase that as a major use of this thing, but I’m hoping that the SDK will let programmers create apps that enable the iPad to be used as an input device — the 1000-sensor multitouch screen would make it pretty compelling for that. I mean if you watch the Brushes app demo, you’ll get an idea of what you could do with this in something like Photoshop or Illustrator.

John Gruber got to play with one a bunch and said that the main thing that he (and it seemed everyone else there) noticed about the experience is how fast it is. And it’s Apple’s own chip in this beast — a 1 Ghz Apple A4 chip. This is going to drive Apple’s bid toward dominance as the “largest mobile device maker in the world”

Apple now owns and controls their own mobile CPUs. There aren’t many companies in the world that can say that. And from what I saw today, Apple doesn’t just own and control a mobile CPU, they own and control the hands-down best mobile CPU in the world. Software aside (which is a huge thing to put aside), it may well be that no other company could make a device today matching the price, size, and performance of the iPad. They’re not getting into the CPU business for kicks, they’re getting into it to kick ass.

It seems inevitable that they’ll try to put one of these babies into a new version of the iPhone, and then, well holy crap. They’ll need to call it the 3GS^2

Peripheral

I wish I’d been right about the magnetic induction stand, because I think that would’ve been a lot cooler than the flip-around carrying case thing that they’re going to ship this with, but it makes sense that they’re going to have the same 30-pin power/data connection that the iPhone/iPod have. Apple has a history (that they seem to have abandoned) of just drastically changing what’s available in the way of interfaces or peripherals on new devices. Remember how aghast people were that the iMac had no 3.5″ floppy drive? Earlier than that, I think there was a big stink when they did SCSI instead of parallel ports on their boxes. Given this history, it made sense to me that they might want to make the sync interactions of the device entirely wireless. But given the existing commitment to 30-pin connectors, it feels a little more “new Apple” that they kept this tech in the device.

I’ll leave the public predictions to people who know a lot more about the history and industry on these things, but it was fun to speculate. I can’t wait to download the SDK for iPad — I should have it later today — and I’m of course hyper-excited to get one in 60 days. Still trying to decide though whether I care about the 3G access. At this point, hearing that AT&T is willing to sell me an unlimited 3G data plan for $29.95 is sort of like hearing that shit sandwiches are 75% off.