Results tagged “development”

If you do any kind of application programming, particular network oriented applications or web applications (who isn’t?), you should definitely be aware of OWASP. They keep a list of the Top Ten security concerns when developing software and I have found the reference to be excellent.

• Site Link: http://www.owasp.org/index.php/Category:OWASPTopTen_Project
• PDF Link: http://owasptop10.googlecode.com/files/OWASP%20Top%2010%20-%202010.pdf

I think a printed version of the updated Top Ten is going to become a part of my standard reference kit to look over from time to time. The guide is organized and color coded in such away that just about anyone could understand why you should be concerned and what the remedies for each of the top ten issues. It provides additional links off to further information and even a standard reference library that provides an implementation reference for best practices.

Cheers.

This morning I had an epiphany about a difference in project management style between the two major development jobs I’ve held. One style was like driving an empty bus and the other was like riding in a clown car. I am going to examine both as anecdotes from my perspective and try to avoid grandiose analysis.

The Empty Bus

So, I start the job and the first thing the company does is hand me the keys to the bus. Actually, they dither on what kind of bus to give me for several months before getting me a suitable one and give me a loaner to drive in the meantime. However, once on the bus driving, I am pretty much on my own. I have a destination to reach that has been vaguely described on a scribbled piece of paper. The directions are unclear and no one in the company has been there before. They keep changing the directions. But I get to drive. That is fun.

Every now and then, I pick somebody from the company up, they make changes to the directions and then they get off again before I go very far. Every six months, everybody climbs on to the bus and sits in the very back. They do a lot of yelling while I park and then they take away my scribbled directions and give me new scribbles to follow and a new destination to reach. But I get to drive. That’s usually fun.

All in all, I am asked to develop software with very little cooperation or direction. I am left on my own to make almost all the decisions. Even though I have weekly meetings with my manager, I am not really given much feedback on whether I’m going the right way. He’s not a developer, so he doesn’t really know enough about what I do to give me useful feedback. My quarterly reviews aren’t very cooperative or helpful, they are more about the manager wishing I would drive faster and make fewer mistakes (mutually exclusive goals when you think about it).

I nearly get into a wreck a couple times, but there’s no one on the bus to help me out. Don’t get me wrong, I’m not an excellent driver. I’m still learning, but some help should help things go faster in process, you’d think. Usually, though, my directions are so unclear and difficult to follow that I am directed to get into wrecks. This is not actually all that fun as time goes on.

The Clown Car

Clown cars are funny. They drive around in circles and then the doors pop open and an absurd number of hilarious characters hop out of the little car. This job is not quite like this. It’s actually more like a really crowded minivan, like the trip I took the other day with my wife, son, dad, mom, brother, sister, and her boyfriend, all crammed into our little Pontiac Montana. But now, imagine, that all of these people have a stake in where the van goes and have a slightly role and different idea about how to go about getting there. Now, we’ve got a good analogy. Clown cars are fun, though.

The CEO’s seat is next to mine and he gets in and out of the van whenever he feels the need. He’s a busy man: lots of vans to help. Usually, he gets in right before we wreck or near the major turns to make sure we drive carefully at those point and turn the right direction. Directly behind me sits an analyst whose job it is to navigate. He tells me where to go and annotates those instructions pretty regularly. Beside him sits another analyst whose job it is to talk to the customer and figure out what they want. He then tells the first analyst and me where we need to think about going next. I get to drive, though, they keep reaching from the back for the wheel and the pedals. That’s annoying, but still fun.

Behind the analysts sit a whole team of project managers, executives, sales people and between them and between the front seats sit a bunch of other engineers. Sometimes the other engineers help drive, make suggestions, and they often critique or commend my driving. There are a lot of people in this minivan, sometimes there’s a lot of yelling about what to do next. All the activity does make for quite a bit of fun, even if it gets a bit distracting at times.

I get to drive. As I mentioned, sometimes the analysts and engineers have their hand on the wheel and help push the pedals for me. This is pretty fun too, unlike the car though, this actually gives us a lot more control. We seem to be getting places in a much more controlled way, though we do have to control our speed much more carefully. It might take us longer, but the drive is fun along the way.

