michaeldehaan.net

What’s the future of data interchange over web services? Currently, I believe too much work is required of clients to utilize remote applications at the level of capability provided by a local API. Basically, it all comes down to speaking using a very narrow wire. It’s like assembling a jigsaw puzzle by sending written letters back and forth to someone in a different country — you give the orders, but only the other person can see the pieces and move them.

Primitive datstructures include strings, numbers, hashes and lists. It is upon this foundation that most web services are based — whether XML based (REST, SOAP), or JSON, these are two dimensional text entities that don’t represent more complex data very well. Well, they could just contain a flat graph topology, sure, but it’s not natural, and it’s verbose.

My theory is that in designing web services for humans (so that things are readable/printable, and their various bash/Perl scripts can operate easily over an XML DOM or XPath, without deep modeling of the underlying business logic or data models in client code), we are invariably designing our data structures in only two dimensions, and probably reducing the number of links and data structures that reference objects in ways that makes the data less useful than it’s natural state. In the the case of SQL databases, we probably spend a lot of time writing code to move between an ideal database representation and the web services representation. In the case of NoSQL databases, we let our web services representation unfortunately limit the best possible way to access the data! The humans have told the computers what to do.

When modelling, say, a list of US cities and connecting roads and airport flight paths in a web service, you quickly get a graph with a lot of deeply interconnected parts. Expression of that graph is, fundamentally, an expression of nodes and edges. Do I want to print a list of cities and each of their neighbor cities? What if I want to produce a list of cities that are 1-2 cities away? What if I want to print a list of all cities in North Carolina? Or cities that are 50 miles away from cities in North Carolina. As we deviate from the need of simple data access, eventually the client application will need to “think” about the data, rather than getting the answer from a simple DOM traversal or XPath query. That is expected… but if that code is accessed by 5 different programming languages, that’s 5 different times that logic will have to be written. Ouch.

What if the thing we “got” for a web services request actually contained multiple datastructure views and indexes into the thing we were querying, so that the client program did not have to calculate? If web services APIs were instead written for machines, and client libraries were distributed to allow more rich access to a software system, our programs would not be likely limited by the need to represent their best internal structure as something close to the representation of the API layer.

To do this, we really don’t even need human readable protocols — but we *do* need to standardize on a more or less standard way of object to binary marshaling. Think is, we did this before (probably because CORBA was a square wheel?), but we threw this out. Hmm. I think we can do better though.

XML or JSON structured data is returned in a way that is intended to make it easier for a particular set of access use cases. What if when requesting a complex topology, I actually got a section of the database that I queried, complete with indexes and various foreign key relationships? Wouldn’t that be easier than traversing it with a XML DOM implementation to build up my own internal model of the original database model, so that I could think about it, and then get my result?

Unfortunately, this sounds a bit like I’m requesting the return of the 1990′s, where it was permissible for a client application to have it’s own database handle. You don’t want that, but I might like it to be able to export tables for the subset of the database matched by a server-cleared search pattern.

Anyway, the theory is this — humans are making us think about data in two dimensional views, and is not good to store it that way. However, the easiest way to present data is just like it’s stored. Further, it would be nice if client applications, in the age of web services, could be as dumb as possible. To do this, they need rich data, without the need to re-model relationships needed to re-represent those 2D datastructures in more complex forms.

Some sort of hybrid between a database handle, web services, and application remoting (RMI, drb, etc) is an interesting idea. Clear my app for the data it wants to access and let me access the raw classes and exported object methods, but limit what I can do based on some rather complex RBAC policy. Basically, I’m not convinced the older client/server methods were busted. They just need to be given some security extensions for the open internet and presented in a different form. The internal API and storage of the app is usually the closest thing to the true data model of the app, and has richer capabilities … finding a way to give web users access to parts of that, safely, is the ticket, and then we don’t have to do all the emailing of the letters back and forth to work on that puzzle — I can just become that remote person working on that puzzle, and use his hands and eyes, as long as he agrees with what I’m doing.

(P.S.: if you think I’m talking about Thirft, ProtocolBuffers or something like that, I’m doing a pretty bad job of communicating what I’m talking about, because those don’t do what I’m talking about.)

