Browsed by
Tag: github

Uploading photos to Flickr from Eye-Fi card with Raspberry Pi

Uploading photos to Flickr from Eye-Fi card with Raspberry Pi

Helsinki Hacklab’s policy for photographing sometimes puzzles our guests which might come from other hackerspaces with limitedly allowed or strict rules for taking photos, for privacy reasons or some others. Back in 2014 we still had very scattered collection of photos by individual members, maybe hosted on their own homepage or somewhere else, until lost forever. To preserve our history better and and have more up-to-date content online, we decided to make both taking photos and publishing them as hassle-free as possible. So we bought then an Eye-Fi card along with our camera and configured it so that all photos are automatically published in Flickr anytime the shutter recloses. So far, no complaints.

kuva kamerastaBut now, Eye-Fi has announced shutting down its service, which we have used for uploading over 4000 photos during the last 18 months. The X2 product line (and some other models) that are affected by this shutdown have still been sold in 2015. First card we had, a 4GB SanDisk branded version, failed this summer, but luckily one member had an unused X2 Connect somewhere, so we were soon back posting more photos of our weekly activities and blurry accidental snapshots of our feet. But, to continue using this Wi-Fi SD card after the service shutdown, we needed a replacement solution for both getting the photos from the card and sending them into our Flickr photo albums – and maybe making some improvements too.

RaspberryPi 3 in our tele rackWe had just received a bunch of Raspberry Pi 3 boards and tried to figure out what we could do with them, and because model 3 had Wi-Fi capability, connecting to Eye-Fi card could be done using eyefiserver2 project. For Flickr upload, I chose using Flickraw library for Ruby, which seemed to be a well-maintained project, so that possible future changes in Flickr API should not be a problem.

First, eyefiserver2 process is started on startup, this gets the photos from the card into RasPi, then every 5 minutes a Ruby program is run, which uploads new photos and marks them published.

The project (or step by step tutorial) can be found in Github:
https://github.com/HelsinkiHacklab/eyefi_flickr_auto_upload

We previously had all our photos ordered in albums by their date. One thing I wanted to improve was to put photos taken between 0 am and 3 am in same album with photos taken on the previous day, which makes less time line discontinuation when viewing photos by start date of an event. The Ruby program also by default renames photo titles by their timestamps. See our Flickr page for results.

In our setup, the RasPi is connected to Internet using Ethernet, and only the Eye-Fi card’s internal network name and password are stored in known wireless networks. If the camera is used outside our Hackerspace, and there is an Ethernet port for the RasPi available (maybe shared from a computer), we should be able to keep publishing photos from ongoing events, happenings, fairs etc. as we usually do. This is different from Eye-Fi center we previously used, in which we configured the card to know new local Wi-Fi and its password. This task required someone (which is me) to have Eye-Fi Center program first installed, and was usually a dull and slow thing to do during ongoing event or buildup. Now we just have to remember to take the readily configured RasPi with us anywhere we go with the camera.

If you don’t have an Eye-Fi card and would like to build a similar auto-publish system, I can’t say if it’s a good idea to buy an aftermarket Eye-Fi card anymore. Configuring this setup requires user to obtain card specific information that might need Eye-Fi services to be available (you cannot login to or create a new Eye-Fi center account after Sep 16th). If you have the card, but don’t really know what to do with it after Sep 16th, go enable its internal wifi (direct mode network) and store the password and MAC address for possible later use while you still can. If I’ve understood correctly, also the current Eye-Fi product line does not offer Flickr publishing. Try googling “hacking transcend wifi sd” for more ideas. Check out FlashAir API guide https://flashair-developers.com/en/.

(2016-09-01) Yesterday Eye-Fi announced a new tool for older cards, which might help to get card Wifi and MAC information after Sep 16th, which are needed this for python server solution.

Github, testausta ja muuta ohjelmoinnin hienoutta alkeista eteenpäin käytännössä maanantaisin.

Github, testausta ja muuta ohjelmoinnin hienoutta alkeista eteenpäin käytännössä maanantaisin.

Joskus keskikesällä kyllästyin odottelemaan kauan kaivattua kurssia tai
työpajaa modernin ohjelmistotuotannon perustaidoista ja päätin ryhtyä vetämään
moista sitten itse. Ohjelma sopii kaiken tasosille ohjelmoijille ja sisältö
sovitetaan joka maanantai läsnäolevalle yleisölle.

Versiohallinta ja automaattinen testaus eri tasoilla on sen sortin hienouksia,
joiden avulla ohjelmiin voi tehdä muutoksia hallitusti. Testauksen avulla
tiedetään toimiiko se (no, melkein ainakin) ja versiohallinta auttaa löytämään
bugin alkulähteille.

Muutenkin versiohallinta on hieno juttu, projektiryhmän joka koodarilla voi
kaikessa rauhassa olla samat koodit auki omilla koneillaan ja muutokset saadaan
kasattua yhteen yleensä automaattisesti tai ainakin kohtuullisella vaivalla.

Tarkemmin asioista puhuttaessa törmätään tosi nopeesti asioiden erisnimiin.
Versiohallinnan puolesta keskitytään yleisimpään yhdistelmään: Git ja Github.
Näissä työkaluissa on vähän hankalahko kynnys yksin alottaa oppimista, joten
yhteinen oppiminen ja keskinäinen opettaminen on paras tapa päästä alkuun.
Vertaillaan myös eri workfloweja ja puhutaan projektien teknisestä hallinnasta
ja branchien filosofiasta.

Miten sitten testaaminen? Testaaminen jakautuu yksittäisiä ohjelman osia
testaavaan unit testingiin ja kokonaisia ohjelmia ja laajempia kokonaisuuksia
testaavaan integraatio/hyväksyttämis testaukseen. Jälkimmäinen jakaantuu vielä…

Testauksen suhteen nyt keskitytään enimmäkseen unit testaukseen ja sivutaan
aiheena muita testauksen menetelmiä. Unit testaus on ohjelmoijan ikioma nakki
ja apuväline, jolla varmistetaan, että tehdyn muutoksen jälkeenkin
ohjelma toimii ainakin niin hyvin kuin se osataan testata. Nää testit tehään
samalla kielellä kun ohjelmakin.

Tähän liittyen harjotellaan Test Driven Development -prosessia, jossa siis
työtä rytmittää jatkuva testaaminen ja testien kehittäminen samaa tahtia
koodin kanssa. Ihan kaikkeenhan se ei tietenkään sovi, mutta mihin sopii,
sopii sitte sitä paremmin. Joku on luonnehtinu, että tää ois vähän niinku
ohjelmoinnillinen vastine kaksinkertaselle kirjanpidolle.

Laajempia testauksia sivutaan Robot Frameworkilla, jolla voi testata vaikka
nyt sitten oskilloskoopin avulla tuliko ohjelmasta oikean muotoinen ääni, tai
osasko PaaS saada uuden version webisoftasta ajoon tai toimiiko vasta tehty
REST API kunnolla vaiko vaan melkein. Robot on älyttömän laajennettava systeemi,
johon voi kirjotella testejä melkein selväkielisesti ja sitä voi laajentaa
helpoiten Pythonilla.