# Composing WCF and ASP.NET MVC4 Applications

By Andriy Drozdyuk Posted on 18 July 2013.

You decided to use Dependency Injection in your application. Unfortunately, your application is not a simple console app that has a main method. It is a complex mess of stuff, including things like WCF and ASP.NET MVC (version 4 in our case). How and where do you compose your application?

# Composition Root

The first thing you need to do is have a composition root. This is a place where all your dependencies will be specified. Here, you specify that “this implementation” provides “this interface”. You should have one composition root per application. If your code consists of multiple applications, like WCF services or ASP.NET MVC web applications—then you need to have multiple composition roots. Of course, you could create some shared code and reuse it in each, but ultimately each application will need to compose itself.

To be continued… (pending examples, di framework recommendation, book recommendation)

# References

1. Dependency Injection in .NET, Seemann, M., 2011, Manning Publications Company.

# Opera Mail or Alternative To Google Reader

By Andriy Drozdyuk Posted on 30 April 2013.

I’ll keep this short.

Google Reader is dead. Chrome does not have a built-in RSS reader. Opera does, it’s called Opera Mail. It looks like this:

You subscribe to feeds by navigating to the RSS feed and clicking on a nice big subscribe button:

# Tutorial on How to write a Haskell Tutorial

By Andriy Drozdyuk Posted on 03 October 2012.

Over the course of reading many tutorials and examples for Haskell and it’s libraries, I can say that there are some things that are an absolute requirement for making it easier for readers to understand your code. Here are the things I think should be in every tutorial or teaching example of Haskell code.

# Explicit Imports

This is so important that it has to be #1. To be able to figure out where a given type or function comes from, always full qualify what you are importing from where.

For example, in the code below, where do the functions ask and put and the types Query and Update come from?

module Test where

import Data.Acid

data MyState = MyState String deriving (Show)

writeState :: String -> Update MyState ()
writeState val = put (MyState val)

queryState :: Query MyState (Maybe String)
queryState = do MyState str <- ask
return $Just str Now if we write it like this, things become much clearer: module Test where import Data.Acid (Update, Query) import Control.Monad.State (put) import Control.Monad.Reader (ask) data MyState = MyState String deriving (Show) writeState :: String -> Update MyState () writeState val = put (MyState val) queryState :: Query MyState (Maybe String) queryState = do MyState str <- ask return$ Just str

which brings me to the next point.

# Explicit Imports of Prelude types

You may know that Maybe monad is imported by the Prelude, but most of the new users will often get confused. So, yes, import the Prelude types and functions explicitly.

import Data.Maybe (Maybe)
import Data.Acid (Update, Query)

data MyState = MyState String deriving (Show)

writeState :: String -> Update MyState ()
writeState val = put (MyState val)

queryState :: Query MyState String
queryState = do MyState str <- ask
return str

# Put Source in Single File

When a new user is getting acquainted with the new library or framework, the last thing he needs to worry about is file or module structure. The user needs to see how components interact with each other. Keeping all the source code in one file (even if long) allows the user to quickly to a text search for a relevant piece of code.

Later tutorials or examples may show the best way to structure the application. In fact, this is what most frameworks provide in a form of starter app or a project template.

# Err on the side of More Comments

Even if you are writing a tutorial, and showing snippets of code, it does not hurt to put comments in that code as well. For example:

-- We'll need this for return types
import Data.Maybe (Maybe)
-- Basic return types for our pure query functions
import Data.Acid (Update, Query)
-- These will allow use to manipulate state

-- What we will persist
data MyState = MyState String deriving (Show)

-- Store a string in a state
writeState :: String -> Update MyState ()
writeState val = put (MyState val)

-- Retrieve a maybe value from the state.
queryState :: Query MyState String
queryState = do MyState str <- ask
return str

while this code may be a nightmare to read or maintain in a real application or for a professional Haskell developer – to a newbie every line is like a piece of gold, clarifying some concepts he or she didn’t completely grasp or understand.

# Provide Library Versions

