Featured

Un final inevitable


Esta probablemente será la última publicación que haré en el blog, así que intentaré que por lo menos sea un poco más memorable que el resto. Antes de comenzar con la reflexión como tal, quiero hacer saber que estoy intentando lo de escribir con Comic Sans para ver si efectivamente redactar resulta más fácil.

“Quill” flickr photo by rachaelvoorhees https://flickr.com/photos/rachaelvoorhees/2551532922 shared under a Creative Commons (BY-SA) license

Tener un blog por primera vez fue toda una experiencia. Incluso si no decidí exactamente de lo que hablaba “cada semana”, me agradaba tener la oportunidad de redactar y dar a conocer mi punto de vista respecto a distintos temas. Me es muy entretenido expresarme e idear analogías para ayudar a explicar ciertas cosas.

De hecho, el próximo semestre comenzaré a impartir materias en el sistema de preparatoria en línea de Prep@net. Me tocará ser tutor para algún grupo y, sinceramente, estoy emocionado. Espero que todo lo que practiqué con este blog me sirva para impartir clases.

Después de la reflexión del segundo parcial solamente hice tres masteries. Haré el típico resumen de los tres temas correspondientes, pero al final tendré que darle un énfasis mucho mayor a lo que me dejó el curso en general. Iré, como siempre, en orden cronológico.

Revisión de código

Honestamente, este fue uno de los temas que más me interesó mientras lo investigaba. Ver las múltiples técnicas, prácticas o consejos para algo tan rutinario como lo es la revisión de código fue revelador.

“Incorrect vs. Correct” flickr photo by ebenimeli https://flickr.com/photos/ebenimeli/6833633182 shared under a Creative Commons (BY-NC-SA) license

Recién me doy cuenta de que mi analogía va todavía más allá de lo que pensaba inicialmente. Al principio comparé la revisión de código con los quehaceres del hogar porque son cosas que, si bien no son precisamente entretenidas y pueden dar mucha pereza, son sumamente imprescindibles para una mejor calidad de vida a largo plazo. La parte que no relacioné originalmente es que hay mucha gente que ya da por hecho ambas cosas, ya son parte de una rutina. No es necesario decir explícitamente lo que se tiene hacer porque muchos ya estamos acostumbrados a realizar ambas actividades.

Incluso si, como acabo de decir, ya acostumbramos a realizar alguna de estas labores, no quiere decir que lo estemos haciendo de la forma más eficiente. Los métodos y consejos en mi publicación original son algunos ejemplos de cómo puede mejorarse el proceso.

Las técnicas que reuní iban desde cosas muy casuales/informales como simplemente ir hasta donde tu compañero y pedirle que le eche un vistazo a tu código, hasta crear fichas para hacer un reporte completo y llevar un registro más riguroso de los cambios hechos.

Verificación y validación

Este tema fue sencillo de explicar, pues en realidad todo dependía de un par de conceptos bastantes simples en sí. Ojo, son conceptos simples por sí mismos, pero debido a su pronunciación tan similar pueden confundirse. La “comparación” de ese tema en realidad fue un par de ejemplos de palabras que de por sí se confunden entre sí, y la verdad es que muchas de esas las menciona el profesor constantemente, así que no siento que haya sido de mis mejores analogías.

“OK Blue” flickr photo by sylvar https://flickr.com/photos/sylvar/3175705552 shared under a Creative Commons (BY) license

El proceso de verificación y validación es uno comúnmente utilizado no solo en el ámbito del software, sino en todo lo relacionado a productos y servicios. Básicamente se realiza una serie de pruebas y revisiones para comprobar que lo evaluado cumpla con ciertos estándares y cierta calidad.

La parte clave para comprender este tema, o por lo menos en mi percepción, es saber qué pregunta intenta responder cada parte del proceso. La verificación se asegura de que el producto/sistema se esté haciendo correctamente, principalmente se asocia con los requerimientos y especificaciones del diseño. Por otro lado, la validación se encarga de que se esté trabajando en el producto correcto, trabaja con las necesidades del usuario y lo que se busca solucionar.

Otros detalles relacionados a cómo llevar a cabo este proceso y algunos de los beneficios que trae consigo están dentro de mi entrada original. Este tema no lo he puesto en práctica, pero pude notar que llega a ser de gran utilidad.

Pruebas en Orientado a Objetos

Lo primero que quiero decir de esto es que en el título de mi mastery escribí “OOkay”, pero no fue un error de dedo, quise meter la parte de Orientado a Objetos y lo mejor que se me ocurrió fue eso.

