After receiving many emails and instant messages the last couple days over the whole Apple vs Flash tit-for-tat that’s been going on. I feel compelled to give my thoughts.

For starters Steve Job’s article, Thoughts on Flash, is full of truth and fiction. The biggest part that rubbed me the wrong way was his lack of distinguishing between Flash and the SWF file format that Flash produces; Jobs conveniently leaves this out. Of course the average person knows nothing about the distinction between Flash, the tool that is used to create a SWF file and the actual SWF file that is used on a website. The SWF file is ‘open’ and there are other products, not made by Adobe, that can create SWF files. So it is fair for Abobe to wave the ‘open’ flag.

As far as Apple being ‘open’. Not so fast there Jobs. I can’t even use the SDK on my Windows machine. You must own a Mac if you want to create applications for an iDevice.

Is there anyone that truly believes Apple could not get Flash to play on their devices if they wanted to? Just say it Jobs, I don’t want to support Flash. Period.

Now my final thought and it’s not a good one for you Flash developers is this: Flash is dying, but it’s not Apple that’s killing Flash. It’s three things: 1.) Ajax 2.) jQuery and 3.) HTML5. These technologies have been slowly killing Flash the last few years. Look around, sites that once used Flash have fazed it out: Yahoo, MSN, IGN and many many others. Because of these technologies, Flash’s strengths are no longer there. It’s been relegated to advertisements and entertainment sites.

In this article we will be looking at a different type of architecture. One in which we utilize jQuery’s ability to easily transfer data (via Ajax and JSON) from the client to the server. We then use ASP.NET and LINQ to SQL to query the database and return a collection of data which gets (automatically) serialized to JSON and sent to the client. The benefits of combining these technologies include: more responsive applications, more processing on the client, less processing on the server and reduced network traffic. Everything runs faster and uses fewer resources.

Still not convinced? Here are some additional benefits of this architecture:

Benefits of the Architecture

1. Unlike an ASP.NET UpdatePanel we only pass what we need; we only receive what we need. We don’t pass ViewStates, in fact we don’t even have a ViewState. We also don’t pass entire HTML chunks and receive HTML chunks we don’t use. For more on this; read: Why ASP.NET AJAX UpdatePanels are dangerous.
2. By using jQuery to call the web service directly, we’ve eliminated over 100 KB of JavaScript and three extra HTTP requests that’s included when you use ASP.NET Ajax.
3. Less dependencies – because all our code is simply xHTML we could switch to a PHP or a Java backend and none of our code for the UI would have to change. That’s right, there are no server-controls; that means no GridViews, no Repeaters, no ListViews, nothing that uses runat server will be found on the page. Not even a ScriptManager.
4. Usability – We can create RIA interfaces AND maintain usability, giving us the best of both worlds.
5. Cross-Browser friendly – We use nothing but xHTML code and jQuery which works across browsers.
6. The entire presentation for the UI is done via CSS. Change the CSS and the entire UI can look different.
7. We maintain a ‘Separation of Concerns‘ – this means we have 3 distinct and wholly separate code bases. A content or HTML level. A presentation or CSS level and a behavior or JavaScript level. We don’t have code mixed together in a web-page jambalaya.
8. Switching architectures from Web Forms to MVC is a breeze.

Hopefully you are salivating at these benefits enough to decide to get your feet wet and follow along.

In this article will be leveraging these technologies to build a grid (or what looks like a table). Later on, in future articles, I will then show you how to implement sorting, paging and filtering on the grid. I have divided this article up into four sections: 1. Sever-side code (ASP.NET). 2. HTML 3. jQuery and lastly CSS.

Click to continue reading »

Over the past month I have been reading jQuery Enlightenment by Cody Lindley. Let me say now, that if you use jQuery or are thinking about using jQuery then you should most certainly buy this book. It’s a quick read (122 pages) that includes colorized code samples, easy to follow examples and solid explanations.

Author Cody Lindley is a member of the jQuery team and explains why he wrote the book.

jQuery Enlightenment was written to express, in short-order, the concepts essential to intermediate and advanced jQuery development. Its purpose is to instill in you, the reader, practices that jQuery developers take as common knowledge. Each chapter contains concepts essential to becoming a seasoned jQuery developer.

