How to Put a Project Under SVN Control

Developers use SVN to maintain current and historical versions of files such as source code, web pages, and documentation. In this article, I’ll be doing a walkthrough of how to put a PHP project into source control using Subversion also known as SVN. I will be using the command line on an Ubuntu server to create a new repository, and TortoiseSVN to checkout and commit files into SVN.

Make sure that the following prerequisites have been completed:

• SVN server has been installed on your server.
• Tortoise SVN client has been installed on your workstation.
• Putty has been installed on your workstation.

In Windows Explorer, determine where you would like to keep your source code. I like to keep my sources under the C:\wamp\www\ folder. In this exercise, our project folder will be named stored in C:\wamp\www\ciproj1\.

Open a new Putty session and connect to your SVN server. Find out where your repository folder is. In this example, our repositories are stored in the \home\svn\repos\ folder. The new repository name will be ‘ciproj1′. Make sure that your user has super user access to run the SVN commands below:

cd /home/svn/repos
    sudo svnadmin create ciproj1
    sudo chown -R www-data.www-data ciproj1

Putty SVN svnadmin create command

The last command gives Apache read and write access to the new repository.
Review the access control file to make sure users can use the new repository. In this example, our access control file is located in the /etc/ folder.

vi /etc/svn-access-control

Now we should be able to checkout the new repository using TortoiseSVN’s checkout command. First, rename the C:\wamp\www\ciproj1 folder to C:\wamp\www\ciproj1-bak. This is because when we checkout the new repository, we don’t want to overwrite your existing folder.

In Windows Explorer, right-click on an empty space, and choose SVN Checkout. In the URL of repository field, enter the URL to your SVN server, making sure that the last directory points to your newly created repository. Click OK.

Notice that the new folder will have a green checkmark, indicating that it is under source control. The repository is currently empty. The Subversion documentation recommends that you create 3 subfolders under the root of your project as follows:

C:\wamp\www\ciproj1\branches
C:\wamp\www\ciproj1\tags
C:\wamp\www\ciproj1\trunk

SVN Folders from the root as recommended by Subversion documentation

Your files should be placed into the trunk directory. The trunk folder is where the code is unstable because it is being developed by 1 or more developers. I will not go into details of what the branches and tags folder are for.

Copy and paste the files and folders located in C:\wamp\www\ciproj1-bak\ folder into the trunk folder.

From the C:\wamp\www\ciproj1\ folder, right-click on an empty space, and navigate to TortoiseSVN > Add. Acknowlege the following screen by clicking OK. Be default, all files will be Added to source control.

The final step is to run the commit command: right-click on an empty space, click SVN Commit. Enter a comment, for example, “This is the first commit.” and click the OK button.

SVN Commit

I just want to make a note that there are other ways to import a project into SVN, and this is just one of them. I hope you enjoyed that walkthrough. Let me know if you have any comments.

Below are links where you can download the applications used in this tutorial:

• Subversion: http://subversion.tigris.org/
• TortoiseSVN: http://tortoisesvn.tigris.org/
• Putty: http://www.chiark.greenend.org.uk/~sgtatham/putty/

10 Things That Can Go Wrong When Deploying a Website

If you are a web developer, you probably have one or more copies of the website you are developing for your client. You may be using synchronization tools available in your HTML editor. You may be using version control systems. These tools are setup to ensure the integrity of the website when it finally goes live. However, even if you have these tools and processes in place, Murphy's Law is still in effect. These are the 10 things that can go wrong when deploying a website.

1. Complications during domain name transfer.

   Plan ahead by updating the email addresses of the Administrative and Technical contacts of the domains in question. Notification emails will end up being sent to invalid addresses if these email addresses are not corrected. Each domain registrar will have different processes and procedures for transferring domains away from them. Some will make it difficult to avoid accidental transfers. For example, domains are "locked" by default. You must first unlock the domain ahead of time or you will end up in domain name transfer limbo. Educate yourself about the processes of the registrar involved.

2. Old pages do not have redirects.

   One of the consequences of redesigning a website from scratch is that the old URL's will be changed. This is expecially true if there is a change in the server side platform, or Content Management System (CMS) platform. If it is important for the client to preserve pages that have already been indexed by search engines, make a list of these pages. Then for each page, create a 301 redirect so that search engines can properly re-index the new URL's of these pages.

