So, I’ve been pretty happy with Wistle, the merb app that runs this blog and fromgenesis.org. But I’ve been pondering the future of it. The design is somewhat monolothic, what with several libraries and such just stuck in the lib directory. I’m now thinking about focusing more on the app itself, rather than just the ability to store the articles in Subversion, but the current setup is a bit too interconnected. I would also like to easily re-use several of the bits in the lib directory in other apps.

The driving force here is actually the comments. The views I have so far are not real useful, and there’s no anti-spam measures whatsoever. And as I’ve pondered what I want to do there–and now with some time away from the original work–I’m thinking much more along “this is part of the app (the UI)” versus “this is part of the back end”.

So, refactoring is at hand. I want to strike a useful balance between “trash it and start over” and “make the changes that need to happen” (Although, since its mostly a for-fun project, if I end up trashing a lot, no biggee). I’m considering the best order to approach this; one in which I plan on doing the comments updates last, but at which there are a number of points at which I could stop and jump over to that. So, here goes.

Move to git

Done 6/14/09 - http://github.com/jm81/wistle

Wistle is currently SCM’ed in Subversion. I’d like to move it to git, and host on github. No particular reason, other than for the chance for some more learning. I’ve only done a little bit with git, and since it seems to be ‘the thing’ among the merb/rails folks these days. The little I’ve used it, I’ve liked it…

Libraries to gems

This is where the change really begins. I want to move libraries out to gems, because there’s no reason for these things to be tied to the app. I foresee five gems here:

1. Filters

   This is the library that allows for filtering text through, e.g. markdown, textile, smartypants, etc. libraries. It will also contain a couple built-in, which I could move out later. One of my favorite features of this lib is the ease of choosing between a variety of implementations for a single filter. For example, for markdown, I could use rdiscount or bluecloth, depending on which is available.

2. Pagination

   (Mostly) Done 6/23/09 - http://github.com/jm81/paginate - See TODO file for future plans for this gem)

   I know, there’s bazillions of pagination approaches out there. This gem would just be for adding a method to DataMapper classes and collections: paginate, which is just like all, but it receives a :page option (and receives or assumes a :limit option). The result has two extra methods: #pages is the number of pages given the current settings, and #current_page is the number of the current page (1-indexed).

   I should probably check what else is out there now, although I’ve never completely liked other implementations I’ve seen, mostly because I want to access the page number and total pages through a method on the returned collection. If there’s something better out there, I probably shouldn’t bother with the updates that are needed, such as adding the #paginate method to DataMapper::Collection.

   What I do have is somewhat based on dm-is-paginated.

