Tag Archives: javascript

And the NodeBots from London assembled

I attended today’s NodeBots London event. The theme (?) was “NodeBots of London… Assemble!” and so we did. Compared to the last event I went to in July, which was way more informal, this was considerably bigger (within the venue allowances, of course) with more people and more things to look at and talk about!

First Oli made an introduction to NodeBots (essentially a place where people program hardware using JavaScript, but everything is allowed if you want to), what Johnny Five is and its relationship to node-serial, same for Firmata, and then some interesting tips for software people turned amateur hardware people I hadn’t heard of before, such as:

the case of the generous motor, in which you can fry Arduinos connected to motors without diodes, when the motor keeps spinning even after you stop applying input voltage, and so it becomes a dynamo which feeds current back into the circuit and so… bye bye Arduino which didn’t have any protection
the flappy servo, when you sequence value changes too fast and that results in just some feeble erratic movements instead of the dramatic ones you expected

Then Alex made an introduction to electricity, in general, which was a good refresher for people like me who studied some electrical engineering at uni/school but haven’t used it for reals since then. He explained the basics (V = IxR) and also insisted again on the importance of putting the right resistors in the right place to prevent things getting fried. He used this online circuit.js utility to depict circuits and the flow of current, the voltages at each point of the circuit (in the subcircuits perhaps?)–super useful and I so wish I had had this when I was taking these subjects. Makes things way more intuitive!

And with that—we hacked a bit! Jerome Loï (who had travelled all the way from Paris!) tried to resuscitate my pseudo fried Duemilanove with a shield and a thingy to mount the ATMega168 only, but turns out that it’s such an old board/chip combination that the bootloader firmware is not distributed anymore! So I left it aside and focused on my next task for the day: find out what the components in the kits I have are! With Jerome’s and Alex’s help, and some image searching, all the components were identified in a matter of minutes. Yay!

Then I was not sure of what I wanted to do—I didn’t really want to start a new project although I have a practical idea, and I was also hungry and Oli’s marvelous cooking skills didn’t help to stop making my stomach rumble. Whenever I tried to focus on hardware or research for my idea, a new wave of delicious slow-cooked stew would reach my nose. Ahhh!

Fortunately Charles made a lightning talk describing how he goes from thought to execution using a sketchbook and Autocad instead of thinking by executing as it’s advised in many environments (something like “you don’t want to waste time and effort on build something expensive that might not work, it’s better to think on a sketchbook first”).

Also someone (whose name totally escaped me, ahh, sorry) gave a little intro about a somewhat related event about which I heard about aeons ago but which seemed to have faded out, Dorkbot. It’s been revived, but I’m sad it is held in a) a quite remote location b) at a time I can’t go, because it sounds like the kind of thing I’d like to attend. SAD FACE.

And then it was finally time for lunch. As expected by the opening flavour, it was so yummy! It gave the day a sort of lovely family reunion for Sunday lunch, except we didn’t argue about silly things, but just used the time to catch up on what we had been up to since the last time I visited their maker space, or talk about what we were building today.

After lunch, I spoke to various people such as Andrew Nesbitt of manythings-fame, and learnt new cool things. Such as:

  • Platform.io which is an IDE for “things”, built on Electron… which can work with Arduino and also has code completion! so if you don’t like the Arduino IDE you can use this instead
  • The Arduino board clones such as the Funduino are interesting not only because they might be cheaper than the originals, but also because sometimes they offer cool features such as additional pins for +5 or +GND, which sometimes can make it easier to build something by connecting the wires directly to the board instead of using a breadboard to ‘multiply’ the pins. Or has a toggle to switch between 3.3 and 5V, etc. This very interesting tip came from Jerome, who also told me about this French shop called HackSpark which not only have a lot of those Arduino compatible boards on stock, but also might seem convenient for folks in the UK. And also have a physical shop in Paris! Wow!
  • The Espruino is small. Like… really small! It also transpiles JavaScript to Lua (if I understood this correctly). You write JavaScript instead of Arduino C flavour, and you can get really quick feedback. Sounds like a cool idea for prototyping without having to tether as with Johnny Five—most useful for wearables!

But my super favourite thing I learnt about today is that pencil lead is a conductor! Jerome built a quick and fun pencil based resistor which controlled the speed of a 555 timer connected to a speaker. So effectively he was changing the frequency of an oscillator, and changed the pitch of the sound as he moved the pencil tip closer or further away from the banana connector clipped to the paper. The other end of the pencil had a drawing pin inserted on it and a wire too, effectively closing the circuit! You can see all this in action in this little vine:

