Diaspora - Good Idea, But...

I've been watching the Diaspora project carefully for little while now. If you aren't familiar with it, the simplest explanation is that it is an open-source version of facebook where users owns their own server.


Diaspora's own explanation is not so concise, but here it is:

Diaspora aims to be a distributed network, where totally separate computers connect to each other directly, will let us connect without surrendering our privacy. We call these computers ‘seeds’. A seed is owned by you, hosted by you, or on a rented server. Once it has been set up, the seed will aggregate all of your information: your facebook profile, tweets, anything. We are designing an easily extendable plugin framework for Diaspora, so that whenever newfangled content gets invented, it will be automagically integrated into every seed.

[read the rest here]: 

I've been looking for something like this to come along for a while. There have been a few feeble attempts so far, but none have gained any traction in the wild yet... and I'm not expecting this one to either.

Here's my take on it...

The Diaspora project has gotten a lot of media attention recently including a feature story in the New York Times. The reason it has gotten so much coverage is mostly just lucky timing. They happened to launch a $10k request for donations on kickstarter.com right as privacy and security concerns with Facebook became a mainstream press issue. Being lazy, the media just latched onto Diaspora as the underdog counter-story to Facebook, rather than do something rash like actual journalism.

Diaspora, thanks to the coverage spike, has accumulated over $175,000; much more than the mere $10k they'd originally asked for. If the donations keep rolling in, they can just skip code and go straight to being famous, rich, and retired.

I'm always pretty excited by these kinds of projects though, and I love the general idea of an open source social network. And, really, who doesn't like a good under-dog?

But, despite my enthusiasm, I am not all that impressed by what I've seen and read about Diaspora so far. I don't have a good feeling about the technical approach, nor the fundamental concepts.

Fundamental Concepts:

The project's fundamentals are subtly flawed in at least two very important ways.

The first is related to the design architecture; that Diaspora will be a distributed multi-node system.

The idea of distributed systems itself is quite solid of course. Spread storage and processing out to as many machines as possible, each fully responsible for their own information domains. This is the principle upon which the web itself operates, so it is well proven.

Diaspora's flaw is the assumption that every user will "own their own server".

This isn't 1994!

Social networking users are regular people, and regular people do NOT want to manage a server node. It doesn't matter how easy you make node management!

Users can barely manage copy and paste, and you want to put them in charge of a distributed information server?

I think the team has completely misunderstood the user's requirements here. Users "want control of their data". They never said that they "want to control their data". This isn't just semantics; it is the critical distinction between what they want, and what Diaspora is proposing to build.

For several years, the trend among users, even the technical ones, has been away from user owned software. Today's users don't want to install or configure anything themselves. They use pure internet apps almost exclusively. The same is true with user data. They don't want to have to deal with keeping track of it, or backing it up, or moving it around. In short, they don't want the responsibility for all that technical crap. They just want to use the software, have the data, and have someone else to blame when things break or data gets lost.

You can see this user trend clearly in the rise of gmail, youtube, flickr, google apps, etc. Wherever possible, people are steadily switching to web supplied software, and are moving data off of their own vulnerable machines into the cloud. All the users have been asking for is a sense of control over what the cloud does with the data once it gets there.

The second conceptual flaw is more subtle. It is the simple lack of focus on end-user features. Their explanations of the user features are, at best, vague; when they bother to mention them at all.

Their focus seems confined to the technical back-end details. Even worse, they use the term "feature" to label the various plumbing aspects of the system. These are not features, these are mechanics. Mechanics are just the means to the ends; it is in the ends that the features hide.

My concern here is really that the team just doesn't seem to understand their true goal well enough to build towards it reliably. They seem focused too narrowly on "how", but not enough on "what".

The plan appears to be to design and build a framework first, and deal with user features later. They say so on their blog in some detail actually, but frameworks are not applications.

I like the iterative and pragmatic approach they describe, but they are already building a framework and still they don't provide coherent explanations of actual user facing features. They only describe them in abstract vagaries; and this is what concerns me.

This kind of thinking is tragically common in application design, and it rarely turns out well. If you don't clearly define the user features you are aiming for, in quite some detail, then you cannot know if you are building the *right* framework; one that will usefully support the user features you'll layer on top later. The framework is likely to be too generic to be very useful during the real feature development stages. When developing front-end code, nothing is harder than having to code against an abstract framework's limitations and constraints, but not getting much help with the very concrete requirements you are faced with.

