I’m trying to show my latest tweet on my website like yours. How do you make the names and links show up like that?

Conceptually it’s very simple. If you like Regular Expressions, the implementation is very simple too. If you don’t, those bits might be described as hellish. Here’s the workflow:

• Fetch latest tweet via the Twitter API
• Find all @name references, look up their real name, and replace with a link
• Find all URLs (“http(s)://…”) and replace with a link to that URL
• Find all hashtags (#hashtag) and replace with a link to Twitter Search
• If the tweet starts with @name(s), wrap them in a “To {@name(s)}:”

Simple! Right? Right. So we take a tweet which looks like:

@ballance @bspotter a summary of my view on #sharepoint - http://rexmorgan.net/media/spcomparison.jpg

And format it to look like:

<span class="salutation">To 
    <a href="http://twitter.com/ballance">Chris</a>,
    <a href="http://twitter.com/bspotter">Brandon</a>:
</span>
a summary of my view on <a href="http://twitter.com/#search?q=%23sharepoint">#sharepoint</a>
 - <a href="http://rexmorgan.net/media/spcomparison.jpg">http://rexmorgan.net/media/spcomparison.jpg</a>

<a class="date" href="http://twitter.com/rexm/status/2772241681">— <span>8:06 PM yesterday</span></a>

The code’s a bit too long to paste in this format, so I got to take Rick Strahl’s sweet CodePaste.NET for a spin and dropped the code here.

Two thing to keep in mind: (1) Twitter can sometimes be slow. Multiple lookups to get people’s real names means this can be even slower. Now, Twitter is pretty cool, but it’s not worth making your audience wait for it to time out. It’s not worth making your audience wait at all. Stick all this code in an HttpHandler and include it as a JavaScript at the bottom of your page, so it will execute after your page is safely in your user's browser. If it fails, you'll just have a blank spot on your page:

</body>
<script type="text/javascript" src="twitter.ashx"></script>

(2) The Twitter's REST API has a 150-request-per-hour limit from a single account or IP. Cache your tweet results enough not to go over that limit, or you will be blacklisted! I cache mine for two minutes. Cheers!

• I do enough design work to know the difference between HSB (also called HSV) and RGB, so I know changing the hue is extremely easy if I have the HSB value (the "H" stands for Hue!).
• I also know GDI+ in .NET works primarily in (A)RGB. I can iterate over the pixels of a Bitmap object and Get and Set the pixel value in RGB.
• There is a mathematical way to convert an RGB value to HSB and vice-versa, but I have no idea what that is.

A few minutes on Google yielded the equations, so I slammed this together in a few minutes more. The basic workflow is:

• Load an image and an amount to shift the hue by
• Iterate over all the pixels in the image
• For each pixel, convert its RGB value to HSB, change the hue, convert back to RGB, set the pixel's new RGB value
• Save the image

Here's a sample input/output:

Here's the central code which changes the hue for a single pixel:

private Color CalculateHueChange(Color oldColor, float hue)
{
    HLSRGB colorConverter = new HLSRGB(
        oldColor.R,
        oldColor.G,
        oldColor.B);
    float startHue = colorConverter.Hue;
    colorConverter.Hue = startHue + hue;
    return Color.FromArgb(
        colorConverter.Red,
        colorConverter.Green,
        colorConverter.Blue);
}

Not exactly rocket science, but interesting to me and presumably the person who asked the question. Here's the source. Disclaimer: This is *not* an efficient way to do any kind of image manipulation. It is just a proof-of-concept. Cheers!

If you control the web server, this isn’t a big deal. A simple config change in IIS6 or IIS7 will keep the worker process alive – and your site code in memory, waiting to be served - indefinitely.

But plenty of sites run on shared hosting. In that case, you don’t have any real access to IIS settings. It’s also not really in the interest of your shared hosting provider to offer to keep your site in memory any more than it absolutely needs to be. So what to do? There is a handful of services which offer to hit your site every x minutes to keep IIS from killing your application. Those just don’t seem right, though. Keeping an application alive should be something we have very granular control over – not some one-off service that might disappear tomorrow.

So I wrote a little class that will let an ASP.NET application decide when and whether to “keep alive” itself. Nothing special, really – it puts an object into cache for 10 minutes, and when the 10 minutes are up, the object requests a page in your site through IIS and re-inserts itself into the cache for 10 more minutes.

As long as your application wants to keep itself alive, it can call KeepAlive.Start(url). Just pass in any URL in your site (e.g. "http://www.rexmorgan.net/journal"). You can check IsKeepingAlive to see if your app is currently keeping itself alive. If you want to stop, call KeepAlive.Stop(). (Of course, that won’t actually kill your app – just allows IIS to eventually kill the process if it goes idle).

Here’s the code. If you find it useful, let me know! Cheers:

public class KeepAlive
{
     private static KeepAlive instance;
     private static object sync = new object();
     private string _applicationUrl;
     private string _cacheKey;

     private KeepAlive(string applicationUrl)
     {
         _applicationUrl = applicationUrl;
         _cacheKey = Guid.NewGuid().ToString();
         instance = this;
     }

     public static bool IsKeepingAlive
     {
         get
         {
             lock (sync)
             {
                 return instance != null;
             }
         }
     }

     public static void Start(string applicationUrl)
     {
         if(IsKeepingAlive)
         {
             return;
         }
         lock (sync)
         {
             instance = new KeepAlive(applicationUrl);
             instance.Insert();
         }
     }

     public static void Stop()
     {
         lock (sync)
         {
             HttpRuntime.Cache.Remove(instance._cacheKey);
             instance = null;
         }
     }

     private void Callback(string key, object value, CacheItemRemovedReason reason)
     {
         if (reason == CacheItemRemovedReason.Expired)
         {
             FetchApplicationUr();
             Insert();
         }
     }

     private void Insert()
     {
         HttpRuntime.Cache.Add(_cacheKey,
             this,
             null,
             Cache.NoAbsoluteExpiration,
             new TimeSpan(0, 10, 0),
             CacheItemPriority.Normal,
             this.Callback);
     }

     private void FetchApplicationUrl()
     {
         try
         {
             HttpWebRequest request = HttpWebRequest.Create(this._applicationUrl) as HttpWebRequest;
             using(HttpWebResponse response = request.GetResponse() as HttpWebResponse)
             {
                 HttpStatusCode status = response.StatusCode;
                 //log status
             }
         }
         catch (Exception ex)
         {
             //log exception
         }
     }
}

<searchplugin xmlns="http://www.mozilla.org/2006/browser/search/">
     <shortname>Stack Overflow</shortname>
     <description>Stack Overflow Google Search</description>
     <inputencoding>UTF-8</inputencoding>
     <img height="16" width="16" />data:image/x-icon;base64,R0lGODlhEAAQAMQAAGZmZu6+gNhWI+aeQfvv35lmM8+4oOB4T/fd0+CGEbuZd9bCrf///+HClvPPoOSWMbSPaeWObOiae9thMvro4vffwOTWyequYPj18f337/XXsOimUAAAAAAAAAAAAAAAACH5BAAHAP8ALAAAAAAQABAAAAVhICOOYjYJCKmSkjBRaxwJRxZXzpgdQhRviYdGRDlJVoRLIjgsTmyrTOARrCBSJMPCgmEQNINNrEAmKwyNSsyggJTJKgBAhbEsDAy5SC/v9/NzgIB+fIF6MXuGhIuHjIwMIQA7</img>
     <url template="http://www.google.com/search" method="GET" type="text/html">
         <param value="site:stackoverflow.com {searchTerms}" name="q" />
         <param value="utf-8" name="ie" />
         <param value="utf-8" name="oe" />
         <param value="t" name="aq" />
     </url>
     <searchform>http://www.google.com/search?q=site%3Astackoverflow.com</searchform>
</searchplugin>

Just create a new xml file in your Mozilla Firefox\searchplugins folder, paste the above in, and restart FF. You should see something like this:

I have a few side projects that need a distributed in-memory cache. These projects are all in .NET so my obvious choices were SharedCache, ScaleOut StateServer, NCache or memcached Win32 with one of several .NET clients. Memcached is a lot more free than the latter two and more well-regarded than the first, so last week I started a little personal project of porting memcached to .NET. My C is pretty rusty but relatively speaking memcached is pretty simple, and it seems like a managed version could perform quite well. Since I know c# better than English, it makes enhancements and customizations to my caching layer much easier.

Thankfully I didn't burn too much time on memcached.NET before Microsoft announced Velocity - a distributed cache written to natively support the .NET stack. After digging in to the CTP code, I came away very impressed. In the past I've viewed the caching layer of an application very simplistically from a usage perspective - a persistent dictionary of keys and frequently used objects. Distributing it across multiple machines adds complexity to the service but not the consumers. Velocity has some features with huge implications in the kind of value a cache can deliver:

• Lookups by tag. This means one thing to me: multi-dimensional object keying. No more ugly pointers or multiple copies of an object per key. This increases the value of the caching layer by orders of magnitude over a simple key-value pair table.
• In-process storage. With a typical cache service, our cache will store a serialized copy of User::Bob in memory. Bob is very popular in our application, so his user object is deserialized into the application process on almost every request. This is wasteful and contributes to memory pressure since we are essentially storing the same object at least twice - sometimes more. In-process storage allows heavily used items like User::Bob to stay in the application process space instead of being serialized to the cache service.
• OOTB Session Provider. Velocity includes a SessionStateStoreProvider implementation out of the box. A high performance, high availability state server for free without putting any pressure on your SQL box (which is probably why you are considering Velocity in the first place).
• Atomic operations & concurrency management. Optimistic locking with versioning opens the door to much more sophisticated functionality than would otherwise be practical with the typical pessimistic locking. I predict applications that are able to align themselves with actual usage patterns much more intelligently.

As I noted in the beginning, memcached is pretty simple. And as my short list of highlights suggests, Velocity is anything but. Although memcached and Velocity solve the same problem - offloading high-volume requests from the data tier to an in-memory intermediary - they serve surprisingly different purposes. Scott Watermasysk summarizes the distinction neatly:

On one hand you have Memcached which treats the cache as something you should never rely on. It is there to help but you should always assume it is going to fail on you and even more importantly (to Memcached) you should accept that as a fact. If you read the Memcached FAQ you can almost here the author laughing when talking about fault tolerance. On the other side of the fence you have features like replication and high availability.

The practical implications are significant. What kind of service are you running? What kind of data are you moving? Who is your audience? These are very high level architectural questions that help shape whether to go with a memcached-like solution or a Velocity-like solution. Jim Benedetto, in an interview with Baseline Magazine, described MySpace's answer to these questions:

100% reliability is not necessarily [the] top priority. "That's one of the benefits of not being a bank, of being a free service"...on MySpace the occasional glitch might mean the Web site loses track of someone's latest profile update, but it doesn't mean the site has lost track of that person's money. "That's one of the keys to the Web site's performance, knowing that we can accept some loss of data"

Usually my default reaction such an idea is "no way!" Loosely coupling system components to the point where data in one layer might not make it to the next layer every time makes me feel very uncomfortable. Embracing discomfort is necessary for growth though, so let's give it a big bear hug and dive in. The original purpose of memcached was to support LiveJournal. In this environment, a failure rate of the caching layer might just mean an extra few round trips to the database. As long as the caching layer works some of the time, we still see a benefit. But then issues start to get sticky. What if the failure comes when we try to invalidate a cache item because a journal post was updated? The old version will be exposed to the public longer than intended. Is this acceptable behavior? Obviously I don't know the answer to that for LiveJournal's case. But the point is significant - how does reliability affect the business value of your application? For MySpace, responding promptly to a hundred million requests and failing a percentage of those delivers greater value than rolling service brownouts or throttling everyone.

Ultimately, the Velocity announcement has brought these questions to the forefront of my mind. I'll be relaxing in Ireland for the next week and a half, but I'm sure I'll be thinking about how to answer these questions for my apps. Make sure to do the same for yours.

START WITH BREVITY. Increase the other dimensions AS REQUIRED BY TESTING.

He actually takes his time to elaborate on the justifications and implications of this advice, culminating in an oft-linked-to post that is really worth reading. The first time I read it I thought it sounded nice, but it didn't quite *click*. It took about 6 more months of fumbling through base classes that I haven't implemented and interfaces that only get used in one place before I punted.

When you are handed a problem, if your first thought is "I will need a base class that does x and probably an interface for y" you are creating extra work for yourself. Writing abstract classes first is, very literally, solving problems that don't exist. When you're writing code, you don't have a problem until you are calling a method that doesn't exist, or doesn't do what you need. No programmer, no matter how good, can accurately predict what calls he will be making from hypothetical classes before they are written. Even if you have a complete class diagram for your entire application (and if you do, why didn't you spend that time writing the code?), it will be wrong. You will have to make changes as your ideas break on the rocky reality of implementation.

Many programmers, when they create a new class, add a ton of features to that class to make it "complete" -- that is, they try to anticipate everyone who may ever use this class, and they add methods that those hypothetical users may want...you may be saying to yourself, "What's wrong with flexibility?" Strangely, I was about to tell you. The problem is YOU ARE NOT A LIBRARY PROGRAMMER.

What Would Wil Do? "Start with brevity." Break the tasks into easily defined units of functionality, and take the first item off the list and code it concretely. Only build what you need to make that functionality work. After you encounter code that can be shared, write your base class. After you hit a problem that can only be solved with an interface, stub it out.

If you just wrote public abstract and you don't already have a class written that will be inheriting from it, stop right there. Backspace over that abstract keyword and start building your concrete implementation first. Put off best practice 'till tomorrow for what you can get working today. I guarantee you will have a more stable, maintainable product in the longest run, and you'll ship sooner.

This all is not to say that you should not have good design to your software. A good architecture is invaluable and irreplaceable. In a later post, I'll elaborate on design approaches that can be built in as your code takes shape, without burning time creating a base library instead of getting things done.

I've been brainstorming names for the web site we're building. I've surveyed some of the finest minds in the software developer community (for very small values of "fine"), and we've come to a collective realization: naming a website is hard. Really, really hard.

No kidding. This isn't just true of websites, or even of companies, but of ventures in general. That's why there are firms that charge tens of thousands of dollars to do it for you. And it's hard to blame them - would BlackBerries be quite as popular if they were called LeapFrogs instead?

But Jeff shoots himself in the foot from the beginning by (almost) eliminating any name that isn't available as a .com. Anyone reading this has some inkling of the sheer volume of domains that have already been registered, and no guess at what percentage of those are squatted would be too cynical. When practically every common and obvious .com name is already taken, companies have to resort to more and more contrived names just so they can say they have theirname.com. But is it really worth it?

In their book Getting Real, 37signals discusses their emphasis on names that make sense:

Give your app a name that's easy to remember. A big mistake a lot of people make is thinking their app's name needs to be ultradescriptive. Don't worry about picking a name that vividly describes your tool's purpose; That usually just leads to a generic, forgettable name. Basecamp is a better name than something like Project Management Center or ProjectExpress.

The name should be simple, with a blend of familiarity and uniqueness - Basecamp, Campfire, Backpack, etc. are all familiar word-phrases to English speakers, but are unique enough as product names to stick. Here's the really interesting part - they don't have the .com for any of those products. Basecamp is basecamphq.com; Campfire is campfirenow.com; Backpack is backpackit.com. 37signals doesn't exactly need publicity by now, but they weren't always known. How did they violate the common domain name wisdom and still succeed?

Jason et al recognized something that most of us just can't seem to get past: the precise domain name really isn't that important:

[D]on't sweat it if you can't get the exact domain name you want. You can always be creative and get close with a couple of extra letters

They looked past appearances and went straight for use. How do people use domain names? If you have a great service, people are going to

• Bookmark it
• E-mail it
• Twitter it
• IM it

What people will almost never do is try to remember the service by name and retype the address from scratch. At worst, they will Google it, which should be easy because it's an easy, short, memorable name. In every case, it doesn't even matter what the domain name is. Your users will never have to remember it or type it. People love or hate 37signals for one reason or another, but I've never heard of anyone begrudging them or their services because their domain names are slightly off. If a service is delivering value, the particular domain name just falls into the background.

Ultimately, I think people get too caught up in selecting "the right" domain name because they are insecure about the website behind that name, and they feel like they need every bit of help they can get, like agonizing over SEO and having "the right" name. If there's one thing 37signals is not, it's insecure. And although their word is thrown down as gospel way too much among bloggers, a bank statement is hard to argue with.

Be confident with your service and your name, and success will follow. Your .com is only as central to your business as you make it.

How can you possibly learn the craft without being exposed to other programmers with different ideas, different approaches, and different skillsets? Who will review your code and tell you when there's an easier approach you didn't see? If you're serious about programming, you should demand to work with your peers.

One of the more unfortunate traits common to the programmer demographic is our remarkable ability to be off-putting. It's certainly more true for some than for others, but even when a programmer is considered "quite personable", he's probably a lot closer to ISTP than to ENFP.

So I'm trying to improve. The single best resource I've found for this is Dale Carnegie's How to Win Friends & Influence People. It's an immersive read - Carnegie is an excellent storyteller and uses clear, concise examples to communicate his "Fundamental Techniques". It's practically written for a programmer, removing all fluff and assumptions about interpersonal interactions - a literal API reference for people:

• "Give people a feeling of importance by praising the good parts of them"
• "Become genuinely interested in other people"
• "Encourage others to talk about themselves"
• "Start with questions the person will answer yes to"
• "Let the other person feel the idea is his/hers."

The brief sampling above evidences the paradox of effectively dealing with people - we have to give what we want to the person we want things from. On the surface, the advice sounds so simple - "be nice to people and you're more likely to get what you want." But how often do we do it in practice? How often do you really give up all the credit for a job well done, even if you did most of the work - or it was even your idea? Not often enough.

Carnegie's thin paperback is so full of behaviors to change that it's overwhelming, so it's good to start with a select few and make them habitual. I've been developing a few habits of my own, slowly but surely. These things will seem like Life 101 to some, and far-fetched to others:

• Being very direct and task-oriented (a major programmer trait), when I need something from someone my first action is to start a new e-mail and politely ask for what I need. New habit: before I hit send, I backtrack to the beginning of the e-mail and write a sentence or two complimenting something they've done recently, or asking about something that is important to them.
• I am trying to remember to append the person's name every time I say "hello", "thanks", or "goodbye" to them.
• When someone compliments me directly, I try to think of someone who contributed, even indirectly, to whom I can credit some of the success.

Hopefully the pattern here is pretty obvious: make other people feel important. People like feeling like other people are interested in them and their issues; people like hearing their name; people like receiving credit. At first it feels a little shallow, maybe even a little sociopathic - having to consciously fish for nice things to say to or about people. But I can say from experience that it doesn't take long to become habitual, and then become natural. When you think about these things all the time, you actually do start to become interested in other people's issues. You become invested in the success other people get to enjoy when you give them credit for a job well done. And that's the real trick - not faking pleasantness to manipulate people into doing what you want, but genuinely being the kind of person other people like getting along with. That kind of person naturally gets what they want, which is really where we all want to be.

• Hosting & infrastructure
• Quality of developers
• Project management & delivery
• Etc.

The rating "quality of developers" got a 4. For a minute, I was a little shocked and offended. If there is one thing our group is known for and prides itself on, it is the quality of our development team. I work on one of the best development teams I've ever known, and my opinion is not atypical. I hear on a weekly basis how above-par we are as a group. The web platform team is "leet", as they say.

Four is good - great, even. Three being "average-competitive", it's highly desirable to be a 4. That being the case, why do I care so badly about being a 5? Is it realistic to want to be a 5? Is it that much of a shock to be told you're only really good when you thought you were the best?

Like I said, my reaction lasted for a minute. But then I asked myself, "is it possible to be a 4 and also be the best?" I think it is. When I say best, I definitely don't mean best in the world. There's always someone better. But "best" in a very localized sense can be different for everyone and still be useful. Like my track coach told me so many times, you're only racing against yourself. The other people out there on the track with you are just useful tools to help benchmark your progress, but the competition is internal.

Anyone who has done any kind of race, especially track, knows that you get your best times when you consistently run with people a little bit better than yourself. The person ahead of you is an attainable goal. If you're alone, you have no baseline with which to construct the bounds of potential achievement. If you're half a mile behind the nearest competitor, any effort would be wasted. If I'm a 5, I've peaked. Any improvement from there on is sheer luck. Personally, I don't want to peak yet.

Never be comfortable. If you think you're on top of the world, it's impossible to go any higher. You've established a mental model of your profession that prevents you from truly aspiring to improve. Instead, if you think you're a 5, make yourself a 4. Keep besting yourself. Spend some time and effort identifying some aspect of development you don't fully understand. Actively seek to work with people who make you feel a little stupid. It's only as uncomfortable as you make it. Be a 4, forever.