Adam Hathcock’s Life in Software

When using AutoMapper to map objects from one type to another in your code you need to implement something like below:

var someMappedDto = Mapper.Map<SomeModel, SomeDto>(someModelInstance);

If you look at the code there is a bit of noise here in my opinion. So what do I mean by noise? I consider anything in my code that gets in my way or does not provide me direct feedback as noise.

In the line above I consider the following noise:

1. Mapper.Map – I do not like this because having Mapper.Map sprinkled all over my code base just means that my code has too much knowledge of the actually mapping library we use, this is noise.  Hey, it was for this basic concept that the Common Service Locator was created to help prevent
2. Having to provide both the source type AND the destination type – The source type should be able to be derived from the source object instance (in cases where you do not want to use the mapper for some child type of the source type).  I concede that you do need to provide the destination type other wise we would have no clue what you want in the end
3. Having to provide the source type instance in the constructor. 

In order to reduce the noise, and make for cleaner code I would like to see something like

var someMappedDto = someModelInstance.Map<SomeDto>();

This feels nit-picky but it is something to keep in mind. Especially when using a bunch of generics. C# Extensions are your friend.

Online blogging tools that are designed to make things as easy as possible for anyone to publish online have been around at least a decade and, by now, "blogging" is well-established as a popular form of one- or few-to-many publishing. But a new crop of tools aims to make things even easier by enabling individuals to quickly share several types of common content with others.

There isn't an accepted name for this type of content. If Wordpress et al are used for what we traditionally think of as "blogging," and Twitter is "micro-blogging," these new tools represent something in between those two extremes. Because the focus of these platforms is on easy, quick sharing of content with a group of peers or "followers," I've settled on the term "quick blogging."

(Tumblr, refers to its content as a "tumblog," leading to the terms "tumblogging" or "tumble blogging," but that's too product-centric; e.g. "kleenex" vs "tissue.")

Quick blogging tools are characterized by two main features that set them apart from more traditional blogging tools. One is a focus on specific types of content. Instead of every post being a generic entity, with the author responsible for including the necessary media and formatting, quick blogging tools allow you share specific items like quotes, photos, videos, and links. Each type of item is automatically presented in a suitable format for its content type, and it's possible to use type-specific styling in pre-made or custom templates.

Another main feature is the ease and speed in which the platforms allow users to post new items for others to view. In most cases, items can be posted in as little as two clicks—though there are differences in the two main platforms, Tumblr and Posterous, that we examine here. In fact, the differences in sharing options are a sticking point, which may lead you to choose one service over another.

I like posterous better. The conclusion (as said by a tumblr guy) is that posterous is "engineered" while tumblr is "designed." The statement may be apt. Posterous does need to get more bells and whistles.

Just for the record, I've never posted by email to posterous.

I recently put up a post on my blog about some of the new concurrent collections in .NET 4.0, and I noticed that a lot of people were being sent by Google to those posts who were only searching for System.Collections. I figured that maybe people could use a similar overview of the collections available to them in the System.Collections.Generic namespace, since it seems to me that no one uses anything other than List and Dictionary. So, in this post, I am going to take a look at a few of those collections, and explain exactly why you would want to use them.

Nice to see the new stuff and how it's implemented.

If you include a ResouceDictionary into Themes/generic.xaml you will receive an exception telling you that the dictionary cannot be assigned to property ‘Source’ of object, yada, yada, yada, very informative.

Problem, solution. Thanks google.

I guess it makes sense since other assemblies cannot look at the generic.xaml and use the local URI to resolve the included xaml files.

Oh, right—sorry, I forgot. That devil will whisper, "You know, if you write this code in Visual Basic .NET, you can make the entire codebase Option Strict Off and Option Explicit Off, make the compiler shut up and you can go home early...." Hell, they've been whispering that bit of subversion since 2001. And ye Gods! The leveled cities! burned forests! cute little kitten bodies! all over the place! It's fortunate that we C# developers have kept all those Visual Basic developers on the straight-and-narrow path of true salvation static typing.

Maybe I am a static-typing fundamentalist, but you cannot say that the "dynamic" keyword in C# should be used in anything except Javascript/COM interop situations (okay, there are probably others, but it is a specialized case).

The author argues (and whines) that VB (something else I wouldn't hang my hat on) made people much more productive than C++. It did, but they had worlds of differences between them. VB.NET and C# have near zero. C# just shouldn't have dynamic/duck typing. If you want that, THEN USE ANOTHER LANGUAGE.

At least, he concedes there are different tools for different jobs. Unit testing is an area that a dynamic language excels in. I simply hate using a loosely typed anything in any kind of project that involves more than one person. Tribal styles of coding develop too easily.

Dynamic languages have their place. Just not in my C#, thank you.

Agile is good for refining, not defining.

If you have an existing product that you want to develop to the next level, then Agile in its truest sense works because you have a base upon which to improve. This means that if you know what your requirements are and these have been properly informed with user research, comparative analysis, business objectives, and analysis of what content you have and what you can technically achieve, then Agile alone can work well.

 

But spending money on software development without a plan of what to build is like asking a construction crew to erect a tower with no blueprint. Some level of plan is necessary to avoid a Frankenstein of each individual’s perspective on the best design solution.

This is a well written article with some criticisms of Agile processes (SCRUM) that are perfectly valid. I've experienced some of the same pain at my new job.

It doesn't invalidate Agile, but it does re-evaluate when in the entire process of software development that Agile(ness) is valid.

NUnrar 0.5

I haven't worked on this much in the month since 0.4. I did add non-seekable stream support. In truth, I'm not sure what else to do until I use it in a project or someone else asks for something.

To me, this comes down to the question “is Bar useful solely for obtaining its value, or also for its side effects?” The stylistic choices should typically be driven by a desire to clearly communicate the semantics of the program fragment.

Eric Lippert reiterates a Clean Code practice.

As you start to work with MEF one of the fundamental decisions you have to make is how MEF will be hosted. There are several factors which will impact your decision including whether you are building on Silverlight or the Desktop and whether you are building an application or a library.

MEF is one of the waves of the future in .NET. Tagging for knowledge.

Most people - even the overwhelming majority of programmers - would say that the main activity of a software developer is "writing source code". But this is a (though quite understandable) misconception - and if you take a look at the available figures on the issue or if you - as a software professional - are honest to yourself, the misconception immediately turns out to be an enormous one.

This is a great piece on maintenance and writing code being the easiest/least important part of software development.