So, what are the required steps?

• Create a dump of the database.
• Add the dump and all local modifications to the local repository.
• Commit the changes to the local repo.
• Push to a remote repository.

In my case I like to go sure and push to two remote repositories.

So, this is the script that will backup my blog and push it to my repos:

D:
cd D:\Webs\dotnetninja.de
SET PATH=%PATH%;D:\MariaDB\bin
del backup.sql
mysqldump --skip-dump-date -u backup blog_dotnetninja.de > backup.sql
git add .
git commit -m "Automatic backup"
git push origin
git push backup master
exit

To automate the backup I just created a simple scheduled task to execute this script once a day.
Restoring the blog from the backup is as easy as described in my blog post about the move.

This was very fine and I am extremely impressed how easy it was to get started with it. Then I ran into a little problem.

I wanted my project to incorporate information about the Git commit hash it is built from, the Git branch it was built from and other little details. For that the MsBuild Community Tasks project offers some nice helpers. So I added the NuGet package of this project to my solution.

The Problems

Now there is this chicken-egg problem: When MsBuild encounters a UsingTask declaration, it automatically loads the assembly that contains the task. If that assembly is not there, using the task will fail. Now, the NuGet download of the packages – including the task library – happens as part of the build. That is, after the project files are loaded. So the fresh downloaded file was not found when importing the projects and… the build fails.

To avoid this problem, I cheated a little bit on MsBuild: I added another project to my solution that also has the MsBuild Community Task project listed in it’s packaged.config. Then I manually set my web application project to be build after this ‘BuildSupport’ project. Now the BuildSupport project build downloads the community task library, which is then available when the project import is defined in the web application’s project file. It’s just a small cheat, though.

Then the next problem: The BuildSupport project is not actually ‘required’ to build the website project, and so the Git deployment build process simply does not build it. The task library is not downloaded prior to executing the actual build process of the application, and so it fails. I could not get the project to build the ‘BuildSupport’ project before the actual web application on Azure.

The Solution

After a little bit of research I found this can be achieved by using a custom deployment script.
I was a bit afraid that I had to figure out how the actual deployment works to add a step just in front of the actual compile, but there is some infrastructure in place to help us out with that.

For a .NET developer this will feel strange, but you’ll need node.js in the first place. The Windows Azure Command Line Tools are a node.js package, and we’ll need that to get started with the actual live deployment script. So, after installing node.js, we’re going to install the package:

npm install azure-cli -g

This will globally install the Azure CLI for use on our console. Now we navigate to our solution directory and let the Azure CLI generate the deployment script that will automatically run to deploy our application to Azure if we don’t do anything custom:

azure site deploymentscript --aspWAP ApplicationFolder\Application.csproj -s Solution.sln

This will generate two files for you. First there is a .deployment file. This is a file structured like a oldfashioned .ini configuration file, telling Azure that there is a custom deployment file and how its name is. It’s content simply is:

[config]
command = deploy.cmd

It also reveals the second generated file, the actual deployment script called deploy.cmd. This is the interesting part for us so far. I’m not posting the full script but rather go through the sections.

First there is a check that node.js is available. It is assumed that this is available on Azure, but to test the deployment script locally you’ll also need node.js. We just installed it, so we’re all set, but the next one checking out the solution could be missing node.

Then the script defines some environment variables for folders. Like where the build artifacts will be placed and where the actual files to deploy will be placed. This defaults to /artifacts/wwwroot and can be overridden by setting the corresponding environment variables before the deployment.

In a thirds step, the script checks if kudu is installed. Kudu is the actual deployment engine running on Azure, and is also capable of running on your machine. After that additional paths are configured.

In the fourth step the actual compiling and deployment work is done, and the fifth is just some error handling.

So, let’s have a look at the actual important stuff in the file:

:: 1. Build to the temporary path
%MSBUILD_PATH% "%DEPLOYMENT_SOURCE%\MyApplication.Web\MyApplication.Web.csproj" /nologo /verbosity:m /t:Build /t:pipelinePreDeployCopyAllFilesToOneFolder /p:_PackageTempDir="%DEPLOYMENT_TEMP%";AutoParameterizationWebConfigConnectionStrings=false;Configuration=Release /p:SolutionDir="%DEPLOYMENT_SOURCE%\.\\" %SCM_BUILD_ARGS%
IF !ERRORLEVEL! NEQ 0 goto error

:: 2. KuduSync
call %KUDU_SYNC_CMD% -v 50 -f "%DEPLOYMENT_TEMP%" -t "%DEPLOYMENT_TARGET%" -n "%NEXT_MANIFEST_PATH%" -p "%PREVIOUS_MANIFEST_PATH%" -i ".git;.hg;.deployment;deploy.cmd"
IF !ERRORLEVEL! NEQ 0 goto error

Now, thats actualy very easy: MsBuild is called for the web application project, and then Kudu is launched to do the actual deployment.

