Programming Tips

Originally written by Jules Robinson. Reproduced with permission.

Uptime - for some people it’s the most important factor to consider when choosing hosting, but how much faith can you really put into these guarantees? What does uptime actually mean? Is it really worth paying attention to the figures that hosting companies give you?

Failure *is* An Option
“100% uptime” does not exist. I’ll say it again, “100% uptime” does not exist. Offering “100% uptime” is like offering a “100% life” guarantee - it doesn’t make sense.

Nothing lasts forever, and in the world of technology, we as consumers are probably doubly more aware of that fact. Things can and will just stop working for no reason at all, and web hosting is no exception. Every web host on the planet will, at at least one point in their lifespan, experience some form of downtime. When you’re dealing with hardware it’s an inevitability. Hardware aside, there are numerous factors (some even beyond the hosts control) that can occur, making websites unavailable.

To promote and offer the concept of “100% uptime” is very misleading and essentially false advertising. What we need to look at here is basically the small print.

How do they offer or guarantee 100% uptime then? What is it?
“100% uptime” is a concept developed by try and indicate to the user that “your site will never go down” if you use their service. The problem here is that your definition of “down” and the hosts definition of “down” are usually two very, very different things.

Offering “100% uptime” is theoretically possible, if nothing does go down, but this can only last for so long. There are multiple points of failure for any web hosting company, and it’s only a matter of time before one of these points makes itself known.

The real issue with the “100% uptime” claim is that as a user, you will rarely know what it’s actually covering.

Server or Network Uptime?
Here’s something that most customers won’t know or realise…The “uptime guarantee” that the majority of web hosts refer to is actually based upon the network uptime and not the server uptime. You won’t find this in any small print within the terms and conditions, because it’s left deliberately vague.

What’s the difference between network and server uptime? Providing the network that the server is connected to remains fully functional and accessible, anything can happen to the individual server and not be covered by this guarantee. That’s right, if (for example) the disks in the server die and it takes 24 hours to replace and restore your website, this may not be covered by the guarantee.

Because it is notoriously difficult to ensure or guarantee the uptime on a shared server, particularly when hundreds of users may be sharing it, it is therefore easier (and more logical from a marketing point of view) to stamp the uptime guarantee on the network itself. Unfortunately, in the real world, it’s a pretty much useless guarantee if the server is dead.

How do you actually define uptime?
When monitoring a server, there are various things you can monitor:

Ping - Is the servers network active and online (generally used to determine if the server is powered on and receiving network requests)?

Web - Is the web service open and accepting connections?

Web Page Display - Is the server actually accepting connections and displaying static (HTML) pages?

Web Page Dynamic Display - Is the server actually accepting connections, and displaying dynamic (PHP/MySQL) pages without errors?

As you can see, “uptime” is a very sketchy definition. Whilst the server may respond to pings, be online, and serving up webpages… if MySQL is down and your site is spewing out database connection errors, you and I would both consider this downtime. Your host, however, probably wouldn’t.

The definition of uptime is ultimately down to your host, and not you. Hosts offering “100% uptime” are generally referring to the network and not the server or services on that server. If in doubt, contact them and get it in writing. It’s important to establish just what uptime is to see if the guarantee actually means anything.

Uptime Monitoring - The Facts Don’t Match
The problem with providing the guarantee on network and not server uptime is that it’s relatively impossible from a client perspective to distinguish between the two. Even when the network is legitimately down from your end, your web host could claim that it isn’t, and it’s the server that is down. You have no real way of verifying or proving this to them.

Occasionally, web hosts will have their own uptime statistics or service monitoring utilities on their website. These are, for all purposes, completely biased and should be totally ignored unless they come from a trustworthy third party source. Most of these tools will be reporting incorrect statistics either because they’ve been hard-coded to lie and say services are up when they’re not (who really wants to tell the world they’re experiencing downtime?), or their tools are run locally and don’t identify network issues.

Because everything on the Internet travels across different networks, maintained by different people and stored at various different places on the planet, these links can sometimes go down and cause problems for specific groups of people. For example, your web hosts network may use a particular link that goes down, causing your site to be inaccessible to all US AOL customers. If your host is monitoring network uptime on a server that is also on the same network as your existing server, this problem will not be detected, and everything will appear to be fine. Whilst network uptime is in most cases not your hosts fault, and is the fault of their bandwidth provider, their statistics will prove inaccurate and will conflict with your own.

