Check out this direct link to “Jason Goldberg’s keynote speech”:http://www.jobster.com/corp/erewebcast_view.jsp at the Electronic Recruiting Exchange conference in Boston. The feed is streaming video and audio.

For rapid prototyping, I’m a fan of “Ruby on Rails”:http://www.rubyonrails.org/, for its lightweight, painfree MVC model.

For large projects worked on by a number of developers, however, Ruby and other lightweight frameworks have limitations. The implicitness that makes Rails so lightweight becomes a challenge as team size increases. (I realize not everyone will agree on this point, but I’m betting there are many who will.)

For instance, there’s no file checked into the source tree that fully describes a model object– I have to browse the database to understand what the object is. There’s also no overall map of all of the pages and associated policies exposed by the application, which is implicitly represented in the filesystem and the source code.

For large scale web development, I like “Spring”:http://www.springframework.org. A single configuration file maps out the entire structure of my web application and the wiring and configuration of the components. At a glance, I can see that a given set of pages has a given security policy. Adding a single line allows me to apply additional interceptors that add new policies.

But Spring is painful for rapid prototyping and iterating because of the frequent need to modify configuration files, rebuild, and restart the application server.

Is it possible to have the best of both worlds? Can we have a rapid prototyping environment that leverages all of our existing Spring investment, and which allows a smooth transition from prototype to production quality code?

We’re currently working a project that we believe will do just this. We have a generic Spring controller, enabled only in development environments, that enables rapid prototyping of pages using the Groovy scripting language for controllers and JSP pages for the views.

I can mock up the presentation by just dropping “foo.jsp” into a directory; depending on the directory I drop it into different sets of standard interceptors are applied (e.g. to require a user login.) I can rapidly prototype a controller behind the page by dropping “foo.controller” into the same directory.

Groovy can import any Java package call into any Java object, so I can reuse all of my existing business logic. Because it’s a scripting language, I can create and modify controllers with the same speed and ease that I update JSPs. Later, I can seamlessly transition to a full fledged Java controller by updating the Spring configuration appropriately; no changes to the view are required.

We’re in the early days of this project, but it seems likely to be useful already. When this is a bit mature, we’ll release it under the GPL for others who are interested in combining rapid development and Spring.

One of the things Alan does really effectively is build a dashboard that lets us track how we’re doing on each release. Understanding where we are and communicating that through the company is essential to making the right course corrections to ship on time.

Alan “discusses an especially helpful chart”:http://www.drizzle.com/~asteele/2005/09/test-coverage-chart.html he uses to communicate status.

Adam Bosworth at the Salesforce.com conference on “Intelligent Reaction”:http://salesforce.breezecentral.com/intelligentreaction/.

Most intelligent people today know that evolution is not the result of intelligent design. There was no grand plan that we’ve been tending towards. It is merely a reaction to the environment. Doing those things that cause you survive better in your environment and evolve accordingly.

Software is evolving in the same way. It’s not about intelligent design. It’s about intelligent reaction.

• Run like mad
• Try things out, watch, learn
• Iterate
• Learn from customers in real time
• Real apps, APIs follow
  

(A biological purist might say that Adam is actually espousing Lamarckian ideas, but I get his point.)

One of the unique capabilities in Jobster is the ability to display a clickable map of the entire US showing all jobs that match the users search.

When the user clicks on a region in the map, the display zooms to show all matching jobs in that region overlaid on Google maps.

Mark Maunder is the smart guy who built this; on his blog he shares some of the SQL tricks he devised to make radius queries lightening fast.

The typical approach in SQL to finding all locations within a given radius is to first find all locations with a square bounding box that encloses the radius, then use a precise (but expensive) distance function to eliminate points in the box but outside the circle.

This is not terribly inefficient, but certainly not optimal– it would typically turn into an index seek on latitude, another on longitude, an intersection operation to find points within the bounding box, and then a series of per-point radius computations.

Marks clever trick is to trade off space for time– in pure SQL he builds an enormous lookup table that gives the distances between all pairs of locations. This table only needs to built once and makes all subsequent radius queries significantly faster. Adding an index on source latitude, longitude, and distances allows to do the radius query in a single index seek. If there is maximum radius you care about, the size of the table can be reduced somewhat by eliminating pairs of locations further apart than distance.

In the wee hours of Saturday morning, the Jobster team rolled out Joster 2.0, and with it two significant new features– Jobster Search and Jobster Rank. You can try out Jobster Search at www.jobster.com.

I’m writing to give you an advance look at some of the features you’re hear about in the official press release this Wednesday, and on Thursday when Jobster CEO Goldberg unveil Jobster 2.0 at the Electronic Recruiting Exchange Conference in Boston with a live “webcast”:http://www.jobster.com/corp/erewebcast.jsp.

Jobster search lets you find jobs anywhere on the web. Jobster Rank is to people as PageRank is to pages– it’s a patent pending way to rank the “relevance” of professionals for a job based on the strength and quality of their links with a company that uses Jobster.

Here’s how it works. When you search for jobs, Jobster searches both company web sites and job boards to find the best matches.

This icon indicates jobs that you can get referred to. Jobster helps professionals find a qualified referral and get noticed through a short chain of trusted connections to the company.

Obtaining a referral from someone the company trusts is one of the ways a professional can increase his or her Jobster Rank.

A high Jobster Rank increases the automatic “star rating” of prospects as seen by the recruiters, and causes them to sort to the top of the list. The most worthy prospects get noticed first, while resume spam is filtered away.

(Implementing Jobster Rank efficiently was an interesting technical challenge, because it considers all of the connections and interactions between an individual and a company out to several degrees. Jobster Rank is incrementally updated through a set of Oracle triggers in conjunction with nightly jobs for the really complex calculations that do not need to be real time.)

The recruiting departments and hiring managers of a number of “leading companies”:http://www.jobster.com/search/companies.html are using Jobster. If you are part of a company that is interested in using Jobster to build a talent network, instructions are on the Jobster web site.

I was stuck in horrible traffic on the way to work today, and pondering ways to fill the time.

It struck me that there’s probably a business opportunity for a provider of enabling technology for listening to podcasts (and other pre-recorded voice content) via standard voice calls.

Here are the “ABCs”:http://www.marketingplaybook.com:

A. There is growing interest in podcasting, and an increasing quality and diversity of podcast content available without charge. Cellphone carriers are always eager to increase their billable minutes.

B. But there’s no good and affordable way to listening to podcasts on plain old cellphones¹.

C. So why not create a service that allows users to listen to podcasts and other prerecorded audio content via a standard call on any cellphone, without the complexities of mobile data or software installation.

The cellphone carriers could do the heavy lifting for promotion and billing. The technology provider would do the technical heavy lifting of providing large numbers of voice streams, leveraging advances in VOIP technology to do so efficiently and affordably.

¹ Phone applications such as “Melodeo’s”:http://seattlepi.nwsource.com/venture/237187_vc19.html or “pod2mob”:http://www.pod2mob.com/main require you to install software of your phone and incur expensive per minute charges. I even saw one application which delivered podcasts as a series of ringtones.

“Squid”:http://www.squid-cache.org is a popular and full featured proxy cache.

We have created a small patch for Squid which adds support for extended cache control directives (x-always-cache and x-cache-key) that are designed for use with farms of web crawlers for which extremely aggressive caching is appropriate. Essentially, these directives give the client total control over the lifetime and naming of pages in the cache.

This patch is being submitted for consideration to be incorporated into the main Squid code base, but in the meanwhile we are making it available for general download.

“Read More”:/blog/projects/squid-enhancements

Jobster has a “20% for innovation program” for our developer team, loosely modeled on Google’s 20% program. We consider the program a success because it has resulted in several interesting features that will graduate into the core product and that are important to our business (for example, relationship based job feeds, Jobster groups, and Jobster rank for prospects.)

