Mi segunda reflexión parcial


¡Hola! Sé que es raro que esté escribiendo en español, pero tengo varios motivos muy buenos para esto. Primero, por ser mi lengua natal, podré expresarme con más facilidad y podré dar a entender cosas que tal vez en inglés no sabría cómo; lo que me lleva a mi siguiente punto: para la reflexión del primer parcial la mayor parte del contenido fue una breve recapitulación de los masteries que había hecho hasta ese entonces, pero en retrospectiva siento que no aportaba la gran cosa. En español podré volver a hablar sobre estos temas, pero con una perspectiva diferente, pues claro, en dos idiomas distintos explicaré las cosas de manera distinta. Por último, y definitivamente no la razón principal, porque me es muchísimo más fácil escribir y escribir cosas en español, lo que me viene muy bien para esta entrega antes de que llegue la deadline final.

“Doing the bird dance.” flickr photo by Bernard Spragg https://flickr.com/photos/volvob12b/9418456505 shared into the public domain using (CC0)

Ahora bien, dejando todos estos detalles de lado, me gustaría copiar un poco el formato que usé para mi primera entrega y explicar qué fue lo más relevante que me ocurrió en el parcial respecto a mis clases en general.
Primero, los proyectos y exámenes comenzaron a ser más pesados, me cansaba más y necesitaba esforzarme bastante para poder cumplir con todos mis deberes. El problema aquí fue que para mis masteries no tenía una deadline tan ajustada, por lo que comencé a descuidar esa parte un poco. Sí redactaba alguno de vez en cuando, pero no los llegué a publicar en su momento pues no lo vi necesario. Por cierto, a partir de mi última entrega del primer parcial creé un documento en Google Docs en donde he estado trabajando en todas estas entradas de blog. Me ha sido muy útil tenerlo todo junto de este modo.

Una cosa de la que apenas me di cuenta conforme escribía el párrafo anterior es que había una prueba que quería realizar para escribir mis masteries, pero creo que ya es un poco tarde para eso. Hace un par de semanas leí el encabezado de un artículo que decía que, cuando estás en blanco y no se te ocurre qué escribir o redactar mientras trabajas en cualquier tipo de texto, cambiar la fuente de tu escrito a Comic Sans resulta muy útil para que las ideas fluyan. Esto probablemente sea un simple efecto placebo, pero de todos modos moría de ganas por intentar algo así. Supongo que para la reflexión final tendré que ponerlo a prueba.

Una última cosa que quiero comentar antes de comenzar a hablar de los masteries de este parcial está relacionada con mis fuentes de información. Una cosa que he hecho desde siempre cuando necesito investigar algún tema para tareas o proyectos es buscar dicho tema en Wikipedia para darme una idea general de qué es lo que estoy buscando y ser más selectivo con mi información, pero como dicho sitio siempre ha sido fuertemente desprestigiado por muchos maestros procuro no incluir páginas de Wikipedia en mis referencias. Últimamente me he percatado de que Wikipedia realmente tiene información muy completa, está bien referenciada y siempre están las versiones en otros idiomas para ver todavía más información al respecto. Incluso para este blog he sacado mucha información de Wikipedia, pero no agrego los hipervínculos respectivos. Comenzaré a hacerlo porque empiezo a ver que Wikipedia es una herramienta que también vale la pena consultar.

“Magnify!” flickr photo by robad0b https://flickr.com/photos/robadob/523367560 shared under a Creative Commons (BY-SA) license

Por último, también relacionado a mis referencias, para un par de masteries obtuve datos e información de distintos foros y páginas de pregunta-respuesta. Sé que no siempre es lo ideal, pero para algunos de los temas que necesité ver en este parcial solo conseguía datos y hechos, pero en muchas ocasiones necesitaba de algún punto de vista ajeno para ampliar mi panorama y conocer un poco más, porque al fin y al cabo, la experiencia es una de las mejores fuentes de conocimiento que hay. Quise tomar varias perspectivas para generar la mía propia.

Bueno, dicho todo esto, repasemos los masteries:

Patrones de diseño

Este tema en particular es uno que conocía ya desde hace un año gracias a la clase de Ingeniería de Software. De hecho, me tocó hablar sobre él, pero si soy completamente sincero, en ese entonces no le entendía del todo. ¡Pero eso cambió! Ahora tengo una visión más clara de los patrones de diseño y de su utilidad.

“pattern” flickr photo by walmarc04 https://flickr.com/photos/ioachimphotos/29693349040 shared into the public domain using (PDM)

Estos patrones de diseño son herramientas que guían a los desarrolladores a darle una mejor implementación a las soluciones de sus problemas. Son respuestas ya estudiadas y que son consideradas como mejores prácticas por alguna razón. Los creadores de este concepto (y de 23 de los patrones) son conocidos como Gang of Four. Ellos también decidieron la clasificación de los patrones según su funcionamiento en creacionales (controlan creación e instanciación de objetos), estructurales (definen relaciones entre objetos) y de comportamiento (establece cómo se comunican e interactúan dos o más objetos).

La comparación que decidí hacer con este tema fue la de intentar bloquear la luz del Sol. Hay quienes lo hacen con la mano, hay quienes lo hacen con alguna gorra o sombrero, hay quienes usan lentes para ello, pero todos están colocando algo que se interponga entre los ojos de uno y la luz solar. Los patrones de diseño funcionan de manera similar en el sentido de que no te dicen cómo conseguir tu objetivo, sino que solo te indican qué es lo que debes hacer.

Este tema es básico dentro del diseño de software, así que tiene mucho sentido que lo veamos en esta materia.

UML I y II