To gain a true representation of network uptime, you need to monitor servers from several remote sources. This will identify any potential network issues from both ends, and you can get a much clearer picture of what’s really going on. There are a few services out there on the Internet that provide this, so I suggest if you’re interested, you Google around for some research. I don’t really want to recommend any individual services here because I believe in others making their own minds up based on the information they find.

Unfortunately, the majority of hosts will only rely upon their statistics when dealing with any type of guarantee. This is quite logical in case the monitoring site or source is experiencing issues and is misreporting downtime, but it can make it very difficult as a client to receive your guaranteed refund or account credit.

Another thing to consider is, how often is uptime actually monitored? Every 1 minute? 5 minutes? 15 minutes? Most hosts that I’ve encountered will perform monitoring every 5 minutes at least. 5 minutes can be a heck of a long time if your extremely popular website is down. What if you experience an issue within that 5 minute timeframe, and the server automatically restarts the failed service before the next monitor? This would essentially mean the server or site was never down. Not according to your host anyway.

What about the 99.9% guarantees?
This, again, is tough to comment on. What exactly does the uptime cover - server or network? Does it cover services? How is it monitored exactly?

0.1% downtime equates to roughly 43 minutes of downtime in any calendar month. 43 minutes is more than enough time to restart services and fix/solve basic issues, but anything more severe may require hours to resolve. If, for example, any significant hardware fails - then 43 minutes is not going to be long enough to replace them, test them, and get everything back online. If anything significant occurs, will they honour their guarantee and admit the downtime? Will they refund or credit you? Try to find out from existing or previous customers if they do.

Who cares, as long as they fix any problems?
As with the overselling, it can be a question of ethics. Do you want to host with someone who promises you something they can’t deliver, and misleads you with guarantees that don’t cover just what you think they cover?

If you were faced with choosing 2 hosts; one who offered “100% uptime - guaranteed” and another who offered “95% uptime”, which would you choose? Most of you would naturally choose the 100% host because not only does it seem like they’re more reliable, you’re also drawn in by the fact that if it does go down, you can get something out of the deal. But if you can’t get something back because it’s network uptime they guarantee, what’s the point? You may as well have gone with the honest “95% uptime” host after all.

Conclusion
Hosting companies don’t like to admit downtime. We know it happens and they know it happens, but it’s almost taboo to mention it. In a “100% uptime” marketed world, anything less makes you seem inferior than your competitors and that can lose you business.

Offering a “100% uptime” guarantee is basically like writing a blank check, and that’s not something most people in a normal state of mind would do. For a business to do that is almost commercial suicide, especially when selling a service so potentially unstable.

The real concern though, shouldn’t be with uptime figures and guarantees, it should be with how your host handles and responds to any downtime it experiences. Will they publicise their downtime and admit to the issues they experience? Will they keep you informed (time permitting) when they expect the service to return? Customer service and communication is key here. Remember, when you’re faced with downtime the last thing you really care about is the guarantee. Getting your site back up and running becomes the priority.

Disclaimer
This information is based upon my experience working within the hosting industry. The content is not intended to represent any or all web hosts and should not be treated as such. In many cases, for ease of clarification I provide examples or situations based upon the extremities of the industry. These examples or situations should not be considered “standard practice”, and every web host’s operational procedures will differentiate.

The information and views expressed within are that of an individual and do not necessarily represent the views of any companies I may be associated with.

I am only human and mistakes may be present. Before choosing a web host, ensure you perform your own research.

Originally written by Jules Robinson, http://www.thiswebhost.com.

Originally written by Jules Robinson. Reproduced with permission.

Part 1. Overselling.

What it means
Overselling is essentially the act of selling more than you are able or capable of providing to the end user, simply because a web host knows that they won’t use it. It plays on the mindset that most clients want as much as possible for as little as possible, despite never using it. It’s a bit like buying a high performance sports car and using it for domestic purposes. You’re sold on the image that you have all this power, but you can never use it. Attempt to use it and you’ll either get into a nasty accident and crash (like a server), or you’ll have your license taken away (be suspended for “excessive resource usage on a shared host”).

To really understand what overselling is, how it works, and why it’s a problem, we need to look at the hard facts and mathematics.

The Truth about Disk Space
Ever seen an advert for a host offering perhaps 50GB, 100GB or even 200GB disk space? Ever wondered how they can offer that at such a low price? They can’t. They can offer it to you, but you’ll never be able to use it. If you even come close to using it, they will (generally) terminate your account and claim that your site has grown far too busy, and that you’ll need to upgrade to a VPS, or dedicated server.

