Monthly Archives: March 2007

Wishing Kathy well

Wishing Kathy well.

We were mortified by the news of Kathy’s death threats. Our Campfire was flush with wtf’s and holy sh*ts. Kathy Sierra is probably the most universally liked blogger among the 37 crew. To see her subjected to this kind of vile, despicable, criminal behavior is heartbreaking

Hopefully the guilty will be duly punished and Kathy will be back to her usual cheery, wonderful, insightful self shortly.  [Signal vs. Noise]

New release of Hobo: The rapid Web application builder for Rails

New release of Hobo: The rapid Web application builder for Rails.

Just over two months ago I posted about a new rapid Web application development framework for Rails called Hobo. The team have now let me know they've got a brand new, redesigned site, and that Hobo has a major, new release.

Hobo makes it really easy to get a basic Web application up and running in Rails. It's a little like scaffolding but with a turbocharger under the hood. And if you want to get up and running in just a few minutes, they have a short tutorial along with three screencasts.  
[Ruby Inside]

Joyent Slingshot

Joyent Slingshot.

For a while now, Magnetk has been engaged in developing ‘Slingshot‘ with Joyent. Slingshot is a platform which allows Rails developers to easily create hybrid web/desktop apps with ease and flexibility. There are some great office 2.0 applications out there, but you must admit there is but there is only so much you can do with just AJAX in terms of flexibility and performance. I love Google speadsheets, but they are slow and kind of clunky. It’s cool, but it’s very 1991.

We’re starting to run up against some painful limitations inherent in today’s web 2.0 experience. Most notable is the lack of any functionality and data accessibility while no internet connection is present. Also, there is no integration with other applications running on the end users’s desktop. Others out there are also in the process of trying to solve some of these problems – but we think we have a particularly powerful take on it. Briefly, I’ll answer the most obvious question people have:

“How is Slingshot different than Apollo or Firefox 3?”

Apollo is a great framework and certainly powerful. It will meet with great success. The Wikipedia entry describes Apollo as:

“A cross-OS runtime that allows developers to employ their existing web development skills (Flash, Flex, HTML, Ajax) to build and deploy desktop Rich Internet Applications.”

Slingshot has the same goals – with the key difference being we allow developers to employ existing applications with no re-write necessary. Additionally, as a bit of personal criticism that you might disagree with: Flash and related technologies don’t come easily to most programmers. ActionScript is super cool, but I’ve always found the Flash platform non-intuitive and confusing. Perhaps I’m dumb; but I know I’m not alone.

Firefox 3 adds the option of local datastores for applications to access in an offline mode, and it is certainly a step in the right direction. The major downside is that it requires developers to specifically tailor their application to this framework and design for it. With Slingshot, we wanted to make it really simple for existing applications to be dropped into our framework basically unmodifed and have them “just work.”

Slingshot is bit the same but a lot different than Firefox 3 and Apollo. Here are our major design goals:

  • Let developers write hybrid desktop/web applications with Rails. Rails is elegant, well designed and allows for rapid development and deployment. It’s also much easier for a novice to learn than Cocoa or C# and it enforces some good decomp and design.
  • Allow Rails developers to create more robust applications that have a comparable user experience to traditional desktop applications. Drag in and drag out of data/files/etc, for starters. In the future, filesystem access to remote data [like SftpDrive…]
  • Allow Rails apps to run offline with simple and transparent data synchronization
  • Lightweight and customizable – we want you to make the decisions about exactly how your app runs, not us.

How this it’s done:

We started by developing application shells for both Windows and OS X that provide a consistent and stable binary environment in which to run Rails apps. One nice thing about the Rails community is that most developers are already developing their application in “offline” development mode, usually on a Mac. Similar to the Locomotive framework on OS X or the Instant Rails application on Windows, we make it easy to bring your custom environment into a stable well defined shell that you can customize in any way necessary. Gems, binaries, auxiliary worker processes – whatever. You have full control.

