Després de tres anys pagant a la Hisenda Catalana, usant el mètode de Sobirania Fiscal ideat per Catalunya Diu Prou (Ara o Mai), aquest any el meu gestor em diu que, amb les festes de Setmana Santa, s'ha fet impossible pagar abans del dia 15, així que liquidarà a la Hacienda. Ja sé que reben els diners igualment, però que voleu que us digui, em va entrar mal de panxa.

Canvis per a no canviar

A principis d'any, Montoro anunciava que a partir de l'u de juliol hi hauria canvis en la manera com es liquida l'IVA trimestralment. No se n'ha sentit res més des de llavors, per tant tot quedarà igual. Sembla que liquidar, el que és liquidar, ens liquidaran igual.

Sí canviarà com declaren l'IVA les grans empreses (més de sis milions l'any), els grups d'IVA i els inscrits en el Registre de Devolució Mensual de l'IVA. El sistema ideat per la Hacienda es diu Suministro Inmediato de Información, escurçant SII. Aquest SII de la Hacienda permetrà que els afectats deixin de presentar alguns models, com el resum anual d'IVA (390), per exemple. Per tal de gaudir d'aquests avantatges, queden en mans dels implantadors de sistemes informàtics necessaris per poder subministrar immediatament informació.

A tot l'estat, hauran d'usar obligatòriament el SII uns seixanta-tres-mil contribuents, que representen un vuitanta percent de la facturació empresarial.

Posant-ho fàcil?

Mireu, em peto de riure quan a la pàgina de la Agència Tributària Espanyola anuncien el sistema com una renovació necessària després de trenta anys usant l'anterior sistema. Calia facilitar els tràmits. Facilitar què? I a qui? Per donar-vos una idea: si vols connectar amb la Agència Tributària cal que ho facis usant un client Web Service amb el protocol SOAP. Tranquil, vol dir Simple Object Access Protocol. Així encara semblaràs més simple si no connectes.

Som al 2017 i qualsevol empresari pot moure milers d'euros entre comptes bancaris sense cap problema. Però el mateix empresari segueix no podent comunicar amb Hacienda sense vendre's l'ànima al diable.

A tot això, ve la independència

Per l'u de juliol, Oriol Junqueras va anunciar la posta en marxa de la Hisenda Catalana. Ja sabeu, aquelles coses que quan les diuen se't posa pell de gallina i t'estimes un piló per ser tan collonut i tan català.

Ara seriosament, heu rebut cap notificació respecte el que s'ha de fer? Tindrem un gran cartell que posi Hisenda Catalana mentre declarem a Hacienda usant el SII?

Es parla molt de ser rigorós i de fer les coses bé.

Llavors, per què anem de bòlit?

Hi ha dies que seria millor esborrar-los. Avui n'ha estat un. Un dels clouds que utilitzo ha fallat al actualitzar dels repositoris estàndard. El resultat és un cloud mort. Una nit de rescue mode. Una visita personalitzada a cadascun dels paquets que es proposava instal·lar.

Quan el que no pot fallar, falla

Les actualitzacions des de repositoris es fan executant transaccions. Si una transacció s'acaba amb èxit, la operació es dóna per bona. Sinó, la operació es cancel·la. Li diem atomicitat i fa que el mon sigui un pèl més segur.

Però, què passa quan, malintencionadament, s'informa malament al sistema que executa transaccions? En principi, les regles entre elements d'un sistema les controla el propi sistema, així que, per poder informar malament cal trobar abans una errada. Per exemple, un paquet no informa correctament de les seves dependències. Sigui quin sigui l'exemple, no és fàcil, però és possible. Si aconsegueix infiltrar-se pot acabar executant una operació que no permetrà reiniciar el sistema que controla la transacció. Fallarà.

L'algorisme de xifrat SHA1

Fa un temps, els bancs avisaven que substituïen l'algorisme SHA1 pel SHA256 en les connexions als TPV virtuals. Això no és estrany, és normal fer millores. Potser no és tan normal que les millores siguin substitucions sense compatibilitat descendent, i que s'avisi amb un termini molt curt. Perquè així va ser, l'avís va venir acompanyar d'un ultimàtum: ha d'estar tot abans de dia D.

