Pondering M&M's

I was poking around the 'Net and found several lesson plans posted by teachers/professors for other teachers/professors. And a bunch of them involved using M&Ms as a way to demonstrate/illustrate the concepts being taught. I read a couple of these and actually learned a couple of things. One article in particular got me thinking about something I am observing here at work. The article was on demonstrating the radioactive decay of an isotope. And I am wondering if this is somehow related to the two colors (either red or green) in Holiday M&M's in the following observations...

1) the ratio of red to green as they are pored out of the bag - there seem to be more green
OR
2) the ratio of red to green as they appear to be consumed - people appear to prefer green

Yes, these are deep thoughts indeed.

With regard to the ratio out of the bag there are a few possibilities that come to mind. First is the conspiracy theory; where some bean counter (or m&m counter) figured out that red food dye is more expensive (0r some other reason red cost more) and to save money made less red M&Ms. I like this solution better than they common ploy food manufactures use - where they keep the packaging the same size, put less in it, put some adverb on the packing to make you believe it's a better value and change you the same (or more)!

The second possibility that occurred to me is what if (as my observations above show) people just like green M&M's better so they make more of them. Is it as simple that red M&M's just like black licorice jelly beans - they have their fans - but they are a minority. My mind starts wondering on prejudices and stereotypes from here; I think I will say more on this later...

A third possibility is the chaos/random theory - that my measly sample of 5lbs of M&M's just not large enough to draw any conclusions. This is just not as much fun as some of the other reasons.

Every hear the one about why there are so many socks out there without a mate; it's because socks are actually the larvae form of coat hangers. Which is why you always have so many of those. Could something like that be true for M&M's that the all the red one's have "hatched" and become green ones. I guess the opposite could also be true depending upon the larvae time length.

Lastly, could this all be related to the fact that some time ago there was a red M&M scare back in the 1970's; where (if my recollection is correct) they were pulled from circulation. So now they are back. But have people really forgotten? So are people consciously or subconsciously avoiding the red ones and the manufacturer knows it - so they make fewer of them?

Hmm. Just needed to share some of the scary thoughts that roll around in my mind. I think this is one of those times when sometimes words don't mean anything.

Happy New Year!!

Is Yukon Cornelius an Architect?

This blog entry has sat as an idea with no text for over a year now. The reason why? I have no idea what an Architect does; I thought I did, but it’s like grabbing a handful of smoke. Reach, grab, and peek inside … nothing – just like Yukon Cornelius. I have considered myself some sort of an architect (maybe not in title but in the role of) for a long time now.

Since I consider myself an Architect; I want to find ways to make myself a better one. What better way than to read and talk to others about their ideas. So I took to reading a bunch of books and articles on this topic. And while they all make pretty good sense; it’s always sense in the pristine context of a book. It’s easy to define something outside the context things like culture, bureaucracy and politics. Sort of like writing code in PowerPoint; code always compiles/works in PowerPoint. When I talk to people they always seem to define what an Architect does as it pertains to themselves or their organization. Turns out organizations are as varied as the description I am working towards.

My current working description for an Architect is; someone that has enough experience to look at a complex problem and see abstractions. Then uses those abstractions to get something done. Note the lack of detail in what is enough experience and the something is. How much is enough? Far be it for me to put down a number. And depending upon the something I may put some other qualifier in front of the work architect; such as “enterprise” or “solutions”. But how many qualifiers do I have to come up with? What if I downsize my something to a piece of code? Since much of coding is about finding abstractions; does that make it an architectural exercise? Nope that’s design. Reach, grab, peek …

So have found the need for an additional definition that is used to help the first. An Architect is someone that gets stuff done at multiple levels in the organization; which means doing some sort of planning (budget, project, envisioning, etc) one minute, setting up a standard for building wizzy widgets the next and finishing off the day with a little code. This definition helps to differentiate pure coding and design from the larger activity of architecture. Architects are expected to some level of design and coding (again meant in a very broad way to include activities like scripting or installing) but they are often meant to do in a way that is not exclusively coding or design. Reach, grab, peek … Better, but notice how long this entry is getting. This is taking way to long!

