Acasă
Despre
Cautare
🌐
English Română
  • PHP for Android o prima parere

    Read this post in English

    Aug 21, 2010 Android PHP PHP for Android
    Share on:

    Cand vine vorba de Android si PHP s-a scris mult pe tema PHP for Android.

    Conceputul este simplu, Google a lansat Android Scripting Environment (ASE).

    ASE este asa cum spune si numele, este un mediu de scripting, iar aplicatiile nu sunt compilate si pot fi modificate de catre utilizator in orice moment.

    Peste ASE se instaleaza extensii pentru diferite limbaje cum ar fi: Python, LUA, Perl, JavaScript sau JRuby.

    Din pacate nu exista suport oficial pentru PHP din partea Google, dar exista PHP for Android, proiect care permite integrarea PHP CLI cu acest mediu.

    Instalarea este foarte simpla si se face direct pe mobil. Pentru a dezolta se poate folosi simulatorul din Android SDK.

    Una din probleme este ca o aplicatie nu poate fi impachetata ca APK, deci nu poate fi postata pe Android Market.

    Practic asta a fost singura problema ridicata pana acum peste tot, problema care nu mi-se pare tocmai mare avand in vedere facilitatile care sunt disponibile in acest mediu.

    Am caut aplicatii facute cu PFA, am gasit foarte putine, am gasit de fapt foarte putine si in alte limbaje folosind ASE. De ce nu sunt atat de dornici utilizatorii sa dezolte? Simplu, din mediu de scripting poti accesa foarte multe facilitati de care dispune telefonul, cum ar fi functia de vibratie de exemplu si cam toate felurile de dialoguri. Este totusi un lucru estential care lipseste in totalitate (cel putin la data cand scriu acest blog), nu exista o interfata grafica, cum ar fi orice fel de fereastra care nu este un dialog.

    Deci care este scopul sa pui o aplicatie pe Android Market daca nu exista interfata grafica? Nu cred ca este aproape un motiv cu adevarat consistent in acest punct.

    Totusi, ce fac utilizatorii in acest mediu atunci? Pai… Cellbots de exemplu. Practic poti face niste jucarii interesante, dar nu te astepta sa poti face aplicatii adevarate (inca). Un alt proiect a fost trimiterea unui NexusOne in spatiu.

    Deci proiectul este interesant, dar nu cred ca are scopul de a dezvolta aplicatii traditionale inca.

  • Android for web developers

    Read this post in English

    Aug 12, 2010 Android
    Share on:

    De curand am schimbat “batranul” HTC Diamond care rula Windows Mobile 6.1 pe un HTC Desire care ruleaza Android 2.1.

    De ce Desire? In principal pentru Android. Exista 3 platforme care dupa parerea mea merita atentie: iPhone, Antroid si Windows Mobile. Mai este si Blackberry dar nu sunt mare fan.

    Pe scurt, am ales Android pentru multitudinea de moduri in care poti scrie o aplicatie.

    Limbajul naitiv pentru Android este Java, dar pentru programatorii web exista alternative cum ar fi: Titanium, Phonegap, PHP for Android sau Adobe AIR.

    Mi-am propus sa exporez aceste tehnologii alternative pentru a vedea cam ce si cat de usor se poate dezvolta cu fiecare dintre ele.

    Tot ce pot spune in acest moment este ca prima aplicatie mi-a luat aproape 2 zile sa o construiesc, dar rezultatul este interesant.

  • Cand ar trebui sa aiba loc optimizarea

    Read this post in English

    Aug 3, 2010 optimization
    Share on:

    Exista carti intregi despre optimizare, dar putina lume mentioneaza si momentul cand aceasta ar trebui sa aiba loc.

    Sunt cateva viziuni fundamental diferite:

    • in timpul dezoltarii
    • la finalul ciclului de dezvoltare
    • niciodata

    Oare care este raspunsul corect? De fapt exista doar mai putin corect sau inadecvat.

    In timpul dezoltarii

    Acest raspuns are cel mai mare potential sa fie gresit.

    Desi este cea mai aplicata metoda si nu ar trebui interpretata ca fiind gresita, aceasta are potentialul de a duce la probleme.

    Cand duce la probleme? Cand in loc de optimizare se foloseste micro-optimizare in mod excesiv.

    Micro-optimizarea poate avea diferite forme in funtie de modul de dezoltare al proiectelor. Unii prefera sa scrie cod “bulk” sau cod procedural, altii folosesc framework-uri si  ORM-uri. In momentul cand te abati de la regula generala de scriere pentru a face optimizare trebuie sa te gandesti la consecinte. Cel care vine in urma ta probabil o sa inteleaga mai greu ce se petrece acolo, iar daca din asta faci o regula in timp proiectul va deveni indescifrabil.

    De exemplu daca folosesti un ORM si incepi sa scri SQL deja piezi scopul ORM-ului. In ORM se fac cativa pasi pentru fiecare interogare:

    Constructie interogare obiectual -> Parsare in SQL -> Executie interogare -> Parsare rezultat -> Incarcare obiecte rezultate

    vs.

    Constructie interogare SQL -> Executie interogare -> Parsare rezultate

    Pasii variaza in functie de implementare.

    De multe ori pare mai simpla si este in mod sigur mai rapida varianta a doua. Dar de ce se foloseste prima varianta? Pentru avantajele arhitecturii! Se pot pune triggere la accesarea sau setarea de proprietatilor de exemplu.

    Un programator matur este cel care scrie un cod “lizibil”, nu doar optim.

    La finalul ciclului de dezvoltare

    Avantajul este ca nu se fac compromisuri arhitecturale in timpul dezvoltarii.

    Asta este in general metoda cea mai buna, pentru ca ai produsul final, dezoltat fara compromisuri si poti sa schitezi punctele care ar trebui sa fie optimizate. In momentul cand ai toate componentele este mult mai usor sa le reorganizezi decat in timpul ciclului de dezoltare cand pot aparea modificari care la randul lor pot duce la replicare de cod de exemplu.

    Dezavantajul este ca la final este uneori dificil sa depistezi punctele slabe ale aplicatiei.

    Niciodata

    In primul rand sa nu existe indoieli, ma refer la proiecte “serioase”.

    Este o regula generala care spune ca “hardware-ul este ieftin, programatorii sunt costisitori”. Mai pe larg asta inseamna ca este de multe ori mai simplu sa scalezi o aplicatie folosind hardware decat sa faci compromisuri majore in cod.

    Multe firme si proiecte sprijina perspectiva asta. Aplicata corect are avantajul ca va fi un cod organizata bine tot timpul, usor de citit cu foarte putine hack-uri.

    Avantajul este la dezvoltare, lipsa hack-urilor face un proiect mai bine organizat (teoretic) si mai usor de extins.

    Din pacate se pare ca exista o interpretare diferita: “trebuie sa mearga, nu sa fie perfect”. Unde poate duce asta? Practic este cea mai buna scuza pentru cod mizerabil.

    Diferenta majora este ca nu optimizezi, iar codul va arata cel putin la fel de rau ca atunci cand ii faci micro-optimizare.

    Concluzie

    In general proiectele care au parte de micro-optimizare excesiva, au potential sa fie rescrise destul de des, fie partial ori complet, pentru ca exista o alta regula care spune ca “decat sa repari, de multe ori este mai simplu sa rescrii”. Din pacate aceeasi soarta o au si proiectele care au cod neingrijit.

    Un dezavantajul major la calitatea codului este ca ingreuneaza productia, cu alte cuvinte lucuri minore dureaza din ce in ce mai mult pentru a fi realizate.

    Proiectele nu trebuie mereu optimizate. Dar atunci cand trebuie, copromisurile in materie de arhitectura trebuie sa fie minime.

  • Web as a platform pe Desktop folosind Adobe AIR

    Read this post in English

    Apr 21, 2010 Adobe AIR JavaScript SQLite
    Share on:

    Dupa al doilea miniproiect revin cu noile mele pareri despre Adobe AIR!

    Lucrand cu Adobe AIR am avut o revelatie, in 2004 John Battelle si Tim O’Reilly prezentau conceptul “Web as Platform”. Acum, folosind Web-ul ca o platforma putem dezolta aplicatii desktop. Practic am parasit un mediu pentru a ne intoarce la el cu o noua perspectiva.

    Daca prima data nu am avut decat 3 zile la dispozitie, acum nu am mai fost atat de constrans. In acest timp am avut timp sa mai decopar cateva din facilitati, cum ar fi NativeMenu si suportul pentru SQLite.

    Cred ca SQLite are scopul de a compensa pentru facilitati de stocare care nu sunt disponibile pe aceasta platforma cum ar fi cookie-uri. Evident pentru ca SQLite foloseste baze de date, capacitatea de stocare este mult superioara fata de mediul Web traditional.

    Dar de ce Adobe AIR fata de alte platforme, cum ar fi Java sau C#? Pentru ca e simplu! Nu cred ca Adobe AIR a fost intentionat ca o unealta pentru a construi aplicatii mari, desi probabil doar in timp se poate vedea acest lucru. Acesta este o unealta buna pentru aplicatii de dimensiuni mici si medii care pot aduce un plus fata de Web. De exemplu in aplicatia mea am facut un sistem de alterte, m-am gandit ce mi-ar place mie vis-a-vis de ce am deja pe Web. Cu acest sistem de alterte eu nu mai sunt nevoit sa intru si sa verific tot timpul ce se intampla. La fel de bine cred ca se pot implementa chat-uri sau instrumente similare, pana la urma daca se poate pe Web, se poate si aici.

    Ce are Adobe AIR este un sistem foarte interesant de distributie, practiv platforma este distribuita impreuna cu Adobe Acrobat Reader, lucru care o face disponibila chiar si pe calculatorul tau fara chiar sa sti.

    Ce nu are Adobe AIR si cred ca ar fi fost util este un sistem de a accesa obiecte COM de exemplu, facilitati de a accesa si alte sisteme de baze de date in afara de SQLite, care oricum este un sistem foarte simplu.

    Un alt lucru care mi-ar place ar fi capacitatea de a folosi facilitati specifice Adobe Flash din JavaScript. Stiu, ar trebui sa le fac in Flash daca tin de Flash dar eu prefer JavaScript ca platforma. Probabil aceste lucruri nu sunt disponibile in JavaScript pentru ca acest limbaj are facilitatiile aduse de HTML 5, cum ar fi: Canvas si Audio, care compenseaza oarecum cu elementele de Flash care nu sunt disponibile implicit in JavaScript.

    Adobe AIR 2 care este momentan in beta, probabil va mai rezolva din novoia de acces pentru resurse de sistem.

    Parerea mea este ca Adobe AIR este platforma pe care un Web developer poate dezolta aplicatii desktop cu usurinta!

  • CodeIgniter 1.7 Packt Publishing – Book review partea 2

    Read this post in English

    Mar 22, 2010 CodeIgniter PHP4 php5
    Share on:

    CodeIgniter este un framework open-source scris in PHP care se bazeaza pe principiul RAD.
    Cartea CodeIgniter 1.7 de la PacktPublishing, scrisa de Jose Argudo Blanco si David Upton urmareste formarea unei imagini de ansamblu asupra framework-ului CodeIgniter, venind in completarea manualului.

    Cartea nu este o referinta, iar acest lucru este evident in fiecare capitol cand se foloseste una dintre facilitatiile framework-ului, cititorul este mai apoi directionat catre pagina din user guide sau wiki care corespunde modulului respectiv. Ba chiar mai mult exista si sugestii catre module alternative care realizeaza aceeasi sarcina.

    Autorii sustin ca pentru a citi aceasta carte sunt necesare doar cunostinte minime de PHP, o promisiune destul de greu de respectat dupa parerea mea, in general cartile care au ca target cititorii incepatori-medii sustin acest lucru. Spre surprinderea mea au avut dreptate, cititorul are nevoie doar de cunostinte de PHP4. Iar cand vine vorba de OOP nici macar nu sunt necesare cunostinte de PHP5 ci pur si simplu modelul obiectual din PHP4. In carte exista chiar si explicatie pentru copierea prin referinta! Evident copierea prin referinta nu mai este relevanta in PHP5, dar avand in vedere ca este un framework de PHP4 probabil ca trebuia mentionata. Se pare ca inca mai exista servere de PHP4 pe internet… pur si simplu trist…

    Citind cartea au inceput sa-mi vina flashback-uri cu bucati de cod scrise direct in PHP si chinul de a face debugging pe ele, incercand sa inteleg munca altora… ce vremuri… groaznice desigur. Explicatia mi se pare foarte buna pentru a intelege concenptul de refolosire din spatele unui framework: “Possibly you like typing regex. Some people like lying on a bed of nails…”. Cred ca pentru un programator, in special incepator, sa citesti asa ceva te face sa realizezi ca nu trebuie sa reinventezi roata de fiecare data ci pur si simplu sa folosesti solutii gasite de altii.

    Comparatia intre solutii, cred ca este cea mai amuzanta parte dintr-o carte de acest gen. Este greu sa compari de exemplu Zend Framework sau chiar CakePHP cu CodeIgniter. Pana la urma fiecare din framework-uri spun acelasi lucru, descarci si incepi sa lucrezi. Eu personal cand vreau sa folosesc un modul din Zend pur si simplu incarc autoloader-ul si trec la treaba. Din comparatie rezulta cum era de asteptat ca CodeIgniter este cea mai potrivita in general, motivatia sa spunem ca este relativ buna si destul de cinstita. Pana la urma este un framework mic si nu are facilitati complexe cum ar fi generare automata de CRUD. Imi amintesc de o carte de Java unde autorul prezenta faptul ca C++ este mai rapid decat Java ca pe un dezavantaj, evident este ridicol.

    Am avut de cateva ori impresia ca exprimarea este gresita. Autorul se foloseste de “mici” greseli in termeni pentru a explica ce se intampla de fapt in spate. Cand lucrezi cu framework-uri MVC unele lucruri sunt simple si evidente, dar pentru un programator care nu este familiar cu notiunile sunt destul de greu de inteles.

    Iar ca sa continui cu greselile, am gasit cateva in carte. Un moment destul de dificil cand inveti ceva nou. Din fericire sunt destul de evidente pentru ca se concretizeaza in erori, iar daca citesti cartea capitol dupa capitol vei sti ce ai de facut ca sa le repari.

    Exemplele mi se par destul de consistente si bine explicata. Cand se introduce o notiune noua aceasta este explicata destul de in detaliu.

    Aplicatiile rezultate nu sunt foarte complexe, de exemplu la final nu rezulta o aplicatie complexa cum ar fi cu CMS, mai degraba sunt explicate module si modul de folosire impreuna a acestora. Cititorul la final va trebui sa decida ce si cum va arata aplicatia lui. De exemplu in capitolul 13 se explica paginarea si ordonarea. Cand se face paginarea totul e ok, dar cand se face si ordonarea paginarea incepe sa dea rateuri. Mi-a luat cam 5-10 minute sa remediez problema, dar ar fi fost frumos ca aceasta problema sa fie rezolvata de catre autori.

    In ansamblu mi se pare o carte reusita, in special daca nu ai cunostiinte de CodeIgniter, este asa cum o prezinta si autorii, o carte pentru dezvoltatori care vor mai multa productivitate in munca lor sau pur si simplu sunt la inceput si vor sa vada ce unelte exista. Cartea totusi nu prezinta solutii mai complexe cum ar fi un CMS sau un shopping cart ci pur si simplu ce are acest framework de oferit.

    Un programator avansat poate intelege din aceasta carte structura framework-ului CodeIgniter, eventual pentru a o compara cu alte framework-uri concutente, fara sa piarda vremea cu exemple complexe si irelevante.

    • ««
    • «
    • 5
    • 6
    • 7
    • 8
    • 9
    • »
    • »»

