Archive for the ‘CVS’ Category

Com fer push a Github amb un usuari diferent, quan hem clonat un repositori anònim

Dimarts, desembre 24th, 2013

Si et trobes que has fet un git clone d’un repositori anònim que et pertany, hi treballes des de PHPStorm i després vols fer push amb uns canvis, et retornarà un error 403 i no et deixarà.

La solució és tant senzilla com anar a la línia de comandes, entrar al directori del vostre repositori i escriure:

git push

Us demanarà l’usuari i la contrassenya i llestos.

sshfs muntar una carpeta a través de ssh

divendres, febrer 3rd, 2012

En Linux muntar una carpeta de servidor per Samba i treballar-hi amb projectes de PHP, suposa alguns problemes.

En primer lloc és molt lent i nombrosos programes perden molta estona, minuts, en recuperar els arxius d’un directori.

Després no està gens recomanat per a Subversion.

A part hi ha problemes de permisos entre usuaris de Linux, i sovint problemes amb la data i hora dels arxius al repositori Samba.

I suposa greus problemes si unim Samba + SVN + PhpStorm.

Aquests problemes desapareixen si enlloc de Samba utilitzem sshfs, que és una utilitat que ens permet muntar carpetes al nostre sistema d’arxius, tenint simplement un usuari ssh.

Jo tinc m’he fet un petit script o guió, que em munta una carpeta cada cop que el crido:

#!/bin/sh
usuari_devel=carles
sshfs $usuari_devel@devel.servidor.codic.cat:/home/OFICINES/$usuari_devel /home/$usuari_devel/devel

Per a instal·lar-lo:

sudo apt-get install sshfs

Gràcies Xavier Vidal.

Li vaig trobar un problema, que és quan poses l’ordinador en modus de suspensió (sleep/suspend), ja que després no pots accedir a la carpeta, ni desmuntar, ni tornar a muntar-la amb sshfs.

L’he pogut solucionar fent:

fusermount -u $mountpoint_devel

tot just abans de suspendre l’ordinador.
En tornar-lo a iniciar després, caldrà obrir una connexió ssh cap al servidor manualment (ssh elmeuservidor), i després podem tornar a llençar sshfs per a muntar la carpeta.

Alliberat Subversion 1.6.16

dissabte, març 5th, 2011

Ha estat alliberada la versió 1.6.16 de Subversion (SVN).

Aquesta versió del popular gestor de repositoris de programari presenta millores com:

– S’han solucionat algunes petades (crash)

– Millora el rendiment

– Resolució de bugs en general

Podeu veure la llista completa de canvis:

http://svn.apache.org/repos/asf/subversion/tags/1.6.16/CHANGES

Adreça curta Twitter: http://wp.me/pzeab-1MM

Fer fracassar projectes d’IT

diumenge, febrer 13th, 2011

Fer que projectes on s’hi ha invertit milions fracassin no és tan fàcil.

Caldria un destraler de la mida de jordi hereu, joan clos, zapatero o un malvat sense cor com jose maría “ansar”, o un brètol extremadament mentider i egoista com alberto ribera de ciudadanos.

Però en situacions normals no serà fàcil que fracassin els projectes d’IT, doncs els programadors que els han d’executar són professionals llargament formats amb el pas dels anys, que han invertit moltes hores de proves, temps d’estudi, investigant els detalls de la tecnologia, diners en llibres, que sacrifiquen part del seu temps personal per a mantenir-se al dia a les darreres tecnologies i així no quedar obsolets i poder oferir les millors solucions a qui els contracta. Però a més de tot això també són magnífics psicòlegs, perquè on el client demana un pal amb una roda de patí, saben veure que el que volen en realitat és una bicicleta (o un psiquiatra).

Llavors, perquè fracassen els projectes?. Perquè s’endarrereixen els terminis, perquè acaben sent molt més cars que no s’havia previst?.

En un moment anem a aquest punt però primer deixeu-me exposar la piràmide de metodologia clàssica.

En la metodologia clàssica de desenvolupament de projectes , hi ha uns quants rols definits: Programador, Analista Programador, Analista Orgànic, Analista Funcional, Cap de Projecte.

