I hereby decree
by David LeMieux
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.
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.
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.
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
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
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
For nearly as long as I've worked at Flite I've done more or less the same thing. Not just "writing code" but "writing code to do the same thing." It has been a fun challenge and actually resulted in some work I am very proud of. Recently, however, I was assigned a new thing and it has been delightfully freeing.
I've worked on different projects in the past, but my main focus on all of those projects has been the ad runtime platform at Flite. Now I am working on something more front-end related and the change of pace has done two things: 1) It has given me a chance to stretch different coder muscles and 2) Taking a step back from platform work, I've actually begun to get lots of creative ideas about the platform again. Previously I was feeling somewhat stuck in a loop.
The stresses are different. In the platform code, I have to constantly make sure I'm not making the file size (for a file served thousands of times a minute) too large. I also have to make sure it is robust enough to work anywhere without breaking ad or webpage functionality. Not having that constant worry has been liberating. In its place are new worries - like am I writing code compatible with existing patterns and not breaking user experience - but they are new and fresh and welcome.
For the one or two people who will read this: Flite is Hiring