My Last Day at Microsoft

by

This day has been a long time coming, but it’s finally time for me to move on to my next big adventure. Today is my last day at Microsoft.

BadgetsFirst off, I would like to thank Microsoft. There were lots of ups and lots of downs and I’ve never had so many of both at any single place of employment before, but without this company that I now call my former employer, I would not be where I am today both personally and professionally. I’ve met so many great people, learned how to build and manage software (as well as how NOT to build/manage software :)) and my wife and I had two wonderful children during my time at Microsoft, but how did I get here (skip the next paragraph if you’re not into hearing about how I started in programming and leading up to Microsoft)?

I remember in high school taking my first programming classes in Turbo Pascal 7.0 for DOS, then Visual Basic 4 and how it finally felt like I found what I wanted to do. I had always been a creator, but never truly found something that made me feel like I could turn an idea into something useful for others until computer programming showed me how to turn those 1’s and 0’s into a piece of software. Seeing how Microsoft was at the center of all this, I knew someday I needed to work for them. In college I had a great time learning lots of mostly useless information, then getting a job working on the university’s web site. The following few semesters were filled with sleepless nights in my dorm room learning how to manipulate the DOM with JavaScript in Netscape. Once IE 4 came out and I learned about XML HTTP Requests, it was all over for me. Within a semester, I dropped out (before I flunked out ;)). This web programming stuff was just too much fun! I took a bit of a break from programming full time and worked in the CAD department at my family’s boat company in my hometown. While that was a lot of fun, I got the programming bug again (pun sort of intended?!?!) and moved upstairs to the IT department where I (and others) built everything for the company at the time from VB6/Flash based sales and financing software (eventually moving to VB.NET/WinForms) to internet and intranet sites using (Classic) ASP (eventually moving to ASP.NET 1.0). While getting to build some cool stuff with Microsoft products, in the back of my mind, I was still thinking I needed to get out there working for Microsoft. I became a Microsoft MVP at this time (for the next 4 years as well), which helped get me more connected to the folks out in Redmond. I also got to see Seattle and the Microsoft campus. Instantly, I knew I could live out here. Somewhere in this story I wrote some articles and co-authored a book and landed my first (of 3!) interviews at Microsoft for the now defunct WinFS (you know, that thing Bill Gates just talked about on his Reddit AMA) team for a Programmer Writer job. I didn’t get it, though reviews of me were generally positive. I decided to leave my family’s company (despite MUCH discouragement) and start consulting on my own. 9 months later, I was drop dead broke and my girlfriend (now wife) had to pay some of my bills to survive. Needless to say, I was too young and dumb and inexperienced at the time to build up my own company. Many lessons learned. Somewhere in there, I got another interview at Microsoft. This time for an SDET position on the Visual Studio team. I didn’t get the job this time either. My results were about the same. Good for Microsoft, not good for this role. Onward! I got a job for a local company doing some cool stuff called Aptera. I was employee #2 (or #4 if you count the two co-founders) in a little office building software for local businesses. I learned a lot about working with people there. I also got married to my beautiful wife then! 🙂 Ultimately, I still had the itch to work at Microsoft and my new wife is an opera singer and there are lots of opportunities in the Seattle area to sing opera professionally. So this time I heard about a cool opportunity (through a past co-worker…at nearly all of my past jobs :P) to work on the Channel 9 website at Microsoft. At the time, it was the hip and cool new thing at Microsoft and I couldn’t pass that up. I flew out and interviewed and got the job!

I began my first day at Microsoft on November 14th, 2005. Here’s a fun blog post from my first day. While you can’t see the image anymore, it’s of me wearing my consulting t-shirt (black) that says “I don’t work here” (funny, right?). I had taken a black marker to the “n’t” on the shirt so it now said “I do work here”. 😉 At the time, Bill Gates still worked at Microsoft (and hadn’t even announced his 2 year plan to leave, though that came within my first year if I remember correctly) and the Xbox 360 hadn’t been released yet. It seems like a life-time ago! I worked as a developer on the Channel 9 team for 4 years and eventually moved to the ASP.NET team where I’ve been for the last 3 or so years (as a Program Manager for almost 3 years). Here are a few highlights from my time at Microsoft…

Worked on the following while on the Channel 9 team:

Channels

  • MicrosoftGadgets.com -> Gadgets.Live.com -> Died (What’s a Gadget again 😛 Windows Vista say what? )
  • Channel 10 (new platform and site for tech enthusiasts…merged into Channel 9 later)
  • Channel 8 (built on new Channel 10 platform and site for students…also merged into Channel 9 later)
  • Wrote ThinkWeek paper with Tobin Titus and Ernie Booth, Bill Gates raves about it, tells us to go get patents, we do, then we try to get funding and fail miserably
  • Another complete rewrite of Channel 9 (yah, I said ANOTHER…and I’m sure there will be many more)
  • VisitMix.com (extract and build up new CMS called Oxite in spare time with Nathan [more later about him])

Worked on the following on the ASP.NET team:

  • Orchard (helped early on, but moved on after about 6 months to be a PM)
  • ASP.NET Web Pages and Razor (PM’d from early pre-Alpha on for v1, then v2)
  • ASP.NET (all frameworks) Templates in Visual Studio 2012
  • ASP.NET MVC (for a bit less than a year)
  • Other small projects like Universal Providers, a new membership system yet to be released as well as helped start some other things you won’t see ship for a while

