duck-case

Hoy no me apetece escribir así que hice unos dibujos hice mi mejor esfuerzo  acerca de por qué UML es importante, ¿qué, no te gusta? Allá tu, si están preciosos.

via GIPHY Ya sabemos algunas cosas sobre los principios Orientados a Objetos... ¿Ya estoy listo para poner en mi biografía de Twitter que soy un dev? Para nada. Lo que sabes gracias a que has leído 4 capítulos dista mucho de lo que aprenderías si lo llevaras a la práctica y este capítulo te lo demostrará. En este capítulo se revisitó el código creado en el capítulo 1, sí, el software para vender guitarras de Rick, él quiere, según él, un "pequeño" cambio que al final resulta ser todo menos pequeño. Sin más, vamos allá. UML sigue siendo cool Lo primero que salta a la vista en el capítulo es que ya vamos a hacer un poco más formales y vamos a usar diagramas UML para todo pues buena parte del capítulo anterior se trató de este tipo de representaciones. La primera simbología nueva que se nos presenta en la lectura son unas flechas extrañas que tienen punta en forma de triángulo: De  Serna, M.  - Transferred from  ResearchGate , Dominio público,  Enlace Sí, esa qu

¿Cuántas veces más te tenemos que decir que debes de dejar de querer reinventar una rueda? Bueno, no importa, te diremos que no lo hagas las veces que sean necesarias hasta que lo entiendas, ya lo hemos hecho con los ciclos de vida del software y hoy toca el turno a un tema especial: los patrones de diseño. Los patrones de diseño son unos de los temas de los que ya deberías de haber oído hablar pero si esto no ha pasado no te preocupes, de nuevo te salvaremos el semestre. Sin más, comencemos. Ya hemos pasado por ahí via GIPHY Sí, ya sabemos que sentirse único es lo de hoy, sobre todo cuando tu código compila después de 3 días sin poder dormir, te sientes el nuevo Alan Turing y estás listo para ser reconocido a nivel mundial por tu contribución a la Ciencia Computacional, pero... Mira, no me gusta pararle las cabras a las personas pero a ver... Revisemos un poco... Sí, tu problema ya lo había solucionado alguien. Y lo hizo mejor que tú al parecer. No te angusties, eso pasa tod

via GIPHY El Mundo Real ™  siempre tiene algo preparado para nosotros y la mayor parte del tiempo no son cosas positivas. Si queremos triunfar en él tenemos que estar dispuestos a sortear todas las eventualidad que nos vayan surgiendo y pasa exactamente lo mismo cuando estamos escribiendo software. Cuando comenzamos a programar nuestro primer hello world.(inserte cualquier extensión aquí) programar parece un juego de niños: darle instrucciones a la computadora y que esta las ejecute. Pero... ¿Qué pasa cuando nuestro software va más allá de sólo imprimir un mensaje en pantalla? Bien, sigue leyendo y vamos a descubrirlo juntos. Analizando ando via GIPHY Mientras estamos añadiendo las primeras funcionalidades a nuestros proyectos siempre solemos pensar en un mundo perfecto, un mundo en dónde todas las personas usarán nuestro software precisamente para lo que fue creado y nada se saldrá de control, pero he aquí tu primero error: el mundo real es cruel, muy cruel. Las

¿Quieren monólegueeeeeee? Bien, me descubriste. Sí, me quedé sin ideas para iniciar una entrada y tuve que recurrir a una frase de un programa mexicano de los 2000's, lo acepto, pero ese no es el punto de esta entrada. Hoy vamos a hablar de unos de esos temas que con tan sólo leer el título sabemos que no será algo fácil de digerir pero me sorprendió lo sencillo que fue asimilar este concepto y si estás pensando que vas a tener que aprender otro lenguaje de programación para aprender un lenguaje de modelado, déjame decirte que no tienes ni idea. Venga, ya capté tu atención, sigue leyendo. Lenguaception via GIPHY Un lenguaje que no es un lenguaje, a que suena a una frase de la película El Origen, ¿verdad? Un lenguaje de modelado no es uno a los que estamos acostumbrados, no, no es de esos fuertemente tipificados que odias cuando nada de compila a las 3:00 A.M., sino que más bien es una serie de normas y estándares acerca de cómo se debería debería hacer una buena rep