There is nothing wrong with building a great framework of course, but the team is getting donations based on the promise of a better social-networking application; not just a social networking framework.

Perhaps the fault just lies in the public's misconception about what Diaspora is proposing to build.

The Technical Approach:

Distributed systems are difficult, but distributed systems with a variable number of member nodes, coming and going at will, are many orders of magnitude more so.

Then there are the problems of distributed document and NoSQL database systems, which are still rather new and immature technologies. Even the best of these still have serious limitations.

Performance is a significant concern in such a system. Nodes have to be able to locate and query other nodes for data very quickly, and a social network will need to hit a large number of peer-nodes for even the simplest user features.

And then there is the problem of fault-tolerance in such a highly distributed system. When a member node is down, slow, or unreachable, the system has to gracefully degrade, without error, and without significant disruption in the user's experience.

Any of these areas present the kind of technical challenge that even companies the size of Google struggle with, but few systems combine so many such elements as Diaspora would. Their back-end architecture is up against some of the nastiest technical challenges the field has to offer, plus competing with established players whose centralized systems do not suffer the same.

To me, the worst part is that, after having overcome the design problems, the system itself will have gained almost nothing that would add any value for the users. I can't think of anything this design allows Diaspora's users to do, that a centralized social network doesn't also provide. Even the promise of giving users control over their data is not in any way unique to this design. Facebook can give users the same control, and with little technical effort (though, it would have a severe impact to their business model).

Despite my misgivings about the architecture, I still think Diaspora should try this approach. Just because I shat all over it, doesn't mean it's wrong to give it a try. If nothing else, they might advance the applied sciences of distributed system design. Even if Diaspora doesn't succeed with a distributed social-network, someone eventually will.

Whether real users will care or not is an entirely different matter. With the team putting so much effort into the complex back-end architecture, they will likely not have the resources left to do a bang-up job on the front-end features; at least not quickly enough to still be relevant.

The front-end features have to be amazing, or the system will not have much user interest. They are up against well-established competition that has had a lot of time to evolve and design their UIs. Creating a compelling experience to compete with them will be quite a daunting, and non-trivial, technical challenge all by itself.

Next...

It isn't fair to spend this much text bashing someone else's project without at least doing them the courtesy of providing constructive suggestions or alternative ideas. But, I'm going to save the constructive ideas for another post.

How Apple Will Lose the Mobile Computing Race

I've heard several people say that "Apple is the new Microsoft". These people are wrong; dead wrong.

Apple is the new Apple. They've not changed in the last 20 years, not even a little bit.

Google is the new Microsoft, and Apple is going to lose the mobile device market to Google the exact same way it lost the desktop market to Microsoft 20 years ago.

How is this going to happen? First you have to know the history.

Let me tell you a little story...

Back in the 80's there were two companies; Apple and Microsoft. Suddenly Apple comes out with a magic new product way ahead of the competition. Enter the Macintosh. The Mac was guaranteed to change personal computing forever, and everyone knew it before the Mac even hit the shelves. There was media hype and gobs of nerd excitement well in advance of the Mac's debut. And the Mac delivered spectacularly on all of its promises.

But Apple insisted on near complete control of the entire platform; hardware and soft. They were terrified that someone else might come along and spoil the pure awesome.

Apple used deliberately unusual hardware, and controlled it with an iron fist. Only Apple and a few licensees were allowed to make Mac hardware. The 3rd party accessory market was as restricted as Apple could make it too.

Programmers could make applications for the Mac of course, but Apple maintained tight control over how applications used the hardware and interacted with the OS. Developers played in the sandbox, but it was Apple and select partners that created the majority of useful Mac software.

Apple was also territorial about who could sell their precious. Macs were distributed mostly through select retail partners. Anyone else that wanted to sell a Mac paid full retail price --which made it very hard to compete with Apple's preferred retailers.

Because Apple had tight control end-to-end, the Mac was a very stable and reliable computer. Most of the software was also high quality, which made the Mac a joy to use.

On the other side, you had Microsoft. They weren't really a hardware company though. They concentrated on making a decent operating system and left the hardware to other companies that specialized in that sort of thing.

There was a lot of compromise and cooperation between Microsoft and the hardware makers though, of which there were many. They created a large market with a wide range of different systems, each with different capabilities, quality, and prices. Microsoft just did what they could to make sure that Windows worked reasonably well with whatever crazy-ass hardware the other guys came up with.

