Amphiro a1 – water monitor

Link

http://amphiro.com/products/a1/

This cool little gadget will monitor your water usage in the shower, to help you try to conserve. Furthermore, it uses the water itself as its power source.

The device does not contain batteries, it harvests the energy for its operation from the running water. The water flow spins a small turbine inside the device. As soon as water runs through the device, it switches on and a small capacitor is charged. The capacitor can supply the display with energy for a few minutes also after the end of the shower. As soon as that energy has been consumed (or at latest after three minutes), the device switches off.

A great example of sustainable technology that can help make a real difference.

So you bought an emoji domain, now what?

Slides

For this entire blog post I’m going to have to use images to represent the emoji for reasons discussed IN this blog post.

Tonight I went and bought what I thought was an awesome domain: Link Emoji.click. Unfortunately, this was rejected as invalid.

I double checked the domain requirements, and it allowed both single characters, and IDNs. So what gives? Well, it turns out you cannot buy emoji gTLDs.

However, I knew that you could buy emoji .ws domains, which I know are the ccTLD for Western Samoa, but I’ve always thought of them as short for .website (which is probably a gTLD by now).

So I bought http://Link Emojito.ws — or as it is in my head: (link)to.(website), get it?

To buy this (or any other domain) you often have to use Punycode, which means this domain is: http://xn--to-n372a.ws.

Then I tried to use it. And that’s when the trouble started.

First, I couldn’t update some WordPress settings, turns out that MySQL prior to 5.5 did not support the full range of Unicode, and it would just truncate at the emoji character. Ugh.

In MySQL 5.5, you can set the column type to be utf8mb4, but prior to that you need to use binary (BINARY, VARBINARY, (LONG|MEDIUM|SHORT)BLOB) column types, which bring with them their own problems, as they are no longer seen as strings (think: sorting, collating, etc).

So I hacked the extension to just hard code in the link, and away we go.

Then I tried to share my new shiny, and that’s when things got really annoying.

While the Twitter client would happily turn the domain into a link when authoring the tweet, it never came through as a link (in the official twitter clients). So I tried the punycode, to make sure that worked… and it turned it into the original emoji URL and linked it. Because that makes sense?

OK, one service down, I switched my WordPress plugin back to using the database, used the punycode as it’s going out to Twitter, it’s all good.

Next I sent it to someone on Facebook Messenger via Adium (which uses the XMPP gateway), and they said it didn’t work. So I went to the Facebook website, and lo-and-behold, it was linking to http://invalid.invalid… uh, that’s not right. I then went to report it to a friend at Facebook using the web IM client, and… it worked. Must be a bug in Adium or the XMPP gateway, right? So I tried to to send it to the first friend again… nope, still invalid.invalid.

Then I decided to share it with my colleagues on Slack. It linked it… but only the to.ws, so I try the punycode, and it shows up as a punycode link, and is linked just fine. Oddly, if I right click > copy link on the punycode, I get the emoji version.

Lastly, iMessage. iMessage did the best, the original emoji URL works just fine, as does the punycode. But as with Slack, if I right copy the punycode URL, I get the emoji version.

So, if you’re considering an emoji domain, be wary. They are fraught with perils. The web is obviously still not ready for the full Unicode spec.

I’d like to blame Zach Holman for some inspiration after seeing his lightning talk on abusing emojis at SydPHP last month: