Newer posts are loading.
You are at the newest post.
Click here to check if anything new just came in.

April 01 2011

17:33

Firefox 4: A Developer’s Perspective


Right on the heels of Internet Explorer 9 arrives the much vaunted, latest iteration of Firefox 4. The release has been a success so far, with over 7 million downloads in the first 24 hours and over 40 million till date. Today, I’d like to give you a quick overview of the changes from a developer’s perspective — I’ll be skipping the new UI and the other whizbang features.


More HTML5

Tutorial Image

A new rendering engine, Gecko 2.0, is under Firefox 4′s hood.

A new rendering engine, Gecko 2.0, is under Firefox 4′s hood. For the most part, as expected, it offers great support for standards-oriented web development. Also at play is a brand new HTML5 parser that defines how your HTML code is turned into a web page.

As a result, you get improved performance, from innerHTML calls specially, the ability to include SVG inline in your code and overall stability and responsiveness due the parsing algorithm being run on its own processor.

More improvements from a HTML5 development standpoint are the more mature support provided for HTML5 forms and the Audio API. Support for the newer markup elements and attributes will significantly decrease the JavaScript code you’ll have to write to provide equivalent functionality. Think easier validation — your form elements will require zero JavaScript to glue the validation rules to it.


WebGL

Tutorial Image

WebGL is a standard that is based on OpenGL ES that lets you perform 3D rendering on the web.

WebGL support has been pretty nascent in previous versions of Firefox — only the nightly test builds featured support for the technology. Firefox 4 ships with full support for the platform.

If you’re wondering, WebGL is a standard that is based on OpenGL ES that lets you perform 3D rendering and other assorted manipulation through the canvas element. The API itself is more low level than you’d exect providing you with enormous flexibility and power. If something can be done on a desktop, you can do it on the web too!


Hardware Acceleration

Tutorial Image

We reduce the workload on our general purposes CPUs by letting much more parallel, and capable, GPUs handle specific computations.

Hardware acceleration is offloading tasks that are typically handled by the software to the hardware wherever possible. In our scenario, we reduce the workload on our general purposes CPUs by letting much more parallel, and capable, GPUs handle specific computations, thus eking out better performance. Both the task of rendering the page content and then compositing it are accelerated though different APIs are used on different platforms.

On Windows, Direct2D is used for content acceleration, including canvas manipulations and drawing, while Direct3D is used for compositing acceleration. On OS X, Quartz handles the former while the much more open OpenGL takes care of the latter.


JägerMonkey JavaScript Engine

Tutorial Image

JägerMonkey is an advanced, optimized version of TraceMonkey, the JS engine in Firefox 3.6

In accordance with developer expectations, Firefox boasts a newish JavaScript engine under the hood — JägerMonkey. An enhanced version of TraceMonkey (the JS engine in Firefox 3.6), JägerMonkey adds many more optimizations to the mix resulting in startling improvements in performance.

Newer and cleverer optimizations like a per-method JIT approach performs more aggressive native compilations resulting in performance that’s a lot better than the competition. To give you an example, Firefox scores roughly six times better in the V8 benchmark and thrice as fast in the SunSpider benchmarks compared to Firefox 3.6.

Overall, JägerMonkey has brought back Firefox in the race for supreme JavaScript performance.


CSS Transitions and More

Tutorial Image

Thanks to heskinradiophonic

Firefox finally supports CSS3 transitions and transformations.

One of the notable additions for a front end developer is extensive support for CSS3 transitions. While the other browsers have boasted CSS3 transitions for a long time now, Firefox has been sorely lacking. The latest version provides a nearly complete implementation of the specification.

CSS transitions provide a pure-CSS method to animate changes between CSS properties. Transformations like scaling, rotating and skewing are on tap for you too! You can even use these transformation within transitions to create nifty effects. Remeber those jQuery snippets you used to fade items and colors, in and out? For our intents and purposes, they’re pretty much redundant — a few lines of CSS is all it takes now.

The newer features include:

  • Support for touch properties.
  • Addition of -moz-any to group together structurally relevant selectors.
  • Computed values through -moz-calc allowing you to define values through mathematical expressions.

Even though it has taken the Mozilla team a while, the mere action of added support makes it easier for web developer to embrace these new technologies.


WebM

Tutorial Image

Firefox now ships with WebM support greatly boosting both its ability to consume video content on the web and WebM’s market share.

Even though developer nightly builds have been able to play the format for a couple of months now, this is the first official release to provide support for the format.

If this topic makes your head a little fuzzy, I suggest reading my earlier article on video codecs on the web where you can find further information on this topic. Suffice to say that by adding WebM support, Mozilla has strengthened its standards based idealogy and simplified life for its users in a single move.


IndexedDB

IndexedDB saves data as JSON formatted documents.

IndexedDB is Mozilla taking a radical, more usable route compared to other browsers by opting to go for the NoSQL approach. Remember that most other browsers use the Web SQL API wherein developers write SQL to obtain information stored in SQLite databases.

IndexedDB saves data as JSON formatted documents and lets you access the information it holds through a simpler, non-SQL API. The end result? Much easier syntax and a more standardized API that insulates you from the nuances of the implementation while still providing you with enormous flexibility.


Web Console

Tutorial Image

While it won’t replace Firebug, the new Web Console is incredibly handy.

The new Web Console replaces the Error Console from previous versions. While it won’t replace some of the advanced tools like Firebug, it comes eminently handy when you’re poking through the innards of a site or an application.

The console can be opened with Ctrl+Shift+K [Cmd for the fruity hipsters] and comes bundled with:

  • a command line JavaScript interpreter that lets you execute JavaScript in real time.
  • a logging mechanism that logs CSS and JavaScript errors. Network requests are logged too letting you access information about the request. Headers, responses, everything’s game.
  • an object inspector to examine any JavaScript object that resides in the browser’s memory.

Better Typography

Tutorial Image

Support for OpenType now lets you play around with more advanced settings like kerning.

You can now use OpenType, a open font format, giving you access to a much more varied palette — you’re no longer limited to web safe fonts.

While it may sound boring, support for OpenType ushers in a slew of features. You’re able to modify kerning, ligatures and get automatic fractions among many others.

One more point to make note of is that if your site is non-English, the new Firefox engine renders your content without any hitches or visual hangups. And with the exponential rise in non-English web pages, this features helps both the developers and the end users.


That’s a Wrap

The newest iteration of Firefox is quite the leap over the previous generation with a number of additions and improvements aimed at developers and designers. JavaScript junkies too have been taken care of by the improved performance courtesy of the new engine, better HTML5 and CSS3 support as well as a much more robust set of tools.

So what do you think about Firefox 4? Love it? Hate it? Let us know in the comments and thank you so much for reading!

March 22 2011

16:38

Why Cloud9 Deserves your Attention


IDEs are a pretty divisive topic among developers – and rightly so. We’re are creatures of habit, creating our entire workflow around the tools we use.

Today, I’d like to talk a bit about Cloud9, the latest entry into this saturated market. If you’ve cemented your feet into your favorite code editor, I’m here to review a few points that I think that may just change your mind. In fact, this isn’t like any editor you’ve ever used before.


What’s Cloud9?

Cloud9 is a browser based IDE. It’s a new product from Ajax.org that aspires to be the premium online development environment for JavaScript developers. As their developers put it, it’s:

The JavaScript IDE for Javascripters by Javascripters.

Cloud9 is written with JavaScript, and JavaScript alone. Yes, I mean both the back and frontends. Node.JS powers the server side part of the platform, if you’re curious, making it self hosting, on some level.

You might be wondering what makes it so special; here are the cliffnotes version of the platform. But before we move forward, a little history.


The Cloud and IDEs

A cloud based IDE has been on everyone’s minds since the concept of asynchronous web applications started taking a hold among developers though I’m pretty sure the idea itself predates the modern web.

Having access to your perfect work environment regardless of where you are is a boon for modern developers and is pretty much on everyone’s wishlist. Imagine being able to fix a simple, yet show stopping bug right from your holiday netbook just as you’re about to board a flight. Flawed, for the obvious reasons, but also perfect.

And let’s face it, minimal code editors have been online in one form or the other for quite some time now. But they’ve been just that — code editors, not IDEs. If you’re pondering on the difference here, I typically consider an IDE to be a code editor with at least debugging support thrown in.

Mozilla’s SkyWriter project, initially called Bespin, was essentially the first, well executed foray into this arena. In that sense, the Cloud9 platform isn’t really new — it has existed under a different umbrella in different stages of genesis for a while now. The current Cloud9 platform is an amalgamation of Skywriter and Ajax.org’s own Ace editor.


What Took so Long?

A number of reasons really.

  • Performance: First up, there’s the issue of performance. The JavaScript engines of yesteryear were severely gimped. And replicating a modern UI requires oodles of power that just wasn’t available.
  • Technology: While AJAX makes for smooth experiences, it still requires a bunch of back and forth between the browser and the server, most of which has to be done manually.

Fortunately, the recent years have seen exponential increase in the performance of JavaScript engines while the introduction of HTML5′s WebSockets make real time applications incredibly easy to make. Well, not incredibly easy, but easier when compared to replicating it with mere AJAX. Libraries like socket.io are a massive help as well.

And with those tidbits of information out of the way, let’s take a look at why I think you’d do well to give Cloud9 a look.


#1 – It’s Open Source

Tutorial Image

That’s right, you didn’t read it wrong. The source code to the current version is completely open source.

If you’re the kind who learns primarily by looking at code written by others or merely wants to poke around to get a feel for the codebase, you can do it! And trust me, you can learn a lot when perusing their code. There’s some pretty nifty code inside!


#2 – Hosted or Local – It’s your Choice

Use any machine to log into your account and boom!, you have the development environment of your choice with zero hassle.

You’re probably wondering what I mean here. Let me elaborate.

Ajax.org runs a hosted, development as a service version over at c9.io. If you’re the kind of person who’s constantly on the move and would like the flexibility of a cloud solution, this is the answer for you. Use any machine to log into your account and boom: you have the development environment of your choice with zero hassle.

On the other hand, if you’re unsure about the entire cloud situation and would like to run a private cloud or more traditionally, just use it as a standalone browser based IDE. Remember how the code is completely open source? There’s nothing stopping you from doing any of the options listed above. Set up a private cloud for your colleagues and code away!


#3 – The Pricing is Great

Tutorial Image

Open source projects get to use it for free!

The hosted version of Cloud9 follows Github’s pricing model.

If a project is free and open source, you get to use Cloud9 for free — there are no limitations whatsoever. Your project will be universally findable and users can fork over your code if they want.

If you’re working on a commercial project or would otherwise like to keep your projects private, however, you’ll need to opt for one of the paid plans starting at $15 a month.

Of course, all of this applies only if you want to use the cloud hosted version. You’re more than welcome to setup Cloud9 locally and enjoy the IDE without having to pay a cent.


#4 – Usable and Slick

Many of the IDEs I’ve used over the years have been pretty… eccentric. No, Textmate doesn’t count! It’s merely a text editor. Most IDEs on the Windows platform tend to be rather eccentric. They can be lumbering beasts with a myriad of panels and toolbars with inscrutable icons and such. Needless to say, most IDEs [shoo, Apple users] are neither usable nor good looking.

Tutorial Image

If, by some off chance, a usable IDE does come out, it almost always is going to be ugly as sin. Call me shallow but I’m going to be looking at an IDE all day, every day. I demand some eye candy, goshdarnit!

Tutorial Image

Cloud9 is definitely an fresh breath of air for me. The UI is minimalist, polished and utterly usable. Subtle gradients, useful iconography and an almost McGyver need to unclutter things are everywhere.


#5 – Extensible and Customizable

Thanks to Skywriter’s influence, Cloud9 features a very simple yet powerful plugin system.

Extensibility and customizability are very important facets of the IDE picture. Often, you’re going to include plugins or extensions to either boost the functionalities an IDE provides or to merely tweak the experience to your liking. Almost all of us do this, to differing extents. Just ask Jeffrey about his .vimrc file!

Thanks to Skywriter’s influence, Cloud9 features a very simple yet powerful plugin system. Are you missing support for your favorite language? Want to modify the interface to better suit your workflow? You can, and should, extend the IDE through the plugin system.


#6 — Git Integration

Tutorial Image

Cloud9 links to Github for version control and integrates completely with the platform.

Revision control is an important facet of modern development paradigms and Cloud9 accounts for this right out of the box.

Cloud9 links to Github for version control and integrates completely with the platform. It’s amazingly simple to edit and update your repos, all from within the IDE. Jeffrey’s recent premium tutorial is something you should check out if you’re even marginally interested in this topic.


#7 — Makes Node.JS Development Easier

Tutorial Image

Cloud9 is the only IDE for Node.JS.

Node.JS is one of the rising stars of the web development industry. It enables JavaScript to be used end to end thus simplifying the entire workflow.

So far, Node.JS support has been nascent, even in desktop IDEs, not to speak of testing or debugging. Cloud9 completely changes the picture. It’s essentially the only option if you’re serious about Node.JS development and need a robust editor to match. You’re able to play around to your heart’s content. A unique app URL to play around at and integrated debugging tools are some highlights if Node.JS development are your primary concern.


#8 — Extensive Language and Debugging Support

Tutorial Image

Cloud9 supports all the most popular programming languages.

From all my talk about JavaScript and Node.JS, you may be inclined to believe that this is an IDE only for JavaScript. Nothing could be further from the truth.

While the marketing tends to focus on the JavaScript part of the equation, Cloud9 supports all the most popular programming languages: Python, PHP, CSS and, of course, HTML. Keep in mind that, since this is under active development, you can count on more esoteric languages being added down the line. Just drop the friendly devs a line and let them know!

And as a modern IDE, it features almost all of the niceties you’d be expecting. Real time validation, break points and other forms of code analysis and inspection are all covered.


#9 — Co-developing and Collaboration is a Cinch

Version control is a great plan for a team over the long run to handle collaboration. But sometimes, all you want is to share your screen with someone else and write code simultaneously. Ever shared a document on Google Docs and watched as someone fix this small error you left behind? Cloud9 lets you do this from a development perspective.

Tutorial Image
Tutorial Image

On a larger scale, it also lets you add and remove developers on a per project basis with even more fine grained control over read and write access. Definitely useful when you have a large team under you. Some rudimentary project management support is baked in as well.

Tutorial Image

Cloud9 ships with an integrated, real time chat client.

And finally, in the spirit of real time development, Cloud9 ships with an integrated client that allows you to communicate with members on your team from within the IDE. Obviously, it’s more IM than email — the interaction is in real time — like Campfire for developers.


That’s a Wrap

Needless to say, if you’re fairly serious about JavaScript, you really owe it to yourself to take a look at the platform. At the very least, you’ll be supporting devs who are pushing JavaScript forward in leaps and bounds.

I hope that you’ve found this write-up interesting. We’ve tried to go with a slightly different topic today, diverging from our usual web development content. I’m sure there are lots of perspectives I’ve missed in this article, so remember to chime in with your comments. Thank you so much for reading!

March 16 2011

16:32

You Have a Disease. Here’s the Cure.


I have a disease. No, not life threatening, luckily; but one that does hinder my ability to be both productive and well-rounded. And you know what? It’s quite possible that you have it too. Disagree with me? Well sure you do, but admitting you have a problem is the first step!

It’s not like we’re content with monthly publications any longer.

The disease I’m referring to is one that I’ve spoken about numerous times in recent years: the “always on” effect. Particularly as web developers, we’re consumed by media and gadgets. You finish up a day of coding, and how do you prop up your feet to relax? Probably with a visit to Engadget to catch up on the “news.” But who’s to blame you? It’s not like we’re content with monthly publications any longer. Heck, we’re not even content with weekly, or even daily news! You — and by “you,” I mean “I” — probably check in on the site, or one of its siblings (Mashable, TechCrunch, etc.) twice a day. It’s admittedly a waste of time, yet we don’t stop.

At first, in the late nineties, all was well. How amazing that we have access to up-to-the-minute news at all times?

Sure, we had to dial in, and pray that the phone didn’t ring, but, even so, the accessibility of endless information was well worth the effort.

But then, this developing illness became a bit more extreme with the introduction of a new generation of smart phones with non-kill-the-person-sitting-next-to-you-while-waiting-for-the-page-to-load browsers! This introduced a whole new level of availability. Not content to access the web only via a wired desktop computer, we can now do so on the go (some taking the “on the go” idea a bit too far…think Tweeting while driving).

So what’s wrong with reading gadget sites twice a day? Well certainly there’s nothing inherently wrong with doing just that, but it’s rarely “just that.” In fact, it’s a symptom of a much bigger problem: information/media/gadget overload. Combine your daily workload with web browsing, social media and RSS feeds, and you get a lot of eye strain.

We all know that feeling; it’s the evening, and you find that, for the last twenty minutes or so, you’ve been mindlessly browsing the web, accomplishing absolutely nothing. During the course of that twenty minutes, it’s likely that you visited more than one site multiple times! Because hey, the refresh button could reveal all sorts of new information.


Buzz: Social Media

What’s a “viral” video?

I remember the day I was introduced to Facebook — way back in 2003. I think, at that point, the term “social media” had no meaning. Little did I know that, in a few short years, the term would not only exist, but also fuel thousands of jobs in the world, which required “experts” in the field. As I write this, I’m reminded of when I was twenty years old, and was asked by a marketing person at a publishing company if I knew what “viral marketing” meant. “What’s a viral video?” How funny.

Fast forward a few years, and Twitter is now the defacto communication standard for most web professionals, in particular. It’s the perfect medium for psuedo-water-cooler-chatter. But then, once again, something happened to many of us. It became a sort of addiction — at least in the lightest sense of the word. Whether you’ll admit it or not, it’s likely that you know exactly what I’m talking about. And if you don’t, more power to you. Good job.

