29
May

Managing Legacy Code While Remaining Somewhat Sane

By jjordan 0 Comments
Categories: PHP, Technology and Web Strategy

I think every coder and every company that's been around long enough arrives at a situation where for whatever reason, old code needs to be re-used. But not in a 'Hey, I'll grab this function from the site' way but in a 'Hey, we need to redo the frontend for this site without redesigning the code base' way. But seemingly without fail, this code was created three versions of coding language ago using barely logical, much less programmatically sound, methods. As a coder, how do you avoid pulling out all your hair in an instance like this?

There could be a number of reasons for doing this. One, there may not be enough budget to redesign the code. The idea is that by not spending the time necessary to document and and then reprogram the code base, time is saved because the code, in theory, already works. Two, if no one really knows how the code works and a deadline is approaching, it may be hard to justify spending lead time on the process necessary to document code that seems to work. However, I might argue that when making a decision like this, one should consider the support time that might be required to ensure that everything is working properly once the site goes live, the time cost of combining two or more disparate types of code which may not want to 'play nice' with each other, and other similar factors.

Ultimately, whether or not to re-use or reappropriate legacy code depends on the budget, time constraints, and other business factors. If the person who designed the code is available, then this process is made easier; if not, the person who picks up the project has to make some tough decisions. If the decision is made to use legacy code, a developer's best plan is to:

1) Be organized. Keep notes on everything and refer to those notes frequently. The code may be unorganized, but that doesn't mean you have to be.

2) Have a plan and follow it throughout your development. If you have a certain way of formatting code, make sure you do it everywhere. Come up with way to address general problems you will encounter. If a function doesn't work, are you going to rewrite it from scratch? Are you going to attempt to fix the code in-place? Whatever you decide, apply the same thing everywhere.

3) Be patient. Dealing with legacy code can be frustrating and slow. Take it one page / function at a time. Speed is always important, but never at the expense of good code.

4) Keep perspective. Yes, you will encounter crazy, illogical ways of doing things. You will not believe that someone could think this way. However, the point is not to let that distract you from the goal of creating good code. Create a 'Wall of Fail' like we have where we poke fun at these things.

So if you are presented with legacy code that needs to be reappropriated, try to follow these steps. If you do, hopefully at the end of the project you will be able to don a smoking jacket, and not a straitjacket.

24
Apr

Setting up PEAR on a Linux web server (CentOS)

By mlavista 0 Comments
Categories: Linux, PHP and Technology

Installing pear lets you take advantages of some really interesting way to extend PHP. This should be a fairly simple install, so we hope this helps.

First shell into your machine. This is a personal preference, but if you don't have an "installs" directory, your home directory can get messy. Let's cd into it.

% cd installs

Now get the pear code:

% wget http://pear.php.net/go-pear

What? No wget? Install wget and come back.

The following is at the top of the file that wget just downloaded, but they don't seem to mention it, so we will. Just run this file as a php script from the command line.

% php -q go-pear

The only thing you need to change is the install path. The default is where you are now. Use /usr/local/bin.

For some reason the default looks like this:

Below is a suggested file layout for your new PEAR installation.  To
change individual locations, type the number in front of the
directory.  Type 'all' to change all of them or simply press Enter to
accept these locations.

1. Installation prefix ($prefix) : /Users/mlavista
2. Temporary files directory     : $prefix/temp
3. Binaries directory            : $prefix/bin
4. PHP code directory ($php_dir) : $prefix/PEAR
5. Documentation base directory  : $php_dir/docs
6. Data base directory           : $php_dir/data
7. Tests base directory          : $php_dir/tests

1-7, 'all' or Enter to continue:

Type "1" to change the path. Go with /usr/local/bin and hit enter

The rest is all defaults and let it install.

To test, when you're done check to see if it's in your path:

% which pear

You should be all set. To install something

% pear install NAME_OF_MODULE
24
Apr

Getting authorized_hosts to work | Logging in without a password in Linux

By mlavista 1 Comment
Categories: Linux, PHP and Technology

So many of the posts out there about this seem to leave us hanging. This post outlines how to log in to Linux without a password and addresses some of the gotchas that seem to creep up along the way. We manage enough servers that it's nice to be able to get in and around quickly.

I'll try to outline the way to do it and then address some of the gotchas that come up.

