A presence that fascinates the humans & unnerves the poultry.
Google drive API file upload script
If you want to upload file to Google Drive, you will naturally gravitate towards the Google Drive API. While reading about the APIs that Google publishes for almost anything, you will learn about their SDK. The SDK provides you with easy functions for interfacing with the API for various programming languages.
The problem is that the more I used the SDK the more confused I was. The documentation is often unclear, not all bindings are implemented across all languages. But above all, the thing that made me dislike the SDK is the fact that uploading a file to Google Drive took 5 times the amount of memory than the file itself. Meaning that the datastructure they use and how they pass it around is SUPER LAME. Not a huge deal if you’re uploading a few doc files but definitely crappy for GB range files. It’s just not right and completes the pattern of “meh” surrounding the SDK.
What is clear & consistently documented is every single API call you can make. It was time to go straight to the API. Sure there is still quite a bit of poking involved in getting something working exactly right but my experience with the API has been a lot better. It has also helped me understand the mindset & design so figuring out new things is much faster.
How?
HTTP, every API call uses it. You can use any technology that you are familiar with to do your HTTP call but I have a penchant for PHP + cURL.
The script
It will read a file in chunks and upload them consecutively. Do to so it uses the API’s resumable uploads. As such it will never consume more RAM that the configurable chunk size.
It still needs a few improvements at the moment but it’s functional.
What it solves
- authentication: getting a new access token from a refresh token as needed
- curl custom HTTP requests with custom headers
- file chunking
- Google Drive API resumable upload
- passing JSON encoded requests in body
- exponential backoff
Doesn’t sound like much but it took a while to piece it all together.
Dr. Meter B003+ 300X USB digital endoscope/miscroscope camera
TLDR: an awesome cheap device wrapped in Chinese funkiness.
The details
It is hard, very hard to not pay attention to all the funny details that go around the device. But it’s a solid device that performs great for a good price. As far as I can tell, it does not do zooming per se, it is only able to get very close to a subject and thus when the resulting picture is displayed on a bigger screen, small details are visible. As such, what you see is strictly dependent on how close you stick the camera to your subject. In fact the camera has a focus length of a few millimeters to infinity, which means you ca use it a a regular camera but you’ll have to turn the focus knob quite a bit for that.
First, some pics of what it’s capable of
They are seriously lacking online
The device itself
On its little tripod
The lens
Everything else
The device has multiple attachments referred to as “beauty inspection tools” which are meant to stick the camera in various orifices of one’s body. They are nicely sealed in sterilized bags (but not the anal one).
Some of the various “beauty inspection tools”…
The unboxing feels like opening a Chinese treasure chest, the mechanism, the texture, the looks; this product is made in China and not pretending otherwise. What else feels Chinese is pretty much anything written in English. It’s super funny to read it all.
Technically
The device is recognized as a standard camera in Windows, MacOS & Linux! No extra drivers necessary. This is what I love about buying products from smaller companies, they go after existing standards. As such you can open it with any webcam software, I took my test shots with photobooth. They provide some software for filming & measuring among other things but I care not about this functionality so I won’t spend the time loading it.
I’ll take it to the beehive this week-end and we’ll see how it does there.
Generic English (U.S.) words and their sexual uses
One phenomenon that is extremely confusing for non-native English speakers is how the most generic words can be used to mean something sexual. Whenever I speak I’m a a state of second guessing what I’m saying.
- Do
As in “I did her”. Do you have any idea how prevalent “do” is? It took me years to master it; getting all of its nuances is a true test of English mastery. The last thing it needs is a sexual meaning that is so easy to let out in the most benign conversations.
- Have
As in “I’ll have her”. This one is actually hard to confuse with other uses of “have” as you rarely talk about a person belonging to another in any other context. But that’s a crazy common word.
- Sleep with
As in “I slept with her”. Did you have sex or did you just sleep in the same bed? Better not sleep in the same room as family or the conversation will be filled with incestuous innuendos.
- Come
“Ben, we’re leaving!” “I’m coming!” Does this mean I’m arriving now or later? God only knows.
- Cock/Caulk
If you are a gun enthusiast handyman raising poultry, don’t even try, find synonyms. These guys are pretty context specific but there are multiples of which they fit and as a result, they tend to show up a lot.
Now to be fair, the only other language I’m intimate with (French) has some of the same sexual meanings associated with generic words, but they are fewer and formulated in a way that removes any ambiguity.
Did I miss any?
Mice in cars
They made it into a 2000 Ford Focus, a 2005 Subaru Forester & a brand spanking new 2012 Suzuki SX4. They leave mouse shit everywhere, they literally take dumps non-stop. They even brought the poison I spread around the house into the cabin air filter these fucking little pricks.
It’s an all out war and I’m not taking prisoners.
First, I gave them back their poison, have fun not coagulating bitches.
Second, all of these cars have a path that allows a small rodents into the cabin. The Focus & the SX4 was through the cabin air intake. I still don’t know how they make it into the Subaru.
Here’s how to upgrade a 2012 Suzuki SX4 to have an armored air intake.
Pro-tip I didn’t know, most cars’ cabin air intake is somewhere right bellow the windshield on the passenger side. Usually you need to remove the piece of plastic that is between the windshield and the hood as pictured bellow.
A close up of the air intake and how completely unprotected it is.

