Books! It’s Raining Books!

June 25, 2008 – 12:57 am

Now, right this very minute, you can learn pretty much everything there is to know about Dojo thanks to 3 newly published books. Writing a book on Dojo is hard in the way the writing a book on Python is hard: there’s so much to talk about, where do you start? When you could teach anyone anything, what do you focus on? Thankfully each of the books takes a different tack, talks to a different audience, and as a result I think the entire spectrum of web developers is pretty well served. Having reviewed 2 of the 3 books before they went to press (Dylan and Pete reviewed the other one), I’ve been amazed both by the depth of the books and by how different they are.

Pragmatic’s “Mastering Dojo” has my name on the cover, but don’t let that fool you…it’s actually quite excellent, largely because Craig and Rawld focused do heavily on helping you not only learn what’s valuable about the toolkit and how to use it, but by digging deep into the guts and showing you why the pieces are put together the way they are. The real art of building really responsive JavaScript driven UI’s is about making good tradeoffs, and this book really helps you understand what Dojo provides you with in ways that let you trade things off for the benefit of the user experience.

The Pragmatic book isn’t shipping from Amazon yet (unlike the O’Reilly and Addison-Wesley books), but if you buy it from the Pragmatic Programmers directly, you can get a PDF of the book immediately while the dead-tree copy wends its way through the end of the supply chain.

Update: Andy Hunt emailed me to let me know that the Pragmatic book is indeed shipping, and last night, upon arriving home from a business trip, I found my copies of the book waiting. Andy informs me that Amazon is also shipping them, so if you prefer the “one click” experience, you can order there as well.

“Dojo: The Definitive Guide” really is. As a reference, you can’t beat Matthew Russell’s tome. Where “Mastering Dojo” teaches you the how’s and the why’s, “Dojo: The Definitive Guide” is the book you’ll keep on your desk and reach back to when you’re not entirely certain what the inheritance tree of the Dijit form widgets is (and therefore, which you need to subclass or mix in). “Dojo: TDG” is chock full of insightful commentary and explanatory diagrams, and where the Pragmatic book helps you learn the pieces and pull them together intelligently, TDG gives you more of the pieces and helps you really get a handle on the vast functionality available in many of the nooks and crannies of Dojo. Don’t develop serious apps without them both.

James Harmon’s “Dojo: Using the Dojo JavaScript Library to Build Ajax Applications” stands out among the crowd as the easiest introduction to the toolkit. While the O’Reilly and Pragmatic books provide serious firepower for application developers, James’ book gives a solid introduction which helps web developers who might not be down with the whole “Ajax” thing just yet a chance to catch up and start taking full advantage of the features Dojo has to offer. Large chunks of Dojo have been designed with non-programmers in mind, from the declarative markup syntax to the template system, and James’ book helps really showcase how simple it is to start building rich, compelling UI’s with Dojo.

There’s probably still room in the market for 2 more books: one on using just dojo.query() and dojo.behavior for progressive enhancement, and one on advanced dojo.data (there are a pleathora of stores and use-cases there) and visualizations like the Grid, Charting, and dojox.gfx. I know that there are even more books in the works of, for, and by the Dojo community, and if the quality of those that come after is anything like these 3, it’ll be just more proof that when the Dojo community does something, we do it right.

My personal congrats and thanks to all the authors who poured their lives into these books for months on end. The results are nothing short of spectacular.

By alex | Posted in community, dojo | Tagged , , | Comments (3)

“Why Do I need To Sign This?”

June 11, 2008 – 3:56 am

There has been much discussion in the various Dojo fora of late regarding the need (and hassle) of requiring that all contributors send in signed Contributor License Agreements. These agreements state that:

  • Those contributing to Dojo Foundation projects actually own what they contribute and therefore have the right to license it to someone else
  • All of the rights needed to preserve the freedom of the code over the long haul have been contributed

Aside from some legal jargon, that’s all that’s in the agreement. So why have it? Why create the barrier to entry for newcomers who just want to pitch in? I have great sympathy for the impatient potential contributor huffing “why do I need to sign this, anyway?”, so this blog post is an effort to boil it down. The reasons start with meritocracy.

Open Source projects often pride themselves on creating a more level playing field; when it works right those whose contributions are good are recognized while those whose contributions are bad are left with bit-rotting patches and hopefully some friendly direction on how to improve. In this way, it’s the essential function of OSS projects to separate good contributions from bad. Oddly, the CLA process is a simple quality filtering function for weeding out the unserious, or simply another way to weed out potentially good contributions from bad.

CLAs are an annoyance to be sure, but consider what they attest to. I’ve heard the argument from time to time that “CLA’s violate the spirit of Open Source” by limiting who can contribute, but that is indeed the point! Mature projects like Dojo don’t accept patches without documentation, unit tests, and good code style…why should clean IP be any different? Indeed, CLAs allow us to be open yet rigorous at the same time. The CLAs process stands in stark contrast to many “open source”-in-name-only products which are produced by single companies or individuals but which don’t provide any way to materially contribute back or become part of the project directly. The CLA process is both a sign that the project is open enough to allow you to “get your itches scratched” if you really want to contribute but also mature enough to manage the risks that come along with allowing everyone to potentially participate.

More to the point, do you really want to be taking code from a group of people who won’t put in writing what everyone assumes about their contributions? And how seriously should you take an organization that hasn’t thought hard enough about their own product to ensure that they actually have all the rights to the work they distribute? Remember, there’s no requirement that anything be Open Source or that OSS products be developed as open projects, but the CLA process is in many ways a seal of quality: projects which require it are built to last (at least on an IP basis) and are also open enough to ensure that their community can grow.

One of the best aspects of the CLA process is that it gets people who are contributing to think about what it means to contribute. The CLA process means that they’ve printed out, signed, and hopefully read and understood that they are doing something serious and that they are joining a community of people who likewise take their work seriously. I really only want to work with people who are committed enough to making Dojo better that they’ll take the time to think about how their work is licensed. Far from being just a task you need to do before you can contribute, the CLA process ensures that the people building Dojo are intellectually tall enough to ride.

