Hack zero: Switch to Gmail
This is not a joke: Gmail is a fantastic and nearly spam-free platform. Notably, you can hook it up with a custom domain name so no one knows you are part of the Goog machine like everyone else.
Hack one: Greylisting with Postfix on Ubuntu
A mail transfer agent using greylisting will “temporarily reject” any email from a sender it does not recognize. If the mail is legitimate, the originating server will most likely try again to send it later, at which time the destination will accept it. Wikipedia: Greylisting
Assuming that you have your own email server, greylisting is genius. Diabolically elegant, really. If you run an email server (or any server that can receive email) you are probably running the Postfix MTA, in which case their is a main configuration file appropriately named main.cf. A couple of edits to this file and you are on your way.
Here’s how this setup looks (not my graph but I have definitely seen this happen on production mailservers):
The really brilliant thing about greylisting is that it it deals with spam way before it ever reaches your inbox, which is the only way to go (I don’t use any spam filtering on my mailbox. That’s too late, especially from a sysadmin perspective (think of the children cycles!).
Step one: install postgrey.
apt-get install postgrey
Two: edit your main.cf file.
sudo vi /etc/postfix/main.cf
Three: Then open it up and look for your smtpd_restrictions; add the following line:
check_policy_service inet:127.0.0.1:60000
Four: Reload Postfix
/etc/init.d/postfix reload
Hack 2: DNS Blocklists
This one is even easier, requiring only an extra line (for each blocklist). The blocklists are Just put it right there in that same block in main.cf. I typically use four of them. (Each has a slightly different purpose and tolerance. Check out the sites to get a flavor for why they exist.) This one is actually my favorite — it was created by the geek premier Paul Vixie and uses a DNS lookup for an extraordinarily light overhead.
Step One:
Open your main.cf file again and add these lines:
reject_rbl_client list.dsbl.org,
reject_rbl_client sbl.spamhaus.org,
reject_rbl_client cbl.abuseat.org,
reject_rbl_client dul.dnsbl.sorbs.net
Then reboot Postfix:
/etc/init.d/postfix reload
As with the example above you will also want to watch your mail log to make sure nothings gone wrong.
sudo tail -f /var/log/maillog
Hack 3: Keep Spammers out of Your Forms
This is really the ideal place to stop spam: before it happens. There are a bazillion ways to prove that someone is a human (CAPTCHAs … sigh), but I think it is instead better to put the burden on the bots.
Step one:
Add a hidden field to your form.
< textarea name="comment" class="hidden" >
Step two:
In your handler, ignore anybody that filled out that form (as robots will do). Here’s a fragment in php (assumes that the presence of a errors array will prevent submissions):
if (!empty($_REQUEST['comment'])) { $errors[] = “No Spam please.”; }
Those are my favorites, let me know if you have any others!
If you need a professional application server, particularly for rails, I’m recommending Rimuhost these days.
Their VPS plans are a reasonable deal, but, as always, the support is what is always most important when choosing a host unless it’s a super small static site, in which case the big guys like mediatemple, dreamhost, bluehost are fine. (Oh and check wordpress.com if you need a free site.)
Just now I’ve been getting really clear, friendly, (and super fast) support from Brandon at Rimuhost, and he showed me a great trick for removing a password from a ssl cert:
cd /usr/local/apache2/conf/ssl && mv sitename.com.key sitename.com.key.with_password
openssl rsa -in sitename.com.key.with_password -out sitename.com.key
Previously one of their techs was chatting to me well into the evening about a SQL issue I was having, free of charge, after he got off of work, just cause he was cool. and I love their VPS control panel, which lets you reboot, power down, and upgrade your RAM/HDD on the fly.
If you need a development and production box, they will clone your production VPS (for free), in under an hour. Fastest demo box I’ve ever set up!
There’s this great movie called A Beautiful Mind that I saw once, and in the last few months I’ve been quoting it a few times when talking about my programming career. Overall it’s a great story, but the one scene that really gets me is when he (John Nash, famous mathematician) is standing in front of a class at Princeton and he puts a particularly complex problem on the board.
It’s the first day of class, and he puts the problem on the board, and then explains how complicated the problem is.
“This problem will take some of you a few months to solve, … for others, it will take the rest of your natural lives.”
Assuming that I could ever even get into a Princeton math class (uh, no), this would be when I walked out. I would drop it and go back to something easier to BS, like a user experience research class.
I mean, what fun is working on things that you can never really GET? Things that you aren’t born with?
Anyway, this has basically been my experience since I’ve moved to San Francisco. As in, totally getting my brain fried by the stuff I see other programmers doing — programmers who were just born with it. I meet guys in coffeeshops and they tell me casually about the device drivers they’re writing. (Seriously, he was building an android or something.)
And thus, in spite of really really wanting to be a great programmer, and thinking that I was pretty good at it, I now realize that I am a shitty programmer, and I always will be. I mean, I think I’m probably around the 50th percentile of programmers, but the problem is that I know about 1% of there actually is to learn in Computer Science. I am the guy who spends the rest of his life trying to figure out the problem on the board. And this was not a good realization. I actually was pretty depressed when I thought about it this way. I was just so much happier when I thought I was a l33t hacker a few years ago.
I am consoled somewhat by the fact that you are probably a shitty programmer too (jk jk jk), but in the last week I had three much more useful realizations:
When it is ok to be a shitty programmer
- You absolutely love it. I saw this guy walking down the street with a beat up cello the other day. And I was thinking about this problem and saying something to myself like, “I’ll bet he is probably in the bottom 30% of all cello players.” This guy probably will never play Bach’s cello suites. But of course, he was on his way to a great gig and was gonnna have an awesome time with has prog-chamber-rock outfit. With a big ass grin on his face. That’s reason enough to work on some impossible problem long after everyone else has it figured out — just cause it’s a fun process.
- You bring something else to the table. If you are a shitty programmer but you can talk to people and help them collaborate, maybe do a bit of design, or do design research, or you just have a strong creative vision — these are all qualities that are missing from some of the greatest programming minds.
- You are working on something important to people. This is the point I was making a month ago about all of the recent web standards fuss: Amateurs are doing more important things than you are, fancypants. And that’s so rad. I mean, imagine that you are a brilliant programmer working on device drivers for some machine that counts money all day for some investment banker or something. Who cares? You can write a million programs that count a bazillion dollars and you will die really rich, but you won’t DO anything. Find projects that are really important, gigs that actually impact people’s lives in a positive way and you are already DOING much more important work than the most brilliant programmers (who are meanwhile busy deep in their cubicles, dying rich).
Don’t get me wrong. It’s not OK to write shitty programs. People deserve good software. That’s part of the point: if you are a shitty programmer, fess up. Find your role on a team. But once you have crossed some basic threshold of capability, and you can build something that is useful, and usable, and you have a great time doing it … then you can really get to work making a difference in the world with your work.
And anyway, being academically in the top 10% of your field typically produces completely perfect, completely conservative, crap. Right?
Three videos for your Sunday afternoon enjoyment. (The first two are for the hippies, the last one is for the geeks.)
The Corporation
“Among the 40 interview subjects are CEOs and top-level executives from a range of industries: oil, pharmaceutical, computer, tire, manufacturing, public relations, branding, advertising and undercover marketing; in addition, a Nobel-prize winning economist, the first management guru, a corporate spy, and a range of academics, critics, historians and thinkers are also interviewed.” The Corporation
The Story of Stuff
“The Story of Stuff is a 20-minute, fast-paced, fact-filled look at the underside of our production and consumption patterns.”
Rspec User Stories
“The implementation of RSpec stories also fills a gap once filled by Rails’ integration tests. RSpec stories run against the whole stack of your application, including routes, controllers, models, and views.This 50-minute screencast introduces stories and shows you how to use them with pure Ruby code or inside a Rails application.” [This one ain't free! But totally worth it. -ed.]
I’ve been following the recent debate about the future of web standards and whatnot. It’s been making me think a bit about what I really want to see in the future of web standards. And I can’t get this great California zine Cometbus out of my head. (Well, ok, by “following the recent debate” I’m just trying to find a smart way to say I read a few blogs. Every single one of which is linked to on Tuesday by Jeremy Keith. Except this one from Thursday Zeldman post. Zing zing. Good stuff. Read the comments for sure. Or just read my post first if you want to feel good about skipping it altogether.)
Anyway, lemme explain.
In its essence I think that the call for better, more ambitious HTML and CSS specifications is great. Obviously it’s crazy that we’re just evolving to CSS 2.1 candidate recommendation after what, six years? (And I could have sworn we already passed the mark but, ok, I’ve complained enough about it enough this week).
Anyway, it’s all well and good. Things are slow. (per Zeldman: “a slow bitch.”)
Besides, really, most of us wouldn’t have a job if it was not for IE6. :)
But one of most the interesting points raised somewhere in the debate goes something like “We need to sometimes ignore web standards and screw around with doing cool stuff. Then the people who write the specs will HAVE to include all these cool ideas we came up with. YAY! Bring on the browser wars!”
I think this is awesome. Geek out with your canvas elements already.
One thing I would observe, however, is that most web developers are not professionals. And this is a Good Thing. The network is good because it is made up of people, real people, who are much better at Whatever They Do than they are at creating websites.
One thing I would observe, however, is that most web developers are not professionals. And this is a Good Thing. The network is good because it is made up of people, real people, who are much better at Whatever They Do than they are at creating websites. They write about industrial ergonomics or your new nephew or architectural criticism or lolcats. Smart stuff, stupid stuff, it all aggregates into a wonderful brown sludge and the one thing that 99% of the network has in common is that they can’t write code to save their life and really they could not give a damn about about all. At ALL. And they never will of course.
Amid all of the verysmart talk about the need for more advanced specifications, we should remember that no one really pays attention to them. They don’t even know that they freaking exist. I mean, do you care about the fancy traffic-law setting bodies that surely exist? No, of course, not you just want to go somewhere.
So the reason this whole debate doesn’t matter for the millions of Real People is that people don’t need to write code anymore. They just need tools to help them publish their content. And, oh yeah, let’s remember that there are BILLIONS of people don’t even have the luxury of doing any of this stuff yet.
Somehow, Real People people need tools that help them just go somewhere. Nothing in any spec matters until it filters into the tools that real people can use, like blogging platforms, CMS’s , and IDE’s. So let’s keep out heads and remember there is so much more to this “web” thing than proper validating HTML5 or CSS2.1 or XHTML2 fancy things, as good as those will be.
Thinking about this seems depressing at first. The issue really is about browsers and blogging tools, content rendering and content creation. The problem is even bigger than IE (which, holeeshit, passes ACID2!!).
But, for me at least, it is a reminder that we already have more capability on the web than we ever could use.
So yeah, think of the photocopier and zines.
What can you do with a fancy new photocopier that you couldn’t do with one from 10 years ago? Not much. Once you’ve cleared the hurdle of cheap, pushbutton printing, you’ve launched yourself into a world of possibility greater than most people can deal with. You accomplish the most important part of the web just by being a great writer, and photocopying it. So I would submit The most important thing about the web is simple, powerful, ultra-low-fi communication, multiplied over and over and over. Connecting people to people. Photocopier innovation, traffic rules, W3C debates … they just really doesn’t matter to the DIY kids making zines, because, well, who CARES?
The best thing you could do is give people more photocopiers, and make them really really easy to use. Make em cheaper, make more of em and screw the Canon XTRZ-992834 with laminating and pink staples. Screw variables in CSS. Because lots of people haven’t got photocopiers, much less telephones, much less usenet or blogspot and definitely none of us really have the capacity to use any of it to its community-centered potential.
Just sayin.
In light of the litigious, melodramatic backwater that the CSS spec has fallen into, I thought it would be worth writing up a teensy, non-brilliant-but-incredibly-useful DIY hack for stylesheets.
In my mind, there is really no way of getting around CSS if you are working on the web. CSS makes your site ugly or beautiful, rendering a site in just a split second of processing right before your retinas pass information to your brain. I love it; it’s one of my trustiest tools. Back in the day I did enough hard time with tables and inline FONT and MARGIN stuff that CSS really was a revelation for me.
So yeah, CSS, I love you, even if you are spooky and crusty and awkward sometimes. And did I mention annoying? Ok sometimes REALLY annoying. … Sometimes it’s late, stuff’s completely hosed by SOMETHING in this bloated stylesheet, and I realize that I’ve just learned to survive on CSS island with a sturdy coconut helmet and strong superstitions about absolute positioning or a negative margin or that extra wrapper div.
That’s mostly Microsoft’s fault, but besides all the browser bugs, it’s really a pretty dumb language. Seriously, what does it take to do a just bit of real vertical positioning without total hackery? And aren’t computers good at this whole MATH thing? So why can’t I do p { width:(100% - 40px);}
Huh? I’m talking to you, CSS. I would break up with you if my salary didn’t depend you.
ANYWAY, there’s a good open source philosophy that goes something like “don’t bitch without a better idea” so here’s three issues that have a solution that I’d like to humbly point out actually have an existing solution.
First, The Solution:
Parse your stylesheets on the server! You can do this in all kinds of languages and frameworks. Hell, you could even do it client-side with javascript if you really wanted to, but for my purposes I’m banging on Ruby on Rails and have fallen in love with the CSS Dryer Plugin which processes the stylesheet dynamically with ERB. (NOTE: READ THAT THERE FULL POST BEFORE JUMPING IN, COWBOY. There’s an important bug with comments in blocks.)
This is decidedly a Not New Idea. But for some reason it’s Just Not Done among most of the developers I work with, who I guess are probably also wearing coconut helmets and carrying around good luck charms.
And, let me tell you, this is decidedly one hack that I no longer am without. As long as you are already proficient with CSS it takes about an hour to figure it out, and then you will never look back. Seriously. This is a good one. I don’t often write much technical stuff here.
Here are the gigantic CSS annoyances that server-side CSS parsing solves for me:
Problem 1: No Variables!
This is a trivial problem really when you start parsing your stylesheet. Most useful for setting a few color variables at the top of the sheet, then you can swap out pallets sitewide. Whiz Bang! Reason enough.
Problem 2: Ridiculous Redundancy
A decent stylesheet has some degree of scope, which makes your stylesheet more readable and your styles most contextual. That is, instead of just saying p {color:fuchsia;} it really is best to have something more specific like div.column p {color:fuchsia;}. But then when you have to repeat the contextual selector (the stuff in front of the p element) every time. So CSS Dryer lets you turn this:
body#homepage div.column p {color:fuscia;}
body#homepage div.column p span {color:black;}
into this:
body#homepage
div.column {
p {color:fuscia;
span {color:black;}
}
}
}
WOOO! This is completely DRY code that renders into exactly the same thing as above before it hits the browser. So this example actually adds a few lines, sure, and it looks more complicated at first, but trust me, this is MONEY. On a stylesheet for a decent size application I ended up with about 25% fewer lines. This is great and all, but the real benefit of having every style nested in its proper context is actually solving …
Problem 3: Stylesheets Get Really Bloody Complicated for Big Sites and Teams
Have you ever been on deadline and cranked out a big stylesheet at 3am and then had to come back to it in a month and actually make a tiny change, only to realize that hey, look, it seems like this should work, but somehow the damn padding on this div is being set in three places, and when I fix it the good and proper way just makes things go ALL to hell and now for some reason I’ve got to put negative freaking margin on this thing but it looks right so I guess I better get back to real work? I hate that. I write bad CSS. A lot. I’m busy and dumb. And it’s maybe that I’m just distractible and impatient but dammit I’m gonna blame it on the fact that this stylesheet is HUGE and I’m tired and I can’t Firebug this page enough to find all the relevant styles. You could also blame it on the other dorks on your team who don’t use the same organizational rules that you’ve been using for years. Blame it on you ex-girlfriend. I don’t care. Cause nested CSS fixes this junk COLD. Take an afternoon and rewrite the project you’re on with nested CSS and you will have a stunning beauty of a stylesheet in which EVERYTHING has it’s place. You feel like a samurai when you come back in a month. That style is set in ONE place. It won’t save you from IE, but you feel like you’re back in touch with the craft.
6/25/07 UPDATE: I am obligated to point out that this little script has graduated from interesting to useless — thanks to the new Google Analytics, which is hands down the best tool for understanding web traffic. And it’s bloody free. You probably knew this already. But, just in case, here’s a great new tutorial. That is all.
It is a pretty basic trick to get an idea of people that are linking to your site. Just google:
link:http://mysite.com
But that is an extremely rudimentary technique for several reasons.
- You will probably get a bunch of *internal* links, which are pretty useless.
- You will not get a sense of the total number of links from each referrer  they are not tallied or ranked.
- You only get referrers for the individual page you type in, not your entire site. Which means that you are getting largely underreported numbers. (even http://www.yoursite.com is different from http://yoursite.com)
You asked, and we listened: We’ve extended our support for querying links to your site to much beyond the link: operator you might have used in the past. Now you can use webmaster tools to view a much larger sample of links to pages on your site that we found on the web. Unlike the link: operator, this data is much more comprehensive and can be classified, filtered, and downloaded. All you need to do is verify site ownership to see this information. Peeyush,
Google Webmaster Central Blog
So yesterday I was super happy to discover via the trusty Google Webmaster Central Blog that there is a new “links view” in the Webmaster Toolkit.
The Webmaster Toolkit is a service from Google that you really should be using. It takes just a few minutes to get started and then you get lots of data, including the new link data. If you haven’t already (and, uh, you run a website), check it out and you will be happy to pick up a bunch of free statistics about your site. Notably, you can also create an XML sitemap (not a graphical HTML sitemap, though!) of your site to make sure google is indexing the whole thing. And you can test your robots.txt file (important for keeping those pictures of the last drunken staff party out of images.google.com).
I did have a couple of problems with the data, though — there still is no way to get a good ranking of your referrers, or a ranking of your most popular pages. Luckily, you can download the entire file and do whatever you want with it. (hooray for openness!)
Since we have a bunch of clients I wanted to send this new data, I took the time to write a simple perl script. And I figured a few other people could use it.
It’s here:
[syntax,unique_addresses.pl.txt,perl]
Instructions for unique_addresses.pl
Prerequisites: Using this script requires that you know how to execute file from the command line (and that you have perl installed). This will only work for Mac/Linux folks (requires perl and the *nix commands for sorting). … If you are a progressive blogger or organization and can’t get this to work, email me your stats and I will process them for you.
- Download your entire external links file from the webmaster toolkit.
- Use Excel or something to pull out that column of external links, and save this as something like “referrers.txt”
- Repeat the above for your “pages” column, but name it something like “pages.txt”
- Download script.
- Make it excutable in the same directory as your “pages.txt” and “referrers.txt” files
- Run “./unique_addresses.pl” and it will prompt you through the rest.
Again, if you are working for a good cause but run into trouble, just email chris at blast dot com or leave a comment.
Just had a really great first experience at Qunu asking obscure questions about our email server. It was an obscure subject, but I needed generalized advice, so I didn’t have a listserv (such as a particular software group) to turn to immediately. I was able to connect to a geek in a few minutes and have, basically, a web-based IM chat. Highly recommended if you need computer-related advice. I think there were probably only a few people online that I would have trusted as experts in this particular field, but hell, that’s pretty great considering it’s alpha. I hope the service grows. God bless the web.
If you are interested in keeping up with the best practices of mime types, content types, character encoding and doctypes ….
A very nice survey of document types from the best developers on the web:
http://www.elementary-group-standards.com/archives/site-standards/why-xhtml.html
Last I checked, only about 2 percent of developers were women.
Just now read this:
The GNOME Foundation received 181 applications for the Google Summer of Code (SoC) program, but not a single application was from a female developer. The lack of women participating in GNOME, and free software in general, has spurred the GNOME foundation to start a summer program to reach out to female developers.
Amazing, considering that GNOME is a core element of open source desktops. (They make, um, the desktop.) And absolutely commendable for the GNOME open source team.
via GNOME needs women
http://www.gnome.org/
Great advice on crafting a home page from A List Apart. In short: build it last, and work first on the details (the smallest, ubiquitous elements of your site). A great homepage with poor search results or product page will only lead to disappointment. So if your site is shallow and ugly on the inside, make sure your homepage is too. Also:
If a first time visitor to your site’s home page does not understand what it is within three seconds, you’ve failed goal number one, so feel free to skip the rest. The only people who will use the site are the people who already know what it does. Or, ya know, masochists.
While I’m in a website-improvement mood, there is also a handy post today from Alt Tags, summarizing the Five Steps to a Better Website in the New Year (via the ever-useful 456 Bera St.). In short:
- Give Your Content Some Attention
- Validate Your Website’s Relevance
- Think About Your Customers
- Review Your Site Navigation
- Identify Accessibility Problems
Wow. Steve at Slayeroffice.com has an amazing color palette generator based on the design technique of Andy Clark.
You enter a hex code value for a color, then another to mix it with, and out comes a beautiful png graphic of the color scheme. Extremely nice work, Steve. This is a great resource for brainstorming color schemes. I’ve used a number of other methods, but this one gets the prize.
< >
Ok, so the color palette generator at wellstyled (shown) is even better.
I still recommend one extension of the techniques: take a scheme you like and use Photoshop to adjust the hue locally, and generate as many versions as you need (perhaps for clients or your boss). Then it’s even easier to get ideas. If your’e a new web designer, that’s a good enough reason on its own to downlo ad a trial of Photoshop, I think.
Finally some useful help from the “celebrity engineer” Matt Cutts, one of the few people in the world that has had intimate relations with the Google Pagerank algorithm. (EDIT: He also happens to use Wordpress, not Blogger. Hmmm.)
This is a description of how to best reference your urls in order to ensure that Google understands them clearly. (the corresponding clarity, is designed — clearly — to increase your rank.)
From the blog of Cutts:
Q: What is a canonical url? Do you have to use such a weird word, anyway?
A: Sorry that it’ a strange word; that’s what we call it around Google. Canonicalization is the process of picking the best url when there are several choices, and it usually refers to home pages. For example, most people would consider these the same urls:
* www.example.com
* www.example.com/
* example.com
* example.com/
* www.example.com/index.html
* example.com/home.asp
Roger Johannsen at 456 Berea St. (web design) says he adds
1. RewriteCond %{HTTP_HOST} ^456bereastreet\.com [NC]
2. RewriteRule ^(.*) http://www.456bereastreet.com/$1 [R=301,L]
to his htaccess file in order to ensure that “www” is added to all requests for a page on his server. Great work. Great post. Thanks, Matt and Roger.
The reason I love web design so much is that anyone can do it. The web is just full of tutorials, examples and geeks on call.
Here’s a massive resource of good links. It’s well organized and through, but it also manages to focus on reputable sources of information. Put this one in your bookmarks if you want to learn about putting your information on the web:
Web Developer’s Handbook: developing web-sites, exploring own imagination | CSS, Color Tools, SEO, Usability etc.
R. Johansson says it best. This is the single most important tool any web developer can have.
Web Developer Extension 1.0
for Firefox, Flock, and Mozilla has been released. There are many new features and bug fixes, so upgrading is highly recommended. The Web Developer Extension is a definite must have for any web professional, so if for some reason you don’t already have it, download it now.
For more info and comments, visit Chris Pederick’s blog post Web Developer 1.0.
Not that I have followed any of this advice yet, but here’s a thoughtful article about preparing websites for an international audience from Molly Holzschlag:
Despite the fact that the Web has been international in scope from its inception, the predominant mass of Web sites are written in English or another left-to-right language. Sites are typically designed visually for Western culture, and rely on an enormous body of practices for usability, information architecture and interaction design that are by and large centric to the Western world.
There are certainly many reasons this is true, but as more and more Web sites realize the benefits of bringing their products and services to diverse, global markets, the more demand there will be on Web designers and developers to understand how to put the World into World Wide Web.
The entire article:
24 ways: Putting the World into “World Wide Web”
Web Designers everywhere are taking a break.
Sometime about 5 years ago people began to realize the frustrating limits of web development because the existing standards were so poorly followed by existing browsers. It was something like what Frost said about “poetry without rhyme is like playing tennis without a net.”
Which is to say, no fun at all. Online communication has progressed steadily since then, and now we have wonderful fruits like “AJAXy goodness” and other Web 2.0 technologies to reap. So take a break from griping about Netscape vs. Internet Explorer.
But Google Maps (etc.) being accomplished, we’re looking for ever greater technologies. The next frontier of web development is the mobile browser — the web in a cell phone.
The concept of the mobile web has been huge this year, and it is now taken as a fact that most internet users in the next 5 years will be getting online for the first time through their cell phones.
And so, with that in mind, here’s a great series of articles from designer Cameron Moll that looks at the background of the mobile web and explores the specifics of developing +designing reliable, readable sites for really, really small screens.
How do we designers and code slingers cope with the current state? What slings and what doesn’? This article attempts to present technical advice on a superficial level.
Mobile Web Design: Tips & Techniques ~ Authentic Boredom
Learning to use CSS can make you insane if you don’t have a good instructor. And who does?
Some of the best advice I’ve ever gotten about web communication relates to debugging your code: you have to learn to problem solve efficiently.
Enter Mezzoblue’s CSS Crib Sheet, may it’s url never expire.
You will no doubt come across many quirky layout issues when building a site with CSS. You’ll end up banging your head against a wall time and again. This is an attempt to make the design process easier, and provide a quick reference to check when you run into trouble.
I also recommend the attendant conversation, which has whole shmear of mostly excellent advice (I don’t recommend removing your DOCTYPE permanently, as one contributor recommends. Everything else is golden advice on this page.)
If you need a free place to host your website, make sure you check out AmbitiousLemon. They look very good at what they do; they at least have a very capable open source software setup on their server, with Ruby On Rails, PHP, Perl, Apache etc. :
We are not a company. Our aim is not profit. We are a handful of computer enthusiasts dedicated to building a free web hosting service where our emphasis is the community we host rather than our own financial gain. You have the talent, the content, and the desire to share it with the world. We are the means to that end.
If you are a nonprofit that needs discounted web design, then visit, nonprofitdesign.org (which I run, in addition to this site.)
Drosphilia researchers have a leg up on web designers.
Well, at least they’ve got a decent explanation of colorblindness. A short paper on colorblind audiences was written a few years ago for researchers presenting their findings on the very latest in the world of flies. The guidelines are easy to understand, and the changes are easy to incorporate.
Here’s a bit:
“There are always colorblind people among the audience and readers. There should be more than TEN colorblinds in a room with 250 people. (50% male and 50% female) There is a good chance that the paper you submit may go to colorblind reviewers. Supposing that your paper will be reviewed by three white males (which is not unlikely considering the current population in science), the probability that at least one of them is colorblind is whopping 22%! … When preparing your presentations (papers, slides, web pages etc.), please take this into account. Here are some comments on how to make figures and presentations colorblind friendly.
I would also recommend a quick look at the Ishihara test for colorblindness for a shot-in-the arm understanding.
And while you’re on a colorblindness kick, you’ll lose blogger points if you don’t read at least Day 12 of the Dive Into Accessibility website, which is the best online introduction to making your website+blog readable by everyone, except illiterates, period.
