Kyle D. Skrinak

I’m slow to upgrade my OS as I prefer stability to running the latest version of code. As of 2 days ago, however, I have taken the leap to Snow Leopard (now at 10.6.2) and I am very pleased with stability and the reduced footprint of the OS. Also among my upgrade concerns is my MacPorts installation. I have a few ports that I need to have available. This time, my MacPorts migration was the smoothest yet, too. After googling, I first found this blog post about the author’s upgrade, but after reading the blog’s comments found a more reliable (not necessarily more simple  but well worth the added time) way to make the upgrade:

1. Reboot and boot using the Snow Leopard DVD.
2. Before running Snow Leopard, perform a “Disk Repair” in disk utility.
3. Run the Snow Leopard upgrade process. Both of mine were at least 45 minutes; I didn’t stick around for the upgrade.
4. After completing the Snow Leopard installation install the XCode from the Snow Leopard DVD. (This step is important)
5. Run Apple’s Software Update (have broadband ready or expect to wait for the download)
6. Download the latest MacPorts for Snow Leopard disk image.
7. Then follow the steps at the MacPorts migration page.
   1. port installed > myports.txt
   2. sudo port -f uninstall installed
   3. sudo port clean –work –archive all

This process does take up some time, but I reloaded my entire MacPorts without a hiccup, which was nice. Also nice is that my 10.5 MacPorts list contains a number of ports I no longer needed, so the cleanup was overdue. I saw none of the dependency or other issues that can happen with MacPorts.

There’s so much more to this, but the details of such are outside of my normal scope; so I’m simply noting this:

If you have a apache 2.2.14-served directory from which you intend to have PHP script interpreted within your *.html files, you must except this directory from your Phusion Passenger environment.

The head-scratcher for us was this: http://www.website.com would show the HTML with the unintrepreted PHP code, BUT http://www.website.com/index.html would properly interpret.

This was a real head-scratcher for the CTO for one my clients and myself when we discovered that subdirectories of our main “web-brochure” site were under Phusion’s control. We simply moved that directory to a new location, outside the environment’s paths, and this solved the problem. It appears that  you can use apache directives to achieve the same result, though I couldn’t.

xamp 1.7.2 ships with php 5.3, which is known to be incompatible with Drupal 6.14. You must use 1.7.1. There. I just saved you a couple hours of troubleshooting.

I blogged earlier about my move from dotproject (dp) to web2project; (w2p) read more there for background. The goodness continues. Whereas using dp allowed me to integrate my project tasks with company info, I have now eliminated  the need for slimtimer, a web app for tracking hours. Slimtimer is an excellent web app for tracking hours to activities and has excellent reporting features and I continue to highly recommend it. What bothered me with using slimtimer was cost and project integration. While it is free, the programmer fairly asks for donations. there are a number of alternatives (Quickbooks for example) that I can use to track project hours for free; while slimtimer is a solid, well-programmed application, it wasn’t worth my making a donation. Alas, I didn’t feel I was quid-pro-quo with the application’s programmer. Secondly, and more importantly (as it turns out) is the integration of task hours, task description against the specific task in my w2p application.

Where w2p doesn’t offer the same detailed start/stop hours tracker, the time recording offers “just enough” data to be usable. However, the integration of task hour recording with description and project info is critical to making it much more informative in the context of the overall project. Whereas I lose start/stop times, I gain recording the specific activities I executed ,which also allows me to make the project’s tasks more generic, thus reducing the documentation overhead while keeping the data relevant for billing and project summary documentation.

Score another point for w2p. The beauty of w2p is that it’s model has made project management for my company more easy to manage. The redesign by the w2p team has helped to reveal functional aspects that might have been available in dp but now make sense in the broader context of usage. I recently wowwed a client by setting up a project site for one of his projects in 30 minutes, with milestones established and gantt-charted. He immediately requested his internal IT guy to set up w2p on their internal server. There’s more functionality that I haven’t accessed (yet) but does seem very useful depending on the client and project requirements (forums, file storage, calendaring), although I rely heavily on Google’s Calendar; maybe it’s time for a rethink on that?

If you’re looking for a project management application, with excellent support for a small core team; check w2p out.

I presume this is a fairly portable tip; but it is awesome, thatnks to the vi wiki.

If you put the following into your ~/.inputrc file:

set editing-mode vi
set keymap vi

You will then have vi keybindings in lftp (and apparently other programs that support readline editing)

