RobSearles is now a .com

I’ve become a bit fed up with this blog.

That is to say I’m not bored of writing it as I do enjoy the writing and when I publish a post I get a great feeling of satisfaction. Nor do I think I should get rid of it and start again, I think some of the stuff I’ve written is quite good. I am, however, a bit fed up with the low number of users reading it. It can be a bit demoralizing at times to spend a good few hours or so crafting (what I would think) is a pretty good blog post only to have only a few people read it.

So I’ve decided to change tack.


Securing CentOS/cPanel with Sudo

I’m primarily a Ubuntu and Debian user, however just bought a new VPS server to hold my company’s clients’ website. For ease of use I chose a cPanel powered VPS which runs on CentOS 5.2

I wanted to secure the setup as much as I could, and one way is to disabled login via root and use the system I’m more familiar with: Sudo. This was slightly more tricky than I thought, but is still relatively painless once the problems have been worked out.

The steps below show how to add a new user (rob) remove any unneeded (for this user) directories, add them into the sudoers list, fix sudo if it is causing you problems, disable root from login in via SSH.


TinyTwit – Polling App for Twitter – Launched!

I am pleased to announce that I have just launched the very first version of my new Twitter Application: TinyTwit.
TinyTwit: tiny polls for Twitter
So what is TinyTwit?

TinyTwit is a way to conduct tiny polls on Twitter. If you want to ask a short question that can have a yes, no or maybe answer then TinyTwit is for you. Simply go to the Create Poll screen and hopefully everything should be pretty obvious.

From my research this is the only in-twitter polling app out there, so it will be interesting to see how it works out.

As said, this is my very first version. I have been hacking away at this in my spare time, so it feels pretty good to get it up and running. However, it is very much in the spirit of “release early, release often” mantra, and there is still loads to do (a decent frontpage wouldn’t go amiss!) Right now I am starting small, and will add new features and try to build traffic up slowly once I know that the system is actually working.

Please try it out, tweet it to your followers and let me know if it works. It would be great to get some feedback, so please register and let me know what you think.

Have fun

What to do with old domains

I am one of those people that are very good at the “ideas” stage, but not necessarily so go at the “completion” stage. You can read that as I get bored easily. I normally have a “great idea”, work around the clock to get it up and running, but within a few days am bored and have another “great idea” which was much better than the previous idea, which I have now become disillusioned with.

This is my curse.

One side effect of this idea-bored-idea-bored pattern of mine is that I now have loads of unused domain names, all sitting there, doing nothing, costing me money. I don’t want to get rid of these because on day I’ll imagine I’ll do something with them, but on the other hand I don’t have any time to do anything with them now.

So What Do I Do?

Well, I have to admit here that I’ve gone to the dark side. I have become a domain parker! Yes, those horrible sites that you some how get to and which list completely unrelated searches to what you were looking for. I hate them. However, there must be a purpose for them – if there wasn’t they wouldn’t exist. They can’t possibly have any purpose for the people visiting them, so they must have some purpose for the people who own them. In other words, they must bring in some kind of revenue.

So I decided to become someone I hate and try out domain parking on one of my domains to see how it goes. The domain name in question is I chose this domain because it is the oldest domain I own (about 11 years!) and it was my first “great idea”. In fact I even managed to get in the papers and on radio because of it. But like all my other “great ideas” I became disillusioned, and moved on.

Most probably rather stupidly!

So here I am, with an old, unused domain name which I don’t have time to do anything with I don’t want to get rid of and is costing me money. So I decide to “park” it. But how do I go about doing that, would I manually have to put it all together, which I don’t have time, or is there a better way out there?

After about have a nano-second of Googling, it turns out that domain parking management is quite big business, and there are loads of companies out there doing it. After reading a few reviews I decided to go with WhyPark. I have to admit, it was pretty easy, in fact effortless. I simply signed up, added my domains, entered some keywords etc, updated my DNS settings, and viola, a brand new parked site:

Yes, it’s awful isn’t it!

But who know, if I can make enough to cover the domain reg costs it’ll be worth it. I’ll let you know how it’s going in a couple of months, so stay tuned (or you can sign up to my RSS feed)

And yes, I now hate myself :)

Some WhyPark reviews:

Increasing Productivity with Gnome’s Tomboy

I have found a new productivity tool, which I find is really help me. Well, OK, I didn’t find it, it was shown to me by a fellow geek. But I have to say it is rather fantastic. So what is it? Well, unless you didn’t read the title to this post you’ll know that it is Tomboy. It’s described as

A simple and easy to use desktop note-taking application.

but I can tell you that whilst it is indeed a note-taking application, and in fact very simple and easy to use, it has bags of power to help organise your life.

How So?

Well, whilst this isn’t going to be an in depth review of any sort, I will instead tell you how it’s been helping me in the productivity arena.

View my Tomboy setup

View my Tomboy setup

For starters it is just so easy to create a new note. If you set it up so you can use Highlighted WikiWords. This instantly creates a link when you write WordsLikeThis to a new, blank note. Simply click on the link and started editing the new note. This doesn’t sound particularly revolutionary in itself, but it is this simple ease-of-use which makes it so powerful.

When you start off with Tomboy there is the “main note” called Start Here. I permanently have this on the right hand side of my desktop, listing the most important things that I must remember or know. If you have al look at the screenshot you can see that I have listed the main clients I’m working on, some reminder todos, meetings (my hospital appointment – I forgot my last one) and some server details I use all the time.

You’ll also see that I have a list of the things I need todo today, in the rather originally named TodaysTodo note.

Tomboy and Getting Things Done

I’ve read David Allen‘s book: Getting Things Done (GTD), and whilst I haven’t followed it too much (I will one day, I promise) I know that it is hugely influential, and a very intelligent system – hmm, why aren’t I using it? In my mind, Tomboy is perfect for GTD where you can have a little list of “@” notes all linking off the main Start Here note. I’m sure you out there will be able to utilise Tomboy far better than I can in a GTD (or note quite so GTD) way.

Note Taking

Tomboy is a note-taking application, so obviously its main purpose in life is to help you take note. But as I have said, it is so damn easy. Gone are the days of faffing about trying to open up Gedit or find a pen and piece of paper. Now I simply right click on the icon, create a new note and start tapping the keyboard in some delightfully haphazard way that resembles the English language. Now I don’t have to use my brain to remember anything ever again!

Other Stuff

Not only does Tomboy offer increased productivity, help you remember stuff and keep your life generally in order, but it also comes with a few extra tools. Firstly there are the plugins, so you can integrate with BugZilla or export as HTML but you can even backup/synchronise your notes to another machine. Also it appears that TomBoy is being actively developed – always a plus.

Anyway, stop listening to me, instead download it, and play around to see if it can help you.


Other blog posts that might help you use Tomboy as a productivity tool:

Rewriting web apps: pros and cons.

I’ve recently been thinking a lot about software rewriting, more specifically rewriting web sites and web apps. The reason for this is that I’m currently working on some code for a client that has transferred me onto their project after getting annoyed with the original developers failing to meet expectations. Without divulging too much, the site I’m working on is a shopping cart application and I was bought on just after launch because of many associated problems with the previous developers.

Now, in my opinion, the code isn’t very good. For starters the output isn’t XHTML compliant using CSS, the display logic is intertwined with the business logic, e.g. there is not template engine (which I’m not a great fan of) functions and patterns are repeated and it isn’t Object Oriented when it seems like an ideal candidate for OOP.

So the dilemma I’m having at the moment is “Should I rewrite from scratch or should I refactor?”

I’m going to let you in on a little secret: I’ve been here before, in a pretty much identical situation, and taking what I’ve learnt from this past experience I’m going to choose to refactor piece by piece. Last time, I chose to rewrite, and this is what happened.

Last time I was asked to make some important additions to an existing code base. However, this codebase was appalling, I could easily do better, I could really make it clean, efficient OO code, reducing the overhead on the server, making the codebase more extensible, producing superb XHTML which can easily be reskinned due to using a template engine produce the output. I just need to plan it out, think about it a bit, seeing how I could incorporate the important additions and rewrite the code and away we go!

Or so I thought.

What I completely forgot about was that I wasn’t re-writing the codebase in a vacuum: this was a live site, which (partly due to the original codebase and partly due to client requests) had to be updated/bug fixed/amended from time to time. Before long I had 2 codebases which both had to be amended to incorporate any new changes submitted by the client. This wasn’t feature creep, this was important changes and bug fixes which had to be done – the manufacture changing product specs, the credit card company being changed etc etc. Very soon I was bogged down by these changes. I spent more time re-planning the new code base to incorporate these changes, and amending the original code base the rewriting wasn’t getting anywhere. The months wore on and I had not released the new site, or made many of the original additions called for at the start of the project. Not surprisingly, the client dropped me. I had become so wrapped up in making the codebase “just utterly fantastic” I lost sight of the bigger picture: This was a real website with real customers and if the new features weren’t implemented the owner would lose business.

