Everybody Hates the Popular Kid

Via Patrick, I just read Steve's latest blog post about code complexity. I think the vast majority of Steve's points are spot-on. Complexity in a codebase ultimately leads to disproportionate support and maintenance costs, complexity when on-boarding new developers, and a general productivity hit. When it takes me 30 minutes to get "in the zone", all it takes is one call from the boss to tear that down. That's a 60-minute productivity hit for a benign interruption and no tooling in the world will help you keep it all in programmer "RAM".

I was talking with a colleague of mine about this (Alok Singh) and we both agree that certain levels of complexity simply extend beyond the limits of most people's cognitive skills, it's simple and complicated all in one.

I agree with many of Steve's core assertions in this piece. But, I can't quite get past the Java-bashing and stereotyping that permeates the post and seems en vouge these days. Yes, there are bad java programmers out there, but is he really hitting on the limitations of the Java language and/or Java programmers in general?

A couple of things that stuck out for me:

"Design Patterns are programmers, and only programmers who use certain languages. Perl programmers were, by and large, not very impressed with Design Patterns."

I'm not sure I see this as an endorsement. I don't really know any non-Perl programmers who find another programmer's Perl easy to maintain. I've written a decent amount of it, and two of the top ten most miserable experiences in my programming career have been trying to decipher CPAN modules. Terse code does not make for manageable code and Perl programmers tend to pride themselves on brevity, readability be damned.

"It's obvious now, though, isn't it? A design pattern isn't a feature. A Factory isn't a feature, nor is a Delegate nor a Proxy nor a Bridge."

I don't really know what Steve's background was prior to Google, but I can say that as someone who works on commercial software which is regularly extended, our customers do actually think that having a factory is a feature. If we swap out authentication mechanisms, customers extending or writing plugins want to use a factory - they want one way to access a single API in Java. Lots of them. We could say, "no, use the REST API" but that hasn't actually seen much uptake (although it's there) and quite simply doesn't scale for core functionality like authentication.

Next is:

"Dependency Injection is an amazingly elaborate infrastructure for making Java more dynamic in certain ways that are intrinsic to higher-level languages. And – you guessed it – DI makes your Java code base bigger."

Actually, I can't see how this could possibly be correct so I'd love to hear more detail. IoC approaches like Spring reduce my code because I'm not using those design patterns that Steve is so against. I don't really care about creational logic any more because the reference I need is injected for me. I don't see Singletons or Factories any more, just references. I may have more configuration files than I did before, but I certainly have less code. Mature libraries like Spring do other nice things for me like hiding unnecessary unchecked exception handling, transactions across multiple resources and making an object remote when it has no inherent remote-ness. For example, I can publish any interface across Hessian, Burlap, JMX or RMI using spring configuration, the code doesn't know the difference. IoC has its issues to be sure, but code bloat is not one of them.

Moving on:

"I recently had the opportunity to watch a self-professed Java programmer give a presentation in which one slide listed Problems... The #1 problem he listed was code size: his system has millions of lines of code."

Ok, so the guy is a bad programmer, or he is bad programmer by virtue of being a Java programmer? I don't see the correlation. If he were giving a talk on VB would this even make the blog rounds? There are lots of bad programmers out there, but I feel like there is a real tendency to use guilt by association against the Java community. At the end of the day, one thing that is generally not disputable is that aside from the core *nix and C library collection, Java is *the* most ubiquitous set of libraries available. Steve likely has the ability to write a native hook against a native C library, I quite simply don't have the time and the Java libraries are my second-best resource.

As a counter-point, I looked at the amount of code in the mainline stable Linux kernel (2.6.23.12), which by count runs at 768119 in just the C - no headers, macros, etc. That's pretty big, and if you look at the committers, there are hundreds of people and companies (but not the almighty Google I might add) contributing towards that code base. But, for the life of me, I can't find a blog post slamming the amount of code in the Linux kernel or that it's too complex, or that it isn't contributing towards the greater good. Similarly, Apache HTTPD core seems to be running over 250K for just the HTTPD C code and surely requires a more skilled developer pool than your average Java developer would fill.

