• Source code management (git, svn, mercurial)
• Branches in scm for development and production
• Separate test and prod server
• Deployment scripts/tools
• DB upgrade scripts
• Some sort of framework (Django, Rails, CodeIgniter, anything)
• CSS reset
• HTML5 doctype
• Follow yslow rules
• Bug tracking software
• Specs!
• Feature list
• Roadmap
• Schedule
• QA
• Code review
• Monitoring – nagios, munin
• Print out scm revision/changeset in comment at bottom of webpage
• Print out server name in comment at bottom of webpages
• Coding standards/guidelines
• Automated benchmarking/profiling, SLAs

What else?

An invalid or illegal string was specified" code: "12

Make sure you specify a full URL in window.postMessage like so:

parent.postMessage('hi there!', 'http://www.ryandoherty.net');

If you use a URL like: ‘ryandoherty.net’ you’ll get a very obtuse and unintelligible error message. I searched the internet for about 20 minutes to no avail. The error message apparently pops up for a number of other reasons. I’m posting this to hopefully help other people out!

Note: the following opinions are mine alone and do not in any way reflect my former employer Mozilla.

A few of you may remember my project ‘Cesium’ that started over a year ago. It was an idea I had to automatically record ySlow scores for websites. It was started by an intern under my direction and myself during the summer of 2009. Needless to say, it never launched. There are a few key reasons this happened (all directly my decisions/mistakes), and if you’re familiar with software development you won’t find any of this surprising.

Not invented here syndrome

This was my biggest mistake. When I announced my intentions, Sergey Chernyshev emailed me about his project ShowSlow, which was almost identical to what I envisioned for Cesium. Stupidly, I only saw ShowSlow for what it was instead of its potential. We could have worked together and added new features to ShowSlow that I wanted for Cesium. It certainly would have given us a huge head start, considering ShowSlow a) already worked and b) people were using it.

The next time I start any project I will seriously consider using/working on another project that meets 50% of my needs. Adding new features to an existing codebase is usually far easier than starting something from the ground up.

Choosing an unknown language and platform

Cesium’s codebase uses Django, which was picked by my intern (and approved by myself). Now, I don’t think Django is a bad framework or Python is a bad language, they simply were wrong for us. My intern had little experience with Django and I had none, which is certainly a bad situation when you need to get a project off the ground in a predictable time frame.

During the start of the project, I should have chosen at least a language and framework that I was familiar with. Learning Django and Python was time-consuming and could have been avoided. Remember: if you need to get a project out the door fast, stick with what you know.

Poor time estimates and priority

Again, another bad decision on my part. After my intern left at the end of the summer, Cesium was about 50-60% complete. In my head I think I believed it was closer to 90%, therefore I didn’t give it as much priority compared to other projects. I continually thought ‘Almost done, just another week or so’. Maybe if I was a Python and Django expert and worked 60 hour weeks.

I’m actually kind of surprised that I convinced myself it was almost done. When I’ve worked on other projects I’m usually the person tallying up estimates, doubling them and providing more realistic estimates for when it will be done. I think I let hubris cloud my judgement.

What I should have done was realistically estimate how long it would take for each feature/bug, multiply that by two then take a look at my other priorities. It would have shown there was at least a few more months of development. I could have then asked for dedicated resources or pushed off other projects.

In the end

A few weeks went by, then months. Eventually my disappointment in being unable to complete Cesium turned into avoiding it. So it sat. And sat. I now (personally) consider it abandoned and there are plenty of other better tools just like it out now. In all, it’s a humbling experience but certainly an educational one. Nothing really revelatory about why it was never completed, nothing new. But at least I learned a few things in the process.

ok i will be graduating with a degree in MIS this spring. many companies what software or web developers who know multiple languages like (HTML, CSS, PHP, JS, VBscript)

i heard it takes 10 years to become master in something. I know a little about each language but for someone to become fairly proficient in ALL of these languages i do not see how software engineers do it. Or do software engineers/web developers just having a fair working knowledge of each language? I hope you understand my question. Basically i want to apply for jobs but when companies ask for web developers that know multiple languages i cant say i am very efficient in ALL the languages. But i do have a little working knowledge and i can always improve.

When I read this email I new exactly how Chris felt. Most job descriptions are daunting. So many technologies! It’s easy to feel inferior and not apply. Here’s my response:

Hi Chris,
I understand your frustration with job postings, many of them list
lots of technologies and decades of experience. I have a lot to say
about job descriptions, getting experience and how to learn. My email
will be long, but I think it will help you a lot.