Disk space is a limited commodity. Disks only come in certain capacities, and you can only house so many of them in a server. Once you’ve filled up your disks, and you can’t add any more to the system, there is NOTHING you can do to obtain more space except delete existing files. There is NO SUCH THING as “UNLIMITED DISK SPACE”. It’s simply a physical improbability, and nothing more than a marketing term. “Unlimited” roughly translated means “We don’t want to advertise a fixed figure, but use too much and we’ll terminate your account”.

For examples sake, let us suppose that the host we are dealing with has 2TB (2000GB) of disk space in the server we are on, and that we’ve purchased a 200GB space account. Mathematically, this means that the host could only store 10 user accounts on that server without overselling.

2000(GB or 2TB) / 200(GB) = 10

This is on the assumption that every account on that server will be allowed to, and can use up to their maximum disk space allowance of 200GB. This is logical because after all, they’ve paid for that space right? But wait…10 clients per server? This can’t be very profitable for the hosting company, can it? It’s not at all, and this is where overselling comes into play.

Of that 200GB space package, most accounts will barely reach even 1% usage (2GB). If we re-do the calculations based upon a 2GB disk space usage instead of the maximum theoretical of 200GB, we see far different results:

2000(GB or 2TB) / 2(GB) = 1000

Wow! That’s an additional 990 accounts we could store on that server, and that’s 990 times more revenue we can earn in the process! Let’s oversell! It’s a very easy trap to get into, and a trap that almost all web hosts fall foul of.

Can you see the problem with this yet? Should any individual or multiple user(s) use more than the estimated 1% of their disk space, the calculations simply don’t add up any more, and the server may experience issues. In some cases it might even run out of disk space. To prevent this from happening, a lot of hosts will suspend or terminate the accounts that use more than this calculated percentage, giving them a variety of excuses. Not all hosts do this, and some will simply move those top user accounts to a different server.

The Truth about Bandwidth
Bandwidth is similar to disk space, but actually has to be looked at in terms of physical network performance. Because networks don’t have a hard set data transfer limit, we have to look at what they’re actually capable of transferring from a speed perspective.

Most servers are connected via a 100Mbit port. For those of you who aren’t networking-savvy, don’t worry too much about this because the figures will be shown below. Because all bandwidth quotas are displayed in bytes and not bits, we need to convert this accordingly. Fortunately, that’s pretty easy for us as it’s roughly a division of ten. A 100Mbit port has a theoretical maximum transfer rate of approximately 10 megabytes a second, excluding overheads. There are always overheads, so let’s drop this figure down to a “safe” 9 megabytes a second.

Let’s assume that this port is constantly in use, and at its maximum capacity 24 hours a day.

9 (megabytes a second) * 60 seconds * 60 minutes * 24 hours = 777600 megabytes

This works out to an approximate maximum transfer capacity of 776GB a day. In a one month period, this works out:

776(GB) * 30 days = 23280(GB) or 23.280TB

Now we’ve crunched the numbers, let’s assume that our hosting company that gave us 200GB disk space also gave us 15TB bandwidth per month. We can see quite clearly from the numbers that it’s possible to provide 15TB, but ONLY if we are the only customer using that connection or port. Unfortunately, we’re not. With a potential for thousands of other clients to be using that connection at the same time, our chances of actually reaching that figure diminish drastically every second. It is, yet again, another marketing ploy. It’s just another way to say “We have no set hard limit on how much bandwidth you can use, but if you use too much, we’ll cut you off”. 15TB looks better on paper than 60GB, after all.

“UNLIMITED BANDWIDTH” is also a complete myth. Using our figures we’ve quite clearly shown that there is a limit on the speed of the transfer through a network, so resultingly there is also a theoretical limit on how much data you CAN potentially transfer. This is something that conveniently most hosts neglect to mention.

Generally speaking again, hosting companies that oversell do not expect a single client to use anything more than up to 3-5% of their potential bandwidth allowance. Using more than this will potentially result in more account terminations and the attempt to sell you a dedicated service.

Why is overselling a problem?
For some it’s a question of ethics. Do you really want to be the customer of a host who lies about the packages they offer? Can your business really survive under the observation of a company who may cut you off at any moment for using “too much” of a package that you clearly paid for? It’s a huge potential risk for anyone that makes money from their website.

For others it’s a question of performance. Sharing a server with many hundreds, or thousands of other people can seriously impact the performance of your website. All it would take is a handful of rogue users to run some badly coded scripts, and they could bring the entire server down. Do you really want to host somewhere that’s so heavily oversold? Statistically, the more accounts on a server, the higher the potential for downtime and server failures.

