automatic – Climb to the Stars

Impressions on New Hearing Aids [en]

As the founding editor of Phonak’s community blog “Open Ears” (now part of “Hearing Like Me“) I contributed a series of articles on hearing loss between 2014 and 2015. Here they are.

As promised, here are my impressions of the Bolero hearing aids I’m currently trying out (hoping I don’t get any of the technical stuff wrong here, do tell me if I did!). They have open tips, like my Widex ones have, but are BTE (entirely behind-the-ear) rather than RIC (with the receiver, the part that produces sounds, directly in the ear canal — this would be the Phonak Audéo model, which I might try in future). My Phonak audiologist Jennifer tells me it doesn’t change much, acoustically: a RIC just moves some of the technology away from behind the ear, allowing the part that sits there to be smaller — important for those, who, like Steve, appreciate when their hearing aids are invisible.

Phonak Bolero Q90

The first thing that struck me with these aids was that there was less ambiant noise. Or less operating noise. Or different. I had the strange feeling I wasn’t really wearing hearing aids. There was probably a little less amplification than what I was used to, but clearly something in the sound texture too.

Voices felt a little tinny/reverb-y at first. Mine, Jennifer’s. Not unpleasant, but a little bit weird. Jennifer told me it was probably due to SoundRecover, which compresses high frequencies into a lower frequency region so we can hear them better. She warned me it would take some time getting used to. I don’t notice anything strange with voices nowadays, so I guess I did indeed get used to it!

I discovered that with Phonak there is a whole list of programmes the hearing aids can switch back and forth from, and which can also be set manually. I left my “main” channel in automatic mode to see how that worked, and for the other ones picked StereoZoom, which is optimised for speech in noisy environments, with a lot of noise reduction and a very narrow beam for amplification, speech in wind (for sailing), and a phone programme (right ear). The last position is a “mute” mode (indispensable for me).

The buttons on both aids have different roles: they can either be used to turn volume up or down, or switch programmes. The catch is that the left button is the “volume down” one, and the right button “volume up”. So as I wanted a “volume up” button, I had to have my programme switch one on the left — whereas it would have made more sense for me to have it on the right. I’m right-handed, and switch programmes more often than I increase volume. Oh well.

I can’t say I’ve used the phone programme much. I tried it, and it works, taking the sound from the right ear (the phone one) and channeling it into the left ear too. It’s pretty neat. But it requires positioning the phone in such a way that the hearing aid catches the phone sound (takes some getting used to) and pressing the phone against my ear with the hearing aid in it ended up being a bit too uncomfortable. So, for long planned calls I’ve reverted to my trusty earbuds. For impromptu calls I still tend to switch to mute, because background noise sometimes interferes with the phone mode (i.e., gets amplified too) and I don’t really feel like experimenting with acoustics when I’m on a call. I guess I should probably run some test calls to really try that mode out.

Given the lousy weather this summer, “speech in wind” has also been largely left aside, as it’s the programme I was planning to use when sailing. I like StereoZoom, though I sometimes have trouble determining if I should use it or leave the hearing aid in automatic mode, specially as automatic mode has a whole bunch of different programmes it can switch to and even blend.

While it’s nice to have a hearing aid that recognises the acoustic environment and chooses the best programme suited to it, it’s sometimes frustrating in practice. I’ll be in my car talking to a friend, and suddenly the quality of the sound changes and I have more trouble understanding speech. And then it changes back. Or I’ll be listening to music in the car, and one ear seems to be treating sound differently from the other. I find the whole concept of a hearing aid intelligent enough to know what it’s listening to fascinating, and would love to know more about how to the tech/programme works, but the control-geek in me would like to be able to have some kind of indication telling me which mode I’m in, and an easy way to override it.

I haven’t yet put my Widex aids back in my ears, which in my opinion points to how comfortable I am with the Phonaks. There’ll be a little tweaking to do next time I go to headquarters and see Jennifer (one ear is slightly less-amplified, and maybe I need a smaller size tip in one ear, we’ll see), and I’ll probably change my selection of programmes, including at least the music one.

Ridding WordPress Plugins of Template Tags [en]

[fr] Cet article décrit une méthode permettant de se défaire des "template tags" qu'utilisent certains plugins. Plutôt que de copier le fameux template tag à 3 endroits différents dans son thème (comme c'était le cas auparavant pour Basic Bilingual), il est possible de modifier à peu de frais un plugin pour qu'il injecte automatiquement son contenu dans le blog.

If you’re like me and use a bunch of plugins to liven up your WordPress blog, you’ve probably noticed that adding template tags in your favourite (or favourite-of-the-week) theme files can quickly become a royal pain in the neck.

One of the things I wanted to do with Basic Bilingual, and which I did with the last release, was make the plugin inject the text for the “other excerpt” (the French text you can see at the top of this post) automatically into the templates and feeds.

Once I’d figured out how to do that, I realised I could modify other plugins, too. And I’m going to tell you how you can do it, too. This method should work for any plugin which generates a template tag, as long as you want the content generated by the plugin to go immediately after or before the post content. (I’m still working on advanced rules for cases where you want to make modifications elsewhere in the template.)

Christine‘s Inline Tag Thing put me on the track (thanks!), as it does just that. Here’s the trick:

create a function which concatenates (= “adds”) the plugin output to the content
add an action hook to the plugin to apply that function to “the_content”.

Fear not, I’ll explain all. You don’t need to really know much PHP to do this, as long as you’re comfortable wading through a bit of code and copy-pasting stuff and making a few small modifications.

Let’s take an example: the Similar Posts plugin, which I’m now using to point out posts related to the current one (normally, in a box at the top of the post if you’re on the website, and as a list at the end of the post if you’re reading the feed).

Similar Posts provides a template tag, <?php similar_posts(); ?>, which you can paste in your template where you like the related posts to appear. Personally, I want them to appear on the main blog page, on the individual archive pages, and on the monthly, category, and taggy archive pages. This means I need to paste the tag into at least 3-4 different template files. And if I decide that I want the tag at the top of the post rather than the bottom, or I decide to remove it, there I go again. Not optimal.

So, here’s how I made it “better” (for me):

A. First, I looked at the plugin code to figure out where the template tag function was; in this case, quite easy, it’s the function called similar_posts(), logically. Here are the last two lines of this function, which do the actual data output:

print $result;
if (defined('POC_CACHE')) print $cache_time;

I changed them to:

return $result;
if (defined('POC_CACHE')) return $cache_time;

So that they didn’t print directly (ie, output text), but just return the value of the data we want to insert.

Then, I created the following function:

function sp_embed_similar_posts($content) {
    $content = similar_posts() . $content;
    return $content;
}

