CASE: Mas haraganes o mas productivos?

"Es cierto que a veces quisiera tener cuatro o mas manos, pero esto es exagerar"

CASE son las siglas de Computer Aided Software Engineering lo cual se refiere a una serie de herramientas de software que ayudan al programador y/o analista a planear/diseñar/desarrollar su proyecto. Esto le permite su usuario ahorrarse tiempo y dolores de cabeza con tareas automatizadas como el cronograma de actividades, el diseño de diagramas UML, refactoring, entre otros.

Los problemas surgen cuando estas herramientas les son enseñadas a los estudiantes de primeros años de ingenieria y estos se malacostumbran al uso de ellas y se vuelven haraganes para escribir el codigo, por lo que pasan por alto las bases necesarias. O sea, es necesario hacerlo a mano para entender bien el proceso.

Un ejemplo claro, el cual he tenido la oportunidad de apreciar, es el uso de los asistentes que vienen incluidos en el Visual Studio 2005, especialmente el asistente para crear un origen de datos, el cual te hace todo, hasta la interfaz de tus formularios solo con un par de clics pero genera un codigo engorroso, dificil de entender para cualquiera que se inicia en el lenguaje y por supuesto es toda una odisea personalizarlo debido a ello.

En lo personal, siempre he sido partidario de conocer como funcionan las cosas antes de usarlas, empezar por lo mas simple y minimalista antes de llegar a lo grosso, empezar haciendo las cosas a mano antes de utilizar las herramientas asistidas, ya que una vez que se conocen las bases, las herramientas asistidas reducen el tiempo de diseño/desarrollo del software y aun se cuenta con la capacidad de personalizarlo.

Si los desarrolladores utilizan unicamente herramientas asistidas de los entornos de desarrollo, como el intellisense, autocompletado o las herramientas de refactoring, estas pueden crear una mala costumbre y una dependencia a estas herramientas de modo que no podrias diseñar/codificar sin utilizarlas. Yo lo he vivido, pero intento de no olvidarme de los tiempos cuando se programaba en c/c++ y cualquier editor de textos era el IDE universal. Se te hace familiar esta situacion?

Y que les pareceria programar de esta forma?:

"Entorno de desarrollo en tres dimensiones"

c++ codigo computadoras diseño java .net lenguajes personal programacion programador

CASE: Mas haraganes o mas productivos?

"Es cierto que a veces quisiera tener cuatro o mas manos, pero esto es exagerar"

CASE son las siglas de Computer Aided Software Engineering lo cual se refiere a una serie de herramientas de software que ayudan al programador y/o analista a planear/diseñar/desarrollar su proyecto. Esto le permite su usuario ahorrarse tiempo y dolores de cabeza con tareas automatizadas como el cronograma de actividades, el diseño de diagramas UML, refactoring, entre otros.

Los problemas surgen cuando estas herramientas les son enseñadas a los estudiantes de primeros años de ingenieria y estos se malacostumbran al uso de ellas y se vuelven haraganes para escribir el codigo, por lo que pasan por alto las bases necesarias. O sea, es necesario hacerlo a mano para entender bien el proceso.

Un ejemplo claro, el cual he tenido la oportunidad de apreciar, es el uso de los asistentes que vienen incluidos en el Visual Studio 2005, especialmente el asistente para crear un origen de datos, el cual te hace todo, hasta la interfaz de tus formularios solo con un par de clics pero genera un codigo engorroso, dificil de entender para cualquiera que se inicia en el lenguaje y por supuesto es toda una odisea personalizarlo debido a ello.

En lo personal, siempre he sido partidario de conocer como funcionan las cosas antes de usarlas, empezar por lo mas simple y minimalista antes de llegar a lo grosso, empezar haciendo las cosas a mano antes de utilizar las herramientas asistidas, ya que una vez que se conocen las bases, las herramientas asistidas reducen el tiempo de diseño/desarrollo del software y aun se cuenta con la capacidad de personalizarlo.

Si los desarrolladores utilizan unicamente herramientas asistidas de los entornos de desarrollo, como el intellisense, autocompletado o las herramientas de refactoring, estas pueden crear una mala costumbre y una dependencia a estas herramientas de modo que no podrias diseñar/codificar sin utilizarlas. Yo lo he vivido, pero intento de no olvidarme de los tiempos cuando se programaba en c/c++ y cualquier editor de textos era el IDE universal. Se te hace familiar esta situacion?