We also talked about how I should use an accelerometer and not tilt sensors for my idea (to avoid false positives), and ways to use Web Audio with hardware stuff, and ways to make things that made noise, even how to make a leslie / hammond! So many things that we can make! So exciting!

And there were many other things I learnt but I can’t recall now (hopefully my brain will retain them). Do join one of these NodeBots groups if you can—great things to learn and a very welcoming environment!

It was also cool to devirtualize people I apparently had met already but totally didn’t remember (hi Jerome… sorry), and meet new people! Hopefully next time I will remember 😀

Oh and Jerome, who was one of the main instigators of the NodeBots cat mesmerizer workshop at LXJS 2014, happened to still have a workshop kit in his travelling suitcase and gave it to me… which means I have a laser in my possession!


From very annoying thing to slightly less annoying thing (and serial, and temperature sensors, and…)

You might recall the annoying thing I built with the Duemilanove before I left it in an unusable state. It was essentially the usual blinking example but with a buzzer connected instead of an LED.

But that wasn’t very musical. So I investigated a bit further. First I connected this huge chunky potentiometer to the board and learnt how to read its values. My idea was to change the voltage of what we wrote to the pin, depending on what the potentiometer said. A cheap way to experiment with how would different values sound in the buzzer, without having to recompile each time—interactive inputs are always so much better!

Analog reads give values in a 0..1023 range, and analog writes can only be in the 0..255 range. So to scale it I divided it by 4.

Continue reading From very annoying thing to slightly less annoying thing (and serial, and temperature sensors, and…)

No more tap tap tap sounds: yay!

A few days ago the fantastic Fritz from the Netherlands told me that my Hands On Web Audio slides had stopping working and there was no sound coming out from them in Firefox.

Which is pretty disappointing for a slide deck that is built to teach you about Web Audio!

I noticed that the issue was only on the introductory slide which uses a modified version of Stuart Memo’s fantastic THX sound recreation-the rest of slides did play sound.

I built an isolated test case (source) that used a parameter-capable version of the THX sound code, just in case the issue depended on the number of oscillators, and submitted this funnily titled bug to the Web Audio component: Entirely Web Audio generated sound cuts out after a little while, or emits random tap tap tap sounds then silence.

I can happily confirm that the bug has been fixed in Nightly and the fix will hopefully be “uplifted” to DevEdition very soon, as it was due to a regression.

Paul Adenot (who works in Web Audio and is a Web Audio spec editor, amongst a couple tons of other cool things) was really excited about the bug, saying it was very edge-casey! Yay! And he also explained what did actually happen in lay terms: “you’d have to have a frequency that goes down very very slowly so that the FFT code could not keep up”, which is what the THX sound is doing with the filter frequency automation.

I want to thank both Fritz for spotting this out and letting me know and also Stuart for sharing his THX code. It’s amazing what happens when you put stuff on the net and lots of different people use it in different ways and configurations. Together we make everything more robust :-)

Of course also sending thanks to Paul and Ben for identifying and fixing the issue so fast! It’s not been even a week! Woohoo!

Well done everyone! 👏🏼

On Loop 2015

I was invited to join a panel about Open Source and Music in Loop, an slightly unusual (for my “standards”) event. It wasn’t a conference per se, although there were talks. Most of the sessions were panels and workshops, there were very little “individual” talk tracks. Lots of demos, unusual hardware to play with in the hall, relaxed atmosphere, and very little commercialism—really cool!

Continue reading On Loop 2015

Some additional thoughts on the recent discussion about “frameworks vs vanilla JS” on mobile

Some context for those of you that haven’t been following this thing:

Paul talked about his research on whether to use a JavaScript framework on mobile devices was good or not, for a number of parameters of what “good” could mean. I thought it was a really good starting point because it is nuanced, has data, considers a number of pros and cons and it’s, in short, way more constructive than the usual FRAMEWORKS SUCK message.

The conclusion is that vanilla JS is faster to start as it doesn’t have to do all the bootstrapping that frameworks do. But perhaps using a framework can also be convenient for you as a developer—and for the user if the developer can provide value to them instead of building their own ad-hoc framework. But ultimately the decision depends of each particular case, and each developer has to make their own judgment.

Unfortunately people in Twitter started essentially responding that “hey phones would just get faster (MOORE’S LAW!!! MOORE’S LAW!!!!), so deal with it and use a framework”, and by the way, “actually Paul used an old version of Ember and also React would never be used that way”, despite the fact that Paul said so himself in the post. Anyway…