Take the Test

You’re officially a social media addict if you identity with any of the following actions.

  • Research: You not only have a desktop Twitter client, but you also researched all of the available options before making your choice. (I chose Echofon).
  • Industry Awareness: You were decidedly pissed when Twitter recently announced the changes to their terms and conditions, which limit the availability of third party applications.
  • Efficiency: Your Twitter client also incorporates other social media sites, like Facebook. If you’re going to waste time, you might as well be efficient at it!
  • Updates: You made at least one tweet about the recent Twitter redesign, and are familiar with some of the technologies used to create the site.
  • Options: You’ve installed more than one Twitter client on your mobile phone.
  • Brightness: You turn the brightness on your phone all the way down in movie theaters, because you fully anticipate checking your email at least once during the movie.
  • Always On: Your desktop Twitter client is, more or less, open all day.
  • Chirps: Between push notifications on your phone, and alerts on your desktop and laptop computers, you hear multiple chirps for every unimportant Twitter update.
  • Engagement: You’re reading this article, and have every intention of commenting with your thoughts!
  • TV: You enjoy the show, “Big Bang Theory.” This is the surest dead ringer for an internet addict. :)

Joking aside, if you’ve felt your leg buzzing in a movie theater, and couldn’t keep yourself from checking your phone, you probably have a problem — a first-world problem, nonetheless, but still a problem! So what’s the solution? Disavow all technology, email, and social media? Of course not. But I would argue that it’s time to implement some barriers. Over the last several months, I’ve begun doing just that.


1 — No Phone On Date Night

Rule number one. If you have a drinking problem, don’t drink. Equally true, if you have trouble ignoring push notifications, turn the phone off. My wife-in-training, Allie, and I have a weekly “date night” tradition. I’m sure you and your significant other have something similar. Under no circumstances should the phone be on during these designated hours.

Rule: Turn the phone off, and keep it out of site for the entire evening. No exceptions — and trust me, you will try to make exceptions. Your spouse can help you with this.


2 — Close the Twitter Client

If you’re similar to myself, your social media app of choice tends to remain open through out the entire day. Of course, that doesn’t mean that you’re actively participating in the feed at all times; in fact, you’ve probably become quite skilled at ignoring the endless new message chirps. Yet, nonetheless, it’s a needless distraction.

Rule: Twitter can be accessed three times a day only. Morning, lunch time, and before you finish up for the day. To some, this may still seem excessive. Why Use Twitter at all? The reason is because it absolutely serves a purpose in the web dev community, if used correctly. Other than these designated times, the app should be closed.


3 –A Full Day Off

Even though most have the weekend off, web developers still tend to work in some fashion on Saturday and Sunday. Some use the free time to work on side projects. Others may use it to catch up on industry news and developments. The reason is simple: we enjoy what we do, and like building stuff! But, this still falls under the information overload umbrella. If you’re not careful, you’ll burn out.

Rule: At the very least, you mustn’t touch the computer for an entire 24-hour period each weekend. No email. No status updates. No power.


4 –Designated RSS Time

It’s intimidating to see how much incredible (and free) content is released every single day. Is your RSS list massive? Probably so! If not, then you’re falling behind the rest of the wolf pack. By no means should you ignore this content, though. Instead, the key is to manage it effectively, and designate specific portions of the week to review the feed.

Rule: Use services like Instapaper or Read it Later to create reading lists. Then, choose 1-3 days each week to filter through all of the information.


5 – Seek Help

All of these “rules” are only effective if they’re followed; and I’ll be the first to tell you that it’s really, really hard. For example, during the process of writing this editorial, I’ve checked my email a few times, and refreshed my Twitter feed a couple as well. The amazing thing is that these sorts of mindless “refresh” button activities have a way of becoming less planned, and more instinctual. Before you even realize what you’re doing, you’ve somehow created a new tab and accessed Gmail.

To combat these tendencies, we can use a variety of desktop tools to limit block certain applications/websites/etc. As a Mac user, I’m a big fan of Concentrate.

Rule: Use tools like Concentrate to “help you work and study more productively.”


Conclusion

Before I wrap this editorial in a bow, it’s important for me to note that I’m using the word “addiction” and “disease” in jest. While I’m willing to concede that I’ve wasted too much time in the past pressing the refresh button, that’s the extent of it. When I use these words, they’re meant to be interpreted in the lightest sense possible, and in a manner that’s applicable to most of us. I’m not referring to actual internet addiction, which is a very real thing.

If I can manage to follow these steps, I’ll be a happier person with more free time to spend outdoors, and with my family. And the best part? The phone will be off.

March 15 2011

16:14

The ABCs of Web Development


Web development can often be an utterly perplexing affair. Today, aimed at beginners, I’d like to introduce you to twenty six concepts or technologies, each mapping to a letter of the alphabet. Sounds wonky? It probably is! Let’s get started after the jump.


A — AJAX

AJAX stands for Asynchronous JavaScript And XML and is the main driving force behind all these super smooth web applications you’ve been using over the past few years.

AJAX, as a technology, has been pretty much all pervasive. GMail? Check. Flickr? Check. eBay? Check. You can even find it in WordPress’ administration panel. So what exactly does it do and how does it do it?

At the center of everything is the XMLHttpRequest which allows calls to be sent and received, after a page has been fully rendered without touching the rest of the page. This essentially means that a web application doesn’t have to go through the a full page refresh for each and every action. This, in turn, provides a much smoother, much immersive, desktop like user experience.

Related reading


B — Browser

A browser is the understated structure on which you frame your magnificent masterpieces, be it websites or applications. They aren’t limited to retrieving websites though — modern web browsers are quite the multitasking beasts. My installation, for example, taps into IRC, FTPs into my development servers and syncs my credentials across every device I use.

As you may have surmised, browsers are simultaneously the cause of much cheer and rage to the modern web developer – they’re invaluable tools as well as annoying beasts. Any developer who has to make sure that his work has to look perfect in every browser will know the pain.

Related reading


C — CSS

CSS is one prong of the front end development trident. CSS, which stands for Cascading Style Sheets, is the language with which you define how a page is displayed — its presentation, if you will.

During the horror days of web development, developers would frequently weave the presentation code into their source. CSS, amongst other technologies, alleviated this greatly by providing a method to cleave presentation from the content.

Related reading


D — DOM

The DOM, an abbreviation of Document Object Model, is the accepted convention for interacting with HTML [or XML] documents. The DOM API provides a way to traverse and manipulate a document programmatically.

The DOM creates a hierarchy that matches the structure of the parsed HTML document. The children are called nodes or DOM nodes.

If you hear someone talking about the DOM, chances are, they’re talking about DOM scripting. This is the term used to describe programmatically accessing and manipulating the DOM through JavaScript. This is the tech behind most modern web sites and applications you see today.

Related reading


E — Events

Modern web applications are deeply event driven affairs. But what’s an event? Most things you do on a web page constitute an event. The trepidatious hover over a funny but possibly NSFW link, clicking on a button, pressing tab to move to the next text field are all valid events.

Event handling refers to the process where we attach a specific chunk of code to be run whenever a certain event is fired. Again, this is one of those fundamental concepts behind modern web development that you’ll need to master.

Related reading


F — Firebug

Any craftsman needs his tools to work efficiently. Web developers aren’t deviants from this rule. One of the most robust tools around is Firebug.

Firebug is a Firefox extension that will galvanize your workflow. It lets you edit and monitor a page’s every aspect on the fly. I can’t quite explain all the features it provides so make sure to hit the links below.

Related reading


G — Grid

Grids are the visual frameworks on which pages are structured. Ported over from the once burgeoning print industry, grids are an essential part of the modern web development workflow.

There are a number of CSS frameworks catering to exactly this need since building a grid based layout, for a non-trivial number of pages and layouts, can be an exercise in masochism.

Related reading


H — HTML

If you’re reading this today, you probably already have a vague idea as to what this is. If you got tricked into this link though, read on. By the way, welcome to Nettuts! We write about web development, cookies and Justin Bieber.

HTML stands for HyperText Markup Language, the defacto markup language of the web — it’s to web pages as bricks are to homes. HTML consists of several components or elements — tags, tag attributes and the content enclosed within the tags.

The latest version of the HTML standard, HTML5, is now upon us bringing a number of new features, streamlining the workflow and fixing a few incompatibilities.

Related reading


I — IE

Ahh, Internet Explorer. The name evokes both awe and anger. Once a hero which brought forth impressive new features to the market, single handedly moving the industry forward, it also dropped the ball by letting the browser stagnate. Till date, it’s also the leading cause of alopecia in front ends developers. After a decade of battering, the latest version of Internet Explorer, 9, is once again in the right path towards innovation.

Whatever your stance towards Internet Explorer is, it’s an intrinsic and inextricable part of the web development process.

Related reading


J — JavaScript

JavaScript is the final member of the essential web development trio. JavaScript, which is NOT Java, is the scripting language of the web. Its use in billions of web pages and, more importantly, web sites stakes that claim. You define behavior through JavaScript — managing events, manipulating the DOM and talking to the server.

Thanks to the incredible adoption of libraries, like jQuery, awareness and knowledge of JavaScript has been growing every year, year after year. I think it’s appropriate to say that JavaScript is an absolute must for every modern web developer.

Related reading


K — Keyword Optimization

SEO relates only tangentially to web development but even then, it’s important for a web developer to have basic knowledge of what SEO is and what it does.

Keyword optimization refers to the process of choosing the correct keywords for your website and then optimizing them so your audience can find your site. While you’re dabbling with all the tenets of SEO, remember this: content is king. If you have bad content with excellent SEO, users will find you but leave soon after. If you have good content, users will find you and stay.

Related reading


L — Less

Less is a stylesheet language with a few aces up its sleeves. Their website states that LESS extends CSS with dynamic behavior such as variables, mixins, operations and functions and I’m inclined to agree.

LESS is CSS on anabolic steroids. Yes, it sounded better in my head but you know what it means. It brings the concepts of a dynamic language to CSS thereby making humongous stylesheets a lot more easier to manage.

Related reading


M — MVC

The Model View Controller pattern, better known as MVC, is one of the most used in the web development world. It’s an architectural pattern that separates each part of a web application into logical chunks for better maintainability — models handle data, views handle presentation while the controller coordinates the flow of information between the two.

If you’ve used a modern web development framework, you’ve used MVC. Ruby on Rails, Code Igniter and Zend Framework all use this pattern.

Related reading


N — node.JS

node.JS ushered in a new era of web development. It enables running JavaScript on an incredibly fast VM [V8]. The consequences of such a paradigm shift may not be immediately apparent but an hour or so with it will make it clear as day.

Incredible speed as well as the ability to manage thousands of concurrent IO events are the main talking points along with the near universal JavaScript developer user base.

Related reading


O — Object

Object oriented programming has been widely adopted by the programming community for the flexibility it brings to the table. With OOP you can write few lines of code, make it more DRYer and thus much more easier to maintain.

But what exactly is an object? It’s quite hard to explain it in a single, semantically self contained sentence so be sure to hit the links below!

Related reading


P — PHP

PHP is unequivocally the most popular server side language — it powers millions, possibly billions, of web pages and applications.

Even in the face of a number of newer, arguably better options to write web applications, PHP has not only survived but flourished. WordPress, Joomla, Drupal, MediaWiki all use PHP behind the scenes. One of the main reasons is the ease of deployment and the relative ease with which you can find hosts supporting PHP.

Related reading


Q — Query

A query, in our context, can refer to a number of things. A query language is used to interface with external systems to obtain information. SQL is a fine example which is used to obtain information from relational databases.

A query string, on the other hand, are chunks of information that is passed to web application as part of the URL. This data maybe anything from the page the user is trying to access to the authorization ID of a transaction. Query strings are formatted as key value pairs.

Related reading

March 14 2011

16:52

The Things Internet Explorer Got Right


It’s the browser that everyone loves to hate—sometimes justifiably so. What was once the most innovative browser became the thorn in every front-end developer’s side. Amidst the turmoil and complaints today’s developers throw at Internet Explorer, what’s often not heard is how Microsoft changed the face of not only front-end development, but web development as a whole.

IE’s fall is not an uncommon story; in fact, it’s somewhat the same story as Netscape. The company behind the leading browser grows complacent, the browser stagnates, and a new champion arises. It’s a repetitive cycle, one that Mozilla faces again to some extent (but that’s another story for another time).


IE4’s Influence on the DOM

Prior to the version 4 browsers, JavaScript was primarily used for simple data processing (form validation). As such, web pages were primarily static. While a page could be dynamically generated by server-side applications, the page could not interact with the user. This limitation existed because of the browser’s inadequate Document Object Model (DOM), which is the application programming interface (API) JavaScript developers use to access and manipulate individual elements in the page. The DOM that existed prior to the version 4 browsers is frequently referred to as DOM Level 0. DOM Level 0 implementations allow developers access to <form/>, <a/>, and <img/> elements, but that’s about it.

“Microsoft is getting Internet Explorer back on track.”

Netscape Navigator 4

It wasn’t until Netscape released Navigator 4 (NS4) in mid-1997 that a browser’s DOM allowed web developers to alter a page with JavaScript. The technique of manipulating elements with JavaScript and the DOM was dubbed Dynamic HTML (DHTML). NS4’s DHTML was certainly a step forward, but its proprietary and ill-designed layer-based DOM and limited Cascading Style Sheet (CSS) support restricted developers in what they could actually accomplish.

Accessing Elements

Netscape did not implement a full object model. Aside from DOM Level 0 functionality, the only elements a developer could access were absolutely positioned elements, <layer/> elements, and <ilayer/> elements (the latter two elements were de facto positioned). Each of these types of elements were represented by a Layer object in NS4’s DOM. Netscape designed Layer objects to be very similar to frame (and thus window) objects. Each Layer object had a document property, which basically was another HTML document. Like frames, a Layer object could be nested in another Layer object, making code to access those layers extremely verbose like the following:

var myLayer1 = document.layers["myLayerId"].document.layers["mySecondLayerId"];
// or
var myLayer2 = document.myLayerId.document.mySecondLayerId;

These two lines of code do the same thing: they access the Layer object with an id of mySecondLayerId that is nested within a layer with an id of myLayerId. Yes, developers had to walk down the layer "tree" in order to access nested layers.

Dynamic Content

NS4’s DOM did not allow for the creation, insertion, relocation, and removal of DOM objects, but because each layer exposed a document object, a developer could dynamically change a layer’s content by using the write(), load(), and close() methods. While this gives some extra power to the layer model, it restricted developers in how they could dynamically update a page. New content would have to be written or loaded into a layer, effectively removing the layer’s existing content. Needless to say, most developers avoided content manipulation and instead focused on changing a layer’s style.

Changing Style

Web development using NS4’s DOM was painful and frustrating.

But style in NS4’s DOM was a funny thing. While the browser supported CSS to some degree, Layer objects did not provide an API for developers to directly access a layer’s style attribute like today’s style object. Instead, Layer objects exposed a very limited set of properties that altered a layer’s position, visibility, clipping, and background color/image—nothing else, and the value these properties accepted were also quite limited. For example, the positioning and clipping properties only accepted numeric values; a developer could not specify a unit (such as px, em, pt, etc). An example of such code follows:

var myLayer = document.myLayerId.document.mySubLayerId;
myLayer.top = 10;

Needless to say, web development using NS4’s DOM was painful and frustrating. NS4’s extremely limited DHTML capabilities stem from the limitations of NS4’s rendering engine (it could not reflow the page). But why spend so much time on Netscape’s DOM, especially in an article that’s supposed to be about IE? Had Netscape won the browser war, today’s DOM would be an evolutionary step from the DOM presented by Netscape in NS4. While today’s DOM is a standard put forth by the W3C (and some Netscape ideas are implemented in today’s standard), today’s DOM is heavily influenced by IE4’s DOM.

IE4’s DOM

Just a few months after Netscape released Navigator 4, Microsoft released the fourth version of IE. It, too, included support for DHTML, but Microsoft’s implementation was far different and superior to NS4. IE4 boasted much better CSS support and a more complete object model to access and manipulate elements and content in the page. The effect of IE4’s DOM was far reaching; in fact, a developer can find many similarities between IE4’s DOM and the standard DOM.

Accessing Elements

“Microsoft changed the face of not only front-end development, but web development as a whole…”

IE4’s designers wanted to turn the browser into a platform for Web applications. So they approached IE4’s API like an operating system’s—providing a near complete object model that represented each element (and an element’s attributes) as an object that could be accessed with a scripting language (IE4 supported both JavaScript and VBScript).

In IE4’s DOM, the primary means of accessing a particular element in the page was the proprietary all[] collection, which contained every element in the document. Developers could access elements with a numerical index or by specifying an element’s id or name, like this:

var myElement1 = document.all["myElementId"];
// or
var myElement2 = document.all.myElementId;

Using this code, developers could access the element object with an id of myElementId regardless of where it existed within the page. This is in stark contrast to Netscape’s layer model in which developers could only access layers through the layer’s hierarchy. The functionality of document.all["elementId"] evolved into the standard document.getElementById() method. But this wasn’t the only way a developer could access elements; one could walk the DOM tree and touch each element with the children[] collection and parentElement property—forerunners to the standard childNodes[] and parentNode properties.

In addition to loading elements as objects, IE4’s DOM represented an element’s attributes as properties of the element object. For example, the id, name, and style properties mapped directly to an element’s id, name, and style attributes, respectively. This design became standard.

Dynamic Content

Microsoft invented the innerHTML property.

Like Netscape, Microsoft did not provide a full-fledged API to dynamically add, move, and remove nodes with JavaScript. They did, however, invent the innerHTML property to get or set an element’s content. Unlike Netscape’s Layer object’s write() and load() methods, the innerHTML property was not an all-or-nothing solution to modifying an element’s content; a developer could use innerHTML to completely wipe out, replace, or add to an element’s content. For example, the following code gets an element’s content and modifies it:

var el = document.all.myElementId,
    html = el.innerHTML;

el.innerHTML = html + "Hello, innerHTML";

To this day, the innerHTML property is a cornerstone of DHTML. It is an efficient means to adding large amounts of content to an element. Even though it has never formally been included in any DOM standard, every major browser implements an innerHTML property.

Modifying Style

Microsoft invented several tools and designs that evolved into pieces of the standard DOM, but the work they did with IE4’s style API became standard with very little modification. The key to changing an element’s style in IE4 was the style property, the same property (and syntax) used by developers today.

DHTML changed web development forever. It was, however, IE4’s DOM that pushed the technology (and web development) forward by being the primary influence on the W3C’s DOM Level 1 and 2 specification. IE4 revolutionized web development in 1997, and IE would do so again a few years later.


IE Revolutionizes Ajax

Ajax blew the doors open for web development.

Before Ajax was Ajax, it was called remote scripting, and developers leveraging the power of remote scripting used hidden frames and iframes for client-server communication. A hidden (i)frame usually contained a form that was dynamically filled out and submitted through JavaScript. The server’s response would be another HTML document containing JavaScript that notified the main page that data was received and ready to use. It was crude, but it worked.

There was an alternative, however: a little known gem buried in Microsoft’s MSXML 2.0 library. IE5, released in March 1999, included MSXML 2.0, and developers found a component called XMLHttp (the actual interface name was IXMLHTTPRequest). Its name is misleading, as the XMLHttp object functions more like a simple HTTP client than anything else. Not only could developers send requests with the object, but they could monitor the requests’s status and retrieve the server’s response.

Naturally, XMLHttp began to replace the hidden (i)frame technique for client-server communication. A couple of years later, Mozilla created their own object, modeled after Microsoft’s XMLHttp, and called it XMLHttpRequest. Apple followed suit with their XMLHttpRequest object in 2004, and Opera implemented the object in 2005.

Despite its growing interest, the popularity of XMLHttp/XMLHttpRequest (collectively known as XHR here on out) didn’t explode until 2005 when Jesse James Garrett published his article, “Ajax: a New Approach to Web Applications.”

Ajax blew the doors open for web development, and at the forefront was JavaScript, XHR, and DHTML—two of which were Microsoft’s inventions. So what happened? What caused a browser that literally changed how web developers write web applications to become the bane of the modern Web?


Internet Explorer’s Fall

By 2003, Internet Explorer’s total market share was around 95%; Microsoft officially won the browser war. With no real competition in the Web space, Microsoft shifted their focus from the browser to .NET. This is confirmed by quotes from many Microsoft employees, but the most telling is from a CNET article entitled “Will Ajax help Google clean up?” In it, Charles Fitzgerald, Microsoft’s general manager for platform technologies, was quoted as saying:

“It’s a little depressing that developers are just now wrapping their heads around these things we shipped in the late 20th century [ed: DHTML and Ajax], but XAML is in a whole other class. This other stuff is very kludgy, very hard to debug. We’ve seen some pretty impressive hacks, but if you look at what XAML starts to solve, it’s a major, major step up.”

So in May 2003, Microsoft announced that IE would no longer be released separately from Windows (the excellent IE5 for Mac was also canned). The browser would still be developed as part of the evolving Windows operating system, but Microsoft would not release any stand-alone versions of IE. They were betting primarily on ClickOnce, a technology that allows developers to write conventional applications (using .NET of course) and distribute them via the Web.

But the Web continued to evolve in the path Microsoft originally set with IE4 and IE5, and Microsoft started to lose market share to Netscape’s heir: Firefox. Developers were writing web applications that lived in the browser, not in conventional applications via ClickOnce. That forced Microsoft to pick up IE, dust it off, and begin releasing stand-alone versions again.


Microsoft Continues to Innovate

IE9, includes much better standards support across the board.

The next two versions, 7 and 8, were largely evolutionary. IE7 contained a variety of bug fixes, the XMLHttpRequest identifier (although it still created an XMLHttp object from the MSXML library), and improvements to the UI and security.

IE8 was largely more of the same, except it sandboxed each tab—a feature that Google also implemented in Chrome (Microsoft announced it first). It isolates each tab in its own process, increasing security and stability. Sandboxing is becoming standard in today’s browsers (Firefox still lacks the capability), and it’s also moving into the realm of add-ons and plug-ins.

Microsoft is getting Internet Explorer back on track.

The latest version, IE9, includes much better standards support across the board, but it also innovates with its new JIT-compiling JavaScript engine (which uses a separate CPU core if available and can access the GPU) and its hardware-accelerated rendering engine. While JIT-compiling JavaScript engines are not new, IE9’s ability to offload compilation onto a separate core in parallel to the page rendering is an accomplishment that will spur on much needed performance for web applications. Its hardware-acceleration abilities proved useful when debuted, and now Firefox and Chrome offer hardware-acceleration to some extent.

There is no denying that Internet Explorer has caused headaches for web developers. The five year lull between IE6 and IE7 caused Microsoft to fall way behind the competition, making front-end development less than ideal. But Microsoft is getting Internet Explorer back on track. They shaped web development to what it is today; here’s hoping they do so again.

The next version of Internet Explorer, version 9, is scheduled to be officially released March 14th, 2011.

March 03 2011

18:09

Language War: PHP vs. Ruby


It’s time; queue the “Going the Distance” theme from Rocky. In the red ring: Envato developer extraordinaire, Ryan Allen, who built the original FlashDen with his cold bare hands. In the blue corner: Michael Wales, a well known member in the PHP and CodeIgniter communities. The battle? PHP vs. Ruby. Fight!


Before We Begin

It must be noted that these sorts of debates are purely for fun and educational purposes. There are times when you’ll choose PHP for a project, and there are times when you’d opt for Ruby. The goal of this series, however, is to learn how and when to make these sorts of decisions. Rather than “your language sucks,” these debates are meant to outline why you might, in certain situations, choose one over the other.


The Contenders

Ruby: Ryan Allen

Ryan Allen

Ryan Allen is a web software and systems engineer who’s been working for Envato since forever. He built and supported the early versions of the Envato Marketplaces in Ruby on Rails, and now looks after the Tuts+ systems, amongst other things.

PHP: Michael Wales

Michael Wales

Michael Wales is a web developer for US Government agencies, and is an active contributor to the PHP and CodeIgniter communities.


And…Begin!

1 – How familiar are you with both PHP and Ruby?

Ryan: PHP was one of the first programming languages I worked with (asides from ActionScript and some very brief Visual Basic). I began building things with PHP in 2001. I worked fairly exclusively with it as a backend tool until late 2005, when Ruby (and Rails) took its place.


Michael: PHP was my introduction to the world of web development, in 1999 – so I’d like to say I have a pretty solid understanding of its position within our industry, its history and the direction in which it is headed. Ruby, like many others, caught my eye with the release of Rails and the success of 37signals. I have a fairly solid understanding of Ruby, as a scripting language in my System Administration duties (Capistrano) as well as some personal and fun projects (the Gosu game development library and Rails). I’m ashamed to admit I’m not as familiar with Rails’ latest versions and it is definitely on my list of things to reacquaint myself with.


2 – Do you feel that your language is more suited to beginners or advanced users? For example, if I’m relatively new to the industry, would I have more trouble learning PHP or Ruby?

Michael: Unfortunately, I can’t give a definitive answer to this – at least not as you’re expecting, since PHP and Ruby are two entirely different beasts. PHP is an amalgamation of language and web framework in one package, whereas Ruby is a programming language with numerous frameworks available.

If your focus is web development and that’s all you really wanted to focus on right now, I would definitely advise you to learn PHP first.

So, if your focus is web development and that’s all you really wanted to focus on right now, I would definitely advise you to learn PHP first for a number of reasons:

  1. You don’t really need a solid understanding of System Administration or deployment best practices to learn and get things done. For virtually every host, you upload and you’re done.
  2. You’re going to gain a lower-level knowledge of how the web works; for example, how a request is passed between the client and server (as it pertains to your application), what functionality sessions provide, the limitations of cookies, the difference between the various request methods.
  3. On the Ruby side (and I’m going to assume the Rails framework, based on its immense popularity): deployment can be very difficult at times (although this is alleviated by services like Heroku, but then you miss out on the educational opportunities of understanding the low-level). I think this lack of low-level education is the ultimate downfall of Rails, from both a deployment standpoint as well a development standpoint – you can quickly and easily use sessions, cookies, create insecure and destructive controllers (via the GET request method). Not that you can’t do these things in PHP as well, but Rails actively promotes this knowledge.

As a developer with 12 years’ experience, I appreciate the shortcuts Rails brings to our industry; but, that is only because I understand what is actually going on behind the scenes.

If you want to become a developer (Web Developer, System Administration scripting, Game Developer, API Developer) who understands low-level Computer Science concepts, object-oriented programming and, in general, advance your Critical Thinking skills – it goes without saying, start with Ruby, it’s an actual programming language (remember, PHP is a web framework disguised as a language).

From a Web Developer perspective, I think this is also one of Ruby’s (and Python’s, BTW) downfalls – is that there really isn’t any “mid-level” entry point. You either understand the HTTP protocol, with the ability to write your own stack, top-to-bottom, or you go with one of the “magical, hold your hand to make a CRUD-system frameworks”.

This is really the area in which PHP shines. If you are stepping beyond the boundaries of CRUD, you don’t need to have an extreme understanding of how an HTTP server works to make your dreams a reality.


Ryan: If I were to teach someone programming from scratch, I’d prefer to teach them Ruby (trouble setting up environments aside – though this is getting easier). A common way to start someone off (after perhaps variables and printing them) is to explain arrays with, say, a shopping list example, take this bit of PHP:

$shopping_list = array(‘Milk’, ‘Cheese’, ‘Hovercraft’);

for ($i = 0; $i < count($shopping_list); $i++) {
  echo $shopping_list[$i];
}

When I learnt PHP, I was taught to use for loops (as I was in ActionScript), when a more succinct and less error-prone foreach loop already existed (as it also did in ActionScript). I had to learn all about this $i = 0 thing, this test thing and this incrementor thing. It was all so confusing! The number of times I’ve screwed up for loops is uncountable (no pun intended). Here’s what the same thing would look like in Ruby:

shopping_list = [‘Milk’, ‘Cheese’, ‘Hovercraft’]

shopping_list.each do |shopping_item|
  puts shopping_item
end

There’s a lot less syntax there, and iterators are to my mind, a lot easier to understand and work with. But for completeness sake, here’s the the PHP example but with a foreach:

$shopping_list = array(‘Milk’, ‘Cheese’, ‘Hovercraft’);

foreach ($shopping_list as $shopping_item) {
  echo $shopping_item;
}

Well, that’s not to bad actually! I reckon that you should only use for loops to count to 10 and things like that, foreach is so much easier to read and teach and so much harder to screw up. And iterators are even better, so I’d go with Ruby.


3 - Many PHP developers move on to Ruby after a few years. Have you found this to be the case, and, if so, why do you think it’s so common? What’s the big “selling” point?

Ryan: The selling point for me (in 2005) was the Rails framework. I had tried my hand at web development with Python but being inexperienced I had somewhat of a tough time, not knowing what to do or where to look (but I managed to build some things, so take that!), but I really wanted to use Python day to day because I felt it had a better, more deliberate design and I liked the syntax. And because Snakes are cooler than Elephants.

ActiveRecord was just so amazing!

Having never worked with anything else beyond ADODB in PHP, and trying and failing at making an ORM many times (I had no idea what an ORM was but I knew I wanted something that somehow mapped classes to database tables), when I first saw ActiveRecord it was like all my Christmases had come at once.

I knew relational databases rather well but was sick of writing the same SQL over and over. ActiveRecord was just, just, so amazing! And Ruby was close enough to Python I was happy as Larry (whoever he is) to have a framework I could get busy and start building things. So for me it was the love of a library and a love of the syntax.

Nowadays we have heaps of amazing Ruby libraries written by talented individuals, libraries such as Sinatra (a lightweight web framework), Nokogiri (a HTML/XML parser), Sequel (a high level database library), RSpec (an automated testing library). All these libraries are installable as RubyGems which I found much easier and user friendly to work with than PHP’s PEAR system.

The community is still fairly vibrant, even a few years in, and companies are hiring Ruby developers like hotcakes. Ruby 1.9 is apparently almost as fast as PHP now as well, so there are many selling points!

Ruby 1.9 is apparently almost as fast as PHP now as well, so there are many selling points!


Michael: I think this is just a natural progression of developers (from Web Development to seeking overall knowledge of OOP languages and an overall Computer Science education) in general – I know it was the route I took.

I think the largest downfall, to this day, is the practice of picking a language and sticking to it to the death. That’s not the way the real world works.

I consider myself a “Developer” – therefore, language is an ambiguous a qualification as the brand of television to a Best Buy salesperson. There are instances in which I pick PHP (if there is an extremely short timeline – outside of CRUD, it’s the language I am most familiar in), there are others in which I pick Ruby (deployment via Capistrano or basic CRUD with Rails) and, even further, Python – which I prefer for Server Administration tasks and parsing of various files.


4 - Often times, we consider our current language of choice to be “better” than the previous. But is that always the case, or is it just “new”? Is it possible that your old code looks poor because you’re now a more skilled developer?

Michael: I think developers can very often get caught up in the “new hotness, old busted” craze. This is why my team always sits down before we begin a project, we lay out the requirements (in both user terms and developer terms – which are two vastly different things) and we talk it out, with very little language/framework preferences in mind. Last week we parsed a few GBs of messaging logs with Perl, this week we built an application whose primary view was an ExtJS GridPanel (because we have extended CodeIgniter core files that handle any situation ExtJS throws at us with 3-lines of code).

It’s all about how much time do we have and how can we produce the best product in that timeframe?


Ryan: Absolutely, some people (myself included) get used to designing things in a certain way that they don’t want to re-learn and change all their hard-earned habits. Once you’re productive with something, why would you bother changing it?

Another school of thought is the more languages and tools you have experience, you’ll be able combine the best techniques and ideas no matter what environment you’re working in (they say this about learning LISP, but I haven’t learnt it yet).

Young programmers will jump on the shiny new things but as you get older and more mature, you want to work with small tools that are simple and robust. If you don’t use every feature and every library available to in Ruby you can get simple and robust without too much trouble.


5 - Are there instances when you might choose to use Ruby for one project, and PHP for another (assuming you have 100% control over the choice)?

One word: maintenance.

Ryan: Yes, one word: maintenance. Software projects have a propensity to require modifications over time, and the original author of the program isn’t always going to be the person who’s making the modifications. Let’s say hypothetically teleports are invented and there is a world-wide Ruby conference and every single able Ruby developer in the world is going (teleports rock!). Now let’s also say that Earth hypothetically is Middle Earth, and Smaug the dragon is rather annoyed about this whole Ruby thing (dragons prefer Python, you see) and decides to pay a visit and gobble all of the developers up out of spite. Now there are no experienced Ruby developers left in the world, oh dear! Now you have this problem of not having a pool of Ruby developers available to work on your projects. What are we going to do Gandalf?

When I’m choosing tools, I’m often thinking about who’s going to have to maintain the project if I get hit by a bus (or crash my motorbike, which is more likely).

I certainly wouldn’t write anything in Haskell or LISP or even F# because we’d have a hard time hiring someone who could or would work on it. Availability of talent and existing talent in a company then very much influences my decision.

There’s another situation where I’d consider the language, and that would be if I was selling a product, say, a custom CMS selling on Code Canyon. I wouldn’t write it in Ruby because commodity web hosting doesn’t generally support it. Whereas PHP is pretty much readily available everywhere and web designers and less experienced programmers are somewhat familiar with it.

There’s another situation where I’d consider the language, and that would be if I was selling a product, say, a custom CMS selling on Code Canyon. I wouldn’t write it in Ruby because commodity web hosting doesn’t generally support it. Whereas PHP is pretty much readily available everywhere and web designers and less experienced programmers are somewhat familiar with it.


Michael: See my answers for #3/#4.


6 - If I’m more of a designer who only dabbles in development work from time to time, would you still recommend that I choose Ruby over PHP? Keep in mind that the terminal is a scary thing to some...

Michael: Personally, I would recommend the Django framework for Python. It was designed with this purpose in mind: the ability to get the developers working on data modeling and displaying data on-screen as quickly as possible, with easy to use tags for designers to present that data in a beautiful manner, while the developers continue to work on the business rules in a concurrent cycle.


Ryan: If you have experience throwing together HTML and CSS and uploading these with FTP, then I probably would recommend PHP, as it has low barriers to entry because you’re already familiar with its metaphor (Wrap your code in <?php tags! Upload it to your server with a .php extension! Away you go!). But if you started taking programming seriously, I’d suggest branching out and having a look into other things (such as Ruby) to broaden your horizons.

When things go wrong, your lack of knowledge will come back and bite you.

Oftentimes I see PHP programmers working with relational databases and having very little understanding of how they work. So really you can get things done without a deep understanding of the technologies you’re working with (you rarely use PHP all on it’s own), but when things go wrong, your lack of knowledge will come back and bite you. How much time do you have to invest in learning these things? Can you go to someone for help if you get stuck? Are you learning PHP so you can get work with it, or just for fun? Choice is a fairly open ended question depending on what your goals are.

