Rhonabwy

Oh yeah – all iPhone this time. I’ve been a bit incommunicado of late – just darned busy. Spending a bit of weekend time teaching iPhone for OReilly, which has been interesting as well as rewarding. This past weekend was at Loyola in Chicago with 9 students – again a whole different kind of crowd from the folks I taught in either San Francisco or here in Seattle.

While I’ve been working on this coursework, Beth has been learning about iPhone development, sometimes helping at the classes and other times working on her own. It’s been really interesting to see the responses to her emails on the cocoa-dev mailing list. Some incredibly good help, a few jerks and their responses.

Beth’s made a screen cast talking about one of her challenges: doing the Interface Builder work to put together a TabBarController and a NavController. A common enough pattern for utility iPhone applications, and one that isn’t easy to explain or see when it comes to Interface Builder.

I think getting people used to using Interface Builder, including learning how to debug it and what happens when you make mistakes, is one of the biggest bonus’ of the in-person class. There’s a huge amount to that tool that just isn’t obvious until you see someone do it.

Heh – it’d be nice if the refactoring tools in Xcode would understand when you’d renamed an outlet too. That’s an interesting error for a newbie to run into. All of a sudden they’re going “Hey, what’s the key value coding thing and what did I do to make an undefined key?!?!”.

Anyway, check out Beth’s screencast if you’re interested in iPhone development. It’s well done.

Kris Markel let me know today via Twitter that Seattle Bus made Todd Bishop’s Top 5 list of iPhone apps. A very nice to thing to hear indeed!

It’s especially nice news coming back from WWDC where my good friends at Rogue Sheep won the Apple Design Award for .

The conventional news vendors – newspapers and local television – are failing badly. They’re taking a lot of damage, and the worst part is that it’s entirely self inflicted.

Karen pointed out something that I thought was a great indicator – last weekend there was a convention in Seattle that brought in 9000+ visitors, and there wasn’t a peep about it in the news: Sakura-Con. Granted it’s a bit fringe – it’s all about Anime – but you’d think that with 9000 people attending that maybe SOMEONE would have covered it in the local news.

Not a thing.

The whole reason that news media is failing is because it isn’t reporting anything relevant. Most news is about the world – and we can get that in increasing venues incredibly easily. Everyone has the world news. So very, very few news outlets have realized it’s the local community, not the world, that’s critical to their lifeblood.

KOMO 4 TV (Fisher News) recently annihilated their entire internet focused staff with the recent economic downturn. <SARCASM ALERT>Talk about forward looking… </SARCASM> That’s just rock fucking stupid on a whole new level.

The news companies are going to go under, and rightfully so, unless they start to wake up and realize they need to do business a whole new way. They won’t have the US Govt standing there to bail them out like the US Automakers either (another fine example of rock-fucking-stupid and self-inflicted damage).

(By the way – notice these stilt walkers? Pretty cool work. Apparently took them 2 years of their own RD to work it out. They walked up the escalators with those!)

Somewhat related to my previous post – I’ve been thinking a lot about packaging lately. At work, I’ve jumped into a team that’s responsible for a whole bunch of infrastructure – envisioning it, building it, and running it.

Two months ago I thought I’d jump in and start building some really awesome spires. Spires in a metaphorical sense anyway – I guess if I was really sticking to an architectural theme, it should be something else – something more broadly useful but still fantastically impressive. I found myself focusing on the infrastructure instead. The infrastructure wouldn’t support what I wanted to build. It’s missing pieces – pieces at the very base of the whole setup. So I’m mucking around in the foundations, shoring up some systems, adding others – getting the basics nailed down with my team to build some of these cool spires. And thinking. A lot of thinking – thinking about what’s most critical, what provides the most value, and what needs to be done in what order to make this team really successful.

One of these foundational pieces is packaging – application packaging, to be specific. The more I think about it, the more I think I need to do something about it – but outside of the walls of my job. The reason for going outside my job for this? I honestly think the world needs another application packaging standard.