When talking to people who have no idea what working in the computer field is like; I use an even simpler version of the second definition. I shorten it to be – “I am a guy who gets stuff done” (sometimes substituting another four letter “s” word for stuff). Hey if you can’t easily describe what you do to a total stranger in an elevator ride then you either need to rethink what you are doing or abstract it down to something easier for them to understand. Unfortunately, this abstraction is so abstract that it encompasses everything.

And nothing. Reach, grab, peek …

Guess I need to rethink my career and start staying at Holiday Inn Express to become proficient at something else.

MSDN Magazine Part 2

As I was scrolling down through my previous posts; I noticed the one I did about MSDN magazine. The three most recent issues (which all arrived at once) did not have the outside folding cover. I don't pretend that I had anything to do with it, but it does make me wonder if others complained. We may never know.

Back-ing into Enterprise Web Applications

Sometimes I just don't know what to blog about. Is it just me? So when I don't have anything I feel is new or original, I guess I need to go back to something old. I know I have blogged about building applications in the browser before. Maybe not on this blog, but certainly on one of the many outlets I have had over the years. This topic has come up again as I consider the implications of technologies like Silverlight 2.0 and AJAX on building enterprise applications.

I really like the browser, but I am not sure it makes a great application platform. It makes me wonder why it seems like we need all these “other” technologies to make it a better platform. Take for instance the Back button. When browsing I am a big fan of the Back button (actually I am still a keyboard kind of guy and I use the backspace key - old habits die hard). Whether you like it or not, I think you will agree it is a standard that a lot of people now understand.

So when I host an application in the browser, what does the Back button do? Or perhaps a better question is what does the user expect the Back button to do? Why would they think it would do anything different?

"Hey, I'm in the browser. There's this big, prominent button with "Back" written on it". Why would I not want to press that?"

As it turns out using technologies like Silverlight 2.0 and AJAX seem to totally ignore this. They ignore it to the extent that you lose a lot of navigation context if you use it. For instance, say I am traversing down through a hierarchy. I get some number of levels deep and I want to
back up to a previous level - hit the back button? Better not if that traversal was being done using AJAX!

By the way this is not an entirely new problem; I first encountered this problem when an application I was reviewing for a client made such extensive use of session that the back button did not do what the users expected. So we spent a fair amount of time and energy coming up with ways to preserve the Back button functionality. First we found some hack that essentially
disabled the back button (ironically, by navigating Forward). Secondly we built our screens such that they used the query string to pass some basic context from one screen to the next; so that when you navigated back the browser would pass all the context back (since all it typically saves is the URL). An additional benefit we got from using the query string was that nearly every page was bookmark-able. The only exception was when you were in edit-mode; we not try to “save” transitive or volatile states.

Couple of side notes... It seems that the Back button works much better in ASP.NET even though the context is not stored n the query string. I have not taken the time to figure out the exact details of how this is working; but I imagine it has something to do with the browser caching pages and VIEWSTATE. Noteto self - go figure this out someday. Found this interesting article to a Java Framework to handle the Back / Bookmark problem introduced by AJAX. I have to imagine that some resourceful person has done something similar on Codeplex (or alike).

There is a time reporting application (to remain anonymous) we use at my current job that makes fairly good use of AJAX. That is in the sense that it does improve the response time and interactivity of the application. The downside is that I continuously get burned by use the back button. Argg!!

On the contrary, the MSDN library site does a pretty good job of mixing the two paradigms such
that when I hit back; the “right” thing happens. Sure, neither of these are enterprise applications (in fact comparing them to one another is hardly fair) but the problem remains.

In my mind I am questioning why we are still using the browser for enterprise applications at all. I know why, but I don’t know why. I mean, the reason why it’s so attractive is that it helps in two major areas; distribution and disaster recovery. Distribution is the whole thing that got
us here in the first place. The DR aspect is something I have been realizing more and more in this post Sept 11 world where DR is something I have to consider more and more. It’s just easy to deploy the web application to two physical sites (managed by some content manager); one the primary and the other the secondary. Give a large enough pipe you can load balance between
the two and have a scalable/HA solution to boot.

By why do they have to run in the browser? Why, why why? Here is what I
propose instead…

1. Build an application as a native Windows .NET application based on a 3-tier architecture. No HTML but some technology like WinForms or WPF.


