Vermutech #15

Aquesta setmana, a nivell laboral, hem vist la llum amb un projecte en què s’hi ha estat treballant durant un temps, i finalment el començarem a desplegar a totes les instàncies. Es tracta d’un bessó digital d’una xarxa elèctrica. A GISCE-TI treballem amb solucions per al sector elèctric, i el bessó digital era una evolució natural dins del nostre GIS.

D’aquí poc arriba l’octubre, i amb ell el Hacktoberfest i la Festa Open Source de Girona, que forma part de l’esdeveniment de la Catosfera. Pots aconseguir entrades gratuïtes!

Començo amb algunes recomanacions,

💾 Programari

• Btop: Continuem amb recomanacions de terminal. És com l’htop però amb més funcionalitats. Desde fa molt temps, htop és el meu monitor per defecte, i no hi ha servidor que no el tingui instal·lat… Però qui sap, potser a partir d’ara serà el btop 😊.

🤔 Curiositats

• Tetris sobre SQL: Sí, sí, tal com ho llegeixes. Amb aquest repositori trobaràs les instruccions per jugar a Tetris al propi PostgreSQL.

📦 Recursos

• UUIDs: Els Universally Unique Identifier (UUID) es fan servir molt sovint quan desenvolupem, però moltes vegades només utilitzem una única versió d'aquests. A aquesta web trobaràs les diferents versions i quan has d’aplicar cada versió.

🌟 El concepte

Per aquest número #15, explico el concepte de "Deute tecnològic", i en comptes de veure'l com un problema te’l vull presentar com una eina que, si s’utilitza amb coneixement, et permet avançar molt ràpidament en el desenvolupament d’un projecte tecnològic.

Sovint es percep de manera negativa, ja que implica prendre decisions tècniques que s’hauran de "retornar" en el futur mitjançant refactoring o millores estructurals. Però el deute tecnològic també pot ser una estratègia per obtenir avantatges competitius en un mercat en què arribar a temps és crucial. Optar per no eliminar certes complexitats de seguida et permet accelerar el desenvolupament i posicionar-te ràpidament, sempre sabent que caldrà resoldre-ho més endavant.

És important entendre que no tot el deute tecnològic és dolent, però cal decidir amb cura en quins aspectes es vol assumir. Les parts crítiques, com les proves (Test-Driven Development, en vaig parlar al número #13) i la cobertura de codi (en vaig parlar al número #14), no s’haurien de comprometre. Si aquestes estan ben resoltes, es poden assumir riscos controlats en altres àrees del sistema, perquè en el futur, eines com el refactoring (en vaig parlar al número #12) i el TDD ens permetran retornar aquest deute tecnològic de manera ràpida i segura.

💖 Feedback

Si t’ha agradat i em vols ajudar, fes arribar aquest contingut a qui creguis que li pot interessar, i entra al canal de Telegram per comentar la publicació.