Tall enough? Join us!

By alex | Posted in Dojo Foundaton, licensing | Tagged , , , , | Comments (6)

Gears De-Brands

June 6, 2008 – 8:13 pm

There are a lot of things about Open Source that are easy to get wrong, either intentionally or by accident. Given the number of folks who get it wrong, it’s pretty clear that it takes real leadership for a project that’s funded largely by a single company to commit to having external committers, manage IP rights in a responsible way, and really work to engage with a community outside of the folks who show up in the office every day. Speaking from experience, I can tell you that it takes real work to ensure that your project isn’t just a code dump or even a read-only subversion repository that just happens to be released under an open license. Real, credible, honest-to-goodness, 100 point open source requires a effortful selflessness that rarely comes naturally to individuals and even less often to companies. I’m blessed to work for just such a company, but the web development landscape is littered with badge-ware, source-available-but-not-open projects, and other abuses of the spirit of the Open Source development model.

It’s no small relief, then, to hear that Google is doing something incredibly mature: they’re taking their name off of Gears. This comes in addition to their previous commitments to keep development truly open and to collaborate with anyone who will help them. From a purely corporate stand-point, it’s the kind of move that takes cojones.

Google’s de-branding of Gears stands in sharp contrast to Yahoo’s half-assed Browser Plus effort which not only isn’t Open Source, you can’t even use it from non-Yahoo domains yet. It’s impressive work technically, and Gears could learn some things from YBP’s plugin architecture, but it’s entirely unclear how such a closed product will help address the fundamental risk facing the web today: we need a trustable, open way to rev the web faster. One that can’t be stopped in its tracks when a Microsoft or Netscape lose the interest or ability to push the web further on their own.

With Google’s move, they’re saying more clearly than ever to the Yahoo’s of the world: “dude, seriously, put down the proprietary and help us make the web better”. It’s my sincerest hope that the Yahoo’s, Ebay’s and Amazon’s, and IBM’s of the world will all heed the call and work with Google to push a truly open Gears further, faster. The web needs the open process, mature leadership, and important feature set that Gears is delivering. No less.

By alex | Posted in Uncategorized | Comments (2)

Wedding Planning

June 4, 2008 – 4:47 am

Jennifer and I were married a little while ago, and as I’ve talked to people during the planning process it has become clear that we had a very different perspective and did things differently as a result. More than a few of the people I’ve talked to about this (mostly guys) have asked me to write up our approach and decision-making process, so here goes:

First, let me outline our constraints a little. Jennifer and I have both been out of our parents houses and financially independent for quite a while. For both of us, our independence is a point of pride and so even if our respective parents had offered to help with financing the festivities, we probably would have declined. So constraint 1: we were paying for it. Next, we decided that the wedding would happen in San Francisco (where we live) and not in Indianapolis or Sacramento (where our parents live). Our lives are here, many of our friends are here, and my church is here. Our connections to other places are very tenuous now, and despite the high cost of doing things in SF, the logistical complications of doing it elsewhere coupled with our sense of belonging in this city made the decision on location easy. Lastly, it was going to be a church wedding. I frequently find myself disagreeing on cultural and social matters with other members of my congregation, and indeed with many synod policies, but it was never really a question for me whether I would be married in the church.

So those are the external constraints: a church wedding, in San Francisco, on a budget of whatever we could personally afford. Everything else was optional or up for discussion. Through the engagement period we were constantly reminding ourselves of several things:

  • We’re a team and wedding planning is a team sport
  • We’d much rather be married than get married
  • Our marriage is worth not going into debt for

Weddings are 2-part affairs: a formal ceremony wherein we get hitched and a party to celebrate said hitching. Many modern weddings do these things at the same venue (not a church) or in other ways bend the formula, but since we were going to have a church wedding, we were going to need a separate location for the reception (aka: party). The wedding/reception split was something we grappled with throughout the planning process, particularly with regards to the guest list. More on that in a bit. A month or so after getting engaged we knew roughly how much we wanted to spend, that we needed to coordinate dates and times with the church, that we’d need some new clothes for the gig, and that we’d need to find a separate venue for the party. Also, we knew that we’d need flowers, invitations, a photographer, and food for the reception. These were the “must have” items for us, but they break down into fixed and variable costs:

  • Fixed: dress & tux, church fees, minimum venue fees, photography, transportation, entertainment
  • Variable: flowers/arrangements, reception food and drinks

Many of the fixed costs have some variable component and vice versa, but looking at the wedding as whole, it became pretty clear that if we were going to have any hope of managing costs, it would happen in the variable costs category. Some costs are also fixed but contingent or in other ways optional. For example, venue rental fees may be fixed based on the amount of time you rent them for, but that fee might be waived if you order food from the venue. The fee might also scale in very rough proportion to the size of the group so an incrementally bigger wedding probably wouldn’t cost you more until you hit some threshold and you had to find another location. In our research desirability, location, and other factors seemed to dominate venue costs unless you’re talking a 500+ person wedding. Also, choice of venue determines a lot of things, like the need for external catering, tents, or temporary flooring. That steep price tag to rent the Conservatory of Flowers doesn’t even begin to cover it when you factor in contingent costs.

Early on we started to look for information on pricing a wedding in the Bay Area and what we found surprised and shocked us, both in the paucity of data, and in the lack of specificity. Even asking vendors directly what things cost wasn’t always a good way to get a straight answer, even on a historical or “how about your last wedding?” basis. The best data we were able to get early on came from a dated issue of San Francisco Magazine which outlined the broad pricing of a wedding held just down the peninsula in Half Moon Bay, and the figures there were a roll-up/ballpark style accounting, not of the detailed variety we were hoping for. It seems that the entire wedding industry is designed to “help” brides and grooms avoid the burden of making reasoned decisions by providing as little comparative data as possible. Asking friends what they’d paid for their weddings was much more helpful, and several were willing to share all the numbers with us (if you know me, don’t hesitate to ask for ours, but I won’t be publishing them here).