Along the way I met lots of great people who I enjoyed working with and will continue to be friends with (and work with) in the future. One in particular that stuck since the latter part of my time on the Channel 9 team was Nathan Heskew. Nathan and I have worked together on side projects at Microsoft since the first few weeks we worked together when he joined the Channel 9 team way back when. We built Oxite together, both worked on the Orchard team for a bit and over 2 years ago started working on Rowi, which is our Twitter app for Windows Phone and Windows 8. We built Rowi for a few reasons. First, we were not happy with any of the Twitter apps that were available in the early days of Windows Phone (there were only a few at the time) and thought that Twitter apps had to be simple and a total piece of cake weekend project, right? RIGHT?!?! Hint: They’re actually a TON of work just like all other good apps out there. Second, we knew that we eventually wanted to build our own company and thought (what became) Rowi would be a good test of that with two simple criteria. Could we build something that people actually enjoyed using and could we do it without losing money? We probably should’ve also included “and still get some sleep since we both have wives and small children at home”, but live and learn (and someday sleep…someday). Now that Rowi is on two different platforms and is the best rated and most popular Twitter app on Windows Phone (other than the more downloaded and much lower rated official Twitter app), we’d rate it as a success for us. While Rowi hasn’t been a big money maker for us, it has been a great experience and we’ve now taken our reputation with this app and used it to find other work, which leads me to…

Rowi StickersWhat’s next? Hidden Pineapple, of course! Don’t mind the crappy little website that’s up there right now. We’re nearing completion of a brand new sexy website! 🙂 I will be the first member of Hidden Pineapple to work on our projects full time. It will be great to get back into development full time, but also great to be able to decide what projects to work on, manage those projects end to end and write them. Here in the beginning, you will find us working on projects for both big companies you know and small companies you might not have ever heard of. Everything from mobile apps and websites to back-end services in the cloud. You will also see us continue work on Rowi as well as some new original products and services of our own. I’m very excited where this is going and will be sharing my personal experiences from running a business, to writing code and working with the community. So, stick around for more!

To keep up with us, be sure to follow @thehp and our new website once it comes online. You can follow me @HumanCompiler and @Heskew for Nathan. If you’re interested in Twitter apps on Windows Phone and/or Windows 8, follow Rowi on Twitter and/or like us on Facebook.

Have any questions? Does your company need a cool app made on Windows Phone or Windows 8 or a web application or service in the cloud? Or maybe all of the above working seamlessly together?!?! Contact me at erik at hidden pine apple dot com for pricing and availability.

-Erik

P.S. Microsoft decided to celebrate me leaving Microsoft by shipping the latest release of ASP.NET Tooling/Templates the same day as my last day! Ok, it’s just a coincidence, but a fun one. 🙂 Do check it out! Great stuff and some of it was some of the last projects I worked on at Microsoft.

P.P.S. For all of you Windows Phone developers out there that have been missing HttpClient from Windows Phone 8, fear not. Microsoft is releasing (ALSO TODAY, my last day) an updated NuGet package with a new Portable HttpClient that will work on Windows Phone. Hooray! 😀

ASP.NET Web Pages Templates for VB

by

Today, (well…yesterday, but I didn’t have time to blog about it yesterday) our team added the Visual Basic versions of the templates you can get inside of WebMatrix for ASP.NET Web Pages.  These are available as NuGet packages on the NuGet Gallery site.

Along with the above 4 templates we’ve also shipped the original 4 C# templates that are included in WebMatrix as packages for those of you who might use ASP.NET Web Pages without WebMatrix.

In this release, we’ve also included a new template that doesn’t ship (yet) in WebMatrix.

To run these templates, simply open an existing or create a new ASP.NET Web Pages app and navigate to (or click the “ASP.NET Web Pages Administration” link on your dashboard in WebMatrix), login to the admin, search for “template”, pick which package you want and install it.  This will put the contents of the template into a folder called “Microsoft Templates” in your app root.  Inside will be instructions to tell you to take the contents of that folder and move them to the root of your site.  This step is unfortunate, but required since NuGet or the ASP.NET Web Pages Administration app doesn’t currently allow you to override existing files.  Now run your site and you should see the template you installed.

Jim Wang, who works on our team (and built the WishList Template), made a video on how to get WishList installed in less than a minute.

We hope these are helpful to get you started with ASP.NET Web Pages!  For those of you working with VB, we want to hear from you.  Are these templates helpful?  Anyone running ASP.NET Web Pages WITHOUT WebMatrix (or Visual Studio)?

IE 9 Windows Jump List ASP.NET Web Pages Helper

by

I’m sure you’ve all heard today about the beta release of IE 9.  It’s looking pretty good!  Did you see that you can integrate with the Windows Jump List now?  Neato!  Neowin has a write up on the meta tags you need to have to integrate with Windows.  Over lunch I wrote a quick helper in ASP.NET Web Pages (install WebMatrix via WebPI here) that you can just drop into your App_Code folder…

Code Snippet
using System;
using System.Web;
using System.Web.Mvc;
using Microsoft.WebPages.Helpers;

