So you know and love the idea of ember-cli. You also want to use sinon. ember-cli uses bower to bring in third party dependencies. At first glance it seems like you could just:

1

bower install --save sinon

It doesn’t work. Read along, or watch the video for details on getting sinon and ember-cli to play together.

Bring in sinon via bower

Turns out if you check the github repo for sinon, you’ll notice that the built files are not included. Looking at this comment, reveals that the author of sinon would rather not have the built files included in the repo. So fabiosantoscode forked the repo and provides a bower package (sinonjs-built) that provides the built files. This works. I don’t really care to have all of the repo in this case. I just want to use the sinon built file, the way I would outside of bower… So instead I add sinon to my ember-cli app like so:

1

bower install --save sinon=http://sinonjs.org/releases/sinon-1.10.1.js

This will bring in sinon and place the file at vendor/sinon/index.js within my ember-cli app.

Include sinon in the broccoli build

ember-cli uses brocolli to build out your ember app. To use sinon we need to make broccoli aware of, and process the sinon files. To do so, we’ll need two brocolli plugins. You can install them via npm like so.

1
2

npm install --save-dev broccoli-static-compiler
npm install --save-dev broccoli-merge-trees

broccoli-static-compiler allows you to pick files out of a tree, and optionally move them. We’ll use it to move the vendor/sinon/index.js file during the build.

broccoli-merge-trees allows you to merge broccoli trees together. We’ll use it to merge the ember app tree and the new sinon tree (of one lonely sinon file).

Now we need to include and use these modules within the Brocfile.js that ember-cli builds for you. So add in a require statement for both of them:

1
2
3
4

// Brocfile.js

var pickFiles = require('broccoli-static-compiler');
var mergeTrees = require('broccoli-merge-trees');

Next lets build a tree for, and move the sinon file during the build. Within the Brocfile.js still, add:

1
2
3
4
5
6
7

// Brocfile.js

var sinon = pickFiles('vendor/sinon', {
  srcDir: '/',
  files: ['index.js'],
  destDir: '/assets/sinon'
});

This tells broccoli to create a tree from vendor/sinon and copy the vendor/sinon/index.js file to assets/sinon/index.js during your build process. Lastly, we need to merge the tree that represents the ember app, and the new tree that we just created for sinon. At the bottom of the Brocfile.js replace the existing module.exports ... with:

1
2
3

// Brocfile.js

module.exports = mergeTrees([app.toTree(), sinon]);

Using sinon in your tests

So we now have sinon included in our app, and build process. Let’s use it in a test. The first step is to include it in the tests/index.html file. Add a script tag like so:

1

<script src='assets/sinon/index.js'></script>

Now fire up the ember server (ember serve) and prove to yourself that sinon is available for your tests by visiting http://localhost:4200/tests, open the console and type sinon.

Last step. In order to use sinon within your tests, open tests/.jshintrc and add sinon to the list of predefined globals. ember-cli executes a JSHint test against each of your files. Trying to use a global (like sinon) without including it here will cause a failing test.

You should be good to go. Mock, stub and spy away within your ember-cli tests.

Leaving and knowing that you’ll miss it

I recently gave notice to terminmate my employment with the company at which I’ve been employed (technically I’ve been a remote contractor for the last year). I’ve been there for 10 years, a long time when considered in the context of today’s tech world. I had a phone meeting today with the company’s director of software development. As we talked two things dawned on me:

1 I’m leaving for good reasons. Nothing gossipy or othewise worth posting. It is just time for me to move on.

2 It’s okay to recognize that it is time, and yet still feel a sense that I’ll miss it. I learned a lot during my time there. I made some good friends. I’ll miss working with ‘em.

I think (for me anyway), it is easy to let today cloud the long term perspective. I’m happy with where I am and where I’m heading today. Yesterday’s experiences, both good and bad, have helped me get where I am today. So I’m coming to grips with the notion that it’s time to leave, and yet still knowing that I’ll miss it.

Note: I wrote this about a year ago. During my transition to octopress, I realized I never published it… So here it is.

