Skip to content

Iloggable

Dream for REST and async

I've been doing a lot of work inside of MindTouch Dream as of late over at MindTouch and i'm really digging it. Steve's put together an awesome framework for doing asynchronous programming on .NET and for being able to treat all access as RESTful resources in your server side code.

Now, coming from a very Dependency Injection heavy design philosophy, Dream has been a bit of an adjustment for me, but the capabilities of Dream, especially the coroutine approach for dealing with requests, is very powerful and fairly intuitive, once you get your head around it.

In an effort to ease the Dream learning curve and cement my understanding of the code base, I'll be blogging articles about it as I go along, and cross-posting them to the MindTouch developer wiki as well. My first article was a continuation of Steve's Asynchronicity library series, this one about coroutines (read: yield) in Dream.

I've been using the C# Web Server project for my REST work up until recently, but I'm currently in the process of migrating it over to Dream. It just removes all the legwork and fits much better into the async workflow of the rest of notify.me.

Clearly I am biased, but seriously, if you need to build REST interfaces in .NET, Dream beats anything you can roll on your own in a reasonable amount of time, and definitely is about 1000% more powerful than trying to force WCF down the REST or even POX path.

  • in geek
  • 3 min read

C# 3.0 language features vs. Java's OS community

I've been in a constant struggle for a number of years and it's a battle between wanting to program in C# but envying the variety of open source projects available on the JVM.

And this isn't so much a windows/linux thing, because mono vs. native .NET is really the least of my problems. The mono team has done an amazing job letting me write code without worry in Visual Studio and deploy on linux. With mono 2.0 just out, i have no code left that doesn't just work when i copy the dll's over. The fact that i do a lot of .NET on linux is not a pain point for me.

But when it comes to open source libraries, the eco-system on java is just so much richer. Think of an API or protocol and google it for java and you'll find it. Do the same for .NET and your chances are much smaller. And if you find it, chances are it's a port of J_foo_ to N_foo_. So you could say, I've got library envy.

So why not just go java? Well, there are a number of C# language features that many might accuse of being "sugar", but i find them incredibly useful to express my intent in code. Here are the things that keep me in C# 3.0:

  • Delegates, especially anonymous delegates. For concurrent programming, they are essential
  • Events. Sure, they are just more sugar on top of delegates, but for async, having the ability to easily declare, subscribe and fire events are a god sent.
  • Properties. Public fields can't be part of an interface and if you ever need to attach observation to the value change, then fields are a dead end. And seriously, getFoo()/setFoo() is busy work for the compiler. It's less readable and more error prone.
  • Lambda expressions. Yes, i want a taste of functional with my imperative
  • LINQ. And i don't mean LINQ to SQL. This isn't about databases, this is dealing with collections, doing map, reduce, filter and projection. Yeah, you can loop by hand, but it's so much less expressive or readable.
  • var. Type inference is the way to go for static type languages. Less clutter, still strongly typed. You can get most of the benefits of dynamic languages with type inference and not have to give up type safety. I hope that we get closer to duck typing tho.
  • Dead easy interop with native processes. No, my VM is not some abstract world that shan't know about its environment. It's just a better way to code, so let me do machine specific things without making me pay penance in blood for it.
  • A language with much more innovation. Ugh, I know MS made innovation a dirty word in their anti-trust battles, but it's really true for C#. C#2.0's best features were aped by Java 5 and C#3.0 is once again miles ahead in new capabilities. People might argue whether that's a good thing, but it can't be disputed that C# is innovating much more rapidly.

So there you go, I'm a C# fan boy. I admit it. But still, i got this library envy. What's a guy to do? I see two possible paths, C# on the JVM or java libs on mono. Both are mostly possible, but I really need to do some spikes to know where the pain starts with the two options.

C# on the JVM: Mainsoft Grasshopper

Author in C#, cross-compile IL into java byte code. Mainsoft is apparently collaborating with the mono guys, so generally what makes it into mono in terms of language features will make it into Grasshopper. Need to take some of my projects and see what happens when i try this.

Java on C#: IKVM

Compile java code into .NET IL using IKVM. This is dependent on the state and compatibility of IKVM and Java. Need to take some popular java open source projects and see what happens when i try to build them using IKVM.

Either sounds like inviting a life of debugging edge cases that no one else cares about. But I don't see a better option. Am I overlooking some other path? Should i stop whining and just go java? Is the OS situation not nearly as bad on .NET as i make it out to be and I can just continue as is? Things that keep me up at night.

Synchronicity Kills

Finally got around to starting my blogging about the technology being built for notify.me.

It's pretty funny that both my Mindtouch and my notify.me coding revolve around heterogenous, asynchronous programming to achieve highly scalable concurrency. Since i started working on notify.me before I started at Mindtouch and dug deep into Dream, the approaches are currently rather different, although I think i can bring lessons learned from either to the other as things progress.

  • in net
  • 1 min read

IEnumerable.ForEach()

I keep wanting to do ForEach() on a collection, and noticed that it was inconsistent whether that extension method was available or not. I always figured that i wasn't importing the right namespace, and blamed ReSharper for not being smart enough to figure out what namespace I was missing. So I finally googled the problem only to find this. Turns out ForEach() isn't on IEnumerable, only on Array and List. Meh. But thanks to Dave, i now have it in my core assembly.

  • in net, geek
  • 2 min read