Regarding terminals, they are, in short, AWESOME. I use them all the time. Yes, they have a learning curve (but what doesn't?). Once you get a handle on them and start writing your own little programs you can’t go on without them. To be fair, I didn’t find the Command Prompt in Windows very useful, but once I switched to a Mac and had access to all the *nix fun under the hood, it’s become rather productive.


7 - What specifically does your language have that the other does not -- if anything?

Ruby has hype, vibrancy, and sex appeal.

Ryan: I’d say something Ruby currently has that PHP does not is hype, vibrancy and sex appeal. Ruby is unequivocally sexy. Women love it. Men want to be like it. Godzilla fears it. I’d suggest hopping along to a Ruby User Group and you’d find a diverse group of people who just love to code, love making things and technology in general. When I began meeting people in the local Ruby community, it was the first time in my life I felt like I was with “my people.” I honestly thought I was the only programmer on the planet who cared about their work up until then. It was very refreshing and I’ve learnt a lot since then, mostly from the people I’ve met through these groups.

Here's a secret: if PHP released an official update with an alternate syntax (more Ruby/Python like), and wrapped the existing standard library in the style of the popular Ruby libraries (and made it consistent), and had backwards compatibility and ability to integrate with legacy code, it'd be a killer product. Don't tell anyone I said that.


Michael: Ease of deployment, a graceful introduction to the lower-level concepts of web development and over a century of documentation and tried-and-true best practices.


8 - It’s common knowledge that PHP is far and away the most popular server-side language on the web. Yet, it’s also the most ridiculed. Why is that? Certainly there’s a reason why it’s so widely used, right?

Michael: Again - ease of deployment, a graceful introduction to the lower-level concepts of web development and over a century of documentation and tried-and-true best practices.

But seriously – because of the low-barrier to entry with PHP it can be hard to discern the difference between someone who actually knows what they are talking about and someone at the same skill level as you that had a spare domain for a blog. Plus, due to PHP’s vast seniority, there’s a lot of content out there – and not all of it is good.

This isn’t a unique problem of PHP’s – one quick look at W3Schools.com will ruin the dreams of any proponent of xHTML, JavaScript, CSS or PHP.

PHP devs suffer from “not invented here syndrome.”

It can be very easy, when you are a learning a language, to find what you believe to be an authoritative resource (which could be out-dated or just plain wrong) and follow along with what they are “teaching” you. This is something the PHP community needs to get much better at – spreading the “right” way to accomplish certain tasks. I’ll admit – the Ruby community has the advantage here, Rick Olson solved authentication for everyone when he released the Restful-Authentication plugin. J

PHP developers, for their first few years, suffer from “not invented here syndrome” – which I don’t believe is a bad thing (until they start selling that or passing it off to others). I think the mindset behind a new developer, experiencing PHP for the first time, is that they really want to understand exactly what is going on – and PHP does a perfect job of “giving them enough rope to hang themselves” – revealing enough to learn, but you’re probably going to hurt yourself. Whereas, and not to discount Rick’s plugin (which is an awesome authentication system), Rails developers are willing to assume this guy got it right and continue on their way.


PHP became immensely popular because it was in the right place at the right time.

Ryan: I’d say PHP became immensely popular because it was in the right place at the right time. The alternatives for server side development back in the day required a fair amount of programming knowledge, yet many people who never thought of themselves as programmers were already throwing things together with HTML and CSS. Following the same deployment metaphor and a basic understanding of how to put websites together you could make moderately useful programs and throw them up on an inexpensive shared web host. Or you could download one that someone else made and tweak it up a bit because the HTML and code was all mixed in together.

Another thing that helped PHP along was the boom of the likes such as the cPanel product and hosting providers white-labelling web hosting. Every man and his dog could become a web host at low cost and without any technical knowledge. Every man and his dog wanted a web site and cheap hosting. PHP and MySQL were stock standard on these shared set ups, and they were everywhere (and still are).

The best doesn’t always ‘win’, a lot of people are still annoyed that SmallTalk lost to Java, though the people I’ve met (serious software veterans) who were around when this happened, say they feel quite at home in Ruby!


9 - PHP is often criticized for its sloppy nature. But, is this a reflection of the language itself, or the users who aren’t familiar with quality code? There are plenty of ways to write clean MVC-based PHP.

Ryan: This isn’t very nice, but I’d say the common criticisms of PHP are quite valid and are due to the way the “language” was designed (or rather, not designed). PHP was born out of a number of CGI scripts that the original author wrote in C (or was it Perl?), and the common case of why PHP went the way it did was so “I could have a C programmer writing scripts for the web in only a couple of days”.

I don’t ever recalling asking a C programmer to make me a web application!

Ruby on the other hand was designed to take the best from a number of languages to create something that was a joy to work with, it has taken cues from Smalltalk, Perl, LISP and others, and it shows.

A very big difference between PHP and Ruby for me was that Ruby encourages you to work with their basic data types like Hashes and Arrays where I never found them natural in PHP. The number of times I had to look up the order of arguments for String and Arrays in PHP is mind boggling.

The number of times I couldn’t remember if this or that function had underscores or not was equally as annoying. I used Zend IDE so I didn’t have to remember but I didn’t like the IDE. It felt like you were damned if you did and damned if you didn’t. There is no consistency in PHP’s standard library and it’s frustrating as an enraged bear in a telephone box. In Ruby, I rarely spend any time in documentation for common data types because the common interactions are so easy to remember.

Once you start using features in Ruby’s Enumerable module, you’ll wonder how you ever lived without it, pinky swear!


Michael: I think this is a reflection of the low-barrier to entry and the inherit curiosity of PHP developers to really understand what is going on. I had read/studied hundreds of white papers, blogs, articles on authentication systems – but it wasn’t until I built my own that I truly felt as if I knew what was going on. I believe new PHP developers are eager to share what they’ve done with the rest of the world and are frequently slammed for doing so, because they didn’t follow best practice or proven security patterns.


10 - Community and documentation are many times more important than the framework/language itself. How does Ruby or PHP’s community compare to the other?

Michael: I think both PHP and Ruby have serious issues in their documentation – and for completely opposite reasons.

PHP has tons of documentation, thanks to its seniority – you can find the answer to any question with a quick Google search and it’s going to work. Is it the best solution? Maybe, maybe not …

Rails has been growing so quickly, that even I have a hard time keeping up.

Ruby has great documentation, but in reality this appears to be a framework vs. framework question, so we’ll assume Rails. Rails has been growing so quickly, that even I have a hard time keeping up. Rails API documentation is great; but when it comes to third-party documentation (books, blog articles, StackOverflow responses) – they’re all out-dated and while following along with this information it is very difficult to debug the problem and fix it.

In this respect, I believe PHP has the advantage as the individual frameworks (CodeIgniter, FuelPHP, Kohana, CakePHP, etc) can mitigate this effect to some degree – if you are using one of these frameworks it is simple to go find the definitive answer for what you are looking for.


Ryan: When I was using PHP, a lot of emphasis was put on how awesome the comments in the PHP.net documentation was. The philosophy seemed to be to ‘write the documentation once, and let people add their two cents’. The problem with this is that comments are laid out in order of posting which means the good ones do not filter to the top, and any insights shared in them were not worked into the documentation in a timely manner (or at all).

So much of the common API is included in the PHP core, which doesn’t change that often, so I think a wiki solution would be more appropriate. That way the community could modify the official documentation, suggest changes, suggest examples, integrate the good from the comments into what people see first. That would be useful (especially to a beginner).

Java courses teach people about polymorphism first and look at what they do – design with class hierarchies as a first cut! It makes me crazy!

In Ruby, a lot of the commonly used libraries are on GitHub, where people can submit small changes and improvements which get rolled into what is generally a regular release cycle. Documentation is paired up in code using RDoc (which is similar to PHPDoc), and when you install a gem it generates documentation on your local system. For much of my work, I’ll either be reading core documentation on rubydoc.info, or locally on my machine, or if any of those fail the libraries’ source code itself.


Conclusion

We've heard Ryan and Michael's thoughts, and you most certainly have your own views. Continue the debate in the comments!

February 09 2011

03:16

Top 10 Pitfalls When Switching to Vim


Admit it: every time you see a person using Vim, you consider the possibility that they know something you don’t. Why else would they be using an editor that, in your mind, is dated, open-source junk? Think what you wish, but there’s a reason why top developers swear by Vim.

Until you’ve spent at least a month working every day with the editor, you’ll undoubtedly hate it! This is specifically why the majority of newcomers will play around with Vim for a day, become disgusted, and never touch it again. What’s unfortunate is that, if these developers could get beyond the pitfalls, they’d be introduced to incredible speed and flexibility.


1. There’s Too Many Modes

It’s true: Vim is not your standard code editor (it’s better). Transitioning from, say, TextMate to Vim is going to be an entirely different process than switching from TextMate to Espresso. Always keep that in mind when you find yourself tearing our your hair because Vim seemingly refuses to enter text when you type.

Though there are multiple modes in Vim, we’ll focus on the three most important. But before we continue, note that each key serves a different function, dependent upon which mode you’re currently in. Even more confusing — at first — a capital letter triggers a different action than a lowercase.

In command mode, pressing the lowercase “i” will trigger “Insert Mode.” However, an uppercase “I” will move the cursor to the beginning of the line. This might sound confusing, but it provides you will incredible power!

  • Command: By default, Vim should rest in command mode. Think of this mode as the “getting around” mode. While, in a traditional editor, you might be accustomed to using the mouse or the arrow keys to traverse your document, Vim’s command mode makes the process quicker and “mouse-less.”
  • Insert: Pressing the lowercase “i” in command mode will switch you into “Insert Mode.” Newcomers to Vim will find this mode to be familiar. As a result, though, they often remain in this mode far longer than they should (I know I did). As a rule of thumb, insert mode should purely be used for the sole purpose of inserting text. When finished, immediately return to command mode.
  • Visual: Think of visual mode as “selection” mode. Need to select the next five lines and delete them? With a normal code editor, you could use the mouse to visually select five lines, and then press the backspace key. With Vim, on the other hand, you’d press capital V to switch to Visual mode, and then type 5J to select five lines down. Finally, you’d press d, for delete.

I know this sounds incredibly confusing at first. You might think to yourself, “All that work just to delete five lines?” The truth is, though, this method is significantly faster.


2. It’s an Ancient Editor

Why would you turn your nose up at over three decades of development?

You might hear your friends say, “Isn’t Vim an ancient code editor?” Well, you could say that; it’s been around for over thirty years. Though honestly, why would you turn your nose up at over three decades of development? That’s longer than I’ve been alive! Better yet, even to this day, Vim is under active development. The most recent release, 7.3, was made available in August, 2010.

Secondly, it’s important to keep in mind that Vim is not Vi. If your only experience is with the latter, take some time to download the latest release and toy around with the new features. You’ll be pleasantly surprised!


3. But I Love TextMate Snippets

If Vim can’t natively do it, you can bet that there’s a plugin available somewhere!

You’ll quickly find that, if Vim can’t perform a particular task, then it’s likely that a plugin has developed to provide that functionality. For instance, consider TextMate’s excellent snippets feature. While Vim doesn’t support this natively, you can download the snipMate plugin, which should make the experience virtually identical to what you’re used to.

Learn More About Switching to Vim from TextMate


4. I Can’t Use the Arrow Keys

The less movement, the better.

Firstly, this isn’t true. It might have been the case with Vi, but you’re free to use how Vim in the way that feels most comfortable to you. So use the arrow keys to your heart’s content — though keep in mind that there’s a reason why most Vim users don’t.

The H, J, K, L keys mapping to left, down, up, and right, respectively, serve two purposes:

  • No Choice: Back in the day, machines didn’t have those helpful arrow keys. As such, they had little choice but to choose the best alternative.
  • Less Movement: If your hands generally rest along the second row of the keyboard, it makes little sense to repeatedly move your hand to the lower-right portion of the keyboard every time you want to move the cursor. The less movement, the better. With this arrangement, you can traverse your documents without moving an inch.

When all is said and done, you are the person using the editor. If, at first, you feel more comfortable using the arrow keys, then by all means do!


5. I’m a Designer, Dude

That’s okay! Vim is not for everybody. As a person who at least attempts to do design work from time to time, I can fully attest that Vim may not be the best fit for designers.

Developers are not designers; it’s only natural that this fact will be reflected in their choice of editors.

If you find that the bulk of your days are spent working with HTML and CSS, then maybe Vim is not for you. Now, that’s not to say that you shouldn’t give it a shot; but it’s certainly understandable, should you decide to stick with a more designer-friendly editor, such as Coda.


6. Vim Offers Nothing My Current Editor Doesn’t Already Do

Plain and simple, that’s rubbish. Certainly, every editor does have its strong points, but you’ll find that Vim is incredibly powerful, and, more importantly, flexible. There are hundreds upon hundreds of plugins available (for free) that will provide support for virtually any kind of functionality that you require.

Many newcomers often cite the built-in “Change Inner” command as a huge selling point. It certainly was for me! Let’s say that you have the following piece of code:

var joe = 'plumber';

Assuming that the cursor is at the beginning of that line, and you wish to change the value “plumber” to “black,” traditionally, you might use the arrow keys or the mouse to select and change the text. With Vim, the process is hugely simplified. Simply type: ci". This stands for “Change Inner Quotes,” or, find the next set of single quotes, and change the value inside.

Kick-Ass Plugins

  • snipMate: Allows you to, for instance, type
    + tab, and have a full div element expanded. It’s tremendously helpful.
  • Surround: Wrap portions of text with parens, tags, braces, etc.
  • NerdTree: Explore your filesystem and to open files and directories. It presents the filesystem to you in the form of a tree which you manipulate with the keyboard and/or mouse. It also allows you to perform simple filesystem operations.
  • TComment: Easily and quickly comment certain lines of your code.
  • Sparkup: Similar to ZenCoding, but provide more support for applying values to elements as well, such as: ul > li { My list item text. }.

7. My Vimrc File is Blank

This was an initial gripe that I had with Vim, as well. When first launching, say, MacVim, you’re thrown into the wolf-pack! No code highlighting, no formatting, no smart indenting… no nothing! Particularly if you’re using a custom Vim editor, there should at least be a base vimrc file to get you started. It can be an intimidating experience trying to figure out how to apply your custom preferences.

For those unfamiliar with a vimrc file, it’s essentially a file that allows you to specify your editor preferences.

Use this as a starter (click the Expand button below):

" .vimrc File
" Maintained by: Jeffrey Way
" jeffrey@jeffrey-way.com
" http://net.tutsplus.com
"

"Forget compatibility with Vi. Who cares.
set nocompatible

"Enable filetypes
filetype on
filetype plugin on
filetype indent on
syntax on

"Write the old file out when switching between files.
set autowrite

"Display current cursor position in lower right corner.
set ruler

"Want a different map leader than \
"set mapleader = ",";

"Ever notice a slight lag after typing the leader key + command? This lowers
"the timeout.
set timeoutlen=500

"Switch between buffers without saving
set hidden

"Set the color scheme. Change this to your preference.
"Here's 100 to choose from: http://www.vim.org/scripts/script.php?script_id=625
colorscheme twilight

"Set font type and size. Depends on the resolution. Larger screens, prefer h20
set guifont=Menlo:h14

"Tab stuff
set tabstop=3
set shiftwidth=3
set softtabstop=3
set expandtab

"Show command in bottom right portion of the screen
set showcmd

"Show lines numbers
set number

"Prefer relative line numbering?
"set relativenumber"

"Indent stuff
set smartindent
set autoindent

"Always show the status line
set laststatus=2

"Prefer a slightly higher line height
set linespace=3

"Better line wrapping
set wrap
set textwidth=79
set formatoptions=qrn1

"Set incremental searching"
set incsearch

"Highlight searching
set hlsearch

" case insensitive search
set ignorecase
set smartcase

"Hide MacVim toolbar by default
set go-=T

"Hard-wrap paragraphs of text
nnoremap <leader>q gqip

"Enable code folding
set foldenable

"Hide mouse when typing
set mousehide

"Shortcut to fold tags with leader (usually \) + ft
nnoremap <leader>ft Vatzf

" Create dictionary for custom expansions
set dictionary+=/Users/jeff_way/.vim/dict.txt

"Opens a vertical split and switches over (\v)
nnoremap <leader>v <C-w>v<C-w>l

"Split windows below the current window.
set splitbelow              

" session settings
set sessionoptions=resize,winpos,winsize,buffers,tabpages,folds,curdir,help

"Set up an HTML5 template for all new .html files
"autocmd BufNewFile * silent! 0r $VIMHOME/templates/%:e.tpl

"Load the current buffer in Firefox - Mac specific.
abbrev ff :! open -a firefox.app %:p<cr>

"Map a change directory to the desktop - Mac specific
nmap <leader>d :cd ~/Desktop<cr>:e.<cr>

"Shortcut for editing  vimrc file in a new tab
nmap <leader>ev :tabedit $MYVIMRC<cr>

"Change zen coding plugin expansion key to shift + e
let g:user_zen_expandabbr_key = '<C-e>'

"Faster shortcut for commenting. Requires T-Comment plugin
map <leader>c <c-_><c-_>

"Saves time; maps the spacebar to colon
nmap <space> :

"Automatically change current directory to that of the file in the buffer
autocmd BufEnter * cd %:p:h

"Map code completion to , + tab
imap <leader><tab> <C-x><C-o>

" More useful command-line completion
set wildmenu

"Auto-completion menu
set wildmode=list:longest

"http://vim.wikia.com/wiki/Make_Vim_completion_popup_menu_work_just_like_in_an_IDE
set completeopt=longest,menuone
inoremap <expr> <CR> pumvisible() ? "\<C-y>" : "\<C-g>u\<CR>"
inoremap <expr> <C-n> pumvisible() ? '<C-n>' :
  \ '<C-n><C-r>=pumvisible() ? "\<lt>Down>" : ""<CR>'
inoremap <expr> <M-,> pumvisible() ? '<C-n>' :
  \ '<C-x><C-o><C-n><C-p><C-r>=pumvisible() ? "\<lt>Down>" : ""<CR>'

"Map escape key to jj -- much faster
imap jj <esc>

"Delete all buffers (via Derek Wyatt)
nmap <silent> ,da :exec "1," . bufnr('$') . "bd"<cr>

"Bubble single lines (kicks butt)
"http://vimcasts.org/episodes/bubbling-text/
nmap <C-Up> ddkP
nmap <C-Down> ddp

"Bubble multiple lines
vmap <C-Up> xkP`[V`]
vmap <C-Down> xp`[V`]

