Ah, interesting and positive coverage on Silverlight.

A friend of mine recently asked, what would be the ideal dream job/work scenario.  I started thinking about it and created this list (Which I’ll be pointing him to).  I thought it would be an entertaining post, so here are the things I came up with.  Please comment with ideas and notions of what would make your dream job/work scenario.

• 30-45 minutes a day for blogging & getting the days thoughts together.- 1-1 1/2 hour lunch with a proper 45 minute to hour long siesta afterwards.  Returning to work for the home run stretch.- Pair development Agile style.  Switching on and off, with stories and the like.  Maybe experiment with the flexible nature of the development style of different developers.  Change pairs at least daily.  Work on reasonable daily work scopes, don’t let the work lag day to day by assigning tasks to large to complete in a pair session.- Downtown PDX Location or otherwise a town center location (Beaverton, Hillsboro, tigard, Gresham?? maybe not Gresham, Hawthorne, Belmont, Mississippi Ave, Alberta, etc).  It adds dramatically to the vitality and creativeness of the developers and their respective solutions.- Friday telecommute for the morning and bulk of the day.  Then meet up for beer/food/beverage of choice day.  Meet about 3 or 4pm or whenever happy hour starts at a designated place that the team chooses.- Assure everyone has a fairly decent laptop.  Not a desktop, there should be no reason to chain someone to a desk for development.  I’ve seen it happen and the laptop allows for a much more relaxed and conducive work tool.  Sometime of course, someone might prefer a desktop, someone might even need an extra hardware kick – which are perfectly good examples.  But a laptop should still be available too.- The team needs to all be in the top % of their respective income brackets.  If they aren’t, the disparity, when learned or guessed or figured out – which always seems to happen, pushes people out of teams, increases turnover, and causes all types of animosity.  Especially when the market is good and there are all those other upper bracket percentages available.- The team needs to be social enough to pull off an effective Agile process, and it helps a huge amount if the team actually gets along on activities outside of work.  Most people that are developers today don’t have too much of an issue with this, especially once everyone gets to know each other and the pair programming kicks in.

That’s just some ideas.  So what else would ya’ll out there in the world have for ideas?  Beer on Friday, Playstation 3, X-Box 360, foosball table, Olympic swimming pool, jet planes, rocket ships, moon landings?   …whoops, got a little carried away.

I’ve been working toward a more and more proactive testing, or test driven development, approach to my work.  With some of my recent BI/OLAP work it has been a bit more difficult, as code isn’t always what needs to be written, sometimes it is just some scripts or ETL processes.  However even these things can benefit from TDD awesomeness!

I however wanted to point out some that Haack pointed out on Research Supports the Effectiveness of TDD and TDD is Also an Organizational Process.  Both of these things, the first I knew would be forthcoming as Haack did, and the later something that I have often discussed with various colleagues.

Now that he’s pointed it out I’m definitely going to have to push harder on new methods for implementing tests against more obtuse environments (such as BI/OLAP Development) and of course keep staying up to speed on the various rock and roll tools such as mbUnit and the various testing techniques.

With that in mind, I think I’ll have to add a few mbUnit and TDD based how to entries to the ole’ blog along with part 2 of my ASP.NET MVC how to.  Stay tuned!

Alright, so maybe it isn’t a dozen, but it sure seems like that a lot of the time.  I was just sitting and going through some old ADO.NET style connection and command creation programmatically, then turned around on another project and started tossing some tables and views into a LINQ Diagram.  I couldn’t help but think, “Wow, after all these years of .NET, there are now a ton of data access patterns and even numerous data connection patterns, classes, and methods.  I decided then, I’d do a quick enumeration of all the connections, data access patterns, and other such methodologies I’ve used to connect to various data sources.

The first methods I ever used where what was available with ole’ .NET 1.0.  Actually, it wasn’t even 1.0, it was the beta product.  One would instantiate a basic connection object, then instantiate a command object passing the stored procedure name and connection object just created as parameters to the instantiation.  From there I would then end up assigning the various parameters of the actual stored procedure.  There had been a few different ways that this would occur.  Sometimes all with one line, instantiation, assignment of the value, or sometimes I would end up breaking it out into multiple lines.  In yet another scenario I would have to instantiate the parameter objects first, so I would do that and then do assignments.  With the basic beta and 1.0 ADO.NET, one could easily spend dozens of ways connecting to data.

The Wade Reynolds way was rather interesting.  He was the senior developer (more like architect) at SCP Pool Corp while I was there.  He had created an entire self creating OR/M with reflection.  We’d call basic procedures and stuff via the procedure, and the parameters and everything would then be available for us to just assign to.  Overall it was a nice setup.  At the core it was using ADO.NET, but one wouldn’t have been wiser for not realizing it.

The third type I remember was my whole sale stumbling full on into OR/M, data mapper, and the tools that generated these layers and objects.  I had worked at creating some business layers and such myself in the past, but an individual developer under tight deadlines really doesn’t have a lot of spare time to churn out entire extra layers.  With the newly found tools, I started creating much more advanced, maintenance friendly, more business enabled applications at this point.  These generation tools really wiped the slate clean for the headache that the database usually was.

Now we’ve got LINQ, which I guess one could say is an OR/M or at least the engine that drives the entity library which is an OR/M.  I look back at the headaches of keeping things in and in sync with a database and it seems in the last couple years.  Over the last couple of years there has been a drastic simplifying drive, while drawing more business functionality and logic into the usage and creation of the database and the related objects used to keep the database.

I for one, am happy with the modern direction of data access and the clarification of the business elements.

I’ve been hearing a lot of discussion about cardinality this and cardinality that. With the topic becoming such a common point of discussion. I decided I would write up something.

First some definitions so that we all have a clear cut idea of what cardinality actually is.  Sometimes cardinality isn’t fully understood at a basic level.  With some of the points I’m going to touch on a full understanding of the basis of cardinality will be needed.

Cardinality : 1. Cardinality is part of formal set theory.  A cardinal number is a type of number defined in such a way that any method of counting sets using it gives the same result.  2. Cardinality is a notion of the size of a set which does not rely on numbers.  It is a relative notion.  For instance, two sets may each have an infinite number of elements, but one may have a greater cardinality.

The second definition is the one that I will discuss further.  I must note, that it is odd that even before anyone is confused, the definitions are in opposition with each other.  Cardinality does or does not include numbers, both specifically defined by use.  For a little more information, check my previous entry Tip o’ The Day.

Now on to some meat of this topic.  When designing cubes and planning the various dimensions of data, cardinality is a key concept that must be taken into account when doing so.  High cardinality high count items make bad dimensions, high cardinality low count and low cardinality low count items make great dimensions. Now before digressing and grumbling about how this might be a stupid statement, hear me out further.

High Count, High Cardinality Data Sets

If you have a large count data set that has no limits, and a high cardinality this is either a questionable data set to turn into a dimension.  These types of data sets; e-mail addresses, user names, or other high cardinality items are not good data sets to use as dimensions.  Sometimes there may be exceptions, but rarely would that be the case.  Generally when there is high cardinality, counts, or other measures and facts are the candidates for these data sets.

High Count, Low Cardinality Data Sets

These data sets usually make a decent dimension because of the ability to pare them down to a set numbers of unique values.  Keep in mind, that whatever a dimension is slicing into, should be visibly readable.  An example would be business departments, or business zones.  Each business department might have thousands or even millions of data points, but when a distinct value is derived from the set of data the cardinality is low enough that one ends up with a low number of actual unique items, making slicing much easier for the people viewing the actual reports.

Mix and Match of High Count and Cardinality Degrees

In both cases above, high count, low or high cardinality, often data sets can be stuck into either category.  Take the birthday of a user database for example.  There are 365 possible birthdays per year, not a good way to slice data.  But if you break it down to just the month or year, you end up with 12 months or x number of years.  This is a perfect example of something to use for a dimension.

On the same note one might have user data, but then have the user data of a particular department noted.  If the user count and user information could be derived and rolled up via the department the break out of user departments into a dimension makes sense.

There are dozens of other ways to look at data.  One of the interesting ideas I heard recently of a high count, high cardinality data set was e-mails.  The e-mails for a particular set where being tracked.  A user wanted to know where the domain of the e-mails where originating from, which individually wasn’t something you’d want a Cube Processing to have to go through.  So instead of trying to derive the origination of each e-mail we had in the data set, we pared the data down to purely just the domain, removing the actual user name part of the e-mail.  From there we where able to pare down the e-mail domain originations into a clear and discernable dimension.

So when it comes to cardinality there can always be more than meets the eye.  Take a second look at high count data sets to make sure they’re really high count, sometimes they can be pared down to reasonable amounts of data.