I've been doing web development since 2005, matter of fact, the first website I ever built is still around .  Back then it was DotNetNuke and WebForms projects, and it sucked.

I honestly had no idea what real HTML was until .Net MVC came out.  The first time I had to write a real form and learn what happened when you posted information was a mind blowing experience.  I've been hooked ever since.

Modern web development still sucks.  But I've learned to manage some of the sucky parts with what your going to see here today.

Step 1: MVC FTW

You need to learn MVC 3 immediately.  There should be absolutely no reason we ever willingly start a new WebForms project again.  It's beyond this article to teach the intricacies of MVC style web development, but I will say that it will immediately boost your HTML, CSS and Javascript understanding.

MVC Resources

 - Intro to ASP.NET MVC 3

 - Introducing "Razor"

Step 2: HTML5 Boilerplate, Normalize.css, Modernizr and YepNope + Polyfills for browser consistency

Battling display inconsistencies with different browsers is never really going to go away.  Legacy IE versions are entrenched in the enterprise world and likely will be there for years to come.  However, we can stand on the shoulders of giants in the web community who have put together a group of collected tips, tricks, magic spells and hacks that give us a pretty consistent baseline experience across most browsers.

The HTML5 Boilerplate project is a great project for not only getting a jump start on a consistent site look and feel, it's also a great way to learn about the cutting edge in web development.  HTML5 Boilerplate code is chock full of tasty bits of knowledge ready for you to expand your mind when you're ready.

HTML5 Boilerplate and Normalize.css Resources

 - HTML5 Boilerplate Site

 - Normalize.css Site

 - Modernizr Site

 - YepNope Site

Step 3: HTML5 != Just put a Canvas in it, bro

I've worked on a couple HTML5 sites... err applications, and I've never once found it helpful to use a canvas element in something that is not a game.  There are so many other cool things in the HTML5 spec that aren't a canvas element that people don't even know about.  The best parts of HTML5 are the things that make you write less code that is more readable.

Isn't that cleaner than a bunch of div's?  And, not pictured, but equally as important is the cleaner CSS that results from not having class pollution everywhere.

I could go on about all the new API's but the point I want to make is that it's no longer acceptable to say "All HTML5 adds is just a canvas and audio element, right?". No,  HTML5 is a collection of state of the art browser API's and semantic markup elements built to let you make the next generation of applications that make use of native resources without the native application walled garden.

HTML5 is a collection of state of the art browser API's and semantic markup elements built to let you make the next generation of applications that make use of native resources without the native application walled garden.

HTML5 Resources

 - HTML5 Rocks

Step 4: Javascript: with great power comes great responsibility

It's amazing how intimidating javascript is to the new comer.  I think when faced with the intricacies and inconsistencies of javascript people often fall back to a mess of procedural code with the caveat that "Hey, it works, so I don't want to change it".  This is lazy, and not the good kind of lazy either.  We need to, and can, write javascript code that is object oriented, loosely coupled and efficient.

Here are some signs that your javascript code is starting to suck:

 - You have one long javascript file

 - You have everything in the global namespace

If you find yourself with a long javascript file and wish you could separate things out into nice manageable chunks, try using a framework like SquishIt to combine and minify your javascript files for you as part of the build process.  Complicated open source projects like jQuery use a similar process to break things down into smaller, more manageable chunks.

Cluttering the global namespace is like having all your variables in an application be shared with everything else.  Information hiding is a core principle of object oriented programming and to that end you should know how to write code that protects it's private data and exposes a nice clean API for you, or someone else, to take advantage of.  One way of doing this is by taking advantage of the Module (or Module-Export) pattern.

Isn't that cleaner than a bunch of div's?  And, not pictured, but equally as important is the cleaner CSS that results from not having class pollution everywhere.

I could go on about all the new API's but the point I want to make is that it's no longer acceptable to say "All HTML5 adds is just a canvas and audio element, right?". No,  HTML5 is a collection of state of the art browser API's and semantic markup elements built to let you make the next generation of applications that make use of native resources without the native application walled garden.

