Category Archives: dev

HTML5 App Stores don’t go too far enough

tl;dr - HTML5 app stores don't leverage the web as much as we should.

Futurama Political Debate

 I'm convinced that packaging HTML5 apps for stores is emulating failure. There are lots of reactions. Among the comments here, Les made the opposite assertion of mine - "where app stores win over plain old URLs is discoverability. ... URLs are precise, but they’re sharp and pokey for most people to handle."

HTML5 App search engine > Pokey URLs

Les made his own counter-point that we fixed pokey URL's with search engines. So, do we need "a special case search engine where the results are constrained [to HTML5 apps]"?


The "webby" approach is to crawl the web to build an index of all app manifests. But how can we discover the manifests? None of the HTML5 app stores document a way to hyperlink manifests.

But maybe we can use SoftwareApplication type, with its convenient installUrl property. We can even use the WebApplication sub-type's 'browserRequirements' property to designate a Firefox, Chrome, or W3C manifest. So Incredible Pizza could expose their HTML5 app like so:

<div itemscope itemtype="">
  <a itemprop="installUrl" href=""><span itemprop="name">Incredible Pizza</span> for <span itemprop="browserRequirements">Firefox</span></a>
  <a itemprop="installUrl" href=""><span itemprop="name">Incredible Pizza</span> for <span itemprop="browserRequirements">Chrome</span></a>
  <a itemprop="installUrl" href=""><span itemprop="name">Incredible Pizza</span> for <span itemprop="browserRequirements">Opera, Windows Phone</span></a>

Voilà. We have web technology to make an HTML5 App search engine. But why are HTML5 app stores making developers manually submit manifest URLs to directories when we could leverage hyperlinks - the central nervous system of the web? As a bonus, a hyperlink-fueled HTML5 app search engine is complimentary to existing mobile platforms. This could be nice:

iOS App Search mockup

Apps contextualize content

Still, an HTML5 app search engine doesn't leverage the web as much as we could. Ambrose Little suggests "discoverability is worse [on the web] because it’s not just apps, it is all kinds of content, much of which is not pertinent nor optimized for your device." This gets to the crux of the issue: outside of pure experience apps like games, when we say we want apps, what we really want is relevant, contextual, optimized content on our mobile devices. Can we deliver relevant, contextual, optimized content to mobile devices without apps?

In Programming the Mobile Web, Maximiliano Firtman touches on this in his chapter about geolocation:

One of the great features of mobile devices is that they can go everywhere with us. That is why the where is very important context to be considered by our websites. Knowing the user's location can help us to show useful contextual information -Firtman

Geolocation is a great place to start, since it's so widely supported on existing mobile browsers. I suggested that could return location-specific content using a captive wifi portal or geolocation. But fuzzy search can also deliver location-specific content, as Google Maps does; though it could be improved to deep-link into a domains' pages with something like GeoURL or a geofenced sitemap.

I.e., if added:

<meta name="geo.position" content="36.05877;-95.8831" />
<meta name="ICBM" content="36.05877, -95.8831" />

to their Tulsa store location page, and maybe add a geo point and radius to their sitemap:

<url xmlns:geo="">

mobile search could do something like this:

iOS Search for Pizza

Search already works

We can search for a pizza place nearby. So what? Foursquare already does that.

But do we have to search for it? As predicted by Mike Masnick back during Yahoo's misguided deal with Microsoft in 2009, "People are discovering that information finds them, rather than them going in search of information. Search already works. The next interesting challenge is in improving the way information finds you, rather than the way you find information."

Improving the way information finds you is how social competes with search, and it's the way mobile web should compete with app stores. Location, time, personal information, preferences, friends, actions - all of these create the context in which information should find us. Chris Cox from Facebook summed it up:

[Mobile phones] should be contextually aware. Check-in to flights, find deals at grocery stores, etc. These things take a bunch of clicks now — it’s all wasting time. The phone should know what we want.

My phone should know:

  1. I have 2 kids under the age of 4
  2. We're near south Tulsa
  3. We typically eat out on Tuesday nights
  4. It's almost dinner-time

It should query the web. To which replies:

  1. Kids 3 and under eat free
  2. We're located in south Tulsa
  3. We have double-play-points specials on Tuesdays and my phone inform me automatically. This touches semantic web stuff; and maybe that's something we mobile web developers should be touching. Because ...

The only group who can contextualize everything is everyone

The web will obsolete app stores ... again. In Scott Jenson's "Why Mobile Apps Must Die" talk at BDConf 2011, he longs for a web-based phone, and a discovery service that helps us find the right needles in the needle-stack of connected things. He calls it "a baby step towards this idea of doing just-in-time interaction" and says "I can guarantee you this will not happen thru apps."

Why not?

Christian reminds us of Yahoo's first (failed) attempt at re-creating a categorized directory of the web. If you don't have time to read Clay Shirky's classic perspective on ontology at least watch this great related 5-minute video:

Even if you skipped both, here's the crux of the matter (emphasis mine):

Yahoo ... added the shelf back. ... The charitable explanation for this is that they thought of this ... as their job, and as something their users would value. The uncharitable explanation is that they thought there was business value in determining the view the user would have to adopt to use the system. Both of those explanations may have been true at different times and in different measures, but the effect was to override the users' sense of where things ought to be, and to insist on the Yahoo view instead.

You can replace "Yahoo" with "Apple" in the preceding statement and it mirrors the current situation of Apps. The web out-grew Yahoo's shelf; it will out-grow Apple's, Google's, Microsoft's, and Mozilla's shelves. Our sense of where things ought to be and how things ought to find us is better than any vendor's. "The web is going to win again. The web always wins." as Johnath says.

The web will win sooner if we spend less time on the shelves and more time delivering relevant, contextual, optimized content to mobile devices.

Packaged HTML5 Apps: Are we emulating failure?

tl;dr - URLs delivered a better experience than native desktop apps; they can do the same for mobile apps.

update: see my follow-up post - HTML5 App Stores don't go too far enough.

HTML5 in a box

When we discussed Sencha's Fastbook app on the mozilla.engagement.developers list Robert pointed out that Sencha compared their HTML5 app running in mobile web browser to Facebook's HTML5 app running in an iOS WebView - the way Sencha & PhoneGap packaged HTML5 apps actually run. It's widely discussed, as we did with Fastbook, that HTML5 apps perform worse in iOS UIWebView than iOS Safari. There are similar stories about Android WebView performance, and Tulsa Web Dev and HTML5 PhoneGap developer Rod just posted a similar performance-related anecdote about BlackBerry WebWorks.

That made me think, "PhoneGap is just that - a stop-gap." ... "we should drop this whole PhoneGap App nonsense and go (back) to mobile web at simple URL's" since:

  1. App discover-ability & installation sucks
  2. App content discover-ability sucks

App discover-ability & installation sucks

A couple months ago, my wife and I took our daughters to Incredible Pizza. When we sat down, I saw this table-tent:

Incredible Pizza Table-Tent

I spent a couple minutes trying to make this "check-in" UX work on my wife's phone. The table-tent literally reads: "TIP: A QR-Reader App is necessary to scan QR codes. There are several free ones available. Check your app store." So, here's what I did to find an app:

  1. Connect to Incredible Pizza wifi
  2. Tap "All apps"
  3. Swipe down to "Play Store"
  4. Tap "Play Store"
  5. Tap "Search"
  6. Type "qr reader"
  7. Swipe thru a huge list of apps
  8. Pick one at random (*)
  9. Tap "Install"
  10. Tap "Accept & Download"
  11. Wait for download & install

Android prompts me with a wall of permissions that I have to accept in order to install the app. And because app updates with new permissions can't be automatically downloaded & installed, many app developers just make their app request all permissions.

* Especially interesting to developers - I picked a free qr reader app at random, verifying that App Stores are more like casinos than gold-mines.

Content discover-ability sucks

Once I had the QR reader app, I started to use it to check-in to Incredible Pizza on Facebook:

  1. Hold the phone in front of the card
  2. Tap "Visit Link"
  3. Tap "Browser"
  4. Go thru 5 redirects to a prompt to open native Facebook app
  5. Facebook opens
  6. Wonder: "Why am I trying to do this in the first place?"

