Back in the 70′s, subliminal messaging was a controversial topic. I remember running across a book from that same year called Subliminal Persuasion that had a lot of images from advertising and movies with supposedly embedded suggestive words and images, primarily of a sexual nature. Check out the Subliminal Manipulation blog if you don’t sex believe me.

Take a closer look at the hair of the guy on the Mixology cover. Now, think about other parts of a man’s body. Good luck getting this image out of your head (no pun intended) anytime soon. I’m really, really sorry.

Next up we’ve got a dude confidently sporting a pink suit. The previous sentence is the only known sentence on the internet including the words dude and pink suit, but not the word pimp. Ignore the faint yellow polka-dots. I double-checked the pamphlet and they must be a scanning artifact. I was so hoping they weren’t, though. I think my scanner understandably puked on the image.

Almost everyone knows his Zodiac sign today. But few have any real knowledge of astrology.

Intent of astrology data herein is simply to inform, not to advise. Therefore any personal application is the individual’s responsibility.

Check out Mr. quilted pants on the left. What grandmother wouldn’t want to see her granddaughter coming home with a nice boy wearing a handmade quilt? OK, besides any grandmother with something against hobos. Those pants are so appalling that I almost didn’t notice the crazy blue plaid suit in the back. He’s channeling Rodney Dangerfield from Caddyshack, but coming up well short. Powder blue cardigan boy looks positively normal in this photo.

If your party kilt is at the drycleaner, a full tartan suit is always a great substitute. It’s a little hard to see, but, yes, those are matching pants. Fortunately, I don’t think it’s the royal Stewart tartan. Too bad his promiscuous plaid partner up front isn’t in a matching tartan. I can’t identify the tartans for certain due to the cumulative retinal scarring, but I’m suspecting they’re variants of the Montgomery Ward tartan.

If you’re daring and desperate for the full pamphlet in a high enough resolution to actually read it, download the 2 MB zipfile.

When I first glanced at the image of the remote control, I thought the bottom left button said “Lasers”. Now, that would be freaking awesome. Whether as a laser light show to accompany the event or as a modern alternative to the incineration of your contributions, I’m all for it. And surely a couple frickin’ lasers would come in handy when kicking some Neorest butt.

However, if you are returning a very large ResultSet, the client will have to allocate a lot of memory on the heap. If you end up accessing each row to create an object from the data, then you will need enough heap space for the entire ResultSet plus all of the objects you instantiate.

The driver documentation explains how to force the driver to stream the ResultSet row-by-row.

The first catch is that you must be using a regular Statement object, not a PreparedStatement.

The documentation says you need to add the following non-intuitive code before executing the query:

stmt = conn.createStatement(java.sql.ResultSet.TYPE_FORWARD_ONLY,
              java.sql.ResultSet.CONCUR_READ_ONLY);
stmt.setFetchSize(Integer.MIN_VALUE);

though you can actually just use conn.createStatement() since TYPE_FORWARD_ONLY and CONCUR_READ_ONLY are the defaults.

There are a couple caveats in the documentation, though they are fairly obvious. You should process the ResultSet as quickly as possible, since locks will be held as long as the statement (and any transaction it is in) is open.

In addition to being non-intuitive, setting the fetch size to Integer.MIN_VALUE might cause unexpected results if you run your code against a database server other than MySQL.

If you’re willing to go all out in committing to MySQL, you can cast the return value of createStatement() to com.mysql.jdbc.Statement.StatementImpl and then call enableStreamingResults(). That will, at least, make the behavior of your code more obvious.

At work I needed to cache a lot of data from a couple of tables. Using the default behavior caused the heap to grow to over 12.5 GB. That made for trouble when running on my 8 GB laptop. By switching to streaming the ResultSet, the heap maxed out at only 5 GB.

Fast forward nearly ten years and not only have the tools and libraries come a long way, but there are many more free or inexpensive hosted services that simplify building a tool/service like PhoneBlogger. Instead of hosting the application code on a shared hosting site, I can now build and deploy on Google App Engine. Though scalability is not an issue for my personal use of PhoneBlogger, if it were turned into a public service, App Engine would make scaling much simpler and more economical. App Engine also makes deployment a snap, though with a small amount of work, so would Fabric. For my PhoneBlogger rewrite, I decided to use App Engine.

