You are sitting in your living room with good friends. Your last vacation, how quickly your kids grew up or your last outdoor adventure is the hot topic of the evening. Notorious like you are you have documented many of your life’s moments with your cell phone or your fancy digital camera. All your pictures are safely stored on your network disk station. Showing these pics to your friends is simple. Browse to your disk station with your TV and show the beautiful photographs in full resolution. One day the internal hard drive of your disk station crashes. All your digital memories lost forever (*1)! It doesn’t need to happen. You can easily backup your disk stations to multiple locations such as external USB hard drives or even to the cloud. I personally backup my Synology Diskstation once a week to an external USB hard drive of similar size and to the Azure Cloud. Making sure I never lose my precious digital memories. In this article, I walk you through how you backup your Synology Diskstation to the Azure Cloud and how you can save money by using the newly announced cool storage. Continue reading
In the article on The dangers of ThreadLocal I explained how the introduction of async/await forces us to unlearn what we perceived to be true in the “old world” when Threads dominated our software lingo. We’re now at a point where we need to re-evaluate how we approach thread safety in our codebases while using the async/await constructs. In today’s post-thread era, we should strive to remove all thread (task-local) state and let the state float into the code which needs it. Let’s take a look at how we can implement the idea of floating state and make our code robust and ready for concurrency. Continue reading
In my last post, I explained that remote working is a life changer. I hope you had time to read the linked blog post in the previous installment. There is an interesting quote in Remote working – Now a business imperative.
Still, the survey found a disconnect between employers and employees in terms of just how often those four walls should come down. On average employees said nine days per month would be the right amount of time to telecommute; employers thought it would be about four. That’s a cultural legacy, Markezich said. “So much of business was built around the workplace,” he said. “But over the past few years technology has made it so people can be more productive spending part of their time working remotely.”
So much of business was built around the workplace. The effect of this cultural legacy becomes apparent when you read the excellent posts from Scott Hanselman:
- Being a Remote Worker Sucks – Long Live the Remote Worker
- Tragedies of the Remote Worker: “Looks like you’re the only one on the call”
As we can see, there is a natural bias when you have people working remotely and other working in the headquarter. It is almost an “us” (the headies) vs. “them” (the remoties). But it doesn’t have to be like that! I believe many companies would benefit from fully embracing remote working by removing the headquarters. With that everyone is a remotie. Knowledge can no longer be concealed in the headquarter. Boundaries are removed. All are treated equally. Communication has to happen through the collaboration tools. There are even more benefits for companies. Imagine the costs you safe but no longer needing to pay a magnitude of money for the headquarter infrastructure, heating, electricity and much more.
By the way, Particular Software is a fully dispersed company. There is no headquarter people go to work. Everyone is remote.
Unleash the potential of remote working and get rid of the headquarter problem!
It is now over a year since I started working for Particular Software as a Solution Architect. I work 100% remote, and I enjoy it. In fact, I even believe that remote working should be the new business imperative in the Software Industry. Many employees like me, like working without walls! The top ten benefits of remote working, according to a Microsoft study and quoted by Kevin Kruse on Forbes, are:
10) Environmentally friendly (23%)
9) More time with family (29%)
8) Less stressful environment (38%)
7) Quieter atmosphere (43%)
6) Eliminate long commute (44%)
5) Less distractions (44%)
4) More productive (45%)
3) Avoid traffic (47%)
2) Save gas (55%)
1) Work/home balance (60%)
I experience these and more benefits day-by-day while remote working. I’ll explore the topics of remote working a bit more on this blog in upcoming posts.
To quote Szymon Kulec, one of my remote-workmates:
Working remotely, not to mention working for Particular Software, is a life changer. I think that aftera months I won’t be able to go back. On the other hand, why would I even consider going back at all?
Happy remote working and reading ;).
Dish washing and the Chain of Responsibility Pattern have a few things in common.
In our house, cleaning out the dishwasher is a shared chore. My son starts the unloading process by removing a dish or utensil from the dishwasher. If he can put it away, then he does. If the proper location for the dish is out of his reach, then he passes it to his mother. She then goes through the same process; put the dish away if she can, or pass it off to the next person in line, which is me. When I get handed a dish I will put it away and, since I’m 6’4″ (1.92m) tall, I can reach all of our cupboard space which means that the process ends with me.
If you want to learn more about the Chain of Responsibility Pattern, I suggest you read the full blog post originally posted on the particular blog.
Pss: I know I haven’t been very active on this blog. Unfortunately writing good articles is a time intensive job. I’ve been focusing a bit more on the particular company blog. I’ll try to make sure that I can resume my blogging activities on this blog. Stay tuned
Languages and frameworks evolve. We as developers have to learn new things constantly and unlearn already-learned knowledge. Speaking for myself, unlearning is the most difficult part of continuous learning. When I first came into contact with multi-threaded applications in .NET, I stumbled over the ThreadStatic attribute. I made a mental note that this attribute is particularly helpful when you have static fields that should not be shared between threads. At the time that the .NET Framework 4.0 was released, I discovered the ThreadLocal class and how it does a better job assigning default values to thread-specific data. So I unlearned the
ThreadStaticAttribute, favoring instead
Fast forward to some time later, when I started digging into
async/await. I fell victim to a belief that thread-specific data still worked. So I was wrong, again, and had to unlearn, again! If only I had known about AsyncLocal earlier.
Let’s learn and unlearn together!
If you want to learn more about async/await and why you shouldn’t use ThreadStatic or ThreadLocal with async/await, I suggest you read the full blog post originally posted on the particular blog.
I should not say this in public because I’m a Swiss Guy, but I love the German Community ;). I’ve been giving Usergroup speeches in many German cities over the last few years. Every community event I attended in Germany was fully organized, well-coming, and the community engaged with the speakers and workshop leads. One of the most unusual events in Germany is starting in a few days in Leipzig. It is the Developer Openspace 2015. Here are a few impressions:
Abstract: An Open Space is a conference without speakers or a fixed agenda. Similar to a BarCamp the crowd meets every morning (at a developer-friendly time), and everyone is invited to suggest a session-topic. That can be the latest hot shit from Silicon Valley (or Seattle) everyone has heard about and wants to discuss with others, or something you are highly interested in, so you’re looking for some fellow experts to give you an introduction.
As part of the pre-unconference sessions on Friday, I will be giving a full day workshop about async/await and the Russian Doll model by applying that knowledge to an almost production-ready service bus-library.
Sounds interesting? Don’t miss that community opportunity and visit the official web page, book your flight/train/cab and let’s meet for a beer in Leipzig in October.
Picture shamelessly stolen from Thomas Bandt.
I’m doing a series of async/await related blog post on the particular blog. This one might also be interesting for you.
You might not know this, but the 4.5.0 version of the .NET Framework contains a serious bug regarding System.Transactions.TransactionScope and how it behaves with
async/await. Because of this bug, a
TransactionScopecan’t flow through into your asynchronous continuations. This potentially changes the threading context of the transaction, causing exceptions to be thrown when the transaction scope is disposed.
This is a big problem, as it makes writing asynchronous code involving transactions extremely error-prone.
The good news is that as part of the .NET Framework 4.5.1, Microsoft released the fix for that “asynchronous continuation” bug. The thing is that developers like us now need to explicitly opt-in to get this new behavior. Let’s take a look at how to do just that.
- If you are using
async/awaittogether, you should really upgrade to .NET 4.5.1 right away.
TransactionScopewrapping asynchronous code needs to specify
TransactionScopeAsyncFlowOption.Enabledin its constructor.
If you want to learn more about async/await and how to flow TransactionScopes over continuations, I suggest you read the full blog post originally posted on the particular blog.