" Source the vimrc file after saving it. This way, you don't have to reload Vim to see the changes.
if has("autocmd")
 augroup myvimrchooks
  au!
  autocmd bufwritepost .vimrc source ~/.vimrc
 augroup END
endif

" easier window navigation
nmap <C-h> <C-w>h
nmap <C-j> <C-w>j
nmap <C-k> <C-w>k
nmap <C-l> <C-w>l

"------------------------"
"NERDTREE PLUGIN SETTINGS
"------------------------"
"Shortcut for NERDTreeToggle
nmap <leader>nt :NERDTreeToggle <CR>

"Show hidden files in NerdTree
let NERDTreeShowHidden=1

"autopen NERDTree and focus cursor in new document
autocmd VimEnter * NERDTree
autocmd VimEnter * wincmd p

"Helpeful abbreviations
iab lorem Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.
iab llorem Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. 

"Spelling corrects. Just for example. Add yours below.
iab teh the
iab Teh The

" Get to home dir easier
" <leader>hm is easier to type than :cd ~
nmap <leader>hm :cd ~/ <CR>

" Alphabetically sort CSS properties in file with :SortCSS
:command! SortCSS :g#\({\n\)\@<=#.,/}/sort

" Shortcut to opening a virtual split to right of current pane
" Makes more sense than opening to the left
nmap <leader>bv :bel vsp

" Saves file when Vim window loses focus
au FocusLost * :wa

" Backups
set backupdir=~/.vim/tmp/backup// " backups
set directory=~/.vim/tmp/swap// " swap files
set backup " enable backup

" No more stretching for navigating files
"noremap h ;
"noremap j h
"noremap k gj
"noremap l gk
"noremap ; l

set showmatch " show matching brackets

" print empty <a> tag
map! ;h <a href=""></a><ESC>5hi

8. I Don’t Want to use the Terminal

Me neither — at least not more than I have too — there are a variety of dedicated Vim editors which provide a more Windows/Mac GUI-like experience.

These editors will provide support for the sorts of keystrokes that are ingrained into your body, such as “Command + F” to search, or “Command + W” to close the current window.


9. It’s too Difficult to Learn without a Teacher

Venturing into Vim

Well I suppose that depends on if you’re more of a visual learner. However, if that’s the case — promo alert — you might consider checking out our “Venturing into Vim” 4-week course. What’s unique about this series is that I recorded each episode in real-time, as I was learning Vim for the first time. The advantage to this is that you’ll get a far more practical overview of Vim. What confused me at first will undoubtedly confuse you as well!

You can purchase it on the Tuts+ marketplace for $9.

Remember how, in school, sometimes, the student sitting next to you was able to explain and help you understand some difficult concept more than the teacher? The reason is because, once you’re mastered a craft, it’s difficult to recall what personally gave you the most trouble. From September to October, I embarked on a four-week challenge, which I call “Venturing into Vim.” After hearing countless extremely talented developers praise this seemingly decade-old code editor, I decided that it was worth a month of my time to figure out why so many people consider Vim to be the best editor on the planet.


10. I Can’t Edit Files on my Server

Of course you can, though, admittedly, it’s not quite as user-friendly as, say, Coda’s remote server feature. Speaking of Panic, if you’re a Transmit user, you might consider installing the Transmit FTP plugin.

“This script allows you to upload the current file via Transmit directly from Vim. For it to work, you need to be working on a file that’s tied to a Transmit connection, and this connection must have “DockSend” enabled.”

With this plugin, when editing a file that has a Transmit connection (open file via Transmit), you only need to press Control + U to push those updates back to your remote server. It’s a cinch!


Sure – there are a handful of reasons not to use Vim. It has a steep learning curve, and requires a complete rethinking of how a code editor should function. That said, there are hundreds of reason why you should use Vim. The only question is: why aren’t you?

February 01 2011

00:04

11 Lessons Learned After Running a Massively Popular Blog


For the last three years, I’ve had the pleasure of managing Nettuts+ – a site with 80,000 subscribers, and over 3 million page views each month. In that course of time, I’ve learned a great deal about, not only what it takes to build an active community, but also the economics of running a sustainable and profitable blog. I’d like to share some of these lessons with you today.


1. It Takes a Village

While, on the surface, many of you may associate Nettuts+ specifically with me, the truth is that there’s an entire team here at Envato that is responsible for its success.

Keep in mind that you can certainly run a successful blog on your own, but, boy oh boy does it help to have multiple hands on deck!

Behind the Scenes

Keep costs to a minimum when first getting started.

Think about it: running a profitable blog can potentially require editor(s), writers, developers, designers, marketers, managers, etc. All of that costs money. I use the word potentially because there are numerous ways to skin a cat; always remember that.

To keep Nettuts+, and more largely, the Tuts+ Network, in tip-top shape, we require:

  • An editor to manage the day to day activities on the site (that’s me!)
  • A designer to keep the site’s visuals current
  • A developer(s) to integrate the required functionality on the site
  • A marketing guy/team to help generate revenue
  • Manager(s) to oversee the landscape of the Tuts+ network

Now, truthfully, this list doesn’t even scratch the surface, though it’ll do for the sake of this article. Does this mean that you can’t start a blog on your own? Absolutely not; in fact, keep costs to a minimum when first getting started. You can accomplish many of these tasks on your own — at least at first.


2. You’re Not Allowed to Make Money

Of course, this comment is somewhat made in jest, but, you’ll quickly find that a blog which earns a bit of money somehow irritates certain members of your community. Some feel that the inclusion of, say, a banner ad reduces the quality or respectability of your brand.

What? You guys are trying to create a sustainable environment for this blog? Sell-outs!

I suppose the idea behind this line of thinking stems from that scary word: “commercial.” If you — gasp — make a living off of your contributions to the community, that, consequently, means that you run a — second gasp — “commercial blog.”

Think what you wish, but what’s the alternative? People have to live and put food on the table. To expect a site, like Nettuts+, to invest thousands upon thousands of dollars every month into educating the community, without any method to recoup those said costs is nonsensical and, more importantly, impossible.

This is specifically why the Tuts+ network offers a Premium program for those readers who want to:

  • A: Give back to Nettuts+, in exchange for providing a never-ending string of daily education.
  • B: Take their training a step further, with higher level and more in depth tutorials and screencasts.

3. You Must Engage

Inject yourself into your developing community.

Some blog owners/editors prefer to remain behind the scenes pulling strings, like a manipulator does to a marionette. That may work for some, but I tend to feel that this management style is unwise for a variety of reasons. Most notably, it’s vital that you, as the owner/editor/manager of a blog, inject yourself into your developing community. Doing so serves a variety of purposes:

  • Relationships: You build a personal relationship with your readers, as you get to know one another. Rather than Teacher -> Student, you should strive for Peer -> Peer.
  • Feedback: What better way to keep your “ear to the ground” than to immerse yourself in your site’s community, whether than come via the comments section, emails, or social networking sites.
  • Loyalty: Engagement builds loyalty. Readers are far more likely to frequent your site if they know you personally, than if you’re a faceless John Q.

IGN

I’ll tell you a quick, and somewhat nerdy personal story. When I was kid, I was a huge Nintendo fan (actually, still am). I’d frequent a site, called IGN, which specializes in gaming news. On the Nintendo channel, the lead editor, Matt Casamassina (who has since moved on to working at Apple) had an enormous fanbase, specifically for the reasons mentioned above. Whether in his reviews, or the quick office videos they put together, he approached his audience on a “hey guys” level, rather than a more formal approach.

As a result, he was far and away the most popular editor on IGN for years. Regardless of the writer of a particular Nintendo review, you were bound to find multiple reader comments containing something along the lines of, “But what does Matt think about this?” That’s 100% what you should strive for!

Make yourself synonymous with your blog.


4. You Have a Duty to the Community

At the point when you decide to turn your blog into a business, you must consider one important fact:

You have a duty to post accurate information.

Certainly, the validity of this statement will vary, depending on your field of interest, though it should remain at least partially true across all industries.

As a blog with 3 million page views a month, we have a duty to post valid content that conforms to the respective standards in our industry. In the case of Nettuts+, this translates to: we must post tutorials, which are forward thinking, and don’t promote dated technologies and techniques.

You’ll Fail

If your community is vibrant enough, though, they’ll keep you in tune, as to what does and doesn’t work on your site.

Now the truth of the matter is: you’re bound to fail at one point or another. Unless you have an MIT-trained team of fact checkers at your disposal, it’s nearly impossible to be 100% correct at all times. We’re not that smart.

On Nettuts+, we’ve posted some brilliant tutorials which simply aren’t available else where on the web. That said, and with full disclosure, we also have posted tutorials, which, in hindsight, could have been improved.

If your community is vibrant enough, though, they’ll keep you in tune, as to what does and doesn’t work on your site. They’ll also provide you with feedback on which authors are welcomed on your site, and which…aren’t.


5. Finding Quality Staff is Incredibly Difficult

Would you be surprised to find that, here at Nettuts+, I have quite a difficult time finding quality tutorials and writers for the site? We’re a massively influential web development blog, yet, even now, I struggle when searching for new authors.

Educational sites are difficult in this regard.

Many incorrectly assume that massive sites have massive rosters of writers at their disposal.

  • Talent: The phrase, Those who can…do is particularly relevant here. Quite often, those who are capable of writing high level/quality content unfortunately don’t have the time or financial need to write for blogs. Given the fact that we’re able to post a new tutorial or article every day proves that this certainly isn’t true, across the board. We continue to post content from incredibly talented developers on a daily basis, but nonetheless, it does make the process more difficult than you might anticipate.
  • Misconceptions: Many incorrectly assume that massive sites have massive rosters of writers at their disposal. Some might think to themselves, “I’d have a 1 in 100 chance of being accepted.” This absolutely is not the case.
  • English: As an English-based blog, that limits our potential author base to those who either speak English, or have learned it as a second language. The problem is that, more often than not, the grammar in tutorial submissions needs to be at least 90% correct. This typically is not the case with the latter, I’m sorry to say.

This is specifically why it’s imperative that you adhere to lesson number three (You Must Engage). By becoming an active member in your industry’s community, you’ll be more successful when it comes to finding authors for your site, than you would otherwise.


6. Open your Pocket-Book

This may come as a shock, but industry veterans cost a fair bit to hire.

This may come as a shock, but industry veterans cost a fair bit to hire. For a high quality, in depth article or tutorial from an industry veteran, you should expect to spend anywhere from $400 – $800 — at least in the web dev industry. Sounds expensive for a single article? Maybe – but these guys have spent their entire adult lives acquiring the necessary knowledge to write such a tutorial.

Nettuts+ adopts a flexible model, when it comes to purchasing guest tutorials. This expenditure will range, in the majority of cases, from $60 – $250. That said, we do make exceptions in certain cases, if the author/tutorial/concept warrants the cost.

When deciding on how much to offer, we consider a handful of arguments.

  • How in depth is the tutorial?
  • Has this topic been covered numerous times across the web?
  • How well-known is the author in the industry?
  • Will the article require a fair amount of editing?

With that pricing model in mind, I’m sure you can quickly realize how much it costs us to fund a month’s worth of tutorials. Banner ads aren’t pretty, but, without them, there’d be no Nettuts+.


7. Trolls Exist

This is the worst tutorial EVER!!

It’s a sad truth that, where there are comment forms, there exists trolls. Don’t worry; every successful blog in existence has received a terribly cruel comment or two — likely hundreds! Rather than curling into a ball at the sight of these sorts of replies, consider them to be a rite of passage.

In the mood for a laugh? This dramatization of a “troll” comment always makes me laugh.

Trolls vs. Criticism

However, don’t confuse trolls with legitimate criticism of your site’s content. Negative feedback will often be your greatest source for improvement. They’ll provide you with article corrections and inaccuracies. The old saying, “the best advice hurts your feelings” is absolutely true.


8. Readers are Scrollers

The print world doesn’t directly transfer over to the blogging arena. Though it certainly does, in terms of grammar and structure, an in depth blog posting is quite different from a chapter within a book.

Want proof? Take a new posting, and publish it as long string of paragraphs, like you may see in a book. Next, over the following several days, use an analytics tool to review how long visitors spend on the page. I promise you that you’ll find these numbers to be surprisingly low.

You have 3-5 seconds to pique a reader’s interest.

  • Investment: Those who purchase a book fully expect a time investment. Alternatively, a visitor to your blog is, more often than not, in search of a “quick fix.” You’ll surely find that they’re not willing to read a seemingly endless string of paragraphs. We have to trick them to do so!
  • Scroll Points: The key to a well-formatted blog posting is inserting “scroll points.” You have 3-5 seconds to pique a reader’s interest, before they move on to the next quick fix. To create scroll points in your postings, use a generous number of blockquotes, lists, call-outs, headings, numbered items…whatever you can think of. As an example, refer to this very article; notice how I’ve applied multiple levels of “scroll points.” We initially have numbered headings for each idea, but then, within each point, I’ve also inserted additional stop points to grab your attention. This allows for a more comfortable and flexible reading experience.

9. Find a Niche

If you attempt to cover the entire spectrum of your industry, you’ll alienate a large portion of your readership.

Every popular blog that I frequent has its niche. Think Nettuts+ doesn’t? Well, it’s true that “web development” is a rather broad focus, but more specifically, we focus on front-end development: HTML, CSS, PHP, and JavaScript. We even have a sub-niche that comes in the form of video tutorials. While they don’t bring in massive amounts of traffic, they have still managed to generate a loyal following from the readers who prefer a more visual style of training.

If you attempt to cover the entire spectrum of your industry, you’ll alienate a large portion of your readership. For example, on Nettuts+, while we could post Python and MODx tutorials every other day, we simply don’t have the audience to warrant the expenditure or the space. The same holds true for the less-used CMSs available around the web. Instead, we focus primarily on WordPress.

Need More Examples?

What if you don’t feel skilled enough, yet, to write articles about your industry? That’s okay, too; use it to your advantage! Create a blog which chronicles your progress in your field. Thousands of people around the world are in your exact same shoes; they’d enjoy reading the blog of somehow who is encountering the exact same difficulties and confusions as you.


10. Don’t Half-Ass It

“If you’re gonna do it…do it right!”

Though that quote is admittedly vague, it applies to nearly all facets of life. If your goal is to run a successful and profitable blog, don’t half-ass the job. I’m sure you’re familiar with the “talkers” — you might even be one yourself.

Sometimes the dream is more exciting than the reality.

“Talkers” spend more time speaking about what their business is, and how it’s going to change everything, rather than physically working toward making that concept a reality.

I’ve witnessed this “loss of enthusiasm” first-hand on multiple occasions. I suppose it’s understandable, though; sometimes the dream is more exciting than the reality — the reality of working your tale off, writing well into the night. It’s much easier to live in your imagination and prepare CEO name plates for your desk, than it is to build a business.

Outline

Before even picking up a pencil — or, in this case, typing a key — determine who it is that you want to be on the web.

  • Special: What makes you special? Not in the Mr. Rogers sense, but in terms of your point of view. Is your plan to follow the pack and release a copy-cat blog? Hopefully not.
  • Distinction: This item travels hand-in-hand with your point of view. How will your blog distinguish itself? Can you converge your ideas into a single sentence? If not, perhaps your blog needs a bit more planning. At Envato, “we help people earn and learn, online.” The movie, Julie and Julia, tells the true story of a girl who created a blog, which served the sole purpose of documenting her progression through a cookbook. That simple and relatable concept transformed her blog into a massive success (and a movie). On Nettuts+, we strive to be “the best online resource for front-end web development training.” What about your blog?
  • Format: What format will your postings take? On Nettuts+, we focus on screencasts and in depth tutorials. Will yours be centered around quick tips? Video? Opinionated rants? Hilarious comics?
  • Service: All blogs must provide some form of service to the reader. This can come in the form of news updates, education, pop culture updates, comedy, etc. Try to determine what your blog’s service is, or will be. Once you’ve decided, you better damn well execute that service better than all of your blogging peers. Honestly, if that’s not your ultimate goal, then what’s the point? Don’t half-ass it.

11. Show Some Passion

Passion is contagious.

Passion is contagious. We’ve all met that person who is utterly consumed by their industry. Isn’t that enthusiasm infectious? It certainly is for me, and I assure you that it is for your readers.

Passion can be a scary thing — or better put, the lack of passion can be a scary thing. It has the potential to dissolve careers, bury businesses, and ruin relationships. So what about you? Do you genuinely have a passion for what you’ll be blogging about? Be honest! It might be smarter to ask yourself this question one night, long after the rest of the world has fallen asleep, as you lay awake. I find that our thoughts are more honest at these points.

An easy way to quantify passion is to ask yourself if you’d be willing to run your blog for free — indefinitely. Take money out of the equation, when deciding.

Income, though certainly the overall goal, needs to come second. The irony is, of course, more often than not, there’s a direct correlation between passion and profit.

I saved this item for last, because I strongly feel that it’s the primary key to a successful blog. Engagement, teamwork, marketing, the concept…that all factors into success. But if there’s no passion at the root, you’re doomed to fail.

Tags: General

January 14 2011

21:41

The State of Video on the Web


A few days ago, Google announced that they were dropping support for the H.264 video codec in its popular browser, Chrome. In light of that, today, we’re going to take a look at the ramifications and current state of video on the web.


A Little History

