The concept of the Uncanny Valley comes from robotics, its hypothesis says that when humanoid robots move and feel almost, but not completely like the real thing, they can be more off-putting than the robots that have less human likeness.
Working on quite a few hardware projects these days, I started to wonder (okay, say it out loud: worry), that there’s an uncanny valley for hardware projects as well. My theory goes such that hardware projects that are almost, but not completely professional can be more off-putting (or underwhelming) than less advanced, clearly maker projects and prototypes.
After trying Resin.io briefly with a SomaFM Streaming Application, I was eager to experiment more with their cloud deployment platform. Maybe some new hardware, maybe some more complex project… In the end, it became a little bit of both: here’s MrEdison, and portable IRC chat display based on Intel Edison.
Checking out the chatter on the #ubuntu channel
The idea came from the fact that we have an IRC channel for the Taipei Hackerspace, #taipeihack on Freenode, just it is not very well (or rather: at all) frequented by people. I wanted to break that channel out of the computer, and put a physical window to it in the ‘space, so people can see what’s going on, and hopefully want to get on too!
I have my fair share of playing with embedded Linux and Internet of Things projects these days, but the real treat is finding projects occasionally that just blow me away. Through some Hacker News comments I ended up checking out Resin.io, a tool that brings cloud deployment and management to embedded applications. That might simple (boring?), but here’s the workflow in a nutshell:
Start a new application and download an image file for your chosen single board computer (1 of 5 choices at the moment: Raspberry Pi 1 & 2, Parallella, Intel Edison, and BeagleBone Black)
Flash the image onto an SD card, connect the board to the network, and boot it up
The board shows up in the cloud management console, and you get a git repo address
Make an application (Docker, Node.js, etc.), do a git push: voila, your board’s running your app
Flash a few more SD cards, connect the devices to the network, all of them will run your application
Modify the app behaviour through environment variables, either all of them at once, or customize each
Check status, logs, updates, online, and enjoy that things just work!
I cannot emphasise enough how good any service feels that 1) runs by git pushing code, and 2) just works.
SomaStream
To try it all out, I’ve put together a very simple application: SomaStream – the SomaFM internet radio streaming app.
SomaStream device status (image uploading)
Grabbed my RaspberryPi that didn’t do much lately, plugged an earphone in it, and started to look for some examples in the docs how to make it play some streaming music.
My previous post, titled SSL status of Taiwanese banks: a sad affair sparked a lot of visits and lot of discussion, clearly touching on something important. It was great to bring to light how well (or badly, in this case) these organizations are doing, as internet security should be one of their key focus.
Many of the organizations improved their setup since then, and it became quite troublesome to manually check each bank and each change, update the table and so on. It’s also good to have not just a snapshot in time, but a continuous record of how they were doing.
Today there was a story on Hacker News, how someone tweeting a screenshot of a bank’s SSL certificate got harassed by the bank in Greece. This got me thinking about the status of the banks here in Taiwan, especially how this place is so wired and online now. So I took a list of taiwanese banks and run each of their sites through the SSL Test. From past experiences I haven’t had my hopes up, but boy is the result ugly…
The usual result of this exercise
SSL Test Overview
I had a list of 43 banks, and for a quick overview I took into account a few key features only. The first is whether there are any active vulnerabilities against the site according to the test (these were mostly CRIME, FREAK, and POODLE attacks). The second is whether RC4 encryption was enabled, as it is now prohibited, and having it on is an automatic Payment Card Industry Data Security (PCI) compliance failure, according to one of the commenters. Other various warnings are mentioned when something really stands out, they are not crucial but more nice to have (though I’d contend that Forward Secrecy and HTTP Strict Transport Security is more than “nice” for anything financial).
