ExpanDrive

Maybe you heard earlier this week about Apple taking out a patent on some solar cells, so soon we can all have solar powered MacBooks and iPhones and blah blah blah.

Look: that might do it for my cousin Irene with the gold pigtails and a frilly pink dress, but that sure as hell doesn’t do it for me. I demand MORE POWER. And like John McCain, who’s so tough he wouldn’t even use a solar-powered sundial, I know exactly where to get it.

That’s right, I’m talking about a nuclear computer. I’m sick of being behind the Cheese-Eating Surrender Monkeys in generating what is obviously the manliest form of power on earth. And don’t bother whining about “feasibility”. If we’d let weenies like you take over during the 60s, there’d be a Russian flag on the moon and the national pastime would be badminton.

A Mac Pro weighs almost 50 pounds, and enough fissionable material for an a-bomb weighs only 11—still sound impossible to you? Sure, you’d need turbines and a cooling system and crap like that, but Apple’s always bragging about how awesome its designers are. Now it’s time to put up or shut up.

On top of just being frickin’ awesome, nuclear computing would all but solve the national energy crisis. When you were running some pansy application like Mail or iWank or whatever, you could use the power supply in your PC to run the rest of your home, and even sell power back to the grid.

Look, I love the environment as much as the next guy—wind turbines, recycling, bottle deposits, hybrid SUVs; the whole nine yards. But solar’s simply not a viable solution for power users; I mean, what are you gonna do when the sun’s not shining?

Let’s say you’re playing Quake IV in your bedroom at 4am, and somehow fighting back the entire Korean Peninsula with a single measly railgun—do you want to get gauntleted because a “low power warning” pops up and ruins your FPS? Or do want your power supply to get so hot from rendering ultra-high-res blood spatter that you have to huck it in the bathtub to prevent a meltdown?

The choice is yours, people. Don’t let Steve Jobs talk you into buying an inferior product.

Image: MacNuke, created by author. From original work by Gmn wnr. Free use under cc-by-sa-2.5.

Are you using bash-completion? I bet you think you are. I bet you’re not. It’s a horrible name (up there with “The Wire” and “Battlestar Galactica”), because people hear it and think that they know what it is, but they’re wrong. Don’t prejudge the bash-completion. It’s much, much more.

Everyone knows about [tab] completion. It’s great. We love it. But, it leaves a lot to be desired. How many times have you done something like this:

Continuity:~$ cd m[tab]

and then seen this:

magnetk/     makay_tex_source.tex     mathjob.pdf     
methods of theoretical physics.pdf     monterpp.pdf

Three pdfs, a tex source file, and one directory. Do you know how many times I’ve wanted to cd into a pdf file? Zero. I’ve never wanted to cd anything but a directory. So why does [tab] completion show me all those files that I’m obviously not interested in?

There’s a better way. In fact, bash already has a robust programmable completion system managed through the builtin commands compgen and complete. While bash is distributed with “programmable completion”, it isn’t distributed with “programmed completion”.

That’s where bash-completion comes in. It’s more than 9000 lines of pre-programmed completion artificial intelligence. It knows that you only cd into directories. It knows passwd only works on users, groupmod only works on groups, unalias only works aliases, and which only works on commands. And that’s just in the first 150 lines. The current version even includes a whole svn subprogram, so that it can figure out valid targets even for the various svn commands.

You can install bash-completion by Macports (sudo port install bash-completion), fink (fink install bash-completion), or apt-get (apt-get install bash-completion). You can also install it by hand. This involves downloading the file, unzipping it, and putting it somewhere.

Regardless of how you install it, you need to make sure it gets sourced when you start a new shell. Sometimes Macports et alias will do this for you, and sometimes they won’t. If you’re new to this, then source just reads a file and executes it line by line. Add a line to .profile (or another file that gets loaded when you open a new shell) that says source /path/to/bash_completion. For those of you with Twitter-eqsue character constraints on your dot-config files, you can also say . /path/to/bash_completion, where the . operator is a synonym for source that saves 5 characters at the cost of being infinitely less readable, and infinitely easier to misinterpret.

Then you’re done. Load up a new shell and enjoy. If you’re used to stupid file completion, then prepare to be amazed. You’ll find yourself groping around with [tab] in places you never would have imagined before, and you won’t even realize you’re doing it.

Interested in helping us test SftpDrive for OS X?  Email jeff@magnetk.com to sign up. Please include a bit of info on your hardware along with you’re hoping to use it for. Thanks!

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.