Tag Archives: node.js

tween.js mega changes

Yesterday I had my every-two-months lucky day in which I could sit down and work on tween.js, and DID I GET THINGS DONE!!!

The first thing I did was to get rid of the minified version. Since the build process wasn’t fully automated, I often forgot to produce and check-in that minified version, and people who used it would get all sorts of weird errors that I didn’t see (specially in Safari and iOS, as the polyfills we added would be in the uncompressed version, but not on the minified, sigh!).

Then I started using semantic-release as my invaluable helper for producing releases. Each time a push to the git repository happens, another service (Travis) runs a battery of tests to make sure nothing is broken. If the tests pass, semantic-release will get in action and (probably not in this order):

  • determine what’s the next “semver” for the package. This is a function of the type of commit you made (a bug fix, a new feature, docs, chore…). Important / breaking commits will cause bumps in the first digit, etc. (I suggest you read more on semver if you’re interested). The type of commit is specified by having the commit message follow a certain syntax. E.g. a feature will be feat: implement feature A
  • tag the commit with the version. E.g. v16.0.1. I believe this is what bower people use and desperately need, and I never provided because I don’t use bower and so didn’t notice.
  • create a github release changelog thingie in github. These go to the releases page in github
  • publish the new version of the package to npm

I think semantic-release can do so much more than this, but just having all these steps performed for me is A W E S O M E. So once I established this “infrastructure” I could go on and fix many other long-standing issues and also merge PRs and address questions.

Since we don’t have to produce a minified version, I got rid of gulp which is what I was using it for. Installing tween.js with npm is now very very lean because I also added an .npmignore and so it just essentially installs the code of the library only. Your trees will not include the examples anymore. Not that it was incredibly big but every byte counts to some people, it seems 😛

I also added jshint (for code correctness) and jscs (for code style) verification as part of the test suite. This was something that would put me off reviewing PRs… and specially explaining to people that it was not OK to change the whole whitespace in the file, or that they should respect the existing guidelines (even if it’s in the contributing file that very few read). So the rules are now there, and everyone has to abide to them, or the tests don’t pass and so the PRs are not accepted.

Interestingly, I added these steps using the advice in Kate Hudson’s talk from Nordic.js front-end automation with npm scripts, where she showed how you don’t actually need a task runner–I recommend you to watch it! Or check out her reading list on the topic.

Next up was dealing with a ton of sorta old and sometimes outdated PRs that had been lying in the guts of github for months. As I explained in my previous tween.js post, something had happened and I hadn’t even seen the notifications for these.

I prioritised FIXES first. Many people are coming up with some novel ideas and features, and I’m grateful for that, but I decided to focus on accuracy and robustness for now. Some aspects of the code are a bit obscure and I am not sure I understand them well, mostly because I just merged them in when someone proposed them, and now I’m paying the price when strange edge case errors are reported.

Of course, I’m still not done by any means, because there was a massive backlog and the day only has so many hours, and I’d like to do human things such as sleeping, etc.

This is brings us to this interesting paradox: many people use tween.js, including big agencies who charge a bunch for their projects, but only a very few submit code or respond to my pleas for help. Maintaining a JS library has become way more demanding over the years. Back in 2011 people didn’t care about npm, bower, tags and releases and what not, so working on tween.js was way more simple and less time consuming. I could have just put a zip file on a website, and people would be happy with that, for all that is worth.

But since I changed roles at Mozilla I am travelling a lot more, and it literally devours your time. I am not complaining about that, but I need quiet time to sit and get heads down on code, and I’m not having much of that lately. Mozilla supports me working on tween.js but I do have my own work duties which take priority. All my coding time is happening during working hours, and when I’m off work I like to enjoy my free time doing things such as being outdoors or just talking to people face to face, not via a bug tracker. Or despair about the list of issues and PRs growing and me not having time to even acknowledge them 😩

But before totally blaming open source for its toxicness, I decided to own this a little bit myself, and totally revamped the README file to make it a bit more welcoming and clear (I took heavy inspiration from Express). I have also filed some bugs and tagged them as help needed or good first bug respectively. If you enjoyed tween.js and want to give back by contributing to these bugs, you’d gain extra points of awesomeness.

People like roadmaps, so this is what I’d like to see next:

  • Review all pending bugs and PRs and resolve or close them.
  • Fix the things that have to be fixed and ensure all code is tested and clear before adding new features, because it is getting to a point where it is unwieldy and scary to even look at a diff (what even does this thing do!?). Hopefully the new automation will help here, and we can focus on logic and not on chores!
  • Divert all new feature ideas to the future ES6/ES2015/ESWHATEVER version of tween where everything will be super modular and you should be able to use parts of it as you need and hack other types of tweening engines as you see fit.

This is it for now. Thanks for reading, and happy tweening!

Possible futures, and nodebotting

You might remember that I was sorting out my music collection. This involves having to use iTunes for adding cover art and editing metadata and blah blah because I’m using a Mac and it seems that everyone has given up on making anything (anything!) better than iTunes.

