Daniel's blog

Handling internal URL parameters

Thu, 14 Jun 2018 00:00:00 +0000

Yesterday I tweeted this:

Dear Twitter: IMO changing URL parameters manually is not a use case and I will not go the extra mile in my application to handle those cases. Discuss! ;-)
— Daniel Rosendorf (@drosendorf) June 13, 2018

and got some answers and questions from colleagues, so I decided to elaborate a bit.

In our current project we build a web application that supports regional instances. For this to work correctly, the user selects a country during registration and immediately gets redirected to the instance corresponding to his selected country if necessary. The instance we redirect to lives under another (sub-)domain, so we are providing the already selected country as a URL parameter. This avoids that the user has to select the country again after the redirect.

We have two links on this page which depend on the selected country. So on each country change which does not trigger an instance redirect, we trigger an event that updates those link targets. This event is normally not triggered when the URL parameter in the navigation bar is changed after the page is already loaded. My coworker added a few lines of code to handle this case as well (he is a very thorough person ;-) ).

And this is the point I want to talk about …

I would not have done this, simply because manually changing the parameter in the URL is not a relevant use case. The parameter is a technical detail which helps us make the application work as expected. To be clear: I have no problem with the few extra lines of code (they are in there and they will stay) and they will probably save us a few extra support cases. But if you are meddling with the URL parameters in my web application, you are doing something that you should not do and therefore I won’t spent any time on helping you with this.

P.S. In any case you should validate URL parameters as any other user provided input to ensure the security of your application!

Moving the blog

Fri, 27 Apr 2018 00:00:00 +0000

Short update: I’m moving away from using Octopress and my own virtual server to build and host this blog. Instead from now on I will be using Wyam to build and Netlify to host it. Comments will be powered by Github or more exactly utterances.

Why? I realized that I do not need the infrastructure of a whole virtual server to host this blog. If I want a server to host a project I can use one hosted in the cloud and spun up on demand. This reduces costs and makes it easier for me to actually blog (hopefully ;-)).

Using utterances allows me to host comments to blog posts on Github which should not be a problem, considering that the main audience of my blog are supposed to be developers. And Netlify has its own CDN. Together with code hosting on Github this is basically an instant win for me ;-).

Updates to the Site

Tue, 02 Feb 2016 00:00:00 +0000

Since changing the layout of the blog I also did some optimizations to enhance it a little bit. Most of those enhancements were proposed by Google PageSpeed, another one I took from the theme setup pages of the used theme, others are more or less mandated by law ;-).

So what did I do?

I optimized the used feature image and my “avatar” using jpegtran which decreased the initial file size by about 10 percent for each image.
I changed my Nginx config to send out Cache-Control and Expires headers for all static assets set to 1 year from request. Here is the config snippet I added to the corresponding server directive:

{% highlight Nginx %}location ~* .(js|css|png|jpg|jpeg|gif|ico)$ {expires 1y;}{% endhighlight %}

I added the async attribute to some of the locally hosted scripts to hopefully shave of a little time by asynchronously executing scripts.
I also added a basic cookie consent notification using Cookie Consent and a little cookie policy site (located here). The text is more or less shamelessly stolen from Silktides own privacy policy site.
Next I added support for responsive images using the Jekyll Picture Tag plugin suggested in the original theme setup pages of the Minimal Mistakes theme.
And last but not least I added Jekyll HTML compression to compress the generated HTML just a little bit. This reduces the index page by about 1570 bytes (which is by about 16 percent) using the following settings:{% highlight Yaml %}compress_html:clippings: allcomments: [""]endings: allignore:envs: []blanklines: falseprofile: falsestartings: [html, head, body]{% endhighlight %}It’s not much, but it’s not bad either and it depends on what markup to original markdown document contains, so numbers will differ.

All in all those are all just micro optimizations but I learned some new stuff and I won’t have to do it in the future.

Changes

Mon, 25 Jan 2016 00:00:00 +0000

It is now the year 2016 and as always things change. But this year is special for me and my family. Things are happening or have already happened, so here is a short overview …