What stopped me seeing this was pride. I was far better than the other guys, I could write better, faster, more extendible code – but of course, this isn’t always true and better code isn’t always a better business decision.

I’ve been reading a lot into this at the moment, and I wish I had stumbled across these blogs before I started rewriting the project above.

Kevin Barnes “To rewrite or to not rewrite, that is the question” (ironically what I was going to call my article!)

Chad Fowler “The Big Rewrite”

And of course:

Joel Spolsky “Things You Should Never Do, Part 1”

Thinking about the situation I found myself in with the possibility to rewrite, I had these thoughts in mind:

  1. Is the project mission critical? If the rewrite takes longer than expected, will your client suffer? If they will, think carefully about rewriting
  2. Is the project fluid? I.E. will you have to make changes to the live site which will need to be included into the rewrite? If so be prepared to work on two code bases at the same time?
  3. Will you be able to devote a substantial amount of your time and brain power to the rewrite? This sort of works with point 2. If you either can’t support two code bases at the same time, or you won’t be able to spend the majority of the time on the rewrite then strongly consider not rewriting.
  4. Why are you doing the rewrite? Is it genuinely to improve the code, or is it because you simply think you can do it better? If the latter, or the latter is the majority reason for the rewrite, strongly reconsider the rewrite

All of these pointed me to rejecting my rewrite plan. So, this time, my plan will be different. This time I’m not going to ditch the old code base (even though I really want to). This time I’m going to do it bit by bit. Improving each area that I have to fix a bug for, or make an addition. I’m going to refactor slowly, but carefully.

And most importantly I’ll be keeping in mind the real reason I’m doing this: this site is my client’s lively hood, not my plaything.

Note: This post has been copied from the old website, originally posted on 2007-11-13. See this entry for more details

Do You Know What a Browser is?

What is a browse? A question posed on this YouTube video to 50 passers by of varying ages and backgrounds in New York’s Times Square.

What a stupid question, I initially thought: everyone must know what a browser is. However, their answers made me raise an eyebrow of astonishment and forced me to rethink my preconceptions.

In our ivory tower of professional geek-dom, where we bask in our undiluted view of the interweb, slowly tweaking the knobs of Web2.0, it is easy to forget that not all people know or even care about the inner (or even outer) workings of this beloved world-net-super-highway of ours.
And why should they?

Why should the average user who is merely looking to book themselves a holiday, of catch up with the latest news, or poke someone who they met 5 years ago one drunken night in the suburbs of Sydney, really care what a browser is, let alone which particular one they are using?

To be frank they shouldn’t.

It should be up to us (the people that build sites and web applications) to make the things we build just work, regardless. Even if it means having to cater for some, er, how shall I put this: crappy old browsers. The users don’t know any better, this is what was on their machine and they can’t or won’t understand why a website doesn’t work with it. Now this is not going to be a rant about users being rubbish, or ill-educated in the art of web-fu, or even about the monopolistic practices of a once small dorm-room company stifling both innovation and standards.


Instead this is a quick reminder to us. Stop banging on about how we have to code for multiple implementations of multiple browsers on multiple platforms. The users simply don’t care. All they care about is if it work or not.

If not, they are gone.

Programming is a Little Bit Like Wine Tasting

As many of you know I’m doing a part time degree course (Politics, Philosophy and History) as well as being a self employerd web developer. One of the best things about this course is that I can go to extra lectures which complement the course. A couple of weeks ago I had the pleasure of going to one of these extra lectures, “The Philosophy of Wine Tasting” by Barry Smith. I must say, it was fantastic. I’ve never really thought about wine tasting before but this lecture was so interesting and Barry was so passionate and eloquent about his subject, I ended up wanting to buy a vineyard.

Incidentally, Barry has just brought out a new book, which you can get from Amazon (I have, perfect Christmas present for my Dad!)

During the lecture Barry took us through the journey of a wine tasting, contrasting the difference between a novice (like me) and an expert. A novice finds a nice bottle of wine, likes it – it works for them – and that’s kind of it, thinks that all this “it smells of blueberry leaves” is a load of crap. Whereas the expert goes beyond their personal preference and analyses the multitude of components the wine has. The grape, the age, the weather, the process, even the earth, the people and history that all go into making the wine what it is. This started me thinking. Now, I’m a bit of a geek and pretty addicted to my job of coding. And I began thinking:

Wine tasting is a little bit like programming

Now run with me on this one.

When you first start, you’re a novice. You’re looking around for what you like, and when it works, you’re pretty pleased with yourself (at least, I was/am). But there is no background to it.

