Example DSL : Mite

~ chriseyre2000 ~ Leave a comment

This is an example dsl used to create database migration scripts in .Net.

Migrations are a common solution to the database upgrade problem used in the Ruby community.

The idea is that the migration file states the changes to the database so that they can be easily applied and rolled back.

This is far more flexible than a random set of scripts.

Various Rhino Projects

~ chriseyre2000 ~ Leave a comment

Ayende Raihen has started the following Rhino projects

  • Rhino-ESB – Enterprise Service Bus
  • Rhino-ETL – Extract Transform Load
  • Rhino-Licensing – Licensing
  • Rhino-Security – Security
  • Rhino-DSL – Domain Specific Language
  • Rhino-Queues – In memory minimal configuration message queue
  • Rhino-Mocks – Mocking framework
  • Rhino-PHT – Persistent Hash Table
  • Rhino-DHT – Distributed Hash Table

I have been looking at Rhino-ETL and Rhino-DSL lately and should have a look at the others.

Rhino ETL Sample

~ chriseyre2000 ~ Leave a comment

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.

Using Two Version Control Software Systems On One Project

~ chriseyre2000 ~ Leave a comment

This seems to be a novel idea.

Version control has two main aspects:

  • Strategic – release builds for bug fixes and formal testing
  • Tactical – for development

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?).