Y que les pareceria programar de esta forma?:

"Entorno de desarrollo en tres dimensiones"

c++ codigo computadoras diseño java .net lenguajes personal programacion programador

Programando Mejor [Parte II]

Hace poco comenzaron las clases en la U otra vez, razón por la que tardo mas de lo usual en poner algo aquí... lo mas interesante es que con solo 2 días de ir, tengo muchos temas de que hablar. Y para continuar con la tradición de las sagas, aquí va "Programando Mejor [Parte II]".

Después de una clase con mucha reflexión (pero no de .net), se nos propuso la idea de pensar bien que tipo de profesional/programador/persona se puede llegar a ser. Inmediatamente se me vino a la mente como rayos hacer para ser un mejor programador/analista de sistemas.
Lo interesante de todo esto fue hablar de la creatividad, definida por el exponente del curso como una forma de apertura... y es eso exactamente... o al menos es una definición muy acertada y expuesta en un lenguaje que todos los asistentes pudiéramos entender.
Y quiero agregar que para los sicólogos...

La creatividad es la identificación, planteamiento o solución de un problema de manera relevante y divergente.

Divergente es la palabra clave para concatenar con la idea del principio.
¿Que tiene que ver todo esto con programar mejor? simple amigo:
Un buen programador es, y sera bueno hasta que no deje de, ser creativo.
No perderá su apertura: al cambiar su metodología e innovará constantemente, al no ser terco y al no dejara de aprender... como bien dijeron: "Dejar de aprender, es perderle el gusto a la vida" (Gracias JRCM).

En el momento en que el programador (u otra persona) cierra su mente a una mejor solución por seguir el viejo camino: ese sera el día en que la amargura se empalme en su código y pierda su habilidad para solucionar los problemas informáticos que le presenten. La belleza de su código y el arte, con la que soluciona problemas, se vera nublada con la negatividad que esa decisión tan fatídica crea en su vida.
¡Por Dios, es como una tragedia griega! y claro que lo es...
Es tan trágico como la muerte del Tío Periquito:

Y tan trágico como Monet ciego en 1923 y muriendo de cáncer pulmonar en 1926...

Waterlilies (Lirios de Agua), 1920-26

Es buen habito para el programador mantener su mente abierta a nuevas posibilidades y horizontes. Hacer todo lo posible para mantener su capacidad de análisis y su creatividad al máximo, en todo momento.
Y esto no es solo aplicable para un programador o analista de sistemas...

es aplicable evidentemente, para TODOS.

Programando Mejor [Parte II]

Hace poco comenzaron las clases en la U otra vez, razón por la que tardo mas de lo usual en poner algo aquí... lo mas interesante es que con solo 2 días de ir, tengo muchos temas de que hablar. Y para continuar con la tradición de las sagas, aquí va "Programando Mejor [Parte II]".

Después de una clase con mucha reflexión (pero no de .net), se nos propuso la idea de pensar bien que tipo de profesional/programador/persona se puede llegar a ser. Inmediatamente se me vino a la mente como rayos hacer para ser un mejor programador/analista de sistemas.
Lo interesante de todo esto fue hablar de la creatividad, definida por el exponente del curso como una forma de apertura... y es eso exactamente... o al menos es una definición muy acertada y expuesta en un lenguaje que todos los asistentes pudiéramos entender.
Y quiero agregar que para los sicólogos...

La creatividad es la identificación, planteamiento o solución de un problema de manera relevante y divergente.

Divergente es la palabra clave para concatenar con la idea del principio.
¿Que tiene que ver todo esto con programar mejor? simple amigo:
Un buen programador es, y sera bueno hasta que no deje de, ser creativo.
No perderá su apertura: al cambiar su metodología e innovará constantemente, al no ser terco y al no dejara de aprender... como bien dijeron: "Dejar de aprender, es perderle el gusto a la vida" (Gracias JRCM).

En el momento en que el programador (u otra persona) cierra su mente a una mejor solución por seguir el viejo camino: ese sera el día en que la amargura se empalme en su código y pierda su habilidad para solucionar los problemas informáticos que le presenten. La belleza de su código y el arte, con la que soluciona problemas, se vera nublada con la negatividad que esa decisión tan fatídica crea en su vida.
¡Por Dios, es como una tragedia griega! y claro que lo es...
Es tan trágico como la muerte del Tío Periquito:

