While getting the Cogent Blog up and running recently, I ran into a strange issue with the Ghost blogging platform and WebFonts - hopefully this will save you some pain.
We use a couple custom fonts on the blog, defining them using the CSS@font-face directives. One font was worked fine, but the other consistently failed to show up.
What the WOFF?
For the font that didn’t work, the browser received a 303 redirect to the same URI, but with a trailing slash. The font that worked was served just fine.
It turned out the “broken” font was in WOFF format, and the one that worked was in WOFF2 format. This wouldn’t normally make any difference, but something was definitely odd. Our blog is hosted on Ghost.io too, so troubleshooting options were limited.
Tricksy MIME Types
The solution workaround turned out to be really simple:
Rename the broken font’s extension from .woff to .woff2, and fix the paths in the CSS.
I’m not sure exactly why this works. Maybe it’s to do with Ghost’s routing rules – or maybe it’s the fault of Ghost’s CDN. Either way, hopefully this solves you some head-scratching if your fonts aren’t working as you expect.
I’m a keyboard/piano player, but I’m learning the Harpejji G16 as well. When playing in my band, I’ve tried playing bass lines with my left hand on the keys, and leads on the harpejji with my right hand. Unfortunately, the stage piano I’ve been using is too big to sit nicely with the harpejji, and attempting V-like instrument arrangements simply gave me RSI. I needed something smaller that was really easy to use, with as little setup as switching on my current keyboard!
Part of my year of projects.
What you need for this Guide
A Raspberry Pi, connected to the Internet. (I’m using an original Model B)
An SD Card with Raspbian installed. The NOOBS method is probably easiest.
Speakers to plug into your Pi, for troubleshooting.
Option A: Monitor & keyboard, for interacting with the Pi directly.
Option B: another PC for SSHing to your PI.
Preparing your Pi
There’s a little bit of work required to get acceptable results out of your Pi. We’ll overlock this Pi, so you will need to power your Pi from a mains power supply to make sure it gets the juice it needs. From here on, we’ll assume you’ve logged into your Pi as the pi user and have a terminal to enter commands.
Run sudo raspi-config, and select Overclock from the menu.
As I won’t be using this Pi for anything else, I’ve chosen to run it at the highest overlock, Turbo. If you’re not comfortable with this, you may choose a slightly less aggressive setting. Play around and find what works best for you.
Create a Separate User
Depending on what you’re trying to do, this step might not be necessary. But if, like me, you want to switch the Pi on and have things “just work”, you’ll want to do this.
Run the following commands:
$ sudo useradd -G audio synth
This creates the audio group, and adds a new user called synth to the Pi. It also sets the synth user’s primary group to audio. This is more important if you want to run your audio through the JACK audio server. I’m choosing not to here, but it’s an option. If you do decide to investigate JACK further, Ted’s Linux MIDI Guide has some useful information.
Next, we want to allow the synth user to run commands with elevated privileges using sudo. Run sudo visudo, which will bring up the sudoers file.
Navigate to the bottom of the file, and add this line:
synth ALL=(ALL) NOPASSWD: ALL
Save and exit the text editor. If no errors come up, the synth user should now be able to run sudo without needing a password.
Setting up the MIDI
Plug your MIDI controller into one of the Pi’s USB ports, and make sure it’s turned on.
Run aconnect -o, and look for your MIDI controller in the output:
Write down your controller’s client number - you’ll be needing it later.
To verify that MIDI events are being sent, run aseqdump -p *xx* (replacing xx with the client number you just wrote down). Play some keys, and verify that note on/off messages are coming through.
Making Some Noise
There are a few options you can choose to generate sound from your Pi, but I’m going with FluidSynth. CPU cycles are precious on a lower-powered device, so more complicated audio software may not work as well. YMMV.
Plug your speakers into the Pi’s stereo output, and make sure they’re switched on with the volume at a low-medium level.
At your Pi’s terminal (again, assuming you’re logged in as the pi user):
$ sudo apt-get update
$ sudo apt-get install fluidsynth
# Try running the aplay -L command. If the Pi complains about aplay not being found, run this too:$ sudo apt-get install alsa
# Now run:$ aplay /usr/share/sounds/alsa/Noise.wav
If everything worked properly, you should have heard noise come out of your speakers!
Wiring it all together
This can get a little fiddly, and I found it helpful to have 2 terminals open on the Pi at once.
In terminal 1, run:
$ fluidsynth --audio-driver=alsa --gain 3 /usr/share/sounds/sf2/FluidR3_GM.sf2
FluidSynth version 1.1.5
Copyright (C) 2000-2011 Peter Hanappe and others.
Distributed under the LGPL license.
SoundFont(R) is a registered trademark of E-mu Systems, Inc.
fluid synth: warning: Requested a period size of 64, got 256 instead
Type 'help'forhelp topics.
Write down the client number for Fluidsynth as well.
Now let’s hook up both ends! In terminal 2, run:
# xx is your midi controller, yy fluidsynth$ aconnect xx:0 yy:0
Play some notes on your keyboard - you should hear some piano sounds come out of your speakers!
Doing all the setup is fine and good, but I’m not going to lug a keyboard around and run everything each time I power on the Pi! Let’s get it happening automatically.
WARNING: Getting these next steps wrong could stop your Pi booting properly. Be careful!
Switching to upstart
Run sudo apt-get install upstart, following the warnings carefully, then reboot your Pi.
Now we’ll set the Pi to autologin the synth user we made earlier. Backup /etc/init/tty1.conf, then edit it with sudo privileges so it looks like this:
# tty1 - getty
# This service maintains a getty on tty1 from the point the system is
# started until it is shut down again.
start on stopped rc RUNLEVEL= and (
container CONTAINER=lxc or
stop on run level [!2345]
exec /sbin/getty -8 -a synth 38400 tty1
This will automatically login the synth user on the first terminal. You can verify this by plugging a monitor into the Pi and rebooting it – instead of seeing a login prompt you should see a shell for synth.
Whenever you log into a Linux machine, a script called .profile gets run. Adding our fluidsynth setup from earlier (with a few tweaks) will run everything whenever the Pi is booted up.
Add the following to the end of /home/synth/.profile:
# Run fluidsynth, but this time as a non-interactive serverfluidsynth -is --audio-driver=alsa --gain 3 /usr/share/sounds/sf2/FluidR3_GM.sf2 &# give it time to boot upsleep 10
# connect the controller to fluidsynth# Don't forget to replace these with the client numbers!aconnect xx:0 yy:0
# Give fluidsynth a nice high priority so it gets as much CPU as possible!sudo renice -n -18 -u synth
Reboot your Pi, and when it’s finished booting, play some keys and listen to your new synth!
If running aplay above didn’t make any noise, perhaps you need to tweak your Pi’s volume levels. Run alsamixer and check that your output is right:
You should make sure that the output is set to be the Broadcom chip, not HDMI or your MIDI device if you’ve plugged it in. You can adjust the volume with the arrow keys &endash if this isn’t working, try pressing m to unmute.
February 2015 saw Federation Square host the latest instalment of RubyConf AU, one of the best tech conferences in Australia. Over 450 Ruby developers from Australia, New Zealand & beyond gathered for 4 days of workshops, talks, and social activities.
I only attended the talks, so I can’t comment on the workshops, although every attendee I spoke to enjoyed them. The 2 days of talks only had the single track, but I think they fell neatly into a few distinct categories. Here are my highlights from each :) They will be available on Eventer soon, so I’ll update these with links when that happens.
This was a wonderful talk. Children are great because they haven’t learned about what they “shouldn’t do” yet. I will be buying her book when I become a Dad, regardless of whether I have a son or a daughter :)
Live coding can be just as compelling as any other live art form. Joseph gave us a peek into the tools that exist for live coding music, and then gave a stunning demo of what’s possible with Clojure + Emacs.
“What new stuff could make Ruby better?”
A great mixture of humanity, high–level maths, and where our language might go in future.
Startups are hard. Build side projects instead. Present You won’t be under so much pressure, and Future You will have a richer set of experiences to draw on. Plus side projects don’t have to justify their existence!
or, You Can Do Post-Technical Things (and doing them will help the entire Ruby community). A call to arms for the more senior members of the community: If some of us who understand the benefits of Ruby don’t move into management, we’ll get managers who don’t and the community will suffer.
I loved the venue – the Edge Theatre is a stunning place and so central to everything! The only downside is that it only allowed for a single conference track. A few people were disappointed that there weren’t more “Ruby-centric” talks, and a single track probably explains most of why.
I liked the diversity of Social Activities. The organisers deliberately recognised that not everyone likes to go drinking at the end of every day. I thought the balance of other activities they provided catered for lots of different tastes. Well done!
I was pleased to meet a few new Rubyists at the conference. I feel like I’ve been on the fringes of the community for ages, and haven’t quite known how to “break in”, as it were. Meeting new recruits to our community gave me a chance to pay that welcome forward.
If you made it this far, well done. The conference was great, and Rubyists of any level should go next year and make it even better.
In just a few months time, I’m going to become a father for the first time. Being an expectant parent, and having some electronics lying around, I thought I’d combine the two!
The idea for this came from a Tessel blog post - taking readings from their modules and sending them directly to a cloud data service. I didn’t want (or think I’d get away with!) bare circuit boards in my newborn’s nursery, so I decided to make a small cover for the board as well.
I’ll be upfront: it’s not quite finished yet. I’m annoyed about that. But in the interests of accountability & transparency, iteration 0 is done!
I made a couple of errors, which I’ll fix when I do iteration 1.
I got the holes almost lined up correctly, but not enough to make the bolts sit smoothly with the PCB. I’ve got to be more precise.
I also painted the boards before drilling the holes (because I was ready to paint but not to drill) - sometimes you just have to be blocked.
What I wanted to discover
That I could simply pick up a new skill, and easily execute what I wanted to do. (This looks really embarrassing when I write it down!)
What I learned instead
I’m not as good with my hands as I thought.
Knowing what I want might be a good step towards the result, but it’s foolish to think I can get there in one step.
For me, better preparation is more important than feeling like I’m moving.
Inspired partly by Magnus Holm’s timeless repo, I’m going to post these kata here as embedded gists, so as I update them (and make more attempts at solving them) we’ll be able to see how my thoughts on software design grow and change.
The first one I’m going to put up is the bowling kata, and I’ll keep the full list up-to-date on the Kata page :)
So much of what we do as software developers is intangible - you can’t taste, touch, smell or feel code! I wanted to make something that was all of those (well, maybe not taste).
In 2011, I took a trip to the Middle East, where I visited a soap factory in Sidon, Lebanon. The same trip I bought some soap from Aleppo, Syria, and thought it was the most wonderful soap I’d ever used. Deep green, with a thick brown patina, it felt exotic to use and wonderful on the skin.
I decided that I would try my hand at soap-making. I’d never done much practical chemistry, and the thought of turning something you eat into something you could wash with was fun.
How does it work?
At one level, soap is Chemistry 101. You mix an acid with a base, you get a neutral salt. Soap is made up of two main components:
Lye (NaOH), which is a base
Some sort of oil, which is full of fatty acids.
With the right proportions and a good stirring arm, you’ll end up with soap!
Did you learn anything?
Apart from how to make soap, I did learn a few things.
Like lots of activities, soap-making works best if you have everything you need before you start. You also have lots of choices: what kind of oils will you use? Will you scent it? Will you follow the “hot” process or the “cold” process?
Because I’d thought ahead about my answers to these questions, I was ready when a block of time became available. I had what I needed, and I didn’t need to run out and look for an ingredient because I was ready.
Soap recipes are quite precise. I actually found the precision required comforting, for two reasons:
It helped me to concentrate on what I was doing.. Knowing too much lye or not enough stirring would ruin my batch scared me into focusing, being fully present.
It told me what to do next. I didn’t have to make lots of decisions on the fly, and I could concentrate more on executing instead.
Be Patient & Persistent
I knew what I wanted to do, and what I thought it would look like at the end. I still needed to do all the work required to go from ingredients to finished product. Following through and finishing gave me the real pleasure and satisfaction of a project completed. I got to use what I made, and I had pleasure in giving some away as gifts.
I’ll take these insights into my software projects, and my approach at work. I’m going to spell out what I need to do before I start, eliminate more distractions, and be thorough so when it’s done, it’s done.
Waleed Aly considered himself a strange guest speaker for a tech conference, given his background in journalism, political science & law. I disagree, though - especially for a conference focusing on humanity.
He challenged us to think about the ethics of the space we’re working in at both micro and macro levels, and used philosophy as a backdrop for the conversation.
The world of philosophy is often ignored, but it provides invaluable questions of “Why?” and “Should?” that engineering, as a “How?” discipline, simply cannot.
Q: “Are there inherent ethical challenges to the technology I’m working on?” is a question we don’t ask ourselves enough. The tech sector has a tendency to focus on what is possible first, then work out whether we should afterwards (usually after it’s too late and we’ve already done it).
Take (as Waleed did) driverless cars. He transposed them into the famous “Trolley Problem” - where split-second decisions have moral questions. We afford ourselves a certain slack because in that situation it’s hard to know what we would choose. What about a machine, that by definition has to be told how to think? How should it answer the question? Even as technologists, ethics problems are our problems.
macro, or the myth of “neutral technology”
Q: Why do we tell ourselves technology is “neutral”, when it so often ends up causing changes for good and bad?
The introduction of the car changed forever the notion of the city. Television changed forever the notion of mass communication.
We tell ourselves that our technological changes (new platforms new media) are neutral - or at least that the net good will outweigh the bad. Why do we do this?
We talk about “the death of print” in the news industry, and assert that journalistic standards shouldn’t change. But how could we assume that standards wouldn’t change when new technology allows us to optimise speed over accuracy like never before?
We build drones, and drones that can wage war without people present. But what would war look like when attackers needn’t fear loss of their own life? Would they be more aggressive and kill more people? Or would they save lives by being more precise?
Waleed suggested that the tech industry perhaps unsurprisingly has more progressively-minded people in it than conservatively-minded. If we recognised that, perhaps we would make better-informed decisions about the social impacts our technological decisions might have.
aside: Technology & Worldview
During Waleed’s Q&A, someone asked questions as “a self-confessed ethics n00b.”. He worried the ethical conversations ended up being a waste of time because he left with more questions than answers!
That fascinated me, because we like to pretend we make decisions in a vacuum, or guided by “reason, science, facts, etc.” And, to an extent, we all do.
But we also see every fact, every piece of information through lenses, or worldviews. To deny that is the very essence of cognitive bias!
How could we, as people working in a quickly-changing industry, incorporate more mindfulness of our worldviews into what we do?
This past week I got the opportunity to attend the inaugural Above All Human conference, held in North Melbourne’s Arts House Meat Market. Here are some thoughts & reflections I took out of it.
There are lots of conversations we’re not having as an industry. Ethics, diversity and responsibility often end up subservient to pragmatism, profit, and monoculture.
“Solving a problem” is a very broad statement. Some people’s problems are finding shoes that fit; others are finding capital to finance their businesses in places with no banking infrastructure. Others just want to find cool links on the Internet.
Just because people are internet-famous and can start cool businesses, doesn’t guarantee that they have insight to share.
Listen to people who are not like yourself, and you will learn.
Morning keynotes Perhaps I was just more awake in the morning, but I felt it was the best part. The morning keynote-ish talks were awesome, and I’ll give them some air time of their own.
#aah14 The conversations happening on twitter were amazing, and having MC @mpesce actively participating helped those back-channel interactions feed back into the main show.
Diversity of speakers One of the organisers’ stated goals was to have a diverse lineup, across genders & cultures. I think they did a great job of that. The only piece missing were older people. There is a wealth of wisdom in the older voices in tech that would have been great to see there.
The venue all the tech conferences I’ve attended in Melbourne have been, sadly, a touch on the bland side. But the Meat Market was a great venue, and the mingling space outside the auditorium was a fun place to hang out, chat, and get refueled.
VC panel I was really interested in the questions being asked of the VC guests - about diversity in VC funding, approaches Australian companies can take in a smaller pond of money, and why an “exit” is pretty much the only strategy VC seems to be interested in.
Their answers? “I’ll fund what appeals to me”, “maybe you should just go to the Valley”, and “because 1000x, duh”.
A sad irony that those keen to invest in “innovation”, etc. feel no need (or interest) to innovate their own practices. What would disrupting the VC space look like?
YC Office Hours This was a strange segment - designed to mimic the YC pitching sessions, but on stage in front of an audience. It felt a bit like free advertising for YCombinator, and (even more oddly) most of the pitching companies didn’t seem that interested in their advice anyway. If I’d made any of those companies I suppose I’d be defensive of my baby too - but it made for a strange (voyeuristic?) experience.
Thanks to Bronwen & Susan for organising a wonderful conference. We need more of these conversations in our industry. Well done & see you next year!