For a time, Twitter planned to allow firehose access through a service called Gnip, but in October stated that they would instead work on providing access themselves.  Since then, details have been sparse on the timeline or methods for which access will be given.

Last week however, some more information has been quietly released by means of an FAQ on the Twitter API website.  Here’s the question and answer in full (emphasis theirs):

When will the firehose be ready?

By late January, early February 2009. For at least Q1 2009, the “firehose” (the near-realtime stream of all public status updates on Twitter) will only be available to a small group of trusted partners. The firehose is a stream HTTP solution; a client connects to it and the stream begins, ceasing only when the client disconnects. Once we’re confident in the stability of the service, we’ll add partners on a case-by-case basis. We may allow a wider selection of clients to consume subsets of the public stream (that is, updates from a collection of user IDs or matching specific search terms). We do not intend to allow anonymous, unregulated public access to this stream for any number of legal, financial, and technical reasons.

There’s a few pieces of new information here.  First, that some kind of beta group will be given firehose access within a few weeks, using HTTP streams.  This sounds similar to the solution provided by Gnip to their users.

Perhaps more important though is the news that a full public stream of the type previously provided will not be returning.  While providing subsets of the public stream could be useful for things like groups, without the full firehose it’s very difficult (if not impossible) to provide a feature like real-time tracking, which has been eagerly awaited.

The three pieces of rationale for not making the firehose public (“legal, financial, and technical”) each bring up additional questions in turn.  Legally, is there a difference between providing public tweets in a full stream and providing tweets publicly by user (which requires knowing the username ahead of time)?  Do the financial motivations refer to saving money on servers and bandwidth, or by making money in providing access for a fee?  And technically, are the existing solutions (such as HTTP streams or XMPP) insufficient for the task, and if so, how?

Earlier this afternoon David Heinemeier Hansson and Jason Fried from 37signals did a live webcast in which they answered questions and talked about some of their upcoming projects.  They spoke about their upcoming book, plans for integrating across all their products, and how they feel about the iPhone and Android.

Architectural Changes

37signals has been trying out Amazon’s EC2.  Rather than implementing it across all their products (a big decision to make, and time consuming to implement) they’ve started by trying it out on Tadalist, which is their smallest and simplest product.  This exemplifies one of the methodologies they use: avoiding huge decisions by first trying small implementations.

They also did this with regards to translations.  Translating all 37signals products into multiple languages is a scary idea.  So instead, DHH tried translating only Basecamp to Danish, the other language he speaks.

New Features and Designs

One of the larger developments 37signals has been working on is a “37 ID”.  This is a global namespace across all of their products, in which users won’t have to login multiple times as they switch products.  It also will aid in product integration, which has been a common question among users.  In the past, they didn’t have a good way to determine which users were the same person across their products.  For example, they wouldn’t know if “dhh” on Basecamp was the same as “dhh” on Campfire.  It will also allow them to start selling their products in a suite, whereby customers could sign up for some or all of the products at once, perhaps with a bulk discount.  37 ID will be rolled out in phases, starting early next year.

37signals has also been working on redesigning the marketing of their sites, and has hired a new designer to work on the visual look-and-feel of their sites.  They’ve started with Highrise.  Below are a few screenshots I took of some of the designs they’ve been working with:

The last picture is what they’re currently going with, and it should come out within the next week or two.

Upcoming Book

A few days ago 37signals announced an upcoming book, with the working title “Unconform”.  The announcement was sparse on details, but today they gave some more information on what to expect. Whereas their first book, the popular “Getting Real”, focused on software development and engineering, “Unconform” is more about business: team structure, hiring, competition, and getting the word out.

One of the main themes of the book will be “small isn’t a stepping stone”. Companies should consider stopping at a small size, and not all businesses need to be massive to be successful.  DHH also described the book as pushing against the “lifestyle-business” idea, that small businesses like 37signals aren’t in the “real world”, or don’t have a “real business”.

Mobile

Jason and David got a few questions regarding their thoughts on the mobile environment, specifically the iPhone and Google’s G1 phone.  They stated that they’ve had an internal debate on whether or not to develop “official” iPhone apps, with the consensus being that they should work on making improvements to their API, and allow third parties to develop applications. They referred to the Twitter model of providing the best API they can, and letting developers work on creating clients on various platforms.

When asked his opinion about the G1 phone, Jason Fried described it as more of a “me-too” device, not having many truly new features like the iPhone.