There was no human-readable URL on the card. I had to choose between "Browser" and "VZ Navigator" that came with the phone from Verizon. The redirects took about 20 seconds. Finally, since they don't deep link into the native app, I ultimately end up just staring at the Facebook app as if I'd opened it myself - nothing there at all about Incredible Pizza.

This totally obscures the app's content, and value, from the user. If I package my HTML5 app with PhoneGap I have to also register a custom URL scheme to link to a specific part of it - something PhoneGap doesn't help you to do(?). And even when you do it, you will need to make and deploy an update to the app anytime you want to add new URL-driven logic to it, invoking another round of app review.

The Plain Old URL approach

Contrast the above experience with a more traditional web approach:

  1. Connect to Incredible Pizza wifi
  2. Tap Browser
  3. (Maybe) Type ""
  4. (Maybe) Tap "Yes" at a geolocation prompt

Incredible Pizza could immediately give me the store-specific web page via captive wifi portal with big buttons for location-and-date-specific coupons, facebook check-in, etc. Or, if I'm not on their wifi, I type "" to get the same thing via geolocation. In addition to a simpler experience, deploying new or updated content is as simple as updating the website.

So why package HTML5 apps?

Considering all the above, I usually ask web devs using PhoneGap: "Why are you using PhoneGap instead of just putting an HTML5 app at a URL?" and they often reply "everyone wants an app." This "everyone wants an app" situation is a problem we developers and designers should address - but not just technically. We should work with our clients and customers to consider the full user experience of native vs. web - especially app installation & content discover-ability.

... although many brands and creative agencies believe that they need to develop iPhone apps, what they need in reality is a good mobile site. It costs less to develop, manage and work across all handsets.

- HTML5 - The End of Apps | Mobile Europe

If you're making an HTML5 app, consider - do you want to make a native desktop application? Why or why not? Then consider if the same reasoning is true for the native mobile application. Consider the URL experience for your customers. Walk your clients thru both native app and URL experiences on mobile devices. We used web URLs to deliver a better experience than native desktop apps - we should do the same with mobile apps.

Good HTML5 Packaging - URL Bookmarks

Vendors like Mozilla (disclaimer: my employer) and Google are also working on manifests to install HTML5 apps on Firefox (OS) and Chrome (OS). Opera and previously(?) Microsoft (via Silverlight) use the W3C Packaged Web Apps (Widgets) standard. I like these efforts if they contribute towards a consistent "installation" experience that works more like an enhanced bookmark. I.e., turn this:

  1. Visit URL
  2. Tap "Add to ..."
  3. Tap "Add to Home Screen"
  4. Tap "Add"

into this:

  1. Visit URL
  2. Tap "Add to Home Screen."

But next time you make an app, consider the tried-and-true web experience:

  1. Tap Browser
  2. Type URL

Facebook never bet on HTML5

I'm going to jump into the mix, but my post is short and sweet. In fact, I wrote it while waiting for tests to run.

Facebook never bet on HTML5. Anyone remember the convoluted rambling of Dave Fetterman at f8 developer conference last year? I remember being both dumbfounded and confounded by it.

So, how does this work? Project FaceWeb is an extension of this progressive enhancement idea. So, instead of the phone saying I am rendering for a WebKit browser, we send an agent that says you are going to be rendering for a WebKit UI WebKit view inside the iPhone app. So, what you have to do is detect that, style a Web code to make that work, build a bridge between the things that you want to write to interact natively with the Objective-C, say in Javascript, then build HTML pages for Facebook in the iPhone. So, you build much smaller native goop instead of having to build over and over again.


HTML5 is probably the way that we should have done it.

Near as I can tell, Facebook invented their own PhoneGap (i.e., FaceWeb) and sent to it, then FaceWeb changed webkit's rendering logic* to match instead of changing to a mobile HTML5 site? That's not HTML5 - that's just stupid.