We got to thinking about why such little data was available, and we came up with several mutually re-enforcing theories:

  • Most people lack experience. People (hopefully) get married once, or at least very few times in their lives. As a result, personal experience regarding how the market works for marriage services is concentrated in the hands and heads of “wedding professionals” of various sorts.
  • The financial reality has shifted. In a time when the fetishization of weddings could hardly accelerate faster, the basic structure of who pays for weddings is shifting. Fundamental demographic shifts are contributing to more people marrying later in life, often when they are as (or more) affluent than their parents. The result is a system tuned to the old reality of weddings funded by relatively well-heeled parents and based on large-scale family participation to send off the new couple with all the furnishings they wouldn’t likely have as very-young singles or students. The new reality is that many of these newer, older couples don’t need things and that they’ll be paying for whatever it is they chose to do out of their own pockets. In the old system, it was a simple matter of the child saying “I want” and the parents either obliging or demurring, whereas the new reality is an odd combination of pent-up dreams, financial independence, and fewer requirements on family support. The market used to be loathe to provide direct information because it could use children acting as children as a wedge in purchasing decisions. In the new scenario, it pays for the wedding industry to encourage fetishization so as to emotionally load decisions. It has to if it’s to overcome the rational side of successful mid-life couples. In either case, it’s not in the interests of the wedding industry to make pricing information easy to come by. If it did, reasonable people could compute margins and say “excuse me?” much more. The goal now isn’t to treat young-adults as children in the presence of parental figures who control the purse strings, it’s to induce them to behave like children of own volition.
  • Emotional loading, one-off appeals, and rationalizations. The tripe that passes for “wedding information” invariably begins with threadbare and transparent emotional entreaties along the lines of “it’s the most important day of your life…” and “you only get married once…”. These appeals to the irrational are everywhere in the wedding industry. In fact, you know you’re in “weddingland” when instead of talking about the thing you’re trying to buy, the sale starts with fluffy discussions of how special it all is…gimme an effing break. There are billions of people on the planet, and a giant percentage of them get married. Clearly, it’s not “special”…indeed, isn’t the whole point that you’re entering into an institution larger than oneself? That you’re making a compact with another person to join your lives in front of a community which values that relationship so highly, and which has such numbers, that it has enshrined marriage in law and custom? I digress. What’s important to know here is that no matter how little you think you care about the color of the napkins at the reception, you’ll find that as soon as you’re actually presented with the choice, you suddenly care. And as it relates to your wedding to this person whom you love, you really don’t want to screw the decision up. It’s not rational, but you can’t escape it. In this void of self-awareness and emotional helplessness an entire industry lies in wait. Do not under-estimate emotional loading.

What to do?

After several emotionally draining conversations about relatively trivial decisions it became very obvious that our best chance to survive the process was to either elope or to find ways to make fewer decisions. We opted for the latter although I now firmly believe that any consenting set of adults can and should be fully excused for choosing the elopement route.

At one point we thought that a professional might be able to help us reduce the number of decisions we’d be faced with, so we interviewed wedding planners. We discovered quickly that the job of wedding planners isn’t to help remove the burden of planning the wedding you might plan for yourself, but rather to help couples make their weddings “different” by giving them alternate sets of choices. From custom-designed invitations to finding locations which are off the beaten path, the modern bride apparently wants their entry into the grand institution of marriage to be exactly like everyone else’s, only slightly different in ways that either show off their affluence, taste, or “individuality”. Invariably, these people tend not to have great taste, so I imagine a large chunk of the planner’s job is to help couples avoid the worst-of-the-worst, but as with interior decorators, good help can’t save a bad client. More to the point, we weren’t looking to be “different”…we were looking to get hitched and be classy about it. The disturbing language used by some of them about “their vendors” also weirded us out. The implication that there were special relationships between some of the planners and some of the vendors seemed to be both a potentially good thing but also fraught with conflicts of interest. At no point did any of the planners we interviewed offer to describe their cost and margin structures with “their vendors” or in detail explain why we should use an opaque structure like that, even when asked directly. That seemed a very bad sign. No planner.

Our hopes of getting professional help dashed, we needed a new way to reduce the number of decisions and we needed to figure out the levers of cost very quickly. Without much trouble, we decided that our best hopes were to find a low-work venue for the reception and to tightly control the guest list. We set a hard limit of 40 people, and stuck to it. That was gut-wrenching for both of us as it meant that many of our favorite people wouldn’t be invited. No aunts and uncles, very few of our good friends from years past, and only immediate family. Part of the complication here is that the people you need to witness the “getting hitched” part of the wedding aren’t necessarily the same people you want to party with (and vice versa), but the wedding format forces you to choose both at once. We had to tell close friends and family that they weren’t invited, and every time we did, it re-started a discussion about him or her or them. Every cut or addition to the list was painful and hard, but we stuck to our guns. Our marriage is worth not going into debt for. We had 40 guests at the wedding, and we were grateful to have every single person there, if sad that we couldn’t accommodate more.

The other major decision that helped us wrestle the process to the ground was to hold the reception in a restaurant. While perhaps not the most romantic of locations, we knew ourselves enough to know that we valued having good food at the reception more than a lovely setting. The logistics of a restaurant reception are also much simpler. No 3rd-party caterer to coordinate with the venue, no half-warmed-over appetizers…the food would be done right and the room already more-or-less in shape for hosting events (thus reducing the amount of decorating needed). We also worked with the event coordinator at Harris’ to make sure that all the logistics were in place, but those turned out to be minimal (mostly deliveries and starting times). No protracted discussions about chairs and tables and colors: we wanted it to look classy and they obliged. Who’s gonna ever remember or care that your table cloths were in “your colors”? Certainly not our friends (and that’s why we love ‘em dearly).