“testing” flickr photo by rjacklin1975 https://flickr.com/photos/rjacklin/436491997 shared under a Creative Commons (BY) license

Este tema fue muy directo, es justo lo que dice el título. Todo de lo que hablé fue de cómo se pueden realizar, sistematizar o de cierta manera automatizar las pruebas en algún lenguaje orientado a objetos.

Debido a que tanto la fase de pruebas en el desarrollo de software como el paradigma orientado a objetos tienen una fuerte presencia en el campo de computación llegué a encontrar mil y un formas de llevar a cabo estas pruebas. Comparé esta diversidad con los sistemas de numeración, pues sin importar su clasificación o funcionamiento, al final sirven para lo mismo. Lo que es importante tener en mente es que en determinadas situaciones puede ser que una manera de manejarlo sea mejor que otras.

En fin, existen muchas maneras de clasificar estas pruebas y cada una tiene sus distintos objetivos. En la página original están incluidas y explicadas varias de estas. Opino que es importante comprender algunos tipos diferentes de pruebas en caso de que uno u otro sea necesario.

Pero fuera de estos temas y de explicaciones similares, he llegado a la esperada reflexión. Este semestre he estado publicando muchas cosas respecto a varios temas relacionados al diseño de software. Si soy sincero, no creo que la parte de diseño sea una de mis fortalezas dentro de la carrera, pero debo admitir que este curso me hizo darme cuenta de lo mucho que ya empleo algunas prácticas de esta rama.

Conforme necesitaba escribir alguna entrada nueva me ponía a investigar exhaustivamente para encontrar información suficiente para hacer mi trabajo, buscaba distintas fuentes que, si bien no siempre hacía referencia a ellas, me servían para confirmar lo que leía inicialmente. Estoy muy de acuerdo con lo que Ken nos ha dicho ya un par de veces: es mejor si no se nos indica qué incluir, cuánto escribir ni de dónde obtener la información.

Me agradaba que para cada tema tuviese la oportunidad de informarme cuanto quisiese y poder ser selectivo respecto a qué poner en el producto final. Tras investigar lo suficiente podía darme una idea de qué podría ser más relevante en mi contexto; gracias a la extensión variable me decidí a imponerme un mínimo de dos cuartillas de texto por cada entrada y me forzaba a investigar más cuando no cumplía esa “cuota”; lo de obtener nuestras propias fuentes combinado con lo anterior hizo que comenzara a buscar en foros y sitios similares algunas opiniones de gente experimentada con los temas que iban surgiendo.

“Research” flickr photo by haynie.thomas36 https://flickr.com/photos/132832534@N03/18344328294 shared under a Creative Commons (BY) license

El conjunto de estas condiciones me ayudó a realmente comprender cómo funcionan numerosos procesos del diseño de software, es la primera vez en que realmente he sentido que el autoaprendizaje ha funcionado. Incluso si en alguna de las entradas que hice malinterpreté un tema o solo rasqué la superficie de lo que realmente involucra, tengo una noción de todo lo visto, y eso lo agradezco enormemente.

También relacionado con la parte de autoaprendizaje, el hecho de poder hacer estos cuando quisiéramos y las deadlines flexibles me ayudaron mucho a lo largo del semestre. Pude enfocarme en cosas más urgentes sin preocuparme por este blog. La manera de funcionar del curso me hizo reforzar mi responsabilidad y mi capacidad de búsqueda de información.

Una cosa más que quiero mencionar sobre este curso es el proyecto que estuvimos llevando a cabo a lo largo del semestre. Si bien ya di una conclusión bastante concisa de lo que me quedó en esta publicación, me gustaría agregar que además del típico trabajo en equipo (que, por cierto, se desarrolló muy bien) pudimos experimentar la parte de entrevistas y búsqueda/comunicación con los stakeholders de nuestro proyecto. Experiencias así siempre son buenas.

A pesar de haber explicado todo esto estoy seguro de que todavía se preguntan una cosa: ¿realmente funciona lo de Comic Sans? Me apena decirlo, pero no me ha funcionado en lo absoluto, mis ideas han fluido igual que siempre y en realidad no sentí ninguna diferencia fuera de lo feo que se ve mi borrador. Seguro sí es un simple efecto placebo, pero probablemente por ser consciente de eso mismo ya no funcionó conmigo. Lo único bueno es que parece ser que tanto Comic Sans como Arial (la fuente que suelo utilizar en mis borradores) tienen un tamaño similar y no tuve problemas para medir cuánto he estado escribiendo.