In this post (part of a “continuing series on innovation”:/blog/category/innovation) I’d like to share some of the features that we’ve identified as important for a successful innovation program.

Doing repeatable innovation is hard. A number of ingredients have to come together: the right people, the right investment and buy in, the right relationships and rituals for collaborating on innovation, and the right process for translating innovation into product.

First, a successful innovation program requires the right people on the boat… the sort of developer who will get bored and quit the company if not given the chance to innovate, who can combine technical creativity with an understanding of the overall business to come up with something unique. A past post on “hiring innovators”:http://thebogles.com/blog/2005/09/hiring-innovators/ talks about ways to help identify these people.

Second, 20% for innovation requires that upper management truly buys into the concept and all of its ramifications.

• Innovation isn’t free: 20% for innovation means investing 20% of your development resources towards that goal, and accounting for that investment in the schedule and the engineering budget. I consider it a great credit to our CEO Jason Goldberg that he fully bought into the concept and the investment that entails.
• Along with investment of resources, innovation requires a considerable amount of trust. It’s easy to desire an innovation program, but then want to add on twelve layers of approval to make sure that the innovation is relevant and likely to succeed. That defeats the purpose of the program, which is to enable smart people to go a bit out on a limb without spending all of their energy achieving consensus first.
• Reserving 20% for innovation requires accurate scheduling. If you attempt to reserve 20% for innovation but underestimate the time required for your release by 50%, not a whole lot of innovation is going to happen. Jobster is blessed to have a Alan Steele as our VP of Engineering; he has an uncanny ability to derive accurate schedule estimates and ship on time.

Third, innovation requires the right processes and rituals to increase the likelihood that the innovation is relevant and finds its ways into the product. The great thing about innovation is that it can lead to collaboration between different parts of the organization that otherwise interact too rarely.

A key Jobster ritual is the innovation bash. It’s an informal, social affair rather than death by Powerpoint. There are snacks and drinks; a gathering of folks from across the company wanders casually from desk to desk, and developers show off their projects followed by discussion. The gathering considers how the features can be used and how they can be improved to solve problems in the business. The net effect is a sharing of ideas and needs, and a cementing of ties and relationships across the company.

Finally, the right innovations need to find their way into the product. I think Google has the right idea with their Google Labs, and we’re emulating this feature in a Jobster labs, which will be unveiled shortly in our 2.0 release. Labs are important because many ideas will fail or at least not be ready for primetime in their initial conception. You need to carve off a space in your application or service were it’s OK to take risks and fail, and where the testing requirements are reduced. A failure in the labs must not cause scale or security problems in the core product, or serious harm to the consumer. Customers must be given realistic expections in the terms of service (and in line or two of text they actually read!) about the things that might go wrong.

Though it isn’t free, a good innovation program pays off greatly in the medium to long run. It delivers features that would never happen otherwise, or that would cost much more under a standard process. Equally important, it helps attract and retain the best people.

Here’s a rundown of what’s new with the Berry 411 local search tool.

• Berry 411 has hit #5 in Rimroad’s list of “popular Blackberry software “:http://www.rimroad.com/software/popular1.html .
• Several new plugins of interest to sports fans have been added: “nba:”, “nfl:”, and “mlb:”.
• “Support forums”:http://thebogles.com/forums have been to added to the Berry 411 site.

A number of bugs have been fixed.

• Fedex package tracking has been fixed.
• Yellow page phone numbers use “tel:” links, which work with a wider variety of phones.
• The user is now correctly warned when they use an address not found in Google local.
• A bug that could cause exceptions in the shopping plugin has been fixed.

The following features are being considered for development. Your feedback and suggestions are welcome.

• Mobile friendly forums for discussing local restaurants, events, etc.
• Address book integration (for OS v4 only)
• Local directory– a responsive directory of links for local information (news, weather, sports, etc) built into the Berry 411 app.