This function takes one parameter ($content), and sticks the output of similar_posts() in front of it. Now you see why we needed to change the other function so that it didn’t print. We’re just modifying the value of the $content string. This new function returns the modified value for the content (in our case, imagine it as being the content of your post with the code for the similar posts listing stuck in front.

Now all that is left to do is to tell WordPress to actually use that function at some point (plugins are usually a collection of functions, followed by a series of “hooks” which actually execute the functions at certain chosen moments). Here’s the action we’ll use:

add_action('the_content', 'sp_embed_similar_posts');

Try it!

This will also add the list of similar posts to the feed.

So, in summary, here is what we have done:

modified the template tag function so that it returns a value instead of printing it (in some plugins, you’ll find a function that already does that!)
created a function to stick that value on the beginning or end of a parameter, $content
add an action hook on the_content to execute the function.

Happy hacking!

Scripts for a WordPress Weblog Farm [en]

A first step to WordPress-farming: a shell script and a PHP script which allow you to easily install a whole lot of WordPress weblogs in only a few minutes (I installed over 30 in less than 5 minutes). Scripts require adapting to your environment, of course.

Update 03.11.06: Batiste made me realise I should point the many people landing here in the search of multi-user WordPress to WordPress MU. All that I describe in this post is very pretty, but nowadays completely obsolete.

Here is the best solution I’ve managed to come up with in half a day to finally install over 30 WordPress weblogs in under 5 minutes (once the preparation work was done).

A shell script copies the image of a WordPress install to multiple directories and installs them. A PHP script then changes a certain number of options and settings in each weblog. It can be used later to run as a “patch” on all installed weblog if a setting needs modifying globally.

Here are the details of what I did.

I first downloaded and unzipped WordPress into a directory.

wget http://wordpress.org/latest.tar.gz
tar -xzvf latest.tar.gz
mv wordpress wp-farm-image

I cleaned up the install (removing wp-comments-popup.php and the import*.php files, for example), added a language directory (as I’m wp-farming in French) and modified index.php to my liking; in particular, I edited the import statement for the stylesheet so that it looked like this:

@import url( http://edublogs.net/styles/toni/style.css );

The styles directory is a directory in which I place a bunch of WordPress styles. I don’t need the style switcher capability, but I do need to styles. Later, users will be able to change styles simply by editing that line in their index.php (or I can do it for them).

Another very important thing I did was rename wp-config-sample.php to config-sample and fill in the database and language information. I replaced wp_ by xxx_ so that I had $table_prefix = 'xxx_';.

To make it easier to install plugins for everyone, correct the language files, and edit whatever may be in wp-images, I moved these three directories out of the image install and replaced them with symbolic links, taking inspiration from Shelley’s method for installing multiple WordPress weblogs.

mv image/wp-content common
mv image/wp-images common
mv image/wp-includes/languages common
ln -s common/wp-content image/wp-content
ln -s common/wp-images image/wp-images
ln -s common/languages image/wp-includes/languages

I also added an .htaccess file (after some painful tweaking on a test install).

Once my image was ready, I compiled a list of all the users I had to open weblogs for (one username per line) in a file named names.txt, which I placed in the root directory all the weblog subfolders were going to go in.

I then ran this shell script (many thanks to all those of you who helped me with it — you saved my life):

for x in `cat names.txt`
do
cp -rv /home/edublogs/wp-farm/image/ $x
cat $x/wp-config.php | sed "s/xxx/${x}/" > config.tmp
mv config.tmp $x/wp-config.php
wget http://st-prex.edublogs.net/$x/wp-admin/install.php?step=1
wget http://st-prex.edublogs.net/$x/wp-admin/install.php?step=2
wget http://st-prex.edublogs.net/$x/wp-admin/install.php?step=3
done

This assumes that my WordPress install image was located in /home/edublogs/wp-farm/image/ and that the weblog addresses were of the form http://st-prex.edublogs.net/username/.

This script copies the image to a directory named after the user, edits wp-config to set the table prefix to the username, and then successively wgets the install URLs to save me from loading them all in my browser.

After this step, I had a bunch of installed but badly configured weblogs (amongst other things, as I short-circuited the form before the third install step, they all think their siteurl is example.com).

Entered the PHP patch which tweaks settings directly in the database. I spent some time with a test install and PHPMyAdmin to figure out which fields I wanted to change and which values I wanted to give them, but overall it wasn’t too complicated to do. You’ll certainly need to heavily edit this file before using it if you try and duplicate what I did, but the basic structure and queries should remain the same.

I edited the user list at the top of the file, loaded it in my browser, and within less than a few seconds all my weblogs were correctly configured. I’ll use modified versions of this script later on when I need to change settings for all the weblogs in one go (for example, if I want to quickly install a plugin for everyone).

In summary:

compile list of users
prepare image install
run shell script
run PHP script

If you try to do this, I suggest you start by putting only two users in your user list, and checking thoroughly that everything installs and works correctly before doing it for 30 users. I had to tweak the PHP script quite a bit until I had all my settings correctly configured.

Hope this can be useful to some!

Update 29.09.2005: WARNING! Hacking WordPress installs to build a farm like this one is neat, but it gets much less neat when your weblog farm is spammed with animal porn comments. You then realise (oh, horror!) that none of the anti-spam plugins work on your beautiful construction, so you weed them out by hand as you can, armed with many a MySQL query. And then the journalist steps in — because, frankly, “sex with dogs” on a school website is just too good to be true. And then you can spend half a day writing an angry reaction to the ~~shitty~~ badly-researched article.

My apologies for the bad language. Think of how you’re going to deal with spam beforehand when you’re setting up a school blog project.