The bad

Unfortunately, this year it will not only be good, but there is also something pretty bad coming up. I will not elaborate too much (there will be probably a separate post in a few months about this), let’s just say that there is some hospital time coming up for our smallest kid and that my wife and I are pretty shaken because of this.

Both good and bad

Next up is something that is both good and bad: I’m going to leave my current employer for a new one. This is bad because I like my current workplace. I like the people, I like the work (at least, most of the time ;-). So why am I going? I feel like I’m not learning stuff as fast as I could. I need people that are as interested in technology and sharing their wisdom about it and other things as much as I am and that is something that’s missing currently. Mind you, it will change but I also need some fresh air.

I’ve been ten years with my current employer and I’ve grown restless in the last years, so I finally decided (with a little push from my wife ;-) to do something about it. And so in march I’m off to new adventures.

Only good

The site was updated a little bit. New layout, a little bit of new technology. While up until now the site was generated by Octopress (which in turn uses Jekyll), the new layout uses mainly Jekyll with some Octopress plugins sprinkled on.

This also changes my blogging workflow. Until this change, I generated the site locally and pushed the generated site onto the server which in turn copied it over to the served directory.Now I only push the source, generation of the final pages is actually done on the server. This allows me to use SSH on my tablet to work on posts as well, so I should be able to blog a little bit more.And that’s the list for now …

Learning something new

Wed, 04 Mar 2015 00:00:00 +0000

TL;DR;

I’ve been coding in C# for more than 10 years now and last week I realized that I feel at home in this language. I feel comfortable in the language, but strangely I do not feel comfortable with this feeling itself ;-)

What’s been happening

For the last few weeks I’ve been involved in a project customizing a DMS for a customer. This customization is mostly done in a strange combination of Java and JavaScript. After a few weeks of coding, I had an excuse to work with C# again and this felt like seeing the day after a very long night. I feel at home when I’m coding C#. Maybe that’s because of the almost 10 years of experience I have in that language. But this also made me think. It’s time to learn something new, to increase the size of my comfort zone.

The list

So here are a few things I want to delve into in the near and not so near future:

Elixir
A quite new language based on Erlang/OTP which should make it the perfect language to implement a web API. The idea is to use the Études for Elixir ebook as an outline for the exercises to get into the language. The solutions will be available on the my corresponding repository on Github.
Aurelia
A new JavaScript client framework developed Rob Eisenberg which looks very nice. The Get Started Guide should provide a pretty good introduction.

Other things on the list include flexbox layouts (which should also help me get into CSS in general ;-), React, OAuth 2.0 and OpenID Connect.

That should pretty much keep my from being bored outside of my day job, so let’s see how this works out.

I need someone to watch my back

Fri, 16 Jan 2015 00:00:00 +0000

TL;DR;

Writing code alone is not easy for me. I tend to get carried away or run into dead ends without someone occasionally steering my back to where I actually should be headed.

A little bit of an introduction

Yesterday I had a talk with a coworker of mine. Somehow we reached the topic of software development and teams in general and I started to talk about how I’m not good in writing code when I do not have someone to help me.

Working alone sucks

And that is coming from me, a self-proclaimed introvert ;-). The problem is that you do not get to talk about your problems the way you sometimes just have to do to think them through from end to end. Also you do not have anyone that immediately sees your code, hence no incentive to actually keep it clean and readable.

Why do you actually need this?

Because I’m lazy. Actually taking care of your code is WORK (no way, really??) and takes time, but it pays off in the long run. Nevertheless one tends to just skip it if he has as much to do as I do in my current project. So a second developer in this case is more of a watch dog. Or not. Of course the additional help is appreciated as well ;-).

Kiss or how I wasted two work days

Fri, 09 Jan 2015 00:00:00 +0000

{% blockquote Wikipedia http://en.wikipedia.org/wiki/KISS_principle KISS principle %}The KISS principle states that most systems work best if they are kept simple rather than made complicated; therefore simplicity should be a key goal in design and unnecessary complexity should be avoided{% endblockquote %}

Today I realized that I wasted almost two days worth of work because I tried to solve problems I did not (yet) have. KISS as defined by the quote above is about keeping things simple, but in my understanding it is also about not doing things that you really do not need.

My problem

I tend to see problems where no problems are. To be more specific, I start to implement a solution to a problem at hand and almost immediately I start to think about future problems that my solution could solve as well. But in the worst case this distracts me that much from the actual problem that I start to lose focus. In this concrete example I’m talking about I worked 12 hours and the final solution did not solve my problem because I missed some details of my initial problem … 12 hours wasted!

The solution

Simple: Focus on the real problem. Ignore anything else that might come up. KISS. If there are future problems where the solution could come handy, I will see it, adapt the initial solution and maybe get something more generic out of the code, but first comes the real problem.

But the funny thing is …

… I’m not actually a fan of generic solutions. Most of the time I actively oppose solving problems that do not yet exist when one of my coworkers asks me for advice. Yet I still fall into this trap. Why is that? I don’t know (that topic is for another post), but mark my words: From this day on I shall focus on the problem at hand and only on the problem at hand ;-)

Week 21, 2014

Mon, 19 May 2014 00:00:00 +0000

Ok, it has been a while since my last weekly post. What happened? Well, work happened, as always. Also something big changed in my personal life. In between there was another ELO training which kept me busy for a whole week and now there are introductions into a new (old) project. So, now review this time because I actually do not really remember the work done in the last view weeks. But the goals are still here ;-).

The goals

There will be blog post this week. A good colleague of mine and me talked about a little architectural solution and I want to test that out. And I will not keep the results or the process to myself.
Finish a very little project (a windows service with self-hosted web to control status and run jobs). This will probably end up in a blog post too ;-).
Do some work.

On this note: Of to do some work, have a nice week!

Week 13, 2014

Mon, 24 Mar 2014 00:00:00 +0000

So, what was up with last week? No post on monday and also no review. Well, I got kind of “sucked into” a training course for ELO. It was interesting and also kept me away from my computer for the last week ;-). So without any further deviations on to the review and the goals for this week.

The review

The blog post is done, have a look!
The prototype … well, its still a prototype and I sadly did not find any time in the last two weeks to work on it.

To be honest, I do not remember too much of the week before last, other than doing a rather satisfactory refactoring on a client project (actually, that was all I did that week ;-). It just feels good when you can replace an overly complex solution with a simpler one that has exactly the same functionality.

The training course last week was interesting although it covered just the basics. I heard that there is an advanced one covering scripting that I will probably attend as well. Let us see where this ends …

The goals

Advance the prototype (depending on the time I have left over this week).
Find a topic for the next blog post.

The goals explain themselves, so I will not go into more detail here.

And now on to a new week.

Tools

Thu, 13 Mar 2014 00:00:00 +0000

As I said last week I am going to talk a little bit about the tools I currently use/have installed on my dev machine. “Tools” in this case meaning almost everything, from languages/compilers to actual utilities and powershell scripts.

And to be honest, this is more for my own benefit as I need to keep track of all that so that I can rebuild it if necessary.

This will be just a list with links to the corresponding blog posts (or whatever) that helped me set the software up, so do not expect too much.

Here we go …

Command line

I am a fan of the command line interface. Not a wizard, but a fan. So here is a short overview over my setup:

Cmder as a host for my standard Powershell console.
msysgit. The only true SCM ;-) in its official windows version.
Powershell (of course) with some custom scripts and extensions in my profile:
- find-to-set-alias to set various aliases for Visual Studio and Sublime Text.
- PsGet
- PowerShell Community Extensions
- posh-git
- I also have a line with a call to vcvarsall.bat in my PS profile:
```
Invoke-BatchFile "C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\vcvarsall.bat" x86
```
  This makes msbuild et al available so I can build most VS solutions from the shell as well.
- Also ssh-agent is started when I start a Powershell session as described in this post by Phil Haack.
Chocolatey. More or less the apt-get of the windows world ;-)
scriptcs. Write C# like it is a scripting language. Nice to play around with.

Languages

.NET Framework (and various corresponding SDKs, of course).
nodejs. For all the JS development that I never come around to.
Ruby. You are not hip anymore without Ruby. Install with the RubyInstaller for Windows.
Python. Nothing to say here.

IDEs

Visual Studio
Sublime Text 3. I use that one for everything I do not use VS for ;-)

That is all for now, but I am almost positively sure that I missed something, so I will very probably update this post in the future.

Week 11, 2014

Mon, 10 Mar 2014 00:00:00 +0000

As detailed in this previous post I am going to blog about my goals for this week (as they are related to work and mildly relevant to you). What I start with today is also a review of the previous week. Oh, and by the way: The reviews will cover any other work related happening I decide to include (almost like a journal) besides the previous weeks goals. So, on to actual content ;-)

The review

First, the goals:

The tools blog post: I started it, but I am not yet sure on what level of detail I am going to write about this. I will very probably do just a short overview together with links and later go into more details (in additional blog posts).
The prototype: I started it and in the course dove a little into jQuery UI and the draggable, droppable and resizable widgets. Interesting stuff, but learning new things always makes me slow ;-)

Additionally, after 3 months on working on a rather interesting project that project got put on hold by our customer. I hope that is temporary because the project and the technologies used are quite interesting. I learned a lot in those months, so let’s hope that the project continues.

The goals

The goals for this week are rather similar to those last week:

Finish the blog post.
Finish the prototype.

Also for the future I will try and choose goals that are actually doable for me in the coming week.

That’s all folks.

Week 10, 2014

Mon, 03 Mar 2014 00:00:00 +0000

What the … ?

So the weekend was nice and I had time to think a little bit about this blog and my (practically) non-existent blogging habit. I want to change that, so here is what I am going to do:

Every monday I am going to write up a list of up to three goals (work or at least somewhat computer related to stay relevant for my also non-existent readers ;-) and will try to keep or reach them during the week.

The next thing the monday posts will also contain are a review of the past week and its goals. Obviously the monday posts will not be written when I am on vacation etc. but I will keep those posts as constant as possible (hear, hear! ;-)

So, enough babbling, on to the goals for this week.

The goals

Write a blog posts about my must-have tools setup as a reference for any future computer setups I have to do (inspired by this post of a good colleague of mine). This will not be a complete list of everything, but I’ll start with the essentials and extend it in the future.
I also want to try and create a little prototype for side project (can not talk about this too much as it is kind of secret, but at least I can mention it here).

So, that’s it for this week. Now I challenge myself to keep those goals and next monday we will see how I did … have a nice week!

Best practices when using Entity Framework Code First Migrations

Tue, 25 Feb 2014 00:00:00 +0000

After seeing migrations in Ruby on Rails a few years ago I regularly searched for an equivalent in the .NET space. Then finally with EF Code First Migrations were introduced. Search done!

Now, after doing two projects using Code First Migrations, here are some basic rules that you should follow¹ if (and only if) you want to avoid trouble with migrations:

Use a local development database.
’nough said.
Use different seeds for different environments.
If your application requires users, your initial seed should in most cases contain an admin user to allow initial access to the application.For integration tests you should only have a bare minimum of data (just enough to get the application/integration tests running). Test-relevant data should be set up/created in your tests and cleaned before/after each test run.
Your seed method should be repeatable.
Take care that your seed method creates one time data really only once (e.g. login data for a specific user or the user itself should not be created again if it already exists). The AddOrUpdate method provides the key selector parameter for that purpose, but there may be cases where that is not enough.
Test your migrations.
The migrations generated by the
```
add-migration
```
command assume an empty database. However once you actually go live your database will not be empty. So test each migration (ideally on a copy of the live database).
Be aware of “merge” issues described in more detail in the MSDN article here.
A few ways to mitigate those are:
- Do not blindly commit your migrations. If you pull/update (depending on your SCM of choice) and you get a new migration that you do not have yet, recreate any migrations you created yourself and which are not yet committed/pushed to avoid merge issues. Take care that you roll back the migrations you are going to recreate to avoid troubles with your database.
- You can also update your model and create your migration for your changes, then immediately commit/push your changes to avoid the point above. But be aware that this approach may lead to more migrations as you make additional model changes during the implementation of a feature.

