A Curious Mind
#tastic

Make stuff

A friend of mine started a blog called make stuff with your kid

If you have kids and want to get them back into the physical world this blog should provide some interesting activities. Heck, he's talking about making all kinds of stuff and then showing us noobs how to do it as well!

Cool stuff,

-d

Sample FluentNHibernate Class Map

Please note that this is pre-AutoMap which I haven't dived into yet, but I thought it would be nice to share none-the-less.

    public class LeadMap :
        ClassMap
    {
        public LeadMap()
        {
            Id(o => o.Id);
            Map(o => o.CreatedOn);
            Component(o => o.Company,
                                        x =>
                                        {
                                            x.Map(m => m.Name);
                                            x.Map(m => m.Address);
                                            x.Map(m => m.Website);
                                            x.Map(m => m.Telephone);
                                        });
            Component(o => o.Contact,
                                        x =>
                                        {
                                            x.Map(m => m.Name);
                                            x.Map(m => m.Telephone);
                                            x.Map(m => m.Email);
                                            x.Map(m => m.Title);
                                        });
            Component(o => o.Survey,
                                            x =>
                                            {
                                                x.Map(m => m.DoTheyWantToBeAnAgent);
                                                x.Map(m => m.WhatTypeOfAgentDoTheyWantToBe);
                                                x.Map(m => m.FoundUsVia);
                                                x.Map(m => m.InBizSector);
                                                x.Map(m => m.WantsAFollowUpCall);
                                                x.Map(m => m.WantsToKnowAboutMainProducts);
                                                x.Map(m => m.WantsToKnowAboutOtherProducts);
                                                x.Map(m => m.WantsToKnowAboutPricing);
                                            });
            HasMany(o => o.InterestedIn)
                .Component(x=> {
                                   x.TableName = "Lead_Items";
                                   x.Map(m => m.ItemId);
                }
                ).AsSet();
        }
    }

The Simple Features

Just a quick post about FluentNHibernate. Its such a simple project that is really going to take NHibernate to a new level. The basics are there, and although the AutoMap stuff has just been committed I have already found a feature that has made it a must have: fluent configuration.

var properties = PostgreSQLConfiguration
                     .PostgreSQL82
                     .ConnectionString.Is("User ID=postgres;Password=xxx;Host=localhost;Port=5432;Database=test;")
                     .ToProperties();
           
var cfg = new Configuration()
              .AddProperties(properties);

Awesome!

A multi-lingual domain

I am working on domain where I need to support the ability to translate content. Such as a product description. I am imagining that the domain model might look something like:

product.Description = "Widget";
product.Translation[Language.English].Description = "Tegdiw";

or

product.Description = "widget";
product.Description[Language.English] = "tegdiw";

or

IProduct product = repository.Get(1, English);
product.Description = "wow";
IProduct productZh = repository.Get(1, Chinese);
productZh.Description = "waw";

Of the three I have presented here, I think I like number one the best. I would say that I like it the most because I have done this model before and it seemed to work well, I am just wondering how much I really care that it forces me to have 2 tables per entity that I want translations for (Product and ProductTranslations). Really that's not that bad I guess. Anyways, I wanted to put my thoughts out there to see if anyone else had some better ideas. :)

It's Time to Reread DDD and ADDDP

After listening to David Laribee talk about DDD and then some of his recent posts on DDD, I believe it is time for me to reread DDD and ADDDP and now that I have both I can read them together.

I look forward to sharing any new insights I might be able to generate, especially in regards to the other things I am learning in the area of Lean.

:)

-d

Reaching out to Educators

As a developer that is committed to a style of learning that is continual I am wondering how I can best pass my knowledge on. Not just in the sense of training, but something more fundamental. How can start reaching kids in high school and help to cultivate an interest in software development. How can connect with the educators and administrators to help them see the kind of talent our market so badly needs. I think JP is right here, I shall just go and ask, and see what they need from me.

So if you are an educator and would like to talk to developer in the real world, I would love to have a discussion with you. Please either leave a comment or use my contact form.

