Category: Development

Posted on

Yet another carousel control

Download the control here

I meant to write something about MEF after my holiday, but I’ve been sidetracked
for a while. One of the things that happened to divert my notoriously unstable attention was a quite excellent five day Blend course by Brennon Williams. My preferred method of writing XAML has been, so far, in a text editor, but Herr Williams was quite persuasive in demonstrating that Blend is, in fact, far, far better for the job.

As part of the course, we wrote a small application. I ended up hacking together a 3d carousel user control for this, which I felt was pretty cool, so I set about rewriting it as a custom control for future use. No, I did
not use Blend. Yes, I did notice it’s a damn sight harder to do it in pure code than it was in Blend.

Warning: This post contains some math. Continue reading “Yet another carousel control”

Posted on

A File Organizer

If you’re anything like me, you probably have a few thousand documents and files lurking around a small forest of New Folder(n) on your desktop. If you’re anything like me at all, you probably also lack the time, interest, inclination and attention span needed to track them down, go through them, and organize them. Now, it so happened that some time ago, a friend of mine had complained of being in a similar situation; worse in fact, since more than one person uses her PC, leaving the whole thing in a mush.

It so happened that I didn’t have much to do in the weekend (note to self: get a life. Naaah…), and had been wanting to brush up a bit on WPF for quite some time, so I sat myself down and started coding. The result is this organizer. Continue reading “A File Organizer”

Posted on

Reusing Cruise Control .Net Configurations on the Same Instance

The sources described in this post can be downloaded here.

This post follows up from my previous post, Configuring Projects on Multiple Instances of Cruise Control .Net. In one of the comments to this post, Elad asked if it was possible to reuse configuration files on the same instance of Cruise Control.Net. This would make sense in scenarios where you want to keep different branches of the same project integrated on the same machine without re-defining all the configuration for each. While this makes perfect sense, I couldn’t find any way to do this directly, so I tried to come up with a workaround that allows this. Please bear this in mind while you read the rest of this post. My knowledge of XML in general and Cruise Control configurations in particular is neither all-encompassing nor flawless in its brilliance, so there are probably, oh, a few million holes you could poke into this method. That said, I’m always open for comments, so if you have a better way, please share it 🙂 Continue reading “Reusing Cruise Control .Net Configurations on the Same Instance”

Posted on

Configuring Projects on Multiple Instances of Cruise Control .Net

A continuous integration server is an essential tool in the box of any team – even a one man team. I’ve used a number of different servers, but in the end I’ve always come back to CruiseControl.Net. It’s a solid, no-nonsense server which has great community support. Since it supports MSBuild scripting, it lets you use almost any tool on your controlled builds; MbUnit, NUnit, NCover, and FxCop are the few I use most often, and they’re a tiny subset of all the coding goodness that can be played with. Continue reading “Configuring Projects on Multiple Instances of Cruise Control .Net”

Posted on

Aspect Oriented Programming in JavaScript

Want to level up your scripting? Check out The Little Book of JavaScript!

The sources can be downloaded here.

A couple of days ago, some colleagues and I were discussing the ins and outs of JavaScript, and one of the things that came up as we talked was how handy having functions as first class objects really is. Although I’d (ab)used this feature several times in the past, I’d never really thought much about it. It was just one of those things that’s, well, taken for granted in the language. Thinking it over a bit, a niggling thought came to me – that it would be really easy to implement aspect oriented programming in JavaScript. Continue reading “Aspect Oriented Programming in JavaScript”

Posted on

Implementing the Undo feature for Jasema

This article describes the undo feature implementation for Jasema 2 using the PostSharp framework.  For a simple introduction, this is my article about AOP using PostSharp. You can also read an article on compile time validation of custom aspects on this blog.
In the previous post, we looked at how PostSharp’s CompileTimeValidate method can be overridden to make sure that it has been applied correctly in the code. What we did not do, however, was to look at the context in which these aspects can be used.

The example given previously is straight out of the source code for Jasema‘s undo feature. This sort of functionality is very, very, very useful in applications involving complex tasks such as drawing, or editing a document, but they can also be a pain to write – not only do you need to maintain a log of each action, but you also have to make sure that each log entry has a way of being rolled back. What follows is a brief description of the route we took when writing the implementation used in Jasema. It is essentially a bastardised command pattern implementation, with a fair sprinkling of AOP thrown in for extra added fun and games. Continue reading “Implementing the Undo feature for Jasema”

Posted on

Validating attribute usage with PostSharp Aspects

This post expands on my previous article on PostSharp. If you haven’t already, read it here.

Most of January has flown by with just one post, effectively shooting down my resolution to blog more often. In my defence, I have to state that I’ve just moved on to newer pastures, with all the re-settling in that involves.

Apart from that, I also spent a few hours twiddling with the Jasema sources, so I do have something to post about at least. 🙂

The .net attribute architecture supports an Attribute Usage definition, which is itself an attribute that can be applied to attributes. AttributeUsageAttribute determines whether said attribute can be applied to fields, methods, classes, assemblies, or any combination thereof. This allows you to identify, at compilation time, whether the attributes you have specified are used correctly, which is great.

There are situations, however, where you might want to enforce some more detailed constraints on an attribute; for example, you might want to make sure that it is only used by classes that implement a given interface, or check what parameters have been defined for it.

It is possible to implement this as a runtime check within the attribute itself, however this is not always a very elegant solution. If you check the constraints every time the attribute is invoked in some way, you’re incurring a performance hit, however slight. If one considers that PostSharp aspects may be called every time data changes in a given field, or every time a method (or even any method in an assembly is called), this may add up to quite a bit, depending on what sort of checking you’re doing.

By making this sort of check at run time, you’re also depriving yourself of compile time checking. Even if you have unit tests in place to make sure you catch incorrect behaviour. it can still take time to run the suite; wouldn’t it be a lot nicer if the compiler could be instructed to raise an error when an attribute is given the wrong parameters, or is used with the wrong sort of class?

While PostSharp aspects don’t allow you to give such instructions to the compiler, they do allow you to do something that’s so similar that the difference, to someone like me, is purely academic (so, flame me). These aspects define an OnCompileValidate method, which can be overridden in your custom aspects. Continue reading “Validating attribute usage with PostSharp Aspects”

Posted on

AOP using PostSharp LAOS

Recently, I came across PostSharp, an excellent open source framework for .net. Among the great set of toys which it brings along is LAOS, an Aspect Oriented Programming solution which works very neatly.

Aspect oriented programming is quite a tricky subject to explain in short, so I won’t. While it’s an oversimplification, for the purposes of this post, we will just say that it is a technique where you intercept the control flow as it passes from one block to another, and attach non-default behaviour at these points.

PostSharp provides a mechanism which lets you define attributes to specify this behaviour; you can then decorate an assembly, class, method or field with these attributes. The specific methods you overload will then be triggered accordingly. Continue reading “AOP using PostSharp LAOS”