1. No XML configuration files. Granted, our builds are in NAnt, so we’re still married to XML, but creating a new build doesn’t need to take any XML editing anymore. Our build scripts have no hard coded values, everything it needs it passed in from Team City. So we can go an existing build, click Copy, then just edit the configuration settings as needed.
2. It queues builds. We run a number of daily builds at 4pm Central and at that time, the build server comes to a screeching halt because all of them run at the same time. We’ve had to stagger them an extend the timeout limit on several because of how slow it gets. Team City instead runs one at a time, queues the others, and lets you prioritize the queue if you need to bump things up.
3. Does more for you. First of all, it exports the source from the main repository cache for you. When building, you want to avoid working off the main repository cache since then you can get stuck with collisions on update, but with CC.NET, we always had to do the export and everything ourself. Team City takes care of and reverts the source to a clean state one each run.
4. Artifacts and cross dependencies. In CC.NET, we always had a network share set up where we’d place built packages, but with Team City, they can be loaded back into the main site for storage and easily accessible. On top of that, you can place dependencies between builds and have the artifacts extracted. For instance, we have one built that fully packages a release every day. We have another build that our Selenium tests. We have a build dependency on them so that Team City extracts our latest package and the build script sets it up in IIS and runs against it. As time goes on and we get more of our subcomponents into Team City, ensuring all subcomponents stay up to date will be automated and far easier.
5. Streaming build log. No longer do I need to wait for the build to be done to see what is going on. Team City can stream the build log to the browser, so I can see where its at, what is hung up on, or if it did something wrong that wasn’t an error, can stop the build and correct it.
6. Easily customize builds. A while ago, we’d built a “preview build” and then a short while afterwards, realized there was an issue with the build. Not with the code, but just the build process. We needed to send an updated one, but wasn’t sure if the latest code was at a release-worthy state. Luckily, Team City makes it super easy. Right through the interface, I was able to kick off a new build of the same SVN revision as the earlier one. It also was intelligent enough so that in the history, it distinguishes it so someone knows it is different and in the description, says it is a build of an earlier commit and out of line with the other builds.
7. Test history. We’ve just started pulling in our test builds, but one nice thing I’ve immediately notice is some of the rich reporting it has around test stats. For instance, it shows when a test started failing (if its been in multiple builds), allows you assign someone to be responsible, allows you to track a test’s history, and even identify problematic tests (probably ones that fail the most). You can even track the test duration and see it change over time.

Overall, would have to sum Team City up as just being incredibly refined.

I know a number of people who have larger Cruise Control setups than us, but overall Team City brings a lot to the table and the cost factor makes it a dead on winner. Team City can easily pay for itself just in terms of productivity. But on top of that, it is free up to 20 build configurations!

On Monday, I took the beta sticker off Trunks, making it officially available. Trunks has been doing quite while, and although it still has a small user base, I’ve been very pleased with its growth. Over the three months it was in beta, new users were slowly trickling in and even got a mention by Mike Gunderloy. There weren’t any major issues that came up, just a few bugs here and there. In that time, have added a few new features, refined the backend, monitored performance (even though its small, still important), and focused on stability of the systems.

Last week I was talking to a friend about Trunks and they were asking what was left in order to launch it… boiled down to adding diff support and the ability to pay for it (kind of important). After thinking “that’s all,” I figured I’d buckle down and finish things off. Also managed to fit in some UI tweaks and refinements, especially after cringing at the signup page I used to have.

If you haven’t already checked out Trunks, I definitely invite you to.

Download

This release includes a few bug fixes and updates, several of which were contributed patches (thanks!).