-d

Random Thought

If you consider that moving data around via messages is still ETL, then I want to talk a bit about why I think message based ETL or ETL:M is better than batch based ETL or ETL:B (batch based is typified by tools like SSIS).

I believe that one of the biggest reasons we have ETL:B is because Applications don't have a way to talk to each other. So the solution in the past has been to extract some logic from the source and destination applications and bury it in a ETL:B package that runs at regular intervals. Here I see two problems. One the regular interval could cause some very interesting consistency issues, two the extraction, duplication, and obsfucation of business logic in a tool that was most likely not built to provide the same level of explanatory power that well written code can.

ETL:B is like trying to transfer knowledge by brain transplant rather than the ETL:M approach which I believe is more akin to a conversation between two interested parties.

As we move to adopt a more ETL:M approach I think we will find that integrating our application becomes not only an easier process, but a more responsive process as well.

How did I get started?

How old were you when you started programming?

I was probably in high school or middle school and was waaaay into role playing. There was a particular engine (Role Master) that was ridiculously complex in maintaining character stats and skills. Tired of constantly rewriting stuff, i decided to make a massive excel spreadsheet that would do all of the calculations for me. It blew away the group with its awesomeness. :)

What was your first language?

Excel? ;) HTML -> CSS -> MacroMedia -> ASP -> .Net

What was the first real program you wrote?

It was for my first job. It was basically screens over data.

If you knew then what you know now, would you have started programming?

Yes! I probably would have started sooner as well. I didn't really come into my programming shoes until after I graduated college. It was while being a technically competent business person that I evolved into a developer.

If there is one thing you learned along the way that you would tell new developers, what would it be?

Don't accept the Microsoft (or anyone for that matter) way of doing things. Constantly question the reasoning for doing anything. Seek out people smarter than you on any subject and listen to them. Don't settle with one smart person, listen to people on the other side of the fence too. Oh, and read 'Pragmatic Programmer'.

What's the most fun you've ever had ... programming?

Working on my laptop in China completely rewriting an application from WebForms to MonoRail ('Castle On Rails' at the time) and seeing the massive benefits. There was a similar feeling when I moved to NH and needed to make a change and it took me 2 minuets to code.

Tagging

-d

The Developer's Canon of Literature

While at alt.net I had several excellent discussions about what developers should read in order to become better developers. I am sure we all have an opinion on this so I thought I would put my two cents out there.

Some Starting Points on just development

The just past basics Better Practices
  • Test Driven Development by Example
  • SQL for Smarties
  • Object Thinking
  • Domain Driven Design
Messaging Reads
  • Enterprise Integration Patterns
  • Distributed Event Based Systems
  • Patterns of Enterprise Applications Architectures
Project Related Reads
  • Implementing Lean Software Development
Personal Faves
  • POJOs in Action
  • The Thoughtworks Anthology: Object calisthenics
Concurrency Reads
  • Programming Erlang
I am looking for a good Concurrency book.

Eventual Consistancy

Eventual consistency. Given enough time, the system will become consistent.

When no updates occur for a 'long' period of time eventually all updates will propagate through the system and all of the replicas will be consistent.

Where I work the app that was driving me nuts at work was our General Ledger. It would take up to three days to become consistent. It wasn't until I started to explore the topic of EC that I started to build a mental model that could handle the GL being inconsistent.

It can be very helpful to talk to your users about consistency, and what does it mean when they say they need it now. Is half a second acceptable? This is where the 'long' from before can be a bit funny. To a computer half a second is a long time 500 milliseconds (a 2 gigahertz processor cycles about 2,000,000,000 instructions a second, 0.5 seconds is 1,000,000,000 instructions [the math may not be exactly right, but the I think the point is still made])

Another interesting question for me is "What if I can give you consistency today but for yesterdays data?" At work, we have a lot of processes that aren't quite ready for messaging, so some of our processes will be upgraded and others will be quite legacy. So its interesting to see how these two styles come together. Users also have a hard time seeing the shift that can be made by embracing more of this Event Driven style.