Això va ser el 2016. El 2017 llegim que Google a trencat el SHA1.

El 2015 es sabia que el SHA1 podria trencar-se en el període d'un any. Que això vagi lligat al canvi precipitat dels bancs, a les "caigudes" dels sistemes S3 d'Amazon i el Google Cloud, no seria d'estranyar.

Aprofitar una caiguda per refer tot allò que no és ja segur del teu sistema acaba sent una excusa perfecte. "El sistema ha caigut, però ja l'hem refet i funciona de nou amb millores". "Oh, gràcies!". És millor això que dir "Sabíem que no era segur, ara ja ho és".

I?

Potser us semblarà que estic lligant amb pinces coses molt diferents. No pas. Estan molt lligades. Els forats de seguretat en grans sistemes, són també grans, obvis i es poden detectar amb més facilitat. Cert que poden ser més catastròfics, però per això són redundants i tenen còpies de seguretat.

Però que passa amb els forats de seguretat en sistemes petits, no tan evidents i amb poc manteniment. El temps de resposta és molt més lent i conviuen amb problemes coneguts durant un període més llarg. Són el riu on les males intencions es treuen la set.

Cal patir?

Moderadament, però sí.

Voldria recordar que per declarar els nostres tributs, fins fa poc utilitzàvem un sistema completament insegur. És més, les instruccions per executar-lo obligaven a despullar de tota seguretat el navegador d'Internet. El problema és lluny de la solució. Encara es continua enviant instruccions a usuaris finals amb coses com "Allà on diu 'Aquest lloc no es de confiança', premeu 'Continuar igualment'".

Quantes vegades mireu els permisos que requereix una aplicació de mòbil? Quantes vegades us heu preguntat perquè necessita tal permís tal aplicació? És el desgranatge de permisos adequat a les particularitats dels programes? La càmera del mòbil no té pilot per mostrar quan és activa, sabeu quantes aplicacions tenen accés a la càmera?

Potser després d'una nit com la d'avui no és bo escriure res, però ara tampoc em posaré a dormir, oi?

Els grans ja han reaccionat al SHA1. Els petits trigaran més. És la cinquena onada.

"Marco l'arxiu com compartit, els usuaris reben la notificació i podem començar a treballar. Però quan passa un temps, ja ningú troba res. És com si desaparegués la informació. Amés, mai està ordenat."

La sensació de desordre en arxius compartits

Els arxius compartits un a un, s'acumulen dins una carpeta del Drive anomenada Compartit amb mi. Una bona pràctica seria moure aquests arxius a l'estructura de directoris que tinguem creada. Això es pot fer sense por a crear duplicats, l'acció crea un enllaç a l'arxiu original. Tot i ser una bona pràctica, obliga a qui rep la notificació a entrar al Drive i posar-hi ordre. Quan la quantitat d'arxius a compartir és alta, no és una bona solució. Un altre efecte secundari de compartir arxius un a un i ordenar-los tan punt arriben, és que el directori on finalment s'ordenen no serà el mateix per a tots els usuaris. Quan es vulguin referir a un arxiu concret per la seva trajectòria, no podran.

Les carpetes compartides van també a parar a la carpeta Compartit amb mi. Hi van amb tota l'estructura que tingui creada i tots els arxius guardats. Les carpetes compartides també es poden moure a l'estructura pròpia, sense por a crear duplicats. Un avantatge de les carpetes compartides és que la ordenació que contenen és visible a tots els usuaris amb qui es comparteix. Qualsevol canvi d'estructura serà visible a tots. Qualsevol arxiu afegit, sigui quin sigui el propietari, serà visible en el punt on s'hagi afegit. Per a tothom igual.

Un desavantatge de les carpetes compartides, és que les notificacions de canvis funcionen molt diferent. Pot haver-hi activitat i no assabentar-nos de res. Per evitar això, el Drive disposa d'un icona de informació que obre una llista d'activitat. La llista mostra canvis, insercions, esborrats. Un resum de què s'ha fet i qui ho ha fet.

Resumint