public static class Windows {
    public static IHtmlString JumpListTask(string name, string actionUrl, string iconUrl) {
        HttpContext httpContext = HttpContext.Current;
        
        if (httpContext.Request.Browser.Browser == "IE" && httpContext.Request.Browser.Version.StartsWith("9")) {
            if (string.IsNullOrWhiteSpace(name)) {
                throw new ArgumentNullException("name");
            }
            if (string.IsNullOrWhiteSpace(actionUrl)) {
                throw new ArgumentNullException("actionUrl");
            }

            if (string.IsNullOrWhiteSpace(iconUrl)) {
                throw new ArgumentNullException("iconUrl");
            }

            if (!(actionUrl.StartsWith("http://") || actionUrl.StartsWith("https://"))) {
                string hostUrl = httpContext.Request.Url.GetComponents(UriComponents.SchemeAndServer, UriFormat.Unescaped);
                actionUrl = hostUrl + VirtualPathUtility.ToAbsolute(actionUrl);
            }

            TagBuilder html = new TagBuilder("meta");
            html.MergeAttribute("name", "msapplication-task");
            html.MergeAttribute("content", string.Format("name={0}; action-uri={1}; icon-uri={2}", name, actionUrl, iconUrl));

            return new HtmlString(html.ToString(TagRenderMode.SelfClosing));
        }
        return new HtmlString("");
    }
}

And then call it in your page…

<!DOCTYPE html>
<html>
    <head>
        <title></title>
        @Windows.JumpListTask("Test", "~/", "fav.ico")
    </head>
    <body>
    </body>
</html>

Not much to it, but hopefully some of you will find it handy.  Note: it does not render anything in browsers other than IE 9.  Maybe we can clean this up and put it in the next release of ASP.NET Web Pages.  :)  What do you think?  Do you have other ideas for helpers in ASP.NET Web Pages?

Writing Helpers in ASP.NET Web Pages (Beta)

by

I’ve been seeing some people asking about how to write their own helpers in ASP.NET Web Pages.  If you’re not familiar with ASP.NET Web Pages or Razor be sure to check out Scott Guthrie’s post announcing them.  I’m the PM for them.  :)  You can use WebMatrix (or Notepad or any text editor of your choice) to build web apps using ASP.NET Web Pages.

First, let me overview how writing your own helper will be in the next version of ASP.NET Web Pages, then I’ll go over how you would go about writing them as of when this blog post went up.

Future @helper Usage (not in Beta)

In the next release of ASP.NET Web Pages you will be able to use our new @helper syntax to easily build new helpers.  The main scenario we’re trying to cover with this is simple.  Say you have a page with a little code/markup that you would like to reuse on other pages.

<!DOCTYPE html>
<html>
  <head>
       <title>Gravatar</title>
   </head>
   <body>
       <img src="@Gravatar.GetUrl("someone@somewhere.com")" alt="Gravatar" />
   </body>
</html>

In the next version you will be able to simply do the following:

  • Create a new file under App_Code in your app named Utilities.cshtml (this can be named anything)
  • Cut the code/markup you’d like to reuse and place it into a method in the new file and replace any hard-coded values with any incoming parameters you have in your method.
  • Call the new helper by the name of the file (Utilities in this example) and the name of the method

Here is what the Utilities.cshtml file would look like:

@helper GetGravatarImage(string email) {
   <img src="@Gravatar.GetUrl(email)" alt="Gravatar" />
}

And here is what the original page would now look like using the new helper:

<!DOCTYPE html>
<html>
  <head>
       <title>Gravatar</title>
   </head>
   <body>
       @Utilities.GetGravatarImage("someone@somewhere.com")
   </body>
</html>

Pretty straightforward and simple. Unfortunately, we’re still working on this feature.  It will be in the next release.

Writing a Helper Today in Beta

For the time being you can convert your code/markup into a static class, which is how we currently build helpers internally.  Here is an example:

using System.Web;
using Microsoft.WebPages.Helpers;

public static class Utilities {
    public static IHtmlString GetGravatarImage(string email) {
        return new HtmlString("<img src=\"" + @Gravatar.GetUrl(email) + "\" alt=\"Gravatar\" />");
    }
}

The most important thing to note here is that your method should return IHtmlString for things to get rendered properly.  How you build it internally doesn’t really matter.  In my simple example I just build a string and then wrap it up into a new instance of HtmlString (which is an implementation of HtmlString).  One other thing to note here is that I’m importing the Microsoft.WebPages.Helpers namespace because that’s where the Gravatar helper that I’m using exists.

One other important thing to note is that while I’m building a string here because it’s such a simple solution, the better/safer way to do this is to build it using the TagBuilder, which is in MVC (and available in the Beta).

The usage for this helper would be exactly the same as the new way stated above:

<!DOCTYPE html>
<html>
  <head>
       <title>Gravatar</title>
   </head>
   <body>
       @Utilities.GetGravatarImage("someone@somewhere.com")
   </body>
</html>

So it’s still pretty easy to build your own, but unfortunately today you have to start learning some OOP concepts, which goes against our goal of simplicity and staying relatively procedural.  Can you see why we’re working on a newer syntax to help simplify this?  🙂

Summary

Writing helpers isn’t too difficult but can be a lot of work if you’re trying to compartmentalize a lot of code/markup and requires you to understand more advanced concepts.  In the next release of ASP.NET Web Pages you will be able to simply cut and paste your code/markup that you want to reuse into a new file and use it.

Do you like the new syntax?  What sorts of helpers are you building?

