duck-case

Esta entrada corresponde al capítulo 2 del libro Head First Object Oriented Analysis and Design el cual tiene por nombre Dale justo lo que ellos quieren  y aborda el primer punto de las buenas prácticas para desarrollar software que nos indicaba que primeramente nuestro software debe de hacer únicamente lo que nuestro cliente quiere así que... ¡Allá vamos! Esta vez va de perros via GIPHY En este capítulo dejamos atrás las guitarras para tomar el caso de Tood y Gina, unos clientes muy flojos  que desean hacer una puerta automática para que su pequeño perro no vuelva a hacer sus necesidades dentro de casa. Una vez tomada el requerimiento principal como buenos en realidad malos  programadores nos ponemos manos a la obra y terminamos nuestra aplicación en tiempo récord pero todo se viene abajo cuando los conejos y las ratas entran a la cocina. ¿Por qué pasó esto? Este capítulo nos deja muy en claro como el tener claro los requerimientos antes de hacer software es muy, pero mu

Siguiendo con algunas metodologías de la desarrollo de software  yeeeeey,   hoy toca hablar de una cuyo nombre fue totalmente inspirado en la compañía que lo creó: Rational Software, estoy hablando del Proceso Unificado de Rational o como los conocemos los amigos RUP así que como siempre, vamos a hablar de una manera que nos quede claro de una vez por todas sobre de qué va esta metodología. De Desconocido - Transferred from en.wikipedia , Dominio público, Enlace Esta metodología tiene características bien diferenciadas de las demás pues se basa en casos de uso para obtener los requerimientos de los usuarios en cada una de sus iteraciones. ¿Iteraciones? Venga, no pierdas el hilo, ya llegaremos a ese punto. Algo que debemos de tener muy presente es que se enfoca en la arquitectura de una manera muy notoria ya que si usamos esta metodología tenemos que creer que esta es la parte central. RUP, RUP, RUPIAS?! via GIPHY ¿De qué demonios va RUP? No te preocupes, aquí te

Esta entrada servirá como recordatorio de cómo es que comenzamos a usar Google Cloud Functions en el lugar en el que actualmente estoy trabajando, así que aquí vamos: Instalando las dependencias No tiene gran misterio, sólo corre esta línea de código y todo estará bien:    npm install - g firebase - tools Identifícate, por favor Claramente nos tenemos que hacer login desde la consola y para esto corremos la siguiente instrucción: firebase login Esta instrucción nos llevará a indentificarnos con nuestra cuenta de Google y deberemos de dar unos algunos permisos, los leeemos cuidadosamente aceptamos todo sin mirar  y listo! Ya podemos comenzar a usar las Google Cloud Functions. ¿Dónde están mis funciones? Revisa el archivo llamado index.js que está en la carpeta functions que se agregó a tu proyecto, ahí deberás agregar las funciones que desees subir a Firebase. La primera función que la plataforma te invita a implementar es esta: // Take the text parameter passe

Sí, ya sé que no fui a la primera clase de Bases de Datos Avanzados y me siento muy culpable por ello la verdad no pero cómo sea, aquí está lo que aprendí de la primera práctica. via GIPHY Después de darle una leída rápida a la primera presentación correspondiente a esta clase noté inmediatamente 2 palabras clave: nephy y netvizz, así que con esto en mente, me puse a buscar de qué demonios iban estas dos cosas así que a continuación les presento los resultados. netvizz   Se trata de una aplicación creada por Bernhard Rieder que nos permite crear archivos .gdf (una especia de archivo de texto que contiene un grafo no dirigido) de las relaciones de grupos en esta red social. Estos archivos posteriormente se analizan en una plataforma de visualización de grafos tal como lo es Gephi. gephi Es una herramienta que nos permite visualizar y explorar todo tipo de gráficas y redes. Y ya está. Es esto. Lo demás que se necesita hacer sencillamente es historia: Utiliza

