This just in from The Onion News Network

http://www.theonion.com/content/video/new_law_would_ban_marriages?utm_source=onion_rss_daily

Thanks for the tip Wayne!

Ah bafflegab. A word steeped in tradition. This word was invented in the early ’50’s by a fella named Milton A. Smith — who received an award for inventing it. At the awards ceremony, he was asked to define it. here’s his response;

“Multiloquence characterized by consummate interfusion of circumlocution or periphrasis, inscrutability, and other familiar manifestations of abstruse expatiation commonly utilized for promulgations implementing Procrustean determinations by governmental bodies.”

You can read the whole article i stole this from here — http://www.worldwidewords.org/weirdwords/ww-baf1.htm

I know.  I should have upgraded MySQL long ago.  But I didn’t realize how easy it was, so I put it off until… now.   The latest version of WordPress (WordPress 2.9) doesn’t work on really old versions of MySQL like my ancient 4.0.27.  Further complicating things is the need to cut blogs and sites over one at a time so’s to be a little prudent about all this.  “Big bang” upgrades seems to result in just that for me — a big bang and then lots of screaming.

I figured out a pretty tidy way to do this, with tips from Garrick VanBuren and Natn Johnston.  Rather than go into lots of detail about what didn’t work, here’s what did work.  This little recipe is mostly for me, since I’m not going to do all these at once and I’ll likely forget some critical bits if I don’t write them down.

Ingredient 1 — multiple instances on MySQL on the same box

This way, I can move the sites over one at a time rather than crashing them over all at once (and most likely breaking things)

• Download the non-installer distribution of mySQL 5.1
• Unzip it into a new directory
• Set up the “my.ini” or “my.cnf” file (depending on whether you have a Windows server or a non-Windows server) to point at a new port — I used 3307,  one larger than the standard 3306 that’s the mySQL default
• run the new instance from the command line (paying special attention to specifying the correct ini/cnf file) until things are running right.  Here’s an example for the command-line;

  • in-the-new-mysql-bin-directory> mysqld --defaults-file="c:\program files\mysql\mysql server 5.1\my.ini" --console

• Get yer daemon running — on Windows that means setting it up as a service, again making sure to point at the port-3307 version of the ini/cnf file

Ingredient 2 — loading up the new version of the database

• Create a new empty database (in the new instance of mySQL) with the same name as your existing blog’s database, let’s call it “YourBlogDatabase” in this writup — I did this with MySQL Control Panel but there are lots of ways to do this, including the command line
• Create a new user (again, with the same username and password as your existing blog, eg YourSQLPassword and YourSQLUserName), also in the new instance of mySQL
• Dump the existing database (from your old instance of mySQL) — use mysqldump from the command line of the /bin/ directory of the old instance to do this.  Here’s an example;

  • in the old-mysql/bin directory> mysqldump -uYourMySQLUserName -pYourMySQLPassword YourBlogDatabase > YourBlogDatabaseDumpFile.sql

  • Note — the username and password syntax is purposely without spaces
  • Note — pay attention to directories and paths here.  I did all this from the command line and moving between the /bin/ directory of the mySQL instances.  I didn’t set up path variables because I wanted to be very sure of which versions of programs I was using at any given time.
• Reload the blog database (in the new instance of mySQL) — shift back to the new mySQL’s /bin/ directory so you’re sure to be using the right version of the command.  Here’s an example;

  • in the new-mysql/bin directory> mysql -uYourMySQLUserName -pYourMySQLPassword YourBlogDatabase < YourBlogDatabaseDumpFile.sql

  • Note — really use the mysql command here, not mysqldump.
  • Note — I found that sometimes I had to specify the port to get this to work right.   “–port=3307” on the end of the command did the trick
  • Note — be prepared to wait for a little while for this to complete if your database is big.  I’m in hour 5 of a big reload as I type this.
  • Note — if you’re nervous and want to monitor progress, use MySQL Control Panel to watch the tables grow by disconnecting and reconnecting to the database in the control panel and opening up the tables.  See?  They’re getting bigger.  All is well, you just have to wait.

Ingredient 3 — new WordPress Code and new wp-config.php file

After all, this is an upgrade, right?  I was extra-conservative this time through.  Normally, I just dump the new WordPress files right on top of the old ones and it all works fine.  This time, I made backup copies of the directories just in case things needed to be rolled back.  Here are the steps I went through.

• Make a copy of the blog/Wordpress directory and files
• Copy the new WordPress 2.9 files on top of the existing directory (not the backup)
• Replace the old leftover wp-config.php file with a newly created one that’s got all the same info as your old one except:
  • Change the hostname to point at the port of the new mySQL server — here’s an example where I’m pointing at port 3307;

  • define('DB_HOST', 'localhost:3307');

  • Comment out the ‘DB_CHARSET’ line — that avoids the “funny characters in my blog” problem that sometimes arises during this process.  Here’s how it looks if you comment it out (alternatively, you could just delete it);

  • /* define('DB_CHARSET', 'utf8'); */

Try it out!