At the end of the day, I don't think Java is a programming panacea. But, if I put on my agile hat, and see that customers want solutions that they can run in their existing environments without worrying abut low-level library dependencies, and reuse a crazy amount of existing code, and that they can hire decent programmers to fulfill, then Java meets those tests and might actually be the simplest solution that delivers business value. C might be faster, Perl more "cool", but neither necessarily makes the most business sense. Business value isn't just about what the technology Illuminati tip their hat to. It's grounded in accessibility and more importantly, can I hire people to implement and support it. In that sense, Java is a decent solution these days. I tend to think business viability is a decent measure of a language, regardless of how it got there.

Socializing Eventual Consistency

I've followed Werner's blog for a while now and his latest on eventual consistency is one of my favorite posts. I recently advocated for an eventual consistency approach for a service offering we're putting together and lost. Part of that I think was that the technology to build an eventually-consistent client could really use some improvement and I'll talk to that in a later post. More at play though was the general issue of pushing people's comfort zones with new concepts.

I was somewhat conflicted after the discussion because the Agile part of my brain wanted to believe that the simplest thing we could do was flow with out skill set and just write to an SQL database. The systems experience in me was screaming the whole way at building a tightly-coupled, highly intertwined system when staring at a green field that didn't really have highly-structured relational data.

As always, I could have done a better job in making my case, focusing more on the technical and less on the emotional, but I sure wish I would have had read Werner's blog before the discussion. Two things really stood out:

"Eventually consistency is not some esoteric property of extreme distributed systems. Many modern RDBMS systems that provide primary-backup reliability implement their replication techniques in both synchronous and asynchronous modes."

When I talk to people about things like eventual consistency, I generally get a response along the lines of "that's cool, but we're not Amazon". No, most companies aren't, but I'm not sure that we shouldn't leverage all the brain power and learning from Amazon to our benefit. You can only make buggy whips for so long while thought leaders speed ahead.

The other piece that stood out was:

"Inconsistency can be tolerated for two reasons: for improving read and write performance under highly concurrent conditions and for handling partition cases where a majority model would render part of the system unavailable even though the nodes are up and running."

Customers are always going to want the C, A and P from commercial software, but experience tells us that they are not all possible. If you buy Werner's arguments, the P is impossible for distributed systems. Most business-focused users I've encountered, when really pressed, almost always choose the A over the C.

When trying to socialize concepts like these, there is truly an art to helping people out of their comfort zones. I'm not as good at it as many people, posts like Werner's go a long way towards helping with that.

Now, if they can just fix that SimpleDB API...

Cheers to Adobe

This is great news from Adobe and should really help them distance themselves from other Ria platforms by providing the middleware to help build better apps without the hefty price that used to come with LiveCycle DS. While I always liked LiveCycle DS, the price and proprietary nature always made recommending it difficult. No more! Now, if we can just get them to keep opening up and give the community the player :)

I also read this announcement to mean that the AMF spec is fully open as well which is also great to hear. I was always unclear on exactly what was available surrounding AMF, no more ambiguity there is equally big news.

Atom over XMPP

I'm currently experimenting with the idea of using Atom over XMPP, at a minimum to push out a pointer to an entry behind a firewall into a more public staging area.

The thought would be that the Atom "pointer" to the entry is pushed into the public space, and when a client of that entry wants more detail, there is an XMPP service associated with the entry that can be used to retrieve the details.

Exactly half of me thinks that this is what Atom was meant to do - get the notion of an entry out there with enough information to make a decision about weather you want the detail, and let the interested parties decided if they want to fetch the remainder. The other half thinks that this is just the geek in me wanting to use Atom when there really isn't a need for it and that XMPP and less-structured XML stanzas can work just fine, that I can demand pull the list of entries when needed as well as the details.

There are some general rumblings out there on the interwebs, but no great success stories. Anyone care to share?

St. Peter seems to be thinking along similar lines. I would love to hear some real-world usages before I'm sold on Atom in this context.

Update: ralphm points to a newer draft on xmpp.org. Thanks!

Having and Eating Cake

Fuzzy asks about options for disconnected client alternatives.

I started a reply, but it got too long so I decided to post and link instead.

I've now done this analysis a few times for a few different scenarios and as with most things, the devil is in the details. At the end of the day, although not quite so dogmatic, what usually matters most is ease of programming and that is generally driven by your server-side. It probably shouldn't be so, I'd love to say "Just put a set of RESTful services out there and I'll handle the client thanks", but in reality the separation is rarely that clean with more rich (i.e. offline) clients.

Fuzzy asks about a couple of technologies that I've worked with and others are mentioned in the comments.