HTML5 is a collection of state of the art browser API's and semantic markup elements built to let you make the next generation of applications that make use of native resources without the native application walled garden.

HTML5 Resources

 - HTML5 Rocks

Step 4: Javascript: with great power comes great responsibility

It's amazing how intimidating javascript is to the new comer.  I think when faced with the intricacies and inconsistencies of javascript people often fall back to a mess of procedural code with the caveat that "Hey, it works, so I don't want to change it".  This is lazy, and not the good kind of lazy either.  We need to, and can, write javascript code that is object oriented, loosely coupled and efficient.

Here are some signs that your javascript code is starting to suck:

 - You have one long javascript file

 - You have everything in the global namespace

If you find yourself with a long javascript file and wish you could separate things out into nice manageable chunks, try using a framework like SquishIt to combine and minify your javascript files for you as part of the build process.  Complicated open source projects like jQuery use a similar process to break things down into smaller, more manageable chunks.

Cluttering the global namespace is like having all your variables in an application be shared with everything else.  Information hiding is a core principle of object oriented programming and to that end you should know how to write code that protects it's private data and exposes a nice clean API for you, or someone else, to take advantage of.  One way of doing this is by taking advantage of the Module (or Module-Export) pattern.

Programmer Values

Tonight I've been thinking a lot about my career.  Every now and then I like to get back to "First Principles" and re-evaluate my core values.

To that end, here is what I think I value as a software developer.

1.  A consistent working location.

  - see Your Commute is Killing You

  - Part of a community that I can contribute to

2.  Solving interesting problems that help people be more productive and prosperous.

  - Challenging work

  - Not micro-managed

  - Do no evil

3.  Working with people who I can learn from and hang out with

  - Continuous learning

  - see Why Friends Matter at Work

4.  Sharing my knowledge with other people.

  - Presentations, discussions

  - Grow your people

  - New business from new ideas

All this is sprinkled with most of the stuff you see in the RSA Animate - Drive video:

That's it for now, maybe some future me will look back at this and re-evaluate.  Next time I'll talk about my career as a consultant and how that meshes with these values.

Now Playing - Drake - I'm On One

_

document.ready with jQuery Mobile

One of the first hurdles I had with creating sites with jQuery Mobile was figuring out how to run my code when a page loads.  Since navigating to a new page no longer requires a postback, the standard $(document).ready approach isn't going to cut it.  I've come up with a solution that I think helps you modularize and isolate your code to prevent having one large unmaintainable lump of a javascript file.

Creating a Namespace

Now when I work on javascript heavy applications, I take care to modularize my javascript but I don't necessarily follow the pattern exactly.  I start out by creating a namespace object, and I usually place this in a file called core.js.

https://gist.github.com/1246402.js?file=ready.core

So, what we're doing here is creating a blank object (MYAPP) to "scope" our application objects.  We extend that object with some new objects to hold our pages and maybe even some options.  We would also maybe put some other stuff in here, but for this example we'll keep it mostly clean.

The Page Event Mapper

Now it's time to do some plumbing work to hook the new page objects we are going to create up to the jQuery Mobile navigation framework.  We want to pass the page events from jQuery Mobile to a page class that will handle the events.

https://gist.github.com/1246402.js?file=ready.navigation

Every page in jQuery mobile is wrapped in a div with a data-role attribute set to "page", so what we're doing here is handling the jQuery Mobile page events and passing them to our corresponding page.

A Page Class Example

Speaking of pages, let's take a look at what an example page looks like in my code.

https://gist.github.com/1246402.js?file=ready.homepage

As you can see, I've kept the code pretty simple.  This class will now be able to respond to init events (which get fired before the page is modified by jQuery Mobile) and the show event which gets fired every time the page is navigated to (even when it's cached and navigated back to).

But Don't Take My Word For It

If you want to give a try for yourself, head on over to the jsFiddle I set up with this example code already set up.

Now Playing: Nas - It Ain't Hard to Tell (Reading Rainbow Remix)

_