On top of this, we have a customized browser that runs without any of the traditional dressing [address bars, buttons, etc] of a web browser. This allows much more intimate access to the application and to the host operating system. By controlling the browser and extending it, we can build a bridge into the OS. A developer can easily tie together existing data import<->export controllers within their existing application directly to normal OS data transport mechanisms like the drag and drop interface, the clipboard, and eventually the filesystem. This is all done without modifying any of the compiled code, and is OS independent. Also, your app is still available from any browser in the world, just like it was before.

A good example of why this is important can be seen by looking at Joyent’s Strongspace. Right now if you want to upload multiple files you browse for each individual file, one by one, hit upload and wait on a page until it finishes [unless of course, you’re using SftpDrive]. With Slingshot, you grab a bunch of files, and drop them onto Strongspace, and they are uploaded in the background. That was easy. Drag out – it’s the same thing, but in reverse. Drag a file from Strongspace directly into Photoshop. Awesome.

Offline mode is cool, so is integration with traditional desktop apps, but it is all somewhat worthless without an easy way to synchronize data with your live server. Slingshot data sync is designed to be extremely powerful while still being lightweight and flexible. We provide controllers and code to handle data serialization & transport in both directions. As the developer, you merely need to aggregate all the ActiveRecord objects that particular user needs to have access to offline. Slingshot does the rest. Same goes for upsync, and we have similar methods built in for files and other data types. The only extra work for the developer is deciding who gets what.

We’re quite proud of Slingshot and are very happy to be working with the fine guys at Joyent. The goals of Slingshot are quite similar to the goals of SftpDrive. Both applications target facilitating a highly connected user experience with transparent and ubiquitous data access. SftpDrive is designed to provide a more networked experience for all traditional applications speaking the one API they all speak – the file system API. Slingshot takes centrally hosted applications that are accessible from anywhere in the world and make them available with or without an internet connection along with integrating them with powerful traditional applications. 
[Magnetk Blog]

re: Vista – I’m downgrading

re: Vista – I’m downgrading.

After about 3 weeks of using Vista RTM as my primary windows development environment, I’m officially downgrading to XP.

The reasons for this are many:

  1. Driver issues; Mouse, firewire controller, power management, to name a few.

  2. Nothing works without about 10 extra installation steps. VMWare Workstation and Visual Studio are the two key components of my development environment. Visual Studio needs a custom patch, needs to be run as administrator, yet still doesn’t fully work right with some plugins I rely on. VMWare Workstation doesn’t run or install correctly without modifying Vista security settings. I’d love to run the 6.0 beta [which has amazing Visual Studio integration] on Vista – but Visual Studio wouldn’t start because it could not “acces the log file”. That’s awesome.

  3. Vista has been out in beta in one form or another for quite a long time now, but the level of changes made during the final 6 months created all sorts of issues that are similar to this. SftpDrive has had Vista support throughout this process, only to have various aspects of it broken and require various fixes for release. The latest 1.6 beta now works with RTM.

  4. UAC is really annoying. The first thing you need to do is turn it off. You would hope some basic sanity would have resolved a few of the issues, such as using control panel. You can’t do anything in the control panels without re-authorizing priveledges on practically every click.

  5. Everything covered in here: The 5 sins of Vista. #1 and #5 really bother me. #1 is truly asinine.

Overall – I’m left trying to figure out why Vista is better and why it took 5 years to make it happen. The start menu is new, I guess. The windows have translucent borders if you spent over $1500 on your machine. Give me a break.

The lesson I’m taking away is that developers can only sell upgrades and “new” revisions based on features. It’s truly poor form to roll 5 years of bug fixes into a $350 package with more regressions than new features.

I’m going back to XP. 
[Magnetk Blog]

Indie Tip #5: Think Small (But Act Big)

Indie Tip #5: Think Small (But Act Big).

One of the trickiest things for me as an independent developer has been choosing the right size of applications to build. I didn't want to make software that only a few people would use, but at the same time, it was out of the question for me to target a huge audience because I'd be unable to handle the support load. So even though my ego didn't like the idea, I've always narrowed my scope in order to build software I could manage.

