Sunday 25 October 2009

Release it! - some loose thoughts

I’ve been trying to finish that book for quite some time. It was difficult :) because it is a book that you can read chapter by chapter without losing the plot and hence it’s easy to abandon it every now and then. Anyway, I managed to finish it this week and I have to say that I haven’t really learnt anything new. This doesn’t mean that it was a waste of time. On the contrary, after reading it I’m more confident that what I’ve been doing is right and I’m not some kind of weirdo that demands the impossible :). It’s definitively a must read for developers that haven’t worked in 24/7 environment where part of their job is to be on call for a week every month or two. When you can get a call at 3 am you design your software in a little bit different way :). I will dedicate a separate post to that topic.
There is one thing in the book that I disagree with though. Page 199, Michael recommends to use SoftReference when implementing a cache in Java. The counterpart of SoftReference in .NET world is WeakReference. I think that is a very bad idea. The most important part of every caching solution is its expiration policy which would translate to a simple question – when does the data need to be refreshed? GC operates at a very low level and it doesn’t have enough information to make an informed decision. Let me give you an example. Let’s say we have 2 arrays of integers(System.Int32). Both of them 1000 elements long and it takes 10 ms to fill the first one and 100 sec to fill the second one and they both need to be refreshed once an hour. From GC perspective they are basically the same objects. It doesn’t matter which one gets collected as in both cases GC will reclaim 4000 bytes. This is not true from the application perspective. If GC decides to release often the memory associated with the second array the application will crawl. If not it will be lightning fast. What if the GC implementation changes and after upgrade to the next version of the runtime the performance of the app changes completely. I wouldn’t like to debug this problem. In other words, you can’t build a solution that needs to be predictable(cache expiration policy) based on a component (GC) that is beyond your control.

Sunday 6 September 2009

Failing fast saves a lot time

Have a look at this MSDN blog post to see a real life example of how crucial it is to fail fast.

Tuesday 1 September 2009

CloudCamp - a bunch of loose thoughts

I know more or less what Cloud Computing is but until recently I still struggled to figure what it is good for. That’s why I decided to attend CloudCamp at Google’s Sydney Office which is a Cloud Computing event focused on sharing thoughts in a form of open discussions. The presenters were there just to start conversations and finish them soon enough to have a few beers afterwards :). I participated in two sessions(Scaling Applications in the Cloud, Cloud Computing from business perspective) and each of them taught me something different.

The sexiest part of Cloud Computing is its promise of scalability. The funny thing is that most of the people will never need it. If I’m not mistaken StackOverflow handles 1 million of hits a day running on a beefy DB server and two medium size Web servers. Sure, it depends what your app does but in most cases thinking a lot about scaling issues before you actually face them is a waste of time. It’s better to spend that time on making sure your app is successful. This of course doesn’t justify complete lack of design and messy code. It’s a matter of striking the right balance. If you know for fact that your app needs to handle huge load then it makes sense to design for it upfront. But again, if there is one problem that startups are dreaming of it’s the load problem :).

One of the presenters mentioned that hosting of a regular WordPress based site in the Cloud is 7 times more expensive than regular, dedicated hosting. The cloud seems to be good for apps which resource utilization is either low or variable. If it’s low then it means that by hosting it yourself you pay for resources that you don’t take advantage of. If your utilization is high it might not make sense to move to the Cloud because the Cloud Computing providers charge you for resources (you will use the same amount) and additionally for promise of more resources when you need them. If you have to handle spikes Cloud Computing might be the way to go as you don’t want to buy bunch of servers that you use only a couple of weeks a year. In other words the key to successful migration to the Cloud is to know your application capacity.

A few people mentioned that they use the Cloud as their stress testing environments. This actually makes a lot sense because you can quickly provision a lot of boxes, do your testing and then discard them for a very reasonable price. In general if you need to perform some kind of activity that is either temporary or repetitive you might want to consider doing it off your premises.

