How to set up a LAMP

LAMP is the common acronym for Linux, Apache, MySQL, PHP/Perl. It reflects one of the most common web server setups in use today. I've set up LAMP servers enough times now that I've mostly got it down to a science, and I'd like to share with you how I set up a LAMP.

Choosing the "L"

I use the latest Ubuntu LTS, or Long-Term-Service release. This ensures 6+ years of compatibility, stability, bug fixes, and security fixes. CentOS, Red Hat Enterprise Linux, and Debian Stable are other common choices, but for the purposes of this document, I will assume Ubuntu 12.04.

Basic "A"

The "A" in LAMP is for the Apache web server, and there's really not much choice in that. Make sure you're running a current version, though. You may also choose which modules to enable or install. I try to keep the server light, and I disable CGI and and deflate. You can enable CGI if you need Perl, or enable Deflate to save bandwidth, but I tend to target script performance and load handling over bandwidth. I also use mod_userdir, which you should install if given the option. On Ubuntu, all of these mods come along with the basic apache2 package.

"M" and "M" (and occasionally another "P")

Although PostgreSQL is also a fantastic option, MySQL is still the de facto standard for LAMP stacks. Future versions of Red Hat Enterprise Linux and Ubuntu LTS will switch to the completely compatible fork, MariaDB, and will keep the acronym neatly in tact. MySQL's InnoDB database engine is nearly ACID compliant, fast, and featureful. For this reason, I install MySQL 5.5 or higher for now, and will use MariaDB when it is widely available. I also often install PHPMyAdmin along with MySQL.

Mind your "P" (or "R" or "L" or...)

The last letter(s) in LAMP are the most flexible. PHP is a common choice, but so was Perl (thankfully, not so any more, though you might still need it with CGI), and Python, Ruby, Lisp, and a few others are also gaining in popularity. I'll focus on PHP, since it's what I mostly develop in, and it is what many common software projects such as WordPress, Drupal, and PHPBB are built on. PHP has a lot of libraries built in, but I recommend adding GD, CURL, and SQLite support which are often packaged separately. Most distributions package the Suhosin (security hardening) patch by default, if not, I recommend you install it as well.

Sending eMail

On Linux, getting PHP configured to send eMail is easy. Simply install Postfix, and you're on your way. During installation, you'll be asked for SMTP configuration, so make sure you have that handy.

Accessing the Server

The standard methods of interacting with a web server are SSH, FTP, and SFTP. I recommend ProFTPd and of course the standard SSH server. ProFTPd is my FTP server of choice because it is very easy to set up. You log in with your system account, and your permissions are determined by what they are set as on the server. This makes it secure and easy to configure all in one.

The Magic Command

One of the things I love about setting up Linux servers is that you can get it down to just a few commands. As my parting thought, here's a magical command for Ubuntu flavored servers that will get you up and running in one go.

sudo apt-get update; sudo apt-get install apache2 php5 mysql-server openssh-server postfix proftpd-basic phpmyadmin phpsysinfo php5-gd php5-curl php5-suhosin php5-sqlite; sudo a2enmod userdir; sudo a2dismod cgi deflate;

Tune in next time for how to set up user accounts, access control, per-user websites, DNS integration, and performance tuning for Apache!

The Importance of Normalcy

In most cases, I champion being unique, and in most cases, that means not being normal. In the case of databases, however, that isn’t the case. In the lingo of database land, being Normal is to be Unique.

Early Databases

In the earliest times, the idea of a database was primitive. If you even had something called a database, it didn’t look much like our databases today. For the most part, programs stored their information in clever flat-file structures. Let’s imagine that you wanted a list of employees at a company. Some are developers, others are managers, some are in the Android department, some in the iOS department, some in the design department, and some in the web development department. An early application might have treated this data as a fancy sort of CSV -- merely separating each of the employee’s fields with a delimiter.

While this works fine for smaller numbers of people, you begin to encounter severe performance problems when you want to manipulate the data based on certain fields. At first, this isn’t a problem. Finding all the people who work under a manager as as simple as matching the “manager” field to the manager’s name. Of course, the wacky new employee (Moreena) who decided to enter their manager’s name as “Kymberlie” instead of “Kimberly” isn’t going to show up. It would make things simpler if the system instead showed options for existing managers so that Moreena can simply select her manager from a list. Generating a list of all existing managers now requires scanning every existing record in the document, a time consuming operation.

The Relational Revolution

Eventually, a new concept, the relational database, was born. Enter: Normalcy. A relational database was so called because it took these spreadsheet like structures, called them tables, and allowed you to specify relationships between them. Along with this came the concept of normalization, meaning that the database was structured in such a way that data was repeated as little as possible, and organized in a way that was as efficient as possible.

