My First Google Buzz App: Who gives a frak?

Subhead: My impression of Google Buzz/the Google Buzz "API."



As most are probably aware, Google Buzz recently launched, while with much less fanfare than the anti-climactic and rather disappointingly immature, but retaining potential, Google Wave, still plenty of hype, noise and clamor.

OK, Google Buzz itself is decent. Nothing super special, but it has potential. Aggregation can make my life easier in various projects. I'm not wowed by it, but, without having had anything in the way of expectations, I'm not disappointed, either.

Now, on the API side ... WHAT API!? There's really not a whole lot of programming to do against Google Buzz yet. Users can associate various accounts for aggregation from other well-known social media services, and Google Buzz provides some XFN markup for non-standard content or services to enable custom associations:

<link rel="me" type="text/html" href="http://www.google.com/profiles/your.username"/>

As far as I can tell, though I'll grant you my weekend was spent on the output side of Buzz and not so much the input, the only way to get content into Google Buzz right now is by an associated service or feed -- which can include your own RSS or ATOM feed, but you can't directly post an update to Google Buzz via API.

On the consumer side, you can pull a user's Buzz updates as ATOM using:

http://buzz.googleapis.com/feeds/{33-digit profile ID}/public/posted "ugly URL"

(You are supposed to be able to use your username, i.e. andrew.badera, instead of that 33-digit profile ID but apparently those so-called "friendly URLs" aren't pushing updates as properly or completely to the hub as the ugly URL-based subscriptions.)

You can subscribe to push notifications of a user's feed via pubsubhubbub.appspot.com. I didn't spend a ton of time digging, but in what time I did spend, I didn't find a .NET PubSubHubbub client subscriber or push notification callback handler floating around the internets. I've written a C# subscriber utility and an ASP.NET .ASHX handler for subscription verification and push callback receipt and handling which I'll be posting later today after hosting it somewhere like Google Code.

So far, Google Buzz and its API seem like Just Another Aggregator. Yes, the PubSubHubbub protocol is pretty freakin' cool, and, at least for now, seems highly responsive when it comes to subscription requests and push deliveries. I'm not yet sure however what's going to entice mainstream social network users to make the leap to Buzz. I'm compelled for business purposes, not personal, and social networking apps don't make the leap without personal engagement and enthusiasm.

Twitter engineering blog, Twitter Text library in C#

Dewald Pretorius came across and shared on the Twitter dev-talk list the recently created Twitter engineering blog. Interesting engineering stuff to be read there, and not necessarily Twitter-specific by any means.

One of the entries mentions Twitter Text libraries for Ruby and Java. These libraries allow external consumers to, in theory, parse tweet text for URLs, screenname mentions and hashtags the same way Twitter does.

I grabbed Matt Sanford's twitter-text-java and created a quick C# port, NTwitterText. It looks like one or two of the URL regex patterns need some tweaking, but otherwise all functionality ported over pretty easily and cleanly.

Job: Mid-level .NET Developer in Saratoga, NY

A friend has "a client in Saratoga that needs a solid mid – to senior level developer – must be .Net C# and SQL. 4-6 years of experience. This person needs to be independent and take ownership of one of the products."

Pay range is decent for upstate NY -- email me a...@b... for details.

I've become a believer

In LINQ. Well, at least in LINQ to SQL, and some of the neat LINQ-to projects like LINQ to flickr and those sorts.

I'm not quite so sure about LINQ to XML -- I still find myself using a lot of XPath, which I thought LINQ would let me get away from. Sure, LINQ to XML is nice for WRITING XML, but reading? I'm not sure it's a big win.

But let's get back to the subject at hand: LINQ to SQL. For quite some time, I felt that LINQ to SQL reduced developer knowledge of the data model below acceptable levels, provided a nearly unnecessary level of abstraction, and coddled the drag-and-drop Mort crowd.

Some of that may still be true, but when building a quick system like one project I've been working on the past three or four weeks and another the past five days, LINQ to SQL, in my mind, gives .NET the feel of something more dynamic like PHP or Ruby. This reduces development pain on short projects, mockups/prototypes or architectural spikes IMMENSELY. You can be much more agile in evolving your data model and business logic without paying the price of a brittle, static data tier. Yes, I found myself dragging-and-dropping tables, over and over again -- and I felt almost no shame in doing so.

According to Microsoft, LINQ takes measures against SQL injection -- one of the topmost reasons for using stored procedures. One of the other big reasons for SQL Server stored procs is performance of course. On small datasets, performance is adequate. I haven't had a chance to test on large datasets yet, or under scale conditions. There are steps you can take to improve performance I plan on exploring.

But of course you can still use stored procedures with LINQ, dragging-and-dropping again, and calling them like a standard .NET method via the wrapper LINQ and the Entity Framework create.

I'm not sure you lose anything with LINQ, and you certainly gain quite a bit in a number of scenarios. I suspect I will be using it quite frequently in the future.

This is a test. You can ignore it.

I recently started posting my blog to my corporate site. However, not every opinion I express is necessarily one of a relevant and/or business-like nature, so while widgetizing the ATOM 1.0 feed-consuming blog code, I decided to add tag-based filtering. Only blog posts I tag as "hes" should end up the company page.

So, here goes the first test. Will the widget behave?

Widget source will be published once testing is complete. Widget uses .NET 3.5, ServiceModel.Syndication namespace. Highly configurable, with caching options (particularly handy when your site is subject to security scanning tools, which can cause feed providers like FeedBurner to label repeated feed requests as malware or bot. Thanks, Nanny Google.)

Widget can be deployed in multiple independent instances throughout site, so you could use a single blog with a number of different tags to publish area-specific content across your site by associating tags with those areas. Kind of a weak CMS (content or knowledge management system) taxonomy. Could possibly use it to auto-associate related blog posts as well.

UPDATE: It appears as though the tag-based filtering is working appropriately :)

Followup: Cryptographic key management

So after some wrangling with my webhost, playing with key containers, and chatting with an MS sort over on forums.asp.net, I've come to the conclusion that machine-level key stores are the proper way to store crypto keys on the server -- never use plaintext files, as I'd originally been considering.

The ASPNET and/or Network Service context should have access to store and retrieve keys from the machine-level store. You can insert them programmatically, or most host support staffers should be able to import them as well.

RSA Cryptography Demo

RSA Cryptography Demo

I've written a simple demo application in .NET 2.0/3.0/3.5 (C#) showing how to generate and manage keys and encrypt/decrypt data using the RSA asymmetric algorithm.