Another presenter said that the Cloud Computing price should drop in the near future because more and more people are using it and it might become a commodity. Someone compared Amazon pricelist to the price lists of mobile network operators. At the beginning the price list was simple to attract customers. The more people use the service the more complicated the price list gets until the point when a regular user is totally lost and the service provider can make more money off him/her then before. It is an interesting theory and definitively true with regards to at least some mobile network operators. I still can’t figure out why 50 AUD worth CAP converts into 150 AUD value :).

An employee of of a big hardware vendor mentioned that some big Cloud Computing providers are working on a standard that will let people to move their apps from one provider to the other. I suppose they figured out that being locked to a particular provider is not what business is looking for.

From business perspective IT infrastructure is a cost. If the cost can be lowered by moving it to the Cloud that’s great. It’s not like business is mad about Could Computing. If a bunch of monkeys were good enough and cheaper than on premises IT infrastructure they would go for it. IT is a tool. So far the best one and let’s try to keep it that way :).

Wednesday 26 August 2009

No coding exercise. I'm not interested.

Richard, one of my colleagues at Readify, wrote an interesting blog post about how he learnt the hard way that if you want to hire a software developer you need to check her/his skills by giving her/him a coding exercise to solve. If you don’t do this you are simply asking for trouble. Have a look at Richard’s blog post for more details.
When I was looking for a job in Australia and I got in touch with a few companies and some of them didn’t require me to write any code. Those companies were immediately off my list. Moving to the other hemisphere was risky enough that I didn’t want to deal with companies that didn’t pay attention to their recruitment process. What is more if a company doesn’t bother to interview you properly that might be a sign that they won’t treat you well.
Just my two cents.

Sunday 16 August 2009

Subtext 1.9.5 -> 2.1.2

I’ve just upgraded my blog from Subtext 1.9.5 to Subtext 2.1.2. The upgrade has been smooth and I haven’t had to make any manual changes. I’m really impressed. Keep up good work guys! I can’t wait for Subtext 3.0 which is meant to based on ASP.NET MVC. Now I need to find a better skin for my blog but taking into account my UI skills that might take some time ;).

5 days SOA and DDD training by Udi Dahan in Melbourne

If there are enough people then this actually might happen. If you are interested and I’m telling you, you should :) then express that as soon as possible by  contacting Simon. You can find an overview of the training here.

Monday 10 August 2009

Quick look at STM.NET performance

STM as an idea looks interesting and definitely has a lot of advantages over regular locking. It helps prevent deadlocks, makes easier to compose components that implement some kind of synchronization, helps eliminate nested locks, supports retries and so on. You can find the full list of goodness here.
When I found out that STM.NET(based on .NET 4.0) is out my first question was related to its performance. I put together a simple test and I have to say that in most scenarios STM.NET is an overkill. Sure, it’s a research project and it hasn’t been productized which means it’s not optimized and it’s not ready for prime time. But still, on average it’s 20x slower than the regular lock statement. That’s a lot taking into account that in most cases developers use very simple locking strategies and try to avoid nested locks. If Microsoft can bring it down to 2x then it is a completely different story.
The results:

The code of the benchmark:

using System;
using System.Threading;
using System.Collections;
using System.TransactionalMemory;
using System.Collections.Generic;
using System.Diagnostics;
class Program
{
public delegate void CustomAction();
[AtomicNotSupported]
static void Main(string[] args)
{
var iterations = 1000000;
Console.WriteLine("Number of Threads | STM.NET [ms] |" +
"Regular locking [ms] | Times slower");
for (var i =1 ; i < 15; i++)
{
Test(i, iterations);
}

Console.ReadLine();
}
private static void Test(int numberOfThreads, int iterations)
{
var storage = new Storage();
CustomAction action = () =>
{
Atomic.Do(() =>
{
storage.UpdateByOne();
});
};
var stm = Execute(numberOfThreads, iterations, action, storage);
storage = new Storage();
CustomAction action1 = () =>
{
lock (storage)
{
storage.UpdateByOne();
}
};
var locking = Execute(numberOfThreads, iterations, action1, storage);
int slower = (int)(stm.ElapsedMilliseconds / locking.ElapsedMilliseconds);
var message = String.Format("{0}\t\t\t{1}\t\t\t{2}\t\t\t{3}", numberOfThreads,
stm.ElapsedMilliseconds,
locking.ElapsedMilliseconds, slower);
Console.WriteLine(message);
}
private static Stopwatch Execute(int numberOfThreads, int iterations,
CustomAction action, Storage storage)
{
var stopwatch = Stopwatch.StartNew();
var threads = new List<Thread>();
for (var i = 0; i < numberOfThreads; i++)
{
var thread = new Thread(() =>
{
for (var j = 0; j < iterations; j++)
{
action();
}
});
threads.Add(thread);
}
foreach (var thread in threads)
{
thread.Start();
}
foreach (var thread in threads)
{
thread.Join();
}
stopwatch.Stop();
if (numberOfThreads * iterations != storage.Result)
{
var message = String.Format("Incorrect value. Expected: {0} Actual: {1}",
numberOfThreads*iterations, storage.Result);
throw new ApplicationException(message);
}
return stopwatch;
}
}
public class Storage
{
private long value;
public void UpdateByOne()
{
value = value + 1;
}
public long Result
{
get { return value; }
}
}

Wednesday 22 July 2009

How many times can you load an assembly into the same AppDomain?

Actually, as many as you want, just call

Assembly.Load(File.ReadAllBytes(@"SomeFolder\MyLib.dll"));

in a loop. All copies will have their code base set to the currently executing assembly. Code base specifies the physical location of an assembly. By executing the following line

Assembly.LoadFrom(@"SomeOtherFolder\MyLib.dll");

we load another copy but this time from completely different location. Let’s add one more:

Assembly.Load("MyLib");

In this way we end up with several copies and 3 different code bases inside of the same AppDomain. This happens because each assembly is loaded into different load context. You can read about that here. Why is it like that? To be honest I’ve found no clear explanation. Some Microsoft bloggers mention that this makes order independent loading possible. But that’s it. From my perspective that’s not much to justify the fact that multiple copies of the same assembly can be loaded into the same AppDomain which is very often dangerous.
The main problem is that the runtime treats types in all copies as completely different types. This means that if you create an object of type MyClass using the type definition from the assembly loaded by Load method you won’t be able to pass it to a method that takes MyClass as a parameter but is defined in the assembly loaded by LoadFrom method. If something like that happens you get InvalidCastException which is hard to believe in because VS debugger clearly shows that the type of the parameter is correct :). It’s only when you dig deeper and check the assembly where the type comes from when you find out that they are from 2 different assemblies. This can be very confusing and hard to debug. Even if there is a valid reason behind this feature it would be great if I could run loader/runtime in some kind of strict mode where duplicates are not allowed and a meaningful exception is thrown when an assembly is requested to be loaded more than once. I can see more and more code that is loaded dynamically at runtime and this feature would be very useful.

Monday 6 July 2009

This blog is NOT dead

It’s been a very busy and exciting half a year for me and that’s the main reason why my blog WAS temporarily abandoned.

Before Christmas 2008 I left Ireland for good. I’ve spent over 3 years of my life there and I don’ regret anything. I’ve met many amazing people and I’ve learnt a lot from both professional and personal perspectives. But my Irish time was up and it was time to move on. I’ve decided to move to Sydney in Australia and become one of the Readifarians. I started my new job at the beginning of April 2009. After leaving Ireland but before arriving in Australia I went travelling(Mexico, Guatemala, NYC) for several weeks to prepare myself for new challenges. That’s the story.

I work as a Consultant which means that I either work from home or work on the client side. It’s definitely completely different way of working than the one you experience as a permanent employee. It’s too early to make some definitive statements but so far I can say that is focused very much on solving problems which makes it very intense. And that’s exactly what I was looking for.

The bottom line is that I’m back to blogging which means I’m more or less settled on the other side of the planet :).