First off, most job descriptions are about 50% exaggeration. Companies
describe their ideal, perfect candidate. Unfortunately those people
don’t exist. There’s no way anyone could be an expert in 5 programming
languages and frameworks for 10 years when some of those technologies
didn’t exist 5 years ago. Descriptions full of buzzwords are often
used to attract many different people. Usually what happens is if
someone doesn’t know a particular language or technology it’s ok as
long as the applicant can learn it on the job. If you know a language
a little bit it’s usually not to hard to pick up the rest.

Also, a good company will look at potential during an interview. If a
candidate seems smart and able to learn quickly, they are usually a
better option than someone who has only worked in one or two specific
technologies for a decade. It depends on the job, but in my opinion
brains and ability to learn is more important than knowing a language
or technology in and out.

In my opinion there are a few skills for programmers that are most important:

1) Ability to learn/teach themselves a new technology/language. This
is mandatory. Technology changes so fast you cannot rely upon what you
learned in school. By the time you graduate it will be antiquated. You
need to know how to read documentation, Google effectively and be
willing to dive and and make mistakes while learning. There is a
phenomenal amount of information on the web about anything you’d need
to learn. You just need to find it Pick a technology or language
you don’t know and start building. Read tutorials, read books, build
something (doesn’t have to be fancy). Go to clubs or meetups about
technologies you’re interested in. Most of all, don’t stop learning.

2) Communication. This is #2, but probably should be #1. I cannot
stress this enough: If you can’t communicate effectively it doesn’t
matter how good a coder you are. Writing, speaking and negotiation.
I’m not a genius programmer, probably in the 60% or 70% percentile,
but I attribute my success to my communication skills. Write clearly
and succinctly. Talk professionally, be friendly. *Listen* to people
and understand their needs. Communicate your status regularly. Tell
people what you do.

With those two skills you will be ahead of probably 80% of all
programmers out there.

Regarding what you know now, apply to the jobs you want! What’s the
worst that can happen? You’ll get a lot of interviewing experience,
which is always good. And if you get a job, even better! Don’t sweat
not knowing everything, just focus on continual improvement and
learning.

Hope that helps,
Ryan

What do you think? Anything I missed or you’d like Chris to know?

Here’s a screencast of some of the new features:

For more info, check out the Mozilla Labs blog post about it or visit the site!

The long: An awesome book about web form design best practices that is backed up by real data and studies. The book oozes design from its glossy stock and full color images to the layout and typography. Overall you can tell that Luke is a great designer and has considerable experience with the usability of web forms. Luke covers just about every topic of web form design from from basic layout to help text to error conditions and about a dozen other topics.

Overall Web Form Design is one of my favorite design and usability books on my bookshelf for its breadth, beauty and usefulness.

So instead of just whining about it, I decided to rewrite Gmail in semantic, clean HTML:

http://ryandoherty.net/semanticgmail/

Why did I do this?

To challenge myself. To prove it could be done. To show people what clean, semantic markup looks like for a complicated app like Gmail.

What’s missing?

A lot. Many of the select menus should be DHTML. It’s just a basic inbox view so far, nothing more than that.

Why announce now?

The big challenge is over for me, writing the HTML and CSS. If someone else wants to work more on it, fine by me. I’d rather get this out than have it sit on my computer any more.

http://ryandoherty.net/semanticgmail/

Rather than throw up a bunch of slides and blab on about expires headers, gzipping and concatenating, I created an awesome social networking website called openSpaceBook. Go ahead and check it out, any login will work.

Now that you’ve realized you should cancel your Facebook account because this is going to be awesome, you can learn how it is pretty slow to load and how we can speed it up.

According to webpagetest.org, a handy-dandy webpage loading tool, it takes about 12 seconds for openSpaceBook’s home.html page to load on DSL. 12 seconds! And that’s just for a static html page, nothing going on in the backend. WTF is taking so long?

This is what’s taking so long:

26 HTTP requests, 773KB! Rendering doesn’t start until 12 seconds into downloading the page! (Thin vertical blue green line.)

Don’t think this page is bloated compared to other websites. Facebook has 182 requests and has 500KB in assets (down from over 1MB a few months ago). YouTube has 42 requests, 356KB. And those sites have most likely been optimized, openSpaceBook is not.

So I have this bloated website, but I can’t remove any features because I’ll lose the ‘ooh shiny!’ audience that I’m trying to attract. What should I do?

