Category Archives: mozilla

Mozilla & Tulsa Web Devs

tl;dr - Mozilla sponsored Tulsa Web Devs for all of 2012. This year Tulsa Web Devs:

  • Grew to 215 members
  • Facilitated 3 spin-off groups
  • Had 11 monthly meetings
  • Had 50 weekly coworking days
  • Had 4 hack days
  • Ran 2 web tracks at local conferences
  • Hosted 2 hackathons
  • Participated in 1 Startup Weekend
  • Helped draft 1 City Council Resolution
  • Worked on 32 open-source web projects

I'd also like to see what other Mozilla remotees are doing in their local web communities ... ?

Members

We've added a bunch of great new members this year. I won't name any specific names for fear of forgetting someone, but our members have started spin-off groups like Red Dirt Web Designers, Red Dirt Graphic Designers, and Tulsa DrupalDevs. We also have a number of WordPress designers and dev's - though they haven't made their own sub-group yet. But our members have presented at OKC WordPress meetup and OKC.js May and June meetings.

Meetings

Our average meeting attendance jumped when we moved from Fab Lab Tulsa to i2E location downtown. We went from ~12 in January to ~30 in November.

By far my favorite meeting was our August meeting where we asked anyone and everyone to simply answer the question "What have you been working on?" in 5 minutes or less where the lightning talks ranged from Couch to django to WordPress to Node.js. I hope to do more meetings like this; even if we pick a single topic, I'd love to have multiple presenters for it.

Co-working

This year we finally - consistently - hosted (at and with Fab Lab Tulsa) coworking days (almost) every Friday. Attendance is anywhere from 1-2 to 10-12, with notable spikes anytime to dev's from consumeraffairs.com make the field trip. ;)

Many of our open-source project ideas come up during coworking days, and we give each other all kinds of technical advice - some of us have saved dozens of hours of work by simply asking a tech question around the tables.

Hack Days

Our hack days typically involved or included working on our open-source projects to prepare for other events. We started the year strong with Hack Days - doing one every-other-month to set up for our Spring Hackathon - but then we ran out of steam. Probably due to ...

~Web Tracks

This year we organized content for 2 "(sorta) web tracks" at established local technology events - a Gov2.0 track at Tulsa School of Dev, and an HTML5 track at Tulsa Tech Fest.

Our Gov2.0 track was pretty much a flop - it's not our area of expertise, the overall event had poor promotion, and the event logistics were terrible.

The HTML5 track at Tulsa Tech Fest was really good. I got Yury to come over from OKC to speak, Patrick to give a fresh edition of his CSS talk from the previous year, and even got Olivier Bloch to speak about HTML5 for mobile cross-platform app development.

Both of our tracks lead into ...

Hackathons

Our Spring Hackathon focused on Gov2.0 and "open data" projects. In 2011 we - especially John Whitlock - made a couple of very valuable and noticeable "open data" projects: TRIF and the Tulsa Transit GTFS project. Motivated by their success, we tried to do more of the same type of projects. We also increased the duration from 24 to 48 hours. We made some cool stuff, but, IMO, the format was too long and the domain was too narrow.

Our 2nd annual Fall Hackathon snapped back to 24 hours and focused only on "apps" - any app would do. Mobile web, HTML5, iOS, Android, Windows Phone, whatever. We did *some* promotion but not so much to be stressful, and we still had a good turnout and made some good projects and progress. I think it was just about the Right Size and Scope™ to be a sustainable yearly event.

Startup Weekend

A bunch of Tulsa Web Devs participated in this year's Tulsa Startup Weekend, creating projects like TFDD.co, Wallcade, and Picirus (this year's winner!). I also started a GeoNotes app aimed at Firefox OS, but our team was a bunch of backend dev's trying to learn HTML, CSS, and JavaScript so I wasn't confident enough to even show it at the closing ceremony.

City Council Resolution

Our Gov2.0 work attracted lots of attention from local civic interest groups, including Transit Matters, Tulsa Now, Tulsa Young Professionals, and eventually the Tulsa City Council itself. So, one of our city councilors contacted me about how to encourage and support the kind of projects and work we're doing. I suggested we should pass a City of Tulsa Open Source Resolution like some I had heard about from Portland, San Francisco, and Vancouver. It's still in draft stage but we hope to get it on a city council meeting agenda sometime next year.

Projects

