ninjapenguin

Just over 3 years ago I joined a startup. The next 18 months went fast, they went really fast. We went from an idea, to having sold a product to some of the biggest brands in the world. We went from a tiny room in an incubator office in the North East to 3 offices in 2 continents and a staff count that was rapidly on the increase. We had a lot of fun.

Within this time I made (a lot of) tea, put together advertising stands and office furniture, evangelised our product at conferences, booked travel tickets, brainstormed product features, talked to potential clients, interviewed and hired new team members – and I developed a bunch of code. I was able to try new development techniques, new tools (some of which failed!), and push a bunch of code to live. Some deployments broke things and I panicked – those were fixed quickly! Did I mention we had a lot of fun?

It’s been quite some time since my last post – but as I decided recently to refresh the sites template I thought I would celebrate with a new post on a recent release I made.

Redis Monitoring Server is a small python server which monitors and logs one or more redis instances, the server can then be queried in a number of ways to retrieve the commands run on the observed instances

Quite a large proportion of my day-to-day job involves the design, implementation and ongoing improvement of an in-house API.

As a result of this, a commonly identified bottleneck arises when dealing with large, ‘expensive’ data. This is commonly seen when an application posts a large volume of well structured data to the API (that some process must be carried out upon), before some form of structured receipt is then returned as a request response.

Analysing such a request tends to show high PHP CPU usage with lower database consumption. This means that with an increase in data processing capacity we could make more use of this redundant database resource.

The structured nature of data exchanged via an API means that we can, relatively simply and reliably, divide the submitted data and process it simultaneously with the help of a great tool called Gearman.

For the second in my mini-series looking at Object Oriented Design within the Kohana framework I am going to look at the Facade pattern. I had this down for the third article, but I had a comment on the last one voicing some thoughts on a common grey area when it comes to this and the adapter pattern, and so I thought I would jump straight to the facade pattern in an attempt to clear up any confusion!

Thought I would do a couple of posts on some basic Object Oriented design patterns and examples of their implementation within the Kohana framework. They’re not going to go into any great detail but will hopefully provide a small insight into some of the inner workings of Kohana and enable  you to make full use of some of the inherent power these patterns provide.

This article covers the adapter pattern. You can see some of the Kohana system libraries making use of this pattern by checking out the system/libraries directory. Within this directory you will find the drivers folder, for now take a quick look at it and see if you recognise any of the class names, we’ll come back to it later.