Skip to main content

The Misadventures of a .NET Dev

Sooo... long time, no post! All zero readers of this blog might be curious about why I disappeared. The short story is I’ve been sidetracked by personal issues combined with a butt-ton (sorry to those in far away lands; I don’t know how to convert this to metric) of work at my paying gig. We’ve all been there and done that. I’m sure you can relate, non-existent reader. But I’m not making any more excuses! This post serves as a list of topics I want to cover in future posts. It’s long, so I doubt I’ll get to all of these.

  • More ‘SharpMock’ – I haven’t abandoned this project, but I was saddened when I realized I had forgotten all I learned about PostSharp when I cracked open the [smelly from having gone so long without bathing] spike code.
  • Creating DSLs with MGrammar – I’ve noticed a lot of bloggers are unsure about the vision Microsoft has for ‘Oslo’. Count me among them. But I definitely have had some fun playing around with Intellipad and MGrammar recently. I see a lot of potential for making my development life easier when it comes to maintaining metadata. I also have an idea for a little project to make it easier to author certain scripts that perform a certain development function which currently depend on some ugly XML (I’m awesome at starting projects and terrible at finishing them).
  • ASP.NET WebForms and the MVP Pattern: What Not to Do – I wish I had time to even play the the new (or old for that matter) MVC bits. I wish I had time to learn Silverlight 3 (or 2, or 1 for that matter). I wish I had time to use jQuery (or some other cool JS framework for that matter) and improve my piss poor JavaScript skills. Alas, we’re stuck in the stone age of web development at my job. I’ve done my best to reduce code duplication and improve testability with the MVP pattern, and along the way I’ve done a lot of stupid things that I think others should avoid. Actually, I probably shouldn’t write about MVP at all. Meh.
  • Persisting Abstract Expression Trees: What Not to Do – Again, the stone age (hmm, I should probably be capitalizing that) of development means not using an ORM. I have some advice about what to avoid if you have to persist expression trees and write all of the data access code. This will mainly be about persisting inheritance hierarchies (table per class, table per subclass, etc.) and coping with object model changes.
  • Building a LINQ Provider – I have no idea why, but I want to do this. I’m specifically thinking of a fun little project called either ‘LINQ to MP3’ or ‘LINQ to ID3’ (I’m good at naming things and horrible and building them). I figure it’s time to start learning .NET 3.5 since .NET 4.0 will be out sometime soon. On that note…
  • .NET Certification Fun! – I never got any MS development certifications (I did manage to fail one test… seriously), and I’ve listed getting my MCPD as a goal at work. I have some opinions on the certifications in general, and occasionally I run across interesting things in the process of studying (okay, I don’t study). I’ll blog about this. P.S. We’re talking .NET 2.0 here :(
  • Ruby, Ruby, Rubyyyyy – I’m not talking about a Kaiser Chiefs song. I’ve been playing around with Ruby a little (and reading Why's (Poignant) Guide to Ruby, which is absolutely hilarious), and it’s a lot of fun. I actually probably won’t blog about this, as I don’t have much to say.

Well, that’s all I can think of for now. Talk to you again in 6 months!

Comments

Popular posts from this blog

Who I'm Is

I am a junior .NET developer currently working in Chicago, IL. I am starting this blog in order to enhance my knowledge of programming subject matter. Hopefully, someone else will be helped along the way. This first post will probably be edited soon...

Stubbing Static Methods with PostSharp

TypeMock uses the Profiler API to allow mocking, stubbing, etc. of classes used by code under test. It has the ability to handle sealed classes, static classes, non-virtual methods, and other troublesome-yet-oft-encountered scenarios in the world of unit testing. Other frameworks rely on proxies to intercept method calls, limiting them to be able to only fake virtual, abstract, and interface members. They also rely on dependecy injection to place the proxies as the concrete implementation of calls to the abstracted interface members. Anyone working with a legacy codebase is bound to run into static method calls (especially in the data access layer), dependencies on concrete types with non-virtual methods, and sealed class dependencies (HttpContext anyone?). The only way to unit test this without refactoring is with TypeMock. I've never used TypeMock, and I'm sure it's a great product, but it's not free. I decided to spike some code to see if I could solve the prob...

Strongly-Typed Property Constraints in Rhino Mocks

UPDATE: As I suspected, this functionality was right in front of my face – it’s called PredicateConstraint in Rhino Mocks. I also realize that I managed to completely ignore the existence of Predicate<T> in the framework, and write my own predicate delegate. Hey, I was on a roll. Rhino Mocks has a PropertyConstraint class that allows you to check the values on properties of objects passed into the method as part of the verification for that method being called. Unfortunately, the name of the property is specified as a string, which means the benefits of strong-typing that Rhino Mocks is normally so good at preserving are lost. Here’s an example (using Rhino Mocks 3.3 and .NET 2.0): [Test] public void Main_Form_Should_Show_Start_Panel_On_Load() { MockRepository mockRepository = new MockRepository(); IMainFormView mockView = mockRepository.DynamicMock<IMainFormView>(); IEventRaiser loadEventRaiser = GetEventRaiserFor(delegate { mockView.Load += null; });...