The other title that I had in mind for this post was Fear of a fundamentalist Egypt. I think both titles make clear my many doubts about the "revolutionary process" taking place in the streets of Egypt right now.
Based on my little knwoledge of recent history, I think the Iran where the Iranian Revolution took place was not much different from today's Egypt. Both countries ruled by a corrupt, pro-Western dictator that was trying to modernize his people, but ruling them with an iron fist.
Unfortunately, fundamentalist muslims seized the revolution and turned it into an Islamic Revolution that resulted in the bloody, oppressive theocracy that we all know. One of the first things Jomeini did was murdering as many as he could of the progressist activists that had taken part in the revolution with the hope of a modern, open, democratic Iran...
I'm afraid the chances for an "Egyptian Revolution" to follow the Iranian steps are terrifyingly high. Egypt has been infected by fundamentalist groups since a long while. The Muslim Brotherhood is probably the best known of them, thought much less radical than the Egyptian Islamic Jihad, this group might not sound much familiar, but sure their disgusting, blood thirsty leader, Ayman al-Zawahiri, is far better known for most of us.
This said, I think my fears of fundamentalists gaining power after a "revolution", either by violent or even "democratic" means are well founded. I need to say that having achieved power by "democratic" means should not make that fundamentalist government valid to us, on the contrary, it should invalidate the democratic process itself in that society at that specific time. I mean, medieval, illiterate, undershock... societies should not be considered eligible for democracy (do I need to remind you how a shocked, empoverished, humiliated German population raised the Nazi Party to power?)
Hopefully my predictions will be proven absolutely wrong, and a better (and that necessarily involves "Western friendly") Egypt will evolve from all this, otherwise, the only beneficiaries of all this will be those countries that will manage to attract the flow of tourist that would no longer be able to visit the beauties of ancient Egypt (who knows, in their absolute fanaticism and stupidity, fundamentalists could emulate their Afghan friends and dynamite the pyramids as the Taliban scum did with the Buddhas of Bamyan).
Saturday 29 January 2011
Friday 28 January 2011
Lake Vostok
Some weeks ago I read some RSS header stating that Russian scientifics were starting to drill into Lake Vostok. I could not stop to read on, and then I forgot about it until reading this on BBC's Web site today.
This is pretty interesting stuff. I first knew about this lake some years ago when I watched this great documentary, The Lost World of Lake Vostok.
The main ideas portrayed in the documentary and that got stored in my memory were:
Reading the BBC article seems like my memory served me well, and the contamination issue has been the main stopper amid the many other technical difficulties. Russian scientists appear to have come up with some ingenious and well thought work arounds:
They said that instead of drilling into the lake, they would go down until a sensor on the drill detects free water.
Then they would take the drill out without going any further and adjust the pressure so that instead of any liquid in the borehole falling down into the lake, water in the lake would be sucked up.
Then the drill would be taken away and left for quite some time to freeze, creating a plug of frozen ice in the bottom of the hole.
Finally, next season, the team would drill down again to take a sample of that ice and analyse it.
Some scientists are not so certain about this procedure being so completely innocuous, but seem to be the least. Let's hope this time the majority is right.
All this said, seems like we could be at the doorway of some really breakthrough in our understanding of life emergence and evolution, thought there's a really important fact mentioned in the article and of which I was absolutely unaware, in the last years a series of rivers have been found under the Antartic ice. These rivers connect other sub-glacial lakes, and if it were the case that they also had reached Vostok Lake, the idea of a completely independent ecosystem should be discarded.
This is pretty interesting stuff. I first knew about this lake some years ago when I watched this great documentary, The Lost World of Lake Vostok.
The main ideas portrayed in the documentary and that got stored in my memory were:
- Being an environment isolated from the rest of the planet for many, many, many centuries, and under conditions not present on any other corner of the Earth, forms of life absolutely different (to say the least) could have evolved there. We could have a whole new range of extremophile creatures there.
- Conditions in Lake Vostok could bear huge resemblance to those in Europa, that Jupiter satellite where allegedly a water world could exist under a thick ice layer.
- Drilling into the lake could spoil this whole mysterious world, cause as we've usually done other times when "conquering new lands" we could take with us all sort of microscopic life forms that could put at risk this untouched ecosystem.
Reading the BBC article seems like my memory served me well, and the contamination issue has been the main stopper amid the many other technical difficulties. Russian scientists appear to have come up with some ingenious and well thought work arounds:
They said that instead of drilling into the lake, they would go down until a sensor on the drill detects free water.
Then they would take the drill out without going any further and adjust the pressure so that instead of any liquid in the borehole falling down into the lake, water in the lake would be sucked up.
Then the drill would be taken away and left for quite some time to freeze, creating a plug of frozen ice in the bottom of the hole.
Finally, next season, the team would drill down again to take a sample of that ice and analyse it.
Some scientists are not so certain about this procedure being so completely innocuous, but seem to be the least. Let's hope this time the majority is right.
All this said, seems like we could be at the doorway of some really breakthrough in our understanding of life emergence and evolution, thought there's a really important fact mentioned in the article and of which I was absolutely unaware, in the last years a series of rivers have been found under the Antartic ice. These rivers connect other sub-glacial lakes, and if it were the case that they also had reached Vostok Lake, the idea of a completely independent ecosystem should be discarded.
Saturday 22 January 2011
Simulate Anonymous Classes in C#
I'm starting to learn Groovy. I've been more on the .Net side all these years cause I think Java (the language) sucks because of its lack of "freak features" when compared to C#: delegates and events, properties, lambdas, Iterator blocks, object literals, unsafe, PInvoke, dynamic... but Java the platform is at least as powerful as .Net, so using a modern language like groovy seems like a good option for me to be able to leverage all the beautiful Java frameworks out there...<
What Groovyists call Closures (they use it as a syntactic concept instead of semantic and admit that the name is confusing, as sometimes these anonymous methods enclose external variables acting as real closures, other times, there's no need for this enclosing, so calling them closures is not fully accurate), are pretty similar to .Net delegates. In both worlds functions are not objects, and the framework and compiler work together to create delegate or Closure objects to wrap functions.
A really beautiful feature is coercing Closures or Maps to implement interfaces. This nice technique makes Java anonymous classes unnecessary, but at the same time reminded me of this Java feature and made me think of it in C# terms.
In spite of all its power, C# 4 does not have anonymous classes. It's strange, cause given all the crazy things the C# compiler does (creating classes for closures, iterator blocks...) adding support for anonymous classes seems pretty easy.
I guess the main reason is that at first sight they don't seem much useful. In Java Anonymous classes are mainly used for the events-listeners thing, in C# the very convenient delegate (named and anonymous) approach is used for event handling, so this use case is over. However, as you can read in this interesting discussion, implementing interfaces with anonymous classes can be pretty useful for testing(Groovyists know it well too), avoiding us to pollute our namespace with unnecessary class names.
So, how can we implement something similar in C#?
So, for the first part, the object creation, what can we do?
Anonymous types:
Anonymous types are pretty limited. We can't simulate methods by adding delegates to them, they're just a "data bag"... so they're of no use for this.
dynamic (keyword) and ExpandoObject. Right, this .Net-C# addition is the way to go. We can add both data and code (using delegates) to these nice objects.
I did some googling regarding "make ExpandoObject implement interface" and found some good posts. This brave guy dared to go down the path of implementing their own Proxy generation code. It's not that System.Reflection.Emit scares me... but I preferred the lazy path of using some existing DynamicProxy solution, and Castle DynamicProxy is the only one I'm slightly familiar with.
So, with this source here, given an interface like this:
we can write code like this:
All it comes down to using an Interface Proxy without Target, and implementing an IInterceptor like this:
The tricky part is that we have to differentiate between access to a method of the interface and access to properties of the interface. For properties access (get or set) Castle's Invocation.Method will point to the get_[propertyName], set_[propertyName] that the C# compiler automatically creates under the covers for properties.
While working on this, I learnt a lot of interesting things about ExpandoObjects (I have to admit I'd never used them before) and this article pretty helped me. They're a really interesting way to provide us with the expansion capabilities of Python or JavaScript objects, but they have a flaw when compared to these objects. Doing something so natural in JavaScript like accessing a method or property based on a string name, that is, something like myPerson["age"], requires some more verbose code in C#, something like:
((IDictionary<string,object>)myPerson)["Age"];
The ExpandoObject implements IDictionary<string, object>, but for some reason (unknown to me) it's using explicit interface implementation instead of implicit, hence the need for that casting. This is event more verbose for method invocations, as we'll need to add one more cast, this time to a compatible delegate type:
((Func<string>)((IDictionary<string,object>)myPerson)["Print"])();
What Groovyists call Closures (they use it as a syntactic concept instead of semantic and admit that the name is confusing, as sometimes these anonymous methods enclose external variables acting as real closures, other times, there's no need for this enclosing, so calling them closures is not fully accurate), are pretty similar to .Net delegates. In both worlds functions are not objects, and the framework and compiler work together to create delegate or Closure objects to wrap functions.
A really beautiful feature is coercing Closures or Maps to implement interfaces. This nice technique makes Java anonymous classes unnecessary, but at the same time reminded me of this Java feature and made me think of it in C# terms.
In spite of all its power, C# 4 does not have anonymous classes. It's strange, cause given all the crazy things the C# compiler does (creating classes for closures, iterator blocks...) adding support for anonymous classes seems pretty easy.
I guess the main reason is that at first sight they don't seem much useful. In Java Anonymous classes are mainly used for the events-listeners thing, in C# the very convenient delegate (named and anonymous) approach is used for event handling, so this use case is over. However, as you can read in this interesting discussion, implementing interfaces with anonymous classes can be pretty useful for testing(Groovyists know it well too), avoiding us to pollute our namespace with unnecessary class names.
So, how can we implement something similar in C#?
- First we want to create an object with x properties and methods without declaring a class for it (going the JavaScript way here :-)
- Second, we'll need to make that normal object implement an interface (compatible with the properties and methods in the object). Seems clear that Dynamic Proxies are the logical choice for this (yes, I have to admit here that it's rather odd that Java (the platform) has included dynamic proxies since a long while and in .Net we still have to depend on third party implementations).
So, for the first part, the object creation, what can we do?
Anonymous types:
var obj = new {
Name : "Xurde",
Age : 15
};
Anonymous types are pretty limited. We can't simulate methods by adding delegates to them, they're just a "data bag"... so they're of no use for this.
dynamic (keyword) and ExpandoObject. Right, this .Net-C# addition is the way to go. We can add both data and code (using delegates) to these nice objects.
I did some googling regarding "make ExpandoObject implement interface" and found some good posts. This brave guy dared to go down the path of implementing their own Proxy generation code. It's not that System.Reflection.Emit scares me... but I preferred the lazy path of using some existing DynamicProxy solution, and Castle DynamicProxy is the only one I'm slightly familiar with.
So, with this source here, given an interface like this:
public interface IPrintable
{
string Print();
string Print2(string st);
string Name
{
get;
set;
}
}
we can write code like this:
dynamic ob1 = new ExpandoObject();
ob1.Name = "Xana";
//notice that we're using ob1 instead of "this", turning the anonymous delegate into a closure
ob1.Print = (Func<string>)(() => "print: " + ob1.Name);
ob1.Print2 = (Func<string, string>)((st) => "print: " + st + ", " + ob1.Name);
IPrintable printableProxy = ExpandoObjectProxyGenerator.GetProxy<IPrintable>(ob1);
//method invocation
Console.WriteLine(printableProxy.Print());
//get property
Console.WriteLine(printableProxy.Name);
//set property
printableProxy.Name = "Xuan";
Console.WriteLine(printableProxy.Name);
All it comes down to using an Interface Proxy without Target, and implementing an IInterceptor like this:
public void Intercept(IInvocation invocation)
{
Console.WriteLine(invocation.Method.Name);
if (invocation.Method.Name.StartsWith("get_"))
//reading a property
{
string propName = invocation.Method.Name.Split(new char[]{'_'})[1];
invocation.ReturnValue = ((IDictionary<string, object>)(this.target))[propName];
}
else if (invocation.Method.Name.StartsWith("set_"))
//setting a property
{
string propName = invocation.Method.Name.Split(new char[]{'_'})[1];
((IDictionary<string, object>)(this.target))[propName] = invocation.Arguments[0];
}
else
//method invocation
invocation.ReturnValue = ((Delegate)(((IDictionary<string, object>)(this.target))[invocation.Method.Name])).DynamicInvoke(invocation.Arguments);
The tricky part is that we have to differentiate between access to a method of the interface and access to properties of the interface. For properties access (get or set) Castle's Invocation.Method will point to the get_[propertyName], set_[propertyName] that the C# compiler automatically creates under the covers for properties.
While working on this, I learnt a lot of interesting things about ExpandoObjects (I have to admit I'd never used them before) and this article pretty helped me. They're a really interesting way to provide us with the expansion capabilities of Python or JavaScript objects, but they have a flaw when compared to these objects. Doing something so natural in JavaScript like accessing a method or property based on a string name, that is, something like myPerson["age"], requires some more verbose code in C#, something like:
((IDictionary<string,object>)myPerson)["Age"];
The ExpandoObject implements IDictionary<string, object>, but for some reason (unknown to me) it's using explicit interface implementation instead of implicit, hence the need for that casting. This is event more verbose for method invocations, as we'll need to add one more cast, this time to a compatible delegate type:
((Func<string>)((IDictionary<string,object>)myPerson)["Print"])();
Tuesday 18 January 2011
Never Let Me Go
Never Let Me Go is an absolutely outstanding film, one of the best that I've watched in a long while. Dystopian elements (but not the classical dystopian neofeudal, orwellian society) in Britain in a non distant past set the stage for one of the harshest and most emotional films in a long time.
Althought there are strong social elements to it: a group of humans bred to serve as donors for others (yes, this part is reminiscent of The Island), human machines whose desires, emotions, ambitions... are of no value to anyone... living beings deprived of any sense of humanity for the rest of the outer world, but portrayed as utterly human for us... it's partially outshined by the emotional side (at least in my experience, even when I'm a rather social aware person).
This emotional, spiritual component, the sense of our existence, our free will, our condition of transitory beings condemned to a short stroll through the long path of our planet (30 years for these poor souls, 70 for the average human... in both cases you get a similar taste of brevity...) absolutely dominates the final impression that it has left on me.
If like me you love Gattaca, not for the SciFic thing, but for the shocking beauty of the story conveyed through the film, a story of self-improvement, of trascending our human limits.... you'll also love this film, not that the story or the final output are similar... but the general feeling throughout the whole film makes me establish a connection.
One of the last shots of the film, when the main female character looks into the eyes of the male character, that lies on the operating table awaiting his imminent death, and they are brought back to the first time when their eyes met, in a not so distant, happy and innocent time... is really overwhelming.
This film has had such a strong effect on me, similar the one that Polytecnique had, in part due to making me aware again of the incredible capacity that some humans have to turn a terrible tragedy into an incredible work of art and beauty.
Althought there are strong social elements to it: a group of humans bred to serve as donors for others (yes, this part is reminiscent of The Island), human machines whose desires, emotions, ambitions... are of no value to anyone... living beings deprived of any sense of humanity for the rest of the outer world, but portrayed as utterly human for us... it's partially outshined by the emotional side (at least in my experience, even when I'm a rather social aware person).
This emotional, spiritual component, the sense of our existence, our free will, our condition of transitory beings condemned to a short stroll through the long path of our planet (30 years for these poor souls, 70 for the average human... in both cases you get a similar taste of brevity...) absolutely dominates the final impression that it has left on me.
If like me you love Gattaca, not for the SciFic thing, but for the shocking beauty of the story conveyed through the film, a story of self-improvement, of trascending our human limits.... you'll also love this film, not that the story or the final output are similar... but the general feeling throughout the whole film makes me establish a connection.
One of the last shots of the film, when the main female character looks into the eyes of the male character, that lies on the operating table awaiting his imminent death, and they are brought back to the first time when their eyes met, in a not so distant, happy and innocent time... is really overwhelming.
This film has had such a strong effect on me, similar the one that Polytecnique had, in part due to making me aware again of the incredible capacity that some humans have to turn a terrible tragedy into an incredible work of art and beauty.
Tuesday 11 January 2011
.Net Garbage Collection basics
Of course I'm not not by far an expert on Garbage Collectors, but I have a basic understanding of how .Net GC works. As with many other of my surface knowledge areas, it's subject to the same cycle of "learn - don't need it for a while, so forget - need it again, so relearn again". The relearn part tends to be painful, cause you're aware of being trying to find the same links and articles that you had already read some time ago... So summing up some of the great info around the net, adding the pertinent links and my own conclusions could save me a lot of time in the next occasion (and posting it will force me to complete it).
While writing it I've decided to split this GC entry in two separate posts. This one will deal with the GC internals, and next one with what all this means for us, developers.
Some theory first
.Net has a generational garbage collector (same has mono since version 2.8) . When a memory allocation takes place (the new operator, just before the constructor gets called) and there's not enough memory available, the GC routine runs. Depending on the kind of GC that you have selected (Workstation or Server) the GC code runs on a separate thread or on the same thread that tried to do the allocation. When running on a separate thread, we talk about concurrent garbage collection, which means that during good part of the GC the other threads can continue to run and there should not be a noticeable "freezing effect". This is an improvement over the traditional approach of "stop the world" while a GC is running. With .Net 4 Concurrent GC was improved and renamed to Background GC, Background garbage collection, making the chances of noticeable stops even lower. Basically, in the pre BG Collection times, if when the GC is going through the Gen 2 objects (that could take some good time) the other normal threads running in parallel and doing new allocations fill the segment where new objects are placed (the ephemeral one, will talk about it later), these threads would get stuck, cause they have no more space for their new objects. Now, with the background collection algorithm, all threads (including the one doing the collection) would get halted at this point and a new GC would be launched that would just take care of this ephemeral segment (this ephemeral segment collections are now called foreground collections), releasing space and allowing the threads (normal application threads and the background collection algorithm thread) to run on.
.Net heap consists of 2 heaps, the small object heap (SOH) and the large object heap (where objects larger than 85000 bytes are stored). Objects in the LOH belong to the Generation 2 (of course Gen 2 also contains SOH objects). Generation 2 objects are only collected when a full garbage collection takes place. Garbage Collections that only take care of Generation 0 and 1 objects are called ephemeral collections in the .Net jargon, should be very fast (no long paths to traverse to build the graph of reachable objects) and because of this won't be launched as Concurrent-Background collections. The segment (16 MBs in current implementation) where Gen 0 an Gen 1 objects are allocated is also called the ephemeral segment, and is always the last allocated segment.
Ephemeral generations must be allocated in the memory segment that is known as the ephemeral segment. Each new segment acquired by the garbage collector becomes the new ephemeral segment and contains the objects that survived a generation 0 garbage collection. The old ephemeral segment becomes the new generation 2 segment.
full text
While the space in the SOH is compacted after a GC is run, it's not the same with the LOH space, this means that non careful allocation of large objects can lead us to fragmentation problems. Compacting the SOH involves great performance gains when compared to memory allocations in traditional native application. Allocations in the SOH are done linearly, the runtime maintains a pointer to the next free position in the SOH (in the ephemeral segment) so the next allocation is directly done there, contrary to allocations in native applications, where it's necessary to find a free memory area. Also, this means that objects created one after the other get allocated contiguously which will also improve performance. Check the excellent Generational GC Performance Optimizations section here for further info.
Finalization
Garbage collection is more than just releasing memory, it also involves releasing unmanaged resources (windows handlers...). We should put the code for releasing these resources in a Finalize method, so that the runtime can release them even if we forget about it.
So, how do the memory release and resource release work together?
It's pretty well explained in the articles and questions-answers listed below. When the GC runs it assumes that all objects in the heap are garbage, so to find which objects should be reclassified as not garbage it begins walking the GC roots (stack variables and global variables mainly) to form a graph of reachable objects. Once done, all objects not in this graph are not accessible by the application and correctly classed as garbage. It's now, when before releasing that memory, the Finalization things comes into play. The GC checks if these unused objects are referenced from the Finalization queue (all objects overriding the Finalize method inherited from the Object class are added to this list while being created), those for which the answer is Yes are removed from the Finalization queue and added to a new list, the freachable queue (that is also a GC root, meaning that objects referenced by your finalizable object are also prevented from being collected at this point), and are no longer considered garbage. That means their memory is not reclaimed in this collection. Once the GC finishes, a special application thread, the Finalizer Thread, will be waken up by the fact of having new entries in the freachable queue and will start to run the Finalize method for the objects there. Once the Finalize for an object is run, the object is removed from the freachable queue, so next time the GC runs it won't be added to the graph, and the object memory will be released.
further reading:
While writing it I've decided to split this GC entry in two separate posts. This one will deal with the GC internals, and next one with what all this means for us, developers.
Some theory first
.Net has a generational garbage collector (same has mono since version 2.8) . When a memory allocation takes place (the new operator, just before the constructor gets called) and there's not enough memory available, the GC routine runs. Depending on the kind of GC that you have selected (Workstation or Server) the GC code runs on a separate thread or on the same thread that tried to do the allocation. When running on a separate thread, we talk about concurrent garbage collection, which means that during good part of the GC the other threads can continue to run and there should not be a noticeable "freezing effect". This is an improvement over the traditional approach of "stop the world" while a GC is running. With .Net 4 Concurrent GC was improved and renamed to Background GC, Background garbage collection, making the chances of noticeable stops even lower. Basically, in the pre BG Collection times, if when the GC is going through the Gen 2 objects (that could take some good time) the other normal threads running in parallel and doing new allocations fill the segment where new objects are placed (the ephemeral one, will talk about it later), these threads would get stuck, cause they have no more space for their new objects. Now, with the background collection algorithm, all threads (including the one doing the collection) would get halted at this point and a new GC would be launched that would just take care of this ephemeral segment (this ephemeral segment collections are now called foreground collections), releasing space and allowing the threads (normal application threads and the background collection algorithm thread) to run on.
.Net heap consists of 2 heaps, the small object heap (SOH) and the large object heap (where objects larger than 85000 bytes are stored). Objects in the LOH belong to the Generation 2 (of course Gen 2 also contains SOH objects). Generation 2 objects are only collected when a full garbage collection takes place. Garbage Collections that only take care of Generation 0 and 1 objects are called ephemeral collections in the .Net jargon, should be very fast (no long paths to traverse to build the graph of reachable objects) and because of this won't be launched as Concurrent-Background collections. The segment (16 MBs in current implementation) where Gen 0 an Gen 1 objects are allocated is also called the ephemeral segment, and is always the last allocated segment.
Ephemeral generations must be allocated in the memory segment that is known as the ephemeral segment. Each new segment acquired by the garbage collector becomes the new ephemeral segment and contains the objects that survived a generation 0 garbage collection. The old ephemeral segment becomes the new generation 2 segment.
full text
While the space in the SOH is compacted after a GC is run, it's not the same with the LOH space, this means that non careful allocation of large objects can lead us to fragmentation problems. Compacting the SOH involves great performance gains when compared to memory allocations in traditional native application. Allocations in the SOH are done linearly, the runtime maintains a pointer to the next free position in the SOH (in the ephemeral segment) so the next allocation is directly done there, contrary to allocations in native applications, where it's necessary to find a free memory area. Also, this means that objects created one after the other get allocated contiguously which will also improve performance. Check the excellent Generational GC Performance Optimizations section here for further info.
Finalization
Garbage collection is more than just releasing memory, it also involves releasing unmanaged resources (windows handlers...). We should put the code for releasing these resources in a Finalize method, so that the runtime can release them even if we forget about it.
So, how do the memory release and resource release work together?
It's pretty well explained in the articles and questions-answers listed below. When the GC runs it assumes that all objects in the heap are garbage, so to find which objects should be reclassified as not garbage it begins walking the GC roots (stack variables and global variables mainly) to form a graph of reachable objects. Once done, all objects not in this graph are not accessible by the application and correctly classed as garbage. It's now, when before releasing that memory, the Finalization things comes into play. The GC checks if these unused objects are referenced from the Finalization queue (all objects overriding the Finalize method inherited from the Object class are added to this list while being created), those for which the answer is Yes are removed from the Finalization queue and added to a new list, the freachable queue (that is also a GC root, meaning that objects referenced by your finalizable object are also prevented from being collected at this point), and are no longer considered garbage. That means their memory is not reclaimed in this collection. Once the GC finishes, a special application thread, the Finalizer Thread, will be waken up by the fact of having new entries in the freachable queue and will start to run the Finalize method for the objects there. Once the Finalize for an object is run, the object is removed from the freachable queue, so next time the GC runs it won't be added to the graph, and the object memory will be released.
further reading:
- Garbage Collection: Automatic Memory Management in the Microsoft .NET Framework
- When does CLR say that an object has a finalizer?
- Fundamentals of Garbage Collection
- Difference between background and concurrent garbage collection?
- how the mark and sweep phases of .NET GC can run concurrently with application threads?
- Background and Foreground GC in .NET 4
- Maoni (aka the GC queen) blog
- .NET Garbage Collector PopQuiz
- Very complete and not too dense article
- Very interesting article that I didn't come across with until March 2012
- No entry in this blog would be complete without a link to wikipedia :-)
Friday 7 January 2011
Van Diemen's Land
Van Diemen's Land was the name given to Tasmania by early European settlers, and is also the title for a harsh and dark 2009 Australian film, renamed (rightly I think) in Spain to Tasmania. Based on true events, tells the story of seven English, Irish and Scottish convicts that scape from the brutal penal settlement where they were convicted.
A story where initial hopes and comradeship give way to despair, distrust and murder, showing us the worst parts of the human condition. Attempting to survive in the wet, mountainous, unpopulated west part of Tasmania while making their way to the East turns into an almost impossible task.
Thought both films are set in very different time periods and the initial circumstances have little in common, I think it's easy to find that it bears a strong resemblance to The Road. Both films share the same unsettling gloomy atmosphere, the scape to nowhere feeling and the resort to cannibalism thing.
All in all, I pretty recommend this film, and once you've watched, it would be a good idea to read a bit about the real main character.
A story where initial hopes and comradeship give way to despair, distrust and murder, showing us the worst parts of the human condition. Attempting to survive in the wet, mountainous, unpopulated west part of Tasmania while making their way to the East turns into an almost impossible task.
Thought both films are set in very different time periods and the initial circumstances have little in common, I think it's easy to find that it bears a strong resemblance to The Road. Both films share the same unsettling gloomy atmosphere, the scape to nowhere feeling and the resort to cannibalism thing.
All in all, I pretty recommend this film, and once you've watched, it would be a good idea to read a bit about the real main character.
Wednesday 5 January 2011
Florence
I was lucky enough to be in Florence for a few days some weeks ago.
Everything you've read and heard about how stunningly beautiful this Renaissance jewel is holds true. Thought I didn't experience the Stendhal Syndrome, I have to admit that my first view of the Cathedral square absolutely overwhelmed me. It was not Brunelleschi's Duomo what impressed me so much (from so near you're not so aware of the size of the dome), but all the incredibly beautiful marble panels (in white, green and red) covering the Cathedral, Giotto's Tower and Baptistery. These marble panels with similar patterns cover other buildings like Santa Croce, Santa Maria Novella and San Miniato al Monte, and for me are one of the more distinctive marks of this city.
Well, there are tons of information freely available on the net to help you prepare your trip there, so I'm not going to repeat in my broken English what many others have said much better, so I'll just give a few personal advices.
In one of my evenings there, when cold and darkness already ruled the city and wandering around the streets was no longer so appealing, I had a look into Palazzo Strozzi, finding a really interesting exhibition, Portraits and Power. Pretty interesting stuff there that kept me busy for more than 1 hour. From all the works displayed there I'd like to specially mention the ones by Rineke Dijkstra, Wang Qingsong and above all The yes men (men, you're brave to confront villains no matter how powerful they are).
Everything you've read and heard about how stunningly beautiful this Renaissance jewel is holds true. Thought I didn't experience the Stendhal Syndrome, I have to admit that my first view of the Cathedral square absolutely overwhelmed me. It was not Brunelleschi's Duomo what impressed me so much (from so near you're not so aware of the size of the dome), but all the incredibly beautiful marble panels (in white, green and red) covering the Cathedral, Giotto's Tower and Baptistery. These marble panels with similar patterns cover other buildings like Santa Croce, Santa Maria Novella and San Miniato al Monte, and for me are one of the more distinctive marks of this city.
Well, there are tons of information freely available on the net to help you prepare your trip there, so I'm not going to repeat in my broken English what many others have said much better, so I'll just give a few personal advices.
- Queues: Sure you've read about the long queues for access to the Uffizi or the Duomo, and maybe you're considering reserving your tickets in advance (paying some extra 4 euros I think) to avoid the line ups. The queues seem to be real in spring and summer, but if you go there in December like I did, you'll have no problem at all, in less than 5 minutes you'll be into any of the big attractions, so you can save that extra money for a gelatto or a crostata
- Cathedral's Dome paintings (Vasari - Zuccari frescoes): Yes, everyone has heard about the impressive work done by Brunelleschi building that astonishing dome, but it was the paintings covering it and done one century later what really stunned me. 3600 square meters to represent The Last Judgement, it's absolutely breathtaking, much more appealing to me than Michel Angelo's one in The Sistine Chapel. The lower sections of this representation, full of demons and tortured poor human souls... remind me a lot of Hieronymus Bosch, so that's why I think I felt so moved by this.
- San Miniato al Monte: Well, moving away a bit of the city centre to go to Piazzale Michelangelo (Michelangelo square) is a rather well known activity. The square itself has little interest, but the views of the city from this small hill are really beautiful. The stairs to get up there, viewing an astonishing city from a height on the opposite river bank, all the people gathered there capturing instants for eternity with their cameras... brought to my mind memories from Prague Castle, Budapest castle or Rome's Gianicolo. Well, the thing is that if you climb the hill for other 5 minutes more you get to a small Romanesque church (with one of those dreamlike marble facades) called San Miniato al Monte. Cross the wooden door and you'll enter a dark, silent, lonely, ancient world, overlooked by an impressive Byzantine like mosaic and the mysterious Cappella del Crocifisso. I bet a spiritual person well could have a mystical experience here :-)
In one of my evenings there, when cold and darkness already ruled the city and wandering around the streets was no longer so appealing, I had a look into Palazzo Strozzi, finding a really interesting exhibition, Portraits and Power. Pretty interesting stuff there that kept me busy for more than 1 hour. From all the works displayed there I'd like to specially mention the ones by Rineke Dijkstra, Wang Qingsong and above all The yes men (men, you're brave to confront villains no matter how powerful they are).
Subscribe to:
Posts (Atom)