Quan compartir arxius un a un

• Quan els arxius sobre els que es treballa són poca quantitat.
• Quan tenen un protocol d'inici i final clars.
• Quan el propietari deixa de compartir un cop assolit el final.
• Quan es fa un canvi de propietari, creador a receptor, i es deixa de compartir.

Quan compartir en carpetes

• Quan hi ha molta quantitat d'arxius.
• Quan és un grup de treball, més de dos.
• Quan l'ordre, directoris, sigui important.

Tinc que deixar de compartir un a un si comparteixo carpetes?

No, de fet, és una bona idea. Compartir arxius que ja són dins carpetes compartides. Es gaudeix de les avantatges de les notificacions, i l'arxiu queda ordenat. L'únic desavantatge és que la carpeta Compartit amb mi s'omple i no queda constància de si l'arxiu ja és dins una carpeta compartida.

Va bé saber...

• Els arxius tenen propietari, que és qui finalment pot decidir quan deixar de compartir un arxiu.
• Quan s'esborra un arxiu que han compartit amb tu, únicament deixa d'estar compartit amb la persona que l'ha esborrat.
• Quan s'esborra un arxiu dins una carpeta que han compartit amb tu, amb permís de modificar, l'arxiu s'esborra realment.
• La paperera que rep els documents esborrats és la del propietari de l'arxiu.
• Quan comparteixes un arxiu, aquest va a parar a una carpeta, ordenada per data, anomenada Compartit amb mi.
• Quan mous un arxiu de la carpeta Compartit amb mi a la estructura de carpetes del teu Drive, no es duplica l'arxiu, simplement es crea un enllaç a l'arxiu original.

En un malson (no pregunteu perquè ho recordo) sóc dins una classe. Sona música celestial i entra la professora. Em somriu. No puc més que pensar que la felicitat existeix i que els àngels tenen gènere.

Per millorar encara més les coses, a la taula hi trobo una tablet. Però quan vaig per agafar-la, tot pensant en impressionar, una ma més ràpida l'arreplega. "Vols jugar o aprendre?"

Enlloc de deixar-ho, allargo la ma per recuperar el dispositiu i mostrar què pensava fer, però em surt un gest matusser, brusc, i m'acaba comportant l'expulsió de classe.

Tossut encara, intento entrar i explicar-me, però el somriure de cortesia ja no hi és i prenc consciència de no haver après res per estar massa embadalit. "Fora! Expulsat!"

Tot intent de corregir-ho es capgira. Veig la porta, hi camino, però cada cop és més lluny.

"Va... desperta!"

El primer cop que vam obrir el codi va ser el 2002. En aquell moment Blai Capdevila i jo mateix ens barallàvem per trobar una solució a la comptabilitat sense assentaments. Comptabilitat documental basada en models. El projecte es deia XMLVocabulary, s'allotjava al domini xmlportal.net i va assolir la mitjana de 30 mil descàrregues mensuals. Mentre ens deixàvem els ulls en la creació de models, a altres llocs del mon desenvolupadors trobaven utilitats ben diferents a allò que estàvem fent. Una de les sorpreses més grans va ser quan una empresa de telecomunicacions a Taiwan va començar a usar el codi dins el seu seguiment d'incidències, afegint suport LDAP, i passant-nos el resultat traduït al xinés. Aquell dia no vaig dormir.

Entenent el risc, acceptant la ignorància

Tinc que dir que sóc poc ortodox. La metodologia utilitzada en aquells moments per vendre desenvolupament de software em semblava escandalosa, poc responsable i gens productiva. Encara ara hi ha gent que continua fent el mateix. I segueixo escandalitzant-me. Primer, no sempre s'entrega el codi. Segon, se li demana al usuari que accepti el disseny de formularis on breument es descriu la operativa. Tercer, es comença el desenvolupament pels formularis. Els supòsits de semblant metodologia són, que l'analista ha entès perfectament què vol el client i que aquest ha sabut explicar què vol a la perfecció. Es comença per la taulada perquè es suposa una bona fonamentació. Això no és cert, mai pot ser-ho.

