by David LeMieux
Not feeling as on-the-pulse as I used to feel.
Sure I am getting older and my life has changed, but it can't just be that right?
I am never one to like "Sorry I haven't posted in a long time" excuse posts, but this isn't that so what is it?
In the words of Arnie Niekamp, "What's next?"
I have a lot more I could say about this, but I have been enjoying Apple Watch. For all the pros and cons here is the shortest summary I could come up with:
In the web advertising world everyone wants to know when and where an ad is being served. There are a number of ways to track this, but a common practice by many third-party ad tracking services is to give the ad creator or publisher a url to a transparent 1x1 gif that serves as a homing beacon of sorts. It loads in the background, you cannot see it, and it sends data to the server in the form of an HTTP request.
This method takes a URL to request and then data to be added to the request body (always a POST request). The idea is that this request is not canceled by user navigation and is more-or-less guaranteed to be made. This sounds delightful, from an ad or metrics perspective, but there are some caveats.
First, the data is sent as a POST, but not as form data. Instead it is included as part of the request body. This isn't a difficulty, but it means your server side code has to know how to parse this data and use it. There can be complication with this depending on what technology you are using. For example, certain Java servlet filters might try and access the body, but it can only be accessed once since it is an input stream.
Second, in case you considered using this with third-party tracking pixels, not every third-party tracker allows POST requests. This negates any usefulness and the feature almost entirely.
Finally, some browsers have a data limit of how much data, per page view, can be sent by the sendBeacon API. In my testing I have noticed that this only includes actual POST body data, so you can still send quite a lot on the query string if you want.
navigator.sendBeacon is not yet supported in every browser, but I think it will be a useful browser feature when it is, as long as one understands the limitations - which are likely to change or be different in each browser.
I have been thinking a lot lately about how to balance short term gains against long term gains when it comes to software development. I suspect I am not the first but what I struggle with is that much of what can be accomplished in the short term is not suitable for long term growth. Focusing too much on the long term can mean you miss short term opportunities and the feedback loop takes too long. You don't want to spend too much time on something that isn't going to help you or anyone else.
I do think the balance lies somewhere in that 1) It is important to understand the problem that needs to be solved in contrast to providing implementations details to any apparent problem without understanding it. 2) Setting up a good foundation, while not bullet proof, will get you a long way toward extensibility and being able to make quick wins later on. 3) Taking a tick-tock approach to short and long term goals (stability vs features, for example) allows teams to achieve both, but at the possible risk of extra context switching and thrashing.
While I am generally a fan of something akin to "agile development" I think that the idea of an Minimum Viable Product (MVP) can sometimes be detrimental if it becomes synonymous with ignoring quality along with features. In my opinion we'd all be able to make the most rock solid set of one or two features needed for a product instead of three or four buggy features.
I am also a firm believer in living within constraints. It isn't always easy and can even be humbling (saying no to a client because your product is lacking something the want can be hard to do) it can also be a catalyst for change while helping to keep things coherent in the mean time. Short term gains should follow patterns and be built on a solid foundation. Long term gains should be the rebuilding or shoring up of that foundation.
I was recently contacted about my interest in paying for pictures of the new Star Wars movie script. I was doubtful that there was any truth in the claims, so I asked for a sample. When I received it I couldn't believe my eyes. Here it is.
Han never shot first.
Needless to say I am now trying to raise the rest of the money needed so that I can get this exclusive before BuzzFeed or anyone else does. Here's to hoping it works out.
Raisins? More like Rad-sins, amirite?
I think I should pitch this to the California Raisin Marketing Board.
Here are some things I've found interesting lately.
There is a lot of new data generated every moment. Most of which isn't actually that interesting, at least not on its own. As the world, or at least parts of the world, continues to be more connected the constant flow of this new information drives innovation in terms of how to organize and consume or even ignore it. How we digest this content, create it, and the tools that help us do both are ever changing and there is a new pattern emerging that points to a different style of data management.
Compartmentalization has benefits, but there aren't great jumping off points.
In college I had used bookmarks to keep track of all the different sites I wanted to check on a regular basis. I would open the pages one by one (and soon after, tab by tab) in a browser and read through the latest articles. Some friends had blogs, those were in the list. Each item was an individual link going to a new compartment of information.
At some point Firefox introduced Live Bookmarks - A bookmark folder that pointed at a RSS/Atom/XML feed and would just show the latest articles as though they were regular bookmarks. It was about this time that the flow changed. Instead of individual, unique jumping off points there was a place to go to see part of the stream and start from there. Then came Google Reader. Reader allowed users to follow any number of feeds and lists and served as a central jumping off point for discovering and following all sorts of data.
Unfortunately Google sunset Reader. There are other services that do nearly identically the same thing, but they aren't quite the same. Because of this (and, I must pause for a moment to mention that Facebook, Twitter, and other popular apps have changed the landscape of how and where people put new information) we have returned to what feels like the bookmarks of before. While there are aggregation services still around, most people turn on their phone then find the app they want to open and start there. The home screen in the new bookmarks bar.
Technology has a constant drumbeat that makes it march ever forward and now is no exception. There are already signs that things are changing. Flipboard, already several years old, is like a content aggregator but also creates a unique layout - making the new content even easier to digest. I am not sure, however, that this isn't just a stopgap. That maybe Flipboard is a bit too Reader-esque and not enough of the thing of the future. An interesting article titled The End of Apps As We Know Them points to that the way we use our apps is changing. We are moving away from the bookmark-style launch screens and more toward interactive notifications and in-the-moment, contextual information processing. Google Now is the current best example of this - showing you information at the time you need it. The newest part of that idea, though, is the shift away from content consumption ("Your flight has been delayed") to content creation and data entry.
Auto updating/formatting of content in the moment.
Facebook, Twitter, and other platforms allow for content creation and sharing in many diverse and easy to use ways and these services will continue to be a part of the new flow. Added to them (or, perhaps, as part of them) will be new kinds of content and data entry. Wearables will allow collection of personal activity data. Phones and beacon/checkpoint technology will give better locational awareness. These ideas certainly aren't new, but the emerging patterns of design and interaction seem to suggest they will become more prominent than they are now. With all this data, though, who will take the time to organize it and make it presentable? The answer is that the computers will do it for us. We can already see how some content streams, like Facebook's, auto filter and layout the things we post on our behalf. Newer technologies like The Grid even claim to be able to do it for freeform, personal content so that a user doesn't even have to think about how new content fits in to their website.
Instead of templates, The Grid talks about applying layout filters. This combination of content filters applied to a layout filter points to a world in which you could just go about your life, maybe take some pictures and then very easily manage who sees what and when and where but with none of the current friction in doing do. It also means that we may be able to move away from some of the walled gardens of the day, but it could also mean the opposite. This kind of easy flow sometimes only works when every part is from the same system.
Handoff and Context switching
Another part of this will be removing the need to think about which device you are using. There is already evidence that this will be a solved problem soon. Apple's own continuity product is a step in this direction.
For the first time in a long time I had the thought that what I currently do as a living, web software engineering, might be taken over by robots. Sure, someone has to tell the robots what to do, but for how long? How long until the steam of data, the flow of information, organizes itself? How many people have personal blog compared to how many users use Facebook? I'm sure some Facebook users would love to customize the look and feel of their feed, but mostly people are content that the feed exists at all. I also wouldn't want to even suggest that a machine could learn "what is design" or "what is art" but they are certainly going to try.
Ads are probably over
In Peak Ads the data suggests that people care less and less about traditional advertising and that advertisers are going to need to find different ways of presenting their sales pitches. Things like native advertising figure in to this. I am not so sure that will last. The Internet is going to move to a non-ad-supported model and it is going to be interesting to watch. I have no idea how any of this new flow of data will be monetized, but I hope it is with people paying money or by the system becoming so cheap that it can run itself. Or become a utility. Who knows. I don't think Internet advertising will be around in a recognizable form, though. That could just be wishful thinking.
I am not an expert in any of this. In fact, a real expert may be reading this and thinking "What a naive, uninformed bunch of grammatically incorrect nonsense." I still think something similar is on the horizon and I am eager to see what happens.
I've been using Yosemite at home and at work for the last bit and have to say I love it more than I probably ought to do. Something about it is in tune with how I think I feel things are supposed to work. Not much has changed, but it just feels more "right." From the design to the small functional differences it is better is almost every way.
The only thing that is a bother for the moment is the new fullscreen button that replaced the old (+) button. Now you know to know to hit "Option+" for it to act like it did before and I use that all the time.
The green one now defaults "Full Screen"
I am a fan of art generated by code. I even gave it a try a little bit. There is a lot that can be discussed about the topic as a whole, but I want to only take a moment and spotlight a project that I found recently through browsing my Github feed.
Jenn Schiffer (who's posts on Medium, by the way, have caused a sufficient amount of confusion at work to make me an instant fan) is dissecting different artists and art styles and how one might replicate them using code.
Example step in the process
This includes first figuring out the patterns and replicable parts of art and then trying to reproduce them procedurally with code. What is interesting to me about the process is that this method almost completely ignores the question "What is art?" and instead says "Here is some art, lets break down the parts. How can I make a similar art with similar parts?" Which itself is an indirect answer to the first question, if even unintentionally.
It sort of reminds me of The Artist is Present Game where you relive the experience of the performance of the same name, only digitally. It isn't the same as the original, but it becomes its own thing by being an approximate replica in a different medium.
I don't mean to draw conclusions from things that don't need them. I enjoy art and code and art made from code. Maybe someday someone will create an interpreter that runs code based on art.
I am a fan of Coins but only recently did I discover this album of Beastie Boys/Daft Punk mashup tracks. I have listened to it a lot over the last few weeks and I have to say that each track is better than the last. The only exception, for me, is the _Disco Breakin track which, while still a fun listen, doesn't follow the crescendo of increasing quality and instead takes us back to around _Pass the Mic. That could just be me, though.
Bonus: There is also a new CVS Bangers
I went to Eastern Washington University for a year between 2000 and 2001. While there I had the opportunity to be in the Marching Band, Wind Ensemble and Pep Band as third trombone. We would be required (and also paid) to play at sporting events. Because of this we would often have need to coordinate with the cheer team because they wanted to be sure to have time to do their cheers and they also wanted to know when we would play different songs because they had worked out little dance routines that accompanied them.
The thing is, though, we didn't really get along with the cheer squad. I am not exactly sure why, but there was some enmity there that perhaps had persisted through time. I was a freshman and so I bought in to the culture of animosity, and that is a topic for another day. It is enough to say that we felt occasionally inspired to upset the cheer team.
We would play this song at the request of the cheer team:
Normally when a band from an opposing school would play this song we would shout over the top of the "Go Team Go" part and instead shout "High School Band" in a mocking tone. We felt we were above this simple melodic rally cry. When the cheer team would insist we perform the tune we were always reluctant to comply. We would use this an opportunity to upset the cheer team.
Since the cheer team had created a little routine to go with the song, and since it was loop-able (as is the song) we would purposefully put extra measures at different parts of the song, adding extra beats here and there, throwing off the rhythm of their dance. They would never quite figure out what had gone wrong and we wouldn't do it frequently enough to have it be common.
A Dead Colors fan emailed me a request:
Could you, by any chance, make a color palette containing all of the dead colors for PhotoShop?
I may have had to go through the hours of pain of making one myself before receiving this message, but it still makes me so happy that you responded.
There is a not-too-recent design trend that websites are designed to not scroll but instead animate or change the information on the screen as the user uses the scroll wheel on a mouse or the scroll bar. A limited example of this can been seen on Dropbox's Carousel site.
As you can see in the video, as the use scrolls downward some animations play and at a certain point the page stops scrolling entirely and only the animations continue, even though the page is still scrollable. There are other, more extreme examples of this as well. Some sites seem to handle this new take on information disclosure in a way that makes sense but many miss the mark and become confusing.
This breaks usability. The animations are visually interesting and the end result (displaying more content) is essentially the same, but there is no longer a 1:1 mapping of the actions a user takes through the interface or the input device to what is happening on the screen. The timeline, for lack of a better term, becomes arbitrary. The different portions of content are harder to track because they lose their sense of placement on the page. If a user is using touch device to scroll then that relationship can be further harmed. (Though in the case of carousel, the site removes this and scrolls as you'd expect).
Timeline may be the right term to use inasmuch as the design of the pages treats the scrollbar like a scrubber going through the time of some animation or even a video, even though the presentation is interactive. If the designer wanted to present the user with a timeline of information then she/he should stick to a more readily identifiable mechanism for the same.
It can also be tempting to misuse animation. Animation really isn't the issue, though. The issue is the disconnect between the scroll action and what you see visually on the page in terms of mapping movement. You wouldn't turn the page of a book and have it only change the picture on the page you are on. That is a bad comparison, but the idea is the same.
Let pages scroll, otherwise use a different navigation mechanism and make it obvious.
var random = Math.random();
I am at an interesting point of my career and the only name I seem to be able to give to it is indifference. In the last six years I have been at Flite the world of software development has changed and not even just once. I do not expect it will slow down either, but my willingness and interest in keeping up has certainly waned.
Recently I have been surveying the job landscape and technologies that didn't even exist (or were definitely not mainstream) three years ago are now listed on almost every job description. There isn't anything wrong with that necessarily but I haven't personally had the time nor inclination to try and do anything with those new technologies but if I wanted to go get a new job I am now expected to know about them.
What makes things seemingly worse is that, in my casual observance of the landscape, we seem to be loosing any subtlety and compromise and instead everything turns in to a Holy War. Everybody is looking for people who are on the same side. Which platform do you use? Which text editor? Which project management methodology? (Which phone platform? Which OS? and on and on) The big players like Google and Facebook and Twitter then throw their weight in the mix. Sometime I think it is because that, as large companies, they don't actually have enough work to do and so spend their time dreaming up their own ideal vision of how things should work. And why shouldn't they? I am still not convinced that their ways should be my ways but it looks like there is no avoiding making a choice.
Take bower for example. It is neat and works as it says on the tin, but I cannot figure out how or why I'd use it in a production environment. If I need to download dependencies I can do that and package them. I am not about to change my deployment infrastructure just because a new tool exists to replace something I maybe do one or twice a month, tops. That said, maybe I am missing the bigger picture. I guess the point is that right now I don't care.
I will own up to the fact that I am falling behind on my own school of thought that if you like something you will do it on your own and gain experience through trial and error. It isn't like I've been sitting at work doing nothing. We don't always have the opportunity to adopt new technologies at the drop of a hat and if we did we might not ever get anything done. I could try harder to stay current.
This complaint is not original nor unique. I feel a little bit like an inflexible curmudgeon by admitting these reservations, but what else can I do?
I am just getting tired of feeling like I need to have an opinion about everything. I am much more comfortable saying that I will use the best tool for the job as I find them, but if "the industry" is going one way I guess I also don't want to be on the side that gets left behind.
Update: This video is great.
Scratch it away!
Its been like eight years since I updated my personal portfolio but I'm glad I did it.
Check it out.
I was informed today that E.ggtimer gets too much traffic to remain on my original hosting plan which is both exciting and scary. In response, my web hosting provider shut it down without warning. I was able to get it set up on Amazon's services using EC2 - so hopefully it will run smoothly and now allow me some freedom in terms of feature enhancement.
E.ggTimer was down for several hours today. Sorry for the inconvenience.
I hereby decree that while the world has moved on from feeds and blogs, or at least appears to have done, I feel like what we've lost isn't completely replaced by what we've gained. That said, I communicate more than I did before, in spite of the connections having less meaning.
I've made some minor tweaks to please. Now inputs use readline instead of stdin so that command line tab completion can work. Second, if you mistype an alias it will try and show you something that might match. This second part is super fleshed out, but if you leave out a work or a character it should at least show you something.
Halloween is my favorite holiday. Other holidays are also great, but Halloween is the one time a year I have an excuse to make something that would otherwise seem unnecessary. Usually I decorate my car for the annual Trunk or Treat. This year, however, my son wanted to dress as a robot with "lights and working gears." And so I felt compelled to grant his request.
Full costume, sans wearer
My wife and I decided to team up. I did most of the robot body and electronics and she did the other decorating and made some cool pants and other accessories.
The front ended up having two sets of LED lights. One set blinked at an interval, the other chased back and forth. A third set of lights, in the head/helmet, ran in a circle.
Two sets of lights and some decoration
Switch controlling the lights
A switch on the left side of the costume, reachable by my son, controlled the lights in the body.
The body and head were made with carboard boxes that we taped up and painted silver. I glued an extra poster-board panel on the front to give it a cleaner looking finish. On the bottom of the front panel were spinning gears. I made those out of high-density foam and connected them to a gear box and electric motor that were inside the box. I cut the gears from a template but since I don't have a band saw I cut them by hand and therefor they were quite inaccurate and would jam frequently. Fortunately since they were foam, any fingers or other things that got trapped in them were safe from harm.
Push button switch
The gears were switched on by a push button on the right side that my son could use whenever he wanted to add some flourish to his costume. While the lights could stay on as long as they were turned on, I made the gears operate with a push button that had to be held so that they wouldn't run all the time, draining the batteries. Also, the motor and gear box were kind of loud.
The wires were all just on the inside of the box.
Wires, taped in.
In the end, my son loved the costume and everyone we met while trick-or-treating seemed to enjoy it as well. Many houses we went to even claimed to be giving him extra candy just because the costume was so great.
There was a costume contest, but he lost to some very well made life-sized Star Wars Lego mini-figs (sorry, I don't have a picture.)
In High School a few friends and I had this idea that the local marching bands, which competed in marching competitions, should also have a friendly flag football game. Instead of asking the schools for permission we organized it ourselves and put homemade signs up sheets in the other schools' music rooms asking for band kids to sign up and contact us. We put our own names and contact information, mine on top.
We may have used some copy that didn't sit well with school faculty who found out. Something like "get revenge" or "beat down your opponent." The schools, not wanting any liability, put an end to it. During Wind Ensemble one morning in front of the whole class our music director called the three of us out by name and asked why we would even do such a thing. In that moment, caught off guard, I failed myself. I shrank. I didn't respond. I pointed to the other guys and essentially threw one of them under the bus.
I am ashamed. I was a coward.
I think about this event often. I am still friends with one but the other I haven't ever talked to since.
Sometimes when I think about what happened I can't decide if I've gotten any better at taking responsibility for my actions, especially in public settings. Had the director pulled us aside privately I may have done better, but in front of my peers I did something terrible. I lied and lost a friend.
CSS is a powerful language used to describe how a webpage should look. It has come a long way over the years and can be used to create seemingly limitless design. Except for when it can't.
I am not great at coding with CSS. I will admit right here that while I have an understanding of the language and the way it should work, I couldn't get by without having to look up every property on the web. I feel like I must not be approaching web design in the right way because I look at all the wonderfully designed websites in the world and it becomes apparent to me that CSS can do a lot and is used to great effect. Whenever I try to use it I bumble around and ultimately end up in a situation where nothing seems to work.
For example: vertical centering. I know there are ways to accomplish it but it always seems like I am implementing a work around and not letting the language do its thing. Why can't
vertical-align: middlejust work?
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.
I hereby decree has successfully migrated to better versions of core technology.
Inspired by the current NSA Scandal
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.
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?
var item = document.getElementById("theItemIWant");
$('#myDiv').show().addClass('foo').append("Hello"); //And so on
$('#myDiv').width() //Returns a number
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: _
> please do something -input 'foo'