So iTunes is this big huge mass of software that attempts to do everything at the same time and does nothing particularly well, and we’re all using it because there’s not much more else available. Talk about user choice, wooops.

Yesterday I was realising this horrible situation and started a parade of tweets:

  • I never know whether to cry at the immense UI failure that iTunes is or just laugh at it so ironically being the flagship product at Apple
  • When using iTunes I’m afraid to click on buttons because I do not know what havoc will that unravel. Things move around without explanation
  • There are buttons that turn into something else, something elses that act like buttons, data losses, weirdnesses, ugh
  • The worst is: there doesn’t seem to be anything better in Mac? (!?) 😭PLEASE PROVE ME WRONG, I BEG YOU 😭

Someone suggested Vox, which I haven’t tried yet. But seriously–only one suggestion! is that all that there is? I ended up thinking again about writing my own “player”. Except it would not be a player, or at least, not just a player, but I was thinking more about a sort of jukebox with sync. Of course I have other things to do right now so that’s probably not going to happen unless I win the lottery I don’t play.

I was in a good mood this morning so I decided to pretend I was funny and laugh at this whole mess with another tweet parade:

  • the year is 2030.
    you can do grocery shopping, pay council tax, vote for your fav eurovision artist and resolve git conflicts with iTunes
  • in 2045 iTunes finally gains sentience and writes the code for you. all commit messages mention titles of U2 songs
  • 2525 it is revealed that iTunes has acquired Skynet (to the tune of Visage’s In the Year 2525 but poignantly sung by Bono)
  • 3001: Frank Poole begs to be killed again by HAL 9000 when he sees iSkynet in action

And instead of sitting back and maliciously grin at the idea of this actually happening and how 2030 is in fact quite close in time and I could be saying “I told you so” in only 15 years, I grabbed my bike to go to Tableflip, the home of Nodebots in London, for a lighterweight NodeBots day.

Good things: it was a gorgeous day (specially compared to yesterday’s where it poured with rain for about 90% of the time), and I got lost in Dulwich which is a beautiful, albeit very adhoc and non-grid at all area, so it’s even a pleasure to get lost and wander around those streets.

Bad things: there was nothing bad about getting lost because there was absolutely no rush at any point during the day.

Oli was a fantastic host and he made us bacon sarnies and coffee. Their space is a-ma-zing. It’s full of tools old and new, and equipment and things and dust from sawing and weird mechanical and chemical smells, and flying things in various sizes and shapes, and there’s some other business where someone is building bikes. BIKES!!! It’s all super cool and I came back very excited about making stuff, even if I just managed to sort of use Johnny Five to control a servo:

Meanwhile, Tom was hacking on his Maschina and making it emit various sounds with JavaScript, Alex was transferring PCB positives onto another surface using an electric iron and two other guys were doing fantastic hacky stuff as well. I also got to hear about Fritzing and it looks really good.

I’m glad I got to use part of the equipment in the Spark core kit I got at JSConf.US 2014 which I still hadn’t had time to use. I’m sad I didn’t get to use the Spark core itself because the nodeschool nodebots workshop is designed for Arduinos and I wanted to see something happen physically and not just emulated, but I am certain I’ll be able to research this before iTunes can also talk to Spark devices via iPay or whatever.

Playing with hardware is fun. I am an almost total newbie in this field. I keep forgetting which pin is the N pin for LEDs (it’s the short one, I just looked it up today). I keep forgetting how to read resistors and how to connect things together. It’s all fine: it’s on the internets, somewhere, or alternatively it comes back to me once I get started. I have absolutely no expectations for what I’ll do and so I can’t let myself down if I forget everything from the last time I played with hardware. It’s OK. It’s a game. It’s fine to forget the rules, you can always re-read them.

And if you haven’t had enough future scenarios, here’s also this very funny article: A horror story that starts with Twitter.

npmoffline: installing npm packages from the cache

npm has a feature where you can ask it to install packages from the cache, where cache-min forces npm to avoid installing packages younger than that value:

npm --cache-min 9999999 install <package-name>

This works, but I’m never going to remember that syntax, so I added an alias to my .bashrc file:

alias npmoffline="npm --cache-min 9999999 "

So now when I’m offline on a plane and want to install a package that I’ve already installed in the past (and so I know is in the cache), I can write this:

npmoffline install <package-I-already-installed>

and it will pull the contents from my cache.

Yayyy 🎉

If it doesn’t work you can also list the contents of the cache with

npm cache ls

and see what packages and versions have been cached. Perhaps you can also grep it, to discard the packages you’re not interested in, e.g. the following will only list entries related to node-firefox:

npm cache ls | grep node-firefox

install-to-adb with command line tool!

As I said, I abhor repetition, so I added a new nifty feature to the install-to-adb module I made.

Now it also has a command line tool, and you can push and launch apps from the command line without even having to write a custom script that uses the module (of course, you can still use the module code by requiring it).

install-to-adb /path/to/your/firefoxos/app --launch

Continue reading

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