So I’m almost to about 10 years in systems management stuff. As I keep thinking of what the ideal merger of all these apps I’ve worked with (or planned to build) are like, here’s how I would build the theoretical next. This is basically client/server architecture for very very many clients. Build something this way, and I think you’d avoid a lot of traps I’ve seen over the years… and it also wouldn’t be that hard. Obviously not everything works for everyone.

• As a general rule, use as much off the shelf components as possible… provided it’s not some project that came out last week, people adopt what they are familar with. Also, you can be lazy and work on more features and less plumbing. Plumbing is not sexy because it’s been done 1000x before.
• Don’t look to big industry standards, these go out of favor quickly. Look to what people are using to get real work done, use those things unless they suck.
• Avoid live queries for state. Hit the remote resource, update the server side state, show that. You’ll want to do things with it later and it scales better.
• Use pull technology to access the managed nodes. Systems aren’t online all of the time and they move, have a way to trigger the pull, which makes it work like a push. Do not have any kind of long running connections to the server.
• Use Apache (or nginx, etc) as much as possible for serving content, and consider squid for caching files, where security is not an issue. Don’t serve files from live code where avoidable
• Consider building UI out of static HTML pages that do regular form submissions. Ok, I kid, but I hate javascript compatiblity and CLIs are better anyway
• Your CLI needs to do every thing your UI can do, the UI is allowed to do less, but must represent anything your CLI can set up
• The CLI should take a remote server parameter, do not require it to be run on the server
• the CLI should not contact nodes directly, but must ask the server to contact nodes and use the API to do it
• Probably use a strongly typed and reasonably fast language to reduce the frequency of errors that occur along the actual error path — Scala maybe? Management apps get very large and can have unexplored areas that are hard to cover with tests
• A daemon if required should be extremely lightweight and just dispatch a helper application to avoid leakage and unnecessary resource drain
• Do not store static content in a database. Updating is difficult and querying is meaningless. You know who you are.
• Connect systems and nodes only via message bus technology for easy routing, but also for easy spying/debugging on communications.
• Where security is an issue, rather than serving content dynamically, consider just adding an access handler to Apache
• Do as much thinking about how clients should look on the actual clients. Your datacenter is great for distributed computing.
• If you need to version control the history of stuff (logs, reports, etc), consider using git internally and have it do all the work
• I’d still use SQL (PostgreSQL) just so I can get migration capability which is lacking in NoSQL. Riak is otherwise awesome. SQL and NoSQL together is the worst of both worlds.
• Allow pluggability via stdin/stdout protocols and subprocess execution. JSON is probably fine and easiest for contributors, don’t limit things to a specific language.
• Add lots of attach points for people to hook into things with their own code
• Assume all operations will target more than one thing
• Make all resources commentable (comments for multiple people, not just one field) and user taggable
• Have iTunes like smart playlists of resources — rBuilder does this pretty well
• Make all resources have an audit trail, including the user that modified them
• Where I need a DSL or complex configuration representation editable by humans, use YAML — but don’t use YAML anywhere else
• Generally prefer JSON over XML because you can represent more types of data structures and it’s faster
• If you have template engines, support multiple template engines using the equivalent of a shebang line
• If you write a webapp, write a client library, and make your view implementation use it to talk to your server. Redistribute the client library, it’s great documentation.
• Log at a reasonable level, but not to the database. Databases don’t make good logs because you have to keep pruning them.
• Use the same protocols between nodes that you talk to the server.
• Server must be installable from one package with editing of only that one app’s configuration file(s).
• Client software that runs on nodes must be installable from one package with editing of no configuration files, a –server parameter for a register command is a good idea but should not require additional setup/files, and it should be trivially easy to integrate with kickstart/preseed or anything else
• Do not think of your application in terms of purposed services, some running here, some not. Most management nodes can run everything and just scale out by adding more . That’s the point of the message bus — first node to ask for more work gets it.
• Keep communications non-chatty (or free from ping-ponging) — if you must push to a node, tell a node what you want to do as completely as possible, expect a response, then give it a break.
• Generate RSS feeds for anything that has a history

And probably some other things.