What we want to achieve now is to build the full solution upfront to have all required NuGet packages downloaded before the actual project is being built. And while we are actually getting our hands dirty in a custom deployment script, why don’t add running the unit tests of the project as part of the deployment? So, if a test fails, deployment will fail too. I think that’s a good idea.

So what I did was adding these two steps just in front of the two default steps:

:: 1. Build solution
echo Build solution
%MSBUILD_PATH% "%DEPLOYMENT_SOURCE%\MySolution.sln" /nologo /verbosity:m /t:Build /p:_PackageTempDir="%DEPLOYMENT_TEMP%";AutoParameterizationWebConfigConnectionStrings=false;Configuration=Release /p:SolutionDir="%DEPLOYMENT_SOURCE%\.\\" %SCM_BUILD_ARGS%
IF !ERRORLEVEL! NEQ 0 goto error

:: 2. Running tests
echo Running tests
vstest.console.exe "%DEPLOYMENT_SOURCE%\MyApplication.Web.Tests\bin\Release\MyApplication.Web.Tests.dll"
IF !ERRORLEVEL! NEQ 0 goto error

That’s it. I just copied the build line and pointed it to my solution, and I added a call to the MsTest tooling to run my tests.

So, with very little tweaking I could remove all dependencies to actual binaries I would have to check in otherwise and I have the Azure git deployment run my unit tests on every deployment. That’s what I call easy and convenient.

It all started with the definition of ‘native’ or – even worse – ‘true native’, but let’s start at the beginning. I know the audience of my blog is mostly .NET focused, so let me get you all set with the required background information.

FireMonkey

So, let’s start what FireMonkey is – or aims to be. FireMonkey is a application development framework (or platform, as Embarcadero likes to call it) and contains components that should enable the developer to build cross-applications with a singe code base for Windows, Mac OS X, iOS and soon to come Android. FireMonkey is written for Delphi and can also be used from C++ within Embarcaderos C++ Builder.

So the main idea is, that you design your forms with FireMonkey components and controls, double-click on buttons to add your business logic like Delphi developers did this for the last decades and then be able to compile the application for Windows, for Mac OS X and for iOS without changing it anymore.

And indeed, this works technically…

Architecture

…but this is also already the point where it starts getting wrong.

FireMonkey, by it’s RAD approach, encourages the developer to click his user interface together, double-click on controls and put all the logic onto the form – where it doesn’t belong. I’m not going to argue with anybody about decoupling, testability of code and all the other Clean Code aspects and concepts. A good developer should have the inner urge to produce code at a certain minimum quality level and putting everything on the form is nothing that helps here. So, the basic concept that FireMonkey encourages is wrong.

New and not-so-advanced developers tend to adopt this bad style and start running into a direction that will end up in fatality. Good developers instead will start by building up a good architecture for their application. Most probably working with tests, that makes the usage of some DI container a no-brainer. This most probably also lead to a good decoupled architecture on the application frontend, perhaps introducing some MVC concept for their GUI. Only this enables them to take a good approach to real and thoughtful cross platform development, but more on that in a minute.

Cross-Platform

Let’s talk about cross platform development in a general way, before we go back to FireMonkey.

Every platform has its specifics. And a user – that is, in fact, our customer we want to sell our application too – chooses his platform for some reason. There are multiple approaches to make the user happy, and the most simple thing is, to integrate the app seamlessly into the environment (platform) the user chose to please him.

Let’s talk a little about UX. I’m thinking about the overall user experience with your application here, not only the look & feel of the GUI. It’s the whole full package including a good guidance through the workflow, helping the user to not enter crap into your app, assisting him to solve problems when he does, make everything accessible for everyone, especially impaired users, and of course also response times and stuff. As said, the whole package.

All platform vendors have thought about how their platform / devices should behave, how software should behave on the platform and what they expect from an application. They offer UX guidelines that describe what fits into the environment and how applications can fit seamlessly into the platform, providing an overall exquisite user experience to the guys you want money from.

Comparing just Apples (iOS and the Mac) and Googles (Android), which are the current relevant platforms for FireMonkey besides Desktop-Windows, UX guidelines shows you how different the platforms are. They are fundamentally different in how the control flow in applications is expected from the user. Leave alone Windows RT for tables and Windows Phone, which have a radical new approach to interacting with applications. But since Windows RT and Windows Phone are not (yet ?) supported, we don’t need to get into those details right now. Just so far right now: Delphi is marketed as the best/fastest/most productive dev tool for Windows. Why can’t you target Windows RT? Or write Windows Store applications for Windows 8 with it? Well, thats another topic. But still taking into account, that the main target audience for FireMonkey are Delphi (and as such mainly Windows-) developers, this leads into a fatal direction:

FireMonkey encourages the following: The Windows-Developer designs his FireMonkey form for Mobile Devices just as he would design a Windows-Application form. This for Windows designed UX is ported in a one-size-fits-all attempt onto the Mac (not so extremely terrible bad), but also to iOS and later Android (overly extremely bad).

