I hereby decree

by David LeMieux

 

Air Cannon
Fully Loaded Air Cannon

Nearly fourteen years ago I was in a musical performance group called "Thump." We were a bunch of high-school students ripping off, er, paying homage to Stomp and Blue Man Group. We played mostly percussive arrangements and put on, what I would call, a pretty rockin' stage show.

My job in the group was Lighting and Effects manager. I didn't play an instrument but I ran the lights, help make the tickets, ran the website, and handled other duties to help make the performance more professional. One project that I had for our second round of shows was to make an air cannon to shoot paper streamers across the audience during a particularly impactful part of the show. Air cannons of this sort were nothing new, but we didn't have a budget and so everything had to be made or acquired on the cheap.

I studied the basic mechanics of air cannons for a while. I consulted with local college and high-school physics professors to make sure my design was sound and would work. When I thought I had a good design I built a prototype. I used a small compressed air tank, some pipes, plumbing, an air gage, and a large aperture manual valve. I had wanted to use an electric valve but they were too expensive. After a few test runs I figured out the right way to pack it, how to add a paper cap at the end to ensure proper pressure distribution, and how to fire it on cue.

The night of the first performance things went better than expected and the air cannon effect provided an exclamation point to the already great performance. It went so well that as a group we decided we wanted two for the next night. The stage was pretty wide and the air cannon only effectively reached half of the audience. We wanted more coverage. Since I already had a working design I went out and bought all the same parts and put them together in the same way, or so I thought.

The second show was a few hours from staring and so I began to prepare the cannons. I packed them carefully with rolls of paper confetti. I checked the valves and all the connections. Then I asked a friend to fill them up with air to a predetermined pressure. I would have done it myself, but since I also ran the lights and other effects I needed to get those set up before people started filing in.

As the final number came we got the cannons in to position. We quickly reviewed firing them (I had been doing it on my own the night before, and this time I needed help) and we got the timing down with a non-firing practice. We armed the cannons and got in to position. The cue came, we turned the valves and nothing.

"Well, at least they both failed together" I thought when I saw the absence of paper streamers, but I was wrong. The cannon on the far side, controlled by my friend, didn't fire. I forgot to tell him that the air gage was stuck and so when he was filling them he thought it already had air in it. My cannon had fired, but it took a few seconds for me to realize that I was left holding only half of it. The entire barrel, a long length of 3-inch PVC pipe filled with confetti rolls, had rocketed in to the audience much like an untied ballon when the end is let go. The barrel weighed anywhere from three to ten pounds. I instantly remembered I had failed to add the last application of PVC glue. The result was that when I opened the valve it filled the barrel with air then sent it in to the audience like a rocket. The barrel cleared a four foot pit wall, sailed over the aisle, and back many rows in to the audience. I never asked how many exactly, but given the angle of launch, it had to be at least ten.

Luckily it "landed" in the lap of a friend and not on the head of a stranger. Actually, it landed in his girlfriends lap and she was okay. I could have seriously injured or possibly killed someone.

I don't know what happened to those air cannons. They were at a group member's home for a bit. I left for college and so did everyone else. They were probably thrown away. Sometimes I wish I still had them though. Those kinds of projects, in high-school, college, and throughout my life have been key in forming my education and experience. I learned so much from almost killing someone with a failed air cannon than I wish everyone could have similar, if perhaps safer, experiences of their own.

Is "killing" hyperbole? Sure, but how I felt in that moment I was afraid I had. I imagined all the worst scenarios.

I am grateful I had the opportunities I had when I was younger and it is a personal dream of mine to be able to enable others to do so in the future.

 

Comments (View)

 

 

I hereby decree has successfully migrated to better versions of core technology.

 

Comments (View)

 

 

Inspired by the current NSA Scandal







Enjoy!

 

Comments (View)

 

 

Code libraries and frameworks are great. They provide so much of the heavy lifting that developing with them becomes easy and predictable. In most cases, code libraries are a perfect remedy.

In JavaScript, for example, jQuery not only provides a nice interface for dom manipulation, but also normalizes all the browser quirks so that, regardless of how a method is implemented, we know it will work. True encapsulation that benefits the developer. Unfortunately libraries like jQuery come at a cost, albeit an increasingly small one: Bandwidth.

There are things that can be done to offset this, like using a CDN hosted version of the file. There are also tools that can help you manage what features you need and only package those in. Modernizr has an excellent example of this on their download page. Still, there are cases like those I see at work where a 20Kb library takes up too much space.

At Flite I help develop our ad platform. Users can make ads for desktop and mobile web use and then traffic them via different channels. The IAB has numerous guidelines about Internet advertising, and one of them is about file size. Some ads, for example, have to be under 40Kb, images and all. Since we develop a platform that allows users to create ads in a drag-and-drop interface and customize it will different components and features we are, in effect, serving small web applications as ads. But for all the functionality we allow, we can't tap in to the features provided in a library like Angular JS, for example, because the minified file size is nearly 30K on its own, leaving very little room for other assets.

I understand this is a problem that is perhaps unique to our circumstances at Flite. It still holds true that if we can, in most cases, make our file sizes smaller then sites will load faster and faster load times mean more satisfied users. So my question is always this: At what point does using a library become useful?