3. Pagination-slice

   Update 6/25/09 - I decided this was unneeded. The jm81-paginate gem (above) now has a helper method (Paginate::Helpers::Merb#page_links) that does what I had planned for this slice to do.

   This involves figuring out merb slices, but that’s worth it. I have a helper (might be part of the first library) and a view partial that I use quite a bit, with slight variations. It’s based on someone else’s code, but I’m not sure I remember what.

   Anyway, I think I could create a useful slice, to make this code more easily reusable. I’ll see.

4. Subversion Fixtures

   Currently in lib/wistle/fixture.rb, this allows a fairly simple way to set up a Subversion repository (which I use in testing the Subversion-to-Datamapper stuff.
   

5. Subversion-to-Datamapper

   The current lib/wistle directory, the stuff that extends a DataMapper class to allow syncing from a Subversion repository.

(A possible sixth gem has to do with “attachments”, along the lines of attachment_fu. It’s not something currently required in Wistle, but I have one more or less together that works more reasonably to me than other plugins currently available)

New Wistle lib approach

Aside from the fact that the above needs to happen in order to simplify new updates, what really interests me is this part. I want to break up the process in the Subversion-to-Datamapper sync. In short, I want to place an intermediary, which is the Atom Publishing Protocol. That way, I can use Subversion to store and auto-publish to any blog app that accepts Atom publishing. The blog app, then, can also accept from any client that publishes via Atom. Both of these options are appealing to me, while still allowing the Subversion to blog app as it currently is without any change from the perspective of the article writer.

So, there would be two libraries/programs then, such as it is:

• Subversion to Atom
• Atom parser to Ruby model

Ideally, this could go in the opposite direction, so that, for example, I could publish via Atom from Word and it would commit to the Subversion and update the blog app. But I’ve not really investigated Atom to know if this would all be easy enough to be worth it.

Another issue this will create is adding some sort of user privileges to authenticate when users try to post articles, etc.

There will also probably need to be another library for updating the views and public files from Subversion, and (possibly again elsewhere) the methods for allowing the views and assets to be found in the right place in the file system based on which site is currently active.

Update app to new libs

This would actually be an ongoing process, updating the blog app to move from the existing integrated libraries to the new gems, including updating for any modifications to those libraries (which will happen in at least some cases). But at some point, I need to make a concerted effort to ensure this all has happened. Which leads to…

Clear separation of app and libs

By this point, the blog app itself should be a distinct entity. It would accept publishing adds, edits, etc. via Atom Publishing, and use the other libraries as needed. But it would not be tied to Subversion as the storage mechanism, and the gem could be used in other applications.

Update versions of datamapper and merb

Another thing that will need to happen, and I’m not sure when, is to update to the latest and greatest datamapper and merb versions, and the latest svn-client lib, which does have some changes. But those will need to happen at some point, at this if not before.

Fix comments

Hey, now we get to really fix the comments, because there’s not all that other stuff in the way. Obviously, this could happen sooner. It involves two major pieces:

1. Nicer looking default views.
2. Anti-spam. I’m currently looking at reCAPTCHA. Another possibility I’ve considered is that the first time a visitor posts a comment using a given email, they would receive a validation email. Since I have no intention of actually showing commenters’ emails, this should be workable.

General app cleanup

Because, there will be stuff to clean up, right?

As a final comment, if anyone else is interested in working on this, please let me know: jmorgan at morgancreative dot net. I don’t know that this project would hold any interest for anyone else, but it would be silly of me not to ask, eh?

An honest politician is like a regular roll of toilet paper. It’s a generally accepted measuring stick, but reports of actual sightings are rarely more than urban legends.

People who get uppity about the US flag. People who make cell phone calls during movies. Cannibals. Sometimes it’s hard to decide which are the worst examples of humanity.

Right, so this thing of people freaking out flag burning, the pledge of allegiance, or flag pins is really tiring. I suppose a rant about how Christians are instructed not to worship idols would be off-topic (sorry, there’s a difference between physically following a banner, say, into battle, and actually taking offense at someone not wearing a pin of that banner). Also, can we acknowledge that very, very few people know the full lyrics to the Star-Spangled banner, and that the Pledge has only been around for about half the existence of this nation. So, for example, George Washington did not say it? Please?

But here’s how I think of the flag. It’s a symbol of our nation, particularly of the unity of the states under the Constitution. Unity of purpose is what the flag seems to most represent. At least to me. And yes, it’s a reminder of those who have died fighting for this nation, both those who fought for good causes, and sadly but importantly, those who gave their lives for ill-conceived wars engaged to meet the goals of a few politicians.

So, politicians using the flag as part of their campaign is pretty contradictory. Let’s face it, most campaigns focus a lot on divisions, highlighting them even when they’re inconsequential and increasing those divisions. Is a politician where a flag pin really respecting that flag or what it represents? I don’t think so.

In fact, for the flag obsessive that are always wanting to propose some admendment to respect that flag, here’s what I propose: “No person may use the US flag, images of it, or references to it, during the course of any campaign for elected government office.” Because these games of (and admittedly it’s often not the politicians themselves engaging in them) “I’m more patriotic than you because I wear the flag pin, or say the pledge, or whatever,” aren’t promoting unity, or indeed any of the many things that are great about the US. No, those dirty and silly games are among the greatest disrespect than be shown to that banner, or to the nation which it represents.

So, I didn’t user merb-auth for GraffitiWok, partly because it wasn’t when I started. But, actually, the users and roles was one of the more complicated and app-specific parts to GraffitiWok, so I probably would have gone the full custom route anyway.

The particularly interesting part (to me) where Board and Note specific permissions, based on two criteria: ownership of the object (an owner can do anything to that object or to its Notes if the object is a Board) and general permissions for all logged-in or guest users. Actually, the models are built to allow per-user permissions, but its not really implemented.

So, there are actually six relevant models, which I’ll review briefly:

1. User - The basic model for users
2. GuestUser - A singleton class representing an anonymous user. I’ll actually ignore this in the subsequent discussion
3. Role - A role, which just records a name and id. For example, “editor” or “poster”
4. UserRole - An intermediate model connecting a Role, a User, and a Board. That is, it says “Bob (User) is an ‘editor’ (Role) on Board #1”
5. Permission - A name and id identifying a permission
6. RolePermission - An intermediate model connecting a Role with its many permissions.

So, a User has one or more Roles for a given Board (or, uses the default roles) each of which then have a set of permissions, thus, per board, a User has a given set of permissions. The upshot of this is some meta-programming to have code like User.first(:email => ‘bob@example.com’).can_edit?(Note.get(1)). I like it, anyway.

Here’s the interesting code:

def process_permission(permission, obj)
  if obj.kind_of?(Note)
    board = obj.board
    permission += ‘_note’
  else
    board = obj
  end

  if p = Permission.first(:name => permission)
    return true if (obj.owner == self && permission != ‘create_note’)
    return true if (permission == ‘create_note’ && obj.board && obj.board.owner == self)
    ur = UserRole.all(:board_id => board.id, :user_id => self.id)
    ur = UserRole.all(:board_id => board.id, :user_id => -1) if ur.empty?
    return ur.collect{ |r| r.role.permissions}.flatten.include?(p)
  end

  return false
end

def method_missing(sym, *args)
  if sym.to_s =~ /\Acan_([\w_]+)\?\Z/
    return process_permission($1, args.first)
  end
  super
end

def respond_to?(sym, *args)
  # repond_to can_{permission}? methods if there is a permission with the
  # given name.
  return true if super

  if sym.to_s =~ /\Acan_([\w_]+)\?\Z/
    return (Permission.first(:name => $1) || 
      Permission.first(:name => $1 + “_note”) ?
      true : false)
  end

  return false
end

The process_permission method is where the real work goes on. If the object is a Note, it actually checks for a permission with the suffix _note on the given Board (with some special coding for can_create_note?). It also uses the default Roles (those for the Board where the User id is -1) if that User has no assigned roles for this Board (a similar thing happens with GuestUser).

For GraffitiWok, I think this approach has worked rather well.

So, I decided to try out git) while developing GraffitiWok instead of Subversion which I normally use for version control. I’ve been quite please with Subversion and have found uses for it beyond just versioning software development (see Wistle), but I’d started hearing a lot about git at about the same point I started working on GraffitiWok.

First and foremost, the people who still claim you can’t use git on Windows are apparently nuts. I have been doing so for nearly a year using this download. So, what have been my impressions.

I love the ability to easily add only a part of the changes in a file to a commit. I realize that running into the need to do this reveals an occassional lack of planning on my part, but it’s really nice. I also really like the ability to amend the last commit. This has come in handy several times as well.

What I haven’t really tried is the branching and merging. Most of the projects I’ve used version control for have been my own; I’ve never programmed on a team. Still, even without that, git is at least as good as Subversion. Or, that is to say, on a one person team, I’m not sure there’s a particular difference.