Since June, as part of my work for PGX, I’ve been doing on-site full-time consulting for iovation here in Portland. iovation is in the business of deterring online fraud via device identification and reputation. Given the nature of that business, a whole lot of data arrives every day, and I’ve been developing PostgreSQL-based solutions to help get a handle on it. The work has been truly engaging, and a whole hell of a lot of fun. And there are some really great, very smart people at iovation, whom I very much like and respect.

So much so, in fact, that I decided to accept their offer of a full time position as “Senior Data Architect.” I started on Monday.

I know, crazy, right? They’ve actually been talking me up about it for a long time. In our initial contact close to two years ago, as I sought to land them as a PGX client, they told me they wanted to hire someone, and was I interested. I said “no.” I said “no” through four months of contracting this summer and fall, until one day last month I said to myself, “wait, why don’t I want this job?” I had been on automatic, habitually insisting I wasn’t interested in a W2 position. And with good reason. Aside from 15 months as CTO at values of n (during which time I worked relatively independently anyway), I’ve been an independent consultant since I founded Kineticode in November of 2001. Yeah. Ten Years.

Don’t get me wrong, those ten years have been great! Not only have I been able to support myself doing the things I love—and learned a ton in the process—but I’ve managed to write a lot of great code. Hell, I will be continuing as an associate with PGX, though with greatly reduced responsibilities. And someday I may go indy again. But in the meantime, the challenges, opportunities, and culture at iovation are just too good to pass up. I’m loving the work I’m doing there, and expect to learn a lot over the next few years.

So what, you might ask, does this mean for Kineticode, the company I founded to offer support, consulting, and training services for Bricolage CMS? The truth is that Kineticode has only a few technical support customers left; virtually all of my work for the last two years has been through PGX. So I’ve decided to shut Kineticode down. I’m shifting the Bricolage tech support offerings over to PGX and having Kineticode’s customers move there as their contacts come up for renewal. They can expect the same great service as always. Better even, as there are 10 associates in PGX, and, lately, only me at Kineticode. Since Kineticode itself is losing its Raison d’être, it’s going away.

I intend to remain involved in the various open-source projects I work on. I still function as the benevolent dictator of Bricolage CMS, though other folks have stepped up their involvement quite a lot in the last few years. And I expect to keep improving [PGXN] and DesignScene as time allows (I’ve actually been putting some effort into both in the last few weeks; watch for PGXN and Lunar/Theory announcements in the coming weeks and months!). And, in fact, I expect that a fair amount of the work I do at iovation will lead to blog posts, conference presentations, and more open-source code.

This is going to be a blast. Interested in a front-row seat? Follow me on Twitter.

Looking for the comments? Try the old layout.

Yes indeed, I am back. Was I ever gone? Well, yes, I’ve been rather busy for the last 15 months.

But December 31 was my last day at Values of n. I’m really pleased with the work I did there. Sandy in particular, was a pleasure to work with. I really think that the work that Rael and I did with Sandy has been important work. Dare I say potentially paradigm-shifting? At any rate, I’m convinced that Sandy is really going to go places. If you haven’t signed on to become her client, do try. Though I will no longer be as intimate with her as I have in the past, we’re still going to keep in touch—I’m still her client. And Rael will do a great job pushing forward with her.

So why did I leave? Well, the truth is that, after Julie’s dad died in July, I found that I no longer had the resources to commit to the 80-100 hours/week required to work in a startup. It was just no longer that important to me. Don’t get me wrong, it was rewarding work, but my priorities completely realigned. It was vital that I continue helping Rael to get Sandy’s career launched, but once that was done, it was time for me to move on.

And what am I doing now? Well, first and foremost, I’m taking a few months off. I’m going to spend a lot more time re-acquainting myself with the two terrific women with whom I share a house, and just generally reset myself. Take a few deep breaths. Relax and enjoy life a bit. Sleep in now and then. That sort of thing.

That’s not to say that I’ll be sitting on my ass all the time. I have a very long list of things I want to do during this time, including catch up on my blogging (hence the title of this post), fix some bugs in Bricolage and help get 2.0 out the door, update my Perl libraries (I’ve got some great ideas for improving SVN::Notify), finally get all my digital photos organized, etc. I already spent much of last week revamping our mail system (I outsourced it to FuseMail). And all that’s leaving aside all the things Julie and I want to get done around the house. That’s the really important stuff.

But do watch for more blog posts in the coming months, too. There are a few interesting things I want to write about, and I’ve got some serious catching-up to do. Interested in following along on my adventures? Follow me via Twitter.

Looking for the comments? Try the old layout.

So, I’m thinking of implementing permissions in the Kinetic Platform differently than they’re implemented in Bricolage. Bricolage has a number of fixed permissions: READ, EDIT, RECALL, CREATE, PUBLISH, and DENY. These permissions are cumulative, so that if you have EDIT permission, it implies READ, and if you have CREATE, it implies RECALL, EDIT, and READ.

This design was based on Windows NT permissions (roughly), and has worked reasonably, well, but is annoying for various reasons. The most serious drawback is that it’s difficult to understand. I always tell people who need to manage Bricolage permissions to read Bric::Security, and then read six more times. But aside from the impenetrability of the current permissions design, it’s also difficult to add new permissions: where should they fit into the hierarchy? This is what happened with RECALL and PUBLISH, which were added in a later version of Bricolage. To this day, it’s a bit confusing to some that, with RECALL permission, you can RECALL a story but not CREATE one.

So I’m looking around for other permissions patterns. Unix is nice, in that READ, WRITE, and EXECUTE permissions are all entirely independent, and apply to three classes of objects (file owner, file group, everyone). But Unix only needs to worry about files; Kinetic applications will have many more objects for which permissions will need to be specified. RT uses discreet permissions with names like “AdminQueue”, “CommentOnTicket”, “CreateTicket”, and “StealTicket” to be applied to every user or group. This strikes me as somewhat more useful, since the permissions are much more descriptive and can be targeted to particular objects. In fact, the permission names even indicate to what types of objects permissions apply!

So I’m thinking of leaving the cumulative permissions model behind and switching to more descriptive, discreet, and potentially numerous permissions. I’m not, however particularly fond of RT’s approach of storing the permissions as strings in the database. Now, I could keep them as numbers, where each permission has its own unique number. This is similar to how Bricolage permissions work. Only I’d have to always use List::MoreUtil’s any() function to see if a permission was in a list.

For example, say that an object had permissions with the numbers 1, 2, 5, 8, 12, 49, and 50. If these were stored in an array, then every time I had to check permissions, the can_do() function would have to search through those numbers:

sub can_do {
    my ($self, $to_check) = @_;
    my $perms = $self->perms;
    return any { $_ == $to_check } @$perms;
}

This isn’t the most efficient approach, unfortunately. If there are a lot of numbers, and you were always checking one that was towards the end of the list of permissions, it’d always take a long time. So, an alternate approach–one that conveniently works well with discreet permissions–is to use powers of two for the permissions numbers: 1, 2, 4, 8, 16, 32, 64, 128, 256, and so on. Then, for a given object, these can just be stored in a single number that’s created by bit-wise ORing them together: 1 | 2 | 8 | 16. Fortunately, PostgreSQL has a nice aggregate function for this, bit_or(). (I’ll have to create my own for SQLite.) Anyway, then the can_do() function becomes much simpler and more efficient:

sub can_do {
    my ($self, $to_check) = @_;
    return $self->perms & $to_check;
}

If the value of $to_check was in the list bit-ORed into their permissions number, it will be returned; otherwise, 0 will be returned. Not bad, eh?

So anyway, I’m soliciting feedback. Are discreet permissions better than cumulative permissions? And if so, are bit-wise ORed numbers the best way to represent an object ACLs?

Looking for the comments? Try the old layout.

Last week, I went on a brief business trip for Kineticode to Alamosa, Colorado. The client was Adams State College, which is planning to use Bricolage to manage all of its content. Alamosa is a sleepy little town of 8,000 people 22 miles north of the border with New Mexico, situated in the largest valley in the world, I’m told. You can get any kind of food you want there, as long as it’s Mexican food, and the high altitude (ca. 2300 m) makes the tequila work wonders on one’s equilibrium.

Mostly I just worked with our clients, but I did manage to take a couple of photos, but I did manage to get a couple of photographs with my Nokia 6600. The “cool” coffeehouse in Alamosa is Milagro’s Coffeehouse, but to judge by their sign, I wasn’t sure I wanted what they were selling.

Alamosa has a very small airport. When I flew in on the little prop plane from Great Lakes Airlines, I was one of two passengers. On the way out (I flew through Denver), there were five of us. I thought the engine looked cool out my window, so I turned on my phone (bad David!) and snapped another shot.

Looks like I might be returning to Alamosa soon to do some training. Maybe I’ll be able to get some more pictures; the sunsets are quite lovely there.

Looking for the comments? Try the old layout.