En fin, lo que aprendí en parciales pasados puede verse en las reflexiones del primer y segundo parcial. Si volviese a decir lo que me quedó, sería básicamente lo mismo que ya está escrito y no aportaría nada de verdad a esta entrada. El aprendizaje puede funcionar de muchas maneras, y siento que ya he plasmado en esta entrada todo lo que me pareció relevante. Me pareció muy agradable y útil la manera de llevar la clase.

“Learn” flickr photo by PlusLexia.com https://flickr.com/photos/153278281@N07/39570228664 shared under a Creative Commons (BY) license

TL; DR: El aprendizaje es maravilloso

PD: No sé por qué hay tantas fotos de Scrabble

Second partial exam [WIP]


Right now, I’ve only done one of the reviews from this period. I will try to catch up in the next few weeks. I have some ideas that can help me get through them all quickly.

I will update this entry once I’ve read every chapter considered for the second partial.

“Work is Going On” flickr photo by cogdogblog https://flickr.com/photos/cogdog/38065460945 shared into the public domain using (CC0)

First partial “exam”


The first partial covers the first eleven chapters of the book Deadline. I’ll summarize all of the things that I’ve learned from Mr. Tompkins during my reading. As I wrote every single review I tried to find websites that complemented the given information, either by stating different points of view on whatever subject was being discussed or by providing updated information. I will try to focus a little more on these.

“203” flickr photo by thecmn https://flickr.com/photos/97947597@N00/48057456022 shared into the public domain using (PDM)

Risks and risk management

Risks are threats that every organization has to deal with, not the kind of threat that others make looking for the company to stay out, but rather the ones that are caused by management errors, accidents or other factors.

Identifying and controlling these risks is what is known as risk management.

There are multiple processes, approaches and standards regarding this subject, and there are several things that have to be taken into consideration before opting for one of them.

Regardless of the chosen approach, the intention of risk management is making said threats do as little damage as possible.

Productivity

There are some common mistakes that managers make when trying to improve their employees’ productivity that actually end up being counterproductive. One of them is mentioned in the story: when employees are distracted or paralyzed by fear (sometimes caused by the manager).

Also, there’s no way of immediately improving productivity in the workspace, but after some time and effort, productivity improvement may be apparent in the long-term. It’s, in a way, an investment.

Gut feelings

One of the essential components of a good manager. It’s that little voice that tells you if you’ve found what you were seeking for or if you need to keep looking even if the opposite seems true. This may not be much of a technical term, but people with tons of management experience affirm that learning to identify and listen to those feelings can be very helpful.

Interviews

There are many techniques that can be used when conducting interviews that can let you know more about the candidates and help you find the best ones quicker. One of the most common tricks is to stay quiet for an uncomfortably long amount of time and see how people react. Apparently, this can tell you a lot about a person, and can allow you to see things that would normally be unnoticed.

Project failures

A lot of software projects fail. In 2017, 14% of all IT projects failed, but 31% didn’t meet their goals, 43% exceeded their original budgets and 49% were late on delivery. It’s a lot more common than it may seem.

Project termination

Sometimes it’s necessary to know when to terminate a project before it’s even delivered. The reasons for termination may vary from one company to another, but regardless of it, the decision by itself may help to not waste working efforts.

System dynamics

An approach that allows to model and simulate the behavior of complex systems by using several components, including loops, time delays and table functions. There are multiple programs that allow to create and test these models. They can be useful to predict and adjust some factors that may be too complicated due to the number of variables affecting them.

Bad bosses

There are some indicators that can tell you if your boss is not precisely the best there is. The most prominent one in the story is refusing to listening to logical reasoning from his employees and demanding certain things to be done just for the sake of it. This happens very often, and sadly some people have no choice but to get used to it.

Guest speakers

Honestly, even if they gave us lots of advice and information, I have to say that the thing that had the biggest impact on me was that I actually have a shot at working my dream job. It’s been a couple of years since I decided that my ultimate goal would be to work in the videogame industry. The first ~three guests had actual experience with videogame companies, and they motivated me to keep chasing my dream.

Mr. Tompkins’ journal helps me finding the keywords that I can use to search for new information and allows me to learn a little more.

“203” flickr photo by thecmn https://flickr.com/photos/97947597@N00/48057456022 shared into the public domain using (PDM)

As for the things I made during this period: I tried to create a simple RPG game using Google Slides because I thought that’d be an easier alternative than writing these entries (since they take me a lot of time to write). It didn’t work, but I’m still trying to figure out what else I can do.

Right now, I’m several assignments behind, so I hope I can make some time to catch up. I’ve read some more chapters of the book, but the reviews are still pending. I’m enjoying the reading, and I want to enjoy making the entries too.

Create your website at WordPress.com
Get started