Geek Daily

As someone who has been on both sides of the hosting fence there are few times that I would recommend a client trying to run and manage their own server. Generally, it sounds like a good idea, especially when you look at the cost of managed hosting. It is important to remember that although it may appear cheap to host your own server, using Linux and other open source technologies, the costs can be deceptive and not always be directly tied to money. Most often if careful and honest assessment is done the managed services turn out to be the cheaper option in the end. What am I talking about? Lets see.

Let me clarify that when I talk about running your own server I am not referring to some guy running a Linux web server on an old PC in his basement. I will be comparing both options for the same level and quality of service.

Up front costs

Let’s compare the up front costs for managed hosting and running your own server.

A typical dedicated server will probably start around $175 per month and gives you a modest server with lots of bandwidth and unless you are running heavily used sites or applications then it will most likely be more than enough. So at $175 per month that will cost you $2100 for the year. That may sound like a lot but really it is not because you get a fully functionally server out of the box with operating system and software per installed based on the package you chose. You also get power redundancy because your server is part of a data center. Also the hosting company still owns the hardware and is responsible for replacement if any hardware fails.

If you were to host your own server and you had the same $2100 budget for the first year. Well it would be impossible to build your server, install power redundancy (modest UPS at a minimum), buy the operating system (if you wanted Windows), and buy any backup and protection software. Also on top of that you are going to need a static IP address (you get that as part of the managed services) which can easily run you $100 per month from your ISP which alone eats up over half your budget.

Server administration

Another important thing to consider is server administration. Who is going to run and maintain your server? Who is going to troubleshoot your server when it goes down at 2 in the morning and you start getting panicked calls from your clients.

Most hosting companies will also administer your server for you as part of your managed hosting package, well, for a bit more money of course. This means that if something goes wrong you just call up technical support and they take care of it. This also means they are on the hook for the protection of your data and making sure the backup routine is in place and functioning.

Let’s consider that compared to you having to maintain your own server. If you are a person that is knowledgeable about computers than chances are you could manage to run your server fairly smoothly. On the other hand consider that if you are busy keeping the server running optimally then who is running your business and generating revenue? You can’t do everything and out sourcing your server administration is one of those things you should let go.

Now even if you paid your hosting company double to include server administration into your package ($350 per month or $4200 per year) this is considerably less then a salary for a fulltime IT person which will run you a minimum of $40,000 per year for someone decent and if you decided to use Linux to save money on your OS costs that salary just took a big jump.

Conclusion

The long and short of this post is to say if you need dedicated hosting then go with a professional company because when you stop to consider all the costs involved whether it be money or just peace of mind running your own server will cost you way more.

Popularity: 27% [?]

Here is what I found interesting this week.

Unit tests are for functionality, not code!
The prevailing philosophy in regards to unit testing is writing your tests before your code. In practice, this happens a lot less than it should. Why should we write our unit tests first?

Turn Google App Engine into your own Personal Content Delivery Network (CDN)
As anybody who has run a growing website or blog knows, response time is going to get worse with the more users you have visiting your site. The users come from all angles, RSS feeds, homepage visits, search engine visits, people sealing your static files that you host, and pretty much anything else that can be served over HTTP. The solution to this problem is to off load your static content on to a Content Delivery Network or CDN. CDN providers cost a lot of money though, so it is nothing for us mere mortals with one server can afford.

But thanks to Google anyone can now run their own CDN for free on Googles servers. Lucky for you and me Google has made the process really painless and you can even have the CDN under you own domain name. In my case static.coderjournal.com.

10 Universal Truths of SEO
Google is great. I use its services on a daily basis and love the traffic it sends to my websites. As smart SEO professionals point out, however, Google isn’t the only search engine around, and may not be the biggest, baddest search engine on the block forever.

Popularity: 12% [?]

This was guest posted by Jason O’Connor, president of Oak Web Works, LLC www.oakwebworks.com where you can get a free webmaster newsletter and read many other original Web design and marketing articles.

I believe some people create and publish websites for the sole purpose of tormenting their visitors. Browsing various websites and navigating the Web can often be like trying to read on an airplane while a kid kicks the back of your seat and the baby next to you alternates between screaming, crying and drooling on you. There are some excellent websites out there to be sure, but there are also a lot of dreadful ones too. The latter are the bane of so many people’s existence, especially those who use the Web regularly.

