How good system administration is like new underwear

I can’t remember the last time I bought my own underwear. I may not have EVER bought any for myself. Each Christmas, there’s typically a few new pairs under the tree with my name on them. Well, more precisely, my name is on the wrapping paper that the underwear come in, not actually on the garments hemselves (because I’m too old now or much too young to have people labeling my clothes for me).

But I never have to worry about underwear. There’s an unseen process chugging along that keeps my clothes drawers replenished with fresh undergarments. It’s a constant. The underwear is just there and it just works.

Good quality system administration is like new underwear because it’s a constant, it’s just there, and it just works.

If the development team is worried about placating the system administration team or if the dev team constantly has to work around various odd limitations in the system, then you’re system administration is not like new underwear at all. It’s like a sock that has holes.

You don’t want to worry when you put on your socks in the morning that your big toe might shoot out of your sock into the cold morning air, right? Is there a more uncomfortable feeling? Similarly, you don’t want to launch your new app and have to cross your fingers that the database is going to hold up. (Perhaps I’m starting to mix metaphors here with all the underwear and socks talk)

But my point is this… When your dev team has to worry about the system administration, they’re going to spend more time talking about and coming up with solutions to issues that could probably be addressed by more robust system administration. That makes your programming projects take longer. And that’s costing you money. Real countable money.

So get yourself a good admin. Pay them wisely. Give them new toys to play with. And never worry about your underwear again.

Continue reading

Google Adsense and Google Analytics may be blocked by McAfee

I can’t confirm what’s going on but I believe that at least McAfee and maybe other firewall appliance providers recently starting blocking googlesyndication.com in the software of their appliances. It started happening at work this week where all of a sudden Google Adsense and parts of Google Analytics were unavailable to us. When I traced it, it was all requests to *.googlesyndication.com, mostly pagead2.googlesyndication.com. Once we created an entry within our McAfee appliances to allow those addresses through, everything went back to normal. YMMV.

Continue reading

Development Environment layout using Linux, Apache, PHP, and Subversion

Some of the age old questions I face lately are:

  • What’s for dinner?
  • Should I accept that friend request on Facebook for the friend of a friend of a friend that I knew 15 years ago?
  • What’s the best development and test environment layouts for PHP using Apache as a web server with Subversion for version control for multiple developers?

Some of you may be asking yourselves the same questions. The choice of dinner is a personal one. I won’t go into that except to say that everyone loves a good burrito. Spicy! And you probably don’t care about my take on Facebook etiquette since your friends list probably dwarfs mine.

But I do have some definite thoughts on the layout of development environments. And I find that there’s a huge lack of information about this on the interweb, so here you go.

We use Linux, Apache, PHP, and subversion in our development environment and so these instructions will be biased towards these topics but I think you can apply this method using various other technologies.

I like to give each developer their own development web site and development database. I find it’s easier for everyone to have their own individual sandbox to play in. We give them each their own domain using their initials, something like rzdev.domain.com for me, Rich Zygler, and vbdev.domain.com for another developer, Vinny Bagadonuts. We set the Apache directories up on the Linux dev box in a similar fashion:

/var/www/rzdev.domain.com/
/var/www/vbdev.domain.com/

This has a few benefits. If I need to show Vinny something with my site development, I can just send him the link to http://rzdev.domain.com/broken-page. I can make changes to code, even major infrastructure code and not break anything for the other developers. We do the same thing with the databases, prefacing them with our initials.

Now, since our dev boxes use Linux, we set up Samba for sharing on these web directories. This means that all the devs can edit files and use source code management on the Linux server itself or on their Windows machines (we use either Eclipse or Zend Studio and create projects on the shares, that’s a whole different posting!).

This dev site layout is closely linked to the way we use Subversion for version control. When we start a new site or application, if we can split out the development evenly enough, we’ll just have everyone work from the trunk version of the code, with each developer working on their own little section. Each developer puts the trunk in their Apache dir and we edit the Apache configs to reflect this:

/var/www/rzdev.domain.com/trunk/
/var/www/vbdev.domain.com/trunk/

The root of the dev sites typically look like this:

/var/www/rzdev.domain.com/trunk/docs ( your Apache document root )
/var/www/rzdev.domain.com/trunk/lib ( non-public PHP library code )

