Innovation

ConnectionStrings.Retrieve("Billing")

Gerry Heidenreich — Wed, 21 Jan 2009 17:12:11 GMT

Connecting To Data
CRM, DMS, Active Directory, internet / intranets / extranets, project management, time & billing, etc... All these systems provide valuable data for our custom development here at Whyte Hirschboeck Dudek. We regularly tap into these systems to retrieve information, so writing connection strings for each system was a regular occurrence, and a pain in the neck when one of our enterprise systems changed servers, or account information for security reasons - various custom apps would break and we would scramble to update the connection info in all the right places, to the new information.

The Good Kind of Lazy
I was feeling particularly lazy one day, and decided to fix the problem for good. I put all of our connection string data into a single table on a sql server, wrote a ConnectionStrings static class to Retrieve("systemName") them as needed, and a 2 minute cache to keep performance under control. Our apps now only need a reference to the ConnectionStrings class. No more worrying about specific machine/account details, or XML file updates across multiple config files on the network.

Consequences
Consequences need to be considered carefully, but are pretty easy to live with or get a handle on. Server/db failure can be handled with a failover, or good disaster recovery plan. There are a couple additional db calls, which again should have minimal impact on performance if you cache your connection strings when you retrieve them. Finally, developers need to figure out the names to connect by. We handled this with a quick datagrid web app that retrieves the ConnectionStrings table contents for reference. Any arguments about security have better counter-arguments, especially when you consider that you can now change the way you retrieve connectionstrings easily (web service, xml file, hard-coded in the dll, encryption, etc), and therefore evolve your security for everything at once. Furthermore, security accounts on these systems can be updated without fear of breaking custom apps. The new information can be updated easily in the ConnectionStrings table.

The benefits, off the top of my head:

- Connect semantically to our systems (by name & context), Retrieve("DocumentManagementSystem") instead of the traditional method "...server=ObiWanKenobi04..."

- Connect in the code (why not?), instead of in an XML file somewhere

- Single point for {failure & recovery, security, monitoring & auditing}

- Integration across systems feels more natural, less fragile

- DBA can manage connectionstrings and account security, and just provide meaningful names to the dev team

- Log ALL connections retrieved, by application, user, & time

Wrote an Inverted Blog Engine

Gerry Heidenreich — Tue, 20 Jan 2009 00:19:53 GMT

50+ Practice Groups, across the entire spectrum of legal services. It is difficult to write a solution for one group, that is useful or even applicable to the others. Abstraction is an extremely important tool around here.

Content Managment
A few years back, when we were rebuilding our website, we abstracted the idea of web content down to a very basic level, then made it extensible. New content types were created by a few simple instructions. Content mainly contained a title, body, and was associated with various practice groups and lawyers. Content types like news, press releases, and articles were a slightly different spin on the same formula. The content manager interface rendered itself, appropriate to which content type was currently in context. It worked nicely, and was only a little more difficult to write than a static content manager would have been.

'Original Content'
Culturally speaking (and this should go without saying), a mid-sized law firm blogging is a difficult concept to sell. We are a pretty savvy group when it comes to tech, but some things just need to surface on their own. We created 'Original Articles' instead: Blog posts with the format & depth of formal articles, that were reviewed and approved, and did not allow comments or syndication. For the meantime, we were getting content in, which got the ball rolling for blogging. As lawyers and our Marketing Department posted Original Article items, they associated the content with authors, practice groups, and keywords.

Finally
We started hearing murmers from the law geeks that wanted to blog. Some associates had personal blogs. Their friends and colleagues had Twitter feeds and law blogs ("blawgs") of their own. The Tech Law team led the charge, and we purchased techlawblog.com. At this point, we were looking at a 3rd party solution, or possibly something custom that was separate from our website. This route would have led to a few different complications that would have hurt our chances of this being a success:
- New content management per blog (1 post that applies to Intellectual Property, and Tech Law would need to be posted separately in each blog), new app for lawyers to learn & manage
- SEO symbiosis between the blog sites and whdlaw.com would be a missed opportunity. Inbound links to the blogs should help our main domain.
- Tagging, categorizing content takes work

Inverted
We decided to keep the solution in-house, and build off of what we already had. We created a 'Blog' content type, wrote in support for comments and a slick approval system so the author can approve from their Blackberry, and a generic page to generate rss feeds depending on the context of our visitor.

Our lawyers can now write blog posts just like the Original Articles they were already familiar with. They make their regular practice group and author associations as before, and possibly add some keywords. As soon as their post is approved, it appears on our main blog stream. If there is an associated practice group that has never had a post before, it shows up automatically as a new blog in our nav bar. Feeds can be created and consumed by practice group, author, or even keyword. In the end, we have all the features of a blog, without any extra work on the lawyers' behalf.

