trespams ha fet tres anys

Escrit per Aaloy a 31 de August , 2007 a les 9:33 p.m.

Ja ha plogut força des de que va tres anys vaig posar en marxa aquest bloc. Han estat tres anys d'escriure de tot un poc, però sobretot del que m'apassiona: la programació i la gestió de projectes i estimació informàtics, tant des del seu vessant tècnica com de la vessant humana. Les estadístiques del Wordpress em diuen que comptant aquest hi ha 167 entrades al bloc, la qual cosa vol dir un poc més d'una entrada setmanal. Vist en perspectiva no és massa, però a mi ja m'està bé. Vaig començar a escriure a mena d'exercici. Sempre m'ha agradat escriure, però fer-ho quan altra gent et pot llegir és una altra cosa, imposa respecte. Tenir un bloc és una manera de perdre la por escènica i acostumar-se a la comunicació escrita com a mitjà d'expressió. Des del principi aquest ha estat un bloc en català, per que sí, perquè m'agrada, perquè és el meu bloc on dic el que vull i perquè s'ha de poder parlar de tecnologia i de qualsevol cosa en català. En Benjamí ho explica molt bé al seu apunt damunt llengua i tecnologia. El boc a més ha servit per mantenir el contacte amb un bon grapat de gent i directa o indirectament contar-los el que estic fent, els meus interessos, el tic-tac de la feina, convidant-los a ser partíceps dels meus pensaments i de les meves inquietuds. Ha servit també com a mitjà on poder desestressar-me, sovint fent conya de situacions viscudes a la feina o al carrer, gairebé sempre, però, conservant la vessant tecnològica del bloc. Als visitants assidus i no tant assidus de trespams, us vull agrair el vostre interès i els comentaris i aportacions. Moltes gràcies! un pam, dos pams, tres pams, ...

1 comentari, 0 trackbacks (URL) , Tags: General


Fusió freda.

Escrit per Aaloy a 26 de August , 2007 a les 1:51 p.m.

Com he comentat en algunes ocasions l'empresa per la que treball està immersa en un procés de fusió, que culminarà la primera setmana de setembre amb la creació d'una nova companyia. Com la fusió freda, de la qual aquest article pren nom, hi ha moltes especulacions del que serà, de les possibilitats i del que passarà a partir d'ara, i com en aquesta hi ha poca informació i una sensació de que a la que se grati una mica hi pot haver una gran decepció. La manca d'informació en un procés així crec que no es bona. Davant la incertesa la gent té tendència o bé a cercar-se un lloc de feina amb més bones perspectives, o bé a adoptar una posició de wait-and-see, és a dir, de veure-les venir. En qualsevol dels dos casos l'empresa hi sol sortir perdent. Quan una persona deixa l'empresa per la incertesa del que pot passar, de fet està protegint el seu futur. Normalment les persones que marxen són aquelles amb capacitat per trobar un lloc de feina, i que troben que un procés de reestructuració, tipus expedient de regulació, ho pot deixar al carrer, i això implica que valdrà menys al mercat de treball, ja que normalment és cotitza molt més un treballador en actiu que un que estigui a l'atur.Davant això els treballadors més capaços poden veure's temptats a anar cercan feines amb millors perspectives i deixar a les empreses que es fusionen amb la gent que precisament no voldrien retenir. En el nostre cas particular tenc la sensació d'estar davant d'un canvi de cicle, tant de l'empresa com potser a nivell personal. Un canvi que s'ha visualitzat amb la marxa de l'empresa de una de les persones més vàlides que m'he trobat mai: el seu director financer. Tampoc és cosa que me posi aquí a especular damunt el que pot haver passat o no, però el cert és que davant el proper procés de fusió tenc la impressió de que ha guanyat el sector del "sortir en la foto". Particularment em sap greu, he fet feina amb aquesta persona durant anys i el conec bé, ant com per considerar-ho un amic. És d'aquell tipus de gent de la que cada dia pots aprendre coses, íntegre, directe, una capacitat de feina impressionant i amb profunds coneixements de la seva feina. Crec que l'empresa ha perdut capital humà en els moments en que més falta farà, i em deixa força intranquil pel precedent que representa. Aquest tipus de coses i una ample anecdotari de peticions del tipus "volem imprimir pdfs pel navegador sense que el client tengui que tenir instal·lat cap lector de pdfs" fan que darrerament em plantegi si no estaré treballant dins d'una tira de Dilbert.

4 comentaris, 0 trackbacks (URL) , Tags: General


Trac i clearsilver

Escrit per Aaloy a 20 de August , 2007 a les 9:07 p.m.

El clearsilver és una llibreria de plantilles que abans feia servir el Trac i que s'està substituint a favor de Genshi, una altra llibreria que segons la gent de Trac els causa molt menys problemes. La cosa està, però, en que no es lleven les dependències fins a la versió 0.11 no s'eliminen les dependències de clearsilver i fins i tot en aquesta versió es mantindran les estructures necessàries per a que els plugins segueixin funcionant. He pogut comprovar de primera mà el que es diu a la web de Trac, "clearsilver sucks", ja que amb Ubuntu i la versió 2.5 de Python no fa sino donar problemes, que sospit han acabat per tomar el servidor Apache 2 que tenim al webhosting virtual. En un primer moment he pensat que se'ns hauria tornat a oblidar el pagament, però no, tots els serveis eren vius llevat de l'Apache i als logs he vist un bon munt d'errors del tipus 
/usr/lib/python2.5/site-packages/trac/web/clearsilver.py:128: RuntimeWarning:

Python C API version mismatch for module neo_cgi: This Python has API version 1013, module neo_cgi has version 1012.
No ha costat molt trobar referències tant al Trac com a Ubuntu d'aquest error i de com solucionar-ho. Aquesta és la recepta que m'ha servit a mi:
  • Davallam el codi font: wget http://www.clearsilver.net/downloads/clearsilver-0.10.4.tar.gz
  • Modificam els arxius config i config.in, cercam les línees que diuen python_version i i afegint la versió 2.5 al davant.
  • Descomprimim el fitxer tar xvzf clearsilver-0.10.4.tar
  • Davallam paquets adicionals però aquesta vegada per apt-get
    • sudo apt-get install zlib1g-dev 
    • sudo apt-get install autoconf 
    • sudo apt-get install python-dev
  • Feim el configure: ./configure --disable-wdb --disable-compression --disable-perl --with-python=/usr/bin/python2.5
  • I per acabar el sudo make install
  • Com que la instal·lació no acaba d'anar fina convé copiar la llibreria generada sudo cp -i neo_cgi.so /usr/lib/python2.5/site-packages/neo_cgi.so per acabar de substituir la referència que hi havia de la llibreria anterior o fer un ellaç simbòlic cap a la nova instal·lació de clearsilver: sudo ln -s ./clearsilver-0.10.4-py2.5-linux-i686.egg/neo_cgi.so neo_cgi.so
Reiniciam l'apache i ja no hauríem de tenir més errors d'aquest tipus. Referències:

1 comentari, 0 trackbacks (URL) , Tags: Informàtica


Llibres agost-2007

Escrit per Aaloy a 17 de August , 2007 a les 8:59 p.m.

Això de que a l'estiu les coses van més a poc a poc és veritat en la majoria de coses, però no en l'enviament de llibres. El dimarts vaig rebre l'avís de que ja podia anar a recollir a correus els llibres d'Amazon que havia comanat no feia ni deu dies i que se suposava que havien d'arribar damunt el vint-i-quatre d'aquest més. Els dijous ja les tenia, després de l'obligat pas per correus. No sé com s'ho fan els de correus del meu poble, però la cosa és que quan es tracta d'entregar llibres mai ens hi troben, ni tan sols quan l'adreça és la de la meva sogra, que normalment sempre és a casa. Però bé, la cosa és que hem començat a fer una ullada a les noves adquisicions i la cosa pinta bé: Facts and Fallacies of Sofware Engineering Robert L. Glass Ed. Addison-Wesley ISBN 0-321-11742-5 Software Estimation Steve McConnell Microsoft Press ISBN 978-0-7356-0535-0 wxPython in Action Noel Rappin  & Robin Dunn Manning ISBN 1-932394-62-1 El primer el vaig comprar per les contínues referències que hi veia a altres llibres d'enginyeria de programari. Pel que duc llegit fins ara crec que no serà el darrer llibre que compri d'aquest autor. 55 fets i 5+5 fal·làcies  que tracten gairebé tots els aspectes de l'enginyeria de programari. El llibre sols mostra fets i ens fa reflexionar i fins i tot ens anima a no estar d'acord amb l'autor. Ara per ara sols duc llegides una trentena de pàgines, però si la qualitat de tot el llibre és com el que he vist fins ara trob que disfrutaré molt llegint-ho. El sofware estimation de McConnell no sabia si comprar-lo o no, després de la mala experiència amb el llibre anterior de McConnell, però al final vaig decidir donar-li una altra oportunitat. La primera impressió és positiva: bona edició i maquetació, espaiat correcte i ple de gràfics, taules i alguna que altra fórmula que ja era present al Rapid Development. Serà el següent després del de Glass. El wxPython in Action l'he comprat com una manera de contribuir al programari lliure. Robin Dunn és un dels principals mantenidors de la llibreria wxPython, i el llibre és una manera com un altra de reconeixement a la feina feta. A més, pel que estic vegint el llibre és molt complet i toca tots temes de la programació d'interfícies gràfiques amb aquesta llibreria. Un dia d'aquests m'agradaria poder fer el mateix amb PyQt4.x A més de la contribució a ben segur que li acabaré traient profit.

