The Well-Rounded Developer

The Well-Rounded Developer

Should the role of a front-end developer be limited to only client-side technologies? I have asked myself this question a lot lately. I come from a background where, as a web developer, I typically work across the following development stack to design and build a product:

  • Design. Graphic design, page layout to how a page flows responsively across devices
  • Client-side code. HTML, CSS and JavaScript
  • Data. Flat data files, RESTful web services, relational DBs, noSQL DBs, …
  • Server-side code – PHP, .NET, Ruby, Lisp, Node.js, Python, …

Recently, I have moved into a position where I am focused on fewer core languages and technologies. As a result, I find myself thinking about the value of becoming an expert in one area of the stack. Is there more value in being an expert than being a well-rounded developer?

The upside to becoming an expert in one subject is that there is more time to devote to exploring every nook and cranny of that subject’s subculture. After all, web development is an art form. We are artists who should know our medium and our style. However, it is this very focus that often makes us lose sight of the broader picture. Programming is not about a particular technology or where it falls into the stack. Fundamentally it is about solving problems. An understanding of when to execute code on the server and at what point it’s best handled it in the browser allows a developer to come up with the most efficient solution to the problem.

Jiro, in Jiro dreams of Sushi, states that “Once you decide on your occupation, you must immerse yourself in your work. You have to fall in love with your work. Never complain about your job. You must dedicate your life to mastering your skill. That’s the secret of success and is the key to being regarded honorably.” Jiro’s skill is sushi. He dedicated his life to coming up with and mastering the techniques of making the best sushi. In order to accomplish this goal, Jiro had to master the art of finding the right seafood vendors, picking the best fish (tuna, octopus, shrimp), preparing the fish, making the rice and creating an experience for his customers. If there was a problem with any part of the cycle, the sushi would be sub-par. So it is with development. A problem, often caused by lack of knowledge, in any layer of the stack can create fragile dependencies, inefficient results or worse…buggy code.

I have heard it said that new tech moves too quickly for well-rounded developers to keep up. This is true in the sense that no one developer has the time to become THE expert in every language, framework and platform that exists today. For a new developer, it can be overwhelming to look at the options that exist and wonder where to begin. However, if we take a step back, we are able to see that this pace of innovation is actually the fuel that drives the well-rounded developer. I say this for two reasons:

  1. The fundamentals of programming have not changed.
  2. The new frameworks and tools allow us to stand on the shoulders of giants.

Concepts such as object-oriented programming, data models and design fundamentals stay relatively stable over time. There are many different implementations of these principals and the principals themselves are expanded upon and refined over time, but much of the knowledge is transferable between languages and platforms. Differences are found mostly in syntax and philosophies. While syntax varies greatly among languages, the ones that tend to gain the most support are derivatives of earlier high-level languages such as Fortran and C. So, a lot of syntax knowledge is transferable as well. While the creator’s philosophy of a particular language or framework can vary, there are a finite number of general philosophies in existence and code design patterns often transcend philosophies. As Solomon said: “What has been will be again, what has been done will be done again; there is nothing new under the sun.”

Programmers that have been working at their craft for a while often say that development is much easier now than it ever was. They are getting at the idea that we do not have to mess around with as much low level stuff as we used to. 30 years ago, programmers had to write device level drivers just to connect to a database or manage a network connection. Given the same amount of time today, we are able to create more feature-rich, complex applications because of the work that has been done by those that have come before us. Frameworks in any context (server-side and client-end) continue to build on this infrastructure and will only speed the pace at which we can develop amazing products.

All of this is good in a general sense, but the real time-consuming part of becoming a well-rounded developer is spent in honing the details of one’s craft. It is difficult to decide which framework is best suited for a project and even more tedious to learn all the exceptions and caveats that come with a particular language or framework. Because of this, community is a vital component to a well-rounded developer’s workflow. Pick ecosystems that have good community support. Find the best framework to use for a project from the discoveries that others have made. Share what you learn when you develop for a platform with others. And above all, build new things.

Twitter API v1.1 Front-end Access

