Hi folks,
today i proudly present the new version 2.0.0.4 of WADM, a simple addon download manager tool, for the popular video game World of Warcraft.
It is simple and easy to use. Just one click, to keep all your favorite addons updated. Give it a try, perhaps it improves your gaming life.
You can found WADM on https://wadm.codeplex.com or https://github.com/mbodm/wadm
Have a nice day.
Quick on-the-way-post:
Lately i worked a lot with Unity and MEF, Microsofts IoC and Code-Composition solutions. I want to answer 2 questions flying around there for a while:
Q: Is MEF an IoC Container ?
A: Yes, it is. It has his limitations (like IoC containers are limited too, when it comes down to object composition, where MEF, on the other side, is really strong), but yes, it is an IoC container.
Q: Should i use Unity or MEF for dependency injection ?
A: It depends on your needs. Read this excellent article by Peter Vogel, released in the Visual Studio Magazine:
http://visualstudiomagazine.com/articles/2013/04/01/unity-vs-mef.aspx
tl;dr: Use MEF if you need deep and complex object composition, fine-granulary resolve filtering and especially composition from dlls, external stuff and so on, for plugin-like solutions and scenarios. Use Unity if you need interceptions for crosscutting concerns or if you want simple IoC, without the complexier usage of MEF (in MEF you bind to properties via attributes and therefore need some (helper)class, whereas in Unity you directly get the resolved object).
As a side note to Microsoft: It is REALLY time for bundling Unity and MEF functionalities in a new straight redesigned library and deliever it by default with the .NET Framework.
Second thing i want to publish on-the-way is, to differentiate and critisize IoC containers in general. Personally i like em and use em. But i really don’t know, if i should like them. They clearly lead to anti-patterns and therefore sometimes can cause more problems then they solve. Don’t get me wrong: We need dependency injection, or better told, we need max decoupling between parts of software. I just think IoC is not ALWAYS the best approach. But some IoCs want to be the masters of all decoupling. And “one size fits it all” has never really worked well. I have not the time, to go into deeper details here, but as some starting point, read that short but great article by David Arno here:
http://www.davidarno.org/2013/11/13/are-ioc-containers-a-case-of-the-emperors-new-clothes/
Also have a look at the comments, what Mark Seeman (we can call him a DI-Specialist without worries) wrote. Very interesting.
Conclusion: Think about WHAT decoupling mechanism you need WHEN, and if you need an IoC, choose wisely.
Hi. Today i want to preach about differentiation. Do you know this dev guy running down the hill, waving his arms, screaming “Aaasync ! Make eeeverything aaasync !” ? I read and discussed about async on the interwebz lately, and was shocked how many guys like the above be out there (insert here a picture of hundreds of that guys, with torches and pitchforks, running down the hill. Yo, frightening).
Since Microsoft (and others) see the immense necessity of good, stalbe and flexible ansynchronous concepts (btw “mission succeeded with an A” at MS), there exists some big async hype in the community. Ok, it´s new (rather not), it´s fine (correct) and you look so damn professional with it (uuum… we come to that one later ^^). So, i´m a developer since nearly 15 years and i often dealing with async concepts, problems and solutions a lot and want to illustrate some things here.
Before we dive deeper into details, here are some common pro´s and con´s of asynchronous programming:
Pro´s:
Con´s:
Now i want to take some of the statements and dive into a more detailed view. First: With async/await (or rather the TPL) Microsoft gets out the most of what´s possible and user-friendly when it comes down to async programming. Really. The TPL is a very good piece of software and the guys Stephen Toub and others from the MS Parallels Platform Team are very very clever and did a famous job. But i don´t want to teach you, how good it is, how you use it, when you use it and what can you do with it. There are plenty of good tutorials etc. out there or on StackOverflow, MSDN and so on. Instead i want to sharpen your mind for when, where and why eventually not to use async stuff, or prevent to exaggerate it.
There are many scenarios you would and you should use async. Everytime you really need to “not block” (i.e. UI stuff) you want async programming. That is good, that is fine. But, to start with an example, be aware to not begin at the deepest level (we call it level5 now) of your non-blocking-“module” and make level5 async. Cause, level5 has eventually to do some job, before level4 can start with handling something. With so called “Continuations” you can make level5 async and continue with level4 if it´s done. Fine. There is a very high chance that level3 and level4 have some similar relations. And level3 and level2 also. What you have done at the end, is the following:
You build an asynchronous chain of
level5 -> continuewith -> level4 -> continuewith -> level3 …
At the end of the day, you realize: “My whole module runs async synchronous !”. And that´s… not… good. If you do that often and in many modules, you see that the overall performance won´t be that good, cause of possible context switches, worker threadpool tricks and so on. Also you see, that you have a complex code construct that is a little bit untransparent for others or yourself later in time. But the worst thing is, you loose something but you don´t gain something. But if you code all the “synchronous relations” just synchronous and “only” run the “whole module” asynchronous, this would be way better. There is no need for async, where you don´t need async. The example above is really dull and simple, but believe me, you can entrap yourself in complexity and it can lead you to the scenario above, if you don´t keep your eyes peeled.
The next thing, you have to deal with, is the so called “thread-safe” term. Most of the things you code asynchronous will be consumed. Asynchronous, obviously. So, sooner rather than later, you have to to develop your class, methods etc. thread-safe. You have to deal with Concurrent-Classes, with locks{ }, and primarily with “what happens when this happens and at the same time happens that”-stuff. “Race-conditions” and “soft deadlocks” are also words, that you have to deal with.That can be very fast very horrible to handle. It doesn´t have to, but it can.
When it comes down to such scenarios, you need to debug. But then you will realize that you will never can debug async stuff as good as you could do it with synchronous code. The Visual Studio Debugger is really really great (imho one of or the best out there), but when things happen “parallel” to the timeline, happen not at a concrete time, and when things happen simultaneously, the debug process itself (not the debugger´s abitlity to debug to that point) will always be more difficult. No Debugger ever could improve that to a degree, where it´s the same as debugging synchronous stuff.
So what ? Did that mean you should avoid async ? No. Absolutely not ! Instead you should learn when and how to use async. Don´t run blind down the hill, waving your arms and do, under some circumstances, some unuseful stuff that wastes your time and your developer resources, just for dealing with something you don´t have to. I promised in the intro i came to that point later: So, even if it´s a hype and it´s cool today, do you really think, you look good, when you do things without really know what you are doing ? Or better: When and why you are doing it ?
So, what did we learned ? Do not overdo it ! Differentiate ! (Eventually the TDD-Hardliners hear that and shout back frightened: “If you don´t TDD eeeverything, you will go to hell !”).
Now we can form a rule of thumb here:
“Code synchronous as often as possible and code asynchronous only at and to the concrete point where you really need it.”
“Use async when you can straight handle the stuff that comes along with it, but don´t avoid async for that reasons in general.”
There are so many Discussions along that topic, that i can not link em all. But here is some stuff and some viewpoints, by Stephen Toub and others, to start with:
Have fun.
“WPF. I love you. Really ! But sometimes… i hate you !”
So, we all know that the WPF has it´s “own reality”. Sometimes genius, sometimes strange, and sometimes… weird ! In this case, it isn´t something like a strange deep technical behaviour. Instead i would call it a “design thing”.
Let me show what i mean, with the help of a little real time story, happened to me today:
It´s midnight and i code a simple test tool, direct from mind to keyboard. The tool needs to login somewhere, so i have to enter a password. I WPF´ed a lot in the past, but for inexplicable reasons i never had to use a password input field. Hmm, seems like i have to use a TextBox and set some property to “password char” or something else. Thought it works like in Windows.Forms, maybe. Ok, no password char or anything else. Google. Ok, TextBox do not have any password-related stuff cause of security reasons. Uuum what ? Security reasons ? Google: “You have to use PasswordBox now”. Ok, no problem. Thought: “Nice, they make it an own control”. Use PasswordBox. Cause we live in the “new world”, thanks to WPF and MVVM, we use ViewModels, sync Control-State via DataBinding with the ViewModel and have better testability and decoupling. Makes us happy. So, i wanna bind my “password value” from the PasswordBox to my ViewModel. And it hits me like a truck: “Binding can only used with DependencyProperties”. WTF ? The Password-Property is NOT a DependencyProperty ? Why not ??? I figured out they have a “PasswordChanged”-Event and the Non-DependencyProperty “Password”, and you can get your password in cleartext (!) from there, in the event in your code-behind file. And then i thought again: “Security reasons… ?”. So i had to read about it. And it´s weird.
Read that: http://blog.functionalfun.net/2008/06/wpf-passwordbox-and-data-binding.html
If you don´t have a SecureString or any other encrypted password data, then at some point, it will pass the ram. I really don´t know where´s the logic here. Finally i think, also at Microsoft, sometimes some things gonna weird :)
Hello there. Today i released my “World of Warcraft Addon Download Manager” called WADM on codeplex. It’s just a simple .NET tool written in C#, that do what it’s name says. I just play a little bit with codeplex and need something to host there. So i decide that it’s time to share a tool with the community that i want to share since a long time.
My first impression was: Codeplex is really a great site, but it seems that git and i never will become best friends. But codeplex supports alternative version control systems like Mercurial and others, so that’s really no problem. It has a really nice guided system that lead you through the creation process. It’s fast and easy. It’s a great platform to host open source software projects like my small tool or perhaps some of my own .NET libraries.
But back to topic: WADM. So, if you are a “World of Warcraft” gamer like me, take a look at WADM. Perhaps it could improve your gaming life. Just a single click to update all your favorite addons, sounds good to me. Doesn’t it ? So check it out.
For more information have a look at the WADM page
Download it from https://wadm.codeplex.com or https://github.com/mbodm/wadm
Marcel´s Blog 