I just had an interesting email exchange with one of my newer staff, a friend from university who worked for [insert name of company] for a number of years. Aforementioned anonymized company being a Fortune 500 company that is in the IT industry. I’ve got stuff with their logo on it in my office.
The conversation began when he asked if he could use a goto statement (in PHP code!) for error handling.
Bearing in mind that this is somebody who is extremely familiar with both Object Oriented and good coding practises, I realized that there must be an interesting story underlying this.
His response to my query for more info is informative:
Tease all you want — I’ll lean on the weight of nine years of experience at [big company name], where (gasp) gotos were ubiquitous (almost exclusively in error handling code, but still).
To clarify further: I actually wasn’t aware that PHP had a goto statement (see: php.net/goto – they have the nice xkcd cartoon in the comments). I’ve been coding in PHP for a long time.
There’s two methods that I usually use to handle errors in PHP code, in case you’re wondering:
1. Make sure that code that can crash is encapsulated in a nice neat function. Check return values of function calls inside the function. If necessary, stick an “@” before function calls that tend to crash in a messy manner. Then return useful info about the final state from the function itself, and check things out higher up in the stack.
2. Stick try/catch code around code that can crash. If necessary, subclass error classes and put in nice handlers for them.
In both cases, make sure that the error level for reporting is appropriate, and that we don’t output actual error messages back to the end user. Where useful, put in logging, and possibly put in code to email error reports back to admin.
It isn’t well trained yet though, so don’t expect too much.
Their more sophisticed commercial level AIs are pretty good at holding down the fort while all of the sales people are busy. Its an interesting idea. Takes a lot of work to train them though.
I’ve discussed project management recently with a number of people who work in more “traditional” software development issues, where projects tend to be large and involve many people working on a project for long periods of time. They often give me odd looks when I tell them that typically my company has around 20 projects on the go at any point in time, with an average length of well under a month.
Bear in mind that these are actual projects, not “operational” things like supporting existing software or running an SEO campaign.
I’d be interested in discussing how to manage this sort of situation with other people – what to do when all of the traditional project management tools go right out the window; how to avoid stressing out staff by making them switch back and forth between many different tasks etc. What kinds of tools do you use to track large numbers of very short projects (I don’t have hours usually to set up a file in MS Project or other similar tools – I write quick checklists on a notepad and then wander from desk to desk)? Is anyone using agile techniques (especially controversial things like two people per screen)?
I did something completely idiotic this afternoon.
While assisting one of my staff with a problematic installation of some open source software on a server, I decided to clean up certain files that we no longer needed with “rm -r *”.
Only to discover that I was in the wrong directory.
It didn’t help that we had been working directly on that computer for several days.
I was saved from losing a week’s work only by the fact that the backup from the morning was good (you never know with backups). We still lost a few hours of work, but that’s much better than it could have been.
Moral of the story: a) backup even more regularly than you think necessary, b) keep a local copy of your working files, c) don’t use “rm -r *” unless you’ve double checked what it will do.
Image courtesy of "gutter" on Flickr. Creative Commons.
I just spent a chunk of this afternoon fixing up a friend’s website which was hacked. The hacker appears to have gained access through a decade old shopping cart (not in use, just sitting in a folder on the site), and then proceeded to insert obfuscated javascript code into every page on the site (several hundred pages, with the code slighly different on each page).
This is the fifth or sixth site I’ve had to clean up in the past year or so, and its always a painful job – I’m pretty good at spotting code that shouldn’t be in a page, but with a large website it can be hard to be certain that it has been completely fixed. And there’s no guarantee that the original loophole that was exploited has been removed. Even under the best of circumstances, cleaning up this sort of mess is a painstaking process.
The following is intended for web designers who aren’t coders – but who use scripts that they have located on the web. Some intro level programmers might benefit. Experienced web programmers should go directly to the following link and do some review: http://cwe.mitre.org/top25/
1. Be very careful about downloading “free” scripts off the web. Do yourself a favour and scan the code before using it. If it has been obfuscated, or it looks odd, you probably want to avoid using it. You don’t need to be a programmer to get a feel for nefarious code.
2. When putting together a website that has any kind of dynamic functionality – be it javascript, a php script on the back end, or something else – bear in mind Jeremy’s Addendum to Murphy’s Law: Whatever can be hacked, will be hacked. There are a lot of common loopholes that hackers exploit that could be easily avoided by looking at code with a cynical eye and trying to figure out how it can hurt you.
3. Periodically review old websites that you’ve done. Code that used to be fine may no longer be so safe. Also, as you learn from mistakes, you may notice all kinds of things that are dangerous in your code.
4. Its also really worthwhile to look at the Top 25 Dangerous Bugs list, linked above. A periodic review is in order. Speaking of which, I’m adding that to my to do list.
5. Verify ALL inputs to a script. If you think you have verified them, get somebody with a cynical bent to test it. If something is up on the web, it is guaranteed that somebody will try some oddball and highly unexpected inputs just to see if they use your script for their own purposes.
6. Remember at the end of the day that there’s absolutely no such thing as a hacker-proof piece of software or hardware. Make regular backups. Assume you’re going to need them.
I just want to finish with an anecdote.
I used to operate a small hosting company along with some of my other duties at my former company.
One day, one of our servers started broadcasting vast volumes of spam email, to the point that we had to shut down the outgoing email service.
I spent a few hours reading log files, trying to pinpoint what exactly was happening. I finally narrowed it down to a script that had been uploaded a few days prior on one of the client’s accounts.
The script was basically a feeble attempt to try and implement a CMS (content management system). Basically the way it worked was that any GET input to the main script was assumed to be the name of an html fragment file, and was included into the script with no verification whatsoever.
If this means nothing to you, you’ve probably seen websites that have URLs something along these lines: index.php?id=123. The “id=123” part can be parsed out by the script as an input. In this case the links looked like this: index.php?page=contact.html.
The script just assumed that contact.html was a piece of HTML code, and included it in.
It didn’t take long before half the hackers in the world were sending the script stuff like this: index.php?page=path_to_malware_or_spam_script. And our server was running those bits of malware as if they were located locally.
I’m currently working on fixing a mess that somebody else made. They used all the right tools (Zend, MVC pattern etc) but then proceeded to make every possible mistake. In any given situation where a design decision was needed, they made the wrong choice.
The specific issue I’m dealing with is that I need to replace the look of the website with a new “template”. Unfortunately, the original developers didn’t stick to the MVC pattern – there’s presentation layer code in the controllers, and controller code in the html fragment files. Ugly.
So here’s the informal poll:
Struggle on, through wind, snow and hail, until the destination is achieved.
Toss the whole thing in the garbage heap and start anew.
Hire an international hitman to address the culprits directly.
Run, screaming.
I think I already know what Sol is going to say.
Disclaimer: For those without humour: the third option is intended to be mildly funny, somewhat sarcastic, and not even slightly realistic.
![Reblog this post [with Zemanta]](https://i0.wp.com/img.zemanta.com/reblog_e.png?w=790)
