Instalarea unui filtru CPL pe Vico TF2+

M-am uitat cu jind preț de câteva minute la noua serie Marcus de la Vicovation. După care am cântărit modul în care filmează și am ajuns la concluzia că partea care-mi lipsește cel mai mult este absența suportului pentru montarea unui filtru CPL.

După ce am studiat vreo câteva tutoriale de pe DashCamTalk Forums, am ajuns la concluzia că ideea folosită de Marcus cu filtrul montat pe quickmount este viabilă și pentru TF2+. Ideea este aplicabilă și pentru celelalte camere din serie care au aceleași dimensiuni și accesorii.

Am pus pe lista de cumpărături:

  • Inel de reducție Cokin, 52 – 43 mm ~ 20 lei
  • Filtru CPL Hoya – slim mount, 52 mm ~ 100 lei
Inelul de reducție

Inelul cumpărat mi-a confirmat faptul că am făcut corect măsurătorile. Este metalic, deci nu există riscul să fie stricat de filetul de pe filtru. A putut fi dus la dimensiunea dorită destul de ușor.

Dimensiunea inferioară de 43 mm cade bine peste gura suportului de quickmount al lui Vico TF2+. Filetul acestuia, este totuși prea înalt pentru o prindere directă de suport. Cei de pe DashCamTalk am văzut că preferă prinderea folosind bandă dublu-adezivă. Eu am mers pe o soluție mai voinicească.

Inel de reducție prelucrat

Am șlefuit aproape tot filetul de 43 mm al inelului de reducție. A mai rămas din el în jur de 0.5 – 0.6 mm pentru a-i oferi o oarecare prindere în gura suportului. Scutește de efortul de a centra inelul pe când se aplică adezivul.

Am folosit șmirghel cu granulație de 120. De acesta aveam la îndemână. După care am folosit șmirghel cu granulație de 50 pentru a finisa procesul.

Potrivire inel prelucrat

Precum se observă în imaginea alăturată, inelul se potrivește bine în gura suportului. A urmat pregătirea pentru aplicarea adezivului. Inelul și suportul au fost spălate sub jet de apă pentru a înlătura resturile rezultate în urma prelucrării inelului de reducție. După care le-am uscat cu uscătorul de păr.

Conform recomandărilor din instrucțiunile tuburilor de adeziv, suprafețele care au urmat a fi lipte au fost șlefuite ușor. Adică marginea suportului quickmount și baza inelului de reducție. A urmat curățarea suprafețelor. Producătorul adezivului recomandă acetona sau un produs propriu.

A urmat amestecarea adezivului, pe bază de rășini epoxi, folosind tăvița și spatula furnizate în pachet. Cantitatea folosită a fost în jurul dimensiunii unui bob de fasole mic. Chiar și așa, a rămas puțin adeziv nefolosit în tăviță. Am aplicat un strat destul de subțire, pe cât mi-a permis vâscozitatea amestecului.

Timpul în care poate fi prelucrat este de aproximativ 2h. Are un timp de uscare la 20oC între 6 – 8h. Eu l-am ținut timp de 11h sub o greutate ușoară. Dimineața suportul era bun de utilizat. Timpul de uscare completă a adezivului este 24h.

Adezivul folosit este Bison Epoxy Universal. Nu este pe lista de cumpărături pentru că-l aveam achiziționat anterior. Se găsește la un preț începând de pe la 14 lei până pe la 20, în funcție de comerciant. În mod normal asemenea adeziv intră în categoria “overkill” pentru fixarea unui inel de reducție din moment ce rezistă până la 170 kg/cm2. Dar faptul că TF2+ este certificată pentru operarea la 75oC recomandă și un adeziv pe măsură care are specificat ca maxim 80oC.

Atașez și restul de imagini cu rezultatul final.

Adeziv
Rezultatul final
Rezultatul final cu filtrul montat
Montaj final 1
Montaj final 2
Montaj final 3

PS: am observat faptul că reglajul cel mai bun privind filtrarea reflexiior este acolo unde săgeata de pe inel și triunghiul de pe filtru se întâlnesc. Se observă în ultima imagine.

Blogger-ul român și cookie stuffing-ul

Zău, nu știu ce se petrece cu această gloată de derbedei. Au făcut ei pe undeva vreun team building și au decis în unanimitate că e OK să-mi împută mie sesiunea de browsing cu cookie-uri de afilere fără ca eu să-mi dau acordul?

La primul caz am lăsat un comentariu acid și am mers mai departe. După care am văzut că sunt alții care insistă. Luăm ca studiu de caz eMAG Profitshare. Nu intru în detalii. Doar citez punctul 4 din ToS:

4. Instrumente de promovare

Afiliatul va folosi instrumentele de promovare oferite de sistemul de afiliere eMAG ProfitShare, pe site-urile care indeplinesc conditiile programului, pastrand intact codul HTML oferit.

Chestie ce mie mi se pare suficient de clară, dacă nu ești lobotomizat. Ceea ce ne duce la faptul că URL-urile injectate prin blog post-uri care conțin redirect-uri 301 (pentru a ascunde referer-ul) la un URL de Profitshare nu intră în categoria “cod HTML intact”. De altfel, “fraierii” care dau click pe link-uri nici nu au habar că la următoatea comandă o parte din sumă merge în buzunarul unuia ce nu are bunul simț să respecte regulile unui joc.

Acum știu că ăștia care nu gândesc nici măcar cu jumătate de “creer” ar avea o problemă cu cele spuse mai sus, gen: “păi dacă e băieți deștepți și se descurcă, de ce te fute pe tine grija?”. De mere. E o chestie de principiu pe care puțini o pricep, dar ca idee, România nu e de căcat. Voi ăștia care găsiți scurtături la orice chestie o faceți de căcat. Nu sunteți soluția, ci parte a problemei. Și asta în detrimentul unora care încearcă să facă în mod cinstit un ban din asta.

Nu fac bani din asta, deci nu mă apuc să fac pe poliția blog-urilor și nici nu e datoria mea să raportez imediat orice astfel de fraudă, dar nu există garanții că nu o voi face pe viitor dacă observ că unii sar calul. Din moment ce unora le merge, bănuiesc faptul că sistemul celor de la Profitshare este suficient de inapt astfel încât să nu detecteze fraudele, deși ar fi trivial să găsești spărtura și să ridici un semn de întrebare pentru cei ce setează un cookie fără referal, dar ajunge pe emag.ro de pe profitshare.emag.ro cu referal.

Chiar mi-am făcut prostul obicei de a da un curl -I pe orice chestie ce mi se pare suspectă. Și de a-mi curăța cookie-urile înainte de a mă pune pe cumpărat, doar de dragul de a le face zile negre unora ce nu sunt în stare să citească un ToS.

O dovadă (anonimizată) despre acest fapt:

Screen Shot 2013-03-14 at 3.17.15 PM

Romanian Programmers pentru OS X (modificat)

Precum se poate observa cu ochiul liber, prefer scrierea cu diacritice. Chiar dacă le consider un moft din partea limbii române, și la o adică, ne-am fi putut descurca și fără ele dacă istoria s-ar fi scris altfel. Dar astea sunt standardele …

Folosirea Romanian Programmers este un obicei ce s-a împământenit de pe vremea lui Windows XP. După care a devenit layout standard în Windows Vista, 7, și un număr de distribuții de Linux pe care nu-l pot determina. Având în vedere că de prin 2007, Ubuntu a fost sistemul meu de operare de bază, iar sub Ubuntu Romanian Programmers este standard pentru limba română, folosirea layout-ului a continuat până în prezent.