3. Scripting interpreter version is incompatible.

   If you have a staging server for development, the version of the interpreter may be different from the version installed in the production server. If the version difference is only a minor upgrade, chances are the scripts will continue to work. However, if the version difference is major, for example, PHP 4 vs. PHP 5, many functions may throw warnings or in some cases, errors. Decide which version you should develop in ahead of time so that the staging and production servers are as similar as possible.

4. Incompatible database format.

   There may be cases where you have developed database tables in a certain format in your staging site only to change it to something different in production. If you did not test the application for these changes, you may be faced with format incompatibilities. Such incompatibilities may be caused by the collation, for example, if the staging database tables were in "Swedish, case-insensitive" and the production database tables were in "utf8". Another formatting incompatibility is the database type (MyISAM vs. InnoDB). Make sure that both databases are using the same format on the staging site and the production site.

5. Client authentication issues.

   If your website requires logins on the application or data layer, make sure that the salt hashes are updated as intended. The salt is one of the inputs in creating a one-way function in encryption. Some developers like to keep the salt the same on development, staging, and production servers, while others like to make these different. For the later, you must ensure that any password hashes are re-generated where necessary, otherwise, the logins will no longer work.

6. Google robot crawl errors.

   When upgrading a static page to a page handled by a CMS like Wordpress, make sure that it continues to be crawled by search bots. There are some plugins that will make the page render in a browser, while at the same time, throw Status 404's in the HTTP headers. Use Google Webmasters to find out what Googlebot really sees, or other HTTP header sniffer tools to disguise your connection as a different client. Additionally, some CMS's have the ability to block access to a site that is still in development. A common mistake developers make is forgetting to turn it back on after deploying to production.

7. Email transmission problems.

   Systems admin tasks often get buried under the overwhelming work involved in deploying large websites for the first time. It should be noted that systems admin tasks should come ahead of any web development task because if the production server is not configured properly, many functions will not work as intended. Email configuration should be one of the first tasks to configure and test. If you have forms that send and receive emails, make sure you test them ahead of time. Check that DNS MX records have been configured properly.

8. Data integrity issues.

   No one should be deploying data-driven websites while it is live. Doing so can cause data integrity issues caused by half-executed queries. Make sure that you always have a full backup before upgrading any database. This can be quite challenging for extremely busy websites, so a suitable time of the day when it is not as busy should be agreed upon with the client to carry this out. In most cases, the website may have to be taken out of commission during the upgrade, so an announcement must first be sent out ahead of time. Consult with your database admin to determine the best approach.

9. Web server permission problems.

   Again, systems admin tasks should never take a back seat to web development tasks. Make sure that proper permissions have been set to files and folders on the development site. See to it that sub-domains are resolving properly, database connection strings are correct, and passwords updated where necessary.

10. Invalid server configuration.

    There are many configuration parameters that may have to be updated on the production site. Such configurations include file size limits. If the web application allows users to upload files, make sure that a suitable file size limit is set in the server configuration. Certain ports may have to be configured to be open or port-forwarded. Some settings are have a different setting while being developed, for example, while being developed in a local machine. After deployment, these settings must be updated to the production server's proper values.

There are thousands of things that can go wrong during deployment and this article only covers 10 of them. This does not even include many unknowns that mysteriously show up during deployment. To be on the safe side, make sure that you have a plan to prepare, execute, test, and roll back. You can also deploy in stages where you are only deploying a portion of the website. You can also deploy in iterations, or deploy in parallel so that you can "flip the switch" when it is ready. Avoid mistakes, but make sure you have enough time to correct them if you still make them by backing up your data, having proper support, and an a roll back plan.

My Review of NetBeans IDE PHP - and Comparison to DreamWeaver

Someone asked for more details about why I like NetBeans, so here's my detailed review of NetBeans IDE 6.9 + PHP and how it compares to Dreamweaver (CS4). I have been a Windows + Dreamweaver user for 10 years.