After all, what could go wrong??   Go to the wp-admin page of your blog.  If things are according to plan, WordPress will want to upgrade the database.  Once that’s done, things should be working normally, except you’re on the new version of WordPress.

What if it breaks?

Oh well, so who’s perfect.  Replace the new WordPress files directory with your old files (I’d rename both directories — so you’ve still got new stuff to play with, but your blog’s running again).  With your old files back in place, your old blog should reappear since it’s now using the old files and the old wp-config file is pointing at the old database.  Then, sit down and figure out what went wrong.

Click HERE for a graphic developed by Brian Solis and JESS3 called “The Conversation  — the art of listening, learning and sharing.”  Sorry guys, I’m not trying to steal your Google love, it’s just that all the places I found your picture made it so small I couldn’t read it.

This is a great 2009 snapshot of a bunch of different platforms that are out there to conduct that Conversation.  It’ll be interesting to check back in a few years and see how the landscape has changed.

OK, so here’s a dead-simple idea.  Shorten your own dang URLs instead of letting the URL-shorteners steal your Google-love.

Step 1 — get yourself an abbreviated version of your domain name.

This site is my old standby blog.  A dumping ground for all the ideas that can’t find a home on one of my other sites.  It used to have the HAVEN.com domain-name but I lucked out and sold that name a few years ago so now it’s on the HAVEN2.com name.  Not bad, six letters, pretty short.  But shorter is better.  So I just ran off and got HVN2.com and loaded it on the server so it points to the same site as HAVEN2.com.

Step 2 — load up the “non-WWW” version of your new shorter domain-name

Egad!  Another 4 letters wasted if you have to put that on your URL!  Make sure that your site answers to the shorter version as well as the “www.” version of your spiffy short domain name.

Step 3 — WordPress users — use the “ugly” version of your links

Here’s a great post from SheepTech that describes how your WordPress blog is already providing you with a darn short URL.  Click HERE to read his article.  In short, your WordPress blog creates a short “ugly” URL in addition to whatever “pretty” URL you’ve specified.  So you can save a bunch of characters by using that ugly URL.  The format looks like this (using the URL for this post);

http://hvn2.com/?p=209

That’s pretty darn short!  Way shorter than the “normal” URL for this post, which is;

http://www.haven2.com/index.php/archives/shortening-my-own-urls

It’s not quite as short as the URL-shorteners, but the nice thing is that it’s MINE.  🙂

I got going on an idea during coffee with Amalia Deloney yesterday.  She was saying the LPFM stations have a tough time filling the hours with programming and my thought was to replicate the old NFCB Tape Exchange using RSS feeds.  Here are some ideas to get people started.

Problem – Not enough programs to fill the day

Idea – Use podcasts (blogs with RSS feeds and audio programs) to aggregate content from a federation of LPFM stations.  Garrick Van Buren built a great gizmo to do this and you can see an example of his system at PodcastMN.  I’m sure Garrick would be happy to help with this.

Problem – Not enough volunteer hours to do the “program director” function for a single station

Idea – Share a program director between a federation of like-minded LPFM stations.  Let the person be the aggregator of multiple feeds similar to the one Garrick does, and then create a feed that drives the daily programs on multiple stations.  The stations could subscribe to this “network feed” and break away whenever they want to do local programming.

Problem – Not enough volunteer hours to operate a single LPFM station

Idea – This gets a little geeky, more for you engineer types.  What about using multiple RSS feeds as the command and control network to operation the stations?  Each station would generate an RSS feed of what it’s doing (playing a file, changing transmitter settings, losing/regaining Internet connectivity, temperature sensing, etc. etc.) and those RSS feeds are monitored by a centralized C&C system that sends station-commands down one RSS feed per station.  Monitor the RSS feeds pretty often (once a minute?) for granularity.  One could use this for both program control and technical control of the station.

Problem – The station isn’t on the Internet

Idea – Use the podcast program-distribution network anyway, but burn the programs to CD and carry them to the station.  What the heck, we used to do this with audio tapes sent through the mail.  This would still provide a really good, cheap source of programming for the federated stations even if they weren’t on the ‘net.

Problem – The station goes off the Internet (thus going out of control)

Idea – Lots of ham remote-control their transmitters (including me).  Many of us have built configurations that poll the Internet and, if the station loses Internet connectivity for some period of time, shuts itself down.  Here’s a link to my configuration, you could use this as a model.  And here’s a link to the remote-controlled power switch that actually monitors the ‘net and shuts the station down if the station goes offline.

Problem – LPFM station doesn’t have any money

Idea – The only thing in this page that costs money is that little switch.  The rest of this stuff you can do for free.

… Just a thought…

More life-hacking.  Here’s a cool concept — from Japan.  Keep track of little everyday things that make life easier.  Click HERE for an article to get you started (a link to a great book is at the bottom of the article).

This book saved my camera a couple days ago.  I dropped it in the snow, the camera was warm so the snow started melting before i could brush it off, the result was a really wet digital camera.  The Urawaza trick was to dump the camera in a bowl of uncooked rice (which acts like those little dry-out packets that are included in lots of electronics).  After a few hours in the rice, the camera emerged dry as a bone and works perfectly.