I started working at the Sunlight Labs this week, and I’m giving a talk on Being a Civic Coder at RubyNation today:

Some resource links:

• Sunlight Labs
• Apps for America 2
• Sunlight Labs Google Group
• @sunlightlabs on Twitter
• Open Secrets
• Follow the Money
• MAPLight
• Apps for America 1 Submissions
• TweetCongress
• DC API
• Apps for Democracy

I attended RailsConf 2009 earlier this month. Overall, it was a good conference, and any commentary on the city to be made has already been made by others.

I brought my Flip Mino HD with me. While great for shooting outdoor (or very well-lit) scenes, I find the Flip doesn’t perform as admirably in lower light situations, which is unfortunately the environment of a conference hall. Also, the Flip is optimized to record voice at close distance, so picking up mic audio from a speaker system wasn’t ideal either.

That being said, here are three videos I recorded at RailsConf. The TweetCongress video has the best audio quality, while the Gov 2.0 Panel, I’m sad to say, has the worst.

Build an App, Start a Movement from Luigi Montanez on Vimeo.

The Russian Doll Pattern from Luigi Montanez on Vimeo.

Government 2.0 Panel at RailsConf from Luigi Montanez on Vimeo.

There’s no doubt about it, the launch of Wolfram|Alpha has been truly strange.

There’s the technology itself. All answers get rendered as images, even when they don’t need to be. It doesn’t handle obvious errors very well.

They oddly chose to launch on Friday night, a time when even the majority of Battlestar Galactica fans opted to use their DVRs and go out. And they’ve fed a media hype machine to levels that they cannot possibly live up to.

But the weirdest thing about Wolfram|Alpha is that they have a control room, like NASA, or like the villains from 24. Nerds hunch over their laptops in stadium style seating, with huge monitors and projected images on a big wall in front of them. Apparently, launching a web app is serious business. They even have a live web feed, which primarily broadcasts video of some guy standing at the back of the room scratching himself.

So, if you think this is all incredibly surreal like I do, I invite you to take any of the above images, download Comic Life, and have some fun. Here’s my stab at it:

While observing the hullabaloo surrounding the Rails community in recent days, one meme kept popping up that struck me as simply not true: The notion that the Rails community is centered around a group of self-aggrandizing rock star programmers, namely DHH and his core team. This cannot be further from reality. The strength of Rails lies in the vast, diverse community of developers who have sought time and time again to help each other out, to teach others, and to share code, primarily because it gave them joy to do so.

As a complete nobody in the Rails community, I’ve done much more observation and learning than I have done sharing these past few years. As such, I’d like to share with you a list of people in the Rails world who have established themselves not through their status or through the force of their personality, but through their output.

• Dave Thomas – The author of the Programming Ruby/PickAxe book, and the main author of the first few editions of Agile Web Development with Rails, Dave was probably the guy who taught you Ruby and Rails.
• David Black – The author of the now-classic Ruby for Rails (refreshed edition coming out soon), David provided some essential reading for the Rails developer looking to harness the power of Ruby. Also director of Ruby Central, the organization behind RubyConf and RailsConf.
• Jamis Buck – A guy who whittles wood in his spare time while living in Idaho, Jamis created the invaluable Capistrano deployment tool to help us automate away tedium. He used to be on the Rails Core team, so putting him here may be fudging the list criteria, but his contributions have been so huge (both his projects and his blog posts), that he deserves a mention.
• Ezra Zygmuntowicz – Literally writing the book on Rails deployment, Ezra did the hard work of figuring out what exactly constituted a solid Rails stack when the existing options left plenty to be desired. He has since worked on a myriad of projects, including Merb.
• Yehuda Katz – @wycats may be the man who saves Rails from itself. As the lead driver for Rails 3.0, he’s already begun sharing the gory details of the Merb/Rails merge to the eagerly waiting masses. He’s also contributed greatly to jQuery, Merb, and Datamapper.
• Leah Silber – Whenever you go to a regional Ruby conference, you’ll always see Engine Yard as the top sponsor. While EY may send Ezra, Yehuda, and others to present at these conferences, it’s the behind-the-scenes help provided by Leah and company that really make a conference successful.
• David Chelimsky – Behavior Driven Development is a complete win that we in the Rails community get to enjoy, and as lead developer of RSpec, David has shown a solid and steadfast commitment to continuously improving the tool so that it in turn improves our software.
• The Thoughtbot team – This company’s work speaks for itself: Shoulda, Factory Girl, Paperclip, and Hoptoad.
• Ryan Bates – Putting out one or two RailsCasts a week for over two years, Ryan has been amazingly consistent both in the quality of his work and in his dedication to helping us become better Rails programmers.
• John Nunemaker – RailsTips may be the most consistently helpful of all the Rails blogs.
• The GitHub team – Even without considering the contribution the site itself has made, the developers behind GitHub have contributed some fantastic projects to the community, namely Cheat, cache_fu, Jekyll, and god, and they’ve done plenty of helpful blogging along the way.