UML también es de esas cosas que conocemos en los primeros semestres de la carrera. Es una herramienta que hemos utilizado una y otra vez y aún así parece que todos estamos muy lejos de aprender todo lo que hay por saber al respecto.

En los masteries de UML el enfoque principal era explicar algunos de los diagramas manejados. Una de las cosas que logré aprender mientras investigaba este tema fue que la clasificación de los diagramas UML depende en una buena parte del componente primario que predomine.

“All You Need is Tools, Tools, Tools” flickr photo by cogdogblog https://flickr.com/photos/cogdog/49021347718 shared into the public domain using (CC0)

Aquí resumo muy brevemente los diagramas de los que llegué a hablar en sus respectivos masteries:

Diagrama secuencial: Su componente principal es la secuencia y se encarga de manejar interacciones entre entidades para llegar a una meta.

Diagrama de clase: Siento que ni siquiera necesito explicar este de nuevo.

Diagrama de objeto: Algo obsoleto, pero se encarga de manejar las instancias que surgen a partir de distintas clases.

Diagrama de paquetes: Agrupan varios elementos en uno. Un paquete, vaya.

Diagrama de estado: Parecido a un autómata, pues define estados y sus transiciones.

Diagrama de componente: Parecido en cierto sentido a los bloques de programación o a módulos de acción. Pueden intercambiarse y modificarse independientemente.

También hablé de GRASP y sus principios, pero la verdad es que el modelo que quiero comentar es el MVC. Verán, al principio no comprendía muy bien cómo funcionaba este modelo, pero justo hace un par de días estaba trabajando en un proyecto de Java donde precisamente este modelo fue el que me hizo la vida imposible. Estaba trabajando con Threads y buscaba dibujar sus actualizaciones con JTable, pero debido a la velocidad de los hilos y al funcionamiento del MVC, una excepción se arrojaba constantemente. La razón era que se modificaba el modelo, pero la vista no era notificada a tiempo antes de repintar, así que buscaba elementos inexistentes en el modelo.

En fin, UML es algo muy útil para el diseño y todo lo que implica ya lo digo en mi entrada original, así que les recomiendo mejor ir a ver esa.

Clases a tablas

Este tema fue uno de los que más se me facilitó entender y redactar. Las bases de datos pueden implementarse de muchas maneras, y con temas tan estudiados como lo son el paradigma orientado a objetos y las bases de datos relacionales, era claro que habría maneras muy sistematizadas de hacer la conversión de uno a otro. 

“Old ship planks” flickr photo by zsolt.palatinus https://flickr.com/photos/137424368@N06/26782878937 shared into the public domain using (PDM)

Esa parte fue muy sencilla de explicar y en la página original incluí un tutorial muy completo sobre cómo llevar a cabo ese proceso.

Afortunadamente, este semestre he estado llevando la materia de bases de datos avanzadas, en la que trabajamos con múltiples bases de datos no relacionales. C* y MongoDB son los mejores ejemplos que tengo para demostrar lo diferentes que son a los que siguen SQL. Gracias a esto, me fue un poco más sencillo entender la complicación de pasar clases a tablas no relacionales, la manera en que estas últimas se manejan y el hecho de que no siempre existen uniones hacen la translación una tarea difícil.

Mi comparación de este mastery me pareció muy apropiada. Pasar de texto a texto siempre es muy sencillo, pero cuando el formato destino va a cambiar radicalmente, muy probablemente se vaya a requerir de un esfuerzo mucho mayor para lograr un resultado de calidad comparable. Es justo lo que pasa con las conversiones contempladas en este tema.

Clases a código

Para el último tema comprendido dentro del segundo parcial utilicé una analogía con pintura y las distintas técnicas y estilos que existen. Me enfoqué en explicar algunas de las diferencias fundamentales entre algunos lenguajes de programación. 

“Classroom” flickr photo by cogdogblog https://flickr.com/photos/cogdog/46702870 shared into the public domain using (CC0)

(Qué curioso el nombre del autor de esta foto)

También hablé sobre los distintos paradigmas que son compatibles o no con ciertos lenguajes y qué implicaciones trae esto consigo al momento de querer hacer ciertas implementaciones.

Hablé sobre cómo es muy fácil implementar un diseño orientado a objetos en un lenguaje que soporte este paradigma, así que de esa parte no incluí mucho. La parte más extensa y que requirió de un poco más de investigación fue la de diseño orientado a objetos en un lenguaje no orientado a objetos. Claro que la conversión no sería tan sencilla, pero de acuerdo a lo que leí (porque nunca he necesitado hacer algo por el estilo por mi cuenta), es posible simular de cierta manera el comportamiento de las clases e instancias, pero que siempre habrá algunos detalles que simplemente no se podrán comparar con un lenguaje diseñado para OO.

Sigo sin entender por qué alguien haría algo así, la verdad.

Pero bueno, fuera de todos los temas vistos en el parcial y de todo el estrés que ha causado la escuela puedo comenzar a relajarme un poco más. La conclusión final del curso, mis opiniones y demás cosas por el estilo quiero incluirlas en mi reflexión final, es lo único que me falta para el blog y ya tengo pensadas algunas ideas.

Así que, por ahora, lo único que me queda por decir es que estoy muy feliz porque ya van a empezar las vacaciones. Daré un gran esfuerzo por escribir otra reflexión que se merezca aparecer en el Twitter de Ken Bauer.

“twitter” flickr photo by o.tacke https://flickr.com/photos/otacke/13970870674 shared into the public domain using (CC0)

Hasta la próxima.

ML ; NL: Lo chido viene en la reflexión final

Leave a comment

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Create your website with WordPress.com
Get started
%d bloggers like this: