C#, TCP and UDP–Part 1 Update 1

After further work on my distributed processing system [some details found here] I have concluded that Windows Communications Foundation (WCF) is going to be where I go with this.

I’ve used WCF for various things in the past.  It’s usually been forced on me, i.e. it hasn’t been something I have chosen to do.  This time, after some research and testing, it looks like I’ve found a reason for me to use it.

• WS-Discovery allows me to get rid of my own UDP discovery process.
• Duplex bindings allow me to have the systems conversing the way I want them to
• Self hosting in a service or a console app is very simple

Importantly, perhaps more than anything else, the other devs in my team are familiar with WCF so nothing, or very little, for them to learn.

I’m going to write some posts later to take me (you (us)) through the process of creating a simple app to do the WCF basics that I need for my app.  This allows me to dump information for my reference, if it helps anyone else – great!

That’s all for now.   Thanks for reading and see you next time.

C#, TCP and UDP–Part 1

I’ve started playing around with distributed processing, i.e. having multiple servers set up to manage the execution of tasks, for example to assist with some over-night batch processing.

I’ve been hunting around for a light weight messaging system to allow all of the executioners and marshalling systems to communicate amongst themselves.  Initially I thought about each system self hosting with something like Owin or Nancy and then have them talk together using something like SignalR.  Interestingly the proof of concept worked out fine, i.e. I could get a number of systems to talk.

I finished the proof of concept work feeling good, but there was something in the back of my mind that was telling me this wasn’t the right thing to do.  So I thought about SignalR and how it worked.  At the top level it will attempt to establish a communications channel between the client and the server with Web Sockets.  Huh?  Light-bulb moment.  Sockets!!  Why not have the various parts of the distributed system talk with sockets?  I feel like I’m on to something with this.  I should be able to define a set of ports that my system is gong to use.  I can the call out from a central controlling system with UDP to the network asking for the distributed components to identify themselves.  Once identified TCP can step in and provide the actually communications channel.

A couple of prototypes later and I’m back to being not so sure.  It should be fine, but getting everything co-ordinated isn’t working quite as expected.

In my next post I’ll post some code, issues and possible solutions.

That’s all for now.   Thanks for reading and see you next time.

Code refactoring–a brief introduction

As the title suggests this is just a very brief introduction for now, later posts will go into more detail.

The starting point is understanding what is meant by re-factoring, or more specifically what I mean by re-factoring.

Re-factoring is not about bug squashing, it’s not about you hunting down bugs and fixing them, that’s what testing and bug squash days are for.  If you find bugs while re-factoring you have to make the call as to do you stop your re-factoring and fix the bug or just log it and come back to it later.  Personally I’d log it and come back later as I’m on a re-factor session not a bug fix session.  You choose what is most appropriate for your situation.

Re-factoring is about making code easier to understand by humans, easier to read by humans and easier to support by humans.  For example a variable named lbBlue, using an older coding style that means local variable (that’s the l) of type Boolean (that’s the b) to indicate if something is Blue or not (that the Blue).  Of course it can be argued that if this is a known convention then that’s fine.  The only issue is what happens then you hire new developers?  It’s not obvious without being told.  If this was re-factored to isBlue then most developers will get it’s meaning instantly.  BTW, has the added advantage that you’ve just taken a step towards self documenting code.

That’s all for now.  Thanks for reading and see you next time.

Code review ramblings

Yuk! Yep, talk to developers about code reviews and they tend to divide themselves into 2 camps.

Camp 1 loves them, can’t get enough of them.

Camp 2 hates them, they’re a complete waste of time.

That second camp exists because no-one seems to have had the time or been able to explain what code reviews are and what they are not.

In all honesty the reasons for and against are wide and varied and can even be specific to an organisation, i.e. for purposes of auditing and compliance.

Personally it never bothered me why and how I was involved with code reviews, the important thing, for me at least, was having clear goals and upfront agreement as to what the code review was trying to achieve.