When we commit code changes in Subversion, we have a hook that updates our main development site here:

/var/www/dev.domain.com/trunk

Again, that site can be seen on the web at http://dev.domain.com/ This way, we can do integration testing on our code to make sure our new code doesn’t break code from someone else within the dev site.

Now, the important thing here is that the Quality Assurance (QA) and Testing people ( if you’re lucky enough to have them ), don’t use any of these previously mentioned sites for their testing. Why not? Well, because if they’re doing a good job and are therefore sufficiently anal, they’re going to complain when code is changing on the site they’re looking at.

So we give them their own test site and database that’s viewed on the web at http://test.domain.com/ and setup in apache at:

/var/www/test.domain.com/trunk/docs
/var/www/test.domain.com/trunk/lib

The developers will meet and create the list of files and database changes that get moved over to the test site. How the actual moving is done doesn’t really matter. If you have the time and energy to set up some Ant or Phing tasks, that works great. But copying/rsyncing files and running some SQL on the test database works just as well. The most important part is that the developers meet to decide which part can go to test. Otherwise, you could have code going to test and eventually production that might not be fully vetted.

When QA finds bugs in test.domain.com, they can send them to the developers. The developers can instantly start working on fixing the bugs in their own dev space at rzdev.domain.com and not affect the other developers or the ongoing testing of the application. Pretty nice right?

Advantages of this approach

  • Uses source code management
  • Developers can unit test their own code
  • Developers can do integration testing between each other’s code
  • Developer A typically doesn’t destroy code or data that developer B is using
  • Developers don’t destroy code or data that QA/testing is looking at
  • Developers can both edit files and use source code management in either Linux or Windows environment
  • Very scalable. Adding new developers into the mix is as simple as adding their respective sub domains and databases (of course, this can also be viewed as a disadvantage, see below)
  • Less bugs make it to production

Disadvantages

  • Lots of sysadmin overhead initially and with each subsequent domain added. You have to set up all those developer sites, rzdev, vbdev, etc. Same overhead when using branching within subversion. Plus, you have to setup all those databases and setup the config code to connect to the appropriate database for each developer domain.
  • Lots of file space for all the sites and databases.
  • Confusing for lone wolf and gunslinger developers who are used to overwriting production or each other’s development code (too bad for them!)

So what do you think? How do you setup YOUR PHP development environment?

Continue reading

linkedin.com needs to sync up company names when the company name changes

My invites to present and former colleagues via linkedin.com have started to tumble in as opposed to the normal trickle. I think that’s a fairly accurate sign of our flagging economy as anything I can personally put a number on. Of course it could also be that I’m a loser who has never really used linkedin a lot and so have practically no contacts there. 😉

What’s annoying however is the way linkedin keeps track of company names and what happens when a company name changes. For instance, let’s say I work at a company called “Davisons.” I put that in my linkedin profile. “Davisons” gets bought by “Johnson, Inc” and they change the name of the company to “Johnson Davisons.” So any new people coming into the company know it as “Johnson Davisons,” not just “Davisons.” When they look for current employees on linkedin, they won’t find all of them because some have the old company named listed while some will have the new company name listed. Not to mention how bad this problem gets when one of your previous employers changes names after you have left.

This problem is what I would call an issue with name history. This kind of name history problem is starting to creep into other areas of the web as well. I’ve already had the misfortune of trying to email someone I haven’t emailed in a few years and reached a completely different person (ie, one person’s email acct was shut down and another started with the same address). Pretty embarassing — makes me think twice about starting emails with “Hey dirtbag! Long time no see!”

The solution for linkedin’s name history problem is pretty simple. They should ask you if the company has gone by any other names and let you choose from possible alternates (or even free type them). It won’t take long for their system to build up the necessary relationships between past and current company names. It could even be pretty slick and auto-update old companies in your profile to their present name if the name is now different from what you specified.

A search for employees of “Davisons” in this case would give you both Davisons and Johnson Davisons and whatever other company names are “linked in” to this company.

Continue reading

Firefox 3 is my panacea

So one of my biggest technological hurdles has been overcome, I can finally switch folders in gmail since I upgraded to Firefox 3.  Sounds small, I know, but I was one of the few afflicted by this weird bug on both my work and home machine.  And I got to use the word “panacea” in a grammatically correct title.  Ahh, life is good.

Continue reading

Beware the Lone Wolf PHP Developer

With all the posts on interviewing PHP candidates popping up lately, I thought I’d post this draft that I’ve been sitting on for awhile that’s related to new jobs and interviewing candidates.

I’ve run into the Lone Wolf PHP Developer at several places I have done work. Sometimes, I’ve had to work side-by-side with the Lone Wolf. Other times, I’ve replaced the Lone Wolf who had moved on to different hunting grounds. Still other times I’ve had to hire people and had to choose between a Lone Wolf and several other candidates.

Just who is this Lone Wolf and why should we fear them so much? Here are some telltale signs of the Lone Wolf PHP Developer:

  1. The Lone Wolf doesn’t understand how to work in a team of developers. They typically don’t even understand what benefits that would create. They do all development on their own, listening to very little input from qualified sources.
  2. The Lone Wolf got to page 141 on Enter-A-Beginner-PHP-Book-Title-Here and no further. Objects? They’ve never heard of them. They must not need them.
  3. The Lone Wolf re-invents the wheel for every project and doesn’t use standard tools and practices.
  4. The Lone Wolf eats their young. OK, I made that one up. Frankly, how could a Lone Wolf have young anyway?
  5. The Lone Wolf is perfectly satisfied with doing programming work on production servers and using FTP to deploy their code. It never occurs to them that they should strive to create development and test environments. It never occurs to them that deployment via FTP doesn’t scale higher then one developer.
  6. The Lone Wolf doesn’t know what the letters SCM, CVS, or SVN are, or how to use them in their daily work.
  7. The Lone Wolf never reads my blog or any other blogs on programming. The Lone Wolf may not know what a blog is.
  8. The Lone Wolf says crazy things like “MySQL can’t do transactions” and somehow gets management to believe them.
  9. The Lone Wolf was initially adored by management because they launched a lot of code live during their short stay. Too bad all that code is buggy and completely un-maintainable moving forward. Management doesn’t like that.
  10. The Lone Wolf whips up incredibly stupid and unnecessarily complex solutions like template systems in which the templates are stored in a database instead of the file system/memory/cache. They shun using tried and true templating methods like PHP files, XSLT, or at the very least, Smarty. (see also: reinventing the wheel)
  11. The Lone Wolf names variables after themselves that mean nothing to anyone else (ex, $lonewolfFlag )
  12. And worst of all… The Lone Wolf PHP Developer fails to realize that there are other developers out there in the business world, trying to earn a living just like they are. By failing to conform to development standards that have been proven and tested, they make everyone’s job more difficult.

Now, I personally have run into this Lone Wolf scenario with other programming languages as well. But I think because it is so simple to work with PHP without much formal training that it lends itself to this problem much more readily then other languages. The blessing and curse of PHP is that it is the new VB 6.

Continue reading

PHP Developer Jobs are the Hottest EVER!!!

** I’ll preface this by saying that I’m not specifically looking for a new position but I think it is important to be aware of the market that you serve. Even in happy times during my employment, I routinely scan job ads to see the health of the market and to gauge its direction. **

If anecdotal evidence means anything, and sometimes it does… and at the risk of sounding like a teenage girl writing on a myspace page, the PHP job market is literally blasting off! I’ve never seen the market for PHP programmers as strong as it right now in the NYC/Philadelphia region.

While there are lots of PHP jobs in the usual suspects like small start-ups, there also seem to be a number of jobs at established companies and developer shops. I’m also seeing a definite split in PHP jobs where there are both entry level jobs as well as jobs for more experienced people with titles like “Senior PHP Developer” and “PHP Tech Lead.” I can’t remember seeing so many senior PHP positions. The salaries I’m seeing are also at an all time high. Many ads have salary ranges that extend well into 6 figures.

As far as requirements I have seen, there definitely seems to be a shift towards frameworks like Symfony and Zend Framework as well as items specifically mentioning IDEs like Eclipse and Zend Studio. However, I rarely see mention of source code management and unit testing. Hopefully those items were cut from the job ads due to space requirements. 😉

If you are a PHP developer in the area and are highly experienced, get ready to reap the rewards for your hard work. If you are a hiring manager in the area, prepare to shell out more for top talent.

So what is everyone else seeing in their area with regards to PHP developer jobs?

Continue reading