Somewhere along the line, we also decided that tradition had a place, and that place was to make things easier. Where tradition didn’t do that, we threw it under the bus. No bridesmaids and groomsmen; why would you do that do your friends anyway? Not having a wedding party removed the need for a rehearsal, and therefore a rehearsal dinner became optional. We ditched the idea of pre-arranged seating at the reception, not even a “head table”. We have 40 of our favorite people in a room together, if they can’t find interesting and fun people to hang out with, well we invited the wrong people.

Tradition did help us simplify some decisions, like clothing. Dress? Straight-forward, classy, elegant (from Jin Wang). The tux? From my tailor, who already had my measurements on file and had instructions to make the suit and shirt as traditional as possible. The hardest part was finding a sized, untied bow tie. We tried nearly every high-end mens clothier in San Francisco and finally found that only Wilkes Bashford has the good goods. Don’t even bother with Brooks Brothers or Saks Men’s or the various “formalwear” stores….all you’ll find there are the nearly-disposable hardware-in-back numbers. We were also able to lean on tradition for the invitations, having decided that we couldn’t screw up too badly by having Crane’s do the job. It was a bit more stressful (and expensive) than either of us had planned on that count, but eventually the product was classic. I’ll save our experiences as Tiffany’s for another post (hint: tradition didn’t help with that one).

For photographers, we sorted through zillions of websites and called each of the ones that looked good. In the end, we found a good local photographer who has been doing this for 20 years and it showed, in a good way. Similarly with flowers, we found a reputable professional who was no-nonsense and laid our fate in their hands to great effect. As a last-minutes thing we decided to try to contact the Tipsy Typsy Trio who we’d heard while hanging out a month or so before at Enrico’s in North Beach. They were available, and suddenly we had a band for the reception. The moral of the story? Where possible, work directly with professionals who will treat you as functioning adults and not as romance-addled blank checks.

We learned the hard way that process of wedding planning is designed to reduce you to feeling about the process instead of thinking clearly about it. We fought back by doing much of it together as a team, finding ways to reduce the number of choices we were presented with, brutally prioritizing what we found most important, and not letting anything in the process of getting married throw us from the goal of being happily married. Time will tell if we made the right choices, but I can gratefully say that we’re both happy and relieved with how it turned out in nearly every aspect.

By alex | Posted in personal | Tagged | Comments (3)

Google I/O, In Retrospect

June 2, 2008 – 4:37 pm

I went to Google I/O last week and thanks to DeWitt Clinton I gave a talk on where browsers are headed and if they can really get us where we want to go. I’m afraid that even more so than is usual for the talks I do with slides, this set is somewhat indecipherable without the actual talk along side it.

Slides are below in PDF format (6mb):

Sadly, I didn’t make it to many of the sessions, but I was able to catch Brad’s excellent talk on building a client-side searching utility with Gears. His demo app used a custom build of Dojo, which was exciting to see because not only was it stripping out stuff that he didn’t need from the base dojo.js using the customBase build option, but he was also able to use the build system to alias dojo.* to pt.* so that it didn’t conflict with other versions of Dojo on the page and also packed up all the modules into a single file. We’ve had each of these features in Dojo for a while, but seeing them used together was incredibly powerful. Dojo can act as “Dojo” or the basis for your own library without much more work. The demo itself (a client-side search engine) was also powerful. Brad used Gears’ worker threads to parallelize the work of pulling fetching, tokenizing, and handling a site’s content. The speedup in being able to move this kind of work into the background (potentially onto separate processors and cores) opens up a new world of potential applications. I’ve been thinking about the implications of a ubiquitous Gears ever since.

An aside: Google throws a hell of a party. The only thing I’ve seen comparable to it was the awesome time that Microsoft hosted at this year’s MIX. Landing the Flight of The Conchords was quite the geek coup for I/O, particularly since most of us had no idea who would be playing. Considering that I also got to see David Capurro at yesterday’s Laughing Squid party, I’m pretty blissed out on geek meme entertainment.

Update: video of my talk is up at the Google I/O site. The video should make the arguments somewhat more clear than the slides alone could (although on the downside you’ll to suffer through my myriad “um”’s and “uhhh”’s). Also, Neil McAllister has a piece up today which summarizes some of the talk’s points. I’m afraid the talk left him with the impression that I support natural monopolies when in fact I only raise questions about their formation in order to find ways to effectively break them (or hollow them out).

By alex | Posted in Uncategorized | Comments (1)

Zend + Dojo: More Than The Sum Of The Parts

May 22, 2008 – 2:56 pm

In the past several months, more and more integrations of Dojo with server frameworks have been shipping, and we couldn’t be happier about the Zend + Dojo integration that was announced yesterday.

Fundamentally the Dojo and Zend teams really “get” each other. Both are deep packages that give you an opinion about how best to do something but also all of the tools you’ll need to make it work at scale. The “use at will” term that the Zend folks use made immediate sense to us. Like Dojo, Zend doesn’t saddle you with more than you’re really going to need up-front, but at the same time, when you need something awesome which is well tested and integrated, it’s right there. No digging around on google to find a “plug in” that will get you where you want to go…both Zend and Dojo give you a full stack of great components to work with out of the box.

There have been some questions on IRC today about why Dojo and not something else, and we know that the Zend folks are committed to continuing to allow Zend to work with other frameworks as well and we fully support them in that. There seem to be lots of choices of Ajax frameworks which Zend could have integrated, but when you look at the requirements of serious products which need to ship tested solutions to really hard problems, the field whittles down very fast. In response to the needs of our users, both Zend and Dojo take seriously our responsibilities to provide integrated, high-quality, unambiguously licensed products that will let user scale both up and down. Key to this is understanding the full spectrum of use-cases, informed by past experience, and striking a balance between enterprise-ready features and close-to-the-metal primitives. The Zend Framework has a larger view of the server-side than Dojo can, and as a result there are new opportunities to optimize and improve the user experience for all classes of users through this integration. This isn’t just about including some scripts on a page, this integration is about improving user and developer experiences, and both Dojo and Zend bring a lot to the table which can compliment the other. Dojo’s strengths in progressive enhancement, packaging, localization, and accessibility all have obvious allegories in the ZF world where a complete integration can more value based on what developers are already doing. All of those features of Dojo will work better when the server-side knows how to “hint” things for the client and work with, not against, the client to deliver better experiences.

