Development

DevOps seems to be sweeping through IT departments these years and for most developers it seems to be sen as a way of getting those pesky gatekeepers from Operations away and ship code whenever any developers feels like it.

The problem is however, that in the eagerness to be a modern DevOps operation, the focus is often solely on the benefits of faster releases (on the short term) the “DevOps” provide over “Dev to Ops”, and many developers do seem to forget the virtues Operations (should) bring to the party.

Remember the good old days, when IT got a new server. It was a special event - and naturally the naming game. Finding that special name for the server, which neatly fitted into the naming scheme adopted (be it Indian cities, Nordic mythology or cartoon characters).

This ought to be then, but the ceremony still happens regularly in many IT departments, where servers are treated with the same affection as with pets - and with all the bad side effects it may bring along.

As a developer it seems, you always seem to strive towards producing ever more complicated code. Utilizing new frameworks, adopting an ever evolving “convention before configuration”, pushing object-oriented programming - maybe Domain Driven Development - are practices introduced, refined and explored in the quest to prove yourself as a steadily better developer with rising skills.

Yet to what point?

While the intricate complications may impress fellow developers, doing so often digs a hole which may be pretty hard to get out of. Every complication - not matter if it is in the design, the architecture or the structure of the code - often provides the opposite effect of the desired outcome. The whims of your current self to impress developers with the latest fashionable technique, is short termed reward for a long term pain.

PHP like many other programming languages has facilities to handle exceptions. Using them is pretty easy, but sometimes lazy programmers seems to misuse them to suppress error messages. A try/catch in PHP is usually constructed something like this:

try {
	// Something can go (horribly) wrong...
} catch {
}

The lazy programmer may leave the catch empty, but frankly you should never do it. When you’re doing something - try’ing - it’s for a reason, and if it fails, someone quite possible need to know - the end user, a log file for the sysadm or someone else. Never leave your catch empty, and if you really have a case, where it’s applicable, at least leave a comment in catch block explaining why it’s okay to do nothing.

In PHP when you have a string and want to find out if it contains another string, there are a few ways to do it. You can use regular expressions, use the strstr functions and a few other methods. The easiest way though is probably by using strpos, which returns the number of the character containing the first occurrence of the thing you’re looking for - and false if the string isn’t found.

When using memcache from PHP, you can save values with either set or replace. You can probably safely ignore the replace method:

“Memcached::replace() is similar to Memcached::set(), but the operation fails if the key does not exist on the server.”

- PHP Documentation

In PHP many things can be done several different ways. Picking which way to do something may be a matter of personal taste or habit. Sometimes however, things may be much clearer for the next developer, if you choose one way over another.

A very simple example of this, is adding a new item to an array. Often I come across this construct:

$valuepairs[] = 'Some value'

It’s valid and compact syntax, but in terms of clarity, I’d prefer this construct anytime:

When playing the role of the DBA, it’s often useful to get a quick listing of how many rows each table in a database contains. The syntax for this is pretty simple in Mysql:

SELECT table_name, table_rows 
FROM INFORMATION_SCHEMA.TABLES 
WHERE TABLE_SCHEMA = '***database name***';

Notice that when using innodb tables, it’s only a rough estimate.

A url may contain a hash/an anchor reference. If you need to remove it from url, it’s quite easy. Here’s a short recipe on how to do it in PHP (including a little test input):

$urls = array(
	'http://example.com/',
	'http://example.com/#test',
	'http://example.com/?id=1',
	'http://example.com/?id=1#test',
	'http://example.com/?id=1&id2=2#test#test',
	'http://example.com/?id=1#test#test'
);

foreach ($urls as $url) {
	if (strpos($url, '#')) {
		$url = substr($url, 0, strpos($url, '#'));
	}
	echo $url, "\\n";
}

Apart from removing the hash ending from urls, the function can naturally also be used on any number of other similar cases, where you need to trim a string.

So your current website - if running PHP - and it seems to work just fine. I am however working on a project, where the new servers are running on a 64 bit version of the OS. This change seem to cause a number of potential issues, and as there didn’t seem to be a resource collection the issues, I’ll try to post a few notes on the experience. Please feel free to add applicable notes and links in the comments.