The people above have written essential libraries, authored books, produced other educational material, and/or helped organize conferences. In other words, they’ve taken the great technical work of the Rails Core Team, and created a community around it.

The above list is by no means comprehensive. So if you believe I’m missing someone, please leave a comment below. Also, in addition to Jamis and Yehuda, there are many of members of the Rails Core team who do it for the music, so to speak, and nothing else. But hopefully the list above conveys the point that Ruby on Rails is so much more than DHH and its small group of core committers.

“This is the real Future of Web Apps conference,” I thought to myself during the first day of JSConf 2009, the first Javascript-focused conference. Upon further reflection of the weekend, I realize that my idea of what a web application can be, and more importantly, how it should be created, has been fundamentally altered. The web browser, usually thought of as a dumb, thin client, is actually full of unrealized potential. It’s time that we, as web developers, tap that well and create a tidal wave of innovation. (This idea was championed by conference organizer Chris Williams in an impromptu lighting talk during the conference.)

In short, we should treat the web browser as a first-class development platform, and Javascript as a Serious Language™. No longer just for presentation, a browser can process business logic, and it can talk directly to our data stores. In offline mode, it can talk to its own data store and sync up later. A well-written application for the browser can give our users a markedly better, smoother experience. For developers, browser-centric development can help us deliver better applications faster, continuing on the promise of agile web frameworks like Django and Rails.

JSConf opened my eyes to the work already under way to accomplishing those goals.

The Frameworks

The two “killer” frameworks out there today are SproutCore and Cappuccino. Both aim to give users a Mac OS X-like experience on the Web. SproutCore is what powers Apple’s MobileMe and OtherInbox, while Cappuccino powers the Apply Keynote-like 280 Slides.

Francisco Tolmasky of 280 North kicked off the conference with an overview of Cappuccino and Objective-J (an Objective-C-like superset of Javascript) and a drawdropping demo of the nib2cib utility, which allows a Mac developer to use XCode’s Interface Builder to construct Cappuccino interfaces. Overall, it appears that Cappuccino is targeted at Cocoa developers.

SproutCore, on the other hand, is a Ruby gem, uses ERB for templating, and supports Rubyish concepts like Mixins. Mike Subelsky, co-founder of OtherInbox and upcoming speaker at RailsConf, presented on SproutCore on day 2. He stressed the importance of Key-Value Coding and Key-Value Observing in his talk, concepts which I admit I don’t yet fully grasp. Interestingly, it looks like SproutCore is in the early stages of iPhone support.

Speaking of the iPhone, a mobile framework called PhoneGap was presented as well. Currently targeting iPhone, Android, and Blackberry (with Palm Pre, Windows Mobile, and Nokia on the way), PhoneGap lets you write your web app (in HTML+Javascript) once, and have it available for all supported platforms (along with proper skinning for the target platform). PhoneGap also comes built in with offline storage support, and does other nice things for you like geolocation and harnessing the accelerometer.

One final framework worth mentioning is Titanium. This is the easiest to explain: it’s Adobe Air or Microsoft Silverlight, but using HTML/CSS and Javascript instead of proprietary languages. A Tweetie-like app was demoed by Appcelerator CEO Jeff Haynie, and it was certainly impressive.

Something that wasn’t presented, but I was given a demo of by a Mozilla employee, is Bespin, which is a web-based code editor harnessing the CANVAS tag in HTML5.

Dealing with Data and Processes

One of the negatives associated with Javascript has been a lack of options when it comes to data persistence. In recent years, we’ve seen support for Gears and HTML5’s WebStorage implemented in the browser, and these suffice for most use cases. There’s also been talk of CouchDB in the browser.

Gears also supports the notion of a worker pool, and Firefox will soon have Web WWorkers, both of which allow arbitrary Javascript to be executed in the background. For real-time messaging, Jack Moffitt presented on Strophe.js, a library for writing XMPP clients, which improves on the Comet) concept that popped up a few years ago.

Browsers Almost There

With the pending releases of Safari 4, Firefox 3.1, and Google Chrome 2, there’s an arms race among browser camps to see who can come up with the best and fastest Javascript engine while building in the most comprehensive support for HTML5. That’s definitely a Good Thing. Who wouldn’t want to write code for a development platform simultaneously supported by Apple, Mozilla, and Google?

So, what about Internet Explorer? The latest version (IE8) does support some, but not all, of HTML5, and Gears is available for storage and threading. But I think this is an issue where we developers need to draw a line in the sand and send a clear message: Either Microsoft catches up with the others, or it gets left behind. If we treat Internet Explorer as a dying platform, it will become one. I’m talking about all version of IE, not just the oft-maligned IE6.

There’s More

For a more comprehensive blow-by-blow, see Michael Harrison’s recap. Conference organizer Chris Williams penned a recap.

For Defogger, the user should be able to paste in a URL (or click on a bookmarklet when on another web page) and get back a defogged, enhanced view of the content. Using OpenCalais, Defogger can figure out the important people, organizations, events, and relationships contained in a news article. While OpenCalais does accept HTML as input, it assumes that everything in the HTML is fair game. For example, putting this AP article hosted on Google through OpenCalais will return “Google” as a company mentioned in the article, when in fact Google is only detected because its name is contained in all the extra clutter around the content of the article.

So I needed a way to remove that extra clutter and pass on exactly what mattered to OpenCalais. Interestingly, I had seen this problem already solved with a bookmarklet called Readability, “a simple tool that makes reading on the Web more enjoyable by removing the clutter around what you’re reading”. Try out the bookmarklet on some websites to see for yourself. It seems almost magical, and comes in handy all the time, especially for long articles, or for reading on the iPhone.

Luckily for me, Readability is open source, with the code hosted on Google Code. It was just up to me to translate the Javascript algorithm into Ruby. So here’s my version of the code:

I’ve commented the algorithms thoroughly, and Ruby is quite readable, so it should be easy to follow. Essentially, the code takes advantage of several common conventions used on modern websites:

• An article (or blog post or press release) is coded in HTML as a lot of text enclosed in <p> tags.
• Those <p> tags are grouped together, usually under a containing <div> element.
• Written English contains a lot of commas.

Using those observations above, along with a few other tricks, the code assigns points to all elements that contain paragraphs on the page, and the containing element with the highest point value “wins”. To use this, it’s a simple pluck_article('http://www.path.to/some/article').

I’ve tried the method above out on the sites of the New York Times, Google AP News, Wall Street Journal, Huffington Post, Athletics Nation, and even a press release on Nancy Pelosi’s site. All worked pretty well. The one platform where the algorithm breaks (both for my implementation above and for Readability) is on Scoop, the blogging platform behind Daily Kos and MyDD. Specifically, the parsing doesn’t work on blog posts that have a long extended entry (usually diaries). This is because Scoop generates a blog post’s main entry and extended entry as two separate <div> elements, and the extended entry <div> ends up “winning”. That’s not at all semantically correct, but I don’t expect it to ever be fixed. Subsequently, SoapBlox sites (like OpenLeft) also have the main entry problem, as SoapBlox is a direct port of Scoop.

I’ll sleep on the problem with Scoop/SoapBlox, but I’m pretty happy with the solution for now. Next up for Defogger: building the page templates using Haml, Sass, and Compass.

The Apps for America contest put on by the Sunlight Foundation is happening right now, and submissions are due on March 31st. Like any respectable software developer, I’ve put off working on my idea for far too long. With two weeks left to go, I’m finally getting around to working on it, most recently coming up with some mocks of the home page:

I’ll likely go with the second mock, as the Capitol background is a bit too busy and won’t work well for the interior, information-heavy pages. In the spirit of transparency, I’ve decided to “liveblog” the entire process of creating the app during these next two weeks. I hope to share design decisions I make, problems I run across, and things I learn. Knowing that I have an audience will hopefully spur me on to create something really good, and maybe will encourage others to attempt an app of their own before the contest is over.

So what’s the idea behind Defogger? It’s a simple app that uses OpenCalais to semantically mark up a news article (or a blog post or a press release), and enhances the marked up document with transparency-related APIs. So imagine giving Defogger an article about some member of Congress presiding over the groundbreaking of some multi-million dollar project funded with stimulus money. Defogger would answer some of these questions:

1. The Politician: Which district does he represent, and for how long? Who are his biggest contributors? Are any of them mentioned in the article? Did this member of Congress put in an earmark or otherwise grease the legislative wheels for this project?
2. The Construction Company: Does this company employ lobbyists? How much money have they contributed to members of Congress, and are any of those mentioned in this article?

Like any good side project, I’m using Defogger as a means of learning some new tools and techniques:

• jQuery: I don’t know this Javascript framework nearly well enough, and usually need to defer to other teammates for their expertise. I want to become a jQuery ninja when this is all said and done.
• Shoulda, Factory Girl, and Mocha for Behavior-Driven Development: I’m comfortable with RSpec, but I know that Shoulda is what the “cool kids” use in the Rails world, and I definitely could do BDD and TDD much better. I hope to build the entire app this way. I employed full BDD with the Sunlight API Gem to great success.
• New Rails Features With Rails 2.3 just released, it’s been far too long (since maybe Rails 2.0) since I did a $ rails my_new_app on the command line. While Rails has been pretty stable these past two years, there are a lot of goodies that I’ve never learned and tidbits I have yet to pick up. I hope to fill those gaps with this project.
• Haml + Sass, and Compass: While I don’t have the best web design chops, I like to think I can hold my own. However, the process of skinning a site is always painful, and I’m constantly looking for ways to produce better, more maintainable, front-end code.

37signals likes to tell us to embrace constraints. Hopefully, I’ll learn that lesson and more throughout these next two weeks. Please consider subscribing to my feed if you’d like to come along for the ride.

This release includes support for two new fields on Legislator, a refactoring of the base functionality so that the gem is more compatible within Rails and Merb apps, and support for Lobbyists, Filings, and Issues. There is a new way to set up your Sunlight API Key, so this release is not backwards-compatible with releases 0.1. and 0.2.

This gem is now considered a feature-complete wrapper around the Sunlight API, and will be bumped up to 1.0 after being used for a bit in the wild.

GitHub

RubyForge

Changelog:

• Warning: This release is not backwards-compatible!
• Change loading behavior of base functionality, works better with Rails and Merb
• Sunlight::SunlightObject is now Sunlight::Base
• For set up, Sunlight.api_key= is now Sunlight::Base.api_key=
• For set up, using “include ‘Sunlight’” is no longer recommended
• Correct usage is Sunlight::Legislator.all_for(...) instead of just Legislator.all_for(...)
• Credit to Rue the Ghetto (rughetto on GitHub) and Eric Mill for inspiring the improvements above
• Add support for senate_class (“I”, “II”, or “III”) and in_office (0 or 1) on Legislator
• Add support for Lobbyists, Filings, and Issues
• Huge credit to mindleak on GitHub for Lobbyist-related functionality

Back in August, I released an initial version of a Ruby gem for the Sunlight Labs API. The gem has since been used in many projects, most famously on Tweet Congress.

This weekend at Transparency Camp, I set out to improve several aspects of the gem, including adding a twitter_id field, which wasn’t there back in August when I made the initial release. Changes include:

• Add support for twitter_id and youtube_url on Legislator
• Add Legislator#search_by_name for fuzzy name searching
• Add Legislator#all_in_zipcode for better lookups on a five-digit zip code
• Raise exception when API Key isn’t set
• Credit for various fixes goes to GitHub users pengwynn, hoverbird, and wilson

Check it out on GitHub. Ruby developers participating in Apps for America will hopefully find it indispensable.

Over the last eight months or so, my blog about software development at Salesforce on Rails, has been criminally neglected. The cause has been twofold. First, I’ve just been incredibly busy, but that’s a tired and lame excuse. More significantly, I’ve largely stopped working with Salesforce.com and the Force.com development framework, for reasons I’ll get into later. So Salesforce on Rails is now retired, and I’ll instead be blogging about software development here at LuigiMontanez.com. Old entries from Salesforce on Rails will be migrated below this one.

So LuigiMontanez.com is now my place to blog about software development technologies, and also about becoming a better programmer. I’ve been heavily into the idea of software craftsmanship lately, facing the harsh reality that I have enormous room for improvement as a software developer. I’ll still blog about the intersection of potitics and technology at Leftmost Bit, so please do grab that feed if you’re interested.

What’s next for LuigiMontanez.com? Well, in addition to sharing my efforts on becoming a better software developer and project lead, I’ll be blogging about these technologies that are currently piquing my interest:

• Ruby and Rails
• jQuery
• CouchDB