-d

More on handling messages

Message Handlers

So having been working on a small app using Mass Transit 0.2 I am trying to come to grips with how I want message handlers to be named and used. Do I call them consumers, do I call them handlers? What about some of the things Grey Young has been saying about message handlers being actual objects? I want to think about these things like MonoRail Controllers but I am not sure that is the best way to think of them. They stay around for one message and process that message then go away, which seems like a controller. However, if we are sending to domain objects, then they are going to have state which I think is bad.

hmmmm.. thoughts?

Mass Transit 0.2

Well today Chris and I decided that MT had reached another milestone of functionality. After having several people review our efforts we have tried to take a lot of the feedback into the system and really polish it up.

This release shows a lot of improvement towards embracing the IoC container quite a bit more. I think that it still has some rough edges around it, but it is an excellent start that should help us to now see where we can further embrace it.

We cleaned up the subscriptions quite a bit, and squashed some bugs that were causing some chatty exchanges. We are also working on a single click install of the subscription manager.

As has been noted previously we are also working on a dashboard that will let you see 'into' the system a bit more, and will be the focus of my work along with automating some more intensive tests. Going to explore just what TeamCity can really do.

Some of the new tests that we are running, and I am looking forward to automating include a load test, load request/reply test, and a load batch test. These three tests have been awesome for ironing out bugs at higher stress levels. I am looking forward to running these on a more automated basis as well as finding new types of tests to create.

The 'host' project has been rewritten to fit a style more comfortable to us as a developer. You basically write a then console program in your project and add a few lines of code to it and off it goes. Much easier to debug into than the old style.

Another new feature and a flavor that Chris will be working on going forward is a Distributed Subscription Cache using memcached that should be a very interesting part of the project to see how it grows and influences the rest of the project.

Batching was rewritten and is now quite a bit smoother, I upgraded the systems at work to include this new API and it reads quite a bit better now.

Not a lot of progress on the build support, which should make working with msmq in your deploy scripts a bit easier to work with.

XML serialization was dropped as it just didn't seem to work as well as we would like. If anyone has a better XML serializer I am all ears. :) The JSON serializer is still in there, but at this point is likely to see little use. The binary serializer is quite nice.

And lastly the project structure has been cleaned up quite a bit, and I look forward to cleaning up and automating even more of the Mass Transit experience. So, pull it down and let us know what you think!

-d

Mass Transit Update

Just wanted to drop a note to say that Chris is on fire! He has written a whole chunk of awesomeness today that should make handling some of our concerns quite easy. We have a new dispatcher sub-system which is quite awesome and will provide a one stop shop for bullet proofing the code to handle errors in a totally awesome way. :)

We are working on the Health Monitoring pieces as well so that you can respond to downed endpoints. How cool would it be that when an endpoint goes down, if you could some how do a NET STOP and NET START as a way to automatically heal (?) a down service.

We are also looking at how we can better integrate an IoC container into the system as well, which should make some of the things we are doing quite a bit easier. :)

So, if you get some time, you should check out the mainline and let us know what you think.

-d

New Flavors I am trying

I am curious to know what everyone is researching into. Below is a list of items that I am actively discussing, reading, or trying to use.
  • Immutable Objects: Trying to write an application where the domain objects are immutable
  • Object Oriented Databases: Trying to write a small sample app with db4o
  • Non-Relational Databases: Discussing where these might be a good fit
  • memcached: Discussing where this tool might be a good fit
  • TypeMock: How does this tool work, and when would I use it over Rhino.Mocks
  • Lean Software Development: Reading two books
  • Erlang: Reading Programming Erlang
  • Messaging

Mass Transit Updates

Just wanted to let you know that Chris laid down some phat beats on Mass Transit this weekend.

  1. Cleaned up the unit tests
  2. Tweaked the load tests
  3. Improved the threading code
  4. Cleaned up MT internals around message sending
  5. Updated the Samples
  6. Added a MonoRail Sample
  7. Cleaned up subscription code

That's some pretty sweet stuff. For more information check out his blog post