I'd stay away from Tibco GI if you want to have any hope for advanced functionality like offline access, XMPP or direct socket manipulation. More rich APIs are available in XUL and AIR if you need to go there, and when I last worked with GI it was quite brutal (I.E. for development environment, no FF support, massive code base). Most of these have changed, but I feel like with something like GI, it almost doesn't matter that it's BSD licensed, you won't be able to grok or change the code anyway, it's too complicated and if you need what it does, you are almost certainly pounding a square peg into a round hole.

In the comments, Brian advocates a combination of Gears and GI - that scares me to death. Two technologies that have no knowledge of each other using the browser as a binary integration bus via JavaScript - I've yet to see that work on any effort of size and it's bound to cause some serious headaches, especially when you can't control what a user does from either side of that integration. Doesn't pass my sniff test.

Most importantly thought, I'd look at the community story there, it's not very compelling. GI strikes me as almost abandon-ware by Tibco and seeing as how they were so late to the OSS game, I have doubts about their commitment to sustain the community. Conversely, AIR has far more momentum and Adobe worked hard towards building community from the beginning.

For what it's worth, when I was talking with Tibco about these concerns and pressing them to open the code, they laughed and told me it would be really expensive. Guess I was on to something. I'll continue hammering Adobe to do the same with the Flash Player with every opportunity I get.

Having worked with XUL, I found it quite painful. The entire effort is under-documented to say the least. For Fuzzy's purpose, it obviously Mozilla-specific which may or may not be an issue. I can't say I've ever seen anyone build anything with any serious eye candy on XUL, just basic chrome and mostly tree views. If you have half an inkling that you might need some eye candy to sell your product, XUL probably isn't for you.

More importantly though, If it doesn't meet your lower-level needs for things like images or networking, be prepared to write some cross-platform C++ and COM-like IDL. You will also need to deal with version differences (i.e. XUL on FF 1.5.x is not the same as in FF 2.x). That said, if made to choose between GI and XUL, I choose XUL.

