good day for mozillians

MDN languagesI want to add a personal note onto what dria said about today's Mozilla activities. (TL;DR - Zarro Boogs on Firefox 4, new Web O'(pen) Wonder demo site, and a new Open Web Apps release.) We made bug fixes and enhancements to Mozilla Developer Network.

We made a handful of improvements to the localization code and process for MDN. Our web localization team is doing great work adding 15 new languages for the MDN interface!

MDN YSlow!

We've also made performance improvements and bumped our YSlow! score up to 88. We're almost ready to hook it up to a static CDN which should get us a strong 'A' grade. (We can't make those DNS changes while IT is preparing Firefox 4 release infrastructure.)

And if you poke around you might see a hint of what's coming soon to MDN.

open(war)

Evil App StoreWe (finally) see the tech industry take critical notice of Apple's closed nature. Most recently over the draconian terms they announced for publisher subscriptions. Of course, I've been self-selecting my articles ever since I heard about Apple's predatory application of the severely closed iOS/iTunes paradigm onto Mac software at large with the Mac App Store. I remember a couple of Apple (one a former employee) buds trying to sell me on it - first extolling the value of a search-able directory of apps with ratings and reviews; less than 5 minutes into the conversation they were complaining about poor App Store search results. Good thing there's an app for that.

This is not totally new. Open source has been fighting the open war (very well) for a while. There are well-known battle plans on both the proprietary side and the open side. Some on both sides want to see their "enemies" destroyed, but some of us think open source has "won" by simply creating and sustaining open products and opportunities - not necessarily destroying proprietary software.

The struggle for Open Web over proprietary Apps is simply an evolution of this struggle of open vs. proprietary. (Personally, I moved from SourceForge.net to Mozilla because I want to be on these new "front lines.") There are signs that the tide may turn in favor of Open Web Apps for Mobile and why not? We saw this already with the victory of the open web over closed networks like AOL, CompuServe, Prodigy, etc.

As much as I'd like to, I'm not predicting the demise of the App Store along the lines of CompuServe & Prodigy. I'm voicing my dissent from the closed status quo and appealing for a more open approach; at least a pro-open perspective. If you're making web apps, build them with open web technologies. Instead of making native mobile apps, make your web apps kick ass on all devices with HTML5, and only go to an App when you really need device-specific features like cameras and accelerometers.

UPDATE: Mobile Europe has a good article on HTML5 & App co-existence.

That's all.

if request.META['HTTP_DNT'] == 1:

SUMO Release</a> Yesterday I sat in on webdev work group - really just a bunch of webdevs sitting in conference room G ("get to da choppa"). I overheard a discussion that showed me the mission of Mozilla permeates the entire organization. Here's an anonymous summary to protect the guilty and innocent:

Dev 1: Check out this 7-line DNT implementation for Site A.
Dev 2: You know the B group is going to hate DNT.
Dev 1: Yeah.
Dev 2: I don't know if it's a battle I want to fight.
Dev 1: It's not what we want - it's what our users want.

It's the same attitude and perspective we had when we first discussed Do-Not-Track at a brown-bag - we should do what our users want. We discussed what Google and Microsoft are implementing, but there are problems with cookie blacklists, as the EFF pointed out. The one I heard most at our brown bag was that NAI "opt out" doesn't specify whether a user opts out of all tracking or only out of the behavioral advertising. The quote I remember from the Mozilla Privacy discussion was: "A Do-Not-Track header is the clearest message a user can send to advertisers that they don't want to be tracked."

It's also the most technically elegant solution. Check the NAI opt-out page with Firecookie and you see the following opt-out cookie: values - TOptOut: 1 (bing, live.com, MSN), optout: 1 (collectivemedia, criteo), id: OPT_OUT (doubleclick), opt: 1 (fetchback), optout: * (invitemedia), qoo: OPT_OUT (quantserve), NETID01: optout and NETOPTOUT: true (revsci), a: cOPT_OUT (rfihub.com), AO: o=1 (yahoo). And that's just from the dozen networks from which I've opted out. The page shows me at least two dozen more networks from which I still need to opt-out. I just did this exercise a couple weeks ago. How often do I need to visit this page to opt out? Where are these new networks coming from?

And a user doesn't have the same cookies between browsers so they have to get the opt-out cookies on every device (think Desktop, phone, tablet, etc. unless they use Firefox Sync of course), and have to get all the new ones on every device too. Google can help you if you clear your cookies - but that's the only issue Keep My Opt-Outs seems to address.

Compare all this with a header:

DNT: 1

It's efficient (6 bytes), decentralized, permanent, extensible (DNT: 2, 3, 4, 'all', 'behavior', etc.) and if it comes down to it - enforceable. It isn't a perfect solution, but I love working at an organization with top-notch engineering talent AND a pervasive focus on the mission to make the web better for everyone. Mozilla FTW.

__init__

I'm embracing a lot of things recently - python, django, my underused programming handle, and now blogging. I liked my old blog, but I didn't have the time nor leeway to post what I was doing all the time. Jay Patel, product manager for MDN, encouraged me to blog about what we're doing there so here I go:

from mozilla.webdev import Job

class MDN(Job):
    def begin(self):
        from mozilla.webdev.mdn import developer.mozilla.org as devmo
        devmo.enhance(features={
            '0.9.3':'Demo Studio', 
            '0.9.4':'Learn HTML5', 
            '0.9.5':'Single Sign-On'}
        )

        from mozilla.webdev.mdn import dekiwiki
        from mozilla.webdev.sumo import Kitsune
        class Kuma(Kitsune):
            pass
        dekiwiki.moveto(Kuma)

There are two parallel tracks for MDN - 0.9.x and 1.x.

0.9.x is a track of enhancements to the existing MDN django, dekiwiki, and phpbb systems. In 0.9.3, we're making an HTML5 Demo Studio, somewhat like the Personas Gallery for HTML5 demos. (Duh.) 0.9.3 will also feature many new locales in the django application, and performance improvements for django & dekiwiki. Our MDN staging server showed a YSlow! score increase from 81 to 91 for django; from 79 to __ for dekiwiki. We're still defining the other 0.9.x milestones.

1.x to 2.0 is a large rewrite of MDN moving the wiki docs from dekiwiki to 'kuma' - a clone of 'kitsune' - the django wiki application we use for SUMO. Both are japanese words (a django theme?); 'kitsune' means (demonic shape-shifting) fox and 'kuma' means bear. We might describe Mozilla support users as foxes and Mozilla developers as bears. Dekiwiki is a good wiki platform, but we've run into problems maintaining it, and we want to move all of MDN to django to leverage django libs and features - especially those developed by SUMO and other Mozilla django projects.

I'm mostly working on Kuma now - cloned kitsune and will merge mdn when 0.9.3 is solid. Then we should be able to branch kuma to an 'mdn' branch for the rest of the 0.9.x work and merge each milestone into 'master' with the 1.x work.

At least that's the plan for now. Keep tabs on the MDN wiki page, MDN bugzilla queue, and join us in #mdn to follow our MDN dev activity. We hope to make MDN a premier web dev resource and I think what we're doing now is going to help us get there.

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:

<img style="display:block; margin:0px auto 10px; text-align:center;cursor:pointer; cursor:hand;width: 600px; height: 200px;" src="http://1.bp.blogspot.com/_Fa_U5q7fBBY/S_rDEmp6JtI/AAAAAAAAAHA/HzWpTb8kA5U/s400/schema_vs_nosql.png" border="0" alt=""id="BLOGGER_PHOTO_ID_5474902780885477074" />

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?

Home / groovecoder by groovecoder is licensed under a Creative Commons Attribution-ShareAlike CC BY-SA
Home / groovecoder by is licensed under a Creative Commons Attribution-ShareAlike CC BY-SA