Fredrik Normén

ASP.NET, AJAX, Silverlight, RIA, Architecture, Clean Code

  • Using Windows Container to isolate builds, useful for CI/CD

    2 Comments

    When we use a build server to build our projects, we may get in trouble if we build several project on the same build server over time. For example if we have a project that was created and built with a specific compiler version and tools. Then we put that project a side and created a new project that will now target a new version of a compiler and new version of the tools we used before, maybe also install new components that are needed for the new project. Everything is perfect and works great for the new project. But suddenly we need to fix a bug or have a change request for the old project we put aside. Now we open that old project, make some changes we build the project. BANG! Failed! It can fail because of new tools that aren’t compatible with the old version, or some new components installed did some strange thing that break the build.

    Read more...

  • References and Class Library Asp.Net vNext – Alpha 3

    6 Comments

    This blog post is about how to add references and creating Class Libraries for Asp.Net vNext applications. There are two ways of creating a Class Library, either by adding a new project and select Asp.Net vNext Class Library template or just creating a sub folder and add a project.json file to that folder. We can also reference to a NuGet package that already includes a Class Library. Adding a reference to a NuGet or Class Library is done by using the project’s project.json file.

    Read more...

  • How to create your own custom configuration source in Asp.Net vNext

    3 Comments

    One of the new feature in Asp.Net vNext is that we can specify one or several configuration sources, a source where our application configuration is located, for example the old web.config (Xml format), JSON, ini or we can create our own custom configuration source, for example reading configurations from a database or other kind of format. In this blog post I will show you how we can create our own configuration source and use it in the Asp.Net vNext.

    Read more...

  • Database Migration and Azure Mobile Service adventure

    4 Comments

    During the last months I have worked with an API backend for a mobile application. Azure Mobile Service with a .Net backend is our infrastructure platform.  There was a lot of struggling to get Entity Framework Database Migration work the way I wanted it to work. But the solution was quite easy, but needed some few changes that I think shouldn’t be needed at all.

    Read more...

  • Merge hell and Feature toggle

    No Comments

    For about three years ago we use feature branches in our current project. It took about a half to one day to merge those branches before deployment. The reason why feature branches was used was more or less because most team members have worked like that in earlier projects and they thought it was the way to work. At that time some of them also wanted to introduce bug branches! That was the right branch strategies for them, because that was what they have learned.

    Read more...

  • Stop saying "but it works on my computer"

    1 Comment

    Often developers and testers are using their own machines for developing and testing software. The local environment can look different, have different tools installed, even different libraries, sometimes some may use technical previews (like me using Visual Studio 2013 preview ;)). When a new team member is joining the team, it may take a whole day or more until he or she has an up and running local environment for the project. Sometimes several developers and testers works with different projects, that requires different versions of tool, libraries etc, all installed on their own local machine. Can result to a lot of mess and problems.

    It's not so strange to hear someone say "but it works on my computer".

    What if we could check-in all en tools and stuffs we need for a specific project into our source control, and when we work with a project we only gets all the tools and stuffs needed, and have an isolated environment configured and installed for the specific project? Wouldn't hat be something?. I read about teams that adds the compiler they use with other stuffs into source control, and also setup scripts to solve this problem.

    Here is one solution to make it much faster to setup a new environment for both new members and existing members based on the project they are working on, and also remove the words "but it works on my computer".

    Create a Virtual Machine for each projects. Configure and install it with the correct tools and all the things the project requires. Then make sure each team members copy those Virtual Machines to their local computer and start the correct Virtual Machine for the project they should work with. By doing so everyone will have the exact environment for a specific project. It requires of course a good computer with hyper threading. I live in a world where I hope the customer or employee understands that a computer with the correct performance, will reduce time and cost when it comes to develop software. A cheap computer can result in a higher cost compared to a more expensive computer with great performance (At the end of this blog post I will share my story about how I managed to get my former employee to invest in new computers for the whole team).

    Adding Virtual Machines to the source control will probably not be so good, each new branch or history will or can create a copy of a large Virtual Machine. So we need a new kind of "repository" to store the Virtual Machine for each projects, a "repository" everyone in the team have access to. It can be a network share, or on a server where it can be accessible over HTTP etc. Make sure you have a good backup plan for the "repository"!

    By adding a Virtual Machine to a "repository" it would be great to have some kind of pointer to the Virtual Machine to be used in our source control for a specific project. We can for example add a file to our source control that points to the Virtual Machine to be used (from where we can copy/download it, add then add it to our local Virtual Machine environment and start it up). But what if we can make this setup and start up easy for us. What if we could use a simple command like "start the Virtual Machine associated with the project"?

    There is a tool that can help us with this, Vagrant. Vagrant is a tool to that can help us copy/download, setup and start a Virtual Machine locally with just a few lines of commands. Vagrant uses by default Virtual Box but have providers for WMWare. I hope to see one plugin in the future for Hyper-V. Just type the command in your command line tool after Vagrant and VirtualBox is installed:

    vagrant init MyProjectDev http://.../MyProjectDev.box

    Vagrant will now create a local VagrantFile with the information about how to get and which virtual machine to be used. This file can then be checked in into your project source control.

    Then to start up and configure a guest machine, just type the following in the command line tool (make sure you have first navigate to the folder where the VagrantFile is located, probably where you have your local source code):

    vagrant up

    Every team member that should work with a specific project just need to get the latest VagrantFile from source control, and then type "vagrant up" and they have a guest environment started.

    When a new team member joins the team, just install Vagrant and Virtual Box on their machine. Then get the VagrantFile for the project they should work on, and then type "vagrant up". No need to install a lot of tools and stuffs that can take a lot of time before the new team member is up and running. Everyone in the team will use the exact environment for the current project.

    How did I managed to replace all computers with new better and faster computer?

    For several years ago I worked with a large enterprise product. I was frustrated every time I needed to run my code in debug mode. I hated my computer, it was so slow! I often heard team members say the same thing. One day I couldn't just stand it, so I went over to my boss and told him "we need new computers, ours are so slow". The answer was "no!". I tried with several arguments but failed. Then I remember something I read in a book, too many leaders have learned to just watch numbers. So I did the following:

    I opened the solution we where working on. I measured the time it took to build the solution on the local machine, and the time to start it up. I took an average number of times a team member will do this task every day. I took what I guess was the average developers salary and calculated the cost for just waiting to the project to start up, based on one year.

    I went home, did the same thing with my computer at home (a much faster one). Took the price of a new computer times number of developers. I went to my boss and showed him how much new computers will cost, and how much we will save with the new computers compared to the current computers during one year. When he notice how much money the current computer cost in waste compared to investment in new computer. He bought us new computers.

    So sometimes numbers must be included.

    Summary

    By using Virtual Machines, we can setup a development and testing environment for team members fast, and we can make sure everyone uses the correct version of tools for the specific project. By using tools like Vagrant we can make the setup much faster and in an easy way,

    If you want to know when I post a new blog post, please follow me on twitter: @fredrikn

    Read more...