British Columbia Welcome U

There's a pretty good thread on the altdotnet board around AutoMocking Containers and the role of an IoC tool. I'm going to second something that Ayende said: 

…I would say that container ignorance is as important as persistence
ignorance. I don't want to deal with infrastructure in my code unless I
cannot avoid it.

Ditto from me.  As the guy who's most likely been using an IoC container in .Net systems for the longest time, minimize your exposure to the IoC container.  It's infrastructure code.  The classes that do the real work in your system probably shouldn't have an reference to infrastructure.  Use the heck out of the IoC tool to put together services and object graphs by pushing dependencies into a class, but minimize the number of places where a class has to directly pull something out of the container.  Besides, if you're leaning hard on autowiring of dependencies, you shouldn't need that many calls to ObjectFactory.GetInstance().

written by \\ tags: ioc

Steve Harman asked me yesterday to show a little demo of the AutoMocking container coming soon in StructureMap 2.5.  Honestly, I was very lukewarm to the idea of an "AutoMocking" container at first because I thought it would obfuscate tests.  Everyone else was doing it, so I figured I'd give it a shot too and I built an automocker into StructureMap.  I'm not entirely thrilled with the API as it stands, so any feedback would be very welcome.

My advice for the last four years has remained pretty consistent:  use StructureMap (or container of your choice) in unit tests very sparingly.  Just use plain Jane constructor injection inside your unit tests.  That advice aside, what you end up with is a lot of boring, repetitive code like this sample from StoryTeller that tests a class called WikiTextPresenter:

        private MockRepository _mocks;
        private IWikiTextEditor _editor;
        private ITestFormatConverter _converter;
        private WikiTextPresenter _presenter;

        [SetUp]
        public void SetUp()
        {
            _mocks = new MockRepository();
            _editor = _mocks.CreateMock<IWikiTextEditor>();
            _converter = _mocks.CreateMock<ITestFormatConverter>();

            _presenter = new WikiTextPresenter(_editor, _converter);
        }

It's simple code, but it's code that you write over and over and over again to do interaction testing.  Instead, what if we wrote something that can

1. Look at the constructor of the WikiTextPresenter class being tested above
2. See that it requires an IWikiTextEditor and an ITestFormatConverter in its constructor
3. Create a mock object for each of WikiTextPresenter's dependencies
4. Poke all the mock objects into WikiTextPresenter for us
5. And lastly, give us easy access to both the class under test and all the mock objects that the class under test depends on

That in a nutshell is an automocking container.

After seeing what the Eleutian guys were doing, I wanted something similar to their AutoMocking container just to eliminate the repetitious code of building mock objects and ramming them through a constructor function.  I built a new assembly in StructureMap called StructureMap.AutoMocking.  Inside it is a class called RhinoAutoMocker that extends the RhinoMocks MockRepository class with some StructureMap magic.  RhinoAutoMocker's responsibility in life is to connect the right mocks and/or stubs to the class under test, freeing you from the monotonous code shown up above.  Specifically, you use a generic parameter to tell the RhinoAutoMocker what the concrete class under test is.  The class itself is below.  After the break, I'll talk about usage.

    // Note that it subclasses the RhinoMocks.MockRepository class
    public class RhinoAutoMocker<TARGETCLASS> : MockRepository where TARGETCLASS : class
    {
        private readonly AutoMockedInstanceManager _manager;
        private TARGETCLASS _classUnderTest;

        public RhinoAutoMocker()
        {
            RhinoMocksServiceLocator locator = new RhinoMocksServiceLocator(this);
            _manager = new AutoMockedInstanceManager(locator);
        }

        // Replaces the inner InstanceManager in ObjectFactory with the mocked
        // InstanceManager from the auto mocking container.  This will make ObjectFactory
        // return mocks for everything.  Use cautiously!!!!!!!!!!!!!!!
        public void MockObjectFactory()
        {
            ObjectFactory.ReplaceManager(_manager);
        }

        // Gets the ClassUnderTest with mock objects (or stubs) pushed in
        // for all of its dependencies
        public TARGETCLASS ClassUnderTest
        {
            get
            {
                if (_classUnderTest == null)
                {
                    _classUnderTest = _manager.FillDependencies<TARGETCLASS>();
                }

                return _classUnderTest;
            }
        }

        // I find it useful from time to time to use partial mocks for the ClassUnderTest
        // Especially in Presenter testing
        public void PartialMockTheClassUnderTest()
        {
            _classUnderTest = PartialMock<TARGETCLASS>(getConstructorArgs());
        }

        private object[] getConstructorArgs()
        {
            ConstructorInfo ctor = Plugin.GetGreediestConstructor(typeof (TARGETCLASS));
            List<object> list = new List<object>();
            foreach (ParameterInfo parameterInfo in ctor.GetParameters())
            {
                Type dependencyType = parameterInfo.ParameterType;
                object dependency = _manager.CreateInstance(dependencyType);
                list.Add(dependency);
            }

            return list.ToArray();
        }

        // Get one of the mock objects that are injected into the constructor function
        // of the ClassUnderTest
        public T Get<T>()
        {
            return _manager.CreateInstance<T>();
        }

        // Set the auto mocking container to use a Stub for Type T
        public void InjectStub<T>(T stub)
        {
            _manager.InjectStub<T>(stub);
        }
    }

