Friday, February 05, 2016

Modifying collections from different threads and still binding it via WPF

angry developer This post is discussing the solution to the NotSupportedException "This type of CollectionView does not support changes to its SourceCollection from a thread different from the Dispatcher thread" and also the InvalidOperationException "An ItemsControl is inconsistent with its items source".

In the first case you want to bind in Windows Presentation Foundation a collection property from your viewmodel and it says no. What happens is that you are using a BindingList<T> or an ObservableCollection<T> and the binding system is using in the background a CollectionView that wraps it which does not support changes via multiple threads. The solution to this is rather simple: use this piece of code:
BindingOperations.EnableCollectionSynchronization(collection, lockObject);
This short blog post from Florent Pellet explains things a little, but that is ending on a dire note: The ViewModel becomes dependent on the view It also suggests that you need to create a lock object for each UI thread, if you have more.

This works in .NET 4.5 and that is the reason that when you are looking the exception up you get all kind of answers that either suggest you invoke any changes on the Dispatcher UI thread (which I believe is against the idea of having a viewmodel) or weird bastardizations of the collection classes used, like trying to invoke the events for list changes on the dispatcher of the invoking delegate. I've tried that and I got the second InvalidOperationException exception that I will be covering later on :)

But let's go further and examine what is going on. If you look at the method declaration, EnableCollectionSynchronization also allows specifying a synchronization callback, something that you could use to manage weird custom collection classes. The Remarks sections says When you call this overload of the EnableCollectionSynchronization(IEnumerable, Object) method, the system locks the collection when you access it, which implies you are losing some performance, but not much else. In case you have many parallel threads that are modifying your collection, you need to lock it, anyway. You may, of course, create your own high performance system of changing a collection and, maybe, run a separate method to marshal changes from your private data structure to the UI bound one.

Now, the InvalidOperationException "An ItemsControl is inconsistent with its items source" is thrown when the ItemsSource property has become out of sync with the Items property, which is usually generated by the ItemsControl. So when I tried to create my own badass collection class, I managed to avoid the first exception and I got this one. The same solution applies to both cases:
BindingOperations.EnableCollectionSynchronization(collection, lockObject);
Funny enough, you have to run this piece of code on the Dispatcher UI thread.


But where to use it? It would be rather simple to use it in the viewodel constructor, using the ((ICollection)collection)SyncRoot object, or even in the constructor of a class that inherits from either BindingList or ObservableCollection and has nothing but this type of initialization. I believe that, since this is a binding issues, something within WPF, then the binding system should handle it, like some type of synchronizing Binding. For a second I thought that the IsAsync property of the Binding class would solve this by itself, but it wouldn't work. Also, Binding doesn't have any methods to override and BindingBase is an abstract class with internal methods to implement, which of course doesn't work. Otherwise it would have been OK, I believe, to create a special SynchronizedCollectionBinding class that enables collection synchronization at bind time. BTW, if you are thinking to implement everything starting with MarkupExtension, forget it. The Binding class is a bit hardcoded in Visual Studio and it wouldn't actually work as expected.

That's it, folks!

Wednesday, February 03, 2016

I presented an introduction on Reactive Extensions at Impact Hub

Reactive Extensions logo Today I was the third presenter in the ReactiveX in Action event, held at Impact Hub, Bucharest. The presentation did not go as well as planned, but was relatively OK. I have to say that probably, after a while, giving talks to so many people turns from terrifying to exciting and then to addictive. Also, you really learn things better when you are preparing to teach them later, rather than just perusing them.

I will be holding the exact same presentation, hopefully with a better performance, on the 9th of February, at ADCES.

For those interested in what I did, it was a code only demo of a dictionary lookup WPF application written in .NET C#. In the ideal code that you can download from Codeplex, there are three projects that do the exact same thing:
  1. The first project is a "classic" program that follows the requirements.
  2. The second is a Reactive Extensions implementation.
  3. The third is a Reactive Extensions implementation written in the MVVM style.

The application has a text field and a listbox. When changing the text of the field, a web service is called to return a list of all words starting with the typed text and list them in the listbox, on the UI thread. It has to catch exceptions, throttle the input, so that you can write a text and only access the web service when you stop typing, implement a timeout if the call takes too long, make sure that no two subsequent calls are being made with the same text argument, retry three times the network call if it fails for any of the uncaught exceptions. There is a "debug" listbox as well as a button that should also result in a web service query.

Unfortunately, the code that you are downloading is the final version, not the simple one that I am writing live during the presentation. In effect, that means you don't understand the massive size reduction and simplification of the code, because of all the extra debugging code. Join me at the ADCES presentation (and together we can rule the galaxy) for the full demo.