The Net continues to grow in popularity and importance for consumers and businesses alike. Therefore, the quality of sites needs to keep pace. Creating and maintaining high-quality websites is more important now than ever. Higher quality equals more revenue.

The following lists the top ten ways that a website misses the boat and contributes to hair loss and nervous breakdowns. Notice the common thread that runs throughout each of these. Namely, a bad website neglects to consider the site visitor’s experience in some fundamental ways.

1. Animation
Seven year-olds like watching animated cartoons on Saturday morning, business people, professionals and most other adults don’t. Sites that include showy Flash animations as an ‘Intro’, animated gifs on every page, or flying words are really annoying. They take away from the content and distract the visitor from achieving their goals. Unless your site is an entertainment site, try to avoid maddening motion. However, if your product or service can be better demonstrated using Flash, Quick Time, or other multimedia, which is common, offer your visitors the chance to click a link to view it. But don’t force them.

2. Too much scrolling
Once I scroll down a full screen’s worth, my eyes start to blur, I feel slightly lost, my head spins and my interest wanes. Computer monitors really aren’t the best medium for reading. The Net and many sites are so big that it’s important to always provide a clear frame of reference for your visitors at all times while they’re on your site. If a page requires two full screens of scrolling or more, simply split it up into multiple pages.

3. Long, text-heavy and blocky paragraphs of unbroken text
I really have to be into a topic or desperately need to glean the information to trudge through big chunks of unbroken text online. If I’m just shopping around for a product or service, you’ve lost me if I have to endure this kind of torture. Again, it is harder to read text on the Web than in other mediums such as books. Additionally, Web users are notoriously impatient, so make your content easy to read and non-intimidating. Use titles, sub-titles, small paragraphs, bullets and numbering.

4. No obvious ways to contact the company
If all you supply is an email on your website, your legitimacy may be questioned. Why can’t you answer the phone? Why hide behind an anonymous and cold email address? Make it easy for your existing and potential customers to talk with you.

5. Unchanging or out-dated content
If I start reading content on a site and soon discover that the content was written three years ago, I split. Since there’s so much information out there, my reasoning is there’s got to be comparable information online that’s more current. If you keep your content fresh your site will attract repeat visitors. And repeat visitors are more likely to turn into customers.

6. Long page downloads
It’s amazing that this is still a problem. When I click on to a site and have to sit there waiting for it to appear in my browser, I start sweating, picking my teeth, tapping my toes, rolling my eyes and soon want to throw my computer through my office window. I’m obviously a little impatient, but again, I know there are other sites out there with the same information that will download more quickly, so why wait? I’m gone.

7. “Me, me, me!” instead of “You, you, you”
Generally speaking, no one cares about you, your company or your thoughts. What they do care about is what you can do for them. So sites that show pictures of the company building or tout their deep philosophy on the way business should be conducted really don’t bode well for keeping the interest of site visitors. On the other hand, sites that speak directly to potential customers about how they can solve their problems, make their lives easier, safer, richer or more comfortable have a much better chance of keeping the eyeballs glued.

8. Non-explanatory buttons or links
Here are some examples of buttons that leave me dazed and confused: A wedding site with a button called ‘Blanks’, a boating site with a button named ‘The Lighthouse’, a book site with a button called ‘The Inside Story’, or a Web design site with a button called ‘Tea Time’. They sound like Jeopardy categories. Imagine trying to find your way on a highway where its various signs read ‘Over Here’, ‘Moon Beams’, and ‘Lollypops’. Good luck navigating your way through. It’s the same with navigating websites. Button and link names need to tell the visitor where the link leads to. Make it as easy as possible for a visitor to know where they’re going before they click. However, there are times when naming a link an ambiguous name may pique the curiosity of a user and get them to click on it. But as a general rule, keep your links and buttons as descriptive as possible.