Microsoft made a decent enough OS, but what they did really well was make programming languages, compilers, and development tools --all that stuff you need in order to make software for the regular folks. Microsoft made it easy to develop applications for Windows, and they stayed out of the way as much as possible. They didn't put up a fight when developers released software to compete with Microsoft's own, and they didn't stop developers from extending the operating system itself in new and unusual directions.

Microsoft was later than Apple in coming out with a good GUI based OS. Windows wasn't too pretty nor much fun compared to the Mac; especially at first. But PCs were cheaper, and came in a variety that fit different people's needs and budgets. The most important thing was that a Windows PC could do everything that a Mac could, though not always with the elegance of the Mac. People often preferred a Mac, but they could (and did) settle for PCs instead.

In the end, what killed Apple the first time around was Apple's own paranoia. All by itself, Apple couldn't evolve the Mac hardware nor the OS fast enough to keep up with a young and rapidly changing personal computer market.

All Microsoft had to do was try and keep up while other companies raced forward with new ideas.

Now jump forward 20 years.

There are two companies; Apple and Google. Suddenly Apple comes out with a magic new product way ahead of the competition. Enter the iPhone. The iPhone was guaranteed to change mobile computing forever, and everyone knew it before the iPhone even hit the shelves. There was media hype and gobs of nerd excitement well in advance of the iPhone's debut; and the iPhone delivered spectacularly on all of its promises.

But Apple insists on near complete control of the entire platform; hardware and soft. They are terrified that someone else might come along and spoil the pure awesome.

Apple uses deliberately unusual hardware, and they control it with an iron fist. Only apple is allowed to make iPhones, and the 3rd party accessory market is as restricted as Apple can make it.

Programmers can (and do) make applications for the iPhone of course, but Apple maintains near complete control over how those applications use the hardware and interact with the OS. Developers are allowed to play in the sandbox only if they use the specific tools that apple permits. Apple and a few select partners make the majority of the useful iPhone apps. Most developers that make apps to competes with Apple's own are denied access to the app store; which is the only way users can obtain apps for the iPhone. Apple will even deny an app if they just don't like what it does.

Apple is territorial about who sells their precious. The iPhone is (currently) only distributed through one network in the U.S., and apple exerts enormous control over how that network does business. AT&T had to wait to roll out 3G services until there was an iPhone that also supported it. There were other mobile phones sold by AT&T that had  3G support as much as a full year before, and AT&T had deployed the network hardware long before Apple's 3G iPhone came out.

Because Apple is in such tight control, the iPhone is a very stable and reliable smartphone. Most of the software is also of high quality, which makes the iPhone a joy to use.

On the other side, you have Google. They aren't really a hardware company though. They make a good mobile operating system, but have left most of the hardware in the hands of companies that specialized in that sort of thing.

There is a lot of compromise and cooperation between Google and the many hardware makers. They have created large market with a wide range of different Android phones with different capabilities, quality, and price. Google just does what it can to make sure the Android OS works reasonably well with whatever crazy-ass hardware the other guys come up with.

Google makes a good mobile OS, but what they do really well is provide cloud services --services developers can use to make useful mobile software for the regular folks. Google makes it easy to build applications for Android, and supply much of the cloud services free of charge. They stay out of the way as much as possible, but give developers a way to distribute software through a centralized app store, with very few restrictions. Apps can also be obtained through independent channels too. Google doesn't put up a fight when developers release software to compete with Google's own products, and they don't stop developers from extending the Android OS in new and unusual directions.

Google was later than Apple with a smartphone. Android isn't quite as pretty compared to the iPhone; though it is rapidly getting there. Android phones are cheaper, available for nearly any network, and come in a wide variety of forms to fit different people's needs and budgets. And the important thing is that an Android Phone can do anything that an iPhone can; sometimes even with the same elegance as the iPhone. People often prefer the iPhone, but they can (and do) settle for Android phones instead.

In the end, what will kill Apple the second time around is Apple's own paranoia. All by itself, Apple cannot evolve the iPhone fast enough to keep up a young and rapidly changing mobile computing market. Their treatment of developers is pushing them to other platforms fast.

All Google has to do is try and keep up while other hardware and software companies race forward with new ideas.

