TODO list of this blog

Things I am planning to write and haven't written yet:

1. Using F# as a scripting language.
2. How to create a custom NuGet feed and creating a NuGet package.
3. Custom config transformations in C# projects.

'Currently reading' list:
Pro .NET Performance.

Candidates to read:

1. Patterns of Enterprise Application Architecture
2. Test Driven Development: By Example
3. Concurrent Programming on Windows

Book Review: Domain-Driven Design: Tackling Complexity in the Heart of Software

DDD  itself

It has been some time since I read this fantastic book. As its title implies, the book is about Domain-Driven design. What is it? Wikipedia states the following:

Domain-driven design (DDD) is an approach to develop software for complex needs by connecting the implementation to an evolving model. The premise of domain-driven design is the following:

• Placing the project's primary focus on the core domain and domain logic.
• Basing complex designs on a model of the domain.
• Initiating a creative collaboration between technical and domain experts to iteratively refine a conceptual model that addresses particular domain problems.

The definition above is long because it's hard to write a definition that will be short and formal at the same time. Moreover, this 'long and formal' definition does not really capture the ideas of DDD (at least as I see them):

1. Developers should know and understand the concepts and ideas of business domain and base the design on the model of the domain. I mean, not only they should know about how invoices are handled in the app, but also understand the idea behind an invoice. That understanding is critical to creating designs that adhere to domain model, not fight the model.
2. The domain language is really important in designing the application. Just consider the following sentences. 'We store legs of a journey in a table in the database' OR 'We persist itinerary information'. The second one will be better understood by a domain expert. He might even point out that we don't need to store the whole itinerary,

The lines above are probably no better than the formal definition, but they should give you the idea.

The book

The author talks a lot about ideas, pros and cons of DDD, refactorings that lead to more domain-oriented code. It also discusses several patterns of writing code that can be easily matched to corresponding domain ideas. For example, Strategy Pattern (as well as most of the classic GoF patterns) are not about DDD, but about lower-level OOD, and Specification Pattern is about real-world specifications transformed into code.

Thus the book covers all the levels of applying DDD: from strategic architecture decisions to writing code, it still tends to be more high-level — architecture and design get more attention than code. And I like this idea, because code may be relevant to many developers, but the ideas are relevant for everyone.

My impression

I really liked the book because it gave me several insights on system design and architecture, broadening the range of things I take into account when writing new products or redesigning the old ones. In the same time, on my level of expertise I might need a much shorter DDD intro book (like this one: http://www.infoq.com/minibooks/domain-driven-design-quickly).

Would I recommend reading it? Definitely yes if you are interesting in software design. It won't make you a great software architect after you turn the last page, but it shows you the path.

Breaking the silence

It's been a tough time recently. From the time of the latest post I've managed to read the Domain-Driven Design book, get quite proficient with MSBuild (for better or for worse) and have got promoted from a junior developer to a fully-functional developer.

I'm soon to write a review for the DDD book, and share some code samples with advanced MSBuild features I've learned. But I need time for that, so please be patient.

Scala course on Coursera

Some time ago I've become quite interested in functional programming, so I just couldn't miss the Scala course on Coursera: http://www.coursera.org/course/progfun.

The course was 6 weeks long, starting with basics of functional programming, including the ideas behind this paradigm and lambda calculus. It covered the following topics: functions, types, pattern matching, lists and other collections and lazy evaluation.

The language

The language itself is a mix of functional and object-oriented paradigm, and is inter-operable with Java (although it's almost no use for me as don't have good knowledge of Java). Scala is easy and straightforward to start with and I like it a lot.

What I got

I've had some prior knowledge of functional programming principles, but the course still was valuable to me:

• I've seen a simple, structured overview of the basic ideas of functional programming paradigm
• I've learned the basics of Scala programming syntax
• I've caught the basic idea of lazy evaluation by an example close to real world
• I've seen quite complete programs that solve a particular task written in a functional language
• I now feel much more confident with functional programming

Thus the course effectively put in order everything I had known about functional programming and gave me some new ideas. However, I haven't found a niche for functional languages in my daily work yet, but I still look for it.

Book review: Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman

How and where I got it

Some time ago I've seen a link to the on-line publication of this book at someone's twitter I follow.
I can't now recall or find who it was (it was someone from DDD community, and that is all I remember).
And the exact link was not to the book, but to a specific chapter: Accurate Self-Assessment.
So I've read the chapter, found it interesting and proceeded to the whole book, which is available freely on-line (see the very first link in the post).

The book

The book reminds me about 'The Pragmatic Programmer' book by several attributes:

• it looks at software engineering as at a craft
• it contains lots of common wisdom (i.e. everyone knows a lot of facts from the book, but this does not make the book bad or boring)
• it is high-level, and gives you quite general ideas of things you may do better
• it consists of many cases described as Context-Problem-Solution
• lots of metaphors and zen-related stuff
• it is easy to read :).