Y tan trágico como Monet ciego en 1923 y muriendo de cáncer pulmonar en 1926...

Waterlilies (Lirios de Agua), 1920-26

Es buen habito para el programador mantener su mente abierta a nuevas posibilidades y horizontes. Hacer todo lo posible para mantener su capacidad de análisis y su creatividad al máximo, en todo momento.
Y esto no es solo aplicable para un programador o analista de sistemas...

es aplicable evidentemente, para TODOS.

Programando Mejor [Parte I]

En el mundo de la programación, existen miles de lenguajes (funcionales o no) que sirven para el único propósito de hacer mas fácil la comunicación con las computadoras... decirles como hacer una tarea, ordenarles que hacer y como hacerlo. Cada lenguaje sirve para propósito diferente, es tarea constante para el programador buscar el lenguaje perfecto para que se sienta cómodo y sea más productivo. Pero entre mas de 1000 lenguajes, esta tarea es como buscar a la pareja perfecta para trabajar en la torre de Babel...


Muchos no saben quizás que el programador siempre busca que su código se "vea bien".
El programador experimentado puede conocerse por su código: los nombres de variables son significativos, utiliza sangrías (tabulación), comenta su código de forma ordenada, entre otras buenas costumbres:


En cambio el novato deja mucho que desear...


Por algún lado tenemos que empezar, ¿no?.
Uno de los problemas principales en la actualidad a la hora de programar, es la falta de modularidad en el código. Muchos (pero muchos) programadores creen que sus clases tienen que hacer de todo. Estas clases todo (o super clases) son en realidad, El Santo Grial del programador... es decir... la búsqueda inalcanzable de:

la ultima clase objeto super abstracta genérica y su jerarquía.

"Imagen tomada del comic: c0ders"

Y claro, en esa búsqueda se termina en una bola de código (basura) gigante.
Un ejemplo visual perfecto para esto, es un juego que se asemeja mucho al problema que menciono, este juego es Katamari Damacy, que consiste en rodar una bola pegajosa llamada katamari, a lo largo y ancho de distintas pantallas, recolectando todo tipo de objetos hasta que la bola se convierte en una gigantesca esfera de basura... casi lo que sucede con el código de muchos de nosotros:


La analogía es ideal: el código comienza pequeño (como la bola de katamari) y termina acumulando miles de lineas de código inútiles... una clase en donde falla la abstracción y la modularidad. La probabilidad de que un proyecto de software falle esta directamente relacionada con el tamaño del mismo. Y la relación entre lineas de código y bugs (errores) es completamente linear. Menos código significa menos errores. Si el código es mas corto, se evita el síndrome de
ML; NL, es decir: "Muy Largo; No leí"
(y en ingles TL;DR : "Too Long; Ditn't Read").
Si hay menos código para leer y es más entendible, son mas altas las probabilidades de que alguien realmente lo lea.

Hasta la próxima!

Programando Mejor [Parte I]

En el mundo de la programación, existen miles de lenguajes (funcionales o no) que sirven para el único propósito de hacer mas fácil la comunicación con las computadoras... decirles como hacer una tarea, ordenarles que hacer y como hacerlo. Cada lenguaje sirve para propósito diferente, es tarea constante para el programador buscar el lenguaje perfecto para que se sienta cómodo y sea más productivo. Pero entre mas de 1000 lenguajes, esta tarea es como buscar a la pareja perfecta para trabajar en la torre de Babel...


Muchos no saben quizás que el programador siempre busca que su código se "vea bien".
El programador experimentado puede conocerse por su código: los nombres de variables son significativos, utiliza sangrías (tabulación), comenta su código de forma ordenada, entre otras buenas costumbres:


En cambio el novato deja mucho que desear...


Por algún lado tenemos que empezar, ¿no?.
Uno de los problemas principales en la actualidad a la hora de programar, es la falta de modularidad en el código. Muchos (pero muchos) programadores creen que sus clases tienen que hacer de todo. Estas clases todo (o super clases) son en realidad, El Santo Grial del programador... es decir... la búsqueda inalcanzable de:

la ultima clase objeto super abstracta genérica y su jerarquía.

"Imagen tomada del comic: c0ders"

Y claro, en esa búsqueda se termina en una bola de código (basura) gigante.
Un ejemplo visual perfecto para esto, es un juego que se asemeja mucho al problema que menciono, este juego es Katamari Damacy, que consiste en rodar una bola pegajosa llamada katamari, a lo largo y ancho de distintas pantallas, recolectando todo tipo de objetos hasta que la bola se convierte en una gigantesca esfera de basura... casi lo que sucede con el código de muchos de nosotros:


La analogía es ideal: el código comienza pequeño (como la bola de katamari) y termina acumulando miles de lineas de código inútiles... una clase en donde falla la abstracción y la modularidad. La probabilidad de que un proyecto de software falle esta directamente relacionada con el tamaño del mismo. Y la relación entre lineas de código y bugs (errores) es completamente linear. Menos código significa menos errores. Si el código es mas corto, se evita el síndrome de
ML; NL, es decir: "Muy Largo; No leí"
(y en ingles TL;DR : "Too Long; Ditn't Read").
Si hay menos código para leer y es más entendible, son mas altas las probabilidades de que alguien realmente lo lea.

Hasta la próxima!

El lenguaje de programacion perfecto...

Hace unos meses, comencé de nuevo con un sueño olvidado hacia tiempo.
Este sueño es usar mi sistema GNU/Linux de manera diaria para quitarme terrible daño cerebral que dejo en mi vida usar Windows (desde el 3.11 hasta XP).
Y no es que Windows sea malo... es una buena idea pero esta TERRIBLEMENTE implementada y
simplemente para mi: tiene fecha de vencimiento.
Ahora me siento orgulloso de decir que solo utilizo Windows para imprimir mis ebooks... lastima que todavía lo utilizo... gracias Canon por no hacer drivers adecuados para tus malditas impresoras.

Claro, el proceso no fue fácil, eventualmente me di cuenta de que tenia los pies en el lodo mas de lo que parece... ha sido un largo camino, lleno de cambios de distribuciones, descargas interminables y discrepancias entre los mismos usuarios de GNU/Linux a los que acudía. Fue tan errático que hasta pensé en usar FreeBSD pero esa es otra historia.
Entonces desde que comencé con el proceso de migración solo me he preguntado algo que todo mundo que pasa por este proceso llega a preguntarse alguna vez...

¿Que uso para programar en GNU/Linux?

Y esa, querido lector, no es una pregunta fácil de contestar, porque hay un sin fin de lenguajes de desarrollo en este sistema. Y es que eso lo hace tan IMPORTANTE para un desarrollador de software.
Como el sistema es abierto y contiene una extensa (y muchas veces detallada) información acerca de su funcionamiento, es "fácil" para el programador adiestrado usar una herramienta adecuada (flex o bison) para crear la sintaxis de un lenguaje y tener en poco tiempo un interprete (de moda por el asunto multiplataforma) o un compilador.

Tan variada es la fauna de los lenguajes como los nombres que estos tienen:

Lisp, Fortran, Ada, Haskel, BASIC, C#, C/C++, Python, Pascal, Cobol...

Para ver una lista mas detallada click aquí

Y existen algunos tan ofuscados y oscuros, como los hay "esotéricos".

Brainfuck, Ook!, COW, Boolfuck, Nanopond, f*ckf*ck, Braintwist, Befunge...

Mi favoritos en lo personal Zombie y Brainfuck.
Muchos de estos surgen de la verdadera búsqueda del lenguaje perfecto para desarrollar y otros por simple diversión.

Pues bien, ahora tienen una idea de todo lo que hay y que (MUY probablemente) este implementado en GNU/Linux.
En este colorido camino, re-formulamos la pregunta anterior:

¿Que deseo desarrollar?
Y añadimos:
¿Deseo que sea multiplataforma?

Por que si bien Microsoft nos enseño que TODOS podemos usar una computadora, no nos ha enseñado que el Sistema Operativo debe de ser el que se adapta a mis necesidades y no al revés.
Y si bien BASIC (en todas sus horribles metamorfosis) nos demostró que TODOS pueden "programar" (mal la mayoría de las veces) no nos enseño que existe una variedad de lenguajes de programación orientados a funcionalidades especificas y que estos pueden facilitar la vida en ciertas áreas complicadas del desarrollo de soluciones informáticas.
Tomemos el caso de la Inteligencia Artificial, área truculenta de la codificación de algoritmos, que seria un suicidio mental implementar con COBOL o FORTRAN... señoras y señores para esos casos existe LISP.

