AmberWeinberg.com » validation

Becoming A Better Developer For 2011

Amber Weinberg — Mon, 27 Dec 2010 14:30:31 +0000

It’s time for the New Year to begin so we all know what that means – an excuse to learn and become something better than we already are1 For the holiday months, I’ve spent a ton of time learning, reading and trying out new coding techniques to find out what works best. Every site I code, I always try to do something a little bit different in order to constantly improve on what I’m doing.

Web technology is always evolving and it seems that every day there’s something new that’s come out. It’s enough to make a sane developer crazy – and unfortunately that means we can never take a rest from our world, or we risk being left behind. (Man that sounds like an awesome movie trailor…)

I’d love to share with you some of things I’ve been learning lately, as well as some new(or new to me) coding tricks.

HTML/HTML5

Frankly, I got so tired of hearing about HTML5, that I finally decided to try it. I now validate all of my sites in HTML5 and use all of the new shorten info in the head tag that comes along with it. However, I don’t use any of the hew HTML5 tags, as they require hacks to get them to work in Internet Explorer. We all know how I feel about hacks, and it’s isn’t good.

In order to help me learn and understand the updates to HTML, I’ve bought several books (and written reviews for you) on the subject:

HTML5 For Web Developers
Building Findable Websites
The Smashing Book
Hardboiled Web Design (bought but not read yet)

Of course I have a TON of books on my wishlist for all of these categories!

CSS/CSS3

I’ve been using CSS3 for several months now and have been able to convince my clients to embrace the idea of progressive enhancement. CSS3 has sped up my coding noticeably, as I no longer have to take the time to slice and code up images for shadows, rounded corners and the like. Also, the new advanced selectors have made my code cleaner and more efficient. I think this is why I’m starting to enjoy mobile development more – because I don’t have to worry about IE at all and can pretty much use CSS3 to it’s fullest.

And the books I’ve read on the subject:

Advanced CSS
Smashing CSS
CSS3 for Web Designers (bought but not read yet)

Improvements To Coding

All this book reading would be for nothing if I didn’t actually learn and implement any of it. In fact, I learned a ton and have made major revisions to the way I write CSS and a few to HTML as well.

CSS

I continue to prefer single line CSS, but I’ve now just started to put my declarations in alphabetical order. While I’m still getting used to this, it’s made it a lot easier to find what I’m looking for, especially on longer lines. I’ve also learned some nifty new selectors I never though to use before. The most helpful has been the use of:

 a > d {}

Which selects only the top level child of the element. This select has been so incredibly useful, I can’t believe I never used it before.

I’ve also started using shorter selectors and not chaining them as much. This makes the file smaller and quicker to implement on loading.

HTML

Besides switch over to the HTML5 doctype and using the new elements, there’s not much I’ve changed in my HTML. I have stopped using containers as much as possible, and instead have started centering the divs, and putting backgrounds on the and tags. This lends to much cleaner code.

To see examples of all of these, you’re welcome to download my Hijinks WordPress theme, which is the exact same theme I use for all the WordPress sites I code.

Other Languages/Platforms

I’ve also been experiencing with other languages and CMS’s and here are some books on those topics as well:

WordPress

I actually didn’t start WordPress development until the very end of 2009, I can’t believe how far I’ve come in learning!

Digging Into WordPress

Objective C
I spent most of the spring, summer and beginning of the fall reading this book. I’m still no where near to making my own apps, but the foundation is there.

Beginning iPhone3 Development

jQuery
This book has allowed me to start writing my own jQuery from scratch. No longer do I have to haggle with plugins or ask the fiance to do it for me.

jQuery Novice to Ninja

What about you?

What are some of the things you’ve learned this year in order to make yourself better for the next?

Validation Is Still Relevant

Amber Weinberg — Thu, 07 Oct 2010 14:30:44 +0000

I was listening to a Sitepoint podcast when they started talking about whether they still validate their HTML or not. This being my expertise, I quickly perked up my ears to listen to what the “experts” were saying. And I was disappointed.

Perhaps the guys who take care of the podcast aren’t coders, or aren’t front-end developers, and if that’s the case, then I forgive them for their validation transgressions. I just hope they really aren’t front-end developers…

What They Said

The guys at Sitepoint admitted they no longer validate their sites, and none of their sites could pass basic validation. They believed that because large sites like Google and Facebook didn’t validate, why should they? They then commented that validation is no longer important today.

Validation Is Important

I’ve always believed that validation is important, especially since I decided to focus my career on front-end development. Surprisingly, this is a source of a lot of debate in the development world, which makes about as much sense to me as policemen disregarding their standard rules.

