anthony galvin

TAGGED: WORK

I'm a technolgist at TodayTix, the posts below are about work, but probably don't reflect my employers opinions. If you want to connect about work related topics, then this is probably the best place to do it. Work related tweets @workoworko

Commuter

I try not to ‘share’ when my commute goes wrong. We chose to live in the village, and yes, it’s not close to the office. Or anywhere (excluding the next village). In fact most of the time, like most people, my commute is pretty mundane.

But. 

Over the next 2 weeks I’m going to commuting by a slightly more unusual set of options, including: private car, folding bike, plane, taxi, @londonmidland train, @amtrak train, tube and (hopefully) snowboard. I’ll try and post back with some good pictures.

It’s going to be an interesting few weeks. 

#photo #train #travel #commute #work

2012-01-15 23:07:23 GMT permalink

#rgaMakeDay

Last week R/GA London had it’s first Make Day - two days of creative and technical exploration, in some ways done just for the joy of being able to make things. I was astonished by the diversity and quality of the work that people produced. Russell, has posted a round up of the different projects, which ranged from a (working) face recognition system running on Windows 8 (which isn’t even publicly available) to some marmalade. For my part I worked as part of team building a “tea and coffee roulette web app / game”.

The concept itself was pretty simple - make a webapp that would allow you to join a tea round, the twist being that the last person to set a preference and complete a simple task would have to make the drinks for everyone else. A quick 10 minute brainstorm and one whiteboard diagram later and we were underway, with @sanderkuypers doing the visual design and the rest of us (@benoitgrelard, @loopdream and myself) quickly began hacking together some working software.

From a tech perspective we decided on a web app (ie, a mobile application that isn’t device specific and can run in the browser) as the best way to get something working with our dev skills. From a front end perspective you can get quite a lot of motion data from some devices (such as an iPhone) via JavaScript, which meant we could build a ‘shake the sugar’ task for the race element of the game. Last one to a hundred shakes makes the tea.

To speed up getting to this device data and creating the UI we used the jQuery JavaScript framework. In the background the game engine was built using PHP and CodeIgniter to handle user registration and keeping everything in sync. We had thought about using node.js to handle socket connections to the devices, but with time limited we settled on using Pusher (a hosted socket service), which had us up and running in about 20 minutes. Behind all this sat a simple mySQL database for keeping everything together.

By the end of the two days we had a working game, that looked great and actually worked - user and device registration, automated email (warning users that the game was about to start), a countdown, simple game (track and field style) and notification to the winners and users - all in real time (via web sockets).

Apart from being a break from our usual client projects and lots of fun it was good to build something a little different - although we didn’t stray too far from our core competency, we did try a few new things. Russell and the management team set some pretty loose (open?) goals for make day, but as the project progressed it was clear that one of the main motivating factors of our team was to deliver working software - which is a pretty healthy team ethic.

I’ll post a link to the source code and a working example once it’s online.

– Follow Up –

Dave suggested that one of the factors for the (relative) success of the project was that the team comprised a variety of skill sets. Whilst this is true, it did come about pretty much by accident. 

#coding #development #rga #work #words

2011-12-11 21:48:00 GMT permalink

UK users like polished Chrome

This post originally appeared on the R/GA tech blog 3 August 2011

This week has seen the news that in the UK, Google Chrome has overtaken Mozilla FireFox to become the second most popular browser. According to data aggregated by StatCounter (a provider of website tracking software), Chrome now has 22.1% of the UK browser market, pushing it past FireFox’s 22.0% market share. Internet Explorer continues to dominate with 46% of UK users still using some version of IE.

Measuring UK browser percentages is not an exact science. Whilst StatCounter usage is widespread, it is by no means the only web tracking software available. This combined with the difficulty in identifying the geographic location of all site visitors means that despite the impression of precision, this data should be regarded as indicative. What is interesting here is the trend and also the reasons ascribed to the growth of Chrome usage in the UK.

Google clearly see speed as a key element in the rapid growth in Chrome usage. Google engineer Lars Bak has been quoted as saying “Speed is a fundamental part of it, but it’s also about the minimal design and the way it handles security”. But the success isn’t only about technical excellence and improving developer tools. A growing suite of cloud based business applications is driving adoption of Chrome by UK businesses. Unusually for a Google product, in the UK Chrome has also been supported by an extensive outdoor advertising campaign.

Whilst Chrome isn’t universally popular, it’s speed and innovative use of caching, has given it, and Google a place on many people’s desktop. With Google alsogrowing rapidly in the mobile market with it’s phone operating system, Android, and making a play at the hardware market with it’s new Chromebook, it would be difficult to see the rapid growth of Chrome slowing any time soon.

#tech #browsers #work #technology #code

2011-08-13 23:20:19 GMT permalink

Head in the cloud

This post originally appeared on the Altogether Digital blog.

Last year at the <HEAD> conference I was fortunate enough to catch Simon Wardley’s excellent presentation on open source and ‘cloud computing’. It was interesting and engaging, but didn’t really seem to be something that the technical team at Altogether could really utilise - the projects we were working on didn’t appear to need ‘the cloud’.