Why is this bad? Because the user chose his platform with something in his mind. This something is the overall user experience with the device and of course with the applications he gets from the store within the platform itself. It’s a closed ecosystem for his needs. He expects his iPhone/iPad-Applications to come in his loved iOS style or he expects his Android-Applications to come in an Android-Style. So again, we need to please our customers because they are the ones buying our applications and giving us their money. So how can we make them happy? Give them, what they expect.

Users expectations, and a sub-plot

That can be done only in one way: To embrace the platform and behave like a good citizen on that platform.
Developing a ‘native’ application is not the only way, but whatever technology you choose, the result should still integrate seamlessly into the environment.

A good example is Exfm. They have a music sharing service, and used to publish a ‘native’ iOS application. Native as in written in Objective-C with XCode. It had a 4-star rating. Still they did a rewrite of the app – with HTML5 and JavaScript – based on PhoneGap. During the rewrite and despite the fact that they were actually programming a web application that runs in a UIWebView browser, they incredibly focused on iOS detail behaviour like the scroll bounce thingy or the possibility to scroll-bounce elements that don’t need to be scrolled because they are not larger than the area displaying them. They even mimicked the iOS behaviour that you can tap and hold on a button, move away from it, slide over the button again and lift your finger to trigger it. They did that with HTML 5.

They did that for one reason: To behave like a good citizen on iOS. To please their users.

And now they have a HTML application that you can’t tell apart from a native application that uses the native UI controls of iOS. The new app now got a 4.5 star rating and more downloads than ever. Here’s an article with a lot of more detail information about the little iOS details that make the app feel ‘right’ on iOS.

Now let’s get back to FireMonkey.

Einheitsbrei

I’m trying to introduce a new word to my english speaking friends: ‘Einheitsbrei’. You already use some german words like Zeitgeist and Kindergarten, and now it’s time for ‘Einheitsbrei’.

Einheitsbrei is a word that could be translated with ‘boring standard mash’. Is used deprecative and describes things that are boring, common, and don’t have any specific characteristic or outstanding elements.

FireMonkey apps are Einheitsbrei. They are sub-standard on every platform and don’t take into account the little, loved by users, elements of the platform they are running on. And in some cases they don’t even get the basic things right.

Architecture, the second: Doing it better

In the first architecture section I described that a good application architecture very probably involves some sort of DI and MVC on the GUI part.

Nick said on twitter:

@phoenixhawkAnd you have full platform access with Delphi for iOS.You can call any API you want.

— Nick Hodges (@NickHodges) April 23, 2013

So, let’s take this for granted. When I can call ‘any API I want’ with Delphi for iOS, then I would have full access to all native UI controls on iOS. When I already have MVC in my application, then there is nothing that would hinder me as a developer to use the DI container to instantiate a view for iOS that is using the iOS native UI controls, and to instantiate a view for Android that makes use of the native Android UI controls there.

With just a little bit more effort on the views using the platform APIs, bypassing FireMonkeys UI controls, your app could behave like a good citizen on the very specific platform my customer chose for himself for a reason. Remember: that customer guy is the guy I need to make happy because I want him to give me his money.

Conclusion

Yes, it’s more effort. Yes, it will take longer. Yes, it will require you to learn about the platforms UX design guidelines and about the platforms native UI controls. But it’s worth it. Like extfm, who re-wrote an existing app with the goal to their iOS users more happy and another one that makes their Android users happy.

FireMonkey instead encourages you to produce Einheitsbrei. And this is just so wrong. You will find out, when you don’t get the ratings required to have enough sales for your app. Users are cruel. They buy your app, and rate it down when they don’t like it. And they tell other users to not buy your app, when they are not happy with it. They will, however, rate your app up and tell others to also buy when they really like it. But just when the app’s buttons are so good, that they want to lick them.

Your app needs to be outstanding, of high quality and provide a well designed user experience to be successful and to be able to compete against other applications. Einheitsbrei doesn’t sell. And FireMonkey, by design, encourages Einheitsbrei. You won’t do yourself a favor by using it.

This is my opinion on why FireMonkey is just so wrong.

First of all I wanted to check out the build servers before diving into the bug trackers. So I set up the first assembly for my project, with just one class and a unit test for it. As I already mentioned in my requirements it is a .NET project and I want to have at least the very basics (building, unit testing etc.) covered.

My test case for this was very easy:
Set up a project in the build server, have it check out the sources of the project and let it build.
After building is okay, add the configuration for unit tests and let the test run.
Check if it builds when checking in new code, and check how it reacts when either the build breaks or unit tests fail.

So, now this is, what I encountered with the systems:

Bamboo

Without digging too deep into the documentation (Documentation? Yes, this is the url. Check.), I set up a build plan in Bamboo to build my project. I set up a first stage that should check out the project from source control and build it.