Software development in this style takes away some of my freedom as a coder. That’s a bummer in some ways, not as much fun. I like control. Yet, it also lets me focus on my strengths while others worry about talking to customers, making sure we have a plan that does what the customer wants, and while the constant feedback makes it hard to see the big picture, I usually have a lot of warning before I drive off the road or get into a wreck. Overall, this is more fun.

So far, I prefer the “clown car”/stuffed minivan to the empty bus. It’s less bipolar and more slow, steady, and directed.

Cheers.

I have a certain frustration with due dates. I have determined that this frustration stems from a misunderstanding of the nature of software and their timelines. I am, therefore, banishing the terms "due date" and "deadline" from the realm of software project timelines (as a lot of software engineering literature has wisely already done) and insist that the word "milestone" be used in its place. Why?

When you decide to create a piece of software to perform some task, you are starting down a path that has no end. Once a software project is created, that project immediately takes on an eternal soul. If you want to add feature X to the software by deadline Y, you will soon find that even if you succeed in getting this feature in by the deadline you still have more work to do on that feature after the deadline. Why?

Features are nebulous little critters. Even when you think you have them well defined, you find out they are more complex once actually implemented. For example, I'm in the process of converting our server infrastructure to use a tool that will help us scale upwards as we add more clients. We aren't done once we move our servers to this new infrastructure because we'll still need to retool it and play with the optimization settings to make sure it's performing well. This will continue for as long as we have the servers.

There's no finality on a software project ever. It will always require a little more maintenance until the business decides we're not doing that anymore. Even then, depending on the project, we may need to do some level of support down the road. I would be surprised if Microsoft doesn't still get support calls for DOS or Windows 95, which have been dead products for years.

My conclusion: A software project is never finished. A deadline is not a deadline, it's a milestone. "Deadline" and "due date" imply finality. A "milestone" is just another landmark along the path, a much better description. There's always one more bug to knock out. There's always one more improvement to be made. Anyone who thinks otherwise is simply naive.

Andy Lester has issued an interesting challenge regarding CPAN. First, I have to say that CPAN is probably at least one-third of the reason I love Perl. Having a centralized, search-able, browse-able, and documentation-oriented repository of modules makes development so much easier than any other alternative I'm familiar with. In addition to all that, it has reviews, forums, a bug tracker, test result summaries, etc. That said, it is far from perfect.

There are two main complaints that I get. The first is from friends who are systems administrators. They often despise CPAN because they don't care if it helps developers easy locate and include modules. All they see is that to install some application, they have to install 15 modules, which installs another 22 dependencies for those, and then another 18 for those, and then another 12 for those, and then another 5 for those and then finally 2 more. This can take hours to build and install all of them. This is just a hassle for them.

From a developer perspective, I also have the problem that Andy highlights: which effing modules solves my problem? For example, if I want to build Subversion/CVS/Git style commands with sub-commands I could use App::CLI by clkao or App::Cmd by Ricardo Signes. Which one is better for my problem space? Both are by smart developers and both are well put together, but they are completely different implementations for a similar problem. This is something that CPAN won't help you with very much. Andy's example of XML is even more complicated.

There are other problems as well. Here are some ideas I've had that could be implemented in individual chunks that could help.

• Wikifying the documentation. This is an idea I've thought some about and even worked on designing an implementation for a bit over my Christmas break. This is basically about allowing visitors to contribute POD to a module on CPAN using a wiki-ish interface. This could improve the documentation. The challenge is that CPAN documentation is generated out of the POD stored in modules themselves. There needs some way to make sure that the POD updates made on the Wiki site can get back into the modules easily. I developed what I think would be a working solution to that problem, but requires the author to pay attention to the wiki and make sure to download the patches. Build tools could help automate this process, though.
• Dependency mapping to cluster modules. Every module contributes a metadata file that should list the dependencies required to run that module. I can think of several useful things we can do here on a large scale. We can use that to suggest which modules are more popular or better based upon how many modules depend upon it. We can use this to indicate (or estimate) how many overall dependencies a particular module has, i.e., you will need to install 184 module dependencies to use this module. We can also tie this dependency information into other features like reviews and ratings to generate other helpful statistics and heuristics.
• Incorporating use statistics. Sites like ohloh, or iusethis have a good idea in how they can rate content. It's not a perfect system, but letting a person just click a counter that says, "this is good" or "I like this" provides a very simple mechanism to rate a module. In addition, it allows you to gather statistics grouping modules again in another way.
  