When I first started programming, I was one of those copy/paste kids that wasn’t quite sure why it worked, but it did, and I was pretty pleased with myself. This is like most people. They have no idea how or why Google works, or Word, or email, it just does. At the same time, people aren’t quite sure why they like a nice bottle of Jacobs Creek, any concept of what’s gone behind it, the effort put in.

But then people start to get more interested, start asking how it works, or why it tastes like it does. Then they get hooked. At this stage most people really go for it. They buy countless books, they read hundreds of articles, but most of all, they start to try out lots of new things. First they start with the foundation, either the language: Ruby, Java, PHP, C#, or the grape: Chardonnay, Cabernet Sauvignon, Pinot Gris and Noir. Each of these have different philosophies, concepts – call it methodologies, behind them. Dabble in these, test them out, see what works for them, try them out for size, for example OOP or “under ripening the grape”.

By now, an appreciation is being formed. Irrelevant of whether you like it or not, you can distance yourself from the actual “flavour”, but instead focus on the inner working of the code, or the wine. You can come to appreciate a well made wine, or well structured code. But also you can come to appreciate the history gone into producing the product in front of you. The age of the vine, the good summer it had a decade ago, or the frost suffered last year, the problems faced by people using the language, the particular itches that had to be scratched, experiences gained from other projects. Once you’ve truly immersed yourself for a few years you can come to appreciate the nuances, the culture, for want of a better word, the soul of a language or of a wine.

At this point, go for it, taste everything, try everything, become an expert. Know the most obscure syntax or date and time functions, know that if you have a cheap bottle of bubbly you can make it taste like the most expensive champagne you’ve ever tasted by complementing it with a little slice of Parmesan cheese on the side. There is so much out there to find out, to sample and to learn.

I have to admit, I love it. I love wine and I love programming. But the most important thought that struck me during this lecture was this: both the best wine in the world and the best programming most likely originate from the garage or shed of someone who is truly passionate about what they are doing.

Note: This post has been copied from the old website, originally posted on 2007-11-27. See this entry for more details

PHP5: Fake Method Overloading

Been struggling for the past hour or so with method overloading within objects, so I thought I’d write a little not on my blog to hopefully help others and to remind myself.

The premise for this is that I was writing a new database wrapper class to speed up the rather rubbish database module I have been using previously. My plan was to encapsulate all my methods in the wrapper (such as get_table_name() etc) in my class then all others fire off to the ADODB class by PHPlens. My plan was to do this with method overloading, such as:

public function __call($m, $a) {
return $this->db->$m($a);
throw new Exception('Tried to call unknown method '.get_class($this->db).'::'.$m);

However, PHP5 doesn’t seem to support that, which is irritating. After some search on the web I find out that PHP5 doesn’t support real overloading.

So after much effort and searching the web and docs I decide to use the call_user_func_array(&obj) technique.

Finished method below:

public function __call($m, $a) {
// check the method being called exists
if (method_exists($this->db, $m)) {
return call_user_func_array(array(&$this->db, $m), $a);
else {
throw new Exception('Tried to call unknown method '.get_class($this->db).'::'.$m);

Seems to work, so please feel free to use

Note: This post has been copied from the old website, originally posted on 2007-07-04. See this entry for more details

Top 7 Tips for Successfully Outsourcing Development

As a self-employed web developer I’ve had numerous experiences over the years outsourcing work to other providers. This is the option I turn to when a relatively “simple” clearly defined project comes in that I’m either too busy to take on myself, or I don’t want to be distracted from a larger, more complex project. I have also hired a number of single outsource developers to work as a “team member” where we both work on the same project together and tackle things in a much more fluid way. Like most experiences, sometimes it’s worked, and other times it hasn’t, also some of the providers have been great, some have been simply awful. This post is about what I have learned from experience.

1. Communication

The number one most important tip I can offer is that you must have a good line of communication with the provider. If you are outsourcing a single project, make sure that it is as fully spec’d as possible, with clearly defined goals and timescales. Also, make sure the provider agrees to the spec and that they fully understand what is entailed. If you are working on a more fluid, lengthier project you must stay in touch with the provider as much as possible. Obviously if you are working in different time zones I’m not suggesting that you should switch to using their clock, but the provider needs to know when you will be on line, how they can contact you if there is a problem/question etc. Instant messaging, email, Skype and wikis are all valid means of communication, each with a specific job, and I strongly suggest that you use as many of these lines of communication as you feel comfortable with, or that the project entails.

  • Instant Messaging
    This is the number one tool for day to day communication. You should always have your Instant messenger fired up and online so if there the provider needs to ask a quick question, they can easily get in touch
  • E-mail
    If a question is too complex for a quick IM, email should be used to outline the problem and also record the decided solution. Email should definitely be used to make statements about the project, timescales, methodology and anything else that needs to have a record kept.
  • Skype (VOIP)
    Sometimes confusion can arise within IM and email. This is especially true if your provider is from another country and does not necessarily speak the same language, or understand the same cultural nuances as you. I can remember with one provider once insulting him over IM because he wasn’t as indoctrinated with the British sarcastic sense of humour as I am. If this is the case, sometimes actually speaking, so the tone of voice can be heard, goes a long way to facilitate communication.
  • Wikis
    I find I’m using wikis more and more when dealing with outsourcing. I find they are invaluable when spec’ing out projects, detailing any changes and also documenting coding guidelines, stating reasons for why the code is as it is. Wikis are also a handy place for the provider to find any links to staging severs, get access to SVN etc. In return the provider can outline the structure of their code and explain why they have done things in a certain way etc.

2. Clearly Defined Expected Outcome

This relates heavily to point 1, but it is absolutely imperative that you have a clearly stated outcome you are working towards, including expected timescales or date of completion. I have found if there aren’t clearly defined expected outcomes, regardless of whether it is a single project, or a “team member” type scenario, the provider doesn’t have anything to aim at. If there is no outcome to aim for none of the functionality will ever get properly written. And, if there is no timescale agreed, there is no urgency to get anything done!

3. Clearly Defined Methodology

As well as having good communication with clearly defined expected outcomes I have found it is imperative to have a clearly defined methodology. This may be as simple as “please email me at the end of the day with a progress report” or be as complex as instructing the provider to always use your online collaboration suite and submitting to the Version Control System for the nightly build. Which methodology you choose to use really depends on how mission critical your project is. Whatever methodology you do use, it is important to define this from day one, as it is very easy to get into a habit, but impossibly hard to break one.

4. Have Good Tools

This is linking in a little bit with point 3. It’s necessary to have good tools with which to implement your chosen methodology. It is also important (critical in fact) that your provider knows how to utilise the tools. One (very irritating) time I noticed that a provider I had just hired promised that he knew all about Subversion, but was downloading, file by file, the entire code base from the browser, and not with an SVN client like TortoiseSVN. Needless to say, he didn’t last long.

These tools should include, in my opinion, at a minimum a version control system and bug tracking software. I am a big fan of Trac but I don’t know if that is just me coming from an Open Source mentality. Also, as I think it is brilliant, I recommend Mantis as a bug tracker if you don’t want to get as complicated as Trac or BugZilla. Damn, that means I also must mention FogBugz, but enough – on to point 5.

5. Treat your Provider with Respect

This isn’t just about being polite, which of course is an absolute must, but is really about trusting your provider to be able to actually work on your project without you having to hold their hand and check up on them every 5 minutes. Yes you should always be there if they need help or have a question, after all they aren’t as up-to-speed on your project as you are in the beginning. However, trusting your provider and treating them with a little programming respect will not be as hard if you heed point 6.

6. Find the right provider for the job

One of my first mistakes when outsourcing work was to just hire the first provider that came along and said they could do the job. Every provider I have since found out says they can do the job, but it really depends how well you want the job done. The more providers I used, the more I realised that getting a provider is really like finding someone to employ. You want to get the right person for the job. Also, a big mistake I made was thinking that a bigger price equals a better provider; this is not always the case. So when you are looking for a provider, ask to look at some example work and some of the code that makes it work. Maybe even give them a little test. You want to make sure you get the right provider after all…

7. Don’t forget, it’s your money

This might seem a stupid point, obviously it’s your money (it may be your client’s money eventually, but you will still have to pay for it first). As it is your money, if you feel unhappy, or are not confident the provider can do what they said they can do, or complete the project, don’t waste your money and your time. There are a hell of a lot of providers out there, you can find someone you are confident with and who can complete the project. When I first started using outsourcers I was often too nice, I helped them out and was very communicative, all good. However, with some of them I realised I was doing more explaining and helping out than the provider was coding. I had to keep on referring them to the coding standards I wanted them to adhere to, or the function spec I had written for them. After a while I twigged that this was costing me money. If the provider cannot do what you are asking, find someone who can. Nevertheless, saying that, if you find a provider that keeps getting it right, doing what you are asking and in the timeframes you’ve requested – hang on to them, they will help your business invaluably!

Note: This post has been copied from the old website, originally posted on 2007-11-15 . See this entry for more details