Thanks to fast internet connections and the cost of bandwidth plummeting rapidly, serving video over the internet has become quite popular. That said, playing videos on the web remained an extremely messy affair. There was a mess of codecs and containers to deal with and no direct way to stream content. This void was filled by three solutions: Windows Media, QuickTime and Real Media; they quickly took over the entire market.

Windows Media

I definitely remember this!

Few expected the trio to be dethroned, never mind this early. And yet, that’s what happened when Flash video completely took over the entire web streaming market — practically making the others vanish, sometime around 2005. The others are still alive and kicking, of course, but up until a recently, Flash video was pretty much the only fool-proof, compatible and easy way to get your streaming content on a web page.


Introducing the HTML5 Video Element

Developers all over the world recognized the gaping hole that Flash exposed in the HTML specification and devised the HTML5 spec to fill in the void. The web needed a first class citizen for video, much like images, that browsers could play natively –without having to rely on a plugin, be it Flash, Silverlight, Quicktime, or something else.

And thus, the video element was born.

HTML5 defines a standard way to embed video content in your web sites: through the video tag.

Support for this standard, both among browsers and content distributors, like Youtube and Vimeo, has been increasing at a rapid pace. Needless to say, this element, along with canvas, has almost been the face of HTML5.


The Competing Codecs

This is where things have gotten a bit dicey. The HTML5 specification doesn’t specify which video formats, containers or codecs the browser should support through the video tag. Each browser maker is free to choose, and support, any format which they deem appropriate.

Ogg Theora was initially the forerunner for the standard video format but was later removed from the specification, replaced with a more vague specifications. Currently, there are three main codecs that are vying for you attention today:

  • H.264
  • VP8
  • Theora

I’ll talk more about the most relevant codecs: H.264 and VP8. Theora, while a contender, isn’t really in the running for the lead so we’ll skip over it. I don’t think we’ll need to go over the concept of a video container today as well.


H.264′s Background

H.264

H.264, also popularly knows as AVC, was developed as a collaborative effort of a number of groups, including the famous MPEG.

It is currently one of the more technically advanced codecs available and provides better frame quality at a much lower bitrate. For the non-techies, you get superior quality at much smaller file sizes.

This is the primary reason why H.264 is used in a large number of places, chief among them being your television stations that broadcast in high definition and high definition optical media, like BluRay.

In addition to quality, H.264 has a number of other things going for it. Content compressed with this codec can be played back by a number of non-PC devices. Reading this on an iPhone? Yep, you can watch H.264 content. Your gaming consoles? Absolutely!

Another point to note is that a lot of said devices have dedicated hardware to decode this type of content. This is why your portable devices have such impressive battery lives. Without hardware support, their CPUs would simply wilt.


VP8′s Background

WebM

VP8, a relatively new codec, is the brainchild of On2 — the same guys behind Theora. Google acquired On2 in 2010, and opened up all the underlying patents for the codec into the public domain.

WebM, the container of choice for most current browsers, utilizes VP8 for compressing its video content and Vorbis for its audio. It produces content similar in quality to H.264.

It is completely royalty free, now and for the future. On the downside, though, it has limited hardware decoding support as well as third party device/mobile support.


Google’s Decision to Drop H.264

As mentioned in the excerpt, Google recently removed support for H.264 from the Chrome browser. This throws a monkey wrench into H.264′s growth among web videos and leaves Internet Explorer and Safari as the only remaining browsers backing the codec. Google’s statement below:

We expect even more rapid innovation in the web media platform in the coming year and are focusing our investments in those technologies that are developed and licensed based on open web principles. To that end, we are changing Chrome’s HTML5 <video> support to make it consistent with the codecs already supported by the open Chromium project. Specifically, we are supporting the WebM (VP8) and Theora video codecs, and will consider adding support for other high-quality open codecs in the future. Though H.264 plays an important role in video, as our goal is to enable open innovation, support for the codec will be removed and our resources directed towards completely open codec technologies.


Google’s Decision: A Brief FAQ

We’ll take a quick look at some questions you might potentially have.

Why the sudden change of heart?

Issues of licensing, royalties and openness. H.264 requires royalties for specific scenarios while VP8 and Theora are completely open.

I’ve heard that H.264 is free for a lot of uses. Is there more to it?

While currently free, if the content is distributed free of charge, it isn’t set in stone. Remember that MP3 had quite liberal licenses early on as well. H.264′s licenses change periodically, 5 years or so, so something that’s free today may not necessarily be so tomorrow. There are no such issues with VP8.

Is this a way of Google trying to control which format the web uses?

Not really, no. WebM is already supported by Opera and Firefox [upcoming versions]. It is also backed by a good portion of the web community. It is much more a question of openness than control.

Editor’s Note: That said, is it not fun to watch the silent slaps in the face that Apple, Google, and Microsoft throw? Tensions between Google and Apple have increased quite a bit in recent months.

What if Google suddenly becomes evil and starts charging royalties?

VP8 is under a BSD license. It is also under an irrevocable free patent license. This is about as close as you can get to free. You won’t have to fess up royalties, now or in the future. Period.

Firefox users can already view H.264 content with a plugin. So what’s new here?

Plugin is the keyword here. Instead of becoming a first class element, video is, again, delegated to plugins. If you’re going to install a plugin to watch H.264, why not just use Flash? It’s not as bad as people make it to be!

So I can use plugins to watch H.264 content?

Absolutely, Pipe it through Flash or Silverflight or whatever floats your boat. There’s just no native support.

Google already bundles Flash, a closed platform. Logic failure?

Nope, not even close. Flash, the player, doesn’t require royalties. In fact, you can take the specification and create your own player. Chrome just comes bundled with Flash for easier logistics.

H.264 is everywhere, goshdarnit!

It sure is. But I believe a contender must be chosen, based on merits and licensing, not just the former. This applies even more for the web, a messiah of openness.

But, but, I shoot all my videos in H.264. Encoding it with another codec is annoying.

You’re probably already compressing it before uploading it to the video service of your choice. Why not simply compress it with VP8? Also, if you are the provider, you’re already re-converting user uploaded videos. Just convert to VP8 now!

But WebM converters suck!

Touche, my friend. Compared to H.264, the tools at hand are sparse. We need to wait it out while someone fills the market’s demand.

Why remove support for it now?

Because the spec, and the war, isn’t over, not by a long shot. Google can afford to make a change here and prevent a H.264 monopoly in the future.


What this Means for a Regular User

To a regular Joe web surfer, nothing changes for you. As long as you use a modern-ish browser, you can continue consuming web video content, be it YouTube or Vimeo – as long as the provider transcodes the content and server them efficiently and effectively. In fact, you don’t even have to use a modern browser if the provider provides decent fallbacks

In your world, nothing changes. It’s just a bunch of geeks talking about things that you can’t even vaguely comprehend.

If you’re a mobile user, though, you’re in for a world of trouble. With most mobile platforms locked down so hard [Apple, I'm looking at you], changing browsers on your every whim is hard. Additionally, most mobiles only have hardware to decode H.264, not VP8. This means two things:

  • Possible choppy performance: Without dedicated hardware decoding, performance may possibly suffer for higher quality videos.
  • Worse battery life: As your CPU continues to thrash trying to decode your content, your battery life is going to take a big hit.

Yes, I know it sucks.


What it Means for a Web Content Producer/Distributor

For desktop users, it really doesn’t change much for you either. If you’ve been already serving content appropriately encoded for every browser, you should be alright for now. Remember, you’ve already had to serve WebM or Theora content for Firefox and Opera; so nothing changes for desktop users.

For mobile users, it, again, is a mess. No mobile browser supports WebM or Theora as of now, while almost every mobile has dedicated hardware for H.264. In order to accomodate everyone, you’ll need to have two version: one encoded with H.264 for mobile users, and another with WebM/Theora for everyone else.

You’ll have to face doubled computational costs and storage. Or you can choose to skip HTML5 video altogether and go with Flash for serving content but, uh-oh, iOS devices can’t play Flash content.

If you have to serve video content for mobile users and are facepalming right now, we can understand your plight and you have our sympathies. Fight on, soldier!


What it Means for Flash and HTML5 Video

In the short term, further adoption of the video element can suffer as developers wait for the dust to settle before making a decision regarding implementation. You’d probably not want to go with a technology that may be doomed to fail. This also means that usage of Flash for video content will possibly spike over the next few months, ironically.

In the long term, it will lead to a stronger and more open web. No one wants a repeat of the GIF or MP3 fiasco and I feel it’s right that Google has finally dropped support for the codec. Props to Mozilla as well for not giving in amidst uproar over not supporting the codec.


Codec Support in Modern Browsers

WebM

Universal pricing table from GraphicRiver.

This is how the compatibility chart will read a month from now, when Chrome drops H.264 and Firefox and Internet Explorer adopt WebM.

With mobile browsers, the situation is simple enough to not warrant a chart. Every mobile browser support H.264 and nothing else.


That’s a Wrap

I hope that you’ve found this write-up interesting. We’ve tried to go with a slightly different topic today, diverging from our usual web development content. I’m sure there are lots of perspectives I’ve missed in this article, so remember to chime in with your comments. Thank you so much for reading!

January 07 2011

16:53

December 27 2010

21:44

Expedite your Workflow with Macros


I’m a productivity tool freak. As I see it, if a short-cut saves me a few moments over the course of the day, then it has the potential to save roughly twenty hours worth of work each year! As such, I religiously use tools like TextExpander, Snippets, Coda, Structurer, LaunchBar, etc. But today, I want to show you how to use a macro program, like Keyboard Maestro or AutoHotKey, to expedite repetitive tasks. You’ll love it!



Conclusion

I’ve preached the wonders of macros in the past, but was often asked about how I specifically use them. Hopefully, this video will provide you with some inspiration and ideas. Let me know what you come up with!

December 21 2010

19:29

This Damn Industry


Editorials on Nettuts+ are few and far between, but, given that we’re nearing the end of yet another year, I thought it might be nice to have a discussion on one sleep depriving aspect of this web development industry that we’re all privy to: it’s forever twisting and turning.

To those of you who have five or more years of experience: knowing what you know about about the steep, never-ending learning curve, would you be willing to start all over?

The more you learn, the more you realize how little you know.


An Example

Take me, for example: I’m 25, and have been working in this industry, in various forms, since college. By any other corporate measurement, I’m a baby — barely worthy of opening his mouth during a team meeting. However, our particular web development industry is a bit different in this regard: we’re young. Many of the developers who are rapidly pushing the web forward are under 30; how simultaneously amazing and depressing at the same time!

Depressing? Sure: depressing. They say that, in Mathematics, if you haven’t had your great idea by the age of 30, you’ll never have it. Of course, I use the generic “they say” because I’m really referring to a line from the movie, “A Beautiful Mind” — but I digress. The advantage to youth is all around us: it’s in the music you listen to, the JavaScript frameworks you love, the tools you use, etc.

Ever notice how your favorite music artists rarely achieve the same level of “magic” in a new album a decade after they entered the music industry? Why is that?

Perhaps, when you’re young, you’re open to new ideas, and question the status quo. Or maybe, fifteen-twenty years later, you don’t have the same drive as you did before. Rocky Balboa would refer to this as the “eye of the tiger”… or the lack thereof. He once lost it…and bad things happened.

Now certainly, this doesn’t transfer over “pin-for-pin” to our little ole’ web development environment, but it’s fair to say that it does in some small form.

My Days

Even when I get paid to learn, I’ve still found that it’s impossible to keep up with the pack.

A large portion of each of my work days is spent learning new technologies. Whether that comes in the form of deciphering the CSS3 Spec, or traversing through countless blogs (thanks, Instapaper!), my job requires me to stay up to date on the latest trends and techniques. I can’t tell you how often my laptop is brought into bed, as I work on a project long after the misses has fallen asleep. My gut tells me that we’re all familiar with the ubiquitous “laptop in bed” syndrome, as well as the hot groin effect. That said, even when I get paid to learn, I’ve still found that it’s impossible to keep up with the pack. For instance, let’s review a short list of exciting new technologies or scripts that I’ve yet to play around with:

  • CoffeeScript
  • NodeJS
  • ControlJS
  • LabJS
  • Raphael
  • Ruby / Rails
  • The Kohana Framework

Perhaps even more depressing, that list only amounts to what I was able to think of within a moment or so. In another six months from now, that list will triple.

Even scarier, at 25, it stands to reason that, within five years or so, I’ll have children. Right now, save a few scoldings from my fiancée — typically when she’s ready to leave the house, while I continually say, “5 more minutes” – I’m able to spend as much time as possible coding away in a room that’s long since gone dark, after the sun went down; because, of course, I can’t be bothered to turn on the lamp when I’m working!

To the Moms and Dads

To those of you who have full-time jobs, wives (preferably just one), and children: how do you find time to continue learning? Or, maybe better put: when do you find the time?


Why do we Keep Learning?

“Two mice fell into a bowl of cream. The first mouse gave up and died right away. The second mouse fought and swam until he churned that cream into butter and he crawled his way out.” – Christopher Walken

So this brings up the question: who do we continue learning new techniques, if those same techniques will invariably become out-dated within a couple years or so? How many useless, old tech books do you have lying around the house?!

I imagine that each of us continues the learning process for a variety of reasons.

  • Passion: From time to time, I mildly complain that it seems as if I never have time to relax, and, say, play that new video game I purchased a month ago, but haven’t yet dug into. Though, if I’m honest, it’s because, during my free time, I genuinely enjoy toying around with some new framework or personal project. As you’re reading this article right now, it stands to reason that you’re the same way.
  • Obligation: Perhaps your particular job requires that you stay on top of the latest trends, and aware of the specific changes/updates in each new browser version.
  • Competition: Is it possible that you neglect your friends in favor of a monitor because of competition with your peers? Do you worry that you’ll be passed by, if you take a month’s vacation?
  • Necessity: We’re invariably inspired by the websites we browse. Intrigued by Apple’s use of CSS3 animations on their website? Well, if you want to mimic that sort of effect without JavaScript, you’ll need to dig into some CSS3 articles on our website, or Andy Clarke’s excellent Hardboiled Web Design book.
  • Enjoy Punishment: Then again, it’s also possible that you enjoy brushing your teeth with a bottle of Jack, and grinding your teeth on the barely-readable HTML5 spec. Whether we admit it or not, I’d wager that we all fall into this camp. There’s a unique sense of pride that comes from learning frameworks and techniques that .1% of the population are capable of understanding.

[...] There is a world of beauty and intellectual challenge that is denied to 99.9 percent of those who are not high-level mathematicians.
– Andrew Wiles

If you’re somewhat like me, I’d imagine that you’ll identify with each of the possibilities above — at least in some small form.


What’s your Point?

Okay, okay; so is there a point to all this rambling? Maybe so; maybe not — editor’s prerogative!

Mostly, my goal today is to selfishly find solace in the fact that, like myself, others, too, stay awake at night, struggling with this frustrating, age-inducing and rapidly progressing industry.

Forget your years of experience: if you take even a year or two’s break from this industry, you’ll find yourself right back at the beginning, once again holding the title of “noob.” But seriously, do any of us ever truly get away from that word entirely? I’ve been using WordPress for years…but I still refer to the WP codex on a daily basis.

So the next time your heart-rate increases, as you, once again, attempt to wrap your mind around some new technique, or way of coding (think web forms vs. MVC), always remember: we’re all in this together; we all feel behind the pack. But, then again, we stay the course because we love this damn industry.


Conclusion

As this article concludes, I have only three questions for you, John Q reader:

  • How do you deal with the constant progression of our industry, and the understanding that, if you take a year off, you’ll feel obsolete?
  • Knowing what it took to get where you are today, would you be willing to start all over, if the clock was rolled back?
  • Why do you read Nettuts+ every day?
Tags: General

November 22 2010

15:04

But it Doesn’t Validate


I have a small pet peeve that I’m going to share with you. On the nights when I finish up a new CSS3 tutorial for Nettuts+ — typically while listening to my favorite Biebster songs — I click publish, and then wait to see how long it’ll take before a reader leaves a comment containing the phrase, “But it doesn’t validate.”


Thanks for the Input!

Here’s the thing about validation: it’s a tool. Nothing more; nothing less; just a tool.

So here’s the thing about validation: it’s a tool. Nothing more; nothing less; just a tool. At first glance, though, it makes sense, doesn’t it? We equate validation with best practices, much like JavaScript and JSLint. Along that line of thinking, why wouldn’t we want a perfect 100% score? Well that’s the thing: we do; however, problems ensue when the score takes precedence over our own logic.


Validating your Designs

To test your markup and style sheets, you can visit:

Alternatively, you can install the helpful Firefox add-on, Web Developer, which, among other things, offers the handy-dandy “Validate HTML” and “Validate CSS” links, as well as the option to validate even your local files.

At this point, a report will be generated, which lists any errors that the validator comes across. But herein lies the rub.

Validating HTML

Is Validation Irrelevant?

Absolutely not. I’d imagine that, particularly for those who are just breaking into this industry, the phrase, “websites don’t need to pass validation” confuses the heck out of them.

“Validation is your early-warning system about introducing bugs into your pages that can manifest in interesting and hard-to-determine ways. When a browser encounters invalid HTML, it has to take an educated guess as to what you meant to do—and different browsers can come up with different answers.”
Opera Developer Community

That said, the final score is, in fact, irrelevant.

Remember the days when we (or at least some of us) pasted those validation buttons to the footer of our websites? How funny; who were they for? The site visitors? Haha; I hope not! But here’s the thing: back then, validation wasn’t really a standard. Validate ButtonNope; in fact, if you even bothered to validate your HTML and CSS, you were a standards-embracing, cutting edge dude! Sometimes, it’s easy to forget that web standards is a relatively new concept.

Validate Before you Ask

Years ago, when I used to participate in CSS forums, it never failed: every time a new member requested help on a strange layout issue, our first response was typically something along the lines of, “Your website doesn’t validate. Fix the errors, and then come back to us if there are still issues.” Many times, odd layout issues are the result of unclosed elements, like a div. In these cases, validation can be of tremendous help.

So what changed? Is validation no longer necessary? Does HTML5 allow us to write terrible mark-up without a second thought? Is the new HTML5 doctype magic-infused? Not at all. Validation is a helpful tool that allows us to pinpoint missed closed tags, extra semicolons, etc. That said, the final score is, in fact, irrelevant. It’s not a magic number – that, at 100%, contacts The Architect behind the scenes, and instructs him to apply bonus points to your website. This score serves no higher purpose than to provide you with feedback. It neither contributes to accessibility, nor points out best-practices. In fact, the validator can be misleading, as it signals errors that aren’t errors, by any stretch of the imagination. The HTML4 validator has quickly become out-dated, but luckily the W3C has a new HTML5 validator (still experimental) that’s much improved.

Now, keep in mind that well-formed markup can boost SEO; however, there’s no specific correlation between SEO and a validation score.

HTML5 standardizes many of the features that some browsers have supported for years, such as custom attributes (via the data- prefix), and ARIA attributes, which fail the W3C’s HTML4 validator.

When testing new designs, be sure to check the experimental HTML5 validator option. With this option set, you can use the supported CSS3 properties, custom data- attributes, and more.

Validator Options

How About 75% or Higher?

Never, ever, ever compromise the use of the latest CSS3 techniques and selectors for the sake of validation.

What if we strive for at least a 75% score? I understand the thinking, as I thought that way too at one point; though, again, it’s irrelevant. When validating, your primary focus should be on determining where you’ve made mistakes. Validation isn’t a game, and, while it might be fun to test your skills to determine how high you can get your score, always keep in mind: it doesn’t matter. And never, ever, ever compromise the use of the latest doctype, CSS3 techniques and selectors for the sake of validation.

The dirty secret of browsers is that they never perform HTML validation against a DTD. The doctype you put at the top of the document switches the parser into a particular mode of operation, but no operations involve downloading the doctype and verifying that the code matches. What does this mean? It means that a basic syntax parser handles HTML, with exceptions specified for self-closing tags and block vs. inline elements (and I’m sure other situations as well).
Nicholas Zakas


What Doesn’t Validate

Dependent upon the options you specify before checking your designs (HTML4 vs. HTML5), the validator will scream like a baby when it comes across:

  • Browser hacks
  • Vendor-prefixes
  • Custom attributes
  • Genuine errors, such as unclosed elements
  • ARIA roles

Ahh, browser hacks… should you use them? The answer to that question has been debated to death, and it certainly exceeds the scope of this tutorial; however, keep in mind that, for instance, usage of the IE6-underscore-hack will fail validation.

For this reason, many designers prefer to use non-breaking techniques instead.

So:

/* Fails validation */
#myElement {
  _position: relative; /* targets only IE6 */
}