I’m perhaps most excited about the data-driven opportunities in the Zend/Dojo integration. Dojo’s data infrastructure is second-to-none, and the design of the dojo.data and dojo.rpc layers provide Zend Framework integration the ability to take advantage of systems like the incredible Dojo Grid and the client-side charting package. There’s more to look forward to, and figuring it out together with the folks at Zend is a great opportunity for the Dojo community.

Pete Higgins and I will be participating in next Tuesday’s discussion with a broader chunk of the Zend Framework world, but until then (and long after) we’ll be hanging out in the #dojo and #zftalk channels on irc.freenode.net. We’re looking forward to working more with the ZF community to build great experiences, and are hugely excited about the direction things are already taking!

By alex | Posted in community, dojo, programming | Tagged , , | Comments (1)

Blatantly Mis-Quoting Sublime

May 7, 2008 – 2:02 am

100 points to Freedom.

Dojo, DWR, CometD, OpenRecord, and the newly accepted Psych Desktop project are all 100 for 100 on Dion’s scale because we’ve done the hard work of building a Foundation, ensuring the IP provenance of every checkin, built a community structure that gives everyone who’s significantly invested a real voice, and have made the sacrifices that ensure that Dojo Foundation projects aren’t just “open”, but that they’re trustworthy.

Dion’s right:

The license is a great starting point, but it isn’t enough.

The Dojo Foundation has open door for any web projects that want to join and will do what it takes to get their score all the way up to 100. If the projects you’re using aren’t 100 for 100 — particularly given that we make it so easy — isn’t it worth asking “why?”

By alex | Posted in Dojo Foundaton, community, licensing | Comments (0)

A Brief Personal Note

April 13, 2008 – 4:08 pm

Yesterday, April 12th, Jennifer and I were married. Our warmest thanks to everyone who attended and our sincerest regrets to everyone whom we could not invite.

Our friends and family made the day truly special.

By alex | Posted in personal | Comments (31)

App Engine: Most Of The Stuff I Want, None Of The Stuff I Don’t

April 8, 2008 – 3:51 pm

I’m not sure who or how, but I got an invite to yesterday’s Camp Fire One event at Google where they announced their new App Engine platform. The event itself was small-ish, with lots of interesting people invited (both from Google and not). I had no idea ahead of time what the announcement would be, and frankly I forgot all about the event until the day of. I’m glad I remembered (note to future self: next time, pack gloves and a hat).

As they started talking about the platform and what’s part of it (and what’s not), I couldn’t escape escape the feeling that they’d gotten it right. It is absolutely the case that for most apps, scaling requires some amount of re-architecting. Systems like Rails are built with such a dependence (intentional or not) on the features of relational data stores that they quickly hit bottlenecks because frameworks aren’t keeping developers out of the gutter. This is nearly the same lesson that the security community collectively came to when it started to beat the average developer about the head regarding the awesome power of defaults. What systems do and don’t do for you “cheaply” defines their character, and in many systems those choices aren’t made consciously, or if they are, they don’t have the benefit of a different perspective which might de-emphasize certain traits. Call it libertarian paternalism, choice architecture, or pure condescension, but whatever it is, systems and platforms today are in the explicit business of making some things easier than others.

As the presenters showed how to make an app quickly, I knew I was looking at something I hadn’t seen the likes of since Jot. We all know that Big Table is a column-oriented data-store, but since most people are still stuck on the likes of MySQL, it’s hard to appreciate how liberating it is not having to think about how adding properties to models will affect a schema. The way App Engine is constructed lets the data store layer provide something called expando models. These models give us the kind of flexibility that I’ve only ever enjoyed before inside of Jot. Want a property? Just add it. No migration, no schema version…just data finding a happy home, and as your app’s skeleton “solidifies” and you figure out which properties really do need to be faster, you can migrate that data into fixed properties with indexes and types and all that jazz. It’s like a gradual type system, only for data stores. It’s agility nirvana for application development.

Speaking of application development nirvana, they also had the good sense to start with a great language (Python) and a great webapp framework (Django) as the basis for the new system. For all the Rubyists and Java heads out there who are surely crying bloody murder, I suggest that they just try it. Seriously. Django’s template system is freaking sweet, and Python (despite it’s lambda-related warts) is close enough to being executable pseudo-code as to still hold the second place in my toolbox of languages.

There’s a lot which I’m sure others will (and have) covered about how App Engine is going to change the game for startups and players like Amazon, but I think that if someone else had launched this system it would still survive on its merits alone. The only wrinkle in the whole thing will be seeing what’s done about pricing over the long haul. It really shouldn’t be hard for Google to beat S3 on price, and I’m sure there will still be a market for EC2 for non-traditional tasks, but fundamentally I think App Engine has all the makings of something really, truly better than the current (assumed) stack.

After more than a year of mourning the effective loss of Jot as a platform, writing apps on the server just got interesting for me again, and that may be the highest praise I can offer and framework or platform.

By alex | Posted in programming, python, webdev | Comments (3)

Dojo 1.x: Industrial Strength Open Web Tech

April 3, 2008 – 6:45 pm

…just ask AOL. James Burke just pinged me to let me know that AOL Webmail has been updated with a slew of new features built using Dojo 1.0. A quick inspection of the app shows all kinds of great stuff including tons of custom widgets as well as extensive use of the Grid. To keep loading of the app quick, AOL is using custom builds to pull Dojo from a CDN and a number of application-specific layers in order to defer loading of code until it’s needed. Congrats to the AOL Mail team! It’s inspiring to see a site that does billions of page-views a month using Dojo so effectively.