Same Team, New Role at Microsoft

by

Today is my first day as a PM (Program Manager) on the ASP.NET team.  If you’ve been following any of the projects I’ve worked on at Microsoft like Oxite or Orchard, you may remember that I just joined the Orchard team as an SDE in November.  Why the fast move?  I’ve actually been interested in switching to the PM role for a couple years now, and the right opportunity happened to come up last week.  The fun part is, I’m still on the ASP.NET team, just in a completely different role.  It happened pretty fast.  On my birthday (April 9th) I started talking with the team about an open position.  Thursday of the next week they told me the job was mine.  On Friday, I was told “you start Monday”.  I am very excited to get started and ‘thrown into the fire’.  I can’t say what exactly I’ll be working on just yet, but it will be fun, no doubt.

Does this mean I’m done with Orchard?  Absolutely not.  I love open source software at Microsoft and I think Orchard is a great project.  I will continue to give feedback and contribute in any way I can and have time for.

I expect to finally get back to more blogging too.  Since joining Microsoft as a developer the amount I’ve blogged has steadily declined into nothingness.  Now that blogging will be one way to gather community feedback, it will definitely happen more often.

My wife and I are expecting a baby girl in June (our second child).  The life changes just keep coming!  Exciting times.  🙂

Planning for the Next Oxite Release

by

As many of you have been pointing out, it’s been a long time since the last Oxite release.  To be exact, it’s been 4 months today.  :|  For a piece of software, that isn’t much time at all.  For a web application, that can be pretty big.  We’re usually fast movers, but we made a decision a while back that we want to “go Beta” for the next release.  This means that the next release should be at least halfway comparable to the feature set of other blog engines out there and that non-developers should be able to run Oxite without much work.  Here are the 3 high level goals for the next release of Oxite:

  1. Improve the admin (add missing features and improve the user experience)
  2. Build a great plug-in model (works well for non-devs and devs alike to build small new features on top of Oxite)
  3. Make installation easier (include Oxite in the Web App Gallery)

With those goals in mind, here’s what we’re working on and how far along we are with each so you can get an idea how much more we have to go…

Required to ship

The following are items we will not ship without and how far along we are in their development.

Plug-in Model – 90%

There’s really too much to talk about with plug-ins here, but the gist of it is that anyone can use their favorite text editor to write a few lines of code, FTP up the file to their web server and run.  You can also use Oxite to edit the code file if your hoster will let you edit files through ASP.NET.  We will be including a few plug-ins out of the box so you can see how to build them and we’ll also have documentation when we ship (you can see the work in progress docs here).  We have already demo’d plug-ins internally to a few teams and so far the response has been great.  We’re just in the process of finishing up a couple things and fixing last minute bugs.

Spam Filtering – 95%

We built a plug-in that will be included in the next release that calls out to a spam filtering service (like Akismet or TypePad AntiSpam) when new comments are added and verifies whether or not they are spam and removes any comments that are spam.

Site Setup Wizard – 15%

This feature has been designed and we’ve gone over the design with one of our new contributors who is going to handle the implementation.  We want to make setting up a new Oxite instance as simple as possible so walking through the wizard, you will be asked as little as possible to get Oxite running.  Afterwards, you can tweak Oxite’s settings to make it work the way you want it to.

User/Blog Management – 50%

We already have pages for adding, editing and removing users and blogs, however, we’re been doing a major overhaul to the admin area and we don’t expect these to be working at the moment.  As we overhaul the admin UX we are going to make some changes to the flow of these pages anyway.

Authorization Management – 50%

We have a permission API in place already for the new release, but we don’t have any UI in the admin for it yet.  Permissions are done by associating 3 things together: User, Role and Entity.  To make a person an owner of a blog to do whatever they want with it, you would associate the user with the admin role to a particular blog.

MetaWeblog API Improvements – 85%

In the new release, we’ve moved the MetaWeblog implementation from WCF to using MVC controller actions.  This makes future work simpler to implement and errors easier to bubble up.  This work is complete, but not fully test.  We will also be adding file support so you don’t have to use FTP for blog post images anymore.

Rich Text Editor – Complete (sort of)

So far, we’ve been unable to find a rich text editor that is compatible with the license of Oxite (Ms-PL) and built on jQuery.  In the meantime, we’ve implemented markItUp!  This will allow you to do simple formatting that most people will need.  In the near future, we will also be demonstrating how you can write your own plug-in to use your favorite rich text editor instead.

Contact Page – 0%

This is sort of a no brainer that we’ve somehow overlooked in past versions of Oxite.  All blogs have a contact page.  Oxite will join those ranks in the new version.  You know, the standard “enter your name and email and a message and I’ll send it to the site/blog owner” type of page.

Scale – 75%

Dumb caching has been implemented at the service level of Oxite.  What this means is that the results of calls to the repositories are now cached after the first time they’re called.  We invalidate cache by entity or entity type or sliding expiration.  The current cache service is implemented using ASP.NET Web Cache.  In the future, we will more than likely implement a Velocity cache service too for those who choose to use Velocity.  We will also probably make the caching a bit more smart and cache entities and query results instead of just straight query results.

Random Bugs and Admin UX Enhancements – 40%

We have a gazillion bugs we’ve fixed since the last release and are continuing to fix bugs (be sure to start a discussion on CodePlex and report them when you find them).  In this bucket, I am also including all of the admin work we’re doing.  We’ve added some cool things like dialogs (that work both service side and client side so they’ll work on phones and modern browsers alike), lots of new management pages, new UX around adding and editing posts and pages, etc.  The list goes on and on, but you’ll have to wait and see exactly what features get in the next release.

More Cleanup – 95%

We’ve done some more cleanup in this version of Oxite:

  • Database – Some tables have been cleaned up and reorganized to make the schema better match the data we store.
  • Model – All of our model classes immutable so objects can never be in an incorrect state.
  • Services – All add/edit/remove services have been modified to return generic result instances that include validation/model results to help keep validation in a single place.
  • Controllers – All controller action parameters have been converted to ENTITYInput or ENTITYAddress classes with ModelBinders to map the values appropriately, all validation has been pushed into the services and we now return ViewModels directly and have filters that convert them into the appropriate ViewResults.
  • Views – Many views have been cleaned up and separated better.  The admin is now completely separate from the rest of the site and now renders HTML 5 instead of XHTML. Skinning the site is now simpler since the admin is not included in skinning anymore.

Optional to ship

The following are items we would like to make time for, but if they take too long, we will ship the next release without them and put them in the next release.  These are ordered by priority.

Modules – 10%

We have a lot of the infrastructure in place, but have yet to fully design how modules will work in Oxite.  Basically, we want to break Oxite up into pieces (like IIS 7) so it’s easy to replace and build your own major chunks of Oxite.  Modules will be similar to plug-ins, but much more powerful and for those who are very familiar with .NET.  If you want to build forums on top of Oxite, a module would help you accomplish that.  Modules will be how you can get into the Oxite/MVC pipeline.  We’re really set on getting this int
o this release of Oxite, but if it ends up taking too long, we will cut it for this release.

Blog Management – 60%

While Oxite does support having more than one blog running in it, we haven’t yet optimized it when you go from one to two blogs.  To do this, there’s quite a bit of work involved like getting the dashboard to be aware of all blogs a user has access to, the menu needs to change in the admin, plug-ins need to have a way for site admins to specify which plug-ins are allowed to run and then blog owners need to be able to set their own settings on each plug-in that’s installed, etc.  This work is high priority on the optional list, but if it doesn’t make it in, it will in the next version.

Skin Engine Enhancements – 0%

While skinning is pretty great in Oxite, we have some ideas on how to improve it further to make scenarios like building an iPhone skin or optimizing Oxite for MSNBot or Google to index your site or making your site work in IE 6 even easier and better organized than it is today.  We will more than likely not get to this one for this version.

Threaded Commenting – 75%

Before we went off and implemented plug-ins we started down the path of adding threaded commenting so it’s easier to understand who is replying to who.  We got the server side implementation done, but not the client side implementation and it still needs to be properly tested.  Hopefully this one will make it in this release, but not making any promises.

AJAX Enhancements – 25%

We’ve done some work in the admin to make things work well client side, but still have some more we’d like to do as well as getting paging and commenting to work client side.  Nice to have, but not needed to ship.

Authorization Provider Model – 0%

Our authorization in Oxite is mostly separated out into its own thing, but there is still work to be done to enable anyone to build a module for their own authentication scheme (like OpenID, Live ID, Facebook Connect, etc).  This is another nice to have, but if it doesn’t make it in this version, it will be very high priority for the next version.

Exception Logging – 0%

This will make it much easier to debug problems when they come up for people, but is a nice to have and will not hold up shipping the next version if we don’t have time.

Unit Tests – 25%

For the most part, the Oxite team isn’t a TDD bunch, but we do see the importance of unit testing and will try to get more tests in there.

Post ship

After we ship the next release to CodePlex, we will be nearly immediately submitting Oxite to the Web App Gallery.  This will make it so those who want to just use Oxite and not go through the code can get Oxite up and running can get Oxite in a few clicks with the Web Platform Installer.  This is exciting stuff and will get Oxite out there much more than it is today.

Future

Even though we haven’t even started any development for these, I believe it’s important to understand where we’re going so we build the right things in the right priority.  These are items we’re beginning to plan, but would definitely love to hear feedback and eventually get help coding.

Oxite.net

This currently redirects to http://visitmix.com/lab/oxite (our home base).  http://oxite.codeplex.com is the other place most people go to.  As we grow and need more features it will more than likely make sense to move the project to our own domain (oxite.net) and consolidate it all to one place (other than the source code).  Luckily, this will just be a DNS change since we already point to that domain for all our stuff.  This is not set in stone yet, but is our current intent.  We want oxite.net to be the page everybody goes to for information about features, documentation on how Oxite works, galleries for skins and plug-ins, etc.

Forums

This one comes up often and we think it’s a good idea.  Once Oxite modules are done, this becomes easier, but forums usually have a lot of features that blogs don’t (even though it’s still the same idea…post and then comment on the post).

Social

We don’t have user profile pages at all yet, nor anything like being able to add friends, etc.  That’s ok for now because there isn’t much of a reason for anybody to register on an Oxite site yet.  Anonymous users can comment and do just about anything an authenticated user could.  In the future we’d like there to be profiles and friends and some modules I can’t talk about yet.  🙂

 

