Entradas

4+1= modelo de arquitectura de software

 A lo largo de la clase vimos diferentes temas que abarcaban desde las razones que hacían un buen diseño; cómo y por qué se tenía que diseñar; si éste aún estaba presente en la, tan cambiante, realidad posmoderna; los problemas a los que se enfrentan los profesionales actuales relacionados a esta temática así como las soluciones que se han planteado en la industria para sobrellevarlos. Sin embargo, lo que más vimos y pusimos en práctica fueron modelos, patrones o estructuras ya definidas que dan pie a una arquitectura de software. En esta última entrega, esto no fue diferente pues, se nos presentó como alumnado, y próximos ingenieros de software, el modelo 4 + 1,  el cual, a opinión personal es el más creativo pero el más asertivo en establecer las razones intrínsecas de la labor de diseñar.  Durante el video The 4 1 Model, se da, como es de esperarse, la introducción formal al tema. Se describe claramente cómo y de qué está formado, así como las características de cada una de estas en
Publicar un comentario
Leer más

SOLID Princples

Uno de los conceptos que más he logrado escuchar a lo largo de mi camino como Ingeniero de software -que quiero aclarar que no es mucho puesto que aún no me convierto oficialmente en uno- es el de los principios SOLID y el impacto que estos tienen al momento de planificar, crear y mantener tanto productos digitales como corporaciones y hasta industrias completas. En el texto Understanding the SOLID principles  por Edward Guiness resumido en la página del profesor, Ariel Ortiz, el lector es introducido a este acrónimo por medio de un resumen de cada uno de los principios que lo conforman: S ingle Responsability Principle: una clase solamente debería de tener una y solo una responsabilidad. Es decir, hará un solo trabajo dentro del código. Haciendo así, que, entonces, sea más sencillo modificar un solo comportamiento no anidado.  O pen/Closed Principle: un componente se abre para ser extendido pero es cerrado para ser modificado. Es decir, una entidad puede permitirse evolucionar siempre
Publicar un comentario
Leer más

Los microservicios

¿Cómo sé, como profesional en tecnología, que estamos viviendo en la posmodernidad líquida? Simple, ahora desarrollamos con microservicios. Suena un tanto alarmista y, hasta negativo el hecho de asociar a los dos términos que acabo de mencionar, sin embargo, esto es totalmente ajeno a lo que quiero dar a entender pues, por una causalidad u otra, este hecho trae para nosotros, ingenieros de software , mayores ventajas que desventajas.  James Lewis, en su texto Microservices  presenta la visión revolucionaria de cómo es que este acercamiento o metodología de crear productos digitales ha transformado la industria y ha permitido a gigantes de la misma llegar a donde están en la actualidad. A lo largo de su texto se nos comenta que, la principal ventaja que éste enfoque trae consigo es la poca, pero no ausente, relación entre funcionalidades de un programa. Es decir, no es que no exista relación entre características del sistema, al contrario, es más importante la aclaración y definición de
Publicar un comentario
Leer más

Talentos ocultos por nuestra cultura

¿Qué pasa cuando se discrimina a una persona por uno o hasta una combinación de los siguientes factores: género, orientación sexual, etnicidad -esto porque el término raza en el más puro sentido filosófico y antropológico está mal empleado en nuestra cultura moderna pero esa es una discusión para otro día- , religión, condición económica y un gran etcétera? Así es, nada. O al menos, según lo que la propaganda contemporánea quiere vender, es lo que pasaba durante el siglo XX y no es como que actualmente aún veamos problemas de este tipo.... En fin, hago esta larga, pero a su vez breve interrogante para hablar del principal tema que no solamente funge como un excelente motor para el desarrollo del drama Hidden Figures, sino que también pone en evidencia la hipocresía y el horror que la ideología puede ocasionar en la sociedad: el racismo.  El racismo, si bien se tiende a relacionar directamente con cuestiones puramente étnicas, es un término que engloba las causalidades de las muchas inj
Publicar un comentario
Leer más

El diseño murió... ¿o no?

Creo que como profesionales dedicados y encarrilados dentro de la creciente industria de la economía digital, estamos acostumbrados a las críticas, a las tan consideradas buenas prácticas, así como al rechazo a las malas. Somos voceros de la multitud, seguidores y creadores de tendencias pero, sobre todo, somos tan humanamente humanos que llevamos nuestra esencia biológica y, en cierto modo, filosófico a nuestra profesión de una manera tan íntima y clara que deja hasta pobre cualquier otra profesión del impacto, popularidad y útil -esto bajo los términos económicos modernos-  como la nuestra. Aunando en lo anterior, el escrito Is Design Dead? de Martin Fowler ejemplifica de manera perfecta todo este palabrerío al exponer la subjetividad más objetiva: ¿Cómo no solo se diseña un buen pedazo de software, sino por qué y bajo qué criterio está bien diseñado? Era el año 2004 cuando éste se creó y, a modo personal, opino que esto sigue pasando y más que nunca.  El punto focal de toda la discu
Publicar un comentario
Leer más

Las corporaciones necesitan de arquitectos más que el software

Desde que entré a esta clase y, en general, desde que tengo la noción de que existe una rama del desarrollo de software titulado Arquitecto de software,  me he preguntado sobre el por qué dicho término existe y, más importante aún, ¿Qué es lo que hacen y por qué sus conocimientos son tan requeridos pero tan subestimados? En mi última publicación, mencionaba que un término como el que nos reúne semana a semana en este blog es difícil de definir y hasta de comprender en su totalidad debido a que, como sucede en cualquier disciplina, requiere de mucho esfuerzo, trabajo y recursos el lograr estandarizar términos cuando dichos conceptos se están construyendo y hasta siendo utilizados sobre la marcha.  La historia del software, como hemos visto durante nuestra carrera, es única en cuánto a su documentación y normalización se refiere pues, dado a su amplia diversidad de contextos de uso, los empleos que se han creado se han pensado que pueden y deben ser entendidos y aplicados por todos los d
Publicar un comentario
Leer más

Todos somos arquitectos de software... en teoría.

Al terminar de leer el capítulo 14 ( Software Architecture ) del libro Code Craft escrito por Peter Goodliffe, me surgió el cuestionamiento: ¿Realmente conocemos de arquitectura de software? digo, todo el contenido descrito por el autor como: componentes, diseño, comunicación, interfaces, entre muchos otros, realmente son conocimientos que, de una u otra forma, hemos visto hasta el hartazgo en la carrera. Pero, aún así: ¿Por qué es necesario el repaso? regreso a mi pregunta inicial: ¿Realmente conocemos de arquitectura de software?  Resulta increíble el pensar que muchas veces como estudiantes y, aún peor, como profesionales primerizos pequemos de subestimar la arquitectura de sistemas y englobarla en términos como: documentación, diagramas, requerimientos de negocio - como nota, he de admitir que estos conceptos no tienen nada que ver con lo que es la arquitectura de software si se piensan por separado, pero justo demuestra mi punto referente a nuestra, tal vez justificada, ignoranci
Publicar un comentario
Leer más