Ei bine dragii moșului, recent m-am mutat înapoi pe OS X. Dar după ani de obișnuință, este greu să treci la scriere fără diacritice, sau pe tastatura “nativă” română care are o ciorbă de taste. Prima opțiune a fost să folosesc key mapping-ul de aici. Încă este puțin irintant faptul că acel command din dreapta e în loc de alt, iar din obișnuință mai dau command + q pe când încerc să scriu “â” și dispare aplicația. Din păcate, alt și command nu se pot inversa.

După care a urmat o perioadă de enervare cu decizia cretină a Apple de a pune o tastă complet inutilă în loc de backtick / tilda. Iar tasta respectivă și-a găsit locul între shift și z, loc complet ignorat de mine până în prezent, pentru că nu e nimic acolo.

Deci am pus mâna pe Ukelele și mi-am rezolvat problema. Am inversat mapping-ul la cele două, deci în sfârșit am backtick / tilda acolo unde le aștept să fie, mai ales pe când scriu în terminal. Din păcate, înlocuirea unui layout nu este atât de simplă pe cât mă așteptam. Soluția am găsit-o aici.

sudo rm /System/Library/Caches/com.apple.IntlDataCache*
sudo find /var/ -name "*IntlDataCache*" -exec rm {} \;

N-a fost nevoie de reboot. Doar de un logout + login.

Versiunea modificată pentru cei prea obișnuiți cu tasta respectivă în poziția corectă este pe GitHub.

EOF

Kernel upgrade sub Amazon EC2 / Ubuntu

Nu o să descriu o metodă generală de kernel upgrade pentru că nu cunosc una ce să meargă pe restul distribuțiilor. Canonical este un susținător activ al virtualizării, iar în cazul Amazon EC2 au pus umărul și oferă suport oficial pentru Ubuntu. Deci o să mă limitez la Ubuntu Server 10.04 LTS.

Dacă ar fi să mă iau după trendul celor de la RightScale de a merge “doar înainte în cloud”, atunci ar trebui să complic problema mai mult decât trebuie să se complice. Din nefericire nu toate aplicațiile au fost create ca să se muleze acestui model: “creez instanțe noi, pe cele vechi le arunc la gunoi”. Iar faptul că au dezactivat butonul de stop instance nu înseamnă că oricine trebuie să se muleze acestui model.

Tipul de management de mai sus presupune:

- apt-get update && apt-get dist-upgrade pentru a avea noul kernel pe disk
- snapshot la EBS (dacă există)
- creat AMI nou cu kernel ID nou
- adăugat instanță nouă in spate la load balancer
- oprit instanță veche

Tipul de management în viziunea subsemnatului:

- apt-get update && apt-get dist-upgrade pentru a avea noul kernel pe disk
- oprire instanță EBS backed
- schimbat atributul kernel (ec2-modify-instance-attribute –kernel $kernel_id $instance_id)
- pornire instanță

TADA!

Load balancerul și aplicația nu o să tușească la acest model. Pe cuvântul meu de cercetaș. Și se poate automatiza la fel de bine ca și modelul pe care-l propun alții.

Bila neagră către Amazon este faptul că nu o să câștige vreodată vreun concurs de uzabilitate. Modul în care și-au gândit anumite chestii sună mai mult a box împotriva unui API și mai puțin simpla utilizare a lui. Din fericire, cum ziceam mai sus, Canonical oferă suport oficial. Deci gasirea acelui $kernel_id magic nu este tocmai căutare în acul cu fân, dacă rogi frumos EC2 API Tools:

Update: Canonical se dovedesc a fi parte a conceptului “world-class pain-in-the-ass”. Noile imagini de kernel, se găsesc folosind:

ec2-describe-images -o 099720109477 --filter name=ubuntu-images/ubuntu-lucid-\*

Ce am zis mai jos rămâne valabil până la kernel 2.6.32.312-ec2. Mai nou, imaginile sunt în /ubuntu-images/.