Make yourself a private key on the machine you'll be coming *from*. This is how to do it using a Mac or Linux. Windows people, I wish you luck with something like cygwin or using your SSH program to do this. If you're using Linux servers, maybe you can do this on the main machine you log in to, then go from there as your "home base."

Open up your shell.

% ssh-keygen -t rsa

Just hit enter for the passphrase (that kind of defeats the purpose of what we're doing). The default is to put the file it makes in your $HOME directory. (echo $HOME). For this example, I'm assuming that's what you did.

If it didn't exist already, this will have created a directory called .ssh in your home directory and created 2 files inside it:

-rw-------   1 myuser  myuser   1671 May 24  2007 id_rsa
-rw-r--r--   1 myuser  myuser    400 May 24  2007 id_rsa.pub

You need to copy the contents of the id_rsa.pub to your clipboard.

% cat id_rsa.pub

Copy it. It should looks something like this (not my actual key, of course)

ssh-rsa kjakjhasdhjfjkahsgdfhjkgasdjkhgfajkshdgfhjags834yg
swdhjgfjkashgdfjkhasgdfjkhgasdjkhfgasjkhdgfjkhasgdfjkhgasdjk
fhgasdcvjhasgdfjhkqg34jhkqgwejkhfgaskjhdgfkjhasgdfkjhagsd== myuser@Zap.local

Now ssh to the machine you want to log in to automatically.

% ssh 123.45.67.8

Enter your password as normal. Once logged in, let's check to see if you have an ssh directory.

% ls -la

If you see .ssh, cd into it. Otherwise mkdir .ssh and cd into it. Now we just need to add your key to your authorized_hosts file. This next command will either add to what you have already or create it if it doesn't exist.

% cat >> authorized_hosts

Now paste the key you copied above. Hit enter to get to a new line and then Ctrl-D to stop editing.

To make sure that there aren't any issues with permissions, make sure that only this user can read the file.

% chmod 600 authorized_hosts

Now let's make sure that this directory has similar permissions. Go back up a directory and fix the permissions

% cd ../
% chmod 600 .ssh

That should do it. Try opening up a new shell window and log in.

% ssh 123.45.67.8

That should get you in without having to enter a password.

Extra credit: I think it's helpful to make sure you have hosts mapped in your /etc/hosts file (Mac / Linux) if the IP or host you're using doesn't have a convenient name for you. Windows XP users, this is conveniently located in your c:\Windows\system32\drivers\etc\hosts file. Of course, other systems vary.

In that file, just make an entry like this

123.45.67.8          server5

And save it. On a Linux system you may need to restart the network to have it take effect.

% /etc/rc.d/init.d/network restart

Now you can just ssh to the name

% ssh server5

Need to troubleshoot? See what /var/log/secure says about it.

24
Apr

Using Subversion for Web Development

By dprevite 1 Comment
Categories: Technology

Hopefully by now you know what Subversion, aka SVN is. It's a version control system that keeps track of changes made to files like source code and documentation. It's similar to CVS, but with some major advantages. We've been using it at work for awhile, and I really like it. Changes don't get lost, we can easily keep track of released versions, and once we get around to implementing it SVN will tie into our bug tracking system.

We usually have two servers for a project, one as the development server, and the other a production server. We all have a working copy checked out on the development server. Using virtual hosts with Apache we all have our own sub domain. So for example on our dev server we'd have:

  • dan.ourproject.com
  • mike.ourproject.com
  • jc.ourproject.com

With each pointing to that developers working copy. We make our changes on the dev server as we're making the site, when we finish a task we check it in, and everyone does an update often to avoid conflicts.

When we are getting ready to push a release out to the production server we have to be careful since a lot of the time there are people using the site. We don't want to have errors pop up on the production server. To make sure it runs on that server as well as it did in our working copies, we have a staging area. It's on the same server as the production copy, but only we have access to it.

So we do an export to the staging area, click through the site and run through a checklist of things to check for and once we're sure it's running ok we copy that to the production area and it's live.

Since we want to keep track of the versions we push out to the production server, we give that release a version number, tag it in our Subversion repo, and update our project wiki.

This workflow has worked well for us and if we have a problem we can always roll back to a previous release. We can also use the Change Report feature of SmartSVN to do a kind of code review when others commit code. If we see something a little strange we can fix it, or if's completely crazy we can roll back quickly.

This is just how we do it, if you do it differently I'd love to hear about it so just leave a comment. In the future I'd also like to look into using Git in a similar way.