None of this really even hints at a date for the next release.  That’s because we really never know when we’re going to work on Oxite.  Seems to be random as we have time.  We’re building momentum with Oxite.  In the last few weeks we’ve added more contributors to Oxite (5 to be exact and we have 2 more joining soon).  Some work for Microsoft, some don’t.  We need your help to continue building a great platform.  Go build something cool with Oxite and show it off.  We’re listening closely for individuals who know what they’re doing, build the right things and are very interested in our “little” project.  Show us your code!  🙂

So how do you think the next Oxite release is shaping up?  Useful?  Awesome?  Horrible?  Am I forgetting any other major features?  What will you build on top of Oxite?  Does it seem like something you’ll want to use?

Oxite Plugin Extensibility Points Discussion

by

Lately, I’ve been integrating some code built by another team at Microsoft, who will for now remain unidentified until they’re ready to make themselves known.  It’s a pretty cool plugins architecture that makes it super simple to build plugins.  It’s not fully baked yet so I’ve been filling in some pieces as I go, but the concepts are solid.  I’m still in the process of refactoring some things, but if you’d like to follow along at home, feel free to grab the latest checkin.  I make no promises that everything works perfectly and the UI for installing/uninstalling/editing plugins isn’t done yet.  You can actually run plugins with the latest code though.

Today, I got our team together to brainstorm about plugins in Oxite.  I thought it might be handy to talk about some of the plugins we’d like to build, as well as some of the more popular plugins that have already been built for other blog engines.  We came up with a nice little list of some initial extensibility points we could have in Oxite.  Since I like to be pretty transparent with what we’re doing with Oxite (follow @HumanCompiler to keep up on Oxite) I tweeted about it:

HumanCompiler Just sat down and laid out all the extensibility points Oxite will expose to plugin developers in the near future. Exciting!

Javier tweeted back pretty quickly:

jglozano @HumanCompiler sounds awesome! Would love to hear about it!

That’s a great idea, Javier!  Even better, I’ll share the list we’ve come up with so far AND get the community involved.  I’d like to get your feedback!  So here’s the list we have so far:

Events

These provide a way for plugins to be notified when something happens.  One might write a plugin so when a new comment is added to a blog post, it sends a txt msg to the post author (using the CommentAdded event).  Another example might be a plugin displays a “How to Use Your New Blog” page to a user who just signed up for a blog on your site (using the AreaAdded event).

  • AreaAdded
  • AreaEdited
  • AreaRemoved
  • PostAdded
  • PostEdited
  • PostRemoved
  • PostPublished
  • PostUnpublished
  • PostViewed
  • CommentAdded
  • CommentApproved
  • CommentRemoved
  • CommentSpamCheck
  • PageAdded
  • PageEdited
  • PageRemoved
  • PagePublished
  • PageUnpublished
  • TrackbackReceived
  • PingbackReceived
  • UserLoggedIn
  • UserLoggedOut
  • UserSearched

Processing Methods

I wasn’t sure what to call these actually.  WordPress calls them Filters, but that didn’t seem totally appropriate.  I’m open to names if you have any.  Basically, these are methods that plugins can hook into to do processing on an Oxite entity like a Post, Comment, User, etc.  One example might be a plugin that takes code blocks in all post bodies and properly formats them before being rendered by the view.  Maybe a plugin that applies a time of day mod to the currently selected skin.

  • ProcessPostInput
  • ProcessPostDisplay
  • ProcessCommentInput
  • ProcessCommentDisplay
  • ProcessNewTag
  • ProcessMarkup
  • SelectSkin

So what do you think?  Is this list a good start?  Are any of these completely pointless?  What others would you use in writing your own plugins?  Is the naming easy to understand?  What plugins would you develop if the sky was the limit?  Share your thoughts.  We’re listening.  🙂

Oxite.2009.2.15 Released

by

We’ve been hard at work over the last month working to refactor Oxite.  We received a lot of community feedback about how we organized the code in Oxite.  I don’t want to go into too much detail, but want to be completely transparent (I’m from the Channel 9 team, would you expect anything less?) about how Oxite came to be.  Oxite was a side project by a couple of us that just thought it would be cool to release some of our code that was reusable, showed off the ability to control your markup 100% and was more than a sample (something people could actually ship on if they wanted to).  It obviously got expanded into more than that, but just wanted to share a little behind the “how, when, who and why” of Oxite.  For a more in-depth explanation, check out Duncan’s post.

Back to the community feedback, although some of it was taken a bit too far, overall the community was right and we decided it was necessary to begin a large refactor to get our code more inline with ASP.NET MVC.  Sampy has a post (Part 1 and Part 2) about the architectural changes we’ve made in this release of Oxite.  You should check out.  He also started an Oxite Architecture page on CodePlex.  I don’t think there’s a single line in Oxite that hasn’t been touched.  As with all projects, we will continue to evolve it moving forward.  We’ve discovered a few places where our current architecture has a few things that don’t work out perfectly.  In the next release we will address some of this, but they will be much smaller changes than in this release.

What We Refactored

Besides "everything", well, we added dependency injection (much needed).  We already had things like our Controllers setup for this, we just hadn’t taken the final step to add it.  Now that we are using it in lots of places, and things are much simpler and easier to setup now.  We get the added benefit of being able to replace anything that is loaded through DI with a web.config (or code) change.  You can replace everything from our Routes to Controllers to ActionFilters to Repositories.  Be sure to read Sampy’s post.  He has a section on DI.