In usage it looks like this for the WikiTextPresenter class we looked at up top.  The test specifies that when ApplyChanges() is called on WikiTextPresenter, it will take the raw text from its view (IWikiTextEditor), convert that text to the internal data structure with ITestFormatConverter, and finally update some information in the View.

        [Test]
        public void ApplyChanges_with_the_automocker()
        {
            RhinoAutoMocker<WikiTextPresenter> mocks = new RhinoAutoMocker<WikiTextPresenter>();
            using (mocks.Record())
            {
                Test test = new Test();
                mocks.ClassUnderTest.TestPart = test;

                string theWikiText = "!|SomeFixture|";
                Expect.Call(mocks.Get<IWikiTextEditor>().WikiText).Return(theWikiText);

                WikiVersion expectedVersion = new WikiVersion(0, theWikiText);
                mocks.Get<ITestFormatConverter>().ApplyChangesFromWiki(test, theWikiText);
                mocks.Get<IWikiTextEditor>().AddWikiVersionToList(expectedVersion);
                mocks.Get<IWikiTextEditor>().SetWikiVersion(expectedVersion);
            }

            using (mocks.Playback())
            {
                mocks.ClassUnderTest.ApplyChanges();
            }
        }

RhinoAutoMocker creates the WikiTextPresenter instance under test on the first call to RhinoAutoMocker.ClassUnderTest.  The Get<T>() method on RhinoAutoMocker simply retrieves the mock object of type T that was used to construct the class under test.  Otherwise, all other usage is just the normal RhinoMocks usage.

In case you're wondering, I chose RhinoMocks because:

1. RhinoMocks is probably the most common mocking tool by a large margin.  It's what I use, and I ultimately wanted a tool for me;)
2. NMock/NMock2 seems to be dead.  I finally eliminated the direct NMock support from StructureMap for the 2.5 release anyway.
3. If you're using TypeMock you probably don't care about dependency injection and automocking anyway

Making the RhinoAutoMocker subclass MockRepository just seemed like a good way to have all of the RhinoMocks capabilities right there at hand instead of wrapped up behind the scenes.

If you want to use this now, you need to download the very latest code out of StructureMap's subversion repository at https://structuremap.svn.sourceforge.net/svnroot/structuremap/trunk.  Like I've said before, I'm basically done with coding on 2.5, but I'm not releasing officially until I can do a full rewrite of the website and documentation.

written by \\ tags: ioc

Picking up from my previous post, How do I know?: Descartes' Rationalism versus Hume's Empiricism. 