I really enjoy listening to good podcasts (lately I’ve been listening to Ruby Rogues and JavaScript Jabber a lot), or watching good screencasts. Over the years while teaching at a university I have recorded, and re-recorded hours and hours worth of videos for students to use as reference material. While these days I mostly hang out with tech geeks, there was a former life in which I lived in L.A. and worked as a recording engineer. In my life I have had access to some of the greatest recording gear the world has thus far produced. I’ve also worked on budget projects at home that turned out sounding great. I thought (with a little nudging from @olivierlacan) that I should write up a bit about getting great audio for your podcast, screencast, video, etc.

There are, in my book, four elements to getting great sounds recorded… Audio Source, Environment, Input and Levels. In this post I’ll describe a little about each and hopefully set you on your way to audio recording bliss.

Audio Source

In the audio engineering world, great detail is placed on the actual instrument. Have a $50 beat up piano, but hoping to make it sound like a Steinway? Good luck. No audio engineering trick is going to fix that. So you have to start with good sound. In the case of a screencast or podcast that means your voice. Not a whole lot you’ll be able to do there other than perhaps some vocal exercise. Try not to record just after eating. As odd as it sounds, I also try to stay away from soda while recording. Ever listen to a podcast where someone obviously needed to clear their throat but hadn’t? Not fun.

Environment

The room in which you record will have almost as much impact on the way you sound as your voice itself. Consider what it would sound like if you were recording in your high school gymnasium. Lots of echoes. In fact in something akin to a gymnasium, it is often difficult to understand each word as the echo from the room can be almost as loud as your voice. Every room, outside of really expensive acoustically treated rooms for science, has a sound signature. It is the way the room bounces sound around. Even expensive recording studios have a sound. In fact, it is generally on purpose. Rooms that have no sound reverberation make us slightly uncomfortable. This means that your office, bedroom, closet or where-ever you are going to record has some sound. Consider it’s effects on your voice. For vocal recordings, you want as little reverberation as possible. If you are serious about recording audio, I would consider some acoustical foam.

[Side note… this acoustical treatment stuff is impossible to take down if you “glue” it to the wall the way most manufacturers suggest. I built some small frames to mount it in, and then hung the frames on my wall. Much more transportable, and didn’t demolish my wall.]

If you are not invested enough to put up actual acoustic treatment, consider the amount of hard surfaces in the room. Sounds, especially at the frequency of the human voice, bounces off of hard surfaces quite effectively. Cover hard surfaces with blankets, the thicker the better. At one point in my life I leaned the bed mattress up against the wall to better cover the wall’s hard surfaces. Cover as much of the walls as possible. This won’t make a great recording studio, but for podcasts it will help quite a bit.

Consider any noises that will occur in the room. Is the Air Conditioner blowing? Are there fans running? Get rid of any noise that you can. There is a point of diminishing returns with this. If you want to see just how much sound there is, try recording a few seconds of you sitting silent in front of your microphone and then insert a second of silence in between using your favorite audio editor. You’ll hear all of those background noises disappear and then come back.

Input

Something has to convert the acoustical sound pressure of your voice to an electric signal. This is technically known as a transducer, and more specifically known as a microphone. The analog electric signal from the microphone then needs to be converted to a digital signal (Analog-to-Digital Conversion or ADC for short) that can be captured by your computer (or other fancy digital recorder). These are two individual processes that need to occur. What I’m really talking about here is a microphone and a way to digitize it.

You will read lots of advice online about using a USB microphone as it does both the transduction and ADC work in the same device. Just plug it in and you are off. I disagree. I really disagree. More on that in the levels section later. Headset microphones and other really, really convenient things don’t generally sound so good. You will want to believe that it doesn’t sound “too bad”, but you will be wrong. You’ll come to realize that you were wrong after investing way too much time recording stuff that eventually you’ll wish you hadn’t. If you want professional sounding results, you will need somewhat professional gear.

When considering microphones there are really two classes of microphones, Dynamic and Condenser. Dynamic microphones are generally not “powered”. Traditionally they have a more narrow frequency range (the range of frequency in which they can accurately capture sound). Condenser microphones on the other hand generally require a small voltage (typically referred to as “Phantom Power”), and CAN, but do not always have a wider frequency range. A few words of caution. I’ve heard people say that they prefer a Dynamic microphone because it doesn’t pick up some of the background noise in the room. First, get rid of the background noise. Second, this is similar to saying that you prefer using overly compressed JPG’s so you can’t see the poorly lit photo. A Dynamic microphone generally cannot capture the extreme high end of the human capacity for hearing too well. As a result it may seem like you are getting “less” noise. In reality you would get the same effect by using an equalizer and turning down most of the high end (what would equate to treble on you car stereo).

