Older blog entries for oubiwann (starting at number 249)

Smartphones: Yesterday's News


As some of you know, I started 2010 by working in a new position at Canonical: Ubuntu Project Manager. I've been having an absolute blast; working my butt off has never been more fun, challenging, or interesting. I'm finding that nearly every side-interest I've had in the past several years is coming to the forefront in my project management work.

There were all sorts of adjustments I needed to make before PM'ing again, and one of those was catching up on communication technology. I now live by email, calendars, IRC, Skype, and phone conversations. Gone are the days of going heads-down into some code for a week or two. I need to stay connected, 100% of the time. I needed to get a smartphone.

What I really wanted was a Nokia N900. Sadly, T-Mobile's not offering one, so I got an Android phone with a physical keyboard instead: a new G1. Yeah, out of date, but considering that I was still using a Razr, the G1 is cutting-edge ;-)

I gotta tell you, this little phone has changed my life. The craziest thing is not the apps, the Market, the features, etc.; it's the touchscreen that has made me a believer.

You Can Touch This


I can't believe how radically the touchscreen phone has changed my computing habits and preferences. When I sit down at my laptop or desktop to do something quickly, I don't want use the keyboard or mouse. I want to point, swipe, and tweak with my fingers. When I'm on the phone, my brain has my speaking and text-processing faculties tied up. To easily multitask while talking, I need to be able to use a different part of my brain: that part involved in motor control.

I like using the touchscreen so much that I will often use my G1 for tasks that are better suited for my laptop, merely because of the joy I get from using the interface.

Touch, tap, drag, push, swipe. I love it. Can't get enough of it.

The best thing of all? This is really silly: I love the virtual desktops and being able to navigate between them with a swipe. Whose idea was this? That designer or engineer needs to be promoted! I have never experienced a more intuitive way of switching virtual desktops. I didn't even know how much this was important to me until I used the G1. I want this for my laptop!

Having such a positive bias towards tactile technology, you can imagine my joy when I saw this Ubuntu blueprint. And then when I was asked to work with Bryce and Andy on the PM portion of multi-touch support, I was quite delighted. This will give application developers and device engineers what they need in order to start creating new exciting stuff for the Ubuntu world. You will be able to have an iPad-like experience on your Linux devices (that have the proper hardware).

The thing is, as much fun as tactile interfaces are, I want way more now. I've been given a taste... now I want the banquet.

An Interface for the Future


So the iPad has been getting lots of press. It's bigger than a phone, I like that: I could replace my pen-and-paper medium-sized Moleskine with one. The thing I like the best though? Yeah, you guessed it: the interface. Curling pages and apps that have been re-worked specifically for the new format/size. I love it when a device lets me use it in a way that is natural and intuitive, and provides visual (or other sensory) feedback on my use.

Apple has made, in my opinion, a good and interesting product. But certainly not a revolutionary one. It's a natural progression from what folks are already doing with smartphones and netbooks.
So let's talk about revolutionary :-)

Imagine you've got a crazy new shirt, one whose fibers convert your movements to electrical current and can power your devices. Perhaps it comes with a "battery net" for literally flexible power storage. Now imagine that some clever sod has equipped your shirt with sockets for micro-SD cards (or something similar). If you've read my "After the Cloud" posts, then you probably know where I'm going with this :-)

Now add some embedded micro-controllers, and bluetooth, a smart phone with cloud-controller software, and you've got a personal S3 with potentially terabytes of light-weight, wearable storage. And your phone controls the nodes, redundancy, failover, etc. Maybe your phone runs Ubuntu and you're pushing backups of your personal cloud onto your U1 account.

But how do we interface with all this great storage? Here comes the banquet I mentioned :-)

I want to be able to reach "into" my phone, grab an icon (application, file, contact, whatever) and put it where I want. But I mean really put it: I can pick up some data off my desktop, and throw it over my shoulder or at my feet. With appropriate sensing equipemnt on the power shirt's sleeves, my arms and hands are now the perfect "mice."

In fact, there's no more virtual desktop (that's old skool). One of the new primary functions of your mobile device is to peer "into" the halo of data that surrounds you now. You can either spin your virtual storage space around you like an inverted, 3D lazy susan, our you can physically move your phone around, like a diving mask peering into the water.

Closing Thoughts


The more data I have, the more I feel that I live in it. The problem is that our current tech forces us into tiny sardine cans and we have to consume our data with the equivalent of a single chop-stick. If I'm going to live in my data, I want to have the best possible experience of immersion that I can. I want an interface that can handle my future.

I could go on and on... I love this sort of thing. The important thing to know now is that the community is working on the building blocks for our technological future. The first steps are being made in open source software that will allow us to take giant, insanely cool steps in the not-to-distant future.

Earlier today, I was looking through old blog posts, reminding myself of issues and topics that I want to continue reflecting on actively. When I got to the end of the posts, I looked at the earliest date and realized that my seven-year blogiversary was this past Wednesday. At my vocalized comment to this effect, Marjorie asked what got me started on blogging. Interestingly, it ties in with my professional life over the past twleve years...

As a physics undergrad and employee of the University of Maryland, I was hired away by a large internet startup for my systems and programming background. Already a fan of Office Space, I got to experience the reality of cubicle life as the not-so-funny, real complement of that classic movie. However, it wasn't my personal experience of cubihell that had the biggest impact upon my psyche; it was the corporate atrocities suffered by various customers and partners of dot-boom era, high-rolling companies.

Already a passionate open-source user and contributor, it become one of my personal goals to make sure a greater number of people (especially those making decisions in companies) were informed about the software freedoms that were within their reach. Within two years of this epiphany, I had my own company and was open-source consulting for everything from small businesses to large international corporations and the Federal government. Everything I did was open source; all of it saved my customers from spending millions of dollars unnecessarily and the enslavement of proprietary lock-in.

It was at this time that I started blogging. My primary interest was to be a voice in the wilderness of consultants, finding other like-minded programmers, project managers, sales engineers, etc., who believed in "open business", transparency, and accountability. As time progressed, my blogging habits adapted to fill other needs in various communities. However, all of my professional decisions have remained true to that initial desire to work on technology that was not only free, but actively prevented the bondage of its users.

For the past year and a half, I've been working at Canonical, the company that funds and actively supports Ubuntu and the Ubuntu Community. Every time I work with a different engineer or a new team, I am blown away by two things: the incredible talent embodied in each interaction, and the dedication that each person has to improving how free technology is delivered to the world.

My blog posts have definitely changed in character over the past seven years. But I'm delighted that, where I once felt alone with my ideals, I can count true giants in the field among my fellow community members, cooworkers, and mentors.

The first version of txAWS just made it out the door, thanks to prodding from Scott Moser, who is helping to get txAWS into Ubuntu Lucid Lynx. It's been uploaded to PyPI now too, so you can do the usual (easy_install txAWS), or you can download it from Launchpad.

Over the last few months, I've been doing lots of work on various open source projects. I've been so burried in them that I haven't blogged (or microblogged) much about them. So much has been happening, though, that I needed to take a break from the coding and communicate some of this :-)

txAWS

Over the last few months, Robert Collins, Thomas Herve, Jamshed Kakar and I have been putting lots of effort into improving cloud support in the async (Twisted) Python Amazon EC2 library. It's been a lot of fun to see that part of the library take shape and start getting production use from Canonical. We have implemented the following functionality groups and their associated API methods:

• Instances
• Key Pairs
• Security Groups
• Elastic IPs
• Availability Zones
• EBS

There is a ticket for the following two groups of functionality, and branches in progress for both:

• Images (ticket #461136 on Launchpad)
  
• Image Attributes (ticket #461139 on Launchpad)
  

Once those are merged, EC2 support in txAWS will be complete.

As a bonus, we've added support for arbitrary endpoints and with that in place, have successfully tested txaws.ec2 against Eucalyptus clouds :-)

txJSON-RPC

There's a new release of txJSON-RPC out now, downloadable from PyPI. Work on the next version has been a great deal of fun. What started out as a conversation on IRC with Terry Jones, ended up as spec-driven doctest work on trunk for implementing support for multiple versions of the JSON-RPC spec (pre-1.0, 1.0, and 2.0).

With these changes in spec support, txJSON-RPC has really started to mature, and that's been fantastic. Even more, the jsonrpclib module that's included in txJSON-RPC (and can be used with non-Twisted projects) is getting spec version support as well.

SOOM in txULS

As some may know, one of my computing passions is ultra large-scale systems. After a phone conversation with Jamshed Kakar and some nice exchanges on the Python ULS-SIG mail list with Alex Drahon, I started working on a set of coding experiments in self-organizing objects. The Google Doc informally outlines the various stages and goals.

For now, the code is living in a txULS series on Launchpad. The reason for its inclusion in txULS is that ultimate goal of the SOOM (self-organizing object meshes) code is to produce an async API for building Twisted services that provide behaviours as outlined in the Google Doc (linked above).

I would to emphasize the networking-library-agnostic nature of the ULS-SIG: Twisted comes up since I spend a lot of time with Twisted, but ever networking library is welcome. I'm personally interested in exploring (or watching other developers explore) various Stackless Python experiments in the ULS systems space.

txSpore

This project was a spontaneous effort resulting from an evening of code review when I first discovered the official Python API from EA/Maxis for the game Spore. It's been a blast and something that Chris Armstrong and I have been working on together. The API is currently feature-complete, but Chris has some excellent ideas about improving usage as well as some additional API augmentations that will make life easier for game developers.

Already more featureful and usable than the official Spore Python API, there are great things in store for this library. Chris has come up with several very cool demo ideas that take advantage of the new API and will push it to the limits. We're both pretty excited :-)

Isomyr

I love isometric games. I'm a freak for the classic look. One night about a month ago, Chris and I discovered Isotope, an isometric Python game engine by Simon Gillespie. It was last updated in 2005 at version 0.9, so I started working on a branch that could be released as 1.0. I never heard back from Simon after an inquiry for his permission to release as 1.0, so I forked the code to a new project: Isomyr. I released the code rewrite work I had done to that point (plus some changes such as replacing some old code with Numpy) as 0.1. At which point things just went nuts...

Isomyr now has support for multiple worlds, customizable (per world) in-game time and calendars, and basic interactive fiction development. The latest chunk of code (that hasn't been pushed up to Launchpad yet) is adding support for general planetary simulation (e.g., axial title, varying daylight hours, seasons, and weather). As you might imagine, this has been a great deal of fun to work on!

PyRRD

PyRRD has gotten some recent community love, with requests for a mail list, new developer-oritnted features, etc. Currently at version 0.0.7, the 0.1.0 release isn't to far away. Folks have been using trunk for a while, which added support for the RRDTool Python bindings back in March of this year. (PyRRD's focus has primarily been for users/developers who didn't have the RRDTool Python bindings installed). In the next couple weeks or months, I expect that we'll be adding a few more features, and then preparing the new release.

PyRTF

Another fixer-upper project, PyRTF (mirroed on Google code as pyrtf-ng) has been on hiatus for a while, due to my diminished need to manipulate and interact with RTF files. However, a new developer has joined the project and the code-cleanup and unit test development now continues. Thanks Christian Simms!

A while ago, Simon Cusack (the original author of PyRTF) and I had some great discussions about the future development of PyRTF and his interest in merging the recent changes into trunk on SourceForge. I deferred on that action, wanting to wait until the code cleanup, unit tests, and API changes had been completed. With Christian's help, we may get there now :-)

Wrap-up

It's been about a year since I've been so active in open source development, and it feels really good to be at it again :-) Being back in Colorado seems to have helped in subtle ways, but mostly it's been the increased interaction and interest from developers in the community that I can thank for my increased activity (and thus enjoyment). You guys are awesome. You're the reason for any code I produce.

Hey folks,

At my last count, we've only received 20 talks so far for PyCon 2010! There are only 14 days remaining for talk submissions... if you've had a great idea about a talk for PyCon, now's the time to make it happen!

Below I've pasted some links that folks might find helpful. The first one has pretty much everything you need to know about submitting a talk for PyCon.

• Proposal Submission Information
  
• Help and Tips for Speakers
  

I just had a delightful weekend of coding :-) I spent the past two days porting the Spore Python API to Twisted. You can now incorporate Spore data (from static XML as well as REST requests) into your non-blocking Python applications/games!

This was a pretty easy task, really. The API just makes HTTP requests with twisted.web.client.getPage. There was a little bit of work involved in creating object models for the XML, and some head-scratching for the error-catching deferToThread unit test I tried to write (it's still buggy... need to figure that one out). Everything else was pretty much cake.

In fact, it was so much fun to kick back and write some playful code that I might overhaul the sync Python code as well and incorporate both into txSpore.

Do be aware, however, that the code still has some big improvements coming. The first thing I want to hit is actually create a client object. Right now, the client module contains a series of functions (since state's not currently needed). However, I want to start doing some basic object caching in order to limit the number of requests made to spore.com and increase the response time. That's the big item for 0.0.2. Update: 0.0.2 is now released!

Next I'd like to create some more demo apps that show off the API usage better. Right now, there's one demo (a .tac file). All it does is ask for a user name, renders a user page, and then links to a user "Spore assets" page (that's the thumbnail image above).

One thing that might be fun to do is write a script that checks for the latest achievements and publishes them to various microblog/status sites with the Twisted PyngFM client :-)

There's a project page up on Launchpad for txSpore, and I've posted a notice and some updates to the Spore developer forums. It's also been published on PyPI.

Enjoy!

For the past couple years, my girlfriend has been amazingly (astonishingly) patient about a whole slew of .wma files that we've got on the network drive... backups of her CD collection made when she was a Windows user. We managed to save them right before the computer died, but she hasn't been able to listen to them when she's booted into Ubuntu or Mac OS X.

Late last month, after getting back from two weeks abroad, Marjorie said that she'd really like to have access to her music collection again (the CDs are cumbersome and stored away in boxes for our impending move back to Colorado). With that said, I did some digging around, and found some immediately helpful links (two years ago, a few google searches had turned up results that indicated too much effort was involved).

I started out by trying a couple free Mac OS X GUI applications, but these ended up being quite horrible: either they did not offer the functionality I desired, they were buggy to the point of being unusable, or they rendered audio with unlistenable artifacts.

In the end, I had to use mplayer and lame in combination. After googling around and some trial and error, I discovered the combination of mplayer options that would successfully extract the audio data from .wma files and dump them as .wav files.

I started with a shell script, but quickly changed to Python, since there were several locations for the .wma files, and none of them on nice paths. I've used this script several times since then, when more .wma files were discovered, and have yet to encounter any issues in sound quality. Once nice-to-have would be to extract .wma metadata and save it in the new .mp3 files as id3 tags...

Anyway, here's the code:




Hope someone else finds this useful and their significant others don't have to wait 2 years for their music!

I just merged async (Twisted) support into the Python ping.fm library today and have just taken it for a test drive. I do love Twisted :-) The Twisted pyngfm API usage is identical to the synchronous API, with the usual exception of using deferreds and callbacks.

Here's some example usage, the client I now use for command-line updates to Twitter, Identi.ca, Tumblr, Facebook, LinkedIn, Jaiku, and even Flickr (note that the keys are stored in an .ini-style config file):





There's another example in the README that iterates through the recents posts made to ping.fm. If you do manage to use it and come across any issues, be sure to file a ticket.

Enjoy!

I was only half paying attention, until the stream of thought actually started getting interesting. At which point I sat upright in the tub and started taking mental notes. Quickly showering off, I couldn't stop the flood of ideas, hoping to get to a written medium as soon as possible, lest they be forgotten.

I forget how the day-dreaming started... perhaps my usual: pick a random topic where I have some experience, and start playing with it. Run simulations and tweak parameters until there's nothing more to look at or some interesting permutation has popped up. 

Ah! Now I remember. I was thinking about the increasing importance of QA in software as more and more marketshare is gained. Not from the usual perspective ("we gotta make sure users don't see bugs, or our shit's gonna flop"), but rather as part of the original problem domain.  It's very common for open source projects to suffer from a lack of sex appeal when considering QA. QA is essential for success; just as important as the code itself. As such, there should be ways of making QA as interesting, engaging, understood, and respected as the act of programming.

That train of thought spawned a couple more pathways for exploration, but the one that ended up being the most interesting was pondering the QA-interest problem at a human resource management level. What would it take to get talented and skilled engineers who would normally gravitate towards some other field of expertise interested in QA instead? How flexible would a company have to be to start attracting for this and other positions as new needs arose due to new pressures? How could it do so by growing and adapting from the inside?

Let's take these rather arbitrary initial conditions as part of a thought experiment following up on those questions:

• a company with a sufficient number of employees to support multiple departments
  
• a highly intelligent, motivated workforce
  
• flexible employees and teams, probably working in a distributed, remote environment