Developing Programmers .com

When I was still in school, I tried writing my first text editor. The biggest limitation I was up against was that output to the terminal was extremely slow.

I got clever: I wrote a display engine that’d take where the screen was at now, and where it wanted to be, and figure out the smallest possible change to update it. This meant that depending what was on the screen, scrolling might involve asking the terminal to scroll, or if it was lots of similar text it might just tweak a character or two; depending which required least time to render.

It was a really cool idea, and an over-engineered disaster. The program took so long working out what was “optimal” that it didn’t matter; it was slow anyway. I’d have been better off taking a simplistic approach, for example just updating whole lines that changed; or even not worrying about it until I got a handle on actual speed, then tweaking from there. Sadly, the “cool trick” was so central to my initial design it was hard to replace.

I’d been blinded by a perceived optimization need, and made the mistake of optimizing early. It’s only relatively late in development you can clearly see where time is spent, and where it matters.

Since then I tend to do things the “simple” way up-front; and just focus on keeping the code clean & modular so I can replace the parts I need to at the end for any optimization tweaks.

Now I’m working in a team, and more than ever “optimizing for simple” is paying off bigtime. When I get questions, they’re usually about the places I haven’t simplified or honed down to the basics adequately.

While having a look at Liquid Planner recently, I stubled across this article. The gang at LP outline strong reasons to try to finish one project before moving on to the next. Even ignoring the substantial time it takes to “context switch” to a new task, the benefit of single-tasking is that you get something finished & usable, sooner.

As you’ll know if you’ve been following Joel On Software, Joel and Jeff Atwood have recently launched “Stack Overflow“, a Q&A site of programming questions with answers that are voted up or down.

As well as being generally worth a look, I thought DP readers might find this thread especially useful, it is about the “one piece of advice” programmers wish they had received at the start of their career.

I recently finished reading “The One-Page Project Manager”, by Clark Addison Campbell.

What Clarke offers is a credible way to report a project’s status in a readable way, to managers, stakeholders and to provide feedback to the people working on a project. The one-page summary he suggests is not ideal for me, but has provided some great ideas I plan to work into my own methods.

Although Clarke is able to summarize the status of a project in a page, either he unable to summarize how his page layout works as concisely, or he was unable to get his book published as just a booklet. The information in the book is worth the price, but not worth wading through drawn out explanations that could have been summarized in perhaps 5-10 pages.

The website provides enough information (if you poke around) to see what is on offer and evaluate whether it will help you. In fact, more than half of the book’s contents can be inferred by viewing the site. The book does have a few (but only a few) things to add.

My rating: 3 stars (out of 5)

I recently did some digging in the Subversion source code to find out answers to precedence questions that remained after re-reading the documentation for Subversion’s per-directory permission files (popularly referred to as ACLs). At work, this helped us a lot with ensuring our new graphical UI for permissions (an excellent tool developed by Mark George) would exactly match the meanings of these files. In this article I’ll provide a short summary of the docs to catch people up, and then explain what I had to find by digging.

Subversion has a “per directory access control” file format, used by mod_authz_svn. It is documented in full here, so I’ll just give crash-course coverage to refresh a few memories.

Basically it’s an “ini” format file, where the sections specify paths and the data within each section specify which users or groups have what access to that path. For example:

[/]
*=

[repos1:/trunk]
@developers = rw
sarah = r
*=

[repos2: /branches/foo]
@reviewers = rw
@developers=r
*=

This starts by saying the root directory in all repositories is off limits to everyone. It’s a simple blanket rule to cover whatever we don’t spell out in further rules. The next section says that for repository 1, the developers group has read & write access to /trunk, sarah has read access, and anyone else has no access. Finally, in repository 2, only reviewers can write to /branches/foo, but developers can look in to see if their code was cleaned up or to merge changes back.

Now for what this article is really about: The ambiguities inherent in this format. For the most part, ambiguities are easily avoided. Especially if you read the highlighted note in the documentation:

The thing to remember is that the most specific path always matches first. The server tries to match the path itself, and then the parent of the path, then the parent of that, and so on. The net effect is that mentioning a specific path in the access file will always override any permissions inherited from parent directories.

OK; this tells us that permissions given in [/foo/bar] can be taken away again in [/foo/bar/restricted]. But what if the permission is in [repos1:/foo/bar] and the other just in [/foo/bar]? And, what if a user is effectively (via groups) or explicitly (by name) mentioned twice in the same path section, or if there is no “*” rule? The documentation leaves enough said that you can avoid these ambiguities, but when the going gets tough or when you’re writing an interpreter to match Subversion’s reading of this file, more detail is needed.

This chart, which I came up with for my work at cvsdude, covers these edge cases:

(Image Copyright 2008 CVSDude; used with permission)

As you can see, Subversion starts by finding the most specific config section that mentions the user in question or the anonymous user.more-specific paths coming first does extend to [repos:/foo] coming before [/foo]. However, [/foo/bar] trumps [repos:/foo] because its first priority is longest matching path. And of course a more-specific section is only relevant if it includes the user, a group they’re in, or has a *= clause.

Once the right section is found, subversion then checks what permissions are granted to the user by this section. The result is an OR of permissions granted by each line; so if the user is in two groups, and one group is given R (read) permission in the relevant section, and the other given no permission, the user ends up with read permission.