Twitter is retiring their v1 API in March of 2013. This means all future API integrations must use the v1.1 API which requires authentication on any request (read or write). This is pretty straightforward using a PHP OAuth library or any OAuth server side implementation, but what if you wanted to implement something client-side? This can be accomplished by using the Yahoo! Query Language (YQL) to do the heavy lifting for us.

A Twitter app is necessary to do any OAuth authentication. Go to https://dev.twitter.com/apps and create a new Twitter application. Once your application is created, click the “Create my access token” button to link this with your Twitter account. You will then have a Consumer Key, Consumer Secret, Access Token and Access Token Secret for this application that is associated with your Twitter account (see an example in the screenshot below). Make a note of these values.

keys

Next, create a text file that contains the keys from your application (leave the env line as it is).

Upload the text file to an accessible URL and go to the YQL console. Run the following query in the console replacing NAME and URL with whatever name you want to reference the stored data by and the url to the text file you just uploaded.

The result of this query will contain an <execute> node (ex. <execute>store://my.host.com/name</execute>). Make note of the value of this node.Your application’s OAuth keys are now stored in a database table that can be accessed from another YQL query. This is important because YQL also has community tables that allow for Twitter API requests. The following JavaScript (yes, some jQuery is used for simplifying the AJAX call) requests recent tweets from the @resource Twitter account and uses the stored keys for authentication. Just change the env value (line 14) to the the value of the <execute> node that you took note of earlier.

That’s pretty much all there is to making client-side Twitter API read requests using YQL to do the rest of the heavy lifting. A couple of things to keep in mind:

  1. The security on this is not great (it’s more security through obscurity). Anyone can use the env link to execute read requests, but they don’t directly have access to your keys. It’s always better to implement this API server side if you have access to do so.
  2. Both APIs rate limit the endpoint calls. YQL has a 2,000 calls per hour per IP limit to their public API. Here is an explanation of Twitter’s rate limits. Caching should be implemented to avoid hitting these limits.

Here is the Codepen Link for a working example.

This concept was adapted from Derek Gathright’s blog post.

SASS Ruby Extension to Check if File Exists

SASS Custom Functions
CSS is executed client-side and so it cannot check for the existence of an image, font or other asset file being referenced. However, since Sass is written in Ruby, it allows for server-side calls by extending Sass via custom functions. Here is a custom function to check for the existence of a file:

If this code is placed in a file named functions.rb, the Sass watch command would be:

So, why would you ever need to check for the existence of a file at Sass compile time? One place I found it useful (I’m sure there are other uses) was when eliminating duplication of internationalized CTA (call-to-action) images. Canadian (or British) English is similar to U.S. English in many ways, but there are some words that are a different between the two (favorite vs favourite for example). The following Sass mixin selects a CTA image from a folder based on the lang attribute set on the page. In the case of Canadian English, it will first check to see if the image exists in the en-ca folder. If not, it will fall back to using the image from the en-us folder. This avoids duplication of the English images that are the same in both Canadian and U.S. English. The benefit of this is:

  1. Fewer total assets, so they are easier to maintain
  2. The total asset payload is smaller (especially important if used in a mobile app)

Front-End Web Development

The state of front-end web development has changed significantly over the last couple of years. Perhaps it was the introduction of responsive design in early 2010, the release of a retina iPad and, shortly thereafter, the retina Macbook pro in mid-2012, or Adobe “killing” mobile flash in late 2011 that prompted the change.

A few years ago, a front-end developer title often defined the term “developer” rather loosely. HTML and CSS were often the only required languages for this role and are really considered to be content markup languages rather than true development languages (however you might choose to define that). A few years before that, we were building websites purely with HTML and images, using tables to implement our layouts. A lot has changed. If you are interested in learning more web history, check out Eric Meyer’s excellent podcast, The Web Behind.

frontend-code

Regardless of what actually prompted this recent shift, I believe there are (at least) two major reasons that the front-end developer role will continue to be significant for quite some time:

  1. CSS and image support has gotten much more powerful and complex.
  2. HTML/CSS/JavaScript can be used to build native cross-platform mobile apps (Phonegap, Appcelerator Titanium).

CSS3, Retina Images, and Bandwidth, Oh My!

The CSS3 spec added lots of very powerful new features. Things like rounded corners, shadows and gradients can be achieved easily in browsers that support CSS3. There are also more advanced features like CSS transforms and animations which require a bit more knowledge about things like keyframes and perspective. Specific browser prefixes must be applied for many of these new features in order to ensure backwards compatibility as the spec continues to evolve.

Of course, the downside to all of this is that CSS code has become hard to maintain. Fortunately, CSS pre-processors have been created to help make CSS code more maintainable and object-oriented (ish). Sass and LESS add features like functions, variables and mixins as well as code libraries (Sass has Compass). Sass does seem to be gaining in popularity for a number of reasons, but the point is that this is one more tool for a front-end developer to learn.

A hot topic in the front-end developer community at the moment is debating how to support images across different devices, resolutions, pixel densities and varying connection speeds. The increasing consumer use of retina-density displays and better internet access from smartphones requires developers to think about how to potentially support multiple sizes of higher quality images at lower file sizes. There are many solutions for supporting higher resolution images on retina displays. You could detect a retina display and serve up double resolution (@2x) images for those displays. This requires two versions of every image to be created which isn’t so bad. The problem is that a device like an iPhone has a retina display as does something like a Macbook Pro. The Macbook Pro could be connected via Ethernet to a fast connection and the iPhone may be on 4G now, but in seconds, it could be down to an edge connection as the user moves away from the nearest cell tower. This article does a good job of explaining the pitfalls of trying to measure or predict bandwidth at the CSS level to serve up different image sizes. So, there is some added complexity that comes with more mobile devices and retina displays.

In addition, any image, whether it’s targeted at a retina screen or a smartphone, should have as small a file size as possible. Tools like:

can do an amazing job of reducing file size while maintaining quality. Even with these tools, a great deal of manual effort is still required to make sure that the images maintain quality once compressed.

Mobile Apps

Because the three main “languages” in use on the presentation layer of the web (CSS, HTML, JavaScript) are so widely known, developers have come up with solutions for building mobile apps on all major platforms using these languages of the web.  A mobile app can be built completely in JavaScript (and HTML and CSS) and compiled with either the open source PhoneGap framework or Appcelerator Titanium for iOS, Android and a number of other mobile OS’s. This gives any front-end web developer the tools to build mobile apps without learning a new language. It sounds like a dream come true, but in reality, most apps that are conceived are complex in nature and require a framework (like Backbone.js) to organize the JavaScript code. With the maturity of these mobile app frameworks that use commonly-known web languages, the front-end developer role has expanded to be much larger than it once was.

Conclusion

These are very exciting times indeed for front-end devs. So much new technology is being released that the door is wide open for innovation. I’m just excited that we are no longer using table layouts.

IPA Episode 1: Responsive Web Design

IP Address is a little video blog that I’ll be doing from time to time. It will consist of my ramblings about web design and development and hopefully have some interviews in the future as well. I will also be trying a different IPA in each episode. This one is all about responsive web design. A few related links that are worth checking out as well:

P.S. I’m working on a brand new responsive design for this website. Check back soon to see it.

YouTube API Share Videos

YouTubeYou can do a lot of things with the YouTube API, but when it comes to private videos, some of the built-in functionality is lacking. I needed to automate sharing of a private video with a list of users once it had been uploaded via the API, but unfortunately, YouTube does not provide a call to do this. This sharing functionality is present in the YouTube admin interface, however, so with a little cURL magic we can automate this as well. Check out the code below for how to do this. I used some code from this phpfreaks forum post as a starting point to log in to YouTube. Note that you will have to set the username, password, cookie_jar_path, video id, and user list at the beginning of this script.

Designs Over the Years

As a new website design launches, I thought I would put together a little gallery of my website designs over the years. Unfortunately, I didn’t take a screenshot of every version and the wayback machine didn’t load all of the images from each, but this is what I could retrieve. I’ve just included the logo from some of the designs. Notice that the new design of the website is a departure from the typical green/grey/black color scheme that I have used in every other version of the site.

Old stevezeidner.com Website Designs

Languages

Lately, I’ve been on a kick of wanting to experience a broader set of languages, frameworks and programming techniques. I listened to an (epic?) episode of FLOSS Weekly with Kent Beck on Extreme Programming and have been thinking about going back to some of my textbook learning in college and applying it to real projects.

First off, I’m going through a Python book as I figure it is not too huge of a leap syntax-wise from PHP. Aside from a little bit of syntax difference, there are a few nuances conceptually (everything is an object, different data structures like tuples, etc…), but for the most part, it seems to be pretty straightforward so far coming from a PHP background.

However, I’ve been hearing a few rumblings lately about PHP gaining a little more traction as a respected language – Facebook after all uses it. In fact, an employee at Facebook has even been rewriting PHP from the ground up for speed. It sounds like it may finally be a compiled language which could help with performance issues.

Other platforms I would like to dive into include Ruby (and RoR) as well as going a little deeper with Javascript frameworks and some of the nuances between the toolkits/frameworks. I also like the idea of accountability that is a part of Kent Beck’s “Extreme Programming” style.

For now, I’m picking Python to use for my next personal project. Once I pick a project, I need you to keep me accountable to finish it.

HTML and CSS Starter Templates

Out of laziness, when building a website, I’ve often just started with one of the Dreamweaver basic template layouts – I’ll go in and delete a bunch of stuff and rework it to the way I wanted. This included copying and pasting code from websites I have built previously and rewriting the same sections of code with each new site. I was also using Dreamweaver as a code editor just because I started there. Dreamweaver is quite bloated however and if you are not using the WYSIWYG features, it is completely unnecessary. There are much better text editors out there already. I’ve currently switched to Notepad++ on the Windows side (what I use at work) and so far it has been working out quite nicely. I have put together a base CSS (2.1 and 3 valid) and HTML (5 spec valid and backwards compatible) template file with the structure I typically use for building a site. There are a few items in the CSS (like the comment block at the top) that are geared towards WordPress users, but those can be ignored or removed as necessary. Now, let’s see the code. First the HTML

Pretty basic, right? The only thing that might throw you off is the DOCTYPE. This is the way HTML5 does it – much simpler. Also, there is some Javascript included for backwards compatibility with IE.

Now, on to the CSS

A few things of note in the CSS. One is that at the top, I’m using a modified version of Eric Meyer’s CSS reset. I changed some of the spacing and indentation to make it a little more compact. I also removed the ‘content: none;’ from the ‘blockquote’ and ‘q’ resets so the stylesheet would validate with CSS3. A final modification I made was to the font size (from 100% to 62.5%). This resets the font base to 10px for easy em calculations (i.e. 1.4em is a 14pt font). The rest of the stylesheet should be mostly self explanatory.

So, what do you use as a starting point when building websites? What do you like about my templates? What don’t you like? What would you do differently?

Finally, last but not least, here is the zip file if you want an easy download: SZ’s Barebones HTML and CSS.

Update: I made some minor changes to the font placement in the CSS file. It didn’t quite work properly before. I’m now setting the font size to 62.5% in the body rather than in the reset. Font size can be defined in em’s in individual classes or ids.

The Tenants of Google

On This Week in Google: Episode 17, Leo suggested that Google may have a set of rules that they follow when building each of their products. Matt Cutts responded with a few of the fundamental tenants of Google. I have listed these below.

  1. Don’t be evil
  2. Organize the world’s data to make it useful
  3. Don’t trap user data – Eric Schmidt, Web 2.0, 2006
    • Be an advocate for users
    • Compete on merit (don’t give yourself an advantage – no proprietary APIs, etc…)
  4. Regarding products…
    • Go for a great product first, then figure out how to monetize
    • Don’t launch a “me-too” product – add some innovation to your product

I know a lot of people are very wary about Google especially as they grow into a larger and larger corporation. While they do seem to be reaching into more technology spaces, it is interesting to see how carefully they make their approach.

What is your take on Google and their level of “evil-ness” in the marketplace? How well do you think they follow the tenants outlined above? Are there more that should be added to this list?