Dojo 1.x is now powering the UI of the world’s largest mapping service, one of the world’s largest email services, the most useful personal information service anywhere, and the front-end of my favorite RSS reader.

The proof of Dojo 1.x’s quality really is in the pudding. Congrats again to the AOL Webmail team!

Update: Travis Vachon also just sent mail to let me know that OSAF’s Cosmo project has also released their 0.14.0 version which has also made the upgrade to Dojo 1.0. Congrats, Cosmologists!

By alex | Posted in community, dojo | Comments (0)

Dojo 1.1: Some Awesome For You App

March 30, 2008 – 1:30 pm

I could go on for a long, long time about what’s great in Dojo 1.1…but I’ll spare you most of that. James, Pete, Dylan, and the release notes can give you a strong sense of why Dojo 1.1 is the most polished, fastest, and easiest-to-use release of Dojo we’ve ever done. For the impatient, you can already start using it from the CDN without downloading anything.

I should mention a couple of Core features from 1.1 that might otherwise go overlooked, though. The first is a lack of visible change. Dojo Core and Dijit from 1.1 are fully backwards compatible with 1.0. We promised that the fundamental incompatibility between 0.4.x and 0.9.x+ was a one-time change, and Dojo 1.1 keeps that promise. We’ve already had reports during the RC cycle of people swapping out Dojo 1.1 for 1.0 without any changes to their apps. It takes dedication and discipline across the entire team to achieve that kind of API stability while still taking risks to deliver better features, reliability, and performance.

Next up, we updated the animation APIs significantly. In Dojo 1.0, we moved to a unified timing loop for animations which helped to significantly improve the performance of Dojo animations. In 1.1, we’ve again improved the performance of the animation system but have also added some great syntactic sugar to the already powerful APIs which we expose. As always, start and end coordinates for an animation can be values or functions which return calculated starting and ending positions. Now, though, you can elide away the { end: 30 } structure and just provide a value. This lets us go from:

1
2
3
4
5
6
7
8

dojo.animateProperty({
    node: "thinger",
    duration: 500,
    properties: {
        width: { end: 500 },
        height: { end: 500 }
    }
}).play();

To just:

1
2
3
4
5

dojo.animateProperty({
    node: "thinger",
    duration: 500,
    properties: { width: 500 , height: 500 }
}).play();

But to get even more terse, we’ll need a different API structure that doesn’t require so much explicit argument packing. Dojo 1.1 adds just such an API:

1

dojo.anim("thinger", { width: 500, height: 500 }, 500);

Note that in addition to being able to drop a lot of stuff out of the function call, dojo.anim also doesn’t require that we call .play() on its returned animation object since in the common case you’ll just want to play right away.

Next up, Dojo now has a unified dojo.xhr() function that covers a lot of bases and gives you a single entry point into the various bits of XHR goodness contained in dojo.js.

As I’ve noted elsewhere, Dojo is also now supporting querySelectorAll on the browsers that support it sanely. Dojo’s CSS engine has always been fast, and by keeping our query syntax to just what CSS provides, we’ve avoided getting ourselves into a situation where we’ll always need to be shipping such a query engine down the wire. Sooner or later, dojo.query() will become nothing more than a call into querySelectorAll plus some syntactic sugar on the returned array. Best yet, API won’t change and you can get the speedup on the browsers that support it now, knowing full-well that things will only get faster and smaller in the future. An investment in a toolkit that is pays attention to the evolution of the web is already paying dividends for Dojo users.

Lastly (for now), there have been some fun additions to the API of dojo.NodeList, the thing that’s returned out of every call to dojo.query(). dojo.attr() and dojo.anim() are now available on groups of nodes. For instance, we can make a group of elements tab-focusable on browsers that support it and then draw some attention to them:

1
2
3
4
5
6
7
8

dojo.require("dojo.NodeList-fx");
 
dojo.query("#nav > .focusable").
    attr("tabIndex", 0).
    style("border", "1px solid transparent").
    anim({
        "borderColor": { start: "yellow", end: "white" }
    });

There’s also a new empty() method on node lists which makes removing children simpler, and the instantiate() method which helps you create instances of a class for every item in the list. Lets say you want to encapsulate some behavior in a class. You could use the hotness that is dojo.behavior or you could use the traditional combination of the Dijit base classes plus the Core parser system. Or you could strike out on your own, particularly for implementing something like a microformat handling library:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

// define a Card class which we can create instances of
dojo.declare("mf.Card", null, {
    constructor: function(props, node){
        this.setAddrs(dojo.query("> .adr", node));
        this.setName(dojo.query(".fn, .n", node));
        // ...
    },
    name: null,
    addrs: [],
    tels: [],
    emails: [],
    // ...
});
 
dojo.query(".vcard").instantiate(mf.Card);

Taken together, these extensions make dojo.query significantly more powerful. There’s also a growing set of extensions to node lists, such as those for easy templating of generated content via dojox.dtl. We’ve also taken care to ensure that anywhere that Dojo returns you an array of nodes, it’ll probably be handing you a dojo.NodeList. That means you can treat these arrays as regular, intrinsic Array instances, or you can use these chainable methods for added node-manipulating power.

An Aside

The team that put together Dojo 1.1 is really, truly, amazing and it shows in the end product.

When it became clear that we had a responsibility to the a11y of Dojo application, they built it and shipped solutions. While others still aren’t thinking about localization, they built it and shipped solutions to right-to-left as well as string handling (including optimizing those processes for deployment). When it became clear that the CSS file structure for building themes was too hard, they fixed it…in a 100% backwards compatible way. When Dojo was “dinged” for poor documentation, they did what they knew was the right thing and kept working on what is now the world’s best JavaScript documentation tool.