The model has also been cleaned up to make more sense.  Before, we were using interfaces for everything to get around LINQ to SQL building it’s own concrete types, but this was problematic.  Now we just have our own concrete types.  Unfortunately, because we can’t easily manipulate LINQ to SQL with different query options before the statement is executed and still get our types back, we have to project them to our types.  A little painful, but not too bad.

Another big complaint we addressed was that our Controller Actions were being used like the Page Load method in WebForms.  We were brand new to MVC when we started Oxite and it was an honest mistake that I think those new to MVC will make.  With the model and repositories cleaned up it and the addition of ActionFilters, we were able to get almost all of our Controller Actions shrunk down so they follow SRP.

We’ve also added quite a few ActionFilters that help us build up the ViewModel and fill things out for the Controller Actions for us.  These are where all our code to do additional things on the page have gone like filling in the sidebar data.  We also created an ActionFilter registry class that Sampy will probably explain more soon, for specifying when ActionFilters are executed.

The last major thing I can think of that we cleaned up were the Views.  To be clear, what the Views produced was always very clean.  What I mean is we cleaned up the code and markup in the Views to use more HtmlHelpers when appropriate.  At the same time we also split more views apart and rearranged where they live to make more sense and to ensure we don’t have repeated markup/code anywhere.  This helps make skinning easier.

With all this refactoring, we still managed to stabilize current features, add new features and simplify deployment.  The refactor was our only goal for this release, but some of us really care what features Oxite has and want to improve on it with every release.  Lot’s of late nights, but well worth it.  Now that we’re all also running Oxite as our blogs we will continue to find/fix bugs and add new features.  Let’s go over old and new features.

Oxite Features

So we’ve got all the basics you’d expect in a blog:

  • Posts
  • Commenting
  • Tagging
  • Content pages
  • RSS and ATOM feeds everywhere (All up, Blog, Tag, Comment, etc)
  • Trackbacks (sending/receiving) and Pingbacks (receiving)
  • Email subscriptions
  • Sitemaps
  • Search
  • Metaweblog API support (use Windows Live Writer, etc to post to Oxite)
  • Web admin
    • All up dashboard
    • Manage site
    • Manage areas (blogs)
    • Add/Edit Posts/Pages
    • Manage comments
    • BlogML import

No need to go over those in detail since they’re very standard these days.  We also have some other features that are either unique to Oxite or are just nice to have and not necessarily in every blog engine.  I’ll let you be the judge which are which.

Background Services

Background services are basically classes that are wrapped by an executor that calls a Run method in a timer so it’s run on a separate thread.  You might be asking why a web app would need this.  Most other blog engines don’t do this, why Oxite?  Personal preference around user experience is the short answer.  The slightly longer answer is that we think it’s a bad idea to hold up a page request to go off and do something intensive or dependent on a potentially long running task (like post to another website).  I’ll use the two background services we ship with as examples of what I mean by that: SendTrackbacks and SendMessages.  SendTrackbacks is a service that simply takes any outbound trackbacks that were generated from creating or editing a post and sends them.  You say, "This seems like a really simple task. Why not just have that happen when you add/edit a post?"  Good question.  It IS a really simple task.  There’s not much code in the service.  However, the work done in that service can take a while and is dependent on the sites that you linked to.  Submitting a new post could be infinitely held up by all those requests and only gets worse the more sites you link to (to get a response back from them).  SendMessages exists for the same reasons.  It’s purpose is to take a generated list of emails and send them through SMTP.  Again, super simple and barely any code at all, but if you have a lot of people with email subscriptions set up or your SMTP server goes down or is slow this could take a really long time.  Background services move the load to the background so the user’s request isn’t held up.

Multiple Site Storage in Single Database

This is mostly a feature that we’ve found important over the years to what we do, but thought it would be helpful to others.  In the web.config <appSettings> you can specify a "SiteName" that is a unique string in the database for the current application’s instance name.  Since all posts, content pages, blogs, etc are all scoped by that name, you can store many sites in the same database.  This may or may not be useful depending on your hosting situations.

Skinning

ASP.NET MVC is perfect for skinning.  We built our own little skin engine that basically just helps the view engine decide where to look for WebForms, Styles and Scripts.  If you just want to create a skin just with CSS that’s super simple.  If you want to create a skin with CSS and override some of the default Views, that is also really simple.  Check out Nathan’s page on CodePlex about How to Skin Oxite.

Web Standards Compliant

From day 1 when we started building the MIX Online site we found that ASP.NET MVC was great for controlling your markup and have taken advantage of that in Oxite to ensure we are XHTML 1.0 Strict compliant as well as having our CSS, RSS and ATOM validate.  Go out and compare Oxite to other blog engines and see how well or not well they validate.  Take it a step further and compare Oxite to major websites out there.  Fun!  Beyond being compliant with web standards our markup is semantic.  This is just a good thing to be overall, but can also make skinning much easier as the classes properly describe the content they are attributed to.  Hats off to Nathan!  Be sure to check out Web Standards: Where the ROI is by Molly Holzschlag and Web Design from the Gut by Nishant Kothary.

What’s Next

