Jason Alexander

I was in my junior year at UNT, working on my degree in Computer Science. I went straight into college after high school, and took a full load every semester.

But, I'll admit, I was tired.

My roommate, and some of my other friends, all started working in downtown Dallas at a startup. I didn't even really understood what "startup" meant, but they would sit around and tell awesome stories, and it truly sounded like fun. I didn't know what the company really did, outside of something on the internet, but I decided to take a break from school and see if I could land a job there.

So, I put together a sad excuse for a resume, and sent it over to someone there that one of the guys said I should email. A few days later I got called in.

I landed a job as a "QA Engineer". Basically, I would listen to various online streaming audio stations and if they were down, or sounded bad, I would try to troubleshoot it. It wasn't a hard job, but it was fun and I got to work with computers every day, so I was happy.Troubleshooting wasn't terribly exciting or challenging, basically we would go on the server, restart the Real Audio server, or reboot the server, and most of the time that fixed it. Generally we used PCAnywhere back then to connect remotely to the machines (there was no Remote Desktop back then), and often times it wouldn't start back up after you reboot a server. So, I'd have to call the radio station and talk someone through setting it back up, or, like KDGE here in Dallas, I would jump in my car and drive up the tollway. Coming in, we'd have a little computer sitting in the floor of the engineering room, with a long line running over and wired into a sound board, as the audio input into the computer. I'd log in, restart PCAnywhere, check it all out and head back to the office.

Yay. 

But, it got boring after awhile, and I just wanted to do MORE. I saw a server in the corner labeled "SQL" and asked around about it. No one really seemed to understand what it did, but said that some consultants we had hired once had set it up. I did some research and it sounded interesting. A "database". Huh, fun.

So, that day I talked with the VP of Operations and asked to go to training to learn more and see how I could help. I found a course, showed them the cost and talked about what it would do and the possibilities behind it. Somehow, he bought it. And, a few weeks later I was off to training to learn more about Microsoft SQL Server 4.5.

And, boy did I learn. Setup, configuration, backups, DBCCs... my head was swimming. An odd coincidence, while I was out they had hired a "Manager of Development", to start putting together a coding team, and we were off to the races.

Originally, I put together very basic reporting using HTC and IDX pages (the pre-cursor to ASP), and started designing databases and recognizing the data that we could capture. It was a blast! I had found my calling.

But, it would have been so easy to just sit and keep it in cruise control, never step out of my comfort zone and never challenge myself. But, I took some initiative, stepped up, asserted myself, and forged ahead. 

And, I've never stopped doing that in the past 15 years of my career. Take a moment to stop, reflect and see if you're truly happy where you are. If not, challenge yourself. Don't be happy with the status quo. 

Permalink | Leave a comment  »

Well, after many years of leaving my blog fairly dead, I decided to resurrect it. Luckily, there's still a few of you subscribed, but it'll be a long haul to get readership back up. But, at the very least, I figure this will be therapeutic. 

Upfront disclaimer:

I'm pivoting my blog a bit. As you may have noticed, my domain has switched to ThinkBuildGo.com. With that in mind, I'll be focusing on my experiences with various startups and entrepreneurship over the last 15 years of my career.

Setting this all up, I'll lay out the basic framework, telling you where I've been, what I've done and in what order. Later, as I get into the nitty gritty details, I'm going to keep out specific company, and people's, names in order to avoid any liability on my part.

I began my career 15 years ago at a company then called AudioNet. This company later renamed to Broadcast.com, went public and sold to Yahoo, making Mark Cuban (and many others) a lot of money.

During the Dotcom days, I went to work for a company called AIVIA, a web consulting firm. This story isn't so exciting, but there are a few things here and there I learned that I'll share.

Later, I went to work for Match.com, when it was smaller and really fighting to become the powerhouse it is today. I learned a lot here that I carry with me today.

Ultimately, I started my own company, Telligent, with a friend from Microsoft. I made a hard run at it for 5 years, and then exited to move on. This is where I learned so much. Nothing is like running your own company. Many of my lessons learned today are from my experiences at Telligent. 

Now, I'm back in a small startup called ShopSavvy, heading up Engineering. And, it's great to be back in a small, scrappy startup! I love it. Every day I leverage knowledge that I learned over my past 15 years.

That all said, I'm going to share that here in the coming posts. Some are goofy stories, some are funny stories, some are stories of lessons learned. 

But, hopefully you enjoy the ride. 

Permalink | Leave a comment  »

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

Permalink | Leave a comment  »

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.

Permalink | Leave a comment  »

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?

Permalink | Leave a comment  »

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.

Permalink | Leave a comment  »

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.

Permalink | Leave a comment  »

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.

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

Permalink | Leave a comment  »