Here are three really nice programs I’ve found (or rather, people have pointed out to me) for the Powerbook lately:

iScroll2: Two-Finger-Scrolling with pre-2005 PowerBooks and iBooks at RazzFazz’ Homepage. This is particularly nice, since it is highly configurable: vertical scrolling, horizontal scrolling, circular scrolling (i.e., iPod wheel scrolling), and even tap-to-click mappings. It seems to be a really well done piece of code.

MyBattery coconutBattery at coconut-flavour.com. This is more than just a battery monitor, since it gives some “absolute” information, such as original maximum battery capacity (in milliamp-hours) and current battery level, capacity, charge cycles, and estimated runtime. We all know deep down that our batteries are slowly decreasing in their capacity as they age. This gives a tangible figure for that degradation.

Desktop Manager. I first encountered a virtual screen program like this under HP/UX, and have used similar programs under Irix, Linux, and Windows. This is a particularly nice one, at least in terms of eye candy. Seems stable, and is great for a machine that’s used for development, web surfing, image editing, etc. to keep each activity kinda separate.

How could I resist a $150 wireless network camera? Well, the answer is I couldn’t.

This is one of the NC1000-W10 systems. It has, according to this site, an embedded Linux kernel running on an ARM processor.

It seems pretty slick. It has dual network interfaces, and, web-based access. The image quality is acceptable for a security camera, or for doing long-term timelapse (my purpose). It’ll do short-range IR illumination, will email images if motion is detected, etc. It requires Windows for its initial setup, but once you get network access, it will work and be further configurable with any Java-enabled browser.

One quirk is that you seem to have to power cycle it (or perhaps reboot it) to get it to utilize any new Network settings. The one snag is that if you configure it to listen on both wired and unwired networks, and it’s unable to connect to the wireless network, it seems to stall out and fail to boot correctly. This is a problem when I have wired and wireless connections out in the office, but only wireless (on a separate wireless network) in the eventual destination. I’ll have to run a long cable to configure it for its final use.

Well, it’s an impossible problem. My digital cameras all have high-speed “spray-and-pray” modes, which are the only reasonable response to the challenge of taking candid pictures of children. One shoots a buffer full of pictures, and in one of them (if one’s lucky), all of the kids will have their eyes open, there will be no fingers stuck up noses, and, if one’s really lucky, there will be nice expressions on all of the visible faces.

But the downside is the proliferation of pictures. One develops a certain Tommygun mentality, and, hey, disk space is cheap. Composition’s easier in Photoshop than through the viewfinder.

In short, I have a digital picture management problem. Apple’s iPhoto is a good start, but it can’t handle the quantities of images I’m throwing at it. Recently, I’ve been using an evaluation version of iView Multimedia’s iView Pro. It seems good, with lots of options and configurability. I’d rather not spend $200, but if I can learn to use it adequately, it’d be worth it. And I certainly don’t have time to write my own (witness the moribund Samuel’s Last Attempted Gallery [SLAG] web application that’s never made it past the schema design phase).

I’ll report here eventually what I find.

Well, I can now state authoritatively that the problem was with Mac OS. I still don’t know what went wrong, or why, since I was originally able to sync a few times before it stopped working.

In any case, I upgraded the notebook to Mac OS 10.4 (“Tiger”), and lo and behold! sync worked with the cable right off the bat. And damn is the USB sync cable faster than bluetooth.

So if you’re having problems synching on a Mac, this might be a starting point for diagnosing the problem.

So I’ve just finished version 0.4 of a module for handling user feedback for CMS Made Simple. It allows users with administrator rights to create reasonably complex forms, with all the user interface objects that we’ve come to expect, and handle the submission of those forms in a variety of ways.

It’s been an interesting experience. Version 0.1 was your standard naive PHP implementation of an application within a framework. It was all one big script in one big file. It would do fairly simple database queries, stuff all the results into a big array, and then process array elements with big switch statements when it needed to customize output based upon UI object type.

Version 0.2 ported this basic functionality into an Object Oriented model. I found that there were a couple of complex decisions to make — should I handle the database storage and retrieval in an OO manner? And if I query a bunch of Input Objects from the database, how do I know what specific kind of object to instantiate since that data is contained in the database record? I guess the truly OO approach would be to use an OO database, or, next best approach, to have a separate table in the database for each kind of input object. But that’s not how I did it, probably to the detriment of my code (I instantiate a superclass object, then use the type details from the general object to create a new object which is the correct specific class.)

Still, this showed how a procedural approach could save a lot of database activity over an OO approach. The data model comprises forms, which contain one or more fields, which have one or more options. In the procedural approach, I denormalize the database so that fields contain the form id, and field options contain both the field id and the form id. I could then grab everything I needed for a form in three queries. With the OO model, the number of queries is proportional to the number of fields. What’s more, there’s been a massive proliferation in the number of files required. While I worry about the web server having to load and parse all that stuff each time, I should probably have more faith in the PHP engine and the OS caching. As a number of people have said to me, I’m not playing on a TRS-80 with 4k RAM anymore. But I still feel like I should be programming as if resources were seriously limited.

Similarly, when it came time (for version 0.4) to add localization of the code, it required some somewhat unpleasant contortions: each Input object needs to have access to a global collection of text strings (stored in a big hash) so they can present localized versions of messages. And I still need to go in and make sure that I’m actually handing around references rather than the copies that PHP likes to pass.

Maybe this is just the yammerings of someone who should understand software design better. Clearly, there were some bad decisions made in the code, although I could argue about how bad they really are.

Another aspect that took me by surprise was how I could test code and have it perform perfectly, while other users reported errors and bugs immediately. In this case, the main culprit was not inattentiveness (in testing, anyway), but my PHP configuration. If you allow output buffering, PHP gracefully handles output before the headers have been sent. Not so, if output buffering is disabled. So when my code would generate errors, my test configuration would blithely allow error codes to be output but then clobber that output with the expected page output. So while I thought output buffering was only involved in performance, it seems that for development, it should be disabled. That way, those bugs cannot be so easily overlooked.