My personal bias is still for AIR. The community has good momentum, programming model is the most simple of the other options (including Sarge's Tcl comment - have fun with that return to DLL-hell). Not open though, so if you go that route make sure it's critical to your story and that open-ness is not.

Lazlo can "compile" to Flash as Mike W. mentions in Fuzzy's comments, but can also remain in AJAX/DHTML land if you so choose - Flash simply performs better. In all the testing I've done, Lazlo will not perform consistently nor render consistently if you do not transform to FVM bytecode, so those are likely not options.

One other potential option is haxe. Saw a presentation on it at OSCON a few years ago, seemed like a solid technology but hasn't really caught on in the states anyway. It's been around for several years now and people who use Neko seem to love it. Can't speak from experience with that one, but I'd give it a look.

Worst Measurement Ever

I've been resisting posting about it for some time, I think since Patrick pointed me at the link almost six months ago. I've reached my breaking point. In my quest to learn Erlang, I've come across at least three blogs and/or articles that actually site this "measurement" with attribution as if it were some sort of legitimate claim as to the scalability of Erlang.

Given that I'm reading his book, I would really expect more from Joe Armstrong and by attribution Ali Ghodsi.

The Apache vs. Yaws measurement is one of the most useless pieces of information produced by the Erlang community, to the point that I'd argue it does a disservice to the Erlang community and the language.

In any sort of quasi-scientific measurement (or primary school science experiment for that matter), I would expect to see:

1. the actual code used to test the server
2. the actual Linux kernel version
3. the actual yaws server code

Instead, we see a graph of an under-documented experiment that creates conditions for a DoS test at best, not a web server scalability test.

From the looks of it, this "measurement" is not:

1. documented to any reasonable extent - what kernel was used? what was the exact Apache configuration? what was the Yaws code used to serve the files?
2. repeatable - no source, little documentation, little detail on the environment
3. peer reviewed - without the above, nobody else can discuss in detail or attempt to repeat the same results
4. valid - it simply does not repeat a real-world environment faced by any modern web server

Allow me to support some of those assertions from real-world experience helping large web sites:

1. Not knowing what Linux kernel version was used, how Apache was configured (in detail) and how Apache was built, it's impossible to know if Apache "was configured for maximum performance". Seeing as they decided not to share any of that vital information, I consider the entire experiment invalid. These things matter, just like if I were to run BEAM on an SMP system without SMP, it's easy to misconfigure the runtime. For example, Apache started using epoll in 2.6.x kernels. Anything earlier than that would be an inappropriate kernel to use with mpm_worker. We wouldn't know from the sparse detail if it is a valid configuration or not.
2. In a real-world environment, if I saw 100s of connections inactive for 10 seconds at a time, I would simply set the connection timeout to five seconds. Not sure how you would do the same on Yaws.
3. Most production web servers don't serve one byte files (the "load" requested by the clients in the measurement). I can't actually recall the last time I saw a high-volume server dish out more than one or two one byte files. Instead, real web servers serve files that measure in the KB or even MB in size. In fact, given Erlang's empirical difficulty handling basic file I/O, I'm not surprised that they chose a one byte file to use in simulating "load". If the file were any larger, Yaws would likely have been swamped under it's own unbuffered I/O implementation and exhibited substantial latency per request.
4. A one byte file would be cached upstream of the server in a high-volume site, particularly if your clients were operating over latent connections where one character per ten seconds was realistic (i.e. dialup).
5. If this were a real DoS attempt, it would be choked off at the ISP router, well before the web server saw the intentionally slow request.
6. I can personally type an HTTP request faster than one character per ten seconds, this is simply not a realistic access pattern from a benign client.

I'm not going to say that Erlang does or doesn't scale. My point is that this diagram and the corresponding writeup are utterly useless and that to site it as a valid study is irresponsible at best (especially when it's your own thesis).

I put this in the same category as Microsoft FUD - there is an agenda here, and people will read it and say "Oh, yea - told you we rock" without questioning the details. Most however, should dismiss it as pure FUD, and FUD served from an Apache 2.2.3 server no less (maybe Yaws wasn't up to the task).

My Bow-Legged Master - Comment

I tried to comment directly on Bill's Blog but comments were broken again. What I wanted to say was:

I think the real tragedy of this legacy is that we currently have installed, in nearly every networked node in existance, the potential for a simple, iterative, resource-driven client that can't really speak the protocol it was designed to handle. I repeatedly find myself grudgingly writing a curl wrapper to test a RESTful API in a pinch while my browser looks at me and laughs.

Oh, and the irony that your comments button says "Post" rather than "Put" is not lost.

Hopefully comments will be fixed soon and I'll cross post, er cross PUT.

Scale in an Ontology Vaccum

I had the pleasure today of reading Clay Shirky's Ontology is Overrated. Being in the collaboration software business, understanding how people classify artifacts is not just a science, it is vital to the evolution of the software we build.

For our purposes, I think it's a dual-edged sword. Make things too wide open, and users won't evolve their own classifications and people will stray away from the true strengths of the tools. Make things too ontology-driven and users will naturally migrate away from the structure, save everything locally and keep emailing and searching with Google Desktop. We have to build a better mouse trap to survive.

For me, a big take-away from Clay's piece was that any attempt to define classifications will fail. The Dewey 200 category is a fantastic example and one that really drives home our inability as simple humans to step out of context.

So, to paraphrase Clay's hypothesis a bit, any attempt I make at trying to define an ontology will fail, mostly because there is no way I can out-think the masses. Ok, fair enough, so how to build software that better helps the masses? Not too difficult at face value, things like tag clouds work great. Unfortunately, the implementation problems grow exponentially under scale. As the volumes of information available electronically continue to grow, and as information compounds on top of itself through links, blogs, etc, the notion of aggregating tag clouds, and more importantly, doing things like suggesting similar clouds shifts from a usability problem into an architectural one.

For collaboration software to innovate, it is faced with several interesting dilemmas. First, how do we expand beyond the bounds of our own control and pull in relevant data outside our domain? It's scary, but if you believe that collaboration software must go down that path, then we're faced with more integration concerns and less of the simplified workflow and text processing which is how most people think of their collaboration tools today.

Assuming you can go that far, how do you actually make sense of all that data? You start to run into scale problems real fast. Customers want one node to run everything and at the same time roll-up data from five internal sources, and ten external sources with partial federated identity all while being responsive. That's a tall order, and one that starts to make the "C" in "CAP" increasingly difficult to archive.

My gut tells me that Werner Vogels' and Amazon's approach to eventual consistency described in Amazon's Dynamo will win out. When you're aggregating and analysing terabytes of data looking for relevance, you have to make sacrifices.

plan for $display_id will be renewed for another year

I received an email from Yahoo! today with this in the subject line "Your Yahoo! Custom Mailbox plan for $display_id will be renewed for another year". I've seen recently that Yahoo! has been hurting and that they have been losing customers, but I can't imagine why.

I used to host all my small business domain registrations and email with Yahoo! Starting a year ago, I moved nearly all my paid services away from Yahoo!. It became clear to me over time that they didn't really intend to actually support their small business services. I challenge anyone to send an email to Yahoo! Small Business support, you can't. There is no means to contact them. At best, you can fill in a generic form that gets lost in the ether (I've tried that a few times too and nobody has ever responded).

No thanks, I'll take my money somewhere that has staff capable of correctly generating a mail merge and that will actually respond to my emails when I have a hosting issue.

Yahoo! is and will be my portal, but come on guys. Maybe Jerry can correct the course, I hope so.

Mind the Gap

I was recently fortunate enough to actually be offered a choice for my hardware and operating system at my current job. It's unfortunate that such choices aren't more common for engineering-types these days. I'm a big believer in the best tool for the job mentality and for me that's clearly some derivative of Linux on the desktop (and likely x86 Solaris on the server, depending on what I'm doing with it).

Faced with said choice, I went with Linux/x86 over Mac (that's another post all together). Having had good success in the past with Ubuntu, I decided to go with Gutsy Gibbon beta. Unfortunately, it was more beta than I would have liked.

First attempt at installation laid down the OS as normal. Being a sucker for eye candy, I wanted to get Compiz working ASAP in hopes of making the Windows users around me think twice. This turned out to be a big mistake. I ended up installing the binary ATI drivers and patching all in the same shot, and from there Gusty went into some sort of video card config hell. Despite my best attempts to hack /etc/X11/xorg.conf, I couldn't rescue my UI and had to start all over from scratch. Thankfully, I had a second hard drive available and copied all my userland tweaks there before rebuilding the whole rig.

This time around, I did a normal install. After making sure that was stable, I went after the binary drivers and got them working. Then, I allowed my updates to run, first system packages, then X11/Xde packages and binary drivers, backing-up my xorg.conf after each step so I could revert.

At the end of the day, the whole thing still isn't all that stable. I could bail on the eye candy, but that would be to admit defeat and that's not how I roll. Still though, I expected more. This experience was not all that much better from my previous Gentoo encounters with multiple reboots to the live CD to bail myself out. I was hoping for more, and didn't get it.

Finally, it's worth mentioning that Java UIs seem to struggle somewhat under my config with Compiz. IntelliJ's menus often don't show up and other Java-based UIs are also lacking.

Speaking of IntelliJ on Linux, it could really use some work. Their reliance on Java's fonts is plain painful, especially with so many nice anti-aliased fonts out there in Linux land. It's a pity that what is generally such a mature product couldn't keep-up with Eclipse and at least match SWT's handling of fonts.

Downsizing

I'm both happy and sad to announce that I'll be downsizing my career. I'm leaving behind my work as a Technologist for Liberty Mutual and assuming a core engineering position with Jive Software here in Portland.

I'm sad to be leaving the team at LM. They are immensely talented and capable of great things, I sincerely hope they are given an opportunity to act on that talent.

That said, I'm looking forward to joining Jive, more so than most of my previous career moves. If you follow the news stories around Jive, they are doing good things and doing them well. They are building on open protocols and generally lean towards Open Source Software as well - both things I highly value.

Have a Seat on the Couch

No idea why it took me so long to find CouchDB, but I will be watching its development closely and will start probing the source once I have a better handle on Erlang. Highlights include a RESTful API, a bevy of clients to talk with that RESTful API (Ruby, Python, Java, JavaScript), data replication for reliability, and off-line capabilities. I can't think of a much better use of Erlang on the server side and I love the use of SpiderMonkey for a Query language , that's plain brilliant and something people should use more of.

Flexy Flex

I will be speaking at one of the Portland Flex User's groups on Sep. 20. The topic will be integrating Flex with RESTful applications, something that really should be easier than it is.

Apache Is My Service Hub

Ok, so I nicked the idea of this post from mnot's Squid is My Service Bus and tried to extend the concept based on ways I've used Apache HTTPD in the past.

In general, I'm a big fan of Apahce HTTPD. It's immensely powerful and has been my "Swiss Army Knife" of the web for some time now, proxying this, caching that, dynamically serving things all the while never once becoming the primary constraint in any distributed system. That's saying a lot as a perimeter service responsible for all ingress traffic.

It occurred to me in discussions with Mike and Patrick that Apache's utility makes it an ideal Service Bus of sorts. Service Hub might be a better term. Most of Apache's default functionality is geared towards moving resource requests around and not protocol mediation (a key criteria of a bus). However, nothing stops the Apache developer from making the server more bus like if the requirements so dictate.

The idea goes like this

• Service consumers, RESTful preferably (although SOAP will work too), desire to perform operations on a resource. The consumer has a client that is smart - it knows that it can rely on finding one or more Service Hubs in the local vicinity, but doesn't care exactly where that hub is.
• The client performs some measure of discovery, a DNS lookup backed by BIND zones, a Zeroconf search for the Service Hub, a broadcast search, something that lets the client discover, at runtime, it's friendly local Service Hub. The important part is that all clients search for their local Service Hub in the same way and in a manner that lets us have one or twenty hubs depending on our needs. We can scale up or down and the client behavior doesn't change.
• When the service client finds a hub, it makes a request of that hub. Next time around, it might use a different hub, or it might hold a keep-alive for the HTTP connection to that hub.

So, what makes Apache particularly well suited for this role?

1. Apache HTTPD is ubiquitous - Apache is capable as acting as an origin, a proxy or a gateway for resources all in one set of configuration while being 99% HTTP 1.1 compliant. It runs on all Unixes I know of, Windows and other platforms. I generally don't think of Apache as middleware, but if you abstract Apache up a layer and treat it as a RESTful gateway, it does fill a role traditionally reserved for middleware.
2. Apache HTTPD can reverse proxy - Apache has an added advantage that it can perform crude load balancing in a reverse proxy configuration. This means, you can have service clients consume HTTP resources without knowing that they are talking with one or twenty back-end origin servers. Sure, F5s have been doing this for some time now, but try installing thirty F5s in a large integration, one for each broadcast domain and see what it does for your budget. Additionally, Apache can reverse proxy for loads of protocols out of the box, HTTP(S), FTP and AJP open worlds of opportunities for the systems integrator.
3. Performance - Apache HTTPD builds on Apache's portable runtime (APR) which is a fairly low-level abstraction on top of most OS system calls. This gives it tremendous performance benefits (like using scalable non-blocking I/O ala epoll on Linux) while still remaining relatively platform-agnostic.
   
4. Extensible - Not long ago, writing Apache modules was a poorly-documented black art. That is improving substantially with books and better reference documentation. But, writing a module isn't necessary at all. With dynamic language alternatives like Python and Ruby that can run in-process with Apache workers, you can extend Apache as a Service Hub however you like and without writing C.

I don't expect to see wide adoption of this type of approach any time soon. If RESTful architectures catch on and people start to see the web as a series of resources, Apache HTTPD's role will continue to grow. It's high time we stopped looking at Apache HTTPD as just a web server and started viewing it as an HTTP Gateway.

Async Beauty

Wow, came across AsyncWeb today and have to say it's a thing of beauty. Excuse me while I tout my own greatness for a while but about two years ago I had an idea to write a NIO/async REST engine for wicked fast, non-servlet cruft, async REST implementation and AsyncWeb + RESTlet is headed in that exact direction. RESTlet is equally impressive and has come a long way over the last six months. Love the pluggable connector design for RESTlet, should really allow it to move in ways that the Servlet spec hasn't been able to.

If you are trying to do things like COMET with traditional threaded servers, you're absolutely mad and need to look at this approach.

New Toy

I have a new toy on back-order with Amazon.

In short, I'm after most of the iPhone features without the phone part. I want:

• A Video Player (including DIVX)


• A Music Player (including OGG)


• A browser over WiFi in a pinch


• A small form factor with decent battery life


• WiFi connectivity

It's not an ideal device, but it's a start.

• I'd like to see an iPhone-like browser, but Opera will do - this isn't my main browser
  
• If I need a full-power browser I'll bust out a laptop.


• I wish I had a competitive device that would play iTunes content

As an additional plus, the Archos will allow me to play Flash content. In general, I'm not seeing a compelling reason to purchase an iPhone over the 605. At a minimum, until until Apple fixes the iPhone's Bluetooth stack to let me sync calendar and contact over Bluetooth, I'll be looking elsewhere.

Enough with the Thai Already

I love living in Portland for many,many, many reasons. But enough already with the lack of food diversity. A local sketchy Teriyaki place just closed down in my Hollywood neighborhood. What opens in it's place? Another Thai restaurant. I won't be going there, I already have a Thai rotation of some really good places, I don't need another. I can count at least ten in a three mile radius, Google says there are more. So, if you're opening a new restaurant in Stumptown, I submit:

• No more Thai


• No more Pho


• A strong Indian effort would make a killing

OMG What Happened to My H3@d3r?

Wow, read this from Scott Chapman which got me down. Yet another attempt to do REST from a Flex app with significant hackery bolted on, fails. I've said it before, when you are concerned with your HTTP headers, you are fighting the wrong problem. I don't spend much time thinking about my TCP window scaling, why should I have to constantly focus on HTTP protocol-level craps?

I'll say it again, someone needs to step-up and write an ActionScript HTTP client. Until that happens, the browser and it's FVM cohorts are the wrong platform for RESTful requests.

Toss the Bath Water and the Baby

Bill Bill de hÓra picks up on the broken-ness of the Flash VM's ability or lack thereof to expose headers to the fault callback. He also pulls in to hell with bad web clients. As I read that, I'm convinced that Flex is actually my escape hatch from browser insanity. I'm heads down in CSS Mastery at the moment trying to make my nav bar behave sanely across browsers for some non-profit work I'm doing. It's sick the amount of work I'm doing to make sure A is left of B in IE 5.5 on Mac *and* IE 7 on XP x64. Comparatively, the time spent doing the same thing in Flex would have been 1/10th the effort if that. So, I actually agree with Bill on this, we should get rid of bad clients, those bad citizens of the web that break and hurt our beloved web.

That's right, we need to toss out the browser all together. Em, or even better, let's actually make our browsers behave as good citizens in the HTTP multiverse that is bearing-down on us like a freight-train made of UTF-8 printable characters (and none of those binary, non-readable ones either thank you very much). As an open message to FF, IE, OP, KQ, etc., I want DELETE. I want access to headers in my XHRs, I want full control. You want to hide it from me, the ignoramus developer because I'm not ready? Ok, wget, here I come!

XMPP MIA?

I've been trying to hit-up xmpp.org for two days now and nothing, nada, zilch from their authoritative DNS server. My dig for the www looks like so:

--> dig www.xmpp.org

; <<>> DiG 9.4.1-P1 <<>> www.xmpp.org
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54001
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 8
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;www.xmpp.org.                  IN      A

;; AUTHORITY SECTION:
org.                    45762   IN      NS      TLD2.ULTRADNS.NET.
org.                    45762   IN      NS      TLD5.ULTRADNS.INFO.
org.                    45762   IN      NS      TLD4.ULTRADNS.org.
org.                    45762   IN      NS      TLD6.ULTRADNS.CO.UK.
org.                    45762   IN      NS      TLD3.ULTRADNS.org.
org.                    45762   IN      NS      TLD1.ULTRADNS.NET.

;; ADDITIONAL SECTION:
TLD2.ULTRADNS.NET.      45863   IN      A       204.74.113.1
TLD5.ULTRADNS.INFO.     1251    IN      A       192.100.59.11
TLD4.ULTRADNS.org.      45762   IN      AAAA    2001:502:100e::1
TLD4.ULTRADNS.org.      45902   IN      A       199.7.67.1
TLD6.ULTRADNS.CO.UK.    477     IN      A       198.133.199.11
TLD3.ULTRADNS.org.      45863   IN      A       199.7.66.1
TLD1.ULTRADNS.NET.      45762   IN      AAAA    2001:502:d399::1
TLD1.ULTRADNS.NET.      45863   IN      A       204.74.112.1

;; Query time: 62 msec
;; SERVER: 209.244.0.1#53(209.244.0.1)
;; WHEN: Wed Aug 22 23:49:06 2007
;; MSG SIZE  rcvd: 344

I like XMPP, I do. But if *they* can't get their DNS right, I'm scared (XMPP depends heavily on DNS working properly).

Easy Peesy

Making it stick.: The "Ease" Argument Again?

I've got Patrick's back on this one, I have a hard time believing that anything that starts with WSDL is going to make my life easier.

I like Dan's project, I do. I think XFire is the way to go if you have a hard and fast requirement to expose a Java-based service via SOAP. But make sure you actually need to go there before you do. If your biggest customer says "we use SOAP and only SOAP" for integration with trading partners, hello XFire.

Thus lies the path to Kakotopia! In my experience, you won't be pointing any tools at each other that actually grok that WSDL and can talk to each other without serious intervention on your part. My last experience trying to do this very thing was a Java/.NET integration for a project was about two years ago, the experience went something like this:

1) Expose XFire service by configuring Spring adapter booya
2) Check WSDL - looks OK, not that I'd know without studying the spec
3) Use VisualStudio .NET Stub generator wizard to create a C# class for invoking the service.
4) Try and run the class from step 3
5) Witness failure, something about unsupported binding
6) Read this.
7) Change API to XML-RPC.