• Feature: Added support for embedded images (patch submitted by jasonpenny)
• Enhancement: Show an alert when trying to use port that is already in use (Issue #5405)
• Enhancement: Don’t show the options dialog in the taskbar (patch submitted by dukesb11)
• Fix: Updates to fix issues with multipart messages (Issue #4959, patched submitted by jasonpenny)
• Fix: Issue with async networking and not handling a disposed object (patch submitted by jasonpenny)
• Fix: Out dated URL references (Issue #5457, patch submitted by billrob458)

So in the past two years, what have I done?  Sadly, a lot of it is sorely behind and out dated, but take a bit of a trip down memory lane…

• The SkitchDav I originally blogged about, but now no longer use
• DM-DBSlayer. I was using it in a personal app, but the app didn’t need scale, so eventually removed it.
• DM-Paperclip.  I really need to dust this off, it needs some TLC.
• Some hacking on Warehouse, which eventually led to my ideas for Trunks.
• Branches, which was basically a ruby port of Gitosis.  I wrote it anticipating using it for Trunks so I could interact with the DB in Ruby.  I did in the first incarnation of trunks, but am now on “Branches 2.0″ which was done from scratch and super simplified so it is Trunks-only and structured to do both Git and Mercurial.  Would actually be nice to pull it out of Trunks and release it.  Damn, another project for my list.
• Tigger.  Really bad name.  When I first wrote Trunks but was unsure about launching it, tried to redo the interface as a better read-only web interface to git repos.  The app should still work… was on Merb 1.0.
• And of course, Trunks.  Merb 1.1-pre.

And I’ve also had several apps that haven’t seen the light of day and were more for my personal use or tinkering.

• For a while I was into EVE Online and wrote an app to parse and process item reports from Eve Central.  It allowed me to locate items that were selling under market rate quickly, compare prices across markets, and I could somewhat defer what items were selling most at different market hubs.  Really geeky.  Probably put several months into it.  Merb app.
• Also wrote an app to track my sales by location, by item, and comparing sales volumes based on price as I played with prices.  Merb app.
• And another for EVE Online… came up with the “Jita Mineral Index” which tracked mineral prices in the main market hub in the game.  I left it up for several months after I stopped playing, until I found that the app that processed the emails from Eve Central broke and had like 200k+ unprocessed messages in its inbox.  Merb app.
• Some time ago, was playing with different virtualization APIs and wrote an app that would provision and deploy virtual servers in KVM and in XenServer.  I’m probably too much of a nut about virtualization.  Mixture of stuff… Ruby, Nanite, Merb.
• A really basic Sinatra app to handle my domains that just have static pages.  Rather than having multiple sites, I have just one and it determines which template to render based on the host header.  Was my first Sinatra app.

And of course some other stuff on Github and Gist.

And I have some that will likely be coming soon:

• This, which I’ll likely blog about once I get a name for it and a domain.  And update the incorrect launch date in the News part, oops.
• Was actually thinking of dusting off my original SkitchDav as a Sinatra app.  What triggered me to write this.
• Also thinking of dusting off an app I prototyped a while ago involving Rack and Solr.
• Always got ideas brewing in my head… just a matter of parsing out which are really worth my free time.

All this Ruby has also helped me to grow so much more as a .NET developer.

• More languages you know the better.
• Exposure to new methodologies and mindsets, new more progressive community.
• Exposure to testing.  Testing is far easier in dynamic languages, and grasping the concepts in a dynamic language makes it easier to apply to a static language.
• MVC.  Thank god for MVC.  Unlearned all the webforms crap and re-learned plain and simple HTTP and a logical structure for your app.
• Making programming fun again.  Its nothing against .NET, but sometimes you need to break out from the familiar and learn something new to remind you why you love programming.  Before Ruby, I was stuck in what I knew and don’t really think I was coding for fun much.

First of all, one thing that is very nice to do, if you have a presence in both places at the same time, is to configure IP forwarding from your old site to your new site.  While it is a best practice to set the TTL on your DNS records really low (mine are currently 60 seconds), ISPs don’t always honor the TTLs and some will be more aggressive with caching.  As a rule, its usually 8-24 hours before you can really count on old caches being expired.

To combat this, forwarding any traffic that might be going to the old addresses to the new ones can be very helpful, and fairly easy to do.

There can be several ways to do this, but can often times end up more complicated.  The pure and simple way to do it is to use an application called rinetd, which is basically an “internet redirection server”.  You simple edit its configuration file, specify the old IP address and port, and the new IP address and port.  Run it and you’re good!

I run ESXi on some of my systems, so I simply created a new virtual machine with a very basic configuration and installed Ubuntu on it.  I gave it a base IP that I wasn’t going to be forwarding, installed SSH on it (to remotely manage it), and then went to town setting up what I needed forwarded.  First, I added the IPs to be forwarded as aliases in /etc/network/interfaces:

auto eth0:0
iface eth0:0 inet static
     address 192.168.1.111
     netmask 255.255.255.0

Now, I need rinetd. On Ubuntu, it is readily available as a package, so just run sudo apt-get install rinetd and you’re set. Edit the /etc/rinetd.conf to list out how you want things forwarded:

# old ip         old port    new ip          new port
192.168.1.111    80          172.16.1.222    80

Afterwards, all you need to do is restart networking and rinetd. So run sudo /etc/init.d/networking restart and sudo /etc/init.d/rinetd restart.

Few things worth noting. rinetd binds to the address/port you specify, so if you are trying to forward port 80, you can’t have something else bound to port 80 on that IP, such as a webserver. So if you need to forward something that you might have in use, you may have to tweak things. If you need to forward SSH, it might be best to configure SSH to use another port for a little while. Second, I’d sometimes just reboot the virtual machine instead of restarting networking. I’d migrate some stuff one night and have it forward for 24 hours, then next night migrate something else and have it forwarded. It’d sometimes get a little hairy adding/removing/reconfiguring aliases a lot, so I’d just reboot.

Another plus with rinetd is that a port of it exists for Windows! A download exists on its site and it is also possible to configure it as a Windows service using ServiceEx. I haven’t tried it myself, but I did find some pretty detailed instructions about configuring it on Windows.

We had an issue with some username handling and it ended up boiling down to there we could go into SQL Server, run this query, and get a result when you’d normally expect it to not match:

select 1 where N'ß' = N'ss'

After that, I was truly stumped. I’d Googled everything I could think of any came up empty. Had I known what the German sharp S was, life would have been easier. Come to find out through some sources, that some of the SQL standards (in this case, SQL92 is referenced) call for the German sharp S is translated down to “ss” in string comparisons. So although it might seem like a bug, it is to-spec. Oracle is also reported as working this way.

To work around the behavior, one option is a workaround function for SQL Server which essentially has you convert the string to a binary column and store it. This may be outside what you can do in your application though, as in ours, we’d need to update every place that does string comparisons on the username as well as altering the ASP.NET Membership tables and stored procedures.

An alternative is to change your database collation to use one that is more binary dependent such as Latin1_General_BIN. This will treat ß and ’ss’ separately, though also be aware since it is binary, it is case insensitive and some behaviors such as sorting may also change.

A topic like this is important for any developer for a few reasons:

First, being in the US, it is easy to be ignorant of other culture’s language handling. You may work to add resource labels so your application can be translated and such, but every so often you will find behaviors related to internalization that perplex you because you’ve never heard of the German sharp S (as in this case).

Second, when its an issue in SQL and you’re in doubt, look at collation first. SQL Server has a huge list of collations, and each one does something different. Its either a behavior with the one you’re using, or the user is using a collation you haven’t tried (tested) before.

And finally… need to try harder to stump Penton. It can be done!

Today’s market is super competitive, especially at the entry level jobs. My sister graduated from CSU Fullerton with a degree in Journalism and Graphic Design, which has a strong communications program and is well respected. She was also a contributing author to the school newspaper, interned at Us Weekly in Los Angeles for two years, and interned for Us Weekly in New York over the summer.

She graduated in May, but just now was able to get a job in her field. That is nuts. Granted over the summer she was doing an internship in New York, expected to stay there but later decided to come back to California. But she still was actively looking for a job from August to the end of January. On the job she finally got, she beat out 250 other people who’d submitted resumes. She was also in consideration for another job, that one was up against even more people and it came down to her and one other person.

The market today is a stark contrast from when I was in college and all my professors and advisors were touting how easy it’ll be to get a job and making $60k easy. I would be scared to be graduating in today’s market.

Today, a degree is just a piece of paper. Everyone else who is graduating with you has the same piece of paper. To beat them out, its who you know and the experience you have. I’m by no means saying college is worthless, but rather it isn’t everything. I’m a college drop out… I left college to work at Telligent. I’ve been luck enough to have it work out, and now my work experience would be more relevant.  Its no longer enough to just go to college.

Building on James’s comment in my last post, a web developer today needs Google juice behind them. A degree is great, but so is a blog with relevant topics, involvements in projects, a Github profile, and more.

I want to talk about professionalism and your brand.

It is kind of ironic that the podcast talks about how you should always be professional in your code comments while producing what they did (think beyond just code comments). In this day and age, the internet is pervasive and data is everywhere. Google crawls everything, and it remembers everything. The post looking for contributors talks about other podcasts being “careful about how they talk”. When its online, it isn’t about being careful how you talk, or even being professional. It is about managing your identity.

The days of “dress to impress” are over. You are no longer judged just by how you physically present yourself, you are your Google results. You could go into a job interview dressed to the T, well presented and the pillar of what they are looking for. But its becoming more common where they’ll Google your name and finding out who you really are.

What you do online stays with your forever. You don’t need to be prim and proper by any means. Just use common sense. You are managing your brand. What your coworkers see, your family, your future employers. You can be bold and opinionated, you can still speak your mind, but do it intelligently. Something like that single podcast can ignite a fire of comments and posts, links, name mentions, and then when someone Google’s your name, they’ll find your drunk rants And it can be hard to manage your brand once it has taken off like that.

A while ago, I’d found this presentation through Twitter about “Evangelizing Yourself” by Whitney Hess. It is chalked full of wisdom. Listen to it (the play button has the audio, I missed that at first). It is all about what I’m trying to say and says it much better.

Trunks is built on Merb and DataMapper, and the implementation involved two models: a User and a Project.  In Trunks, a repository is a Project because “repository” is a reserved attribute in DataMapper and I was running into issues early on, so I changed it to Project.

A project belongs to a user, and a user has many projects.  A user can also be a collaborator on many projects, and a project can have many collaborators.  So I already had the first relationship which was a simple 1-to-many relationship.  The problem came about with adding collaborators.  In a sense, it is a normal many-to-many, which you can do in DataMapper similar to how you would in ActiveRecord using a “has_many …, :through => …” relationship, but I was creating a relationship between models that had an existing and separate relationship.

I didn’t want the user.projects collection to return the projects a user collaborated on, because it was intended to only be the user’s own projects.  And similarly, a project only has one owner, not many.

I essentially found I needed a “has many through” with named attributes.  To do this, I had to actually create the proxy class that goes between the user and the project model, rather than let DataMapper create it automatically.  That way, I can control the attribute names on the proxy class so that “users” and “projects” on the two models won’t get munged.

The result looked like this:

class User
  include DataMapper::Resource
  ...
  has n, :collaborations
  has n, :collab_projects, :model => 'Project', :child_key => [:id], :parent_key => [:user_id], :through => :collaborations
end

class Project
  include DataMapper::Resource
  ...
  has n, :collaborations
  has n, :collab_users, :model => 'User', :child_key => [:id], :parent_key => [:project_id], :through => :collaborations
end

class Collaboration
  include DataMapper::Resource

  property :id, Serial

  belongs_to :collab_user, :model => 'User', :child_key => [:user_id]
  belongs_to :collab_project, :model => 'Project', :child_key => [:project_id]
end

Having a “collab_users” on the Collaboration class allowed me to have the project model to get an attribute name “collab_users” instead of trying to use “users”. And on user, I could have “collab_projects” instead of mixing things up with the existing “projects” attribute.

When creating the relationships though, I had to be careful to spell out the actual parent and child fields rather than let them be automatic, otherwise it’ll run into issues where it’ll try to create ‘collab_user_id’ and ‘collab_project_id’ and inserts will fail because those columns aren’t being set.

Take the relationship definition on the user model:

	has n, :collab_projects, :model => 'Project', :child_key => [:id], :parent_key => [:user_id], :through => :collaborations

I am essentially saying create an attribute named ‘collab_projects’ through the ‘collaborations’ relationship. ‘collab_projects’ will be of type Project. The child key on Collaboration is ‘user_id’ and the primary key on User is ‘id’. Here, the fields I specify are betwen User and Collaboration, not on Project.

Then on Collaboration, I have:

	belongs_to :collab_user, :model => 'User', :child_key => [:user_id]

Here I tell it that the attribute on Collaboration will be collab_user, but the model it is linking to is User. Basically saying I belong to user, but don’t create an attribute named ‘user’. I set the child key, which is the column on Collaboration, to be ‘user_id’. I want to do that else it will try to create it as ‘collab_user_id’.

Confused enough? All boils down to having two separate relationships between two models and having control over what the attributes are named. After all this, I end up with these calls:

  user.projects        # the user's own projects
  user.collab_projects # the projects the user is a collaborator on

  project.user         # the owner of the project
  project.collab_users # the users who are collaborators on the project

Now, why did I migrate?  I know a few months ago, I caught some slack on Twitter for stating that I didn’t see what all the drama of Graffiti was (this was pre-open sourcing).  And I still agree.  Graffiti is a great tool, I liked it and enjoyed it, however I ended up deciding to migrate for a few reasons.  Most notably is the plugin availability/community.  Wordpress has tons of plugins for different tasks, and Graffiti simply doesn’t compare.  The developer in me may say “hey, I can write my own” but the reality is that I don’t have the time to or really want to.  I wanted a drop dead easy way to include code in posts and didn’t want to fiddle with it.  I wanted easier media management, and didn’t want to come up with something new on my own.

I had tossed around the idea of writing my own blog, since I wanted it off of my servers, but other services like Tumblr didn’t have quite what I wanted.  I thought it’d be nice to write a simple one in Sinatra and use MongoDB (via MongoHQ), but it again came back to prioritizing my different projects, and I’ve called blogging apps the new Hello World.

In the move, I also wanted to bring over all the content from my original blog, qgyen.net.  Now I have basically merged the two blogs and everything from my original domain redirects here.  Gain more Google juice, and sadly, my old dead domain had still more subscribers than my new domain.  Yes, sad.

How was the process?  Not too bad.  For a good guide, I’d recommend Jef’s post.  I made a few changes through:

1. I used the original VB.NET version of the GraffitiToBlogML tool (link).  I simply found it before the C# port.
2. Both the VB.NET and C# version have the potential of producing invalid XML.  They basically just write out XML directly rather than use the XML libraries within .NET.  One place it broke for me is they produce the old post uri by basically taking the post title and replacing spaces with dashes, it doesn’t strip invalid characters.  I had some posts with quotations in the title (“).  This broke the XML.  I changed it to use category.LinkName and post.Name, since those are the url-able portions used directly by Graffiti itself.  I also had it not append .aspx, since Graffiti didn’t actually do that.
3. BlogML seems to treat the post’s creation date as when it was published.  This can be an issue if you had migrated from to Graffiti from something else, like Community Server.  I had 300 or so posts who up in December 2007 at first.  The migrated data had a creation date of December 2007, but Graffiti had a separate Published field that marked when it was published.  I changed the tool to handle that so I could migrate my data right.
4. At least in the VB version, it was missing some null checks, I ran into one with TagList being null instead of empty.
5. I imported using the BlogML importer rather than MoveableType one.  For a really simple walk through, see this guide.

I will definitely miss Graffiti, since it was so drop dead simple to use.