Also, I intend to add something to the demo if I have the time and that is unit testing, showing the power of the scheduler paradigm in Reactive Extensions. Wish me luck!

Monday, February 01, 2016

I was at FOSDEM'16

Long story short: I thought FOSDEM 2016 was terribly non-technical.

The entire conference took place at the ULB Solbosch Campus in Brussels, Belgium, which is composed of several buildings in which many rooms are being used for presentations. That meant that not only you had to plan the speeches that you wanted to attend to, but also consider the time it took to move from one building to another (in the cold and rain). Add to this the fact that the space was still insufficient for most talks, and if you didn't get there before the talk started, it wasn't uncommon to find the room full and be turned down at the door for security reasons (meaning fire hazards and the likes, not stupid terrorism). I thought the mobile app FOSDEM Companion was very helpful in keeping track of what is what and where and when.

The talks themselves, though, were mostly 20-25 minutes long. While some reached to 45 minutes, most of them were short presentations of one product or another. Someone would speak in front of a Powerpoint (or some alternative) slide and the most common template was: "I am X I work at Y and we are doing product Z. Here is a history of the product, here is what it can do for you and you can find more at these links." They were open source and free, alright, but other than that it felt like it was a marketing conference, not a technical one. I have seen only one presentation that included actual code.

This doesn't mean I didn't enjoy myself. I've met old friends and some of the presentations were really interesting. I was particularly impressed by something called Ring, which is a completely peer to peer and securely encrypted communication system. Basically it allows you to find people, talk to them (via text, sound, video), while having no central server. It was something that I was looking for and that uses DHT as a discovery mechanism.

So my conclusion is that if you are not there for a specific project or topic, so that you end up finding the people that are interested in the same thing and network with them, FOSDEM is pretty superficial. The talks were recorded and the videos will slowly appear on the FOSDEM video archive site, so actually going there just to see the presentations alone might not be necessary. Being from a slightly different technical domain, I wasn't interested in socialization, and I think that was my biggest mistake.

The people there looked interesting. A friend of mine summarized it well: "one of the few places where there is a queue at the men's bathrooms and not at the women's". There were of course plenty of facially haired, pony-tailed, black leather wearing, Linux laptop carrying hackers running around, but most of the people there didn't look that young or that "hacky". In fact, I think the age average was probably around 40.

That's about it for my FOSDEM report. If you need any more information, leave me a comment and I will fill any holes in the description.

Update:
The talks that I went to and I liked were these:

The Last Policeman, by Ben H. Winters

Book cover This book was recommended by Jeff Atwood, of Coding Horror and Stack Overflow fame. He liked it, I wasn't impressed. In The Last Policeman, Ben H. Winters attempts to describe a world that is powerlessly waiting for the arrival and impact of a 7km wide asteroid. While smaller than the one that killed the dinosaurs off, it would still pretty much end human civilization and most of the life on Earth. As a result, people are killing themselves in depression, quit jobs to "go bucket list", nothing is working, nothing gets repaired, etc. In all of this, a detective is trying to solve a case that looks like just another suicide, but he feels it's not. It is an interesting concept and it was well written by Winters, but I had difficulty believing in the world he was describing. More than that, except rumors of something Iran is planning there is no mention of any other country. I believe that in this situation a lot of people would inertially and routinely continue what they were doing until they figured out that it doesn't make sense (and that probably it didn't make sense to begin with), but there would certainly be more aggressive social changes that the author completely ignores. Plus that "going bucket list" would certainly become frustrating once you can't go on a cruise because no one is sailing the thing or you can't enjoy your favorite food because the restaurant got closed.

Worse than that, at the end of the book I was pretty satisfied with it. It was short, to the point and while not perfect, it was enjoyable. And then I learn that it is part of a trilogy. This automatically diminishes the act of reading it somehow and the book entire by the fact that I can't convince myself to read the other two books. So yeah, bottom line: I thought it was kind of average.

Tuesday, January 26, 2016

Write Right!: Creative Writing Using Storytelling Techniques, by Kendall Haven

Book cover Write Right! is a monster. It goes through every step of writing a book, including the one that the author, Kendal Haven, considers the most important: editing. Then, in its second half, it contains exercises for improving writing. The intended audience of this book is teachers of creative writing, not just beginner writers, so that makes it even more valuable.