2. For the middle tier I would like to use something the Entity Framework and LINQ. I have a question as to whether I am going to have a marshalling/serialization issues with this technology.


3. The applications are deployed using something like ClickOnce deployment.


4. In addition, I want to get rid of the requirement to have a specific .NET framework installed. I like the direction the Xenocode people are taking. Basically linking the .NET Framework into your application thereby bringing all the code and the dependencies down as part of download / install.

Just thought I would put some thoughts out here and see what if anyone is
actually listening. Hopefully you also were able to hand on until this point.
Regardless it’s a place for me to vent; kind of like my diary.

Web Application User Interface Paradigm

To Blog or Not To Blog...

We have been having some internal discussion at the company I work for about blogging both internally and externally.

Now I am not very prolific or anything so my blog is probably not a big deal. In fact it seems like it is more of a novelty than anything else. Every now and then someone will come up to me and tell me that they stumbled across my blog and found a couple of interesting (i.e. funny) things. The issue "the company" has with blogging is twofold; first that I not reveal anything that would compromise the competitive secrets or that I not tarnish the image. Both of which I understand I have honored. I don't mention any specific vendors or names. I mean really - what programmer in the Enterprise has not had a problem with the infrastructure folks.

Internally, we want to start blogging as a way of documenting things in the same vein that MSFT seems to be going - that is that is more than just communicating what is going on at any given moment but also as a way of documenting things. I find it interesting how many blogs MSFT people have posted and the amount of information on them. In fact, many blogs seem to be a replacement for traditional documentation. Which as long as I have a strong search engine - works fine for me.

Which brings me to the one thing that is preventing me from rolling internal blogs out - how do I find anything. We plan on using MOSS and Office 2007 as our blogging platform, which actually works pretty well. The only concern is how strong the MOSS search engine is. I guess the only way to tell is to try, but I am just dragging my heals. I have so much other stuff on my plate that it's hard to get any momentum behind this.

As I write this I feel the energy building, I just hate a whiner.

Services (part 1 of many)

I not been blogging much lately because I have felt like what I have been working on is just not blog-worthy. We "outsource" most of our infrastructure services to an internal division; which was recently turned over to a large outsourcing firm. So I have been spending much of my time "training" the folks who I interact with on a near daily basis to do what I need them to do. As it turned out this was not a trivial task. And that's all I have to say about that. :-)

I am beginning to look at building out some data services. In the Investment Management business data is king; especially market data. What I am learning (or should I say re-learning or feeling pain around) is that without the data in place the service is nearly useless. So my project is really turning into data project where I am bringing in and reconciling market data vendor feeds. Oh yeah and by the way I am exposing them as a service.

Which has me questioning myself; why a service in the first place? I just want to make sure I am actually providing real value and not just overhead. I think the key reason for a service here is provide a single well define abstraction of the backend. We have so much market data and so many sources of market data; that providing a flexible abstraction makes sense. My expectation is that we will be consuming this data right from Excel (the universal financial application platform) as well as many of our custom applications.

I remember presentations back in the mid-90’s when I was a Microsoft and we were listening to the early internal presentations on Microsoft Transaction Server (MTS) by Pat Helland and James Utzschneider. They were talking about MTS interception and how you can accomplish cool things when you can get in the middle. That is exactly what we are trying to do. Once we get the abstraction of the data, we can begin to do some cool things.

My biggest concern about building a service is performance. In past lives when I have built services I would always warn people that if you need fast performance then web services you should think long and hard about not using web services. Of course there are ways that you can “cache” data outside of the service, but now you start to run into the dirty cache problem. I want to go back and read Pat Helland’s fiefdoms articles from a bunch of years ago to get my head back into this problem space. I recall Roger Sessions also doing some similar work based on Pat’s original article.

Next decision is what Framework bits to use; WebMethod (.NET 2.0) or WCF (.NET 3.0)? I know .NET 2.0 pretty well; so I feel confident I can get something done fairly quickly on those bits. But why do something on the “legacy” asmx platform? Why not just bite the learning curve now? I assume the interop between the two just works; so if I wanted to the service to be in WCF and the client to be either that would be OK.

I was just noticed the bottom the page (I write this in Word first) coming up. And I didn’t think I had anything to write about...