Melodycode

Molto probabilmente anche voi avete a casa il frutto VIMAR 16450 attaccato a qualche presa (solitamente nei pressi dell’ingresso): il suo scopo è sostanzialmente quello di illuminare nel caso in cui manchi improvvisamente la corrente elettrica (utilizzando le proprie batterie interne).
Una funzionalità aggiunta molto carina è che staccandolo dalla presa può diventare una comoda torcia da portare in giro per illuminare le stanza buie.

Se non avete ancora capito a cosa mi riferisco ecco una foto del frutto (esiste anche nella versione bianca):

Dopo anni di funzionamento il primo componente a saltare sono le batterie quindi, se questo frutto non vi funziona, al 90% è quest’ultimo componente a necessitare di essere sostituito.

Esistono varie “revisioni” della VIMAR 16450, la versione più vecchia non ha le batterie rimovibili al contrario delle versioni più recenti; se avete una versione vecchia, non vi preoccupate, con un stagnatore ed un cacciavite a taglio si può facilmente porre rimedio al problema (non serve essere elettricisti, ve lo assicuro); considerate inoltre che questo frutto, nel caso in cui vogliate ricomprarlo, costa non meno di 70 €.

Ho deciso quindi di acquistare le batterie (4 €) e lo stagnatore (30 €) e in una decina di minuti ho ripristinato il funzionamento della torcia VIMAR 16450.

Le batterie ricaricabili originali erano delle Ni-Mh da 1,2V e 550mAh mentre quelle che ho acquistato sono delle Ni-Mh da 1,2V con 600 mAh (le potete trovare anche su Amazon).

L’unica cosa a cui prestare attenzione è la polarità delle batterie, quindi segnatevi la posizione prima di sostituirle.

Ho fatto delle foto con il frutto smontato, il circuito (in entrambi i lati) e le batterie utilizzate (quelle verdi); spero che tutto ciò vi sia d’aiuto.

Spesso ci troviamo a cercare il nostro nome e cognome su Google per vedere come/dove siamo indicizzati/nominati, stessa cosa ho fatto io l’altro giorno cercando Daniele Simonin: non trovando in prima posizione questo sito ho deciso di creare questo post con la speranza che faccia da Hub per questo tipo di ricerca.

Elenco pertanto i profili pubblici inerenti la mia professione:

• LinkedIn
• GitHub
• GitLab

Ci tengo a precisare inoltre che non ho alcun profilo Twitter, Instagram e Pinterest.

Translated version: English Italiano

TL;DR: Images and sources of my Bartop Arcade.

Those who know me know that in these past months I’ve been finishing my Bartop: an Arcade Cabinet large enough to house the monitor and the control panel (without the coin box).

Main features are:

• Wood cabinet;
• 17″ LCD Monitor;
• Stereo speakers;
• LED backlit Marquee;
• Panel control for 2 players.

For the cabinet design I’ve used Sketchup: I had to learn it by myself taking into account all the issues concerning cutting and measuring the wood.
I’m neither a do-it-yourself expert nor a woodworker, so I’ve done a lot of feasibility study: my dad was a great help.

After the cabinet design, it’s time for the control panel: it hosts 2 joystick and 12 buttons in the top part, leaving free space for 4 buttons (Player 1, Coin 1, Player 2 e Coin 2) in the bottom part.
To make it I’ve used Adobe Illustrator because it’s a tool I’m familiar with and it permits to use millimeters as a measure unit.

As you can see, the panel control (A and B) can be opened to allow maintenance work, same for the rear door (between D and E).

Now it’s time of hardware parts, here’s the shopping list:

• Raspberry Pi 3 (42 €);
• I-PAC 2 (53 €);
• 2 x Seimitsu LS-32 Arcade Joystick (with switch D44X Cherry – 4.8mm) including screws (35 €);
• 2 x Seimitsu LS-32 Shaft Extender (5 €);
• 12 x Happ Competition Arcade Button (with switch D44X Cherry – 4.8mm) (40 €);
• 2 x Happ Concave Arcade Start Button (with switch D44X Cherry – 4.8mm) (8 €);
• 2 x Happ Standard Arcade Button (with switch D44X Cherry – 4.8mm) (6 €);
• 100 cm LED strip (12 €);
• Trust Leto stereo speakers (10 €).

I received a used 17″ LCD Monitor for free (I had to buy an HDMI-DVI for 8 €) and the wood (14mm Poplar plywood) cost me about 50 € (a 80cm x 80cm panel and a 150cm x 50cm panel).

