<< Previous | Home | Next >>

Google: developers, developers, browsers !

Is it possible that a single company be responsible for both the best browser out there along with the worst one?

As it turns out, yes it is possible, and yes it does exist: Google.

Since the first release of Chrome, it has become my browser of choice: Fast, fast, stable, fast, versatile, and the easiest to debug. I did not think about it for a minute. Plus, as a developer, it is one of the most advanced browsers and allow many cool things. All in all, kuddos for your browser there, good work.

Then came Android, with a default browser also based on WebKit. I - among many - thought that it was a "mobilized" version of Chrome. But no, they did another browser altogether. Fine.

Now, it isn't as fine as we hoped at the time. It seemed obvious - knowing Google - that their browser would kick ass. But no, it doesn't kick ass: it sucks. In fact, among friends we call it "The IE6 of WebKit". "The IE6" refers to the disabled child in the family. There is a surprisingly homogeneity in the WebKit browsers if you exclude Android's default browser. And once every 5 times, you do something that works on iOS, Chrome, Safari... and Android stumbles on it.

Now, it's been several loooong years for web developers, and still there are so many areas that lag behind all other mobile browsers... that I'm starting to lose hope. Really. Despair crawls into me day after day, week after week, month after month.

So Google, pleeeeeeease, just give it the attention it needs, or replace it with Chrome, but pleeeeeeeease, do it fast. Seeing as 1/3 of the traffic from Android comes from version 2.3, we know one thing for sure: even when Google gets its act together on that front, it'll be quite a while for web developers to be able to forget this pain.

Please. Act quickly.

Categories : CSS, html, Android, JavaScript

Just released: color-finder

ColorFinder is a small javascript library that detects the main color in an image. The algorithm is simple and flexible. By the way of a callback method, you can influence the results by favoring certain types of colors. You can find it here: http://pieroxy.net/blog/pages/color-finder/index.html You can also have a look at the GitHub repo.

Categories : JavaScript

MySQL charset hell

There are not a lot of paradises on this corner of the earth, but there's one sure hell: charsets with MySQL. MySQL has the peculiar idea of defaulting everything to latin1. Everything.

Everything should be utf-8 of course, just because it fucking works with every character on earth.

Now, let's assume you got the following error message somewhere in some obscure logs:

Illegal mix of collations (latin1_swedish_ci,IMPLICIT) and (utf8_general_ci,COERCIBLE) for operation '='
This means one thing: you're in MySQL charset hell. Welcome in. You're deep in. It's hot.

The road to heaven

First, you will need to edit your my.cnf file, to be found on linux in /etc/mysql/ and add/modify the following properties in the proper section:
[client] default-character-set=utf8 [mysql] default-character-set=utf8 [mysqld] default-character-set = utf8 collation-server = utf8_unicode_ci init-connect='SET NAMES utf8' character-set-server = utf8
The goal is to see everything as UTF-8 while running the following:
show variables like 'char%';
The result you want is this:
+--------------------------+----------------------------+ | Variable_name | Value | +--------------------------+----------------------------+ | character_set_client | utf8 | | character_set_connection | utf8 | | character_set_database | utf8 | | character_set_filesystem | binary | | character_set_results | utf8 | | character_set_server | utf8 | | character_set_system | utf8 | | character_sets_dir | /usr/share/mysql/charsets/ | +--------------------------+----------------------------+
Similarly for collation:
mysql> show variables like 'collation%'; +----------------------+-----------------+ | Variable_name | Value | +----------------------+-----------------+ | collation_connection | utf8_general_ci | | collation_database | utf8_general_ci | | collation_server | utf8_general_ci | +----------------------+-----------------+

Now what?

Now, you're still in hell, but you just got the promise of not getting deeper. And you still need to get out, that is to change all your tables to store UTF-8. There you have several options, some consisting in dumping everything, recreating a new DB and reloading everything (see the second link below). I chose the path of the ALTER. Here is what you can do:

Migrate your dbs:


Locate the faulty tables:

SELECT table_schema,table_name, column_name, character_set_name FROM information_schema.`COLUMNS` C where character_set_name = 'latin1';

Migrate column after column:

Of course, the CHAR(50) piece (and eventual other options such as NOT NULL) depends on the column. Good luck.

And remember: For every MySQL install you do from that point on, do this first. Less trouble for after.

Categories : General rambling

lz-string: We'll try to make it faster

I've setup a small page where I share my findings in trying to optimize the implementation of lz-string. This work will continue in the coming weeks. You can leave a comment in this blog entry for any feedback.

Categories : JavaScript

Just released: lz-string

lz-string is a compression program for JavaScript in the browser, based on LZW. It is fast, meant for localStorage or any other string-based storage in JavaScript, and is particularly efficient on short strings.

All can be read on the home page: http://pieroxy.net/blog/pages/lz-string/index.html And a demo can be found below for live compression: http://pieroxy.net/blog/pages/lz-string/demo.html

Categories : News, JavaScript

Tomcat, Java and https

So I recently acquired a free https certificate from StartSSL. All well and good, this was fairly easy. Now, I have 4 files at my disposal:

ca.pem pk.mydomain.com ssl.crt sub.class1.server.ca.pem

At that stage I'm fine. I'm about to configure https and will go on with my life. As it turned out, things aren't exactly going to turn out that way.

Tomcat needs a keystore. None of those files will make the trick of course, but none of the stupid attempts I was about to try made it any more. It's not about just throwing the three certs in a keystore. Oh no, it's a bit more than that.

As usual, Stackoverflow bootstrapped me in the right direction.

openssl rsa -in pk.mydomain.com -out out/ssl.key cat sub.class1.server.ca.pem ca.pem > out/intcacerts.pem openssl pkcs12 -export -in ssl.crt -inkey out/ssl.key -certfile out/intcacerts.pem -name "mydomain" -out out/keyandcerts.p12
And that's it. Now, in the server.xml you would find the following:
... keystoreFile="/path/to/my/keystore/file/keyandcerts.p12" keystoreType="PKCS12" ...
And that's all. If you have several domain names running on your Tomcat instance, you need a certificate that will accommodate them all, because to this day, Tomcat cannot use a different certificate for different hosts.
Tags : , , ,
Categories : Java
<< Previous | Home | Next >>