Even though all the code in contained in the article, I have received many requests for a Visual Studio project containing the code and all the unit tests that cover the test scenarios in the original article, so what I have done is open source the code on Codeplex. It seems many people have found this code useful, which is great, so I hope that by open sourcing it, more people will get use out of it.
Usability enhancements to the Test Configuration Editor, like linking tests from the editor and the test runner view, sorting tests by execution result and a tool for generating file checksums (MD5, SHA1, SHA256) to make the Checksum tests easier to use.
Writing out of Txt, Csv, or XML test reports from the Test Configuration Editor or Command Line Test Runner tool.
Added 2 new test types for spawning command line / batch files.
The 2 new tests for calling command line applications / batch files are useful if you need to test something that the Smoke Tester doesn’t support out of the box. One of the tests (CallExecutableCheckReturnCodeTest) lets you run an executable and check the return code. The other test (CallExecutableCheckOutputTextTest) lets you run an executable and check for the existence of a text string in the console output. These are very useful if you have some separate tools that you use for system checking.
Safepad has started becoming quite a popular tool with people, and I get feature requests from users all the time. The 2 most common requests are the following:
Caching of session passwords.
Generating user passwords to be stored in a secure document.
On this latest release I have focused on these 2 requests.
Caching of Session Passwords
In the previous versions of SafePad, everytime you open a document you have to enter in a password(s). Some users have found this a little painful, because for certain groups of files they use the same master passwords to secure the files, so they felt that when the application is open, they shouldn’t have to re-enter the password each time if the file has the same password.
This has been the most asked for feature request,so I have added it into Version 1.3. As you can see in the screen shot below, when you load a document, there is a check box to ‘Cache Password for Session’ when you check this box, the password(s) will be cached in memory (in encrypted form), so that the next time you open a file with the same password it will just open. If you try to open a file that uses a different password, you will be re-prompted to enter the password.
Once you close the application the cached password will be removed, so it will need re-entering when you load up the application. I didn’t want to get into the problems of saving the encrypted passwords to disk, I would rather just keep them in memory. I hope you find this a big usability feature. I have been using it for over a month (at the time of writing) as I keep all my staff 1 to 1 notes in encrypted files, so it is nice to be able to just open the files in a sessions without entering the password every-time.
Recently I open sourced a very useful tool called the Post Deployment Smoke Tester. The Post Deployment Smoke Tester is a tool that allows you to run a suite of tests on your environment after you have deployed a piece of software. These tests are invaluable in a large corporate enterprise as more often than not, the people who are doing your deployments are not the original developers.
Out of the box the tool contains many tests that should be immediately useful to you, but you may wish to add in your own. It is early days for this tool so we wont have provided everything that is possible out of the box. If you do need to add in a new test type then you can do so very easily.
If you do want to add or amend any of the tests, then this short article will help you navigate around the Smoke Tester solution structure.
The Smoke Tester tool is split into 4 main components. TestConfiguration, InstallationSmokeTest, ConfigurationTestsand CommonCode. The relations-ships between these 4 modules are shown below.
Both TestConfiguration and InstallationSmokeTestare your test editor/runners. Generally you won’t have much need to change these unless you want to add some extra functionality. You main areas of interest will most likely be the ConfigurationTestsand CommonCodeassemblies. This is where you modify or implement new test types.
I came across an excellent video by Jeremy Ruston who is the founder of the TiddlyWiki project and now works for BT as their Head of Open Source Innovation. The video covers the how, why, when, and who of starting an Open Source project. One particularly interesting part is about accepting patches to your project and dealing with poor quality patches through plug in and extensibility mechanisms.
I have just released a new open source project called the Post Deployment Smoke Tester. This project has been a collaborative effort between a number of fellow developers in response to a typical enterprise software development problem, getting rapid feedback on the success of your deployments into production.
This tool has literally saved my teams bacon a number of times, and maybe it can help you too.
The credits for this toolset are as follows:
Open Source Release : Stephen Haunts
Original Author : Hugh Phoenix-Hulme
Contributors : Stephen Haunts, Jon-Paul Flood, Daniel Steele, Oliver Sintim-Aboagye, Mark Jones
The all Familiar Problem
For anyone working in an Enterprise Software environment, I am sure you have all encountered the same problems. You finish your development and testing. You package up a release and prepare all the release documentation for the operations team and submit the change request into your Change Request system for approval. Then the release is deployed during your standard outage/change window, normally at an ungodly hour of the night.
The people who do the deployments generally have no knowledge about what they are deploying, they will just follow the change instructions that you have written. You will normally only really know if the release has been a proper success once your users get their hands on it the next day. In some businesses that can be a big risk if an outage or problem with the system has a financial or customer service impact.
Recently I moved my main home PC and Laptop over to the Linux Mint distribution, which for someone who has been a dedicated Windows users since I ever got my hands on a PC back around 1990, has gone amazingly well. My next little venture is to do a little cross platform development. Although I have moved away from Windows (not strictly true as I have set up Windows 8 in a Virtual Box environment in-case I need to switch over for something) I still really like the .NET environment and C# language, so I would like to carry on using it. I would like to learn another language like Python / Ruby, but I really don’t have the time at the moment as I have just changed job and I also have young kids at home which takes up a lot of my spare time.
Thankfully, there is the Mono .NET implementation that I can use and it is really well supported. Mono is a Free (as in freedom) implementation of the C# language and .NET runtime that is written to the ECMA-334 open specification. As well as being open source, Mono also has a company, Xamarin, sponsoring its development as they use the mono system for their IOS and Android application development system, of which you can also use for free (within limits).
My main interest at the moment is writing desktop applications for both Linux and Windows. Mono does support Windows Forms, but it isn’t as well supported as the Linux Gnome user interface library GTK. Mono has a version called GTK# and it is designed to be cross platform so you can use it with Windows and Mac OSX as-well.
After more playing around with Linux I decided to take the plunge and wipe my main desktop PC and install it natively. I have been trying out both Linux Mint and Elementary OS for a few weeks now in a Virtual Box VM to see whether the desktop experience is any good, and I am glad to say that it has now matured perfectly.
I first decided to install Elementary OS natively. This worked fine on my laptop, but there was a problem when I installed it onto my PC. There seems to be an annoying display bug where the screen just flips out if you have multiple monitors attached. This looks to be a known issue, but I am not sure when it will be fixed. This is a shame as Elementary OS has a nicer look and feel to Linux Mint, but after recently shelling out for 2 very nice 24inch flat panel monitors, I wasn’t going to be in a position where I could only use one of them. Elementary OS worked fine though if you unplugged one of the screens.
Next up I decided to install Linux Mint, which in itself is an amazing distribution. The installation process for this was very smooth and within 15 minutes my PC was wiped and I was logging into a fresh install of Linux. Everything worked as expected, sound, display, usb etc. I spent an hour or so installing updates and some applications (Mono Develop, xMind, Cairo Dock etc) and I was all done.
In a previous article I talked about whether a Linux desktop was ready to become a mainstream OS on a desktop computer for everyday, non techie users, like my Dad or Wife. In that article, I concluded that, Yes, Linux is now at the point where it is becoming a viable option. Linux has been the mainstay on servers for many years now, and powers a large proportion of the internet, but it has never really caught on with standard desktop computing. This has changed though with tablet computing as Linux sits underneath the Android operating system.
In the article I stated that Linux Mint was a very good transitional Linux distribution because it looks and acts very similar to Windows, so this would make a users migration to Linux a lot smoother. There are still a number of hurdles to overcome for the user like giving up any Microsoft specific applications like Office in favour of LibreOffice, and general hardware device compatibility, which driver wise, lags behind Windows.
In the comments for the other article, a reader suggested checking out Elementary OS. Elementary is another Linux distribution based off of Ubuntu, that has been designed to be very easy to use. The user interface as you will see in a bit is gorgeous. Also this distribution is very lightweight in that it doesn’t come with hundreds of installed applications like Linux Mint does. This makes it more like a base install of Windows, where you just get the operating system and a collection of small apps and utilities. I find this quite appealing as I don’t like clutter.
So lets take a look at this OS. You download the ISO file image from Elementary OS website. Again I am installing it under Windows 8, using Virtual Box. As this distribution is based on Ubuntu, it has a very familiar installer which is very easy to use. The whole process took about 15 minutes. Once the installation had completed I was at the Login Screen ready to sign in and start using the OS.