Step 1: Reduce HTTP requests

The first thing that can be done is reducing the number of HTTP requests. There are 3 reasons for this. One is every HTTP request has a small amount of network overhead, and the more requests you remove, the less overall network traffic.

The second reason is browsers have a limit to the # of HTTP requests they can make to a webserver (or hostname, specifically). Older browsers were limited to 2. Some newer browsers have upped that limit to 6 or 8, but they still have a limit. Therefore when a browser has reached its limit, it has to wait for requests to finish before starting up new ones. So the more requests necessary, the more queuing will occur.

The third reason is specific to JavaScript in that browsers will only download and execute 1 JavaScript file at a time. This is done because JavaScript can modify the DOM, redirect the page or do any number of things that may affect what resources need to be downloaded. So even if a browser can download 8 requests in parallel, JavaScript files will still be download sequentially. (There are efforts to improve this issue in Webkit and Gecko.)

So lets see how we fare after reducing our HTTP requests. I did this manually by copying and pasting all of my CSS files into 1 file and JS files into 1 file. I also took all my CSS background images and merged them into one. Then I can use CSS background positioning to only show the graphic I need.

Results after combining files

Shazam! Down to 5.8s! That’s a 50% increase in speed for less than 30 minutes worth of work. And 8KB has been shaved off of the page. Sweet. On to our next step.

Step 2: Set expires headers

Another simple trick that requires a few lines of code is setting expires headers. Expires headers are a type of header that tells the browser when an asset ‘expires’ from its cache. When you set it to years in the future, a browser will cache it and never ask the website again for it.

Expires headers look like this:

Expires: Thu, 15 Apr 2020 20:00:00 GMT


The assets you want to set expires headers on are things that don’t change much. Like images, CSS and JavaScript. I know, CSS & JavaScript might change every week or two and this can result in your users never seeing new content. The way around this is to change the filename of your assets whenever you update them. This can be done manually or with a build script of some sort.

You can set expires headers in Apache by adding this to your httpd.conf or .htaccess file:

<FilesMatch "\.(ico|pdf|flv|jpg|jpeg|png|gif|js|css|swf)$">
Header set Expires "Thu, 15 Apr 2020 20:00:00 GMT"
</FilesMatch>


So let’s see how we fare:

Hmm, 6 seconds. No improvement. Not surprising, we didn’t really change anything. In fact, we actually added an extra header per request. The extra 0.2 seconds could be due to this or due to varying network latency or utilization.

What was improved was repeat response time. Down from 1.3 seconds to 0.6 seconds. And this performance improvement is carried over to all other pages. Any previously cached assets will not be downloaded again or checked to see if there is a newer version (If-Modified-Since request). So a user’s multiple page view experience will be significantly faster.

So what else can be done to really improve performance?

Step 3: Gzip your content

Now we’re talking. Compressing your content is an easy way to significantly reduce the amount of data transmitted. HTML, CSS & JS are all text, so they compress very well. So let’s see what kind of performance increase we get when we compress our content.

Yes! Down to 2.7 seconds! And we’ve cut the amount of data down to 223KB, which equates to $$$ saved when you pay for bandwidth.

To gzip your content in Apache, you can add this to your httpd.conf or .htaccess file:

<IfModule mod_deflate.c>
<FilesMatch "\.(js|css|html)$">
SetOutputFilter DEFLATE
</FilesMatch>
</IfModule>


Step 4: Move JavaScript to the bottom

Remember way back in step #1 when I said browsers only download 1 JavaScript file at a time? Well, they also block rendering of any content after them in the DOM. So when your JavaScript is referenced at the top of the page, like most webpages do, it blocks the rest of the page. The solution? Move them below all your content!

Here’s what happens when you move your JavaScript to the bottom of the page:

So, down to 2.4 seconds (even though the amount of data is the same, discrepancy most likely due to network latency or bandwidth fluctuations between tests), but the rendering of the page starts at 0.9 seconds as opposed to 2.3 seconds in step 3. This makes the page appear to load faster because the browser will begin to show content before it has finished downloading the JavaScript file at the end of the page.

So, we’re down to 2.4 seconds, can we do any better? You’re darn tootin’!

Step 5: Minify CSS & JS

Hang in there, we’re at the last step. Here’s another way to reduce the amount of content sent even more. Minify your CSS and JS. Basically this means removing all newlines, comments and unnecessary spaces. It can also include programmatically replacing variable names in JavaScript with shorter ones.

