• Tag Archives php
  • Any nou IDE nou

    Avui acaba el mes de gener, durant el qual he estat provant el nou IDE PhpStorm per desenvolupar principalment en PHP. Recentment van publicar la versió 7 i és la que he estat provant. Ofereixen un mes de proves gratuït perquè puguem descobrir totes les seves funcionalitats, abans de pagar els 89€ que costa la llicència personal.

    M’havien parlat molt bé del programa, i no ha estat una sorpresa veure que realment funciona molt bé. Jo ja estava força content de l’Eclipse, amb el qual porto treballant uns vuit anys, tot i que certament era molt pesat (lent), a vegades es penjava o petava (crash) i de tant en tant calia esborrar les dades d’usuari perquè s’havien corromput i tornar a configurar-ho tot. Això era el més problemàtic i feixuc de fet, i en el meu cas succeïa una o dues vegades cada mig any. Ben mirat, és inadmissible; la pròpia aplicació hauria de protegir-se i d’alguna manera assegurar que no es perdi mai la configuració. Jo sóc un defensor actiu del programari lliure, i em sap greu dir-ho però de moment el canvi a PhpStorm val molt la pena. I per il·lustrar-ho una imatge val més que mil paraules:Phpstorm over Eclipse

    Perquè la transició sigui més còmode, té una opció per usar les mateixes dreceres de teclat que l’Eclipse. Jo en faig servir moltes, moltíssimes, i ha estat una sorpresa que el PhpStorm te’n faci descobrir de noves amb els consells que apareixen cada vegada que obres l’aplicació. A més a més són fàcilment configurables, i es poden cercar pel nom de l’acció o fins i tot fent la drecera! Té moltes funcionalitats semblants a l’Eclipse però sobretot es diferencia en la velocitat, es nota que va molt fluid en tot moment, i amb què porta de sèrie moltes eines lligades de la mà amb el desenvolupament de PHP, com detecció automàtica del repositori Git, edició de fitxers html, css, javascript, bash, yaml, etc., cerca ràpida per símbols (funcions, classes, mètodes…), comentaris en línia per identificar tipus de variables, i moltes coses més.

    Crec que serem companys de feina durant força temps 🙂

    GD Star Rating
    loading...

  • Barres de desplaçament a l’Eclipse amb Kubuntu 11.10

    A la versió Kubuntu 11.10, les barres de desplaçament (scrollbars) de l’Eclipse no funcionen correctament.

    Per aconseguir que funcionin les noves barres a KDE, cal editar el fitxer /usr/bin/eclipse i comentar la línia:

    #export GDK_NATIVE_WINDOWS=true

    Si a més a més volem que les barres tinguin el funcionament i aspecte de les tradicionals barres de desplaçament (old style), hem d’afegir:
    export LIBOVERLAY_SCROLLBAR=0

    Sort!

    GD Star Rating
    loading...

  • Variables no inicialitzades “unitialized” depurant PHP amb Eclipse i xdebug

    Mentre depurava codi en una nova instal·lació d’Apache+PHP+xdebug m’he trobat amb el problema de no veure els valors de les variables a la vista “Variables” de l’Eclipse. Pràcticament totes apareixien com “unitialized” o no inicialitzades, però en canvi imprimint-les per pantalla sí que tenien valors.  Cercant una mica he trobat aquest bug de xdebug: http://bugs.xdebug.org/view.php?id=467.

    Se m’ha acudit que si mai abans he tingut problemes depurant qualsevol versió de PHP, potser l’error estigués relacionat amb què aquí tinc la 5.3.2. Per resoldre el problema podia instal·lar una versió superior de xdebug on sé que el problema ja està resolt, com a la 2.1, però com realment no necessitava aquesta versió de PHP, podia provar amb la 5.2. Així que he seguit el post de com usar paquets d’una versió anterior d’Ubuntu i he fet un downgrade de la versió de PHP+xdebug, a la 5.2.10 i 2.0.4 respectivament.

    Després de reiniciar l’Apache la depuració torna a funcionar bé!

    GD Star Rating
    loading...

  • Instal·lació de xdebug per PHP i Apache2 a Ubuntu

    Un dels principals defectes de la majoria de programadors de PHP és oblidar-se de les eines de depuració (debugger). Tots hem estat en feines on no disposaven d’aquestes eines a la nostra màquina, o no permetien la seva instal·lació, o senzillament no hem pensat en posar-les.

    Jo vaig començar el meu primer contacte amb la programació amb el llenguatge c. Llavors a la universitat ens feien usar el programa Microsoft Visual Studio, amb el qual podíem compilar i depurar (debug). La depuració ens permetia seguir el programa pas a pas i saber el valor de cada variable en cada moment, i corregir així errors existents que s’escapaven a simple vista i que no eren de sintaxi.

    En passar a PHP, penso que és més difícil entendre com funciona la depuració, pel fet de tenir el navegador per un costat i l’entorn integrat de desenvolupament (o IDE de l’acrònim en anglès) per un altre. Tanmateix, cal instal·lar prèviament alguna cosa al servidor per poder-li indicar des del nostre IDE l’ordre d’aturar-se a la línia de codi que nosaltres vulguem. Per aquest conjunt de factors la majoria de programadors prescindeixen del depurador com a tal i utilitzen el mètode de prova i error, i miren el valor de les variables enviant el seu valor directament al navegador. Les tres funcions de PHP més utilitzades per fer això són: echo, print_r i var_dump.

    Jo he passat força temps utilitzant-les també, però quan tornes a la depuració t’adones que abans estaves perdent el temps. Amb aquest rudimentari mètode, si no coneixes molt bé el codi, primer has de trobar el punt on està la variable que vols observar, teclejar el codi que mostri el seu valor i executar la consulta de la pàgina des del navegador. Molt bé, ja has vist el seu contingut, però com ha estat calculat? Com s’ha arribat fins aquí, a través de quins fitxers, mètodes o funcions? La majoria de vegades has de tornar a escriure més codi per mostrar altres variables, perquè l’anterior no t’ha servit de massa, i tornar a actualitzar el navegador. A més a més, després cal eliminar tot aquest codi extra que has creat només per mirar el valor d’algunes de les variables. I quantes vegades passa -a mi també- que acaba pujant a producció codi amb aquestes sentències de “depuració”?

    Per evitar tot això, el millor és usar un depurador de veritat. Encara que al principi perdem una mica de temps per configurar-lo i aprendre com funciona, després ens estalviarà molt temps i mal de caps. Jo per desenvolupar en PHP i MySQL utilitzo el servidor web Apache2 sobre Ubuntu; una solució LAMP vaja. I com a IDE l’Eclipse amb el PDT (PHP Development Tools) i alguns altres plugins.

    Amb els següents passos podreu instal·lar xdebug amb l’Apache2 i PHP:

    sudo apt-get install php5-xdebug

    Això ha instal·lat el paquet corresponent i ha creat el fitxer /etc/php5/conf.d/xdebug.ini amb aquest contingut:

    zend_extension=/usr/lib/php5/20090626+lfs/xdebug.so

    Si ara comprovem el resultat de cridar a phpinfo(), veurem:

    This program makes use of the Zend Scripting Language Engine:
    Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies
        with Xdebug v2.0.5, Copyright (c) 2002-2008, by Derick Rethans

    Al mateix fitxer xdebug.ini hem d’afegir aquestes línies:

    xdebug.remote_enable=on
    xdebug.remote_handler=dbgp
    xdebug.remote_mode=req
    xdebug.remote_host=localhost
    xdebug.remote_port=9000
    

    I ja per acabar, carreguem els canvis de configuració a l’Apache:

    sudo /etc/init.d/apache2 reload

    En un altre capítol escriuré com configurar l’Eclipse per depurar des d’allà.

    Gràcies Derick pel fantàstic xdebug!

    GD Star Rating
    loading...

  • Com usar paquets d’una versió anterior d’Ubuntu

    En actualitzar (ahir) a Ubuntu 10.04 LTS Lucid Lynx, he passat de la versió de PHP 5.2.10.dfsg.1-2ubuntu6 a la 5.3.2-1ubuntu4. Si volem tornar a tenir la versió 5.2, hem de configurar l’APT per tal que usi aquells paquets que vulguem de les fonts de Karmic Koala. Així:

    Primer llistarem els paquets de php que tenim instal·lats:

    dpkg -l | egrep php

    En el meu cas són:

    • php5-common
    • libapache2-mod-php5
    • php-pear
    • php5-cli
    • php5-curl
    • php5-dev
    • php5-mysql
    • php5-memcache
    • php5-suhosin

    Dupliquem el fitxer amb les fonts de programari canviant la paraula lucid per karmic:

    sed s/lucid/karmic/g /etc/apt/sources.list | sudo tee /etc/apt/sources.list.d/karmic.list

    Creem un nou fitxer de preferències que anomenem per exemple “php”:

    sudo nano /etc/apt/preferences.d/php

    I copiem aquestes tres línies per cada paquet dels llistats anteriorment, tot canviant el nom del paquet:

    Package: php5-common
    Pin: release a=karmic
    Pin-Priority: 991
    ...
    

    Un cop ho hem configurat tot, actualitzem els paquets:

    sudo apt-get update
    sudo apt-get upgrade
    sudo apt-get dist-upgrade
    

    No ens oblidem de reiniciar el servidor web; per l’Apache:

    sudo apache2ctl restart
    GD Star Rating
    loading...

  • Actualitzar automàticament la revisió/data/autor en fer commit a subversion

    Si recentment escrivia l’entrada sobre la comanda find amb la possibilitat de fer diferents cerques simultànies, avui explico un cas on ho he usat.

    Alguna vegada haureu vist en fitxers amb codi font (siguin del llenguatge de programació que siguin), que a la part superior apareix informació sobre què conté el fitxer, la seva llicència, o l’autor, la data i el número de revisió dels darrers canvis que ha patit el fitxer en qüestió. En referència a aquestes tres darreres em refereixo a una línia d’aquest estil:

    $Id: codi.php 148 2006-07-28 21:30:43Z jaume $

    Evidentment aquestes dades no són escrites a mà per l’autor cada vegada que fa un canvi al fitxer (una nova revisió), sinó que es realitza automàticament; i concretament aquest és el format que utilitza subversion per la variable Id. En realitat jo havia escrit $Id$ allà on he volgut del fitxer anomenat codi.php, i en fer el commit al dipòsit el sistema ho ha substituït per la línia completa que veieu a dalt. Id és una combinació reduïda de les paraules clau $Author$, $Revision$ i $Date$, que també podeu utilitzar de forma independent. Al manual de subversion (en anglès) podeu llegir més al respecte. Si volem que tots els fitxers del nostre projecte que tinguem al sistema de control de versions subversion incorporin aquesta funcionalitat, hem de configurar el servidor de certa manera. Editem el fitxer /etc/subversion/config (aquest és el camí a Ubuntu, però serà similar a altres distribucions). Per defecte enable-auto-props està comentat, ho deixem així:

    ### Set enable-auto-props to 'yes' to enable automatic properties
    ### for 'svn add' and 'svn import', it defaults to 'no'.
    ### Automatic properties are defined in the section 'auto-props'.
    enable-auto-props = yes
    

    I una mica més avall editem les propietats automàtiques:

    ### Section for configuring automatic properties.
    [auto-props]
    ### The format of the entries is:
    ###   file-name-pattern = propname[=value][;propname[=value]...]
    ### The file-name-pattern can contain wildcards (such as '*' and
    ### '?').  All entries which match (case-insensitively) will be
    ### applied to the file.  Note that auto-props functionality
    ### must be enabled, which is typically done by setting the
    ### 'enable-auto-props' option.
    *.php = svn:eol-style=native;svn:keywords=Author Date Id Revision
    *.txt = svn:eol-style=native;svn:keywords=Author Date Id Revision
    *.sh  = svn:eol-style=native;svn:keywords=Author Date Id Revision;svn:executable
    *.tpl = svn:eol-style=native
    *.css = svn:eol-style=native
    *.js  = svn:eol-style=native
    *.htm = svn:eol-style=native
    *.html = svn:eol-style=native
    *.htaccess = svn:eol-style=native
    *.png = svn:mime-type=image/png
    *.jpg = svn:mime-type=image/jpeg
    *.gif = svn:mime-type=image/gif
    

    Jo he definit que només els fitxers amb l’extensió php, txt i sh tinguin la capacitat de substitució de paraules clau. A més a més els .sh vull que siguin executables (de manera que si algú fa un check out el propi subversion s’encarregui de marcar el bit d’execució per nosaltres). I si us hi fixeu, la resta de fitxers de text tenen una altra propietat: svn:eol-style=native. Això fa referència al final de línia (en anglès, eol = end of line), i serveix per què vàries persones treballin sobre els mateixos fitxers en sistemes operatius diferents (els quals usen diferents caràcters per indicar el final de línia). Les tres darreres línies són pels fitxers d’imatge, cadascun amb el seu tipus mime corresponent.

    Un cop fet això, ens assegurem que els fitxers nous que agreguem al dipòsit tindran aquestes propietats, però què passa amb els fitxers existents? Cal que els donem les propietats nosaltres manualment, i aquí entra la potència de la comanda find. I si ho podem fer tot d’una sola passada millor 🙂 Ens situem al directori arrel del nostre projecte i executem:

    find . \
    \( -name '*.php' -exec svn propset svn:eol-style native {} \; -exec svn propset svn:keywords 'Author Date Id Revision' {} \; \) , \
    \( -name '*.txt' -exec svn propset svn:eol-style native {} \; -exec svn propset svn:keywords 'Author Date Id Revision' {} \; \) , \
    \( -name '*.sh'  -exec svn propset svn:eol-style native {} \; -exec svn propset svn:keywords 'Author Date Id Revision' {} \; -exec svn propset svn:executable {} \; \) , \
    \( -name '*.tpl' -exec svn propset svn:eol-style native {} \; \) , \
    \( -name '*.css' -exec svn propset svn:eol-style native {} \; \) , \
    \( -name '*.js' -exec svn propset svn:eol-style native {} \; \) , \
    \( -name '*.htm' -exec svn propset svn:eol-style native {} \; \) , \
    \( -name '*.html' -exec svn propset svn:eol-style native {} \; \) , \
    \( -name '.htaccess' -exec svn propset svn:eol-style native {} \; \) , \
    \( -name '*.png' -exec svn propset svn:mime-type 'image/png' {} \; \) , \
    \( -name '*.jpg' -exec svn propset svn:mime-type 'image/jpeg' {} \; \) , \
    \( -name '*.gif' -exec svn propset svn:mime-type 'image/gif' {} \; \) > /dev/null
    

    I això és tot, a programar de gust! 😉

    GD Star Rating
    loading...

  • Error javascript provocat pel plugin Ozh’ Admin Drop Down Menu de WordPress

    No sé si hi ha alguna incompatibilitat entre els plugins RB Internal Linker i Ozh’ Admin Drop Down Menu de WordPress, però ahir vaig actualitzar el primer a la versió 2.0.11 i ara està fallant. El problema l’he detectat amb Firebug (quina eina més meravellosa!), que mostrava el següent error de javascript:

    syntax error
    var oam_toomanypluygins = ;\n

    He cercat directament al directori de plugins quin fitxer contenia aquest nom de variable, des d’una connexió ssh al servidor, així:

    egrep -r oam_toomanypluygins *

    Han sortit tres resultats. El problema es troba al fitxer ozh-admin-drop-down-menu/inc/core.php, a la funció en llenguatge PHP wp_ozh_adminmenu_js().
    A la línia:

    $toomanyplugins = $wp_ozh_adminmenu['too_many_plugins'];

    veiem que la variable PHP $toomanyplugins és assignada i més endavant inserida directament entre codi javascript. Ràpidament ens podem adonar que si la variable és buida s’introduïrà un error al codi javascript perquè faltarà algun valor entre els caràcters = i ;

    var oam_toomanypluygins = ;

    Per resoldre-ho, després de la línia PHP anteriorment esmentada he afegit:

    if (empty($toomanyplugins)) {
        $defaults = wp_ozh_adminmenu_defaults();
        $toomanyplugins = $defaults['too_many_plugins'];
    }
    

    D’aquesta manera comprovem si la variable és buida i li donem el valor per defecte abans d’inserir-la entre codi javascript.

    Resolt! 🙂

    Actualització (01-03-2010): a vegades les coses serveixen per més persones, per això és bo compartir. El desenvolupador del plugin m’ha contestat:

    Hello Jaume
    Nice catch, thanks for this! I’ve updated the plugin to deal with this case
    Cheers,
    Ozh

    GD Star Rating
    loading...

  • Fi de la Drupal Camp Barcelona 2010

    logo drupal camp spain barcelona 2010

    Aquest migdia ha acabat la Drupal Camp Barcelona 2010. Després de les sis ponències que vaig escoltar ahir, avui he decidit assistir a les següents:

    La que més m’ha agradat avui ha estat la primera, d’en Daniel Primo Gorgoso.

    GD Star Rating
    loading...

  • Drupal Camp Barcelona 2010

    Ahir va començar la Drupal Camp Barcelona 2010, el major esdeveniment anual organitzat per i pels amants de Drupal a Espanya. Jo vaig ser dels tres primers en inscriure’m-hi i ahir ja em vaig perdre el primer dia per culpa de passar hores al metge. Però avui, malgrat anar enguixat i amb crosses, sí que assistiré a totes les ponències que pugui. Som-hi!!

    Actualitzo (27-02-2010): finalment he assistit a totes les ponències de la sala auditori, la gran. Han estat:

    La tercera és la que més m’ha agradat, realitzada per César Martin, sobretot pel seu dinamisme i la quantitat d’exemples que ha comentat.

    GD Star Rating
    loading...

  • Com obtenir el Pagerank (PR) d’una uri des de PHP

    Primer de tot, per aquells qui no sapigueu de què parlo, us poso la definició de Pagerank de la Viquipèdia:

    PageRank és l’algorisme que utilitza Google per determinar la posició d’una pàgina web a l’hora de fer una consulta mitjançant el seu motor de cerca. Aquest mètode mesura el seu grau d’importància de forma numèrica i permet situar els resultats més fiables en primer lloc. Alhora, reflecteix la probabilitat que hi ha de que un usuari que navega a través d’enllaços de forma aleatòria arribi a una pàgina web concreta.

    Doncs bé, he trobat un script en el llenguatge de programació PHP que permet obtenir el Pagerank . L’he transformat en una classe i aquí el teniu…