- One should treat others as one would like others to treat oneself
- One should not treat others in ways that one would not like to be treated
FluentMigrator getting started
I realized on the fluent migrator mailing list today that even though it’s been around for nearly two years, I’ve never written any blog posts describing what it is or example of how it works.
There is some documentation with a very basic walkthrough here: https://github.com/schambers/fluentmigrator/wiki
Brief history of FluentMigrator
When Ruby on Rails first became big everyone grew accustomed to their migration framework that was baked in called Rails migrations. Migration frameworks quickly popped up in other areas and languages. Fast forward a brief time and Nate Kohari, Justin Etheredge and myself threw together FluentMigrator. Initially, the three of us never took it to completion and some gracious community members took it to working completion. Around the same time I was finally in a position to use it myself at a new workplace.
Over the last 12 months, there has been several new contributors and many bug fixes from the community. The community and usage of FluentMigrator has finally reached a place where it’s a living open source project.
What is a migration framework?
First things first. Many people aren’t really familiar with what a migration framework is or if they need one. Many shops I’ve been at have come up with their own way to version the database, many times only forward through time.
The concept is fairly straightforward. Any modification to your database warrants a “Migration”. This migration has both an “Up” method (forward through time), and a “Down” method (backwards through time). With the use of commandline, nant, msbuild you can automate the migration process during deployments to different environments. The migration framework stores a table in each database (by default FluentMigrator calls it’s table “VersionInfo”, in which it stores what migrations have been applied to that database), with this information, the framework can determine what migrations need to be applied to that database (along with what version you told it to go to on the commandline) and will then execute each migration in succession that it needs to apply.
This has some interesting benefits. Now that we have both a forward direction and a back direction, rolling back a database change is as easy as asking the migration framework to go “back” one or more versions. You could even go all the way back to version 0 (a completely empty database) if you wanted to.
FluentMigrator has a fluent interface for manipulating the database at an abstracted level. Because of this database abstraction we’re able to convert the semantic model built with the fluent interface into database commands on multiple different vendors. Currently FluentMigrator supports MSSQL 2000, 2005, 2008, Jet (Access), MySQL, Sqlite, PostgreSql and Oracle. Implementing a new vendor is as simple as adding your own visitee that gets called via the visitor when a migration is interpeted.
Enough with the jibber jabber. How about some samples?
Creating a table with columns, one of them being a primary key
[Migration(201104021153)]
public class CreateUsersTable : Migration
{
public override void Up()
{
Create.Table("Users")
.WithColumn("UserId").AsInt32().PrimaryKey().Identity()
.WithColumn("Name").AsString()
.WithColumn("PhoneNumber").AsString();
}
public override void Down()
{
Delete.Table("Users");
}
}
Some things to note here:
Every migration is a normal csharp class. I usually place all my migrations in one assembly, I’ve seen other people place them where their data related code is. It’s up to you where they go.
Every migration needs a unique identifier in the Migration attribute. This number is interpeted as a long, so we usually use the format of YYYYMMDDHHMM, the chances of two developers creating a migration at the same exact minute are very slim. If we had just normal incremental numbers, we run the chance of two developers of stepping on each other with migration numbers.
Each migration must derive from the “Migration” class. This will make you implement both the Up() and Down() methods. As you can see, Up contains the migration code to go forward in time, Down() is the code that is what you would need to do, to undo the Up migration. Simple enough.
Changing a column name on Users table from “Name” to “FirstName”
[Migration(201104021208)]
public class RenameColumn : Migration
{
public override void Up()
{
Rename.Column("Name").OnTable("Users").To("FirstName");
}
public override void Down()
{
Rename.Column("FirstName").OnTable("Users").To("Name");
}
}
As you can see, on the Migration base class, there is a number of properties that allow you to begin the fluent interface chain. The most common hooks are Create, Delete, Rename, Insert and Execute.
We use the Execute command to call into sql scripts in instances where we need to do something more complex that the fluent interface doesn’t handle. Usually this is some form of changing data or moving data around that would be difficult with the fluent interface. Execute has two methods: Execute.Sql(“sql string”) and Execute.Script(“myscript.sql”).
That’s enough for a primer now, next time we can dive deeper into how we can run the migrations from commandline/nant.
In closing, here’s some links to FluentMigrator:
Till next time!
Managing Wiki content
In the recent past we’ve setup a wiki in my organization, it is used by project managers and developers alike. As a result, we have had a surge of content placed onto the wiki without much organization or planning on what content should go where. Here’s some tips for managing wiki content if you’re using MediaWiki like us, or any wiki software for that matter. Please note that I just recently started to organize our content so if you have any tips please add to the list!
1. Use Categories
Categories provide an easy way to group wiki content. By adding a page to a category, it is added to an alphabetical list on the category page. You can even nest categories within categories for a hierarchical category listing.
2. Group landing page content
One thing that started to happen on our wiki was the landing page became the starting point for any wiki page. We all would place a link to the new page in a general area of where the content fit. Over time the landing page became a very large list of bullet points under a number of headings. Now that we started using categories, we’ve started to cut down on the number of content on the homepage and placing them in relevant category pages.
3. Namespaces
Although I haven’t played with namespaces yet, MediaWiki has a nifty way of “namespacing” your pages into higher level groups. MediaWiki comes with a list of builtin namespaces and you can add your own by making some modifications to the MediaWiki configuration.
4. Use SpecialPages
A great feature that they have in MediaWiki is “SpecialPages“. Special pages provide a great way to find dead content, unlinked pages, long pages and other ways to find content that needs to be refactored. Often, I use these pages as a starting point to target my refactorings. In much the same way that we use static code analysis tools to target refactorings, these pages are a great way to find a starting point.
I’m sure there’s several other great organizing techniques to keeping wiki’s up to date and would love to hear them from everyone and to share with the community. I had a hard time finding any good blog posts on wiki organization so hopefully this will aid someone in the future as a good starting point.
Feature Presentation
Over the past year I’ve taken an active role at my organization of the agile coach (albeit a pretty crappy one) and in my time there tightening up our processes and culture, one thing I’ve come to realize is there are a couple of fundamental agile practices that are so easy to understand and yet difficult for many organizations to adopt.
I’m not referring to technical practices. Often as software developers we focus on the technical aspects of our jobs. While TDD/BDD, IoC, Pair programming, continuous integration and other things are important, we should also challenge ourselves to learn more about the business and what aspects of the software drive money into the company. In the end, it all comes down to the features that are baked into your products. What else pays the bills?
A hard change to make in an organization that is transitioning to agile is getting them to think in minimum marketable features. This type of thought and culture change is a core piece of being able to deliver software iteratively. Without focusing on MMF’s, we get caught up in feature bloat, neglect to release our software early/often and get bogged down in the process. I’ve come to find that feature organization and presentation are an extremely important piece of the puzzle. Without being deliberate with your features, you run the risk of a chaotic feature environment as features bleed into one another and become hard to distinguish. Which in turn makes them difficult to release in significant portions.
At the opposite side of the spectrum it is possible to release TOO many features in too short of a time span. This feels like the software is racing out the door as soon as your’re done compiling the code. While not as dangerous as never releasing features, it results in low quality software as ancillary sanity checks are not performed because of the rapid pace of release. I would argue that this is a better place to be in as far as deployments are concerned, however it’s a worse place to be when it comes to product quality.
I’m sure more posts along this vein will come. This is one I’ve been letting sit for awhile and with the transition to wordpress, I’m attempting to clear the backlog so to speak. Enjoy 🙂
Do Unto Others
There are many concepts that software development processes and management can learn from. Many of them we use for our technical engineering, others apply to processes and still more apply to the organization as a whole. But none come as simple and as important as The Golden Rule. The Golden Rule states:
It’s as simple as this folks. As a team leader every action I perform, every task I ask someone to do I first evaluate this rule mentally to ensure that I am not asking the developer at hand to do something that I would not do myself. It also allows me to reflect on the situation to make sure I am not applying double standards or treating someone unfairly.
Being software developers, our ego’s are larger than usual and we have so much to prove. Often, we forget that we are working with other human beings and our ego’s usually do us more harm than good.
As simple as this rule is to utilize and apply, so many of us get it wrong or ignore it completely. I am continually baffled that so many people do not take this rule into consideration in their daily lives. The karma wheel always comes around, and often at the time when you are at your weakest.
Why not have it benefit you rather than hurt you?
31 Days of Refactoring eBook
Back in August I did the 31 Days of Refactoring blog series. Fellow LosTechies as well as other community members urged me to convert the series into an eBook. I had intended to (really!), but Simone Chiaretta beat me to it and took it upon himself to create the series into an eBook perfectly formatted and threw in some nice styling.
On that note, and a HUGE thanks to Simone for doing this task, you can find the link to the eBook below. I’m sure I’ll format things or may have missed some spelling errors so if you find anything please let me know. Again, huge thanks to Simone for doing this in his spare time. The community thanks you very much as do I.
Jacksonville Code Camp 2009
This past weekend Jacksonville Code Camp took place at University of North Florida campus in Jacksonville. The event was very well organized and donations also went to Goodson’s Children’s Hospital. There was a silent auction fundraiser after the code camp at Sneakers in Jacksonville where all proceeds went towards the children’s hospital.
I did one presentation on SOLID Principles. As noted here are some relevant urls to information about my talk:
https://github.com/schambers/solid-principles/tree/master
At that repository is the presentation and all of the sample code I used during the presentation for your reference.
There was quite a few other interesting presentations. Jim Remsik from HashRocket did a presentation on Agile Storycarding. One of the attendees took some video of the presentation and posted it on vurl which you can find here.
Kevin Wolf demo’d his ORM Smackdown project that shows the differences between several different ORM frameworks along with some great information around each. Kevin definitely put a lot of effort into this detailing and looking at each ORM framework.
I didn’t have a chance to take an immense amount of photos but I did take about 40 that you can find here: http://www.flickr.com/photos/schambers/sets/72157622065448379/
Everyone had a great time and I am already looking forward to next year.
On a sidenote, next weekend (September 5th) is Tally Code Camp in Tallahassee Florida. Shaping up to be another great event. Try to make it out if you can!
31 Days of Refactoring Series complete!
Well, we have come to the end of the series. I hope everyone has found some value in the series. Some examples were extremely contrived and maybe not all that useful but hopefully someone can use them at some point.
As an added bonus at the end of the series I have committed all of the sample code used in the last 31 days into github. You can find all of the sample code available for download here: https://github.com/schambers/days-of-refactoring/tree/master
After also speaking with fellow LosTechies, I am now going to work towards turning this series into an eBook available for download after making some tweaks to examples with your input that you made along the way.
For reference here is the original introductory post with a listing of all 31 posts:
https://lostechies.com/blogs/sean_chambers/archive/2009/07/31/31-days-of-refactoring.aspx
I hope everyone enjoyed! Till next time. 😀
Refactoring Day 31 : Replace conditional with Polymorphism
The last day of refactoring comes from Fowlers refactoring catalog and can be found here.
This shows one of the foundations of Object Oriented Programming which is Polymorphism. The concept here is that in instances where you are doing checks by type, and performing some type of operation, it’s a good idea to encapsulate that algorithm within the class and then use polymorphism to abstract the call to the code.
1: public abstract class Customer
2: {
3: }
4:
5: public class Employee : Customer
6: {
7: }
8:
9: public class NonEmployee : Customer
10: {
11: }
12:
13: public class OrderProcessor
14: {
15: public decimal ProcessOrder(Customer customer, IEnumerable<Product> products)
16: {
17: // do some processing of order
18: decimal orderTotal = products.Sum(p => p.Price);
19:
20: Type customerType = customer.GetType();
21: if (customerType == typeof(Employee))
22: {
23: orderTotal -= orderTotal * 0.15m;
24: }
25: else if (customerType == typeof(NonEmployee))
26: {
27: orderTotal -= orderTotal * 0.05m;
28: }
29:
30: return orderTotal;
31: }
32: }
</div> </div>
As you can see here, we’re not leaning on our inheritance hierarchy to put the calculation, or even the data needed to perform the calculation lest we have a SRP violation. So to refactor this we simply take the percentage rate and place that on the actual customer type that each class will then implement. I know this is really remedial but I wanted to cover this as well as I have seen it in code.
1: public abstract class Customer
2: {
3: public abstract decimal DiscountPercentage { get; }
4: }
5:
6: public class Employee : Customer
7: {
8: public override decimal DiscountPercentage
9: {
10: get { return 0.15m; }
11: }
12: }
13:
14: public class NonEmployee : Customer
15: {
16: public override decimal DiscountPercentage
17: {
18: get { return 0.05m; }
19: }
20: }
21:
22: public class OrderProcessor
23: {
24: public decimal ProcessOrder(Customer customer, IEnumerable<Product> products)
25: {
26: // do some processing of order
27: decimal orderTotal = products.Sum(p => p.Price);
28:
29: orderTotal -= orderTotal * customer.DiscountPercentage;
30:
31: return orderTotal;
32: }
33: }
</div> </div>
This is part of the 31 Days of Refactoring series. For a full list of Refactorings please see the original introductory post.
Refactoring Day 30 : Return ASAP
This topic actually came up during the Remove Arrowhead Antipattern refactoring. The refactoring introduces this as a side effect to remove the arrowhead. To eliminate the arrowhead you return as soon as possible.
1: public class Order
2: {
3: public Customer Customer { get; private set; }
4:
5: public decimal CalculateOrder(Customer customer, IEnumerable<Product> products, decimal discounts)
6: {
7: Customer = customer;
8: decimal orderTotal = 0m;
9:
10: if (products.Count() > 0)
11: {
12: orderTotal = products.Sum(p => p.Price);
13: if (discounts > 0)
14: {
15: orderTotal -= discounts;
16: }
17: }
18:
19: return orderTotal;
20: }
21: }
</div> </div>
The idea is that as soon as you know what needs to be done and you have all the required information, you should exit the method as soon as possible and not continue along.
1: public class Order
2: {
3: public Customer Customer { get; private set; }
4:
5: public decimal CalculateOrder(Customer customer, IEnumerable<Product> products, decimal discounts)
6: {
7: if (products.Count() == 0)
8: return 0;
9:
10: Customer = customer;
11: decimal orderTotal = products.Sum(p => p.Price);
12:
13: if (discounts == 0)
14: return orderTotal;
15:
16: orderTotal -= discounts;
17:
18: return orderTotal;
19: }
20: }
</div> </div>
This is part of the 31 Days of Refactoring series. For a full list of Refactorings please see the original introductory post.
Refactoring Day 29 : Remove Middle Man
Today’s refactoring comes from Fowler’s refactoring catalog and can be found here.
Sometimes in code you may have a set of “Phantom” or “Ghost” classes. Fowler calls these “Middle Men”. Middle Men classes simply take calls and forward them on to other components without doing any work. This is an unneeded layer and can be removed completely with minimal effort.
1: public class Consumer
2: {
3: public AccountManager AccountManager { get; set; }
4:
5: public Consumer(AccountManager accountManager)
6: {
7: AccountManager = accountManager;
8: }
9:
10: public void Get(int id)
11: {
12: Account account = AccountManager.GetAccount(id);
13: }
14: }
15:
16: public class AccountManager
17: {
18: public AccountDataProvider DataProvider { get; set; }
19:
20: public AccountManager(AccountDataProvider dataProvider)
21: {
22: DataProvider = dataProvider;
23: }
24:
25: public Account GetAccount(int id)
26: {
27: return DataProvider.GetAccount(id);
28: }
29: }
30:
31: public class AccountDataProvider
32: {
33: public Account GetAccount(int id)
34: {
35: // get account
36: }
37: }
</div> </div>
The end result is straightforward enough. We just remove the middle man object and point the original call to the intended receiver.
1: public class Consumer
2: {
3: public AccountDataProvider AccountDataProvider { get; set; }
4:
5: public Consumer(AccountDataProvider dataProvider)
6: {
7: AccountDataProvider = dataProvider;
8: }
9:
10: public void Get(int id)
11: {
12: Account account = AccountDataProvider.GetAccount(id);
13: }
14: }
15:
16: public class AccountDataProvider
17: {
18: public Account GetAccount(int id)
19: {
20: // get account
21: }
22: }
</div> </div>
This is part of the 31 Days of Refactoring series. For a full list of Refactorings please see the original introductory post.
subscribe via RSS