I’m also planning to participate in the Apps for America contest put on by Sunlight Labs. My submission will harness Open Calais and the various government transparency APIs, creating a tool to allow users to clear the fog about some of the non-obvious connections between our elected officials, special interests, and the laws and policies coming out of government. It’ll be called Defogger.org.

Compelled by the contest’s spirit of transparency, I’ll be blogging the entire app development process right here, from start to finish. With the contest deadline set for March 31, I certainly need to get started on the project sooner than later, and what better way than to force myself to blog about it on a regular basis.

Stay tuned!

This article by Robby Russell reminded me of a hopefully helpful post I’ve been meaning to write for a while. The problem is straightforward: You’ve got Phusion Passenger set up on your Mac OS X Leopard (see Robby’s post for details). Your client called, and they say the site you just launched for them looks funky in Internet Explorer. Fun. So now, you want to access your local Passenger site living at http://myapp.local from the copy of Windows Vista living in your VMware Fusion.

There are two things you need to do in order to access your Passenger sites from Windows Vista via VMware Fusion:

1. Figure out what Vista thinks is your Mac’s IP address
2. Create entries in Vista’s /etc/hosts file (yes, Vista actually has one)

So fire up VMware and Vista, and let’s begin:

Determine Vista’s Gateway IP

When running VMware Fusion, the virtualized OS (in our case Vista) refers to the host system (Mac OS X Leopard) as its IP Gateway and its DNS. So you want to figure out what that IP address is, and you’ll be able to access the Apache server running in Leopard. Determine the IP with the following steps:

1. Open the Control Panel, switch to Classic View, open Network and Sharing Center.
2. Click on Manage Network Connections in the sidebar.
3. Double click on the Local Area Connection, and click on the Details button.
4. Make note of the IPv4 Default Gateway – that’s your ticket to accessing your Passenger sites.

Edit Vista’s /etc/hosts file

I discovered this handy link, which tells you all you want to know about Vista’s hosts file. In short, it works pretty much the same as any Unix /etc/hosts file. I followed the instructions to set up a shortcut on my Vista Desktop for quick access, and the screenshot of the Properties dialog for that shortcut is below:

Now, just edit the file, creating an entry for each Passenger site:

172.16.160.2 site1.local
172.16.160.2 site2.local
172.16.160.2 site3.local

With the file saved, you should be able to access your Passenger sites from a browser in Vista (no restart of anything needed).

Multiple IEs

Now for a bit of a bonus, I highly recommend installing IETester in Vista. IE8 beta 2, IE7, IE6 and IE5.5 will be at your fingertips.

Find this helpful? Please consider recommending me on Working with Rails.

Browsing through the Force.com Discussion Boards while playing with the new version of the Force.com IDE (released June 19), the ever helpful JonP explained exactly how to generate a .object file on standard objects.

Fire up Eclipse, and in your Force.com project open up src/unpackaged/package.xml. Find the XML element with the name of “CustomObject” and add in some new subelements with the value of the standard object. It should look like this:

<types>
    <members>*</members>
    <name>CustomObject</name>
    <members>Contact</members>
    <members>Account</members>
</types>

Then, run the “Refresh from Server” functionality by right-clicking on src/objects and accessing the Force.com menu. Your standard objects should then appear.

Alternatively, if you’re paranoid about too many custom fields being editable (and quickly erasable) in the IDE, you can stick in an entirely new types element named CustomField that looks like this:

<types>
    <members>Opportunity.SomeCustomField__c</members>
    <name>CustomField</name>
</types>

Now, you’re able to use the power and speed of the IDE to create, edit, and deploy custom fields on your standard objects. It’s a great productivity win. A big thanks to JonP for explaining all this.

While computing moves more and more to the cloud, it’s interesting that Ruby web development best practices tend to go in the opposite direction, toward the workstation right in front of you. Running a local web server via ‘script/server’ (or my preferred method of ‘thin start’), hosting gem documentation locally, and using local git branches are all win/win practices because they’re far more efficient, and frankly, let you do some bonehead moves without your co-workers ever having to know.

So maybe deployments should be practiced locally as well. Ezra Z. has announced Engine Yard Express, a VMware image that’s essentially an Engine Yard production slice. The idea is that you run the image via virtualization software on your workstation, so that you can get all the benefits of a virtual server without having to actually connect to one through the Tubes.

Yes, this really rocks. You’ll be able practice deployments on the plane!

So first, you’ll need to buy VMware Fusion for your Mac. I first purchased Parallels over a year ago, but VMware clearly kicks its ass. Clearly. It actually runs Windows without making the rest of your system unusable.