Validation is written by the W3C, which takes care of HTML and CSS standards. Validation rules are like guidelines, you don’t have to do it, but it’s something you should do.

Passing validation helps in several ways – it helps you rule out browser bugs, your code tends to be cleaner in nature, and you help push a browser standard that will make it easier to code for in the future. Think about it – if developers didn’t care about following standards, why would browsers? We’d probably end up back in the Netscape/Internet Explorer days where each browser went off in their own direction in how they rendered items. It would be like hacking and coding for each browser – and we’re trying to move away from hacks right? (Which is why I’m holding off on using HTML5).

Plus it holds your code to a higher standard and shows you care about quality. Designers don’t have to use grids or good typography to make a living, both those that do are often more successful. The same with developers. I’ve actually had clients go through each of my portfolio pieces to see if they validated.

Validation Is More Important Than Ever

Not only has validation always been important, but it’s now more important than ever. Even though it can’t directly affect your SEO, getting rid of extra divs (divitis & semantics related to validation) allows the Google bot to make it through your code easier and ensures they capture all of your content.

With the proliferation of new kinds of browsers as well (think mobile, iPads & netbooks), validation becomes even more important. I just finished coding a huge mobile site for Audible and encountered several bugs invisible to Firefox and even the desktop version of Safari. Upon glancing at the iPhone, however, you could see huge layout issues. The problem was mismatched tags and improper nesting. Had I not gone and validated the site, I could’ve been searching for the bug for forever.

Resistence

I’ve never understood why a lot of developers never took the extra step to validate their HTML. A lot of the complaints I get about validating, is that it takes forever. However, it should easily take you less than five minutes to validate your code if you learn proper syntax and rules. It’s easy.

Of course, there are always exceptions to the rule. When a client insists on a new browser window popup on link, and for some reason you’re unable to use JS for this, you’ll often find yourself using target=_blank and that’s ok every once in awhile, although you should try to deter the client from new browser windows due to user annoyance.

I will admit that I don’t bother validating my CSS. Before CSS3 I never really had any CSS validation errors, and if I did it was easy to tell by the messed up website. Now that I use a lot of CSS3 and vendor prefixes, I don’t even bother to look. But these aren’t improper syntaxes or hacks – they’re still valid code.

Your Thoughts

Do you validate your code? Why or why not?

Building Findable Websites

Amber Weinberg — Mon, 16 Aug 2010 14:30:41 +0000

Building Findable Websites by Arron Walter is one of the best books I’ve read on the subject of SEO, web standards and accessibility in the world of code.

Aimed specifically to developers, Building Findable Websites is 264 pages based on several topics. This isn’t a regular SEO book, but teaches “findability” through good coding practices, including best practices for Flash, Javascript and AJAX. It also includes basic SEO information on keywords in titles, alts and density.

I skipped over a few sections because it included basic information I already knew or beginners info on things like using Feedburner, but I still found a ton of relevant material to keep me interested.

The book has a ton of resources and code examples and even gives access to several bonus chapters on online.

You can find Building Findable Websites on Amazon for $30.

Should You Document Your HTML?

Amber Weinberg — Wed, 30 Jun 2010 16:03:22 +0000

Anyone who knows anything about my development style knows I’m a huge stickler for clean, semantic code. It kills me when a client asks me to edit an existing site that’s filled with improper tabs, run-on coding, extra blank lines and divs name “div45673435534″.

I’ve been so proud of the development community lately, because I’ve watched the importance of clean code in the past year or so become very, very important. As a matter of fact, clients are now becoming educated in this subject and hire developers based on the quality of their code.

So I’ve noticed several recent articles on structuring code, and since I’m always looking out for new ideas, I’ve perused as many as these articles as possible. However I’ve noticed one alarming tip that most of these articles offer up to developers – that you should comment your HTML extensively.

I disagree that you should comment your HTML extensively – or even at all.

Now, before you flame my comments let me explain why.

What is the purpose of commenting code?

Commenting code is meant to do a few things. One, it tells any future dev who needs to work on your site what something does. Two, it helps you find what you’re looking for.

In languages like PHP, Javascript, ASP and Objective C, commenting is very important because the files can go on for forever and it’s not always obvious as to what something does. HTML, however, is not and should not be built like this.

Semantics comes into play a lot more in HTML than anything else. What your HTML code does should always be obvious, as HTML itself is very simple in nature and structure. Your divs should be named semantically, header for the header, footer for the footer. Your files should never be very long, thanks to the use of includes and repeating areas (like the header and footer).