9. Inconsistent navigation
Imagine sitting down at a restaurant and the waiter comes over to you and hands you five different menus, one for the appetizers, one for the soups and salads, one for the entrees, one for the desserts, and one for the drinks. Annoying. Now imagine if each menu had a different format, layout and method for listing the items. Brutal. I really don’t want to work that hard at picking out my dinner, I’m hungry and I just want a meal. Don’t make your visitors work hard either by expecting them to re-learn your navigation system each time they enter another section of your site. They too are hungry; for useful information and they’re even more impatient.

10. Inconsistent look & feel
When the look & feel completely changes from one page to another in a website, I think I am visiting another site, another company, a partner or subsidiary. I get very confused. This screams poor planning and often results from tacking on new sections later after the original site was built. This can lead to design-drift. It may be tempting to stray from the original design; you may have a better design now. But wait till you do a complete next-generation re-design of the entire site before introducing a new look & feel. If not, lots of visitors will be scratching their heads with one hand and possibly clicking away with the other.

Finally, any site that employs a number of these notorious features is particularly painful to experience. When I click to a website that has five different fonts and colors, scrolls down to the core of the Earth, incorporates zinging words and big fat blocks of text, lists no phone number and has content written and dated in 1996, I scream and know deep down inside that pulling my fingernails out wouldn’t be as torturous as having to remain there a minute longer.

Popularity: 11% [?]

I was thinking about some of my skills sets today and this lead me to a realization.

I consider myself to be good with relational databases. I may not be an expert guru, but I have designed and implemented some pretty complex systems, very well IMO.

The realization was that I rely to much on GUI interfaces. Yes, they are great and help get things done faster but in the instant the GUI was not available would I be able to function? True, I could always jump onto Google but my productivity would be greatly reduced because I would have to look up a lot of things.

I also realized that I tended to be more disciplined when a GUI was available. For example, when working with MSSQL I used plenty of Sotred Procedures and was extremely careful to make sure all contraints and relationships were in place. However, when using MySQL, usually phpMyAdmin, I rarely used an SP or setup relationships.

So why is that? Because for MSSQL there are nice GUI interfaces to let me quickly and easily add all those good things but in phpMyAdmin there is noway to add them except through queries.

Conclusion, I am lazy. I am working on this but it is true. This is by no means a good excuse to ignore good practices.

So here’s to using a little less GUI and brushing up on some advanced SQL techniques in the near future.

Popularity: 10% [?]

Jeremy Miller has been writing a wonderful series on building your CAB/exploring design patterns. I highly recommend you read the series.

Click here for the first article in the series.

Click here for a list of articles in the series.

When last we left our hero, D’Artagnan was chasing the evil Lady de Winter across the breadth of France trying to intercept her on her dastardly mission when he found himself beset by disparate responsibilities within the tight confines of a single autonomous view with no room for sword play. D’Artagnan, being a perspicacious young man, quickly sees a way to separate the numerous concerns he’s facing by opening his attack with…

Popularity: 9% [?]

Eric Woods has put together a great article (part 1 of a series) on some of the most common design mistakes developers make. Hopefully this will help you avoid making some of these mistakes.

(1) Scoping Woes
Many projects end up being doomed to failure before they’ve really started, simply because their scope was wrong. The most common problem is the infamous “scope creep” where the scope of the system steadily increases as more and more people get their say. This is the sort of situation where a simple travel booking system ends up with full expense claim management facilities being built into it, with inevitable repercussions for project costs, timescales and quality. The converse problem is where scope is artificially limited (perhaps to meet timescales) and so the effectiveness of the system is compromised. Architects need to maintain a particular focus on scope problems that relate to system qualities. Does the system really need to be available 24×7x365? Or would working hours plus Saturday mornings be sufficient? It is really true that no security is needed beyond simple login? Once logged into the system can users really perform any system operation? Catching these mistakes early in the project will help to greatly increase the probability of success.

(2) Not Casting Your Net Widely
A related mistake that many of us have made is to focus on just a couple of our system stakeholders – classically the acquirer (who is paying for the system) and the end users get all of the attention. However there are often quite a few other interested parties who need to be involved. Consider people like auditors, systems administrators and DBAs, testers, helpdesk staff, the development team and so on. You’ll probably need the cooperation of a fair number of these people in order to successfully deploy your system and number of them may not share your enthusiasm for it! Think about searching for stakeholders in groups like acquirers, assessors, communicators (like writers and trainers), developers, maintainers, suppliers, support staff, system administrators, testers and end users. The sooner you can make contact with these groups and understand their interests and concerns, the better.