The mystery for me was how can someone write about captivating and engaging writing in a book as dry as Creative Writing Using Storytelling Techniques. I understand it is mostly a manual, but it was really difficult to go through it, as it was full of information start to finish. Now I must reread it at speed and make a summary of the techniques in order to even begin to absorb the huge amount of very useful information in the work. Not to mention actually doing the exercises at the end.

What I really liked about this book is that it is very algorithmic. At every page I was considering - and still am - how I might codify this into a software to help me evaluate a piece of literature and maybe even suggest improvements automatically. If I am to extract an essential idea of the work it would be "editing is very important". The author acknowledges the need to write fast, from your gut, to lay the words out there, not even considering spelling or grammar, just vomit your thoughts onto the page, but then he submits that the process of evaluating each scene, each chapter and the book for structure, wording, verb uses, sense involvement, specificity of language, action, dialogue, sequels (not book sequels, but that thing that details what characters think and feel about what just happened), etc. is perhaps the most important in translating that story that you have into an interesting book to read. And after getting a final version you are happy about, he makes you eliminate 15% of the words. Ruthless! :)

Let me make this clear, though: writing is damn tough. It consists of two parts: observing the world and describing the world. In a recent post I was complaining at how bad I am at the former, but this book makes it clear how complex is the latter. Making the written word express what is in your brain at the moment of creation is extremely difficult and complicated. This book helps in defining exactly what that is and give you tools to do it and improve on doing it. A great tool!

To sum it up: This is not light reading. It is a manual for writing teachers (what the hell are those? I wish I had some in school). It helps tremendously if you are self-taught, also. It requires multiple readings or at least a summarizing effort at the end, to structure it in a way that makes it easy using it as a reference. And then, of course, are the exercises for improving writing which take the second half of the book

Thursday, January 21, 2016

Patterns for Parallel Programming: Understanding and Applying Parallel Patterns with the .NET Framework 4, by Stephen Toub

Patterns of Parallel Programming Stephen Toub wrote this document, as he calls it, but that is so full of useful information that it can be considered a reference book. A 118 pages PDF, Patterns for Parallel Programming taught me a lot of things about .NET parallel programming (although most of them I should have known already :-().

Toub is a program manager lead on the Parallel Computing Platform team at Microsoft, the smart people that gave us Task<T>, Parallel, but also await/async. The team was formed in 2006 and it had the responsibility of helping Microsoft get ready for the shift to multicore and many-core. They had broad responsibility around the company but were centered in the Developer Division because they believed the impact of this fundamental shift in how programming is done was mostly going to be on software developers.

It is important to understand that this document was last updated in 2010 and still some of the stuff there was new to me. However, some of the concepts detailed in there are timeless, like what is important to share and distribute in a parallel programming scenario. The end of the document is filled with advanced code that I would have trouble understanding even after reading this, that is why I believe you should keep this PDF somewhere close, in order to reread relevant parts when doing parallel programming. The document is free to download from Microsoft and I highly recommend it to all .NET developers out there.

Date Published: 7/16/2010 File Size: 1.5 MB

Tuesday, January 19, 2016

SpaceX first stage landings on a sea barge: Three failures should be a strong indicator of a design flaw

Falcon 9 first stage explodes on barge In January 2016 SpaceX made history by landing the first stage of a rocket that they have just launched. I know, Blue Origin did it first, but SpaceX rockets are designed for GEO orbits, while Bezos' reusable rocket is for LEO, so different animals. However, they have tried doing the same three times, last time just yesterday, only landing on a special barge at sea. Each time this have failed. But let's watch the three attempts, see what's going on.

First time, a year ago, January 2015, you can see that something was wrong with the way the stage came down, it was already angled and the horizontal speeds were really high.


Second time, three months later in April 2015, it almost got it right:


Third time, yesterday, 18 December 2016, it actually landed, then a landing leg gave out:


But what happened? Each time the stage reached the landing spot, each time in a vertical position and with low vertical speeds. Every time the engine exploded it did when the stage tried to stop and fell over. Wouldn't a specialized grabbing mechanism have prevented some of these accidents? Maybe even the first one!

Now, I understand that the purpose of SpaceX is to have a first stage that can land anywhere, and so they must rely on their device only, assuming nothing of the landing site, but once they go through the engineering issues, just catch it in a net, intersect three metal cables to support the upper part of the stage, do something. Look of those things, slowly falling down: you want to jump and catch them, like you would a drunken friend. Make your rocket understand it's not alone, Elon, that it's got our support! :)

Seriously now, I can't even imagine what would happen if the wind started blowing harder while the rocket tried to land on the barge. Since you have a specialized landing vehicle, make it better. The rocketry is fine, it is time to work on the support infrastructure with just as much aplomb and creativity.