Good-bye annoying emacs keyboard commands in lftp!

I made the switch about a month ago; from QuickSilver to Google Quick Search Box. I did so when I read that QuickSilver’s developer had dropped the project but resurrected it as an apparently re-factored project over at Google. Except for the “Google-In-Your-FACE” UI, it’s the same great utility that QS was, only now it’s maintained, and some new goodness added. Check it out.

One big change (for a small utility) is the way it handles typing your command. QS would “forget” if you paused for, roughly 4 seconds. GQS doesn’t forget, in the same way gnome-do doesn’t forget. It felt clumsy at first, but after the “what will QS ‘guess’ I’m trying to type” coolness factor dies down, I find I prefer the memory permanence. Sometimes eye-candy can slow down pragmatism.

When Canonical released Karmic Koala, I didn’t hesitate to do the update-manager distribution upgrade. In the back of my mind, however, I knew that I was going to carry forward a bunch of cruft that had built up. The upgrade was successful, but I saw very little difference in basic features. so I decided to scrap the original and reinstall the Karmic as a new installation. I went with the 32-bit version (I’ll wait until a 64-bit flash binary becomes available for the 64-bit OS) I already have a /home partition separate from my main / partition. However, I switched from ext3 to ext4 and the conversion deleted all existing data (none of it was critical) I probably could have saved the data by doing an ext3 -> ext4 conversion independent of the installation.

So I hit a snag after the clean install: no wireless on my Broadcom 4311. I did what I always do when this happens. I checked Google and found various wild hairs, but no answer. Then, words of an old friend came back to me; “When the toaster isn’t working — check to see that it is plugged in.” Of course, there’s Occam’s razor, but enough analogies. The Dell 1520 laptop has a switch that toggles bluetooth and wifi, for power savings. The darn switch was off. I turned it on and there it was: WiFi.

After that, no problems yet. I’m experiencing much better overall performance. The hit was so bad that I’ve basically stopped using this laptop. There was something to how I configured MySQL and lighttpd and probably some other stuff — I’ll follow my own advice and do my LAMP stacks as VirtualBox machines, not on this machine itself. Now onto zsh, Adobe Air/TweetDeck, gvim, and so on.

Insanity is doing the same thing and expected different results. I’m not sure why I keep doing this, but I do: when including a jQuery script into an xHTML page, be sure to declare the script properly: “text/javascript” not “application/javascript”

Now to create a repeat loop: for (i=0;i<=100;i++); echo “use “text/javascript” \n.

I use a LAMP-based web application to track my projects. I had been using Todoist.com, a great on-line to-do list for many years but I needed better accommodation. My hosting provider at the time had a “click-and-go” installer for dotproject so I installed it and moved all my data over and started using it. However, I had continual technical and UI issues with it, (namely, dp doesn’t like MySQL instances with temporary table creation disabled) and I noticed there was a 2 year lag between what I installed and the then current version (2.1.12, which it is still at; more on that in a second) but the hosting company wouldn’t upgrade. So I de-installed the canned version and uploaded 2.1.12, which helped reliability, at least a little bit. However, the “temporary tables” issue remained, and dp would choke on creating the main status page.

A little research, starting from how to work-around the lack of temporary tables, led me to a fork of dp, “Web2Project.” It appears that the w2p fork was fostered by the lack of development at dp. While I don’t use w2p as well as I could, I am greatly pleased with the reliability and better over performance and UI. You can’t miss the similarities, but gone are the in-line error messages and incomplete pages.

Installing w2p (which allowed me to start by using my dp data) was a bit of a hurdle. First things, check your requirements. W2P doesn’t like php4, and I didn’t confirm mysql requirements but I am running 5.x without issues. I first tried to work from my web server, but the typical network latency made this process cumbersome, so I decided to migrate firstly in my MAMP setup, which turns out (in hindsight) to be the best way to perform this process. I had to change the install script so that the case statement defaulted to a single option: upgrade an existing dp database into w2p. After the install script had no choice, it moved my dp data into a w2p schema, ready for work. There is one issue. They have dropped “ticketsmith” support. I used this feature for a brief period and found it’s lack of integration problematic. Apparently the w2p team agrees. However, why not remove this data if unsupported?

Huh. Turns out mutlisite drupal and placing files at a directory’s root added a layer of complexity I hadn’t planned on. I used image module and views, which is just as well, as it has other advantages, such as using image nodes.