Tag Archives: mozilla

Install to ADB: installing packaged Firefox OS apps to USB connected phones (using ADB)

I abhor repetition, so I’m always looking for opportunities to improve my processes. Spending a bit of time early on can save you so much time on the long run!

If you’re trying to build something that can only run in devices (for example, apps that use WiFi direct), pushing updates gets boring really quickly: with WebIDE you have to select each USB device manually and then initiate the push.

So I decided I would optimise this because I wanted to focus on writing software, not clicking on dropdowns and etc.

And thus after a bit of research I can finally show install-to-adb:

In the video you can see how I’m pushing the same app to two Flame phones, both of them connected with USB to my laptop. The whole process is a node.js script (and a bunch of modules!).
Continue reading

jQuery UK 2015

I attended jQuery UK past week, sorry about the delay in writing about it :-)

The organisation was as smooth as it could be. They made sure we knew where, how and when to go to places and treated us really well, so it was a pleasure to be a speaker in this conference.

I must admit I was stupidly silly with regards to the conference at the very beginning. My programming bias elitism was yelling on my brain “oh I MIGHT NOT NEED jQUERY! Who needs it these days anyway!?”

But turns out that

  1. there’s lots of people who cannot afford to compromise on customer support, so they have to go the pragmatic way, and
  2. there’s a lot about newest web technologies we can share with them too!

So when they asked me to talk about Web Components I opted to frame it in the most pragmatic way too: how to use them without shooting yourself in the foot, so you can start working in a more modular way and taking in all those advantages.

I asked before starting and from an audience of… 300? 400 people? approximately 20 had heard about Web Components and about 10? had implemented them in a project. So I ran a quick introduction on what they were, why they were developed and how they looked like, before tackling them interoperating with the four main “frameworks”: jQuery, React, Ember and Angular.

A write up on the results of my research is upcoming, but in the meantime you can look at the slides if you’re so inclined. Be aware that something in Nightly was crashing with the slides at the time I presented, so if your browser crashes (including Nightly for Android)… you know why ;-)

The talks I watched:

Addy Osmani gave an excellent talk on the state of Chrome’s developer tools and then explained how their team identified performance issues on Wikipedia, and how to fix them (this was related to Paul Irish advising people to not to use jQuery’s hide() method). Also, Paul is sorry for tweeting that without the proper context.

Natasha Rooney explained what Service Workers were and what problems they were meant to solve, but I am afraid if you had not a bit of background it would be a little bit confusing as the topic is *complex*.

Andy Hume explained various techniques on how to deliver fast experiences specially on mobile.

Alex Sexton infused us with a bit of South-West American culture and told us about don’t mess with Texas, then tried to find an equivalent for the web (don’t mess for the web?) with regards to hacking/building websites that cannot be hacked.

Jenn Schiffer explained all about vart.institute* and how it came to be. Also provided multiple screenshots of Dave Methvin keynoting at various jQuery events, which was quite amusing. And invited us to feel more empathy for people in the industry, which is a good thing if you ask me. *you can read it as fart and feel silly and it would also be totally OK

Estelle Weyl gave a very interesting talk on how to use forms and take advantage of all the cool features that browsers are already providing us but some people opt to rewrite in clumsy ways that go against all accessibility and usability best practices.

Ben Foxall did one of his shows (at this point we should call those a performance rather than giving a talk) where he involved everyone on the audience and elevated our phones from mere “phones” to interactive objects or “things” that transcend the simplest notion of “phone”.

I’m sorry I couldn’t watch the rest of talks, but it was great to meet Alice Bartlett, Rosie Campbell, Anne-Gaelle Colom, Rich Harris, Philip Roberts, David Rousset, and of course, Bodil Stokke!

After the last talk finished, we moved to the larger ‘hall’ style space where there were some snacks and drinks and people could mingle and ask questions if they hadn’t had the chance yet, so that was way better for me than going to a crammed pub, as I could walk between groups and speak to different people and not YELL ALL THE TIME. There were also some stands and also RETRO GAMES but I started talking to people and forgot to check out the games. AAAAH! Funny moment: Mike MacCana getting super excited about how he could help them setup multiplayer in DOOM using IPX.

All in all a very interesting conference for people who build websites and are willing to improve their practices or tooling… or both! I definitely learnt a bunch of things, so highly recommend checking it out next year!

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.