Tag 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.

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

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 SourceForge.net. (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.

The Long Local Tail of Web Developers

Long Tail of Web DevelopersAt my last work week in Mountain View, I sat in on a few #devengage meetings. I heard someone (maybe Christian), say we do a good job talking to the top 20% of web developers but not necessarily the bottom 80% - the long tail of web developers. At Mozilla, I know I'm not in the "top" 20% of Webdev - there are just too many awesome webdevs around me. And though it's intimidating, it's also exhilarating to work alongside so many top-notch developers who can teach me the "top" 20% of web development skills. (Les, I'm looking at YOU!)

Still, something many of us remote Mozilla employees appreciate is the "rock star" status that working for Mozilla grants us in our local places outside of "Hugeness bubbles" like Silicon Valley. The Mozilla reputation is relatively higher and commands more attention outside these bubbles.

For example, at the Tulsa School of Dev conference, with (I think) 150 attendees, a few Tulsa Web Devs arranged a "web" track that really amounted to a "WordPress" track, since all of us had at least some WordPress experience to share on an entry level. That afternoon, I gave a Web App Security talk using our own WordPress site as the victim. (Sorry guys). My session had about 40-50 attendees - maybe 1/3 of the entire conference!

I'm smart enough to know that I'm NOT smart enough to attract that many developers on my own merit. The simple fact is putting "Mozilla" next to a speaker's name in Tulsa, Oklahoma attracts relatively more developers than it does at High-Profile-Town Tech Conference 2.0. In Portland, at Open Source Bridge with 480 attendees, where more knowledgeable and more adept Mozilla Webdevs spoke; they attracted roughly the same 40-50 number of attendees at each of their talks - including those of us in Webdev!

What if Mozilla leveraged our remote employees' clout to reach out specifically to their local web developer communities - the "bottom" 80% of web developers like me? What would that do? I would hope a few very cool and important things:

  1. Push & pull more web developers towards the "top" 20% which ...
  2. Flattens the head of web developer knowledge and skill, which ...
  3. Raises the overall level of web developers

I've read the Long Tail. I agree power laws are natural and healthy distributions. We need the top 1% and the top 0.1% who are pushing development limits at the razor's edge. At the same time, Mozilla is about flattening power for the benefit of the individual and the betterment of the web. We could do really well if we purposely reach further outside the "top" 20% of web developers.

But what would it look like? Does Mozilla send staff to smaller local events where we already have remote employees? Do we sponsor these events? Do we bring some developers from small communities to Mozilla HQ for a work-week? I don't know - I'm asking.

bugzilla-agile

Bugzilla is cute but deadly.I'm not a pure Agilista™ but we're always trying to improve our development process for MDN. John and I like Scrum and XP stuff, but every team does Agile™ a little differently - as they should. A while back we shopped around for tracker tools and stuck (as Mozillians always do) with bugzilla. We - i.e., mostly John and Jay - also looked at acunote, planbox, scrumdo, agilezen, pivotal, and agilebench.

What we most like about Bugzilla:

  • Bugzilla is Mozillian - it channels the work of tens of thousands of Mozillians; we can cc anyone in the community on a bug
  • Bugzilla is open - we can link anyone in the world to a bug
  • Bugzilla is versatile - as Jonath says in Bugzilla for Humans, it's the devil we know

On the latter point, I've forked some agile features onto Greg's BugzillaJS to help us work more Scrummy™. Our most pressing issue is managing releases - our scope keeps bloating and our releases keep slipping. So we're starting to use the Agile/XP concept of "points" to estimate bugs, track our team velocity, and hopefully improve our release rhythm and reliability. Behold our improved "sprint backlog":

MDN™ 0.9.9 Sprint™ Backlog™

There's a few new things going on here. Here's a summary of how we're doing what we're doing:

Bugzilla Agile Target Milestone
Milestone releases - We use the milestone field of bugzilla for our releases. Next up is 0.9.9 scheduled for August 2nd release. As we move to a more continuous development and release cycle, the milestone version numbers lose meaning (just like Firefox), but we want to track releases. (Sorry James, we're not deploying every check-in just yet).

Bugzilla Whiteboard
Whiteboard overloading - We're using a tag=value pattern in the whiteboard to add new "fields" because adding fields and values to bugzilla requires IT changes and they're over-worked as it is. In our case,

  • 'u' - the primary user of the feature/bug (faster and more programmable than writing "As a ___, I want ___" every time
  • 'c' - the component that the feature/bug modifies
  • 'p' - points

bugzilla agile story points

Calculating points and stories - For any search that includes the "whiteboard" column with the specified tokens, the addon sums the number of "Open" and "Closed" stories and points for the release.

MDN Components Graph
Pretty graphs - data visualization FTW. Seriously, graphs give us a quick snapshot of the open v. closed bugs, and in which component we're spending our effort. This is important for MDN because we want to re-write the wiki while continuing to deploy site enhancements and changes. Now we can see exactly how much of our effort is going to the wiki as compared to other components.

I really hope this improves our releases and makes life easier for devs. Points by release and components are our most pressing needs so we can set realistic release and product expectations, and keep ourselves honest about where we're spending our effort. We'll probably add velocity and burndown charts once we finish a few point-based releases.

If anyone else wants to use it, my fork of BugzillaJS is up on github; download the .xpi file and open it with Firefox to install the addon. Feedback and pull requests are very welcome!

Edit: I should point out we're inspired by other agile Bugzilla tools - the Songbird team has wrestled bugzilla into their Agile process, and fligtar created moxie to help AMO product management.

Webdev Offsite & Open Source Bridge

Mozilla WebDevBack when we released Firefox 4, I remember a fellow mozillian tweeted

The folks I work with are built out of brains, grit, guts and glory. Amazing. I am _so_ lucky.

Last week I verified the sentiment when I met a bunch of the folks I work with - many for the first time. Our WebDev offsite (photos) was great. We had a nice little Webdev unconference at the Urban Airship office on Monday, then we all attended, and a few of us spoke at, Open Source Bridge.

On Friday a bunch of us hacked on little projects and, as the conference wound down, we snuck into a room for a hack-n-tell. It showed me how much skill we have in webdev, and our evenings together showed me our group's passion. I'm humbled by both.

Late absentee to the party

Firefox 4 Launch Party in Ten ForwardI'm a couple days late, but I work remote so I didn't actually get to attend the Firefox 4 launch party. Working remotely for Mozilla is a double-edged sword - it's a great opportunity to work for the best web company in the world from the comfort of my hometown, but we remotes miss out on the day-to-day awesomeness of company HQ. Even so, along with everyone I was mesmerized by glow.mozilla.org for which fellow webdev's potch, jbalogh, and chowse deserve every compliment they get! All of engineering operations did some amazing work for this. Our VP said it best:

The release day went off without a hitch - we shipped Firefox 4 to over 4 million 6 million people, and if that wasn't enough - we shipped 3.5/3.6 to hundreds of millions more, *at the same time*, all without breaking a sweat! Amazing websites were featured in news outlets such as the NY Times showcasing our amazing webdev talents (both in design and scalability), along with great dashboards from the metrics team that kept everyone on top of how the release was going over various mediums. Users were delighted to have fantastic support articles all updated for Firefox 4 and we caught the few people attempting to game/DoS our infrastructure within minutes. Sync more than tripled its new user rate and hummed along across multiple datacenters. Just amazing across the board.

What's also amazing is the sustained rate of the launch - we pushed 9M downloads on day #2 and we're still pushing 8k downloads per minute, so it looks like we may push another 10M today on day #3! If the other day was a good day for mozillians these last few days have been amazing - inspirational and humbling for this n00b webdev in the org. I can't say how proud I am to work for such a great company, so I'll let this video do it:

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.