After I was done with my OSS projects, I decided to share the goodness with some of my clients and then came to realize a few issues with my “stop storing dependencies in the repository” crusade.

First, many of the dependencies can’t be published to the public nuget.org server. That means that we need to find a way to store them locally.

Solution: Install local nuget feed.

Why a local Nuget feed is a good idea

Having a local feed allows your company leverage all the benefits of package management internally.

Plus you can use it to cache common used packages in case you have issues downloading them.

How to do this you ask? Well, is not as straightforward as I hoped. Luckily I had the help of @davidalpert to fight IIS configuration and @ferventcoder and @davidfawl to answer all our questions.

After approximately 3 weeks of tinkering with the server, David managed to make it work. (Kudos, yay!)

Here are a few links to follow in order to install the server locally:

• Hosting your own local and remote feed by Phil Haack
• 404 on remote server discussion on nuget site

Key points:

• URL should be http://yourserver:port/dataservices/packages.svc
• Add the .nupkg as mime type with application/zip
• Remember that the new server is not an MVC application
• Be patient, very patient…

I got the server running, now what?

Well now we have to tackle a different problem. I found that some of the projects are using libraries that are not yet published to the public feed.

Though I could package and publish them (I have done so with Structuremap.Automocking and others), some of them are a bit out of date and others are the result of downloading the source, modifying it and compiling it locally.

Either case, I thought that I’d like an easy way of packaging and publishing these packages to the local feed in order to keep using them.

Doing so is also a great solution if you don’t have the time to review if an upgrade would work, or is to risky to do it.

If you read my previous post you already know that I’m using Albacore to generate the nuspec file, build the package, etc.

My first thought was to use those tasks for each of the packages in need to create. And I started to do so.

Rake again and again

After creating a rakefile, copying the libs, etc for the third time,  my laziness sense (similar to spider sense without the awesome and the great responsibility thing) started to tingle indicating that should be a way of avoiding this repetitive task.

• Copy the assemblies to a lib folder
• Generate the nuspec with the name of the library and the version
• Compile the nuspec and create the package
• Copy the package to the destination to be served by the local feed

Instead of writing one rakefile per package, why not just add parameters to the rakefile so I can call it from command line specifying:

• Name of the package
• Version of the package
• Folder where to get all the assemblies

And voila! Here is the result, I hope you find it useful.

To use it, you will have to type something like this:

rake deploy:publish[AvalonDock, 1.0, "c:\project\lib\avalondock"]

Are you doing anything else cool with nuget? Please share!

Basically, the Nuget project solves dependency management for all your .NET projects. That means that you don’t need to search any more for libraries that you need to use like NHibernate or nUnit and just install them from a centralized server.

The path to Nuget

So far I’ve been using Rake for all my builds and I’m super happy with it. Using a DSL specifically designed for building projects is a great advantage, Ruby gives you lots of flexibility and the Albacore gem is the cherry on top.

One of the many things that I like about the Ruby world is gem + bundler combination. For .NET projects I’ve been using also noodle to copy the dependencies to my local folder (usually called lib).

However not everything is ponies and rainbows:

• Ruby based solutions are not always well received in .NET project (no matter how good they are)
• Not many developers publish their libraries / frameworks
• Creating gems with .NET assemblies is discouraged since Nuget was born

All this reasons plus the fact that the .NET community was embracing the idea of package management using Nuget make me consider it as a great option.

However one thing was keeping me from doing the change, and that is the ability of reading a configuration file and use it to download all dependencies (very similar to what Bundler does).

And that was it…. Until a couple of days ago….

Nuget Adoption

Last week I say a tweet by @davidebbo saying that Nuget supports now reading from a config file!

Why is that so important? Because I don’t want to store my dependencies in the repository any more!

The assemblies that we use in a project usually don’t change until we update a newer version. What’s the point of storing them with our code if we can use just a reference to them and download them at our leisure?

It takes way less space to store our repositories and updating the packages quite easier because you just change the references and the configuration file, and that’s it, everyone gets them.

Also imagine sharing in your company all the internal assemblies by publishing them to a local Nuget server instead of having a share drive or similar.  Update the version whenever you want! No more versioning dependencies nightmares! And everything is treated the same way, they are all packages!

So I installed latest version of Nuget (following the link above) and started the conversion:

Step 1: Changing the References

Open your .sln file, remove all your references and add them again by doing right click + Add Package Reference. That would accomplish the following:

• Find the reference in the package server
• Install it to a local package folder (usually called Packages)
• Write a config file with the dependency installed (in the same folder as the project)

Step 2: Modify the Rakefile

I need dependencies in order to build, so I need to make sure that before building all my dependencies are satisfied, to do so I modified the task setup:dep to do the following:

namespace :setup do
	desc "Setup dependencies for nuget packages"
	task :dep do
		FileList["**/packages.config"].each do |file|
			sh "nuget install #{file} /OutputDirectory Packages"
		end
	end