This same exact pattern of behavior is repeated with the new iPad.

The situations are so similar it is almost insane that Apple can't see their own doom coming.

There are some major differences between now and 20 years ago, but none of them bode well for Apple.

Google is in a much more competitive position than Microsoft was 20 years ago, and Android is a much better product to pit against the iPhone than Windows was against the Mac.

Perhaps the biggest difference between now and then though is that Apple wasn't crapping all over their software developers back then. Apple did limit developers in some ways, but never in the arrogant and insulting way they do now... and especially not through any legal or contract trickery like the iPhone developer agreement.

Apple is also much more blatantly motivated by pure monetary greed. Twenty years ago, it felt like the Mac more about a vision of excellence, making a better tomorrow, being different, and enabling new and wonderful possibilities. The iPhone today though is clearly just a cash cow. Apple's every legal and marketing move is so transparently profit motivated that it doesn't even fool kindergarteners.

There is no greater vision behind the iPhone like there was the Mac; behind the iPhone it's just dollar signs, abused developers, and shackled customers.

Peter Watts - about birthdays....

I'm one of those people that just has a knack for seeing the world a bit 'differently" than most people. What some people see as absolutely normal social behavior, I often see as utterly absurd.

This is not usually an advantage, if you were wondering.

But I've got nothing on Peter Watts, the now famous Sci-Fi author, border-guard crushing bad-ass, and sadly... convicted felon. His writing is filled with this kind of totally brain breaking logic.

Like birthdays...

Below is an excerpt from his excellent novel "Blindsight" that exemplifies exactly the kind of thinking that breaks most people's brains. The novel is available online for free under a Creative Commons license (CC), or you can buy it in paper or audio if you prefer.

In prelude, know that the character Sascha has multiple personalities (the Gang of four as they are known  in the book).

"Yeah? Name one."

"Birthdays," I said, and immediately wished I hadn't.

Sascha stopped chewing. Something behind her eyes flickered, almost strobed, as if her other selves were pricking up their ears.

"Go on," she said, and I could feel the whole Gang listening in.

"It's nothing, really. Just an example."

"So. Tell us." Sascha cocked James' head at me.

I shrugged. No point making a big thing out of it. "Well, according to game theory, you should never tell anyone when your birthday is."

"I don't follow."

"It's a lose-lose proposition. There's no winning strategy."

"What do you mean, strategy? It's a birthday."

Chelsea had said exactly the same thing when I'd tried to explain it to her. Look, I'd said, say you tell everyone when it is and nothing happens. It's kind of a slap in the face.

Or suppose they throw you a party, Chelsea had replied.

Then you don't know whether they're doing it sincerely, or if your earlier interaction just guilted them into observing an occasion they'd rather have ignored. But if you don't tell anyone, and nobody commemorates the event, there's no reason to feel badly because after all, nobody knew. And if someone does buy you a drink then you know it's sincere because nobody would go to all the trouble of finding out when your birthday is — and then celebrating it — if they didn't honestly like you.

Of course, the Gang was more up to speed on such things. I didn't have to explain it verbally: I could just grab a piece of ConSensus and plot out the payoff matrix, Tell/Don't Tell along the columns, Celebrated/Not Celebrated along the rows, the unassailable black-and-white logic of cost and benefit in the squares themselves. The math was irrefutable: the one winning strategy was concealment. Only fools revealed their birthdays.

Sascha looked at me. "You ever show this to anyone else?"

"Sure. My girlfriend."

Her eyebrows lifted. "You had a girlfriend? A real one?"

I nodded. "Once."

Don't let unit testing push you around!

Test Driven Development (TDD) and the ever increasing trend towards Unit Testing as a religion among developers is probably a good thing for software quality in general. I've just  spent a couple of weeks trying to employ the recommended unit testing techniques with Entity Framework 4, and this has reinforced my misgivings about the wisdom of some of the  basic concepts behind how unit testing is supposed to be done.

I've always been somewhat lukewarm towards unit testing. I certainly don't do as much testing as I probably should, but I do agree that some unit testing is essential to developing a quality application. So, I always do some unit testing, but only to the degree that I feel the testing is appropriate or necessary.

But unit testing has grown in popularity over the last 10 years, to a point where it appears that common sense is not a part of the process anymore.

The source of my misgivings about this blind commitment to unit testing deals with one of the fundamentals; that a unit test should only test logic within the specific block of code that is under test.

