Blog

Building a Bespoke Random Number Generator

Posted on Friday 19th October 2012 at 16:22
My girlfriend is a teacher, and often, when she is producing material for her maths lessons, she will ask me to think up a random number for her. This is pretty easy when she needs one or two, but it gets a little more difficult when she decides she needs 20 or 30, especially if they have restrictions on them, such as they must be able to be divided by 10, they must be 4 digits long or they must have 2 decimal places.

So in the end, I decided it'd be quicker and easier for me to just make her a random number generator webapp using HTML5 and PHP. The most basic version took me about 20 minutes to build, and in total I've spent about 2 hours on the final version, which you can have a play with here. It's not exactly the world's most complicated project, but I learnt one or two things from it, so I thought I'd write it up and share the knowledge.

Getting Started

I began by creating a simple HTML form with two input fields, one for the number of numbers to be generated, and the other for the number of digits long that each number should be. The form posts to itself, at which point we have two PHP operations to perform. The first one is to transform the number of digits required into a minimum and a maximum for the random number generator, and the second is loop for as many numbers as are required, generate a random number that meets the parameters each time, and then echo the number back to the browser. Together they look like this:
// Set the minimum possible number with the correct number of digits

$zeros = $_POST['digits']-1; // The number of zeros required, e.g. 100 has 2 zeros

$min = pow(10, $zeros); // 10 to the power of $zeros, e.g. 10^2 = 100



// Set the maximum possible number with the correct number of digits



$max = pow(10, $_POST['digits']);

$max--; // Minus 1, e.g Maximum 3 digit number is 999; 10^3 = 1000-1 = 999



// Cycle through as many iterations as are required



for ($i = 1; $i<= $_POST['results']; $i++) {

$number = mt_rand($min, $max); // Random number generator with assigned minimum and maximums

echo $number;

}





So far, so simple.

Adding Decimals

Next we want to be able to add a set number of digits after the point. It's entirely possible that there is a simple way of doing this that PHP Maths experts know (if you know of one, please comment and let me know!), but the best solution I could come up with was to repeat the above process to generate a second random number, and then join the two numbers together as a string with a decimal point between them:
// Generate decimal and join them together

$decimal = mt_rand($dec_min, $dec_max);

$number = $number.".".$decimal;

}





Setting Intervals

Since this tool is designed to produce random numbers for use in maths lessons, the final requirement I needed to build in  was the ability to set intervals in the "random" numbers, for example, we might want to generate numbers that only end in 5 or 0, or we might only want numbers in 3 times table. Once again, I wasn't aware of a very good way of doing this, so I had to improvise a little bit.

First, I created an array listing the first 20 numbers that fitted the rule. Then, when the random numbers were being generated, I used a regular expression match to determine if the numbers being generated fitted the required rule, before outputting them.
// Produce an array of number endings that fit the required interval pattern



$interval = $_POST['interval'];

$intervals = array();

for ($i = 1; $i<= 20; $i++) {

array_push($intervals, $interval*$i);

}





// Create a regular expression pattern from the array



$pattern = implode("|", $intervals);

$pattern = "/(".$pattern.")$/"; // Checks if the end of the generated number matches one of the pattern options





// Whilst loop is running, check randomly generated number against the pattern



if(!preg_match($pattern, $number)) {

// If pattern match fails, reduce the cycle count by 1 and then begin the next loop.

$i--;

continue;

}




Conclusion


This is a simple tool with a very limited range of useful functions, but for what it is designed to do, it is far quicker and easier than working out numbers by hand. The tool took a couple of hours to perfect, which means that if I were building it commercially, it'd be a pretty cheap investment for any size of business, which, if used by enough people within an organisation for long enough, could begin to save many valuable man hours.

This is just one example of how a webapp can seriously speed up business admin or other routine tasks. There are loads of others, and I hope that in the future, many more businesses will be looking for ways to speed up the work their employees do.



You can try the tool here.

0 Comments

Creating an API with JSON

Posted on Friday 7th September 2012 at 15:53
I was recently asked to build an API to allow a mobile app to interact with a website. Since this isn't something I've been asked to do before and since most web developers don't list it amongst their skills, I thought I'd write up the process I went through, in the hope that it's useful to someone else. 


I do my server side scripting in PHP like a lot of developers, so I shall describe the process from a PHP perspective. If what I'm saying doesn't tie in with your chosen language then I apologise.


What exactly is an API?

An API (Application Programming Interface) is a method of allowing separate systems to talk to each other, for example a website and a app, or two separate servers. One of the best usage examples from recent times is Twitter, whose API allows a wide range of mobile and desktop apps, built by 3rd party developers, to access and update the Twitter systems.

