Code Drop: C# Tag Extractor

Well, unfortunately my previous series is a bit derailed. I started working on an all new MongoDB driver and I hated to write up a whole series of post using a driver I didn’t really believe in. So, for those of you reading and waiting on that, please be patient with me – it’s coming, but I just want to wait until we have the new bits ready.

That being said, one thing I used to do with my blog was do semi-regular code drops of things I found useful and perhaps to you too.

That being said, I present a very basic code drop for doing tag extraction. One of the scenarios we were discussing was the ability to take a body of content and suggest possible tags for the post. Not terribly complicated, but I also thought it was a fun little routine to build. And, hell, if it saves you 30 minutes at some point in the future then it’s done it’s job.

The class is pretty simple:

You call AutoTagger.ExtractTags(string) passing in the text you want to parse, and it returns you a Dictionary<string, int> of the most common keywords found, and the number of times found ordered in descending order like so:

Take a look at the code, but it’s pretty simple. It strips all the HTML from the given input, scrubs out any punctuation that will cause problems, and then runs through all non-noise words and counts the occurrence of them in the string.

Enjoy!

Check out the code here: http://bit.ly/9WHa70

Fork the code on Github here: http://bit.ly/bsNuXM

Getting Started with AutoMapper

As they say: “Hindsight is 20/20”

After publishing that blog post yesterday, and starting to layout the entire series, I realized I did everything wrong (boy, how often can I say that? ). My next series in my posts relies on the audience knowing and understanding AutoMapper. And, not even the simplest of parts of AutoMapper, it uses more of the intermediate functionality.

So, with that being said, I wanted to jump in-line here real quick and cover AutoMapper.

If you were like me a year ago, I looked at AutoMapper and thought, “Meh.” Great, a framework to map objects into other objects. Yay.

But, I didn’t get it at the time. It hadn’t clicked.

In the MVC world, one of the best practices out there (and there are many, I’m only advocating one; make your own opinion here) is that you have POCO (Plain Old CLR Object) – this is just a very basic class that has properties, and no logic. What I used to call a “Wrapper”; a dummy object that I would shove data into and pass around. Many times you need to transform the data in that POCO to another object, say a Model (if you’re using MVC) to pass to the View. This is where AutoMapper comes into play. Now, granted, there are many different architectures, opinions, ways to do thing.

So, let’s get started.

Automatic Property Mapping

 

First, we’re going to go over the most basic scenario of AutoMapper: automapping. This is where AutoMapper will try to resolve the mapping itself, looking for like-named properties in the source and destination objects.

Let’s setup the two classes we want to map back and forth: keeping with my theme from my earlier post, I’m going to use a User class and a Contact class. They should share some data, but ultimately Contact will have some fields on it’s own.

Here they are:

 

Nothing to them. A few shared properties, but some unique ones.

Now, check out this magic on how we map one to the other:

In that first line, I call Mapper.CreateMap, passing in the source object, and the destination object. In more complex scenarios this won’t work, but this is the most simplest use of AutoMapper – it will create a map for like-named properties. Note: You’ll want to add this call wherever your app starts up. If it’s a web app, stick it in Application_Start in your global.asax.

From there, I new up User and fill it with data. I then call Mapper.Map, telling it the source and destination again in the type parameters, and passing in my User object. It returns me a ContactModel class with data mapped where possible.

Finally, I print out myContact.FirstName which is, you guessed it… “Jason”. Easy!

Manual Column-level Mapping

 

But, what about that other data we want to carry over? Some of that data should go to Contact, but AutoMapper just doesn’t know what to do with it. Here’s how you can tell AutoMapper how to handle a specific mapping (it’ll still do the automapping where it can):

I simply added a .ForMember() call on the CreateMap() call. You can follow along the syntax there, too, and see I’m telling it that for Contact.FullName, concatenate User.FirstName and User.LastName with a space in between.

That’s it!

Custom Type Converters

 

However, sometimes those ForMember() mapping calls just won’t do. There’s implied inference with the mapper, still, that it does a little black magic to reflect and assign values over. If you need to get down and dirty and do the conversions yourself, you have to get into type converters.

Type converters allow you to hook directly into the mapping process, and handle the entire mapping yourself. Sounds complicated, but it’s easy. First, let’s build our ITypeConverter:

