Somehow it's been a crazy week. I worked on a different project everyday. The electricity went out one night. The police were inspecting everyone's bags on the NJT on wednesday too.

I think this is good for a friday. Thanks to Dani for finding it for me :)

Linux - The Video Game

Linux - The Video Game

I've been throwing around an idea a bit around the NYC office today, and it's been getting a pretty interesting reaction, so I want to share it here as well. The idea is to make the Linux Desktop more like a Video Game. It starts with the Spinning Cube.

First I want to throw away our concept of the windowed desktop. Managing a set of windows is something a bunch of programmers came up with to manage their own development workflow, and it's something that the home user ignores at best, and is frustrated with at worse. In the OLPC project, they managed to completely do away with the whole notion, and switched to full screen apps, with an overlay that can be accessed by the push of a button. I want to take this a step further. In Sugar (OLPC) the user is faced with a single context, which is the task that he/she/it is working on. Given the power of our computers, and the preference of some users, they may want to check their email, facebook, friends blogs, chat, and download po^H^Hmusic all at once. If we treat each one of these as a separate context, we need to provide ways of letting the user switch between them easily. Well, let's say the user presses a button on his/her/its keyboard that says "Chat", we need a way to give him/her/it a visual clue that we are switching to there. A spinning cube is an excellent solution. Seeing the desktop zoom out, spin, and zoom in is a great clue to the user what is happening. Later, the user can turn it off for speed, but by that point, it's hardwired into the user's brain what is happening. We can take this one step further, and explain all the visual effects are good training tools.

Let's run another use case. The user wants to configure their system. Since we've so conveniently explained to them that their system is a cube (well, i'd prefer a dodecahedron, cubes are overrated these days), it would be trivial to assume we could zoom out of the cube, and view 'settings' lying beside it. Perhaps setting could be a great Atlas holding up the cube on his shoulders, or perhaps four elephants standing on the shell of a giant turtle. Naughty apps could be punished and forced to sail off the edge of the cube. But I digress. The user zooms out, and a menu pops up. If you've ever played a video game, it's fairly analogous to what happens when you press Pause in the middle of a game. That is the crux of the idea. Replace the bulky desktop metaphor with the sleek interface of a Video Game, and use some favoured fork of a Compiz tool as the graphical engine.

Anyways, sometimes I think in design requirements lists better than in highbrow literature, so here is one:

• The core interface must be accessible with an Xbox controller, Playstation controller, or a Wiimote. Although the standard 105 key keyboard could be used, along side a mouse, ideally a custom keyboard with similar D-pads, and context switchers would be very nice. Any hardware geeks out there?
• At some point, we'll need a good input method for typing text without the burden of a keyboard. Maybe this is a bad idea.
• Social Networking is the future. Heavy integration with any and all social networks is a must. Hooks need to be in place to 'share' any general activity with a friend. This is analogous to the social networking features in the OLPC project, however a little more sophisticated.
• Use of 3D effects as visual cues to direct the user's attention to important things. They should be minimal in effect, although a bit of smoothness goes along way. The cube is one example. Using subtle ripples on the screen to point the user in one direction is another. Perhaps ripples following the mouse cursor if the user loses it. Bouncing windows however cool should not be enabled by default, but is always a good option to show as a demo. Chuck Norris's fist bursting out of the screen on the other hand when the user does something stupid is quite acceptable.
• Abolish the file system. I didn't bring it up earlier, since it's orthogonal to the GUI effects, but it's one more gotcha that burdens the user. I'm proposing a history based system. Arbitrary tags are also good. Being able to set commonly used filters are even better.
• Physical awareness. Recognizing that the user's laptop is on the home network might be a good time to sync up all the shared files. Realizing that the laptop is in the same room, and willing to be used as such, the system can hook up with the laptop, and use it as an auxiliary screen. For example, while playing a game, having "you got mail, you won three auctions, and that hot chick you met last night wants to talk to you" showing up on your laptop might be a fun to implement feature.
• User and Expert mode. There is a huge debate on how much information the user needs to know. The developers of a certain instant messaging client believe that the user is not interested in which connection mechanism is being used to chat with. Sometimes the user doesn't care, but sometimes he does. Rather than argue about what the user really needs, just give them two options, all or nothing. Being able to customize what information the user really wants might be a version 2 thing, but hey, it's also open source.
• Speaking of which, the entire system should be open to development. While no dev tools or compilers are installed by default, it should be pretty trivial to say "show me the source" and have the system download everything, and setup a new context for development. Then ideally it would say "i'm sorry dave, but this will void your warranty" at which point you go and remove critical components while your Okama Gamesphere sings Daisy, and then dies. The build system should then let the user tweak an option, compile and deploy it, and see it take effect as soon as possible. IE, the user decides he doesn't like file chooser, and he wants to write his own. He downloads the source, edits it in place, says 'show me the new file chooser' and voila, a gentoo minute later, his entire system is switched over. Let's say he wants to share this with his friend. Well, his source tree is just a clone of a mercurial (or another distributed source manager) which he can commit to, and share.
• Speaking of which, a repository for user patches with ratings would be necessary at some point. Of course, supposing that a slew of 13 year old males with a penchant for naughty language discover the joys of open source software and flood a repo with comments that are generally unwanted, it should be very easy for a user to create his own repo. This way quality members to the community can contribute, and work on a reputation based system rather than a clog the network with odd ratings system. I think this one is probably a little more complex than I really meant, but it should be very easy to open, hack, and share, and hopefully merge back into the main stream.

Well, I had a bunch more ideas, and more details, but it's very hard to write things down when running, especially when it's raining like it was earlier :) All the same, we have a playstation in the office. I'm gonna see what I can do to get the bluetooth game controller to control my window manager, and see if I can go from there. I really hope I can make this a reality.

Oh yeah, and a MythTV context. Turn that expensive playstation into a very cool box. :)

The art of getting work done

The art of getting work done

In the madness that ensuing with the JBoss project we're trying to get working in my department, I've decided the best way to get work done right now is not to touch it at all. Instead, I spent my time today laying the groundwork for my 1% project that I'll be doing later this summer. So without further ado, I point you to the brand spanking new mercurial repository for Kefir:
My New Repo @ http://kefir.sf.net/hg/kefir/
Commiting is very easy, since it's using mercurial, so all you need to do is email me with patches, if you're interested in helping out.

If you don't know what Kefir is, it's a pretty simple concept. The graphic designer sketches out a great new concept for your GUI in Glade. It's gonna be the greatest thing since sliced bread, or at least Gnome HID compliant. Unfortunately, now the developer is screwed into writing massive amounts of boiler plate code to interact with libglade. Since you, the developer, is smart enough to be using Python, I'm guessing you're also smart enough to hate boiler plate code. This is where Kefir helps.

For every top level window in your GladeXML file, Kefir sketches a frameclass in Python, that when instantiated creates a replica of that window on your screen (or alternative). If you specify any callbacks for any GTK events, Kefir creates a call back function ready to be filled in. Sandino Flores Moreno wrote a brilliant guide on it's predecessor, Tepache, on how to write a web browser in under 100 lines of code. Kefir makes your life simple (and healthy if you drink it, providing you're not lactose intolerant or allergic to dairy, cows, or life.)

The funny thing is, whether you're a fan of Object-Proxy or MVC, Kefir can do them both. Kefir can function as both a Thick client proxy, or as the Controller in some elaborate MVC scheme. Writing a guide on how to do both is on the agenda this summer. Stay tuned for that and other fairly bizarre things, like my Todo list, and perhaps a look into my collection of old children's books.

Speaking of which, I went tag sale hunting this weekend, and picked up a few excellent finds. It's getting harder to collect old vinyl cover art, as everyone seems to want to hold on to their old vinyl's these days. The only ones that are being sold it seems are near perfect quality records at exorbitant prices. Alas. But I did walk off with a few nice things to add to my book collection. I now have yet another copy of the Hobbit, complete with yellowing pages, and the original artwork. I found two pieces illustrated by Maurice Sendak, which will be nice to add, a copy of "Butt Wars" I plan on passing on to the short people that run around my dad's house (after I'm done reading it of course), and to save the best for last "Elihu the Musical Gnu". This classic piece of literature features rhymes like