None of this is a new idea. None of these are really very innovative, but I think they would be steps in the right direction toward making CPAN work better and better. If we can incorporate additional metrics into how the search works, adding tagging, or who knows what else along the way would go a long way.

I wonder if we could expose the CPAN services currently available in some sort of unified web service that would allow developers to try and enhance and experiment too. This could make it so that CPAN grows in new ways without a lot of overhead to get TPFs attention or what-not.

I don't know. More ideas...

Cheers.

I'm currently experimenting with some stuff related to using JavaScript on the server and the client. The results I'm getting are somewhat mixed. The idea I had was to see about letting someone customize some aspects of an application I'm developing that is intended to help you live more healthy. Basically, based upon the statistics of a food or other parts of the application, you could create custom metrics to measure your success or failure according to your particular preferences. (Some people monitor carbs, some monitor Weight Watcher points, others are interested in fat and protein, etc.)

I've successfully added tools that will allow you to add your custom metrics to the system using your own JavaScript snippet. This snippet is passed a object representing the food item (and eventually to include other information). I can then calculate your metric based upon the current food your viewing and your code.

This calculation is performed on the server side using Mozilla Spidermonkey
and the JavaScript
module on CPAN. On the server, this ends up looking something like this:

use JavaScript;
my $runtime = JavaScript::Runtime->new;
my $context = $runtime->create_context;
$context->eval_file('benchmark.js'); # base API library

# do some other setup of the objects I need in __tmp.food

$context->eval(

     q/function evalIndicator(food) {/

    .$user_calculation # this variable contains code from the end-user

    .q/}/

);

$result = $context->eval(q/evalIndicator(__tmp.food)/);

I've added a little more in there for error handling and such, but that's the core of how I handle the work on the server. The really nice thing here is that the user's JavaScript can't really do much bad other than a denial of service by looping or recursing internally. The server-side JavaScript doesn't include any BOM objects that could be used to do terrible things like steal user information, etc. Furthermore, if I run this code as a separate process that communicates back to the server, I can easily wipe it out if it takes longer than a few seconds to work.

Then, using a combination of Dean Edward's sandbox
and some custom hacking of my own, I can then provide on-the-fly updates from the client using most of the same JavaScript code. This allows the JavaScript to run in a relatively safe container within a hidden IFRAME.

On the client, I've implemented the sandbox in this form. I've left out some of the error handling and other details for simplicity:

// Dean Edward's sandbox in OO form:
function Sandbox(preloads) {
  this.iframe = document.createElement("iframe");
  this.iframe.style.display = "none";
  document.body.appendChild(this.iframe);

  this.frame = frames{eval:function(s){return eval(s)}};"+

    "top=opener=parent=null"+ // cut off access back to the parent

    "<\/script>"

  );

  this.frame.document.close(); // stop the throbbing

}


Sandbox.prototype.eval = function(code) {

  var sandboxObject = Sandbox.functions[this.serialNumber

;

  return sandboxObject.eval(code);

}

Sandbox.prototype.close = function() {

  document.body.removeChild(this.iframe);

  Sandbox.functions[this.serialNumber] = null;

  this.frame = null;

  this.iframe = null;

  this.serialNumber = null;

}

Sandbox.serialNumber = 0;

Sandbox.functions    = new Array();

Now that I have the sandbox to run things in, I need to setup a similar environment as I use on the server. My initial implementation embeds the user's code as a special attribute in the middle of the page, but it could be special block in the header or an Ajax request once to fetch the code string into a variable just after load, etc.

// This code runs onload, to make sure benchmark.js is loaded completely
var sandbox = new Sandbox(['benchmark.js']); // base API library

// When the user changes a value inthe page, the calculation can be made again on the fly...

var result = sandbox.eval(

    ""

  // do some other setup of the objects I need in __tmp.food

  + "function evalIndicator(food) {"

  + user_calculation // this variable contains code from the end-user

  + "}"

  + "evalIndicator(__tmp.food)"

);

Again, I've omitted some of the other details to keep this article at a manageable length. That's the gist of how I run this on the client.

Now, after I've done the work, I probably am going to drop the client-side effort and provide updates by contacting the server using Ajax-ish requests. Why? Well, I can control the server-side environment much more closely by running the code in a separate process that I can kill off if it runs away. If someone's code accidentally (or intentional) tries to do something malicious on the client, I get the blame. The browser is a much less controllable environment. They could fire off requests passing information regarding the end user off to an unknown third party or compromise something even worse if I'm not very careful. I'd have to do a very thorough job of stripping the sandbox area completely. Even then, I don't know if I can actually protect the user from a malicious attacker since there are so many unknowns regarding browser implementations. I'd need to do a lot more studying before I'd be willing to run untrusted code this way for sure.

On the other hand, this trick might work swimmingly in an environment where I trusted all the code being executed in both boxes. I'd certainly be willing to do this on a project at some point to provide calculations on both server and client using the same embedded code, which is why I'm writing the article for others. Anyway, this has been an interesting adventure in JavaScript.

Cheers.

While working at my current job, we've used three different systems to manage our projects. First, we used Trac
, which I liked very much. As we transitioned from project management into user support after the first launch of the new web site and related products we tried to use RT
for project management, which I like very much as well, but turned out to be a poor choice for what we were doing. Finally, over the past few months we've implemented a new system during Drupal
, which has been moderately successful for us. I wanted to discuss the progression briefly and explain how to use Drupal for the task of software project management.

Initially we used Trac. Trac is basically a wiki + issue tracker + code browser + milestone manager. It does those four things extremely well together. You can create wiki pages for documentation very easily. You can easily link between wiki, issues, code revisions, files, etc. You can gather your issues together in dated milestones for releases. You can track all the activity of your developers from a central timeline. All of these were working well for us. The only major drawback is that my knowledge of Python (which Trac is written in) is limited and there are things we wanted to do with it that would have required more customization than Trac is really capable of without patching it. That wasn't a show stopper. I can learn Python and we could have lived without the customizations, but it was a drawback for us.

However, Trac is not a tool that works well for end-user support since it's email integration doesn't work very well and isn't quite as transparent as I'd like. Having used RT for end-user support and loving it for that purpose, we implemented that and transitioned to RT for project tracking as well. At that point, I setup a Drupal site to sit beside the RT site to hold documentation. As far as end-user support goes, RT is the bomb. The keys, as far as I'm concerned, is the ability to logically separate support issues into queues, being able to transparently integrate email, being able to link and merge various tasks together, being able to make private technical comments on a ticket separate from replies that go out to the person with the problem (that's a killer feature), and having lots of flexibility when it comes to building email templates and triggers that send email on comment... oh, and really, really, really flexible access control. I've not seen a system for incident tracking with end-users that even comes close (not that I've seen many such systems). I've also made quite a few customizations to the system to make it more useful for us.

As far as project management goes, the RT-Drupal combo was a failure. It caused a lot of headaches, there was confusion about what was happening, and we really didn't store much of any documentation in Drupal. We should have added RT as an end-user support mechanism and kept Trac in place without modification. Had we done that, I don't think we would have implemented the Drupal system we're using now, however. Basically, I/we decided that trying to use RT to track our software projects wasn't working for us.

I suppose we could have found a way, but we decided instead to give the Drupal Project and Project Issue module a try. This decision was made for several reasons. First, we'd made a strategic decision to use Drupal as the new base platform for our central web service, the Boomer Knowledge Network
. By reusing Drupal for project management, we could more effectively reuse our knowledge and even try a few things out on the support site that could be copied on the BKN. We weren't sure it would succeed and we might have switched back to Trac again if it hadn't.

However, our use of Drupal with the Project and Project Issue modules has worked out better for our purposes at this point than I think Trac would have. The Project module for Drupal provides little to no value on it's own for us except to break up our various software projects into chunks. The Project Issue tracker, on the other hand, has all the power we need. The only major drawback at this point is the inability to assign another user to an issue //drupal.org/node/4354">http://drupal.org/node/4354, perhaps, eventually they will even agree on a fix and apply a patch!
. Other than that, it can track pretty much anything we need it to in a way that fits our team's development style [# Our development style bears some vague resemblance to Agile, but much less formally structured].