Els programadors, són els que ocupen la base de la piràmide. N’hi ha molts i són els qui fan la feina.

Després d’un temps de programar, dos anys o tres, els caps han vist si té aptituds, i si presenta una bona capacitat d’anàlisi, de síntesis de la informació, si és capaç d’organitzar la informació, i de redactar documentació, aquesta persona pot fer algunes tasques d’Analista.

Llavors tenim un Analista Programador.

Si durant uns dos anys aquesta persona es desenvolupa bé fent d’Analista Programador i té aptituds, pot començar a fer d’Analista Orgànic.

Un Analista Orgànic analitza la informació, i prepara documentació orgànica o tècnica. Amb una analisi orgànica els programadors saben com han de fer les coses tècnicament (noms de camps de la base de dades, mida, tipus de dades, claus… llenguatge de programació, etc…).

Després d’uns dos anys de fer d’Analista Orgànic, si s’ha entès bé amb els equips de programadors que depenien de les seves anàl·lisi, i la persona demostra aptituds com entendre la gent, partir els problemes en petites solucions individuals, si sap tractar amb la gent, se’l promou a Analista Funcional.

L’Analista Funcional es reuneix amb els clients (majoritàriament ho fa el Cap de Projectes o l’Analista acompanya el Cap de Projectes), els demana què volen, i a partir del que li expliquen amb paraules planeres, fa les preguntes adients i redacta una documentació explicant el que es vol fer i com es farà (sense els detalls tècnics que corresponen a l’Analista Orgànic).

L’Analista Funcional normalment acostuma a dirigir un petit equip de 3 a 5 programadors.

I finalment si se n’ha sortit bé amb les tasques d’Analista Funcional, se li detecten qualitats per a la planificació fins i tot de diversos projectes alhora, guiar equips i formar-los, negociar amb proveïdors i clients, caràcter, fermesa, empatia i dots de líder, aquesta persona passa a ser Cap de Projectes (CP / JP / PM – Project Manager).

(Nota: hi ha un altre subtipus que es diu Cap d’Equip o Team Leader, que ve a ser un Cap de Projectes descafeïnat, sense masses coneixements ni autoritat a l’organigrama, i que s’encarrega de dirigir un petit equip de Programadors o Analistes Programadors).

És a dir, per disposar d’un Cap de Projectes o d’un bon Analista Funcional calen entre 8 i 10 anys.

Aquest model era útil en els temps en que els ordinadors valien una fortuna, utilitzaven sistemes propietaris i llenguatges de programació i bases de dades que no podien aprendre’s si no estaves dins d’una empresa i portaves molt de temps estudiant-los.

Això no vol dir que aquesta piràmide de la metodologia clàssica sigui la ideal.

Hi ha programadors extraordinaris que valen un imperi, però que no serveixen, ni els agrada ni els interessa, per a fer Anàlisis Funcionals o parlar amb els clients.

No és raonable no fer servir aquest Talent, i és una ximpleria encasellar-los en funcions laborals rígides i en feines que probablement no els agraden, o fer que no puguin programar simplement perquè són tan bons que mereixen ascendir. No té sentit.

Però el que sí que té molt bo la metodologia clàssica de Desenvolupament de Projectes de Programari (Software) és que t’assegurava que un Analista Funcional o un Cap de Projecte tenien una formació suficient i les aptituds i les capacitats necessàries per a fer la seva feina.

Diguem que aquest lent procés d’escalar per la piràmide actuava de filtre i deixava fora dels llocs més delicats les persones que no en tenien la capacitat, ja fos humana, tècnica o comercial.

Sota el paraigües dels rols de la metodologia clàssica hi ha hagut la picaresca de moltes empreses de serveis (outsourcing), que com quan més amunt en la piràmide més es cotitzava, feien passar Analistes Programadors per Caps de Projecte per tal de facturar més per la hora, o programadors novells o inexperts per programadors Sènior (mínim amb 5 anys d’experiència) .

Un altre problema dels programadors que treballen en consultores fent outsourcing és que van de client en client, d’empresa en empresa, programant el que saben, però ningú els ensenyava res i ningú els corregeix els errors que cometen perquè ja són en un altre client, així que van repetint els mateixos errors empresa rera empresa. Si treballessin amb un bon Cap de Projectes aquest els formaria i els corregiria els errors de codi, disseny de bases de dades, etc…