This book is intended for three types of readers. The first is someone who has read introductory books on jQuery and is looking for the next logical step. The second type of reader is a JavaScript developer, already versed in another library, now trying to quickly learn jQuery. The third reader is myself, the author. I crafted this book to be used as my own personal reference point for jQuery concepts. This is exactly the type of book I wish every JavaScript library had available.

I would argue that this book is perfectly suitable for beginners too. It’s simply a must have jQuery book. It’s the only one you need; it will take you from beginner to competent user.

I do ASP.NET / C# web development where I build web-based software for school districts. My preferred architecture is one in which I use NO server-controls. That means no GridViews, no Repeaters, no ListViews. If fact, nothing that uses runat server will be found on the page. The page will only consist of XHTML. So there is no need for a viewstate either. We end up using jQuery a lot in this architecture. We use jQuery / Ajax to call Web services that then query the database using LINQ to SQL and pass our data back to the client where we can then populate our XHTML controls. It works great and is extremely fast and efficient. The code couldn’t be cleaner. In addition, this methodology would allow you to easily change to a PHP or Java backend and you wouldn’t have to change a single thing on the frontend. I will give a full example on this methodology another time, but the point is – you need to learn jQuery.

For more information on the jQuery Enlightenment book, including a breakdown of each chapter go here. I would recommend buying the full color book from lulu.com as it’s well designed and very handy to have on your desk.

CSS is a sticky subject in the best of times and to make it more sticky I thought I’d run down the techniques needed to make a sticky footer that works in all modern browsers. This is unlike most examples on the web that break in either Opera, IE8, IE7 or indeed in all three.

Try any of those footers from the Google search above in IE8 or Opera (some don’t work in IE7 either). Load the page then grab the bottom of the window (not the side or corner of the window) and drag it up or down and you will see that the footer usually sticks in the wrong place, messing up the display.

Now try it on my old original sticky footer version (circa 2003 which pre-dates all those above) and you will see that my version is working in all browsers including IE8.

Before we get into details I should first explain what a sticky footer is.

What is a Sticky Footer

A sticky footer is one that sits at the bottom of the viewport when there is not enough content in the page to push the footer down. If there is a lot of content then the footer sits at the bottom of the document and will be below the fold as usual. Why this is desirable is because on short content pages you won’t have a footer right at the top of the screen looking very strange indeed as shown from Figure 1 below.

Figure 1 – normal footer close to content.

Figure 2 – Sticky footer at bottom of viewport.

Note that a “fixed positioned” footer is not the same thing as a sticky footer as a fixed positioned footer is one that sits at the bottom of the viewport at all times and never moves. Don’t get confused between the two.

Overview

Before we get into the nitty gritty detail I will briefly explain the concept in getting a sticky footer to work.

The first thing we need to do is create a 100% high container which is achieved by setting the html and body elements to 100% height and then creating a container that is a minimum of 100% high. The footer is then placed after this container which means it will be invisible as it will be below the fold of the page but by the magic of negative margins we can bring it back into view at the bottom of the viewport.

Of course this means that the sticky footer must be a fixed height (pixels or ems will do) so that we know how to accommodate it with the exact negative margins that bring it into view. This also means that our footer is now overlapping content on the page so we will also need to protect this content with either padding on an inner element, or some other similar approach as you will see when we get into specifics later.

That’s basically all there is to it except that we have to squash a few bugs on the way to make it work everywhere.

Click to continue reading »

Is technology really making a difference?

Of course we all love our iPods and Blu-Ray players and doing research before Google came along was slow, often times requiring you to get in your car and go to a library. Anybody remember using library tools such as card catalogs and Microfiche to perform research? Now we can do it from our beds, simply by entering a few words into our mobile device and get instantaneous results; fantastic, no doubt.

Today’s cell phones look like something out of Star Trek. Actually, they look better and have more options.

We truly live in marvelous times. But, what does it all add up to? Technology is supposed to make our lives easier, more productive and in some areas eliminate work altogether. And for the most part I think we can say it’s worked. So how come I, like you, still work forty plus hour work weeks? In fact, since World War 2 the number of hours worked per week has grown. In her recent book, “Willing Slaves – How the Overwork Culture is Ruling our Lives“, Madeleine Bunting states that from 1977 to 1997 Americans working full time have increased their average working hours from 43.6 hours to 47.1 hours each week. (This does not include time required to travel to and from their places of business).[1] How can this be? In addition to working longer hours, many families have both family members working. The United States Bureau of Labor Statistics states that between 1950 and 2000 the number of individuals in the active labor force grew 227 percent from 62 million to 141 million.[2]

