If you ever run across this while fighting with Hibernate, one quick fix is to instruct JDBC to turn the bad date values into NULLs, eg:
jdbc:mysql://localhost/test?zeroDateTimeBehavior=convertToNull&autoReconnect=true&characterEncoding=UTF-8&characterSetResults=UTF-8
Your mileage side-effects may vary.
More excellent Java + J2EE tips (and lots of other stuff in Czech) here.
Ron Paul calls Bernanke out on exactly what he plans to do: Flood the market with even more credit.
I agree with Ron Paul. Pandora’s box has been open for quite a while now. There’s nothing but a vacuum left to try and re-inflate.
This is a godsend. Wish I had thought about doing this before.
$ diff source/worksforme.php <(ssh -n me@liveserver cat /home/me/source/worksforme.php)
You can also compare files on two remote hosts.
$ diff <(ssh -n me@testserver cat /home/me/source/worksforme.php) <(ssh -n me@clientserver cat /home/me/source/worksforme.php)
If you find that you need to access a Mac from a Windows box, probably you’ll find yourself surfing the specs of a variety of Win32 X-Windows clients. Here are some that I tried:
Cygwin also has an X client, but I didn’t muck around with that.
RealVNC is (I think) the original. I’m guessing that the others are forks of Real, and that either Echo is a fork of Ultra or Ultra a fork of Echo. Tight seems to be a fork of an earlier, simpler version of RealVNC. And, according to their website, is “fully compatible with the standard RFB protocol used in VNC.”
It’s not surprising then that, out of the box, TightVNC is the only client I could get to connect to a Mac from my Vista machine at home. Tight’s refresh/rendering is plenty slow, but gets the job done.
When in doubt, reboot. Nokia’s reset codes are pretty easy to remember if you use the “RES” and “RST” mnemonics.
Soft reset code: *#7370# (*#RES0#)
Hard reset code: *#7780# (*#RST0#)
Literally. I was just alerted to this site here:
http://coolepochcountdown.com/
As you can see, in less than five days the Epoch time will reach 1234567890. Ephoch time is, of course, POSIX time, a popular time-keeping method for Unix which is measured in the number of seconds that have passed since the POSIX clock started virtually ticking at midnight on January 1, 1970 (not including leap seconds).
I hereby call on all geeks everywhere to begin immediate global Epoch time party mobilization. We’re gonna party like it’s 915148800!!
Or, well technically we’re going to party like it’s 915148800 + 319419090 plus or minus some leap seconds. Which happens to also be this coming Friday the thirteenth. Which might be unlucky except that it falls before Valentine’s day in the year of the Bull, so…
Er.. Nevermind, just get some booze and spread the word.
Recent versions of WordPress like to second-guess the internal and external encodings used by mbstring when assembling data from the database and spitting it out to blog pages. Probably this works fine for most, but if you have an older database storing text as something other then UTF-8, probably you have a custom chunk of mbstring configuration in an .htaccess file or similar; perhaps like this:
php_value output_buffering 1
php_value output_handler mb_output_handler
php_value mbstring.language Japanese
php_value mbstring.internal_encoding EUC-JP
php_value mbstring.http_input auto
php_value mbstring.http_output SJIS
php_value mbstring.encoding_translation 1
WordPress’s second-guessing will break this, resulting in a bunch of garbled posts. To fix, comment out this chunk of code in wp-settings.php:
/*
* In most cases the default internal encoding is latin1, which is of no use,
* since we want to use the mb_ functions for utf-8 strings
*/
if (function_exists('mb_internal_encoding')) {
if (!@mb_internal_encoding(get_option('blog_charset')))
mb_internal_encoding('UTF-8');
}
With this gone, WordPress will stop second-guessing and custom encoding translations should flow through just fine.