Results tagged “boomer.com”

I previously published an article here about using Drupal and RT together to create a knowledge base system. I've continued to improve the system and wanted to give an update on how it's working.

Of the pieces I mentioned in my previous article, I have implemented Organic Groups in the system. I have not (yet) implemented any of the other ideas I had at the time. In addition, I have used the Front-Page module, added use of the Content Construction Kit (CCK), and started adding some tweaks to RT.

Organic Groups

I have added Organic Groups to the site to operate the same kind of functionality as is provided by a SharePoint sub-site or a Trac project. Each Organic Group is a smaller segment of the whole knowledge base dedicated to a specific project or knowledge area. Organic Groups allows each user of the site to be a member of just the groups that are of use to him. It keeps membership lists for each group and also provides (some) notification regarding new content (it would be nice if content updates could be included as well, but does not at this time). Content may also be associated with no group or can be associated with a group while also being public as well.

All in all, this has been very helpful to segmenting the site.

Front-Page

I've used the front page module to setup a simple comment that goes to all anonymous users. The knowledge base is available from the Internet, but is only intended for internal use at this time. However, it is possible that someone might stumble upon it (most reading this could probably guess it's location in less than three tries and probably a majority only in one...). I wanted a special page facing out for anonymous visitors so that it would tell them to bugger off (though, in much nicer terms than that). It would also help our staff find the pages they are looking for more easily.

The front page module allows me to setup a front-page that's special to any anonymous visitor as well as having a page that's special to those who have already logged in. After you login to the site, the new front-page is a basic table of contents and list of policy documents that affect all of the group sites.

Content Construction Kit

The CCK is the future of all content on Drupal sites, as far as I can tell. Soon, the "story" and "page" and "blog" content types will just be custom content types created by the CCK. This is a good move. Custom content types has been a weakness of Drupal for sometime and flexinode wasn't quite there—in fact, it was one of those demo-turned-indispensible modules that every programmer dreads creating or maintaining.

In this case, I've used a combination of the CCK, the Category module, and the Event module to create a special content type, the "sub-project". These are a combination of "component" and "milestone," which seems to fit our web development project. Some of the features on the site can be grouped into convenient sets that all can be accomplished together. Each of these tasks are related and often feed each other, but aren't really the same task, thus are handled in separate tickets. This has been very helpful.

Each sub-project has a title, a description, and a due date (the need for the event module). These are plottable on a calendar via the event module. These are also "categories" via the Category module, i.e., nodes that act like taxonomy terms. This allows knowledge base content to be classified into these special categories. This is very cool. I have also pulled these into RT, which I will cover in the next section.

In addition to the above, I plan on creating some other custom content types for various bits. For example, I would like to build a "computer" content type to describe individual machines on our network and a "software package" content type to describe computers. These can then be used in the IT group to associated particular articles with particular computers and software packages. Thus, the CCK content types begin to take up the role provided by custom lists in SharePoint. These can also figure into the RT modifications I'm about to describe.

Auto-Complete in RT

I need to formalize this a bit better, but I have added customizations to the custom field rendering component in RT so that I can make custom fields autocomplete in the same way as they do in Drupal. I have added a "Sub-project" custom field to the Web Development queue. Then, I tweaked the component so that those custom field editors pull the available values from the available milestones in Drupal. This is the first real communication I've added from one system to the other and, so far, to work it requires you to be fully logged in to both systems (no single sign-on yet).

I'm still pretty happy about this and it certainly beats the pants of Microsoft SharePoint. I hope to have further updates as well. Currently, I'm thinking of more CCK types (as mentioned), pulling tickets into Drupal from RT so that categories list the tickets that belong to them (possibly using RT's RSS features and the Aggregator module or Aggregator2 module or some other variant), and getting single sign-on working so that we don't have to login twice anymore.

I'm also still considering some of the things I mentioned previously, though they aren't quite as high on my radar right now.

Cheers.

I want to create online communities, content management tools, and collaboration sites through the use of Open Source software, particularly using Perl-language tools.

Education (a.k.a. how much homework I did)

M.S. in Computer Science
Kansas State University, December 2004 Manhattan, Kansas

B.S. in Computer Science
Kansas State University, December 2001 Manhattan, Kansas

Attended
Manhattan Christian College, August 1996 to December 1997
Manhattan, Kansas

Publishing (a.k.a. bragging about my ideas)

Andrew Sterling Hanenkamp, "Developing RESTful Web Services in Perl," ONLamp.com, O'Reilly, //www.onlamp.com/pub/a/onlamp/2008/02/19/developing-restful-web-services-in-perl.html , February 19, 2008.

Andrew Sterling Hanenkamp, "Single Sign-on in Jifty using CAS+ (Part 2)," ONLamp.com, O'Reilly, //www.onlamp.com/pub/a/onlamp/2007/06/09/cas-single-sign-on-with-jifty-part-2.html , June 14, 2007.

Andrew Sterling Hanenkamp, "Single Sign-on in Jifty using CAS+ (Part 1)," ONLamp.com, O'Reilly, //www.onlamp.com/pub/a/onlamp/2007/05/31/cas-single-sign-on-with-jifty.html , May 31, 2007.

Andrew Hanenkamp, ¿Using Java Classes in Perl,¿ perl.com, O'Reilly, //www.perl.com/pub/a/2006/12/21/using-java-classes.html , December 21, 2006.

A. Hanenkamp, D. Andresen, ¿Heterogeneous Channel Bonding Revisited,¿ to appear in the Proceedings of the IASTED International Conference on Parallel and Distributed Computing and Systems (PDCS 2003), pp. 387¿392. Nominated for IASTED Best Paper Award in the area of Communication Issues. Marina Del Rey, CA, November 3-5, 2003.

Skills (a.k.a. Buzzword Bingo)

Bluga Webthumbs Object-Oriented Programming Perl Best Practical RT Visual Basic Ajax Amazon SQS CGI Java FastCGI REST SOAP/WSDL Jifty C++ XML-RPC CSS XSP XHTML SQL JSP/Servlets mod_perl JavaScript XML Prototype PHP XSLT Apache Drupal Amazon EC2 jQuery Trac Tomcat Magnolia SQLite Jackrabbit/JCR Oracle Python Microsoft SQL Server MySQL PostgreSQL Amazon S3 Script.aculo.us C

Experience (a.k.a. companies and people that believed in me)

Interaction Developer
Boomer Consulting, Inc., February 2006 to present
Manhattan, Kansas

• Business Development
  • Participate in strategic planning process at semi-annual firm summits
  • Recommend solutions regarding technical aspects of business plans and ways to profit from technology products
  • Provide technology solutions related to associations, classes, conferences, and consulting provided to clients
• Development
  • Use and customize Open Source content management systems like Drupal and Magnolia ECM to build content infrastructure
  • Use Open Source platforms like Jifty to build custom web applications for handling surveys, statistics, and single sign-on
  • Gather requirements, design, implement, test, and document software development projects
• IT Support
  • Manage dedicated hosted servers by installing and upgrading custom applications and other related software
  • Create server installation images and deploy and maintain server instances using Amazon EC2
  • Create documentation and handle support calls for staff and clients

Systems Coordinator
Kansas State University, October 2003 to February 2006
Computing & Information Sciences Manhattan, Kansas

• Development
  • Customize Best Practical RT for specialized issue tracking
  • Develop a custom CMS for the internal knowledge base
  • Extend Microsoft Active Directory for cross-platform accounts
  • Develop an agent-based configuration management system, integrated with RT
• Communication
  • Teach an undergraduate course on Computer Architecture
  • Help faculty, staff, students in a 250+ system network
  • Write policy, administrative, and end-user documentation
  • Manage four student staffers and one full-time staff person

Graduate Research Assistant
Kansas State University, October 2001 to October 2003
Computer & Information Sciences Manhattan, Kansas

• Use J2EE, EJB, and JSP to create a prerequisite checker
• Configure and maintain Oracle 9i RDBMS
• Linux kernel development for channel bonding (trunking) experiments
• Answer students' system and database questions

Part-time Network Consultant
Network Resource Group, Inc., October 1998 to November 2001
Manhattan, Kansas

• Develop web-based project management system using Java/J2EE
• Extend a Perl-based spam and email antivirus filtering solution
• Build PHP-based ASP tools for monitoring client email filtering
• Develop a Windows GUI application for data-entry in C++
• End-user computing, server, and network support for clients

Projects (a.k.a. pro bono work)

New Hope Church web site

• Install/maintain Drupal installation.
• Integrate layout design and improve content design
• Help manage content and policies
• Develop helps and other materials on how to use the site

Jifty

• Minor contributor to the project
• Specifically interested in Jifty::DBI object-relational mapping API, database backed models API
• Worked on class auto-generation
• Built the initial graphing and charting plugin and API

CAS+ Implementation of CAS

• Provides a single sign-on server compatible with Yale's CAS
• Written with Jifty in Perl

Crossite Module for Drupal

• Allows a single Drupal installation to share/not share nodes on multiple sites
• Makes use of taxonomy to make decisions per node

Promotional Code Module for Drupal

• Allows for registration with a promotional code
• Grants special privileges on registration (or on activation)
• Optionally strips privileges, blocks, or deletes an account when the promotion expires

Presence (a.k.a. other places I appear on the Information Superhighway)

• My Facebook Profile
• My LinkedIn Profile
• My Ohloh Profile
• My CPAN Page

Favorite Books (a.k.a. others sometimes have good ideas too)

A list of technical, non-fiction books I am currently reading or recently read and enjoyed.

• The Myths of Innovation by Scott Berkun
• Open Business Models by Henry Chesbrough
• Perl Best Practices by Damian Conway (I do not frequently agree with Conway, but he does bring up ideas that make you think about how you code in Perl.)
• Innovation Happens Elsewhere by Ron Goldman and Richard P. Gabriel

Phew! This is getting nuts. I am more busy on web development at home than I am at work. Frankly, with this flurry of stuff going on at home, I'm starting to get a bit bored with work. Well, I do want to talk about something I did at work yesterday because it was pretty cool. I've put together a knowledge base and issue tracking system using Drupal and RT. It was pretty easy and I think others might benefit from at least some aspect of the solution.

We've been using Trac to keep track of our knowledge base, issues, milestones, and source browser surrounding the web development project. For the internal IT stuff, we've been using Microsoft SharePoint. Both have had limited success. Trac worked perfect until we needed a way for web site visitors to send in support requests via email. Trac's support for this is total crud. It's still being worked upon, but after having used RT in CIS, I'm pretty hard to please when it comes to support tracker email integration. Sharepoint has worked about as well as it ever does: good enough, but it's a bit tiresome to use. If we were using the beta of the new version, it would probably be fine, but that's not trivial upgrade to perform without causing massive alterations to lots of other services we run.

Okay, so I've started to put together something that could potentially replace both of these with flying colors. It's still a work in progress, but I think I've already got something better after only a couple days of working on the problem.

First, I installed RT 3.4. After installing it and getting Sendmail configured on our hosted server, I got RT configured. I leave learning how to do this as punishment for the reader.

Then, I went in and installed Drupal 4.7 and started configuring it. First thing to do is to install all the modules. I've installed the following:

• Category. This is one of my new favorites. It is a drop in replacement for the Taxonomy module that makes every vocabulary and every term into a node. You can even use arbitrary content types as vocabularies and terms and can have vocabularies within vocabularies. It's very nice. Oh, and you can set the default item depth of a category so that it automatically aggregates children to a certain depth. Also very nice.
• Interwiki. This is kind of the best available for the functionality I'm looking for, but it needs a bit of work to get it right. Basically, you can register prefixes with it that will then be translated into URLs using a wiki-like syntax. For example, it comes configured with the prefix "w" automatically linking to Wikipedia articles. Thus, you can insert Nichols Hall and it would link off to Nichols Hall at Wikipedia. You can add other prefixes to other sites or use no prefix, i.e., foo or //drupal.org/project/pathauto">Pathauto. This ought to be a standard Drupal module. It generates paths for a node according to settings you set. I use it heavily on this site now and it's what allows us to have nice wiki-like articles on the new knowledge base.
• TinyMCE. This is a must have if you have non-technical or semi-technical staff helping you write articles. We have a content editor, Doug who understands but doesn't really converse in HTML on a regular basis. There's no need to make him when TinyMCE exists and is so easy to install and use.

That's it. I installed all of those and then went through the tedious process of setting up access controls, updating settings, etc. Now, I can create a page on the site titled "You are a foo foo" and then create another article and link to it by adding the text [:You are a foo foo
. I can use TinyMCE to format the text without worrying about learning the Wiki-syntax-flavor-of-the-month and so I won't be too afraid to show someone completely non-technical how to enter knowledge base information later on.

I added new custom interwiki prefixes for getting at RT and Trac tickets and the old Trac knowledge base articles as well for the transition period. Now, I can link to our old standards document via BoomerStandards
or to a ticket in the old system via 435
or to a ticket in the new system via 219
. I added a number of other shortcuts as well and this is really the only wiki-syntax anyone needs to know about and this is a pretty easy one to remember.

The knowledge base is now in place. Let's go back to RT. To RT, I've now added a callback to the system for the ShowMessageStanza ticket element in the RT system. That is, I created a file named "Callbacks/boomer/Ticket/Elements/ShowMessageStanza/Default" in the local hacks directory for RT. You may wish to see CustomizingWithCallbacks for more information on creating customizations using the RT callback system. Anyway, the contents of this callback is as follows:

<%perl>
$$content =~ s{(?<!&)\#(\d+)}
{<a href="${RT::WebURL}Ticket/Display.html?id=$1">#$1</a>}gx;

my %config = (

        tracwiki => 'http://trac.example.com/trac/foo/wiki/$1',

        trac => 'http://trac.example.com/trac/foo/ticket/$1',

        rt => $RT::WebURL.'Ticket/Display.html?id=$1',

        http => 'http:$1',

        https => 'https:$1',

        '' => 'http://supportkb.example.com/$1',

);

$$content =~

        s{

                (!|\\)?         # stop now if there's a ! in front

                (

                \\

\|]*):    # match a prefix like abc:, remember the prefix

                (([^\

]+))? # match a pretty name like "Blah Blah is cool."

                \]              # match closing ]

                )

        }{

                my ($escape, $match, $prefix, $link, $title)

                        = ($1, $2, $3, $4, $5);

                if (defined $escape) {

                        qq($match);

                }

                elsif (defined $config{$prefix}) {

                        my $url = $config{$prefix};

                        my $term1 = $link;

                        $term1 =~ s/\ /_/gx;

                        my $term2 = $link;

                        $term2 =~ s/\ /\+/gx;

                        my $term3 = $link;

                        $term3 =~ s/\ /%20/gx;

                        my $term4 = $link;

                        $term4 =~ s/\ /-/gx;

                        $url =~ s/\$1/$term1/gx;

                        $url =~ s/\$2/$term2/gx;

                        $url =~ s/\$3/$term3/gx;

                        $url =~ s/\$4/$term4/gx;

                        $title = defined $title     ? $title

                               : $link =~ /^                      "$prefix:$link";


                        qq(<a href="$url">$title</a>);

                }

                else {

                        qq($match);

                }

        }gex;



</%perl>

<%args>

$content

</%args>

If you're unfamiliar with Perl and Mason, you may have a migraine by now. You might have one anyway, unless you're a JAPH like me.

Anyway, this replicates part of the functionality of interwiki within RT messages by converting the [rt:123
sequences into links. This also features the ability to create links between tickets using a #123 syntax as well, which I'd like to add to the knowledge base eventually as well because I find the Trac-style linking of #123 (tickets), @123 and r123 (revisions), and [123] (changesets) to be very easy to remember and very handy.

That gets me much of the way to an integrated Drupal/RT knoweldge base/issue tracker system. I still need more though, but I haven't gotten there yet. Stuff I'd like to add in:

• Organic Groups. This would allow us to have a subsite for each knowledge base: one for internal IT, one for web development. Later, we could add one for sales information, one for content style guides, or whatever.
• Fix/replace interwiki. The interwiki module is nice, but isn't quite nice enough. It would be nice to have additional formats available. With very little effort, I should be able to create a custom filter to either extend this functionality or outright replace it just for our needs.
• Single Sign-on. I have some experience with this lately. If I can get it so that I only sign in once to Drupal and or RT and then I'm in both, that would be great. If I could implement it using an independent LDAP server, all the better.
• Configuring RT. Configuring the interwiki-ish filter for RT is done in code. This isn't ideal. With whatever solution I work on for Drupal, it would be nice if the RT filter could load it's configuration from the same place, or at least get it from a config file and not in the code itself.

Will I get all this done? Probably not, but I'll get some of it done and if I think it's interesting, I'll try to share it with you.

Cheers.

As I said earlier this week, I want to write about how I implemented single sign-on for the new Boomer.com web site. I didn't come up with the design on my own, but the implementation is from scratch and unique--i.e., proprietary. In the future, I hope to replace the system with something else but since certain aspects of our system's integration or currently in limbo and the lack of prefab Magnolia-to-Drupal implementations, a quick and dirty implementation was certainly in order. I like the results, as much as I can for a quickie, which is why I share it here.

Design

As I just mentioned, I did not invent this design myself. I merely implemented the pattern described for Cosign, a project at the University of Michigan. If my deadline hadn't been looming so close, I might have considered implementing a Drupal plugin for Cosign. As it were, though, I created a fresh implementation that has no other relationship to Cosign than the fact that I have approximately the same structure of HTTP requests and responses that it has (and probably several other implementations).

For the following use-case, I will call the web site that holds authoritative information the Auth-Site and the other site requring authentication information against the Auth-Site, the Sub-Site.

Basically, the use-case works like this:

1. The Client attempts to connect to a protected document on the Sub-Site.
2. The Sub-Site server returns a Sub-Site session cookie to the Client and redirects the Client to the Login-Checker of the Auth-Site.
3. The Login-Checker of the Auth-Site determines if the Client has logged in already to the Auth-Site. Assuming that the Client has not, the Login-Checker returns an Auth-Site session cookie to the Client and redirects the Client to the Login-Form.
4. The Client then fills out the Login-Form and returns it to the Auth-Site, which validates the login using the Login-Form-Checker. Assuming success, the Login-Form-Checker notes that the original Auth-Site session cookie came from the Sub-Site. It then performs a redirect to the original protected document on the Sub-Site that includes in the URL a Login-Token.
5. The Client then returns to request the original protected document from the Sub-Site, but with the Login-Token this time. The Sub-Site then performs an out-of-band (direct connection from Sub-Site to Auth-Site) to see if the Login-Token is valid. Assuming the Login-Token is valid, the Auth-Site returns the Client profile to the Sub-Site and the Sub-Site returns the protected document.

That probably sounds pretty complicated, but it basically amounts to the Sub-Site deferring login to the Auth-Site and asking the Auth-Site for a Login-Token to validate the user by. The major hiccup is the risk of session hijacking if an attacker happens to guess the token.

If that's still confusing, the Cosign site has a lovely sequence diagram of the interaction.

Implementation

So the actual implementation required two additional Java servlets to run with the Magnolia server (in addition to the login servlet already in place). One I called the CheckForLoginServlet. This servlet checks to see if the visiting user has already logged in. If the user has, the user is redirected from whence she came with the login token to verify her authenticity. If the user is new, the user is then redirected to the login form, which is notified of which URL the user needs to be returned to afterward.

The second servlet is the ValidateAuthTokenServlet. This servlet handles the out-of-band, server-to-server communication, which verfies the user and sends an XMLized version of the user's profile from Magnolia auth-site to the Drupal sub-site. The token itself is a UUID, which should be sufficiently difficult to guess, but might still be vulnerable to snooping attacks, since the communications aren't currently encrypted. Really, though, this is no worse than any other plain text login, which has the same vulnerabilities. We plan to move the authenticated parts of the site to SSL in the next few months to make the system stronger.

Another interesting piece to the puzzle is that I made the LoginToken objects semi-autonomous in that they erase the persistent data they store with the user objects when the session they belong to is invalidated. A user can login multiple times from differnet locations and each location will have a unique session token. When the user's session times out, the token is also invalidated.

On the Drupal side of things, I had to add a couple little hacks to get things to work just so. First, since the Drupal site is entirely contained within the Extranet, all documents are protected documents. No one should see anything on the site without logging in first. Thus, I overrode hook_init to perform a redirect to the CheckForLoginServlet unless the request came with a login token, came from a browser with an already validated session, or was coming for the cron script---which I didn't want to authenticate to execute.

If the request comes with a login token, the Drupal server performs the out-of-band check against ValidateAuthTokenServlet to see if that login token matches any current user session. If it doesn't, the user is kicked out to the CheckForLoginServlet to login again. If it does match, the user is, effectively, logged in by a special subroutine which loads their profile information from the XML passed back by the ValidateAuthTokenServlet. This also updates all the roles the user is in to make sure his permissions are correct and then drops them into the page.

All-in-all, the visitors should be relatively oblivious to the system. The only hiccup at this point that I need to take care of is to make sure that anytime the query string of a request to Drupal or to Magnolia contains a login token, that the client be immediately redirected again to remove the token from the location bar. Those tokens shouldn't accidentally end up in linked URLs if the user copies-and-pastes, or someone may find themselves logged in as the other user---i.e., bad stuff.

In the long-term, however, I will probably implement something like Cosign or CAS or SXIP, depending on how things shake out over the next few months. If we choose the right standard, we should be able to provide better integration with clients or third party apps to improve our SaaS opportunities in the future.

Ooblech. I'm tired. I better get this posted and then get some sleep.

I'm excited to announce the two new site launches: this web site and a new Boomer.com. The latter has involved 6 months of my blood, sweat, and late hours. The former took me all of today to revamp and re-re-re-re-re-release. I'm also working on launching about three other web sites in the near future.

Home Site

As I stated previously, I'm going to start toning down the development I do at home. Well, at least that was the plan. It didn't really work as I thought. I've probably spent almost as much time in front of a screen at home as at work over the last few months. The reason is related to some work I've been doing with Perl and Java---which, incidentally, might be published on Perl.com in the next few months.

I've been toying with the idea of using a Java-based database engine called Jackrabbit with a Perl web front-end called Catalyst. While that was a fun project to work on, the results weren't quite as nice as I wanted. Rather than continue tweaking it into what I want (which would probably only take another month or two of effort), I'm going to take what I've learned and move on to using Drupal again instead.

Why back to Drupal? Well, I was using WordPress, which is a pretty decent blog app. However, it's just not as easy to hack as Drupal is and I know that if I have a blog, I'll still want to tweak it, but that's not so easy with WordPress. Furthermore, I'm webmaster for the extranet site at work, which is Drupal, and our church web site, which is Drupal. I figure I can maximize my ability to maintain all these Drupals. Drupal is an excellent general purpose CMS even if it's a little bit of overkill for a blog.

I'm also starting to contribute to a number of different web sites and I'd like to have one central location to collate all those contributions and I hope to make this the place. With some enhancements, I think either the built-in or one of the other aggregation modules available for Drupal will come in handy for this. I also have a kiddo on the way and plan to share photos here. That is to say, this isn't going to be just a blog for long.

Finally, as I mentioned I did learn something from the Perl/Jackrabbit integration and I plan to use some of that to improve the user interface of Magnolia (see below) and/or Drupal. I'll probably write a blog on what I learned in the next few days so that these thoughts aren't quite so nebulous.

Boomer.com

Boomer.com is another interesting beast. I'm still trying to decide how I feel about what we've done. It looks pretty good. Though, the look will never look as good as either Eric or I want it to. Being so close to the project, I know all of its blemishes. Like home remodeling projects, when you fix something, there are inevitibly a few mistakes that bug you, but when you look at project by someone else, you never even notice them. It's the same way here: I will always know what isn't quite as nice as it could be even though almost no one else will notice.

As for the technology, we've actually built a hybrid of Magnolia and Drupal. That's mostly interesting because Magnolia is written in Java and requires a Java-based application server, while Drupal is PHP based and requires CGI or an Apache module to run. There are some tools to help PHP and Java communicate server-to-server, but we haven't used any of them, mostly because we couldn't get them to work correctly within our timeline.

However, I'm pretty happy with how well the integration works. The most interesting project related to this so far has been the implementation of single sign-on, which required some interesting redirect tricks. It works pretty well and I'm confident that our customers will be completely oblivious to the nuts and bolts of the process. I'll probably blog on the single sign-on process in another blog coming up, so look for it! ;)

Just because we launched, though, doesn't mean we're finished. There's a long list of new features to add. Since I'm not sure how much of that list is safe to tell, I'm going to just say that we hope to sell more stuff and hope to add more multimedia and hope to put up some additional web-based applications to facilitate our consulting; that ought to vague enough. :P

Other Sites

I'm also working on a few other projects. A couple of them I don't really want to talk about except to say that I'm working on them. ;) However, our church web site is one of the biggies I'm currently working on. This is another Drupal site. First, the web site is currently running an old version of Drupal (either 4.5 or 4.6, I don't remember which and 4.7 is current). Second, the church has been redesigning the look of our logo, letterhead, signage, and web site. The web design has been chosen and Eric and I will be putting that together as soon as we can.

Anyway, I'm excited about that and the fact that the church will be starting a monthly newsletter to help drive new traffic to the site. I hope this will improve communication for our members, which has been a historical problem of our church (as it is with so many).

That's what I'm working on. As I said, I'm tired and now it's time to sign off.

Cheers.

Ooblech. I'm tired. I better get this posted and then get some sleep.

I'm excited to announce the two new site launches: this web site and a new Boomer.com. The latter has involved 6 months of my blood, sweat, and late hours. The former took me all of today to revamp and re-re-re-re-re-release. I'm also working on launching about three other web sites in the near future.

Home Site

As I stated previously, I'm going to start toning down the development I do at home. Well, at least that was the plan. It didn't really work as I thought. I've probably spent almost as much time in front of a screen at home as at work over the last few months. The reason is related to some work I've been doing with Perl and Java---which, incidentally, might be published on Perl.com in the next few months.

I've been toying with the idea of using a Java-based database engine called Jackrabbit with a Perl web front-end called Catalyst. While that was a fun project to work on, the results weren't quite as nice as I wanted. Rather than continue tweaking it into what I want (which would probably only take another month or two of effort), I'm going to take what I've learned and move on to using Drupal again instead.

Why back to Drupal? Well, I was using WordPress, which is a pretty decent blog app. However, it's just not as easy to hack as Drupal is and I know that if I have a blog, I'll still want to tweak it, but that's not so easy with WordPress. Furthermore, I'm webmaster for the extranet site at work, which is Drupal, and our church web site, which is Drupal. I figure I can maximize my ability to maintain all these Drupals. Drupal is an excellent general purpose CMS even if it's a little bit of overkill for a blog.

I'm also starting to contribute to a number of different web sites and I'd like to have one central location to collate all those contributions and I hope to make this the place. With some enhancements, I think either the built-in or one of the other aggregation modules available for Drupal will come in handy for this. I also have a kiddo on the way and plan to share photos here. That is to say, this isn't going to be just a blog for long.

Finally, as I mentioned I did learn something from the Perl/Jackrabbit integration and I plan to use some of that to improve the user interface of Magnolia (see below) and/or Drupal. I'll probably write a blog on what I learned in the next few days so that these thoughts aren't quite so nebulous.

Boomer.com

Boomer.com is another interesting beast. I'm still trying to decide how I feel about what we've done. It looks pretty good. Though, the look will never look as good as either Eric or I want it to. Being so close to the project, I know all of its blemishes. Like home remodeling projects, when you fix something, there are inevitibly a few mistakes that bug you, but when you look at project by someone else, you never even notice them. It's the same way here: I will always know what isn't quite as nice as it could be even though almost no one else will notice.

As for the technology, we've actually built a hybrid of Magnolia and Drupal. That's mostly interesting because Magnolia is written in Java and requires a Java-based application server, while Drupal is PHP based and requires CGI or an Apache module to run. There are some tools to help PHP and Java communicate server-to-server, but we haven't used any of them, mostly because we couldn't get them to work correctly within our timeline.

However, I'm pretty happy with how well the integration works. The most interesting project related to this so far has been the implementation of single sign-on, which required some interesting redirect tricks. It works pretty well and I'm confident that our customers will be completely oblivious to the nuts and bolts of the process. I'll probably blog on the single sign-on process in another blog coming up, so look for it! ;)

Just because we launched, though, doesn't mean we're finished. There's a long list of new features to add. Since I'm not sure how much of that list is safe to tell, I'm going to just say that we hope to sell more stuff and hope to add more multimedia and hope to put up some additional web-based applications to facilitate our consulting; that ought to vague enough. :P

Other Sites

I'm also working on a few other projects. A couple of them I don't really want to talk about except to say that I'm working on them. ;) However, our church web site is one of the biggies I'm currently working on. This is another Drupal site. First, the web site is currently running an old version of Drupal (either 4.5 or 4.6, I don't remember which and 4.7 is current). Second, the church has been redesigning the look of our logo, letterhead, signage, and web site. The web design has been chosen and Eric and I will be putting that together as soon as we can.

Anyway, I'm excited about that and the fact that the church will be starting a monthly newsletter to help drive new traffic to the site. I hope this will improve communication for our members, which has been a historical problem of our church (as it is with so many).

That's what I'm working on. As I said, I'm tired and now it's time to sign off.

Cheers.

For part of today, I moved our internal IT support from a Trac-based system to a Sharepoint site. I'm making the move because we're starting to use Sharepoint to help improve internal communications and this seemed like a more logical place since our IT doesn't involve any need for Subversion---code repository integration is where Trac really shines, IMO.

Fortunately, we'd only been using Trac for IT support since I started in February, so there really wasn't much in there yet. We'd organized the Wiki into a few categories of information to describe computers, software, printers, network devices, policies, etc. There were really only about a dozen documents and about 20 tickets in the system, so I did all the work by hand rather than trying to script the maneuver.

For those who don't know, Sharepoint is a portal system that allows any user of the system to create lists of custom records very nicely. It's kind of like a dumbed down version of Microsoft Access for the web with some extra connective tissue and less up-front flexibility---it's just as flexible, but that requires doing a lot of extra footwork. We've used Sharepoint as a document management system up to this point, but are now expanding our use to help us in publication tracking and general project management and collaboration---the kinds of things that Microsoft itself uses Sharepoint for.

Now, in order to get this transition to work properly, I had to create some custom lists because Sharepoint 2 provides nothing close to Wiki functionality unless you want to use Word documents (yuck!) without any help linking items together. Since most of our records were concerned with computers, printers, and software, I created custom lists (i.e., tables with the CRUD forms you need) for each of these and then copied the data over (and filled in a bit more than we had before while I was at it). I then customized the prefab "Issue" list template to connect it with these lists. I copied the tickets over and added the extra comments and then created our one actual How-To document to a Word file and stuck it into a document library. After spending the afternoon putting it together, it does the job, but it's just not quite right.

What I really needed was another Wiki, but Microsoft doesn't provide one in 2.0 (the current version, though I understand 3.0 may offer such a thing out of the box) and there's really no simple way to emulate anything close without cracking open Visual Studio. There are some pay for Wiki add-ons, but while the price isn't out of reach, it's not really worth the price if I can just use a Wiki as a separate piece. There are other small annoyances in Sharepoint such as the lack of configurability or that what is configurable is really the wrong kind of configurable. I don't really care that much if I can set the width of the panels in the portal, but it sure would be nice to have an easy way of adding menus to the sidebar or topbar of static pages: sorry, no easy way to do, señor. Bah. Oh, and don't get me started on the lack of RSS/Atom syndication support in a Portal! (Though, techincally, I can write an XSL stylesheet and import the RSS as an XML panel, in this case. There's no non-programmatic way to do the export, to my knowledge, though.)

This pretty much confirms my experience with most Microsoft products. They work great so long as you conform your way of doing things to The-Microsoft-Way. When I worked to develop an Microsoft Access call database a few years back, it seemed that I spent most of my time trying to make my VB code weave through a field of "Not-The-Microsoft-Way" mines. I've faced the same issues when working with creating styles in Word or formulas in Excel or trying to configure the front page of Outlook. My favorite language is Perl simply for the fact that there's no conformance on any level. You can imagine that I don't handle this way of doing things very well.

The other issue Microsoft has is due to their hugeness. It takes a very long time to release product updates. Microsoft hasn't made a major feature release to Sharepoint since 2003. Wikis have started taking off in the corporate environment since then. Three years is a long, long, long time in the Internet Age. Sharepoint is an obvious delivery platform for a Wiki, but since Microsoft hasn't really added any features to it in three years, one can hardly expect it to have any groundbreaking functionality.

These two problems combined with my long-standing distrust of any software for which I can't find the source of a bug by reading the source are the reasons why I dislike Microsoft-based solutions. I don't really care for their business practices, but I don't really expect anything different from such a large bureaucracy.

Microsoft has a problem with agility. Their software solutions are sluggishly developed and new features are static in nature. I assume the highly structured nature of things is due to the massive testing and documentation infrastructure they've built to ensure quality (fifty or more people might be involved with adding a new method to a library), but I think this has ended up creating software solutions that feel stiff and are so often delayed months or years in delivery.

Open Source software can suffer for the opposite reason. The bigger projects seem to do alright because their is such a massive amount of contribution guaranteeing quality. The smaller projects, however, can suffer from a lack of quality because the authors don't put enough emphasis on design and testing and just hack some code together (which works for the smartest developers, but not the average folks like me).

I think Microsoft could definitely benefit by trying to streamline their process and reduce the amount of overhead required to get a new feature. Until they start putting out solutions that are a little more flexible and a little more timely I'm going to have a strong dislike for Microsoft products. Until they open the source (hah!), I'm going to distrust Microsoft products because I know I won't always be able to find the original source of bugs. That's all I have to say about that.

Cheers.

The last few months have been interesting. I've started a new job building the web site of Boomer.com. Part of this process has been reacclimating myself to Java. My language of preference is Perl and I'm still working on a few projects at home involving Perl. In the last week, we've made some decisions in which it appears as if we'll be using PHP here for some of our development as well. From these experiences, I've found that Java actually cooperates pretty nicely with these two scripting languages.

In Perl, I've written a library to connect with a Java library I'm using at work, named Java::JCR. Rather than porting an implementation of the JCR to Perl, I've actually hooked the JCR libraries from Perl. Using a tool named Inline::Java, the Perl interpreter spawns a JVM to run the Java code and then communicates with that JVM to run the necessary code. This actually works very well. After getting past the first few hurdles of getting the interface built, date conversions handled, and exception handling worked out, a user of the Java::JCR library can use a JCR implementation without worrying about any of the nuts and bolts of the interface. I'm very happy with the Perl-to-Java interface here.

In PHP, we're looking into using Drupal to make up for some of the deficiencies in our web site design, particularly in the area of community collaboration. However, we're using a JCR-based ECM, Magnolia, to handle a lot of the document and publication management. We need communication between the collaboration side and the publication side of the web site. Much of that communication can be handled through the use of RSS and other syndication protocols or through the use of RPC. However, since both of these involve serialization of data across a network connection, they can slow things down. Some features (particularly search, in our case), don't work very well this way. Therefore, we're looking at the PHP JavaBridge or Caucho Resin and Quercus to perform direct language communication between PHP and Java.

From my experience thus far, Java actually does a pretty decent job of communicating with other languages—either by RPC or even directly with inter-language communications. This involves some overhead of running both an interpreter/VM for the second language in addition to at least one JVM, but it seems to work pretty. I don't know that I can really extrapolate out to other languages in general, but from my experience and research so far, PHP and Perl both seem to work very well with Java. Since each language has it's own pros and cons, this allows me to consume pros from multiple languages while avoiding a few more of the cons.

Anyway, this has been a cool enough experience that I thought I'd share it.

Cheers.

I'm currently working on the last minute preparations for the launch of a new web site for Boomer.com. We are using a pretty decent piece of software for the side, called Magnolia. However, one issue in the Magnolia source that's been bugging me is the use of java.lang.Exception in many throws/catch clauses.

This is a pretty nasty habit that Java developers should avoid. Often when building code quickly or when you're making a lot of changes, it may be tempting to engage in this habit, but it's a fairly bad idea. Let me enumerate:

1. Catching Exception may catch errors you aren't really anticipating and handle them in ways thare aren't correct or mask them from appearing higher up in the call stack where they belong. For example, you may write a piece of coding expecting some kind of database errors that should be ignored, but you end up spending an hour ro two trying to track down a problem because something throws the infamous NPE, but you were ignoring it rather than coping with it, which led to some other problem in your code 500 lines later. Not cool.
2. Catching Exception involves treating all errors the same, which is rarely the right way to handle problems. Generally, each exception should be handled differently. For example, a database connection problem shouldn't be treated the same as a failure to return an expected result. On the web, the former might result in a 500 Internal Server Error and the latter might be better described as a 404 File Not Found error. Those are very different responses.
3. Catching Exception rather than the specific exceptions masks changes to code that will affect other parts of the code. For example, if I write a piece of code that throws errors that are generally ignored, but later come back and add another function call which adds a new exception that really needs to be handled by the caller in the 4 or 5 places the method is used, I might not catch all 4 or 5 places if my throws clause just contains Exception. This isn't smart use of the static checker to help me find places where a code change might propogate elsewhere.
4. Catching specific exceptions helps to make code self-documenting and easier to read. If all the code just catches Exception or states a throws clause of Exception, that's a really poor indicator of the kinds of errors one can expect from that method. If you also don't include any JavaDoc or wait until later to add your docs, it may take a lot of deep looking to find out what errors are really possible.

If you are a Java programmer, you should avoid this trap. No matter how tempting it is, even on code you plan to use just a few times and then throw away, you ought to think about this carefully. There've been far too many times in my programming experience where a little bit of temporary throw away code suddenly became permanent because I found it more useful than anticipated or project goals changed. I don't want to write some quickie code that I then have to go back and rewrite because I hacked it together with a bunch of bad habits, if I end up reusing it. I expect most programmers don't.

Anyway, don't code stupid. You don't want to be featured on The Daily WTF. Cheers.