(3) Just Focusing on Functions
It goes without saying that a key quality of a system is what it does. People buy or build systems in order to perform useful work and so it’s crucial that the system does what people need it to do. However, a trap that many new software architects fall into is focusing entirely on a system’s functions without considering any of its other properties.

Unfortunately, while we do need to get the system’s functional processing right, this is rarely enough; unless the system exhibits a whole range of qualities (such as performance, security, maintainability and so on) it is unlikely to be successful.

In my experience, an architect needs to focus on the type of functions that a system has to provide and must design a suitable framework that each of the individual features of the system can be slotted into during detailed design. The design of the overall framework has to take into account the kind of functions it will host (be they computationally intensive, data oriented, batch operations, interactive operations and so on) but crucially, it must also be capable of providing the right level of performance, allow the application to be secured, allow for high availability and disaster recovery, support operation and administration and so on.

In reality, if the system isn’t fast enough or is insecure, if it can’t be supported or changed to allow for new requirements, it probably won’t be used and may not even make it into production in the first place. Identifying and delivering on these non-functional requirements is a crucial part of the architect’s role.

(4) Box and Line Descriptions
At some point in the development of the system you will need to write something down to explain your ideas for the architecture of the system – in other words, you’ll need an architectural description.

The question is, how do you go about describing something as complex as a modern software intensive system? The approach that we’ve all tried at some point is the single, all inclusive, “boxes and lines” Visio diagram that tries to show everything. The diagram probably includes software modules and some interconnections, machines, network links, databases and data flow, some user interaction, perhaps some system monitoring and so on. If you’ve tried this yourself then you already know that it’s not a terribly effective approach.

There are two reasons why the huge Visio picture doesn’t work well as an architectural description: firstly, it’s trying to show too much information in a single representation, and secondly, no one is really sure quite what each of the different types of symbol that you’ve drawn mean.

The first problem means that the diagram doesn’t work well for anyone, as everyone has to hunt through it for the information they are interested in. Infra-structure experts have to discern the machines, network links and infra-structure software from the whole, software developers have to try to work out what the software layering is, testers need to try to untangle dependencies from data flows. Each person is mentally creating their own subset of the diagram in order to understand it. The solution to this problem is to decompose your large diagram into a number of well-defined, non-overlapping views of the system such that each view addresses one aspect of the system structure (such as runtime functional structure, software module structure, data structures or deployment environment). This is a well proven technique and there are a number of standard approaches you can use to guide you in achieving this (see the Further Reading section).

The solution to the problem of ambiguity is to make sure that you use a well defined notation for your diagrams and to provide enough supporting text somewhere to make your intentions clear. UML is an obvious starting point, given its tool support and wide use, although quite honestly it’s not a very good architectural notation (although again see the Further Reading section for some guidance on how to use it effectively). For those situations where UML isn’t effective, you will probably design your own notation to represent your ideas. However, remember to clearly define what your notation means so that people aren’t guessing – different people rarely guess the same way!

(5) Forgetting That It Needs to be Built
It’s always very satisfying to create and prototype an elegant, sophisticated design for a new system and it’s always more interesting if we manage to use some novel new technologies and techniques along the way. However, when we do this, it’s often worth asking ourselves which stakeholders our new design is really serving – the answer may well be ourselves, first and foremost (and possibly the development team).

I’m not suggesting that we shouldn’t innovate or that all systems should use COBOL and VSAM but always bear in mind that your design needs to be built, tested and deployed in order for it to be successful. If the design or the technologies you use are too sophisticated or immature, then you may be jeopardising this.

Common things to watch out for related to building the system include designs that the developers or testers don’t really understand, technologies that they aren’t enthusiastic about or don’t have the time to learn, and new technologies that don’t yet have good tool support or perhaps impose a new and unfamiliar way of working. The presence of any of these factors suggests that you need to tread carefully and make sure that you work with the development and test teams to minimise the risks.

