That is the title of the talk I gave yesterday at Full Frontal in Brighton. The video is still not out but here are the slides (and the source for the slides, with all the source for the examples).
If you were in my Web Audio workshop in Berlin, this talk followed the same style, except I refined some points and sadly forgot a couple. I also showed the Web Audio Editor in Firefox DevTools, which I didn’t in Berlin because Jordan was going to talk about it after me.
I had a little bit of a surprise at the end of the talk, when I “presented” for the first time a little project we’ve been working on for a while: OpenMusic. And I have “quoted” the presented word because the work has always been in GitHub in the open, so if you followed me in GitHub you might have seen all the repos popping up and wonder what the hell is Sole doing lately.
So, just in case you weren’t in the conference, OpenMusic aims to be a nice collection of interoperable/reusable Web Audio modules and components. This is an idea that Angelina sort of had when they saw my audio tags talk last year, and has been brewing in the back of our minds until a couple of months ago when the A-HA! moment finally happened.
And so I’ve been pulling apart components and pieces from my existing Web Audio-based code, because I realised I was doing the same thing over and over and I wanted to do new things but I didn’t want to do the same thing yet again. So, small npm based modules it is. And a bunch of them!
I’m a bit short on time lately (and I’m being very generous on this description), so some of the modules are a bit too rushed and a tad obscure, but they should work and have some minimal documentation already, and they’ll get better. Be kind while I deconstruct my hacks–or better yet, start deconstructing yours too! =)
Thanks to Remy for inviting me to this ultra cool conference… and accidentally triggering the A-HA moment!
A week or so ago James Coglan tweeted this:
It reflects perfectly why I didn’t get too much into Python other than writing isolated scripts that worked well with themselves and didn’t require extra packages, because installing them was a pain and different in each system (compiling, package managers, other package managers, eggs, pip, bla, bla). And then there was the virtualenv solution, but that adds another layer of managing that I have to deal with. I just want to get things done and be able to distribute them in a manner that makes it easy for other people to use my software.
This reminded me that I had to spend a whole afternoon a while ago trying to make some brew-installed packages operate in harmony with other libraries/binaries in my system. It was so tedious and fuzzy I can’t even remember what the problem was actually. Just the notion that installing all the software and making it all available into a global scope === bad, because different versions will require other different versions. And either everything works in harmony and life is beautiful, or you spent a rainy afternoon feeling miserable because of the weather and the incompatible binaries.
tween.js r14 is really more of a “cleaning house” revision than anything else. No new features have been added, but the library should be a little bit more usable now and lead by example by using better code examples that aim to be efficient JS and CSS wise:
- Include license header on the minified files too (hyandell)
- Make examples more efficient by using requestAnimationFrame‘s own timer instead of calling Date.now again (Robert Eisele)
- Make it explicit that you can install tween.js with npm and bower (sole)
As usual, you can download it/clone from github or install with npm:
npm install tween.js
And as a “new thing”, although it was always here, installing via bower is also possible:
bower install tween.js
You can also read more instructions and code samples on getting the library.
Cheers to whoever told me you could install any package using git with bower. I believe it was the magnificent Edna Piranha! So thanks Edna!
TL;WR*: a mostly social event, great for meeting the authors of those modules you see scroll past when you run npm install and it installs half of the internet. Also, lots of presentations on somewhat hipster stuff which I not always understood, but that’s great–I like not understanding it all from the get go, so I can learn something. And some discussion about physical and mental health and better community building and other important non purely technical stuff that usually never gets the chance to be discussed in tech conferences.
npm can do much more than just installing packages and resolving dependencies for installing packages. One of the things it can do is running scripts! You might have seen that already:
It has a series of defaults. For example:
will attempt to run
You can, of course, redefine those defaults by specifying them in the scripts field in package.json. Suppose my script for launching the server doesn’t live in the root of the project, then I’d have to modify the start script entry consequently. Imagine this very minimal package.json:
"start": "node server/main.js"
The defaults can be called with just npm something, and there’s a list of default scripts npm recognises in the script documentation page. Some are very handy because they get called automatically before some scripts are executed. For example, if you run npm test, the pre-test script will also be automatically run before (if it has been specified). You could use that to make sure your bundles are updated before testing them.
If you want to run a script whose key is not one of the defaults, you have to invoke it in a slightly different manner. Suppose it’s specified here in your scripts:
"my-specially-named-script": "echo \"NICE\""
You would then run it with
npm run my-specially-named-script
As you can see it’s not too complicated, and the whole thing is very minimal and obvious, which I like.
If you want to learn more about “advanced” uses of npm and scripts, be sure to read the excellent Task automation with npm run from the always inspiring substack.