[gilug.org] [OT] Recomenacions per editor PHP

2006-05-19 13:25:34 UTC

On Fri, 2006-05-19 at 10:24 +0200, Eduard Vidal i Tulsà wrote:
> En/na Raul Perez ha escrit:
> > On Thu, 2006-05-18 at 17:56 +0200, Marc Torres wrote:
> > 
> >>El 18/05/06, Eduard Vidal i Tulsà ha escrit:
> >>
> >>>>Sisi, guerra!
> >>>>
> >>>>
> >>>
> >>>La guerra dels editors començat ha :P
> >>
> >>Jejeje, encara que la llista estés adormida, veig que la gent es
> >>desperta ràpid :-D
> >><flame start> ;)
> >>
> >>
> >>>Debug a un php?
> >>>
> >>>només s'ha d'activar que el php et mostri els warnings i els errors
> >>>només miran la plana ja veuràs quina merda de programa estas fent...
> >>>no nessesito que un programa fet amb java que triga l'ostia a carregar
> >>>m'hi digui, ja tinc l'apache :)
> > 
> > 
> > I perquè no ? 
> > A vegades et pots trobar que al llançar un missatge al navegador es
> > talli el procés que estiguis fent ( sobretot en accions POST que
> > requereixen redireccions ).
> > 
> Ostres, Jo em vaig trovar una vegada amb una cosa com aquesta, era un 
> proces que em creava una arxiu tex, i despres feia el corresponent pdf
> per depurar-lo vaig comentar la redirecció, per veure l'error del pdflatex
> Pots donar exemples on estiguis obligat a fer redireccions?
> Gràcies!

Un exemple molt clar és quan el retorn al usuari no és "text/html" MIME
per defecte al navegador.

El cas del PDF és un d'aquests. Tu fas una crida a un script el qual ha
de generar un resultat que no és HTML.
Poden ser PDF's .. poden ser Imatges ( img/jpg etc .. ) i poden ser
altres tipus de media quan per exemple has de fer streaming i llençar
directament audio o vídeo.

En quasevol d'aquests casos al intentar debugar i escriure qualsevol
cosa al navegador la capcelera HTTP és el primer que s'envia.
En aquesta capcelera s'especifica el MIME del resultat que generes ( que
per defecte és text/html ).
Llavors quan intentes escriure qualsevol altre tipus de média el
navegador el teu codi et fallarà.

En el moment doncs de per un $pdf->Output(); l'script et fallarà
generant un error tipus :

"Headers allready sent" ( semblant .. ara no tinc cap prova per aquí per
posar-ho exacte )

Com he fet per solucionar això ? Antigament havia fet servir codi meu
per simular logs en l'aplicació, escriure-ho en un fitxer text ( que et
pot donar problemes si no tens permisos d'escriptura i això passa tot
sovint en ISP's ) per mail etc ...