In the original version of PhoneBlogger, I coded a bunch of static VoiceXML and JavaScript for managing the telephone interaction with a caller. At the time, three of the most prominent services for VoiceXML developers were Tellme (now owned by Microsoft), BeVocal (now owned by Nuance) and Voxeo (still independent). I had to write slightly different code for Tellme and BeVocal, but the differences weren’t that significant. I think it would have been pretty simple to port to Voxeo, as well. Improved support of VoiceXML 2 would now likely allow me to use the same code on each platform.

While VoiceXML is still a great option for building speech apps, a couple of new services bring you simple APIs for building speech or DTMF (touchtone) applications, at the cost of portability. This time around I’ve started with Twilio. I very quickly turned a Python/GAE example from the Twilio website into a DTMF app for tweeting by phone. Although speech recognition allows you to build much more complex and natural applications, many simple applications can be built quickly and easily with just support for pressing keys to provide input. PhoneBlogger falls into that category, for now.

One very convenient thing about Twilio is that I can use their platform to capture and host recordings in a format that is simple to play back in a web browser. If I were really concerned about longevity of the recordings I could easily retrieve them and store them elsewhere, but I’m okay with keeping them on Twilio servers for now. That’s an easy enhancement to add later. The biggest downside for tweeting the Twilio links is that the Twilio recording URLs are ginormous. Fortunately, the goo.gl URL shortener made quick work of that problem.

I’m also going to take a look at porting my code to Tropo, which is a service offered by Voxeo. Tropo is built on Voxeo’s Prophecy platform and offers speech recognition as an option.

I decided to begin the rewrite by first supporting tweeting by phone. Twitter offers a great API, which is made even simpler by libraries like Tweepy. I highly recommend first checking out the OAuth support in any library for Twitter you might consider using. OAuth can be a complex beast, but libraries like Tweepy make it almost trivial.

The original PhoneBlogger source code and a couple iterations of it are available on SourceForge. I wasn’t particularly interested in learning about CVS at the time, so I just uploaded tarballs of all the code. While SourceForge has improved a lot, I’ve become more of a fan of GitHub. Google Code, LaunchPad and BitBucket are also great options. I started using LaunchPad when working on a Java library for Gearman, but then set up a couple of repos on GitHub when I started working on Log4mongo-Java. I’m much happier with Git, Bazaar and Mercurial than Subversion and CVS (Caveman Versioning System). I’ve already started posting code for the new phoneblogger project on GitHub.

As of now, the new version of PhoneBlogger supports tweeting by phone. All the code is on GitHub, along with a README file with the basic steps to set it up for yourself. In an upcoming blog post I’ll walk through those steps in a little more detail.

The right way is to execute SET SESSION sql_log_bin=0; on your current connection before running the statements you don’t want replicated. Then, either execute SET SESSION sql_log_bin=1; or close the connection.

The crazy way is to execute the statements while the default database is set to a database that is not replicated. Many DBAs configure MySQL servers so that the mysql database is not replicated, since it may contain user and host info that is specific to a server instance. When the default database is set to a database that is not replicated, mysqld will not replicate statements affecting any database. Feature or bug, you be the judge.

In my example scenario below, db1 is the master and db2 is the slave.

First, create a table in the test database and verify it is replicated. Here’s an example create statement.

mysql> CREATE TABLE test.rs (a INT);

Then, use the MySQL CLI to connect to the master database server (in this case, db1), set the default database to mysql (-D mysql) and execute an INSERT statement. The short version of this is:

[me@server ~]$ mysql -u me -D mysql -h db1 -e "INSERT INTO test.rs VALUES (1);"

Then, verify that the row was added on the master, but not on the slave.

[me@server ~]$ mysql -u me -h db1 -e "SELECT * FROM test.rs;"
+------+
| a    |
+------+
|    1 |
+------+
[me@server ~]$ mysql -u me -h db2 -e "SELECT * FROM test.rs;"
[me@server ~]$

And if you haven’t already guessed, the insane way is frequently the accidental source of many out-of-sync situations. Use the sane way to fix the damage.

Of course, the easy way to sync up tables on out of sync servers in a replication chain is to use mk-table-sync.

