MDN 1.7 Released

Posted by groovecoder on 09 Dec 2011

17We released MDN 1.7 today. Included in this release:

MDN

Wiki

  • Switch auth from MindTouch to django (big bug 674635)

MDN 1.8

The major themes of MDN 1.8 are:

  • Merge our separate mdn & wiki branches so we can develop and deploy both with a sane release process.
    It also lets run the new wiki on the production site, controlled by waffle, so we can get feedback from MDN users on the new wiki.
  • Clean up and polish the django auth.
  • Define UX and mockups for BrowserID.
  • Continue to support the Apps developer launch on MDN.

It's gonna be the future soon

Jay is leaving Mozilla! :( I'm going to miss him and his war stories from the good ol' days of Netscape. He brought a lot of insight and perspective to MDN and drove the efforts to make it more than "just" a documentation wiki. Until someone else takes over product management, we're going to put our heads down to work on the big components of the MindTouch-django wiki migration:

  1. Migrate MindTouch wiki data.
    It's nice that MindTouch stores HTML and our django wiki also stores HTML. Much better than having to parse and translate wiki markup.
  2. Implement an alternative to DekiScript
    MindTouch's DekiScript is a LuaScript subset for making dynamic content snippets in wiki pages. We're planning to implement an equivalent system based on JavaScript with a library to work with the django wiki.

I'll probably run product management interference for any urgent MDN features (e.g., apps) until we have a dedicated product manager.

Right now James and Les and I are in Toronto with #sumo and #sumodev talking about the future of the newly-amalgamating "Platforms" Webdev team. We want to open MDN, SUMO, Mozillians.org, and Input sites as community "platforms" over the next year. Stay tuned for more ...

MDN 1.6

Posted by groovecoder on 22 Nov 2011

MDN 1.6

We released MDN 1.6 today.

MDN

Kuma

Up next

For MDN 1.7 we will:

  • Complete the switch from MindTouch authentication & users to django authentication & users.
  • Add some spiffy HTML5 features to MDN.
  • (Start to) Merge the separate kuma (master) and mdn (mdn) branches into a single branch so we can optimize our git workflow and run the new wiki side-by-side with MindTouch for testing and comparison.
  • Promote MDN developer profiles.
  • Include various content changes and bug fixes.

In other news(?), as you can see from my Google search box there, Angry Birds Web now works in Firefox, and Safari and IE9. (Why does Rovio give Opera a big fat screen to download Google Chrome? How much is Google paying these developers to bundle or promote Chrome with everything?) Someone needs to tell Rovio it's not just for the Chrome Web Store anymore. And someone needs to tell Google that "Chrome Web" is as senseless as "Firefox Web", "Explorer Web", "Opera Web", "Safari Web", "Xbox Web", "iPhone Web", or anything else into which companies are trying to confine the web these days.

Angry Birds Chrome-only?

pseudo-translation to test i18n

Posted by groovecoder on 18 Nov 2011

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 \
    xx_testing/LC_MESSAGES/messages.po
./compile-mo.sh .

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

MDN Agile and status

Posted by groovecoder on 09 Nov 2011

tl;dr: We're settling into an Agile process for MDN with daily standups and weekly planning. In the last few months we've added and enhanced developer profiles, events, demos dev derby, and other MDN features. We've also restored, added, and enhanced drafts, review flags, search, article properties, section editing, and authentication in the new wiki. I'll try to write status posts more frequently - each time we make a release, if possible.

AgileAgile

Since my last MDN & Kuma progress post, we've settled into a regular, yet customized, Agile methodology in the MDN team with our agile Bugzilla JS tool. We've pushed MDN 0.9.8, 0.9.9, 1.0, 1.1, 1.2, 1.3, 1.4, and 1.5 thru it relatively smoothly. We've learned and adapted a few techniques in our Agile process worth noting:

Daily standups on IRC

  1. What have you done since we last met?
  2. What do you plan to do until we meet next?
  3. Are you blocked by anything?

By far the 3rd question here is the most important. The first questions are mostly intended to lead into the 3rd. Our scrum-master (now me) is tasked with removing any and all blockers as much as possible - usually chasing down people in other groups from whom we need something (IT, DevEngage, Legal, Security, etc.)

(Bi-)Weekly Retro & Planning Poker

We push code on Tuesdays, so we alternate between post-/pre- and mid-sprint planning meetings. Mid-sprint planning meetings are shorter and faster, little more than a standup. We use an etherpad template for a running minutes of our weekly Wednesday meetings. The basic format is:

  1. Retro - what's go[(ing)|(ne)] good or bad in the sprint?
  2. Discuss - general items to discuss, usually flowing from Retro
  3. Planning (post/pre-sprint only) - re-assess bugs carried over from previous sprint, use planningpoker.com to estimate the current sprint backlog in bugzilla

Test Chamber ProgressStatus

We're developing major features for both MDN and the upcoming wiki.

MDN

  • Developer profiles
    My MDN profile is missing demos because I haven't made any yet. :( We want to hook this up with Mozillians.org in the (near) future.
  • Events
    We've tried to make the MDN events page a comprehensive resource to find the events Mozillians attend. Inspired originally by Christian's site for Mozilla events.
  • Demos & Dev Derby
    We've done significant work on the Dev Derby feature - streamlining the process and clearing out bugs. This is one of my favorite MDN features. When I need to show anyone cool web technology I can open the MDN demo studio and inevitably find something way cool with canvas, video, audio, and webgl.
  • Miscellaneous
    We're also finding and squashing bugs as often as we can. We finally restored production server error emails, so we should be much better about squashing bugs that real users are are hitting. And we're trying to add smaller optimizations and fun features as often as we can.

I enjoy enhancing MDN in addition to building the new wiki system. The wiki is important and should help us take more control over our docs, but it's still behind-the-scenes; I like shipping code to a production site that helps people, especially developers, immediately.

Wiki

We hope to soon (by the end of the year) run the new wiki side-by-side with MindTouch so we can work from a single line of code and allow testers to compare MindTouch with the new wiki on the same server. But so far we've developed the following features on the separate kuma wiki staging server:

  • Drafts
    We use localStorage to periodically save the editing session so a writer doesn't lose precious work if their client crashes.
  • Review Flags
    We added review flags for both technical and editorial review.
  • Search
    We restored the Sphinx-powered search backend we inherited from SUMO/kitsune (just in time for them to move on to ElasticSearch). We still need to restore all of the search frontend and ancillary features.
  • Page Properties
    We restored and refactored document properties we inherited from SUMO/kitsune.
  • Section Editing
    We added section editing to the wiki - our first major modification to the wiki functionality we inherited from SUMO/kitsune.
  • Authentication
    We're in the middle of switching MDN user authentication from MindTouch to django. We will run both authentication backends together, first django then falling back to MindTouch and auto-registering and migrating users to django authentication as they log in.

The wiki work is going pretty well, but we still have a couple of major hurdles to clear: data migration & user scripting. We are already investigating data migration a bit, and once we start migrating data over it should help direct our work on user scripts. In my opinion, we can see light at the end of the tunnel but we're still watching out to avoid potential train-wrecks.

The rest

Outside of MDN, I helped pull together an HTML5 track for Tulsa Tech Fest, helped organize a Tulsa Hackathon with Tulsa Web Devs, and I participated in Startup Weekend Tulsa. At SWT we started a quick web app on top of the TRIF project from Hackathon called OttoZen to send an SMS alert to someone when there's a traffic incident on their commute. It's making us consider building a broader Data/App site for Oklahoma. We'll see.

From now on I'll try to make a status post every time we make an MDN release.

{{ your_town }} Hackathon

Posted by groovecoder on 12 Oct 2011

Main Street PixelsLast weekend we did our Tulsa Hackathon - the summary post has links to sites and code we made and a local media live stream where I talk too much like an idiot.

It was a great experience. Mozilla sponsored our after-party (thanks Stormy!) where I emphasized Mozilla's mission to open and improve the web for everyone - from 450 million Firefox users all over the world to 40 developers in Tulsa, Oklahoma. Here's a quick summary of the projects that more-or-less finished (more details at the website):

At Mozilla we have lots of remote employees who live in towns outside of the "hugeness bubbles" like Silicon Valley. I want to encourage any and all remote employees to get involved with their local technology and developer communities. To promote the Hackathon, I went on a whirlwind tour of our local groups - I spoke about Solr @ Tulsa Java, mobile web development @ Mobile Tulsa, attended a Tulsa .Net developers meeting, arranged an HTML5 track at Tulsa Tech Fest (where Dave gave us the big auditorium stage!), and attended our community leadership town hall. It was tiring, humbling, and inspiring. I'm still processing it all.

Programs like Mozilla Reps help amazing and effective volunteers to promote the Mozilla mission in local communities. In fact, out of all this activity, one of our Tulsa Web Dev's is applying to the program. But that shouldn't offset employees evangelizing for a free, open, and better web right in our own back yards!