Observations
I am amazed at how few people understand syndication and subscriptions, especially considering that the icon is literally everywhere. It may be another couple years before people start to see the value in it.

Aggregator is a painful word for such a cool idea... I think I will try using reader more, though I think it sounds too passive.

The law industry is really buying into social tech, especially blogging, Twitter, and LinkedIn. The community right now feels very much like the developer community did, 5 years ago. It is refreshing. Maybe it's just me though, as I am watching the legal sector while these technologies are finally going mainstream.

My initial thoughts about Mesh...

Gerry Heidenreich — Fri, 18 Jul 2008 18:18:58 GMT

Update 7/28/08: LiveSide (http://www.liveside.net/, or Twitter @liveside) posted that Mobile Mesh is out in a limited capacity (no folder IO sync yet), http://m.mesh.com from your Windows Mobile, Blackberry, iPhone, or Symbian.

Update #2 7/29/28: Mac client was out briefly today, but was quickly brought offline. Screenshots for this & mobile are at http://www.liveside.net.

First and foremost:The platform sells itself: The key is getting people to install the client, add something to their Mesh from one device, and 'consume' it from another. Nevermind the details, they complicate things. Erick at TechCrunch stated in April that Mesh is 'aimed at developers'. What? Why are they aiming? Throw it out there with some simple user stories and see what happens. Share photos, back-up your important stuff, access your favorites from any computer, write your own news stream. It could be compared to the functionality of many social apps: flickr, google docs, twitter, all the recent sync/backup services (that's the trend lately I guess)...

Wish my Blackberry had a Mesh client. I would love to sync images/videos taken with my camera, view files from my laptop, home pcs, work pc, from my blackberry... Mobile clients are due in late '08.

Wish Mac had a Mesh client. My boss has shifted to the Mac camp, and I don't really blame him. Ours isn't the only enterprise with a chance to convert from MSFT to Mac/Linux in the next 3-5 years. Non-windows clients for the Mesh platform won't keep this from happening, but it will reduce the growing 'painting myself into the corner' feeling that MSFT technologies tend to have. Mac clients are supposedly due for release late this year.

Source control??? Sharing of files & folders, reporting, versioning, syncing, and for extra credit: realtime collaborative authoring (at the very least, via remoting)??? Still unsure about how many requirements Mesh meets here, still playing around with it.

Smaller bits from the blog team: This is probably rediculous, but Twitter is ruining my taste for verbosity. I guess there should be some detailed anchor content that is thorough, and it's as good a place as any. I have to wonder though: If the Mesh team posted more frequently on much smaller stories and concepts, Mesh adoption may increase, and the details would flesh themselves out via posts from the developers they're targeting (like me).

Public Mesh: It may not be practical in a Mesh topology, but it would be cool to be able to watch how other people are using Mesh, and it may create opportunities to broaden networks.

Competing with Google: MSFT needs to go live with a model that makes me feel like they're giving it away. I am sure they will have priced tiers for their services, but the 'free' service should be generous enough that I don't feel like I get more from Google. Let people appreciate the value of the cloud before they are even asked to pay for it in any way.

Hotkey: I love notifyicons, but I love hotkeys more. I don't like to have to hunt for my icon to view remote documents or interact with my colleagues. It needs to become a natural extension of my Windows experience, like OS X's F12

Social net awareness: Import my friends from {twitter, gmail, facebook, linkedin}. Mesh should give me as many opportunities as possible to bridge my social nets together - this complements its goals of bridging apps and devices. Friendfeed does an amazing job at this, but will probably always be just a social net.

Depot, an exercise in Community-Sourcing

Gerry Heidenreich — Sun, 08 Jun 2008 04:43:59 GMT

No downloads or pics, just a quick rundown of a very cool app idea while it's in my head.

About a year and a half ago, I wrote a small winforms app. It's stayed very rough around the edges and hasn't gone anywhere from the original prototype. This prototype (I called it Depot) was written as a proof-of-concept of the simplest possible community-sourced bookmarking / tagging / searching tool that could possibly exist. A self-organizing business-specific link / text library could provide immense value to a company.

Depot hinges on 4 basic features common with collaborative apps:

1. Producing: Adding content in the form of URLS and/or text (2 different fields that can be used individually or combined)

2. Tagging

3. Searching for any item by any combination of title words or tag

4. Sharing: All content is automatically shared, and open to edit & extend, by anyone within the network

The search is an autocomplete textbox, that works with any combination of title words and tags. Typing 'catering' displays all catering items, but as you start to type 'catering madison', the suggestions filter appropriately. As you would expect, changing the text over to 'thai madison' updates to items tagged or titled with thai and madison.

The url + text fields is an interesting feature - a user may want to toss in a quick note for a catering url someone else added, like "Beware the red curry!!!".

The app seemed to work beautifully, but the algorithm is not built to scale up yet. Everything is cached heavily on the client-side. There are no concurrency checks. Also, to be fit for production, it will need some kind of user-auditing, history, and probably some kind of browser integration (or at least bookmark / favorites sync).

I don't know yet what will become of Depot. I hope to find the time and motivation soon to dust it off and start polishing it up for a pilot group. If nothing else, I got an ornery hog of a tag-search algorithm that may come in useful someday.

Shrinking the 'App Surface' - Microsoft Mesh

Gerry Heidenreich — Wed, 23 Apr 2008 20:58:30 GMT

I have lost track of how many social networks I'm involved with. The 'app-surface' is too huge to manage.

In my work, we struggle with a problem of custom development: another system means another place for the lawyers to worry about their data.

We are maintaining apps that were designed for a specific purpose but are being used by 25% of the organization.

Occasionally, I will bang out a new prototype app that may or may not take off. It helps keep the innovation conversation going, but it broadens the surface of possible apps to work in. This is a problem. The solution is buried somewhere within the combination of service-enabling application data, creating dashboards and pluggable architectures, notification systems, unified communication, etc... Lately we have been talking about Sharepoint as the ultimate solution because you can wire all of your enterprise libraries into web parts and slap it all onto a single webpage. What about mobile data then? What about non-web types of collaboration? What about persisting a conversation between meetings, email, and phone? The problem too big to solve with a website. It may be too big to solve with a platform, but it sounds like Microsoft is having a go at it with Mesh.

The Mesh is composed of 'mesh objects', which are standardized feeds (SSE, which is now FeedSync) of data. Mike Zintel from the Live Mesh Team talks about Mesh in his "Live Mesh As A Platform" post:

... a customer’s mesh, or collection of devices, applications and data that an individual owns or regularly uses...
... one instantiation of a mesh object is as a local (shared, aka Live) folder on a PC. This same mesh object might be instantiated as a slideshow on a web site, and as preview and upload UX on a mobile device with a built-in camera. A Live Folder is but one specialization of a mesh object. A mesh object could also represent a range of cells in Excel or a To Do list that can be accessed from anywhere...

I want this so bad... My collaboration post here shows where my head is at when it comes to communication channels and their disconnectedness from each other. I think speech-to-text and text-to-speech, combined with data-to-feed and feed-to-data (bidirectional feeds especially, with FeedSync!) are going to tie things together and shrink our app-surface to a managable level. The Mesh, as far as I understand it, is the first technology that makes this seem possible.

In the meantime we will keep juggling (and forgetting about) our socnets along with our various calendars, emails, meetings, and apps...

What may have been http://ep.iphano.us

Gerry Heidenreich — Thu, 17 Apr 2008 03:40:14 GMT

Still on the subject of Atwood (3rd post in a row) & stackoverflow.com (2nd in a row)... this is it though...

In Jan 07 I jotted some stuff down, called it ep.iphano.us (don't know if the domain was available then, it isn't now). I wonder how close the stackoverflow.com vision is to what I had in mind? I invisioned urls as answers, but it seems like Jeff & Joel want their own knowledge base of fresh answers. Pasted notes from my tiddlywiki:

Overview
Digg-like community where users submit ideas or questions, and other users submit URLs as answers to them. Users can endorse questions, as well as responses. Each user has 2 scores: QEndorsements, and AEndorsements. The front-page effect is used for 2 lists, both chronological: Left lists requests (ideas/questions) that have passed some threshold of endorsements, and Right shows Responses that have exceeded some threshold of answer endorsements. Users can subscribe to filtered sets of questions and/or answers. Submissions (requests or responses) can be categorized, described, discussed, and tagged. Users can subscribe to their own sets, which may be as simple as all requests that are either tagged 'movie' or categorized as 'movie'.

Use Cases
- Submit new Idea or Question (request submission type)
- Submit new response (as url, to a request)
- Create filtered set for request- Create filtered set for response
- Grab feed url for filtered set
- View set
- View front page (requests, and responses)
- Endorse request
- Endorse response

Db Tables
- SubmissionType {Request, Response}
- FilterType {EndorsementCount, CategoryType, SubCategory, Tags, UserEndorsements, UserEndorsements, User, Filter}
- CategoryType {Technology, Science, World & Business, Sports, Entertainment, Gaming}
- User
- Submission
- UserEndorsement
- UserFilter (UserSet)
- SubmissionTag
- SubmissionSubCategory
- UserSubmissionTypeScore

Reading, Writing, Arithmetic, and Business

Gerry Heidenreich — Thu, 10 Apr 2008 00:15:21 GMT

The land of opportunity, land of the free. The land of 40 million children between the ages of 5 and 15. The land where 85% of those children go to public schools [1]. 34,000,000 creative, open, trusting, impressionable minds with little or no education in business or financial responsibility.

There is something that occurs in a small percentage of these children. It is unfortunate, in this country, that it is such a small percentage. It is also unfortunate that by the time it happens, they are no longer children. They get the itch. It is opportunity. It begins with an idea, and often ends in a lesson. Whether it is the wrong ideas or the wrong execution, these lessons can be expensive. The expense is some combination of money, reputation, and time. The amount of this expense is proportional to the age of the recipient. The younger the student, the lesser the expense, and the easier the recovery.

Business is not about calculus, sociology, or accounting. For that matter, it is not about reading, writing, or arithmetic. In fact, it adds context to every other aspect of education. Math now has a purpose. Reading, writing, and typing provide communication skills that can be put into real practice. It is engaging, like a child's game. There are risks and rewards, tactics and strategies, successes and lessons. There are no prerequisites to learning these things. The concepts are as effective to a grade schooler as they are to a college student. It is easy to teach that business is about the exchange of money, for goods, services, and information, in a mutually beneficial transaction. It is easy to describe demographics, product positioning, reputation, relationships, profit, expenses, and negotiation in simple terms.

Twenty years ago, our trial-by-fire was the Lemonade Stand. Over a couple summer days, we tossed some lemonade together and sold it for a quarter a cup. The new Lemonade Stand is online. Services like Ebay and Amazon, Lulu.com and Google's AdSense provide an inexpensive, flexible point of entry into business. With a little guidance, any child could set up an account and start selling online.

In the land of the American Dream, opportunity is everywhere. Unfortunately, most people are oblivious to it. I strongly believe that it is our obligation to our children and our country to illuminate the young minds in the ways of business and financial responsibility.

[1] U.S. Census Bureau, http://www.census.gov/Press-Release/www/releases/archives/education/004214.html

Community-Sourcing

Gerry Heidenreich — Wed, 02 Apr 2008 19:10:06 GMT

I have been a HUGE fan of Digg.com for years. The content is generally good, the community is fun and (again, generally) intelligent, but the model: Submit/Vote/Discuss/Report... brilliant.

MyStarbucksIdea.com, and Dell's IdeaStorm.com follow the Digg.com model, but in the context of innovation focused on a business. They are crowdsourcing their innovation to the world, and their future offerings are going to be more organic than ever before. The new tool on their belt gives them a clearer idea of their actual customers' wishes. Minimize the assumptions. Outsource your innovation to the one group the really cares about your product, and spend next to nothing for the data you get from it... brilliant.

Wikipedia (currently) defines Crowdsourcing as "... the act of taking a task traditionally performed by an employee or contractor, and outsourcing it to an undefined, generally large group of people, in the form of an open call."

I am in the habit of repurposing (or desigining my own) social-network ideas as internal solutions, and along the way I have occasionally had my share of failage/lesson-learnage, but I've also scored some wins. Like everybody else that thinks they have a new idea worthy of its own name, I have started calling it 'community sourcing'.

I reformed the definition above to fit my needs:

Community Sourcing
The act of taking a task traditionally performed by a specific member of the group, or consultant and exposing it to a controlled, generally large group of people who share the same interest as the group, in the form of an open call.

The term seems to be out there (google 2080 hits), and the purpose looks similar.

As far as walking-the-walk goes, we have working 'community sourced' systems used every day for content-management, marketing, and project management. Newer and (therefore, I hope) less-used solutions include link-tracking (think del.icio.us), and yes, a submit/vote/discuss/report app, which, in my humble opinion, is... brilliant.

Collaboration Katamari: Brainstorming for the ultimate collaboration app

Gerry Heidenreich — Tue, 11 Sep 2007 17:16:00 GMT

Communication mediums are everywhere - each has it's benefits and drawbacks. Ward Cunningham once asked “What is the simplest online database that could possibly work?”, hit a few keys, then the wiki was born. I've always been facinated by the consistent emergence and evolution of collaborative mediums...

Every once in awhile, things like BBS, IRC, ICQ, Usenet, telephones, and water coolers fall into the hands of users that use it, extend it, and make it perpetual. New technologies like Google Gears and Yahoo Pipes, and the .Net 3 stack are appearing that give us the power to wire up some killer-features into our existing frameworks & apps.

I just tripped across a small feature list of what I would consider the ultimate collaboration app. I wrote this months ago, when my site was offline (I've got a lot of written stuff still sitting around, gotta get it up here)... When I wrote it, I was reflecting on what communication channels we use every day, and what makes them important to us:

Common communication channels:

- Phone call
- Conference call
- Meeting
- Static website (managed by IT)
- Dynamic website (managed by Knowledge Owners as Content Managers)
- Wiki
- Email
- Blog
- Instant messaging (IM)
- Walk-in / informal discussions

What's the perfect all-purpose collaboration app? Here's my feature-list for the Killer Collaboration Application

Ease of use - You can quickly and naturally provide information without stepping out of the flow of your work

Email and IM feel natural, and if users are able to disable the interruptive aspects of them, they provide a great environment for informal and quick group discussion. Websites (Content Management Systems) require some knowledge, and usually the user needs to open a browser to access/change information, and are therefore more disruptive.

Timeliness - How up-to-date is the information? Is it stale by the time it's needed by others?

Many mediums use a chronological format. Email (in particular, the inbox) is a chronological list of correspondence that is easy and natural to use. Using Re: and some clever UI tweaks, 'threads' of discussion can continue on, keeping a discussion and information timely. IM is the poster-child of timeliness, to the extreme that lighthearted conversation is one click away. Copy and paste a news hyperlink directly to friends in your IM network and they immediately get notified.

Applicable - Does this information apply only to current circumstances, or is it applicable outside these circumstances, even to other parties? How does this information apply to others?

Phone calls or IMs may used for be personal, circumstancial purposes. Meetings include those 'in context' to the purpose of the meeting.

Accessible - Is this information available to others outside the exchange? Over what channels? Is the information 'pushed' out to users, or do they have to actively pursue it?

Websites and wikis are used to be accessible to larger audiences.

Accurate - Is the information being exchanged conclusive, substantive, concrete, of good quality, objective? Or is it informal, ad-hoc, subjective, inconclusive?

Persistent - Is the information available after the exchange? Is it recorded somehow, or does it exist on a persistent platform like within a database?

Meetings and phone calls do not persist without the help of minutes or recording equipment. Most other mediums persist chronologically, in a proprietary format. Custom, database applications and service-oriented architectures provide flexible persistence solutions.

Stable - Is the information backed-up, are updates audited? Or is it volatile, where random updates can occur and remove or irreparably change data?

Wiki content, though it is open and easily editable by anyone, has full auditing (who done it?) and versioning (roll it back!) to enforce stability. Email threads can easily lose focus or change topics entirely over a series of correspondence, and are therefore more volatile (yet more conversational).

Reusable - Does the information exist in a standard, open fashion that enables others to access it for their own needs?

RSS, Web services, and Service Oriented Architectures (SOA) provide standard channels for outside applications to repurpose data. Extracting data from an outside source can literally be as easy as writing a url and picking through the resulting XML response.

Intelligent Image Resizing - Amazing video demo!

Gerry Heidenreich — Thu, 23 Aug 2007 13:10:00 GMT

Via Digg > OhGizmo!, the video & article is here: Smart Image Resizing Cuts The Useless Out Of Your Pics

I'll check out the 20mb (pdf) whitepaper sooner or later, but here's what's going on as far as I can tell...

Technique:
This engine is resizing images by removing paths of pixels vertically or horizontally instead of columns of pixels. The path they add/remove is determined by interestingness. They refer to this technique as “retargeting“ (as opposed to resizing or resampling).

Identifying Image Interestingness:
They are determining the interestingness (or in their terms: gradient magnitude) by starting with a grayscale version of the source image, then creating a new image using The Sobel Operator on the source image. The resulting image represents large gradient activity (interestingness.) with light, and boringness... with dark.

Original grayscale, and the Sobel gradient image of the same picture:

Discovering the least-interesting path:
The engine then uses an 'importance or energy function' to discover the least-interesting path, composed of 1px from each column or row. This function seems to represent the most consistently shaded 1-pixel path from one end of the image to the other...

“Retargeting” the image:
Once the least-interesting path is discovered, it is then either removed or copied, depending on if you are “retargeting” your image to make it larger or smaller.

Maybe ImageManipulator needs some Retarget methods... now if only optionsscalper could help me work through this math ;)

Here's the video: