Brushing up a little on some of the things available in PHP5. Here’s something that made me weep happy tears. Given the XML file:

<people>
    <person>
        <name>Daryl L. L. Houston></name>
        <coolness>100%></coolness>
    </person>
    <person>
        <name>Steve Urkel></name>
        <coolness>-100%></coolness>
    </person>
</people>

And the code:

<?php

$people = simplexml_load_file('test.xml');
foreach($people->person as $person){
        print $person->name . ' (' . $person->coolness . ')' . "\n";
}

?>

You get the output:

Daryl L. L. Houston (100%)
Steve Urkel (-100%)

No iterating over arrays, no finding the right PEAR class and making sure you’ve got the right versions of dependent PEAR classes installed. It Just Works™.

I’ve more or less avoided PHP5 to date, as much of the code I write wouldn’t benefit a great deal from many of the things I understand PHP5 to provide, but this alone makes it worth a second glance.

The other day, I was looking for some QuarkXpress-like publishing software for Linux after working with much frustration in Open Office to come up with a template for a publication I’m thinking about doing some work on. Open Office is great software, but it’s just not ideal for this kind of layout as far as I can tell. I found something called Scribus that seems a little rough around the edges but that I think’ll do the trick. Unfortunately, I had a lot of trouble getting it installed. It needed Qt, and that had some prerequisites that I had problems with. When I had trouble doing a manual install of this stuff, I decided to use yum to try to install qt, and at some point in the process, I used yum to uninstall it. And yum decided to uninstall a bunch of other stuff at the same time. Which didn’t really cause a problem until I had to reboot yesterday and gnome wouldn’t start. (Incidentally, I wound up finding an rpm for Scribus that installed with no problem and rendered all this pain really superfluous and thus doubly painful.)

So I decided to just reinstall my system. Since getting the widescreen and wireless working on this laptop was a pain originally, I made an effort to save all the info I recalled having needed to do so, figuring it’d be a pretty quick matter as a result. But I forgot to save my xorg.conf, and the wireless stuff didn’t work as seamlessly as one might have hoped. And though I thought I had blogged the steps when I originally set up this system just in case I needed to do it again, I hadn’t. Luckily, it didn’t take as long this time, though it still wasn’t exactly a walk in the park. So here’s a quick walkthrough for future reference.

For the widescreen, I need a tool called 915resolution. Once you get that installed, for this particular laptop, I add the following lines to /etc/rc.local:

/usr/sbin/915resolution 66 1280 800
/usr/sbin/915resolution 34 1280 800
/usr/sbin/915resolution 45 1280 800
/usr/sbin/915resolution 54 1280 800

Then, I edit /etc/X11/xorg.conf so that the screen, monitor, and video sections look like this:

Section "Monitor"
  Identifier   "Monitor0"
  VendorName   "--> LCD"
  ModelName    "1280X800@75HZ"
  Option       "CalcAlgorithm" "CheckDesktopGeometry"
  Option            "dpms"
  HorizSync    30.0 - 82.0
  VertRefresh  58.0 - 75.0
  UseModes     "Modes0"
EndSection

Section "Screen"
        Identifier "Screen0"
        Device     "Videocard0"
        Monitor    "Monitor0"
        DefaultDepth     24
        SubSection "Display"
                Viewport   0 0
                Depth     24
                Modes    "1280x800" "1920x1200" "1680x1050" "1440x900"
        EndSubSection
EndSection

Section "Modes"
  Identifier   "Modes0"
  # 1280x800 @ 75.00 Hz (GTF) hsync: 62.62 kHz; pclk: 107.21 MHz
  Modeline "1280x800_75.00"  107.21  1280 1360 1496 1712  800 801 804 835  -HSync +Vsync
EndSection

Some tutorials suggest that I need to get the ATI driver, but I’ve found that it’s not necessary. So, that takes care of the widescreen setup for this model (Sony VAIO VGN-FS550).

Next up, networking. I initially tried to cobble this together more or less piecemeal as I had done previously (thanks to the process of trial and error). But what ultimately worked was the directions that start here, which links to this site, which is the real jumping-off point. Essentially, here are the steps:

1. Download and install the ieee80211 subsystem.
2. Download a recent ipw2200 driver (which requires the ieee80211 subsystem).
3. Download and install recent firmware.
4. Copy the load, unload, and other similar scripts from the ipw2200 directory to, say, /usr/local/wireless
5. Add the following to your /etc/rc.local:

   modprobe ipw2200
   cd /usr/local/wireless
   /usr/local/wireless/load #ipw2200 driver loader
   

6. Reboot or execute those commands by hand.
7. Then just bring your wireless interface up as you normally would.

The installs listed in the first two steps are pretty routine. Just do the standard make and make install. I don’t think I had to do any other steps to make those work. The firmware files have to be copied into the hotplug directory on your system, which you can find the location for by looking for the FIRMWARE_DIR line in /etc/hotplug/firmware.agent.

After getting the wireless working, I ran into a couple more problems. For both wired and wireless interfaces (though I initially thought it was just the wireless), I started getting random disconnects. When I looked at the output from dmesg, I kept getting the error “no IPv6 routers present.” After googling around, I checked /etc/modprobe.conf and made sure the line for eth1 specified ipw2200 as the module rather than eepro100, which was what was listed when I checked. So far, this has kept my link up for a few minutes. If this is the sort of thing that degrades over time, it might not appear just yet and I might not be out of the woods, but in the short term, that change (and a subsequent reboot) appears to have done the trick.

It’s official. I’m now a Drupal contributor. A month or two ago, I applied for a Drupal cvs account after writing a couple of modules I thought might be useful to some Drupal site administrators. Specifically, I wrote a module that lets the community keep track of and rate (in a roughly Diggish fashion) links picked up from aggregated feeds. I wrote another that helps correlate nodes in a Drupal site to bugs in some bug system or another. And to help add some polish to both of those, I wrote a module that incorporates xajax into Drupal to make for absurdly simple ajax integration. Yesterday, I got confirmation that my Drupal cvs account had been approved, and I’ve now checked these modules in here, here, and here for the world at large to use, praise, scoff at, whatever.

I think I’m going at last to stop qualifying tech posts with the usual “don’t bother to read this if you’re in my family because you’ll probably find it pointless and really quite a snoozer” disclaimer. Basically, if it’s marked tech with no other categories or tags, it’s probably going to be of limited interest to most of my family.

For both work and another site I’m playing with right now, I’m using Drupal and have a need for multi-site functionality with separate content but shared users. I tried setting this up a year or so ago at spreadfirefox.com and it was anything but ideal. Things have gotten better since then, but they’re still not perfect. Here’s how I got this to work after consulting various Drupal forum posts.

1. Copy the default config. In the sites directory, copy the “default” directory and paste it in as the domain name you wish to multi-home on this Drupal install. If default/settings.php is configured to host domain.com and you wish also to host abc.domain.com, name the new directory “abc.domain.com”.