As I’ve never attempted to type this out, rules I generally like to live by (to varying degrees of success):

• Shoot straight, play fair, and work hard
• Destruction is easy, creation is hard. Create more things.
• Animals are people too, except when they are very tasty and widely eaten. If hell is overseen by chickens, I am screwed.
• There’s something to learn from everyone
• Have as many different perspectives as possible
• Fear is the Mind killer (darn you, Frank Herbert)
• Imagination is one of the most important skills ever
• When faced with a potential conflict, seek first to understand other viewpoints
• Always question your assumptions, views, facts, and biases
• Never sit with your back to a door (darn you again, Frank Herbert)
• Just like in Calvinball, few rules and limitations are fixed
• “Your first 10,000 pictures are your worst.” — Keep doing things even when you suck at them, is the best way to get better at them
• Always be helping robots enslave humanity at some future date
• Most things can be improved by adding lasers

Hopefully that helps people understand me less.

For local folks, I’m planning to give a talk on Open Source communities & business models (or “Open Source in non-glamarous practice”) at the upcoming NCSU FOSS Fair, this February. This may be a bit more “fair and balanced” (or PG-13?) than my usual open source community cheerleading pitch I’ve given in the past, but should be (maybe more) interesting. This will be mostly based on experiences with Red Hat and Puppet Labs (both great and tremendously valuable experiences) as well as tracking trends in programming, open source, and startup news. Rough plans, for which, I promise, there will be no slides whatsoever (so you’ll have to go) below. Get some insight into reality of what they don’t tell you about OSS from a battle scarred DevOps veteran.

• Scalability and success of different OSS business models. What’s right for you?
• What to do if you don’t have a strong user community?
• Is your project sellable?
• Recognizing what type of community your project has, and what that means, and how you can use it
• Managing user vs strategic direction
• Realities of clone projects, “freeloading”, forks, mindshare, & innovator’s dilemma
• Riding the line between Minimal Viable Product vs the Killer App, amidst limited resources
• Project Marketing 2.0 and Grassroots strategy

Today I took my new Olympus 45mm 1.8 out for a spin, attached to my trusty Panasonic GF1. As promised on twitter, here’s a mini review. Even though I don’t think I know anyone with a Micro 4/3rds camera, I like to feed the Google — and more people should buy them anyway, because they’re awesome.

I like lenses to be both sharp and fast –the benchmark, my favorite lens that I use on my Canon 5D is a Canon 85mm f/1.2L. This lens is clearly not going to be it, as that is the lens God would make if he made camera lenses (and charged $2k for them) … but I wouldn’t want to lug it around all day either, and it absolutely never makes it out on business trips where I need to haul a laptop along. This lens is Micro 4/3rds only hope though, if there is a lens that is to even pretend to be that, this has to be that lens. Now, with the crop factor of Micro 4/3rds, this is as “fast” as a regular 1.8, but it’s two stops less in depth of field from a regular 1.8, so… it’s not going to be that amazing. Let’s see how it turned out…

Better than expected! Overall, I’d give this lens a 90/100 — it’s pretty sharp and this is about as good of depth of field you should expect to get out of a Micro 4/3rds lens, and would be absolutely perfect for vacations. The depth of field is not going to pass for medium format quality, but it just might pass for 35mm on a good day. And usually, the focal length is usually just right. I don’t think it’s razor sharp, the color isn’t phenomenal, but it’s pretty darn good, and I must remind myself, pretty inexpensive. The build quality is very good. And what do I mean razor sharp anyway? I spent most of the day at f/1.8, which is not where any lens is sharpest. That’s not even a fair test.

So here’s some test shots from walking around NC State, light was a bit harsh, December, about noon, no clouds. Also it’s really hard taking pictures in a area ruled up by bricks. The ultimate proving ground. Did I mention the squirrels have grown as large as small dogs? It’s true. No pictures though. Too dangerous to stay in their territory.

While my 85mm 1.2 is not jealous, I’d say I wouldn’t expect that to come out of a camera of that size. This lens currently lists for about $380. A pretty good deal for getting depth of field in a very light portable camera.

Over Christmas break I’ve converted the startings of my music theory library noose to Python, for no other reason that Python is my day job, and it makes things *slightly* easier to work in just one language. The new version is so far free of objects, so it can accomodate extremely long scores. (While it’s not used for that now — It’s been an interest of mine since college to build a music program that could create continuous scores that continually evolved over a day or more, so… I’m keeping that option open.)

Anyway, goals. My favorite way to record music is using an Elektron Monomachine serving as a sequencer for itself and a series of analog synthesizers. To compose anything chorded, you have to spread things out over various tracks. I don’t play these things live with a keyboard, because I don’t have 18 hands — and robots have much better timing than I do.

I don’t have a every note of every scale and mode in my head yet (understatement), I’d ideally like to compose things using something similar to the Nashville numbers system — preview the composition with something like garage band, and then enter it more properly into the Elektron, making full use of parameter locks, mod wheel changes, and so forth. This would also allow easy repeating of themes in different scales, like modulating between keys. Ideally I want something I can edit in ASCII.

So, the way I see a song is basically a series of multiple patterns like this (ignore the non-fixed with font):

scale: C Major

moog  1 | 1 2 3 - -  - - -  - - - - -  - - -
sem   1 | 1 - - - 1  - - -  1 - - - 1  - - -
xs    1 | 1 2 - - 1  - - -  1 2 - - 1  - - -
voice 3 | I - - - IV - - -  V - - - VI - - -

Where “moog”, “sem”, and “xs” are names of various analog synthesizers, and “voice” represents three voices of another synthesizer, doing something like a choir patch. In my current setup, I have the capacity for 12 parallel tracks and actually have 10.

Though the way the monomachine enters things is basically like this, in a 16 to 64 step pattern:

      moog |
     moog0 |  C4 Cs4  D4 --- --- --- --- --- --- --- --- --- --- --- --- ---
       sem |
      sem0 |  C4 --- --- ---  C4 --- --- ---  C4 --- --- ---  C4 --- --- ---
     voice |
    voice0 |  C4 --- --- ---  F4 --- --- ---  G4 --- --- ---  A4 --- --- ---
    voice1 |  E4 --- --- ---  A4 --- --- ---  B4 --- --- --- Cs5 --- --- ---
    voice2 |  G4 --- --- ---  C5 --- --- ---  D5 --- --- ---  E5 --- --- ---
        xs |
       xs0 |  C4 Cs4 --- ---  C4 --- --- ---  C4 Cs4 --- ---  C4 --- --- ---

So, I needed something to generate format 2 from format 1. While the use of three voices for a chorded instrument may sound like an annoyance, I can actually assign very different timbres for each voice, which is pretty cool.

While it’s not polished to the level I want it yet, behold: monogrid.py.

Naturally MIDI output is likely to be useful, though I won’t have it playing directly into the monomachine, because
most of the fun of Elektron gear is programming variance in the individual timbres of steps.

I still have to program in some more scales into the library, and teach monogrid to support multiple pattern inputs, you get the general idea.

Many people are confused about the differences between the web, grid, cloud, web services, and “as a service”. I’ve decided to help them out.

Click for Large

Here’s some questions I’ve never asked, and probably won’t.

• Why were the manholes in Nashua, New Hampshire triangular?
• Convince me that you are not a figment of my imagination, or me of yours
• List your top 10 favorite guitarists.
• Let’s change things up. You Interview me.
• It’s karaoke time! You have “Wheel in the Sky” by Journey, go. No looking up lyrics.
• Should NASCAR turn right in the Southern Hemisphere?
• What are the advantages and disadvantages of basing a number system on base -3? How about base -3i?
• Discuss how to make Ping Pong be successful in an 8PM Thursday major network time slot
• Draw a picture of a turtle.
• If your Mom said she liked PHP programming, would you still speak to her?
• In event of zombie outbreak, where are the most desirable holdouts in the city?
• Rate ducks, cows, sheep, pigs, and ferrets in terms of how funny they are
• How would you make extreme programming more extreme? Think “extreme ironing”, but better.
• Port GWT to node.js, except use COBOL

Recently got a new Macbook air, it’s awesome, and I took the opportunity to end my usage of a few web apps that were hurting my brain.