While there are always exceptions, generally vocals will sound more natural via a good condenser microphone. While top end professional condenser microphones can easily run into the thousands of dollars, there are a lot of decent condenser microphones in the $200 - $300 dollar range. I’ve used lots of microphones in my days. For myself, I have settled on a Rode NT1-A. These days you can get an NT1-A for around $230.

Levels

Both Dynamic and Condenser microphones produce a “mic level” signal. This isn’t actually a strong enough signal for us to record with typical equipment. In order to get microphone levels to a standard level, you need to run the output of the microphone into a “Pre-Amp”. A microphone pre-amp will boost the signal to appropriate levels to be recorded, known as “line-level”.

One of the main issues with recordings I hear on the web involve a bad environment, coupled with low audio levels. The issue generally goes like this: You record something, but your audio level is too low. So you go into your favorite editor and “Normalize” the audio. This brings up the audio level to the highest possible without clipping the signal. But, to your dismay it also brings up all types of hums, hisses, and other audio nasties that were previously not heard… What to do.

The answer to this dilemma is to record audio as “hot” as possible. You want to have your input level on your recording device (your computer, or other recorder) be as close to max as possible without clipping. This is tricky, the human voice is a dynamic instrument. It is easy to get louder as you get excited.

My advice is to use an analog compressor. There are lots of pre-amps that have an analog compressor built in. In previous years I’ve owned all types of pre-amp / compressors. In the end I have settled for a simple device by Joe Meek… You’ll have to excuse the site, they are audio engineers, not designers. It turns out they no longer make the version I have, but it’s closest cousin would be the threeQ.

What’s a Compressor

In audio engineering terms a compressor is an audio processor that limits the rate of increase for a sound once the sound crosses a specified level. There are a few parameters that compressors use. A “threshold” is a signal strength value. The compressor will begin operating on audio once the level is greater than the threshold. Compressors also have a “ratio”. A compression ratio of 4:1 says that for every 4dB (dB stands for Decibel, and is a unit of signal strength in audio) only allow the signal to actually increase by 1dB. Most compressors will also allow you to adjust two more parameters “attack” and “release”. Compression attack is simply how fast you want the compressor to kick in once the threshold is crossed, and release is how quickly you would like the compressor to return to non-compression once the audio drops below the threshold. Not overly complicated right?

Why use Compression

So earlier we talked about how getting the highest audio level without clipping the audio was paramount to creating a good recording. Human vocals are quite dynamic and it is easy for us to get loud enough to cause havoc on the recording system. So we compress the microphone output. This allows the audio level to stay a bit more contained, and allows us to turn up the input level on the recorder to get the best quality. Most professional vocal recordings you have ever heard are extremely compressed. You have to be a really skilled vocalist to convince an audio engineer that some compression isn’t required. When done right it will actually thicken up the vocal sound a bit.

This is why I believe you shouldn’t use a popular USB microphone. USB microphones contain the transducer (microphone), the pre-amp and the Analog-To-Digital converter. As such there is no way to compress the audio signal before it is being converted to digital. This results in not getting the best level possible, and the eventual “Normalize” process which makes everything louder, including the noise floor. In theory you can use some audio software to compress audio after it has been recorded. In my experience this just makes recording video more painful. It requires you to rip the audio from the video, process the audio, and then re-sync the audio back to the video. Not to mention you have already solidified the noise floor.

The last word on levels

When you start working with multiple parts (microphones, pre-amps, compressors, etc), it is important that you maintain an appropriate level through-out your signal chain. Allowing levels to be low on the pre-amp only to bump them up in the compressor will result in unwanted noise. Watch your meters and make sure you have appropriate level though-out the signal chain.

Conversion

If you’ve follow my advise thus far, you still need something to do the analog-to-digital conversion and record the audio. I have been using Mac computers for a long time now. Over the years my analog line input to my Mac has always been suitable for podcast / screencast quality. I simply plug the output of my pre-amp / compressor to the line input on my Mac. If you are on a machine where this is inadequate (I remember having a PC with a cheap “Soundblaster” audio card that was awful!), I would consider buying a small audio interface. I’ve had good luck with M-Audio in the past, but honestly haven’t had the need for a sound card for a while (thanks Apple!). I let my Mac do the ADC, and record the audio.