I have about eight of these stories, some of them end with me snooping HTTP Headers because of obscure server errors. Some, like a recent attempt to create a Flex service to consume Confluence's WSDL end with obtuse client-side schema errors. That's about all the CPU cycles I give to these types of things, after that I fall back to things I can control and see. Maybe some day it will work, but I haven't seen it materialize yet.

Given recent episodes with REST, I'm not sure it's a clear winner from the browser either, because I again find myself looking at HTTP Headers to try and figure out what is broken. I don't want to spend my time doing that. Seriously, I'm done breaking out Wireshark to troubleshoot protocols that work until people try and get cute with them.

RESTful Flex Angst

Following on the previous post about issues encountered getting Rails and Flex to play together, we've now observed that certain popular browsers do not correctly interpret the HTTP specification for status codes on HTTP responses. Namely, IE 6 (haven't tested 7) treats any 200 status code other than 200 as an error. Perform an overloaded POST to a RESTful service in IE and get a 201 back, IE exposes a status of error to interested applications.

Why does this matter? When trying to do Flex integration with a Rails back-end, we are required to rely on Flex's callback mechanism to tell us if we get a result or a fault. Flex apparently, relies on the browser's plumbing to determine the success of the request. So, updating a RESTful resource via a Flex HTTPService for example appears as a failure at the Flex layer because IE tells the FVM that it got an error. This was the source of great angst for us because most of us test our Flex applications in Firefox.