The whole goal of a software developer is to make someone’s life easier. If we’re successful our software or device will allow a user to be more proficient, saving them time and allowing them to get more work done. But does it really matter if the user is now able to get their work done faster if the end result is still working forty hours? What does it matter if you can get twice the amount of work done? Forty hours is forty hours. I’m sure that by increasing the amount of work we are able to get done each day that someone benefits, someone higher up, but it isn’t you and it isn’t me.

It seems like life just keeps moving at an ever accelerated pace. Like a merry-go-round that started off slow and built up speed. Perhaps it’s moving so fast now that we can’t jump off? Or maybe we still don’t feel we need to jump off?

Author Daniel Quinn in his book Ishmael gives us a parable that may explain what has happened. It’s certainly interesting.

Click to continue reading »

jQuery, a lightweight (only 19kb in size) JavaScript library has become my new best friend. It's like mushrooms to Mario. Obviously I'm not alone since Microsoft is now distributing jQuery with Visual Studio (including jQuery intellisense). If you are using the new MVC framework from Microsoft then you will no doubt become familiar with the intricate workings of jQuery.

jQuery is not all that difficult to learn. The biggest thing you have to understand is all the different "selectors" that are available to you. Using selectors developers can query, in a CSS like way, for HTML elements, and then apply "commands" to them.

For example, the below JavaScript uses jQuery to find a <div> element within a page that has a CSS id of "rightSide", and shows it and "leftSide" and hides it.

As another example, the JavaScript below uses jQuery to find a specific <table> on the page with an id of "datagrid1", then retrieves every other <tr> row within the datagrid, and sets those <tr> elements to have a CSS class of "even" - which could be used to alternate the background color of each row:

This next example gets all links <a> in a specific <div> and attaches an onclick event to them:

Being able to traverse the DOM and locate HTML elements to attach events, behaviors, animations and CSS is priceless. But what about ASP.NET controls like the RadioButtonList, GridView, ListView, Repeater, and many others that we as developers like to bind to? How do we traverse them when they all get their ids auto-generated? That's what we will look at now! And with jQuery it's not that hard!

Click to continue reading »

"He emerged from the metro at the L'Enfant plaza station and positioned himself against a wall beside a trash basket. By most measures, he was nondescript: a youngish white man in jeans, a long-sleeved T-shirt and a Washington Nationals baseball cap. From a small case, he removed a violin. Placing the open case at his feet, he shrewdly threw in a few dollars and pocket change as seed money, swiveled it to face pedestrian traffic, and began to play."

This scene is all too familiar for those of us that work in an urban downtown area. Do we stop and listen or just hurry on about our business?

But wait, this was not your typical panhandler. No one knew it, but the fiddler standing against a bare wall was one of the finest classical musicians in the world. In fact, the musician was Joshua Bell. Whom just three days before he appeared at the Metro station, had filled the house at Boston's stately Symphony Hall, where merely pretty good seats went for $100. The very violin that he played was worth more than most of the passer byes would make in their lifetime. The violin was handcrafted in 1713 by Antonio Stradivari and the price tag was reported to be about $3.5 million.

Joshua Bell, one of the worlds top classical musicians, equipped with his million dollar Stradivari violin played one of the most difficult violin pieces ever. AND THE WORLD WAS TOO BUSY TO NOTICE...

This experiment arranged by The Washington Post struck a cord in me. Probably because I fear that I would be one of the many that was too busy with life to see or hear the beauty that was right there in front of me.

This is one of the reasons for the less frequency of blog post these days. The other reason is the birth of my second child. In the words of Ferris Bueller, "Life moves pretty fast. If you don't stop and look around once in a while, you could miss it."

The life of a software developer is fast paced for sure, maybe that's why they call them sprints in the Agile dev methodology. Make sure you are stopping from time to time to smell the roses or hear the music. Work to live. Don't live to work...

Be sure to read the entire Washington Post experiment here. It's well worth your time.