Take Aways

So… record in a room that has as much acoustical treatment as you are comfortable with (from blankets to acoustical foam), the more the better. Use a decent condenser microphone and run it through a pre-amp that has a compressor. Make sure that your recording device is getting the highest signal possible without clipping the input.

This is more as a reference for me than anything. I cannot seem to ever remember how to exclude a directory when doing a recursive grep so here we go:

1

grep /some_pattern/ /search/path -irn --exclude-dir=log --color

1
2
3
4
5

-i => case insensitive
-r => recursive
-n => show line number
--color => highlight the match
--exclude-dir => don't search in this path

For multiple excludes use --exclude-dir={dir1,dir2}

I’m mostly hoping that the act of typing this out will help it stick. Perhaps it’ll help you as well.

I have gotten this question a few times over the last few weeks (we have several developers starting to explore ruby at work). I put together a video today on debugging ruby using pry and pry-debugger. I thought I’d share it here as well.

I figure if nothing else, I’ll have a place to point people should / when the question arises again.

In the not so distant past I made a decision that I wanted to really force myself to get overly comfortable and proficient with vim. I took the plunge. I had a tough time at first, but as I look back, I’m really glad I did it. I really enjoy vim. I realize there are other great options as well. I’m not against others having their opinions on editors (or even IDE’s for that matter). But for me, I’m glad I made the jump.

I’ve started in on a course that is requiring us to write Java. The natural choice then is to go back to using Eclipse. I’m really comfortable with Eclipse, and recognize the power that it brings. But… I keep believing that I can get it all done just as quickly using the shell and vim. Add in snipmate, Command T and the ability to write some shell scripts, and I think I’ll be happy sticking with vim.

So this afternoon I took some time to build javantas a shell script that handles some of the cruft of starting a small java project.

Give it a spin from the Github Repo.

My quest to go all-in with vim continues to make progress. This progress was held up a bit with my recent work on C++ within the university. With all the cruft that surrounds C++ development a full featured IDE seemed tempting. So over the Thanksgiving break I spent some time working on yesman (available at GitHub). Yesman is a command line application that will create and manage your C++ projects including unit testing. It will create a project, download and compile Google Test, and help you stub out C++ classes, headers and testing fixtures.

It is not quite finished. Future versions of yesman will include a system that allows you to build your c++ project through yesman using a managed make build process. Feel free to fork, tweak give feedback at the GitHub repo

I’ve been sharpening up the C++ lately. I have found it interesting that there does not seem to be a de-facto unit testing library. There are plenty of options to choose from. I have decided to run with Google Test if for no other reason than it seems to be somewhat active and updated. I put together a quick pair of screen casts that walk through getting started with Google Test. I’m using a Mac running Lion (10.8.2) at this time, but believe these directions should be the same for most linux builds.

Enjoy

Downloading and compiling Google Test

Using Google Test

It’s no secret that I have arranged some things in my life to go back to school while continuing to work full time as a remote developer. I am quite grateful for the opportunity to do so. It was no small effort. I have a wonderful wife and a flexible work situation that have made it possible. Generally, when I explain to folks that I am going back to school, I am greeted with an interesting look and a simple question “Why?”. It is a completely valid question.

Most of my programming understanding has come through books, reading, and most importantly watching and doing. I’ve made plenty of mistakes over the years and I believe I have learned a good deal from them. I have gone through what I believe is the typical back-and-forth of “I’m a pretty good programmer”, to “I’m an idiot”, and then back. When the opportunity to dedicate a substantial amount of time towards becoming a better programmer arose, I took it. I am too much of a realist (hopefully not too cynical) to believe that somehow putting forth effort in a traditional computer science program will somehow transform me into a software craftsman. I do however believe that in higher education we should be promoting the same values that the craftsman holds true. More on this in a minute.