So here are a few things that made my life much easier when holding code reviews:

• DO code reviews at someone’s desk
• DO NOT code review in unfamiliar surroundings, such as in a meeting room
• DO keep reviews focused
• DO NOT use code reviews as an excuse to look at every single line of code in the entire solution
• DO keep code reviews to just a few methods or functional units
• DO always be positive when providing feedback
• DO NOT ever blurt out comments such as “That sucks”

I don’t pretend to be some expert on this subject, I haven’t spent years, or even more than a few hours, carrying our any kind of scientific study.  All I can offer is that I’ve done it and these work out fine in the majority of code reviews I’ve been involved with.

So let’s break those bullet points apart a little and attempt to explain what I mean by each.

• DO code reviews at someone’s desk
  If you’re going to perform a code review of a colleague then do it in their own environment, i.e. sat at their desk, with their software and, therefor, a familiar environment.  They are most comfortable the, they may be a little nervous if they’re a “Code Review Virgin” so by sitting at their desk you are using a little psychology to help them be comfortable and will then be able to work with you in the review session much easier.
• DO NOT code review in unfamiliar surroundings, such as in a meeting room
  See the notes above.  It’s important to allow the person that wrote the code that is under review to start in the most comfortable situation possible, don’t let them worry about having to move into a meeting room, log on to a computer they may not be familiar with, or use a development environment that isn’t theirs.
  With the above said it is important, no actually it’s vital, that you talk with the person to see which environment they would be more comfortable with, i.e. are they happy to sit at their desk or would they rather go off to a meeting room?  Sometimes egos get the better of people and the worst thing that could happen is them thinking that they are gong to look bad in front of their peers.
• DO keep reviews focused
  Try your best to keep on track.  Don’t go off talking about what you did over the weekend, how the football is going, etc.  Keep to the plan.  Focus in on a business critical part of the code under review, or the bug fix, or (if they are a developer that is new to your organisation) the coding style.
• DO NOT use code reviews as an excuse to look at every single line of code in the entire solution
  Don’t get distracted by other code.  Keep your eyes on the code under review, if you find other code that you feel you need to comment on, make a note and do so outside of the review.  The only exception to this is where you may be aware of similar code or functionality that has previously passed code review and you want to use as a positive example.  Never, ever, go off to find more bad code to use as an example of what bad code is.
• DO keep code reviews to just a few methods or functional units
  Keep it short and sweet.  If there is a lot to cover think about having a further code review later in the day or the following day.  The chances are that you will start losing focus and stop adding any value to the process.  Think about time boxing review sessions to 15 or 30 minutes, whatever works for you.  45 minutes is about my limit.
• DO always be positive when providing feedback
  Hopefully this goes without saying.  You should try as hard as you can to educate in a positive way.  If something works then it can’t be wrong.  If it doesn’t work then there is a bug.  If you find a bug try and get the developer to run a pen test through the code to validate it does what they think it does.  This way you assist them finding the bug and, maybe, give them a new tool that they may not have thought about, i.e. pen testing.
• DO NOT ever blurt out comments such as “That sucks”
  When you are providing feedback to another developer be positive.  Ask questions and try to understand their approach so that you understand what processes result in the code you are reviewing.  You will, on occasions, find that they copied a similar block of code from the existing source and adapted it to solve their problem.  The code may have been floating around for sometime, i.e. prior to you investing in code reviews, and – you know what? – the chances are you wrote it.  So be a little cautious with what you say.
  Only by asking questions can you discover the developers though process and competence.  You may discover a solution that you hadn’t thought about.  If you can think of a “better” way of solving the problem then rather than saying “That sucks, do it like this” it is far better to ask “Did you think about doing it like this?”  They may surprise you and say “Yes I did” and then give you reasons as to why they dismissed that idea and implemented the code you are reviewing.  And yes that does happen.

Remember that code review are about education, consistency, but most of all it’s about education.

 

That’s about it for now.  Thanks for reading and see you next time.