The Secondary Twitter Stream: New Applications You Can Expect Thanks To User Streams

At Twitter’s recent Chirp conference, they announced a new “user streams” feature that allows users to receive a real-time stream relevant to them. Today they opened it up for everyone to play with.  They’re very quick to point out that the service is still in development, so we shouldn’t expect any new applications in the near future.

Even if you’re not a developer, there are a few neat things in user streams, which you can expect to start seeing once this functionality goes into production. There are a lot of actions that Twitter users take beyond actually posting tweets. The user streams function opens all of this up in real-time:

  • See who your friends follow. In real-time, you can see who you’re friends are following and unfollowing.  Sometimes, you see people follow a bunch of users in bulk (I’m guessing they’re using a script to automatically follow back their new followers).
  • See favorites and retweets in real-time. Currently, favorites aren’t very widely used, but I could see this growing over time.  A real-time look at what your followers find interesting could be a great way to stay up to date.
  • See all your friends’ replies. Last year Twitter had a minor controversy when they disallowed users from seeing every reply their followers sent.  Instead, you could either turn off all replies, or only see replies when you also followed the replied user.  In user streams, all replies appear to be open again.  I could see this being a great way to find new people to follow, by seeing who your friends are talking to who you don’t follow yet.

All together, I see this creating an entire secondary sort of twitter stream in addition to your main friends timeline. The combination of following, favoriting, retweeting and reply events in real-time can provide a very interesting look at what’s happening by-the-minute in your circle. Tools to aggregate this data can provide a different service, by showing you trends that you might have missed among users who are gaining followers, engaging in conversations, and being favorited.

Twitter: Firehose will be not be made public, available only to "small group of trusted partners"

Ever since Twitter disabled access to their firehose last year, many users have been waiting with baited breath for its return.  The “firehose” refers to the stream of all public Twitter posts.  Currently, it’s only possible to get a small subset of all public posts, and many types of Twitter applications aren’t possible without access to the firehose, such as real-time track and trend analysis.

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?

Highlights from 37signals Live

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.

What We Do Here (And, We're Looking for Work!)

I’m not sure if all of you are aware of exactly what we do here at Draconis Software.  I thought now would be a good time to let everyone know, since we’ve got some availability for new work.

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!

How Apple Can Support True Background Applications on the iPhone

At the WWDC in June, Apple announced their Push Notifications system, which will give iPhone applications a way to display messages to the user even when their app isn’t running. While this will give chat, microblogging and feed reading applications some semblance of running in the “background”, many users (including myself) haven’t been thrilled with this solution (and not just because it’s still not out yet!), as it doesn’t allow for cases like music streaming, or background location polling.

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?

From Gmail to MobileMe

When I purchased an iPhone 3G (upgrading from the first gen), I also purchased the companion MobileMe service, and I’ve been giving it a test run since.  At the time, I was hoping for a replacement to Google’s Gmail, but unfortunately, it’s not quite there yet.  I thought I’d take a few minutes to offer some tips to the MobileMe Email team, as well as start a discussion on email services in general.

[Read more...]

Internet radio as the killer iPhone app

Since Apple launched the App Store for iPhone OS 2.0, I’ve been keeping my eyes out for what might be the next killer app for the iPhone.  I’ve often thought the iPhone would be a game-changer in the mobile environment, allowing people to think of their phones in a new way.  These mobile devices are no longer simply a phone with added-on Internet access, but a complete communications and personal computer system.  With games and other non-communication-oriented apps the iPhone has achieved much towards this end, but there’s one additional category that has the potential to be a game changer in an unexpected way: internet radio.

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.

New Draconis Software Site Design

Just a quick note about our new site design (if you haven’t noticed already).  We’ve put a lot of effort into redeveloping our site, hopefully conveying a fun, bright feel.  The main change, though, is what’s no longer visible: our network monitoring system RSP.  As a company, we’re moving in a different direction and have decided to make our site focus on our consulting efforts.

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?

Pulling Subversion Logs for a Single User

There are many times during a project where I use the svn log command in order to see what has changed and to get a feel for the pace of development. It’s also great when you’re dealing with clients; you’re only one command away from telling an inquisitive client exactly who did what task and when they did them. However, svn log is missing one important feature — the ability to filter by a particular username. When I asked in #svn on freenode, they suggested I use the --xml option and parse the resulting output.

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.

[ruby]
#!/usr/bin/ruby
require ‘rubygems’
require ‘hpricot’

username = ARGV[0]
if username.nil? || username == “”
puts “Please specify the username to cull log entries for.”
exit
end

puts “Requesting SVN log, this may take a bit.”

doc = IO.popen(“svn log –xml”) do |f|
Hpricot.XML(f)
end

entries = doc.search(“logentry”).find_all do |entry|
(entry/”author”).innerHTML == username
end

entries.each do |entry|
revision = entry.attributes["revision"]
author = (entry/”author”).innerHTML
date = (entry/”date”).innerHTML
msg = (entry/”msg”).innerHTML

puts “r#{revision} – #{author}”
puts “#{date}”
puts “#{msg}”
puts “-”*80
end
[/ruby]

A Rails Developer's Thoughts On Using Grails

We strongly believe in using the right tool for the job.  While we currently think of Rails as the de facto choice when it comes to writing webapps, we’ll always consider other options, such as one of the many other Ruby web frameworks, or going with another language such as Python.

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.