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.

La nova versió de BrightSide Dossiers porta el nou tipus de dossier: Projecte. Junt amb el nou tipus, els usuaris podran veure en l'apartat Dossiers del menú web, Els meus Projectes. El nou visor es composa de dos navegadors principals, categories i fases.

Novetats per a projectes

Quan s'indica que un dossier és un projecte, la fitxa de dossier canvia per mostrar les noves característiques de projecte. Apart d'un conjunt de camps, la més important és la fase de projecte. Aquesta substitueix l'estat del dossier en la barra d'eines i defineix un conjunt d'accions possibles en el visor web. Per exemple, mentre un projecte és una Idea o està a la Incubadora, els usuaris registrats poden demanar participar-hi. La forma de participació la aprèn d'altres participacions a projectes. En la fase de Concurs, els usuaris ofertants podran pujar ofertes directament al projecte.

Pel que fa a les participacions a projecte, els usuaris poden fer-ho usant els estàndard Beneficiari, Oferent o Coordinador. Els projectes també tenen la figura del Dinamitzador.

Pel que fa a les ofertes, són temes tipus Proposta usant la agrupació Oferta.

Els projectes poden configurar fàcilment les fitxes d'obertura i tancament per formar part del propi projecte, i no com document adjunt. Cadascuna de les fitxes pot tenir tants apartats com necessiti.

Novetats per a dossiers

Els dossiers en general es beneficien de les noves característiques de projectes. Per exemple, les agrupacions de temes són també vàlides per a dossiers. I les participacions d'usuaris amb discriminadors.

La configuració de descriptors per a crear fitxes de dossier són també una nova característica que els projectes porten al mòdul.

Conclusió

BrightSide Dossiers dóna un nou pas per aconseguir que la documentació de projectes estigui dins un mateix entorn, configurable, escalable i sota el control de l'usuari final.

"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.

Característiques del visor d'activitat

• El visor mostra l'activitat de l'usuari, no la del conjunt del sistema. Cada visitant veurà informació relativa als seus temes, incloent persones implicades.
• Les gràfiques tenen enllaços actius que porten directament a la base de coneixement i permeten veure el detall de l'activitat.
• Es mostren dades numèriques de participants, separades pel tipus de participació.

Dades segures, sensibles a qui les veu

BrightSide Dossiers, el mòdul que controla les dades de fons, manté en tot moment les dades mostrades dins els nivells de seguretat adequats a l'usuari. Es mostra allò que l'usuari pot veure, tant de temes com de persones amb les que ha mantingut alguna relació de feina.

Es manté també el nivell de permisos pel que fa a facilitar l'accés al nucli de l'aplicació.

Nova característica estàndard, out-of-the-box

La funcionalitat proporcionada pel visor d'activitat és una característica dels nous BaaS. Els usuaris de BaaS donaran la mateixa funcionalitat als seus clients, proveïdors i col·laboradors.

Des de les primeres versions de la interfície web per a temes, es va buscar facilitar la funcionalitat, amagant totes aquelles opcions complexes que portaven als usuaris primerencs a dubtar davant els formularis.

Un dels exemples d'aquesta simplificació és la manera en que es resolen les feines. De les múltiples opcions possibles s'escullen només dues: Solucionat i No es soluciona.

Segons les bones pràctiques per a temes, tal i com es descriu a Inici i final d'un tema, el correcte seria que el responsable resolgui i deixi a l'informant la responsabilitat de tancar el tema, un cop comprovat que està realment resolt.

La suma de simplificacions aplicada als formularis web per a temes, fa que els temes quedin tancats immediatament després de ser resolts. Una de les coses que s'aconsegueix amb aquesta simplificació és que el tema en qüestió desapareix d'els meus temes. L'informant rep el correu indicant que el tema s'ha resolt i cap nova acció es requerida. Molt fàcil, però...

Les comprovacions no són sempre possibles al moment

Una incidència pot estar resolta pel responsable, però qui l'ha reportat podria no tenir manera, o temps, d'executar la comprovació. Què ha de fer doncs? Guardar el correu notificant la resolució fins tenir temps de comprovar-ho?

Pendent de revisió

BS Dossiers afegeix un nou estat a la participació dins un tema. No és un estat del propi tema, sinó que afecta només als informants. La lògica que segueix és la següent: Quan un participant que no és l'informant tanca un tema, s'activa l'estat pendent de revisió per a l'informant del tema. Els usuaris amb temes pendents de revisió, veuran l'avís en el visor d'activitat Elephant per a BS Dossiers. Un tema pendent de revisió té una nova acció possible, Arxivar. Arxivar un tema pendent de revisió és, simplement, deixar de tenir-lo pendent, haver-lo revisat. Sense necessitat de estar guardant el correu de notificació.