0 comentaris, 0 trackbacks (URL)


Va d’ERPs

Escrit per Aaloy a 15 de August , 2007 a les 7:55 p.m.

Des del blog de Ricardo Galli me n'assabent de dos articles [1] molt interessants damunt els ERP, a més obviament del seu(s) propis escrits. Particularment el ERPs em fan molta grima, tant perquè la majoria són programes tancats que fermen als seus usuaris, per la manera que es comercialitzen i perquè representen una manera de fer programes allunyada del que es consideraria bones pràctiques de programació. D'ERPs conec l'Oracle Financial, Navision i SAP, encara que aquest darrer molt de passada i tots ells tenen un problema fonamental: és l'empresa la que s'ha d'apatar a l'ERP. Si no es fa així els costs d'adaptacions són tan grans que ben bé l'empresa podria haver-se permès crear els seu programari a mida. Però clar, la manera de comercialitzar un ERP és dir que el programa fa tot el que necessita l'empresa i més, que té tots el mòduls i que en tot cas sempre es podran fer adaptacions. La realitat però, és que una vegada s'ha convençut a les altes esferes de la bondat de l'ERP i ja s'ha desembutxacat una quantitat més que considerable en llicències de l'ERP i la base de dades i comença la fase d'implantació i adaptació l'empresa ja està agafada. Si vol seguir fent feina de la manera que sap fer i que és el seu factor competitiu, haurà de fer mils d'adaptacions a l'ERP, adaptacions que es cobren a preu de canari jove i que poden doblar o triplicar el cost en llicències de l'ERP. La història de que la gent de l'empresa podrà fer adaptacions sense problemes no és més que això, una història. La realitat és que l'ERP és tan complexe que els propis consultors reconeixen que tenen gent especialitzada en un mòdul concret del producte. I després venen les actualitzacions de versions. Actualitzar torna a ser com a una implantació. En vaig viure una indirectament i sols veies gent de la consultora anar i venir, fent hores i més hores. El cost: prohibitiu! I sols va ser un canvi de versió! Els ERPs són el fast-food del programari de gestió. Prometen una solució ràpida, però després resulta que has de fer coa per a que t'atenguin i si en menges molt tens assegurada una indigestió. Els ERPs també prometen una solució immediata a les necessitats d'informatització d'una empresa, però es cuide'n molt de parlar-te dels temps d'implantació que s'aniran allargant, dels riscs de la implantació i del que et costaran les futures actualitzacions. Si parlam d'enginyeria de programari hem de parlar del costs de desenvolupament dels projectes i de la quantitat d'errors i del cost del maquinar. Es ben conegut que un programa de 100.000 línies no té un cost 10 vegades major que un de 10.000 línies, sinó que el cost és sensiblement major, i quan es desenvolupa programari per un ERP estan agafant tant les complexitats del programa que desenvolupam més les complexitats del propi ERP. Els ERPs tenen desenes de milions de línies de codi, i per tant les possibilitats que hi hagi errors en el codi augmenten en la mesura que augmenta el nombre de línies. Si tenim un programa de 10.000 línies i una taxa d'errors de 5 errors per KLOC podem estimar que tenim uns 50 errors pendents de detectar quan el programa passa a producció. Com que segons Putnam-Myers el nombre de defectes per línies de codi és lineal, podem esperar que l'ERP tengui una taxa d'errors en la mateixa proporció o major, ja que el distribuidor es cuidarà molt de dir-nos quin és el ratio d'errors del programa o el temps necessari per la seva actualització. I si el nostre negoci depèn de fer adaptacions a programari que tindrà errors, que haurem de corregir mantenir i que possiblement perdrem en la propera actualització costossísima de l'ERP, doncs la cosa fa por, molta por. Però encara hi ha més, tothom pareix estar d'acord amb que els ERPs són complexos, molt complexos, i amb això la linealitat del nombre de defectes per KLOC no es manté, sinó que creix de manera exponencial, i això malhauradament no afecta sols a les línies de codi de l'ERP sinó a les modificacions i adaptacions que se facin, que hereten aquesta complexitat. Què vol dir això? Doncs adaptacions més cares, més males de mantenir i depurar. Així que la cosa està clara, davant la opció de desenvolupar un conjunt d'aplicacions a mida per la nostra empresa o tirar d'un ERP hi ha que valorar no sols el cost d'implantació de cada solució, sinó els costs dels anys que vindran i com afectarà la implantació de l'ERP als nostres processos de negoci, ja que en lloc d'adaptar el programari al negoci haurem de fer les coses com l'ERP millor li vagi per gestionar-les. Respecte a l'arquitectura orientada a serveis (SOA) he de dir que sí que ho veig com a una manera de guanyar independència de distintes capes de programari i augmentar la reutilització de codi, en forma de programes. Si se fa bé, tendrem serveis petits, molt orientats a una tasca, controlables. Podrem controlar la complexitat de cada servei i mantenir la seva taxa d'errors molt baixa. Això implica no caure en la trampa que volen els fabricants d'ERPs actualment: tot serà un servei i ho podràs fer servir sempre que facis servir el nostre BPEL o el component X que te proporcionen. La idea és seguir-te tenint fermat. El serveis ens poden ajudar a anar independitzant capes de l'ERP i anar fent millores sense tenir que llevar tot l'ERP de cop. Per exemple, podem fer un mòdul de facturació en forma de servei que al final deixi les línees de facturació en la manera que les vol l'ERP de torn. Si feim una aplicació de facturació que faci servir el servei, estam aïllant-la de l'ERP i si demà decidim anar cap a un altra ERP lliure o cap a aplicacions sofisticades i separades el cost d'adaptació serà molt menor. Les empreses no necessiten que tot sigui un servei, necessiten que tot el que es pugui reutilitzar pugui ser un servei, i que els programadors puguin fer servir aquests serveix per anar montant les aplicacions. La metàfora del Tente no és aplicable, no es tracta de sols ajuntar peces, es tracta per una part de montar una arquitectura de serveis i aprofitar-la per crear aplicacions que aprofitin els serveis com si fossin llibreries, però això està molt lluny de joc d'anar encaixant peces. Particularment és una idea que cada cop m'agrada més, però entesa d'aquesta manera. Per exemple, amb Java i llibreries com XFire o Axis és prou senzill publicar serveis Soap, però els serveis interns no tenen per què ser precisament SOAP, podem tirar de protocols més lleugers com l'XML-RPC per exemple i fer-los servir per augmentar la velocitat de comunicació entre els serveis i la nostra aplicació. Aplicació, per cert, que no té perquè estar escrita en Java, la capa de presentació en Java, ja sigui Swing o web és feixuga i amb una velocitat de desenvolupament i instal·lació poc àgil. Podem tirar de llenguatges d'script per fer la capa de presentació i tenir el millor dels dos mons: la facilitat de creació d'interfícies d'usuari dels llenguatges d'script i la facilitat de crear serveis que tenen els bastiments de Java. Tot i això, no crec que a curt plaç els ERPs desapareguin, hi ha massa inversió feta. Seria el mateix que dir que els programes fets en COBOL desapareixeran d'aquí no res. Canviar un ERP és molt costós, i a més hem de tenir en compte que potser l'empresa encara està amortitzant la darrera actualització. [1] http://evora.mit.edu/smr/issue/2007/fall/01/ http://www.roughtype.com/archives/2007/08/erps_troubled_l.php