El desenvolupament de software no s'hauria de vendre, simplement perquè comprar-lo és una ruïna. Entenem-nos, comprar el desenvolupament d'una solució completa no és recomanable. Desenvolupar és una inversió, no una despesa. Desenvolupar és car i no sempre surt bé. Segons les noves tendències, el software està en una constant fase beta on cada incidència és tractada amb màxima cura. El software està en constant millora, s'adapta i creix.

En casos reals, quan es decideix iniciar un nou projecte, l'anàlisi i el desenvolupament són només una part del tramat. Cal la plena implicació de l'usuari avançat. Aquell que entén quin és l'objectiu i és capaç de trobar on falla. I tot mitjançant l'ús, sense tocar el codi. Reportant cada incidència amb tots els detalls i donant idees. L'èxit d'un projecte es mesura en la quantitat d'usuaris avançats que reporten incidències i en la rapidesa en que es desenvolupen les solucions. L'usuari coneix i el desenvolupador realitza. L'analista catalitza el procés.

Particularitats, camins al no res

Fa més de deu anys que no desenvolupo codi que no vagi al tronc principal de Elephant i BrightSide. Això vol dir que tots els usuaris usen el mateix tronc. Ja ho dic ara, les dues aplicacions tenen usuaris ben diversos, des d'autònoms a petites i mitjanes empreses. L'ús que en fan és també molt divers. Què passa doncs amb les particularitats?

Quan un usuari demana una particularitat, allò que no serà útil a ningú més, el primer que faig és intentar eliminar-la. Dràstic? No pas. Iniciar una branca de codi per una particularitat només pot acabar malament. Per una banda, la resta de mòduls creix ignorant-la i podem acabar amb una incompatibilitat. Per altre banda, al no estar en el tronc principal, no es millora ni creix al mateix ritme. Amés, eliminar-la no sempre vol dir no fer-la. També pot dir tornar-la genèrica, es a dir, afegir-la al tronc principal i deixar que la resta d'usuaris en gaudeixi.

Tornar una particularitat en una característica general és un mal de cap. Primer cal barallar-se amb els conceptes, de particulars per una funcionalitat concreta a generals per tot. Després cal, per això és genèric, més configuració. El resultat, però, és més funcionalitat pel conjunt. Tothom hi guanya.

Quan és impossible la transformació a genèric cal provar a incorporar-ho sense que es noti. La via més ràpida són les factories de classes o funcionalitat afegida. Reconeixes una interfície però no saps qui la implementa. Un cop fet el reconeixement, implementes la interfície com un mòdul endollable.

Si finalment cap de les solucions anteriors és possible, crees la versió especial per aquella particularitat, sabent que tard o d'hora es transformarà en un malson.

Publicant el coneixement

El programari obert és coneixement aplicat. Al codi s'hi suma tot el que sap l'usuari avançat. La qualitat dependrà de la maduresa del projecte, dels coneixements de les eines que tingui el desenvolupador i del coneixement de l'objectiu que es pretenia assolir per part de l'usuari. El programari obert estalvia feina a tercers i permet integrar projectes. Això afavoreix la col·laboració i resulta en una millora pels elements integrats, converteix projectes sencers en usuaris avançats reportant incidències.

A cadascú el que li toca

Haureu notat que li dono especial importància a l'usuari avançat. Bé, encara pot tenir-ne més, normalment és així.

Els casos pràctics m'han ensenyat que sense un usuari que estigui disposat a implementar el projecte en el mon real, aquest no té masses possibilitats d'èxit. Disposició per anar provant en la mesura que es va fent, en els punts on s'aconsegueixen fites. Això vol dir temps, paciència i molta implicació. Com sigui, crec que cal donar-los el reconeixement que mereixen i traduir-ho en compensacions.

La millora constant afavoreix compensar la dedicació dels usuaris avançats d'una manera ben fàcil: gaudint de les millores que ells mateixos han proposat, més d'aquelles que hagin proposat d'altres. La Fundació TiC rep les contribucions de Turro.Org i les publica sense cap cost, en un intent de convertir el teixit empresarial català en un usuari avançat. Queda molt per fer, però ja hem començat.