Software Design and Architecture - Emiliano

 Al finalizar la lectura dos cosas me dejaron pensando. La primera siendo el contenido del articulo. El cual se puede resumir en las diferentes formas de definir arquitectura. Es muy cierto el hecho de que el termino arquitectura es algo tan vago pero que al mismo tiempo se utiliza en todos los lugares. Y lo peor es que en cada contexto se utiliza de manera distinta.  Como el autor menciona, la arquitectura cambia dependiendo la vista. Para el usuario no le importa los componentes o como esta el esquema de la base de datos. Al arquitecto le interesa la vista de las interfaces y las interacciones.  Y creo que llego al mejor resultado. La idea de que la arquitectura es un contrato social creo yo es una de las mejores definiciones que he escuchado. Y aun mas cuando se define que se incluyen los componentes que todos los involucrados en este contrato social entienden.  En mi experiencia laboral esa ultima parte es algo que completamente encaja. Cuando hablamos de arquite...

 I feel that architecture in most small projects is almost never seriously considered. And, to some extent, I can see why. Most time it takes a lot of effort, time and cost to set up an architecture when you are planning to do a small project with the intent to run it and forget about it.  Even in this situations the code is not excempt from bad techiniques, horrible and lengthy code or the need for extra effort to maintain, Maybe the impact will be lower or none at all, Simply because the fact that once you are donde, you are no longer going to add features, modify behaviour or else. And in this instances it can be considered okay to go with such naive aproach. That would be the case in a perfect world tho. As the text points out, rarely does the project avoid extra features, modification, or even the always present bug & glitch. And the irony of all is that even in those cases when you know for a fact that once the product is finished you wont ever touch it again, y...

  La historia de cómo el sistema de guía fue creado es impresionante, y aún más con las limitaciones tecnológicas de la época. Definitivamente causa una gran impresión en mí todo el proceso y también la perspectiva que tenían en ese entonces del desarrollo de software.  El hecho de que el software fuera un afterthought da una clara visión de que en ese entonces todavía estaba muy poco explorado la programación en sí. Y esto se puede ver reflejado cuando el troubleshooter the houston llegó y revisó el código.  Que hubiera código duplicado, lleno de bugs y consumiendo más memoria de la disponible demuestra que en ese entonces aún no existían buenas prácticas, planeación o principios de desarrollo de software.  El hecho de que con 70~Kb lograran hacer un programa para aterrizar en la luna es sorprendente. Incluso ahora me sorprende el nivel de optimización e ingenuidad que se requiere para lograr un programa con semejantes limitaciones.  Y más aún cuando vidas hum...

 ¿Qué espero del curso? Tener un mejor conocimiento de las mejor practicas a la hora de estructurar proyectos. Esto incluiría de ser posible desde como debe estar estructurado un programa (desde organizacion de carpetas, dependencias, servicios, etc) hasta como estructurar una solución, es decir que debemos tener en cuenta a la hora de incluir APIs, serverless functions, SQL y NoSQL, etc.   Mis hobbies e intereses personales Me gusta mucho los videojuegos (aparte de la programación). Los libros también es algo donde pierdo tiempo cuando puedo. Escuchar musica mientras trabajo es algo que ayuda mucho a concentrarme.  ¿Qué me ha atrapado últimamente? Si bien no es reciente, un libro que me gusta bastante es El nombre del viento, por Patrick Rothfuss. Ultimamente he estado empezando a introducirme al mundo de ML, aunque ha sido un reto ya que no logro encontrar buenos tutoriales para proyectos pequeños que quisiera realizar.