Tag Archives: mozilla

webpack vs browserify

I saw a project yesterday that was built using webpack, and I started to wonder what makes webpack better than Browserify? The website didn’t really explain to me, so I asked in Twitter because I was sure there would be a bunch of webpack experts ready to tell me—and I wasn’t wrong! ;-)

TL;DR

Webpack comes with “batteries included” and preconfigured, so you get more “out of the box”, it’s easier to get started, and the default outputs are really decent. Whereas with browserify you need to choose the modules you want to use, and essentially assemble the whole thing together: it’s slower to learn, but way more configurable.
Continue reading

How to keep contributors when they are not even contributors yet

Today I wrote this post describing my difficulties in getting started with Ember.js, a quite well known open source project.

Normally, when I find small issues in an existing project, I try to help by sending a PR–some things are just faster to describe by coding them than by writing a bug report. But the case here was something that requires way more involvement than me filing a trivial bug. I tried to offer constructive feedback, and do that in as much detail as possible so that the authors could understand what happens in somebody else’s mind when they approach their project. From a usability and information design perspective, this is great information to have!

Shortly after, Tom Dale contacted me and thanked me for the feedback, and said they were working on improving all these aspects. That was great.

What is not great is when other people insta-ask you to send PRs or file bugs:

Look, I already gave you A FULL LIST OF BUGS in excruciating detail. At this stage my involvement with the project is timid and almost insignificant, but I cared enough to give you good actionable feedback instead of just declaring that your project sucks in a ranty tweet.

The way you handle these initial interactions is crucial as to whether someone decides to stay and get more engaged in your community, or run away from you as fast as they can.

A response like Tom’s is good. He recognises I have more things to do, but offers to listen to me if I have feedback after they fix these issues. I can’t be sure I will work more with Ember in the future, but now I might check it out from time to time. The potential is still there! Everyone’s happy.

An entitled response that doesn’t acknowledge the time I’ve already invested and demands even more time from me is definitely bad. Don’t do this. Ever. What you should do instead is act on my feedback. Go through it and file bugs for the issues I mentioned. Give me the bug numbers and I might even subscribe to them to stay in the loop. I might even offer more feedback! You might even need more input! Everyone wins!

This is the same approach I use when someone who might not necessarily be acquainted with Bugzilla or Firefox tells me they have an issue with Firefox. I don’t just straight tell them to “FILE A BUG… OR ELSE” (unless they’re my friends in which case, yes, go file a bug!).

What I do is try to lead by example: I gather as much information from them as I can, then file the bug, and send them the bug URL. Sometimes this also involves building a test case, or extracting a reduced test case from their own failing code. This is work, but it is work that pays off.

These reporters have gone off to build more tests and even file bugs by themselves later on, not only because they saw which steps to follow, but also because they felt respected and valued from the beginning.

So next time someone gives you feedback… think twice before answering with a “PATCHES WELCOME” sort of answer—you might be scaring contributors away! :-)

How to organise a WebGL event

I got asked this:

Going to organize a series of open, and free, events covering WebGL / Web API […]

We ended up opting for an educational workshop format. Knowing you have experience with WebGL, I’d like to ask you if you woudl support us in setting up the materials […]

In the interest of helping more people that might be wanting to start a WebGL group in their town, I’m posting the answer I gave them:

I think you’re putting too much faith on me

I first learnt maths and then OpenGL and then WebGL. I can’t possibly give you a step by step tutorial that mimics my learning process.

If you have no prior experience with WebGL, I suggest you either look for a (somewhat) local speaker and try to get them to give an introductory talk. Probably people that attend the event will be interested in WebGL already or will get interested after the talk.

Then just get someone from the audience excited about WebGL and have them give the next talk

If you can’t find any speaker, then you’ll need to become one, and for that you’ll need to document yourself. I can’t write a curriculum for you, as it will take way more time than I currently have. WebGL implies many things, from understanding JavaScript to understanding 3D geometry and maths, to how to set the whole system up and running on a browser.

Or can start by learning to use a library such as three.js and once you become acquainted with its fundamentals, start digging into “pure WebGL” if you want, for example writing your own custom shaders.

Or another thing you could do is get together a bunch of people interested in WebGL and try to follow along the tutorials on WebGL or the examples on three.js. So people can discuss aloud what they understand and what they don’t, and help and learn from each other.

I hope this helps you find your way around this incredibly vast subject! Good luck and have fun!

Now you know how to do this. Go and organise events! EASY!

It’s actually not easy.

Promise.resolve(node-firefox)

As a follow up to my FOSDEM15 post, here’s the link to the Hacks post on node-firefox: Introducing node-firefox. Or if you just want to jump to the code, here’s the project page.

