Here’s the scenario I think a lot of companies out there are working with:

One (or more) server(s) containing

Files

MS Exchange

Intranet

Customer accounts

Other business specific data

Several PC/Laptops connected to the server

In these companies I think people work by copying files from your server, modifying files on their own PC, then saving them back into the respective clients’ folders. This may work for the first few clients because you can’t keep track of the latest version of your product/sotware but when it comes to upgrade to your latest and greatest version…uh oh. Migration is a pain.

Problems I imagine they may still encounter:

Bugs reappearing

Not knowing which version of code is the right one or latest

Two people can’t work on the same project very easily

You shout across the office to say “is anyone using xxx”

Not all source control systems fix all of these issues but many will make your life easier.

… say you are a solo developer working on your own personal project. A centralized repository [SVN] might be an obvious choice but consider this scenario. You are away from network access (on a plane, at a park, etc) and want to work on your project. You have your local copy so you can do work fine but you really want to commit because you have finished one feature and want to move on to another, or you found a bug to fix or whatever. The point is that with a centralized repo you end up either mashing all the changes together and committing them in a non-logical changeset or you manually split them out later.

.. you can have a QA repository that lets the QA team try out the code. If it works, the QA team can push it up to the central repository, meaning, the central repository always has solid, tested code. And it works!

That means you can run experiments in separate repositories, and if they work, you can merge them into the main repository, and if they don’t work, you can abandon them, and it works!

What would I do?

From my current experience I’d choose either Git or Mercurial. Making merging a simpler task sounds like win-win from my point of view.

Here’s the scenario I think a lot of companies out there are working with:

·One (or more) server(s) containing

oFiles

oMS Exchange

oIntranet

oCustomer accounts

oOther business specific data

·Several PC/Laptops connected to the server

These people may work by copying files from your server, modifying files on their own PC, then saving them back into the respective clients’ folders. This may work for the first few clients because you can keep track of the latest version of your product/sotware but when it comes to upgrade to your latest and greatest version…uh oh. Migration is a pain.

Problems I imagine they may encounter:

·Bugs reappearing

·Not knowing which version of code is the right one or latest

·Two people can’t work on the same project very easily

·You shout across the office to say “is anyone using xxx”

Not all source control systems fix all of these issues but many will make your life easier.

… say you are a solo developer working on your own personal project. A centralized repository [SVN] might be an obvious choice but consider this scenario. You are away from network access (on a plane, at a park, etc) and want to work on your project. You have your local copy so you can do work fine but you really want to commit because you have finished one feature and want to move on to another, or you found a bug to fix or whatever. The point is that with a centralized repo you end up either mashing all the changes together and committing them in a non-logical changeset or you manually split them out later.

.. you can have a QA repository that lets the QA team try out the code. If it works, the QA team can push it up to the central repository, meaning, the central repository always has solid, tested code. And it works!

That means you can run experiments in separate repositories, and if they work, you can merge them into the main repository, and if they don’t work, you can abandon them, and it works!

What would I do?

From my recent web research I’d choose either Git or Mercurial. Making merging a simpler task sounds like win-win from my point of view.

One of our clients has a complex Excel 2007 spreadsheet they need to do some automation with. The current solution involves lots of manual steps to create charts in a PowerPoint presentation. To this end I started researching how to add items to the ribbon bar so they could automate tasks with Macros.

However, when I started looking into it more deeply I discovered you could easily create plugins using Visual Studio and manipulate spreadsheets and most of the Office 2007/2010 suite using the Office.Interop DLL.

These are the helpful resources I used to get some development underway:

Custom UI Editor Tool – This tool allows you to manipulate the Ribbon using only XML. You can then use defualt icons and OnAction events to call functions held in your spreadsheet. This means you could ship a spreadsheet template (.xlst) or macro enabled worksheet (.xlsm) with built in ribbon items.

I’ve had some experience with TDD and ASP.NET webforms from a previous project I was working on and we were using a Model-View-Presenter pattern which as far as I can see is pretty much the same as MVC.

The View – This is a dumb portal to communicate information to the user

The Controller – This communicates information to the view and translates it to and from the Model. It is generally unit tested and could communicate with the view via a View Model.

The Model – Contains business logic, stores and retrieves data in a database and is really the concrete information regarding your software project. This is also the data that you may need to mock to check your controller handles user input correctly.

More buzz words I needed to look up/I feel are never explained particularly well:

View Engine – A method of displaying information to the user. See wikipedia for a better description

Routing policy – Rather than using Viewstate, URLs can tell the controller what to display

Dependency Injection – DI allows you to inject objects into a class, instead of relying on the class to create the object itself. (Microsoft)

IOC

“Inversion of Control – IOC specifies that if an object requires another object, the first objects should get the second object from an outside source such as a configuration file. This makes testing easier.” (Microsoft)

Car requires seats. Car should get seats from factory (not the driver/user).

URLRoutingModule – Guesses the page you are trying to reach. No match means it falls back to the default IIS settings. In MVC a URL does not equal a page. Browser requests are mapped to controller actions.

MvcHandler – Selects the controller that will handle the request

JSON – JavaScript Object Notation

The Controllers Execute method, invokes an action method associated with the controller, which in turn, receives user input, prepares a response and returns the requested type. The built in result types are:

ViewResult (which renders a view and is the most-often used result type),

RedirectToRouteResult,

RedirectResult,

ContentResult,

JsonResult, and

EmptyResult

ASP.NET Routing

An ASP.NET Web Forms application is content-centric. An ASP.NET MVC application, in contrast, is application logic centric. It uses a route table to work out which controller to use and associated input data. What I’m not sure about yet is how to save data back to the Model through the view.