GOV.UK was built rapidly to meet a tight deadline. The push to get GOV.UK out of beta into live, transitioning 326 government websites onto the single domain, and closing down Directgov and BusinessLink resulted in a significant amount of technical debt.
Continue reading
On the GOV.UK team, all our changes are peer reviewed using Github’s pull request system. If a developer wants to make a change to one of our projects, they need another developer’s approval before the change is accepted into the source repository. A reviewer can comment on parts of the change to offer feedback and suggest improvements. This review process is essential for sharing knowledge and limiting the bugs we introduce into our applications.
Continue reading
Changing a database schema on a production application can be a complicated and risky process. Due to the nature of some of these schema changes and the underlying database engine, the physical change may take many minutes and can block clients from performing operations on affected tables. Even a change that completes in seconds with no blocking can result in applications getting confused when the layout of the database changes underneath them.
Continue reading
I was recently Lyst’s delegate to the Amazon Web Services re:Invent conference in Las Vegas. It’s their annual show where they announce big new features and EC2 instance types, and also a great opportunity to learn how to make best use of new and existing services. This year was no exception, with the launch of AWS Elastic Container Service, bringing an EC2-like API to the running of Docker containers (see Alex’s recent blog post on Docker), and also AWS Lambda, truly a potential game changer where Amazon will run short lived instances of your own functions to process discrete items of data from an event stream.
Continue reading
We’re fairly heavy users of RabbitMQ here at Global Personals, with 10 distinct workflows spread across 2 separate dual-node clusters. At peak our biggest workflow is around 1,200 messages a second, mostly processed by a Node.js worker. The majority of our workers however are Ruby-based using the Bunny synchronous AMQP gem. Across all our clusters and workloads we process around 3,000 RabbitMQ transactions per second.
Continue reading
The globaldev team is gradually becoming more polyglot, and is constantly
churning out more supporting applications to help run our platform. Deploying
all these apps the “old fashioned way” provides a big headache for our
Operations team. Luckily, the industry is moving more and more towards
containerised PaaS-style deployment such as that used by Heroku.
Continue reading
Up until recently, the internal Rails services that make up our Mobile platform utilised action caching for a lot of requests. When data is rendered it gets compressed and cached in memcached, ready to be served by the Rails app next time that action is called.
Continue reading
If you need to store an IP address in a database, it’s possibly because you’re logging web requests or similar. This means the table can get very large, very quickly. If you’re storing the addresses in a VARCHAR, you will use up a lot of space in your table and make indexing a nightmare. A lot of people don’t know that you can represent these as an INT which is much more db-friendly.
Continue reading
EventMachine supports listening on UNIX domain sockets, therefore Goliath does too.
Simply create a config file as per the instructions on the wiki with the following:
port = nil
This makes EventMachine take the address parameter as a unix socket, so simply run your server in the following way:
ruby hello_world.rb -sva hello_world.sock
You can then serve it up using nginx:
http {
server {
listen 80 default;
location / {
proxy_pass http://unix:///Users/boffbowsh/code/hello_world/hello_world.sock;
}
}
}
Continue reading