We made too many projects to list them all, so just check out our Tulsa Web Devs GitHub org page or our Projects page. Our projects have spanned from local consumer interest to irc bots to wordpress plugins to open data.

Mozilla?

What does all this have to do with Mozilla? In running the group, I've tried hard to NOT make it all about Mozilla, but Tulsa Web Devs now boasts 1 Mozilla Contributor & 1 Mozilla Rep, 2 Open Web Apps, and dozens of engaged Firefox users. Now many members have asked me to bring MORE Mozilla activity into the group - to host a Mozilla hack day, bring speakers in from Mozilla, and help people contribute to Mozilla's websites. I'm looking forward to more collaboration between Mozilla & Tulsa Web Devs in 2013!

I'd also like to see what other Mozilla remotees are doing in their local web communities. Got a good story to share?

Mozilla & WordPress

Mozilla WordPress

TL;DR - I made the Promote MDN WordPress plugin and enjoyed it; why isn't(?) there a more intentional relationship between Mozilla & WordPress communities?

WordPress development

To make the Promote MDN WordPress plugin these last couple weeks, I've worked with WordPress more than I have in the previous decade. I've run dozens of sites with WordPress, but have never been active as a developer or contributor. Observations:

  • Keep code tidy - Okay, so there's globals and no MVC. But I copied messy code from SEO Smart Links, ran it thru PHP_CodeSniffer and it was actually easy to follow and work with it, due to the ...
  • Good docs - The codex has lots of good info. I Googled for stuff like "wordpress http get", "wordpress cache", and "wordpress i18n" and the codex docs always had what I needed.
  • Can leverage Verbatim for l10n - After I made a .pot file for the plugin, I added it to our existing MDN project on verbatim. Within hours it was translated into Dutch, Polish, and German. Then a couple days later Brazilian Portuguese and Spanish too. I love our localization teams so much.
  • Releasing is painful - It's exactly this painful. It makes me really love and appreciate our new chief deployment system on MDN, and heroku for my other sites.
  • Releasing is cool - It's cool that the plugin is now just a couple clicks away from millions of users. The appeal of "app stores" I guess.

WordPress development at Mozilla

I coordinated a "WordPress at Mozilla" talk for an OKC WordPress User's Group meetup. When I asked about WordPress on Yammer, only Craig and Jake claimed to have WordPress dev and deployment experience at and for Mozilla. They say we have many dozen - approaching a hundred? - WordPress blogs & sites at Mozilla. In addition to that, we have:

Mozilla and WordPress

WordPress runs about 55 million websites in the world. 332 million people view over 2.5 billion pages on WordPress.com's hosted sites alone, where there are also 500k new posts and 400k new comments every day.

Which makes me wonder - does Mozilla have any official or intentional relationship with WordPress? Should we?

WordPress empowers people to make and control their own content on the web. (As opposed to, say, Facebook Pages) It seems like we could combine efforts in some cool ways. At the very least, many of our projects and websites could probably put together a cool and useful WordPress plugin of some kind. It's really not bad at all. :)

Firefox rapid releases: developers *are* users

Jono

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.

Jono

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. ;)

Mozilla in OKC

In the last couple weeks I've made two trips down highway 44 to give talks about Mozilla technology to web groups in Oklahoma City.

OKC.js June Meeting BannerFirst, I went to speak at the OKC.js June meeting about the various JavaScript API's and related technologies Mozilla is developing and promoting for the open web.

Jesse had told me the OKC.js group has started well and they were right. There were about 25 or 30 attendees. I covered a lot of material (see my presentations page) and then gave away some swag - an Aurora laptop cover-sticker, shirts, and pens - to anyone who answered a quiz question about the content. Everyone likes shirts! In addition to questions about Gaming, Mobile, Apps and Boot to Gecko, I also got lots of questions and interest about our Tulsa Web Devs activities.

The following week I recruited Craig and Jake to help me give a "WordPress at Mozilla" talk at the OKC WordPress June Meetup.

There were about a dozen attendees and we used vidyo to do a conference presentation on our blogging infrastructure and operations (Jake), our theming (Craig), and finally I showed our BrowserID WordPress plugin. We got some good questions an interest, particularly in new One Mozilla theme and its accessibility features. I left a bag of pens for the meetup group - I had given away all my other swag at OKC.js.

