This might seem like a minor release but I personally think is a very good and worthwhile update! The first cool thing in this release is that we have now full AppVeyor support in the console runner. By default the console runner uses auto detection to determine whether it is running under AppVeyor and automatically prints out the necessary outputs for AppVeyor to report the progress, the passed and failed specs and more on the user interface. The auto detection feature uses the APPVEYOR_API_URL environment variable. The auto detection can be disabled by providing the –no-appveyor-autodetect flag to the console runner. This behavior is congruent to the TeamCity integration.
The next very cool and anticipated feature is the resharper gallery integration for the plugin. The Machine.Specification plugin can now be installed by using the Resharper Extension Manager for Resharper 8.0/8.1/8.2 and dotCover 2.6/2.7. The old installation way with batch files is still supported. But I strongly recommend to use the Extension Gallery! You’ll see why at the end of this post.
Before you install the plugin you need to make sure all previously installed MSpec plugins are removed.
By default the batch files installed the plugin files into %APPDATA%\JetBrains\ReSharper\v8.2\Plugins\mspec.
- Make sure you close all instances of VisualStudio and delete the mspec plugin folder.
- After that restart VisualStudio, goto the Resharper > ExtensionManager menu and search for Machine.Specifications.Runner.Resharper.
- Install the latest stable version and you are ready to go!
In the future all plugin updates will be delivered automatically via the Extension Gallery and the old installation procedure with batch files will be deprecated. The final picture says more than thousand words
Last but not least I want to give a shout out to the following contributors who provided the AppVeyor support:
This is the seventh post in a series about what makes a team effective. Effective means, the team does the right thing to reach its goal.
I’ve seen several projects that started well, but after about one year into the project problems arose. The developers started to do software archaeology before adding new functionality. They simply weren’t sure any more what happens inside their software. So they went from method to method and from class to class to guess what a change would do (or possibly break).
Their software had become a black box.
Once the team cannot predict the impact of a change, estimations are impossible. The change may take one day when everything just works out fine. Or the change may take several weeks because the change results in a cascade of follow-up changes (also known as bugs). If the team can not even roughly estimate what a change costs, the team cannot plan anymore. They cannot say whether a certain feature is worth building (value is bigger than cost). Therefore, they cannot decide anymore what to do to make a profit.
This is the sixth post in a series about what makes a team effective. Effective means, the team does the right thing to reach its goal.
A lot of Scrum teams work Sprint per Sprint. They seldom look further ahead than a single Sprint.
While they really tackle problems just in time, define requirements as late as possible to eliminate waste, they still suffer from a big problem: Good ideas take time.
Finding a good solution to a hard problem takes normally more time than a single Sprint.
In my last post I showed how to deploy endpoints and to subscribe for events. In this post I’ll cover how to send commands and what ServiceMatrix does for you under the hood.
In order to send a command we apply apply almost the same steps as when publishing an event. We create two undeployed components named AscensionManagement (the sender of the command) and RecruitementOffice (the receiver of the command). The command is we want to send is called AscendToHeaven (number 2 in the overview picture).
This is the fifth post in a series about what makes a team effective. Effective means, the team does the right thing to reach its goal.
Your code prevents doing the right thing
I often see teams that want to do the right thing but can’t. Their software won’t let them.
This is caused by lots of loose ends in the source code. Everything is begun but nothing is finished. There are simply too many open tasks. Or there is a lot of technical debt present. Before the team can do what it needs to do, it has to pay back a lot of technical debt. And there is often not the time for that. A third cause is lack of automation. Everything has to be done by hand. This is error prone and slow. And all takes too much time to do it right, so just add a shortcut more to get it done. But this makes things even worse the next time a decision has to be made.
This is the fourth post in a series about what makes a team effective. Effective means, the team does the right thing to reach its goal.
Not even remotely comprehensible
A lot of software is built today by adding feature after feature very quickly without considering understandability and maintainability.
The result is that new features find their way into the software slower and slower because understandability drops over time.
This is the third post in a series about what makes a team effective. Effective means, the team does the right thing to reach its goal.
When we have a goal in front of us, we tend to think about how we can get there in a single fast step. However, most of the times in software development the goal moves while we are walking towards it. Either because our customer sees our progress and has a better idea, or because we understand the problem a bit clearer and find a better solution.
When the goal moves and we wanted to get there in a single big step, we invested a lot:
- we designed the whole solution up front and
- we probably implemented code that is no longer needed and needs to be removed again (resulting in additional costs)
This is the second post in a series about what makes a team effective. Effective means, the team does the right thing to reach its goal.
Bad coordination within the team is a major reason why teams are not effective. Things are done multiple times (“oh, you already did this? Me, too!”). Unnecessary work is performed because we just assume that this should be done. We miss opportunities to go live early, to add the feature with a simpler, cheaper solution or to act on a good idea. Or we simply build the wrong thing because of a misunderstanding.
Plan the day
In Scrum we have a great opportunity to coordinate within the team on every day at the Daily Scrum.
This is just a quick post which explains how you can rename an existing database in RavenDB. Actually you can’t. What you can apply is the following procedure:
- Create a new destination database in RavenDB with the new desired name
- Export the source database into a RavenDB dump
- Import the dump into the destination database
This operation is an offline operation. You could also use the replication bundle to replicate information from one database into the other on the same server but this only works when you already have setup the source database with the replication bundle activated. I’m not going to cover replication in this blog post.
In my last post I showed how to create a service and a publisher. In this blogpost I will show how to subscribe to messages and how to deploy components to endpoints. In my blogposts about CompositeUI for Service Oriented Systems I called about services or “things”. I don’t cover that theory here. I encourage you to read those blogposts.
Before we can deploy the undeployed component WarehouseRaid we need to create a hosting component for that. This can be done by clicking on “New Endpoint”. In this step we are creating Earth and Heaven as NServiceBus Hosts. There are other endpoint types like MVC site available. For the R.I.P.D sample we are building here, a NServiceBus host is sufficient enough.