Cryptography is a subject that I personally find fascinating. It really is one of the mathematical branches of computer science that really does seem to have a sense of magic to it. But this “magic” normally comes at a price, and that is the need for some really heavy duty mathematics. This normally puts people off, including myself as I am no math genius.
Lots of cryptography books are very heavy on the math and theoretical aspects of encryption, like Applied Cryptography by Bruce Schneier, which is great if you want to delve that deep, but most people including software developers just need to understand at a higher level how the algorithms work and how best to apply them in real life. That is where this book, Everyday Cryptography: Fundamental Principles and Applications by Keith M. Martin, comes in. The book is structured as follows :
This isn’t a long post, but just a useful snippet of code. I was working on some code for a system this afternoon and I needed to check that a username was a valid user in ActiveDirectory using C#. This isn’t something I have had to code before, so I thought I would share this useful nugget of code. I hope you find it useful.
public static class ActiveDirectory
public static bool CheckUserinAD(string domain, string username)
using (var domainContext = new PrincipalContext(ContextType.Domain, domain))
using (var user = new UserPrincipal(domainContext))
user.SamAccountName = username;
using (var pS = new PrincipalSearcher())
pS.QueryFilter = user;
using (PrincipalSearchResult<Principal> results = pS.FindAll())
if (results != null && results.Count() > 0)
I have released an Open Source libray under the GPL 3.0 license called Block Encrypter that builds on the code discussed in this article. If you need to do reliable and secure symmedtric encryption then this library would be very useful to you.
I thought I would start a little series on using some of the cryptography primitives in .NET. Cryptography and Encryption is something that most developers working on enterprise applications will come across, especially if you work in the financial services industry.
Whilst cryptography is a fascinating subject and the design of these algorithms is very interesting, I do not recommend using an algorithm that you have designed yourself. The standard algorithms in practice today have been through lots of analysis by experts both in private industry and governments all around the world trying to find faults and weaknesses, so you are much better off using these recommended systems.
The main algorithms fall into 2 categories, Symmetric encryption and Asymmetric encryption. Symmetric encryption contains algorithms that are based solely on an encryption key. For example, if you encrypt some plaintext with Key1 you get a cipher text out the other end. If you then decrypt the cipher text with the same key (Key1) you will get back to the original plaintext.
Asymmetric encryption works by having 2 keys, a public and private key. These keys are mathematically derived from each other. The public key can be used by anyone and the private key has to be kept secret. I will talk about asymmetric encryption and more specifically RSA in another post.
What I will show in this article is a good practical implementation of AES in .NET. We will start with the following interface. The interface contains 2 methods, Encrypt and Decrypt. They methods take cipher text/plaintext and an encryption key.
The system monitor discussed previously will collect a lot of data from different systems. The amount of information that is collected can be vast and in its raw form may not be that useful except to people who really understand what the data represents. The key thing with a dashboard is to break this information down for different users. This may be a complete view of the data, or just a subset for different purposes, so you have to think about the context in which the data is going to be provided and the intended audience.
For me, a key requirement of the dashboard I built was to make the data from the monitor available to my development and operations team in an easy to view format. This dashboard contains more technical information including exceptions as that is more appropriate for the intended audience. You may need to provide another dashboard to key business stakeholders. The level of information you provide here would most likely be different and contain more business level data.
Your dashboard may be viewed in different places. This might include a large TV attached to the wall, projected against a wall, or the dashboard might be run on a person’s desktop computer. If you are displaying the dashboard in a place where people cannot interact with it, i.e. on a large TV Screen, then you want to make sure the dashboard automatically refreshes itself. I will cover this more later on in the article.
Types of Dashboard
You really are spoilt for choice these days when it comes writing a dashboard. You can keep the display simple or you can really embellish the presentation. As I said earlier, it depends on your target audience. I personally find that keeping the display simple is the best thing to do. I have seen some dashboards that go overboard with dials, speedometers and other fancy graphics, and these can confuse the information you are trying to communicate if you are not careful.
You can develop your dashboard as a native application. This is what I did with my own solution for the company I work for. I work at a company that is based around the Microsoft stack, so this really gave me 2 choices as a .NET developer; Winforms or WPF. As I needed to get the dashboard up and running quickly I used Winforms, mainly because I am very familiar with this particular technology. WPF would also have been a very good choice.
My dashboard was aimed squarely at a technical audience, so the level of detail could be higher. The context of the dashboard was to allow developers spot any problems in our critical systems. I decided to keep the screen design very simple. I used a tabbed control, where each tab represented one sensor from the xml stream written out by the monitoring system.
Recently, I have been doing lots of recruitment for .NET consultants. Each of the CV’s we receive all stress that they are experienced in working in agile development shops. This is great. We are an agile development company so these people sounds like a great fit.
So we get them into an interview and ask them, ‘What does agile mean?’, ‘How do you know if your team is truly agile?’ It’s at that point we get the standard list of responses:
We do Test Driven Development.
We pair program.
We use continuous integration.
We use SCRUM, KanBan, XP etc.
Use work in iterations.
We use story points.
We calculate team velocities.
These answers are all well and good, but they don’t describe what an agile team is. These are all just facilitators to being agile. What’s even worse is that these interviewees seem to have not heard of the agile manifesto.
I am a bit of a book worm, especially with technical books. I love nothing more than to extend my knowledge on my craft. I wanted to let you know about a book that I have been reading recently that is absolutely fascinating. The book is called, the Architecture of Open Source Applications.
The idea behind the book is simple. If you were an architect constructing buildings, you wouldn’t do so without studying how other buildings are constructed. The premise is the same for software. As a software developer / solutions architect, how can you design applications without first studying how other applications are designed and built? That is exactly what this book does. This book covers 25 open source applications and discusses how they were built and designed.
Does it build? Yes then continue, No then stop the code review.
Run the unit tests.
Do they run and all pass? Yes then continue, No then stop the code review.
Check the unit test code coverage.
Is the coverage around >60%? Yes then continue, No then stop the code review unless there is a good excuse for the coverage that the review team are happy with.
Check the code metrics (Cyclomatic Complexity and Maintainability Index)
Are the metrics within agreed boundaries? Yes then continue, No then stop the code review.
Run the static code analysis against the agreed rule set?
Are there any warnings / errors? Yes then stop the code review, No then continue.
Once you get to this point, the development practices have been followed and you can proceed to review the actual code.
All of the tools I discussed above are available as standard to developers who use Visual Studio Enterprise Edition, except Resharper/CodeRush etc.
Unit Test Coverage
Whilst you are developing your software you should be writing tests to exercise that code. Whether you practice test driven development and write your tests first or write tests after the fact, you need a decent level of test coverage. This gives you a level of confidence that the code you are writing does what you expect it too. Also, it gives you a safety blanket when you need to refactor your code. If you make a change in one area, does it break something somewhere else? Unit tests should give you that answer.
The screen shot below, shows the Test Explorer view in Visual Studio 2012. From this view you can run all of your unit tests. As of Visual Studio 2012 Update 1, you can group you tests based on pass outcome, length of execution and project. Think of this view as your project health dashboard. If you have a good level of coverage and they are all green, then you can carry on developing. If you have any red tests then you need to work out why and fix them. Don’t let this view lead you into a false sense of security though. You still need to write tests to a decent level of coverage and ensure you are testing the right things.
You can check your test coverage very easily in Visual Studio. First you can click the little drop down ‘Run’ menu in the Test Explorer, or you can open the ‘Test’ menu in Visual Studio, and then open up the ‘Analyse Test Coverage’ and select ‘All Tests’. This will give you a view similar to below.