Chad(wik)’s Musings…











{February 10, 2009}   Death to Narrow Themes

Seriously, narrow themes should be a thing of the past at this point.  This should make images and articles much easier to read.  If only I had enough time to develop my own theme.

Bah, it’d probably suck anyway!



{November 24, 2008}   Petition for Matte Displays

Just trying to pass the message along.  Apple’s recent move to remove all matte displays from its notebook line has left me with a sour taste.  I was looking forward to updating my notebook but I guess I’ll be waiting for a new Mac Pro instead.  If you’re interested in signing a petition for Apple to offer matte displays, check this one out (6000 strong so far…).



{November 9, 2008}   The Perfect NAS

The perfect home NAS, as far as I know, has yet to see the light of day.  It’s frustrating to read performance reviews of the new Drobo, which utilizes FireWire 800, and discover that it barely pushes the read/write limit of FireWire 400.  

How hard is it to make a good NAS that’s not $1000?!  NetGear’s ReadyNAS NV+ is a nice device, but I cannot justify spending nearly a grand to get a box with no drives.  It’s really frustrating to be a multi-dimensional computer user that needs a robust, redundant, reasonably-priced device to store photos, stream audio/video, and backup home PCs.  

Here’s my wish list for the perfect NAS:

  • Minimum 4 drive capacity
  • Multiple connection types: GigE (hence the “N” part of NAS), FireWire 800, USB 2.0, and optionally eSATA
  • Web management interface
  • Support for multiple file systems
  • Reasonably fast read/write speeds such that files can be copied while streaming HD videos or audio
  • Reasonable price tag of ~$500
  • Bulletproof OS which does not require fancy or advanced configuration, but can be tweaked by power users

I don’t think it’s too much to ask.  Families need a device like this to keep all of their children’s photos and videos safe and also to provide a backbone for home entertainment and productivity.

Someone make it happen!!

Update 1: Maybe we just need to save our stuff in a cloud.



{March 24, 2008}   Helpdesk
Our helpdesk system sucks.  It’s a half-cocked .NET (v1.0) app that was basically conceived as a proof of concept and left alone.  In my opinion, it hardly even meets our most basic need: search.  The importance of documentation in the area of IT support is paramount! 

Currently, the simple app performs and searches.  That’s it.  And that’s being generous with the “searching” description.  It doesn’t support tags or boolean searches.  You have to basically guess right to return any results.  We’ve grown accustomed to this searching method so much that we can cheat it to serve our needs.  This has to change!I’ve spent hours upon hours looking at other helpdesk-y applications and nothing impresses me.  I need a system that can perform the following operations:
  1. SEARCH
    • Tagging
    • Boolean
  2. FLEXIBILITY (mostly DB-related tasks requiring unique tables)
    • Must include the ability to attach multiple IT workers to a ticket
    • Must automatically update time fields (ticket created, assigned, updated, etc.)
  3. EXTENSIBILITY
    • We must be able to extend the usage of this tool to provide a framework for future webapps
The last requirement is the most important.  We need a framework that can be used for multiple helpdesk-type apps.  We have several pieces of software that beg to be converted to web applications.  There’s a prevailing hypothesis that webapps, when used on the intranet, offer enhanced security over desktop apps.I’ve spent several days just searching for a framework that will allow me to create a helpdesk application as outlined above and I’ve come up completely empty. My searches began with AJAX so as to steer away from M$-based .NET apps for a more open solution.  

Unfortunately, even through searching O’Reilly’s Safari Books Online, I haven’t gleaned any useful information to aide me in this quest.  After reading a recent article in Wired Magazine about Ruby on Rails, I’ve started to explore the possibilities of using RoR.  What’s most confusing about web development is how all of the pieces fit together.  RoR, AJAX, DHTML, HTML, etc, are all very confusing when it’s unclear how they fit together to deliver the application. The most frustrating aspect of this entire project is that the datagrid, the most fundamental component of any web application, seems to be the most elusive of all components.  I’ve found just a few examples (in various languages) but none of them appear to use SQL data and most are pricey or included in a pricey development environment.  I’ll continue the search…



I’m attempting to import our small (~300 articles) wiki into Apple’s new OS X Leopard Wiki software.  I’m using MediaWiki 1.10, MySQL Essential 5.0.24, and PHP 5.2.3 on a Windows Server 2003 box.  I’ve been following a few discussion on Apple’s Support Forums (http://discussions.apple.com/thread.jspa?threadID=1262380&tstart=0) and only recently have we talked about Apple’s Wiki Importer (only available to ADC members).  Using the MediaWiki Export Document from the Disk Image, I was unable to successfully point the tool at my wiki’s index page.  By process of elimination I determined that one bit of JavaScript code rendered the page (within the tool) incorrectly:

 // if we’re on the index page, expand the “to” links

if (location.href == appleWikiImporter.indexPageURL()) {

$$(‘a’).each(function(a) {

if (a.href && a.innerText == ‘to’) {

add_index_links_from_url(a.href);

}

In other words, when I pointed the Importer at my All Pages MediaWiki page, it displayed no page links what so ever.  Removing the above code solved the issue. 

The next step is to determine which sections of MediaWiki’s CSS need to be ignored so that they aren’t imported into Apple’s Wiki.   I should also mention that I chose to use the default MediaWiki skin (and therefore the default CSS), which is located at %mediawikidir%\skins\common\wikistandard.css.  I iterate through a couple of times to try and figure out the correct syntax for the sections to ignore and determined that Apple’s tool identifies the sections in my CSS by using dot notation.  In other words, by specifying “.footer” as a CSS Content Exception, the Importer ignored the “#footer” tag in the CSS and therefore any “footer” tag in a wiki article. Currently I’m having problems with the “Edit” field that MediaWiki puts next to any heading/sub-heading.  Also, the Importer tool is taking the fulltext of a MediaWiki article and setting that as a tag for the resulting Apple Wiki article.  More to come as I figure this stuff out.



et cetera