I had a request lately for a post on the topic of "Persistence Ignorance" (I swear I'll finish it soon Ward).  While trying to formulate that post, I realized that I needed to start with an examination of the first causes that might lead you to Persistence Ignorance.  I thought was a nearly mandatory way to start the post because Persistence Ignorance (PI) is only a means, not a goal in and of itself.  It's possible that an examination of the goals behind Persistence Ignorance might lead to a perfectly good compromise that isn't pure PI.  More interesting to me is if there is really an underlying set of qualities that we can use in a concrete manner to make rationalizations about software development techniques.  I'd like to use this post as the kickoff for a short set of essays to explore what I think those first causes are.  Just warning you now, this is going to be long.

Debate is Good

We developers are an argumentative lot.  This tool/practice/process/technique versus that one.  We're always debating the best way to build software — and it's a good thing that we do because software development is a young profession.  Our basic laws of physics change underneath us as hardware abilities increase and multicore systems beckon.  New ideas, techniques, tools, and processes are popping up all the time.  Which to try?  What to bet my career on?  Can my tool really beat up his tool?

Inevitably we form emotional attachments to our tools or begin to see our identity in terms of a tool.  That's unfortunate in that it blinds us to other ideas and leads to us holding retrograde postitions for a reality that might have passed us by.  We need to stop and remember why it is that we liked our current positions in the first place.  Both to better practice and understand those ideas, and also to know when to jump to something better. 

I personally believe that debate can be healthy for us as a means to compare and contrast ideas of how software ought to be built.  In any argument or discussion however, somebody will eventually pull out this old nugget — "I just use whatever is best for the job at hand!"  Which is a nice sentiment, but nothing but hot air without some substance behind it.  What is best?  How do we decide what is best?  Is there a constant set of basic criteria that we can use to judge software techniques through time?  I say yes.

And why do you believe that?

Frans Bouma in his exit from the ALT.NET list included this little nugget that made me sit up and pay attention:

In general asking 'Why' wasn't answered with: "research has shown that…" but with replies which were pointing at techniques, tools and patterns, not the reasoning behind these tools, techniques and patterns. Answering Why with pointing to techniques, tools and patterns is creating a cyclic debate: the Why question is asked to understand the reasoning why some tools/techniques/patterns/practises are used. Pointing back at tools/techniques/patterns/practises isn't going to make you any wiser, as you then only learn tricks, because you can't put any argument on the table why you use pattern X, use technique Y and practise Z.

Frans goes on to use the example of Separation of Concerns (SoC) as a concept that everybody says you should use, but nobody questions or explains.  I've called Separation of Concerns the "alpha and omega" of software design.  I obviously think it's important too, but why?  What does it give us?  To Frans' point, only by understanding those real goals can we better utilize SoC to write better software.

It's important to understand why we espouse the things that we do, both to better understand how to apply something, and to know if we're just doing something out of Cargo Cult behavior.  What is the underlying first causes that make us think SoC is so important?  Let's take up Frans's gauntlet and start trying to answer the "why's."

But first, before we even talk about the "why's," I want to first throw out some of…

My Choices

I've made and continue to make a certain set of choices for how I prefer to work and what I think works.  You've made your own set of choices.  Below are some of my choices and preferences.  I'm sure some of these are purely preference, but I think many of them are directly connected to my interpretation of the first causes and underlying forces that I'll discuss in the next section.

• Evolutionary design is much more natural to me, and I strongly prefer an environment that actively supports that.
• I'm a huge proponent of Test Driven Development and Continuous Integration practices.  I'd say that creating an automated build script is the very first development task in any project.  My tool usage is very much impacted by my ability to do TDD with a given tool.  And yes, I think TDD provides a lot of benefits above and beyond simple unit testing (more on that later).
• I design from the middle tier or user interface first, and the database last.  Again, some of that is just preference, but there are some very real reasons to work first with your objects and let the database fall out secondly.
• I'm all for micro code generation in forms like ReSharper's live templates, but I don't care for fullblown code generation schemes that try to build a full application from a fully formed database.  Given a choice between using a reflective approach versus code generation I'll almost always pick the reflective approach.  We can't do it in a mainstream .Net language yet, but I'll take metaprogramming over code generation as well.
• I'm interested in the little mechanical advantages of software factories, but Software Factories as a methodology sounds like a complete non-starter to me (can you say CASE 2.0?)
• As far as the Domain Specific Language (DSL) experimentation goes, I'm betting on textual DSL's and language oriented programming over graphical DSL tooling.  I'm much more interested in things like the Ruby acts_as_state_machine than I am in Microsoft's Workflow Foundation.
• I'll go out of my way to avoid using designers in Visual Studio for anything but laying out elements on a screen, and I'm looking hard at dynamic layout techniques for my system.  I'm going down a path of using my own fluent interface DSL to express data bindings and screen behavior in WinForms because I think it's faster than using the design time support in WinForms.
• I favor explicit coding over magic.  I vary rarely use custom events in my code because I think they obfuscate the code and make it harder to understand.  I prefer explicit observer classes as need be.  Call me strange on that one though because I'm close to a minority of one.
• I prefer to understand code by examining and reading the code.  I'm not a big believer in external documentation (mostly because I've never found other people's documentation to be very useful and I know that the documents that I labored diligently over in the past were never read by anyone but me).  Code readability is paramount to me (but of course we all have our different ideas of what that means).
• I generally think that most (but not all) comments in the code are an apology for bad design rather than something that is helpful.  The xml documentation embedded in code makes code harder to read.
• I like clean separation of concerns in my architectures.  I'm very iffy about Active Record approaches in static typed languages.  I intensely dislike architectures like CSLA.Net that ignore Separation of Concerns — even though CSLA.Net obviously has plenty of fans.  I think orthogonality in a software design is a paramount concern that cannot be sacrificed for short term productivity gains. 
• I absolutely detest intrusive frameworks, especially if they involve a lot of inheritance chains. 

Ok, there's what *I* like.  Now, let's see if I can connect some of these choices to what I think the underlying forces of software development really are.  And of course, if I can't make the connection, I need to reconsider these preferences;-)

First Causes and Values

Underlying everything we choose is a set of drivers.  At the very lowest level is the simple goal:  "provide as much customer value as possible as efficiently as possible."  You might say that your first cause is to just get it done.  Great, but what does "done" really mean?  I'm going to take the XP line here, "Done, done, done" means that the code can ship.  The functionality is complete, it's tested well enough, and the customer has approved the functionality.  It's not good enough just to write code, we also have to have ways to make sure the code we've written is correct and that we've written the correct functionality in the first place.

Most of the effort in software development is deciding what to do.  The construction of software is nothing but typing.  I've seen it argued that the most important, and time consuming, activity in all of software development is learning.  Learning what the customer wants, what they need, how our architecture performs, and learning that our initial design wasn't that great when we actually tried to implement it.  I don't think we can really know everything upfront, so if we're really setting off on a project without knowing the exact path, we better make regular course corrections with plenty of…

Feedback - I honestly think this is the single most important "First Cause."  My experience is that productivity is most heavily impacted by our ability to quickly apply some sort of validation to anything we do.  I've just written a requirement / designed a screen layout / coded a requirement / sketched a UML diagram, is it right / valuable / usable / not really what the user intended?  I strongly think that a team's or individual's tools and practices should be chosen with a very strong regard for the quality and quantity of feedback that those tools and practices provide.

A couple weeks back I was in some discussions about the future Composite WPF guidance.  One of the participants made the remark that we should be careful not to sacrifice productivity for the sake of testability.  I think that's a false dichotomy.  When we talk about getting to "done" we need to be careful to consider everything that it takes to get to done, and that includes the effort that we put into removing defects from the code.  We need to optimize the complete lifecycle of the code, not just the initial production of the code.  Being fast to code and hell to debug when anything is wrong is a net loss.  So let's add…

Testability - The simple ability to test and verify a system bitwise.  How easy and quick is it to validate parts of the application work?  I feel like this is a specific case of Feedback, but merits it's own treatment.  I've written about this quite a bit in the past, but I want to use the essay on this topic to challenge my own views a little bit and see how things fall out in the post-TypeMock world.

Software is complex, and the overall system may have hundreds and even thousands of variables.  The human mind can only hold so many variables at one time.  What we need to do is to be able to pick off logical parts of the system and work them in isolation.  We need to eat the elephant one bite at a time.  That leads to iterative development processes for the team, and in the code we need…

Orthogonality - Simply put, the ability to divide and conquer by being able to work on a single concern of the whole system at a time.  Every major design technique that I'm aware of exists to provide a heuristic to take an amorphous blob of requirements and decompose it into a series of approachable coding tasks.  The ability to work on one thing at a time is crucial for productivity.  Designs that allow us to turn a complex system into a series of simple tasks are good.  Designs that organize the code to make the assignment of responsibilities predictable are good.  Designs that throw all the code into a giant DoWork() method aren't helpful.

I'd also extend "I just want to get it done" to being able to sustain ongoing efforts in the same code later.  Most systems I've worked on are continuously maintained and extended until they just become too expensive to maintain and extend.  Clearly, there's a huge economic value in these systems to providing for sustainable development.  Along the way, I've observed (empiracism) a very large disparity between my productivity in one codebase versus another codebase.  For purely economic reasons, I definitely want to build in the ability to change a system over time.  If I'm going to get in and change a system over time, I want a couple of qualities in my system to make that change safe.  Feedback loops, Testability, and Orthogonality all play major parts in making it safe and economical to change an existing system, but there's another major factor in a software design's ability to change over time:

Reversibility - The best example I can give for Reversibility is watching my 4 year old son paint with water soluble paint across the table from me as I write this.  I'd be a lot more worried about what he's doing if I didn't know that I can easily wash it all off later.  The same thing applies in software design.  If I know I can reverse a design decision later without serious consequences, I don't have to be that worried about getting it perfect now.  That's a hugely liberating feeling.  If I can build the system's persistence scheme simple, and fit in caching later when the volumes demand it, I can build the system right now for the initial release without having to make those decisions about caching upfront.  When we have Reversibility, continuous design is possible and analysis/paralysis problems can be put to bed.  My design choices are directly informed by my wish for better Reversibility. 

Oh yeah, and people stuff too.  I wrote ad nauseum about teams and communication and collaboration last year because my client was self destructive in this regard.  That's all available at:  On Software Teams. 

The Series

If I've tallied things up correctly, I'd like to write some deep dives on:

• Feedback
• Orthogonality (mostly links though)
• Testability
• Reversibility - Its impact and importance for doing design.  What design choices give us more or less reversibility.  I also want to look at how external factors can improve or diminish reversibility
• Can you "see" the flow of the code?  Solubility, readability, whatever you call this quality of code.  Can I tune into the "signal" in the code that I care about without getting bogged down by unrelated "noise?"  I think I'm going to say that this is a specific manifestation of Orthogonality.
• Why and How TDD Works - First and foremost, TDD is a design technique, and I'm going to treat it as such.  TDD is more than unit testing.  TDD encourages Orthogonality and provides a fast Feedback loop. 
• Persistence Ignorance (PI) - Just applying the first causes to the problem of persistence and seeing where PI applies.  It's just a means for better Orthogonality and Testability. 

The Fly in the Ointment

There's at least a couple problems with my arguments in this post that I'm happy to acknowledge:

1. Not every system or project is the same.  As I've said before, I strongly favor using a Domain Model architecture backed by an Object Relational Mapper that supports "Persistence Ignorance."  I also said that I don't care for the Linq to Sql or NetTiers type of approach to system building, but there are a lot of systems where the entire goal is to attach a user interface to a database in the fastest way possible.  I think data-centric approaches are perfectly applicable in those cases, even though I would never touch them in any of the systems I build that tend to be very rich in behavior and business logic.  All I mean to say is that our choices of "what is good" are very much influenced by the work that we do.  If you work primarily on CRUD or reporting applications that don't change much throughout their lifecycle, then you won't care about the same things that I do.  Then again, you're going to get into serious trouble if you take those data-centric techniques and try to apply them to a system with rich domain logic.
2. Opportunity Cost.  Just because your favored solution "works," doesn't mean that there isn't a better way out there that would give you better results.  If that's the case, you're actually losing time and money by using your current techniques, technologies, or processes.  The first example that comes to my mind is a talk I sat in last spring.  The high priced architect speaking was demonstrating his application framework.  The framework required you to write a *lot* of little factory methods and classes by hand.  I asked him why he didn't just use an IoC tool to avoid all of that monotonous coding.  His response to me was that his way has always "worked" for him.  Yes it worked, but I could have done the same thing with less code and mechanical effort.  I think that TDD works for me, but maybe there's something totally different I could be doing instead or more likely, a better way to do TDD.  Maybe Design by Contract could replace some parts of TDD for me at some point (I still see DbC as a small subset of TDD, not the other way around). 

I can make both an empirical statement that TDD works, and I can provide the rationale for why it works, but there's always the possibility that something better is out there.  Even if you "know" what's right, you better keep a look out for better things.

written by \\ tags: ioc

Today Yahoo announced that they are joining forces with the OpenSocial platform, and will be joining both Google and MySpace to build “The OpenSocial Foundation”. This new foundation “will seek to ensure that the technology behind OpenSocial remains implementable by all, freely and without restriction, in perpetuity.” It is modeled after the current industry-supported OpenID foundation. As an addition to that announcement, Google has released “opensocial.org” to promote the development of OpenSocial on a standard platform away from the Google environment.

Read more about it over at OpensocialNow!

Share This

written by \\ tags: ioc

I just wanted to briefly mention that I now have 30 OpenSocial T-Shirts from Google for the Utah side of the West Coast Open Social Hackathon tomorrow night. Also, in addition to that, I hear Bungee Labs will be providing Fudruckers to eat at the event, along with Guitar Hero, Rock Band, Halo 3, and Call of Duty on 2 40″ screens. Come on over to hack and learn or just have fun! Learn more about the event here:

http://staynalive.com/articles/2008/03/21/announcing-the-first-west-coast-opensocial-hackathon/

UPDATE: I also have 2 free tickets to Google I/O for two lucky winners we’ll draw from a hat (transportation, meals, and lodging NOT included)

Share This

written by \\ tags: ioc

Time for a little rant.

I’ve been researching Google’s initiative to crack-down on websites selling and buying paid links. I’ve let myself get a bit riled-up as I’ve re-discovered the following:

1. Too many people still think Capitalism is somehow inherently evil
2. Some usually bright people have an amazingly hard time distinguishing between spam and good content

I’m not going to spend a lot of time on why Capitalism is not inherently bad. Go read Mike Mann’s book on making change—it’s a free book (making it appealing even to anti-capitalists).

On point number two I’ll voice a few more thoughts. Aaron Wall wrote an insightful post on new link strategies that people have employed to avoid having to purchase links outright. Some of the comments to that post just about killed me.

One comment reads, “It can’t be long until Google starts detecting these types of strategies.” An astute retort followed shortly, “Never going to happen. What is there to detect? Good content written by an author who writes about the field? Sorry, writing guest posts/content is as legitimate as it gets.”

After reading so many on similar blog posts, I got the feeling that there are many people out there who must have been bitten so many times by the spam bug that they can no longer see the difference between junk and good content.

What do people expect? Should Google be penalizing online newspapers because their journalists get paid to produce the content? Should Google ban their own site for offering up paid listings?

I think some people have this idea that any website actively trying to get links, traffic, or any other type of attention is spam, or at least in the same category. They think that any site attempting to draw traffic must be doing so surreptitiously, or behind some clandestine operation. No so! These are surely the same people who think Wikipedia would turn to the dark side by posting ads on the site. I’ve got news for you people; most of the sites you read that have content worth reading exist because someone is getting paid (refer to the link to Mike Mann’s book above).

The difference between spam and good content lies in context and relevance—two things that these spam crying scuttlebutts should be able to determine. Google doesn’t claim any artificial intelligence and they seem to be able to do a good job most of the time.

Don’t get me wrong, I hate spam too. But you need to know the difference. Here is a very succinct and simple way to distinguish spam from quality content for those of you who have a hard time telling he difference: spam will always appear unsolicited and out of context. Both attributes must accompany any content for it to be categorized as spam. If you have a site that has relevant content about a particular subject and it is accompanied by pertinent ads, you are not looking at spam. Read this entry by Matt Cutts for other good insights.

written by \\ tags: ioc

There is a saying that goes: “It’s better to tell the truth poorly than to lie well.”

Recent events have shed light on what this saying truly means; two highly publicized and one not so publicized events show that it does no good to lie about or embellish the truth.

In the first example, Kwame Kilpatrick, the 37-year old mayor of Detroit, has “been booked on charges of lying about steamy text messages with his former chief of staff.” He is accused of “multiple counts of perjury, conspiracy, obstruction of justice and misconduct” in a scandal that will, in all likelihood, land him behind bars and end his political career. Telling the truth may not have saved his political career, but it certainly would have saved him from being sent to the clink.

In the second example, in an effort to establish her “battle-tested” leadership, Sen. Hillary Clinton said last week during a campaign rally speech that during a visit to war-torn Bosnia in 1996, she had to land “under sniper fire”, “without a welcome ceremony” because she and her party had to run “with our heads down to get into the vehicles to get to our base.” But a CBS correspondent who was with the former First Lady on that trip produced video evidence that what Senator Clinton had said was simply not true. Now, her media relations team is doing some manipulating of the facts themselves, which will probably continue for the next couple of days until the press gets tired of writing about it. But instead of boosting the “battle-tested” leadership image she is so desperately trying to portray, it shoots holes in her claim to any previous leadership experience at all. What stories are embellished, which are fabricated, and which ones are completely imaginary?

The third example comes from a recent job application we received. We had previously worked with the applicant and knew about some of the information on this person’s resume because of our working together. However, the “facts” claimed on the resume for work performed while with us did not mesh with what we knew the applicant did, nor did the facts match what was reported on a client’s Web site. The applicant knowingly embellished information on the resume, probably thinking we would not catch it, or that if we did, we may not recall the exact details. However, when the embellishment was caught, the application process ended. We probably would have progressed further with the application process, but the trust was now exhausted.

We could go on for days; there are many more examples of individuals who flat-out lie, possibly under the impression that they’ll never get caught. But eventually, the truth always comes out. Elliot Spitzer found out the hard way; so too, has Kwame Kilpatrick. The simple fact is, they didn’t have to find out the hard way. They just needed to tell the truth.

It may be hard to do in the moment, but giving the facts is much better in the long run than falsifying information.

written by \\ tags: ioc

Over the past week or more I’ve been having a lot of fun watching earthquakes all over the world. Not the actual earthquakes, but the reports of earthquakes. And not text reports, or overly dramatized news reports … but a timeline of earthquakes along with them being plotted on Google Maps, updated every 5 minutes. Live Earthquake Mashup is a very impressive demonstration of a “mashup“.

I found out about the site when a friend Tyler Whitaker twittered about the site … and it took me a day or two to go and see what he was talking about. Since then, I have left it up and running on my test workstation in my office … and it has offered me a whole new perspective on earthquakes! (As I was writing this, I just noticed there was an earthquake in Yellowstone National Park - not far from here - last night that was a 4.2 quake!)

There are several things that this has really brought to my attention … about earthquakes, and also programming. The truly fascinating thing that I have learned about earthquakes is that they are going on, all day long, all around the globe, but few make any news. The other thing is that they seem to cluster (duh!) around the key places on the earth where the plates are under the most pressure and shifting … and that these places are now clearly visible on the map provided! I keep thinking about what a movie of this map would look like if recorded over a long period of time. Like twitter, this mashup has raised my awareness about something that I otherwise would have never known. It has condensed an entire series of global events into a concise model that is presented to me while I work. I like that concept …

The other thing that amazed me about this mashup is just how simple it is. I do not want to minimize the effort and work of the author in any way … and I truly respect the creativity and thought that went into it. This is a powerful example of where we are going with software components, and ease of development.

When I first ran the application, of course I immediately recognized he had used Google Maps for the mapping … most everyone does. I was also aware of the USGS RSS earthduake data feeds that the US government provides. I was very impressed with the timeline that he had at the top of his application … it provided a very nice way to visualize the time series of earthquakes, and allows you to scroll easily through them, and to select earthquakes and have the map reflect their location. I did notice a copyright notice on the timeline - SIMILE. When I reloaded the application later, I saw it make a request to http://simile.mit.edu … huh … time to investigate …

What I found was impressive. MIT has a program called the Semantic Interoperability of Metadata and Information in unLike Environments … SIMILE. They have a whole set of components and software that they have created and are offering for free use. The Timeline is a SIMILE project, and it is a component that can be used in mashups as easily as Google Maps! (I’m slowly working my way through their site to examine all of the other components and software … pretty cool stuff …)
So the developer of the Live Earthquake Mashup took two high-level visualization components - Google Maps and the SIMILE Timeline, and knitted them together with some code to fetch and parse the RSS feeds (which might also be a available library) and created a very powerful and useful visualization of global data … and made it available to anyone who wants to see it. It was not a formidable task to create this incredible demonstration of what is possible.

Of course now this application has me thinking about other possible mashups that could be created with these same components. I know of a few, but it would also be interesting if law enforcement would release crime details as RSS feeds, or traffic accidents. What other types of data might be interesting to display on a real-time updating map like this one? I’d love to hear other ideas …

earthquakes, google, maps, mashup, mashups, MIT, simile, time, timelines, usgs

written by \\ tags: ioc

Hey, Marty, would you mind parking the DeLorean for me while I finish up this blog post? Thanks.

Hi, everyone! I’ve just come back from the future. Well, not really. I’ve actually just been reading through a bunch of articles about the Semantic Web as envisioned by Tim Berners-Lee and other brilliant thinkers. My appetite to research this topic was spurred by this article I read about two weeks ago. It’s been a fun escape into the world-of-tomorrow. Some have already assigned the moniker “Web 3.0″ to the Semantic Web. Here we go again…

So did I find anything of value on my futuristic escapade? Well, I started my trip (as always) by going to see The Oracle to find out what she thinks of the Semantic Web. It’s still unclear to me how people will interact with such a system—from what I can tell there are no consumer apps yet that handle these types of semantic web interactions. But according to the Wikipedia article, computers will do most of the menial pairing of search results that we currently do manually.

Funny enough, there are many who believe that this particular vision of the future cannot come to fruition. Others say it has already begun to happen. I don’t know enough about it yet to base an opinion either way, but I do see elements of a semantic web in now widely used web techniques like tagging.

According to Tim Berners-Lee, Google will not survive on the semantic web—at least not in its current state. Yahoo even recently announced that they will begin supporting certain semantic web standards and technologies to let people produce much richer search results.

So if search engines as we know them need to change at the advent of this new Semantic Web, do SEOers need to follow suit? Will SEO become the task of simply building properly formatted semantic markup for digestion by future search engines? That could be part of it. In fact, part of good SEO practices now include creation of semantic based data feeds (think RSS). And now with the birth of Yahoo’s open search, website owners will be rewarded for producing more semantic data and suppling it to Yahoo. I expect Google has something similar in the works.

But how far out is our paradigm shift? How quickly will the bandwagon pass? Is there a bandwagon at all? The more you think about it, the more you think, “wow, this Web 3.0 is going to be pretty cool! It’ll make SEO and search in general a lot cleaner”. As I began to ponder all of these new ideas, The Oracle sent me to this other article. Stopped in my tracks.

Mr. Doctorow is right on. One of the huge problems Google et al currently face is the overabundance of garbage on the web. This must be what Berners-Lee meant in part when he said, “…make sure people aren’t using their authority to do things that they shouldn’t be doing”. Unfortunately, that’s much easier said than done. There will always be people who are trying to game the system. Website owners of the future will be creating oodles of inaccurate meta-data about their spam sites to trick your computer into pulling bogus information into your data mash-up. Can you imagine searching for a good Italian restaurant near the place you have a meeting tomorrow at noon and you’re given a map full of bogus locations all advertising male enhancement pills. No thanks.

Let’s get back to the original question quickly: does SEO die on the semantic web? I think the answer is a resounding no. In fact, an understanding of keywords, search engines, markup, and semantics will play an even bigger role as time goes on. But who knows what the real future will bring.

Alright, I’m outta here. Where I’m going I don’t need—roads. But I do need to add some quick semantic metadata to this post before signing off (*throws in another old can and a banana peel*). OK, I’m off!

written by \\ tags: ioc

The CTO Breakfast will
be held this Thursday, March 27 at 8am in the Novell Cafeteria
(Building G). Anyone interested in high-tech and product development
is welcome. The discussion is free-form, so feel free to bring some
topics to discuss.

Here is a list of upcoming meetings:

• Apr 17 (Thursday)
• May 30 (Friday)
• June 27 (Friday)

Please get them on your calendar!

Tags:

utah

events

cto

breakfast

written by \\ tags: ioc