I don't disagree with this principal, but the sticking point is that you have to fake your code's dependencies, especially the external ones like real databases and external services. In most modern applications, external dependencies are pervasive and sometimes very hard to avoid.

To support testing without hitting external dependencies, you generally design your code in a way that allows for dependency injection. There are several ways to do dependency injection, but the different techniques can range in complexity a lot. On the simpler side you can just use overloaded constructors or write methods so they take their dependencies as parameters. On the other end, there are horribly complex programming acrobatics such as the Inversion of Control (IoC) design pattern.

No matter which techniques you use, the overall point is that your unit tests are able to supply their own versions of any dependencies instead of using real ones. These mock (fake) dependencies will mimic the behavior external systems or other complex code routines.

I'm not opposed to making some concessions in my code in the name of enhanced testability. Indeed, many of the simpler dependency injection techniques lead to better code in general. But there are cases where simple techniques just don't work. This is where I start to have serious misgivings about the wisdom of unit testing.

I've always had the opinion that the use of fancy OOP tricks, complex inheritances in particular, should only be used if there are direct benefits to the application. Likewise, employing advanced design patterns is only worth the effort if the patterns solve issues within your application's actual problem domain.

To some degree, facilitating better unit testing can be considered a good reason to employ some of these more advanced techniques. Indeed, the TDD guys will usually tell you that unit testing is a part of the application's problem domain, and that a full suite of unit tests must be part of the delivered product. I do see their point, but I do believe that there are cases where it is misguided --and unwise.

In my opinion, you should never compromise your application's primary requirements just for the sake of unit testing. Testing is at best a secondary concern; an optional requirement when it doesn't interfere with other priorities.

But that doesn't stop developer after developer from doing insanely stupid shit to their code for the sheer sake of testability. I've seen so many otherwise simple applications become bloated and convoluted beyond reason, and often to the detriment to both developers and the application's functionality.

The most recent case of this that I've run into was with the next version of TicketDesk. I have a class library to encompass the application's core domain logic. Here I had planned to auto-generate my entity model from my database, add some data annotations and custom logic of my own, then just create a simple service API to expose the model to my web application; and in the future potentially other clients such as Silverlight.

All-in-all this is a pretty standard design. My entire reason for choosing the Entity Framework was to leverage the more advanced features, both within the library as well as within the client code consuming it.

After spending a solid two weeks exploring how to make Entity Framework 4 testable the correct way, I'd ended up with an insanely complicated hand-hacked variation of a standard generated EF model. But to support the necessary dependency injections, especially with the problematic EF ObjectContext, I had produced gobs of abstract interfaces and classes. Return types at the service API had become so abstract that the consuming clients had lost access to all of the special functionality of EF models; the very features that had made EF an appealing choice in the first place.

I got far enough into this to prove that achieving a useful level of testability could be done, even with the dreaded ObjectContext. But well before I reached that point, it was apparent that doing so would make my code into a complex and time consuming maintenance nightmare.

I still needed to be able to unit tests my custom logic and service layer though, but I was done with doing it "the right way". Instead, for my tests I pointed the ObjectContext at a real database server, used the built-in CreateDatabase method to generate a temporary fake database schema from the EF model, and wrote my tests against it.

My tests are able to add any fake data needed directly to the temporary database via the strongly typed and auto-generated ObjectContext. With this approach, I can still test the relevant code blocks, but without jumping through hoops to dodge a dependency on a database server.

Sure, it isn't technically the correct way to do unit testing... and yes, many of my tests do spend a bit of time talking to the external database, or managing the test data within it; but all of the extra complexity is encapsulated directly within the unit tests or helpers classes within the test project; not junking up my actual application.

I'm sure the more fanatical unit testing advocates, especially the TDD guys, would foam at the mouth at this approach, but I have nearly 100% code coverage in my tests (excluding generated code). And for me, the biggest advantage is that my application code is simple, elegant, effective, and highly maintainable...

Isn't that the whole point of unit testing?

Visual Studio 2010 - Revisiting Themes and Fonts

[update: 4/2010 - there is a new color schemes site for visual studio that also has several alternate themes, including the humane studio theme discussed here. ]

With the pending release of VS 2010 and it's shiny new UI, I thought it time to revisit the topic of color schemes and fonts. I have typically use a hacked up "dark theme" in VS 2008 with a black or near-black background, but I wasn't too thrilled with the results after porting my previous color scheme over to VS 2010.

