If you are doing integration over Microsoft Message Queuing (MSMQ) all the provided links in this blogpost could be very useful. Administration of Microsoft Message Queuing (MSMQ) can be hard without the right information at your fingertips. Here you find everything necessary to setup and operate MSMQ successfully. Most of these links are very old and some of the administration information is a bit outdated on latest Windows Servers. Nonetheless are this blog post very helpful to understand the inner workings of MSMQ in order to properly configure it for production. I will add more links from time to time to this blogpost. Continue reading
When I talk to developers and managers about Azure they immediately think about large scale applications, amongst other things like information security & privacy which I won’t cover in this blog post. Let me say you this: No you don’t need terabytes of data and millions of customers to consider Azure! Even in your day to day job as a developer Azure can be really worth it. For example my friend Roland Krummenacher has an excellent blog post series in German called “Real World Windows Azure”. In his series, he talks about how you can leverage azure storage to save large files to reduce the load on your webservers, how you can monitor applications from remote by using Service Bus Relay and more. For some of us these ideas still seem out of reach because we fear the learning, the never ending arguments how evil the cloud is and oh my… don’t event talk about… THE COSTS! In this post you learn to start small with Azure but think big! Continue reading
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.