Pel·lícula "OfficeSpace" traduïda com "Trabajo basura", absolutament imprescindible per a comprendre la vida dels programadors mal gestionats i com les empreses perden diners a cabassos

També existeix l’estafa barroera que es va posar de moda gràcies a la ignorància dels empresaris consistent en que algú que es venia com Cap de Projecte “gestor” i no tècnic, tot menystenint els tècnics proclamant que saber programar implicava no tenir cap habilitat per a dirigir equips o prendre decisions comercials. Solien dir “jo no sóc un cap de projecte tècnic, jo sóc un gestor. Els Caps de Projecte no haurien de saber programar, si en saben és que no són uns bons Caps de Projecte. Són els programadors qui han de saber programar”.

Lògicament tots els projectes on foten l’urpa aquests bon vivant fracassen, i els programadors acaben fent de Cap de Projecte i treballant 12 hores al dia i els caps de setmana gratis mentre els falsos Caps de Projecte menteixen creativament per amagar als seus caps els autèntics motius del fracàs del projecte. Aquests projectes solen acabar amb alguns programadors injustament acomiadats, amb una demanda contra l’empresa per part del client per incompliment de contracte o amb el fals Cap de Projecte abandonant l’empresa a mig projecte per a anar a enfonsar projectes una altra empresa però cobrant més.

Vendre la manca d’habilitats (skills) com si fossin una avantatja!.

Això vindria a ser com dir que un entrenador de futbol no ha d’haver estat futbolista.

L’exemple és prou gràfic. Si no ha estat futbolista no sabrà el que passa al camp, el que és rebre un cop, el que ofega entrenar 7 dies a la setmana sense un dia per estar amb la família, el desgast dels viatges en autobus de 14 hores, el que és una sobrecàrrega muscular, els nervis de jugar en un camp hostil, quina és la bona manera de fer les passades, no sabrà el que és jugar en una posició que no és la teva, amb pluja, etc…

Un exemple que vaig crear fa temps és el d’un Director d’Hospital que no sigui metge.

Doncs si no és metge i només “gestiona” pressupostos difícilment els metges podran fer-li entendre que cal un aparell de raigs X, o que cal substituir un aparell de ressonància que emet radiació letal!.

Això també ha fet molt de mal.

Com tot a la vida, hi ha mals metges, mals advocats, i mals Caps de Projecte (en realitat no mereixen dir-se així, però com no hi ha cap títol que acrediti que ets un bon Cap de Projecte fan passar bou per bèstia grossa).

És a dir, que per a tenir resultats ben professionals, calen bons professionals!. I costa molt de formar bons professionals.

I si no els sabem distingir ens la colaran i els nostres projectes aniran com el cul.

Avui en dia, amb Internet i els ordinadors generalitzats, un bon programador amb una bona idea, pot crear un projecte per si sol.

El Talent permet diferenciar-se i una sola persona pot fins i tot fer que una companyia que anava a desaparèixer avanci la competència i obtingui beneficis milionaris.

Ara imagineu Leo Messi, Xavi Hernández i Andrés Iniesta guiats per un entrenador mediocre, que no en té ni idea, però que vol fer creure tothom que en sap, i empra l’arrogància, crea terror i promou la manca de diàleg per a intentar dissimular les seves mancances.

Però tornem al model clàssic.

Si tens una persona que porta 8 anys preparant-se per a preparar documentació, per a compilar els requeriments en apartats que facin clara i entenedora la feina que han de desenvolupar els programadors i tan ben definida que no hi hagi lloc a dubtes sobre el que es fa, el que no, i com es fa, que si el client demana un canvi, no hi hagi dubte de que és un error seu i l’hagi de pagar com el que és: un canvi de requeriments; si tens aquesta persona, no repetiràs la feina dues vegades, per que fa la seva feina ben feta.

Per que el que fa fracassar els projectes no són aquells programadors que porten anys formant-se i que són els únics que fan hores extres gratuïtes o que treballen dissabtes i diumenges sense cobrar per complir un plaç que no han establert o que s’ha desvirtuat per un canvi/ampliació de requeriments que no paga el client.

