Archive for February, 2010

Apache – Name Virtual Host errors


2010
02.27
For some time now apache has been bugging me that there is a configuration issue with my virtual hosts, so I decided to find out what the issue was and try to resolve it. As it happens the fix was easy but not well documented.
Issue:
[warn] NameVirtualHost *:80 has no VirtualHosts
Resolution:
You can resolve this by ensuring that you virtual hosts are configured correctly. To do this you should have a NameVirtualHost for each of your ports and then be using ServerName within each virtualhost. By configuring apache this way you allow it to correctly interpret requests for different virtual hosts on the same IP Address.
Example:
In my apache2.conf file I have the following declaration
NameVirtualHost *:80
And then each of the virtual hosts is configured:
<VirtualHost *:80>
RailsEnv beta
ServerName my-app.redjamjar.net
DocumentRoot /home/rails/beta/my-app/current/public
<Directory “/home/rails/beta/my-app/current/public”>
allow from all
AllowOverride All
</Directory>
</VirtualHost>

How to get your email heard – make it a tweet style one liner


2010
02.22

Every time I make it third person single question/update one liner I get an almost instant response – it really is awesome.

And for the longer messages… well that little subject line is the place to not ‘name’ the email but to get right into the essence of the email – by the time its been read the recipient wants to read the rest of the email.

Integration – how to plan for the unknown


2010
02.17

No one has ever said integration of one system with another is straight forward. But does it always need to be a surprise a minute roller coaster ride? In a recent and slightly challenging (read evolving) integration projects I devised a simple set of rules:

Action Plan:

  1. Identify the unknowns
    How? Start simply with broad questions. Don’t be too quick to get into the detail as this will be the natural tendency. At this stage understand nothing about the detail but fully comprehending the end user environment or capabilities will give you a greater barometer for detecting where the unknowns are essential or not.
  2. Questions everything, assume nothing
    I’ve tripped over this many times, combined with one this is probably the largest probably when scoping, initiating or specify an integration piece of work. I find Excel is my friend in this situation, I can capture questions and responses as the knowledge flows
  3. Seek documentation but don’t rely on it.
    Documentation in what ever form is usually well intentioned, but out of date, inaccurate or just plain wrong. Typically the documentation will look grand ‘Technical Specification for X.Y.Z version 1.2′ however what tends to happen is that was written at the outset before a line of code had been written – ask yourself when you last went back and updated a specification at the end of project, yet you want to make key integration decisions based on it?
  4. Get a setup of the system as close as possible to the real environment for use during development, verification testing and UAT
  5. Commit, integrate and test regularly. Really if your not doing this forget it
  6. Use real data not ‘lorem ipsum’ or ‘test account 1′
    Demand this especially if you have translation or localisation considerations to consider.
  7. Allow your/encourage your client to come and inspect your work – they may see things your developer mind over looked.
    Coming from a developer mind I’m always surprised how easy it is to be lulled by our perspective on systems.
  8. Testing
    Even with all the automated testing, eyeballs and code reviews I’m still amazed by how often I come across developers who see it as acceptable to ship code from their development computer to a production environment without any testing.

Have I overlooked anything you find works best for you? Let me have your comments and I’ll add them in.