Tom didn’t quite like the analysis and said that you would need to compare using some other app other than TodoMVC because it’s too simple.

Dave added some more insights too, replying to Tom.

I want to add a number of additional reflections because I ALSO HAVE OPINIONS and since I’m done with talks for the year, I have time to manifest my thoughts now:

The “phones will get faster” fallacy

They might. But that’s not the case for everyone who is not a developer or a techie. The constant, absurd, terrifying-to-witness delusion of developers who believe that everyone is accessing their websites using a 4G connection with the latest and greatest device is just painnnnnful.

Granted, some apps will be built for very niche segments, and you can “count” that they will have the appropriate device to run those. An example of this, somehow, could be games that only run on PS4. The crucial difference is that, ideologically and ideally, the web is not a closed controlled platform as a games console is, despite the multiple and insistent efforts from certain vendors and the irrational buy-in from many developers.

But I go on the streets and I do not see everyone using the latest and greatest iPhone. I see a variety of devices. Tons of cheap Android phones which are suuuuper painful to see in action because the hardware is ‘utilitarian’ but developers assume that everyone has a great Nexus phone as they have. And also—people have been taught that they have to install an app per service because said services do not know how to build a website to provide the service. So turns out that people do need to complete a lot of tasks with their phone, and the more apps they install, the more crippled the phones become.

Yes, you can get another phone which is faster, but it’s going to eventually get slow as you reinstall your ‘task based’ apps again. And the fact that is “faster” doesn’t mean that it actually is giving you the 100% of the resources to you.

Also: apparently JS is not getting faster on Android, despite people buying ‘faster’ phones.

Todo MVC might be, in fact, good enough

While it might not be a super complex app, it is still an app and something we can compare between different ways of offering the same functionality built in different ways. Dismissing it because it’s smaller is ignoring the fact that this is a low bound of “how bad” it gets even with small apps. If anything, it might get even worse.

Code size is not necessarily bad by default

You can have a big code base that seems to run very fast on the phone—time from download to render being super small and the app being very responsive.

But you could also have a very small code base that blocks like there’s no tomorrow, and makes the users of an app cry in frustration because it makes them think that their phone is somehow broken (“WHY IS THIS SO SLOW argh I’ll need to get a new phone OMG NO”).

The sweet spot

Or: but what do you really need?

Framework fans often seem to get offended that the simple proposition of not using a framework (also known as “vanilla JS”) is brought into a conversation. “WHY WOULD YOU NOT WANT TO USE A FRAMEWORK IN YOUR SITE?!! ROWR ROWR ROWR GROOOOWL!!

Well, actually, you might not need a framework. Or maybe you might need one. Or maybe not now, but soon. So it’s good to plan a little bit ahead, but it is not advisable to plan too far away, because you might be adding lots of additional baggage you won’t need after all.

I think that using a framework starts to make sense once you go past a certain level of complexity. Specially when you have URLs that need to be parsed with a router, and then you have to render templates and all that—possibly your best bet is to use an existing framework with a good community behind, so that people have already tried doing similar things to what you might want to do, and there’s lots of literature you can find.

Those are probably well better tested than any “Frankenstein framework” you might write, and can also offer you great features such as rendering on both the server and the client side, so you get the best of both worlds. Developing this kind of thing yourself might take you a very long time.

But maybe you don’t need to do all that; perhaps you just need a router. Or just a template engine. In my ideal world you should be able to just pick bits and pieces individually, and use them. But that tends to only work for small projects.

Frameworks as a neutral option

It’s not explicitly discussed in the existing posts, but adopting an external framework developed, vettoed and regulated by some other organisation can be one of the most neutral things to do in organisations which do not want developers to “get territorial”, i.e. if the whole organisation adopts the framework ONE of its developers wrote, that developer “wins”, and it creates a potentially problematic power dynamic. I guess that would be Conway’s law at its best.

Another great side effect of not using a framework developed ‘in-house’ is that developers who work on the code base later don’t need to deal with the terrible lack of documentation that is the usual case with in-house frameworks. To date I yet have to see an in-house framework that is not terribadly documented, and I’ve been building stuff for the web for more than 15 years…

Developers love to engage in loud neverending discussions about framework technicalities but it’s important to keep in mind that politics are what ends up driving adoption more often.

History repeeeaaaating

I already wrote about libraries and frameworks back in 2007, where it was assumed that you had to choose a PHP framework. Ah, this never gets old…

Same conclusions apply, so I’m just going to literally quote myself:

[…] investigate […]