Becomes:

/* Passes validation */
* html #myElement {
   position: relative; /* targets IE6 */
}

The reason behind this line of thinking is, what if, in the future, say, Internet Explorer 10 will also render properties that are prefixed with an underscore? In cases such as that, your IE6-only (so you thought) styling will also be applied to IE10 and beyond, presumably. Now, the truth of the matter is that this would never happen, as it’d break a large number of websites. That said, this method of browser-targeting is indeed a hack. Except in smaller or rare cases, it’s better to use a conditional stylesheet, or a form of feature detection to target specific browsers.

Vendor Prefixes

While we can all agree that applying multiple vendor prefixes to properties, all for the sake of achieving, say, rounded corners, is incredibly tedious, you should thank your lucky stars that the browser vendors experimented with these technologies before they were officially recommended.

Had webkit not experimented with CSS gradients, and had Mozilla not improved upon their suggested syntax, gradients would not be as widely supported in the current generation of modern browsers as they are today. You see, browsers have a huge hand in shaping the future of the web.

.box {
  background: #666;
  background: -moz-linear-gradient(top, black, white);
  background: - webkit-gradient(linear, left top, left bottom, from(black), to(white));
  background: linear-gradient(top, black, white);
}

With all that said, the use of these vendor prefixes will cause your style sheets to fail validation. But that’s okay; don’t let that worry you one bit.

Learn the rules so you know how to break them properly.

Unfortunately, even now, many designers elect to use, in our example above, images to create gradients — if only for the purpose of pushing their validation score back to 100%. If you fall into this camp: you’re doing it wrong.


Use Validation…

  • To test for unclosed HTML elements
  • To check for typos
  • To ensure that you haven’t omitted any semicolons
  • For peace of mind

  • Validation is Not…

    • A game. Don’t waste time achieving a 100% score, when you know exactly what you’re doing. However, do use it to point out your mistakes.
    • An all-encompassing checker. While it does test for errors, it does not point out bad practices, accessibility issues, etc.
    • To be used as an excuse for not embracing the latest CSS3 techniques. The longer you say to yourself, “I’ll use this in a few years…” the further you’ll fall behind.

    Conclusion

    If you only take one thing from this article, remember that validation is simply a tool. As soon as you compromise your own logic and techniques for the sake of appeasing a validator and achieving a meaningless score, it ceases to be a tool. That said, use it, and use it often!

October 26 2010

16:15

Quick Tip: Even Quicker Markup with Sparkup


Most of us are familiar with the popular Zen Coding utility by now. For those who aren’t, it turns the process of creating complex markup into a CSS-like selector. This can save you an extraordinary amount of time; however, it does have a few short-comings. Luckily, another tool, Sparkup, inspired by Zen Coding, remedies these issues, and pushes your productivity even higher!


Prefer a Video Tutorial?


Wait…What’s Zen Coding?

Consider the following markup:

<div id="container">
   <nav>
      <ul>
         <li>
            <a href=""></a>
         </li>
         <li>
            <a href=""></a>
         </li>
         <li>
            <a href=""></a>
         </li>
         <li>
            <a href=""></a>
         </li>
      </ul>
   </nav>
</div>

This is fairly common markup that you’ll create for every new website. Assuming that you don’t already have this saved as a snippet, it can easily be recreated within seconds, with Zen Coding.

#container > nav > ul > li*4
  • Target ids and classes with the # and . selectors.
  • Use the > to filter down the tree and create children elements.
  • Request multiple elements by using the * symbol.
  • Use the + symbol to create siblings.

Room for Improvement

Unfortunately, there are a few issues that I have with Zen Coding.

  • To the best of my knowledge, there’s no easy way to travel back up the tree. For example, if I create a ul > li*4 selector, I’m not aware of a way to filter back up to the ul, and then create a sibling element.
  • There isn’t a way to assign innerHTML to an element. Wouldn’t it be great if I could type, ul>li {Some Text Here}?
  • I don’t believe there’s a way to tab between stops, after you expand.

Luckily, a utility, inspired by Zen Coding, fixes every one of the issues listed above. It’s forward compatible — meaning, all of your Zen Coding knowledge will transfer over seamlessly.


Availability

At the time of this writing, Sparkup is available for TextMate, Vim, and for general usage, via the command line. It’s fairly trivial to install. For more information, refer to the screencast above.


Climb up the Tree

With Sparkup, we can travel back up the tree.

The Syntax
ul > li*3 > a < < + #contents 

Notice how we're using the < to travel back up the tree. From the anchor tag, one < will take us to the list item, and another will bring us back to the unordered list, at which point we can create a sibling with the + symbol. Very helpful!

The Output
<ul>
   <li>
      <a href=""></a>
   </li>
   <li>
      <a href=""></a>
   </li>
   <li>
      <a href=""></a>
   </li>
</ul>
<div id="contents"></div>

Add Text to Elements

By using curly braces, we can assign values, or innerHTML to the elements we create. This feature was badly needed.

The Syntax
ul > li > p { My Text Here } 
The Output
<ul>
   <li>
      <p> My Text Here </p>
   </li>
</ul>

Tab Stops

With Sparkup, we can tab over the necessary stops, so that we can manually insert our attributes/values as quickly as possible. With MacVim, as shown in the screencast, you can use Control + N and Control + P to switch between the stops.

This way, rather than having to resort to numerous directional key presses, a single command will take you where you need to be. Refer to the screencast for an example.


So what do you think? Will you be making the switch?

October 22 2010

20:05

9 Confusing Naming Conventions for Beginners


Especially when first getting started with various web development languages, it can prove to be a difficult task to learn all of the various naming conventions from language to language. This can be even more confusing when developers disagree on what’s considered best practice. To help ease the transition for beginners, this list will describe some of the more common conventions.


1. Underscore Before the Property Name

When you come across a variable or method that is proceeded by an _, there’s no voodoo magic being performed by the scenes. It’s simply a naming convention that reminds the developer that the variable/property/method is either private or protected, and cannot be accessed from outside of the class.

PHP Method

// This variable is not available outside of the class
private $_someVariable;

class MyClass {
   // This method is only available from within this class, or
   // any others that inherit from it.
   protected function __behindTheScenesMethod() {}
}

Note that, in the code above, the underscore is not what makes the variable or method private; the private/protected keyword does that. The underscore is only a reminder for six months down the road!

JavaScript Method

var Female = (function() {
   var _trueAge = 50,
        _trueWeight = 140;

   return {
      age : _trueAge - 15,
      weight : _trueWeight - 30
   };
})();

Female.age; // 35
Female.weight; // 110
Female._trueAge; // undefined (cause it's private, yo)

By making Female equal to, not a function, but the returned object, we can create private variables. Again, the underscore prefix reminds us of this.


2. UPPERCASE Constants

A constant is a variable with a static value, that won’t change. For example, if your project required the need to multiply a value by the state tax, you might assign this rate, $.0825 to a constant. However, not all languages have these variable types built in. As such, it’s a best practice to use all capital letters to remind yourself that you’re working with a constant. This is a common convention in the JavaScript world, and is used its native objects, like MATH.PI.

JavaScript Method

var TAXRATE = .0825;

PHP Method

define('TAXRATE', .0825);

3. Single Letter Prefixes

You’ve surely, at some point, come across a variable that was proceeded by a single letter, such as "s" or "i".

$sName = 'Captain Jack Sparrow';

This is referred to as Hungarian notation, and has fallen out of favor in recent years, though it’s still a convention that’s used by many companies.

Hungarian notation is a naming convention that reminds the developer about the type of variable that he’s working with: string, integer, etc.

Particularly in the JavaScript world, this practice is frowned upon, due to the fact it’s a loosely typed language. A loosely typed language is one that doesn’t require you to declare the data type of a variable. Why is that significant? What if, using the notation convention above, we declared a string with the "s" prefix, but then later changed the variable to an integer? At that point, this form of notation would in fact work against us, not for us.

var sName = "Lieutenant Commander Geordi La Forge";
typeof(sName); // string
....
sName = undefined;
typeof(sName) // undefined

The Dollar Symbol

jQuery users: before you step on your pedestal and praise yourself for not using this form of notation, ask yourself if you prefix variables – wrapped in the jQuery object – with a dollar symbol? If so, that’s a form of Hungarian notation. It’s a symbol prefixed to a variable name which serves the sole purpose of informing you of the variable’s type or qualities.

// The dollar symbol reminds me that this variable
// has access to jQuery's various methods.
var $container = $('#container');

Should You Use It?

That’s entirely up to you. Even many jQuery team members use the dollar prefix method. Ultimately, if it works for you, that’s all that matters. Personally, as of about a year ago, I don’t use the dollar symbol prefix any longer — but only because I realized that it wasn’t necessary for me. Make up your own mind on this one.


4. Capital First Letter

What about those “variable” names, which capitalize the first letter of the name?

$response = $SomeClass->doSomething();

In the code above, $SomeClass is capitalized because it is a class and not a variable name. Again, this is a naming convention that most developers use. When returning to the code a year later, it’s a small lightbulb that informs them that they’re working with a class, which has objects and methods available.

// Note the capital M in the class name.
class $MyClass {
   function __construct() {}
}

The JavaScript World

In JavaScript, we don’t really have classes; but we do have constructor functions.

var Jeff = New Person();

The reason why we capitalize the name of the constructor (Person) is because it can prove easy to sometimes forget the new keyword. In these circumstances, JavaScript won’t throw any warnings, and it can be a nightmare to track down the glitch. The capitalization is a helpful alert for the developer, when debugging. Douglas Crockford is a big advocate of this convention.

Alternatively, if you want to protect against your future self’s forgetfulness, you could first ensure that the constructor is, in fact, correct, before proceeding.

function Person(name) {
  // If the new keyword is absent, the constructor will be the window.
  // In this case, compensate, and return a new instance
  if ( this.constructor !== Person ) {
    return new Person(name);
  }
 this.name = name;
}

// Intentionally forgot the "new" keyword
var Joey = Person('Joey');
Joey.name; // Joey

5. CamelCase vs under_score

Why is it that some variables use a camelCase pattern,while others use an underscore to separate words? What’s the correct method? The answer is there is no correct usage. It entirely depends on the language, and/or your company’s coding conventions. Both are perfectly acceptable.

// camelCase
var preacherOfSockChanging = 'Lieutenant Dan';

// under_score
var preacher_of_sock_changing = 'Lieutenant Dan';

However, with all that said, it’s a best practice — when you have the option — to follow the common conventions of the language you’re using. For example, the large majority of JavaScript developers use the camelCase syntax, while other languages, like PHP, tend to prefer the underscore usage. Though, again, this isn’t set in stone. The Zend Framework advocates camelCasing as a best practice.

More important than what you use is ensuring that you stick to it!


6. Directory Structure

Particularly when working on a team, it’s essential that you adopt the proper directory structure as your fellow developers. But, at the very least, certainly don’t drop all of your stylesheets and scripts into the root of your project, without any organization. Many developers prefer to place all of their images, scripts, and stylesheets within a parent Assets directory.

/ Project Root
  /Assets
    / js
      / min
        script_min.js
      script.js
    / css
      / min
        style_min.css
      style.css
    / img
      img1.jpg
  index.html
  otherFile.html

Also, note the convention of also creating a min folder, which contains the dynamically added minified versions of your scripts and stylesheets.


7. Semantics

When creating mark-up, hopefully, it’s widely understood that the ids and classes you choose should describe the type of content, and not the presentational aspects. As an example:

Really Bad

<div id="middle-left-and-then-a-little-lower"> Justin Bieber is my homeboy section. </div>

Better

<div class="section"> Justin Bieber is my homeboy section. </div>

Best

<section> Justin Bieber is my homeboy section. </section>

How come? What if, six months down the road, you decide to place your Justin Bieber fan section in the middle-RIGHT-and-then-a-little-lower section? At that point, your id will make little sense.

As we transition into an HTML5 world, you should find yourself using far fewer identifiers in your elements. ids are less flexible, and are many times unnecessary.


8. Double Headers and Footers

You know what stinks? When working on a centered website that requires multiple backgrounds that extend the for the entire width of the window (usually for the header and footer), you typically have to wrap your content so that the outer element will extend, while the inner element can remain centered.

As this is a common issue, it's important to adopt a common convention for creating the necessary mark-up.

<div id="footer-wrap">
	<footer>
	  My footer content goes here.
	</footer>
</div>

The difficult decision here is that, assuming you're working with the new HTML5 elements, you have to decide whether to place the footer element on the inside or the outside. It's still up for discussion, however, I tend to feel that it's more semantic to place the actual footer element on the inside.

divs should be used only when:

  • There's no better element for the job
  • When your need of the element is purely to structure a layout

9. Shortcuts

Decide now whether or not you're going to allow the use of shortcuts in your code. Writing precise/clean code is always a battle of readability vs. size. This is why it's paramount that development teams follow the same coding guidelines. To provide two quick examples:

Is the Ternary Operator Okay with You?

var name = 'Joe';

// regular
if ( name === 'Jeff' ) {
  alert("That's me");
} else {
  alert("Nope");
}

// ternary
(name === 'Jeff') ? alert("That's me") : alert("Nope"); // Nope

What About the Logical && For Short-Hand Conditionals?

var getTweets = true;

// regular
if ( getTweets ) {
 alert('getting them now');
}

// Logical AND
// Right-side won't run, unless left-side is "true"
getTweets && alert('Getting them now');

Many developers will frown upon the use of the logical AND in this case, insisting that it limits readability. This is certainly a valid argument, though, nonetheless, even popular libraries like jQuery make heavy use of this method.


Conclusion

To reiterate, the specific conventions you choose are far less important than ensuring that you remain consistent with your usage. In fact, many development teams write their own convention guidelines for new dev hires. Thanks for reading!

September 30 2010

23:38

9 Ways to Instantly Code Faster


Doesn’t the title say it all? There are a wide variety of tools and techniques which can drastically improve the speed at which we code. Particularly during time-sensitive settings, even a savings of a few seconds per iteration can add up substantially over the course of the month. I’ll show you ten of my favorite methods in this article.


1. Zen Coding

Combine the power and specificity of CSS selectors with HTML mark-up, and you get Zen Coding. Certainly, I wasn’t the only one whose jaw dropped the first time he saw:

div#container>div#contents>ul#nav>li*4

…convert to:

<div id="container">
	<div id="contents">
		<ul id="nav">
			<li></li>
			<li></li>
			<li></li>
			<li></li>
		</ul>
	</div>
</div>

In this last year, the Zen Coding project has gained considerable attention, and has been expanded to support a wide variety of code editors, including Espresso, Vim, Netbeans, TextMate, and Komodo Edit.

“Zen Coding is an editor plugin for high-speed HTML, XML, XSL (or any other structured code format) coding and editing. The core of this plugin is a powerful abbreviation engine which allows you to expand expressions—similar to CSS selectors—into HTML code.”


2. Split Windows

For many, a simple tab-based coding experience is more than adequate; however, others prefer a more integrated approach. Unfortunately, the ability to split windows is not widely available across code editors. Luckily, though, a handful of them do support it at varying levels of flexibility (the king being Vim).