Claudiu Perșoiu

Programare, tehnologie și altele
Mai multe

Postări recente

  • 30 de ani de PHP
  • Slider in Tasmota folosind BerryScript
  • Proiectul care rezista probei timpului
  • Docker in interiorul wsl2
  • Migrând de la Wordpress
  • Calea personalizată pentru Composer cache
  • Magento2 si crudul adevar
  • Un pic de PHP, Go, FFI si atmosfera de sarbatori

DIVERSE 72 PHP 68 JAVASCRIPT 22 BROWSERS 12 MYSQL 12 WEB STUFF 12 MAGENTO 7 DESIGN PATTERNS 5 HARDWARE 3 HOME AUTOMATION 2 LINUX-UNIX 2 GO 1 MISCELLANEOUS 1

PHP 53 JAVASCRIPT 20 PHP5.3 14 MYSQL 13 PHP6 12 PHP5 10 FIREFOX 9 CERTIFICARE 8 INTERNET EXPLORER 8 ZCE 8 ZEND 8 CERTIFICATION 7 MAGENTO 7 HACK 6
Toate etichetele
10 ANI1 3D1 ADOBE AIR2 AJAX1 ANDROID3 ANGULAR1 ANONYMOUS FUNCTIONS3 API1 APP1 BERRYSCRIPT1 BETA1 BOOK1 BROWSER4 C2 CALCULATOARE1 CARTE2 CERTIFICARE8 CERTIFICATION7 CERTIFIED2 CERTIFIED DEVELOPER1 CHALLENGE1 CHM1 CHROME1 CLASS1 CLI2 CLOSURES5 COD1 CODE QUALITY1 CODEIGNITER3 COFFEESCRIPT1 COLLECTIONS1 COMPOSER1 CSS3 CSV1 CURL1 DEBUG1 DESIGN PATTERNS4 DEVELOPER1 DEVELOPMENT TIME1 DIAGRAME1 DOCKER2 DOCKER-COMPOSE1 DOUGLAS CROCKFORD3 DRIVERE2 ELEPHPANT2 ENGINEER1 EXAMEN1 EXCEL1 FACEBOOK2 FEEDBACK1 FFI1 FINALLY1 FIREFOX9 FISIERE1 FPDF1 FRUMOS1 FTP1 GAMES1 GD2 GENERATOR1 GO1 GOOGLE5 GOOGLE ANALYTICS1 GOOGLE CHROME3 GOOGLE MAPS2 HACK6 HARDWARE1 HC-911 HEADER1 HEIGHT1 HOMEASSISTANT2 HTML2 HTML HELP WORKSHOP1 HTML51 HUG1 HUGO1 IDE1 IMAGINE1 INFORMATION_SCHEMA1 INI1 INTERNET4 INTERNET EXPLORER8 IPV41 IPV61 ISP1 ITERATOR2 JAVA1 JAVASCRIPT20 JQUERY1 LAMBDA2 LAPTOP2 LINUX1 LIVELY1 LUNI1 MAGENTO7 MAGENTO22 MAP1 MAPS1 MICROSOFT1 MINESWEEPER1 MOTIVATION1 MSN MAPS1 MYSQL13 MYSQL WORKBENCH1 NGINX1 NODE.JS2 NOFALLOW1 NOSQL1 OBSERVER3 OBSERVER PATTERN1 OOP1 OPERA1 OPTIMIZATION1 ORACLE2 PAGESPEED1 PAIR1 PARSE_INI_FILE1 PASCAL1 PEAR1 PECL1 PERSON VUE2 PHAR1 PHONEGAP2 PHP53 PHP ELEPHANT2 PHP FOR ANDROID1 PHP-GTK1 PHP42 PHP510 PHP5.314 PHP5.46 PHP5.53 PHP5.61 PHP612 PHP7.41 POO1 PR1 PROGRAMMING1 PROIECTE1 RETEA1 REVIEW1 ROCK STAR1 ROMANIAN STEMMER2 RSS1 SAFARY1 SCALAR TYPE HINTING1 SCHEME1 SEO1 SET1 SHOPPING CART PRICE RULE1 SIMPLEXML1 SINGLETON1 SOAP2 SPL2 SQLITE1 SSH1 STACK TRACE1 STDERR1 STDIN1 STDOUT1 STOCATE1 STUDY GUIDE1 SUN2 SYMFONY2 TABLE1 TASMOTA1 TEST TO SPEECH1 TITANIUM2 TRAITS1 TTS1 UBUNTU1 UNICODE3 UTF-82 VECTOR1 VISTA2 WEB2 WEBKIT1 WINBINDER1 WINDOWS2 WORDPRESS1 WSL21 WYSIWYG1 XP3 YAHOO3 YAHOO MAPS2 YAHOO OPEN HACK1 YSLOW1 YUI1 ZCE8 ZCE5.31 ZEND8 ZEND FRAMEWORK4
[A~Z][0~9]

Copyright © 2008 - 2025 CLAUDIU PERȘOIU'S BLOG. Toate drepturile rezervate