The problem is further compounded by the fact that Flex doesn't expose any of the raw response data to us, simply a FaultEvent with little useful information (one of the dreaded stream errors actually). No headers, no body content, nothing. I've seen blog posts that hint at this being a limitation of the FVM's status as a lowest common denominator runtime, Flex included - some browsers don't expose headers to plug-ins so neither can the FVM.

When I find some time, I'm going to fire up the ActionScript Socket API and write an HTTP client that doesn't require overloaded POST, that exposes plumbing of the HTTP, and that allows *me* to determine what is or is not an error.

Alternatively, I've got a more simple tool in the works that will allow you to test HTTP methods of all sorts and status codes propagate back into the FVM.

In a future post I'll dig into some of the interesting behaviors we found examining these behaviors from the stand-alone player and how it does it's networking.

RESTful Rails Angst

I've been working with Rails to provide RESTful services to a Flex application recently and a number of issues have come up that people need to know about dern it.

Today's story entails a battle with Rails' scaffold_resource. The RESTful generator makes a noble effort to create RESTful controllers. However, a few minor issues pop-up that need repairing in the current incarnation of the generator.

The most glaring issue is that the default code doesn't handle ActiveRecord find errors gracefully. For example, if I have a FoosController servicing requests to "/foos/1.xml" and that model :id=1 doesn't exist, the default FoosController will throw a RecordNotFound which up the call stack results in a 500 error being returned to the client. This, is unfortunately not "RESTful" as they say. The correct behavior would be to return a 404 indicating that the desired resource does not exist, not that the server could not handle the request. Adding this behavior is not difficult, but it's somewhat tedious in that each generated controller exposes four find calls that can fail in this way.

Additionally, as Peter Armstrong's solid PDF-only book on Flexible Rails points out, the default implementation of to_xml used throughout the controller is quite painful for certain clients. Most programming languages don't allow "-" in member names and as such, mapping tools that attempt to make XML traversal easier by exposing the XML structure as a choke on the default XML marshaling. As Peter points out, you can change this behavior by adding the ":dasherize" option but again, this is all over RESTful Rails controllers.

I could fix both of these through some hacking on the Rails distro, but then I have to remember to keep my changes across upgrades. Another option would likely entail injecting some app-specific base classes into the hierarchy, again not an idea I'm crazy about. If I come up with a better approach, I'll post it here. Or maybe back as a patch :)