Categories

Tag: development

In a recent project, I had to install the TranslateX module into an EPiServer 6R2 site. TranslateX is an open source EPiServer module that allows you to export pages in XLIFF format for translation services. The problem is that the original module was created for EPiServer 4 and has been since updated to work with version 6.0, but I was unable to find any resources or help to get it installed in 6R2 or 7. After some trial and error, I came up with these steps.

Download EPiServer CMS 6.0 from EPiServer World and install it. Don’t worry — even though it’s an older version, it shouldn’t cause any problems with your R2 installation.

The default options for the first step of the installer should be fine. On step 2, check the “Show All Sites” check box, and then select the site where you will install TranslateX. (Note: You will receive a compatibility warning when you check the “Show All Sites” check box, but it doesn’t appear to be a problem.)

Finish the installation.

Now, you should have it successfully installed. However, there’s more to do before it’ll work. First, you will need to create a folder for TranslateX to save temporary files, and EPiServer will need write access to the folder. You can name the folder “translationtemp” or something similar.

Open your Web.config file and look in the AppSettings section for a key named “xliffworkpath”. You’ll need to update this value with the location of your “translationtemp” directory.

At this point, you can now create translation projects for your pages by navigating to a page in the CMS and clicking the “Translation” tab. But when you try to run the project (Admin Mode > Admin tab > Scheduled Jobs > Translation scheduler service > Start Manually), you’ll probably notice an error on the “History” tab and you will never receive an e-mail with the translation. That’s because you will need to tell EPiServer which languages are available for translation through an XML file.

In the root folder of your EPiServer installation, there should be a “lang” folder. Create an XML file called “translationlangs.xml” and place it in that folder. Here’s a sample of the content to include in the XML file:

Make sure to update the XML to fit your own language needs. As long as your mail server is working, you shouldn’t need anything else. If the “History” tab on the translation scheduler service says, “OK,” after starting the service, you’re good to go.

I haven’t tried installing TranslateX in EPiServer 7, but let me know if the steps above were any help.

Whether to use tabs or spaces when indenting code has been a source of contention among developers for some time. However, in none of these debates have I found a legitimate reason for spaces instead of tabs — at least not when both sides have a firm understanding of how tabs are to be used (i.e. indentation, not alignment).

Advantages of Tabs Over Spaces

So, why do I prefer tabs over spaces? It’s quite simple: there are a huge number of advantages and very, very few reasons to use spaces — namely to work with teams that are stuck in their ways.

1. Fewer Key Strokes

This one should be obvious. Pressing the tab key on the keyboard is only one keystroke. Unless you indent with only one space (which is bad for other reasons), you’re spending more time typing. Now, I hear you saying that almost all modern code software can automatically replace a tab with a certain number of spaces. Let me say that this isn’t a solution; it exacerbates the problem and makes it nearly impossible to insert an actual tab character. It’s just a patch to a problem and misleads people into thinking that white space isn’t important — until they work with someone else’s code, who didn’t use the same number of space characters as the “auto-space” feature in their editor.

2. Easier Keyboard Navigation

Even if your editor does replace tabs with spaces, it usually doesn’t change how the arrow keys navigate through those characters. With tabs, I can use the left/right arrow keys to move back or forward one level of indentation with each key press. This doesn’t work with spaces, and if you’ve only ever used spaces, you probably don’t even realize how inefficient it is.

Many hard-core coders will point out that there are editors such as Vim with very efficient keyboard navigation that doesn’t rely on the arrow keys or that you can use keyboard shortcuts (like ctrl+left arrow) to move through white space, but not everyone uses those editors (or is proficient with them), and shortcuts are often still more complex. Even so, the ability to move from one level of indentation to another is not addressed.

If you’ve worked with spaces your entire career, then you probably think that being able to navigate quickly through levels of indentation is a minor boon. You’ve probably learned to naturally compensate by using your mouse and clicking to place the cursor where you want or some other keyboard combination. However, tab users immediately recognize how painful it is to move through code with spaces. It’s like switching from a two-button mouse to one with only one button — why would anyone do that?

3. Smaller File Sizes

Both space and tab characters take up one byte of space. If you use two spaces to indent, you’re doubling the file size of your documents, and you’re more likely quadrupling the size since many editors default to four spaces per tab.

Most space apologists will claim that code can be minified or compressed in some way, but let’s be realistic. Take a look at the source code of just about any website’s HTML that relies on spaces for indentation, and you’ll find that the vast majority are not compressed. Even when they are, the original source exists somewhere and is taking up disk space. Storage may be cheap, but that’s not a good reason to fill it up.

4. Configurable Indentation Preferences

Suppose I like four spaces per level of indentation, but my colleagues prefer three. We’re eventually going to have to negotiate on one or the other, and if I’ve been using four spaces, then it’s going to be hard to break that habit. This leads to inconsistent, sloppy code. Even if I eventually adopt my team’s standard, what happens when I move to another team or inherit a project from other developers? It also means that any new team member will also have to adopt our version of the acceptable number of spaces.

If you were to use tabs, you wouldn’t have this problem. Each developer can configure their environment to use a specific tab width; whether it be two, four, or even eight spaces. This makes everyone happy. Imagine if you forced everyone to use a specific font size or syntax highlighting. Obviously, these things don’t impact the quality of the code, so why not let everyone customize them to their own personal preference? Why are you being a white space Nazi?

5. Readability

Quick question: How many levels of indentation are there in the line with the //Case 1 comment?

See how much easier that was? Each tab is one level of indentation. With spaces, we’re at the mercy of the developer and whether he/she was consistent with the number of spaces. Finding errors with improperly nested code is much easier when tabs are used. You can’t accidentally forget a part of a tab, but you can easily enter three spaces instead of four.

By the way, I purposefully made a mistake in the number of spaces for one of the lines in the first example. Did you catch it? Would you have missed it if I had used tabs?

Why Spaces are Problematic

1. No Consensus on Amount of Identation

We touched on this in briefly in the points above, but it’s important enough to get its own section. No one agrees on how many spaces make up one level of indentation. Standards are important when it comes to code. Just because your team has come to a decision on a set number of spaces per indentation, doesn’t mean that they’re all happy with it, that they’ll all honor it, or that the decision will work on anything other than new, start-from-scratch projects.

With tabs, there’s only one decision to be made: tabs or spaces. With spaces, there’s tabs or spaces, and how many spaces. Given the advantages of tabs outlined above, I don’t see why this should be a hard choice.

2. Not Portable

What do I mean by “not portable?” I mean that if you share your space-indented code with anyone else (e.g. all those online tutorials where you can copy/paste the code), the recipient is going to have to reformat it for his/her environment. People that use spaces instead of tabs think that this is just par for the course, but tab users have a big advantage here — they can use the code as-is. Worst case, they may need to change the indentation level, but they’ll certainly never have to go through each line adding and removing spaces. And don’t say, “editor X handles this fine.” Wait until you have to work in a client’s environment where only Notepad is available.

3. They’re Hard to See

Spaces are a poor fit for indentation simply on the fact that you can’t easily see an individual space character among groups of spaces. How often have you been typing an Office document where you had to do a double-take to see if you had typed two spaces instead of one? Granted, this isn’t as much of a problem with fixed-width fonts, but it’s still a problem.

I absolutely hate it when developers use only one or two spaces for indentation, and it’s not because of bad eye sight. If your HTML or XML is so complex that you need tens of levels of indentation and it’s interfering with the available horizontal space in your editor, then you’re doing something wrong. If you must use spaces, use at least three or four.

Hopefully, you code with visible white space markers. If not, then maybe that’s why you don’t see the problem with spaces. In Visual Studio, use ctrl+r ctrl+w to show white space. In Sublime Text 2, add the “draw_white_space” setting to your user preferences and set it to “all”. If you’re a serious coder, then you should have a consistent use of tabs and spaces, where tabs (usually denoted by arrows) represent the level of indentation and spaces (usually denoted by dots) represent alignment characters. Here’s an example:

This seems to confuse a lot of people in the space camp. It should be easily noticeable that the code above has one level of indentation and that spaces have been used to align the “size” and “shape” properties so they line up nicely. For some reason, the space people claim this as something that can’t be done with tabs, and then they try to demonstrate their point by incorrectly using multiple tabs to align the properties. They don’t seem to understand that tabs are only for indentation. Spaces are for alignment.

So Why are Spaces Used so Often?

With all these advantages, why are there so many advocates for spaces? Here are a few possible reasons.

1. Misunderstanding of Difference Between Indentation and Alignment

Some people have a hard time knowing when to use spaces and when to use tabs, so for them it’s easier just to use spaces all the time. This is a cop-out, and if it’s your excuse for using spaces, then you need to learn the difference.

2. Code Editors that Replace Tabs with Spaces

Many code editors, Visual Studio included, default to replacing tabs with spaces and not showing white space characters. This leads to ignorance as to what is actually happening behind the scenes, and novice coders never learn to use tabs as they’re meant to be used. It also leads to a mixture of tabs and spaces that only looks good when viewed in the original editor.