The reason that APIs are so important is that they allow you to give a user access to data on your server, but in a way that you specify and can control. The alternative would be to allow users direct server access, which is about as safe as leaving your house unlocked, with a sign on the door telling passers by that you won't be back for a month and they can help themselves.



How do you build one?

Put simply, building an API is very similar to building a dynamic website. You receive a request with parameters from a client, you run a database query for the information they need (or to post information, if required) and then you use code to format the data that's returned to the client via the HTTP or HTTPS protocol. The only real difference is that instead of returning the data wrapped up in HTML, you wrap it up in XML or JSON instead. It's also necessary to set the header information being returned to state that you're returning XML or JSON rather than HTML or something completely different, so that the client system is aware of what it is processing.

One thing to note is that, whilst most web browsers are pretty good at interpreting poorly formatted HTML, the chances are the client system that is processing your output will be unable to handle invalid code, so make sure you validate everything that will ever get returned to the client. Personally I recommend JSONLint for JSON validation.




XML or JSON?

When you build your API, you can choose to write the output in XML or JSON. XML (Extensible Markup Language) will be familiar to anyone who has ever worked on an RSS feed before. It looks a little bit like HTML, but it deals entirely with content, and isn't parsed by a web browser (unless it has been set up with an RSS reader). JSON (JavaScript Object Notation) is designed to be easily readable by humans, as well as by JavaScript, although it is language independent. The main argument in favour of JSON over XML is that the syntax is a hell of a lot simpler, which makes it very easy to write. I'm sure there are other arguments for or against it that more experienced developers could tell you about,  but that was the one that won me over.

There are just 6 data types in JSON: string, number, boolean, array, object and null. If you're reading this then you should know what each of those are already and how they work, each one behaves pretty much the same way they do in PHP, although the syntax for objects and arrays is different (see below).

JSON always starts with a { and ends with a }. Pretty much everything else is name : value pairs, which is why it's so simple.



Building your JSON

The first thing to do is set the header information. In PHP, this can be done with the following command:
header("Content-type: application/json");