For personal reasons, I have started evaluating some of my development efforts in Ubuntu 10.10 + NetBeans PHP 2 months ago. So far so good. It scans your folders for class/parameter/function definitions and creates a custom auto complete library. It is open source with lots of open source plugins. It does not crash like DW likes to do once in a while. It supports advanced Subversion commands (if you're familiar with TortoiseSVN, the menu items looks like that).

The search feature is very fast (or is it because I'm running Linux?). Color coding and error hints have been very accurate even when intertwined in HTML and PHP, but sometimes, it is too critical, for example:

<div> </Div>

will show up as an error because of the capital D. I love auto termination of common symbols like test (brackets), {braces}, and 'quotes'.

My dislikes include the lack of a WYSIWYG editor plugin that looks like Dreamweaver's 'Design View or Split View'. FTP functionality pales in comparison to DW's more intelligent FTP and synchronization system.

Well it has only been a couple of months. I will post a more updated review in the NetBeans IDE in the future.

Sending HTML Email and Newsletters to Your Clients

Writing a newsletter can be a very beneficial part of your marketing campaign. It gives you the opportunity to promote products and services, gather feedback and intelligence, or just to stay in touch so that you remain within their radar. In this article, I will discuss issues that you need to be aware of so that you can decide whether your organization needs a newsletter campaign.

The first thing you need to be aware of is that for most of your clients, they are already receiving dozens of newsletters every day. How can you maintain constant contact with your clients without being a pest? Make sure that there is value in each one. Put yourself in their shoes and read over your newsletter. What is in it for you? Compare your newsletter to a similar campaign and identify what makes yours better.

Send your newsletters only to those people who will appreciate them. This means that these people must have had the opportunity to opt in to receive your newsletters. It is far more effective to have a targeted list of 100 interested recipients than to blast 100,000 emails to people who don’t want it. Not only is Email blasting a poor strategy, but in many states and provinces, it is illegal.

It wasn’t that long ago when sending and receiving HTML emails was such a cool thing to do. But only in a matter of months, this was abused by virus and adware authors. Today, Email clients disable HTML support by default. Many “fundamentalists” still prefer to only receive plain text email. So if you are only sending HTML emails, these recipients will only see the source code. So when creating your HTML newsletters, make sure that you have 2 versions: an HTML-formatted version, and a plain text version.

Spammers have abused the Internet from the day it was born. Almost every Email client nowadays has a built-in spam filter which can identify tell tale signs of a Email spam and automatically moves them into the Junk mail folder. Some Email clients allow users to automatically chuck spam into the trash. Before sending out your newsletters, review it for obvious signs of spam. There are numerous tools on the web to validate your newsletter before sending it out.

Mailing list marketing is a competitive market. There are hundreds of companies competing to get your business. They offer tools that will save time and money in managing your newsletter campaign. They offer hundreds of free templates that automatically generate HTML and plain text versions, list management tools and reports to measure your results, opt-in systems, viral capabilities to entice your clients to forward your newsletters to their friends, spam validation, and more. Most of them will have a “free version” or a limited time trial version. So try them out to find out if their services can help your organization manage your newsletter campaign.

Tips on Targeting While Using Framesets

When using framesets on a website, the most common problem is getting the links to open in the correct frame. This is called targeting and is set by using the target attribute of the anchor tag by giving it a "target" to open their links in. In most websites that do not use frames, you will notice that the target assigned is usually "_blank", "_new", "_parent", "_set", or "_top". In a frameset, the target is usually the name of the frame.

Consider the following piece of code:

<frameset rows="50,*">
<frame src="/frame1.html" name="nav">
<frame src="/frame2.html" name="main">
</frameset>

There are two frames in the above frameset. The first is called "nav" and the second "main". Try to imagine that the nav frame (frame1.html) is used for navigation, and all links inside it should opened within the main frame (frame2.html). To do this, you would give the links in frame1 the target of "main" as follows: <a href="/page2.html" target="main">. However, what if you don't want to add the target to every link on your navigation page? You can have a global setting for targets by setting a default target in the HEAD of your document, called the "base" target. You simply add the line:

<base target="main"> 

within the head of the frame1.html page, and all links will then open in the main frame.

Using Frames and Noframes

One of the most misunderstood sections of the frameset tag is "noframes". In reality, this tag allows people with browsers that do not support of have frames enabled to still view your page. In a typical frameset, the HTML looks like this:

<frameset rows="50,*">
 <frame src="/frame1.html" name="nav">
 <frame src="/frame2.html" name="main">
</frameset>

The code above will render a web page with two frames: the top being 50 pixels tall and the bottom being the rest of the page. This would make a nice top navigation bar frameset with the branding, banner, and navigation in the 50 pixel frame. However, if one of your viewers comes to your site and is using a browser that is not support framesets, or has disabled support for framesets, they will get a blank page. So much for the chances of them returning to your site. To make it viewable by them you need to add four more lines of HTML like so:

<noframes>
This site is framed, but you can <a href="/frame2.html">view a non-framed version</a>.
</noframes>

Notice that because you are pointing to the content portion of your frameset (frame2.html) in the noframes section of the page, your site becomes accessible. Always keep in mind that while you may be using the latest version of your favorite browser, your audience may not want to continually download the latest software. Their machine may not support it, or they may not have room to install a 20+ Meg program on their hard drive, or they may be using a mobile phone, etc. Adding four lines of HTML is a simple solution.

You know how pleased I am with your company. I recently opened my own business and knew that an important element of marketing my business is to have a web presence. I am not a technical person, nor do I have much experience with the web (other than surfing). I had no idea what I wanted or needed, other than 'a website'.

Avoid Using Pop-up Windows

I hate pop-up windows and I know a lot of people who share the same sentiment. Even browsers are aware of this and automatically block pop-up windows. The only reason a why site would have pop-ups is because the site owner is thinking of his/her own interests rather than the readers. We all know that when we are browsing, most of us hate pop-up windows. Why is it that suddenly when we switch places and become the site owner, we lose our ability to see through the users' eyes. Let us remember to put ourselves in their shoes.
Pop quiz: Which of these reactions to pop-up windows is a visitor more likely to have?

        (a) "Oh wow! A popup window! I love sites with popups! I will make certain to bookmark this site and visit often. I will also certainly click the ad or links in the popup because I love them so much."

        (b) "@#&$! Whoever made this website obviously has no respect for me as a visitor. When I leave here I will never come back."

Pop-ups should be used sparingly and only when necessary. For example, if your website requires a user to enter additional information before downloading a file from your website. Another example is if you need to control an element on a web page and the only way to do it is by opening a pop-up window. In both of these cases, the pop-up window must automatically close. I hate having to close 10 pop-up windows  after visiting a web site.

Only use pop-up windows if it adds value to the user's experience. Having these on your website is one sure way to drive traffic away.

The Importance of Contrast on a Web Page

An important part of web site design is Contrast. This is because it often means the difference between a web page that looks great and a web page that is hard to read or causes your eyes to strain. Often times it can be hard to decide what colors work well in contrast to others. The color chart below should help show you different colors and how they contrast or don't contrast well as foreground and background colors.

Be aware however, that contrast is more than just how bright a color is compared to the background. You will notice that some of these colors are extremely bright and show up vibrantly on the background color - such as blue on black. But I labeled it as having a poor contrast, because while it appears to be bright, the colors make the text difficult to read. For example, if you were to create a web page in blue text on a black background, many of your readers would have eye strain in no time.

		Background
		Red	Orange	Yellow	Green	Blue	Violet	Black	White	Gray
Foreground	Red		Poor	Good	Poor	Poor	Poor	Good	Good	Poor
	Orange	Poor		Poor	Poor	Poor	Poor	Good	Poor	Poor
	Yellow	Good	Good		Poor	Good	Poor	Good	Poor	Good
	Green	Poor	Poor	Poor		Good	Poor	Good	Poor	Good
	Blue	Poor	Poor	Good	Good		Poor	Poor	Good	Poor
	Violet	Poor	Poor	Good	Poor	Poor		Good	Good	Poor
	Black	Poor	Good	Good	Good	Poor	Good		Good	Poor
	White	Good	Good	Poor	Poor	Good	Good	Good		Good
	Gray	Poor	Poor	Good	Good	Poor	Poor	Poor	Good