August 28th, 2012 by Todd Anderson
TXJS: How I Found a Fresh Perspective in the Heart of Texas
TXJS was a dual-track event, so conference-goers had to choose their talks wisely. Fortunately, the recordings will be made available online at some point. The talks I was fortunate enough to see did not disappoint. Though I picked up some tidbits about the language here and there, the real take-away from the event was a fresh perspective on developing. I will outline three rules I plan on making habit of remembering:
I am a huge advocate for testing and analysis in development. Loosely tied to that is my desire for refining the build and deployment process for projects. My ultimate goal as a developer is to deliver a product that provides the best experience to the user under the given environment. I have been pursuing that goal by writing unit tests, vetting and (sometimes) writing plugins for my IDE and creating proper build dependencies and deployment scripts. In focusing on this, my comfort level in testing the experience of a deployed application in its natural environment has plateaued.
Part of this may be due to the nature of every day use of a browser, but mostly it is because of laziness and a ”good-enough” mentality. I am quite familiar with ‘WebKit Inspector’, as I use it every time I test in development and the staging-ready build, yet I have stuck to using Safari as the browser for this.I have a problem with tabs and cache when it comes to my everyday browser. By “problem”, I mean I am a hoarder. By “everyday browser”, I mean the one I check email, rss feeds, click links and (leave) open tabs in: Chrome. I have literally dozens of tabs going at a time. It is a problem. I’ll admit it. What is a bigger problem is that it was keeping me from the wonderful WebKit Inspector that Chrome provides, all because I didn’t want to clear my cache and ruin my set up.
This is where my time at TXJS started to impact my thinking. In Madj Taby‘s talk, Tools and Techniques for Faster Development, he presented useful tips and tricks in using the WebKit Inspector provided from the Google Chrome team. Taking and expanding on topics he discussed in Modern Web Development: Part 1, he showed some key features I knew I could just not live without in my testing from that moment forward, mainly the settings (settings for your inspector, can you believe it?!), more profiling options, event handler listing and expanded memory graphing.
From this talk, I realized that I should be engaging with the Inspector more. I run things through WebPageTest (which I think uses PageSpeed) and various browser plugins like Dom Monster and YSlow, but I am not engaged with the result – only re-active. I should be testing and experimenting more in the same environment that the end product will be interacted with while I am interacting with it.
Chrome Canary is now my interactive development and pre-staging deployment test browser and I am happy about seeing the light to upgrade.
Madj Taby’s talk offered some clarity for me on how I can be testing smarter, taking advantage of tools available to me to be a better developer.
Experiment & and Challenge Current Implementations
Far too often, I find myself implementing the same solution for what appears to be the same problem again and again. While there is nothing technically wrong with that approach, as long as it is tested properly and known to be a valid solution, I might be missing out on discovering an alternate path which will provide the same desired result. Even if the new path is not as straightforward, it has the potential to get me thinking in new ways about a subject I thought I had mastered..
Alex Russel‘s talk, Overconstrained: the Secret Lives of Rectangles, reminded me of that fact. One of his projects, Cassowary JS, addresses constraint-based layout for DOM elements. The methodology used in addressing the issue is a bit more involved than that, but the end result is a toolkit used to assign constraints to elements whose layout will be updated at runtime.
[NOTE: The wording in the preface to this section, in as far as weighing the validity of a new experimental path, should not be directly applied to Alex's work demonstrated. Anything I mention in this section is not intended to belie his work- it was his talk that made me realize my own short-coming in experimenting more with solutions. It's probably the talk I spoke to others most about afterward.]
The title of this section is not meant to sound frivolous. In fact, the talk that drove this point home to me involved highly technical material, but it was presented in a playful manner by Heather Arthur in her talk, Machine Learning for JS Hackers, on a subject that culminated in a project that had me and many others in the room laughing along – kittydar: face detection for cats.
The talk was actually more about machine learning and perception, yet the underlying tone (at least how I perceived it) was to follow your interests and experiment. “Have fun!” Arthur is not hired to write detection scripts for social networks to send Growl notifications on incoming cat picture uploads – at least as far as I am aware. The underlying message of the talk was in machine learning, from which experimentation and exciting projects arise. The talk made me realize that sometimes diving into a subject and experimenting is meant for your own enjoyment; it doesn’t always have to tie back to some body of work.
Its great that I have found a method of working that is comfortable for me, but I shouldn’t stop experimenting and evaluating other methods and procedures that can help me find a solution or just having a laugh. Sometimes it takes being immersed in the intellect of others to light that fire. Thanks to Alex Sexton, Rebecca Murphy, the crew and sponsors for putting on a great event.