25. October 2010 15:26
This series is meant to be a pragmatic look at creating a modern web application today. What this means to me is that older browsers still need to be supported. In some environments the use of Internet Explorer 6 is still well over 20%, especially in corporate environments where XP and IE6 are the standards they are bound by. Though dealing with a browser that is quickly reaching a decade in age, which is ancient by software standards that tend to churn a new generation every 2 years or so, there is hope. I'll be referencing IE versions 6-8 as IEOLD, since these really are the existing legacy of IE as it stands. IE 9 is shaping up to be a much more compliant browser that has a great UI and does a much better job of rendering content. There are a few quirks as it stands that I will point out in the next segment in this series, I'll be referring to IE9+ as IENEW.
In this exercise we will be using HTML5's DOCTYPE tag which is very simple and straight forward. In fact it's the first DOCTYPE I actually committed to memory, (<!DOCTYPE html>) how cool is that. HTML5 by definition is very pragmatic in and of itself. The main lesson in HTML5 is to use what works for you, as many browsers have created enhancements for their own needs and then copied them from each other. Starting with WhatWG and moving into the W3C's group as a movement to formalize these enhancements as a standard, that doesn't mean you shouldn't be utilizing it today. Moving forward I will be using several HTML5 tags, in addition to using CSS3 to avoid the use of images for simple gradients and rounded corners. In order to facilitate this, I'll be first adding two shining stars into my tool-belt.
The first of which is the wonderful html5shiv. This allows us to utilize the new tags defined as part of HTML5. As there are several new tags within the HTML5 space, it is much better to use these as a more semantic means of marking up our site, over simply using meaningless DIV tags with class attributes everywhere. The html5shiv is a fairly light script that will add support for these new tags in old IE versions (prior to 9). You will also want to take a look at html 5 innershiv if you intend to inject these new elements via the innerHTML DOM property.
The second tool we will be using is the CSS3PIE (Progressive IE) HTML Component which can be used with IE versions prior to 9. By defining behaviors against elements that will utilize background gradients and rounded borders for IEOLD, we will be able to eliminate the need for the use of images, and complex layouts to achieve these commonly used effects.
Though both of these tools have been out for a while, I hope you find them useful. I'm outlining the series below, and will inject the links as these articles become live on the site. My goal is to have a the first eight articles in this series (including this one) released in the next two weeks.
- Part 1 - Getting Started.
- Part 2 - Working with HTML5 and CSS3.
In this article we'll work through how to utilize rounded corners and border radius properties as well as show how to deal with the issues that IE9 currently presents here in addition to utilizing Chrome Frame for those users that have it installed.
- Part 3 - Getting the page laid out.
In this article we'll work on getting the overall page layout in place. This will include standardizing on our core fonts as well as utilizing a grid to keep our stuff lined up nicely.
- Part 4 - Buttons, buttons and more buttons.
One of the most often stylized elements on any web based application is the button. The real question is, how we get them how we want them, along with some thoughts on tying buttons to inputs.
- Part 5 - Ironing out the wrinkles.
We will now work on getting things a bit better organized. We'll also deal with a few IE6 specific issues, namely the lack of attribute based selectors in CSS.
- Part 6 - Getting your script on.
In this article we'll get some initial functionality laid out in order to work through progressive enhancement as well as making sure to defer our scripts until after the content is ready for it.
Here I discuss my fairly comprehensive list of scripts I'll be including, as well as mention some that I'm not actively using but will be there if you need them.
- Part 8 - Inputs and Validation.
- Part 9 - Enhancing Inputs.
Here I'll create an enhanced input that will allow for a calendar control used in conjunction with a date validated input.
- Part 10 - Custom Notifications.
In my current position notifications of input validation errors and other messages are shown in popover modal dialogs that purposefully interrupt the user's actions. Here we'll work through the initial creation of such a popover and extend the jQuery validation to support this behavior.
I'll be adding additional articles in the future; the topics will present themselves as this project moves forward.
23. June 2010 20:52
You know, from the hiring perspective, I "get" that there are probably 10+ bad developers for every good one. I also "get" that you have to do some screening. Just the same, I get really anoyed when I have ro take my third test from a recruiter or consulting company on the same site, and have to create yet another freaking login on that site (previsor), or the couple dozen sites the likes of monster redirect you to in order to once again create a login, where you can't get the same username you've used for 15 years because it's tied to an email address you no longer use and haven't for a decade. Would it *really* be that hard to share some of this basic information. Not to mention the trivia quizzes riddled with questions on obscure corner cases you rarely use... I mean, I know enough of them to usually do okay, but after a while you really become a bit anoyed. Not to mentin kiling 2+ hours of your personal time on the code challenges "from scratch". I just killed 4+ hours last night, lost track of time, after going through one last week where I ddn't ask or think enough then cutting corners to have something working in time, I went too far over the top writing boiler plate code in PHP of all things, where the undisclosed rate is probably lower than I can afford to take.
I really wish there were a better way... Here's hoping one presents itself. In the past three weeks I've spent more time taking quizzes and talking to recruiters than the people doing the hiring, and coming from a group that recently went through hiring, I know there are still stacks of resumes. I wish this rant were fomulated a bit bettered, but it was my last day on a contract today, I've done yet another quiz and have yet another coding challenge tomorrow afternoon.
30. May 2010 14:41
Don't spammers ever "get" it? I mean, I have comments set to moderation, and disabling comments after two weeks, but still seem to get half a dozen or so for each new post, and my blog isn't even all that popular. I can't imagine what other blogs go through. It's really disheartening to be completely honest. Sometimes there are acts that just make me question society as a whole, and the proliferation of spam into every aspect of social online culture is one of them. This includes online chat, web boards, newsgroups and email itself.
I honestly feel that society is better off without this garbage, but I'll be damned if I feel any legal/government originated solution would ever work. This is simply a rant, and not suggesting anybody actually take action, but sometimes I really feel like the whole "Dead or Alive" type of warrants from the old west may not have been such a bad idea regards to spammers.
To be honest, working on anti-spam technology is actually a pretty big passion of mine. As someone probably more irritated by spam than most, but also running a hobby site, whose new members get email confirmations that are often caught in the spam traps on email providers. I really just wish there were at least *some* better solution out there. I think having reverse and forward DNS of the mail server match is a good start. A strict SPF record along with this would help. Followed by use of block lists. If all three of these techniques were used together as checks by everyone, I think the sheer amount of delivered spam would be reduced to near zero, with much less negative impact. Oh yeah, it would also require mail operators to act responsibly regarding their clients, and actually have some real form of contact for other mail providers/operators.
27. May 2010 10:19
Okay, I'm getting really tired of seeing posts like this one... So I figured I'd take some time to debunk the thing.
15. May 2010 15:42
Last night, I was working on my presentations for Desert Code Camp, all night.I honestly fell asleep around 5am and didn't wake up until around 3. I had all my test data setup for MongoDB, I had utilized a lot of the presentation resources from the MongoSF conference. Specifically re-tooling the "powerpoint replacement" script from Michael Dirolf. I've got about 2-3 pages of samples and notes here on that I'd like to cover.
Around 1am I was going over the node.js stuff for that presentation, amazing how much pain one mistake can bring (entered "kiwi.requires('express/plugins')" instead of just "requires(...)". The nodejs demo was made with parts from Craig R. Webster's "Getting Started With Node.js", and some parts centering on use of express/haml/sass thanks to the post from How To Node on "Blog rolling with MongoDB express and Node.js". I had meant to get a bit in on the CommonJS plugin conventions and a some templating with the haml and sass support, there wouldn't be time to tie it in to mongo.
I'm making this post, containing links to those resources I was deriving my presentations from, so the information is at least out there. The stuff on node.js is harder to track down, as unfortunately the node.js site doesn't link to outside demos much at all, and some of the documentation, even the api docs are hard to follow. MongoDB's site does better, but there's still a few rough edges in how the JS console (reference client) documentation is organized. If you have any questions, feel free to email me.