The easiest way to do this is to use a compressor like YUI Compressor. It’s a Java app that takes a CSS or JavaScript file and spits out a minified version.

So how well does openFaceBook do after minifying?

2.2 seconds, not bad. Down to 154KB too. So openFaceBook has gone from 12 seconds and 773KB of data to 2.2 seconds and 154KB. That’s a 81% improvement in load time and a 80% decrease in page weight. And all those steps took me about an hour or two to do. That’s a pretty good ROI for a few hours worth of work.

Summary

Speed is everything. It’s a feature that is often left out of PRDs and users’ thoughts about websites, but it’s there. And they notice on a subliminal level when your site is slow. With all the hoopla about how browsers are getting faster and faster, how fast you can deliver content to your users becomes more and more important.

Resources

• WebpageTest
• Yahoo! Exceptional Performance

So in some of my previous posts about becoming/being a web developer, I say you should write code, lots of code. I also think the more varied real-world experience you get, the better developer you’d be.

So how can you get more real-world experience when you are a student or have a full-time job? Easy, you can write code for Mozilla!

Want some Python, Javascript and MySQL exeperience? Help us with our Graph Server. Dying to show off your killer PHP skills? Help us with AMO. Want to work on Drupal? Work on spreadfirefox.com. Want to work on some crazy futuristic ideas? Check out Mozilla Labs.

All of our code is open source and available through svn.mozilla.org or hg.mozilla.org. You don’t even need an account to checkout the code!

The basic workflow would go something like this:

• Take a bug
• Submit patch
• Ask someone to review the patch
• Once reviewed, submit the patch
• Pad your resume

Want more info? Check out the wiki and mozilla.org/contribute.

Photo from onthetower.

There’s been so much talk recently about performance and scaling thanks to Twitter and I really want everyone to shut up about it.

“Language Foo can scale better than Bar!”

“If only they had used language Baz!”

Pay attention to this part because I’m only going to say it once:

Your code doesn’t scale, your architecture does.

I’ve been reading about scalability for a while now and participated in a few highly-trafficked websites and I can say that the language that we used was the least of our concerns. And it would probably be trivial no matter what language we chose.

Every time I’ve ever heard someone talk about scaling issues, I don’t hear them talk about the raw execution time of their code. It’s always about disk I/O, database performance or network capacity.

When I interviewed at Insider Pages a few years ago they never mentioned Ruby or Rails as a limiting factor, it was databases and their network. A nice blog comment about Insider Pages mentions scalability tactics.

When Scribd talks about scaling with Rails, you don’t hear them mention Ruby. It’s all about adding databases and caching. (Please remember Rails is a framework (an architecture for your code) and Ruby is a language).

Flickr talks about scaling a lot [PPT] and they don’t mention PHP. They mention database sharding, caching and capacity planning.

Even Twitter’s status blog never mentions Ruby as their bottleneck. They mention database and database, load balancing and caching . Blaine Cook’s presentation about scaling Twitter mentions databases and caching. (I know, I know, he left Twitter, but his comments are still spot-on with common scaling issues.)

Yahoo’s former engineer Jeremy Zawodny has an old presentation on scaling PHP and MySQL and he never mentions PHP as the bottleneck.

So remember kids, when you are thinking about scaling, think about your architecture.

I subscribed to most of them and a few others, and here’s my writeup of the ones I think are worthwhile:

css-d

http://www.css-discuss.org/

Very high traffic list. Beginner to intermediate questions about CSS.

javascript-official

http://tech.groups.yahoo.com/group/JavaScript_Official/

Medium traffic Javascript list. Mostly beginner questions.

yui-performance

http://tech.groups.yahoo.com/group/exceptional-performance/

Low traffic front-end performance mailing list. Very high quality questions and answers.

public-webapi

http://www.mail-archive.com/public-webapi@w3.org/info.html

High-quality mailing list about the next APIs in web browsers. Very technical and active.

ydn-javascript

http://tech.groups.yahoo.com/group/ydn-javascript/

High traffic and quality mailing list about the YUI JS library. I actually unsubscribed because it was so active. Great for developers using YUI.

jQuery development

http://groups.google.com/group/jquery-dev

High quality mailing list about the development of the jQuery library. Medium traffic, very technical.

Even though I no longer work at Yahoo!, I had to blog about the Messenger website redesign (internally known as project Aurora).