En la entrada de hoy cambiaré la forma en la que analizamos el contenido de un tema y tomaré una posición más activa sobre todo en el momento de digerir la información presentada en la fuente que se nos designe para ello. ¿Qué toca hoy? Bueno, hoy vamos a analizar en artículo llamado The Cathedral and the Bazaar  y, entre otras cosas, el artículo busca que el lector reflexione acerca de dos estilos de programación opuestos: el modelo catedral y el modelo bazar. Sin embargo, llega a un punto en el que el artículo deja de ser puramente informativo pues pasa a intentarnos vender la moto y comienza a argumentar a favor del modelo bazar. ¿En qué acabará todo esto? Ni yo lo sé, venga, vamos a descubrirlo. via GIPHY Lo importante El artículo comienza dándonos una breve introducción a lo que posteriormente se le denominará modelo bazar, un modelo de desarrollo que tiene como parte fundamental a los usuarios y a las liberaciones rápidas de versiones, un modelo que se retroaliment

Así es, en tiempo récord leí todo el texto A Case of Study: The 8 Queens Puzzle  y debo de decir que fue una pasada pues me recordó aquellos tiempos en los que tenía que leer un algoritmo tras otro y entenderlo en tiempo récord. Para escribir el programa se utilizó la versión 7 de Pharo así que aquí están los resultados. via GIPHY 8 Queen Puzzle en GitHub Y a continuación las respuestas a las preguntas 1, 2 y 3: 1. La modificación que se tendría que hacer es:     Iniciar en la columna más a la izquierda     Si todas las reinas ya están puestas parar la ejecución y devolver true     Probar y hacer un seguimiento con todas las filas de la columna actual. Si la reina puede ponerse en esta fila marcarla como parte de una solución recursivamente revisar si el poner la reina en ese lugar conduce a una solución. Si el poner la reina en ese lugar conduce a una solución regresar true. Si el poner la reina no conduce a una solución marcar esta como una no solución y probar

Usos de casos, casos de uso... Hoy vamos de un tema súper importantísimo y más vale que lo comiences a tener claro pues no le hemos dedicado 3 entradas para que lo olvides así como así, así que aquí vamos de nuevo. Casos de uso, otra vez. Un caso de uso es la descripción de una acción o actividad. Un diagramaasaaaaaa te asustaste, no, no vamos a copiar el artículo de Wikipedia , lo intentaremos hacer un poco más ameno. via GIPHY Casos de uso (rematch x3) Los casos de uso fueron inventados por Ivar Jacobson en 1986 y lo petaron gracias a que en ese entonces el UML era lo máximo para el desarrollo de software, sin embargo, hoy en día contamos con muchos modelos, cada uno con sus características bien definidas, y estas herramientas siguen formando parte de muchos de estos modelos, ¿por qué? Bueno, quizá su magia radica en que son extremadamente útiles e intuitivos cuando estamos intentando resolver un problema y a continuación te diremos con un poco más de detalle de qué van.

Bien, ya hemos terminado nuestra aplicación y esta funciona más que bien... ¿Ya somos los mejores programadores del mundo? ¡Pero claro que no! Si apenas es que hemos empezado. Hoy vamos a tocar uno de los temas que a muchos desarrolladores me incluyo no nos agrada mucho pues usualmente conlleva aún más quebraderos de cabeza que el iniciar un proyecto: el cambio. No, no estamos hablando del típico cambio que nos ofrecen los políticos en cada periodo electoral, estamos hablando de cambios en nuestro software. Pero... ¿Y si todo funciona perfectamente? ¿Por qué lo he de cambiar? Esa pregunta se la tendría que hacer tu jefe a sí mismo, pero como es tu jefe estoy seguro que no se la hará así que acostúmbrate, el cambio es la única constante en el desarrollo de cualquier sistema y debes de estar listo para aplicarlo así que... ¡No te preocupes! Aquí enlistaremos algunos de los pasos que puedes seguir para no morir en el intento. Requerimiento vs. Casos de Uso (rematch) via G