2. Tweaking per-site settings. Edit settings.php. First, change the $base_url value to match the new domain (in this example, it would read “http://abc.domain.com”). Then edit the $db_prefix variable. If the variable is a string, Drupal’s engine prefixes the string to all database tables before running queries. If it’s an array, you can define per-table prefixes. This is really the heart of the multi-homing capability, as you’ll want to share some tables but not others. Here’s the setup that has worked for me:

$db_prefix = array(
‘default’ => ‘abc_’,
‘authmap’ => ”,
‘profile_fields’ => ”,
‘profile_values’ => ”,
‘role’ => ”,
’sequences’ => ”,
’sessions’ => ”,
‘users’ => ”,
‘users_roles’ => ”
);

In my case, I had already created all of my tables with no prefixes. Thus for the shared tables, I set the prefix to a blank string so that those tables get used. For all tables not listed explicitly in the array, the engine falls back to the default value, which I’ve set to “abc_”. So all tables listed here (non-content tables) are shared, and all others have to be created with the appropriate prefix (”abc_”).

3. Editing table names. I found the following script somewhere in a Drupal forum thread:

#!/bin/sh
usage(){
cat - <<EOF
cat database.sql | `basename $0` prefix1 | mysql
EOF
}
[ "$1" == "-h" ] && usage && exit
[ -z $1 ] && cat && exit
PRE=$1
sed “s/\(TABLE\|INTO\|FROM\|REPLACE\) /\1 ${PRE}_/g”

Copy it into your database directory in your Drupal install. Make sure it’s executable (”chmod u+x convert” where “convert” is whatever you named the script). Then execute “cat database.mysql | ./convert prefix > prefix_database.mysql” where “prefix” in both instances is the alphanumeric database prefix you provided in the “default” slot for your $db_prefix above. In my case, it would be “abc”. This will create a file that you can slurp into mysql using your favored method.

But before you do so, you’ll probably want to hand-edit it a bit. It’s not essential, but for the sake of reducing your number of tables, it’d be ideal. Basically, for the tables you’re sharing as listed in $db_prefix, delete the create table statements and any other statements associated with those tables. If you’re creating many sites, I recommend doing this once, then using vim to edit subsequent copies and doing a regular expression to substitute values.

4. Manual database tweaks. Here I’ve had to do some manual tweaking to make things work properly. I’m assuming that your initial site already has some configuration values set up that you’d like to clone to your new sites. This was the case with my setup, at least. Some of these steps may not be necessary if this isn’t the case.

• DELETE FROM abc_variable
  Get rid of potential duplicates that may arise for the next step.
• INSERT INTO abc_variable SELECT * FROM variable
  Clone your initial site’s variable settings into your new site.
• DELETE FROM abc_permission
  Get rid of default permissions
• INSERT INTO abc_permission SELECT * FROM permission
  Clone your initial site’s permissions into your new site. If you’ve already set up permissions in your initial site, this brings them into the new site so that you don’t have to redefine them. They’ll diverge from this point onward. You could also just share this table by adding it to $db_prefix above.
• DELETE FROM abc_system
  Get rid of default system settings
• INSERT INTO abc_system SELECT * FROM system
  Clone initial site’s system settings. This and the previous step may not be necessary, but they seemed to help out with a theming issue I’ll get to momentarily.
• DELETE FROM abc_cache
  Weird things happen if you don’t do this after some of the other steps.

Even after doing these things, you may run into some weird issues with the theme. I think the sequence I’ve provided above resolves these, but if not, just get logged in as admin, make sure your theme engine is set correctly in the new site, and make sure a theme that uses that engine is selected. In my case, weird theme issues had to do with the fact that the phptemplate theme engine wasn’t enabled but a theme that used it was. I believe tweaking the system table as described above helped me resolve this.

5. Miscellaneous. There are other things you might consider sharing. Taxonomies, for example, might be something you’d want to share across sites, though in my case, I want site admins to be able to define their own distinct taxonomies.

I’m sure doing this sort of modification kills the upgrade path and makes it harder and harder to maintain upgrades as you get more and more multi-homed sites. Fair warning.

Be careful with permissions. Test any changes, as you may or may not be giving permissions for some users to do things across sites (if you share the permissions and users_roles tables, for example).

I hear you can specify database names in addition to table prefixes in $db_prefix if you’d like to select across databases. The syntax here would be “database.abc_” rather than just “abc_”.

That’s it. After following those steps per site under my setup using Drupal 4.6.5, I’ve got four sites (a main and three subdomains) all using the same user database but with different content. If I’m logged into one, I’m logged into them all, so I can participate in different segments of the community without having to manage multiple logins. It’s pretty nifty.

I’m working on a community dashboard for work that’ll help me monitor different ways in which people are interacting with the community. One metric I thought it’d be neat to have was how many people have filed more than X bug reports during the last period Y (month, say, or week) and what the average for that period over time has been. This involves a pretty complicated query wherein you have to group by both user and period, which is kind of tricky. It’s also very expensive: With only about 1200 bugs in our database, this query was taking six seconds when I was testing it out. That’s clearly unacceptable. So I poked around a bit and discovered the GROUP_CONCAT function, which lets you group by one column and output the relevant grouped data in a delimited column. So say your query is something like this:

select DATE_FORMAT(creation_ts,’%Y-%m’) date, group_concat(reporter) cnt from bugs group by DATE_FORMAT(creation_ts,’%Y-%m’)

Here I’m getting all months in the database and a listing of all reporters of bugs for that month. The “cnt” column is a comma-delimited lists of user ids for those who reported bugs in the given month, duplicates included (though you can specify DISTINCT to eliminate duplicates). The query returns almost instantly and gives me something I can parse pretty easily in the programming language of my choice.

In my case, I split the “cnt” column on commas for each result and tally the ids for users who appear in the list X or more times. I then pass this data back to a function that does math to get averages and to find a count for the current month, and voila, community metrics.

I blog this here because it’s the sort of thing I might want to remember later, and I always put that stuff here rather than at my work blog, where my regular readers probably figure this should actually go.

I’ve taken a little break from tech postings here because most of my tech postings of late had been about Flock, and I wanted to group those elsewhere. Here’s another tech posting that’s relevant to Flock because I wrote this code for a project for Flock, but it doesn’t exactly belong at that blog because it’s not specifically about Flock. So feel free to skip over this one, dear family members.

Xajax is a php library that makes ajax development a cinch. I’ve looked at a few ajax libraries, and there are better implementations than what xajax provides on the javascript side, but the ease with which one correlates php function calls to javascript function calls in xajax is well worth the reduced functionality in many cases. For example, xajax doesn’t (as far as I’ve investigated, at least) provide elegant drag and drop functionality. But for simple updating of content upon request completion, it handles the basics without forcing you to write your own javascript callback functions (which can be a pain and which can make your source code look really nasty). Here’s a quick primer on how it works:

• Write php functions to do server-side data manipulation and to use xajax calls to manipulate the page upon request return.
• Register these functions in your php script. This gets the correlating javascript functions added to the javascript include.
• Include the javascript in your source, tell xajax to process requests, etc. (all this is outlined in detail at the xajax site).
• Add the javascript function calls to your source. If your php function was named “delete_member,” your javascript call is named “xajax_delete_member.”

That’s it. Arguments passed to the js function are passed straight through to the php function, and you have to do no special mumbo jumbo to make the thing work. The out-of-the-box functionality is pretty simple when compared to the libraries available at, for example, script.aculo.us, but xajax is reportedly extensible, so you’re certainly not limited to what you get out of the box.

Now, on to why this is ideal for Drupal development. The more I use Drupal, the more appealing I find its API. It’s pretty simple to extend the software. For example, I recently wanted to add a little snippet of code next to the title of any sort of node. Lucky for me, the Drupal developers thought to include a nodeapi hook, which lets you do just what I wanted to do. For all its niceness in some areas, though, it’s painful to do some things in Drupal. Adding global ajax support seemed a likely candidate for such pain because Drupal’s got menu hooks, a permissions system, etc., that I thought might make for tedious hacking.

I started by simply including the xajax code in one module I was working on (as proposed here), but when I wanted to include the same sort of functionality in another module, I started getting collisions. The library code was called more than once, so I found myself getting php errors. This prompted me to try to find a way to make xajax work globally across a Drupal install. And it turned out to be dead simple. I simply included the xajax library as in the example linked to above. If the node is enabled, this adds the javascript include to the template globally. Then I added some code that checks all installed Drupal modules for a function named MODULE_xajax_init (where “MODULE” is the module name). This init function for relevant modules performs the function registration calls. The routine for adding ajax support to any module in Drupal, then, now goes as follows:

• Install and enable xajax.module.
• For the module you’re writing, define MODULE_xajax_init and include function registration calls.
• Within your module, define the php functions you’ve registered.
• Add javascript calls to your UI.

That’s it. Voila. Magic, easy ajax support in Drupal.

Xajax is especially suited to Drupal because it handles everything using simple php code. There’s no writing of nasty javascript callbacks and embedding those into your templates or, worse, into your module itself. The appeal of using this xajax module is that it works globally across your Drupal install with no “function already defined” type errors and, well, it’s done and it’s free. You can download the module here.

As noted previously, I’ve been overwhelmed by the positive response Flock has gotten so far. The community forums have been hopping (I’m trying to put a little dent in responding to a backlog each day; if there’s something pressing in there that nobody’s responded to yet, drop me an email at daryl at flock.com and I’ll see if I can help), and we’ve had a good bit of activity on our Flockstars list. We’ve also had an overwhelming number of offers of help. Believe it or not, it can be very hard to accept help because all the offers have to be organized, but don’t worry — we intend to organize all the offers and accept a lot of the help.

For the time being, if you’d like to volunteer to help out in some way, you can go here to do so. We might not get back to you right away, but by submitting your info here, you guarantee that it gets stored in a searchable database rather than lost in somebody’s inbox or blog comments.

If you’re one of the few dozen people who commented on Geoffrey’s blog post, I’ve probably sent you an email asking you to do the unspeakable and resubmit your info using the new page. I hate to ask you to do this, but it saves me a lot of time that I can put to better use actually working on Flock, and I figure you guys’re all behind that and will forgive my asking you to do something sort of redundant.  If you’ve offered through some other means, I hope you’ll also do me the favor of filling out the new form with your info, just to make sure we’ve captured your offer. Thanks!

Technorati Tags: flock, work, tech

On Monday, I had my gall bladder removed. Yesterday, I worked a 15-hour day because we decided to launch Flock publicly. Today, I’ll be good for more or less nothing.

We’ve been releasing to larger and larger beta groups over the last week or so, and we decided yesterday afternoon to go ahead and release publicly. Of course, we had much work do to, as we had been focusing more on shipping a browser than on getting our public Web site in good shape, etc., and so our crew spent the evening whipping that stuff into good — not great, but good enough — order for public consumption. This meant crossing our fingers that we could withstand a slashdotting better than we did two weeks ago (because of some heavy-duty server infrastructure changes we made, we weathered it without issue). This meant working on our messaging a bit in order to help preempt some of the stupid sorts of comments that always seem to emerge. When we half-released for Web 2.0 a couple of weeks ago, for example, rumors abounded that we were taking Firefox, making it Windows-only, and slipping in adware. WTF? So we obviously wanted to have some blog posts and FAQs in place to explain some of what we’re doing. What we’ve got so far is available at www.flock.com.

The slashdot reviews have been much more even-handed this time. There have been the expected trolls (and let me just say that even though the trolls shouldn’t bother me, they do, because after all, I’ve missed bits of my daughter’s childhood to write the software they’re panning, and I’ve sat up with a hurting abdomen the day after surgery to do things to get a pre-release out; the whole crew has made big sacrifices to ship the software these trolls dismiss out of hand without regard for the human effort that drives its production; one would hope they’d at least download the software and try it out before dismissing it, but it seems that few do). But there have been some really good comments as well. Among my favorites:

Giving me quick access to something like a blog or Flickr isn’t “innovative”. A bookmark/favorite does the same thing with less overhead.

I thought the same thing until I actually tried the Flock Developer Preview that was just released. (I’m posting this from it now.)

I was all set to be unimpressed but I have to tell you, it’s pretty impressive if you have a blog how easy they have made posting Web content to it. There’s a “shelf” tool, for starters, that you use by just highlighting any text on a page and dragging-and-dropping it into the Shelf. Then, when you want to post about that text, you just click the “Blog this” button on the toolbar; this opens a new post (Flock autodetects the settings for your blog, so there’s no configuration if you use most popular packages) in a WYSIWYG editor. Drag the text from the shelf into the editor and it pops the text in, encloses it in BLOCKQUOTE tags, and adds the cite=”" attribute with the URL from the original page.

Revolutionary? Maybe not. But it’s so damn slick! Currently when I blog something I copy it from Firefox into an HTML editor (Movable Type’s built in editor sucks), mark it up there, log into the admin screen for my blog, then paste the marked-up text into a new post. Oh, and then I have to go back and find the original URL, copy it, and paste it in the appropriate pages. That’s a lot of back and forth that Flock eliminates.

Some people use a tool like MarsEdit [ranchero.com] or wBloggar [wbloggar.com] to combine the “markup” and “posting” steps together in one place. But Flock puts all the features of those products right in my browser — no switching between programs, no copy/paste gymnastics. There’s a market for those products, so it’s not a big leap to imagine a market for Flock, either (albeit a small one).

It’ll be interesting to see how well Flock holds up to ongoing use over time. But my first impressions are better than I expected them to be. You might want to try it too before you pass judgement…

Slashdot | Firefox-based Social Browser Flock Launches

and

Flock had me skeptical from the screenshots (ugly and useless), but having actually used it, it’s pretty gosh darn neat. The Shelf is an incredible killer feature. I’ve tried out a few similar extensions for Firefox, but none did it as smoothly and intuitively as Flock has. All it needs is a few hardcore snippet-management-tools, and it’ll be my new favorite research program.

Likewise, the blog editor falls under the “pretty neat” status. The formatting gets eaten by Wordpress.com’s post-parser (to filter out nasty javascript and other malicious evil), but that isn’t a major downer, as it does tend to exhibit some weirdness like underline remaining after deleting a link. The WYSIWYG-editor part of it definately needs some work to be up to par with the rest of the browser.

Overall, I’ve been seriously impressed. For being a the first public release of a browser, it’s feature-filled and non-crashy. This must be attributed to it being based on Firefox. All it needs is a few months of polish and I can unconditionally accept it as my new primary browser. As is, I’m giving the idea serious thought.

P.S.: I didn’t use the del.icio.us integration, as I didn’t really use the service much before. But now that it’s seamlessly integrated into the browser, I’ll try it out again.

Slashdot | Firefox-based Social Browser Flock Launches

Of course, these appeal to me in part because I’m the perpetrator of the shelf (with its various warts and pimples), which gets pretty good reviews so far. But they also give me a little hope for the slashdot crowd. There actually are those who expect one thing, evaluate the software, and come away with a more balanced view rather than falling back on the old standby comments about how silly social networking is or how we must be making Firefox into a Windows-only spyware engine.

It’s been a good morning. I’ve been reading and responding to mail from our flockstars mailing list, where people are already submitting extensions that will work in Flock, and glancing over the hundreds of feedback emails that have come in over the last 12 hours. Response overall has been very good. Yes, we have a long way to go, and there are many crucial bugs we have yet to fix, but the people we’re aiming at seem to think we’re on to something, and that’s nice validation.

I plan to work until noon today and then to take most of the rest of the day off to try to spend with my daughter, whom I don’t think I even hugged or kissed once yesterday. Then there’ll probably be a regrouping/evaluation conference call this evening where the Flock crew will talk about the last day and the coming very busy days, deciding just how we’re going to keep up our momentum and try to deliver a better and better and better product. Stay tuned!

Technorati Tags: flock, work, tech

People I know seem not really to know what I do for a living. They know it has to do with computers, and most of them know I’m working on
software, and many know that I’m doing something with browser software. In a nutshell, here’s what my company does:

Flock hopes to turn the browser into a dashboard for collaborating, blogging, sharing photos, reveling in a raft of other group activities that have recently caught fire online (see BW, 9/26/05, “It’s a Whole New Web”).

Flock, the New Browser on the Block

So far, based on my dogfeeding our software last night and this morning, we’re well on the way to success. I’m blogging manically lately, I guess. What we’re doing is exciting, and it’s good to have something techy to blog about, plus it’s cool to use the tool I’ve helped create to blog about said tool. My apologies (to both of my readers) for all the redundancy lately.

Technorati Tags: flock, work

At least two people have complained recently that I had comments turned off. I turned them off because even when I’ve got moderation set, I have to go in periodically and manage a few hundred spam comments (each of which sends me a moderation request email), and that bothers me. And as I ever got only a few comments a week that were relevant, I figured it was no big loss. Well, I figure that two readers makes up darned near a majority of my regular readership, and I won’t let it be said that when the masses speak, I don’t listen. So I took a few minutes today and installed a captcha thingy for comment posting. I had this installed in the past (before an upgrade wiped it out), and it seemed to work pretty well. Here’s hoping it works pretty well, at least, or the masses will be silenced again.