Each of my applications initially targeted a market that I thought would be too small for a big software company to bother with, but was more than large enough for an independent developer. And each targeted a market that I thought would gradually increase over time, so I'd be able to grow my customer base without suddenly being overwhelmed (with admittedly mixed success).

But just because I chose to think small didn't mean I had to act small. Surviving as an independent developer requires you to act big. You can't get away with a substandard UI or feature set just because you're a small company – in fact, I'd argue that you need to make your product even better than the software created by the big players. A lot of people are nervous about shelling out for software written by a very small company, so you've got to show them that you're worth it.

If you really want to act big, puff up your chest and realize that the fact that you're small is your best asset. Your size is a competitive advantage, because large companies take forever to write software. In the time it takes for a big company to finish deciding what they're going to build, you can develop and ship an entire application. And you can respond to market shifts and new technologies much faster, so you can survive even if a large company moves into your space.

By Nick Bradbury. [Nick Bradbury]

Indie Tip #4: Get a Life

Indie Tip #4: Get a Life.

Being an independent developer is great, but it can lead you to feel isolated if you don't force yourself to get away from your computer. You're not mingling with co-workers every day, so you've got to find other ways to socialize. Otherwise you'll end up being just another blob in front of a screen.

Attending conferences is one way to get out, and it's something I enjoy a couple times a year. But that's an awfully expensive (not to mention infrequent) way to meet people – and it's not a good way to meet people who don't develop software. Honestly, if there was only one thing I could recommend for indie developers, it would be to get away from techies and technology as often as possible.

One thing that's worked well for me is joining a local marathon training group. I get outdoors and have a shared goal with non-geeks, and I feel energized as a result (well, most of the time – sometimes I just feel sore). Other indie developers I know have done regular charity work, become involved in local politics, or simply taken up hobbies that get them around other people.

Whatever route you take, I guarantee you that you'll last longer as an independent developer if you regularly put the tech toys aside. Surrounding yourself in geekdom is a quick road to burnout, and if you get burned out, you're going to have to get a “real” job again.

By Nick Bradbury. [Nick Bradbury]

Indie Tip #3: Don't try to be cool

Indie Tip #3: Don't try to be cool.

Call it a pet peeve, but it annoys me when I see “cool” applications with “cool” features that provide little or no value to real customers. Honestly, there are waayyy too many useless “Web 2.0” applications that look like they were designed by developers who want A-list bloggers to think they're cool.

Here are some ways you can tell when a developer is trying too hard to be cool:

  • The product's UI is littered with buzzwords like “AJAX” and “Web 2.0”
  • The home page brags about how their software integrates with all the popular social networking sites, but there's no description of what it actually does
  • The documentation contains the word “Micro$oft”
  • They offer tech support on Twitter

“Cool” is fleeting (just ask the Fonz), whereas utility has staying power. So avoid the temptation to build something just to impress your peers, and instead try to build something that'll impress end users with its usefulness. Then customers will think you're cool, because you just made their lives a little simpler.

The way I see it, if you're able to give up the corporate world and code at home in your underwear, then you're already cool. So stop trying to be cool and focus on building something that's useful.

By Nick Bradbury. [Nick Bradbury]

Semantic web as social enjoyment

Semantic web as social enjoyment.

The recent launch of Freebase.com, the first application of the semantic web engine being developed by Danny Hillis’ new company, Metaweb, was written up by, among others, Esther Dyson, Tim O’Reilly, and Martin Heller, from whom I received an invitation to try Freebase. (Note: I don’t yet seem to have invitations that I can dispense.)

If you scan those articles and the blogospheric halo surrounding them, you’ll soon glean the essentials. Freebase is like Wikipedia in the sense that it’s an open data project. But where Wikipedia is a database of unstructured articles, Freebase is a database of categorized and related items. You can use it to add or edit items and, more ambitiously, to create or extend the categories themselves.