OKC has a good web community that is starting to connect and do more - much like Tulsa. We have a full-time Mozilla employee in OKC. I'll plan to collaborate more between OKC and Tulsa web communities. Maybe float ideas of an OK Mozilla group or something. I'm already planning to talk to students at Francis Tuttle Technology Center Web Design and Development program.

MDN 2.4.5

Late as usual! MDN 2.4.5 bug list and backlog.

Highlights

  • Wiki
    Syntax Highlighting
    KumaScript is in! (Though it's not available on stage9 yet.)
    Migrations are running on stage9
  • Bugs

Check the MDN 2.5 backlog for what we're pushing next!

MDN 2.4

MDN 2.4 bug list. This was our first 1-week sprint and release, so there's not as much to report.

Highlights

  • Wiki
    Nothing shipped, but Les filed the master bug for KumaScript - our replacement for DekiScript.
  • BrowserID
    Fixed lots of little bugs and enabled BrowserID for French, German, Spanish, Polish, and Chinese locales.

MDN 2.4.5

MDN 2.4.5 sprint backlog.

  • Wiki
    KumaScript lives and I ran it successfully on my local environment!
    Syntax highlighting for code samples - both new and migrated
    Profile doc activity feed switched to Kuma
  • Some bugs

So, wiki work continues at a good clip and our process seems to be going well. We're changing our standup time to 10am PT since most of the team is CT or ET now.

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 (MacVim.app 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

MDN 2.3

Released February 28th. We are moving to weekly releases on MDN so these posts are hard to keep up. I will probably start combining releases. And I'm just going to link to the MDN 2.3 bug list instead of linking individual bugs.

  • Wiki
    migrate tags from MindTouch to Kuma
    (Re-)enable tag display and editing
    remove extra redirect for locales
    verify code samples work post-migration
  • BrowserID
    fix login infinite redirect bug
  • HTML5 & Apps MWC pages
    Paul and Craig cranked out the new HTML5 and Apps landing pages in time for MWC

ScrumBugs for MDN 2.3While Paul was with us he created ScrumBugs! I love it! I always appreciated the way we did Agile/Scrum/XP/whatever at SourceForge.net, and I've been forcing pushing for Mozilla WebDev to adopt some of the same practices. And I just really like pretty graphs! Can you tell?! :)

MDN 2.4 & 2.4.5

We're calling our first weekly sprints 2.4 and 2.4.5, but I think next we'll just move to 2.5, 2.6, ... until we all meet up in New York for MDNYC. At that point we'll probably abandon bugzilla milestones and just use the whiteboard to organize bugs into sprints based on release dates. Until then, here's what we're working on for 2.4 and 2.4.5.

  • BrowserID
    Hopefully killing all the remaining BrowserID bugs so we can concentrate on wiki
  • Wiki
    Les is rocking lots of KumaScript work
    Migrate file attachments
    Wiki code syntax highlighting
    Refine UI for tag editing
    Activate continuous migration on staging server for MDN doc community

MDN 2.2

  • BrowserID
    bug 721171 to draw Sign in buttons with progressive enhancement - should hopefully fix our search results snippets too! ><
    bug 719945 to link to browserid on the demo submit page
  • MindTouch wiki migration
    prepare for localized page migration (bug 717380)
    scripting architecture (bug 715253)
  • More

Kumascript Diagram

I'm excited about kumascript - lmorchard's prototype for implementing server-side scripting in kuma to replace DekiScript. I'm glad we're using JavaScript. I was a little surprised that MediaWiki chose Lua for their new scripting language (is it ironic that DekiWiki and its Lua-based DekiScript has roots close to MediaWiki and now MediaWiki is going to Lua-based scripting too?). JavaScript just makes sense for us - a community of web developers writing web developer docs.

MDN 2.2.5

MDN 2.3

MDN 2.1

We're doing better at keeping away from big new features while we try to work on the wiki migration, so there's no big item in today's release notes.

  • More BrowserID cleanup
    bug 715723 was really annoying - Sign in was broken from wiki pages
    bug 715811 should help users who've forgotten which email address they use on MDN
  • MindTouch wiki migration
    James did a thorough job on bug 710734 to expand the markup allowed in kuma
    Les did some more great working discovering all MindTouch namespace pages (bug 710753) and script template usage (bug 714804)
    Craig fixed up a bunch of CSS issues we've discovered as we migrate real content (bug 710737)
  • More

MDN 2.2