As I am a newbie developer, I got lots of useful information from the book: learning, learning strategies, hidden problems of many learning strategies and so on.

Will it be useful for you? Yes, if:

• you feel you are at a plateau of your learning curve for too long OR
• you want to find a good career strategy OR
• you are a complete newbie to programming OR
• you feel you could learn new things more effectively OR
• you are the continuous-learning guy who never stops in acquiring new knowledge.

The book is short, and, were I you, I'd give it a try nevertheless of your current level and skill set.

NETwork Conference 2012 — Kharkiv, Ukraine

On November 10, Saturday, I've attended a conference for .NET developers, called NETwork Conference 2012.

The conference

The conference was held by Sigma Ukraine here, in Kharkiv, for the second time and turned out to be rather good. Obviously the conference was not as exclusive and cool as those expensive conferences abroad, but it was:

• free
• in Kharkiv (not even the capital of Ukraine)
• featured interesting speakers.

So I'd say it was good.

The presentations

Were quite different. I'd like to highlight two of them.

1. Sander Hoogendoorn presented about Agile process and problems of dogmatic application of different Agile techniques. It was quite a refreshing talk because both the topic was interesting and presenter — good.
2. Alexander Konduforov talk about with SignalR. The talk was technical, brief and useful. He covered history of server-side event implementations, shared his experience building real-time web-sites using this library and provided comprehensive answers to the questions from the audience.

I enjoyed both talks a lot.

Several things to mention

1. Live coding at the conferences looks horrible. I've never seen a good coding session during the presentation. A video prepared in advance would be much better.
2. Due to compact schedule I've missed an interesting talk about CQRS. Anyway there were too many people there for the smallest room at the conference. And the largest room was almost empty.
3. The number of rock-star speakers  at the conference decreased compared to the previous one.

Still it was an interesting conference, yet I'd like to have more technical presentations and less about Agile :).

DDD basic definitions

I'm currently reading the Domain-Driven Design book by Eric Evans which has already introduced several interesting concepts of a high-level software design. Three things I'd like to talk about are:

Entity

An entity is an object that is defined by its identity, not by its attributes. For example, a person is an entity as there is no single attribute that defines a human and cannot be changed: name, SSN, full name, and even any composite key built on these attributes can't define a unique and fail-safe indexing. One can change name, sex, hair color and address, but it will be the same person. Well, his identity stays the same.

Value Object

A value object is from different kind of objects if compared to an entity. Value object is defined only through its attributes and needs no other identity. For example, if you have several pens, you only distinguish them based on their color. A color is an attribute of a pen, and asking your friend to pass you a red pen you effectively select an object by its attribute. Of course, a pen can also be an entity if each pen is unique (in a museum of pens, maybe) and you need to distinguish them.

Aggregate

An aggregate is a cluster of associated objects that is treated as a single object when changing data. This sounds like something complex, but it is not. It's just a root (an entity that defines aggregate identity) and a boundary that defines what's inside. A cell phone is an aggregate and its battery is inside its boundary context. Quite simple.

So, now we have objects of three kinds: those that have attributes, those that have identity and those that compose them.

Next thing to discuss is object's life cycle and operations, but I haven't read DDD that far yet.