Now that we’ve got most of the refactoring done and are more solid across the board, what’s next?  Lots!  Our team can’t devote time to working on Oxite unless it is related to one of our projects (like it was for MIX Online).  It just so happens this month’s work relates to Oxite for our next project so we will be making improvements.  We will be creating the new Session Browser for MIX and it will be running Oxite.  Out of this, the new feature we’ll be adding is files.  This was one of the few features we had in the first version of Oxite, but had to cut.  It’s coming back in the next release because we need it for the session browser.  This includes being able to upload new files and associate them (or existing files at any URL) with a post.  We think that’s valuable in a blogging platform (and of course for us) so we’ll be adding it for the next release.  We will also be refactoring a few more things as we go.  On a personal level here are the things we will be working on in our spare time:

Plugins

Plugins will allow a developer to build new functionality on top of Oxite and allow someone running Oxite to drag-drop-run this new functionality.  Some of you may have noticed there are some plugin classes in Oxite today.  These were just the start and we ran out of time to finish that feature.  We will finish them off in the next release to make it super simple to tack on little pieces of functionality (everything from adding Routes, ActionFilters and Controllers to keeping track of settings for the plugin and making them installable) to Oxite.

Skin Variations

We will be adding the ability to create subfolders under a skin with addition Styles and Scripts (and potentially other subfolders for other sub-variations) to create variations of skins.  These variations will "inherit" all the Styles and Scripts from its parent skin.  We’ve found lots of skins that would look great with tweaked colors, fonts, etc.  At the same time, we will also be modifying the site settings page to make selecting a skin and optionally a variation strongly typed (ex. dropdown lists).

Rich Text Editor (RTE)

Without a RTE in the web admin, it can be a bit difficult to craft your own HTML by hand.  For now, we suggest you use something like Windows Live Writer to post to Oxite.  Eventually we’d like to add RTE to the plugin side of things so you can decide which RTE you’d like to use.  We’d also like to find an RTE that we can ship out of the box with Oxite, but it’s difficult to find one with a license that agrees with MS-PL.

Trackback validation service and trackbacks display

We’re currently keeping track of inbound and outbound trackbacks, but we don’t currently validate that received trackbacks are valid (ex. did the site actually link to you or is this just spam), nor do we show trackbacks anywhere in the default skin.  This is what we’ll be implementing.

User/Role Management

This is an area we dropped the ball on with this version of Oxite.  Our "authorization" model right now is basically "can you log into Oxite?  Ok, then you can do whatever you want."  For most this is fine since you’re usually just using Oxite for a single blog.  In the cases where you’d like to have more than one blogger on your site (family website, company website, etc) this is crucial to be able to set permissions to blogs and other stuff and we will be adding it back.

Content Page Management

There is currently no UI for displaying what content pages are available on your site (other than the dropdown list for picking which page is the parent of the current page you’re adding/editing) so you can move/remove them.  We haven’t figured out if we’re going to use a tree view or something else for this, but it is needed and has already been brought up in the community.

Other View Engines

We are investigating other view engines.  WebForms in MVC is great, but sometimes it isn’t a great fit, especially when you want a designer to work on the views.  Spark is one of them that we’re investigating.  If anything, we will at least get back to following MVC and allowing other view engines to be registered and used.

Mobile Views

Because of our good markup that we render, viewing an Oxite site from a phone is a decent experience.  It is readable.  We want to do more.  You should be able to control your markup without a lot of work that gets sent to phones and this is what we’ll enable.

This list will take us a bit.  If I had to guess I’d say 2 or 3 months to finish off that list (there will be many release in between).  Keep in mind this is just as we have time (an evening here and there) and it’s possible and likely that this list will change over time.  I’d love to hear what features you all think are important.

Where to Get Oxite

If you’ve read this far and want to checkout Oxite, please visit Oxite on CodePlex.  The latest release can be found here.  Be sure to go through the Setting up Oxite page as there are dependencies to run Oxite.  If you end up running it publicly somewhere, let us know and we’ll add your site to our list of sites running Oxite.  If you create a skin you want to share it, let us know and we’ll post it up for others to find.  If you have feedback for us or just want to discuss Oxite, start a discussion on CodePlex.  If you think it’s lame that I use the default skin for Oxite (I do and it’s lame), make a hot looking skin and I’ll use it for my site and give you credit!

How to Keep Up on Oxite

Many of us are on Twitter and we talk about Oxite.  You can follow me on Twitter here.  My blog will also be a good thing to follow as I’ll be talking about Oxite as we progress.  Oxite on CodePlex will also be a great place to watch since they have discussions, an issue tracker and RSS for Releases.

What Now?

I have some other "hidden" features I’m going to blog about soon, but what do you want to see blogged about next?  What isn’t clear in Oxite?  What’s hard to use?  What things do you want to learn how to customize?  Any other questions you have, please leave a comment and I’ll address them.

My Blog Moved (to ErikPorter.com Running Oxite)

by

Alrighty, so now that I’m dogfooding my own code it’s time to get back to blogging and talking about Oxite and other stuff our team works on. Unfortunately, first I need to finish off my site. As of this writing it is running plain old vanilla Oxite with nothing changed (other than my data). I still need to add a few things like analytics, tweets to my sidebar, about page text, etc.

Once I get all of that I’ll be putting up a blog post about the new version of Oxite we released last night. After that, I’ll blog about some of the features we currently have that are not really documented.

My blog has moved from there to here (if you happen to be looking for my old content).