I started working on it around December 2007 on preliminary planning, scoping and design feedback. After we had the specs nailed down, we hired Ryan Parman as our main developer to build out the site. Adrien Cahen worked on a new PHP framework for our site to run on and I worked as the project lead/architect/go-to guy for anything tricky.

Awesome things about the site

Shiny new CSS & HTML

We scrapped everything we had and rewrote it all with YUI Fonts and Reset. MUCH cleaner and more semantic.

Better Performance

The old Messenger website had gotten quite slow over time and I spent a few months cleaning it up to get a decent ySlow grade for the homepage and download page. The new site is blazin’ fast, getting A grades on all pages except the Plugins page, primarily because the images are pulled from the Yahoo! Gallery website and they don’t set appropriate cache headers.

Fantastic Configuration

Building a site for nearly 30 localizations isn’t easy, and configuration is one of the hardest parts. Every locale has specific features and needs that increase the complexity of the site. Ryan, Adrien and I spent a lot of time figuring out the best way to do this and I think it’s much better than before. We have base configuration files for each locale and every page is locale agnostic, it simply loads the appropriate configuration file for the locale you are viewing.

Automagical Content Updates

In the old Messenger website, we had configuration for the IMV gallery in two locations, one of them remote. In order to display a page of IMVs, the data had to be merged, which ended up in lots of code and duplication of information. The new website fetches information for the IMV and Plugin galleries automatically and caches the content. No configuration resides on the webservers, so there’s a lot less work on our side to update and edit content.

Many thanks to Ryan, Adrien, Sarah, Lorraine and Tak at Yahoo!. Good work guys!

What does semantic markup mean?

Semantic markup usually means using proper HTML tags for your content (p tags for paragraphs, divs for large content areas of your page, tables for tabular data, etc) and meaningful classes and id’s for your CSS. It also means not putting any inline CSS or Javascript in the body of your HTML page. There are exceptions to this rule, but for most of the time, this is how a properly coded webpage will be structured.

Knowing the answer to this question means the interviewee has been paying attention to web development for the past 5 years. It also means they understand the proper design and coding principles like separation of content (HTML), style (CSS) and behavior (JS).

Describe the box model

The box model describes rectangular boxes that are generated for elements in a web page. The properties of these boxes are margin, border, padding, width and height.

If an interviewee doesn’t know this, they probably haven’t read 1 book or website about the basics of CSS.

When would you use a table in a webpage?

For tabular data. Representing data in a database or a spreadsheet. NOT for layout

Tables for layout is definitely in the past, so if a developer talks about using them for layout, they’ve been out of the loop for a long time. CSS is for layout, it provides much finer control and allows for semantic markup of your content and data.

Is Javascript an object oriented language?

Yes, Javascript is an object oriented language. Base objects or classes are called prototypes. They allow for dynamically adding attributes and functions to the prototypes and they will immediately be available to all instances of the prototype. (There’s a lot more you can do with prototypes)

This question is actually a tough one. Lots of developers program in Javascript frequently and never learn more than the basics. Learning about Javascript prototypes is one of the first steps in understanding what makes Javascript different than most classical object oriented languages

Can you assign behavior (open a new window, show/hide an element in the page) to a link in a webpage without placing any Javascript in your html markup?

Yes, you can. 1) Include a Javascript file in your document 2) Search the DOM for the link by Id, class or tag. 3) Attach a function to the element’s onclick event via the addEventListener (W3C event specification) function or attachEvent (IE). 4) When the function is called, perform the required action and stop the event from continuing via event.stopPropagation or event.cancelBubble (IE), event.preventDefault or event.returnValue (IE).

Events are very tricky in browsers. I had to research a bit to figure out how to do it without a Javascript library. If a developer mentions adding javascript:foo() into the href or onlick=”foo()”, they most likely haven’t learned about proper separation of HTML and Javascript. They also most likely don’t know about graceful degradation/progressive enhancement. This allows for handling search engine crawlers, browsers with Javascript turned off, Javascript errors that stop execution and mobile browsers that don’t support Javascript.

What’s a closure and how/why would you use it in Javascript?

This one’s tough. I’m still learning how closures work in Javascript. In very simple terms, they are references to variables or functions inside a function after it has executed. (I think that’s a good explanation.)

A good use for them is to hide variables or functions from external code. This is similar to private variables and functions

Knowing at least the basics of Javascript closures means you know Javascript pretty well. Once you learn closures and how to use them, you can start doing really nifty things with Javascript.