I could build a company standard for application packaging. I’m pretty convinced of it anyway… but I don’t think it would be successful in a long term (i.e. more than 1-2 years). For an application packaging standard to be really effective, it has to have a broad support base, will require a lot of effort, and for an effective standard I philosophically believe it must be an open standard.

The use case that’s driving this thinking is being able to programmatically deploy new servers, drop down applications, and configure them in a very fast time frame (in a manner of minutes). The use case is one of the classic jet-pack and flying cars dreams of elastic/cloud computing.

There are some enterprise tool chains that do this today. Sort of. If you squint real hard. Most of these tools are born from the world of policy based computing, IT control and compliance, and configuration management. They don’t match up with the use cases real well, and the enterprise software solutions in this space and horrifically and tragically expensive. I can’t even blame them – clearly that’s where the money’s been for these tools.

The marketplace is pushing – there’s a need, there’s a HUGE opportunity here. It’s where applications become components that can be, and are, programmatically deployed and controlled. It’s the next step up in the abstraction layer for the systems we use every day.

There is some work towards solutions to this problem today. It’s not like I’m the only guy seeing this problem (if I was, I’d likely be delusional).

• RightScale has a great product that layers on top of Amazon’s EC2. It’s damned impressive.
• 3Tera has a tool chain that starts to deal treat virtual machines as packages to be deployed, connected, and replicated at need.
• Parallels has created AppStandard.org, which is really the closest anyone’s come to what I’m aiming at – but even it’s not quite there – not to mention copyrighted and proprietary.
• VMware is making some aggressive moves into the tools space as well, propagating the OVF standard (with the DMTF) and the concepts that we’ll be deploying VMs, not applications, in the very near future. I’m not sure they’re wrong – but I think they’re missing half the picture.
• The DMTF has standards that are skipping around the ideas, but not quite nailing them on the head.
• In the open source world Puppet and CfEngine are the kingpins – programmatically defining infrastructure. They fail to take the next obvious step into application deployment – but I think only because they lack the infrastructure components needed to do it in an effective way.
• At Velocity 2008 (which I attended last year) Adam Jacob gave the talk Building an Automated Infrastructure. They used these tools, and one of the points of the talk was the applications and their configuration weren’t yet well dealt with.

I think the solution to this problem is an application packaging standard that includes configuration and parameters into its metadata.

Like other packaging standards, the packaging needs to:

• allow the code to be dropped into place
• define dependencies that the application requires
• have a common and open format that can be stored and shared in open repositories

What it needs in addition is:

• the package should contain parameters (configuration elements) that can be programmatically determined
• once determined, the application should be able to be deployed with parameterized configuration – details updated at deploy time
• ideally this will enable the capability to update that same configuration programmatically, idempotently and remotely

What I think it needs to be successful:

• An open format with at least one, preferably multiple, implementations enabling that standard.
• A base set of common applications packaged in this format, available for immediate use
• a tool to create the packages and verify they’re ‘good’
• a tool to deploy the packages overlaying configurations – at least on a local basis
• a public repository of common packages to build a dependency library upon
• a way to copy/mirror that repository cheaply and easily in any organization to reduce cost of uptake
• a damned impressive example solution that takes advantage of the kit

In short, a crap-ton of work. For a company to want to go do these things, they’ve have to be pretty damn visionary. And I’d expect that they’d want to keep this kind of IP to themselves. I need this kind of solution, the economic times are rough to chase visionary dreams outside of the core competencies of the job, and I think a successful solution would benefit everybody. To me – this whole setup screams “open source project” to make it work.

So now I’ve defined it – put it out there.

Are you interested in making something like this? Contributing to a open solution? Willing to put some sweat equity behind a project that could revolutionize things, but is essentially building bricks for a foundation?

I have some projects on my plate right now that I can’t just drop – so it’ll be a month or two before I start pursuing this one. Let me know if you’re interested… haven’t even decided on the structure it’ll need around it to work, but I’m heading in that direction.