Well, the setup was done quickly, but the build would not start. What I did was the following: I configured two local agents, both are capable of running the build. The build plan had a single stage “Build” with two jobs: Checkout and call msbuild with my solution file.

When I manually selected ‘Run’ it was queued and ‘waiting to be build’ forever. When clicking onto it, and selecting the only stage with the hourglass besides it from the sidebar, it told me this status: “Status: Job has not yet been queued. Waiting for prior stages to complete.”.

This was where I went like WTF? What prior stages? This was the only existing stage in the only existing plan.
After spending several hours with this situation I decided to create a User account on my Bamboo evaluation installation for someone to support me and opened a support ticket at Atlassian.

A few hours later the support logged in – and just saw a failed build that started like 20 minutes before.
After that the server behaved like normal: A new checkin resulted in an almost immediate new build like I would have expected.

So, why did the build fail? I used a Git repository on BitBucket for the tests, and configured the version control settings to check out from Git. I though that was the obvious way to do it. I was wrong, as Bamboo would not check out the sources. As I later found out, since the Git (hint! hint!) repo is hosted on BitBucket, I needed to select ‘BitBucket’ instead of Git from the repository type selection to be able to use it. My dear. After that it worked.

So, after this little problem I went on to configure the unit tests. I added a new stage for the tests to the build plan and configured a new job that would call MsTest and run the tests.

That job failed on every approach to run it. It always told me that the assembly was not found.
To make a long (several hours over a few days!) story short: Obviously the different stages in a build plan are executed on the same agent, but in different working directories.

At the time of this evaluation there wasn’t anything hinting to that in the Atlassian docs. By now, there is a small article explaining that you need to configure Artifacts to bring build results from one stage into another, but without further explaining how to set up the artifacts in detail.

Back then, I tried to figure out the different directories but that required a lot of changes to my build scripts that wouldn’t work on the dev machines after that, and so I put the MsTest job in the build stage to have it execute.

Guess what? After changing the build stage it wouldn’t start again with the same delayed until forever problem I already had until I waited several hours when it suddenly executed.

After all, my experience with Bamboo wasn’t really turning me on.

TeamCity

I already mentioned that we use TeamCity at my work place. So setting up the initial project was a bit new to me, but I knew what the settings were and where I had to tune a little bit. So the initial setup of my project with two build steps build and test was done in a few minutes.

Of course everything worked from the very instane I clicked on run.
Then I went on to activate code coverage reports for the test build step by simply activating dotCover from a little drop down in the test build step. After the next build I had a complete test coverage report on TeamCity.

Conclusion

I struggled a lot with Bamboo. It has a steep learning curve and the documentation is.. well, let’s simply call it it could be better. A lot. The Atlassian tools in general, and Bamboo is no exception, are obviously powerful, but you have to spend a LOT of time with the system to get it running like you expect it to – and I don’t want to spend too much time fiddling around with my toolset.

TeamCity on the other hand is streamlined and guides you through the process of configuring your builds. Everything I needed was set up in a matter of minutes and everything worked directly as expected from the very beginning.

Actually, at this point it was clear for me to use the JetBrains tools and not Atlassians, but I still had a quick look at Jira and YouTrack, which I want to describe in a dedicated blog post.

See the other parts in this series:

1. Part 1: Basic tools
2. Part 2: Automate everything
3. Part 3: Bug tracker requirements
4. Part 4: Build server requirements
5. Part 5: Additional tools, server and hosting
6. Part 6: The evaluation candidates
7. Part 7: The evaluation begins
8. Part 8: A little bit more evaluation

My mistake? I already teasered it in my last post about my pet project: I bought a Drobo S as a storage solution. The Drobo S is the predecessor of the current Drobo 5D.

The title of this post is a clone of the I’m done with Drobo post of Scott Kelby. In this post he describes that he had some issues with his Drobo. He eventually ended up in a situation where all drives in his Drobo were stillokay, the Drobo itself wasn’t and since his device was out of warranty he would have to buy into an extended support package to be able to access his data.

Well, my own situation is not (yet) that bad, but I have a strong feeling I may end up in a similar position.

Now, what are my issues with my Drobo S?

I already use my second replacement unit. The very first Drobo I received after ordering had a problem with the drive bay in the middle and wouldn’t recognize a disc in it. In the first replacement unit all five slots worked and that was fine for almost a year.

Then, as I already mentioned in my previous post, my server suddenly started loosing the connection to the Drobo. On a regular basis I came home and my home server would miss the drive. Only a reboot of the host computer would (most probably, but not always) fix this.

This of course was very annoying, but was not extremely critical because I only had media files stored in the Drobo which were available through a TVersity media server. I could not stream videos through my home when the drive was lost, but that was okay in the beginning. The connection was eSATA, because USB is too slow for streaming two full-HD streams at once.

It became more critical when I started to run my evaluation VM on that home server and placed the virtual hard disk of the server on drive D (my Drobo drive). A disconnect could leave the VM in an inconsistent state and probably damage my infrastructure.