What’s most impressive to me about the Dojo team, though, is that this isn’t a centrally planned, in-house operation by a giant company. There isn’t a product road-map other than what’s decided at the Developer Day events and in the weekly IRC meetings. Dojo is the collective work of volunteers, committers, and companies that understand that building things together in a truly open project is better for everyone. Having the source of a product be available under an OSS license gives you certain rights in an instantaneous sense, but for those advantages are usually just advantages for people already “inside” of a project. To really convert on the benefits of openness, the process of developing the product needs to be just as open as the license. Open Source business models all tacitly acknowledge that most pithy of truisms: the people on a project are its greatest asset. If new people can’t join or “get in”, then the project is effectively closed, and the benefits of openness can’t be fully realized. Users win when advocates for their needs can emerge from more places, developers win when they can get involved and make a real difference, and a project benefits its community is really that: a group of people who show up because they want to make things better. I’m proud to be working with just such a dedicated group on Dojo.

During the 1.1 release cycle, Wolfram Kriesing and Nikolai Onken earned their committer stripes. They didn’t start making Dojo better because they happened to work somewhere or because their company sells Dojo…they joined the project the way most of us did: they saw a place where they could contribute and because Dojo is run as an open project, they were able to have a huge impact. Nikolai’s artwork and theme wrangling are largely responsible for Dojo 1.1 being the most attractive Dojo ever and Wolfram’s code contributions have made interfacing services with dojo.data stores easier than ever before.

We’ve got an ambitious set of improvements slated for 1.2, and I’m confident that while it always looks slightly chaotic, the advantages of working in the open with whoever shows up will continue to pay off for everyone. If you’ve been a Dojo user and have thought about contributing, there’s never been a better time to come find us on IRC or the forums and help to shape the future of the toolkit. You can be part of this amazing team too. It’s as simple as that, really.

I can’t wait to work with you to make our corner of the Open Web better.

By alex | Posted in community, dojo, openweb | Comments (3)

Progress Is N+1

March 26, 2008 – 5:32 am

Not sure how I got there, but I just stumbled over this bit of dark humor at Joel Spolsky’s expense, and in reading it I was reminded of a discussion last Friday where I voiced my frustration that as much as IE 8 looks to be a good point release, we know next to nothing about it’s intentions with regards to ship dates or auto-update deployment. I’m not talking exact dates or firm plans here, just “within the next N months” or “we’ll wait N (plus or minus 3) months to put it on Windows Update”. Knowing those things fill in the missing bits of making any plans around IE. No plan is complete without a “who”, a “how”, and a “when”. Right now we’ve got the first two bits (ish), but the third is a mystery….which means we don’t have a collective plan.

By the transitive property of IE being the monopoly market-share browser, we can clearly state that we have no idea when the Open Web will be revved. This is based solely on the IE team’s lack of commitments. This is a terrible result, and one which I think the frenzy over IE 8’s features has obscured.

Joel’s article and some of Mark’s commenters make it obvious that there’s now a gap in the expectations of some devs about what it means to be a web developer versus what it meant 4 or 5 years ago. Back then we all assumed that browsers would get better, or at least different. There was bitter complaining about how incompatible everything was and how horrid it was to have to update everything…but underlying that discontent was the assumption that the web would keep changing. Web developers have to a great extent lost this assumption and I see a lot of the acrimonious discussions about new browser features in this light. There is great fear on the part of the web development community that progress will cost something, and they’re right. So long as we’re only talking about one revision, the cost looks new and surprising, but if we were to start talking about how we’d keep revving the web, those costs could be assumed by all parties again. It’s for this reason that I posit that the most important thing about IE 8 won’t be any of its features…it’ll be that it ships soon-ish and goes out to auto-update (if that is indeed the plan, which we don’t know).

The analogies that Joel brings up about standardization are perhaps valid if you take a snapshot in time of features vs. conformance. What happens in the browser world, though, is that things where were only marginally possible with old features become the norm via new features. New tags or CSS rules get added which make what was hard simple, if less flexible. In that process, we find that we need strong agreement on the behavior of those “mainline” things, while it’s perfectly OK for browser vendors to disagree about the fringes. Those fringes, after all, are were new things should be getting developed and introduced for market testing. It’s only when new things don’t get introduced and that broad agreement isn’t forged and “full” standards conformance comes into the fore. We need 100% standards conformance for all the nit-picky corner cases when those are all we’ve got in the way of “new” platform capabilities. Joel’s view of the world doesn’t take into account healthy evolution and improvement based on real competition. Competition makes suppliers responsive to customers and gives a real path for evolution. Standards make suppliers responsive to proxy bodies who are easily distracted.

IE and all browsers are as much a platforms as applications, but browser vendors get themselves into strange positions with regards to the platform bits of their products. Since browsers are positively differentiated by their chrome and not their engines, you can think of renderers and script engines and all the things that webdevs care about as costs of doing business for a browser-producing organization. Insofar as they make money, they do it on chrome, not rendering. Of course, getting into the good graces of web developers is great for a browser maker, but getting in front of users is the only real metric of browser success and to get there one only needs a renderer that’s on par with the others. You can’t positively differentiate a browser by making it more standards compliant or even by introducing new and awesome non-standard features. Those things can have strategic value, but they can never stand on their own.

Which brings us back to IE being a platform. The bits that webdevs care about must change in order for the web to get better, and today webdevs are platform customers without a commitment from their biggest supplier to ship another version beyond the one they’re working on now. If this were any other sort of platform, this would never ever fly. Code-in-escrow would be demanded along with a roadmap, or at a minimum a commitment to an N+1 version in a reasonable time frame. But webdevs don’t have that leverage by virtue of the disintermediation that browser economics now demand.