This morning I walked through the 18 degree Fahrenheit snow and ice to get to campus. As I often do, I was listening to a podcast during my walk. In this case it was the Ruby Rogues episode 78 . (As a quick aside, I really like the Ruby Rogues. It is informative and funny with just the right amount geek. Whether you write Ruby or not, it is a great podcast for web developers.) Anyway, so in this episode they are talking about Hexagonal Rails applications. They get into a small geek spat over the approach and the Active Record pattern as a whole (geek spats are perfectly healthy in my opinion). The discussion lead me off on a mental tangent about craftsmanship. One of the main attractors for me to the Ruby world is, what from my perspective feels like, a community effort to lift the craftsmanship level of the community. I realize that there are plenty of folks writing bad Ruby as well. Heck, when I look back at code I’ve written I feel like I’m one of them! By in large however, I feel that the Ruby community embraces this notion of software craftsmanship.

So back to my current situation. I am sitting through a few CS undergrad courses in order for the university to admit me into the post-graduate Computer Science program (my current under-grad degree is in Art & Design which “no worky” for the university…). I am learning a lot. So far it is mainly low level stuff that most pretend to get, but often have never really done. I’m writing assembly (which I’m convinced is good only as a rite-of-passage). I’m building the classical data structures (stacks, queues, trees, maps etc). Truthfully, it is a blast. The material isn’t overly complicated. The professors do a decent job. It is fun… in a nerdy way. But it isn’t perfect. There is something missing. Craftsmanship and passion for writing good software is difficult to find in higher education. Don’t get me wrong. There is passion and well intentioned professors who are putting forth their best effort. Generally however, the passion seems pedantically focused on minutia that typically feels irrelevant to the objective of building great software.

I think this craftsmanship gap is easy to fall into for academics. When you only discuss concepts for 50 minutes a day, three days a week, it becomes difficult to incorporate. Furthermore, in such a setting you are rarely ever forced to maintain or update your code, as such the need for well designed interactions fades. If the software you are writing never reaches a particular scale, as is often the case in under grad classrooms, it is an easy trap to fall into where you begin to question what value there is in design, unit testing, TDD, code reviews, peer programming, etc. As such you rarely hear about such things. Such things are relegated to a quick discussion of “you may hear of these things after graduation”. This is a mistake. I understand that in most higher education settings your input is a group of students who may have never programmed. I also recognize how difficult teaching programming to a blank slate can be (I had the privilege of teaching introductory OO concepts for several years at a private university). By not instilling a sense of passion about the quality of code a student writes, we are setting students down the wrong path. A path were the only metric of code quality becomes if the program “works”, is a path of re-living the mistakes of decades worth of experience of prior developers. There must be a balance between classical classroom theory and pragmatic battle tested approach and design.

This isn’t a new dilemma. The difference in approach between the apprentice and classically educated has been around for some time. I find it interesting that as a society we have yet to recognize the need for a dual headed approach. An approach in which we blend the real world nature of the apprentice with the theory of the classroom clearly has merit. Yet, as is often the case, we seem to divide off into our two corners of the world to assume there is no merit in the other approach. Hopefully someday we will figure out how to balance these two approaches. Both have a measure of validity along with numbers to show their success.

So people do indeed ask why I’m going back to school. Truthfully I am doing it to ensure that I have experienced both approaches. I believe that the systems we use and design will only get more complicated. I don’t believe that I’ll get everything I need from a classic education. I am hoping to balance a life’s worth of lessons, passion, and attempts at craftsmanship with the theory and low level understanding of classical computer science.

I just got back from Adobe’s Create The Web event in San Francisco. I am excited about Adobe’s direction and what they are up to. If you haven’t already seen it, you should check it out. They have put the keynote video up and it gives a good overview of what was talked about all day. In short, I really like that Adobe is taking a shot with open source software. This isn’t the easiest route to deliver a product but I think it helps to engage the community. More importantly I think it is a great way to get feedback from actual users who care about the product.

I left the event feeling inspired that Adobe is heading in the right direction with the new Adobe Edge product line. I hope that tools like Reflow have the ability to make a big difference in moving to responsive designs. I really like the inline editing and live reloading features of Brackets. Inspect (previously Shadow) is also a good focused product.

This was another aspect that I appreciate about the Edge line. Rather than attempting to make one big super tool, Adobe is making smaller focused tools for specific tasks. This will allow folks to use the tooling where they are helpful, but not require a complete rethinking of how you are comfortable working today.

Lastly, there is something exciting about web tools that are being built with web standards. There is something about a set of tools that is built by folks who are also writing web standards, that output files as web standards that feels right.

All in all I was really impressed by Adobe yesterday. I think they are finally hitting their stride in their move to support web and open standards.