Monthly Archives: May 2004

Bloglines Account Dead?

Posted on by
Reply

I’ve been pretty happy with Bloglines since I started using it about two and half weeks ago. Until tonight. I’m no longer able to login. I tried the ‘forgot my password’ page, but it told me that I had entered an invalid email address. So I sent a note to them using their contact page. Hopefully they will get this resolved soon.

Update (10:36pm): Looks like Bloglines just took their site down with a simple message indicating that they’ll be back up ‘in a couple minutes’. /me crosses my fingers hoping for the best.

Update (11:53pm): Still no Bloglines.

Update (8:30am 31 May 2004): Bloglines came back up at some point eary this morning. I’ll have to export my subscription list from time to time just in case they go toes up.

Update (6:12pm 31 May 2004): I received a response from Bloglines around 1pm today. Looks like a hardware failure was the source of their problems:

Hello,

We had a hardware failure this evening with one of the database machines. No data was lost, and we have backup servers for just this occasion, but the site was down for a couple of hours. The system is back up now, and we apologize for the downtime.

Thanks, Mark

PostgreSQL Check Constraint Supports Regular Expressions

Posted on by
8

I was thinking the other day how great it would be if you could store a regex pattern requirement in the database for each column. After a few Google searches I came across a post on the PostgreSQL Novice email list that gives an example of how to do this using PostgreSQL’s Check Constraint feature in combination with the POSIX Regular Expression support in PostgreSQL. Here is an insanely simple example:

CREATE TABLE example_table (
     first_name VARCHAR(100)
         CONSTRAINT check_first_name
         ( first_name ~* '^[a-z]+$')
);

That would create a table named ‘example_table’ with one column, called ‘first_name’, that would only accept inserts or updates if ‘first_name’ only contained lower case letters a through z. I love it when something pops into my head that I think would be really cool and then find out that someone else already has it working! (Although having PCRE would have been an added bonus.)

I also looked to see if MySQL supported this. It looks like the current versions do not, at least according to their create table syntax documentation or their constraints documentation. So I started going through their todo list to see if it is planned for some point in the future. I didn’t see it on the feature list for 4.1 or for the new feature list for 4.1. Nothing in the todo list for 5.0 about constraints. Ahhhhh, found it. On the todo list for 5.1 is an entry under ‘New functionality’ called ‘Column-level constraints’. I wasn’t able to find any information about when MySQL 5.1 might become the stable version. The only thing I did find was an email where the guess for MySQL 5.1 was sometime around 2006.

Adding 'More…' To Your WordPress Entries

Posted on by
2

Scriptygoddess has four steps to using her WordPress ‘more…’ plugin. She uses javascript to hide the rest of entry. WordPress also has a built-in ‘more…’ ability which is a little simpler, but less flexible. The built-in feature may only be available for 1.2, so double check that it works with your version before you start using it. You simply add <!--more--> where you want to break the entry.

While I’m on the topic, WordPress also has built-in page navigation per entry by using <!--nextpage--> multiple times.

PHP's in_array And Loose Typing Grief

Posted on by
Reply

I’ve got a small function that builds an HTML select form given a name, array of options, an array of selected options and some javascript options. While looping over the array of options I have a very simple call to PHP’s in_array function to determine if the option currently being looked at is also one of the selected options. The code looks something like this:


           if(in_array($option, $selected_options)) {
               $out .= " selected";
           }

This worked most of the time, but started given me problems under certain conditions. This is where having loose typing in PHP can be a bit of a down side. So my first thought was to simply add true as the third argument to in_array which forces a type comparison as well as a value comparison. This fixed the problem for my previous error conditions, but broke the conditions where it was working before. I thought about adding another argument to my simple function as a hint to know if it should use strict type checking or not. That approach didn’t feel right, I wanted something that would just work. So I threw out the code above completely and replaced it with the following:


            foreach($selected_options as $selected) {
                if("{$option}" == "{$selected}") {
                    $out .= " selected";
                }
            }

In concept this does the same thing as in_array, but the comparison is always done in string context. So far this works under all of the conditions that I’m using it. One of the problem combinations is when 0 (zero) is a valid option. Another problem is when an option could be a number or a letter. With in_array I had to decide which way I wanted to it break, with a simple foreach using string context, both conditions work.

I doubt that this will be the best solution in call cases, but it seems to be working in mine where zero values and type issues were causing me grief. I’ve only been testing this for about 15 minutes, so we’ll see if this stands the test of time as it gets more use.

WordPress Chat

Posted on by
1

I’ve started hanging out on #wordpress (on irc.freenode.net), mostly just lurking unless I see something interesting. I’ve seen some of the developers in there from time to time. So if you want to talk WordPress come on by and say hi.