He had a Kazoo, brought from Kalamzoo,
which he blew and he blew.
But the tunes that he knew
-and he knew quite a few-
were sticky as glue.

I wonder if RMS has a copy yet.

Life is like a surrealists nightmare, it still makes too much sense.

JBoss and Deployment

JBoss and Deployment

After a rocky start trying to determine the scope of a few projects my colleagues and I would be working on, we set to working on a few projects using the JBOSS stack. Is there a word for the nightmare you get when you try to develop production grade material with beta software?

I spent my entire day mucking around with Eclipse trying to put together an IDE + Build system set up in an all in one package for everyone else on the team. Last summer, when I worked for Krones AG, they used a three level system for their database design. From what I got out of their thinking is that they prefer to think in database terms over object oriented terms. They treated web development as the icing on top of their databases, and the testing and QA processes revolved around this. First the database developers would develop their stored procedures and setup the tables into an SAP database called KE. Once tested to work, they would deploy them to a testing stage KQ, where we, the web applications department, would setup our pages to work on top of what ever disasters were created. Finally we would declare our stuff done, deploy the Java, Oracle, and SAP apps to their respective servers, and the devs would redeploy from KE to KP, where all the users got their data from. Once a month, they would copy the data from KP back to KQ, so we could have fairly good test data to work with, but there would be no worries that we would clobber any of the production data.

This is what I'm thinking for our purposes. Since testing JSF sites along with all the rest of the Java Junk requires a running server, it's best for basic development to run that locally, until the app coalesces into something usable. There is also a fairly decent SQL server written in Java that can be run along side the server, so we can make sure persistence works between deploys of the app. But when I run seam-gen, the build.xml files I get out of it seem to understand that there is only one server this app will ever be deployed to. So I'm left with a very tough layer to implement. For testing/QA and production, I want to create two more layers named exactly that. (Actually I like the idea of Mr. and Mrs. so I can be totally ambiguous.) The production AFAIK is going to be running JBoss proper, with MySQL. Or Postgresql, but I don't think that matters much. So naturally, I want the testing to be running the same thing. The tricky bit, is I want to be able to pick up the latest nightly, and run a single command that deploys it directly to testing. This would be simple, but it means changing all the deployment config files. As it stands, they are single mindedly set up for one type of server, at one address, etc... I'm thinking an ideal situation would be a command that took a JBoss server address, port, SQL server, and port, and type, and could flexibly deploy anywhere. Superideally would be a screen in Eclipse to do the same thing.

Or maybe I'm just wasting my time with eclipse, and I should learn how to do this all on the command line, like Chuck Norris would.

The Boston Tea Party

The Boston Tea Party

The past two days, we, the interns at the NYC office, were up in Boston to meet the OLPC and Westford offices. We didn't actually get the chance to throw crates of Fedora Discs into the Boston Harbor to promote the release of Fedora 7, but we did get to eat cake with some of the people who worked on it. Present were the tubes and trucks with which had been used to collaborate and develop Fedora 7, so it was only fitting that they were also present, and in the form of cakes and pies. Sadly I did not have a digital camera with, so I'll have to wait till the film is developed, or some of the guys up in Westford send me the pictures to use. *wink wink* *nudge nudge*

Wednesday though, we got to see the OLPC's main office on the MIT campus. If you don't know what this is, google could tell you most of it. It's a concept to bring very low cost laptops in bulk to all sorts of nations all over the world, in order to bring computer resources to areas where they don't even have electricity or running water. They give the kids these green laptops that are designed to survive a hurricane practically, or a monsoon. And they are so small, have bunny ears and are so cute! Did I mention they are bright green?! They are very awesome. Holy crap, they are so cute.

Well, being made a guinea pig for testing Fedora 7 was not my idea of fun, but I had alot of fun going up there all the same. We have our boxes working again mostly, so things aren't too too bad anymore.