Our Swedish friend Roger Johansson asks the question, “Are we designers or developers?“

“On the about page of this site I used to call myself a “developer/designer/occasional writer”. It’s a bit confusing, and I still find it hard to know what to answer when someone asks me what I do for a living. Am I a Web designer? A Web developer? A Web programmer? All of them? Neither? It really is a difficult question to give a simple answer to.” — Roger Johansson

Like Roger, I have struggled with this question. Then about two years ago I decided to just pick an answer and go with it; that way when the hair dresser asks me the question I don’t sit there and go “um…ah…er…developer” and they end up thinking I’m lying and I’m really a spy or something.

So my answer is: I’m a developer!

I decided to steal my answer from the home building industry. Someone who builds homes for a living will often choose to call them self by the generic term developer. They may be an architect or mason or a carpenter, but those are the more specific skills used on the job — they call themselves home developers.

They use architectural skills to ensure that the house is designed well; that it’s structurally sound. Then using masonry and carpentry skills they build the home.

This is the similar to building a website. You design the site using pencil, paper, Photoshop and your learned knowledge of what it takes to make a website “structurally sound” and then you develop the site using HTML, CSS, PHP and all the other tools that go into developing websites.

So in my mind we’re both developers — they develop homes and I develop websites.

What’s your take — designer, developer, programmer or other?

When someone asks what you do for a living, what’s your answer?

“Caching” is a term you’ve probably heard mentioned before in various places (including this site). The idea behind caching is to store a copy of some piece of data so you can re-use it again later without jumping through whatever hoops you had to go through the first time to get it. There are different ways you can cache data (queries, objects, etc) and different medium in which you can store the cache (files, database, memory). Any way you do it, the main goal of caching is to increase the performance of your site or application. In many cases caching is used to lessen the amount of interaction with the database, which increases performance and decreases the load on your server.

I would like to talk about my personal favorite method of caching: memcached. I’ll show you how memcached works, how to install it, and how to use it to help your site/application run faster and scale better. According to the memcached site, “memcached is a high-performance, distributed memory object caching system, generic in nature, but intended for use in speeding up dynamic web applications by alleviating database load.” In plain English, this means memcached is an application that you can use to take advantage of spare free memory on any number of machines to cache pretty much anything you want (with a few exceptions) and retrieve it very quickly. Memcached was originally developed by Danga Interactive to help speed up LiveJournal. Some of memcached’s great features are that in runs on a number of platforms (Linux, BSD, Windows), is VERY fast, and has a number of client APIs already written so you’ll more than likely find libraries for any type of project you’re working on. We’ll focus on the PHP API in this article.

(more…)

This blog is now old enough that I’m starting to get to know a few of you guys and gals that comment with regularity. But, I would still like to know more about you and that’s what this post is for. So let us know more about you.

Answer these questions:
- Name: Mark Angeletti
- Your website URL: Search-This
- Profession: Software Developer
- Favorite movie: It’s a Wonderful Life
- Blog you most frequent (besides your own): Chris Garrett on New Media
- How you discovered Search-This: built it
- Your main interest as far as web stuff goes: marketing and blogging
- What do you do for fun: hiking and soccer

Let us know - this is going down in your permanent record

According to a study done by Port80.com in August 2006 they found that “Microsoft IIS serves 54.9% of Fortune 1000 web sites.” I’ll be honest, I would have lost money on that; my money would have been on Apache.

Does this surprise anyone else?

I decided to do some research of my own using Firefox and the Web Developer extension to view each website’s Response Headers to see what web server they’re using. Here’s what I found:

(more…)

Larry Wall (of Perl fame) once wrote in the “Camel Book” that the three virtues of a great programmer are laziness, impatience, and hubris. Out of these three, laziness is my favorite. Wall defines this as “The quality that makes you go to great effort to reduce overall energy expenditure. It makes you write labor-saving programs that other people will find useful, and document what you wrote so you don’t have to answer so many questions about it. Hence, the first great virtue of a programmer.”

He goes on to talk about coding and documenting in such a way so as to not create more work for yourself down the road, but he never addresses how to make the initial effort easier. I want to give a few pointers as to how you might get off on a good start.

(more…)

Search-This is taking a three day weekend and will return with a new post tomorrow. But we are not leaving you empty handed; we would never do that. In fact, we are sending you on a FREE trip to watch the brilliant marketing video by venture capitalist guru, Guy Kawasaki! That’s right, you have won an all expense paid trip to “The Art of Innovation” by Guy Kawasaki! All you have to do is click the link below and sit back and enjoy… See ya tomorrow…

[ The Art of Innovation by Guy Kawasaki ]

You’ve just posted a killer blog entry and submitted the link to digg. You get a hundred or so diggs in the first hour, and the next thing you know, you’re on the front page. A couple hundred diggs later, you get one of the various dreaded messages that your site is either dead or dying (”Server cannot be reached”, “Service Temporarily Unavailable”, or the unthinkable “Account Suspended!”).

“How could I have prevented this?”, you ask yourself.

There have been many articles on this topic offering various suggestions such as toying with the webserver and database settings, using a form of query/content caching, and ensuring you use good hosting. All are good suggestions, but what if you’re using a blogging service or shared hosting? The following list contains some very simple ways to help alleviate some of the issues caused by the digg effect.

1. Monitor the number of diggs: It’s not as if you wouldn’t do this anyway, but keeping an eye on the number of diggs and if/when you get front paged helps you get a jump on the traffic spike.
2. Talk to your hosting provider: Giving your hosting company a heads-up on what’s going on can save them some headaches (especially if you’re on shared hosting) and possibly save you some $$ on your hosting bill.
3. Turn off comments, widgets, etc: Most diggers don’t comment on dugg pages anyway, so one less trip to the database can make a big difference. Have a rating widget you can disable? Do it. Try to keep the number of queries to the database to a minimum.
4. Don’t use images or other media: Content is king, right? Unless you’re specifically posting an image or some other media, don’t include additional images or media. Each one is another request that the server has to handle and another chunk out of your bandwidth cap.
5. Post a static copy: Some blogging tools will create a static copy of your post. A static page uses much less server resources to serve than a dynamic one. If you don’t have that option, create a static copy and redirect to it. If things are still slow, post a “print friendly” text only version that removes all the excess chrome from your site.
6. Redirect to a copy on a caching service There are a couple of caching services that are great for situations like this: DuggMirror and CoralCache. They’ll cache a copy of your page and have the infrastructure to handle very high loads. It’s a good idea to follow their instructions and populate a cached copy as soon as you submit to digg. With the more popular stories, diggers will refer to the cached copy when the dugg page gets slow, but often the cached copy is too late and grabs a copy of one of the dreaded “dead site” messages. Better yet, why not create a cached version using CoralCache and submit the link to the cached version to digg.

I can’t guarantee that doing all these things will keep your site from faltering to the almighty digg, but they’ll certainly help keep it alive as long as possible. Happy digging!