Same Team, New Role at Microsoft

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

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.


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.

This currently redirects to (our home base). 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 ( 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 to be the page everybody goes to for information about features, documentation on how Oxite works, galleries for skins and plug-ins, etc.


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).


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

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:


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

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.


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 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 hereMy 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 Running Oxite)

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).