Mes: febrero 2025

De regreso al Desktop 15 años después

Duramente más de 15 años trabajé con una computadora portatil independientemente de si trabaja en la oficina de un cliente o en mi oficina. En este último caso solía usar dispositivos externos(monitor, teclado y mouse, etc) para trabajar más cómodo.

Hablo en pasado porque hace un par de meses decidí comprar una computadora de escritorio para dejarla fija en mi oficina. Una de las principales motivaciones para esto fue contar con Linux, ya que mi computadora portatil es MacOS y eso me trae dificultades cuando tengo que dar soporte a mis alumnos que en su gran mayoría no usan MacOS. Por otra lado yo había dejado de usar máquina de escritorio por el tamaño físico de los gabinetes que realmente me resultaba incómodo. Pero resulta que desde hace un tiempo hay mini-pcs muy potentes. Así que con todo esto en mente comencé a investigar para comprar una mini-pc y ponerle Linux.

Luego de varias averiguaciones decidí comprar una mini-pc Bmax B4 Pro, 16 GB de RAM y 500 GB de disco. Vino con Windows 11 Pro de fábrica, el cual decidí conservar e instalarle un Linux en paralelo. La decisión de la distribución de Linux ya lo compartí en un post anterior: ubuntu.

Todo el set de periféricos ya lo tenia, paso a detallar:

  • La BMax viene con dos puertos HDMI en los cuales conecté mis monitores gemelos Dell. Nota al margen para el modelo del monitor: Dell P2018h de 20 pulgadas, una joya, puede ponerse en orientación vertical y funciona como hub USB (tiene 4 entradas USB), conexión HDMI, VGA y DisplayPort.
  • Camara USB Logitec C922 Pro Stream Full Hd.
  • Parlantes Edifier R1000TCN
  • Micrófono USB Fifine K669B
  • Impresora laser Samsung M2020w
  • Teclado y Mouse estoy utilizando los de una vieja iMac conectados por USB. Hice una configuración custom en el Linux para que el mapeo de teclas resulte igual al que tengo en la MacBook.

Con todo esto, del CPU salen 5 cables: alimentación electrica, 2 hdmi para los monitores, audio y un USB para el monitor que funciona como hub. A su vez el monitor hub recibe: cámara, micrófono, impresora y teclado (que a su vez tiene conectado el mouse).

Luego de 1 mes de trabajo con este setup estoy muy cómodo.

Pair-Programming: una práctica subestimada y malinterpretada

La práctica de Pair-Programming es en mi opinión una práctica poco utilizada. Creo que muchos la prueban en algún momento pero luego la abandonan. Al mismo tiempo creo que mucha gente tiene una idea equivocada de lo que es esta práctica.

Respecto de la mala interpretación: la idea general es que dos personas trabajan juntas en una única máquina. Eso no es pair-programming, o mejor dicho faltan cosas. La práctica de pair-programming implica una serie de cuestiones adicionales como ser: cada uno de los programadores tiene un rol que va rotando siguiendo una dinámica predeterminada de forma tal que el teclado de cambia de manos, se trabaja en pequeños incrementos, etc, etc.

Respecto de la subestimación: hay gente que cree que esta práctica baja la productividad y por ello algunos se oponen a su uso. La realidad es que hay varios estudios desde hace mucho tiempo que demuestran que esto es falso, ya escribí sobre esto hace un tiempo.

Ahora bien, justamente por estas dos cuestiones es que en mis cursos de ingeniería de software estudiamos y practicamos pair-programming y en general tiene una muy buena aceptación por parte de los alumnos (más detalles en otro post).

En lo personal hago mucho pair-programming con los equipos que trabajo y suelo complementarlo con otras prácticas como trunk-based development, integración continua y TDD. Creo que justamente el combo de prácticas es lo que hace «que cierre».

Sobre la Orientación a Objetos y su pobre uso en la actualidad

La programación orientada a objetos (POO) tiene ya más de 40 (¿50?) años y sin embargo….

Para empezar me parece importante destacar el hecho que la POO no solo es una «tecnología de programación» sino algo mucho más amplio: es un paradigma. Esto implica que además de programar utilizando ciertas herramientas (encapsulamiento, polimorfismo, etc, etc), también tiene impacto en la forma en que planteamos los problemas y diseñamos nuestras soluciones.

Hoy en día creo que todos los lenguajes de programación de uso masivo tienen soporte para POO. Al mismo, en las carreras universitarias de sistemas se enseña POO.

Sin embargo, una y otra vez vemos (en la industria y en la academia) soluciones que utilizan objetos pero que no son orientadas a objetos. Abundan las soluciones con objetos contenedores de datos por un lado y objetos con lógica/algoritmos (pero sin datos) por otro. Para el resto del artículo me voy a referir a estas soluciones como «soluciones procedurales (SP)». Este fenómeno de «datos por un lado» y «comportamiento por otro», no es nuevo. De hecho hay varios frameworks que proponen este enfoque. Ya desde los años 2000 J2EE proponía nombre a estos objetos: «session beans» y «entity beans». Esta estrategia puede resultar práctica e incluso conveniente pero es contraria a la propuesta de la orientación objetos donde se supone que cada objeto encapsula dentro de sí, datos y los algoritmos que operan sobre esos datos.

A esto se suma al hecho de que hay gente que cree que construye soluciones orientadas a objetos porque usan clases, herencia, y demás herramientas de la OO pero que en realidad son soluciones procedurales porque siguen separando datos y comportamiento.

No digo que esté mal hacer soluciones procedurales, de hecho creo que hay situaciones donde este enfoque puede ser el más conveniente. Pero esta confusión entre soluciones procedurales y soluciones orientadas a objetos traen dos situaciones potencialmente problemáticas.

Un problema es cuando decimos (o creemos) estar haciendo algo (una solución OO) pero en realidad estamos haciendo algo distinto (una solución procedural).

El otro problema es usar un enfoque cuando en realidad sería mejor utilizar el otro.

Los primeros 15 años de mi trabajo docente fue intentando enseñar POO y por ello soy consciente de la dificultad de enseñar/aprender este tema. Hoy en día en los cursos que dicto en la universidad se supone que los alumnos ya llegan sabiendo OO aunque lamentablemente en la mayoría de los casos vemos importante falencias. Creo que en parte esto se debe a que muchas veces se enseña OO utilizando «problemas simplificados», o sea: los alumnos saben hacer modelos computables orientados a objetos de ciertos problemas, pero sin tener que lidiar con infraestructura (interfaces de usuario, persistencia, etc.).

Lo que veo en mis cursos es que cuando les planteamos problemas en los que tienen que lidiar interfaces de usuario, persistencia, etc, se «desvían» y terminan haciendo soluciones procedurales :-(.