Actualment el que faig servir és Log4PHP
( http://logging.apache.org/log4php/ ) que és una llibreria d'apache
(els que feu Java i/o c# ja la coneixereu com log4j o log4net ).
És molt i molt fàcil de fer servir a més de ser molt configurable, pots
guardar els logs a fitxers texte, xml o directament en base de dades amb
el que desrpés és molt fàcil fer-te un petit lector d'aquests logs per
poder veure els errors.

A més és fàcil fer-te una classe que et serveixi després per a qualsevol
projecte que facis :)

Un altre exemple de que pot fer que et passi això són en les crides a
serveisweb siguin XMLRPC, SOAP o el que sigui.
En aquest cas el MIME de l'HTTP serà sempre "text/html" que entraría en
conflicte de la mateixa manera amb el "text/html" que hi ha per defecte.

> 
> > Llavors és molt útil poder debugar el codi.
> > 
> > D'altra banda jo també uso Vim ( no el gvim si no el vim a seques ).
> > 
> > 
> >>:-DDDDD
> >>Ja sé que el problema principal de l'eclipse és el que tarda a
> >>carregar... (ai, el java...) I evidentment el vim carrega tres mil
> >>dues-centes setze vegades més ràpid que l'eclipse, però bé, tinc un
> >>portàtil força decent i amb pocs segons ja tinc carregat l'eclipse.
> >>
> >>A l'albert, gràcies per l'enllaç, sempre és bo!
> >>
> >>A en Giro, gràcies pel consell, però la meva intenció és tenir el codi
> >>al repositori (és correcte en català?) svn i anar-lo desant allà.
> >>L'ftp el necessito per pujar els fitxers php al servidor i fer la
> >>prova
> > 
> > 
> > Que jo sàpiga és més adient dir "dipòsit" que no pas "repositori" o si
> > més no és el que diuen els de SoftCatalà i/o el TermCat.
> > 
> > Quan al SVN només dir que hi ha molta gent que empra malament aquest
> > tipus de programari :
> > 
> > SubVersion així com CVS, Bazaar o d'altres són gestors de versions
> > col·laboratius. És a dir que el seu propósit és sempre guardar les
> > difents versions que poden ser alfas, betas, estables etc ... de la
> > feina que estiguem fent.
> > 
> Així a un subversion només s'envia la feina quan funciona?
> pots explicar-nos una mica la filosofia?

La filosofia sempre és que la teva feina de programació estigui ben
definida, feina que és la que normalment fa un Analista de Sistemes.

Això sempre ajuda molt a que després no perdis temps pensant en com fer
les coses ni en les funcionalitats que li pots afegir al teu programa
simplement perque ja ho has fet abans.

De fet no és res més que la vella i mítica tàctica del "Divide y
vencerás" :)

Posem per exemple que fas un afegit a una web dinàmica i que has de fer
que el llistat de comandes que tenen a la seva intranet es pugui ordenar
per data i per nom de client.

Un cop saps això has de fer la "divisió" del problema en petites parts i
un exemple d'aquesta sería :

- Modificar la classe Comanda.php i afegir-li el métode :
getComandesOrderBy(string ordercamp, string orderdirection)

- Modificar la web perque faci servir aquesta funció en comptes de
l'antiga getComandes() que no gestionava l'ordre.

- Modificar la plantilla web perque tingui un COMBO on poguem escollir
l'ordre que volem.

Com pots veure he dividit el que era en principi una "tasca petita" en
tres de ínfimes o trivials.

Fer la primera tasca petita pot provocar que no la tinguessis enllestida
en tota una jornada laboral i, llavors quan és l'hora de marxar hi ha el
dilema de que fer ... pujar això al SVN o no, i el més important .. si
commito que hi poso com a missatge ?

Tenir una revisisió que no funciona al teu dipòsit no és logic ja que en
principi no necessitaras mai recuperar-la ja que no esta finalitzada a
part dels conflictes que poguessis provocar a d'altres programadors en
el cas de que estiguessis en un grup de treball a l'actualitzar-se el
codi i veure que han de fer feina extra per fer compilar/funcionar el
codi per seguir amb les seves tasques.

En el cas de fer les tasques infimes i trivials, saps que si en la teva
jornada laboral només pots fer-ne dues de les 3 que hi ha no destorbaràs
als teus possibles companys a més de que podran veure la feina que has
fet tu en els dos missatges que has generat al fer els dos commits.

> i si soc monoprogramador, com en joan palomo... a mi em serviria?

Et pot servir i serveix per exemple per poder calcular amb detall el que
pots trigar a fer un determinat producte sobretot quan els projectes són
llargs i has de calcular per exemple nº d'hores i/o data de finalització
( aquesta última dada sempre ens la demanen jejeje ).

D'aquesta manera et servirà per poder dimensionar bé el problema i que
després tal com es diu popularment no "t'enganxi el toro" :)

Com moltes coses és questió d'actitud i no pas de necessitat, a més
l'acostumar-se a treballar d'aquesta manera fa que en el moment que et
trovis amb feines on hi ha més programadors a part de tu no tinguis cap
tipus de dificultat a adaptar-te a noves situacions :)

> Jo el que faig es tinc una versió que funciona, i despres quan l'he 
> millorat em carrego l'antiga (tar cjvf antiga`date`.tar.bz2 
> programaweb/; rsync portatil:/cami/de/proves/ programaweb/ ) i poso la 
> nova...
> Que em recomeneu?
> 

És perfectament compatible el que he explicat abans amb el que estas
fent ara. A més ... perquè carregar-se la versió antiga ?
Hi ha mil i una raons per guardar una versió que funcioni pero amb menys
funcionalitats. 

> 
> > He vist en la gran majoría dels casos a desenvolupadors que fan servir
> > aquestes eines com a una simple carpeta on guardar-hi la feina amb el
> > que moltes vegades es troven dipòsits amb codi font que compilen
> > correctament o que ni tan sols funcionen.
> > 
> > Pujar versions que no compilen o pujar feines sense adjuntar-hi el
> > missatge pertinent pot provocar conflictes que després són complicats de
> > resoldre ( sobretot quan no volem perdre l'historic dels fitxers en
> > questió )
> > 
> > Clar que utilitzar correctament aquests tipus d'utilitats requereixen
> > una acurada fase d'anàlisi del producte a desenvolupar que .. moltes
> > vegades al ser adreçats a grups molt reduïts de programadors o fins i
> > tot a un sol programador és eliminada per presses ;)
> > 
> > 
> >>A l'eduard, dir-li que potser provaré el gvim, a veure què tal...
> >>(encara que sóc Kde-ero i això de tenir les gtk només pel vim... vinga
> >>segon flame, start! ;-D)
> has provat *kvim*, crec que aquest si que té suport per cvs...
> http://www.freenux.org/mirrors/kvim/
> >>
> >>Algú més a la sala? :-D
> >>
> >>Salute!
> >>
> >>Marc.
> >>_______________________________________________
> >>Llista mailing list
> >>
> >>http://gilug.org/cgi-bin/mailman/listinfo/llista
> >>
> >>
> >>
> >>
> >>------------------------------------------------------------------------
> >>
> >>_______________________________________________
> >>Llista mailing list
> >>
> >>http://gilug.org/cgi-bin/mailman/listinfo/llista
> 
> 
> _______________________________________________
> Llista mailing list
> 
> http://gilug.org/cgi-bin/mailman/listinfo/llista
> 

Ouch .. tall de parrafada que he fotut :)

No dubtis en preguntar el que vulguis si tens més dubtes! :)

-- 
Raul Perez <>
Web4Linux