This is a short presentation I created for the company I work for, and gives my thoughts on the state of .NET logging libraries in 2014. My knowledge comes from day-to-day use of MSEntLib and log4net and moving from TraceListener to NLog in Roadkill. The presentation comes from a web and windows service perspective.
A while ago Roadkill’s CI solution was hosted on Appharbor, which was a great solution (and free for a single project), but the configuration hacking and I problems with the hosted environment with the unit tests meant it wasn’t a viable solution for Roadkill’s requirements.
After Appharbor I moved onto using Bamboo from Atlassian. This, like Appharbor, was also a great hosted product but was costing me a lot in Amazon EC2 hosting costs which I was too cheap and miserly to pay for.
I then moved onto Teamcity which is the CI I’m most familiar with, having set it up and used in two companies over the past 5 years. Right now, the Teamcity mothership is hosted on DigitalOcean and a Teamcity agent runs on my desktop PC to run the build. I’m also too cheap with this solution to keep it running 24/7, so I launch it on demand which is really when I do check-ins to Roadkill.
A few days ago I heard about Appveyor through the grapevine and decided to give it a try with Roadkill. Appveyor does all its instancing via Azure, but also lets you control the instance using post-install and post-build powershell hooks rather than the completely sandboxed approach of Appharbor.
So far I’ve been impressed at how easy it is to use, but also how customisable your instances can be.
With a post-install hook I installed Chocolatey and then Chrome and MongoDB (with SQL Express 2012 already installed):
After this, I had to do a bit of hackery to change the configuration file connection strings, as they default to using (local) for the instance and integrated security. The best tool for hacky ugly code is of course Powershell:
“gc” is a shortcut for get-content, and the “output-file” cmdlet is important as the text file isn’t saved without it.
With these scripts in place, there is a small tweak you should make to the Git settings (Appveyor is free for public Github and Bitbucket projects) – make sure the clone depth is 1 to avoid the entire history of a project being downloaded. That’s important for Roadkill, as I store the Nuget packages folder in the repository so I can work offline on my laptop easily.
Everything works well and it is really fast to get going. The main setbacks I’ve had, which are Roadkill related, are the size of the Roadkill Git repository is huge (around 200mb), and Chrome/MongoDB is also a lengthy install. So the builds go from around 15 minutes locally to 30 minutes on Appveyor.
The acceptance tests ran via Chrome, against the local IIS Express server, however they conk out after 30 tests which I’m assuming is from the instance running out of memory or having a maxed out CPU. Integration and Unit tests both ran fine however, with the main set back being the launch time. But I don’t mind too much about that, and I can live without the acceptance tests being run via the CI for now, happy to “decomission” the Teamcity in the coming weeks.
In the UK we’re fortunate enough to get 5 free holidays a year, under the guise of “Bank Holidays”. These are mostly on Mondays and come in January, March/April, May, August and December.
Below is a calculator for working out the dates of these holidays, along with tests for the next 5 years. The class tells you if you’re on a bank holiday, but could be easily changed to return the bank holiday dates. For now, it doesn’t tell you if you’re on the Boxing Day bank holiday.
If you want to enable integrated security in your SQL Server connection string, and don’t want to have to update your App Pool with a username across different machines you can simply add ‘NT AUTHORITY\NETWORK SERVICE’ as a dbo for the database you’re querying.
Obviously this isn’t recommended for production use, and shouldn’t really be used in larger teams or multi-environments (staging, live-staging, live) setups.
Warning: this post contains large amounts of pro-automated-testing propaganda.
Roadkill is now up to over 1000 tests (around 1150) as it gets near the version 2 release coming in 2014. Around three hundred of these come from the Markdown parser that Jeff Atwood wrote, and the HTML sanitizing toolkit, but the others have all accumulated over the past year including a lot of retro-fitted tests which were written to aid refactors. The test coverage is now around the 75% mark according to Jetbrain’s DotCover tool:
When you write Typescript, you’re forced by the compiler to use the “this” keyword when you want to access member variables or methods. If they’re static, you’re forced to use the name of the class (as you usually would in C#, although it’s syntactical).
One of the more important parts in Roadkill Wiki is removing malicious HTML from the markup that’s entered, even when the markup (Creole and Markdown) is controlled.
The markup you enter is converted into HTML, and then sanitized internally to remove any HTML that is bad, the markup can also contain HTML itself – the Creole parser allows this as does the Markdown parser to an extent.
For the most part Roadkill Wiki doesn’t need this level of sophistication in its text parsing,
One of the subjects I recently studied in my part time university course was how to measure a software system’s complexity, including quality measures for your code. These are statistical ways of measuring code or system complexity date back to before the SOLID principles became popular and with a little bit of insight give a fairly good marker of how complicated or clean your code is.
With Roadkill almost 3 years old, I thought I’d give some of the metrics a try on the source. There’s basically two ways of measuring system complexity: before you start the project and after/during the project.
Assuming you have used the Github Windows gui (or the console) to clone a Github repository, you can push it up to Codeplex in the console by using something like this:
git push --all https://git01.codeplex.com/roadkill
I use this Mercurial plugin on an Ubuntu box to synchronise my Bitbucket Mercurial repository onto Github. It’s a crazy setup to have 3 repositories, but this comes from the problem that Bitbucket gets very little exposure to the .NET community while Codeplex is used heavily. Git is probably a close second behind Codeplex for exposure but I still prefer Mercurial to Git, at least for the 1-man Roadkill project.
Why not sync Bitbucket with a Codeplex mercurial repository? The Codeplex Mercurial support is terrible by their own admission, and pushing any large changes simply times out, so I have to jump through these hoops to sync everything up.
A long time ago I mentioned in this post that I was planning on writing up some notes I made at university about Genetic Algorithms (from now on, known as GAs) and my version of a very simple example in C#. Years later…here it is! C# isn’t the most popular choice for artificial or natural intelligence programming, that job is largely the domain of Java or other more academic friendly languages. This means there aren’t a great deal of C# examples out there for neural networks, search and genetic algorithms and programming.