Also bear in mind that your system needs to be installed, monitored and controlled in production. Sophisticated architectures can make all of this significantly harder and immature technologies often have weak monitoring and management facilities, even after their development support has been improved. Again, it’s a case of working with the relevant parties (such as system administrators and perhaps the vendors) to make sure that no one has any nasty surprises late in the day.

Popularity: 7% [?]

I read the first part of a great article on why inheritance is not the best way to implement things. I like the Jedi references in the explaination. Everyone needs a DarkHippo!

The difference between is-a and has-a relationships is well known and a fundamental part of OOAD, but what is less well known is that almost every is-a relationship would be better off re-articulated as a has-a relationship.

Bad

// bad
class Jedi {
    function drawSabre():Sabre { … }
}
class DarkJedi extends Jedi {

    function crushTownspeople():void { … }
}
dj:DarkJedi = new DarkJedi();
dj.crushTownspeople();

Good

// good
class Jedi {
    function drawSabre():Sabre { ... }
}
class DarkPowers {
    function crushTownspeople():void { ... }
}
class DarkJedi extends Jedi {
    // DarkJedi has-a DarkPowers
    public var darkPowers:DarkPowers = new DarkPowers();
}
dj:DarkJedi = new DarkJedi();
dj.darkPowers.crushTownspeople();

Popularity: 7% [?]

Haacked.com has posted another great article. The basic jist is don’t force your users to input the data as you want but manipulate the data to the way you want it giving your users a much nicer experience. It also has a nice Seinfeld Soup Nazi reference.

Be reasonable; are we so afraid of regular expressions that we can’t strip extraneous characters from a single input field? Let the users type their telephone numbers in whatever they please. We can use a little quick programming to filter out what we don’t need.

User: (filling out form) user+nospam@example.com

Validation Nazi: Entering a plus sign is $2.00 extra.

User: But the RFC allows for a plus sign.

Soup Nazi: You want plus sign?

User: Yes please.

Validation Nazi: $3.00!

User: What?

Validation Nazi: No form submission for you!

Popularity: 7% [?]

The Internet has matured alot since it’s inception. It has under gone many changes and today we are seeing some amzing things done with various Internet technologies. One of the key factor in this vast amount of rich and interactive data is Web Standards.

Web standards have allowed us to transmit and share data in reliable and predictable ways. Semantics is a component of Standards, although not as important as a defined structure for the data, that describes the data it contains. Semantics, in many ways, is about common sense. It makes sense to expect a paragraph tag (<p>) to contain a paragraphic of text. It would also make sense to expect a table to contain a grid or table of data. So why are tables used for layouts?

That in and of it’s self is a very interesting question. While the we have made great advances there are still some areas that are a little slow in catching on, for whatever reason. One area is XHTML. While the XHTML specifiaction has been out for years there are still many developers using HTML 4. I was even talking to a fellow developer the other day and a company he is working with still has the bulk of their web work in HTML 3.2, the horror!

Perhaps it is the fact that Internet Explorer still doesn’t correctly support the XHTML mime type (XML application) that developers have asked, “Why bother?” Or perhaps some just don’t see the benefit in making the switch. Now to be clear I am not saying we have to go back and convert evry website or application we have ever written but at least any new development should be in XHTML.

Why bother? Well, for me anyways, one big reason is Google. The search engine giant is favoring semantic and clean markup in it’s page indexing. So a little extra effort when writing your markup can have big payoffs down the road.

So back to the question of why tables for layouts. Well there are many arguments like tabled layouts take longer to load and are less favorable to search engines, which are probably true. Ultimately every developer must choose for themselves. Believe me if I could cram tableless layouts and semantics down everyones throats I would. I am tired of working on projects that someother person has banaided together with horrible markup and then trying to repair the damage (or at least just figure out what is going on). Whether it is that you’re comfotatble with tables or you think that it is easier just bite the bullet, switch to semantic markup and use tables for what they were made for, tabular data. You’ll be glad you did, maybe not today, maybe not tomorrow, maybe not while your cursing my very existence as you piece together your first layout then look at it in IE6, but someday you will thank me!

Cheers.

Popularity: 11% [?]