end

And I need to make sure this happens every time before building, so I need a dependency in the build task (remember that I’m using Albacore for the msbuild tasks).

	desc "Build the project"
	msbuild :all, [:config] => [:setup] do |msb, args|
		msb.properties :configuration => args[:config] || : Debug
		msb.targets :Build
		msb.solution = solution_file
	end

Step 3: Enjoy!

That’s it! Super easy! If you want to check the code please go to github and download it.

First of all, I would say that you have to be sure that you would like to be an architect, and for that we have to agree on an architect definition.

An architecture in software development can be considered a collection of different components, each one with a particular role, and the interaction between them through interfaces.

Therefore, an architect is responsible for defining the best architecture in order to solve the problem at hand. In order to do that the architect should have technical roots and technical acuity to grasp technical issues and collaborate with the team to solve them. The architect will have the global view of the system and would be responsible of identifying the major issues that have to be addressed to avoid failure.

An architect has to be close the developers and able to answer questions and provide guidance to the rest of the team. He has to be fond of writing code and familiar with the technology the team is using. A good architect will be a combination of being a excellent technologist, strategist and politician.

The difference between the team leader (or lead developer) and the architect is the scope and the responsibility. The architect has a broader scope that includes interaction between different components, security, response time, etc.

Many times the architect role is considered a “promotion” or the next step in the hierarchy for a lead developer. But that may be a mistake because unfortunately not all the great developers or leads have the broad talents required to be an architect.

So, what should we do to achieve such a worthy goal?

Here is a (mixed) list of subjects to learn and practice (not exclusive, just a starting point):

• Different architectures: Which well known architectures are available?
• Security: How to secure applications and systems, which options are available, benefits, etc.
• Concurrency: How to run process in parallel? Implementation, Benefits, drawbacks….
• Communication and Services: Why be service oriented? What kind of services are available?
• Testing: TDD, functional testing, how to write scripts to test web or desktop apps.
• Storage: Which databases or alternative methods of storage are available?
• Development methodologies: Which ones are available? Why should I use one instead of the other?
• Agile planning and management: How does it work? What is the difference with classic management?
• Source Control Management: SVN, CVS, GIT…
• Continuous Integration: What? Why? When
• Development platforms: Rails? J2EE? .NET? GWT?
• Politics: How to be politically correct and identify managers and customer needs.
• Communication: How to communicate with your team, managers and customers effectively.
• Requirements: What should they look like? When is enough?

Sometimes, architects specialize in one technology or framework (i.e: Web Services Architect, .NET Architect, Testing Architect). I think is natural to have more experience in a particular technology than other but that doesn’t mean that you should ignore the rest. Not always the job you are working on will help you to develop or to grow towards being and architect. That, I’m afraid to say is up to each of us.

As any software professional you have to research, read books, blogs and try to meet others with the same goals. Keep your information up to date, find tendencies, success stories, antipatterns (patterns to identify failure) and guidelines.

Here are some books I like (see the link for the full information) and think can be helpful:

• Patterns of Enterprise Application Architecture
• Design Patterns
• Manage It!
• Enterprise Integration Patterns
• Refactoring to Patterns
• Java Concurrency in Practice
• Enterprise Recipes with Ruby and Rails
• Software Architecture in Practice
• Documenting Software Architecture, Views and Beyond

And here some blogs that I like:

• ScottGu’s
• Haacked
• James Gosling: on the Java Road
• Ayende @ Rahien
• The Planetarium
• StackOverflow

There is no certified recipe, you will find all kind of architects with many strengths and weaknesses. As with any other role, try to find architects that inspire you, people that you respect that will help you to keep your spark alive. Follow them in their blogs, books and conferences. They would lead you to other great professionals for sure.

Here are some of mine:

• Martin Fowler
• Bertrand Meyer
• James Gosling
• Scott Meyers
• Kent Beck
• Scott Guthrie

As a closing remark, keep in mind that is very important to work supporting your team and whatever you do don’t become a “Seagull architect“.

I’ve worked on several projects where the architect was like a seagull. He swooped in, dumped a lot of poop in the form of PowerPoint pictures of the architecture, and left as soon as possible. He didn’t stick around for the hard part of the project: making the product work in this architecture or evolving the architecture so that the product could work by the time of release.2

But if your architect is overly fond of drawing programs and not fond of writing code and can’t really answer the developers’ questions about how to make the parts fit into a coherent structure, you don’t have a real architect. Eliminate that person from your project, and build time into the project for assessing the architecture as you proceed. Add the lack of architecture as an explicit risk to your project so you can manage it.

Not every project requires an architect. If you have no architect, your sponsors should recognize that your team needs time to assess the architecture and see what patterns are emerging.

It’s possible to have an architect who acts as a consultant to the project. It is harder when you have a consultant-architect—Murphy’s Law implies that the architect will be busy on another higher-priority project when you need him or her most.