So as webdevs, we must be canny enough to find a way to “better” which doesn’t put all of our eggs in any particular basket. Every browser that we depend on either needs an open development process or it needs to have a public plan for N+1. The goal is to ensure that the market knows that there is momentum and a vehicle+timeline for progress. When that’s not possible or available, it becomes incumbent on us to support alternate schemes to rev the web faster. Google Gears is our best hope for this right now, and at the same time as we’re encouraging browser venders to do the right thing, we should also be championing the small, brave Open Source team that is bringing us a viable Plan B. Every webdev should be building Gear-specific features into their app today, not because Gears is the only way to get something in an app, but because in lieu of a real roadmap from Microsoft, Gears is our best chance at getting great things into the fabric of the web faster. If the IE team doesn’t produce a roadmap, we’ll be staring down a long flush-out cycle to replace it with other browsers. The genius of Gears is that it can augment existing browsers instead of replacing them wholesale. Gears targets the platform/product split and gives us a platform story even when we’re neglected by the browser vendors.

Gears has an open product development process, an auto-upgrade plan, and a plan for N+1.

At this point in the webs evolution, I’m glad to see browser vendors competing and I still feel like that’s our best long-term hope. But we’ve been left at the altar before, and the IE team isn’t giving us lots of reasons to trust them as platform vendors (not as product vendors). For once, we have an open, viable Plan B.

Gears is real, bankable progress.

By alex | Posted in openweb, webdev | Comments (19)

March 20, 2008 – 1:21 am
By alex | Posted in community, dojo | Comments (1)

SitePen Launches Dojo Support Service

March 14, 2008 – 10:31 am

SitePen has been building an amazing team and today we’re bringing a little of that team to a lot more of the Dojo world.

As part of the relaunch of sitepen.com, we’ve unveiled our new support offerings (the available packages are here). For some time now SitePen has been offering consulting to firms using Dojo, and we’ve recognized that many of our clients aren’t prepared to engage us for a consulting engagement but need more than an intensive training session for their teams. In this middle area lies the need for a support product which can help capable teams get un-stuck quickly when the going gets tough. Other customers have expressed a strong desire for professional support due to their enterprise’s nascent experience with Open Source, and for them we’ve built “lightweight consulting” into the Enterprise plan to help get architectural issues addressed in addition to handling pressing fixes.

SitePen is adding this support product to our already successful application development and Dojo/DWR training businesses. Since we’re also building apps, we know how important it is to have the right person an email or phone call away. Support is a logical progression for us as a company and for Dojo as a project, and we’re committed to doing it right. Everyone we’ve assembled to provide support to our clients are committers on the projects we support (sharp tacks, all) and as we described recently at DDD the plan for SitePen’s support business is designed to help us improve the toolkit at every opportunity. Right there on the page describing the packages you can see our commitment to keeping Dojo a healthy Open Source project:

When you find an issue with Dojo, DWR, or Cometd, we…provide you with emergency bug fixes. We also commit these patches back to the relevant open source project as appropriate.

SitePen has also recently been working to help ensure that Dojo’s API documentation tool is top-notch and that the introductory material for getting started with Dojo are solid, all of which we’ll be releasing in the coming weeks alongside the release of Dojo 1.1. In all of the support team discussions, it’s been clear to me that everyone involved gets it: not only are we here to support our customers, we’re here to make Dojo and DWR better for everyone in the process. It’s the kind of positive feedback loop that only happens when you have the right people on the bus and when the whole business understands the real value of Open Source both to customers and to the community.

Speaking of making things better, we’re convinced that the last thing you need when working with our support team is a headache. The support UI has to be as easy-to-use as it is good looking, so we’ve built a custom support interface that lets customer submit tickets, check the progress of ongoing ones, and use completed tickets for reference. Check it out:

By alex | Posted in Uncategorized | Comments (2)

MIX + SxSW

March 5, 2008 – 3:14 am

I just landed in Vegas where i’ll be for the next several days at Mix ‘08. I’m looking forward to hearing more about what the IE team has in store for IE 8. I’ve got a whole stack of questions and they’ve promised a frank discussion without any pre-conditions or NDAs. This oughtta be good. If nothing else, it will tell us how far retracted the IE Cone Of Silence (TM) is. I’ve got hope, but I’ve been teased before and despite an impending Beta, there’s precious little to go on about what IE 8 really will and won’t be (or even when).

I’m not a gambler, and generally don’t like Vegas, which makes me all the more excited to be going to SxSW directly from MIX. I haven’t been in a couple of years, but Dylan has been keeping the annual Dojo Salt Lick field trip alive, and I’m excited to be able to be able to join the rest of my (mostly Silicon Valley) compatriots in stumbling around Austin under the influence of Shiner and BBQ. If you’re also going to be in Austin (at SxSW or not) and want to join us in our trip to BBQ Mecca, just RSVP and let us know how many you intend to bring and whether or not you can drive others.

Oh, and there will be an auspicious panel wherein authors of successful JavaScript libraries will all thank John for doing the work of proposing a panel and therefore ensuring that we all have an excuse to come to Austin to drink Shiner and eat BBQ. The last time I went to SxSW I hosted a panel with some of the smartest people I know and it went over like a lead brick, convincing me once and for all that SxSW is the Jerry Springer Show of technical conferences and that the point of panel discussions there is to stir shit up. It doesn’t even matter what it is…everyone else there is nursing the same mild, Shiner-induced hang-over and if they really cared about technical content…well, they would have gone to ETech.

If you’re going to either MIX or SxSW, let me know! Conferences are always more fun when you know the Hallway Track is going to rock.

Update: there’s much to say about MIX now that it’s over and IE 8 is in our hands, but apparently we’ve communicated about the Salt Lick thing very poorly. While we’d love it if you’d RSVP to rsvp at dojotoolkit dot org if you’re joining us, what you really need to know is when and where. Namely:

When?
8pm, Sunday March 9th
Where?
The Salt Lick
18001 FM 1826
Driftwood, Texas 78619

Remember, it’s BYOB and if you RSVP we can help coordinate rides and such. Looking forward to seeing you there!

By alex | Posted in Uncategorized | Comments (3)