10Gen put on another excellent MongoDB conference last Friday, this time at Microsoft Research in Mountain View. Like Mongo SF, there was a good balance between intro and advanced material, as well as between 10Gen presenters and third party presenters, like myself. Registration was smooth, sessions ran on time, they made it easy on presenters, presentations were videotaped, audio was recorded with a direct feed, food was adequate (though putting squeaky bags of chips in rooms was not a good idea), 10Gen people were really helpful and the after party at Tied House was excellent.

And best of all, I talked my way out of an undeserved traffic ticket while leaving Microsoft Research. The car in front of me pulled into the street and then stopped to wait for a car to go by. I pulled up to the stop sign and stopped, since he was already in the street. When he finally pulled away, so did I. Fortunately, the cop accepted my side of the story and let me go. He was actually pretty nice about it.

Below are the slides from my presentation on Logging Application Behavior to MongoDB. If you’re interested in logging to MongoDB from Java, Python, Ruby, PHP and/or C#, I hope you’ll find them useful.

I’m currently on the agenda to present on the same topic at the January 18 San Francisco MongoDB Meetup. By then, I plan to have more detailed info on analyzing data that has been logged to MongoDB.

Yesterday I received my first ever 419-style spam/scam by US Postal mail. It was actually posted from Dar es Salaam, Tanzania, with a cool rhino stamp that cost somebody 800 Tanzanian shillings, which is currently about 55 US cents.

My correspondent is allegedly CHARLES TAYLOR (JNR), son of Liberian strong man Charles Taylor. Daddy is now locked up in The Hague awaiting trial for his role in the civil war in Sierra Leone. And, no, he did not have a role in the design of the classic Converse sneakers, though it hasn’t been proven yet that Naomi Campbell didn’t decorate her chucks with sanguine diamonds courtesy of the Chuckster. Seems like Chuckie, Jr., is reaching out to people in Spain, as well.

It’s a pretty sweet offer, as I would be in line for a minimum of nearly $90 million USD.

I’ve very excited to be speaking on Logging Application Behavior to MongoDB at Mongo SV 2010 in Mountain View on December 3rd. Interest in the conference has soared and 10Gen is now expecting 500 attendees. Just a week ago, they were at 300 attendees. They had to add a fourth track of talks to handle the interest.

If you’re going to be at Mongo SV, please let me know or look for me at the conference. I’ll obviously be easy to find between 2:45 and 3:30 pm.

In my talk I’m planning to cover:

• Why MongoDB is useful for application logging
• Strategies for logging to MongoDB
• Commonalities in logging libraries
• General purpose and MongoDB-specific logging libraries for:
  • Java
  • Python
  • Ruby
  • PHP
  • C#/.NET
• Analyzing logs in MongoDB

ERROR 1005 (HY000): Can't create table 'test.b' (errno: 150)

$ perror 150
MySQL error code 150: Foreign key constraint is incorrectly formed

Oftentimes, the problem is actually with the columns that are referenced in the constraint. A careful comparison of the two tables revealed no differences in the column definitions. However, the column definition doesn’t tell the whole story.

It would be painful if you had to declare the character set each time for every character-based column. So, MySQL lets you define the default character set for the table, and each character column will inherit that specification. The table inherits from the database setting and the database inherits the systemwide setting. So, visually inspecting the CREATE TABLE statement may not be sufficient.

In our case, the first table had been created when we had been using a systemwide default character set of latin1. We had since changed to using utf8. Since the columns that were being referenced in the constraint were varchars, the character set needed to be the same. This would not have been an issue, of course, if the columns had been integers or some other non character-based column.

The statements below can be used to recreate the error message. It’s more obvious in this example, because the default character set is explicitly stated. Default values are great, until they silently sneak up on you and gnaw your hand off.

CREATE TABLE a (
	id VARCHAR(10) NOT NULL,
	PRIMARY KEY (id)
	) ENGINE=InnoDB DEFAULT CHARSET=latin1;
 
CREATE TABLE b (
	id VARCHAR(10) NOT NULL,
	FOREIGN KEY (id) REFERENCES a(id),
	PRIMARY KEY (id)
	) ENGINE=InnoDB DEFAULT CHARSET=utf8;