(image used with permission: http://www.flickr.com/photos/kamoda/3184396852/)

I’m taking some time today to read up on the events and talks at PyCon 2009 happening this past week in Chicago. I’ve been watching a few folks on twitter who are there (John DeRosa and Ted Leung). It’s been interesting to see what’s happening through their comments and links. There’s the inevitable talks that I wished I’d attended, hopefully slide decks will appear for a good number of those and I can catch up even after the conference content. PyCon is one of the best there – they go out of their way to make the talk content available as quickly as possible with the right set of controls for content (the speaker’s are the ones responsible for uploading their content).

Anyway, all this led me around to the conversations that have been happening around packaging with python. It was a topic of some conversation (and has been needed for a while now, in my opinion) at the Python Language summit (notes from Ted about it). Tarek Ziade did a survey recently of what folks were using, and posted his results, which were interesting. zc.buildout and virtualenv got some attention from multiple folks. I think the most crucial was the summit talks themselves, which Tarek summarized on the mailing list. The gist – there is a high-level plan at improving the packaging world around Python:

• standardize more metadata, especially including dependencies, and APIs for accessing the metadata and dependencies.
• there should be an API to get metadata for a package without actually executing any of the package’s installation script.
• this will go into the stdlib for Python 2.7 and 3.1
• it will be provided as separately downloadable backports for prior versions (maybe using a bootstrap not unlike ez_install)
• keep distutils, but start deprecating certain higher-level functionality in it (e.g. bdist_rpm)
• don’t try to provide higher-level functionality in the stdlib, but instead let third party tools built on top of these core APIs compete

When I was working more extensively with Django, that was the biggest headache – getting a packaged, ready to roll quickly environment. I’ve trailed off in the past while with the Django project (not actively using it at the moment, although I think that’ll likely switch around again) – but the lessons about packaging have remained with me.

My favorite tool is an 12oz ball peen hammer.

I should probably have prefixed this with the fact that I’ve spent a lot of time doing metalwork, and if I thought of myself more as an artist, I’d say that was my preferred medium. Lots of metal work: casting with bronze, tin, and silver, soldering, forming, cold metal work with copper, pot metals and steel, forge work with iron and steel. When you’re doing metal work like this, you live with a LOT of hammers. For a while in my basement (when I lived in Missouri), I had a wall with over 40 hammers on it – and thought that was a reasonable number. I show outright jealousy towards some long-time smithy workshops that have 70+ hammers.

I’ve mostly shut down that metalworking shop these days, but I still keep some pieces of it around. The 12oz hammer is one of those items that I’m just damn fond of. It’s a good weight, not too heavy and not too light. When I was doing forge work, I learned early enough that while a big ole sledge was a fine thing for rapid moving, the really interesting work could be best done by a light touch with a fairly light hammer.

One of the aspects that I like most about the smithy workshops is that it’s just understood that you’ll make your tools. You’ll build exactly the tool you need to make the end result that you’re after. The other aspect that I learned (after many, many screw ups) was that you’d best be thinking about finish up at the very start of a project and not just the end. Know what you want the end result to be in all its form and function, and then make it happen.

I took those concepts with me into software and have wound around a number of different gigs, mostly ending up somewhere between development and operations in “Internet companies” – and yeah, making tools.

A couple of years ago I got to see Michael Johnson give a talk about making tools – which he does for Pixar. A year later I had a chance to talk with him directly after he was presenting to a bunch of Disney Internet Group folks – both presentations where basically the same: about making tools.

I suspect I’ll ruin his general thesis, and certainly it isn’t a good synopsis, but the gist I got from his talks was that making tools was about shifting the effort from one team to another. And that if you’re doing that – you’d better make sure that it’s the right way to make things better.

In a larger organization, the process of shifting the work from one group to another is often a messy process. Things break, misunderstandings can happen, and maybe not everyone understands why you’re doing what you’re doing. In a smaller organization, some of these folks don’t exist – it’s almost easy (and mandatory) to make a larger use of tools to get stuff done. But for me, the larger, messier wins are the ones that really pay off. It takes more work, no kidding, and a lot of communication to go along with the technical efforts. In fact, I’d say they’re darn near equal in terms of need inside the organization to make a tool successful.

There’s a lot more that goes into it all – making tools. I’ve got a lot more thoughts and ideas – but I wanted to post something up here on my blog for anyone wandering by and wondering about “this guy at Disney” who’s hiring for an automation engineer.

If you end up interviewing with me, tell me you read the post – and what you think. I’d like to know…

Not related to iPhone or Mac development, sorry.

My team at Disney has an open position, so I’m out scouring the world for folks who’d like to work in an Automation Tools Team for the group (Disney Interactive Media Group) that drives the Disney web sites and internet presence. And if you’re local to Seattle, then yeah – surprise! Disney has a fairly large office here.

The official job description is available online at https://disney.recruitmax.com/main/careerportal/Job_Profile.cfm?szOrderID=190328

Don’t send your resume’s directly to me – I’ll never be able to act on them if they don’t “go through the right process” (this isn’t a small company, you know). But if you are interested in tools and automation for Technical Operations, check it out.

Oh – yeah – the position is in Seattle, no remote.

For the past several months, I’ve been coding away madly for a new iPhone application – a course to teach other folks the basics of programming on the iPhone. I’m developing the course for OReilly Media and will be teaching at least the first few iterations of it – probably more.

My first course is now available for signup if you’re interested:
http://youriphoneapp.eventbrite.com/. It’s a two day course – April 25th and 26th, from 8am to 5pm.

UPDATE:
If you’re interested in attending this beta course, use the discount code “iphonedev” when signing up – that should give you $900 off, reducing the cost of the beta session to $300.

We were going to try and provide the first course at no-cost to attendees in return for feedback, but the realities of today’s economic situation mean that we’ve got to cover at least the basic costs for this one. I’m really jazzed about getting this out there – I’ve been working for quite a while to make this as absolutely stellar as I can manage!

It’s pretty clear, from my iPhone application at least, that I’m a fan of mass transit and interested in using data that’s already available to make it more useful. One of the hardest nuts to crack in that space is “how long will it take me to get from point A to point B”. Lots of people have been working on it for quite a while, and the solution to this problem – while “well known” from a computer science point of view – just hasn’t existed in much of a public space. Google transit was really about it there, at least until today….

The walk-score guys (really called “FrontSeat.org“) have made available a technology preview of a transit mapping system for some cities in the US (Seattle, Portland, and San Francisco) that does a great job of showing this off. The earliest version I saw of this was a London underground version that showed how far you could get in 5, 10, 15, etc. minutes from downtown London. It was a one shot – great map – showing the benefits that the underground provided if you were living around that city. Since I saw it, I’ve been wanting something like it for Seattle – of course without enough gumption to go knock it out myself.

When I first put out Seattle Bus the most common feedback I received was “Hey, how about a program to show me HOW to get from here to there…”. Well – the backend of that bad boy problem now appears to exist: Brandon Martin-Anderson, and available on GitHub. Lord knows where he found a GTFS feed for Seattle’s metro system, but I’m impressed!

No spoilers…

I went and saw the movie Watchmen this morning/early afternoon – a break from my “usual” weekend routine of the past 8 weeks or so. I’d hoped to see if Friday afternoon at a mid-day show, but I waited too long and the tickets sold out. Rotten Tomatoes is calling it a 65 at the moment – I suspect it’ll go higher over the weekend. I know of a number of folks that were disappointed with the film, but I wasn’t among them.

I particularly enjoyed the dystopian alternate-day reality they provided, and the special effects were, as expected, very well done. One of the actors I thought came off as fairly wooden compared to what I expected from the graphic novel – but overall I was very pleased with the whole effect.

Definitely not a movie for Karen though. For Karen, I think the next flick will likely be Coraline – which I’d really like to see. I’ll have to wait until next week though. She’s down at DisneyLand with some of her cousins and their kids for this weekend. That’s leaving me footloose a bit, and with a good excuse to see a movie.