At the tail end of a discussion over the best way to do a piece of threading a colleague came up with the simile I have as the title for this post. I liked it so much, I've sort of adopted it as a general guideline for approaching multi-threading.
See it applies in a couple of ways.
1. Threading can keep a user looking at something pretty, while a bunch of things go on below the surface like fireworks and the firemen who used to run around lighting them when I was a kid in the country.
2. Threading can be extremely powerful, but needs to be used responsibly. Otherwise, you can end up without some of your digits!
3. If you use common sense both threading and fireworks can produce really good results, with very little effort and danger.
Anywho - after our discussion it seems I had piqued John's interest as about an hour later he sent me a bunch of articles on threading which were really good reads so I thought I'd share a couple...
Threading in C# - Joseph Albahari covers a a few different ways to approach synchronisation Use Thread Local Storage - Doug Doedens which talks about thread level storage, which is a concept I hadn't heard of before but reminds me a little of the Session object in ASP.NET. The second article comes with a VB warning though :P
Wednesday, February 27, 2008
Sunday, February 24, 2008
Patterns and Performance
No, not at the same time... :)
I got sent a couple of articles today from a colleague at work. One to do with the Null-Object pattern and one to do with achieving performance increases through better use of the .Net base class library.
First - the performance article. This one is an older article (Jan 2006) but is a handy one to have in the library. Having not previously read it, I was surprised by a couple of things. First of all the old String vs StringBuilder comparison. I was under the impression that it's never better to use string over StringBuilder when concatenating strings. Apparently, that's not quite right. The magic number of operations (with the caveat in this case of concatenating 25 character strings) seems to be around 7.
Of course, even if you're only doing a couple of small additions you've got future proofing to consider. Is this likely to be wrapped in some form of recursion? Is my 1 or 2 concatenation function going to be called 55 times by a higher purpose? Is that under my control?
The conclusion I've come to - though it may go against the article is that it's almost always better to use the StringBuilder. But I tend to err on the safe side...
The other article was on the Null-Object pattern. This pattern advocates the use of a class which implements all the required members of an interface - with either a default functionality or empty code block. See here or here for a more detailed description.
To me, this is really a dependent pattern. By itself I don't see much value in it. However when coupled with a factory pattern - it becomes valuable. Why? Well part of the purpose of the null-object pattern is to remove the need for object equals null checks in code. If you can't control the object however, the null check is still required as the caller/client could still potentially hand you a null object and therefore cause an exception (which is expensive - see above mentioned article!).
However - if you're using a factory of some sort to supply you an object based on an interface this solves the issue of what to do if the factory doesn't know which instance to return by giving it a default implementation. So you can then have what is basically a stub being returned to allow your code to run safely, sans null checks.
Originally, I wasn't so keen on this. It makes the code look flaky. After a chat about it, some more coffee and a bit of perhaps not so quiet reflection (I mutter when I think) I've come to see the benefits of this particular beast. It makes your code more concise. There is less code for codes sake, and more action going on – and that makes me happy :P
I got sent a couple of articles today from a colleague at work. One to do with the Null-Object pattern and one to do with achieving performance increases through better use of the .Net base class library.
First - the performance article. This one is an older article (Jan 2006) but is a handy one to have in the library. Having not previously read it, I was surprised by a couple of things. First of all the old String vs StringBuilder comparison. I was under the impression that it's never better to use string over StringBuilder when concatenating strings. Apparently, that's not quite right. The magic number of operations (with the caveat in this case of concatenating 25 character strings) seems to be around 7.
Of course, even if you're only doing a couple of small additions you've got future proofing to consider. Is this likely to be wrapped in some form of recursion? Is my 1 or 2 concatenation function going to be called 55 times by a higher purpose? Is that under my control?
The conclusion I've come to - though it may go against the article is that it's almost always better to use the StringBuilder. But I tend to err on the safe side...
The other article was on the Null-Object pattern. This pattern advocates the use of a class which implements all the required members of an interface - with either a default functionality or empty code block. See here or here for a more detailed description.
To me, this is really a dependent pattern. By itself I don't see much value in it. However when coupled with a factory pattern - it becomes valuable. Why? Well part of the purpose of the null-object pattern is to remove the need for object equals null checks in code. If you can't control the object however, the null check is still required as the caller/client could still potentially hand you a null object and therefore cause an exception (which is expensive - see above mentioned article!).
However - if you're using a factory of some sort to supply you an object based on an interface this solves the issue of what to do if the factory doesn't know which instance to return by giving it a default implementation. So you can then have what is basically a stub being returned to allow your code to run safely, sans null checks.
Originally, I wasn't so keen on this. It makes the code look flaky. After a chat about it, some more coffee and a bit of perhaps not so quiet reflection (I mutter when I think) I've come to see the benefits of this particular beast. It makes your code more concise. There is less code for codes sake, and more action going on – and that makes me happy :P
Saturday, February 23, 2008
Office Furniture
I was perusing for office furniture this evening and came across this site. These guys have some of the coolest furniture. I'm thinking of getting the $100 speaker + massage + music gaming seat/mat.
Brilliant.
Brilliant.
Friday, February 15, 2008
Back in the market...
Well, thanks to a good ol' funding shortage at work, I'm back in the job market. I'm currently attempting to obtain one of 3 roles that I've applied for, with a couple of others out there in the mist. I've done a couple of interviews, and the most interesting one so far is Readify.
I'm also looking to try my hand at Facebook app development. So if you have a Facebook app idea that you'd like to see done, leave a comment and let me know!
I'm also looking to try my hand at Facebook app development. So if you have a Facebook app idea that you'd like to see done, leave a comment and let me know!
Subscribe to:
Posts (Atom)
Posts
