Aaronontheweb

I alluded to a change in my employment circumstances in my previous blog entry, and now that I'm an official Microsoft employee as of Monday I feel extremely comfortable making this information public.

My role is Developer Evangelist for the BizSpark program; Microsoft recruited me for this position after they read .NET Culture Shock: Why .NET Adoption Lags Among Startups and the rest, as they say, is history. I've relocated to the Santa Monica area and my immediate task is to work on increasing goodwill towards Microsoft and the .NET platform among the startups in southern California; it's a prospect that is exciting, daunting, challenging, and mind-blowingly awesome all at once.

If you're involved with startups in SoCal then I will make it my mission to meet you and find a way to help you should you require it. If there's anything I can do to help you, please feel free to contact me.

As for the blog - it's not going to change much :p . If anything, I'm going to have more content as a result and it'll be from a much higher altitude than it was before.

Wohoo!

If you enjoyed this post, remember to subscribe to my RSS feed!

General, Startup, Microsoft Microsoft, startups, Los Angeles

I showed up at BarCamp7 this morning and saw that absolutely no presentations were up on the board whatsoever, so me being me I spent most of the day putting together a presentation at the last minute.

I spoke for an hour about How to Design Applications People Love. I’ll add more to this post later after I decompress with some TV, but here’s my PowerPoint:

All in all, it turned out really well – I’ll try to update this post with some more detail tomorrow.

Update 7/13/2010

Ok, here’s the run-down of my talk:

1. We all begin with ideas for new applications or products, but in order to determine if it’s worth actually pursuing any given idea we have to determine who the product’s core user group actually is and whether or not they’d actually use it enough to merit its production.
2. We begin this determination using “the onion process,” a name I invented on Sunday morning, which elegantly formalizes the process I’ve been using for my latest group of projects.
3. During our execution of the onion process, we inevitably make a number of assumptions about our application / product’s users – therefore we have to map out those assumptions explicitly so we can systematically test them when we start our customer / user engagement process. I find that it’s best to use a mind map for this, but a simple outline can work too.
4. Once we have our assumptions outlined, we have to test them by interviewing potential users and determine if and where we are on/off-target.
5. Let the process of churning begin.

If you enjoyed this post, remember to subscribe to my RSS feed!

General BarCamp, application design, apps, startups

This time last weekend I was in the middle of the second session of Southern California Code Camp. Ever since I came to the realization that no man is an island and I’m going to ultimately need to work with other programmers in order to be successful in this business, I’ve made an effort to attend as many geeky networking events as I can.

Code Camp was a fantastic learning experience for someone who’s as interested in the .NET platform as I am. During Code Camp I was introduced to:

• Silverlight 4;
• Silverlight for Windows Mobile Phone 7;
• ASP.NET MVC2, which I used this past week to build The Great Wall of Geeks;
• .NET 4.0 multithreading (Parallel.For, Task engine etc…);
• .NET coding standards; and
• Agile Development and working with legacy code.

By far and away the best session for me was the Pair Programming / Agile Development Dojo, namely because I got my first taste for Agile development and the inherent value of rapid prototyping and test driven development was obvious.

More...

General .NET, Code Camp

One of my best friends from college once described a previous job in the financial industry as something akin to "giving guns to monkeys."

He felt that the product he sold, although it was something that could reap tremendous benefits for his customers if used properly, was something that more often than not harmed customers' livelihoods because the tool was too unwieldy and naunced for the average person to use correctly.

Like my friend in the financial industry, programmers are faced with a similar quandry - do we give our users enough rope to potentially hang themselves (more freedom) or do we provide a more authoritarian, constrained, "baby-proofed" experience (less freedom?)

All programmers are UX designers

Giving guns to monkeys and baby-proofing aren't about bugs or errors in the software. The concepts are both about making judgement calls in user experience design, and it's not just the UX gurus who have to worry about this sort of stuff - every programmer does.

Here's a technical example which illustrates my point:

I'm in the midst of creating an open source library for seamlessly parsing RSS/Atom feeds for legacy .NET 2.0-3.5 projects, where we don't have access to .NET 4.0's built in SyndicationFeed classes.

One of my test cases is the Hacker News RSS feed (http://news.ycombinator.com/rss), and when I tried to execute a basic HttpWebRequest against it, the method failed because apparently Hacker News' feed is not fully RFC-complaint and thus HttpWebRequest raises an error as a defense mechanism in order to prevent HTTP response split attacks from occurring.

Microsoft responded to a legitimate security problem with a binary solution - either you turn off unsafe header parsing and run the risk of a split response attack or you simply don't process data from sources with malformed headers. They baby-proofed it.

And what, pray tell, does Microsoft recommend for us developers who want to use HttpWebRequest to download feeds from sources like Hacker News?

"If you find a site that exposes this behavior [non-RFC-compliant HTTP headers], contact them and ask them to fix it."

At no point did this behavioral decision grace the desk of a UX person at Microsoft (that's my assumption at least,) nor should it have. It's a user experience issue, but it's one that affects other programmers trying to leverage Microsoft's .NET framework in their own projects. Therefore the user experience decisions are made by the very programmers who maintain this portion of the framework.

One can hardly fault Microsoft for erring on the side of caution when it comes to security; in fact, the decision to make HttpWebRequest throw an error when a potentially unsafe header is detected is probably the right call.

I suspect a lot of developers honestly don't care to download content from sources with non-compliant headers. However there are a number of developers who want the freedom to make calls to those sources, and since Microsoft made it somewhat difficult to disable this security mechanism there's now an enclave of programmers who all use the same configuration hack to reverse Microsoft's decision, which ultimately isn't something Microsoft wants either.

This decision is one where not enough freedom was given to end-users - one whitespace character in the Content Length (should be Content-Length) HTTP header shouldn't force .NET programmers to deny their own application/service's end-users the ability to consume RSS feeds like Hacker News.

So what do you think? How much freedom should be afforded to the people who use our libraries, APIs, applications, and services? Is it better to baby-proof or give guns to monkeys?

If you enjoyed this post, remember to subscribe to my RSS feed!

General Architecture, HttpWebRequest

I wanted to repost a presentation that I saw on Twitter yesterday which highlights some interesting trends in the state of open web APIs across the board:

Here are some cliff notes:

• SOAP is losing marketshare to REST or SOAP's share is simply being dilluted by the avalanche of new REST APIs - the charts don't make it clear;
• JSON is on the rise;
• OAuth is surging and is now adopted by 80+ services; and
• APIs are maturing in their practices.

If you enjoyed this post, remember to subscribe to my RSS feed!

General General, REST, APIs

Hi,

After a couple of happy years blogging my forays into social media, Facebook application development, online marketing, and so forth on AjaxNinja / Marketing Ninja, I took a year-long break from blogging between May, 2009 and May, 2010. Now that I'm back in the saddle with my copy of Visual Studio, a slew of startup ideas in the social media / online marketing space, and a hell of a lot of energy, I decided that it was time to get back into the habit of blogging.

As of writing this I'm still working for SmartDraw as a mutli-faceted online marketer, although I'd like to see one of my startup projects take a life of its own and blossom into what I do full time.

Here are the goals I have for this blog:

1. To publish short code samples which other .NET programmers may find useful in the course of developing their own applications which leverage social media / web 2.0 REST APIs.
2. To publish longer code examples, tools, and extensions to aid .NET developers.
3. To link up and network with like-minded developers who want to collaborate on projects, preferably in the San Diego area.
4. To build an online sounding board for ideas about software development in the social space.
5. To convince people, namely myself, that I know what I'm doing

If you enjoyed this post, remember to subscribe to my RSS feed!

General General, Blogging