3. Copy and Paste Programmers

Many developers learned how to write code by pasting it from other sources. Unfortunately, Web browsers aren’t the best at displaying code, and Web authors weren’t sure how to insert tab characters into their tutorials. This means that a large majority of the code that is shared online uses spaces instead of tabs.

4. Sloppy, Indifferent, and Poorly Organized Coders

Many programmers don’t care about what their code looks like. “As long as it works” is their mantra. These people are usually disorganized and write code that is difficult to maintain. They are entrenched in a specific code editor and are highly resistant to change or anything that jeopardizes their current method of writing code.

I hope you don’t fall into that last group and that you care about how your code looks. Well written code should be quick to create, easy to maintain, and it should look beautiful. Maybe that last bit isn’t important to you, but maybe you’re not passionate about what you do either. Use tabs for indentation. Spread the word.

There are plenty of tutorials for WAMP installations (Windows, Apache, MySQL, and PHP), but I don’t know of any that have quick, easy-to-follow directions for someone familiar with Web development, but not necessarily with getting a local installation started.

UPDATE: The following instructions are no longer up to date. To install a WAMP server, try using XAMPP.

Installing Apache

The latest version of Apache can be found at http://httpd.apache.org/download.cgi. Unfortunately, the Windows version is not always up to date with the Unix version, so you’ll have to scroll down the page until you find the most recent Win32 version. You should notice a few download options for Win32 (“source” or “binary” and “without crypto” or “including OpenSSL”). Unless you plan on using SSL, download the binary version without crypto (it’ll be an MSI file).

After the download completes, open the file and run it. Click “Next”, accept the terms and conditions, and continue through any other screens until you’re asked for some server information. Enter localhost for both the network domain and server name fields, and use whatever e-mail address you like for the administrator’s e-mail field.

If you want Apache to run, even when you’re not logged in, leave it set to run as a service. However, if you’ll only be using it with an occasional project, change it so that it has to be manually started. The “typical” installation should be fine, as well as the default destination folder. After installation completes, click “Finish.”

To start Apache (assuming it isn’t running as a service), you can navigate to the “bin” folder (found at “C:\Program Files\Apache Software Foundation\Apache2.2\bin” in most cases) and run the “httpd.exe” application. Personally, I run it from the command line. To do this, open a command prompt, and update your PATH environment variable (e.g. SETX PATH "%PATH%;C:\Program Files\Apache Software Foundation\Apache2.2\bin"). Close the command prompt, reopen it, and now you should be able to launch Apache by simply typing httpd.

To make sure everything is working, visit http://localhost/, and you should see a blank page with the words, “It works!” If not, try http://localhost:8080/ — 8080 is a common port used if the standard port 80 is unavailable. The Web page being displayed is found in the “htdocs” folder of your Apache install.

Installing PHP

Visit http://www.php.net/downloads.php and download the Windows binaries and source (Thread Safe, ZIP format) of the latest version. Extract the ZIP files to a “PHP” folder in your “Program Files” directory (e.g. “C:\Program Files\PHP” — you’ll need to create the “PHP” folder). After extracting the files, make a copy of the php.ini-development file and rename it to php.ini.

Now, we need to make some configuration changes for Apache to recognize PHP. Open the “httpd.conf” file in the “conf” folder of your Apache installation, and search for a list of lines starting with “LoadModule”. After those lines, add the following:

LoadModule php5_module "C:/Program Files/PHP/php5apache2_2.dll"

Next, look for the <IfModule mime_module> section of httpd.conf and add the following just before it’s closing </IfModule> tag:

AddType application/x-httpd-php .php

Finally, add the following to the very end of your httpd.conf file:

PHPIniDir "C:/Program Files/PHP"

To verify that PHP is working, create an index.php file in the htdocs folder, and add the following to it:

Installing MySQL

First, download the MySQL Community Server MSI file from http://dev.mysql.com/downloads/mysql/. The installer is fairly simple — choose “Typical” when prompted for the setup type, and it should complete shortly afterward. Check the box to run the configuration wizard after the install. The default settings should suffice for most of the screens, but you’ll need to choose a memorable root password before finishing.

As for MySQL, that’s it. No additional setup needed. Create a database and start programming — you’re local dev machine is ready to go!

Conclusion

Hopefully, you now have a working WAMP installation. I purposely left out a lot of configuration options, as the purpose of this guide was to get you up and running as fast as possible. If you notice any mistakes or have any issues, feel free to post them in the comments below.