Next, download the image and double-click on it. Before you even realize what happened, you’ll be presented with a ready, fully-functional slice just waiting for you like an obedient dog:

You’ve been pleasantly provided with randomly generated passwords for the root and express users, and you’re even given the IP address it’s chosen.

Let’s create an alias for that address so we don’t have to memorize it. Open up /etc/hosts in your favorite text editor (requires sudo permission) and stick something like this in there:

192.168.233.128 express.local

Now, you should probably just leave your VMware window alone. Instead you’ll want to SSH into the slice as if you were logging into a remote server:

$ ssh express@express.local

Nice! A quick visit to http://express.local:81 gives you your Merb start page.

Now, in your Capistrano scripts, you can use ‘express.local’ as the domain of your servers, and you’ll be able to practice deployments without ever connecting to a remote server. Bom chicka wa waa!

When I first started playing around with Ruby on Rails, one of the things that struck me was how development was done completely locally. Instead of uploading or synchronizing your source code to a remote web server, you simply fired up a Ruby web server process on your local machine, and the development process seemed to flow more smoothly.

In that same vein, documentation for Ruby gems can be annoying to hunt down. You have to go to the gem’s web site, and hope that RDoc exists somewhere. Or, you can navigate to your gem’s local install directory and poke around in there. Too much work, and it could break your flow. Not anymore:

$ gem server

Now, just visit http://localhost:8808, and you’re good to go. That easy!

Also, you may find yourself missing RDoc on updated gems, so make sure to do this when it bothers you:

$ sudo gem rdoc [--all|gem_name]

Now, it would be great if the server just started automatically on boot up, with no need for a command line directive. In Mac OS X Leopard, the preferred way is to use launchd/launchctl, which is about as obvious to the uninitiated as the rules of Cricket. Luckily, there’s Lingon, which wraps all that ugly XML in a nice GUI. Make a new entry that looks like this:

Note the full path to the gem command, which I needed for the launch command to work. And that’s it. Full documentation to all your locally installed gems, available whenever you need them.

Special thanks to Daniel Fischer for the ‘gem server’ tip, and Brandon Beacher for the tip on Lingon.

Because the Force.com developer community is still very small, it’s important to make the most out of what Salesforce.com (the company) provides for us on the Web. The best site for all things Force.com is of course developer.force.com, with its invaluable Wiki and Discussion Boards. But sometimes dead-tree versions of knowledge can be helpful too.

Ebooks

SFDC has made available two free books, one is an introduction to the platfom and the other is a recipe-style book. If you’ve been to a Force.com event recently, chances are you received these as actual, bound books. Here are the PDF ebooks:

• Introduction to the Force.com Platform – Really a beginner’s guide, this book takes you on a feature tour of the Force.com platform, and goes over both administrative/declarative features as well as the more programmatic Apex and Visualforce capabilities.
• Force.com Cookbook – I find myself flipping through this problem/solution recipe book often. It’s very helpful at producing those “Ah! So that’s how I’m supposed to do it!” moments.

The APIs

The Force.com Application Programmer Interfaces (APIs) allow us developers to integrate our Salesforce instances with external web services, as well build in some powerful customization into those instances. I don’t print these out, but rather just keep the PDFs quickly accessible for fast keyword searching:

• Apex Web Services API – Covers the SOAP API in all its glory. I personally wish this was REST, but SOAP is better than everything but REST.
• Apex Metadata API – A newer API, the Metadata API allows us to define the structure (fields and relationships) of our custom objects via XML rather than via the declarative point-and-click interface. Unfortunately there’s no Metadata API available for standard objects (Contacts, Accounts, Opportunities) yet, but I expect that to change this year.
• Apex AJAX Toolkit API – The AJAX Toolkit is primarily used with S-Controls, which are being phased out in favor of Visualforce. To be honest, the AJAX Toolkit has always seemed like a workaround hack to me, and hopefully the combination of Visualforce and Apex Code will render it obsolete.

The Developer Guides

These are must-prints. As more thorough extensions to the ebooks above, these guides are the definitive resources for developing with Apex and Visualforce.

• Apex Developer’s Guide
• Visualforce Developer’s Guide

Frequent Updates

Both the APIs and Developer Guides are updated with every release (Spring, Summer, Winter), so make sure to grab the newest versions when you see your org being updated, and please do recycle the old versions if you print them out.

I suggest bookmarking this post, so you can quickly access these PDFs instead of browsing through the developer.force.com Wiki. Enjoy!