[PHP Class] Expand short url
26 Mai, 2011 | Categorie: Freebies, PHP | Tag-uri: gratuit, PHP, sandbox
L
ink-urile scurte sunt bune atunci când ai nevoie să economiseşti spaţiu, dar nu prea sunt bune când habar nu ai unde o să ajungi după ce dai click pe un asemea link.
Metode de a afla link-ul original dintr-un link scurt sunt numeroase. Poate cel mai simplu dintre toate constă în urmărirea conţinutului din header.
Mod de utilizare
<?php
include('expandlink.class.php');
$link = new ExpandLink();
echo 'http://t.co/jad0dDv = '.$link->expand('http://t.co/jad0dDv').' ';
echo 'http://bit.ly/iI5EGB = '.$link->expand('http://bit.ly/iI5EGB').' ';
echo 'http://j.mp/iAq8PE = '.$link->expand('http://j.mp/iAq8PE').' ';
echo 'http://goo.gl/w666r = '.$link->expand('http://goo.gl/w666r').' ';
Download: expandlink.class.php
Link-urile din exemplu sunt luate la întâmplare de pe Twitter.
TrackBack URL Permalink RSS Comentează Tweet
Expand short URL the easy way: http://j.mp/m43EXo
This comment was originally posted on Twitter
Ar fi vreo câteva comentarii legate de cod. Evident, umbra de coder din mine nu poate să tacă din gură.
- nu prea ai nevoie de clasă ce poate fi instanțiată. Înafară de a verifica existența extensiei cURL, instanța obiectului îsi pierde din sens. O clasă statică (stateless) are mai mult sens. Oricum, verificarea existenței componentelor de runtime la fiecare rulare a codului nu este o idee strălucită. Există metode mai bune pentru a pune grămadă o aplicație. Proprietatea $output deasemenea își pierde din sens.
- folosirea operatorului silent (@) duce la un timp mărit de execuție per fiecare apel de funcție ce îl folosește. Toată bucata de cod ar putea fi introdusă între două apeluri de error_reporting() ce să coboare, respectiv să ridice nivelul de error reporting la valoarea inițială. Cred că singura variantă plauzibilă de utilizare este în situația în care folosești un runtime ce nu permite să umblu la error reporting level. Oricum, aș merge mai degrabă pe validare de input folosind filter_var() și verificarea valorilor returnate de catre curl_* în loc să folosec operatorul silent.
- ești sigur că toate acele situații sunt Exception()-ale? Văd de multe ori cod complicat cu excepții pe când un simplu return FALSE; în caz de eroare este mai mult decât suficient. Mecanismul de tratare a excepțiilor este măsurabil mai lent decât simple convenții, în orice limbaj de programare. Personal le văd rolul pentru a nu avea control flow cretin la o chestie complexă ce poate să crape din multe motive. În rest, programatorii tratează prea des simple erori ca situații “excepționale”.
- folosești două expresii regulate pentru o chestie pe care o ai disponibilă în cURL (vezi mai jos).
- urmărești doar primul redirect. Ceea ce peste HTTP nu este musai să fie adevărat. Poți să ai oricâte redirect-uri până la un URL final (vezi mai jos).
- HEAD este mai eficient decât GET. HTTP parser-ul nu trebuie să se ocupe de un eventual response body (vezi mai jos).
Pun un mock-up în legătură cu ce ziceam mai sus prin paranteze. Timeout-urile sunt barbar de mari, dar de regulă folosesc cURL în CLI, nu pe server side din motive de blocking I/O și toate implicațiile pe care le poate avea asupra unei aplicații.
$ch = curl_init(‘http://goo.gl/w666r’);
curl_setopt_array($ch, array(
CURLOPT_NOBODY => 1, // Use HEAD instead of GET
CURLOPT_FOLLOWLOCATION => 1, // Go further
CURLOPT_MAXREDIRS => 30, // Limit it though
CURLOPT_CONNECTTIMEOUT => 30,
CURLOPT_TIMEOUT => 120,
));
curl_exec($ch);
if (curl_errno($ch) === 0)
{
$url = curl_getinfo($ch, CURLINFO_EFFECTIVE_URL);
}
else
{
// do something about the error
}
curl_close($ch);
// return $url
var_dump($url);
Cei 2 cenți ai mei …
@SaltwaterC
Cred ca ti`a luat mai mult sa scrii tot acest reply decat mi`a luat mie sa scriu clasa folosita drept exemplu in acest articol. Pt asta iti multumesc si hai cu raspunsul:
Codul este doar de exemplu pt cei cativa pusti care m`au stresat la cap in ultima perioada cu problema asta. Return boolean si exceptiile sunt lasate pt a se da o idee despre ce se poate extinde si unde.
nu prea ai nevoie de clasă ce poate fi instanțiată
Codul este sub forma de clasa pt ca am alergie la cod procedural.
Servicile de gen folosesc doar un redirect . Daca din al 2-lea url se mai face un redirect, este alta mancare de peste. Eu vreau doar sa imi fac o idee pe unde ajunge un URL ascuns, nu sa urmaresc un carnat de mai multe redirecturi. Daca le urmaresti pe toate te complici singur, pt ca trebuie sa verifici si daca nu cumva te baga intr`un redirect loop.
Da, folosirea semnului @ pt a ascunde avertismentele si erorile mareste timpul de executie cu ~.005 per iteratie. Programezi drivere ca sa iti faci astfel de probleme ? Dupa ce te lovesti de cativa clienti hostati pe servere fantoma, incepi sa sufli si in iaurt.
In rest numai de bine si ma bucur sa vad ca mai treci si pe la mine. Spor maxim
@SaltwaterC
Daca nu faci o instanta noua la clasa cum ai de gand sa utilizezi respectiva clasa ? Chiar si daca este singleton o instanta tot este creeata si este utilizata pana la terminarea executiei.
@stefan
El se gandea la static. Cand vrei sa aranjezi un cod simplu sub forma de clasa doar ca sa il citesti mai usor, este preferabil sa folosesti metode statice.
Eu folosesc metode statice foarte rar, pt ca imi este peste mana sa le testez si sa le extind. Dar asta este doar o problema de stil personal, de gusturi si de inspiratia de moment. De cate ori nu vi sa intamplat sa va cititi codul scris cu 1 – 2 zile in urma si sa exclamati “ce bou am fost !”.
Evident că mi-a luat mai mult. Are mai multe cuvinte
. Dar la 45-60 wpm, nu tastez tocmai lent.
Pe partea de OOP, pot să zic: am fost acolo. Adică să scriu cod mai mult ce să facă într-un mod mai complicat un lucru ce se putea face într-un mod mai simplu. Sau să scriu mai mult cod ce să facă același lucru ce putea fi scris mult mai concis (aka unde e progresul?). Cât că era pregătit pentru orice schimbare, abstracțiile peste factory pattern design erau ‘flawless’ din punct de vedere logic și puteam oricând să adaug un nou provider fără a schimba codul de deasupra. Dar toate acele situații prevăzute pentru care am pierdut mult timp pentru a face design-ul aplicației și implementarea, nu au apărut. Este doar un exemplu, dar în timp este foarte ușor a cădea pe această pantă, ceea ce în cazul subsemnatului nu a fost tocmai un lucru de lăudat având în vedere că lucram la un startup. Aici sunt multe de zis. Probabil o să scriu un articol lung pe această temă.
CURLOPT_MAXREDIRS => 30 rezolvă problema unui redirect loop. Deasemenea timpul de conectare și timpul total de execuție al cURL (ceea ce include timpul de transfer de la clienți lenți) este limitat. În ultimele luni am vorbit mai mult HTTP peste cURL sau node.js decât alte chestii. Nu-mi scapă astfel de detalii cu ușurință.
Și da, sufăr de boala benchmark-ului din constrângeri de resurse limitate sau volum consistent de req/s.
Chestia cu CURLOPT_MAXREDIRS nu o stiam. Multam de pont.
Și da, sufăr de boala benchmark-ului
Inseamna ca ai rabdare de chinez.
@SaltwaterC
vad ca acest articol are tag-ul “sandbox”, iar daca dau click pe acel tag imi apare un disclaimer care face discutia dintre tine si vim cam inutila. in plus de asta nu o sa gasesti doua persoane care sa programeze identic oricat ai incerca. fiecare are stilul lui, ideile lui fixe, daruirea lui si conceptia lui asupra modului in care sa rezolve un task.
@stefan
Tocmai pt ca fiecare developer are propriul stil si propria conceptie vis-a-vis de rezolvarea unui task duce la aparitia interminabilelor dezbateri cu tema “aici eu scriam asa, nu asa cum ai scris tu“.
Singurele diferente pe acest plan apar la developerii mai trecuti prin focurile meseriei, care au lucrat in echipe mai mari de 5 – 6 persoane si care stiu ca asta implica mult mai mult decat “a scrie cod rapid si in stilul tau“.
Timpul o sa iti arate ca exista “n” tipuri de oameni cu tot atatea caractere si cu trecerea anilor o sa inveti cum sa te comporti cu mare parte dintre ei.