How do you debug a webpage?

Lots of ways. Alert statements (basic debugging), Firebug, DebugBar, DragonFly, Web Inspector, and Developer Toolbar.

Knowledge of development tools is important and increases productivity immensely when you can inspect your website’s state without using alerts all over the place. Programming large websites becomes tedious and time-consuming if you don’t have tools like Firebug or the Developer Toolbar.

What are some ways to increase performance of a web(site, page)?

Any number of these methods.

With the current proliferation of AJAXy web apps and Web 2.0 designs, sites are getting much slower. Knowing how to take a site that loads in 5-10 seconds and cut it down to 1-2s is very important. Users do notice and care how fast sites load, and so should you.

Those are my questions, what are yours?

Basically it’s a 10 week intensive front-end engineering course that ends with a full time job at Yahoo!. Despite all the bad things that have happened to Yahoo! in the past few months, it’s still a great place to work and you won’t get anything like this anywhere else. The front-end engineering discipline is taken extremely seriously at Yahoo! and you will learn more than you could ever think of.

A few days ago a friend of mine asked me how he could improve his skills/knowledge of web application design and development. I had some recommendations for him, and it really got me thinking. How does one become a great web developer? It’s such a huge field that it’s hard to know where to start. Here’s what I’ve come up with so far:

Experience

I know many people are looking for a book, website or class that will make them a great web developer. After a lot of thought about how I became a (semi) decent web developer, experience really seemed to be reason why. You simply cannot become proficient at anything without doing it. A lot. And web development is no different.

Don’t believe all those “Teach Yourself X in 24 Hours” or WYSIWYG tools, you need lots of varied experience to become a great web developer. It’s rare having 1 job will teach you every part of web development, it’s such a huge field. The basic technologies/skills that are involved are HTML, CSS, JS, 1 back-end language minimum (PHP, Ruby, Python, Java, Perl), interface design, semantics, information architecture, systems architecture, database design and scalability. And that’s just a start!

Odds are you need about 2-3 years of experience before you can call yourself ‘experienced’. You need to write code, lots of code. Bad code, good code, messy code. Doesn’t really matter as long as you can look back at it in a few weeks/months and say “This code is crap!” (I do this frequently). You also need to break things, make mistakes and blow through a few deadlines before you can begin to understand the ‘soft’ parts of software development.

Continually learn

I’ve heard this from lots of other bloggers and tech gurus. If you aren’t constantly learning and expanding your skill set, you will be left behind. Technology moves fast and keeping up is paramount.

Continually learning means everything from experimenting with new technologies, reading blogs and books to going to conferences and technology groups in your surrounding area. You need to expose yourself to as many new ideas as possible all the time. You are never ‘done’ learning and can take a break.

Being a web developer/programmer is like being a shark, you have to keep moving to stay alive.

Finally

Actually, that’s it. A lot less things to follow than I thought. Add comments if you have more ideas, I’m always interested in new information!

Things to read/check out

Don’t think that by reading these books and blogs you’ll instantly become a great web developer, I still consider myself average to above average.

Books

• The Pragmatic Programmer
• Becoming a Technical Leader
• In Search of Stupidity
• Hackers & Painters
• Blockbusters
• Joel on Software: And on Diverse and Occasionally Related Matters That Will Prove of Interest to Software Developers, Designers, and Managers, and to Those Who, Whether by Good Fortune or Ill Luck, Work with Them in Some Capacity
• The Best Software Writing I
• Behind Closed Doors
• Managing Humans
• The Mythical Man-Month
• Peopleware: Productive Projects and Teams
• The Non-Designers Design Book
• Founders at Work
• Good to Great
• Dreaming in Code
• The Art of the Start
• Maverick
• The Design of Everyday Things
• The Art of Project Management
• The Art of Innovation
• Building Scalable Websites
• Designing with Web Standards
• Bulletproof Web Design
• Web Standards Solutions

Blogs

• The Daily WTF
• Ajaxian
• ejohn.org
• High Scalability
• IEBlog
• miscoded
• Nate Koechley
• NCZOnline
• Quirks Mode Bug Report
• Quirks Mode Elsewhere
• ReadWriteWeb
• Scruffy-Looking Cat Herder
• Software Development in the Real World
• Yahoo! Developer Network blog
• Yahoo! User Interface Blog
• A List Apart
• Business of Software
• Coding Horror
• Joel on Software
• Scott BerkunThe Department of Style
• techno.blog
• Bruce F. Webster