El que fa fracassar el projecte és que tot aquest Talent dels programadors és en mans de persones que no tenen ni idea.

Persones que es diuen “gestores” que no saben jugar a futbol. Persones absolutament júniors o encara menys, amb molt poca experiència al món laboral, i sense les aptituds que té qualsevol Analista Funcional.

Llavors, com es vol que els projectes no fracassin?.

A la mitologia clàssica Aquiles conduïa els seus soldats a la victòria. Lluitava amb ells. Era un crack de les tècniques de lluita (programació).

I els seus homes el seguien sense dubtar-ho perquè sabien que sabia el que es feia, i no els conduïa a una derrota pel motiu de ser un ignorant sobre assumptes de guerra.

A la pel·lícula Troia mostren un Aquiles que sabia lluitar, sabia defensar-se, sabia metodologia sobre com s’havia de defensar el grup i era disciplinat.

La pràctica condueix a la mestria, i el Talent s’ha d’aconseguir amb dur esforç.

Ara imagineu-vos un montilla dirigint un exèrcit. Què passaria?.

Dir el que s’ha de fer des de reraguarda és fàcil. I aquest mal cap pot tocar el dos si les coses es posen peludes.

Però arremangar-se i fer que les coses funcionin requereix: 1. Voluntat 2. Habilitat (skills) 3. Esforç

Llavors, tenim empreses multinacionals que paguen sous de 30.000 € bruts anuals als seus programadors, si és un equip de 10 programadors 300.000 € bruts anuals, és a dir, tenen 300.000 € bruts anuals en Talent programador, però després posen aquest talent en mans de “gestors” sense experiència.

A la batalla, generals sense formació ni experiència guien les tropes d’elit al fracàs i a la seva aniquilació, que en el món d’IT es concreta en que els millors toquen el dos i van a empreses on els deixin treballar bé.

Normalment però abans han perdut moltes amistats i la seva vida social és una merda perquè es deixen la pell a la feina tractant de compensar el que d’altres espatllen amb la seva mala gestió o colant canvis de requeriments quan el projecte és a mig fer pel simple motiu que aquests gestors no fan els deures.

Avui en dia, la piràmide clàssica no és molt utilitzada, i tenim programadors multidisciplinars que quan convé fan d’Arquitectes de Sistemes, de Cap de Projectes, d’Analista Funcional (o en els cassos més humiliants de Dissenyador Web. Programar i fer servir el photoshop normalment és com ser de Green Peace i treballar a un escorxador. Requereix qualitats diferents i el que és bo en una cosa acostuma a odiar l’altra)

Però tenim un single point of failure, un punt d’error on falla tot. I és que els projectes són dirigits per persones que no tenen ni idea de què dirigeixen.

No saben res tècnic, però tampoc saben prendre requeriments. Així que els projectes són conduits al fracàs, al sobre cost, i els desenvolupadors es cremen i marxen.

Posats a escollir, sempre és millor que dirigeixi un equip o un projecte, algú sense dots tècniques però sí amb humanes que escolti i valori els tècnics, ja que si els escolta aquests el guiaran cap a la manera bona de treballar.

Els tècnics, siguin on siguin de la piràmide, estimen la seva feina, li dediquen moltes hores a perfeccionar-se i volen fer bé les coses.

Ens sentim orgullosos del que sabem fer i de com ho fem, i necessitem sentir-nos orgullosos de la nostra feina.

No hi ha una manera millor de fer plegar un equip que fer-li fer malament les coses.

Seria com forçar que un escultor genial que fa obres extraordinàries, treballi amb mals materials, males eines, amb menys temps del necessari i forçar-lo a fer xapuces. Intolerable!.

En el món dels informàtics hi ha de tot: professionals bons, normalets, amb inquietuds, per qui només és una feina… encara que majoritàriament abunden els qui estimen la professió.

Però per a saber distingir-los i guiar-los adientment cal molta competència i know how a nivell directiu.

I si es treballa per projecte, o per sprints com a la metodologia Scrum, val més que inverteixis en que els Product Owners siguin bons professionals, ben formats i amb experiència, perquè altrament estàs desaprofitant aquell Talent i cremant-lo.

