Here is a simple state machine project.
It has a dsl for it’s configuration.
Random outpourings of a software developer
Here is a simple state machine project.
It has a dsl for it’s configuration.
Here is a quick sample that shows how to get rhino etl working.
It moves data from one database into another without any of the complex transforms.
Rhino.Etl.Cmd -c:database.config -f:CopyUser.boo -p CopyUser
=== database.config === Need to replace the [ with the expected angle brackets.
[configuration]
[connectionStrings]
[add name=”source” connectionString=”Data Source=DATABASE_SERVER1;Initial Catalog=databaseName;User=username;Password=password;” providerName=”System.Data.SqlClient.SqlConnection, System.Data, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089″ /]
[add name=”target” connectionString=”Data Source=DATABASE_SERVER2;Initial Catalog=databaseName2;User=username;Password=password;” providerName=”System.Data.SqlClient.SqlConnection, System.Data, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089″ /] [/connectionStrings]
[/configuration]
=== CopyUser.boo === Need to replace [TAB] with tabs
process CopyUser:
[TAB]input “source”, Command = “SELECT strUserID, strParamGroup, strName, strValue from tblParameter where strUserID = ‘FRED'”
[TAB]output “target”, Command = “””
INSERT INTO tblParameter (strUserID, strParamGroup, strName, strValue)
VALUES (‘JOE’, @strParamGroup, @strName, @strValue)
“””
Remember that boo is a tab sensitive.
This is a site that sells peer to peer lending.
That is you can get in on the bank lending risks and rewards.
This seems to be a novel idea.
Version control has two main aspects:
Typically these two needs conflict. Developers that are refactoring frequently don’t check in there changes until they are finished.
This means that one step too far and you have a lot of rework. In addition it is hard to pass a changeset to another developer/machine without compromising the Strategic version control. This may only be an experiment to identify the shape of future work.
Typically these have been solved by having branches in the vcs. However branching is rather expensive.
In a corporate environment you can have a standardised system imposed due to its provision of work item tracking.
You would not want developers checkin in lots of small changes to the strategic branch – just to back them out later.
A neater solution is to use two distinct systems. Keep the corporate vcs for the strategic use (integration testing, structured builds, work item tracking) but allow the devs to have local version control using a distributed version control system such as Mercurial/Hg.
This allows the developer to check in every time that the local code compiles successfully. It allows you to go back that 5 mins rather than spend that hour redoing your work.
Combined with a suitable suit of unit tests this gives a greater degree of freedom to experiment. In addition you can pass these tactical version control changesets between developers or machines. (How do you take tfs away with you so that you could develop on a plane?).
Microsoft are not very good at writing installers.
Here is a good example of an epic fail:
I want to add Visual C++ to the Visual Studio 2008 installation on our build server.
I start with the setup.exe.
This fails (after a long wait).
Some Google searches later and I find that the next step is to use the add/remove programs to trigger the same program.
This fails. Apparently a service packed visual studio cannot have a product added. This is a slow classic partial install then full rollback without a useful message.
So I remove Visual Studio Service pack 1 (which is a slow process).
I then install Visual C++
Then I attempt to reinstall the service pack. Somehow this needs 5 GB on the C: Drive (something the server I am using does not have free) the D: drive has over 80GB of free space, but no the C: drive is the only option. What the hell needs 5GB? I could install an entire operating system with full build chain in less.
So I uninstall Visual C++ and reload the service pack.
Now I am theoretically back where I started (only have lost some time).
The build machine has two build servers on it: tfs and cruise control.Net. (one is for integration testing, the other for deployment builds)
Cruise Control.Net can build our entire source tree. tfs fails on the Silverlight application.
After some more searching I find that the uninstall of VS.Net 2008 SP1 also silently uninstalled the Silverlight VS.NET service pack.
As the build machine does not have direct internet access (don’t ask – the security department is clearly insane).
So I download the service pack installer (70MB) on another machine and then copied to the deployment box.
At this point I find that the installer itself needs to download more.
This means a call to our server team to get the internet access added to the locked down box.
Finally I get the items installed.
I have several complaints:
Why is it so hard to add a product to visual studio?
Why is there no failure log in the installer?
Why must the installer use the C: drive?
Why can’t you download everything that you need to install in one hit?
This is an article on adding drag and drop to a C# application.
Here is the Wikipedia article on Mercurial.
Mercurial/Hg is a great little distributed version control system.
The beauty of this is that there is no central server to get in the way.
A number of times I have worked in places where the central version control server is down (for hours or days) which caused a significant amount of disruption to the development process.