posted Dec 13, 2015, 7:22 PM by Sami Lehtinen
updated Dec 13, 2015, 7:22 PM
- Nice article how to use Bayesian ranking of items with up and down votes or 5 star ratings. I might find this article actually useful in near future.
- Read a few articles about Lithium-air battery. It might well be the next big battery technology being widely used.
- Tor Messanger allows you to easily chat securely, anonymously and privately over Tor Network.
- Let's Encrypt is great. Let's hope it really breaks trough. Their abuse prevention is really limited, I've used similar methods. But I think it's very reasonable attempt to prevent abuse. Yet as said, it'll fail. Main problem is that people don't understand what SSL/TLS / lock means. It doesn't actually really much mean anything at all, especially with DV certs. Well, you don't need to trust CAs if you don't want to. For high security sites, I'm using public key hash check and I totally ignore the more or less useless certificate. So in that sense, self-signed is much more reliable than 'trusted via CA' certs. If personally know who sent the key, and I've verified out of band that it's the right one. Then I prefer trusting the key instead of some 3rd party claiming it being authentic. Here's Let's Encrypts article about Phishing and Malware and CA's role.
- The Open Graph Protocol - I noticed a huge gap in my skill set. Gotta learn this, experimented for an hour and got very happy with my results.
- Absolutely excellent post about how to configuring SPF and DIKM for your own mail server.
- Amazon QuickSight - Yet another BI solution, I just had to check it out. It sure does look very much like the Tableau, which I've really loved. I also liked the Storyboard feature. I wonder if the SPICE is as awesome as Tableau pre-processor which makes many analysis really much faster than similar tasks would be using standard SQL. I just can't wait for the preview. kw: QuickSight, Amazon, SPICE, BI, Data Visualization, Analytics, Insights
- I've been helping a few friends building their system data structures and database design. Efficient compact storage, great performance and relations so that data can be actually pruned from database without causing any major problems. I've seen so many cases where relational database is designed in a such way that pruning data can't be practically done, because primary keys or database record IDs are linked with other data so badly that it would be simply too hard. That's something which needs to be accounted for when creating the database. Statistics data also needs to be purposefully non-linked, so it can be saved and works perfectly even if rest of the data structures have been removed from the database.
- Carefully studied OpenBazaar Oracles and Risk Contracts post. It's interesting to see how they can standardize insurances using JSON market objects.
- Only one thing slightly annoyed my with SendGrid. I usually prefer reusing code, but some guys just love doing same thing differently every and each time. Like when they send success message via webhook, it's encoded differently from failure message. application/x-www-form-urlencoded vs Content-Type: multipart/form-data; boundary=... Just why you can't do it similarly every and each time? Sometimes I feel like guys designing stuff are trolling others. Let's think hard, how we can make everything as annoying as possible. Instead of how we can make this smooth and nice. Yep, I've seen way many software which are either designed very badly, or they're just laughing like crazy each time when someone tries to use their crazy API.
- Sometimes it would be just so fun to make it so that each field in JSON document would use different character encoding, let's mix in octal, hex, base64, uuencoding and all kind of stuff, how about rot13? And so on. Actually part of the data could be XML embedded in JSON. Why? Well, just for fun. And let's use urlencoding too, we have many options why not to use all of those. And date and timeformats and units. Could we fit in same document milliseconds, seconds, weeks, days, hours, some field with UTC time and some with time and timezone. Options are endless. How about inventing our own number formats? Like decimals must be prefixed with sign like -/+ and then 12 digits and two decimals, without separator. So -2.14 would be -00000000000214 are we having fun yet? If number is positive, don't use +, we require that you use 0 instead of -.
- Unicode homoglyphs also allow almost endless possibilities. Do you think this is eight? ８ or this is Ϻ? Also requiring field content to be ｘ can mislead someone. Did you say the variable name included dollar sign ＄ ok, but which one of those. function（） right?