Ethan Codes

I want to say a little something about hardcoding values. Don’t.

Here is my example. You have an online application. It has 13 pages. You have a pointed that says what page the user is on. When that pointer gets to 14 it means the user is done and they get a summary page. That’s okay. But then you put something like this throughout the code

if ($ap['pointer'] == 14) { ... }

That may make sense to you in the short run, but eventually it’s going to bite you (or more likely, whatever poor sucker inherits your code) in the ass. What happens when we add/remove a page? I have to go change all of those 14s to something else. Where are all the 14s? How long is it going to take to fix all the values you’ve hardcoded?

I seem to train a lot of our clients in Wordpress, so I thought I’d write something up. Copy/Pasted here, for your entertainment.

In my experience, most people think Wordpress training is going to be terribly complicated. Usually, they don’t “get” computers and don’t expect to understand a content management system, either. Once they see how simple Wordpress is, they can usually take care of their content on their own.

I usually start by explaining that they don’t need to worry about copying down any URLs, usernames, or passwords because I’ll send those by email. This is one of those things that stress people out, so already they don’t have to worry about something.

I explain a little bit about the Dashboard. Usually by this time I have cut out most of what shows up on the Dashboard in order to make their lives easier. Nobody cares about the Wordpress Development Blog, so turn that off before-hand. The Dashboard is nice because there’s multiple ways to get at what you’re trying to get at.

Then I explain that there are two kinds of content: Posts and Pages. I explain what they are. The concepts are pretty simple.

Then I show them Posts. Once they see that it’s just a Title, Body, and a Category, you can watch them relax. This isn’t so hard. The editor is friendly and easy to use. Inserting an image is easy. Uploading a PDF is easy. Links? No sweat. They can do this. I usually ignore everything else on the Post form page because it doesn’t matter to them.

I usually go through the process of editing existing Posts, and then creating new Posts. I show off how creating a Post in the News category automatically shows up on the News page, and the Home page. That sort of thing. People are relieved by automation.

When people see that a Career Opportunity is just a Post in a different category, they see how simple it is.

Ask if there are any questions or if anyone would like to see something again. Take a drink of water.

Then I go through Pages. They like that pages are organized hierarchically. And Pages have fewer fields than Posts, so they can handle this, too.

People are often very concerned about screwing something up. I mention the Preview button. I tell them they can check the front end after they’ve made changes, and if anything is wrong, go back and edit it. And I mention the revisions. Nobody has ever needed the revisions.

Any questions?

That’s usually it. The thing I hear almost everyone say is “that’s really simple” and “I’ll have to get in there and play around.” Even after seeing how easy it is, people think it’s voodoo. But nobody really has any trouble with it once they’ve tried it themselves.

One of the cool new things about wp2.9 is support for post thumbnails. What this means is that you can associate an image with a post, as a thumbnail for that post.

Previously I have had to write all kinds of code to pull the first image embedded in the body of the post, resize it, and throw that into the template. For example, a “Current Projects” page. Each project on this page is a Post in the “Current Project” category. You can embed/upload an image into the body. My template then extracts the image from the body, resizes it, makes a link out of it, and displays it on the page that lists all of the Current Project Posts. I’ve done this so many times I copy/paste the code from one project to another.

WP2.9 has this post thumbnail business. Which is brilliant. You enable support for post thumbnails in your theme. Then there’s a new block on the Post edit screen where you pick an image to use as a thumbnail. You don’t upload it to the body, it’s separate and clear. Then I use two functions in my template code to check whether or not there’s a thumbnail for this post, and if so, output it.

Dirt simple. I love it. I played around with this a bit so I know how it works. I can’t wait to put it into practice.

Nobody likes to do browser testing. Nobody wants to do it. It’s like cleaning your room. You keep hoping that if you put it off long enough it will go away. So the first thing to understand is that browser testing MUST be done. Suck it up.

That said, there are things you can do to minimize the amount of browser testing you have to do. If you understand the kinds of things different browsers tend to do differently, you can build your HTML and CSS accordingly. For example, if you float something to the right but do not give it a width, IE6 will probably mess it up. If you know that ahead of time, you can put widths in your floated containers when you build it and save yourself some headaches later on.

Of course, eventually you’re going to have to just do it. When you get there, I think it’s best to take a “shortest route possible” attitude. Do the simplest thing possible to make it work. Don’t rethink your whole HTML structure unless you absolutely have to. This means you may do some things that are less than perfect, but when it comes to browser testing all that really matters is that it looks good on the front end. Whatever the quickest way is, just do that.

If you were the kind of kid who didn’t need to be told to clean up your room, maybe you’re the kind of developer who browser tests as soon as possible, and repeatedly. The sooner your get the browser testing over with, the better. But also, you will probably keep tweaking the design until the site goes live. It’s not a bad idea to do multiple waves of browser testing.

Stylesheets. This isn’t Highlander, there can be more than one. Include your “core” stylesheet first. This is where the majority of your CSS goes. The website should pass browser testing almost entirely with just this “core” stylesheet. Only create other stylesheets to fix small things, and include them after your “core” stylesheet. Name them something clear, like styleIE7.css. It’s up to you how you include them. I am fond of using a PHP function to determine browser info, and then spitting out an HTML link tag for the appropriate stylesheet. Like I said, try to fix as much as you can in the “core” stylesheet and keep your browser specific stylesheets to a minimum. I have stylesheets for IE7 that have only two definitions. Clean and simple.

I want to take this opportunity to ask you to comment /* the crap out of */ your stylesheets. Organize them, so that all of the #header stuff is together with a comment explaining that this is header stuff; all of the #nav stuff is together with a comment denoting the start of navigation stuff; all of the #footer stuff is together; and so on. Keep it neat and tidy. Ship shape. This makes it easy for you (and your team mates) to find things. It’s less confusing when trying to debug an issue. The only thing worse than browser testing is browser testing someone else’s design, so when you’re building your stylesheets remember that someone ELSE may have to browser test it.

Lastly, decide, with your team, what browsers you are going to support. This should be agreed upon and known. Consult some browser usage statistics when making this decision.

At work I started and maintain a repository for code snippets and how tos. Things we can re-use on other projects. A lot of is is stuff you can just copy/paste into another project and it works, which is really cool and saves us from having to re-invent the wheel for every project. Today I tried to use something I posted a few months ago. It’s super convenient. I don’t have to worry about “how” it works- I know it just works. And it would have just worked if I hadn’t left out a function. So, yeah, re-using your own code helps you make sure it still works.

I just had a neat idea. Everybody should be storing their resumes in XML. There should be a “standardized” XML resume format, like there is for xHTML and CSS. XML is meant to be sent around, and you want your resume to do that. Then each company can have their own XSL, so that every resume they look at is formatted the way they want it. If Company A only wants to look at the last position this person had, they can write an XSL for that. If Company B likes everything to be in bulletted lists, they can do that. It’s all the same data, all the same resume, but people would be able to choose how they see it. XML is easier to search than a Word document. XML files are smaller than Word documents. XML is more platform independent than Word documents. Conceptually, a person could write up one resume and then write multiple XSLs to display the resume for different skills/positions/etc. I wonder if this already exists…

I passed my third certification exam this morning. This means I’m now an IBM Certified Application Developer- Lotus Notes and Domino 6/6.5. I’m proud that I’ve finally gotten some certification. It’s a really major step, professionally.

I passed my first certification exam this morning. The home team was pleased. Two more tests and I get the next level of certification.

I took some practice tests for Lotus Notes R6 Certification. I got 87% on Notes Domino 6 Application Development Foundation Skills and 71% on Notes Domino 6 Application Development Intermediate Skills. Clearly, there are areas I need to work on. Encryption, workflow, security and apparently application architecture.