Hoy no será para nada un post técnico. Hoy vamos a hablar de un tema en especial como amigos de toda la vida aunque, estoy completamente seguro que ningún amigo de toda la vida te hablaría del ciclo de vida del software, sin embargo es  el tema en turno en la clase de Ken  uno de los temas más apasionantes de la Ingeniería de Software así que, vamos allá. via GIPHY Un ciclo de vida no es otra cosa más que una serie de pasos bien definidos que sirven como guía para desarrollar software de una manera más efectiva y no pasarnos toda la vida añadiendo características que al final no se van a usar o solucionando bugs eternamente cosa que suele pasar muy a menudo en los últimos días de nuestros proyectos finales. En el Mundo Real ™  no solamente está en juego nuestra calificación sino entran recursos más valiosos como tiempo y dinero, así que en el papel estas metodologías parecen ser maná venido del cielo. ¿Por qué digo que parecen ser? Bueno, porque como en la mayoría de tem

Bien, ya encapsulamos todo y hemos hecho que nuestro código ahora luzca como una verdadera matrioshka... ¿Qué es lo que sigue? Ahora nos tocará ayudar a nosotros y los programadores del futuro. via GIPHY ¿Qué pasará cuando nos toque hacer mantenimiento y queramos añadir otra nueva característica? ¿Qué pasará cuando venga otro programador a actualizar nuestro código? Sinceramente esperamos que no suceda una catástrofe. Sinceramente creo que esto funcionará como un recordatorio para mi en el futuro también: un esfuerzo ahora nos ahorrará muchos problemas en el futuro. Cuando diseñamos una aplicación a todos nos llega un momento de iluminación en el que conocemos absolutamente de nuestro código, sabemos qué hace esta parte, con qué otras partes se comunica y si quisiéramos modificar algo lo haremos en menos de 5 minutos, tanta es nuestra confianza que mientras revisamos cierta parte vemos otra oportunidad de encapsular más nuestro código sin embargo, no lo hacemos porque en ese m

Si no lo lleva, no lo lleva No sé dónde es que escuché esta frase tan popular en el sur de México pero aplica muy bien para lo que queremos explicar aquí: tenemos que comenzar a aplicar los principios básicos y de flexibilidad de la programación orientada a objetos. Quizá nos ha pasado, al momento de crear una funcionalidad nueva para un programa que estamos recién escribiendo nos comenzamos a llenar de variables que, al menos en ese momento, tiene mucho sentido para nosotros y terminamos teniendo constructores larguísimos y setters y getters por todos lados. Pero cuando la funcionalidad ya está ejecutando su tarea nos damos cuenta, quizá no necesitábamos tantas variables. Entonces... ¿Qué hacemos? ¿Las dejamos ahí y le decimos a nuestro cliente que se adapte a ellas? Va a ser que no. Al satisfacer una petición de nuestro cliente por alguna razón, cualquier razón es válida, no entendemos bien qué nos está pidiendo y es aquí cuando tenemos que comenzar a aplicar las buenas

Cuando comencé a leer el libro Head First Object-Oriented Analysis and Design me llevé una grata sorpresa: no es nada técnico. Al contrario, dista mucho de ser una literatura aburrida y despierta mucho el interés del lector pero no se confundan, el que no sea técnico no quiere decir que no sea muy bueno y para muestra de ello es imposible hacer una sola entrada para el capítulo completo así que dividiré todos los capítulos con el contenido que se me hizo más relevante del mismo. Así que, manos a la obra. By Zyance - Own work , CC BY-SA 2.5 , Link ¿Qué significa buen software ? Para mí, significa que además de que cumpla la tarea para el cuál fue creado también debe de tener una implementación elegante, es decir, que no tenga líneas de código repetidas y que sea extensible. Ahora sí... ¿Qué realmente significa buen software ? Según este libro, significa más de una cosa: El buen software debe satisfacer al cliente, es decir, debe de hacer lo que el cliente quier