I've always been decently happy with Visual Studio's text editor once I change a few of the more retarded defaults (really? Line numbers aren't enabled by default?). But that default white background with dark text is a bit harsh on the eyes.

I personally prefer darker color schemes, but Visual Studio has never been a "theme" friendly app. You can easily import and export settings, which serves as a poor-man's kind of theme though, but overall personalizing the theme is Visual Studio is always a pain in the ass.

So the first thing I did was try to find a new base theme online that I could start from, then customize it to my own preferences.

Every time I try a black background based theme, I keep running into the same problems:

1. There too few colors that are bright enough to contrast readably against a black background. This is exactly why so few web pages use black-grounds despite their popularity among web users.  


2. A good editor color-codes text to help the developer quickly interpret the meaning and structure of their code. For Visual Studio you need about a dozen distinct colors, which is not easy against a black-ground.


3. Most colors that are usable on black are the really bright ones like hot pink, lime green, and electric blue. These tend to clash easily with each other though, and I often end up with a nauseatingly horrible color scheme as a result.

With VS 2010, these problems are just harder to get around. The new version adds yet more color-coding, all of which is useful. So this time, I tried a few of the compromise themes.... Ones that aren't based on black/near-black backgrounds. The most interesting of these turned out to be a theme called HumaneStudio:




The colors remind me of an old editor (whose name I cannot remember) from back around 1995 or so. It uses a series of browns for backgrounds, and for text a mix of various earth tones from across the color spectrum.

I didn't expect to actually like this theme when I downloaded it. Earth toned stuff isn't my thing typically, but after only a few minutes working with it I discovered this was quite possibly the most fantastic theme ever! The colors are dark enough not to be too harsh on the eyes, and the wide array of available text colors works effectively with Visual Studio's color coding. I did have to make some minor changes though: First I replaced the font...

A mono-space font is non-negotiable for code editors (so says me!), but there are several good mono-space fonts to choose from. There are six that I personally recommend, all of which achieve a decent balance between long-term readability and efficient use of screen space:

Serif fonts:

A serif is the little ticks at the edges of characters. These come from the old days where chisels were used to carve letters in stone or wood. Serifs tend do improve readability of text, especially with larger blocks of smaller text. Most books, newspapers, and other text-heavy documents use serif based fonts for this reason. These fonts are less visually appealing at larger sizes though, so serifs are less common for titles, signs, and short text scenarios. Serif fonts also tend to be more readable on older low-resolution electronic displays. A major drawback to serifs is that they tend to bleed into darker backgrounds. The serifs can even disappear completely when used on black at small font sizes.

• Courier New (Serif) - This is an old font, and been the default for windows text editors for a very long time. The problem is that it wasn't designed for modern high-resolution LCD displays. Quite the opposite actually, as this variation was specially designed for readability on older low resolution CRTs. Courier New wastes a lot of horizontal space, and doesn't scale smoothly. Still though, this font and has been around a very long time for very good reasons, and remains a quite serviceable font today.
  
  
       
• AnonymousPro (Serif) - This is a modern serif font. It is more stylistic than courier and has been designed with today's higher-resolution LCD displays in mind. It remains highly readable even on dark backgrounds, though the serifs are subtle enough to bleed out almost completely on black backgrounds. This is my favorite of the serif fonts.
  
  
       

Sans-Serif fonts:

These fonts lack the ticks at the edges and most people find them much more visually appealing. The drawback is that sans-serif characters can be less recognizable at smaller sizes. Sans-serif fonts do allow more flexibility in character shapes, which leads to more artistic styles. With today's higher resolution displays, sans serif fonts are increasingly common even for dense and small text cases where serif fonts used to dominate. Sans-serif fonts don't suffer as much from use on black backgrounds so long as the characters aren't over-stylized or too compressed.

• Consolas (Sans-Serif) - This is Microsoft's new favorite mono-space font, and is the default for VS 2010. It was designed specifically for LCDs and is further optimized for Microsoft's Cleartype font rendering technology. On dark backgrounds at smaller sizes though this font tends to flatten out awkwardly (in my opinion). On light backgrounds though, this is one of the best fonts ever invented. It scales very smoothly and is exceptionally pleasant at medium to large sizes. Though not a serif font, the character styles are very similar to serif fonts like courier new.
  
  
       
• DejaVu (Sans-Serif) - This is a variation of the Vera font family, and is very popular on linux systems. The general shape is similar to Consolas, but the characters are taller, a tad wider, and the style is a little more rounded. It doesn't flatten out like consolas at smaller sizes, and for this reason it has become my personal favorite on black or near-black backgrounds.
  
  
       
• Envy Code R (Sans-Serif) - This is a somewhat bizarre font with a wilder style. It uses thin lines and is somewhat compressed, but overall I'm not personally fond of it. It is a popular developer font though, and has decent readable even on dark backgrounds, but long-term readability does suffer at smaller sizes.
  
  
       
• Monaco (Sans-Serif) - This is a windows version of the popular font used in TextMate from the Apple universe. This is the largest of the fonts listed here. It also has a fancy stylistic look with unusual character shapes. While pleasant to look at, I find that it wastes too much space all around. It does render very well on dark backgrounds, mostly because of the exaggerated size of the characters. It is a solidly readable font once you get used to it.
  
  
       

The default font for the HumaneStudio theme is "Envy Code R". While this is a neat font, it is just too "stickish" for my tastes. I switched the default font to either AnonymousPro or DejaVu. I also removed all of the "bold" text effects from the theme's settings; the bold effect work well with Envy Code R, but not so much with my own preferred fonts.

I'm torn between AnonymousPro at 11pt and DejaVu at 10pt with this theme.

In VS 2008 AnonmousPro is my preference, but VS 2010 renders text differently. I'm finding that I am leaning more towards DejaVu in VS 2010. Another area that required some customization was the output and find windows. HumaneStudio's default settings uses a custom font called Palm OS. This is a terrible font! The color scheme for these windows is also a green-on-green "lime explosion" type thing. I like the stark contrast of these windows compared to the warm tones of the main editor window, but I had to change the background to black to make the output and find text comfortably readable at such extremely small sizes. For the font in these windows I stuck with AnonymousPro at 8pt.

Overall, HumaneStudio is probably the best theme I've ever used in a code editor. It was very easy to get used to, and it holds up amazingly well during long coding sessions without causing me any eye fatigue. This theme also has a lot more flexibility for customizations than most black based themes.

On VS 2010, the warm earth-tones in the editor window tends to contrast poorly with the default VS 2010 scheme for menus, borders, and the other non-text editor features. By default, these are based on a stark blue color theme, and these settings cannot be changed directly in the options menu. Fortunately there is an extension for VS 2010 that allows you to customize these non-editor colors. The extension's built-in "autumn" scheme seems to fits in with the Humane Studio editor theme perfectly.

I've put my own variants of the Humane Studio theme if you want to try them out yourself:

Redd's Variant HumaneStudio Theme for VS 2008

Redd's Variant HumaneStudio Theme for VS 2010

You'll want to get the AnonymousPro and DejaVu fonts and install them before you load the themes.

Visual Studio 2010 - Weak-Sauce Substitute for Dynamic Help

Microsoft has removed the dynamic help feature from the new version of visual studio. It is somewhat sad. I've been a big fan of dynamic help and will miss that feature.

I suspect that we'll see an extension that adds this functionality back, but until then...

There is this like really old mechanism that does nearly the same thing. Just highlight the member in the text editor and hit the F1 key. This will bring up MSDN help for the member you have selected.

It isn't as slick as dynamic help. Dynamic help was smart enough to scan for related topics and display them in a ranked list for you to pick from, where the F1 mechanism only goes to the most likely topic.

 There is a pretty decent discussion on the topic over at LeeDumond's blog that also includes information from a PM at Microsoft about it.

Updated Review of ReliableSite.net - One Year Later...

[UPDATE - 2/7/2011] I have terminated my relationship with ReliableSite.net. I cannot recommend this hosting provider to anyone anymore. Over the year since I wrote this post initially, their service quality has degraded drastically, and the technical support is abysmal.  

It has been well over a year now, so I thought I'd take a bit of time to revisit my old review of ReliableSite.net that I put up last year. This was prompted by a request I received from the original review asking me for my updated opinion.

So...would I recommend ReliableSite.net for your shared hosting needs today?

Depends on what you are doing with it...

Now... keep in mind that I have zero experience with their dedicated servers, virtual hosting, or cluster hosting. I am a shared hosting customer, and that is the extent of my experience with ReliableSite.net. I also only host a few small, low-traffic, personal sites with them.

For personal sites or low priority systems like mine then sure. Reliable has a great price tag, their speed is quite good, and the system is reasonably reliable as advertised. Everything that I wrote in my original review is still true and accurate.

But for serious business apps, commercial services, high-traffic sites, or anything that requires high up-time I couldn't in good conscious recommend them as a hosting provider. Not directly because they have failed to meet my own expectations, but just because there have been some issues over the last year that have eroded my confidence in their capabilities and the prospects for their long-term survivability.

What puts me off of giving them my full endorsement?

• No Visible Growth.
  
  ReliableSite.net doesn't appear to be evolving.
  
  Their site hasn't changed much. Their forums are a ghost-town. Their documentation and support KB hasn't added many new articles. I've not heard of a large influx of customers adopting them as a provider. There are no new "non-biased" third party reviews online that I can find. And there is no "buzz" about this company around the net.
  
  This company is going into their 4th year or more, so I'd expect to see soem serious traction from them by now.... but today they are in almost exactly the same spot they were in back when I signed up.
  
  The lack of customers talking on their forums especially troubles me. I'd expect to see all kinds of stuff on the forums, but instead there is almost nothing going on there. Either they don't have many customers, or the customers have nothing to say.
  
  Either way, it is not a confidence builder that this company will be around a year from now.
• Support
  
  I had a bizarre reoccurring problem. The problem itself wasn't something to worry about regarding their hosting capability. It was just that their backup script would sometimes trip up on my database backups. This caused the backup files to start growing very fast, and within a day or two each nightly backup would end up being like 1GB or more (for a database of about 5MB).
  
  The problem itself isn't too worrisome... I suspect it has to do with an automated process my site performs that messes with the backup script --Not really their fault as far as I can tell.
  
  But each time this happened, my file usage would exceed the 3GB limit of my account at which point their system would automatically shut down my account. This takes down the web sites and email access.
  
  This system would send a notification telling me I was over the space limit, but I'd never get that notification because the email server gets killed too.
  
  So I'd find out the hard way that stuff was down at which point I log in and delete the messed up backup files and contact support to ask them to restart my services again.
  
  And here is the problem... if my sites went down outside their regular business hours, I wouldn't hear back from support until after 9am the next business day. So when my site would go down on Friday at 1am; it was be Monday around 9:15 am or so before it was back online again.
  
  This happened 10 or more times during the first year until I finally turned off the backup script.
  
  Basically, the lack of response from support made it feel like the entire operation is run by just one guy that works a regular 8 hour a day job... And for all I know this may be true.
  
  It is quite possible with this kind of setup that ReliableSite.net could just be a one man operation.
  
  A couple of web servers in a web farm, a few database servers, and DotNetPanel to tie it all together is not beyond one good admin's ability to manage.
  
  The support replies were generally good though, and they seemed to know what they were talking about (unlike many providers I've had in the past where the support staff obviously had no idea how to even spell computer, much less how one works).
• Downtime
  
  Overall, the sites have been pretty reliable as advertised. But there have been some cases where my site wasn't available. At least 4 or 5 times that I know of the email server or the web servers were non-responsive. Since I don't actually use the site that often though, there could be many more occasions where it was offline that I didn't know about.
  
  These problems would always get fixed without me having to contact support... but not until after 9:00 am the next morning.
• Email
  
  Their email system is pretty decent, but I've noticed a significant jump in spam that gets through their filters these days. This suggests that they aren't keeping on top of the latest anti-spam measures.
  
  Overall, though it is also clear that email is not one of the services this company really wants to be heavily involved in. They provide some basic service, enough for personal use or to support the email requirements of your web application, but the options are rather limited.
  
  And as I mentioned, they don't expect their own email servers to be the host of your primary email address... otherwise they'd not turn it off when your account exceeds the allotted space limits and such.
  
  

So anyway, almost everything from my first review is still correct, but I'm not feeling as optimistic about the company overall. I had planned to move my own hosting over to DiscountASP.net this past year, but I decided to renew with ReliableSite.net one more year and see how it goes… moving all my stuff is a royal pain, and I had other things to do at the time.

I can recommend this hosting provider for small and personal sites, but considering how competitive the shared hosting landscape is these days, I'd recommend you put serious sites on one of the larger, more popular, and well established providers instead.