Vim

The excellent Vim editor offers an unprecedented level of window combinations. Use :sp and :vsp to create new windows from within normal mode.

Other editors which implement a multi-window functionality include:

3. Embrace Social Coding

In the last two years particularly, the idea of social coding has gained considerable popularity – and why wouldn’t it? If it’s fun to share photos on Flickr, the same will of course be true for coding. With site likes Envato’s recently purchased Snipplr, Github, or Forrst, not only can you manage your own snippets for future use, but you can also take advantage of multiple brains by receiving community feedback on your coding techniques and choices.

Snipplr

Envato recently purchased the popular Snipplr.com

Another social networking site? Yes, that is true; but, I must admit: it’s fun. Plus, it’s educational!


4. Code Management Tools

Online networks like Github, Snipplr, and Forrst are fantastic, however, they can be time consuming to access, when you need to reuse a specific piece of code (assuming it’s not already part of a bundle). The solution is to install one of the various code management applications available around the web.

Personally, as a Mac user, I prefer the not-free Snippets app.

Snippets App

With this tool, when I’m working on code, I can simply press, on the Mac, Command + F12 to insert my desired code snippet into my project. Even better, it integrates an “Export to Snipplr/Snipt/Pastie” feature that’s extremely useful.

Share with Snipplr

While many editors offer an integrated snippets utility, I’d recommend embracing a third party tool instead. This way, your snippets aren’t limited to a single editor.

What Sorts of Snippets Should I Save?

Everything you can think of! As a rule of thumb, if you tend to type some block of code more than once, save it. Let’s do an obvious one together; when producing a new website, how often do you type out the three lines or so to create rounded corners in the modern browsers?

#box {
 -moz-border-radius: 3px;
 -webkit-border-radius: 3px;
 border-radius: 3px;
}

This takes around ten seconds to type each time. What a waste! Instead, create a new snippet, and reduce your coding time by 90%.

Alternate Options


5. Choose a Proper Editor

The Holy Grail of efficient coding; your choice of code editor will have the largest affect on your coding speed. Unfortunately, there isn’t a definitive answer. Your decision will largely be dependent upon:

  • Which languages you code in
  • Your OS
  • The type of UI you prefer
  • Comfort with the command line (or lack of)

As an example, someone who predominantly creates HTML themes for a site like ThemeForest would be unwise to use a full IDE like Aptana. It’s simply unnecessary and too slow. However, the same is not true for a server-side developer.

Questions to Ask Before Deciding on an Editor

  • How important is speed? Should the editor open nearly instantly?
  • Do I require integrated debugging tools?
  • Does this editor offer some form of bundle functionality?
  • How easy to memorize are the keyboard shortcuts?
  • Are my favorite extensions and plugins (like Zen Coding) available for this code editor?
  • Do I require integrated Git logging?
  • Am I okay with a GUI interface?
  • Do I prefer speed over visuals…or Vim over Coda?

When I asked myself these questions, I determined that speed and performance were paramount. As such, I currently use Vim, which is significantly daunting at first, but provides an unprecedented level of flexibility and speed, due to the fact that even traversing your page requires a language, of sorts. However, for larger projects, which require debugging, I use Netbeans.


6. Use Bundles

Bundles: learn them…use them. Editors, like TextMate — and, subsequently E Text Editor — popularized bundles; however, they’re widely available from editor to editor.

What’s So Great About Them?

How many times have you found yourself typing the same generic piece of mark-up or code, whether that might be a new function, or the structure of a new jQuery plugin. How much time are you wasting each time you repeat this process? This is where bundles come into play.

For example, by downloading the TextMate CodeIgniter bundle, we can take advantage of a wide array of methods and snippets. Remember – less typing is always a good thing!

CodeIgniter Bundle

With this bundle installed, we only need to type the designated shortcut, and then press tab (in most editors). This will then expand the shortcut into the requested code. What separates a bundle from a snippet is that you can specify multiple tab stops to further expedite your coding speed.

Vim Users: if you miss/envy the TextMate bundle feature, check out the SnipMate plugin.


7. Use LESS.js

Tools like LESS.js and Sass can drastically increase your coding speed. In terms of which one to choose: they’re both excellent. LESS.js is particularly impressive, though, because it runs 100% on the (wait for it…) browser’s JavaScript engine.

How Does it Work?

These tools allow for all of the features that you wish CSS had — such as variables and functions.

/*
Variables!
*/
@primary_color: green;

/*
Mix-ins are like functions for commonly used operations,
such as apply borders. We create variables by prepending
the @ symbol.
*/
.rounded(@radius: 5px) {
	-moz-border-radius: @radius;
	-webkit-border-radius: @radius;
	border-radius: @radius;
}

#container {
/* References the variable we created above. */
	background: @primary_color;

/* Calls the .rounded mix-in (function) that we created, and overrides the default value. */
	.rounded(20px); 

/* Nested selectors inherit their parent's selector as well. This allows for shorter code. */
	a {
		color: red;
	}
}

Pro Tip: To make your browser update every time you save a file (very handy feature), use the watch method. Place the following at the bottom of your project. Of course, this assume that you’ve already setup LESS.js.

less.env = 'development';
less.watch();

LESS Compiler

Many might argue that it’s unsafe to use a JavaScript-based solution. But that’s okay; there are a handful of compilers available around the web. The best solution I was able to find is called LESS.app.

LESS APP

After you download it (free), you simply drag your project folder into the app, which instructs it to watch all .LESS files. At this point, you can continue working on your project, per usual. Every time you save, the compiler will run, which generates/updates an automatically created style.css file. When you’re finished developing your app, you only need to change your stylesheet references from style.less to style.css, accordingly. Easy! Now there’s no reason not to take advantage of LESS — unless you’re using a different solution, like Sass.

Generates CSS FIle

8. Prototype Early with Firebug

You know the drill: write a bit of JavaScript, switch and refresh your browser, receive an error, return to the editor…and rinse and repeat. Though we all do it, sometimes, there are far more efficient alternatives, such as protoyping early with tools like Firebug. By working directly in the browser, you cut out the middle man, so to speak.

The uber-talented Dave Ward recommended this tip, and has even created a screencast demonstrating this method.


9. Don’t Reinvent the Wheel

When first getting started in this field, I always took issue with comments like “Don’t reinvent the wheel.” It’s not about reinvention; it’s about understanding how the wheel functions. However, once you know the inner workings of the wheel, this argument certainly is true: Don’t Repeat Yourself.

Coding each new project from scratch is incredibly time consuming.

If you want to complete new projects as quickly as possible (and who doesn’t), save yourself some time, and take advantage of the various levels of abstractions that are available around the web. A handful of my favorites include:

  • HTML5 Boilerplate – Whether you choose to use this template in its entirety, or in bits and pieces, it doesn’t matter. Just use it! And while you’re at it, split the sections of code into snippets for reuse! Watch the official guide to Boilerplate on Nettuts+
  • CodeIgniter (PHP Framework) – For higher level PHP applications, the CodeIgniter framework is a fantastic choice. Even better, the community support is second to none. If you happen to be a visual learner, our CodeIgniter from Scratch series is, also, second to none. :)
  • 960 (CSS Framework) – If you require grid-like structures, both the 960 and Blueprint CSS frameworks are fantastic choices. They easily turn hours of work into a two minute process; and, if you’re worried about file bloat, you needn’t. That’s a ridiculous argument. Let us teach you how to use 960!
  • jQuery (JavaScript Library) – Does this one really require explanation at this point? Save yourself the headaches, and use it (that is, unless you’ve developed your own awesome library).

Conclusion

I’ll show you mine if you show me yours. Which tools and resources do you use to code faster?

September 29 2010

00:57

September 17 2010

01:38

Sexy Real-Time Analytics with Reinvigorate


To best serve your website’s audience, you need to understand them as best you can. The best way to do that? Analytics. There’s a few ways to track your website’s traffic, though Google Analytics is probably the most popular due to its price — free.

However, Google Analytics has several important features missing that other analytics providers offer; namely real-time stats and heatmaps. Reinvigorate is one of those providers, which we’ll take a look at today.


Read the Full Review on our Sister Site: Web.AppStorm

Reinvigorate

A web app review is a bit beyond the scope of what we cover on Nettuts+, however, it fits perfectly on the awesome Web AppStorm. Read the full review there, if this interests you!

July 13 2010

14:04

Three Steps to Fostering a User-Centered Design Culture


As responsible designers we must educate clients on the importance – both the validity as well as the viability – of the user-centered design process, one that gives due consideration to the needs of potential users. With the three steps that follow, we’ll go over techniques that you can use to get your team thinking about what’s really important with regards to the design of their websites you’ll help them create.

This Post is Day 2 of our Interface Design Session. Creative Sessions

Shattering False Idols

Anyone who’s worked as a web designer or developer for a sizable length of time has had a client say “Hey, I’ve got a great idea for a website; can you help me build it?” While their enthusiasm is wonderful, this question is typically loaded with preconceptions (read: misconceptions). The process for creating a website is never as straightforward as even we would hope it to be.

It is with these projects that we must be most careful—the ones where clients seem to know exactly what they want. They probably have a particular layout in mind, perhaps some specific functionality that should be included. But more often than not, these images of perfection give little-to-no consideration for the users that will actually visit and use the final work product. What can we do with such steadfast clients?


Step One: Introduce Design Thinking

As with any collaborative endeavor, it is particularly important to ensure that all members of the team are fighting for the same goal. The earlier this is done, the better.

In effect, we want to move clients away from subjective goals (“I want it to look cleaner.”), towards measurable, objective ones (“I want it so clean that sales increase by 20%.”). By asking a few straightforward questions, you’ll find the design that client’s require isn’t littered with nearly as many obstacles.

To start the ball rolling, have your client jot down five things he wants his website to do for him (don’t be surprised when not-a-one of them has to do with end users). Next, inform clients how their goals will affect your design and development process.

Consider, too, forming an experience strategy.

An experience strategy is a clear set of experiential goals used to add cohesion to design and development endeavors. It should answer some fundamental questions, such as: What’s our eventual experience goal? Should user’s love our site? Should they feel that we’re really really good at something in particular? How should they feel about feature [x]?

Lastly, get a development strategy put in place. In formulating such a strategy, the questions you’ll address include:

What research and development methodologies work best for this project? What deliverables are best for any given stage of this project?

Although these questions are simple, they’re extremely important.

1

Suggested Reading


Step Two: Replace Bad Habits with Good Ones

Before hopping into sketching interfaces and pushing pixels, we must first ask the ever-important question: what do users need?

Remember: without user research, design is meaningless. Make sure your client knows this, too.

So, how do we answer such a question? Well, with design research. That’s how.

But you, the experience designer, already know this. The important part is getting the client and/or organization with which you’re working to understand why design research is so important, especially considering that they probably have some pretty bad design habits in place already.

Back in the old days, websites were born from functional specs—cold, heartless documents outlining every functional aspect of the website. Needless to say, this took users out of the development equation.

Utilize prototyping methods (such as sketching or storyboarding) and employ user-testing to show your client what kind of feedback they can expect from their new website. Once you tell him he’ll be saving both time and money by building his website with the results from your research findings, he won’t ever miss his functional spec.

Remember: without user research, design is meaningless. Make sure your client knows this, too. Providing even rudimentary research findings can help everyone on the team make informed decisions as we move our design process forward.

2

Suggested Reading


Step Three: Share the Wealth

Experience design is both a visual and physical process, so it clearly benefits from collaboration. As a designer, you likely have lots of research, wireframes, personas, and other deliverables filed away for the projects on which you’re working. Take them out and share them with your colleagues.

Foster a fertile environment for design growth.

Listen to their feedback and provide your own. Foster a fertile environment for design growth. Storyboarding is a great tool, introduced at Adaptive Path, for this kind of collaboration. Once previous design deliverables have been shared and passed about, team members collectively pitch design solutions to advance towards the aforementioned end goal. The final storyboard is yet another fantastic tool to prompt further conversation later on in the process.

Regardless of the specific techniques or deliverables that you employ, collaboratively working on and sharing user-centered design deliverables helps facilitate a shared design understanding amongst your entire team.

3

Suggested Reading


Moving Forward

In this article, we’ve explored three simple steps that you can follow to blaze the user-centered trail at your organization. Don’t take them the wrong way: these steps do not constitute some kind of magical collection of UX incantations; instead, they are merely illustrative of the way forward.

By drawing your project team’s attention towards the following aspects of design and development, your organization is much more likely to think about its challenges in holistic, user-driven fashion. The rest, as they say, is up to you.


This Post is Day 2 of our Interface Design Session. Creative Sessions

July 12 2010

22:18

Why Wine and Macbooks Don’t Mix…and How to Handle the Aftermath


Ready for a revelation? A concept that you’ve never considered before? Well here it is: never ever, ever poor a glass of wine into your Macbook keyboard. Or, more practically put, be extremely careful when there’s a drink of any kind near your laptop. If a spill occurs, and you don’t act quickly enough, you’ll find yourself staring at a massive bill for a new logic board, hard-drive, battery, and anything in between.

Accidents do happen — so plan on it. What’s more important is that you learn exactly what to do when these spills inevitably occur.


Step 1. Don’t Freeze. Unplug!

Macbook Wine Spill

Ahhhh! The wife (meaning, you) accidentally spilled wine all over your keyboard. From personal experience, I can assure you that, for some odd reason, your first instinct with a massive computer spill is to freeze for five seconds or so, in shock. Don’t do this! Luckily Apple laptops are pretty helpful about automatically shutting down to prevent as many issues as possible before they happen. The more recent laptops even have liquid detection…though I’m certain that Apple is more interested in voiding your warranty than protecting you. For those uninformed, most laptop warranty’s do not cover spills.

Nonetheless, don’t waste a single second. Quickly unplug the computer, and shut it down.

The walls and carpet may have liquid on them as well, but ignore that. The computer is far more important right now.


Step 2. Flip that Sucka

Turn the laptop over to let the liquid drain

The next step, which should occur within seconds of beginning Step 1, is to flip the laptop upside down, into an L-shape. Gravity will then force as much liquid to drain out of the keyboard as possible. Make sure that you lay it on a towel so that it can soak up the liquid.

Let gravity do its job. Immediately flip the laptop into an L-shape.


Step 3. Open the Back

Unscrew the laptop to reveal the insides

Using a tiny screw driver, unscrew the back-side of your laptop. This will, of course, vary, depending upon which model you’re using. I’m sure you can figure it out.

Particularly on Macs, not all of the screws are the same size. Make a note of which screw goes where.


Step 4. Remove the Battery and Hard Drive

Remove the Macbook Pro battery

Before progressing, ensure your livelihood and touch some metal objects nearby to remove any potential static electricity from your body.

Needless to say, batteries and liquids — especially sugary, acidic liquids — don’t play nice together. Wherever yours is located on your laptop, remove it as quickly as possible. Next, get the hard drive out as well. We don’t want to risk any liquid seeping in, and corrupting your file system!

And now that you know how easy it is to remove a hard drive, don’t ever again pay a person to upgrade your hard drive. It only takes a moment to do yourself. ;)


Step 5. Dry the Insides

Clean the insides of the computer after a drink spill

With a paper towel of some sort, begin cleaning the insides of your computer. Depending upon how much liquid was spilled, this may either be a quick or lengthy process. For yours truly, it took around ten minutes to clean everything.

Some people prefer to use a hair dryer to clean the insides. This one is up to you; however, I’d encourage you to not do so. Play it safe and use a towel. We don’t want to risk frying the insides.


Step 6. Rubbing Alcohol and Cotton

Clean the insides with a cotton swab

Next, we need to continue removing as much sugar and acid as possible from the logic board. Otherwise, over time, it can begin to corrode the wiring. Yeah, this isn’t good!

Using rubbing alcohol and a cotton swab, begin dabbing any stained areas — but be gentle. If you have access to the backside of your keyboard, clean that area as well. Unfortunately, on the newer Macbook Pro models, it’s extremely difficult to access this section. With past models, it was quite easy to remove the keyboard entirely, for cleaning purposes. Unfortunately, that’s no longer the case.

Rubbing alcohol will help dissolve any remaining acid or sugar on the logic board.


Step 7. Leave it Alone

Leave the computer off for 3-5 days after a spill

Anxiety is a dangerous thing. Resist the urge to determine whether or not you’ve destroyed your laptop, and keep it off for a minimum of 72-120 hours (3-5 days). This will allow any remaining liquid to dry/evaporate first. Make sure that, while its drying, you keep the battery outside of the computer. This is mostly a precaution.

Keep the computer off for 3-5 days — no questions asked. Do not turn it on during this window.


Step 8. Cross Your Fingers

Cross your fingers

After 72-120 hours, reconnect the battery, screw everything back in, cross your fingers, say a prayer, and turn on the computer. Particularly if you’re using a new Macbook Pro (2009+ models), you’ve done everything you can do. With hope, and more often than not, it’ll chime, and start-up like a charm. However, if the battery is dead, or the hard drive is corrupted, you’re next best option is to take it in for official repair. Of course, this will somewhat depend upon how skilled you are, when working under the hood.


About the Author

Jeffrey Way — me…yes, I’m speaking in third person — recently committed a Cardinal Sin, and caused a massive wine spill into his Macbook Pro. Had he not followed these exact steps, he’d be forking over another life savings for a new Mac. Luckily, that was not the case.

Thanks for reading. Should the same ever happen to you, I hope this guide will help a bit!

Older posts are this way If this message doesn't go away, click anywhere on the page to continue loading posts.
Could not load more posts
Maybe Soup is currently being updated? I'll try again automatically in a few seconds...
Just a second, loading more posts...
You've reached the end.
Get rid of the ads (sfw)

Don't be the product, buy the product!

Schweinderl