# pentru mașini 64-bit
ec2-describe-images -o 099720109477 --filter name=ubuntu-kernels/ubuntu-lucid-amd64\*
# sau, pentru mașini 32-bit
ec2-describe-images -o 099720109477 --filter name=ubuntu-kernels/ubuntu-lucid-i386\*

Notabil este faptul că în /ubuntu-kernels/ se găsesc versiunile considerate stabile. Mai există și chestii ceva “bleeding edge”, dar vorbim de mediu de producție, nu de joaca de-a virtualizarea.

Update: la 2.6.32.316 (1 Iunie 2011) au revenit la schema de publicare explicată inițial. Doar 2.6.32.314 nu apare în listă, fiind nevoie să fie pescuit de prin lista de imagini oficiale.

MySQL Backup peste SSH

Update (1 Martie 2011):

  • Suport pentru a specifica un MySQL host. E musai să fie definit minim cu “localhost” pentru o conexiune locală. Va folosi UNIX socket. Pentru TCP socket, se folosește 127.0.0.1 ca adresă.
  • Suport pentru compresie la nivel de protocol SSH. Mă gândeam la asta, dar am activat-o doar pentru MySQL – chestie destul de inutilă pentru o conexiune locală prin UNIX socket. Acum, cu suport pentru host extern, își are rostul.
  • Schimbat criptarea în blowfish-cbc ce este semnificativ mai rapidă pentru SSH.

Backup-ul – un rău necesar. Existența unui server cu skip-networking complică problema. Dar nu o face imposibilă. SSH știe să returneze chestii peste STDOUT. Iar un script pus în cron face ca această pacoste să intre în categoria “set it and forget it”.

Iar dacă tot am vorbit de un script, acesta este:

#!/bin/bash
 
# EDIT
MY_USER=""
MY_PASS=""
MY_HOST="localhost"
SSH_USER=""
SSH_HOST=""
SSH_PORT=""
# END EDIT
 
CDIR=$(dirname $0)
PKEY=$CDIR/private-key.pem
DUMP=$CDIR/dump
DATE=$(date +%F+%H-%M-%S)
 
if [ ! -f $PKEY ]
then
        echo "Error: The SSH private key file is missing!"
        exit 1
fi
 
if [ ! -d $DUMP ]
then
        mkdir $DUMP
fi
 
echo "Fetching the databases ..."
database=($(ssh -C -c blowfish-cbc -i $PKEY -p $SSH_PORT $SSH_USER@$SSH_HOST mysql -C -h$MY_HOST -u$MY_USER -p$MY_PASS -e '"SHOW DATABASES;"'))
count=${#database[@]}
for ((i=1; i<count ; i++))
do
        if [ "${database[$i]}" != "mysql" -a "${database[$i]}" != "information_schema"  ]
        then
                echo "Dumping ${database[$i]} ..."
                ssh -C -c blowfish-cbc -i $PKEY -p $SSH_PORT $SSH_USER@$SSH_HOST mysqldump -v -C -h$MY_HOST -u$MY_USER -p$MY_PASS -x -B ${database[$i]} | nice -n 19 pbzip2 -c > $DUMP/${database[$i]}-$DATE.sql.bz2
        fi
done
 
</count>

Are 5 opțiuni de configurare, destul de evidente. Caută private-key.pem în directorul în care se află – unde private-key.pem este cheia ce face posibilă comunicarea peste SSH fără a folosi autentificare cu parolă. Iar din moment ce se folosește rețeaua, atât mysql cât și mysqldump folosesc protocol compression (flag-ul -C). Dependințele sunt evidente la o primă citire. Nu este cel mai eficient mod de a face backup (rețea, spațiu), dar este simplu de implementat iar câteodată aceasta contează. Ignoră bazele de date mysql și information_schema. A se ignora ultimul tag a-la HTML din blocul de cod de mai sus. GeSHi face fițe.