For those who missed 37signals Live but would like to watch it, you can watch it on Justin.tv.

Here are the three main types of work we do, and why we do them:

1. Web (Rails, Grails, et al): Our bread-and-butter remains in doing web development.  Despite the complexity that HTTP brings you when trying to build an application, there’s still something exciting about the dichotomies that web development brings: web framework and database, server-side and client-side, function and design.  And clearly web companies aren’t going away anytime soon.  For a while now (probably over a year) most of our clients have tended towards Rails, and it’s also our defacto suggestion for new clients.  Lately though, we’ve been doing a bit more work with Grails, which I think is becoming an exciting framework.  We’re also open to some of the older web technologies, like Java or PHP.
2. Mobile (iPhone): Our decision to branch into mobile development was influenced by one main factor: we’re in love with the iPhone!  Luckily, the iPhone is also a pretty good platform in which to develop, and many of the methodologies from web development can carry over.  Our most recent iPhone project was creating an iPhone interface for Invotrak, which shows how web and mobile development can be bridged.
3. New Things!: We pride ourselves on being able to tackle new technologies (see #2 above).  For example, as much as we love Rails, we’d jump at the chance to play more with one of the other Ruby web frameworks, like Merb.  I don’t know what the Next Big Thing will be in a year or two, but I hope that we’ll be playing with it when the time comes!

We don’t limit ourselves to any one type of client.  We’ve worked with public companies, pre-venture startups, individuals, and everything in between.

For anyone interested in talking to us, there’s plenty of ways to contact us, including our website, email, or just leave a comment on this post.

Also, I’m curious if anyone reading this has consulting firms of their own (and/or does freelancing)? Let us know in the comments!

At the SDK event, Apple gave a number of reasons why they didn’t want to support true background processes for iPhone applications:

1. Having lots of applications running could quickly use up the limited resources and battery on the iPhone, causing performance problems.
2. They didn’t want the user to have to worry about managing active programs with some kind of complicated “Task Manager” interface.
3. If applications could continue to run in the background without any visual cues to the user, it would be that much easier for apps to perform unintended/unrequested operations.

I think there’s a way for the iPhone to provide better support for background applications, without breaking the requirements listed above. Think about what happens when you’re on a call, and you tap the Home button. You can launch applications, and pretty much do whatever you like while still on the call. Here’s what this looks like:

You’re aware that you’re still on a call because of the bar at the top of the display, and you can tap to return to the call if you wish. I think background applications could work the same way, and in so doing wouldn’t break any of Apple’s requirements:

1. Only one app could be in the background at a time, so you wouldn’t have lots of apps hogging the resources of the phone. Yes, you’d have another process using resources in addition to the foreground application, but it wouldn’t need to use any of the graphics framework, and in my experience the iPhone would be powerful enough to handle this kind of limited processing.
2. Nothing is hidden from the user. They know exactly what’s happening in the background because they’re being told at the top of the screen, and can tap that bar to return to the app. Another nice benefit here is that perhaps the application could customize what gets displayed in this line, so an app like Pandora could have the row say “Now Playing: Enter Sandman by Metallica”.
3. No Task Manager is necessary. The way users interact with the background app is intuitive because background phone calls already work the same way.

Of course, this isn’t a perfect solution since only one app is running in the background at once. If you want something to run 100% of the time, then you’d never be able to run an additional background app on top of that. However, I think a system like this in addition to the Notifications framework solves most of the desired use cases for background apps: music playing/streaming, location polling, real-time text updates, and so on.

What do you think? Would this kind of system solve the problems you have with background apps on the iPhone?

First, I thought I’d outline the reasons for an alternative to Gmail.  Let me preface this by making it clear that I love Gmail - it’s a great service, but one that has some inherently odd choices that make it less than ideal for an email-heavy user.  Some of Gmail’s most irksome quirks:

• No such thing as folders.  Instead, everything is tagged, which doesn’t lend itself well to being used inside my mail client
• The “All Mail” special tag appearing in my mail client via IMAP, which appears as though I receive two of every email
• Removes duplicates of messages, which means if I send a message to myself, it will never appear in my inbox (instead, it’s always in my Sent Messages tag)
• Not completely reliable.

In terms of reliability, it’s very important to me that the service is always available, and always fast.  I want to receive messages moments after they’re sent - not hours later.  When checking for messages from my other accounts (via POP), Google uses some heuristics to determine how often it should check for new messages.  Unfortunately, this often means it won’t check for an hour or so, which can be very annoying.

So, I’ve been on the lookout for a Gmail replacement for some time, and thought I had found it in Apple’s revamped MobileMe service.  When it was launched, it appeared that Apple was doing email right, but as I’ve learned from using the service first-hand, I’ve merely traded improvements in some areas, for problems in others.  For instance:

• It can’t check foreign email accounts.  This wasn’t a complete deal-breaker, as I have some clever auto-forward email recipes setup which largely solves this problem.
• There’s no way to send mail as a non-MobileMe email account.  You can create multiple “personalities” that give you different @me.com addresses, but there’s no way to send as a non @me.com address.  This is a huge problem, and means I can’t stop using Gmail until this is added to MobileMe.
• It drives me crazy that the web interface often refreshes the entire page.  If I leave it open in a Safari tab for a little while, then return, it seems to refresh.  That’s annoying.
• Another annoyance factor is that whenever I return to the email interface (or whenever the page refreshes), all of my folders are expanded.  I have a LOT of email, and I keep them fairly well organized into many different folders.  I’d like the system to remember what folders I had kept closed.

I should mention that I am a big fan of the push email functionality I get with MobileMe (and is a major reason why I’m still using the service).  Also, the email web interface is clean and intuitive (and matches the Mail desktop app, which scores major points with me).  Compared to the other major email providers (Gmail, and Yahoo Mail, for instance), the MobileMe email interface wins hands-down.

Apple’s MobileMe is a fantastic service, but I just can’t switch yet.  So many different great features are all aligning to make for a killer email product, but the annoyances I’ve outlined are show-stoppers for me (and why I can’t dump Gmail just yet).  I’m more than happy to pay the MobileMe subscription service if Apple could just get these last few details smoothed out.

What’s your take?  Have you considered switching from Gmail to MobileMe?

The Pandora and AOL Radio apps are designed to allow you to stream radio to your iPhone or iPod Touch.  The introduction of fast 3G Internet access on the iPhone represents a significant threat to satellite radio and, to a lesser extent, terrestrial radio.  Consider the implications.  A user has an iPhone that’s the same size as an iPod (or a Sirius Stiletto) that can stream radio while in the car, walking down the street, or inside a building.  The iPhone can hop onto WiFi networks (same with the iPod Touch) or use 3G.  Even Edge connectivity allows for decent streaming.  All that adds up to great wireless access - as good as, or better than, satellite technology, since 3G and Edge connections work indoors whereas satellite doesn’t.

Accessibility aside, the real advantage is the phenomenal flexibility streaming radio provides.  Take Pandora for example.  It’s a streaming radio program for the iPhone that creates a customized radio station matched exactly to your tastes.  But even the simple ability to skip over songs you don’t like, a basic feature of Pandora, is inherently absent from any pre-programmed content station.  Such a simple feature goes a long way to improving your listening experience, and it’s almost embarrassing in the age of TiVo to not be able to skip over content you don’t find interesting.

With greater accessibility and significantly greater flexibility, streaming Internet radio will become one of the biggest threats to satellite radio over the next few years and will become a killer app for the iPhone.  Cell technology is getting better at providing high-speed Internet access, and already there are a number of very good streaming services that match listener’s tastes to music.  As the iPhone becomes increasingly popular among consumers and access speeds increase, satellite will suffer.  Satellite’s only hope to stay competitive is to offer enough exclusive content that listeners won’t be able to part ways with satellite radio without missing their favorite programs, but even that strategy is tenuous at best - it will only be so long before the content creators themselves decide to head for the greener pastures that Internet streaming radio provides.

The Draconis Software website has gone through many different iterations over the years, and I’m particularly happy with the direction it’s going in.  As time goes on, we’ve worked hard to simplify our web presence, putting up only the most interesting and necessary information about our company and what we’re up to.  This has been one of the principal tenets of the web 2.0 design movement, and we’ve certainly practiced this with our clients.

But, enough about our thoughts on the site: we’d much rather hear what you think!  What do you like/not like about the new design?

The following is what I came up with. It's a ruby script that uses the delightful Hpricot gem to parse the xml. It takes one argument, the subversion username that you wish to retrieve the logs for. I hope that it's useful for someone else! You can curl it from http://pastie.textmate.org/197763.txt if that makes it easier, too.

Lately I've been looking for a chance to play with Grails.  Briefly, for those who aren't familiar, Grails is a web framework that uses the Groovy language - an agile, dynamic language designed for the Java Platform.  Grails was meant to use some of the main tenets of Rails (convention over configuration, "Don't Repeat Yourself", et al) while using Java web technologies like Spring and Hibernate.

Fortunately, I was finally able to find a chance to play around with Grails - as a simple way of "porting" an existing Java web application to a dynamic language and framework.  My reasons were the following, which I'd imagine are true for many other Grails developers:

1. The ability to include straight Java code in the project meant being able to re-use existing code, especially if it was not directly related to the webapp.  For example, I was able to take a terse image generation function and drop it right into the project.
2. Having the framework based on Spring, Hibernate, Acegi and Sitemesh meant there were fewer conceptual changes moving from the old code-base.  Working on the code I often felt that I was maintaining the original ideas while reducing the inherent verbosity of Java.
3. The previous point applies to the interface code as well - the views in Grails use GSP, which is very similar to JSP and made porting the views almost trivial.
4. Moving from another Java framework to Grails requires less of a "sell".  A Grails project packages as a WAR file no different from any Java project.  It will have all the positives (and negatives) of a Java app.

So, having used Grails a for a while now, how does it stack up to Rails?  Here a few of the things I enjoyed about Grails:

• The GSP tags have the power of JSPs, along with a few features that make them simpler.  They've also added some tags that don't have equivalents in JSP, and are quite nice.  In particular, I liked using the "sortableColumn" tag, which generates columns in tables that handling sorting.  This is something I would like to use in Rails.
• Grails does not currently use migrations (schemas are generated from field declarations in model objects), and while for some projects this could be an issue, it made development that much faster to add a few fields and have the database automatically be updated.
• By default Grails uses a messages.properties file that contains message codes like validation errors and other generic error messages.  In some ways it's nice having all these messages in one place. Also, the validation errors use a default message per constraint type, which can then be overridden.

 As well as some caveats (I won't go so far as to say "problems"):

• Grails uses some different terminology than Rails.  Models are "domain classes", validations are "constraints", and so on.  Not much of an issue, but it may take some getting used to.
• The form helpers in views are not as sophisticated as Rails.  Less boilerplate code is generated for you, and more thought has to be put in to maintaining states and values of form elements.

Of course, there's nothing that Grails does that couldn't be done in Rails with a bit of extra code or a plugin, and I'd imagine for the most part this is true for Grails as well, so it's really more about simplicity and core conventions.  I'm still working on the port, so I'll be sure add updates as I get more experience.

There's a lot going on in the world of Rails these days.  This is great for developers, but sometimes it can be difficult to keep up with all latest happenings in the community.  In addition to changes in Ruby 1.9 and Edge Rails, there's a constant stream of news with regards to well-known Rails projects, emerging plugins and development/coding strategies.

Below are a few resources I use to stay up-to-date without experiencing information overload:

1. RubyFlow.com - This relatively new site is a great way to quickly see daily Rails news.  It was built by Peter Cooper (author of Beginning Ruby and the blog Ruby Inside).  Anyone from the community can post links on the site, or comment on posts.  I find myself visiting here multiple times per day to get a quick sense of what's happening and to make sure I haven't missed any important news.
2. GitHub - In addition to being a public git repository, GitHub has become a developer social network of sorts.  By following projects that interest you (including Rails itself), you end up with a single place to view all the commits that have happened on your projects.
3. Twitter - For the twitter users out there, there are a few options.  First, there's a user called rornews that you can follow, which posts links to Rails blog and job postings across the web.  You can also follow a number of members of the Rails community who are on twitter, including Obie Fernandez, Geoffrey Grosenbach, Ryan Bates, and why the lucky stiff (side note: anyone is welcome to follow me on twitter as well!).  Finally, you can consider using the tracking feature on twitter to follow "rails" or "ruby on rails".  This will give you a lot of updates, but if you're willing to sift through it you'll probably learn about news almost as soon as it happens.
4. Shared Feeds - I really like shared feeds (also called link blogs) as a way to see the best content filtered through a trusted source.  A few feeds to check out include Obie Fernandez, Geoffrey Grosenbach, and what appears to be "Matz" himself.  Or rather than following a single person, you try tracking searches for "rails" on FriendFeed or RSSmeme.
5. Blog Suggestions - There are a whole bunch of great Rails blogs out there, but if I had to choose the top 3 they would be the official Ruby on Rails blog, The Rails Way, and Ryan's Scraps (I find the "What's New in Edge Rails" posts to be invaluable).

If anyone has any other suggestions, please post them in the comments!