Outsideprint is the site I’ve used for the glass decal: easy to use, fast and with great support.

It was obvious for me to use a Raspberry Pi but I can’t say the same thing for the I-PAC 2: connecting the controls wires (joystick and buttons) directly to the GPIO of Raspberry goes against the modularity principle (a must for me).
The IPAC 2 “transforms” the control panel into a keyboard so I can extend the hardware (regarding the Raspberry and the controls) easily without headaches.

Now it’s time to share some photos of the bartop (finished and during the construction):

How I made a Bartop Arcade

IMPORTANT: If you are interested in making a Bartop, I created a Git repo with all the sources under the MIT license.

This post contains just the essentials info , otherwise it would have been a wall of text.
I thank Arcade Italia for showing me the right way, Retropie for the great software shared to the community and last but not least my dad.

Insert coin…

Questa settimana è stata molto critica per il mondo della sicurezza, infatti sono successe 2 cose molto importanti.

Cloudbleed

Il 17 Febbraio 2017 è stato scoperto un bug di sicurezza nel reverse proxy di Cloudflare che causava la fuoriuscita di dati residenti in memoria come cookies HTTP, tokens, data in POST, ecc…
La scoperta è stata fatta da Tavis Ormandy facendo immediatamente il giro del mondo, il tutto è degenerato quando si è scoperto che questi dati sono stati salvati nelle cache dei vari motori di ricerca (Cloudflare ha collaborato con Google per mitigare questo effetto collaterale).
Attualmente navigando tra la cache di Bing e Yahoo si può ancora incorrere in qualche frammento di memoria sparso tra il contenuto in quanto è difficile riconoscerlo sistematicamente (e quindi eliminarlo).

SHAttered

Il 23 Febbraio 2017 Google ha annunciato la prima collisione in SHA-1, che cosa vuol dire? Quando 2 file diversi hanno lo stesso hash siamo davanti ad una collisione e Google infatti è riuscita a creare 2 PDF diversi con lo stesso SHA-1.
SHA-1 (come altri sistemi di hashing) viene usato per dimostrare che un determinato file non è stato modificato oppure che è stato scaricato correttamente, le implicazioni di sicurezza sono ovvie.
Divertente come WebKit abbia messo in crisi la propria repo SVN committando un test riguardante proprio le collisione SHA-1.
Git è meno sensibile alle collisioni SHA-1 in quanto i 2 file dovrebbero avere anche le stesse dimensioni (rendendo la sfida molto più difficile).

Se andate su GitLab adesso troverete il seguente messaggio:

GitLab.com is currently offline due to issues with our production database.
We’re working hard to resolve the problem quickly. Follow GitLabStatus for the latest updates.

Comunicando attraverso Google Docs scopriamo maggiori dettagli:

• LVM snapshots are by default only taken once every 24 hours. YP happened to run one manually about 6 hours prior to the outage
• Regular backups seem to also only be taken once per 24 hours, though YP has not yet been able to figure out where they are stored. According to JN these don’t appear to be working, producing files only a few bytes in size. It looks like pg_dump may be failing because PostgreSQL 9.2 binaries are being run instead of 9.6 binaries. This happens because omnibus only uses Pg 9.6 if data/PG_VERSION is set to 9.6, but on workers this file does not exist. As a result it defaults to 9.2, failing silently. No SQL dumps were made as a result. Fog gem may have cleaned out older backups.
• Disk snapshots in Azure are enabled for the NFS server, but not for the DB servers.
• The synchronisation process removes webhooks once it has synchronised data to staging. Unless we can pull these from a regular backup from the past 24 hours they will be lost
• The replication procedure is super fragile, prone to error, relies on a handful of random shell scripts, and is badly documented. The staging DB refresh works by taking a snapshot of the gitlab_replicator directory, prunes the replication configuration, and starts up a separate PostgreSQL server.
• Our backups to S3 apparently don’t work either: the bucket is empty

So in other words, out of 5 backup/replication techniques deployed none are working reliably or set up in the first place.

A quanto pare le repo sono salve mentre non si può dire la stessa cosa per gli issues e i merge requests, morale della favola?
E’ giusto fare i backup ma è altrettanto importante testarli!

UPDATE: GitLab ha scritto un post dopo la tempesta. Un applauso per la trasparenza e per il modo in cui hanno affrontato il problema.