The thing that's really helped though is Drupal's CCK module. This is a customization tool that allows you to add custom fields on nodes. The Project module has a system for building releases and such, but it's really strongly geared towards how Drupal's core, theme, and module code is released, which isn't precisely the way we release our work. Rather than using it, we built our own system by building a custom Release node and then associating custom fields to link that node to a project, setting a status (in progress or deployed), a planned delivery date [# usually within 2 weeks], and a list of references to issues that should be completed on release.

We then reconfigured the states that they are defined for issues so that we have a "fixed / ready to deploy" state and a "deployed / completed" state to match with our releases. Those working on a given release can change the state of all the issues to "ready to deploy" as soon as they get everything on that issue complete. Once all of them go light green, I "schedule downtime" [# I.e., I do it late at night when our members are asleep] and perform a code push and do all the configuration necessary to finish the production release [# Usually, this is a 5 minute process, but sometimes as long as 2 or 3 hours]. Then I can mark that issue as resolved.

We also have some documentation in the system, but we're not doing as well here as we probably could. I'm also starting to build some tools using more custom node types with custom CCK fields to handle idea gathering. I'd like team members to be able to visit a site and share that link in a way similar to Digg or Delicious within the office and I'm already a good ways along on that. We're building a review system so that other staff outside the team will be able to comment on screenshots and comps so we can develop a feedback system.

I've also figured out a way to get the timeline back, which was a feature I really liked in Trac. Using the Drupal news aggregator, I can pull the feeds for code commits, issue creation, releases, and even comments [# via the Drupal Comment RSS module]. Unfortunately, I haven't found a way to pull issue followups in a way similar to Comment RSS so those are missing still, but I may just build a Followups RSS module if I have to.

Anyway, I'm pleased with how the project modules are working in Drupal for us. It's a little more flexible than Trac is (IMO) and since I'm very familiar with PHP [# I'm unfortunately familiar with PHP, which is a language I just don't like for both idealistic and emotional reasons.] and with Drupal [# On the other hand, even though Drupal is written in PHP, much of its design both internally and aesthetically is quite nice.], the code customizations are a piece of cake.

Well, that was a lovely ramble. That's what I get for writing so late after working all day....

Cheers.

There's a pretty decent article over
at A List Apart on relationship management by Keith LaFerriere from a couple weeks ago (catching up on some of my reading). I enjoyed the "Hat Head" versus "Bed Head" comparison, particularly since I'd definitely qualify myself as a "Bed Head" in my attempt to live a creative lifestyle. Though, as a developer, my idea of a creative lifestyle is probably a little different from the conception of a typical designer (less coffee and black turtlenecks and more Dr. Pepper and not-shaving).

Anyway, he makes several very important points that I think everyone in development and design need to adhere to more.

• Don't take things personally. Yes, you are being creative and it is important to you, but if you're making money doing it, you need to have a professional attitude and be willing to compromise.
• Be an example, particularly if you're the team leader. It's really amazing how much the behavior of a person is determined by the people around him. If you get ticked off every time someone does something you don't like, people around you will probably start having at least a kernel of similar behavior. This goes doubly so for managers and leaders. Your behavior sets the tone the rest of the group will judge itself by. Be good.
• Watch your language. By this I'm referring to trying to be what I would call "open-minded language." If you indicate by the adjectives you use that you're not listening or don't intend to, you will convince no one of anything. Avoid strong adjectives and try to talk as if all the options are still open even if you're already on a specific path. You can make it clear that a bad idea isn't going to fly without insulting your audience.

Anyway, I just wanted to post that link and give an infinitesimal boost to what I consider to be a good overall article on getting along with coworkers and getting the job done as a team.

Cheers.

I'm currently in hurry-up-and-wait phase and rather than go back and edit yet-another-script I'm working on, I thought I'd make a short post about the projects I'm hoping to work on, but I haven't got time for just now.

Blog Reload

The first major project I'm working on is my blog reload. I've posted an early version of that here
previously. The development version is quite a bit further than the published version is, but I've reached that point where I can't really release anything until I tie up some loose ends (e.g., I have a blog component on it, but no comment component).

This one also happens to be the base tool I'm using to work on another project...

Gentle Birth Doula Services

A friend of ours, Rachel, recently started a web site
to go with her new hobby/business. She's taken the training and now either very close to or already officially licensed as a doula.

For those unfamiliar with modern labor and delivery practices, many people now hire an additional helper for labor and delivery called a doula. A doula is not a nurse, but just someone with knowledge of the birth process that can give aid to the mother during the process beyond what care is provided by the birthing center or hospital nurses. (For example, being available prior to going to the hospital.) Actually, that's just my understanding and I'm probably off a bit.

Anyway, Terri and I are helping her fix up her new web site. I'm going to give her the software I'm using to build my web site reload and then work with her and Terri to make it look better.

Sermon Illustrations

A few months ago a pastor, Monte, in North Carolina contacted me out of the blue about the possibility of starting a web site for collecting sermon illustrations ala social networking. It's a good idea and I'm still interested in it, but it's stalled out. I hope to make some time for it over the next few months. We'll see.

Jifty Book

I caught Chromatic and Jesse Vincent at OSCON and I suggested that Jifty really needs a book. I'm slowly working through a table of contents for it. I'm also hoping to get some time for it in the near future to get back to work on that idea. I really like writing and would love to do that more.

Software Ideas for IRC Bot Nets and POE

Something I've been building at work as sparked my interest and I'd like to combine somethings I've learned from using Jifty and from using POE to build an IRC Bot Net to build a better tool for building Bot Nets for various things. I've had a fascination with multi-agent systems since I took a course on the subject during grad school and I'd like to apply some of my knowledge from there as well (i.e., designing robust multi-agent communication protocols).

If I could, I would like to publish an article on the subject, but my previous outlet for such, OnLamp.com, may not be accepting articles of that kind anymore since their trying to produce higher quality content.

Expansion of Contentment

I'm thinking about ideas of taking this blog to the next level. I'd kind of like to expand it beyond just me and get other authors posting here. What that looks like, I don't know, but I'm thinking of possibly making it into a place where Christians working in web, design, and IT can get together to talk about what they're doing and what Christian Service in the modern workplace looks like.

Okay, looks like my tests have finished baking, so I need to go back to previously scheduled overtime.

Cheers.

Drupal
is by far my favorite CMS, despite the PHP (or poohp as I tend to pronounce it). One of the places Drupal is strong is organization, as long as you want to organize everything in a web. It does provide hierarchies and has breadcrumbs, but these are where Drupal begins to show weakness. In this articles, I'm going to explore how Drupal organizes itself and how you can take advantage of that organization out of the box, or with some module help, or by custom hacking. It's a summary of the research I've been doing on the topic.

Organization

Organization of content in Drupal, as shipped, primarily operates in these ways:

• Follow that term. You click on a post in a list and see a list of categories (formally "terms" in Drupalese) associated with the post. You click on one of those and you can see all the other posts on the site that are like that one.
• Order from the menu. You can assign a page to one or more menus, which are just hierarchical lists of links. If a menu item on the screen matches what you're looking for, clicking on it will take you to the node, term page, a list, or whatever the link points to.
• By the book. Pages can be arranged in ordered hierarchies, like books. If you look at a page in one of these organizations, you can click on the sub-pages or go to the previous page or the next page or up to the next level from any page here.
• Follow that forum. Forums are really glorified category terms.

That's it. Those are all the organization options you have built-in.

Caveat Emptor

However, there are some inherent gotchas that newbies aren't always aware of. The first is that the breadcrumb is pretty weak in Drupal without some help. This usually reveals itself in a scenario like this (this is approximately how I ran into it). A newby downloads and installs Drupal, logs in as administrator, and goes to create his first vocabulary (a custom system of categories). He creates a hierarchy and adds a bunch of terms. He finishes and adds a test node that has one of the category terms set that has two or three parents. Let's say, "Food > Fruit > Citrus > Orange". However, rather than seeing a breadcrumb on the node view that reads "Home > Food > Fruit > Citrus > Orange", he just sees "Home". If he's like me, he's confused but just assumes he did something wrong. He tries clicking on the "Orange" term to see the breadcrumb there. The breadcrumb turns out to be exactly as expected, "Home > Food > Fruit > Citrus". That means if someone gets that term and clicks on the test node, the breadcrumb that should, intuitively, expand one level deeper completely evaporates.

The problem is that this is a misunderstanding of the purpose of the taxonomy system. The taxonomy system does not provide any structure for the nodes. It provides some structure for itself, but the nodes themselves still belong at the top. It's a completely flat structure. Structure is provided to nodes in Drupal core in one of two ways: the Book module and the Menu module. Which way is appropriate for your site will depend on your needs. Also, neither of these may be satisfactory, but we'll get to that in a bit.

Book Solution

The first mechanism provided by Drupal is the book module. This module allows any node to have a parent. To use the book module, you must first enable the module, configure the permissions, and then create a Book page. The first Book page will be at the "Top Level" meaning it starts a new "book". You can then create additional nodes that are in the tree. The top must always be a Book page node type, but the rest can be any node type you like, but you have to go through the extra step of configuring the node via the Outline tab after your create it. Update April 21 @ 7:28pm: I just realized this is an error. I forgot about the Outline tab. You can make any page the root of a book via the Outline tab. (Book pages automatically have the "Parent" option configured on their create form.)

If you look a the breadcrumbs of Book pages, they operate exactly as expected. Each breadcrumb is created by traversing the list of parents until it gets to the top level and then adds "Home" in front of everything. The book module can also provide a hierarchical list of pages that looks like a typical Drupal menu as well via the Book block that comes with the Book module.

This is, by far, the most common sense method for hierarchically organizing your site's content. However, if you need special content other than the book pages you have an extra step to make it work. If you need to organize non-node content (special forms or something) the Book module may not be any help at all. Also, a single node can't belong to multiple books. A node may only have 0 or 1 parents in a simple hierarchy.

Menu Solution

An even more flexible solution is through the Menu module. The Menu module allows you to create Menus, which are hierarchical lists of links (it allows you to manipulate the built-in menu items as well, but that's another topic). These links may be to nodes, terms, or anything else on the local site that has a URL. They may also be absolute links to get to locations on other web sites. Each menu item has exactly one parent, but since you're only creating links, you could have a single node or other item linked in as many different menus as you need.

Furthermore, creating a hierarchical menu also tweaks the breadcrumb. If you have a node that would otherwise appear at the top level (i.e., it doesn't belong to a book), the first menu it is listed in will be used to create a breadcrumb for that node. Therefore, if you had a taxonomy structure with a matching menu, you could fix the problem of having your node appear without a breadcrumb.

Unfortunately, this too comes at a certain cost. You must maintain the menu structure manually. You have to add each node as it goes. If you have a taxonomy structure to mimic, you have to do double duty on your data entry and then make sure your menus point to each new node you create.

Setting up the menu while creating a node is pretty easy for an administrator. Anyone with permission to administer the menus can setup the menu for a new node via the "Menu settings" box on the create page. However, if you want authors to be able to do this without being able to tweak the entire menu structure, you're out of luck. You either grant someone the right to manipulate everything or nothing, which isn't acceptable in many situations with more than a few authors.

You can address this issue by looking into the Menu Subtree Permissions
module. This allows you to grant edit access on parts of menus to certain roles.

Add-ons

There are many, many add-on solutions for handling this. I'm going to give my favorite choices and then list the others I've found. This is not a complete list, but it does highlight the modules I've examined a bit in my search for a solution.

Taxonomy Menu

A solution that uses the combined power of taxonomy and menu is available in the Taxonomy Menu
module. This module creates a menu item for each taxonomy term in the system. This automatically gives you both downward navigation through menu items and upward navigation through breadcrumbs. This isn't quite as good as the navigation provided by the book module, but with intelligent use of the sticky flag or manual items, you can come relatively close.

Add on Custom Breadcrumb

Another way of handling the breadcrumb is via the Custom Breadcrumb
module. This module allows you to associate a breadcrumb with a node based upon it's node type. For example, if you have event nodes that always needed to appear in "Home > News > Calendar > Events," then you can use the Custom Breadcrumb module to do this. If you need a more variable structure than this, then Custom Breadcrumb still doesn't do it.

Others

Here are some other add-on modules that you may wish to consider:

• Taxonomy Bradcrumb
  . This module provides half the abilities of the Taxonomy Menu in tweaking the breadcrumb. It does not, however, provide any way to navigate down to the items in the tree, just the parents on the way back up.
• Category
  . For the daring, there's also the Category
  module which provides a complete replacement system for the core Taxonomy module, Book module, and provides a special menu module for creating menu items automatically on the creation of nodes. However, this is a big module with lots of options and I've back off from using it because it's almost too powerful to figure out how to use it most effectively. I've had some trouble getting it to work really well.
• Pathauto
  . This module doesn't actually help you organize your site, but it can makes your URLs match your breadcrumb organization structure. I highly recommend this module to make your URLs pretty. However, be aware that the URL aliases can quickly clutter the URL Alias page if you have a lot of pages.

• Theme Hacks

  If you do a search on the Drupal site for "breadcrumb" you will come across several hacks to the theme. All of which are customizations that make use of drupal_set_breadcrumb()
. You pass that function an array of links and it will give that array of links to the page template. This is the ultimate solution if no other will work for you.

  However, again, this still only gives you the upward navigation. It doesn't provide any kind of downward navigational structure.

  Conclusion

  Drupal does provide ways for organizing your content, but some of the out-of-the-box methods may not be ideally suited for your situation. Drupal comes out of the box with excellent support for web-like and river-of-news style organization. Hierarchies are quite possible and can be managed, but the structures provided for such assume a relatively light amount of hierarchical information. However, by using a few modules and the taxonomy structure, you can create very flexible and functional hierarchies to suit any site structure.

For the past few months or so I've been dinking around with CAS
and OpenID
and a few other protocols for web single sign-on
. The reason for this is primarily because at work we run a multi-platform web site. For the main content portion of our web site we've been using Magnolia
and for the community side of the site we've been using Drupal
.

It's kind of an odd setup, but it works. The structure might change in the near future, but that's a different story. We've got a few other products and services that we're also building. However, we don't really want members to login multiple times whenever accessing a different segment of the web site. This is where single sign-on comes in.

For the initial revision of the work I created a homebrew solution of single sign-on. It's immature, it doesn't really handle some of the security concerns it really ought to, and it's maintained only be me. Needless to say, this was a quick and dirty rather than ideal solution. The plan all along was to create a tool that could provide a single sign-on service in a standard way so that we didn't have to do much, if any, of the maintenance.

My research led me to conclude that CAS (Central Authentication Service), created by Yale, is really the best solution available. There are several others out there including Cosign, Crowd, OpenSSO, and others. CAS is the most widely supported of these schemes and it implements a very robust, simple, and functional protocol.

The major drawback to CAS, for me, is that it is written in Java. This isn't a terrible issue at work since we already use a J2EE server to support Magnolia. Yet, my experience with J2EE servers (even the ones that are just servlet containers) has led me to believe that they tend to be more difficult maintain than Apache with CGI or FastCGI add ons. Furthermore, I have some interest in using CAS on my own web site, but don't have the means to host a J2EE server without changing how I host my site (and I'm very happy with DreamHost
).

Therefore, I decided to see how difficult an implementation of the CAS server protocol would be in a different language. It was not difficult. The protocol requires fewer than 10 HTTP request/responses to be implemented and the processing required to build those actions is straightforward. Viola, we have CAS+.

CAS+ implements the complete CAS 2.0 protocol. As far as I can tell (without asking as I haven't contacted anyone in the CAS realm), the CAS 3.0 protocol does not exist or does not differ from the core of CAS 2.0 in that it consists only of aspect-oriented hooks to extend CAS+.

My plans branch further in that I want CAS+ to be a more general solution to this problem than CAS is. CAS is meant for use in a totally secure environment, whereas I'm willing to sacrifice a few things for additional flexibility. I've implemented CAS+ in Jifty
and am using CAS+ as a test bed for the work I'm doing with Jesse Vincent on the "virtual-models" branch of that product. Finally, I am thinking of building CAS+ into a more general authentication solution. There's no reason why it couldn't also support some of the other SSO protocols that exist and I would love for it to be an authentication source and sink for distributed authentication protocols like OpenID.

Okay, so that was kind of a meandering way to introduce CAS+. If you're at all interested, feel free to check out the Subversion repository where it's hosted. This is the only project resource I currently have for accessing anything about it. If you want help with it, you can use the Jifty developers mailing list (see Jifty.org
for information) or see me, zostay, in "#jifty" of the freenode IRC server.

Here are the important links:

• Via Subversion: //svn.jifty.org/svn/jifty.org/CASPlus/trunk
• Brows the Web: //svn.jifty.org/jifty.org/CASPlus/trunk