If we return to our example earlier, we would no longer store each employee as a single record with all of the information; at least, not exactly. Since multiple people work for the same manager, that manager’s name is duplicated data. We then take that data and “Normalize” it, by putting it in a separate table. The same is true of departments. Each table gets a special column called a primary key. This key is a unique internal way to identify each item. By convention, this is called the “id”. What’s important is that the unique key is internal to the database, and is linked but not equivalent to the actual text. To associate an employee with a manager and with a department, we define two fields for each employee which are a special type called a foreign key which points to the identification column in the table with the information we want to associate. There is now a simple, concise, table which lists the company’s managers, one of whom is Kimberly. When Moreena goes to select a manager, the database no longer needs to scan an entire document. Instead, it simply lists the small list of managers, and when she selects Kimberly from the list, inserts the unique identifier into her manager field as a foreign key, directly linking her to her manager in an efficient way.

Being Normal

Keeping your databases normalized is absolutely important both because it improves the efficiency of your queries, and also because it maintains the integrity of your data. Given our example, if Kimberly decides that she actually likes the way Moreena spelled her name, and gets it legally changed, it would be difficult to apply this to a monolithic structure. It would require the equivalent of a massive find-and-replace operation. Of course, that may result in Kimberly-the-housekeeper who takes out the trash getting her name changed as well. In a normalized database, since only the unique internal identifier links the manager to the employee, you can simply change the manager’s name, and leave the id the same. Thus, the next time it lists your manager, it shows the new name, as referenced by the id. Additionally, modern databases provide functions that further speed up queries on normalized data, allowing even a moderately powerful server to handle literally millions of data elements and return complex queries in a fraction of a second.

Principles of UX Design

All the time we hear about making things pretty. We also still hear a lot of complaints. This time, I want to approach the problem from a different perspective. Instead of talking about user interface design, I want to talk about user experience design. This isn't about how websites look, it's about how websites work.

Overview

In this case, not an overview of this article, but rather, how to think about the overview of a user interface. A good user experience is action-oriented. Ask yourself, "what does the user want to do?". If, for example, the answer is "write something", that task should take center stage. You should also ask, "what does the user want  to avoid". In the case of writing something, that is most often "distraction". Blogger and WordPress are two very polished user interfaces for writing, but I've never been too fond of WordPress's user experience.

Blogger

WordPress

Blogger is a Google product, so it retains the Google branding bar. WordPress provides something similar, but unlike Google, it is only one product, so why is it there? Google hides the left hand navigation, giving a wider area for writing, and places formatting buttons outside the writing area. Post settings are neatly organized in both, but Google hides them in an understated expandable menu. Even the icons gray, and each is formatted cleanly and consistently. I have no trouble blocking those blocks out when writing. WordPress mixes gradients, different control types, boxes, and a nice big blue button right next to where I'm writing. It's not terrible, but more distracting than the Blogger experience. Finally, I have to criticize the big pink dialog telling me a plugin is incorrectly installed. First of all, there's probably a good reason why the plugin is set up like it is, second, I'm not a user who has the required access to fix it, and third, even if I did, why do I care about it at all when I'm writing a new blog article? A simple, focused, and task-oriented UI will lead to the best user experience. Back to the idea of an overview, this means that a cursory glance over a page should immediately answer those same two questions for the user. If a user wonders "what am I expected to do here?" they should immediately be able to identify what it is, and a lack of distractions should keep them from adding "and I can do that here too..." to their answer.

To Confirm or Not To Confirm

Whether or not, and how to confirm performing an action with a user is always a question to ask. Often, that comes down to whether or not the action is able to be undone. Even a delete, if not permanent, is not something that you need to confirm. Almost all the time, a user means to do what they are indicating, and asking every time is just an annoyance. If you must confirm each action, make it as easy as possible for the user. One way I have done this is to pop up a small dialog with large buttons directly under the cursor. In this way, the target to confirm is easy to hit, and doesn't require a lot of mouse movement. Another way to approach the problem is to simply make it difficult for the user to make a mistake. When managing users, there are various actions that can be performed per account. I use a UX that makes it a simple and consistent two-step process. First, the administrator selects the account they wish to perform the action on. The account is highlighted, making it easy to see what account is selected. The buttons to edit and delete are large, separated, and easy to differentiate. Deleting is a simple and quick process, but it still requires two clicks.

UI vs. UX

Whether a design decision falls more in user interface or user experience is a fine line, and almost everything falls at least partially in both categories. There are many other aspects of the user experience to consider, and design is certainly something that plays a part. That said, pure user experience doesn't need to look pretty, it needs to be functional, and is a much more fundamental part of user interface creation than the design elements. As important as design is, I encourage you to always consider UX first, and then make it look nicer. Your users will appreciate it.