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.

A little about me

It’s been a number of years since I first wanted to write a blog.  The biggest problem was finding that “thing” to write about.  The other problem is actually finding the time to sit down and write.

Finding time has always been an excuse, however since moving jobs a couple of years back I have found that I now have time on my hands and can finally dedicate a bit of time to typing up my ramblings for my future reference and for anyone else that may find them of use.

As a prelude to “real” blog posts I suppose it would be an idea to introduce myself.

I’m known as J98 – no need for the detailed background, that’s just how it is.

So taking the lead from Microsoft with DirectX and ActiveX, where the X equates to the globally know wild card character *, I decided to call my blog J98X, i.e. anything and everything about J98.  Somewhere for me to brain dump my thoughts and ideas.

At the time of writing this I’m in the “40 something” bracket, which is great by the way.  I’ve been developing since I was 11 or 12.  Starting with a Commodore Pet at the school’s computer club, then finally getting myself a Commodore 16 quickly followed by a +4 (had a very cool book for this that helped my convert Commodore 64 machine code to the +4), BBC Micro at school, Spectrum, Commodore Amiga 500 and 1200 (which I still have lying around somewhere).  Programming with DOS, QBasic, Visual Basic, BBC Basic, Amos Professional, ASP, PHP, Perl, Cold Fusion, VB.Net and C#.  I spent a bit of time with C++ and Python, may go back to them at some point.  I enjoy technology of all kinds, however my heart is with writing software.

I’ve spent time investigating development tools and techniques, mainly on the Microsoft stack, but I have looked around at Java and Ruby conferences as the problems faced by developers of any kind are very similar and looking outside of Microsoft gives added insights and validations of techniques.

I love code reviews and code refactoring and enjoy providing guidance on both.

A couple of developer traits I really don’t like:

• Lazy developers, those that just don’t want to learn.  Happy with what they learnt from a book or a course 10 years ago and think that is it.
• “Know-it-all” developers, those that think they have nothing more to learn and even if they did they wouldn’t admit it and wouldn’t, ever, learn anything from another developer.

To give a bit of balance a couple of traits I really do like:

• Lazy developers, those that don’t want to keep doing the same thing over and over and over, these developers will find solutions to get them away from the repetitive and onto the core
• Developers that know that they don’t know, more than happy to admit it and wants, needs, to do something about it.

Although I’d like to ensure future blog post are more then just the ramblings of a moron, I’m not going to make any guarantees just yet.  Let’s see how it goes.  It should be “thought of the day” kinds of stuff, along with a health splattering of educational bits and pieces; what I’ve learned, my thoughts or just notes to allow me to store those things I don’t want to forget.

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

Hello and Welcome

After some 32 years since I first typed on a computer keyboard and after nearly 20 years actually getting paid for having fun, I’ve got to the point that my brain is unable to cope with the amount of information that I get bombarded with every day, the number of technologies I need to be aware of, and all the R&D I try to do.  So I figured the best thing to do is start a blog and use it to act as my PA.

Although I am commencing this journey for personal reasons I hope that someone else finds some of my ramblings of use.  If not, no worries.

I don’t know just yet exactly what form this blog will take.  It is going to be based around technology in the most part.  Even then it will likely concentrate on Microsoft technologies, but I may just deviate from time to time.

Most of all I hope to keep this fun and informative.