A case for TDD

I know, it's been rather quiet here lately. I've just been slammed with coding, so writing things up is falling behind. In addition, my blogging time's going to be split between techblog.notify.me and www.mindtouch.com/blog. And I'm behind on both of those as well. I should have some fun Dream and DekiScript stuff for the mindtouch blog and some asynchronous programming for the notify.me blog soon. As soon as i can get myself to stop coding again.

So what makes me stop coding for a minute to babble on? It's just a quick case studio of why TDD is important.

I've been an Inversion of Control/Dependency Injection for about a year and a half, and while I've eased my way into it, I'm pretty much at the "an interface for every class" stage of having everything abstracted so i can easily mock things. But here and there, I take in third party assemblies for my projects. And most of the time, they are not well interfaced. And generally I try to create a facade that is interfaced, so i can test my interaction in isolation. But depending on how many secondary classes their code uses, sometimes my facade gets lazy leaving places i can't mock.

Now, i'm pretty religious about test coverage, but i do have holes where my facade leaves untestable bits. And this is where TDD shows it's worth. Because when a feature is added or a refactor happens, almost with 100% certainty, the bugs that manage to get into production are in the code that doesn't have test coverage.

The lesson here is that the time saved in not building a properly mockable facade, thereby torpedoing my testability, is repaid manyfold in debugging later as bugs make it into production. meh.

  • in geek
  • 2 min read

OMFG AppleTV, seriously? Wipe yourself clean, why don't you?

Ok, here's a feature of AppleTV that can only have it's origin in some devils bargain with Content industry: Once you associate an iTunes instance with AppleTV for sync, you better not ever want to change it, because in the blink of an eye, you will staring a freshly wiped HD.

See, syncing means that whatever is on your PC/Mac is also on your AppleTV. So if you remove it from the PC, it disappears from your AppleTV. Ok, fine, a bit stupid a way to do content management on the AppleTV, but maybe i'll buy that it simplifies things, since all you have to do it keep things organized in AppleTV and all is good.

But here' the kicker, you ever change your AppleTV association to another iTunes, all is wiped of the AppleTV after one quick dialog. And no, oh, it's only hidden in case you re-associate because you realize that was not what you meant to do. No, you now get to re-synch 150GB back to your AppleTV. All for a second of misreading a dialog and clicking the wrong button. Wow! Really? That's great UI simplification. User makes mistake, gets to sit around for a couple of hours while AppleTV re-synch.

Any you cannot tell me that the brilliant minds at Apple came up with this scheme because it was just the most intuitive UI they could think of. No, this is all about the content industry being deathly afraid that someone might take their AppleTV to a friends house, copy all his content and then take it back home. As if this assinine sync behavior prevents something like that.

Grrr.. This is just stupid. 8 out of 450 items synced.

  • in net
  • 1 min read

The riddle of the disappearing WPF databinding

I'm currently on a custom control that has a bunch of panels slaved to each other via databinding. And I ran into a bug where moving an element around would suddenly break the sync with the other panels. Nothing in the Output about data-binding failing, so i inspected it with Snoop to see that my data-binding had just up and gone away. So I tracked down the suspect code and monitored the data source with Mole as i stepped through and saw that the data-binding went away right after I set the dependency property.

Yeah, not really magic at all. A quick look at the Xaml showed that I had left this particular binding as default (i.e. OneWay). And if you have a OneWay binding and manually set the dependency property, the binding gets overwritten and goes away. Switching the binding to Mode=TwoWay restored my sync.

  • in net
  • 1 min read

WPF Custom Panel layout and Dependency Properties

Just a quick note I learned the hard way when creating custom panels in WPF: If your panel has dependency properties or attached properties on its children that affect measure and/or arrange, calling InvalidateMeasure or InvalidateArrange won't necessarily do the trick. For that matter, calling these methods isn't even necessary. Instead use the FrameworkPropertyMetadata Metadata class to set appropriate FrameworkPropertyMetadataOptions.

So if you have a Dependency Property on your panel that affects the measure or arrange of its children, make sure it has FrameworkPropertyMetadataOptions.AffectsMeasure and/or FrameworkPropertyMetadataOptions.AffectsArrange set.

Similarily, if your panel has an attached property for its children, whose modification affects how that child is laid out, set FrameworkPropertyMetadataOptions.AffectsParentMeasure and/or FrameworkPropertyMetadataOptions.AffectsParentArrange.

Now layout and arrange are properly invalidated and called for you.

  • in net
  • 1 min read

XP 64, IIS 6 and ASP.NET

My current dev machine is running XP 64, which is a first for me. In the default setup IIS was not installed, so I went through Add/Remove Programs and installed it, which gave me IIS 6. This in turn has several tabs for ASP.NET, but try as you might none of these are what actually turns on ASP.NET and you just end up with mysterious 404s on a application enabled directory that's configured just like the working ASP.NET on your other machine.

Well, it turns out that ASP.NET (even though it shows up in the Properties tabs) is not installed by default and if you go to Web Service Extensions you won't see it there. So next, track down aspnet_regiis which is in the Framework directory and run

aspnet_regiis -i

Then go back to IIS Manager -> Web Service Extensions where ASP.NET should now be an available extension. Enable it and finally ASP.NET works.