Regardless of how you choose to track your history, one of the things you often want to know is which commits are in what branch. Sounds easy enough, right? And yet, you wouldn't believe just how cumbersome certain version control systems make answering such a simple question.
Tell me if you recognize this scenario. you’re in the middle of rewriting your local commits when you suddenly realize that you have gone too far and, after one too many rebases, you are left with a history that looks nothing like the way you wanted. No? Well, I certainly do. It was in one of those moments of despair that I finally decided to set out to create my own git undo command. Here’s what I came up with and how I got there.
Since the dawn of civilization, common sense has taught us that the way forward starts by knowing how we got here in the first place. While this powerful principle applies to practically all aspects of life, it's especially true when developing software.
When I started doing TDD a few years ago, I often felt an inexplicable gap between the functionality described in the requirements and the tests I was writing to drive my implementation. BDD turned out to be the answer.
If you’ve been using AutoFixture in your tests for more than a while, chances are you’ve already come across the concept of customizations.In this post I’m going to talk about how to write general-purpose customizations.
This article sums up my experience when overclocking a Raspberry Pi computer. It doesn’t provide a step-by-step guide on how to do the actual overclocking. Instead, it gathers the pieces of information that I found most interesting during my research, while diving deeper on some exquisitely geeky details on the way.
I love working with the command line. In fact, I love it so much that I even use it as my primary way of interacting with the source control repositories of all the projects I’m involved in. It’s a matter of personal taste, admittedly, but there’s also a practical reason for that.
When I first incorporated AutoFixture as part of my daily unit testing workflow, I noticed how a consistent usage pattern had started to emerge. Multiple tests shared the same context, which had to be initialized in exactly the same way over and over again. Luckily, AutoFixture customizations offer an elegant way out of this unnecessary duplication.
Now that AutoFixture 2.2 is approaching on the horizon, it’s a good time to start talking about some of the changes that were made to the underlying behavior of some existing APIs. I’ll start off this series of posts by focusing on the new generation strategy for anonymous numbers.
I’m excited to announce that AutoFixture now officially supports delegates in the main trunk up on CodePlex.
There was a time when all my energies and effort went into building web applications. In the beginning the platform I was on was Microsoft ASP 2.0, but since 2002 it became all about ASP.NET Web Forms.
It’s interesting how a lot of the work I’ve been doing lately has in some way involved a kind of performance tuning. Previously I’ve talked about how to increase the performance of .NET applications by using delegates instead of reflection in code that runs frequently.
Lately I have been involved in the performance profiling work of a Windows client application, which customers had lamented to be way too slow for their taste.
In my previous post, I talked about how to design a class that uses a WCF client proxy in such a way to make it testable in unit tests, without having to spin up a real service to answer the requests. The technique I illustrated uses a particular Inversion of Control (IoC) principle called Dependency Injection (DI), in which objects that a given class depends on get pushed into it from the outside rather than being created internally.
I have to admit that in the beginning I didn’t think Inversion of Control (IoC) Containers were that big of a deal. The idea of relying on an external agent to manage all the associations between objects in an application, sounded like it would bring more problems than advantages. Overkill. But I was wrong.
I can’t stress enough the importance of having a code convention in place before starting in any kind of software project.
A while ago I run into a rather interesting and insidious bug, which I thought I would share. The bug manifested itself in a Windows Forms application, occasionally causing it to crash with an "out of memory" error. Little did we know that the hunt would lead us down the dark corners of the Win32 graphics API.
The ASMX Web Services framework, as obsolete as it may feel, still supports HTTP cookies in the exact same way as you would normally expect. WCF, on the other hand, broke that tradition in the name of a higher level API. This article explains how the two programming models handle cookies and suggests a solution to the problem of sharing a common cookie across multiple Web Service requests.
I am currently in the middle of a project where we are migrating a (large) amount of web services built on top of ASP.NET in .NET 2.0 (commonly referred to as ASMX Web Services) over to the Windows Communication Foundation (WCF) platform available in .NET 3.0. The primary reason we want to do that, is because we would like to take advantage of the binary message serialization support available in WCF to speed up communication between the services and their clients. This same technique was possible in earlier versions of the .NET Framework thanks to a technology called Remoting, which is now superceded by WCF. In both cases it requires that both the client and server run on .NET in order to work. But I digress.
If you have followed the latest advancements in the technologies and standards around web services, you must have come across the term “REST” at least more than once. In rough terms REST is a way of building web services by relying exclusively on the infrastructure of the World Wide Web to define operations and exchange messages. This is an alternative to “traditional” web services, which instead use a set of standardized XML dialects, WSDL and SOAP to achieve the same goals. The reason I’m writing about REST is that if you, like me, have prematurely judged it as some kind of toy technology, you are in for a real eye-opener!
When discussing web development, the subject of security inevitably comes up. Last week while I was teaching a class in ASP.NET, we had a sample login page that, although being quite trivial in nature, was exposing a serious vulnerability to SQL injections attacks.
The other day I was reading about one of the most talked about future Microsoft technologies code-named “Oslo”. The details of what “Oslo” is are still pretty vague, at least until PDC 2008. In short it’s a set of technologies aimed at creating Domain Specific Languages (DSL) that can then be used to build executable programs. Yes, I know that still sounds vague, but that’s really all Microsoft has reveled about the whole project so far.
I’ve recently picked up reading (again) my all-time favorite book about software development. Code Complete by Steve McConnell. The book was first published in 1993 and has been a timeless guide for anyone in this industry about the science and art of software development. A craftsman’s handbook, if you will.