How do I spot overselling?
It can be very difficult to spot overselling, depending on how severe it is. Generally if you see a host offering high packages for next to nothing, they’re overselling. If you see fairly good packages at insanely low prices (around $1/month) - they’re overselling.

The fact is that hosting costs money. Servers, staff, bandwidth, disks, replacement and backup hardware…it all costs money, and we’re not talking about pocket change here. If you pay $1/month for hosting then you should expect the same as if you paid $100 for a car. If it works fine without any problems for a period of time, then that’s great, you’re lucky. When it experiences problems, don’t be surprised if you receive little or no support at all.

Not every host oversells, and not every host charging $1/month for hosting packages is going to provide you with little or no support. The intent of this part of my guide was to inspire you to think carefully about what goes on “behind the scenes”. Remember, if it looks too good to be true, it probably is…

Originally written by Jules Robinson, http://www.thiswebhost.com.

I know its been a long time since I’ve written anything. I haven’t had much time lately. Even if I did have time, I don’t have any ideas for something to write on. If you have any ideas for a topic, please do tell me.

This really isn’t a programming tip, but it is vital if you are a programmer. How you should talk to a client. I have learned this the hard way many times. And though all these tips may be good, USE YOUR JUDGEMENT! All clients are different; don’t do something you believe will be bad.

1. Grammar
Probably my worst, I don’t know where I would be with out MS word. You will not be taken seriously unless you spell everything correctly and your grammar is good. Most people you work with are not English scholars, so perfect grammar isn’t completely needed. Just make it the best you can.

2. Don’t engage in small talk unless they start.
Business is business, personal talk is personal talk. They generally should be kept separate. It just seems odd to have your programmer ask you how your day is going. Though, if the client wants to have a quick chat, do so if you have time. If you don’t have time or don’t want to, politely inform them you have work to do.

3. Don’t over-mention payment.
The price of the item you are working on was agreed upon when you started. The fact that you will be paid is implied. Try to stay away form mentioning it or it will give the client the impression you only care about the money. When the end comes and it is time to ask for payment, don’t use phrases like “Please pay me” or “Please send me my money”. Better to use “Please send funds to [place]. I will send you the files as soon as receive them”. It sounds less focused on the money and changes the focus to giving the client his files asap. Leaving a good last impression can mean a return client.

4. Don’t play the blame game.
It is not uncommon for a client to misinterpret what you say. When it was harmless I apologized for not being clear and continued. Was I unclear? I don’t think so, but to quickly resolve the harmless conflict I took it and went on. When the misunderstanding is of some significance, it becomes purely circumstantial. Don’t take the blame for what isn’t your mistake, but don’t blame them for your mistake. More not taking the blame for what isn’t your fault later.

5. Don’t use too many large words or complicated sentences.
Not to call clients stupid, but coming at your client with a barrage of large words that are sure to send them to dictionary.com is a bad idea. They will instantly take it as you trying to manipulate them into something. Or they will just think you are an idiot compensating with large words. For instance, you would not want to message them

Just say

6. Speak to them according to their tech knowledge.
Different clients have different knowledge of how programming works. Some of my clients are less experienced programmers and want to know how I am building it. Others don’t even know what a database is. Generally, don’t tell them the inner workings of the program unless they want to know. They hired you to make a good program, they should trust you. You aren’t a teacher, if they don’t know how anything works; politely inform them you don’t have the time to explain it. If they know what they are doing and want some insight into the program, just tell them.

Off of the polite tips, here are some tips for realistic communication in the event that blind politeness with get you ripped off.

7. Don’t take the blame for what you didn’t do.
If you make a mistake, take the blame for it. But if the client misread something that was clearly his mistake, it is his fault. If it has no impact on anything, just take the blame to avoid conflict. But if it affects something (another feature, something works different, ect), politely inform them the error is on their part and you cannot fix it for free. This is purely circumstantial, there is no formula to say if it is your fault or not. Decide objectively and fairly. Also include a clause in your policies that leave you as the decider of where things go in lack of detail.

8. Be as assertive as you have to, when you have to. But not more.
If a client is doing something that is wrong, inform them of that. I had a client some time ago that wanted something that he simply didn’t specify earlier. He was insisting it was implied; I eventually had to reply “No offense intended, but a reasonable person would not expect that to be implied. Since it was not clearly specified, I will not program that feature for free.” He was mad, but the project worked out and he did return later for more work

Lately, other people’s code has been getting on my nerves. It is so messy it takes me an hour to just decrypt it. Don’t get me wrong, I can work with other people’s styles if they are clean. This inspired me to make this article on writing clean code. This is not a sure fire guide to clean code, but they are good guidelines.

1. Indentation

What style you use doesn’t really matter, just stick to it. I find the allman indent style the easiest, but it is fully up to you. Just stick with it in the entire application. If you have a team, make sure they all use the same style. The only style you should never use is none.

If you want a list of indent styles, go to http://en.wikipedia.org/wiki/Indent_style

2. Brackets

PHP lets you have a single line under an if, while, or for statement without using brackets. Don’t use it. It makes things harder to read and leaves an open door for a bug should you accidentally add second line. Reason being it wont create an error, it will execute the command as normal outside of that condition or loop.

3. Comment your code

Even good code can be complicated. Comment everything you do. This does not mean every line, but every basic function. If you have a complicated process (well, hard to read) comment every step so the next programmer knows what is going on. And remember Eagleson’s law

“Any code of your own that you haven’t looked at for six or more months might as well have been written by someone else.”

4. Make everything as simple as possible, but not simpler.

This Albert Einstein quote sums up how your coding should be. Simple as possible. Some things simply take complicated, hard to read code. Don’t be afraid to use complicated code where needed, just comment them. But when possible, make it simple. One reason is as Brian W. Kernighan said

“Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. “

Other reason is because adding things to applications may make it more complicated. Why not start from easy and work your way up as slow as possible opposed to start at the top and have no room to move.

5. Use descriptive variable names

With good indentation, comments and simple code, bad variable names can still make an application near impossible to modify. In no more then three words (there is a good reason they are not called novels), describe what it does and what it is. Lets say we have a mysql query getting all the post to the forum, a good name would be $posts_query. $query would not be good for the task, all it tells you is what it is, it could be any query. The same goes for functions.

6. Good looking variables

Descriptive naming is essential, but it serves almost no point if your variable name is $postsquery. It makes it harder to read because the next programmer has to separate the words themselves. It is better to either capitalize the first letter of each word ($PostsQuery) or use an underscore ($posts_query).

7. If you don’t use a templating system, embed PHP in HTML, not HTML in PHP

PHP gives you the ability to end the PHP and start html, if its within an if statement it will honor it. It is easier to read HTML with embedded PHP then echo’d HTML with all the quotes escaped. For example

if($condition = “value)

{

?>

<input type=”text” name=”<?php echo $name; ?>” />

<?php

}

Opposed to

If($condition = “value)

{

echo “<input type=\”text\” name=\”$name\” />”;

}

It doesn’t make a huge difference in that instance. But when outputting large blocks of HTML, it is far easier to read if you are putting the PHP in the HTML.

I originally wrote this article over a year ago. But after going though it I fixed allot of mistakes in grammar and composition. I also added a few things.

Programming:

Plan out what you will do before you do it.
This may seem trivial, but the hour you spend doing it will save you many hours down the road. I have learned this the hard way many times. As this may seem obvious, the only reason it is such is because you just thought of it. It won’t be nearly as fresh when you come back tomorrow. I have a full guide on planning projects here.

Make your variable names as descriptive as possible.
It doesn’t matter if the variable ID doesn’t exist, if it is with a bunch of results with result_ before it, make it result_id. This will make easier for you or any future programmer to do it. I have had to work on code where everything wasn’t well named; it was a major, multi-hour pain.

COMMENT YOUR CODE!!!!
This is by far the most important one. No matter how bleeding obvious the code looks now, it won’t be in 10 days when you have a bug that needs fixing. Comment your code for other programmers and yourself. Don’t be afraid to put long comments where they are needed, they do not affect speed. Just don’t go overboard, comments explain what you are doing. Don’t write a small novel over what this code did to get here and its background.

If a piece of code is used allot and may be changed, make it an include.
This is one again I have learned the hard way with deadlines just hours away. An include means one change and it’s done in every file. Typing it out every time not only makes the code messier, it makes it hard to edit. Lets say your page has a header that goes into every page. You present it to the client and he finds one error. This could mean a 25 file fix up if you don’t use includes. But if the header file was an include, it is a no problem deal.

To each its own, don’t make two things in one file.
There is no crime in making allot of files for a project. If you have two different parts that are in the same process (a forums reply box and the file that actually posts it for example), use two different files.

Don’t reinvent the wheel.
You will have projects that have the same functions in part. It is not a crime to take the code from an old project and modify it, doing so gives the client better code and saves you time. I use the same code from a project I did about a year ago for a user system. Why? I use it because its rock solid code that works every time. All I would do should I remake it is rewrite the same code, possibly some bugs with it. Similar projects mean similar code, whether you take advantage of it or not.