* UPDATE: as pointed out in comments, this isn't exactly accurate. Faceweb does some funky stuff though, and their engineering manager in charge of the project couldn't even articulate what it is. So it still sounds like bad engineering unrelated to HTML5.

* UPDATE 2: You should read Matt Asay's analysis of Facebook's HTML5 fiasco. In fact, you should read everything Matt Asay writes.

phpunit travis ci undefined offset


How I learned to stop hating on PHP

PHPUnit Travis CI Undefined Offset

TL;DR - "Undefined offset" is an E_STRICT level PHP error, and uses E_STRICT+ by default. Put

  1. error_reporting( E_ALL );
at the top of your phpunit test suite to find and fix all your warnings and notices to fix Travis builds.


Today Laura and I chatted briefly about djangocon presenters bashing PHP. I mentioned that the Promote MDN code is some of my favorite code - in any language. As with my Zend_Rest code, the two keys I've found to writing good PHP code are:

  1. Use a coding standard
  2. Write unit tests

Coding Standard

I use Chris Adams WordPress Coding Standards for PHP_CodeSniffer to stick to that. It was amazing how much nicer the PHP code was when I took just an hour to clean up what I inherited from SEO Smart Links. The PHP community would do well to embrace, encourage, and even enforce coding standards more - the way the Python community does with PEP8.

Unit Tests

I write unit tests for Promote MDN too. My tests/doubles.php is hacky, but it Freaking Works™; I didn't have to build out a set of fixture data or couple the test suite to a running WordPress instance. Like WordPress, I just (ab)use the global namespace to (re-)define dependency functions with doubles.

I also took the opportunity to try out Travis CI. After fixing the travis.yaml and phpunit.xml files just right I got a bunch of test errors with the message "Undefined offset: 1" which frustrated me because I didn't see them locally. While we chatted about PHP, Laura reminded me about PHP's error reporting levels, and she was spot-on. I bumped up to E_ALL locally and got the same errors as Travis.

Error Reporting Level

I spent the next 10 minutes fixing my warnings and notices and realized - I should always use a higher error level in PHP. Python will rightfully gripe at me if I try to access a dictionary element by a key that doesn't exist. But PHP can be equally strict if I set my error level to E_STRICT or higher. So, I'm adding it to my list:

  1. Use a coding standard
  2. Write unit tests
  3. Set error level to E_STRICT

I really think these 3 practices could make any PHP code into good solid code. Instead of simply bashing on PHP, from now on I'm going to simply advise PHP dev's to stick to these practices - it's good for the developers and good for the community.

Firefox rapid releases: developers *are* users


There's a tempest brewing in the Interteapot over Jono's post about the Firefox rapid release cycle. I reacted the way he probably anticipated - "Good points that are already well taken." But tech media is sensational, so the story reported was "Firefox dev hates Firefox ZOMG!" prompting an official Mozilla Press Statement™ and a sincere face-palm from Jono.

Let me make something clear: Jono is one of my heroes. When he writes something, I read it. And when he writes how Silicon Valley culture has a monomaniacal obsession with hugeness, I read it so often that it's the first hit in my browser bar for 'le'. But I want to add another perspective to his main point - at least the main point he wanted to make.

The main point I wanted to make was about the distance between the developer perspective and the user perspective, the costs for users of updates (even good updates), and the reasons why developers (everywhere, not just Mozilla) may have trouble seeing updates from the user perspective.


Web developers

I'll emphasize that Jono means the Firefox developer perspective vs. the user perspective. Web developers are Firefox users. Working on MDN, acting as a developer evangelism rep, and running Tulsa Web Devs gives me some insight into the web developer perspective, so let me talk about them.

I've showed the new dev tools, HTML5, CSS, and JavaScript support to web developers and they are always surprised how much has been added to Firefox in the last year (i.e., the time they've been using Chrome.) Most of them make an opposite response to the one Jono describes - something like "Wow, I need to look into Firefox again." And I'm able to re-pitch, re-sell, and re-promote Firefox with "What's new in Firefox for developers" every 6 weeks rather than once a year!