2 comentaris, 0 trackbacks (URL) , Tags: Informàtica


Software project survival guide

Escrit per Aaloy a 14 de August , 2007 a les 8:26 p.m.

Titol: Software project survival guide Autor: Steve McConnell Editorial: Microsoft Press ISBN-13: 978-1-57231-621-8 Pàgines: 288

Sofware project survival guide és un llibre damunt la gestió de projectes en general, no entra a explicar cap metodologia concreta, sinó que és un conjunt de consells i llistes de coses a comprovar en els projectes, però sense mullar-se ni anar al detall.

Al contrari d'altres llibres de McConnell he de dir que aquest no està a l'alçada, pareix més un llibre d'aquells que es fan per pagar factures i que s'aprofita de la fama dels que l'han precedit.

Tot i això he ha coses aprofitables: alguns "survival checks", una mena de llistat de coses a tenir en compte o a fer per dur endavant el projecte, i és un recordatori del cicle de vida d'un projecte.

L'estil tampoc és el que acostuma McConnell, molt més amè de llegir. Aquest m'ha costat acabar-ho, ja que li passaven per davant tots els altres llibres que he anat comprant aquesta temporada.

En el que fa a l'edició, el llibre té una edició amb una tipografia de cos dotze amb molt de marge per tot i amb un doble espai generós. Amb una altra tipus d'edició el llibre no passaria del centenar de pàgines.