Don’t overuse OOP
Among programming techniques, Object Oriented Programming is a pile driver. Insane power and ability, but extremely resource intensive and large. Using OOP takes a long time to process and run. The flexibility and power it provides should one be used for pieces you will reuse on large projects. If the project isn’t large, OOP may be overkill. If that piece of code doesn’t need to be reused frequently, it may not need to be an object.

Project:

Set realistic deadlines.
NEVER give a deadline you don’t think you can make, all that can do is make the client mad and you stressed. It is better to give a deadline you think you can beat, because if you make it better the client will be happier. Should you not make it early, you have time for the unexpected. The other reason you should do this is most-nighters. There is nothing harder to edit then code made by a programmer in a time crunch, even if that programmer is you. I have done most-nighters to meet deadlines before. When you are tired and running on caffeine, your code gets messier and messier to the point you can’t read what you just wrote.

Never go into a project you can’t or won’t do.
This one is bad you both you and the client. If you don’t think you can do a project, don’t try to. What will happen is you spend extra hours trying to do this, you will eventually say you can’t do this, or raise your price. The client will either leave you or never use you again and give you bad reviews. I’ve turned down many high paying projects because I did not know how to use the script they wanted modified.

Keep the client updated.
Updated clients are happy clients. I would never go back to a programmer who tries to avoid contacting me on what’s going on. I would want a programmer who messages me when I come online, telling me what’s being done. Even if it is not a complete module being finished, I still want to know it’s being worked on.

Never compromise your price.
I’ve had clients come to me with a CMS project for $300. In a money crunch, $300 sounds awful nice, you might be almost inclined to accept. Just take into consideration what you are doing to yourself. You are working just as hard on a project for less money. When a project for a fair price comes up you must turn it down because you are busy. It doesn’t end there though, if somehow it goes public that you gave a cut rate job, there will be people left and right asking you for a cut rate job. You don’t want a reputation for that. There are people who will pay the higher price for a good job. It is better to wait for a good one to come then to compromise your pricing standards.

I have also found that the ones expecting cut rate jobs are the hardest clients to work with. A low price either means they have no experience in what it takes to make a site like they are asking for, or they just don’t care. Either way, a bad price is a warning sign of a hard to deal with client.

Don’t work for free

This could be categorized in the same place as the previous tip. But I feel it deserves its own paragraph.

Any programmer who has been in the business for a while has had many people asking for free work. Generally they are broke kids looking for a free script. They generally make promises they never intend to keep, the common ones I hear are

1. When the site makes money you will get X% of it
2. I am outsourcing you, if I like your work many paying projects will follow

3. This will look great on your portfolio. We will both become rich off of this!.

All these have problems. One and two require the unchecked honesty from the client over money. Legally speaking, he could run with your code and there is nothing you can do about it. The final one is true, but if you need to expand your portfolio, you should not do it for someone else. If you need an extra project to show clients, do it for yourself or a paying client. That way you maintain the rights to the code and can use it whenever you want.

Make your terms clear before the project start.
I have had clients mad at me to the point where they left me even though I had the upfront fee. All because I wouldn’t do an addition for free. Clients don’t know how it works, even if they think they do. You would be surprised at what clients have asked me to do for free. The best way around this is to make it as clear as you can what you will do, what you will not do and what you will charge more for. I make sure all my clients read my policies before I seriously consider doing the project. That way if something comes up you have something on your side so he had no right to get mad.

Give the client his moneys worth, always.
No matter who gets the short end of this, give the client what he paid for. If the job takes half the time you expected, he will still give you full money. But if the project took longer then expected, still do a job to its fullest. Happy clients return to a programmer that gave them what they wanted, it is good for future jobs to keep your standards high. Returning clients generally pay well because they know you aren’t a scam.

Always have an upfront
When I was just starting things to program professionally, I had a return client come to me for a project. I did multiple projects for him before, easy to work with and trustworthy. He wanted a mail script for a smallish amount of money. It was a fast job, so I didn’t require an upfront. When I finish, his paypal isn’t working, since he outsources me he has a deadline and needs to relay this to his client. He offers me hosting in return for the money, but I don’t need hosting so I decline. I then tell him since I trust him I will give him the files if he will pay me when he gets it fixed. We agree and he gets the files. He stayed in contact for about a week with excuses I didn’t really believe, but I didn’t want to start a fight. It He never replied back. I got scammed by a client who I had a rather long history with. The moral of this story is always charge upfront and never give out the work until you are payed. Even clients you trust could go bad over it. I should also add that the amount was $35. Yes, he went bad on me even with a extensive history over $35.

Happy programming!

