In Valid Logic

When implementing the collaborators feature in Trunks, ran into a bit of a roadblock with how to describe the relationships between the repository and the users.

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

Last night, I managed to migrate my blog from Graffiti CMS to Wordpress.  I’d been planning on migrating for a while now, but was just a matter of finally deciding to sit down and do it.

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.

How many times have you had a dialog like this: I should blog more. Well, what should I blog about? I don’t know, but I should blog more. Though I don’t want to sound boring, repetitive, or like an idiot.

There are probably two problems at work. First, over thinking a simple problem. Second, finding what you’re passionate about and how to best express it.

There are a number of top notch developers who hardly blog, if at all. But when they do, it is pure gold. They speak more with code than on a blog. You don’t need jaw dropping libraries or masterpieces, but just useful stuff someone else might want to use or read.

Want to find who the true leaders are? Find prominent people on Github and see what public projects they have. You’ll quickly find who is down in the trenches.

Having just gone to CodeMash 2010 last week, I am certainly reinvigorated. Especially after Joe O’Brien’s talk on "Refactoring the Programmer". It was really spot on with so many aspects of the developer’s lifestyle. Some things I’ve taken aware include:

• Scale back Twitter. It is a time sink and I rarely learn anything in that time.
• Blogs are great, but scale back what I read. All about finding the most value for the time. Ignore banter and marketing. Find others who show their passion in their writing.
• Write more code. Practice makes perfect. Athletes aren’t just naturally talented, they practice and are learning continuously.
• Read more code. Find good leaders, and learn what they’ve already learned.
• Read more books. And not necessarily on coding, but on improving yourself overall. Happiness comes from improving overall, not just in your profession.
• Go out on limbs. If you put something out there, ask people to check it out and give some honest feedback. If you have a question, seek out an expert and ask them. Be clear in what you’re asking, courteous of their time, and you’ll likely get your answer.
• Reciprocate. Asking for help is a two way street, so you need to pay it forward. Forming connections goes a lot further than hoarding your time.

My passion is in doing. Nothing makes me happier than hacking away on some random idea until 1-2am. And it is contagious. It bleeds over into all that I do. I put out better work during the day. I’m glad to go to the grocery store before dinner. I’m happier paying my bills. I came out of CodeMash with a whole list of things to hack on and hopefully get even more to keep me invigorated until next year. And hopefully I can throw the ideas out there, get some feedback, and create some value for others.

Typically, branding is a good thing. It brings you recognition, people remember your product/company, and you hope all that translates into sales. But branding can also be over done. Take for example, Smart Assembly (or rather "{smartassembly}") which was acquired by Red Gate back in September. Don’t get me wrong, Smart Assembly makes and awesome product, but the whole "{…}" thing has been over done.

For example:

1. All emails from them use "{smartassembly}". Even one hand typed support response did.
2. The press release when Red Gate acquired them uses "{smartassembly}".
3. The MSI you download is "{smartassembly}.Setup.msi"
4. The default install location is "C:\Program Files\{smartassembly}"
5. The executables are "{smartassembly}.exe" and "{smartassembly}.com" (.com is the command line runtime)
6. And yes, the project files you save are ".{sa}proj".

The branding can also get in the way of using the product. Smart Assembly is an obfuscation tool, so it would seem reasonable to integrate into your build process. NAnt is of course a popular tool for automated builds. NAnt scripts use $"{…}" to denote variables. While this doesn’t create a conflict, in my opinion, it clouds your scripts with excess brackets and takes away from the experience. (Note: I originally said it conflicts with using NAnt, I was wrong, since I jumped ahead of myself forgetting that it needs a ‘$’ too)

Branding is cool and all, but when it gets in the way of your user experience by overuse, its gone a bit too far.