I és que la majoria dels projectes d’IT fracassen, perquè els qui recullen els requeriments no els prenen bé (incomplets o erronis), perquè el client dóna un coneixement funcional erroni o incomplet, esbiaixat, i després van passant canvi sobre canvi, xapussa sobre xapussa i sempre tractant de mantenir els mateixos costos i terminis.

La majoria de cops el client no sap el que vol, molts ni tant sols saben en detall com funcionen processos crítics del seu departament, però això no els priva d’engegar projectes on s’han d’informatitzar.

I si el responsable d’una àrea, el client, no té el coneixement del que fa la seva àrea funcional, llavors ningú el té i el programador no ho podrà endevinar.

En aquests casos els informàtics només poden fracassar. De la mateixa manera que un arquitecte no pot construir una casa a mida pel client, si el client no sap quantes portes vols, si vol una o dues plantes, si hi ha d’anar ascensor per algú amb problemes de mobilitat, etc… i si a sobre el client canvi de parer constantment i es nega a pagar el sobrecost d’enderrocar les parets fetes, refer els plànols i tornar a començar la secció.

En tot cas és just que el client despistat pagui el sobrecost de les coses que van recordant (sobre la marxa) que porta la seva àrea i que s’han de reflectir al projecte. (Nota: encara que ho expressi amb humor és inadmissible que un responsable d’àrea no sàpiga què fa o què ha de fer el seu producte, servei o àrea).

Així que si voleu que els vostres projectes d’IT no fracassin, contracteu bons professionals. Digueu no a la incompetència.

Els bons programadors són importants i et salvaran el cul si tot ho altre falla i no hi ha metodologia, però un bon Cap de Projecte amb un equip de programadors Junior els acabarà formant i es preocuparà de que treballin amb metodologia.

Les persones que recullen els requeriments és clau que siguin bons professionals amb experiència. Altrament faran refer funcionalitats als programadors, desfer moltes hores de feina, i cremarà els tècnics perquè algú que fa d’analista funcional sense tenir ni idea no entén res de res. A més reportarà errors (bugs) que no ho són, si no que són canvis de requeriments encoberts de requeriments que no van passar al seu dia o van passar explícitament així, reportaran bugs que no són bugs si no funcionament estàndard del navegador o amb explicacions vagues i incompletes, sense captures de pantalla, etc…

I si el valor afegit de la seva “gestió” és reenviar emails, val més que contractis a una becària o becari i els posis al servei dels programadors per a que reenviï els emails.

Estalviaràs diners i problemes.

Diguem no a la incompetència.

Perquè els directors no han d’oblidar que el desenvolupament de programari és una feina artesana. Com els sastres.

Els programadors fan els vestits a mida per als seus clients (programes), però no hi ha res més ximple que posar a algú que no és sastre a destorbar la feina dels sastres, i que no els deixi prendre mides a ells i els doni mides parcials i incorrectes, els les canviï després que ja han dissenyat el patró i tallat la tela, els digui com han de treballar o els empenyi a estar més hores al taller quan resulta que la feina no es pot entregar a temps precisament perquè el no sastre no deixa fer bé la feina als artesans programadors.

I quan dic artesans ho dic de manera estrictament literal.

El programador ha de conèixer aspectes del maquinari, com la velocitat a la que pot escriure en disc, o desenvolupar estratègies per a superar aquest límit, calcular quantes instruccions pot executar el servidor per segon, extrapolar quants usuaris concurrents (alhora, que ara estem a Internet i la web s’accedeix globalment) suporta la web, optimitzar els colls d’ampolla per superar aquests límits, fer consultes a la base de dades que ben fetes triguen 0,01 segons però mal fetes poden bloquejar el servidor durant quatre segons (i 50 també!)… es construeix amb molt de talent i coneixent els detalls de les màquines, els sistemes operatius i els llenguatges de programació!!! I també els seus límits.

Bé, si l’empresa és milionària i no li preocupa la competència sí que es pot treballar així.

Avui en dia ens trobem amb nous paradigmes, un d’ells és que molts joves saben molt més que els seus professors en algunes àrees. Si els membres s’un equip saben molt més que qui els mana i aquest els obliga a fer les coses malament, l’empresa perdrà l’equip.