Properly tabbing and spacing your code also gives it natural breaks that allow your eye to quickly find each section. Comments are not needed for this.

Commenting The Close of Divs

Open any HTML or WordPress template from Themeforest and what do you see? Closed div tags that are commented. Why do you need to label which div is being closed if you properly tab? Commenting this just makes for an annoying longer file. For example, what’s really the purpose of this:

Is that really necessary? Also putting comments like this blocks the eye from naturally discerning the short closed div tags.

Still with me?

If you’re a developer who’s worth anything at all your HTML should naturally be readable. I could possible see the need for a comment or two if you’re doing something extra wacky that may not make sense. But really, who’s not going to understand what a header div is for?

10 Ways To Increase Traffic By Changing Your Code

Amber Weinberg — Tue, 01 Dec 2009 15:29:40 +0000

Search engine optimization, or SEO, is a very complicated science. While no one knows exactly how Google ranks websites, we do have a lot of proven techniques.

Good SEO depends on several factors in your website, but when you usually think of SEO, you probably think of dealing with content and inward links. But did you know that there are several ways to improve your traffic and SEO by changing your code? Increasing traffic and rankings in code depends on three factors.

Read the Rest of my Post on FreelanceFolder

The 7 Habits of Miserably Failing Web Developers

Amber Weinberg — Mon, 09 Nov 2009 18:31:52 +0000

OK bad Stephen Covey references aside, we developers can often fail into bad habits while slammed with coding that eventually stop us from reaching our full potential. While some habits can help us speed up our work, others (like stuffing my face with candy as I type…) can do harm to both our business and personal life. Let’s put down the halloween candy and look at some of the bad habits you can develop in your coding life.

Habit #1: Couch-Potato-ism

Is this you?

We all love constant work and good downtimes. The only problem with both is that you can start developing a couch potato mentality. You either get into the habit of doing the same types of jobs day in and day out or you’re left with no work and staring at a blank computer screen. You’re not learning anything new. This is a good way to dumb yourself out of the field. You should be learning new ways of coding, tricks or even new languages every day.

I’ve heard a lot of people say to give your self “fake” client projects and practice that way. However, I don’t like to waste my time. Learning, per se, is never a waste of time, but I’d rather learn AND make some fat cash. (Ok maybe a little cash…) It’s difficult for web developers to do this, because we can sell photographs or designs, and there aren’t any stock code snippets sites out there yet (anyone want to start one with me??), but I’ve found a few good ways to up yourinsert-your-favorite-2-4-letter-web-language-game.

WordPress/HTML/CMS templates – I’ve recently teamed up with a designer, and we just finished our first template (hoping it will be out by the time you read this). Although I spent FOUR times as much coding time as I would’ve a paid site, and it’s a possibility I’ll make little to no money off it, I easily quadrupled my knowledge of backend WordPress in a weekend. I don’t even do backend programming. This learning experience = way worth it.
Books in other fields - I love reading. I’m a real geek all around. What better thing to do in my spare time than read a new book? While programming books are impossible to follow if you’re not sitting in front of a computer, web theory books are GOLD. I’ve been interested in doing some additional marketing for my site, which is why I picked up a copy ofSix Pixels of Separation a few weeks ago. I might go back and pick up a copy of Seth Godin’s Tribes: We Need You to Lead Us next.

Habit #2: Keeping a coded bird’s nest

My favorite thing in the world is opening a website that someone else has coding and going blind instantly. No really, it’s a pastime! Just as bad as designers who neither label or organize their layers in folders, developers need to be just as organized. Code inside of code inside of code needs to be properly indented.

Now imagine how much you’d have to spend if you were missing a closing div tag somewhere….Just make sure your code is always indented and spaced well. Top level touches the side, next element gets one indent, the next another etc etc.

Habit #3: Stuck in 1993…and proud of it

I bet this guy codes in tables...

I still have developers (especilly .NET developers…) that argue with me about tables. No, not a dining table – but that archaic way of laying out a page using static sliced images, Photoshop “programming” and Dreamweaver’s design view. If you ever want to be a real developer, you need to start using CSS properly. Tables should ONLY be used for tabular data…and eating on.

True story -> I’ve been making websites since middle school. My first website was a super cool site dedicated to my beloved Sailor Moon, beautifully laid out in frames and animated gifs (this was before image programs for me, so no slice tool!) Then along came Paint Shop Pro and it’s wonderful slice tool, hence the birth of Amber’ed Tables. I stopped making websites for a few years after I started college. I started one for my portfolio and guess what? Those few years that I’d been out of the web world, a little thing called CSS (See habit #1 above)…hence I was laughed out of a lot of web portfolio critique forums. I had to learn it like everyone else. (Yea yea, all you got out of this story was I was an anime dork, didn’t you?)

Learned the correct way, CSS IS easier than using tables (both have the same application “theory” anyways, i.e. versus

, and: more powerful, quicker to download, easier to make browser friendly, easier to move stuff around, easier on my eyes when I have to fix it and just plain easier…and correct.

Habit #4: One big ol’ image to rule them all

Bad developers use the slice tool in Photoshop like there’s no tomorrow. This is a horrible practice because it makes the website both static and slow loading. Only graphical data (pictures) should be an image; and the only time text should be an image is if the font isn’t web friendly and the client insists on using it. Also, if the client decides to change something after you’ve finished coding (which happens 99.9% of the time) and everything is an image…well that’s going to be a huge PIA for you. It’s also bad for SEO because like flash, a search engine can’t read an image, and an alt tag is held in less esteem that real content. Let’s take a look at some tips to reduce images:

Repeating Bkgs – Unless the bkg is one big image, it’s probably a plain color, which you can use a regular hex for, or a repeating image (look at my bkg). For repeating images, take the SMALLEST snip of the bkg possible that still makes it repeat correctly. I believe my background is only 1px wide and tall.
Buttons - If the bkg of the button can’t be rendered via CSS, it’s ok to use an image, however the text inside a button should be…text. I can’t tell you how many times I’ve had to change the text of a button!
1px regular horizontal dividers should always be an hr tag instead of an image

Habit #5: Stickin it to the designer

Seriously-love your designer and code, ok?

Just because you’re a developer with zero sense of design, doesn’t mean you shouldn’t care about the design. When a client or designer hands you a PSD they expect the website to look EXACTLY like the PSD. It doesn’t count to just throw up some code with some of the design elements and call it a day. I’ve had a few clients come to me because their programmer just threw up the site – and it was completely off from the PSD (we’re talking 50-100s of pixels) and none of the fonts were even the correct size, style or color. That’s a good way to lose your clientele. While no website will be exactly pixel for pixel, it’s to your advantage to actually figure out how many pixels div #1 and div #2 are from each other. It’s equally as important to make sure your fonts and colors match the PSD.

Habit #6: Who cares about standards? I make the rules!

You’ll probably get tired of hearing me say this…but validation and semantics are important!! (Notice the bold?) Why are they important? Do you struggle with browser compatibility? Do you have problems getting things laid out correctly? Do you have problems with code not functioning as you thought? Do you validate and use proper semantics? I bet not. While these things don’t always fix the site up perfect (I should tell you about the doozy of the site I coded this weekend) it gives you a HUGE headstart when trying to fix it in all browsers. When you don’t validate and something is messed up – you have to use all kinds of hacks and start at the code for long hours trying to figure out why something isn’t moving to the right; but if you’ve validated, you don’t have to worry about unclosed div tags, or something overflowing into something else. Plus it gives you a HUGE heads up in the community – I’ve recently seen a HUGE uplift in validation standards (thank god) and many agencies won’t hire you if you don’t validate.

Habit #7: Their code isn’t politically correct

A great developer names their elements and images with things that make sense: header, nav, leftColumn, rightColumn, buttonHelp, navAbout etc etc. A horrible developer names their items stupid things that don’t make sense: button1, button1234, image36, fatcat etc etc. Tell me, where on the website is button 1,234? Wouldn’t it be more helpful if it were named buttonAboutLady or buttonAboutHelp? In a year, when a client comes back to you and wants to change button 1,234, are you going to remember which button that is? While you can always look at the source; it still takes an insane amount of time, especially when its a HUGE website (think a hospital website) to go through 1,000s of images to figure out which one you’re looking for. Ditto in the CSS. Here’s how I try to name my CSS elements and images:

What is it? A nav item? Button? Callout?
Where is it? The homepage? About us? Blog?
Description? If there’s more than one types of these I’ll also give it a description.

I.E. An image on the about page of your cat may be called aboutCat, or a button of your cat on your blog may be called buttonCat or buttonBlogCat, depending on how complex your site gets. This helps later on, believe me.

A lot of these are easy bad habits to develop, or habits already developed by beginning developers. Work on these to become a better developer and I promise you’ll see an increase in the quality and amount of paid work.

What are some of your bad habits?