Website Updates

Working with Ross on a massive website redesign.  This redesign is brought on partially from complaints of website users about the disparate nature of the content, and the difficulty in finding relevant information on the site.  A recent hard drive failure on our web host's server which resulted in some loss of content was also a contributing factor.  We hope to have something up next week.  The site will actually be broken into multiple sites to allow for better organization.  Drupal will power two of the sites--the CUWiN main site, and a second specifically for the local network.  Two additional sites will be created using wiki software.  One will be a private wiki to document the organizations infrastructure and to store other private documents.  The second will be a wiki for the developers.  It will focus on bug tracking, software documentation, etc.  I'm considering using Ikiwiki (www.ikiwiki.info) for this, as it is simple, and integrates with the code repository.  Hopefully this will make it easier developers to incorporate the wiki (and documentation) into their work flow.

Filed under:

Matthew Isaacs's Recent Field Reports

Drupal "Hacks"

As part of the website redesign, we're adding new sections for user generated content.  We needed to keep this content separate from the rest of the site, so that any user could edit the user sections, but not the rest of the site.  For basic content types, this is simply a matter of defining a new content type based on the standard drupal "node", and then assigning the correct permissions to that new type.  But what if you want to do something similar to a more advanced content-type such as a book?  One could extend the book module to support a similar derived content feature (best solution).  But that can take a fair amount of time, and with no guarantee of changes being accepted upstream, you face the possibility of either running outdated module code, or having to reapply your edits for every update.  A quicker, and much simpler method, especially for those with little programming experience, is to make a few, essentially cosmetic changes to the book module.  These changes consist primarily of changed the names of the tables the module stores its data in, and the internal name that drupal uses to identify the module and its components.  And while your modifying, you can easily alter the human-readable names and descriptions.  And its all as easy as Find & Replace.   …read more

Website Updates

Working with Ross on a massive website redesign.  This redesign is brought on partially from complaints of website users about the disparate nature of the content, and the difficulty in finding relevant information on the site.  A recent hard drive failure on our web host's server which resulted in some loss of content was also a contributing factor.  We hope to have something up next week.  The site will actually be broken into multiple sites to allow for better organization.  Drupal will power two of the sites--the CUWiN main site, and a second specifically for the local network.  Two additional sites will be created using wiki software.  One will be a private wiki to document the organizations infrastructure and to store other private documents.  The second will be a wiki for the developers.  It will focus on bug tracking, software documentation, etc.  I'm considering using Ikiwiki (www.ikiwiki.info) for this, as it is simple, and integrates with the code repository.  Hopefully this will make it easier developers to incorporate the wiki (and documentation) into their work flow. …read more

Automated network upgrades

 Another recent  project has been automating the firmware upgrade process on CUWiN nodes.  To accomplish this I've hooked into the upgrade script present on each node.  I've added a script to be on each node that functions in one of two ways: 1) automatically checks for updates and runs the update process, scheduled through cron and 2) a remote "head" initiates the process and tells a set of nodes to check for updates and perform the upgrade if necessary.  The nodes query a webserver for a list of updates.  The webserver contains a list of id's and version numbers for those id's.  A node retrieves this list, finds its id (not necessarily unique), and compares its version number to the one listed.  If the one listed is newer, it dowloads the file specified and runs the upgrade.  Once the upgrade is complete, the node reboots (if run directly), or schedules a reboot for a random time in the future (automatic mode). …read more

Community Map-builder

I can across an application that allows for community built apps.  I'm considering its appropriateness for some of the mapping functionality for CUWiN.  http://communitymapbuilder.org/display/MAP/Home