Then the disconnects started to happened more frequently over time until I encountered this issue daily and even multiple times on a single evening. As a software developer I know how to troubleshoot and check for possible error sources: The Drobo also lost it’s eSATA connection to another machine. USB was fine on both, but as already mentioned not an option because of the slowness of USB.

The Drobo service tried hard to fix this and eventually sent me another replacement unit.
This was okay. Now – guess what happened then? The replacement unit starts to show the same issues too. Now, even the USB connection get’s dropped once in a while.

So, while I initially was extremely happy with my Drobo and it’s performance, I’m currently in a state of constant alert for when my Drobo will eventually fail and won’t be accessible anymore – together with all my data I stored on it.

Of course I have a backup of the important data (honestly, my terabyte large video archive isn’t important enough to keep it as a backup, so that would be a loss, but given the time I can spend on watching them it wouldn’t be that hard). But the main idea of a large storage, with a very fast connection directly attached to my home server is to have direct and instant, always-on access to the data. Something, that I thought my Drobo could provide. But something, that a Drobo obviously isn’t capable of providing in a reliable way.

So I’m done with Drobo, because I can’t trust my device to function properly any longer.
I need to check for alternatives soon. If anybody knows of a solution for my problem, that is holding currently about 6 TB of data, more incoming, with very good performance and data throughput (just like a normal internal HDD), so please tell me.

Download

For this I downloaded the evaluation products from the Atlassian homepage and the free installers from JetBrains. Please note the slight difference between a ‘product’ and an ‘installer’ download. I wanted to do a side-by-side installation of all tools on the same VM to compare them easily.

Just as a little side-note, I will do a blog post on my hardware that drove me crazy during the evaluation. Just so far by now: I have a Drobo storage attached to my server at home, and I had the virtual server hard disks on that drive. Now guess what happens when suddenly the host machine looses the connection to the Drobo. Regularly and over and over again. But as said, this will be part of a separate blog post on its own.

So, after the download I ended up with two .exe installers for YouTrack and TeamCity, and with two zip archives for Jira and Bamboo. The Atlassian web site then directed me to a documentation link where I had to look for the installation instructions matching my setup.

Installation

All four products are Java-based.

JetBrains solved this very sound by obviously packaging the required runtime directly into their programs. I did not need to install Java on the system before installing YouTrack and TeamCity. Both programs as well as the first build agent of TeamCity were installed as autostart windows services automagically. They installed fine and directly started to run on the their corresponding port that I could change in the installer.

Now the tricky part began: Installing the Atlassian tools. First of all, the documentation suggested to install the 32-bit SDK, even on 64-bit machines. Just to get this straight: We’re talking about software that aims to be run in a production environment for enterprises, and they suggest using a lot of ram. This was my first WTF-moment with the Atlassian tools. I loved to choose a 64-bit runtime, and not the SDK but the real runtime, but well…

So, I installed Java. The JDK. For 32 bit. I then had to unzip the zip file and choose an installation and an instance folder: Second WTF-moment. The instance folder is something like the working directory of the program. Okay, so I did. In a small side-note in the installation documentation there is mentioned that there should be no space in any path name. “Any” means, no spaces in the path to Java, the products installation directory and the products instance directory. Of course, Java is installed in “C:\Program Files\…” by default. With a space in it.

Being a software developer myself I can only shake my head about such a ridiculous requirement. A software should be written in a way that it can cope with valid paths on the corresponding operating system. Especially software that is intended to help other software developers. Well, of course I ran into problems with my default Java installation location and had to uninstall and re-install Java again to another location.

The next tricky part was installing the Atlassian software as a windows service. You have to manually use a Java service wrapper tool for that. Oh, and I almost forgot: To configure Jira and Bamboo you need to manually edit configuration files, which are not really well documented…

After all, I got all four system to run. That is, I could open them in the browser and set the systems up.

So far, it’s an extremely clear plus for YouTrack and TeamCity. Installation is very easy and no hassle with config files, Java paths and service wrapper tools. The Atlassian stuff might be suited for enterprise use with a special person dedicated to setting up, configuring, fine-tuning and maintaining the system, but for a one-man show the overhead of a simple tool installation seems too much.

In the next post I’m going to describe the first functionality tests.

See the other parts in this series:

1. Part 1: Basic tools
2. Part 2: Automate everything
3. Part 3: Bug tracker requirements
4. Part 4: Build server requirements
5. Part 5: Additional tools, server and hosting
6. Part 6: The evaluation candidates
7. Part 7: The evaluation begins
8. Part 8: A little bit more evaluation

Well, it is not true that there is not a single one of her available. If you know a few not publicly available details and where to look / what to search for, you may be able to find a single image showing just her. And there is one other picture she happens to be visible on, and that is my wife’s Facebook profile picture that shows our whole family at our wedding. So that’s not a photograph of her alone, and you can’t see too much of her on it. Besides the first image, there is not even one online mention of her name on the internet, and I want it to stay that way.