En definitiva, si us ho regalen o el trobau de segona ma agafeu-lo, però no val la trentena d'euros que costà.

0 comentaris, 0 trackbacks (URL) , Tags: Gestió de projectes


Filtres de selecció de personal

Escrit per Aaloy a 13 de August , 2007 a les 10:12 p.m.

Trobar bona gent és difícil i trobar-la que a més es pugui integrar en un equip ja format encara ho és més. A les respostes d'anuncis de feina s'hi pot presentar molta gent i en poques preguntes sovint s'ha d'intentar esbrinar si la persona que tens al davant serà bona tècnicament i a la vegada la seva manera d'entendre la feina serà per l'estil de la que hi a al grup.

Encara que soni molt a tòpic hi ha una sèrie de regles heurístiques que quan parlam de programació web ajuden a fer-se una idea d'ambdues coses:

  • Adreça de correu amb domini propi : suma un punt. Per mi vol dir que al manco hi ha una preocupació per cercar-se la vida i potser haver donat d'alta un domini. Tenir un domini implica que també es pot cotorrejar abans de la selecció i veure quins temes preocupen al possible candidat o candidata.
  • Adreça de correu amb Hotmail: resta dos punts. Sovint també vol dir que estàs engantxa al messenger i/o que no ets capaç de diferenciar el tenir un correu per usos lúdics d'un per usos professionals. Serveix per a diferenciar la gent que el primer que intentarà fer és posar-se el Messenger.
  • Edició d'HTML. Si el sols es sap fer servir el Dreamweaver resta de cop 2 punts. Implica que d'entrada es tendran problemes quan es tracti de modificar planes webs fetes a troços, pràctica habitual en la programació web. Si utilitza un editor amb resaltat de sintaxi suma un, si a més sap fer servi el vi/vim suma dos punts. Si no ha fet mai una plana web resta cinc punts de cop.
  • Coneixements de CSS. Si ha maquetat pàgines amb CSS i sap perquè ho ha fet suma 2 punts. Si no sap perquè ho ha fet sols en suma un. Si no sap què és resta un punt. Tenir coneixements de CSS ajuda a saber el que es podrà fer en la pàgina.
  • Coneixements de Javascript. Si els sap fer servir mitjanament suma un punt, si a més coneix alguna llibreries de les típiques suma un altre punt. Si sols coneix el que posa el Dreamweaver lleva un punt. Tot es pot aprendre, però si un ja té experiència en Javascript vol dir que realment ha programat per la web. Si a més abans ha dit que utilitzava un editor "per programadors" començarà a agradar-me força.
  • Si sap què és l'arbre DOM suma un punt. Si no ho sap i ha dit que ha manejat força Javascript ens haurem de plantejar sèriament si ha està decorant el currículum.
  • Si sap què són els estàndards W3C suma un punt.
  • Si sap que és un sistema de control de versions suma un punt, si a més l'ha fet servir suma un punt més.
  • Utilitzar Linux suma dos punts. Per una part vol dir que encaixarà millor en el grup, però objectivament vol dir que serà capaç de modificar una plana que no està al servidor local, estarà acostumant a que els noms dels arxius són diferents en majúscules i en minúscules, sabrà què és l'UTF-8, etc. I sobretot demostra ganes de fer coses i de no conformar-se amb el que fa la gran majoria.
  • Utilitzar Firefox com a eina de desenvolupament. Suma un punt. En suma un altre si coneix dos plugins indispensables per al desenvolupament web.
  • Conèixer un llenguatge de programació d'script suma un punt. Si aquest es Python o Perl en suma un altra. PHP o Ruby no puntuen més. Un perquè a un que fa programació web se li suposa un mínim coneixement de PHP i Ruby perquè no es pot distingir de si es fa per moda o per convenciment.
  • Conèixer el patró MVC i saber-ho explicar suma un punt. El patró MVC s'ha convertit en omnipresent per la web i conèixer-lo i fer-ho servir indica que es una formació en programar pensant en la separació entre capes.
  • Conèixer SQL suma un punt. No fer-ho en resta un. No puc concebre que algú faci webs dinàmiques i no tengui idea d'SQL.
  • Conèixer els bastiments i llibreries utilitzades a l'empresa suma dos punts.
  • Ser membre actiu de Bulma o algun LUG suma un punt. Indica que el candidat s'implica en el que fa i contribueix amb les seves aportacions.