As you can see, this is a class that implements ITypeConverter, and declares the source and destination mapping in the interface declaration.

From there, you implement a Convert() method, passing the source type document, returning a destination type object. And, whatever you do in between is up to you.

In my case, I do my mapping logic of building FullName, mapping over FirstName and LastName, and putting the EmailAddress into the BusinessEmailAddress property. Then, I return it. But, you can see that this is where you would do any of your needed logic around scrubbing, converting, etc…

Now, to plug this in. It’s super simple, like so:

As you can see, all we did was replace our ForMember() calls above with a final method call to ConvertUsing(), passing in our new converter as the type.

That’s easy! And, that’s AutoMapper 101.

There’s so much more that AutoMapper does. I recommend you check out http://automapper.codeplex.com/ to see everything it does. It’s pretty amazing stuff overall, and I think you’ll find it will become a major component in your next solution.

Getting Started with MongoDB and C#

I had been hearing all of this talk of the NoSql movement, and, being the ever-curious tech type, I had to dig in and see what it was all about.

Of all the various options out there, MongoDB has been getting a lot of press lately. MongoDB is hailed as one of the top NoSql options out there for being ultra-scalable, and highly performant. You can see the long list of known production deployments out there.

With that context being set, I had to see what all the excitement was about. And, here’s how you can too:

1.) First, check out the Quickstart to get everything installed and setup. One note here: if you’re like me and you want to setup MongoDB to run as a service, check out the help in “mongod –h” but you can basically run “mongod –-install” and it will install it as a service for you.

2.) Next, go download the MongoDB .NET drivers from:http://github.com/samus/mongodb-csharp/tree/master

3.) Unzip, copy where you need to and add it as a reference to your project. You’re all set!

Your next step is to figure out how to work with MongoDB, and, as with any database (relational or not) you still have the basic operations: querying, updating, inserting and deleting.

So, let’s get started!

 

Connecting to the Server

 

So, how do we connect? Very simple. Check it out:

This assumes the default host (localhost), and port (27017; unless you configured it differently when setting up mongod). If so, there are constructor overloads to pass in a different host name and port.

 

Getting the Database

 

Don’t worry, you’re not in a completely foreign world here. There’s still the concept of a database. Here’s how you get the database instance (carrying forward the earlier code):

Again, simple, right?

 

Referencing the “Table”

 

Here’s where it gets interesting. There’s no concept of a table. The idiom to remember here is that MongoDB treats ever record as a “document”. So, instead of a table, there’s a collection of documents. Here’s the fun thing:

Because MongoDB is “schema-free” those documents structure can vary, even when in the same collection.

Yes, hard to twist your brain around, but this is really just a logical grouping of data. In most cases, however, people do put like structured documents into the same collections.

Let’s get our first collection:

In this case, we’re getting a collection called “Contacts”. Even if you’ve never saved anything into that collection, yet, it will still return you a valid collection to work with. So, this is how you create new collections.

Now that we have a collection, we can actually do stuff with it! Exciting, huh?

 

Introducing the Document: end all, be all.

 

In the MongoDB world, the Document class is the center of it’s universe. Because the very concept of the database is built upon the concept of this document, this is what you’ll find yourself using most. You use them to insert data, update data, delete data, query data. You will learn to live it, love it and adore the Document.

Here’s where I’m going to pick up the pace a bit because this is really where I got that “Ah ha!” moment, and I think you will to.

First, let’s insert some data:

Here, I did all the stuff from earlier (connecting, grabbing the database, getting the collection), and then I new’ed up a Document object. The Document object is nothing but a big Dictionary object, in this case.

So, I go to town. As you can see, I create a logical entity for a “Contact” in my mind, adding first name, last name, address, city, state and zip code, and I assign values respectively during the process.

Finally, I call the Insert method on my collection, passing in my document.

You have just created your first record in MongoDB. Stop, pat yourself on the back, think to yourself “Really, is that it?” and let’s move on.

Updating data (and really, pretty much everything else) is just as easy:

Easy! The only difference here (and what I didn’t show) is that I added the “_id” property of my document, after having inserted it earlier. This gives MongoDB reference on which document to update.

Now, deleting is just as easy. In our previous method, we just change the “Update” method to “Delete”. I could also leave the other properties, but in this case I already know the ID, so let’s just strip it down to that:

Again, easy enough!

Now, querying the database. This should look very familiar, and make a lot of sense if you’ve been keeping up:

Here, I create a Document object, I set the “City” property to “Dallas”, and I call Find(), passing in that Document object. The Document object, in this context, acts as the query to MongoDB to tell it what to search for.

From there, I iterate through Find().Documents, which is just a collection of Documents and print out the “FirstName” from each record.

Whew, that was long, sorry. And, there’s still a ton more to cover, but I’ll leave that for another date. Interesting, eh? It’s been enough to make me think about using it in a project myself. What about you?

Command line parsing in C# with NDesk.Options

UPDATE: Miguel pinged me on twitter to tell me that NDesk.Options is now Mono.Options and is now in the standard build of Mono. Awesome!

I was working on my MDD framework, writing a command line application to help. Every time I do this I have to fumble around with how I’m going to handle the argument parsing. Typically, I end up just hacking something up so that it’s good enough, but this time I wanted to do it right.

Enter: NDesk.Options (http://ndesk.org/Options)

This is a great little utility class that parses the incoming string array. The awesome thing here is that it gives you a very flexible interface for defining the expected incoming parameters. You can add an option string that allows pipe delimited aliases, Boolean parameters (they’re there or not), and required or optional parameters.

Let’s look at the code:

Here you can see it all. After newing up the OptionSet class, we start adding options. They have strict typed Option you can use, or you can do what I did, where I’m doing pipe (|) delimited aliases, with lambda expressions as the second parameter to actually do something with the value incoming.

In my case, I’m using “=” which tells OptionSet that the parameter is required. If I wanted them to be optional, I would simply use a “:” instead.

In the third option I’m not using either, which makes it a Boolean parameter. Here, I’m telling the OptionSet that if “?”, “h” and “help” is passed in to call the DisplayHelp() method below.

And, there you go! Simple, but effective command line parsing. And, you don’t have to hack something together anymore every time.

Re-release of Authorize.Net C# API (now NAuthorize)

Every time I jack with my blog, I get lots of emails about my Authorize.Net C# API not being available any longer. It was one of the first ones that was ever written out there, and it’s been tried and true for many years.

It doesn’t do everything possible that Authorize.Net offers, but it does all the basic commerce transactions necessary for building e-commerce (this was used on the original Telligent store).

I wanted to make sure I don’t lose it again, and I wanted to release it into the wild. So, here it is. Henceforth known as NAuthorize:

http://nauthorize.codeplex.com/

Added to my list is to one day go back and write tests for it so it has more testing and documentation built in. Meanwhile, take it FWIW.

Ch-ch-ch-changes!

Well, it wasn’t long ago that I posted about the fact that I was moving away from self hosting my blog, and moving to Storytelr. Sadly, while I love the concept, it wasn’t working for a few reasons:

1. I’m boring, and only posting most of my twitters is even more boring. Which leads to…
2. My reader count dropped off drastically. So, for those of you that are still there: THANK YOU! I promise more good content now going forward.
3. I’m getting back to the point where my technical skills are where they were 3 years ago, and I’m starting to work on lots of fun side projects. With that, I want to share my knowledge in a way that I can’t on Twitter.

In 2010 I’ll be doing some fun, fun things (hint: my legal restrictions that have had me bound the past year will be expiring in the next year). Some projects  and goals for this year:

• I have a Google App Engine (GAE) product that I started building and will launch this year. This will play with Twitter, and will play on the power of crowd sourced knowledge.
• I’m going to start building some fun stuff on Azure. I can’t really talk about it yet, but I’ll definitely share my experience here.
• I’m going to write at LEAST one game for the XBox 360 using XNA. I have a great game idea already, and start studying up. I’m not naive enough to think I can make a living from this, so it’ll be for fun and NOT profit.
• I started working on a Model Driven Development framework. There are a few things out there that are similar, but in FubuMVC fashion, I’m going to build something for me by me, and if anyone’s interested in using it, great.

So, all and all it’s good to be back – it’s been nearly 6 years now with my past work at Telligent combined with the last year of working outside the Tellisphere and getting my technical chops back.

Looking forward to it!

Hello world!

Welcome to WordPress.com. This is your first post. Edit or delete it and start blogging!