Ever read any articles that say the web/technology are rewiring your brain? I didn’t really have that problem, say, around 2000 or so. You used a mail reader, your chat client, whatever, and these things gave you nice alerts when you had stuff to read. You went on the web to find things. Web applications didn’t really exist, but lots of very good fat clients *did* exist.

However, juggling two web apps, gmail.com’s horrible user switcher, and occasionally visiting twitter to see if anything new was happening mixed the usage of the web for useful information with this weird feedback loop of “do I have stuff to look at? Maybe, let’s go look.”. Context switching is evil, and there’s a loss to flow and getting stuff done. You can easily get into “Hey Look, A Squirrel!” mode and be a lot less productive.

Anyway, the new Mac app lineup:

Sparrow, for reading mail and doing the whole Inbox Zero thing
Reeder, for reading RSS feeds
Twitter’s app, versus twitter.com
Alfred, just so I don’t have too many different ways to start things

It’s amazing how much my brain likes this.

How’d we get taken up by web apps that give us bad attention-draining interfaces that require us to visit and work with them, all different from one another? I don’t know. I’m sure a lot folks have been using Gmail over IMAP for a while, but I used the web app, because I liked it’s search, and had grown to think that was the way it was supposed to be done. OS X mail and Thunderbird have been relatively poor, so it was the only decent alternative, despite it doing some annoying things with threads, quoting, and so forth. Google Reader made it easy to subscribe to things even when it wasn’t great at making things easy to consume. Plus there was the whole “the web is the future” kind of discussion that was frequent on echo chambers like ycombinator. (I’m still convinced there’s too many new developers on those sites, as they’re way more captivated by the next Javascript library than they should be. And hey, get off my lawn!)

So, while we’re frequently told the browser is the future one true platform, and I look back longingly at days developing for Swing (not really) and WxPython (which worked great), I am happy to see the future in desktop apps. Yes, the web and needing to jump between so many different tabs to keep up with things *does* rewire our brains, as we have to go seek out information in some sort of event driven loop. Moving to push based apps means we have many less events to deal with.

Right now, I have no mail, and I have no need to reload gmail to check. And switch accounts to check the other. But I know I don’t have any mail there either. I also don’t have to check twitter, because I have no tweets. I can just focus on what I’m doing next. I’m less likely to need to get lost web surfing and can go put up Christmas lights. I’m slowly becoming less event driven again, and it feels great to not monitor so many input streams.

Technology shouldn’t have to rewire our brains and workflows, or steal into our time, it should be made to fit into it. So let’s not say the web is the new platform, let’s remember 1997, pre-webapps and how we probably got a lot more done then.

Cobbler moving to github is now complete. cobbler.github.com and Wiki.

Why do this? Well, github has better collaboration tools for one. Another more important reason is to make the knowledge that Cobbler isn’t a distribution-specific project really really obvious, and to open up work from people moving in different directions. Fedora Hosted was great at the time, but now it’s a flat list of half-abandoned projects where new people don’t find things. On github, browsing what people you have forked, you DO find things, and you are exposed to new projects. Where should some good code live so that people could find it? That’s why.

While I’d be remiss to not thank Red Hat for doing a lot to sponsor development over the years, I’m also happy to say it now lives on in a completely upstream, with Scott moving on Facebook (congrats!), James Cammarata doing a ton of work, and even taking some nice github pull requests from Canonical (arm support, among others), and all the commits being community driven by a pretty large pool of folks. It’s not part of a “modern” Red Hat management stack, even. So, reasons to keep things on FedoraHosted (implying a CentOS/RHEL focus) when we’re just as likely to get patches about SLES or Ubuntu? Not much. I’m actually very interested in seeing how much of the Cobbler stack I can get running on OS X.

What am I doing somewhat back around this? Hopefully not tons but making sure there is an environment where people can continue to work on it, though as I’m more and more involved with clouds, I like knowing that it’s around and kicking for when I am going to need to provision the physical boxen underneath that cloud, and that it works for everyone. I definitely plan on using it again in large capacities someday. Plus, there are some things here and there that I always meant to clean up … and they might be haunting me some