Hem de dir que d'entrada el possible candidat ha de conèixer el bàsic que se li demana, és a dir, si l'oferta és per programador Java-J2ee, si ja no es sap cap de les dues coses doncs el més probable és que el seu currículum ja no passi pel filtre de RRHH. Si ho fa llavors ens trobam davant un currículum que pot ser vàlid o estar especialment decorat per l'ocasió.

Un currículum amb una puntuació d'entre 17 i 20 és algú que s'ho paga entrevistar amb més profunditat. Entre 13 i 16 convé fer-hi una ullada però no hi ha massa possibilitats així d'entrada, i si és menys que aquest valor doncs potser és millor no perdre-hi més temps.

Tant les opcions com les valoracions són elegides ad-hoc sabent d'entrada el tipus de gent que m'agrada i que potser encaixarà bé en el grup, empreses i grups distints poden tenir valoracions distintes. Segurament una persona amb una puntuació de 20 no encaixarà en un ambient poc dinàmic i que no tengui capacitat d'innovació.

4 comentaris, 0 trackbacks (URL) , Tags: Informàtica Java Gestió de projectes


Canvi de hostingaire

Escrit per Aaloy a 07 de August , 2007 a les 8:01 p.m.

Bona part d'aquest diumenge passat Trespams i el seu correu associat no ha estat accessible i la cosa ha estat tan greu que ha requerit un canvi de hostingaire. Anteriorment aquest blog estava hostejat a un VPS de Bitfolk. La configuració de l'VPS era la mínima permesa i la relació qualitat preu no era dolenta. Un poc lent per a dur el Wordpress i el correu i caigudes de unes poques hores de tant en tant, però sense tenir que plantejar-se canviar a un altre servei. Diumenge però ens trobàrem que no es podia accedir al servidor. Al principi vàrem sospitar que era una caiguda com les altres i vaig reportar l'incidència. Però no, resulta que hi havia hagut un malentés en el pagament i ens havia tallat el servei. La reacció típica és un poc entre comprensió i indignació. Comprensió perquè si un no paga no pot esperar servei, però a la vegada indignació perquè si fins aleshores els pagaments han arribat sense problemes i el lloc està actiu doncs cabria pensar que el hostingaire demanaria abans de fer una cosa així. Res, que pagàrem la quota (del 6 juliol al 6 d'agost) i vàrem sol·licitar que es restablís el servei, amb la queixa de que "home això s'avisa!" en pitinglish. Idò no, ara per restablir el servei el senyor de Bitfolk diu que vol ara 3 mesos per avançat. Això en la meva terra se li diu xantatge asquerós. Li diem que perfecte, que com que ja hem pagat que ens restablesqui el servei i després ja discutirem el tema dels tres mesos, però que mentres el servidor ha de tornar a ser "viu". En el e-mail final el tipus ens diu que no està d'acord en que les coses es tenguin que fer així i que no ens vol com a clients i que no ens restaura el servei ni tan sols els dies que ens queden i que hem pagat (tard, això sí, però pagat). El més divertit de tot és que ens diu que per 8 lliures si ens pensam que paga a un enginyer el diumenge. Cony, vol dir que per aturar el servei no era també ell un "skilled engineer" fent feina el diumenge? I que es pensa que feim nosaltres? El seu temps és més valuós que el nostre? Després d'enrecordar-nos del bona part de la seva parentela, es va procedir a passar tot el que teníem a Bitfolk cap a un nou servidor VPS, a BudgetDedicated per més senyes. Una feinada, fonamentalment de Bernat,  però que gràcies  a les còpies de seguretat i a la rapidesa del servei de  Bugdget va fer que el canvi  fos molt més suau del que potser es pensava el  de Bitfolk. Bon vent i barca nova Bifolk! Per cert, el servidor és sols una mica més car, però va més del doble de ràpid.

2 comentaris, 0 trackbacks (URL) , Tags: Informàtica