For every library that you import or reference, provide an exact version that the code you wrote will run with. Haskell is a fast developing ecosystem, and things get broken all the time. For a newbie it is not important that they work with the latest libraries when learning. All they needs is to grasp the concepts and ideas. After which they will be able to go out on their own and infer how these things should work in future versions.

The easiest way to satisfy this requirement would be to include .cabal file with your tutorial or example, which has the Build-depends directive. You can easily and interactively create a .cabal file for you code with the following command, which you should run inside your source code directory:

cabal init

# Explain Difficult Type Signatures

One of the most difficult things for a newbie to figure out is all the types everywhere. So when you have a complicated looking type, take your type to explain what is going.

For example, Acid State tutorial does a great job with this when they explain this type signature:

 update' :: (UpdateEvent IncCountBy, MonadIO m) =>
AcidState (EventState IncCountBy)
-> IncCountBy
-> m (EventResult IncCountBy)

and here is the explanation:

EventState is a type function. EventState IncCountBy results in the type CounterState. So that reduces to AcidState CounterState. So, we see that we can not accidently call the IncCountBy event against an acid state handle of the wrong type.

# Figuring out the Label and Caption in LaTeX

By Andriy Drozdyuk Posted on 12 April 2012.

Sometimes, when you place the label and caption inside the figure out of order, you get weird numbering in your document when you go to reference that figure. What many people don’t realize is that there is a reason for this madness and it is much easier to understand why this happens, then to try and remmember the order in which these things should go.

# Why this happens

Perhaps if people know why this happens, it will be much easier to remember what goes where.

## Short version

Caption command within a figure or table acts much like a sectioning command within the document. So if you don’t put a caption, the label has nothing to “label”, and the closest thing it can find is a section in which you are in.

## Longer version

To understand what is going on we must establish a few things. First, a label command when placed anywhere in the document will label the section of the document in which it is places. So something like this:

Section \ref{sec-one} is great!

\subsection{First section}
\label{sec-one}

This is the first section

Will produce:

Section 2.11 is great!

2.11 First section
This is the first section

Second, label command appearing in a numbered environment acts differently. Numbered environments are things like equation, eqnarray, enumerate, figure, table… In each of these environments the label command acts differently. For example, in eqnarray environment the label can go anywhere before the \\ that ends the current equation - effectively giving each equation it’s own label!

The figure environment has different rules. In particular, the thing that creates numbering inside the figure environment is the caption command. A figure may have multiple captions, creating multiple “sections” within the figure. On other hand, if the caption command is never used, the label still uses the text numbering (which is the number of the section of the document it is in).

Remember: A figure may have multiple captions

So, if we have something like:

\begin{figure}
BLAH
\label{sec:one}
\caption{Blah figure!}
\label{fig:blah}
\end{figure}

we now know that Section \ref{sec:one} will refer to the section of the document in the text and will produce something like Section 2.11.

While Figure \ref{fig:blah} will actually refer to the thing we want and will produce something like Figure 1.

# Conclusion

Since it is difficult to remember which goes first, caption or label, inside your figure, understanding why the order matters completely removes the need for memorization. Since the caption command is responsible for sectioning the figure environment, we know that we must call it at least once before using the label command. By knowing the why we can immediately deduce the how. And that, makes all the difference!

# Reference

I would be lying if I said that I figured this out (no pun intended) on my own. The book “LaTeX: A Document Preparation System (2nd Edition)” by Leslie Lamport—as old as it is—was the primary source for my understanding of this topic.

# Better Vim Configuration

By Andriy Drozdyuk Posted on 12 February 2012.

Having gotten tired of constantly re-configuring my Vim on every computer, I’ve decided to create a Git repository to store all the stuff. I’ve made it public, available for anyone to use: https://bitbucket.org/drozdyuk/vimfiles

What are the advantages of using Git to manage your Vim configuration?

1. Good base to start from. You don’t need to fight with the ugly default configuration of Vim.

2. Better plugin management. By using Git, you can take advantage of Git’s submodules feature, which allows you to easily fetch up-to-date Vim plugins straight from their repositories.

3. Useful Plugins. My Git repository comes with a minimal number of useful plugins, which are tested and working. If you want you can easily add more!