I'm a nobody, nobody is perfect, therefore I'm perfect.
(5 votes, average: 4.40 out of 5)
Loading ...Posted in Blogroll, Fun Time, Photos, Random Thoughts at 11:15 pm by Liv 
This is what my house looks like through the eye of a 6 year old — observe the heart-shaped windows and the little kid on the trampoline (probably the only reason why I’m being liked so much 
lol)
(5 votes, average: 4.60 out of 5) Loading ...Posted in Blogroll, Random Thoughts, Tech at 10:38 pm by Liv
I’m sure as a developer you’ve all heard of unit tests and best practices which preach to unit test your code in the finest details to ensure stability of the platform you are building. While my post does refer to Java (due to my recent experience) I am convinced that this can be applied to developers in any other language – in particular, years ago in a previous life I used to write C++ and I know the points made here are still valid for that language.
So you’re a developer, you write code, you test it and your code ultimately makes it in production as a result of some release process – which can range from someone simply deciding “let’s make a release today” to a lenghty’ properly managed cycle. Either way, part of your job, you think, is to document and unit test your code. And you’ve done all that, code goes into production and everyone is happy. But the very next day an uber-urgent request comes up to change some of the functionality you’ve implemented and add some new one too. (If you ever worked in a startup you know that is such a common scenario!) Since you wrote that code in the first place it becomes your job to address these new requirements, naturally. Deadline is tight and you realise that you need to change a lot of the guts of your code to make it happen. And then you realise that your effort has to be doubled now because you have to change the unit tests too! Not only does the re-factoring make your tests not compile anymore but the actual scope of the tests themselves changed too. If you work in a small team where eveyone has about 10 tasks on their lists at any given time, passing the responsibility of writing the tests to someone else is unrealistic so you’re stuck with them – and with longer working hours to beat the deadline. At this point maintaining a whole set of unit tests becomes a burden that slows down the development and your time is spent half and half in between implementing functionality and writing tests – and do I need to remind you that tests don’t make the business any money? Arguably, the fact that your tests are there ensure your company product is stable – however psychology tells us that first of all since I’m writing the tests for my own code, the errors I’m putting in the code will most likely make it in the unit test too – and as such my code will look perfect after running the tests when the reality is far from it. Secondly, same psychology suggests that if I’m pressed for time I am less likely to pay attention to something like unit tests which are ultimately not crucial for the application. And in fact, I’m more likely to comment out or remove pieces of the old unit tests which need major effort and/or don’t compile anymore – and this just renders the time previously spent on unit tests useless – so I have managed to waste my time and the company time for nothing. (Be honest now: how many times have you not commented out unit tests yourself or seen it done just to get the work done and out of the way?)
So there it is: the joy of unit tests! Having worked with a few startups in my time I started detecting a pattern which mostly says write your code first – if your dev team is good enough (please tell me you haven’t hired just the “standard” in a startup – how will you survive?) then your code is 90% there. It will have bugs but make no mistake about it, it won’t have the standard “if null value passed in, system crashes” – it will have in fact errors so well hidden inside that in most cases your unit tests won’t reveal it anyway as they are contextual and only probably manifest under serious load. And such problems will only manifest themselves not by running a nightly build together with the unit tests but by actually having this in production for a few months and hitting a peak of traffic. And I don’t care what you say, but I’m yet to find that developer who can write unit tests to emulate 5,000 requests a second to test his shit! So really your unit tests protect you from your average Joe Bloggs touching your code – and if you hired him/her I think you deserve to pay the fucking price: if you’re some big corporation hiring people by the dozen or outsourcing to Elbonia or somewhere in the middle of fucking nowhere then you deserve your faith! I think you should spend most of your time writing unit tests for the idiots you entrusted with your code!
I am not against unit tests though – for those of you who made up your mind already! – I think it comes a time in each company’s evolution when you cannot justify anymore not hiring the “standard”. At that moment in time you do have lots of resources and time on your hand to afford the luxury of unit tests; at that moment in time product development doesn’t mean introducing 5 features in your product each day; at that moment in time you no longer have just a bunch of enthusiastic clever guys who want to change the world, you have the financial backing, you have the money and resources to start worrying about unit tests and processes – and that is a nice problem to have. But in my humble opinion is you’re small, if you ticked all the right boxes and you’ve got a small core of developers doing a great job, unit tests will only slow you down. And the main purpose for your startup is to provide rapid development and turnaround for your clients and I doubt that writing unit tests will help you achieve that.
(5 votes, average: 4.80 out of 5) Loading ...Posted in Blogroll, Fun Time, Photos, Random Thoughts at 1:06 pm by Liv
You probably heard me talking about it before, but here’s some pictures from the Illumini Event 2010:
The queues for the opening went all the way around the corner:
Some of the interesting bits:
And the piece prepared by focAR Group:
(6 votes, average: 2.33 out of 5) Loading ...Posted in Random Thoughts, Rugby at 9:51 am by Liv
I was talking recently with a friend (in fact it was last night during my training with my Phantoms) about the upcoming rugby world cup next year. Being a kiwi and with the World Cup hosted by New Zealand he is telling me that there is no way the All Blacks can’t win this! I disagree – naturally
First of all, without disregarding the All Blacks’ strength and tradition in rugby, they didn’t show that much in last world cup – well they did to a certain extent but I think we all remember France kicking them out of the competition in the last 20 minutes of the game pretty much (while the All Blacks were in fact still leading on the score board!) – and the rest was history as they say… Another world cup the kiwis didn’t make it to the final!
Its true they did show some good rugby the other week where they defeated the Springboks in the TriNations – quite sure it wasn’t something easy to swallow for the Boks who were playing at home. But it takes more than that methinks to reach the cup final. And unless from now on the kiwis smash everything in their way I can easily see a repeat of last world cup in 2011 for them.
On the other hand we got France in Europe who’s been flying through the 6 nations – and I’d be very curious to find out how they do this season in the 6 nations as they have finally came up with a brilliant formula for their team where each piece fits in perfectly. Granted they were “helped” by a limping England squad – which only showed improvement and brilliance towards the end – but not enough to deny the French their grand slam. Nevertheless the French rugby is at its peak at the moment – and as much as I’d love to claim the fact that this is possibly due to some English players infiltrating their rugby premiership (Wilko, James Haskell and Ollie Philips to name just a few) that isn’t the case really.
I remember seeing an article by Will Carling after the last 6 nations where he was claiming half-jokingly that the next rugby world cup final is decided: France v South Africa. To be honest one can see that happening the way things are shaping up at the moment. While Will has been pretty awful with some of his recent predictions in terms of rugby (sorry Will but as much as it pleased me when you predicted the other week that Saracens will take it to the Exiles in the London Double Header, they did get thrashed in the end I’m with him on this one as it does indeed look very likely.
I was told the level of domestic violence goes up in Auckland when the All Blacks lose at home – well they’d better get the police and ambulances on standby already as I can’t see the kiwis to make it to the final let alone win it!
(5 votes, average: 5.00 out of 5) Loading ...Posted in Tech at 9:36 am by Liv
One of the common tasks of setting up a production environment in your datacentre is setting up monitoring of your servers. This is quite often overlooked (“our application doesn’t have bugs and doesn’t crash!”) until hell breaks loose. At this point the damage is done and 9 times out of 10 is irreparable. (If you get a call from a client telling you your app has been messing up their website and as such their traffic for the last 24 hours its unlikely you’ll see them again!)
The thing is I am yet to find a monitoring system that works really “out of the box” and is easy to configure – and I think that has a lot to answer for the occasional lack of monitoring nowadays. I totally symphatise with sysadmins who are lumped with the task of setting up a monitoring system – because what makes sense to chose? The “best of breed”? Open source? Cobble together some scripts in a scripting language of your choice? Ask developers to change or implement some code in order to provide JMX hooks or SNMP traps? What about historic data? And the list of questions goes on.
I know there are companies who prefer commercial products for the reason of support offered. The irony is that you install a monitoring system to inform you when your system breaks – but you take out a support contract in case the monitoring system itself breaks! Let me spell it out for you: you take your car for a MOT to find any problems with and then pay the guys to fix it and make it road worthy – but in case it still fails the day after the MOT you pay another tax to the same garage so they come and fix it again. How many of you do this as a norm? I bet you if you heard such an offer from your local garage you’d say “no thanks mate” get in your car and drive to the next garage. So I don’t see the point in the support contract on your monitoring system. I see the point in paying for a license and most importantly training for your staff so they know how to configure and use the damn thing – and from my experience the training is a killer in terms of finance as it normally sums around 5k per week per person. And if you have 3-4 sysadmins you’ve coughed up 20k straight away. (ahem surely you’re not gonna tell me that your production environment is managed by one sysadmin or, God forbid!, developers) My point is that from the little that I know licenses for these monitoring systems are comparable with the training costs above or even less – and the training is the vital thing that you need! And training can be provided for any kind of system not just commercial ones – so I don’t see the point in investing in a commercial system really as quite likely you can get the same from a non-commercial one!
Which brings me to the point of open source systems: I know loads of open source purists who will go for nothing but open source on the basis that is maintained by a community which provides support for it as well and are receptive to user’s suggestions and feature requests. Really? 
when was the last time you emailed SpringSource or Apache and said “it would help me greatly if you implemented this feature” and they turned around and said “fair enough next month’s release will have it“? Even if they do listen and go ahead and implement your requested feature you probably have to wait somewhere around 6 months to 1 year for the next major release right? By that time you found a workaround and don’t tell me when the release comes out you’re finally gonna ditch all that “workaround code” and spend time on implementing the requested feature – quite likely by that time you’re dealing with other more important things to the business so this gets thrown in the pile of technical backlog and if it gets looked at it’s going to be in another few months ! So I’m yet to be proven that embracing open source technology will actually get you all the monitoring requirements sorted. (Or for that matter any other software requirements!)
There is of course the argument that if its open source that means you got access to the sources – and if you have the sources of the product,well, you can do anything right? No shit, Sherlock! How many people are going to look to a product complex enough so you don’t understand it and say “fair enough we’ll have a look at the sources to see why it goes wrong“? Next to nil. Nada. Zilch. Because if you want to figure out some open source code you need to hire a few people who will make a job out of looking at an open source product and make sense out of it. If an open source source code is easy to read and understand then quite likely it doesn’t do that much – if it does lots then it’s complex and complex means difficult. And if it’s difficult to configure then you can bet your bottom dollar the code is not that simple – and as such not that simple to read! I remember talking to Alfresco a little while back and they said to me that they were putting a lot of work into reaching out to the community so to speak : wiki’s, FAQ’s, forums, they had the whole works! (and I’m sure they still do, they have a great product). However when I started talking to them about the community input into their product codebase the answer that transpired was upon the lines of “sweet fuck all, mate“! There are loads of users who might check out the sources, have a look and have an opinion on it but very few of them would actually contribute! In fact at the time I was talking to them about it they were seeing absolute 0 commits or patches or anything like that from the community.
There are of course companies who will take an open source system, have developers who study the code and adapt it to suit the company needs and transform it to suit their needs. 2 main points here though:
I’ve touched on the open source concept before in this blog and looking back at that post I’m afraid to say things haven’t changed that much in this area – and as such like I said don’t expect to be able to pick up an open source monitoring tool, read through the sources and adapt it to your needs! Instead have a look at how many of the feature it has offers and which ones can be easily implemented – for the rest of them you’ll most likely have to consider in-house tools rather than try to modify the source!
And since we are on this topic, it is worth mentioning the monitoring tools built in-house, as from my experience with startups they account for a lot of monitoring of production environments. I know your average enterprise will tut at me for saying this, but in a startup everyone is doing about a hundred jobs at once – and introducing a new (monitoring) system means that number will grow to about 150 – are you really sure you want to add more things on your team’s plate when your main objective is to develop a product? Instead why not leverage their existing knowledge and build some scripts and tools in a language they know already so there’s no learning curve – and also you can easily change these in the future? I’m not even suggesting any technology – there’s Bourne shell, awk, sed, perl, Groovy, python and a whole lot of others. If your team is comfortable with any of them why not use that knowledge for not just development but system monitoring as well? On top of that from what I have seen most of commercial or open source systems support plugging in a script – so these can be then easily moved into any other system.
Start small and allow for growth – the basic principle of a startup right? After all just because its open source and free it doesn’t mean its the right one for you – or simply because it costs you money it doesn’t mean someone is going to take the burden of configuring and maintaining it off your shoulders!
Lake Tahoe 28/Jan/2012