After this, you are free to launch straight into your data return by echoing name : value pairs, but if, like me, you find this approach a little heartless, you can do what I do and add a little sanity checker to the start of output, so that the client (whether human or machine) can check that they're going to get what they're expecting:
{
	"api":


{


"name": "Test API",


"status": "OK",


"version": 1.1,


"query":


{


"id": "5",


"limit": "500",


"results": 173


}

What you see above is a JSON object called "api". JSON objects look a little like name : value pairs, except that the value half starts with { and ends with } instead of double quotes, and contains a series of name : value pairs, rather than a single string, number or boolean. N.B. The names and values in JSON are always contains in double quotes ("), not single ones ('). The API "name" is there simply because the project in question required several APIs to be built. "Status" reflects whether the database query was completed successfully or not and "version" is used so that the client app being built knows which version of the API is being served, should significant changes be made to the structure over time.

As you may have guessed, "query" is another object (yes, you can nest objects (and arrays) inside objects), this time containing the parameter settings that were received by the API from the client. "Results" shows the number of rows returned by the query.

Next up, we start returning the data:
"jobs":
	[


{


"job_id": 1176,


"job_title": "Office Assistant",


"job_ref": 12012,


"job_type": "Temporary",


"job_date": "2012-07-22",


"job_duration": "Ongoing",


"job_positions": 1,


"job_skills": "Personnel must hold valid qualifications",


"job_duties": "Making tea, answering the phones, ordering stationary etc",


"job_dateadded": "2011-09-07 10:15:02",


},


{


"job_id": 1710,


"job_title": "Chief Executive Officer",


"job_ref": 124,


"job_type": "Permanent",


"job_date": "2012-08-01",


"job_duration": "Permanent",


"job_positions": 1,


"job_skills": "Must have run a major multinational before<br />Able to go on the radio and lie about turnover figures<br /><br />Happy to appear at public enquires",


"job_duties": "Smiling lots, shaking hands, chairing meetings, sitting in a swivel chair, ordering people to do stuff",


"job_dateadded": "2012-01-18 10:15:18",
},


...

Our API contains details of job adverts, so to list them, we've created an array called "jobs". In JSON, arrays can be used to contain a group of objects, with each object representing one item in the array. The array is wrapped in square brackets ([]), with each object then appearing in the usual {} and separated by commas (,). N.B. Individual objects within the array do not need to be named, as the array key will be automatically generated when the JSON is parsed by the client.

In the interest of simplicity, I prefer to make the name half of the name : value pairs match the corresponding database field name. This isn't strictly necessary, but it can be a great help when debugging the code.

It's worth noting the use of <br /> in the "job_skills" field. JSON will not validate if actual line breaks appear within a value, so it is important to strip these out and replace them with something that won't cause any upset (such as <br />). (Edit: Will Earp has pointed me to this forum post that points out that line breaks can be escaped by replacing \r with \n and escaping \n with \\n. Will assures me that json_encode() does this for you. Cheers Will.) Whilst you are at it, JSON also gets upset by many special characters, so I'd recommend locking down the data being inputted as thoroughly as you can. I used the following regular expression to strip out unwanted characters:
preg_replace("/[^A-z0-9/.-!"?$%^&*()_[]{}+?|@',:;<> ]/", "", nl2br($data));

Needless to say, this isn't a comprehensive guide on building APIs with JSON, but hopefully it'll give you an idea of where to start. If you are having trouble with your API and need advice, or would like to outsource the process altogether, please don't hesitate to contact me. In case you need to check it, the complete API output for our example looks like this:
{
	"api":


     {


"name": "Test API",


"status": "OK",


"version": 1.1,


"query":


{


"id": "5",


"limit": "500",


"results": 173


},


"jobs":
	[


{


"job_id": 1176,


"job_title": "Office Assistant",


"job_ref": 12012,


"job_type": "Temporary",


"job_date": "2012-07-22",


"job_duration": "Ongoing",


"job_positions": 1,


"job_skills": "Personnel must hold valid qualifications",


"job_duties": "Making tea, answering the phones, ordering stationary etc",


"job_dateadded": "2011-09-07 10:15:02",


},


{


"job_id": 1710,


"job_title": "Chief Executive Officer",


"job_ref": 124,


"job_type": "Permanent",


"job_date": "2012-08-01",


"job_duration": "Permanent",


"job_positions": 1,


"job_skills": "Must have run a major multinational before<br />Able to go on the radio and lie about turnover figures<br /><br />Happy to appear at public enquires",


"job_duties": "Smiling lots, shaking hands, chairing meetings, sitting in a swivel chair, ordering people to do stuff",


"job_dateadded": "2012-01-18 10:15:18",
}


     ]

Edit: As Will Earp has reminded me, there is a PHP function that can turn an array into a set of name : value pairs, called json_encode(). This can dramatically speed up the coding process, as you won't need to manually write out any of the JSON. My reasons for giving you the manual method are firstly, because I've not used json_encode(), so can't talk with any authority on it yet and secondly, because you'll have a much better understanding of the use of JSON itself if you learn to code it by hand first. Afterwards you should be able to make a judgement call on which method will best serve the needs of any given project.

0 Comments

A Change of Focus

Posted on Thursday 31st May 2012 at 11:41
In my last post I talked about the difficulties I was having with branding MRG Web Development in a way that attracted clients. I received a lot of feedback from a large number of brilliant and helpful people and have since done a lot of thinking about my strategy going forward.

The conclusion to all this has been a slight change of focus. I still intend to do everything that I did before, but rather than focus on services for end user business clients, I'm going to aim to market myself towards other web designers and developers.

As I say, this is a change of focus, not of direction. If you are not a professional in the web industry but want a website, I shall be very happy to build you one. The difference for you is that you'll know me from now on as you probably always should have done, as Mark Glover. I am, as we speak, creating a new section to my other website (http://markglover.co.uk) specifically aimed at small business customers, with a more personal, friendly tone.

Meanwhile, this website will be redesigned to cater for my techie clients. Things are going to get pretty geeky around here, I can tell you. The information on the services I offer will be rewritten with all the jargon put back in, and this blog will be aimed at developers, with posts about technical problems I've encountered and commentary on changes in the industry.

As with business clients, I'm going to be a lot more personal. No more "we" when I mean "I". I am in business, but my business is freelancing, at least until I grow it enough to need to take on staff.

Far from feeling like my hand has been forced, I'm actually rather excited about the changes. Talking geek with other techie types is much more my style than popularist, every day articles for users who don't share my love of technology.

I look forward to introducing myself to you as me, not my company from here on in :-)

0 Comments

The Difficulties of Branding for the Self Employed

Posted on Monday 28th May 2012 at 16:35
For me, one of the hardest aspects of starting out as a self-employed person is branding. Even working out whether to describe myself as a self-employed person, a freelancer or a small business owner has provided strangely challenging.

There isn't really any technical difference between calling yourself a freelancer or self-employed. Small business owner is a little vaguer, as it suggests that you may have employees, but the term is equally applicable for someone by themselves. A one person business is still a business after all.

You might argue that it doesn't matter, but to me it seems crucial in determining the impression that you give to potential clients. I've often wondered whether freelance denotes free and easy, hard to pin down, not really committed to the work; hardly the message you wish to put across to the client. Hiding behind the façade of a business name and logo certainly feels more professional, but is it actually colder, more distant, less accessible?

When I first started up, 18 months ago, I sort of fell into the role. I didn't know whether what I was doing was temporary or permanent, a small operation or something bigger. To tell the truth, I still don't. I started out by marketing myself as a freelancer. Just Mark R Glover the freelance web developer. Nice and simple, no strings attached.

At first, that seemed to work well. It was all very personable, one to one, smiles all round. But all my clients were small, and, dare I say it, a little bit cheap. For some reason, being a freelancer seemed to attract the sort of client who was after £2,000 or £3,000 of work, but only willing to write a cheque for £200-300.

I didn't and still don't want clients like that. I am adamant that good web development is a highly specialist professional skill and that prices should reflect that. The cheaper the work, the less time and attention we can give it, and nobody benefits from that. Not us, not our clients and certainly not the end users.

So, I changed strategy. I got myself a business name and a logo and attempted to look increasingly solid and reliable, with the hope of attracting bigger business clients with bigger budgets, who could afford to pay me for the sort of high quality work that I wish to do.

Unfortunately, the longer I have pushed this business identity, the fewer new enquiries I've had, and gradually this has led to less and less work. I'm sure that there are other inadequacies in my marketing techniques, but the only thing that I could be worse at is branding.

I'm forced to conclude therefore that either my business branding is wrong in some way and has killed my appeal with clients, or I have somehow replaced a strong personal brand with a much weaker, less confident and less well defined business brand.

I find myself returning to the drawing board once again and trying to decide what to do. Either I need to ditch the business name and everything that I've put into it and go back to being Mark the freelancer, or I need to try and understand why my business branding, which after all is for exactly the same product, doesn't inspire people to engage my services.

And no, for the record, 9 years of studying business academically has not been helpful in allowing me to solve this problem. Branding is something you have to feel.

0 Comments

Joining The Mobile Web

Posted on Thursday 24th May 2012 at 08:49
You don't have to look far to find statistics about the growth of web browsing on mobile phones. It's now a well accepted fact that the number of people using mobiles and tablets for their browsing is set to overtake the number using computers some time in the next few years. But for this to happen successfully, the whole way much of the web is designed is going to have to change, and that includes your website.

For at least the last 10 years, many of us have been aware of the concept of websites for mobiles. Back then, we were talking about WAP, a specific, separate part of the internet, where formless, text based pages could be delivered to small screens very slowly and at great expense to users.

The arrival of the iPhone changed all that. Here was a device with a fully functional web browser (minus the Flash plugin) that not only could load and process full websites, but could also be relied upon to bring along enough users to make mobile websites a worthwhile proposition for any of us.

This should have been the point that websites designed around mobiles became the norm, but it wasn't, for two reasons:

Firstly, the mobile version of Safari (and, later, the browser for Android) were built to be able to process web pages designed for desktops and to display them in the same way, albeit at greatly reduced size. This required sophisticated page zoom techniques and rather more processing power than is ideal on a handheld device, but it worked. You and I looked at smartphone users zooming in on our pages and struggling to tap the correct links on our menus, and decided that that would be fine.

Secondly, shortly after the arrival of the iPhone, Apple introduced the App store. Business owners rejoiced. Now we could fork out for expensive mobile specific development and perhaps even charge the user for accessing it.

It was the Financial Times that changed everything.

Being financy, they realised that paying lots of money for a website and then paying lots of money for an iPhone app and then paying lots of money for an Android app and then paying lots of money for a Blackberry app was proving to be a strain on their development budget. They decided on a new, more efficient way. They weren't going to develop all these apps any more, they were going to have a specifically designed, browser based, webapp that would work across all smartphones and be easy to use on each of them, as well as a full website for desktop and laptop users.

Now this may seem equally expensive, but it isn't.

Thanks to a design technique known as Responsive Web Design, it is possible for your website to adjust its size, layout and design to suit the device it is being viewed on. This means that the same content can automatically look equally at home on a smartphone, a tablet and a PC or Mac, without you needing to pay to have extra versions developed for each platform.

With the seemingly unstoppable rise in alternative devices for accessing and browsing your website, this is undoubtedly the way that you can keep audiences enjoying what you have to offer, without having to spend a fortune producing new versions of your site, every time a manufacturer brings out a new phone or other gadget.

The point is that users expect websites to be easy to navigate and use. Sooner or later, they will expect your website to be easy to use on their phone and tablet, as well as their PC. If it isn't, they'll take their business elsewhere. Take action now to avoid losing business in the near future.

0 Comments

Google Chrome is the World's Most Popular Web Browser (and why you should care)

Posted on Sunday 20th May 2012 at 17:46
According to Statcounter.com (http://gs.statcounter.com/#browser-ww-weekly-201120-201220), this week, for the first time ever, Google Chrome overtook Microsoft's Internet Explorer to become the world's most popular web browser. This is a far more important (and exciting) development than an article about browser statistics might at first suggest.

Since the 1990's Internet Explorer has held a dominant position in the browser market. For most of that time, this has allowed Microsoft to dictate how websites have evolved, as everyone was required to build sites to run almost exclusively on Internet Explorer.

This was a bad thing, as, comfortable with their market share, the code engineers at Microsoft became extremely sloppy, building a browser that was slow, poorly thought through and not compliant with the official standards to which all websites and browsers are meant to comply to ensure consistency.

Then, around 5 or 6 years ago, competition began to appear, first from Firefox and then from Chrome. Both browsers were significantly better designed than Internet Explorer and gradually became far more standards compliant. As their market share grew, Microsoft were forced to start improving their browser in order to keep up with the competition.

For this reason, Internet Explorer 9 is much better than any previous version, and quite a bit faster too, which is good for developers and good for users, who don't want to waste precious seconds waiting for their pages to load.

Now that Google Chrome is in the lead, Microsoft will have to work even harder to catch up and those users who've made the switch to Chrome will be able to enjoy the fastest browsing experience currently available. For web developers, this means that they can take advantage of the new standards that Chrome supports to build better, more user friendly websites, without having to worry quite so much about the Internet Explorer users who can't enjoy the advances in the technology.

This may seem like a small step on a long road, and it is, but it's also a mile stone on the journey to making the web and all websites better for all of us, and, surely, that's no bad thing.

0 Comments

What is a CMS (Content Management System) and Why Do I Want One?

Posted on Friday 11th May 2012 at 09:32
If you are looking for someone to build you a new website, you'll probably have noticed the phrase Content Management System or its acronym CMS appearing on websites and in literature from web developers, including here at MRG Web Development. But what is a CMS, and why would you want one?

To answer that, we need to go back in time to the days before content management systems existed and examine the problem that they were invented to solve. In the early days of the web, each webpage you looked at was stored as a separate file on the server of the person who owned the website. These pages were written in HyperText Markup Language (or HTML as it is known), and plain text. To change the content of a web page, you had to login to the server, download the file for the page you wanted to edit, make changes to the text and corresponding HTML and then upload the file back to the server.

There were a number of drawbacks to this approach: it was very slow, the person making the changes needed to know HTML, a mistake in the syntax could break the entire page and you had to give out your server security details to anyone who was to contribute to the website - a major security risk.

Content Management Systems changed all that. Now, the content of a web page was no longer stored in files on the server but safely inside a database. Web developers were able to develop special, secure web pages where the person responsible for editing the content of the website could do so by filling in forms, without needing to know any HTML and without the ability to damage the rest of the website.

It's now a good many years since the first CMS appeared, and today there are a wide range of different systems available for different purposes. Each one is designed to make it as easy as possible for users to edit text and pictures, add pages and make many other changes quickly, without training and without having to worry about breaking anything.

If your website has a CMS, you are no longer reliant on the website's architect to make changes for you, and nor do you require special software or a specific computer. The CMS is part of the website, and, like the rest of your site, it can be accessed from any computer, laptop, tablet or mobile phone with an internet connection, anywhere in the world.

Most content management systems (including our own Dominion CMS) allow you to create password protected accounts for multiple users and monitor who does what to the content of the website, giving you security and the ability to supervise changes, whether they be by a single user or a whole team of editors.

In the past, a CMS was a costly addition that was only worth considering for the websites of large organisations, but today I'd strongly recommend having one on any website, large or small. So next time you are looking at what a web developer is offering you, make sure you keep an eye out for that popular little acronym, CMS.

0 Comments

How to Approach Commissioning a Website or Web Project

Posted on Friday 23rd March 2012 at 09:07
In my last post I talked about ways and means of finding a web developer. Now I'm going to address the next step, which is the process of actually approaching a developer with a project and going through the commissioning process in a way that will make the rest of the project run smoothly.

So, you've chosen the developer you wish to use, you've contacted them to arrange a meeting and now you are about to meet with them for the first time to discuss your exciting project ideal. What do you need?

  1. A Positive Attitude


    By and large, web developers are passionate about what they do. They love the creative process of designing and building websites and they love meeting with clients and embarking on the long journey of a new web project together. What they don't love is clients who are uninterested, cynical and unwilling to contribute their time and ideas to the project. Websites aren't commodities that you can pick up from a shelf in a supermarket. They aren't generic. They are complex, individualistic entities that require a great deal of understanding of the purpose for which they are being built and creative enthusiasm from everyone involved.


  2. A List of Requirements


    I might be exaggerating slightly if I suggest that websites are all as unique as snow flakes or finger prints. They aren't. There are a lot of copy cat websites out there. But that doesn't mean that every website is the same. There are many different things that a website can be, and you won't be doing yourself or your developer any favours if you don't have a clear idea of what you need your website to be able to do. You won't be expected to know every detail of every feature, that is something your developer will work on with you. You will be expected to know what sort of information the site will contain, roughly how many pages you think you'll need, whether you want a picture gallery anywhere, or a contact form. Start thinking of these things in advance and the meeting will be far more productive.


  3. Brand Guidelines


    If you are commissioning a website for an existing business or organisation with an existing identity, your developer will need to understand that brand identity as soon as possible. The image of your organisation determines everything from the colours on your site to the wording on your menus. For the website to work, it must "feel" like a part of the organisation it represents.


  4. Realistic Expectations


    This relates a little to the specification of the site, but even more so to the time scale and cost of the project. Modern websites are complex creatures. As a result, they often take some time to build and will therefore cost a lot. Please don't contact your developer and expect them to deliver the finished website to you by the end of the week. It isn't going to happen. For a start, most web developers keep several projects on the go at any one time. This means that they may not actually be able to start work on your project for two or three weeks, or even longer, if they are really busy. Make sure you ask them for an indication of how long they think it will take and be upfront and honest about any deadlines you have to meet, so they can tell if what you want is realistic or not. Similarly, make sure you approach the project with a realistic budget. Web developers are highly skilled professionals and as a result charge professional rates. My standard rate of work is £40 per hour and the majority of websites I build take between 25 and 100 hours to complete. That means that most projects are going to require a budget of between £1000 and £4000 to be completed satisfactorily. Don't approach your developer with a budget of £200 and an idea for a site that makes Facebook look small scale. You won't get your project off to a good start and you're likely to offend the person you wish to work for you.


  5. Understand The Problem


    Almost all websites exist to solve a problem, so make sure you understand what that problem is. It might be as simple as your customers needing more information about your business, or it might be that you are struggling to time track and invoice the work you do effectively and need a web based system to manage it for you. Whatever the problem is, make sure you understand it, so that you can communicate it to the developer. They need to have a thorough understanding of the situation if they are to come up with a good solution.


During the meeting, your developer will probe you for more details as they try to build a picture in their minds of what you need and how to go about doing it. They may make lists of features or draw little layout diagrams. They may discuss hosting options with you, visual details and content management systems.

This is a two way process. You should take this opportunity to ask questions of your own. You might not understand all the details of web development, but make sure you understand enough to feel comfortable about what will happen and when.

You should leave the meeting with a clear understanding of what the course of action will be, what you expect from the developer and what they expect from you.This way you should find yourself at the beginning of an exciting journey, not a commissioning nightmare.

0 Comments

How to Find a Web Developer

Posted on Monday 5th March 2012 at 17:09
Finding a web developer is a tricky business. The relationship you form with them will, at the very least, have to last the duration of your project, and ideally should last for as long as any and every project that you've commissioned from them remains live.

This requires a great deal of trust and mutual understanding. If you can't see eye to eye with them, how can you be sure that they are going to do the work you need them to do, and at a reasonable price? How can they be sure that you are going to pay them and deliver the things that they need to get the job done?

Here are a few top tips to help you find a Great web developer:


  1. Word of Mouth


    Personal recommendation is the single best way to find a web developer. If someone you know and trust has a website, find out who built it for them and if they'd recommend that person or not. No one can give you an insight into the service a developer provides like an existing client.



  2. Social Media


    If no one you know personally can recommend a web developer, try reaching out to your wider network of contacts, via social media. Linkedin is popular amongst professionals and web developers will often have recommendations from people who commissioned them or worked with them on their profile. Twitter is another great source of recommendations as everyone is always willing to answer a question quickly and concisely. If you haven't tried it yet, I'd also suggest Google Plus (http://plus.google.com), as it is mostly inhabited by computer geeks at the moment, so there are lots of developers on there.



  3. Websites You Like


    If you come across a website you like, take a look at the bottom of the page (the footer) and you'll probably find a little credit telling you who designed and built the site. Although this isn't the same as a personal recommendation, knowing that the developer you choose is capable of delivering the result you want is very important. If a website doesn't say who built it, try contacting the owner. If they received a good service they'll be only too happy to tell you.


  4. Google


    It might seem obvious, but Googling (or Bing, Ask Jeeves etc) is a great way to find a developer. Almost all web developers have a website of their own, usually with some customer testimonials and a portfolio of their work. It may not tell you everything you need to know, but in the absence of anything more concrete, it's a pretty good place to start.


  5. Once you've found a web developer you think you might like to use, the next step is to approach them with your project idea, and that is something I'll talk about in my next post.

0 Comments

Time to Design

Posted on Friday 24th February 2012 at 16:13
If you've looked through the site, you'll probably have noticed that I put emphasis on the fact that I'm a developer, not a designer. It's a distinction that many people outside the industry struggle to grasp, and I often get referred to as a web designer, usually by people that I've just told that I'm a developer.

The distinction has mattered to me for years, but not out of some misguided sense of pride. I'm not suggesting that because development and coding are regarded as being more difficult that design by the general public that I think that that's the case, quite the contrary. The reason why I don't call myself a designer, is because, in my opinion I'm dreadful at it.

From as far back as my memory goes, I've always been dreadful at all aspects of presentation. Handwriting, drawing, painting, laying out text neatly, imagining new things, all of it. I don't consider myself naturally creative or arty at all.

But people don't recognise this, and herein lies the problem. To my friends, family and clients, I am someone who "makes websites", and no matter how many times I tell them I'm a developer, they see me as a designer as well. And they expect me to design. Well, my clients do, I don't think my friends and family care too much.

When I'm working with other developers it is important for them to understand my strengths and weaknesses, so that they allocate me work that is suitable, but end users and site owners expect me to provide a complete package, and that is what, going forward, I need to be able to deliver to them.

So, starting now, I am attempting to teach myself to design, as well as build websites. It isn't something I've ever been opposed to doing - I love the idea of being arty and creative - but as with development, it isn't a skill you can learn without effort. That's my challenge: learn how to design websites.

0 Comments

Getting Our House in Order

Posted on Friday 17th February 2012 at 14:24
People who aren't involved in the running of a business on a day to day basis often imagine that they are well organised, well oiled machines. Obviously this isn't always the case. When I started MRG Web Development, things were disorganised and chaotic. And that's largely how they've remained, until now.

Over the past couple of weeks, I've been working on a webapp that I hope will simplify and enhance our back-office operations significantly. At the moment it is primarily a client and task management and invoicing tool, probably not all that different from many available on the market.

I started with this element of the tool because I needed a replacement for the third party solution I was then using, partly because it didn't really work the way I wanted it to, and partly because I would have had to pay a monthly fee to issue more than 3 invoices a month, and I'm not a fan of paying for things that I don't think work terribly well.

So I built the tool and it now manages all our clients, projects, tasks and invoices rather nicely. But this is only phase one of the project. What I'm really after is the ability to produce useful and meaningful statics about where the business is and where it's going. Up until now I've had no way of knowing how turnover performed in the last quarter relative to the previous one, or relative to the same quarter last year. I had no way of telling you whether we had unpaid invoices, how many projects we have on the go or even how many clients we have.

To some, this sort of information might seem like number crunching for the sake of it, but actually, if you are trying to run a business at a strategic level, this is exactly the sort of information you need to know to help you make the right decisions.

The webapp isn't finished yet. It's going to continue to grow and evolve over the coming months as I try to understand the business in new ways. Whether it will dramatically alter our direction, I can't yet say, but in future, when we make decisions, they will at least be backed up by some reliable data.

0 Comments

It IS Personal, It's Business

Posted on Friday 10th February 2012 at 11:56
We all know that line: It's not personal, it's business. I've never even seen The Godfather and I know it. It seems to get used a lot in the corporate world by those wishing to justify unpleasant actions or decisions, but does it really make sense?

When I decided to go into business in November 2010, I had seen first hand what it was like to be on the receiving end of a web development company who seemed to think that the Mafia were a good role model for how to do business. For the founder of the organisation I was working for though, the venture was intensely personal and being treated in a cold, distant and unhelpful manner left a bad taste in his mouth and in mine.

When I left that job a short while later, I had a theory that, actually, for most business owners, especially amongst SMEs, business is nothing, if not personal. It occurred to me that treating my clients with the same degree of respect and understanding that I extended to my friends was a pretty good model for business and would help me when making decisions with an ethical element to them.

This philosophy has served me well since then and is still at the heart of how MRG Web Development relates to clients, supplier and colleagues in the industry.

There is one element of business though, where I've had to learn the hard way that business is business too: money. One of my hardest struggles has been relating to money in a business sense, rather than a personal one.

Prior to starting in business, I was earning an average of about £8 per hour over a 40 hour week. So when someone suggested to me that £15 an hour might be a good rate to charge clients, I thought I was in the money.

What I didn't understand is that there are many aspects of business that suck up the money you charge your clients before it enters your wage packet, and that you have to charge more as a consequence. If my low rate wasn't harming my profit margins enough, my perpetual habit of underestimating my hours to avoid asking for large sums of money certainly was.

Last month I finally brought my rate up to what I've calculated will be enough to run my business: £40 an hour.

To me, on a personal level, this seems like an incredible amount of money to charge someone for my time, but this is business, it's not personal. My clients may like that I am personable with them, but they see me as running a business and providing a service. What they care about is the service that I offer them, not what I charge for it. They all know what I took a year to grasp, which is that my fees aren't for my time alone, they are for running a successful business and making a profit, and if they don't have a problem with that, why should I?

Service is personal. The fees for it are business.

0 Comments

Site Longevity

Posted on Friday 3rd February 2012 at 12:38
I spent much of this week building a WordPress theme for a client. It wasn't a brand new theme, in fact, it was identical to the existing theme.

The reason for the rebuild was that the original theme had been built in 2009 and wasn't put together in a way that accurately reflected the progression in browser support for web standards. At the time it was built, it worked reasonably well on the browsers that were available at the time, but it didn't adopt many best practices and it didn't cater for any changes that were expected, either in newer browsers or in WordPress itself.

The result of this was that after less than 3 years, the site simply stopped working. It was impossible to upgrade the WordPress installation, there were error messages all over the admin area, and the public facing part of the site had numerous errors in styling and a drop-down menu that simply didn't work in some browsers.

Had I built the original theme, I would have fixed it for free, as the design itself wasn't due for replacement and the errors were all down to bad coding. Sadly though, the original developer was no longer available, and the client ended up having to pay MRG Web Development to fix something that shouldn't have been broken.

Although browser and server technology is regularly changing, it isn't generally hard to predict where it is going, as web standards tend to be developed slowly over a number of years. Whilst backwards compatibility is very important, it's no less important to ensure that a website is still going to work with the standards that are due to be introduced, as well as those that have expired.

We aim to build sites that will comfortably last up to 4 years without technical problems. Most websites have their designs refreshed every 3-4 years, so this ensures that our clients can choose to have a new look to their website when they are ready, without being forced to make changes because of more and more technical problems.

I feel that this should be a minimum standard that all web developers meet. I hope that most of them do, but unfortunately there are still many cowboys in this industry.

0 Comments

The Triple Bottom Line

Posted on Friday 27th January 2012 at 10:56
This week I attended the first 3 days of the Eden Project's 5 day Green Foundation course, aimed at helping businesses to position themselves to take advantage of the low carbon economy, which the UK is shifting towards over the next few years. Although I consider myself pretty switched on when it comes to climate change and the various related issues, I found my time at Eden to be a real eye opener.

The first and most important point being made was that the UK Government has bound us to such strong carbon reduction targets that over the next 40 years, the whole way we live our lives and do business in this country is likely to change significantly. At the moment, a few of the most switched on large companies are beginning to talk about their carbon emissions in terms of electricity usage and waste management, but within a very short few years, we are all going to be expected to know and to be able to justify the carbon emissions from our suppliers' employee's cars when they commute into work.

In short, the level of responsibility that each business, large or small, will have to take when it comes to environmental issues, is being stepped up several gears from where we are now.

The second thing I took away from the course was a little of the process that a business has to go through (using the Eden Project itself as a case study) to make changes that will allow it to be more sustainable. It isn't simply a case of sticking some solar panels on the roof or putting bio-fuel into all your company cars, it's about systematically looking at every aspect of your business in an analytical and measurable way, and evaluating the way you operate; not just against the traditional financial bottom line, but against the Triple Bottom Line of sustainability - economic, social and environmental.

Only when businesses start taking those three factors into account for every single decision they make, can they begin to prepare themselves for a world in which they will be scrutinised more than ever before.

And the starting point for all this? Knowing where you are now. Until you can measure, accurately and systematically, what your Triple Bottom Line looks like today, it won't be possible to improve on it.

That being the case, over the coming weeks I shall be beginning a process of measuring and auditing MRG Web Development, to find out how we stack up. In the future I look forward to announcing the things that we can do to help ourselves, our supplier and our clients to deliver on tangible Triple Bottom Line targets.

It won't be easy, but that's not an excuse for failure. The future of this business, and of every other, depends on the success of this mission.

0 Comments

Welcome to the New Website

Posted on Sunday 22nd January 2012 at 16:09
Hello!

It gives me great pleasure to welcome you to the new, not-temporary, and finally finished MRG Web Development website. One of the sad truths of being a web developer is that the worst website you have any involvement in is invariably your own, simply because it isn't practical to find much time to work on it when you have a busy client list.

That said, having finally found the time to build this site, after more than a year of attempting to fit it in around everything else, I am hoping to be able to keep it up-to-date. This blog, especially, should hopefully avoid looking too static, with regular news and information from the MRG office, as well as my thoughts, comments and ideas about a whole range of tech, web and small business related subjects. I hope it'll be an interesting read for other developers, clients and anyone else with an interest in any of these areas.

At the moment I have an idea in my head that I'll be blogging here about once a week, probably on a Friday, but we'll see how that plays out in practice over the coming months. Until then, I'd like to welcome you once again to the new site and thank you very much for taking the time to drop in.

0 Comments

About the author

Mark Glover is a Freelance Web Developer, based in Fleet, Hampshire, United Kingdom. He writes about topics related to web development and the wider tech industry. You can message him any time on Twitter or by email.
Not a web designer or developer? I also build sites for individuals and small businesses. Take a look here