If all I need to do is get an element on the page, there is no need to use jQuery with its selector interface when regular old Vanilla JavaScript can help:

var item = document.getElementById("theItemIWant");

But if I need to do something that becomes complex across multiple browsers and my own code would be bloated and inefficient, why not rely on a utility to do it for me?

Picking the right library or utility can also help when bandwidth is concerned.

There are resources out there to help find small libraries, like Micro JS, though not every library there has legacy browser support. It is also important to be aware that some libraries have dependencies on others - so a small MVC framework might actually depend on some other larger utility in order to function correctly.

Like I said before, maybe this is becoming less of an issue in the real world, but why not take a moment to consider how to make things more efficient and cleaner for our end users? Also, the exercise of solving code problems without a framework helps engender more respect for them and their utility.

 

Comments (View)

 

 

There is a pattern in some JavaScript libraries in which methods called on an object return that same object so that more methods can be called. This is known as method chaining and it looks something like this:

$('#myDiv').show().addClass('foo').append("Hello"); //And so on 

This code gets the #myDiv jQuery object, shows it, adds the class 'foo' to it, then appends some HTML. We could continue doing this for many more methods.

Unfortunately, not every method follows this pattern consistently. Setting dimensions, for example:
$('#myDiv').width(300).height(300);

works fine, but if we call either of those methods without the new dimension:
$('#myDiv').width() //Returns a number

what we are really asking for is the current width and so a number is returned. That means we have one method with different return types. The jQuery team have decided this is how they want their interface to work and that is fine but this is something to consider when designing your own library. You could easily imagine that the method should always return the current dimension, even if a new one is set. Perhaps a different method that always return self would then also provide the kind of usability that is desired for chaining (e.g. $().setDimension()).

Method chaining is useful, but so are well defined, consistent interfaces. Promises use this pattern to great effect which is a small part of what makes them so powerful. My own personal preference would be that if your interface method can consistently return self and it would be useful to do so, then make it happen. Otherwise, I fall slightly over the line of being more interested in a clean api.

 

Comments (View)

 

 

I made some minor updates to please lately and I figured I could talk about them here.

First, I fixed some bugs around the token replacement and input for aliases that use them. I also made it so that the template values could be provided inline with the initial command so that what was once:

> please do something

> input: _


can now be:

> please do something -input 'foo'


Next, I made it so that when using --list you can provide a filter argument. please --list bar, for example, will list all aliases that contain the word "bar".

Finally, I added environment variable support to aliases so that $ENV_VARIABLE will correctly parse to the right value.

Just download the project or clone it from github then run the rake install task and it should be ready to use on your OS X terminal!

I am sure that no one else actually uses please, but I find it very useful. Since the please.yml file can be stored in any directory (based on environment variable), I have it stored in my Dropbox folder so that between computers I have the same list of aliases, automatically synchronized. If it were to ever get more popular, I could even see putting together a github repository or some other way for people to share their alias files. But maybe I need to make the code more robust before then.

 

Comments (View)

 

 

To my knowledge, Kraft has not done a campaign like this, but they should.

 

Comments (View)

 

 

A quick update to say that I put the bulk of the E.ggTimer code on Github as is. Mostly because it isn't doing much good just sitting there. Also, it will better coax me to make improvements and clean it up.

Check it out on Github

 

Comments (View)

 

 

Responsive Design
All the different layouts. 1) Large. 2) Medium Large (iPad Horizontal). 3) Medium Small (iPad Vertical) 4) Small (iPhone)


Continuing last years example I made another digital family Christmas card.

Last year I experimented with different HTML5 features including audio and canvas. That card was JavaScript heavy. This year I decided to try my hand at CSS and everyone's favorite buzz-work: Responsive Design. The result is a page with a lot of rectangles and images. Clicking (or tapping) each image will flip it over with CSS 3d transitions and show new content. The JavaScript used is minimal.

I had originally set out to use a framework or library like Twitter's Bootstrap. I found, however, that there was a certain amount of feature overkill for what I was trying to accomplish.

I also attempted to use CSS media queries to support Retina devices, but I failed miserably. Maybe next year?

I've made the code for both cards available at github. As usual, it only works in modern browsers, and even then only really in the webkit ones. I didn't want to take the time to make it compatible. Sorry.
2011
2012

 

Comments (View)

 

 

Just a story I did on Twitter. Nothing important.

Back in my day we had books. You had to pick them up and open them and turn each page by hand. David LeMieux (@lemieuxster) January 29, 2013

And if you wanted to know where something was you'd have to hope it was in the index or that there was even an index at all. David LeMieux (@lemieuxster) January 29, 2013

And from time to time certain books would be enchanted. Opening them without first saying an incantation would release all of Hell's demons. David LeMieux (@lemieuxster) January 29, 2013

Then you'd have to run to the warlock's house and ask him to help, but there was always a price. Your Uncle Jim gave his life for ours. David LeMieux (@lemieuxster) January 29, 2013

Anyway, you kids don't know how good you have it, what with these AR Contacts and cranial implants. David LeMieux (@lemieuxster) January 29, 2013

 

Comments (View)