Before you start on a project for a client, you need to give a quote (or estimate) and a deadline. To do this accurately you need to map out the project and what you will do.

Why plan projects?

Planning a project gives you an accurate time and price estimate, it also gives you guidelines on what to build during development. It can cut your development time by a large amount because you won’t have to worry about bad design. Lastly, there is nothing worse for a large application’s design then having a programmer who added as he went. Planning a project will make the overall design far better.

Is there a right or a wrong way to plan a project?

No. There is no best or worst ways to plan out a project. The contents of this article are what I have found works best for me. As you should do with all tips/tutorials you see, play around and find what works best for you.

Enough of the ever so interesting before talk, lets start planning! Each of these steps should build off the last. For example purposes, I will use a fictional image hosting site to map out.

Step 1. What is the project?

In plain English, outline what the sites general purpose is and all features. This should be confirmed by the client before you start to avoid errors.

Example

The purpose of this site is to safely and securely upload images to the server. Users can manage their uploaded image if they register and log in. Admins have complete and total access and can manage everyone’s images.

Step 2. In English, what are the functions this site would do.

This is where you in more detailed talk, go through all the features. You generally don’t need to show this or any further steps to the client. This step isn’t completely necessary if you are going to map the rest out in the same sitting. If you are going to have a pause in between this and the end of the next step, do this to save you the time of think it all up again.

Example

Uploading –Basic html upload page followed by a php script to see if they are logged in the upload it accordingly.
Login –Basic html login page and a php script to log the user in. I can just use my pre-built user script for this
Register- Html page with a php script following it to register you. Part of the premade user script.
Management –If user is logged in, show all his images and give him the option to delete them.
Admin manage –A list of all images with the ability to delete

Step 3. What files would be used and what would they do

Working off of step 2, create a list of every file you will need.

Example

System

Class.php –Has the user and SQL cleaning class. The user class includes authentication for both users and admin.
Head.php –To be included on every page, logged you into the mysql server, includes
class.php and does other processes every page needs to do.

End User

Index.php –The index page, all html besides the login page
Upload.php –The page that does the uploading from the form on index.php
Login.html –The login form
Login2.php –Actually log the user in.
Logout.php –Delete the user’s login cookie
Register.html –The regsister form
Register2.php –Actually register the user. Check for like username, mismatched passwords, ect.
Manage.php –Show a listing of all the user’s images and redirect them to the login page if they aren’t logged in.
Delete.php –Check if the image if belongs to user logged in (redirect to login page if logged out) and delete image if it is.

Admin

Admin/manage.php –The admin management script, identical to the user’s management script, just remove the queries limitations and display them all.
Admin/searchuser.php –A text box to search for usernames
Admin/searchuser2.php –Searches users from serchuser.php, if no name is in the GET data, search everyone to have a member list without making an identical file. This has links to ban, make member or make admin any user (including other admins and yourself)
Admin/changeuser.php –Actually changes the user the way the admin requested

3.1 Database design (done at the same time)

While you are going though the files, compile your database design.

Example

Table user

Int id
Varchar name
Varchar pass
Int rank

Table images

Int id
Varchar url
int user_ID

4. How much time with expected debugging would this take

You now have your database designed and your files mapped out, go to each file and assign how long it should take you, assign one fee for the database (that includes designing it here)

Example

System

Class.php –2.5hrs
Head.php –.5hr

End User

Index.php –.5hr
Upload.php –1.5hr
Login.html + Login2.php + Logout.php –.5hr.
Register.html + Register2.php –1hr
Manage.php –1.5hrs
Delete.php –.5hr

Admin

Admin/manage.php –.5hr
Admin/searchuser.php + Admin/searchuser2.php –2hrs
Admin/changeuser.php –1hr

That totals to 11hrs, you use that to give your quote or estimate to the client. The art of estimating how long a part will take is a tricky one. If you are not sure how long it will take, break the file into every part you can think of and think how long each part will take to code. If you simply don’t know, estimate up. Chances are if you don’t know how long it will take you (or exactly how to build it) you will have quite a fun time debugging the file.

When you start programming, you use what you made as a guideline to program your projects by. Go from file to file creating the script. When it is finished it should be almost exactly as you mapped it out.

Happy programming!

1. Choose a skill

Different people are good at different things, I am an expert programmer but cant design for the life of me. I know excellent designers who cant program for the life of them, then I know people who can do both. The only way you can find out what you are good at is to try them both. If you are good at both, you are gifted. Having both is a skill I wish I had. I can’t give good advice for design since I don’t do it, so this guide will be mainly for a programmer, but the tips should apply for both.

