The Blog - Archive for projects

FaceJam – a web toy for parties, conferences and networking

by Mark P. Filed under: Products,Technology

We’ve just put up the first version of Face Jam. A really simple online tool that once “connected” stops you from forgetting all of the those lovely people you met last night…

A user sends a Twitter name by SMS (to a short code) and receives back a message with their full name, location and other networks. The person will also be saved to your online account so that when you’ve sobered up got in front of a PC the next day you can check out (and connect with) the people that you met last night.

It’s super simple and good fun. We’ve got a few neat enhancements in the pipeline too.

Currently it’s UK and O2 only due to the use of the Bluevia Oauth. We’ve got another etcher post coming about the development journey.

Social media, riots, politicians and humour

by Mark P. Filed under: Community,Products

You’ve heard the politicians going on about Twitter and Facebook and the riots? You’d have to be living in a serious hole or must have been on holiday a long time not to have. There’s been a lot said and a lot done.

We recently pitched the government via the Technology Strategy Board for a system to predict where this stuff might happen (better the devil you know!)… They are taking this stuff seriously, there was £600k available to research this “Minority Report” style software and while its not where it needs to be yet, it is not as far off as you might think.

Well now (via a new company) we’ve done the opposite of predicting the future and discovered an interesting twist – humour, however “dark”, plays a large part in social communication and trending. Using control data and then a continuous stream of “chatter” that fits targeted queries, the Churnbar system was “taught” what it should be looking for with minimal human interaction with some interesting results.

To quote Nigel Legg the auth of the post,

Care is needed when using social media to find the instigators of criminal activity.  Law enforcement agencies need to determine whether a post is humorous or serious in intent.

For a full explanation read Nigel’s excellent post.

A little monkey love

by Mark P. Filed under: Products

We all like cakes. We all like a bit of love. So when a mysterious box arrived at the office on Friday from a client with the most beautiful cup cakes in, we were super chuffed.

The sparkly cakes from the lovely folk at Go Ape were to thank us for delivering their summer campaign with such brevity and fabulousness!

We built the social competition using the pro version of our new Rusic.com product, enabling us to build the competition in days instead of weeks (or months). We think it’s pretty awesome and after only a few days it’s already got some amazing stories going on.

Craziness by Go Ape, design by Refreshed, social and tech by Simpleweb, and of course the CAKES by Rachaels Kitchen. Awesome.

Things to consider when putting a website live!

by Tom H. Filed under: Knowledge

There’s no shortage of help out on the web for building websites, but, what about once you’ve built your site? It has to be made live and published for the world to see.

We’ve deployed quite a few hundred sites in our time and I thought I’d share a few hints and tips to ease the process and make it more streamlined.

Firstly, there are two main types of deployment:

1. Brand new website

2. Update to an existing website.

The second of these is generally far more difficult to deal with, normally DNS and email will already be setup.

Step 1 – Get your DNS in Order

Don’t underestimate how long this might take, often it will involve your customer digging out information they have filed away years ago.

You need to find the following:

  1. Registrar – which company is managing the domain? You can find out by doing a WHOIS on the domain. We use DNS Stuff for this. See example.
    • If the domain hasn’t been registered, it’s easier to do this yourself with your preferred company. We use http://www.ukreg.com/ normally, and, their system isn’t bad.
    • If the domain has been registered, you will need the login details to make amendments. Some times, customers might be reluctant to give you this, so you’ll have to do everything via them.
  2. Take a snapshot of the DNS. If you change records later, you’ll want to know easily what to revert back to if something goes wrong. We do a DNS Report for every domain using DNS Stuff and save it. You can also take a screenshot of your Registrars name server setup or save the zone file if you have complete control. We write down IP information for our various servers in our Wiki so when we come to do updates we have the information quickly to hand.
  3. Determine what name servers the domain is on. This is normally the ones provided by the registrar but could quite possibly be another company. Again, you can determine this from a WHOIS or DNS Report. We prefer to use our own DNS company, it gives us more flexibility and we know we can do certain things not all providers offer (such as changing TTL – see the right way to move a domain).

Step 2 – Sort out hosting

Ok, I’m not going to say too much about this. But, make sure you leave plenty of time to get hosting setup. If you’re setting a website up on a dedicated server, and it’s not something you do all the time, you probably need to allow 2 days to get it all setup and working. Things to consider:
  • Do you have any monitoring? If the server grinds to a halt, you’re going to want an idea why. We use Munin
  • Have you got backups setup? Are they offsite?
  • Do you have the web server and database server configured and appropriately optimised?
  • Can the server send email? If there is an SPF record for the domain (there should be) then you’ll need to add the IP of the server. If the server is sending email directly, it should have a reverse dns entry to the server.