Y es que al final, quizás esa es la primera lección del "programador": aprender a distinguir que lenguaje usar (que en gustos no hay nada escrito, pero por favor sean realistas) y en que caso usarlo ya que "La lógica es la misma, la implementación es la que cambia".

Hasta la proxima!.

El lenguaje de programacion perfecto...

Hace unos meses, comencé de nuevo con un sueño olvidado hacia tiempo.
Este sueño es usar mi sistema GNU/Linux de manera diaria para quitarme terrible daño cerebral que dejo en mi vida usar Windows (desde el 3.11 hasta XP).
Y no es que Windows sea malo... es una buena idea pero esta TERRIBLEMENTE implementada y
simplemente para mi: tiene fecha de vencimiento.
Ahora me siento orgulloso de decir que solo utilizo Windows para imprimir mis ebooks... lastima que todavía lo utilizo... gracias Canon por no hacer drivers adecuados para tus malditas impresoras.

Claro, el proceso no fue fácil, eventualmente me di cuenta de que tenia los pies en el lodo mas de lo que parece... ha sido un largo camino, lleno de cambios de distribuciones, descargas interminables y discrepancias entre los mismos usuarios de GNU/Linux a los que acudía. Fue tan errático que hasta pensé en usar FreeBSD pero esa es otra historia.
Entonces desde que comencé con el proceso de migración solo me he preguntado algo que todo mundo que pasa por este proceso llega a preguntarse alguna vez...

¿Que uso para programar en GNU/Linux?

Y esa, querido lector, no es una pregunta fácil de contestar, porque hay un sin fin de lenguajes de desarrollo en este sistema. Y es que eso lo hace tan IMPORTANTE para un desarrollador de software.
Como el sistema es abierto y contiene una extensa (y muchas veces detallada) información acerca de su funcionamiento, es "fácil" para el programador adiestrado usar una herramienta adecuada (flex o bison) para crear la sintaxis de un lenguaje y tener en poco tiempo un interprete (de moda por el asunto multiplataforma) o un compilador.

Tan variada es la fauna de los lenguajes como los nombres que estos tienen:

Lisp, Fortran, Ada, Haskel, BASIC, C#, C/C++, Python, Pascal, Cobol...

Para ver una lista mas detallada click aquí

Y existen algunos tan ofuscados y oscuros, como los hay "esotéricos".

Brainfuck, Ook!, COW, Boolfuck, Nanopond, f*ckf*ck, Braintwist, Befunge...

Mi favoritos en lo personal Zombie y Brainfuck.
Muchos de estos surgen de la verdadera búsqueda del lenguaje perfecto para desarrollar y otros por simple diversión.

Pues bien, ahora tienen una idea de todo lo que hay y que (MUY probablemente) este implementado en GNU/Linux.
En este colorido camino, re-formulamos la pregunta anterior:

¿Que deseo desarrollar?
Y añadimos:
¿Deseo que sea multiplataforma?

Por que si bien Microsoft nos enseño que TODOS podemos usar una computadora, no nos ha enseñado que el Sistema Operativo debe de ser el que se adapta a mis necesidades y no al revés.
Y si bien BASIC (en todas sus horribles metamorfosis) nos demostró que TODOS pueden "programar" (mal la mayoría de las veces) no nos enseño que existe una variedad de lenguajes de programación orientados a funcionalidades especificas y que estos pueden facilitar la vida en ciertas áreas complicadas del desarrollo de soluciones informáticas.
Tomemos el caso de la Inteligencia Artificial, área truculenta de la codificación de algoritmos, que seria un suicidio mental implementar con COBOL o FORTRAN... señoras y señores para esos casos existe LISP.

Y es que al final, quizás esa es la primera lección del "programador": aprender a distinguir que lenguaje usar (que en gustos no hay nada escrito, pero por favor sean realistas) y en que caso usarlo ya que "La lógica es la misma, la implementación es la que cambia".

Hasta la proxima!.