Awkward Coder

I'm working on an app with lots of asynchronous stream processing done using Rx (Reactive Extensions) - IObservable<T> method. We were discussing the other day whether to replace the implementations which only return a single data item via the Rx stream with the more standard TPL (Task Parallel Library) Task<T> method. We came to the conclusion we wouldn't make the switch for a couple reasons, firstly keeping the code consistency, we're using Rx everywhere for async so why change; and secondly with a possibly more important reason because performance isn't an issue (at the moment). Then I thought.... What's the performance difference between IObservable<T> and Task <T>  for a single async invocation? A simple console app should do, running IObservable<T> vs Task<T> and the quickest wins - reminds me of Celebrity Deathmatch ... Firstly we need something to test, calculating the first 100 primes: All I need now is...

I'm currently working on a project with @HamishDotNet  & @LordHanson where we make heavy use of Rx (Reactive Extensions) for processing streams of data which are generated asynchronously. We have multiple pipeline processes based around an Rx stream, they look something like this: The method Sequence returns an instance of IObservable<T>  which is then acted upon by 4 or 5 methods before the Subscriber is called, some of these methods might mutate the state along the way. The important part is the idea of the pipeline to process the Rx stream as it is generated by the asynchronous Sequence method. So what I wanted to do is log what's going on - how long each step takes (in the pipeline) as well as how long the Rx stream is alive and when the stream generates a value. The issue we have is we don't want to overly modify the code just support such logging\telemetry. I don't want to end up with something like this: Don't get me wrong, if I had only ...

I was asked the other week how I'd implement a view-model that binds to two combo boxes in the view, where a selection in one affects the other. I've called it category & sub-category combo boxes but I guess it could also be called parent-child combo boxes. Now I don't perceive this as particularly complex to do, but I was asked how would I do it? Would I use two seperate lists and how would I avoid stack overflow exceptions when raising property changed events. The UI looks like this: The categories are represented by the top combo box: The sub categories are represented by the bottom combo box: You should be able to infer from the screen shots that each category has a set of sub-categories, the only special category is All - when selected then all sub categories are displayed, as shown above. So when Category A is selected then only the related sub-categories should be displayed: I used a dictionary &  linq to achieve the behaviour required...

I've blogged before about the perf improvements of using the CallerMemberName attribute over an expression tree to avoid using hard-coded property strings names when firing the PropertyChanged event on INotifyPropertyChanged. This works great for the majority  simple cases. Setting the property &  notifying :  or just notifying: The problem is when it's not the simple case - when setting a property on a view model and wanting to force the updating of another property (on the view model) it doesn't work obviously. At this point I'm thinking I'll go back to the expression tree approach.

Ran into a problem today, wanting to get the assembly that started the an application. Now this isn't a tricky problem just had to bend it to my will :) We have a code-base shared across platforms (WPF & Silverlight) via project linker  and we need the ability to get the executable assembly, MSDN describes this as 't he assembly that is the process executable in the default application domain ' ans this is accessed via the  GetEntryAssembly method. The problem is purely because GetEntryAssembly is not supported in Silverlight so we had to come up with away to get the assembly version of the startup dll in the Silverlight XAP. The following code is contained in a library (framework) assembly which know nothing about which assembly (executable) was loaded into the default application domain. So I came up with the idea of using the Application.Current property:

I was looking at the download figures for FINDaPAD in the windows phone marketplace today and noticed another spike in downloads on the 26th of June, it had the  same pattern as the spike on the 20th of May. Why are we getting such high downloads on these days? Normally we get a much more modest download rate, 150 per month - not bad a for free app only targeting the UK marketplace: The only reason I can think of is - we've been featured twice in the windows phone marketplace. It would kind of make sense as the second peak is considerably smaller than the first indicating a subsequent placement in the marketplace. It would have been nice to get some heads-up before being featured, even if it's only for personal vanity :) So if you want to get your app featured in the marketplace make sure you complete all the artwork requirements. These can be updated at any time:

Okay so the title is slightly misleading, I'm still writing   code in C# (.Net) but I'm no longer manually building the solution inside Visual Studio, no F5, no Ctrl+Shift+B... You might be thinking huh? What I mean is I no longer go round the continual cycle of  write code, compile code, test code, refactor code etc. We've managed to remove the compile & test  phases from the development process and I can't elaborate how liberating this is. This has been achieved by using a continuous testing framework - tests are executed as you write the code. I found this article back from 2007 stating all the benefits you'll get from using such a framework - ' It’s turning the knob on Test Driven Development up to 11 ' - so true... I'm currently working in an environment where the main constraint is not the tools we're using but the underlying OS. We're stuck with 32 bit Win XP machines for at least the short to medium term and our biggest pro...