Step 3 – Register SSL

If the site is an e-commerce store or has secure parts to it. It will probably need an SSL certificate. Don’t forget about this. We use GoDaddy.com for certs because they are cheap and actually pretty good for getting things setup.
  1. Check to see if the existing site already has a cert. Ask the client if they have the cert details, they probably don’t want to buy another if they can avoid it.
  2. Getting SSLs setup can take a while (not going to go in to how you do this, maybe another day), mainly because of the verification process. You will quite likely need access to the name servers to add verification information in to prove you/your client owns the domain name. Allow a few days for this!

Updating DNS/Name Servers

Ok, so you’re ready to switch off your old site and move to your new site! Exciting…

But, there’s a right way and a wrong way to do it.

Lots of web companies will say this to their clients when they move a site:
“We’ve done the DNS update, we’re just waiting for it to propagate and this will take 24/48 hours”.
WRONG!
This is what a web company tells you when they don’t know what they’re doing. If you do things correctly you can switch things very quickly and minimise the amount of people that end up on the old site. Follow the following:

Do you need to change name servers?

When you need to switch name servers:
  • Don’t try and update records at the same time!
  • Setup your new target name servers to be exactly the same as the old ones.
  • Switch name servers.
Nothing should go wrong, providing you have copied all the records over. Almost all Registrars will tell you name servers take 24/48 hours to update. This is possible, but rare. Normally, in a few hours all will be cool. But, before you do anything further, check the domain is using the new name servers with a WHOIS lookup.

Changing records

When you are ready to switch to the new server you will need to update one or more A records for the domain. This isn’t a full explanation, but it should at least set you on the right path.
  1. Find the TTL (time-to-live) for the records you want to change. You can do this with a DNS Stuff Domain Report or it should be in your DNS configuration.

    The TTL is the amount of time the record will be cached.

  2. If the TTL is 1800 (expressed in seconds), this is 30 minutes the record could get cache. It’s typical for this to be about 1 to 6 hours. Reduce the TTL down to something like 60 seconds or 120 seconds. But… you need to wait the original TTL for things to get flushed out before you are ready to update.
  3. Change your record after the original TTL has expired. There should then only be a 60/120 second window when they might get the old record though…. but this isn’t necessarily true! Why? Because you are only changing one name server normally, and the changes need to propagate. Knowing how long this might take is again down to name server setup (partly why we like to use ours) and further TTLs on the actual domain itself.
  4. When everything is a-ok, put the TTL back up (otherwise every lookup will end up going to the main name servers first).
One more cool tool I like, DNS Stuff provide a ISP cached lookup facility. It will scan all the DNS servers of major ISPs to see if there is a cached record for a domain.

In Summary

There’s quite a lot to domains and moving sites. Hopefully this has helped a few people but all I would say is, give this stuff the respect it deserves. DNS runs the web! Just because I can walk in to a plant store and hire a digger, doesn’t mean I should… well, not without at least finding out how to use it properly.
For all your earth moving needs, try Hewden

Love buckets and feature creep

by Mark P. Filed under: Products

When we’re working on projects for clients there’s always new ideas being thought up throughout the project. Ideas are great as an indication of a positive development.

The other side to this positivity coin though is the impending doom of “feature creep”. Sometimes its inevitable. It’s just the way it is. Get used to it! Over the years we’ve created a system that has evolved into something that seems to work for the client and for us. It’s even spurred us to build an application to manage the process.

We call this process the “bucket of love”. It’s a virtual bucket that all ideas go into. The term is fluffy and golden enough to take the edge off of a client feeling like they’re being ignored. They’re not of course, it’s just a sound way to remove feature creep until the end of a sprint. When we reach the end of the sprint, if it’s still a good idea we can discuss implementing it. Voila, everybody is happy.

This brought us to actually creating a system to do this and thus Rusic.com was born. A user logs in with their social account (Twitter or Facebook) and they then create “idea buckets”. Each idea bucket holds the basic premise of a question, “how can we improve sprint X?”. Everybody can contribute their ideas, “like” and comment on other peoples ideas. It’s a great way to see what is interesting (and what isn’t).

Interest doesn’t necessarily mean “like” either. I can make a negative comment but it still shows that I’m interested in an idea, just like in a real conversation.

There’s also a lot of social goodness going so that each idea bucket gains some momentum. Momentum is necessary for the generation of ideas. Ideas breed ideas…