I take care of what I share on the internet and with whom I share what kind of information. It’s a bit tricky to keep track of that, but it’s possible. As an example, I’m pretty sure that no one knows my middle names, without having in person heard them from me or someone who knows them. Well, at least, Google doesn’t know them, which is a good indicator for that. Oh, and by the way, if you know them and haven’t heard them from me, then please tell me who told you. I need to sort that out…

So, why exactly is my daughter’s name and images of her such a secret to the public (= non friends & family)?
It’s because I want to protect her. And it’s because she is (better: she will be, at some day in the future) the only one that should decide what should be shared about her.

Social engineering is a threat

So what it is, I want to protect her against? It’s a very easy form of social engineering to gain her trust later. The sad thing is, that it’s not just very but extremely easy.

I want to give an example: What could be the problem of sharing a picture of her, now when she’s about 20 months old, in our garden, together with her uncle and any other random person that is well-known to our family while playing with a ball?
This is not a problem now, but let’s pretend since that very day 2 and a half-year passed, and she’s in the age to be an attractive target for a child abuser.

Well, this bad guy could see this old picture on a social network. Analyzing the picture’s metadata (not necessarily the date on which the picture was shared) he knows when this picture was made, and potentially also the geo-coordinates where it was taken, because modern smartphones or cameras do add these information to the image data. He then probably simply follows the connection graph of family members and their friends to find out the names of all the people on the image. It’s even more easy if those people are tagged.

With all this information, he can make up a story around this day – she won’t remember that for sure. She probably only knows the situation from the very same picture as her single memory of that occasion. So he could go like “Do you still know me? I’m that friend of your uncle Martin and Pete. I was around when we played with that red ball in your grandpa’s backyard and helped you get up again after you hurt your ankle.” The last thing is totally made up, but nobody remembers such a small injury – but of course, he helped her out. That’s for sure a nice friend of Martin and Pete she had so much fun with.

And then he goes “Martin said, I should pick you up and bring you to your Mom. She’s back from work early and want to go to the city with you to buy some nice clothes. Perhaps you will get some ice cream too?” That’s it. She’s going with him.

And all this just because too much information was shared. Information, that is harmless in that specific context, but can be combined to design a seemingly authentic story a little girl can’t look through. The more information you share, the better the story can get, the more trust that person can build up.

Is it real?

The example above of course was made up. But it was made up in a time where burglars already check your Facebook timeline to find out when you’re in vacation and then check Google Maps and Google Earth to determine the best way onto your ground and where to vanish unseen with all your stuff. Such a story is possible, and someone will eventually do that or already did that, and I just didn’t read about it.

If you share, think about what and to whom

I also found some good advice in this other post over here at reputation.com.
Of course the zero-sharing path I chose may be not the right thing for you. If you really want to share, then make sure what you share. Remove metadata from pictures before uploading them. And make sure, with whom you share. Most social networks have options to only share with your close friends or certain groups (like your family). And you can make sure that those people are not able to re-share this in larger circles.

This is, what this post is about:
Use those features. Take control of your information flow. And make sure that you don’t share information that could be abused easily.

Since I want to spent not too much time on my infrastructure, I just want to check out two or three candidates for each, and I already have a list of bug trackers I’m definitely not going to use, so I start with them first. Also, the Wikipedia comparison sheet of issue tracking systems is a good reference to exclude some applications. I’m going to start from the side of the bug tracker and from that I make an inner join on the available CI servers with integration possibility as the join condition.

My filters

Again my little disclaimer: This is my personal list of filters for my personal pet project. They may or may not apply to your use case or requirement catalog.

First of all, I want to host the solution myself and not depend on someone else’s infrastructure. Then as the next thing I already mentioned I want at least a minimum integration of bug tracker and CI server, so anything that totally does not know from each other is not in my scope, as well as tools that don’t integrate with any CI server solution.

You already know that I use a Windows Server for hosting, and I don’t want to mess around too much with my IIS, so I’d like to stick with solutions that are either ASP.NET or PHP applications, or that are not hosted in the IIS directly. Besides that I don’t want to manually administer an extra apache on a system. I don’t know enough of that and I don’t want to spent my time learning how to manage another web server when I already know how to manage my IIS and administering web servers is not my main business. I’d rather spent my time learning more about things that really push my skills forward and making me more specialized.

When thinking about the database, I want to use either MySQL/MariaDB or Microsoft SQL Server Express. I know how to manage both as well as Oracle (which I don’t want to set up and keep it running myself without the help of an experienced Oracle DBA), and learning setting up and running yet another database is not on my to-do list for now.

Those restrictions already strike out a lot of possible systems, and the next one will make the list even shorter: I don’t want to use something that is not commercially maintained. There are several reasons for that. If there’s a bug that itches me, I don’t want to hope that the community is going to fix it. In several open source projects the normal answer to a bug report is “where’s the pull request for the fix?”. I don’t want to dig into the code of my bug tracker to fix issues myself. I’m willing to pay for my tooling even if I try to keep expenses low.