It has got a really positive response and we’ve already got very good questions and ideas for using it in ways that we didn’t expect. Thanks all!

I have to step away from leading the project as my backlog of devrel tasks essentially grows by the day, but I leave node-firefox in the capable hands of my colleagues .DS_Storoz (also known as Brittany Storoz) and tofumatt (also known as tofumatt). Of course I’ll still be hovering around the project and maybe building the occasional module and whatnot! You can’t get rid of me that easily… ;-)

Notes on FOSDEM 2015

FOSDEM finished a few hours ago and I’m almost literally fusing with the couch from where I’m writing this, bad body posture and all. It’s the best I can do.

I presented the latest project I’ve been working on, node-firefox, at the Mozilla track today. I was screencasting my talk but there were mechanical difficulties (namely the VGA plug disconnected), and Quicktime went bananas with the resolution change, so you’ll have to wait until the recordings for 2015 are published to watch the talk. By the way, kudos to Ioana Chiorean for her well researched introductory notes for each speaker. She never ceases to amaze me :-)

It was really challenging to give this talk because there was people getting in and out of the room all the time, other people speaking out loud, and others playing games on a tablet (with sound effects!) and it was all so distracting that at some point I said something like “sorry, I’m really distracted”. I don’t know if that’s a “speaker faux pas“, but it was the truth! Ahhh! At least neither my live demos or Nightly crashed, so there’s that ;-)

I will write a post on node-firefox soon–probably for the Mozilla Hacks blog.

I spent most of Saturday finishing code + the talk so I only had the chance to watch a few talks by other Mozilla colleagues, and they were really interesting. Probably my favourite was Marco Zehe’s plea for rethinking the way we approach accessibility: it should not be an afterthought or a “nice to have” feature, it should be built-in from day zero. And it’s not only about blindness, it’s about motor impairment, cognitive impairment, color blindness… It’s not only about being able to “tab” between elements, but also about being able to understand their meaning. So many things we take for granted! We need to build for the people, but I feel we need to change our front-end culture of chasing the shiniest and nicest framework in order to get there.

I also wasn’t really thrilled about getting into the event itself. I found on Saturday that it didn’t have a code of conduct, or rather, it had a “social conduct policy” that verged on the antisocial:

The FOSDEM organisers were surprised to hear that harassment is a common problem at open source conferences around the world…

For an event this size, I expected them to have a code. I didn’t even bother to check! Even more, Mozilla is supposed to not to sponsor or attend events without a Code of Conduct. This was really disappointing. A year ago, I decided to never attend another conference without them. And there I was in Brussels and with a talk on my hands. What do I do? Do I just give up or just go ahead and do it?

I decided to do it anyway.

I sometimes go to places I don’t really feel like going to, so that someone else won’t feel like they’re the only one “not man”. It helps normalising the fact that women do exist in this field. It also puts a strain on me, but I want to think/hope that it will be less straining over time, as more and more diverse attendees join me.

Then on my way in, there was a group of Spaniards discussing out loud how German women are or not attractive. I’m highlighting “Spaniards” here because I am a native Spanish speaker, and I can be pretty sure there was no “misunderstanding” or cultural barrier here. I perfectly understood what they said. And when I hear that, I start wondering if they’re going to be discussing the rest of women they see at the event, the type of thoughts that are going through their minds, and that makes me uncomfortable.

Walking down the halls, I got those looks I hadn’t got in a few years—more specifically, since I stopped attending heavily sexist demoscene parties: “Oh, a woman!”. My colleagues that attended FOSDEM before had assured me it was a great event and it was all OK, but they are all men and their perception surely doesn’t include getting treated as an anomaly of sorts.

Thankfully, many attendees have called for a proper code of conduct. FOSDEM has replied, in a convoluted way, what many interpret as “we will have a code of conduct”:

Code of Conduct, message received. Booklet statement not evolved for 3 years, our way of handling issues has and will continue to improve. #

Some other attendees had made a fool of themselves declaring that CoC are not needed and “women are actually not interested in technology and engineering”. Pau, your behaviour is a good reason why women won’t apply to speak at FOSDEM. Have you stopped and considered that perhaps, maybe perhaps, women have less opportunities to change plans on a month’s notice and that’s why they can’t attend? Gah…

This “incident” aside, I had difficulty enjoying the event because of its busyness. The fact that it was all free and open for anyone to attend meant there was A LOT of people around, and while there were limits on the number of people inside a room for security reasons, there was no limit on the number of people circulating or just being on the halls. It was noisy and hot and damp, and as we say in Spanish “it smells like humanity” :-P . So if you have issues with crowded places, perhaps FOSDEM is not a place you want to be in.

I certainly won’t go back until they sort out their Code of Conduct and inclusiveness issues.