2. Start:

If you are a programmer, start with learning HTML, you wont be able to complete anything well without a basic knowledge of HTML. When you learn HTML you need to start a programming language, I would recommend PHP since its easy, widely supported and there are tons of resources for it. When you learn one well (and I mean really well), move on to something else. Javascript/AJAX is a valuable skill these days.

3. Choose hosting

No matter what you do, you will have to have hosting. What should you pay? Can you afford the good hosting? Ask yourself this, can you afford to have a problem with you server and spend almost a week trying to find a knowledgeable tech. Can you afford downtime during projects? You get what you pay for; I pay $20 a month for 3 domains, one gig space and 60 gigs transfer. For this seemingly steep price, the techs respond to tickets in 15min (this includes admins) and there is zero downtime –it works right the first time. My last host (does it matter who? All budget hosts are the same) took 8 hours per response, the issue would take days. I have a full article on how to choose a host here.

4. Build a portfolio

People wont go with you at a good price till you get a portfolio and recommendations. Do one smallish open source script for your portfolio, this will give clients a good look at how you code. For recommendations, do cheaper works, when you have both you can start working at a full price. And remember,

NEVER WORK FOR FREE!!!

5. Find your price

If you are going to be renting an office or have many costs of business, read Julian Jackson’s article on pricing here. If you are not, find a fee you are happy with and work at that. What do you value your time at? That is a question only you can answer.

This is my announcement that I plan to move this blog to its own domain in the next few days before SEO comes into play. If you have a domain name idea, please leave it in the comment box.

Most of my tips are (and will be) on making a system secure from a hacker trying to exploit a hole in your system. However, even the most secure login systems can be rendered useless if you have a weak password. Passwords can be the easiest way for a hacker to gain control of your system. When you get a password there is no need to find a security hole and cover up your tracks, its log in and do your damage. Most clients I come across have weak passwords – some as weak as “123456”. Here are some tips for good passwords.

1. NO Dictionary Words

One of the first attacks a hacker will try is whats called a dictionary attack, this is where the guesser goes through a list of words in a given language. Using two words wont help with this, some guessers can go as fast as tens per second.

2. Make Your Passwords Long

The second type of attack is called a brute force attack, this is where the guesser goes though every possible combination in a sequenced order. This is only effective for weak passwords such as “123” or short (sometimes “four letter”) passwords. If you have a long password this attack could take years to successfully complete, look at the math of this.

Each character has at minimum 62 possible values (upper/lower case letters and 0-9). If you have a 8 character password, there are 62^8 possible combinations. That’s 2.1 * 10^14 (210,000,000,000,000) combinations at 100 per second it would aprox. 69,000 years for the operation to complete.

The simplest and most effective way to combat a brute force attack is to use a long password.

3. Mix Cased Letters and Punctuation

Even though it would take a simple brute force engine thousands of years to complete its course, more advanced ones can cut the time substantially by going over the likely ones and skipping the unlikely ones. One thing they can do is not try mixed case letters, simple (and obvious) way to combat this is to mix your letter cases. If you don’t want to use mixed case letters for memory reasons, use punctuation marks, not all systems allow it but it is a great way to make a brute force attack even harder. This makes the odds of a brute force attack or a dictionary attack far less likely to work.

4. Never Use the Same Password Twice

I must admit, I violate this one often with smaller login systems. However when it comes to accounts that I have above average privileges on or someone would want to get (like my bank), I never use the same password twice. The main reasons for that is so if one password gets found out, that will be the only account compromised. When I owned a forum I always told my moderators and admins to keep the password they use here unique to any other forum.

What does this have to do with development? Everything, the systems you make shoud be secure. The above advice is good password practice, the below tips are ways to incorporate them into your programming.

1. Force Password Length

One thing I have learned doing what I do is that users tend to select the weakest passwords they can get away with. If they are to do this, you need to set some limits, the first and most important is to make it at least six letters long (I recommend eight).

2. Provide a Note with Security Recommendations

There are some things you simply can’t put into a script, you cant reasonably check for dictionary words and common sequences of things. Add a note that the user is responsible for their password, that they shouldn’t use dictionary letters and they should mix letter cases.

3. Cap Attempts Allowed

Using a database, track what IP’s have failed login attempts, after 10 wrong guesses don’t let them try for another hour. I wouldn’t worry about this on smaller systems; it is somewhat memory intensive to do this. This makes even a dictionary attack near impossible; it could take years to guess even a bad password.

With all these steps, it’s ultimately up to the users to choose the password security, but these tips make it harder for users to choose bad passwords.