There are quite possibly more things to keep in mind, but those where the points that I remembered best. In my opinion you should follow all of those rules (with the possible exception of number 2) in any case, otherwise you and your teammates will spend some time to fix issues you will encounter when runningupdate-database and/or deploying your application.

In my not so humble opinion that is ;-) ↩︎

Brainstorming: Living documentation

Fri, 02 Aug 2013 00:00:00 +0000

So it’s been awhile since my last brainstorming article (almost 2 years), but here is another one ;-)

{% img right http://www.daniel-rosendorf.de/images/library.jpg %}

Introduction

So, I’m reading again … after what seems like years I decided to read something “technical” again and this time I want to tackle Specification By Example by Gojko Adzic. After not even finishing the fist chapter an idea that I had some months ago came back to me.

The premise

Imagine a typical software project with detailed specifications and a lot of automated acceptance tests (both of which do exist in every project, right? ;-). In “Specification By Example” Gojko talks about living documentation, which means that specifications are executable and are validated frequently against the project.

Basically the specifications and the examples included are acceptance tests that get executed during the build and reflect the current development progress.

The problem

Unless you are using something like the Gherkin language to do your specifications, there will be no really easy way to translate specifications into tests and test cases that some system can automatically execute. So now what?

The solution (as invented by me ;-)

You already have automatic tests in place and you already have the build fail if a test fails which in turn means you already have a test report. Everything that’s missing is a system to capture the specifications and some way to map the captured specifications to one or more automatic tests.

So that’s what we are going to build.

The web application

The web application has a basic user management and allows for the following things:

Capture specifications (either directly in the web interface or through some kind of import, MS Excel would come to mind … although I really do not know why :P)
Show current state of implementations (Not implemented, Ok, Failing)
Map specifications to tests in a test result report
Upload test result reports

The setup

For this to work the projects test results need to be uploaded to the web application. This can either be done manually (HINT: Don’t!) or automatically by your CI server. For this the web application provides a simple API endpoint to post the documents to.

The workflow

Let’s assume we have a specification that we need to implement. We already have it in the system, so when a customer logs into the web interface the specification is shown as “Not implemented”. Now the developer has implemented some or all examples/test cases and the current test results got automatically uploaded to the application. So the developer logs in, selects the not yet implemented specification and is then able to map test results to this specification, so that after the mapping is done and the developer checks a checkbox during mapping that says “These are all test cases, there will not be any more” the specification and/or its examples will be shown as “Ok”. The mapping is stored so that when a mapped test fails, the project overview will be updated and show the status as “Failing”.

From here on, advanced workflows can be started, e.g. if a specification fails is it because requirements have changed or because of technical dependencies in the system (which probably should not be there).

Great, what now?

I honestly don’t know … but I will make this some kind of conceptual series and blog about design details. So maybe at the end, we have a complete specification that we can implement ;-)

Image courtesy of Yuri Levchenko.

4 simple rules

Tue, 11 Sep 2012 00:00:00 +0000

Why?

I’m feeling quite depressed the last few days and I really do not know the cause of this. Vacation with my family was nice (although my wife was glad when I started working again ;-) and there are no other big factors in my life that pull me down that much. At least that’s what I think …So I decided to do a little experiment this week.

The rules

It’s easy, just 4 simple rules to follow:

Go to bed (and sleep) at 10 pm.
No staying up late.
```
 *Get up at 5.30 am.* 
```
That’s not too much of a problem as the kids are up this early as well :-)
```
 *Do not drink more than 4 cups of coffee during the day.* 
```
This will be harder, because I’m quite addicted to coffee during my working hours.
```
 *Take time to work on your private projects.* 
```
I have severall ideas of website and tools I want to build and it is time to start (and finish) at least one of those.

What are the expectations?

I hope that this will help me loosing those quite depressive (and also quite disturbing) feelings. I don’t know if it will work, but it’s at least worth a try. Wish me luck :-)

Types of tests in a software project

Tue, 10 Jul 2012 00:00:00 +0000

Disclaimer

The following descriptions and definitions are purely based on my own experience and knowledge. People will disagree. So be it ;-). I’m willing to talk about every definition in this post.

Types of tests

Unit test
Typically automated, this kind of tests exercises a single method in a system. In unit tests all external dependencies are mocked so that the tested code is completely isolated. Isolation in this case leads to a test that runs purely in memory as accessing a database of the filesystem would make this an integration test (see below).
Integration test
Normally automated as well this kind of test does test a set of components and their interactions and their integration into the whole (thus the name integration test).
Acceptance test
An acceptance test is another kind of integration test. Its goal is to verify that specific acceptance criterions (which are usually specified on a user story) are met when implementing a specific story.
User interface tests
User interface tests drive the system through its user interface. Integration or acceptance tests may do this through special interfaces or on a layer just below the UI but a UI tests usually simulates a real user interaction like clicking a button or selecting an item in a dropdown.

It’s all just words

Those are the types of tests that come to my mind at the moment. There are more and there are also other names for some of those tests above. Also the definition varies from developer to developer (and that’s good ;-). Nevertheless at least inside of a team a common vocabulary should be used for specific test types.

I hope this definitions help a little.

Why use Continuous Integration?

Fri, 29 Jun 2012 00:00:00 +0000

TL;DR;

Continuous Integration means that all changes are continuously integrated into a common integration branch. This allows for faster “compatibility” checks between various development branches, faster failure in case of test errors resulting from those changes and therefore less time developers have to spend hunting for issues that keep them from developing.

Continuous integration and development workflow

From a developer point-of-view, continuous integration means that you should integrate the changes in your local development branch into a central integration branch as soon as possible. Note the wording “integration branch”. Changes committed to this integration branch may not necessarily be released as there may be still work to be done before the corresponding feature/bugfix is done. This leads to the following branches in your SCM:

master (from which the releases are built)

development/integration (as the name says ;-)

```
a number of feature branches
```

and the following development workflow:

 The developer works on a feature branch.

 As soon as he wants to commit his changes to the integration branch (which should happen at least once a day, possibly more often), he merges his changes from this feature branch into the integration branch.

 After that he checks that his changes do not break anything on his local machine (project still compiles, tests still pass) and then

 pushes his changes to the central repository.

From there, an automated build server gets the lastest version and does a clean build. This ensures that the developer merged everything needed to build the project (sometimes a source file does not get committed etc.), which in turn ensures that each developer can continue working as expected then he gets the lastest sources.

Ensuring the integrity of the build

The workflow above should ensure that the automated build always passes. When this is not the case, fixing the build is the highest priority for the development team, as a broken build means that either

A feature is broken (marked by a failing test ... hopefully)

A test is broken (either because of changed requirements or brittle tests)

The project does not compile (which hinders other developers from getting the latest source and integrating their changes)

Tools

Continuous integration can be done totally by hand. You do not need a build server to check the build, you can do the clean build yourself. Nevertheless there are several tools (or classes of tools) that help you during the workflow:

A build server like [TeamCity](http://www.jetbrains.com/teamcity/), [Bamboo](http://www.atlassian.com/software/bamboo/overview) etc.

A DCVS like [Mercurial](http://mercurial.selenic.com/), [Git](http://git-scm.com/) or [Bazaar](http://bazaar.canonical.com/en/)

As I said, you can do Continuous Integration without those or with other tools, but especially a DCVS eases the integration process.

Complementary practices

Practices like TDD (and its various cousins) and automatic testing in general in combination with a build server allow you to verify the integrity of your project regularly. You can of course leave those out of the chain, but if you do automatic builds you should absolutely integrate automated tests as well (and everyone knows you should do TDD in any case, right ;-).

Blogging is hard

Fri, 01 Jun 2012 00:00:00 +0000

As the title says: Blogging is hard. At least for me. I’m used to consume stuff on the internet, getting myself to write about stuff that actually interests someone is not easy.But why? I guess it’s the process of writing things down.

The problem

Most of the time when I’m developing something I think to myself: “Write a blog post about this!”. Then there are the things to do:

Get a neutral example for the thing you want to blog about.
Most of the time the code you are working on is project specific although the real problem you want to blog about is not (otherwise, why blog about it in the first case?). So you have to come up with a generic example for your problem, which takes time.
Get the code in a form that your readers can work with it.
Although there are people who advocate posting code as images (as to avoid problems with Copy&Paste code) I like to provide the code in my posts as gists. This takes time and I have not yet developed a workflow that makes this fast and easy for me.
Actually write the blog post.
Coming up with the content, wording etc. takes time. I blog primarily for myself yet if no one can pull anything from my posts, the post is essentially worthless (which in fact my be true for this very post).

So, what to do about this?

Blog more. Develop a workflow for blogging. Get used to it. In the end it benefits me. It makes me think about the problem at hand, forcing my to come up with a more generic way to present it, seeing it from a slightly different angle.

And even small blog posts like this one (without too much content ;-) benefit me by familiarising me with Markdown syntax and just plain old writing.

Lowering the entry barrier for new developers on an existing project

Fri, 18 May 2012 00:00:00 +0000

What is this all about?

This post is a short compilation of suggested practices to ease the entry barrier for developers coming into an already running project. As I’m mainly using the .NET Framework and Visual Studio I will describe options that refer to this setup.

This is purely a thought experiment at the moment: None of the things mentioned here were actually implemented or used by me, although I guess there are projects out there (commercial and open source) that use things from this list and I will certainly take care that future projects that I’m involved in will include some of the things mentioned below.

Things you should have/do

Have an easy way to set up a local development database. Use either a tool like RoundhousE or something like EF Migrations.
Have documentation that points to places (or people) of interest (e.g. source control, build server, extended documentation). Suggestions here would be a ReadMe document in the solution folder etc.
If additional software has to be installed to open projects in Visual Studio, provide a simple script that installs them if necessary. Examples would be ASP.NET MVC projects etc.
Have all necessary libraries in a folder within the source control so that they are checked out with the project (or have a script/tool that installs them like the restore option of NuGet)

The very simple goal for this is that a developer checks out a project and immediately has all the things necessary to start working on it without having to contact or disturb another dev.

Note that environment specific assumptions in scripts and tools may exist (e.g. the users machine has to be connected to a specific VPN to successfully execute the script etc.) but this means that they have to be taken care of first.Also take care to provide good error messages and advice if something in the scripts goes wrong.

Why go through all the trouble?

There are several reasons to do all this:

If you are a small software shop, chances are that you need to shift developers frequently. Making it easy for developers to actually develop is just naturally a good thing to do.
Some of the practices above have the additional benefit that they integrate and help with automated builds and Continuous Integration (and its more advanced form of Continuous Delivery)

Final thoughts

Practices shown in this article are overlooked most of the time. But I do not think that they take too much time to setup … at least if you include them from the very beginning in your project. However as mentioned above I do not have the real world practice I’d like to have in this topic which in turn means that I will be missing a lot of points. If anyone has something to add to this list, feel free to leave a comment. I’ll try to update this post now and then to keep this list as current as possible.

Brainstorming: Automatic updates for Winforms/WPF applications

Thu, 24 Nov 2011 00:00:00 +0000

This post is the first of a collection of brainstorming articles I’ll write in the near future. These are primarily meant to note down my thoughts on specific projects and/or feature implementations etc.

Currently a lot of ideas whirl around in my head (which have nothing to do with my potential future project, of course ;-). One of those is an automatic update feature for windows client applications.

The idea is that there are two main components:

An update server which is a web service of some kind. This server would include some tooling to allow for easier package creation (more on that later).
A client library which you can use to enable automatic updates. This may include dialogs for user notification.

The client

The application using the client would include a public key. The packages provided by the update server would be simple zip archives containing an xml file with relevant data (name of the application, version etc.) and the updated component (either an msi file or a dll for simple plugins). The xml file also contains a SHA1 hash of the updated component and will be signed with the private key corresponding to the public key stored in the application.

On startup or whenever the client application would check the update server for updates like this:

The client can also send additional data (like license keys etc.) as an optional parameter in the GetVersionInfo method which may then be processed by the update server. This would change the webervice call above to something like this:

If the user chooses to download the update, the client application will download the whole zip file, extract it and first verify the signature of the xml file against the embedded public key and then the SHA1 hash against the downloaded update to verify its integrity. This should avoid most of the security risks as long as the update server is called via https and has a valid certificate.

The developer of the application will be able to choose whether a valid ssl certificate will be enforced on the client or not.

The server

As mentioned above the server stores update packages and provides a webservice to retrieve the current available version of an application and the update itself.

The server should store those updates in a single directory (maybe one subfolder for each application or updatable component). In the first step the server would only support the creation of the update package via a command line tool (e.g. a Powershell script):

This will ask the user for the passphrase for the private key and generate the xml file with the hash and signature automatically. It will also copy the output (both the update component and the xml file) to the directory provided in the –out parameter.

The zip file for download will be created and cached on demand by the server. Later on a push of updates via the webservice itself may be implemented.

When the client asks for the version info the server will return the values from the xml in the applicable application subfolder. This means the client is responsible for checking if the provided version is newer or not.

Handling of additional data provided by the GetVersionInfo call can be easily added to the service by adding a custom version handler to an internal dictionary:

This is what I have in mind so far, I guess there will be a follow up post to this when more thoughts come up ;-)

Waterfall is dead ... or is it?

Thu, 10 Nov 2011 00:00:00 +0000

{% img right http://www.daniel-rosendorf.de/images/waterfall_medium.jpg %}After working about 6 years on a project for one of our customers the time for me to move on has finally come.

My employer stays the same but I’ll switch to a new project and it really may be a new project in the sense of that theres is not a single line of code written at the moment.We are currently in the state of creating a quote for this new project and there it hit me again: Waterfall … or at least something like it.

But first, a little bit of background: For the last 6 years I worked in an environment that required us to be agile (even if we did not know the right name for it at that time). For the whole of my professional live up until this day I’m used to changing requirements and short deadlines.

But now it looks like in the next project this will change. Not. To be honest, I can not believe in a project where requirements will not change as soon as the customer actually gets to see the product. But I also know that the 1.5 projects I’ve done so far are not nearly enough to be used as a base for such a strong opinion.

Whatever happens, I’ll blog about it.

Image courtesy of baaker2009.

Testing the auto deployment hook

Thu, 20 Oct 2011 00:00:00 +0000

This is just a test post to test the auto deployment hook ;-)

Hello World ... again

Wed, 19 Oct 2011 00:00:00 +0000

Hello world … again. This time in english ;-).

The goal: at least one blog post per week starting with this one … and to familiarize myself with Octopress.

The mission: to not sound stupid and maybe offer some insight for someone who stumbles about my corner of the great interwebs.

Running Nancy with Kayak in a simple console application

Wed, 23 Mar 2011 00:00:00 +0000

Here we go again …

In the last few days a did some smaller experiments for a new project idea that is spooking around in my head. One of those was to try and get Nancy up and running with Kayak in a simple console application.

This post from Louis DeJardin provided a good place to start. Most of the post ist still current but there are some changes you have to make to get this up and running. I have no “official” information but I had to change the provided code in the KayakStarter class from this (taken from Louis post):

to this:

Did you spot the difference? The only change is the third parameter of the call to the Gate.Hosts.Kayak.KayakGate.Start method. This makes the non-working example files from the NuGet package working again, but it also seems like the Startup class is not used anymore.

Maybe someone with more experience in Kayak/OWIN can shed some light on this?