Today I’d like to introduce a project I’m calling “ConTabs” – simple, but flexible table generation for console applications. As well as simply being an open-source project, I’m also planning to use ConTabs as an excuse to explore some of the interesting aspects of modern .NET development.
In today’s post, I want to share a trick I discovered: using Stack Overflow to help answer my questions. Before you stop reading, I mean without posting my question at all. In fact, I simply rediscovered the time-honoured tradition of “rubber ducking”. I think Stack Overflow provides the perfect place to rubber duck and I’d like to share my reasoning.
Have you ever wanted to test the behaviour of a method, without making it part of your public API? Have you ever been forced to choose between compromising on the encapsulation of your business logic, and ensuring that it behaves as expected? Allow me to introduce the
InternalsVisibleTo attribute! In this post, we’ll look at what this lets you do, but we’ll also touch briefly on the debate surrounding its use.
Today I had reason to do something I haven’t had to do in a really long time: add IntelliSense hints to a library we supply. Because it’s been so long since I last did this, I had to look up one or two details, so I thought I’d share a quick summary.
At work, we have a system that lots of users interact with, but which sometimes needs some “alone time”. From time to time, we email our users and ask them to close the client application, so that it can do what it needs to do. (Needless to say, this software was not written in-house!) Users being what they are – and emails being what they are – this approach leaves something to be desired.
A colleague and I put our heads together and decided that we needed something obvious, intuitive and highly visible. “What if,” we thought, “we could wire up some traffic lights to a Raspberry Pi?” So that’s what we decided to do. In this multi-post blog series, I’ll outline what parts we used, how we wrote the software, and how we made our little old Pi ready for the enterprise environment. In this first episode, I’ll focus on how we got to a working proof-of-concept.
This post was inspired by conversation I had at my desk today. It’s a conversation that takes place every now and again and it always takes the same form: someone will come over to my desk, start using my mouse, and remark on how lovely it is. They aren’t wrong. My mouse is excellent. Not flashy, but quietly brilliant. And it’s not just my mouse either. My keyboard is a joy to type on and I have some pretty nice wireless headphones too.
Now, the point of this post isn’t to boast about all my lovely things. As I point out in these desk-side conversations: these are the tools of my trade. During the week, I spend fully a third of my waking hours using a keyboard and mouse to cajole electrons into doing my bidding. Whilst I’m doing this, I very often use my headphones to shelter my concentration from the noisy open-plan office around me. Given that I’m using these things so much, any minor niggles can add up to become real productivity drains. In short, it’s pretty important to work with decent tools.
Today I want to talk about adding log4net to a new project. It’s not hugely complicated or high-tech, but there are a few factors that mean I always seem to struggle with one aspect or another. There’s usually an irritating couple of minutes when I’m Googling questions and seeing purple links! This post is a sort of memo to myself then, and perhaps next time this post will be among those Google results!
I recently discovered Project Euler and have become an overnight evangelist. For those of you unlucky enough to not have discovered it yet, Project Euler (pronounced “Oy-ler”, by the way) is a series of maths problems that lend themselves to being solved with programming.
In my humble opinion, Project Euler is great. So great, in fact, that I thought I’d spell out exactly why you should give it a try. So here goes, 4 reasons I think you should give it a go.
If, like me, you’re coding education was (ahem) “non-standard”, you might not have given much thought to the underlying mechanics of how .NET uses memory. Us C# developers are a bit spoilt really. We can pretty much get on with the coding, without having to concern ourselves with allocating memory or worrying about leaks. The CLR does an excellent job of sorting it all out behind the scenes.
It was only when boxing came up in a conversation recently that I realised how flakey my understanding of memory management in .NET really was. I mean, I sort of knew the concepts, but I think I thought I knew it better than it turned out I did. So I went away and brushed up and thought I might as well share my new understanding. In this post I’ll try to cover some basic concepts, such as value types vs reference types, the stack and the heap, and boxing and unboxing. I’ll finish by explaining both why you should care and why it’s less of an issue these days. In future posts, I may go a bit deeper into some of these concepts, using this post as a reference. Continue reading
In my current role, I find myself working a lot with our sales handling pipeline. It takes an order through our API and starts a set of processing pipelines for things like fulfilment, accounting, and our CRM system. Because the main entry point of the pipeline is an API, I used to find myself using Fiddler to make fake calls to our API in the testing environment.