$39.90 for unlimited 2-year wildcard certs is a whole heck of a lot cheaper than anything else I’ve seen.  In fact, that’s not much off of what I’d been paying for 2 years of a single-site certificate, having done a lot of comparison-shopping.  And it’s really hard to beat free for single-site certificates.  It’s an easy replacement for self-signed certificates at the same price.

This tutorial assumes a basic knowledge of vim — insert mode, command mode, loading and saving files, etc. It is intended to help vi novices develop their skills so that they can use vi efficiently.

(Posted mostly for my own reference, though I thought it might be of use to anyone else who wants to improve their use of vim.)

The lack of TextPad for mac has left me searching, on and off, almost constantly for the “right” mac text editor.  Most of the time now, that search leaves me right back at Komodo Edit, the free cross-platform text editor built on Gecko and Scintilla that I’ve been using for a logn time now.  Every other major editor just seems to be missing something I’ve come to really like in Komodo Edit, even as slow and clumsy as the interface can be sometimes.

I really wanted to like BBEdit, TextWranger, TextMate, skEdit, subEthaEdit, Coda, etc., but none of them seemed to have the simplicity of code-completion (including variable and constant name completion) and intelligent code auto-indenting that Komodo Edit does.  I wanted to like the integration of various resources in Coda, but having the reference materials in the one program versus in a web browser window over on that second monitor there just didn’t seem to make enough of a difference.  I wanted to think that having an editor that could do sftp and subversion was worthwhile, but it just didn’t seem to matter to my workflow.

It’s been so long since I’ve been away from TextPad that I’m not sure even it would compare to Komodo Edit.  Of course, the one tool that is poised at any moment to start eating into Komodo Edit’s share of my use time is MacVim (this is apparently a new port of vim).  Vi/vim is so unbelievably powerful… and so much more my style than Emacs.  Vi has been my text editor of choice at the command line for about a decade or so now.  See also Why, oh WHY, do those #?@! nutheads use vi? and the two graphics below.

One of the things that took the most work to get right was the thickness of the graph lines.  Because of the nature of the graphs, it was an absolute necessity that the lines be drawn with antialiasing enabled.  PHP’s interface to GD (or perhaps it’s GD itself?) ignores the line thickness setting when antialiasing is enabled.  The solution I eventually settled on is to, more or less, draw several one-pixel-wide lines next to and on top of one another to get the appearance of a thicker line.

As an aside, I’m using the technique mentioned here for permanently redirecting the old URL to the new URL:

… if you actually moved something to a new location (forever) use:

<?php
 header("HTTP/1.1 301 Moved Permanently");
 header("Location: http://example.org/foo");
?>

It looks like there’s some issue in using curl_multi_exec() in PHP with too many requests at once causing some requests to fail strangely, potentially accounting for the lack of data from several sites that are clearly not down and clearly provide stats.txt.  My current workaround is to do the requests in smaller blocks.

I’m also trying to provide more detail as to why there aren’t stats for the sites that don’t have stats.

But the biggest development is that there will probably be graphs of the data over time.  I say “probably” because while the code is pretty much written, I’ve only been storing historical data for about a day so far (in the past, only the most recent data was kept), so it’s hard to tell whether the graphs will look okay with a lot of data and whether producing the graphs will put a significant load on the server.  The data will probably update more regularly and more frequently–likely noon and midnight CT.

Also, if anyone knows for sure if Bloty, IziBlog, and/or LiveLogCity are still alive or definitively dead, I’d like to know.  Oh, and CommieJournal seems to be looking at the posibility of moving to a different codebase, though I can’t for the life of me see why anyone would want to try to move thousands of accounts from the LJ codebase to something incompatible and with a different working paradigm.

… it is strongly recommended for the PHP developers to add more secure random number functions to the PHP core and it is strongly recommended for PHP application developers to keep their fingers away from srand() or mt_srand() and to never ever use rand() or mt_rand() for cryptographic secrets.

It sounds like the PRNGs in PHP, mt_rand() and rand(), shouldn’t be used for anything security-related, and perhaps /dev/random or /dev/srandom or some such should be used instead (though this is much more system-dependent).

Of course, it’s also annoying that while there’s a set_auth_cookie action hook, there’s no clear_auth_cookie, so my plugins had to override the clear_auth_cookie function wholesale rather than hooking into it as they do with set_auth_cookie.

If you have some twisted desire to make this unholy integration that I now seem to have working and would like some of my code, leave me a comment.

However, I just came across this in the bbPress forums:

As of July 2008, do NOT try to integrate WordPress 2.6 with bbPress 0.9 Use WP 2.5.1 – the reason for this is simple – WordPress has radically changed the way cookies are used. If you have already installed WP 2.6, don’t worry you have not broken anything, you’ll just need to downgrade and install 2.5 instead. 2.5.1 is perfectly stable and has no known security issues – 2.6 only adds a few new features to WP. There is an updated version of bbPress in the works to support the new cookie method but it might be awhile before it’s available in a mainstream release.

Now, ostensibly, WP and bbPress are coming from the same people/place/company/organization/whatever, so I think I should be able to expect the one to work with the other and to *not* have the left hand tell me to ignore what the right hand is doing.  This is almost enough (*almost*) to make me give up on trying to piece together a decent way to hook into the is_user_logged_in() thing for the non-WP part of the WP-based site I’m working on, since the bbPress part of the site won’t work even if I do fix the non-WP part of the site.

• what was the one and only login cookie in 2.5 is now limited to /wp-admin
• there’s a copy of that one that’s just limited to /wp-content/plugins, for backward compatibility with plugins
• there’s a new cookie that is at COOKIEPATH (which can be defined in your config file), that is checked by calling

  is_user_logged_in()

  (but perhaps this isn’t intended for secure authorization?)

So, it appears the way to go may be to change

auth_redirect()

to

Maybe more to follow on this when I’ve more thoroughly explored it.