There’s been a lot of discussion about how this approach does or doesn’t match up with the W3C’s vision for the semantic web, and the suite of standards and technologies associated with it. I’ll leave that to the experts and simply reiterate one crucial point. The authors of the semantic web are going to be people, not machines. And people will only want to play the game if it’s easy, natural, and fun.

Early indications are that Freebase is going to be a whole lot of fun. In his walkthrough Tim O’Reilly calls it addictive, and explains why. Because the system thinks in terms of relationships among types of items, a single act of data entry can produce multiple outcomes.

Tim’s writeup gives a couple of examples of what that’s like. Here’s mine. I found a record for myself in the system, sourced from Wikipedia. I updated it to say that I’m the author of the book Practical Internet Groupware. Then I added that Tim O’Reilly was the editor of my book. That single edit altered the records on both ends of the author/editor relationship. My book’s record now showed Tim O’Reilly as its editor, and Tim’s record sprouted a Books Edited list that contained my book as its first item.

Nice. This is just a Hello World example, of course, but it has the feel of something that people will be able to understand, will want to use, and will enjoy in a social way.

A couple of years ago, I wrote a column entitled WinFS and social information management. It concluded like so:

Developers have always tried, and so far always failed, to define reusable objects that meet the needs of knowledge workers in the real world. Meanwhile, in the era of social computing, we’re learning to watch for the patterns that emerge as people interact in information-rich contexts, and then pave those cow paths. The first WinFS-aware applications, which will be personal information managers with hooks for sharing and synchronization, won’t align with this strategy.

These WinFS applications will, however, enable you to pave your own cow paths, for example by storing and reusing queries. Nobody can know how people will ultimately want to share these contexts among WinFS clients in a peer-to-peer fashion, on WinFS servers when they emerge, and on the global XML Web. So I hope Microsoft will come to see WinFS not only as a platform for developers, but also as an environment in which users can do simple things that yield powerful social effects.

Nowadays a lot of folks say WinFS was doomed from the start and should never have been attempted. I didn’t think that then and don’t now. I did, clearly, wish that WinFS had been part of a strategy of cooperation with the cloud. And I’d still like to see some version of that scenario play out.  [Jon Udell]

Joyent Slingshot

Joyent Slingshot.

Introducing Joyent Slingshot

Joyent Slingshot allows
developers to deploy Rails applications that work the same online and
offline (with synchronization) and with drag into and out of the
application just like a standard desktop application. We have Joyent Connector
and a select group of third party applications working under Joyent
Slingshot. Joyent plans to have Slingshot available for general release
on both Windows and Macintosh OS X in late April, 2007. If you would
like to be considered for a spot an early release tester, please send
email to slingshot [at] joyent.com You must be a Rails developer with
an application we believe would help us put the final polish on
Slingshot.

Joyent Slingshot is a game changer.

The
framework is lightweight and customizable and allows Ruby on Rails
applications to run offline with a simple and transparent data
synchronization. You, the developer, make the decisions about exactly
how their apps runs, what synchronizes – not Joyent.

Joyent
Slingshot enables Rails to break free of the browser. It breaks down
the wall between a Web application and a desktop application without
losing what makes a Web application great: the ability to rapidly
develop, deploy and update, now for desktop applications.

Joyent
Slingshot allows Rails developers to easily create a hybrid Web/desktop
application with the experience a user expects from a normal desktop
application. Drag in and out of the Rails application for files, email,
iCal events, vCards, bookmarks (html files) to begin with. Before final
release, Joyent will be extending this to native filesystem integration
and native datastore for additional data-types.

How does Joyent Slingshot work?

It
provides a consistent and stable environment for a Rails application to
run off Windows and Macintosh OS X. We remove all dependencies and
conflicts with system binaries. Additionally, Joyent Slingshot allows
developers to customize their environment as they please. Install any
gems, plugins, binaries, whatever. We can handle it. Joyent Slingshot
is like a virtual machine for a Rails application to run on. Sweet. . . .   [Joyeur]