A few months later, and although the sun is shining on Great Portland Street we are happily working ‘under a cloud’.The concept of cloud computing has been around for a while and there’s plenty of definitions and not a little controversy about whether some of the larger cloud players are really providing a silver lining. I don’t think the team here at Altogether is that hung up on a formal definition of ‘the cloud’, we just like effective solutions that work for our clients. However,  as a broad definition: Cloud computing is a way of virtualising data in order to provide a specific performance benefit. The performance benefit may be the ability to provide a rapidly scalable hosting environment or fast access to rich content using edge served data.

Earlier this month Ciaran blogged about how Altogether were working with Kleenex to produce a Twitter based hayfever map of the UK. What he didn’t mention was that as the campaign progressed it was picked up by the press and traffic to the site started to increase pretty rapidly. In order to keep up with the demand for the service we simply moved some of the data storage out into the cloud, in this case Amazon’s S3 service. In Amazon’s words S3 provides “a simple web services interface that can be used to store and retrieve any amount of data, at any time, from anywhere on the web”. Or in our words, the site stays up and performs well.

Whilst the hayfever sufferers have been keeping a sore eye on Twitter, we’ve also been working with Vertu on their new global website. The site has lots of content including rich video and some hefty photography, all delivered in 7 languages. There’s a lot of data flying around. To improve the performance of the site we’ve been working with Akamai who provide ‘edge serving’ technology, which is basically a way of putting the content nearer to the customer - in Akamai’s case on 48,000 servers in 70 countries.

In both cases there’s some pretty geeky stuff happening, which to some people is pretty exciting in itself, but what’s more important is that we have another tool in our digital armoury that ensures the solutions we deliver for clients stay online and perform well, whatever the weather.

#work #tech #code

2009-06-18 15:25:00 GMT permalink

Economic Analysis In 140 Characters

This post originally appeared on the Altogether Digital blog.

The economy is in crisis and the government announces its latest budget in an attempt to try and dig the country out of the deep economic hole that it is currently in. Whichever side of the political divide you’re on this is clearly serious stuff.

I’m certainly no economist, so last night I tuned into Channel4 news for some serious analysis of what’s going on. There was a panel of experts and politicians from across the spectrum discussing the political and economic fallout from the budget. Mid-debate something strange happens; Jon Snow interrupts and they cut over to Krishnan Guru-Murthy who’s sat in front of a PC reading out detailed economic analysis (in 140 characters or fewer) from random people on Twitter.

Now these people aren’t actually random. They’ve tagged their tweets with #c4budget, as @krishgm has asked them to do throughout the day. But I don’t know who they are and have no idea whether they know any more about the economics than Vince Cable or Mickey Mouse.

I’m a big fan of Twitter, it’s brilliant for lot’s of things but detailed economic analysis isn’t really it’s strength. But it’s easy to see the attraction for the ITN news team, who produce Channel4 news:

They don’t have to send someone into the street to get the usual vapid one liners from people stood at a bus stop (which was how the 10 o’clock news on BBC1 gathered public reaction). It makes them look like they’ve got a finger on the pulse of the electorate and shows that they are technologically innovative. It’s cheap TV.

However, there’s a bigger issue here. I’m watching Channel4 news because it can do something that I can’t: get leading politicians and experts in a room and hold a debate on the budget. Searching twitter for #budget is something I can do in a matter of seconds. We don’t really need to have a publicly owned (and theoretically public service) TV station paying someone to read out tweets on air. It’s a bit like getting Simon Schama to Google the year Henry VIII was born.

But of course with media companies around the globe struggling to find new business models that will continue pay for all of these annoyingly expensive journalists, this could well be a depressing foretaste of what’s to come.

#work #tech #social

2009-05-13 09:59:00 GMT permalink

#work #code #tech

2009-04-16 16:24:00 GMT permalink

So I didn’t win the Manchester leg of the Diesel wall competition. Some bloke called Tim won instead.

#work #design #creative #posters

2008-06-16 08:55:00 GMT permalink

It often starts with a sigh. Away from work you hear the obvious sound of frustration when an app or service doesn’t work as expected or crashes at a critical moment. As more and more of our lives are mediated through different glass rectangles, the expectations and importance of delivering brilliant, scalable and reliable experiences on those devices grows.

Which means in practice that the numbers of people involved in creating and engineering the apps and services that people rely on are inevitably large. One of the challenges for people like myself responsible for delivering the software to make all this happen is that with so many people involved how do you create an environment that delivers high quality software and services.

It’s a bit of a management speak truism that everyone on a project is “on the same team”, but in practice that’s not really possible. For some of the global projects I’m working on at Huge, there’s often over 100 folks involved, with a large percentage of these made up of engineers in variety of locations. We have a common objective but in practice we are many teams.

Where location does play a factor is often around balancing time zone coverage so that there’s enough people in each location to ensure effective collaboration. There’s no point adding a single developer with almost no time overlap with anyone else on the project.

However, in practice the amount of overlap doesn’t always have the positive effect people might think. Complex engineering problems require deep focus and an environment that reduces interruption in addition to cross discipline collaboration. The reality of a distributed team is that at some point of the day there are times when there’s fewer people online. Which correlates with fewer interruptions.

Would I choose to have the engineering teams scattered across the planet if it was possible to have everyone in one building. Probably not, but the reality of the work is that this isn’t really possibly, and in practice it’s not the most important piece of the puzzle.

#work #teams #agile #remote #software

10/11/2018 permalink

<< previous next >>