I have been shooting for one talk a month, and things are looking great for that goal these days.

• In January, I gave my Economics of Cloud Computing talk at CodeMash.
• This month I gave Deviant Ollem’s Lockpicking talk,
• In March I’ll be giving the Economics of Cloud Computing talk to ColArc,
• In April I’ll be giving my new Software Modeling with ASCII talk to the IEEE and ACM.
• I have a talk lined up for May, I think.
• I have talks submitted for TechEd, DevLink and CodeStock so that should give me lots to do for the summer if anyone accepts me.

Then I just have the fall to worry about.  Pretty good year so far!

Being in the design phase of a large-scale project for the State of Ohio, I have been giving a lot of thought to the problems of Modeling and Design.

You see, I am in an interesting position on most projects – I am an actual Solutions Architect.  In today’s IT environment the term ‘architect’ has grown to mean “good coder with big mouth” and I don’t really fit that mode.  I am not the best coder in the room most of the time – although the size of my mouth could be debated.

What I excel at is the designing of solutions, which leads me to use the term ‘software designer’ to describe myself.  This isn’t terribly good either, as it leads people to believe that I produce pretty graphic design and UX, which isn’t my specialty either.

What I am, in truth, is a Software Modeler.  I am the person that figures out what the domain model looks like based on the requirements of the system and the realities of the project.  The one who stands at the end of the room and scribbles boxes on the whiteboard?  Yeah, that’s me.

Thinking about this has really helped me to hone down the definition of SQL Modeling in my head.  People ask me “Why is Oslo hooked to SQL Server?  Is it just another data language?  Don’t we have enough of these?  I thought M was a language not a database thingie!  Oh woe is me!”  Well, the key is in the difference between design and modeling, and how tightly coupled the model and the database really are.

Software modeling begins and ends with data.  The user interface is, I hate to point out, now the purview of the business analyst.  When I get a functional specification for a project, it has the UI in it right there.  I don’t have to ‘design’ that any more.  All I have to figure out is how to do it.  This effort is modeling, and it is about data.

Today I needed to estimate an inventory system with a few quirks.  Without thinking, I got out my notepad, sketched an ER diagram, and worked from that.  How many POCOs?  How many adapters?  How big is the entity model?  Yes, eventually I had to estimate how long it would take me to build the screens, but the bulk of the work was in the domain model, where the work is done, as it should be.

Imagine if I could have instead described my model in text, without all of the brittleness that the ER diagram entails, and have that text description emit both the databases and the POCOs for me?  And then, if something changes, I could change my scratch model and my other code changes?  What if it didn’t break my changes or additions?  What if it didn’t create scores of stored procedures that are impossible to manage? 

Wouldn’t that be nice.

This, though, is the goal of SQL Modeling.  It is clear as day exactly where it fits in the product lifecycle – right there overtop of my fancy notebook scrawls.  Those boxes and chicken feet have a place somewhere, but it’s time for a modeling solution that actually is a solution.

As part of a project I am working on, I need to create an appointment calendar with appointments that can be tagged with and one (or more) of four tag groups.  The appointment viewer can then be filtered to see only appointments tagged with selected properties.

The tags are stored in a generic pot with all of the tags, and then are themselves tagged by Type. 
(Can amyone say MetaInformation.  Yeah, there’s an app for that.)  The tags of each type should have their own checkboxlist. The UI looks like this:

There are a number of ways that I could implement the collection that I bind to the listbox, but I am using Telerik controls and they would really like a generic list.  OK, I can handle that, right?  I can make a generic List of the particular POCO, and just pass it through.  But … how do I filter?  In the old days I would write a sproc, but these days, we have LINQ, and this is a job for LINQ to Objects (really the only LINQ that matters …)

protected List<Tag> Clients 

{ 

    get 

    { 

        var clients = from x in Tags 

                      where x.Type == "Clients" 
                      select x;         return clients.ToList();  
    } 
} 
  
protected List<Tag> Resources 

{ 

    get 

    { 

        var resource = from x in Tags 

                    where x.Type == "Resource" 
                    select x; 

        return resource.ToList(); 

    } 

} 
  
protected List<Tag> Staff 

{ 

    get 

    { 

        var staff = from x in Tags 

                      where x.Type == "Staff" 

                      select x; 

        return staff.ToList(); 

    } 

} 

protected List<Tag> TextTags 
{ 

    get 

    {         var tag = from x in Tags 

                    where x.Type == "Tag" 

                    select x; 

        return tag.ToList(); 

    } 

} 

Now I can work from the Tags collection in the entity model, and easily get just the values I need.  I can get rid of the magic values with an enumerator, but I thought it was a good use of Linq.

I posted a pic of the latest delivery by my favorite UPS guy, along with a little beer haiku:

Even on cold days
The ups driver can
Bring warmth to my heart

A few people asked about the brew plan, but it doesn’t fit in Twitter.  I thought I would post it here for fun.

Good Night In Mexico

(From TCJOH, page 179)

7lbs Dark DME

1lb Rice

1lb Light Crystal Malt

¼ lb Barley

1 ¼ oz Spalt

1oz Saaz

1oz Hallertaur

German Lager Yeast

Nutcastle

(from BCS, page 151)

7lbs Pale Ale DME

¾ lb Special Roast

½ lb Victory

½ lb Crystal

¼ lb Pale Chocolate

2oz Williamette

Nottingham

Leaden Lager

(Hellbranch Recipe)

7 lbs ultralight DME

3oz saaz

Saflager S-23

So my plan was to start some Android development with Eclipse in Linux, just to sharpen the saw. But you know what?  With all of the improvements in Linux over the last ten years, it still sucks.  If ANYTHING goes wrong, you are screwed.  You have to change some bit flag in some cryptic file that there are four references to in Google, and then restart seventeen times.

Specifically, what I did was install Eclipse in Jaunty Jackalope using Add/Remove.  That was admittedly my mistake – Jaunty doesn’t support 3.4 or 3.5 of Eclipse, which are needed for a quality experience in Android development.  Second mistake – I tried to install Eclipse 3.5 manually over top of 3.2.  HORRIBLE idea.  When I figured out what I had done, it was a mess to fix it.  In short, total time to compile Hello World, 5 hours.

Windows 7 experience: 10 minutes.  We will be talking about Windows.

To get started, you want to install the JavaSDK.

Next you want to install the Android SDK.

Finnally, you want to install Eclipse.

After all of the installations are done, you will want to configure the Android tools for Eclipse.  Part of this is adding the SDK components.  This is all well document, and most importantly, it is hard to screw up.

The only weirdness is the necessity to manually create the package file.  IT’s easy but weird.  From a command prompt, go to the location that you put the Android SDK (Mine is just in the Documents folder) and run this:

android create avd --target 2 --name my_avd

The you just need to create a new Android project in Eclipse.  I’d write about it, but it was so well documented in the Hello World documents.

And there we go.  Got the whole things running, in just about ten minutes.

The actual programming thing, well that’s next.