Es pot tenir un Cap de Departament no tècnic si té unes magnifiques qualitats humanes i de planificació i escolta els tècnics.

Però és devastador que qui pren els requeriments i demana explicacions sobre com estan els desenvolupaments, és a dir qui actua com Analista Funcional i com Cap de Projecte (els product owners a la metodologia scrum) no tinguin ni idea del que fan.

També és un problema que persones que no saben de programació prenguin decisions, o deixin de prendre decisions necessàries, sobre com es treballa amb els repositoris de codi (CVS, Subversion, Git…), quins servidors de desenvolupament hi ha i qui els pot gestionar, quins entorns hi ha (desenvolupament, integració, pre-producció, producció/explotació), quina metodologia es fa servir per a les pujades o per a la programació del codi…

Tot sovint els equips es trobaran treballant sobre els mateixos recursos (arxius de codi, procediments emmagatzemats de la base de dades…) bloquejant-se i trepitjant-se els uns als altres, amb branques desactualitzades… i les pujades a producció seran infernals, llargues, feixugues, plenes de problemes, fent que l’empresa perdi diners en estar parada la web (o generant errors) i cremaran els bons professionals que només tracten de fer bé la seva feina.

En moltes empreses de consultoria i de Desenvolupament a mida de Programari els que la lien són els comercials. Com ells cobren bonus en funció de la quantitat de projectes que venen, i tampoc tenen ni idea de res, venen coses impossibles, amb terminis esbojarradament curts o molt per sota del seu cost d’execució real, i un cop signat el contracte cobren i desapareixen deixant el marró al Cap de Projecte i a l’equip.

Una altra tècnica que fan servir els mediocres és fer reunions constantment, que esdevenen trampes per a monopolitzar el temps dels Caps de Projecte potents que podrien canviar les coses.

Des de la seva posició a negoci, imposen fer reunions que consumeixen hores salvatgement i impedeixen avançar en àrees importants.

I és que ja sigui per a recollir requeriments, per a redactar documentació, per a programar, per a dirigir un projecte, per a tenir cura de l’equip… cal tenir temps per a dedicar-li.

Valdria més sacrificar un programador Sènior i, després de pactar-ho, demanar-li que faci de product owner (metodologia Scrum) i reculli els requeriments.

Serà fotut per a ell si li agrada programar, però tindrà la satisfacció que els seus companys poden treballar molt a gust amb els requeriments ben especificats i que la feina surt bé i més ràpid. Farà documents funcionals clars i ben redactats i no els passarà ni una als clients, perquè sap que la badada consentida del client, vol dir hores de feina extra i frustracions per als seus companys.

Per a evitar situacions com les que he descrit jo proposo que les empreses tinguin clar tot això que he dit, contractin bons caps i analistes funcionals, i facin avaluacions de 360 graus.

A les avaluacions de 360 graus, els treballadors, individualment, parlen amb una persona de recursos humans de la seva confiança i avaluen els seus caps i altres aspectes de com funciona la companyia. Lògicament la persona de recursos humans ha d’estar molt ben preparada, perquè si no encara generarà més frustració. Es tracta d’escoltar la informació clau que ens diu la gent, ja que ens aportarà una informació valuossíssima sobre on està fallant la companyia i quins són els comandaments intermedis que fan que les coses no funcionin.

Adreça curta Twitter: http://wp.me/pzeab-1KT

Alliberat Subversion 1.6.13

divendres, octubre 1st, 2010

La versió del programari per a control de versions ha estat alliberada en la seva versió 1.6.13.

Aquesta versió soluciona diversos errors, millora la gestió d’urls (per exemple: amb caràcters insegurs), proporciona compatibilitat amb Ruby 1.9…

Podeu veure les millores de la branca 1.6 al seu lloc web:

http://subversion.apache.org/docs/release-notes/1.6.html

Alliberat Subversion 1.6.12

dilluns, juny 21st, 2010

Fa uns minuts s’acaba d’alliberar la versió 1.6.12 del popular programari de control de versions Subversion.

A més de 65 errors solucionats ofereix nombroses novetats.

Podeu veure totes les novetats d’aquesta versió a la plana oficinal:

http://subversion.apache.org/docs/release-notes/1.6.html