This is the last filter: The software should be affordable for a one person show and scale up to a small team of about 5 until it gets more expensive.

The candidates

After applying my filters to the list of available bug trackers, only a few are left over. They are only commercial solutions where I can rely on support. Then I additionally filtered a bit more for products from companies where I have a feeling that they are well-known in the developer communities so I can additionally rely on fast help via StackExchange.

First of all, something what I tested some time ago and is indeed a good software for keeping track of your project and your to-dos is FogBugz, but the self-hosted edition is too expensive for me (the entry point is a 5 user licence at 999 USD).

As I already use a lot of stuff from Atlassian, it would be logical to check out their solution too. This would be Jira. It is the same 10 USD for 10 User entry point and integrates with Stash, FishEye and Crucible. That would make it a first class citizen in my current environment. They also have a build server, Bamboo, that would fit in nicely too. So Jira and Bamboo are my first candidates for the evaluation.

Besides that I already use tooling from JetBrains (ReSharper, DotPeek), and they also offer a bug tracking tool called YouTrack and a build server named TeamCity. For both tools JetBrains offer free licences that restrict either the number of possible users or build configurations. So with 10 users and my single project I would be in the free licence area for both, and upgrades are affordable for larger teams starting at 450€ for a 10-user YouTrack licence and 25 users is a mere 225€ upgrade. TeamCity upgrade is more expensive, but it is also possible and allowed to set up more than one free TeamCity instance if it really would be necessary. This seems a good pack and so they are in the evaluation.

So far I am very happy with SoureTree, ReSharper and DotPeek and I have a feeling that both companies can deliver a decent bug tracking and continuous integration software for my needs. That’s why I chose to stop with picking candidates at this point. Evaluating four products is a not so trivial task already and if both products in a category would fail, then I still can choose other candidates to check.

Continue with the next part, or see the other parts in this series:

1. Part 1: Basic tools
2. Part 2: Automate everything
3. Part 3: Bug tracker requirements
4. Part 4: Build server requirements
5. Part 5: Additional tools, server and hosting
6. Part 6: The evaluation candidates
7. Part 7: The evaluation begins
8. Part 8: A little bit more evaluation

Preamble: Actually, it is a spare time, private thing, and as such I don’t want to spent too much money on it. I also don’t (yet?) know how long this will take and as such don’t want to pay too much. Especially not on subscriptions for services.

So, where to start? I think source control is the most important thing for a software project, so let’s go.

Source control

I chose Git. In the first infrastructure post I already mentioned some of my versioning tooling (which in fact already changed up to now). I have a lot of experience with SVN, not yet so much with Git, but as I already mentioned it seems that from an adoption and acception point of view Git is the new mainstream source control tool. It is powerful, it is cross-platform, and GUI clients support is growing. My other alternative would be Mercurial (Hg), but despite it’s better windows GUI clients, adoption is not that good and I want to be able to ask questions on StackOverflow and get help quickly.

So, I already said I was using Bitbucket from Atlassian for hosting free private repositories. This is only partially correct by now. I decided to self-host my repositories and use bitbucket as an additional off-site backup for my repositories. Why is that? I don’t want to be fully dependent on a single point of failure (Bitbucket). They host in the cloud, and we all saw that the big cloud players like Amazon with EC3 and Microsoft with Azure can encounter large-scale problems. Even if Atlassian takes all precocious measures to keep their service available, which is probably not the case given a lot of people are only using the free stuff, something really stupid like expired certificates at the cloud side could render the service unavailable for hours or even days.

My idea is the following: I mainly work on my self-hosted repository. Whenever my build server has a new successful build, it will automatically push that to the Bitbucket repo. This way I have a repo backup on my dev mashine, Bitbucket with the latest fully working state (since you commit and push often, that should not be too far away from my local copy) and of course my self-hosted repo. That should be enough safety in case something happens to my notebook, my server or Atlassian.

Speaking of Atlassian, they have this great Git client SourceTree for Mac. They recently announced opening up a beta test for SourceTree for Windows via Twitter. Guess what? I signed up

You see, I use Bitbucket from them, I use SourceTree on the Mac from them and I’m eager to get experience with their SourceTree for Windows. Atlassian is very present in my Git-centric versioning environment, which is why I also started to use their product Stash. Stash is BitBucket on my own server. I can create repositories, manage permissions (okay, currently I’m the only user) and have it automatically manage my branches. And it is very cheap at yearly 10 USD for 10 potential users. So when my project succeeds, and I stock up my development team beyond 10, then I for sure will have the money to upgrade.

Source quality