Now with protection, it looks pretty bad but it has done the job so far.
Back in business
Here’s how to access the intake from the inside, it gives you access to the air filter. You just need to remove the glove box first, no screws need to be removed.
It’s pretty lame to post my dumb hack online but I’ve had an incredibly hard time finding any information about cabin air intakes for cars so I hope it’ll help someone.
2016-10-17 edit: Commenter André shares the picture of his setup. Ingenious use of self drilling roofing screws!
André: ”we added a few more screws after this was taken to mold the wire mesh tight against the opening”
Chicken cam – back online!
But with a serious loss of functionality. Given the internet connection that I have (cellular) I can’t reasonably set it up to do live streaming. I’ve also disabled interaction with the cam. What’s left is an image uploaded every hour. Not super duper cool but I’ll take what I can get in this neck of the woods.
Hopefully this will get better when better internet is available.

ZFS send/receive accross different transport mechanisms
Sending ZFS snapshots across the wires can be done via multiple mechanisms. Here are examples of how you can go about it and what the strengths and weaknesses are for each approach.
SSH
strengths: encryption / 1 command on the sender
weaknesses: slowest
command:
[bash]zfs send tank/volume@snapshot | ssh user@receiver.domain.com zfs receive tank/new_volume[/bash]
NetCat
strengths: pretty fast
weaknesses: no encryption / 2 commands on each side that need to happen in sync
command:
on the receiver
[bash]netcat -w 30 -l -p 1337 | zfs receive tank/new_volume[/bash]
on the sender
[bash]zfs send tank/volume@snapshot | nc receiver.domain.com 1337[/bash]
(make sure that port 1337 is open)
MBuffer
strengths: fastest
weaknesses: no encryption / 2 commands on each side that need to happen in sync
command:
on the receiver
[bash]mbuffer -s 128k -m 1G-I 1337 | zfs receive tank/new_volume[/bash]
on the sender
[bash]zfs send tank/volume@snapshot | mbuffer -s 128k -m 1G -O receiver.domain.com:1337[/bash]
(make sure that port 1337 is open)
SSH + Mbuffer
strengths: 1 command / encryption
weaknesses: seems CPU bound by SSH encryption, may be a viable option in the future?
command:
[bash]zfs send tank/volume@snapshot | mbuffer -q -v 0 -s 128k -m 1G | ssh root@receiver.domain.com ‘mbuffer -s 128k -m 1G | zfs receive tank/new_volume'[/bash]
Finally, here is a pretty graph of the relative time each approach takes:
SSH + MBuffer would seem like the best of both worlds (speed & encryption), unfortunately it seems as though CPU becomes a bottleneck when doing SSH encryption.
That's as close as they let me get
2 hours tracking them, they were very very sneaky. Given that I was on a sloped terrain, I naturally went for high ground which was a mistake, they can fly away from you much faster going downhill.
[flv:http://ben.akrin.com/wp-content/uploads/2012/10/IMG_1875.MOV.flv http://ben.akrin.com/wp-content/uploads/2012/10/thumbnail.png 688 387]
New toy :D
[flv:http://ben.akrin.com/wp-content/uploads/2012/10/IMG_1786.MOV.flv http://ben.akrin.com/wp-content/uploads/2012/10/Screen-Shot-2012-10-09-at-8.58.34-PM.png 688 387]



