In almost every one of these encounters, I also show web developers the Aurora release channel, and they love it. I tell them Aurora is Firefox, just 7-13 weeks in the future. (Because Mozilla has time machines) It gets new features like the awesome new responsive design view and javascript debugger even sooner, and it lets web developers see how their sites work in future versions of Firefox.

Here's the kicker: Aurora updates more frequently than Firefox does - and web developers love it! These are Firefox users. And importantly, they're usually "the people who shout the loudest about browsers."

So that's it. Just want to point out an important segment of Firefox users for which the new rapid release process is a big improvement. Jono knows this, but maybe some clueless tech journalist will pick this up and write a "ZOMG Mozilla web developer likes Firefox" article. Nah, not enough page-views.

UPDATE: Too perfect. Right after I published this, I got an update prompt from Aurora. 😉

Editing MDN with VIM

UPDATED: New screenshot with html filetype! Thanks Screwtape for the tip in the comments!

Yes, it's possible! If you're like me you want to spend as much time in vim as possible. While I appreciate CKEditor on MDN, I personally prefer to edit text in vim, and I think many developers might agree. And since MDN should include content written by developers for developers, here's a way to edit your favorite web developer docs (that would be MDN), using vim. (In my case, MacVim)
It's All Text Preferences

  1. Install the It's All Text Firefox addon.
  2. Go to the IAT preferences
  3. set your editor to vim ( in my case)
  4. set your hotkey. (alt+command+e in my case, now that I'm used to Firefox Dev Tools "Inspect" and "Console" keyboard hotkeys)
  5. Go to the MDN article you want to edit. (Apps/Getting Started in my case)
  6. Click Edit (duh)
  7. Click Source
  8. Type your hotkey!
  9. Drink beer and edit away!*
  10. :wq

* groovecoder is not responsible for whatever Sheppy might do to you if you actually edit MDN while intoxicated.

MacVim Quite on CloseNote: For MacVim you may need to set the "After last window closes: Quit MacVim" preference so it puts you right back to Firefox when you :wq.

Apps/Getting Started in vim

pseudo-translation to test i18n

MDN Unicode BannerI really like that Mozilla has a strong L10n team made up of both employees and community volunteers. Months ago we made some cool localization changes to MDN, and I learned a lot about django localization, gettext, pootle, and translate toolkit.

Back then Leszek, a localization volunteer and add-on developer, filed a bug about a bunch of un-localized MDN strings, and then found a bunch more un-localized strings again recently. I remembered I had read about using pseudo-translations for localizability testing, and thought I'd try it for MDN.

MDN, like (almost?) all Mozilla webdev projects, uses gettext message files (svn), so we can use translate toolkit. (woo! SourceForge project!) We also use a product_details repository (svn) to closely track the same language and country codes used by other Mozilla products. I needed to add the new test locale, but Pike pointed out we have to use a single-character subtag (x-testing) to indicate a privately-defined language code (per ietf bcp47), while Stas pointed out that pootle requires a two-character subtag. So, we added 'x-testing' language to the product_details (bug), then I added  xx_testing in locale/ for pootle, along with a x_testing -> xx_testing symlink so django uses the xx_testing files for the x-testing locale.

I installed toolkit and ran podebug on our message.pot file:

cd locale/
mkdir -p xx_testing/LC_MESSAGES
podebug --rewrite=bracket templates/LC_MESSAGES/messages.pot 
./ .

Which gave me a pseudo-translated messages.po file and a compiled .mo file.

Testing Messages PO file

I changed MDN to use the environment-specific language-loading snippet (found in playdoh funfactory) to keep the test locale from showing up in production. (We have to add the 'x-testing' locale to linux on our staging servers so gettext can use it there, which proves to be quite a chore.)

Voilà - a new pseudo-translated locale for MDN development. It shows which strings we forgot to mark for localization:

MDN strings missing 18n

Couple of items I'd like help with:

  • Find out how to exclude jinja template variable names so that
    {{ _('Welcome back, {username}]) }}

    doesn't create

    #: templates/includes/login.html:3
    msgid "Welcome back, {username}"
    msgstr "Ẇḗŀƈǿḿḗ ƀȧƈķ, {ŭşḗřƞȧḿḗ}"
  • Put all this into tower

Virtual Machines and Real Humans

Encouraging contributors to open source website development

Mozilla, like any good open source project, is a community. 25% of contributions to Mozilla Core, Firefox, Thunderbird, and other products come from the community rather than employees. We, i.e. Mozilla Webdev, want more community web developers to contribute to Mozilla websites. Here are community contribution stats for some Mozilla websites:

  • SUMO
    github: kitsune
    ADV*: 357k
    community contributors: 0
  • AMO
    github: zamboni
    ADV*: 736k
    community contributors: 3-4
  • Socorro
    github: socorro
    ADV*: ?
    community contributors: 1-2
  • MDN
    github: kuma
    ADV*: 56k
    community contributors: 4

* Average Daily Visitors
† Guesstimated figures - looked at commit logs and our LDAP phonebook; open to corrections

tofumatt wrote a good post about how we're starting to use vagrant and puppet to give developers easier access to working on Mozilla Webdev sites. lmorchard has a passion for this idea, and he's been extremely patient with all my troubles and questions about Vagrant and Puppet as I've tried to jump on the bandwagon of putting clouds in boxes. I don't want to discredit their work and opinions, but let me offer my own.

I am slow and make mistakes


Instructions for humans are nowhere near as good as instructions for computers. Humans make mistakes, misunderstand, and are generally not as fast as computers when doing this kind of thing.
- tofumatt

Amen to that. If you read some choice excerpts from our #mdn chat log, you'll see how slow I am (and how patient lmorchard is) re: vagrant. Even though I'm slow, I presumably have more "sysadmin" experience than the oft-cited hypothetical design contributor just trying to make a CSS fix, and yet vagrant and puppet make me cringe. So far, vagrant and puppet have only introduced MORE setup pain - and not the regular MySQL setup pain that I (and yes, even designers) have done dozens of times already.

Making boxes put boxes into clouds for your boxes

Clouds and Boxes

I've also started playing with Puppet by itself, to build plain-vanilla VM appliances and to spin up cloud servers on Amazon EC2 and Rackspace Cloud Servers. It's going pretty well, and it's conceivable we could do without Vagrant to script the build of downloadable VM appliances and to spin up disposable cloud servers.
- lmorchard

lmorchard is spot on - maybe because he's tired of dragging my slow brain thru vagrant and puppet. Our CI machine should generate vm images with 1-button deploy to Rackspace or Amazon. I think this idea of using VM's to encourage community contribution to website projects is an all-or-nothing deal. If it doesn't work 100%, it's worse than failure. If a community contributor runs into problems with vagrant or puppet, it's much worse than if they run into problems with MySQL or pip. At least there's a bunch of established resources to debug MySQL - I couldn't find much debugging resources for vagrant, besides lmorchard.

At SourceForge we had this kind of "ideal" setup for years. The Service Operations Group at SourceForge maintains sandbox servers with an admin dashboard for creating, managing, and destroying per-developer sandbox vm's that run instances of (Though sadly it's behind corporate LDAP - only given to employees) I don't know if/how that model could scale from a single site to dozens of sites all with different moving parts. And there are big latency issues developing on a remote vm. Still, it's exactly what we would want for that elusive CSS designer who wants to fix Mozilla sites without setting one up. She clicks "Create MDN Sandbox" and gets an email containing the domain and access credentials to start editing code on her sandbox. Beautiful.

The virtual machine is us

The web is no longer just linking information ... the web is linking people. People sharing, trading, and collaborating.

In all this technology, we sometimes lose track of the people. I don't want to abandon the idea of using virtual machines to encourage community contribution; the SourceForge sandbox model is, for me, the ideal system for enabling easy contributions from casual community developers. I'll join work for something similar at Mozilla.

I do want to highlight an additional on-ramp for getting community developers involved with Mozilla websites - Mozilla webdev's should get involved with our developer communities!

A couple weeks ago at our Tulsa Web Devs coworking day, Buddy and I were talking about Mozilla and he asked how he can get a job at Mozilla. I said Mozilla really likes looking at your open-source code, and also likes hiring community contributors. He asked how he should become a contributor. The easy answer is go to the Get Involved with Mozilla page, but since I was working on MDN that moment, I showed him the kuma repository I was working on. He forked it and went thru the "menial and often fragile setup" in our installation.rst; I fielded his questions as he went.

It was incredibly valuable - he filed a kuma setup and installation bug and made the appropriate fixes. Then he went on to fix an easy 1-liner bug, and got comfortable enough to do a significant bug involving cron, urllib, and json to generate a humans.txt file for MDN - which now includes him as a community contributor!

Of course, we can't spend all our time recruiting and mentoring community developers to do our work for us. [Or can we? 😉 ] And Buddy is an exception in his level of commitment to contribute. So, yes we should reach out to those developers looking to make a casual CSS fix without wanting to set up a whole website environment (though we've received those 1-line CSS commits into MDN even without vm's). That's a good reason to pursue turn-key VM's.

But if you're at a conference or an event and someone asks you how to get involved with or fix a bug on Mozilla websites, don't just send them to a page or a virtual machine - pull up a chair and work with the real human sitting next to you.

Web Standards in Visual Studio

Visual Studio HTML5I just learned about Microsoft's Web Standards Update to Visual Studio, and I think it's a great step for Microsoft. When Microsoft showed Windows 8 apps written with HTML, CSS, and Javascript, a lot of Microsoft dev's - especially Silverlight dev's - whined expressed concern about being abandoned by Microsoft.

My area - Tulsa, OK - is dominated by enterprise/Microsoft developers. I have heard horror stories of websites built by enterprise/Microsoft developers who know very little outside of Visual Studio. We're working on opening the web developer atmosphere up with stuff like Tulsa Web Devs and Tulsa Hackathon, and we're trying not to scare away the couple of Microsoft dev's (like Chris and Chris) who have come.

Philosophically, and as a recent Eclipse-to-vim convert, I know how much difference good developer tools can make, and I know Visual Studio is way up there for many developers. This web standards update is great for Microsoft web developers. I hope the project gains momentum, and gets some more official Microsoft promotion - more than their equally good WebMatrix project. (Which I heard about just a few weeks ago, even though I'm a web developer in a Microsoft-heavy area?)

quick blurb on NoSQL

I've spent about as much time thinking about this as NoSQL developers spend thinking about their schema, but here it is anyway.

At SourceForge I'm presently developing and maintaining a few different systems using all kinds of web tech's and languages - PHP, python, solr, Postgres, MySQL, and mongo. One thing I'm noticing is that the mongo systems are something of a breeze to write, and then a real challenge to maintain - especially debugging. Our mongo experts mostly say that the tooling for mongo is just 'immature.' I'm sure they're right, but that also points toward what I think might be a fundamental difference in the two modes of development.

AFAIK, there aren't any "old" NoSQL systems around? Mongo is only out since 2007, and Cassandra since 2008? We started using mongo early 2009, and even just one year out it feels so much more painful to maintain than our Postgres or MySQL systems that have been around since 1999! My theory is that NoSQL sacrifices maintenance and future development effort for the sake of startup development. I even made a neat drawing:

Initially mongo seems to save on effort until the first valley - initial launch. At this point, the system launches and typically starts interacting with other systems and with users - data requirements change towards reality, which means code - i.e., function and logic - changes, not just model. In our environment, all other systems that use the data must also change their code which seems harder than the originating code. The code and the data are so intermixed that seemingly any and every change in either domain makes knock-on effects that have to be addressed.

In a typical schema data system, we front-load a bit of data modeling effort. After launch, when we get new and changing data requirements we typically address the schema changes that might be involved, and may have to write a data migration/transformation script. But beyond that, it seems we don't have to worry about data integrity or any other knock-on effects. We can change some data-access or model classes and be on our way.

So, am I just an old crusty developer shouting at these NoSQL kids to "get off my lawn!" ? Or has anyone else noticed this too? Maybe it's just the heterogeneous mix of NoSQL + schema that's killing me. Just seems like such a pain for not enough benefit?