Since you now the tooling I use to store my sources and to manage it on my server and my development machine I want to introduce another tool I bought and installed, even if it’s usefulness is (currently) questionable. I bought FishEye and Crucible from Atlassian to. At 10 USD each it was not a real investment, and I feel that FishEye lets me keep control over my code more easily. It allows fast searching through all the project code (in 5 repositories for 10 users) and lets me browse through the history of my code in a convenient way. Crucible as a code review tool is probably not of so much use for a one man show, but perhaps later on somebody want to join my efforts with this project and potentially participate on revenues, if this becomes successful. Crucible is the only tool thats the 10 USD for only 5 and not 10 users.

Hosting

For a long time I had a hosted Linux root server (dune) at Strato for 49€ / month. It used to host my email server (I completely switched to Gmail for my domain a few years ago), hosted my first blogs, some home pages and discussion forums for the guilds when I still was playing. Besides that I had a very small Windows Server at 1&1 (smarthost), which I got for 14 € / month as a special offer during my studies. But it was not powerful enough to replace all services on dune.

As I already posted, this blog (and almost all other things hosted on dune and smarthost) now moved to Gallifrey. Gallifrey is a big Windows Server 2012 ‘Level 4′ V-Server at Strato, with 4 virtual CPU cores, 4 Gig of ram and a 250 GB HDD. Enough power to host those littles web sites, my blog and my complete build environment. I ordered Gallifrey when there was a 6-month free offer and it is at 29€ / month. So I canceled dune and smarthost, which will in fact save me about 34€ / month while at the same time offering more power.

Backup

As already mentioned, my sources will be automatically backed up to BitBucket. By now, I also put the sources of this blog and all other homepages into Git repositories which are also automatically backed up this way. All databases are dumped on a regular basis and copied over both my home server and a cloud storage. Same goes for the working directories with config files and changing contents. They are copied to a backup location, zipped and transferred together with the database dumps. All that is triggered by a scheduled task on the v-server.

Summary

So the toolset for my pet project is right now:

• VMWare Fusion
• VMWare Workstation
• Microsoft Windows 8 Professional
• Microsoft Visual Studio 2012 Professional
• JetBrains ReSharper
• Source management:
  • Git command line client
  • GitHub Client for Windows
  • Atlassian SourceTree for Windows Beta
  • Atlassian BitBucket for Backup
  • Atlassian Stash for Repository management
  • Atlassian FishEye for code search
  • Atlassian Crucible for code reviews
• Other little helpful tools:
  • JetBrains dotPeek .NET decompiler
  • The Regulator, a regular expression tool
  • LinqPad to easily test code snippets and experiment around

Update: Fixed some typos. Thanks Manuel

Continue with the next part, or see the other parts in this series:

1. Part 1: Basic tools
2. Part 2: Automate everything
3. Part 3: Bug tracker requirements
4. Part 4: Build server requirements
5. Part 5: Additional tools, server and hosting
6. Part 6: The evaluation candidates
7. Part 7: The evaluation begins
8. Part 8: A little bit more evaluation

Now the second important thing is to stay in control of my code I’m going to produce driven by those tasks. For that I want a good suite of unit- and integration tests. The next logical step is having the tests run at every checkin, so a CI / build server is required. This also automatically opens up the possibility to automatically deploy certain parts of my project to test, staging and eventually production environments. So this is something I totally want to go for.

My personal requirements for a CI / build server:

• Work fine with .NET environments
  I want to write something for .NET developers. As such, my pet project is a .NET project itself. I like to use the things that come in the same box as .NET (MSBuild, MSTest). Whatever tool I chose, it should support that out of its own box.
• Work fine with Git
  Okay, that probably is a no-brainer. Git is the new SVN (just talking about adoption here, please don’t kill me for that comparison), and I assume all tools out there will have Git support in some degree.
• Can build branches automagically
  That probably comes with ‘fine’ Git support. Whenever I create a new branch and push it to the repo the CI server builds from, this branch should build too automatically. This way I know for sure everything is working before merging stuff.
• Easy to setup
  I actually want to work on my project and don’t spend all my spare time with getting my infrastructure up and running.
• Integrate with my bug tracker
  As already mentioned in the previous post, a two-way integration of Ci server and task tracking would be extremely cool, but is not an absolute must-have.
• Allow extensions with reports easily
  I think about code coverage analysis, running FxCop and or StyleCop on the Buildserver and have their reports displayed directly with the build report. Not from the very beginning, but such things should be possible.

So, that’s pretty much it for the CI / build server.

The next post will bring some light in the darker areas of the infrastructure part, like where to host my Git repositories and what additional tooling may be nice when working with the code. This will also raise some questions about hosting in general as well as setup and tooling on the server, which may affect the tools that I’m going to evaluate.

Continue with the next part, or see the other parts in this series:

1. Part 1: Basic tools
2. Part 2: Automate everything
3. Part 3: Bug tracker requirements
4. Part 4: Build server requirements
5. Part 5: Additional tools, server and hosting
6. Part 6: The evaluation candidates
7. Part 7: The evaluation begins
8. Part 8: A little bit more evaluation