Archive for the '3463' Category

Rearmando Smalltalk (Smalltalk from Scratch)

Thursday, May 1st, 2014

Pienso que Smalltalk es una tecnología maravillosa que ha influenciado la programación durante las pasadas décadas. Pero no directamente: su influencia mayor no ha sido a través de uso o de aparición de “killer apps” sobre Smalltalk. Lo que veo que ha pasado es que Smalltalk influenció a programadores. La marca de las ideas de Smalltalk se pueden rastrear en las decisiones de diseño de lenguajes como Python y Ruby. Y muchos programadores se han visto atraídos por las ideas de Smalltalk, trantándolas de aplicar a otros ámbitos. Pero Smalltalk, como tecnología, no ha tomando al mundo. Podemos discutir las razones: una temprana “balcanización” de los proveedores, la falta de una temprana implementación de código abierto. Mi postura: está muy ligado a su propia “GUI IDE”, y es un poco demasiado (tiene demasiadas piezas).

Pienso que es tiempo de explorar caminos alternativos. Durante años, visité tecnologías, lenguajes, y en la pasada década y media (más o menos), tomé de nuevo a Smalltalk, intentando encontrar uno de esos caminos alternativos.

Pienso que un camino a explorar es intentar armar un Smalltalk más simple. Un Smalltalk no tanto ligado a una GUI ID, no ligado a miles de clases. Me imagino una implementación simple que pueda acceder al resto de los avances de programación (como el ecosistema de Node.js).

Para poner manos en la masa, estuve armando tres implementaciones: Smalltalk sobre .NET, en Java y en los últimos tres años en JavaScript/Node.js:

https://github.com/ajlopez/AjTalk
https://github.com/ajlopez/AjTalkJava
https://github.com/ajlopez/AjTalkJs

Más información en posts en http://ajlopez.wordpress.com/category/smalltalk/ y en http://msmvps.com/blogs/lopez/archive/tags/Smalltalk/default.aspx

Pero este post no es para repasar esas implementaciones. Lo que quisiera es pasar en limpio, escribir sobre algunas ideas sobre cómo crear un Smalltalk, sin tener que pasar por el achicamiento de imágenes de uno ya existente.

El Núcleo

Pienso que se puede armar un nuevo Smalltalk, desde un núcleo mínimo. Para eso, podemos partir de un Smalltalk que ejecute albergado por otra tecnología, como puede ser .NET, Java, o JavaScript, o cualquier otra. Pero es hora te dener un Smalltalk que no sea tan aislado, que converse con un ecosistema: tiene que apalancar lo logrado en otros ámbitos. Por ejemplo, un Smalltalk ejecutando sobre JavaScript puede acceder a todo el ecosistema de ese lenguaje, o al ecosistema de Node.js si estamos trabajando en el servidor.

El núcleo de Smalltalk debería implementar:

Object: el objeto y clase base, con algunos métodos iniciales como #subclass:.

Array: para arreglos con acceso por índice numérico, comenzando desde 1 para no romper con la tradición Smalltalk.

Dictionary: para mapear claves (nombres) a valores.

Tipos Primitivos: para acceder a la tecnología albergadora (.NET, Java, JavaScript), a sus tipos primitivos.

Aceso a tipos y objetos nativos: para crearlos, llamar sus métodos de tipo y de instancia.

La Librería

Primero, una implementación mínima de algunas clases, que pueden ser empaquetadas en una implementación inicial.

Pero luego, viene algo importante: tratar de vivir en un ecosistema de paquetes. En vez de tener centenares o miles de clases, que cada aplicación pueda referenciar y obtener los paquetes de un ecosistema. En mis implementaciones, he tomado el camino de usar NPM (Node Package Manager) para publicar y consumir paquetes, para instalarlos por aplicación, aún usando las versiones específicas que necesite cada aplicación y paquete.

Algunos candidatos a paquetes, como ejemplo:

– Una librería de tests (con un método assert)
– Un servidor HTTP
– Un framework MVC (tengo un ejemplo en Smalltalk sobre JavaScript/Node.js usando Express)
– Mensajes distribuidos (tengo una implementación en C#, el objetivo de este año es tener algo similar en JavaScript/Node.js)
– etc.

De esta manera, la adopción de un paquete será más fácil: no se necesita portar un paquete a otro dialecto, sólo consumirlo, teniendo las dependencias en su lugar. Para eso, cada paquete describe las dependencias que necesita.

Items Adicionales

Quiero implementar ambientes/environments: cada clase o paquete puede cargar otras clases pero para uso interno, sin interferir con el ambiente Smalltalk global, previniendo colisión de clases y versiones.

Otra cosa que quiero es poder ejecutar más de una imagen al mismo tiempo. Y que una imagen ayude a otra. Por ejemplo, que una imagen chica pueda ir agregando métodos a sus clases, pero los métodos de compilación los encuentre en otra imagen. De esta forma, una imagen puede comenzar chica, de poco tamaño, siendo ayudada por otra para ir creciendo e implementando los casos de uso que necesita. De esta forma, nos evitamos tener que partir de una imagen grande, e ir reduciédola. Tengo una implementación de estas ideas en mi versión de Smalltalk en C#.

En algunas implementaciones, quiero una imagen (para leer y grabar). Pero primero puedo explorar hasta donde llegar sin tener la necesidad de persistir una imagen.

Cualquier GUI debería ser creada fuera del núcleo, tal vez usando el ambiente albergador. Por ejemplo, usar Windows.Form si estamos sobre .NET o Mono, o Swing o SWT si estamos en Java, o el notable Canvas en caso de HTML5/JavaScript. Pero la idea es que el manejo de la GUI tiene que estar claramente separado de la implementación núcleo. Los Smalltalk populares actuales están muy ligados a la GUI que contienen en toda imagen. Veamos otras tecnologías: Python, Ruby, Node.js, Go, etc… Hay multitud de ellas que avanzaron sin estar ligadas a una GUI y a una IDE. Y sus programadores siguien creando aplicaciones útiles.

Como siempre digo: hay que explorar. Ese es el verbo a usar. Tenemos que explorar caminos alternativos, aún cuando no queden en claro la ganancia a obtener. Si hubiera visto, a esta altura, alguna “killer app” en Smalltalk, o el uso de Smalltalk para la creación de aplicaciones (como pasa en Python, Ruby, Java, JavaScript, Node.js, .NET, y otros), yo no pensaría de esa forma. Pero por alguna razón, Smalltalk no llegó a ese estadío. Veo entonces que hay alternativas, flotando alrededor nuestro, listas para ser exploradas.

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

La Desaparición de la Programación

Sunday, April 20th, 2014

Hace unos meses, escribí:

El Futuro de la Programación

Donde enumeraba unos puntos a considerar y a resolver sobre lo que nos espera en el futuro. Muchos de nosotros tenemos la programación como profesión, y además nos fascina. Pero ademas de lo que nos puede gustar, tenemos que ver cuál es el impacto en la sociedad y en la historia humana.

Para mí, el desarrollo de software apalanca gran parte de las actividades humanas. Recordemos lo que era el diseño en arquitectura hace unas décadas, o lo que era comunicarse con otra persona usando solamente un teléfono. O intercambiar trabajos por correo físico. Lo que ha influido el desarrollo de software en todo esto, es grandísimo. En algún milenio que viene, verán a la prehistoria humana como la época donde no había información digitalizada ni software ni hardware. Tanto la información como su proceso, se han incrementado en varios órdenes en los últimos tiempos (tendría que revisar el final de “La conexión cósmica” donde Carl Sagan clasifica las civilizaciones por la cantidad de datos?/información? que producen y manejan).

Es por eso que es importante (no solamente interesante) plantearse esas cuestiones, y preguntar también por el futuro de nuestra profesión. No para hacer lo que nos gusta, sino para ver en qué forma podemos contribuir a que todos estos cambios sean para mejor. Por eso planteaba varios de los puntos de ese post, y uno era:

– Desaparición: ¿cuándo desaparecerá la programación?

Pienso que tenemos que explorar el camino: hacer desaparecer la necesidad de nuestra profesión. No creo que desaparezca, pero es un buen ejercicio ver qué se puede hacer para que el desarrollo de software no sufra la falta de programadores, y hacerla crecer (¿quizás apalancada con software más “inteligente”?)

En una lista de correo, alguien planteó que esto es “una falta de respeto” a la profesión. Bueno, estuve meditando, y no encuentro falta de respeto en mi postura. Es como quejarse de falta de respeto a los cirujanos porque alguien invente curar la apendicitis con una pastilla. O de falta de respeto a los dibujantes técnicos ante la aparición del Autocad. Todo cambia en las actividades humanas, y tenemos que explorar (noten el verbo, explorar) ese camino: ver cómo podemos acercarnos a la desaparición de la profesión. Como puse antes, no pienso que desaparezca, sino que cambie, y veo que tenemos una ventana de oportunidad para mejorar y conseguir más con menos. Si menciono lo de la lista de correo, es porque me asombra que se pueda interpretar de esa forma lo que escribo. Por favor, que nadie lo tome así. Recuerden el objetivo: mejorar en lo que podemos aportar a las actividades humanas, más allá de la profesión o de lo que nos guste hacer. Si podemos aportar más, con menos, creando agentes u otras formas de escribir software, o haciendo la programación más fácil, ¿por qué no hacerlo?

Yo respeto mucho a las tecnologías que han podido hacer que más personas tengan acceso a hacer cosas. En el ámbito de la programación,  podría poner como ejemplo a Ruby on Rails: claro que por abajo es un código enrevesado, inflado, con cosas demás o que podrían mejorarse mucho. Pero ese no es el punto principal. El punto es que ese código (“horrible” si quieren verlo) ha posibilitado la creación de más software, y no me queda duda que ha sido para mejorar. Tomemos PHP: ¿quién no ha criticado a PHP como lenguaje? ¿cuánto tardó para tener una implementación de objetos aceptable, y namespaces? Sin embargo, ahí está PHP alimentando a WordPress, Facebook y otros sitios. Rasmus Lerdorf y otros, con PHP, cambiaron la historia humana. En estos ejemplos, pienso que es importante separar lo que nos gustaría que fuera en lo técnico (mejores clases en Rails, con mayor separación de “concerns”; mejor implementación básica de PHP; etc…), de lo que realmente son: grandes herramientas que han hecho posible tantas cosas.

En estos últimos años me he ido alejando de la posición de “ingeniero de software”, deteniéndome en todos los detalles técnicos que podría mejorarse en una implementación, o declamando sobre todos los patrones y “mejores prácticas” que tenemos “casi la obligación” de aplicar, porque si no, lo que hagamos será “poco profesional”. Lo que me importa al final del camino: el valor que una herramienta puede aportar (y el costo de conseguir ese valor).

But I digress… Volvamos a la “desaparación” de la profesión y a la generación del software.

Los que me leen (digamos yo y mi tía Carlota ;-), saben cuál es el camino que quiero explorar en eso que planteo más arriba: la aplicación de la inteligencia artifical a la creación de software (perdón, de nuevo, ¿es “falta de respeto” a los jugadores de ajedrez la creación de un Deep Blue que le gane a Kasparov? para poner otro ejemplo).

El otro camino: hacer que la programación esté al alcance de gente que no es profesional del tema. Habrá que discutir cuál es la forma para esto: ¿mejores lenguajes? ¿formas visuales de programar? ¿ecosistemas de pequeños módulos que interactúen por Internet, y que cada uno pueda sumar su módulo? ¿”application stores” que puedan ser llenadas por aplicaciones generadas por no programadores? Hay mucho para investigar en este tema.

Pero, como decía Perón: “mejor que hablar es hacer, mejor que prometer es realizar” (bien, ya veo que con mi suerte para ser interpretado, esta frase va a tener derivaciones políticas ;-). Si ven lo que escribo cada día, en código o en posts, casi siempre toca alguno de los caminos mencionados arriba: o hacer programas que creen programas, o hacer que la programación esté al alcance de más personas, sean programadores profesionales o no. Todo dentro de lo que puedo ver, pensar y hacer.

Los invito a pensar sobre estos temas, y también a hacer. Por ejemplo: ¿es importante este tema, el futuro de la programación y “luchar por su desaparición”? ¿o realmente el futuro será el que diga que hacer? ¿hay que acercar la programación a más gente? ¿o es mejor cultivar la profesión y mejorar como profesionales? ¿es un “o” exclusivo? Y ante la respuesta que pueda encontrar cada uno, hacer algo para acercarse a ella.

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

Always Be Coding

Tuesday, April 8th, 2014

Como profesionales del desarrollo de software, debemos perseguir ser cada vez mejores programadores. Una actividad que he adoptado en los últimos años, es: “Always Be Coding”, siempre estar programando. Cada día, escribir una pieza de código. Intentar algo nuevo. Mejorar lo viejo. Abrir el cerebro. Explorar nuevos caminos. Escribir un nuevo lenguaje. Practicar TDD cada día. Empujar por la simplicidad. Comenzar un simple proyecto “Hello world” usando un nuevo lenguaje, tecnología, sistema operativo. Escribir un simple sitio web usando el nuevo framework de moda. Si escribimos en C# o Java, intentar Ruby o Clojure. Si usamos Ruby on Rails, pasar aunque sea a intentar Sinatra, o hacer un cambio a Python con Django. Si nos gusta Lisp, ver de usar ClojureScript en un proyecto web. Si nos gusta Smalltalk, probar Pharo con Seaside. Si somos “geek” de los lenguajes de programación, ir por Rust, Go, Dart. Si escribimos ASP.NET MVC en nuestro trabajo diario, probar SignalR, entonces cambiar a Node.js y Socket.IO. Cambiemos de editor. Cambiemos de lenguaje de programación. O escribamos uno nuevo.

Aún cuando todos estos lenguajes, tecnologías, librerías, frameworks, no estén en lo que hacemos diaramente en el trabajo usual, lo que aprendemos por explorar algo nuevo es bienvenido. Y la práctica constante hace al maestro. Si mantenemos el cerebro abierto, nuevas ideas podrían fertilizar nuestra mente y agregar algo a nuestra caja de herramientas/habilidades. En nuestra profesión, lo único constante es el cambio. Aunque hay otros temas para practicar, como habilidades “blandas”, trabajo en equipo, también debemos (yo y uds) practicar cada día las habilidades más duras, y perserguir el “craftmanship”.

Así, para poner el dinero donde pongo la boca, cada día escribo una pieza de código, en repositorios públicos y no públicos. Evidencia parcial:

Van a ver que también dejo evidencia en la historia de “commits” de mi flujo de trabajo usando TDD.

Ese es mi compromiso público: escribir código cada día. Para aprender algo nuevo, practicar alguna habilidad, explorar nuevas formas de hacer algo. “Always be coding”!

Foto orignal de http://atechnologyjobisnoexcuse.com/2012/04/coffees-for-coders/

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

Make It Work, Make It Right, Make It Fast

Sunday, February 23rd, 2014

Hace unos años, me topé con esta frase aplicada al desarrollo de
software:

”Make It Work, Make It Right, Make It Fast”

Es decir, algo como:

“Primero que funcione, luego hacerlo bien, luego hacerlo rápido”

No recuerdo la fuente original. Frecuentemente se la atribuye a Kent Beck,
pero parece que hay precedentes, ver:

http://c2.com/cgi/wiki?MakeItWorkMakeItRightMakeItFast

En la última década, comencé a comprender la aplicación de estos consejos, y
realmente pienzo que mis habilidades de desarrollo de software se vieron
mejoradas por adoptar esta manera de hacer las cosas. Podría asociar los dos
primeros pasos con TDD (Test-Driven Development), pero se puede emplear la frase
en contextos más amplios. Revisemos que pienso de cada parte, y cómo las aplico
cada día.

Make It Work

Sí, en vez de intentar hacer “LO CORRECTO” desde el vamos, pongo primero mi
esfuerzo en hacer algo que funcione (una función, un método, un rama de un caso
de uso, una experiencia de usuario). No me preocupo por si la implementación
interna es la mejor, ni trato de aplicar todos los patrones del libro. Escribo
código que funciona. Simple código, y que funciona. Siguiendo esta
recomendación, veo que escribo código simple, que me permite ir comprendiendo el
dominio del problema. Si lo que tengo que estregar es una rama de un caso de uso
(no un caso de uso completo), el entregable puede que arroje luz sobre el modelo
de negocios del dominio, y aún permite una retroalimentación temprana de parte
de los usuarios de la aplicación.

Sin embargo, si hubiera intentado desde el vamos hacer “lo correcto”, podría
haber perdido mi tiempo y esfuerzo en algo que no es seguro que es lo que el
sistema y los usuarios necesitan.

Como caso especial de aplicación de esta máxima: “make it work” es una parte
esencial de TDD, el segundo paso: hacer que el test pase a verde.

Make It Right

Solamente cuando ya tengo algo de código andando como quiero, vuelvo a él y
lo mejore. Puedo remover duplicación de código, aplicar algún patrón porque me
lo pide el contexto (evito aplicar un patrón solamente por un impulso
irresistible de “patronitis”), exploro nuevas implementaciones alternativas.
Esta es la oportunidad de remover o hacer decrecer cualquier dueda técnica que
haya quedado, cualquier reliquia de código tóxico. Si veo algo que está
implementado de forma extraña, voy y lo trato de reescribir mejor.

Cuando lo que escribo lo escribo siguiendo el flujo de trabajo de TDD, aplico
este consejo en el paso de refactoreo. TDD me ayuda a controlar el nivel de
deuda técnica, manteniéndolo a un nivel bajo. Y teniendo todo escrito bato
tests, puedo explorar con confianza otras implementaciones alternativas, sin
sufrir en el proceso. Es realmente un paso creativo. Algunos programadores
pinesas que TDD obstruye la creatividad, pero yo veo lo contrario: estos dos
pasos son una forma de ejercitarla.

Make It Fast

Solamente entonces me preocupo de la velocidad de ejecución, y cuando el caso
de uso y contexto lo amerita. Hay tantos factores que pueden influir en el
rendimiento, que sólo me pongo a revisarlo cuando YA tengo una implementación
andando. Si Uds. tienden a escribir código en las anteriores fases, pensando en
“esto lo pongo así, porque de esta manera la ejecución va a ser más rápida”, les
pediría que revisen su actitud. Yo no sé (y Uds. tampoco) si un métod será lo
suficientemente rápido, si no tenemos un claro caso de uso que necesita tal
nivel de velocidad, y sin haber MEDIDO el rendimiento antes de la optimización.
No optimizar lo que no se mide.

Más veces de las que hubiera deseado, me encuentro con proyectos donde se
tomaron decisiones apresuradas pensando en el reandimiento: alguien que agrega
procedimientos almacenados “porque son más rápidos”, pero sin tener evidencia de
esa afirmación, sin ninguna prueba automatizada que mida realmente el
rendimiento. Y entonces, comienza a emerger en el medio del sistema, un
procedimiento almacenado de cientos de líneas, con lógica de negocio incluida,
porque “así es más rápido”. Y peor, escrito sin tests.

Luego de haber practicado esta frase en mis proyectos personales y
profesionales, les puedo asegurar que realmente me he beneficiado de seguir
estos consejos. Es un placer ver cómo una idea crece hasta llegar a una
implementación concreta y sólida.

Nos leemos!

 

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

El Futuro de la Programación (1)

Thursday, August 29th, 2013

El gran Microsoft User Group de Argentina cumple 18 años de existencia. Recuerdo cuando comenzó como un desprendimiento de otro grupo (el Club Byte) y los idas y vueltas de su crecimiento. Antes de la llegada de las redes sociales y la ubicuidad de la web, fue el lugar donde se podía discutir en persona, compatir intereses, dudas y descubrimientos. Cuando llegó a los 10 años, dí una charla sobre la historia de la programación. Creo que es apropiado ahora ponerme a escribir sobre el futuro de la misma.

En estos días, vuelvo a leer la conferencia de David Hilbert, en el Congreso Internacional de Matemáticas, Paris, 1900. En el principio, encuentro:

¿Quién de nosotros no se alegraría de levantar el velo tras el que se oculta el futuro; de echar una mirada a los próximos avances de nuestra ciencia y a los secretos de su desarrollo durante los siglos futuros? ¿Cuáles serán los objetivos concretos por los que se esforzarán las mejores mentes matemáticas de las generaciones venideras? ¿Qué nuevos métodos y nuevos hechos descubrirán las nuevas centurias en el amplio y rico campo del pensamiento matemático?

La historia nos enseña que hay continuidad en el desarrollo de la ciencia. Sabemos que cada época tiene sus propios problemas, que la época siguiente o bien resuelve o bien desecha por estériles y reemplaza por otros nuevos. Si tuviésemos una idea del desarrollo probable del conocimiento matemático en el futuro inmediato, deberíamos dejar pasar ante nuestras mentes las preguntas no resueltas y examinar los problemas que la ciencia de hoy plantea y cuya solución esperamos del futuro. El día de hoy, a caballo entre dos siglos, me parece muy adecuado para hacer una revisión semejante de los problemas. Pues el cierre de una gran época no sólo nos invita a mirar hacia el pasado, sino que también dirige nuestros pensamientos hacia el futuro desconocido.

Ver

http://aleph0.clarku.edu/~djoyce/hilbert/problems.html

El tema programación es muy dinámico, y no me atrevería a encarar la historia del próximo siglo. Pero puedo ir explorando algunos puntos.

Primero, siguiendo a Hilbert, voy a examinar algunos problemas que le quedan pendiente al tema programación. Revisaré la historia de cada problema, la tendencia actual, y cómo podemos proyectarla hacia el futuro. Esa proyección podrá ser para dentro de cinco años, diez o más décadas. Más allá de eso, no creo que pueda avanzar con cierta seguridad.

Segundo, aparte de plantear problemas generales, puedo ir planteando la pregunta final: ¿cuál es la programación que se usará en la Enterprise de Star Trek? Pueden leer que algo ya había encarado en un post:

http://msmvps.com/blogs/lopez/archive/2010/05/09/el-software-de-la-enterprise.aspx

Tercero, quiero destacar desde ahora algo: quienes estén leyendo esto, probablemente sean personas interesadas desde el vamos en la programación. Y todo este ejercicio podrá parecer apenas una especulación, un divertimento para programadores. Sin embargo, levanto la mano y digo: la programación, y su producto inmediato, el software, ha cambiado la historia humana. No sólo la programación: ha sido acompañado por el avance en hardware, y en comunicaciones que posibilitaron que desde hace décadas tengamos Internet (vean que es un “subproducto” de la guerra fría). Pero de una u otra forma, es necesario poner explícitamente: el futuro de la programación no es un tema menor. Lo que sí moderaría es: ese futuro será moldeado por muchas fuerzas, y apenas puedo hoy escribir algo de eso. El futuro vendrá y nos sorprenderá con algo, más allá de lo que esperamos.

Por ejemplo, cuando yo era un niño (sí, ya sé, desmiento que en aquel entonces todos los continentes eran uno solo; ya en mi infancia se había iniciado su separación :-), se especulaba que en estos tiempos íbamos a tener estaciones ubicadas en la luna, y que en vez de autos íbamos a volar en vehículos individuales (los de mi edad recordarán “Los supersónicos”, con nombre original “Jetsons”). Vean que no pasó nada de eso. Si bien Julio Verne pudo anticipar los submarinos, el cohete espacial y otros eventos, hay que buscar mucho en sus escritos para atisbar algo parecido a lo que es hoy Internet o su encarnación más presente, la Web. El más moderno Asimov, puso énfasis en robots, y apenas en alguna computadora Multivac: nunca puso en el tapete la posibilidad de tener una red que nos uniera (excepto quizás en alguna parte final de su “La última pregunta”), ni nunca reparó en la importancia de la programación como actividad separada (que apenas asoció con la configuración de harilidware).

Todo esto indica, que el trabajo de generar programas, la programación, llegó por sorpresa a la actividad humana.

Volvamos al tema problemas. ¿Qué problemas actuales guiarán el futuro de la programación? Propongo una lista, a explorar en futuros posts:

– Escalabilidad: atender una cantidad variable de usuarios clientes, sin morir en el intento.

– Ubicuidad: que los programas se encuentren disponibles desde cualquier lugar.

– Comunicación: que los programas puedan comunicarse entre sí.

– Composición: que un programa se pueda armar componiendo otros programas.

– Agentes: que los programas, más que una herramienta (algo que usamos, como una pala, para excavar un pozo) sean agentes (algo que actúa, como una persona que excava por nosotros)

– Inteligencia Artificial: que los programas consigan niveles de “pensamiento” humano

– Creación: que los programas sean creativos, no sólo que funcionen como los programamos

– Actuando en cuerpos autónomos: digamos, robótica autónoma.

– Generación automática: programas haciendo otros programas

– Nuevos lenguajes: o vino viejo en nuevos odres, evolución de los paradigmas.

– Desaparición: ¿cuándo desaparecerá la programación?

Me parece una lista interesante para ir explorando. Por ahora, basta con estos elementos. Si tienen algún otro problema a investigar para el futuro, me avisan por acá.

Nos leemos!

Angel “Java” Lopez

http://www.ajlopez.com
http://twitter.com/ajlopez
https://github.com/ajlopez

 

Ser Microsoft MVP

Saturday, August 3rd, 2013

Hace una semana participé de una reunión de MVPs (Most Valuable Professionals, ver What is an MVP?) en la sede local de Microsoft, acá en Buenos Aires, Argentina. Fue una reunión privada, así que no voy a comentar mucho de lo charlamos o temas privados. Seguramente los que la organizaron tendrán para compartir posts sobre los temas.

Pero sí quisiera hoy comentar algo que comenté en la reunión, y aprovechando este blog, poder explayarme más en detalle, dando más contexto. Tal vez ponga más enlaces de los necesarios, pero es para dar más panorama de lo que quiero expresar. Y también para cumplir con lo de Lo que no está escrito y en Google no existe.

En primer lugar, algo corto: hay diferencia entre ser MVP de IT de ser MVP de desarrollo. Veo que los MVPs de IT (Information technology, digamos, SQL Server, Exchange, Dynamics, … ) tienen otros problemas y tienen otro tipo de situaciones. Así que lo que sigue será dedicado más a ser MVP de desarrollo. De ahora en más, en este post, “MVP” será “MVP de desarrollo”, como soy yo, MVP de Visual C#.

¿Qué es ser MVP? Bueno, es un título otorgado por Microsoft, anualmente. Uno envía las actividades de los últimos doce meses, las evalúan (en un proceso no muy conocido) y luego llega un día en que anuncian por email si uno sige “in” o sigue “out” ;-). Si uno es MVP, participa de algunas reuniones (me gusta la cerveza, las papas fritas, las “picadas” que se arman 😉 y tiene acceso a algún beneficio, como una subscripción al MSDN (Microsoft Development Network).

Pero yo quisiera hoy escribir sobre algo que, siendo MVP, me parece que es la cuestión principal. Uno llega a MVP porque COMPARTE CON LA COMUNIDAD de desarrollo. MVP es, digamos, la “frutilla de la torta”, pero no es el objetivo, por lo menos para mí. Si uno quiere ser MVP, tiene que enfocarse, no en eso, sino en simplemente aprender Y COMPARTIR. Hay gente que me conoce y no sabe que son Microsoft MVP. Lo importante es colaborar con el desarrollo de software.

¿Y por qué? ¿por qué es importante? Bueno, a muchos MVPs (me incluyo) nos gusta programar. No es algo impuesto, realmente nos gusta. Pero a alguien se le puede dar eso de “me gusta programar”, pero también se le puede dar “no comparto nada, programo y punto”. Lo que veo es que la programación de software es una actividad importante, ver posts Software es más que software libre o código abierto, y El encanto del desarrollo de software. Y me gusta desde hace décadas, ver Treinta años en el desarrollo de software.

Pero más allá del gusto personal, veo que la creación de software es algo que permea y facilita las demás actividades humanas. Vivimos en una gran época, donde el software (y el hardware) han transformado la historia humana (basta señalar Internet y su más conspicua faceta, la web). ESO ES LO IMPORTANTE. No importan tanto los detalles, como tener la última beta, o saber la enésima función que aparece en ASP.NET MVC 17, sino en participar y difundir la creación de software.

En ese sentido, veo que mis actividades se dividen en:

A- Programar

B- Programar programas que creen programas

C- Colaborar para que haya desarrolladores que programen programas

La tarea A es la que más me gusta. Participo en proyectos privados, y también me entreno publicando proyectos abiertos. Pero prácticamente pasa desapercibida (ver Mi tía Carlota y yo). Pero no importa tanto eso. Lo importante para mí es entrenarme (especialmente en Test-Driven Development, y en varios lenguajes y tecnologías), y publicar (para no ser canuto). Luego se verá si es útil o no para los demás. Actualmente, ver mi cuenta de GitHub para trazar esta actividad.

La tarea B es casi mi proyecto de vida. Ver The joys of a forever project. Pueden ver mis posts y enlaces a trabajos aquí y aquí. En especial Generación de Código e Inteligencia Artificial.

La tarea C es la que ha quedado más visible. Comparto lo que voy viendo que parece interesante e importante, dí cursos (ya pagué mi cuota, ya no doy más), doy charlas (que me parece más liviano e importante), participo de videos (como las VAN de Alt.NET Hispano, podcasts, y ahora, mi serie TDD Rocks!). Difundo las reuniones que se van a realizar por mi zona (ver ejemplo), y hasta a veces las comento (ver ejemplo).

Posts relacionados con la tarea C, solo un “potpourri”:

Ser catalizador de cambios
Babel de lenguajes en .NET
Papas fritas, cervezas y una babel de esos raros lenguajes nuevos
Temas interesantes en el desarrollo de software
Estructura e interpretación de programas
Un programador pragmático
Aprendiendo de Jason Bourne

Y también:

Matriz de competencias de programación
Estrategia para ser mejor desarrollador
El programador humilde
Se necesitan desarrolladores no programadores
El mejor lenguaje, la mejor herramienta (busquen la cita de Rambo)
No somos vulcanos (que trata de explicar la existencia de algunas prácticas)
Los 10 mandamientos para crear buen código
Es tiempo de volver a la simplicidad (una de las raíces de mi actual “push” por programar usando TDD)
El software de la Enterprise (tratando de dar horizonte de lo que es el desarrollo de software en la historia)
Los principios de la buena programación

Y desde hace años, cumplo con

A post a day keeps the doctor away

Es importante conocer la historia de las cosas, ejemplos de posts:

La historia secreta de Silicon Valley
La historia de Smalltalk

Y un poco de humor 😉

Tato Bores y el desarrollo de software
Si los aviones fueran armados por programadores

Y lo que no alcanzo a poner por acá, o en charlas, va a mi timeline de Twitter, y agregado a la historia de mi Delicious.

En los últimos años, me he dedicado a la difusión de:

Scrum
Test-Driven Development el flujo de trabajo que veo MENOS USADO (todos hacen agile, scrum, iteraciones, hasta pair-programming, pero pocos he visto usando TDD) Pienso que insistiendo en este tema, es donde puedo aportar más a la tarea C (y la practico diariamente en la tarea A)
Node.js con JavaScript me parece una “mantequita” de flexible.
Lenguajes, ambientes y ecosistemas, como Ruby, Python y Smalltalk.
Y cada tanto vuelvo a Inteligencia Artificial. Ver La inteligencia artificial y yo,

No sé si ayudará o no, a muchos o a pocos, si todo es “bueno”, seguramente es mejorable. Pero eso es lo que hace un MVP de desarrollo: compartir.

En el ambiente Microsoft, como Microsoft MVP, yo veo que la empresa ha evolucionado muchísimo, y en la última década tiene la gran oferta de .NET como framework, y Visual Studio. Igual yo opino:

Visual Studio debe ser gratis

Mi primer contacto con el software de Microsoft, fue a principios de los ochenta, con el compilador de línea de comando C, que era un comprado a Lattice. Luego sacó el propio. Hasta programé con Xenix, y usé Multiplan. Vi el nacimiento del MS-DOS, y el command.com. Vi el primer Windows con ventanas sin solapar (oia! Deja vu! Windows 8! ;-). Vi cómo se agotaban las cajas de Access su primera versión, acá en Buenos Aires. Vi la compra de Visual Fox. Vi la aparición de ese gran lenguaje y entorno que es Visual Basic. Vi …. y podría seguir. Recuerdo cuando la oficina de Buenos Aires estaba en 9 de Julio y Av. del Libertador (¿se llama así?) Vi el nacimiento de Microsoft User group. Vi….etc…etc…

Fue un post largo. En resumen:

– La actividad de software es importante
– Compartamos lo que vemos, aprendemos, leemos, hacemos, …
– Ser MVP me sirve para tener cerveza, papas fritas, y el Visual Studio 😉

Dejo de lado algo importante: ser MVP me hace conocer a otros MVPs, lo que me parece magnífico.

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
@ajlopez

Un Buen Proyecto (3)

Saturday, June 8th, 2013

Anterior Post

En los anteriores posts quedó claro que, en mi postura, lo importante de un proyecto es que resuelva (o ayude a resolver) el problema del cliente.

Bien, ¿dónde queda todo lo que aprendemos de patrones, OOP, y demás?

Imaginemos que tenemos que desarrollar un sistema que nos diga cual es el número de la lotería de este sábado que viene. Nada más: el cliente nos lo pide, para solucionar el problema “No tengo dinero para encarar otros proyectos e ideas que tengo”. Hacemos el programa, funciona y resuelve el problema del cliente: la falta de dinero.

¿Acaso a alguien le importa los patrones, OOP, SOLID o lo que sea? NO. Solamente importan en dos circunstancias:

– Porque nos ayudan (a nosotros, no al cliente) en el desarrollo actual

– Porque van a ayudar a la gente que haga la versión 2.0 de lo que estamos haciendo

Los patrones son para los programadores. Si el sistema lo armamos de una vez, y funciona, a nadie en el planeta la importaran los patrones que usamos. Mientras nos de el número de la lotería que el cliente necesita, estará todo bien.

Solamente interesa YAGNI, DRY (Don’t Repeat Yourself) y demás en esas dos ocasiones:

– Para nosotros, cuando estamos desarrollando y queremos refactorizar algo.

– Para quien venga luego de nosotros, en la versión 2.0, a mejorar, extender, adaptar lo que armamos.

Ejemplo del primer caso: imaginemos que el algoritmo que estamos usando tiene código repetido. Aplicamos DRY y refactorizamos, sólo para seguir avanzando en el desarrollo. Sino, no hace falta refactorizar. Si así como está, la aplicación ya funciona, a nadie le importa los patrones o cualquier otro factor de diseño que se nos ocurra. “Make it works”, lo primero que hay que obtener.

Pero si vemos que todavía no alcanzamos el objetivo, podemos refactorizar y mejorar la implementación. Es una especie de “Make it right”. Al tener ordenado y “patronizado” lo que estamos armando, es más fácil, en general, irlo modificando.

Si no entendemos eso, no sirve de nada saber patrones. Los patrones se aplican EN CONTEXTO, y para resolver un PROBLEMA en particular. No porque son “cool” o es lo que dicen los librso.

Ejemplo del segundo caso: si nuestro sistema es un ERP, que solamente contemplaba algunos casos de uso, en la versión 2.0 es posible que necesite cubrir otros nuevos casos. Es ahí donde se ve el poder de haber “patronizado” la versión 1.0. El mantenimiento, la extensibilidad, la refactorización será más fácil para el que venga. Recuerden: hay que codificar como si el que vieniera luego de nosotros, sea un asesino serial que conoce el domicilio de nuestra familia 😉 Tenemos que facilitarle el trabajo.

Por supuesto, no todo es codificación en un proyecto. Hay comunicación, explicar lo que estamos haciendo, su adopción, despliegue, etc… Pero antes de proseguir sobre el tema “proyecto bueno”, quería hacer esa aclaración: muchas de las “best practices” que adoptamos son para encarar de forma efectiva la refactorización actual, o la modificación futura. Si no necesitáramos refactorizar ahora (por ejemplo, escribiendo todo bien desde el principio), o no se necesitara la modificación futura (sistemas “one shot”, como obtener el número de la lotería del sábado que viene y nada más), no tendríamos que preocuparnos por patrones o “best practices”.

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

Un Buen Proyecto (2)

Thursday, May 23rd, 2013

Anterior Post 
Siguiente Post 

Ya tratamos el principal tema que nuestro proyecto tiene que cumplir para ser un buen proyecto: solucionar el problema al cliente. Puede que sea sólo un colaborador, entre otros proyectos, para llegar a esa solución. Por ejemplo, me pasa muchas veces que el proyecto que me toca es de programación de una aplicación, pero la solución total del problema implica su instalación, mantenimiento y adopción. Otras veces no: nuestro proyecto abarca toda su ciclo de vida, por lo menos de la primer versión.

Puede suceder algo que muchas veces se nos pasa por alto:

– No podemos estar seguros de que lo que entregamos es un buen proyecto al terminarlo y entregarlo.

Hay que ver si realmente funciona en el campo, en la vida real.

Pongamos un ejemplo. Sea nuestro cliente es una compañía de seguros y su problema es que está perdiendo clientes porque los productores de seguros tardan mucho en otorgarle una póliza o no. La solución evaluada es: poner una aplicación en línea que reduzca el tiempo de aceptación o rechazo de un día a quince minutos. Hacemos la aplicación, pero al llegar a desplegarse y ser usado se muere cada media hora por la presión de uso, y la causa es el código de nuestro proyecto. O peor, trabaja bien, soporta la carga, pero otorga aceptaciones a cualquier caso. En ambos casos, nuestro proyecto no habrá sido un “buen proyecto”.

Es por eso que en nuestro proceso es importante las pruebas de carga y las pruebas funcionales. A lo que voy, es que muchas de las actividades que realizamos terminan teniendo su origen en la necesidad de cumplir con ser un buen proyecto. Un proyecto puede parecer “bueno”: tener todo “en regla”, haber sido programado con todos los patrones, ante las entradas correctas dar el resultado correcto, pero fracasar en su implementación porque no revisamos que, así como lo tenemos programado, no soporta más de diez usuarios simultáneos.

Aparece la cuestión de la calidad de nuestro entregable. Podemos discutir luego si la calidad es responsabilidad del equipo ágil, o si hace falta un equipo aparte de QA (Quality Assurance). Pero vemos que todo esto es motivado por la necesidad de cumplir con lo que espera el cliente: la solución de su problema.

Para poner un ejemplo “al revés”: al cliente no le importa que lo que entregamos sea escalable como Facebook, si su problema y solución (digamos, un sistema de compras) necesita solamente atender a veinte usuarios (los representantes de sus proveedores principales).

En próximos posts: si una solución es exitosa, hay que mantenerla; el aporte de TDD y el proceso de desarrollo.

Nota personal: lo de no poder ver si es un buen proyecto al terminarlo, me fue sugerido por Aristóteles. No encuentro la cita ahora, pero cuando habla de “eudamonia” en su “Etica a Nicómaco”, habla de lo que yo traduzco como “buena vida”, “con los dioses a favor”. Dice Aristóteles que muchas veces, un hombre al morir no puede estar seguro de haber llegado a la “buena vida”: puede que el resultado dependa de su influencia en otros hombres, aún luego de su muerte. (me temo que Aristóteles hablaba de “hombres”, ciudadanos con derechos, y no de “seres humanos”; mujeres abstenerse, era el Borat de los filósofos ;-).

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

Un Buen Proyecto (1)

Thursday, May 16th, 2013

Siguiente Post

En mis charlas de TDD (Test-Driven Development) comento algunas características de lo que tendría que ser un proyecto bien terminado. Algo ya comenté en TDD y Diseño de Implementación (1). Hoy quiero escribir (es decir, pasar en limpio, compartir, explicar un tema para ver si lo entiendo) sobre un tema más amplio: lo que considero un buen proyecto. Pensé inicialmente que bastaría un solo post, pero nones: éste va a ser el primero, y luego seguiré escribiendo.

Pongo algo de contexto. Voy a escribir sobre un proyecto:

– Profesional

– Con desarrollo ágil en equipo, con iteractiones, backlog, etc..

– Cliente externo, con un representante

– Para ejecutar en producción

Es decir, no necesariamente tiene que ser de código abierto (en mi caso en general no es), no es algo que armamos en nuestro tiempo libre (no, es un proyecto de nuestro trabajo de desarrollo de software), no es una demo, va a estar en producción y tendrá un ciclo de vida (no necesariamente apoyado por nosotros: el proyecto tiene una terminación y una entrega final). Igual admito que es difícil abarcar todos los proyectos profesionales. Pero creo que con lo que voy a describir varios proyectos serán incluidos en esta exposición.

Entonces, en este marco, ¿cuáles son las características que tendría que tener un proyecto terminado para que digamos: “es un buen proyecto”? En el sentido de sentir y pensar que lo que entregamos es bueno. Claro, depende de bueno ¿para quién? Como estamos en un proyecto profesional, lo principal es que sea bueno para el cliente (empresa) que nos contrata. Puede ser bueno para nosotros (“uy, aprendí un montón de MVC”), para el equipo (“nos integramos y conocimos”), para nuestra consultora (“uy, con lo que ganamos podemos comprar nuevas oficinas”, o “ahora podemos ser conocidos por haber trabajado en este gran proyecto”), para el mundo (“ahora hay un nuevo framework que todos podrían usar para ser más productivos, etc… “). Pero lo que importa es:

TIENE QUE SER BUENO PARA EL CLIENTE

Vean que más arriba escribí “cliente (empresa)”. Es decir, tiene que ser bueno para la empresa o sector de la empresa que nos contrata. No hay que medir (en principio) que sea “bueno para Charles”, por ser Charles nuestro contacto principal en la empresa. A no ser que sea Charles el que pague la factura, no es el “cliente”. Es un representante del cliente.

Para ponerlo en claro: no es QUE NO IMPORTA absolutamente que nosotros encontremos que el proyecto haya sido bueno para Charles, para el equipo, o para nosotros mismos. No, estoy tratando de encontrar cuál es lo MAS importante.

Pues bien, después de haber participado en este siglo en varios proyectos ágiles, y también viendo el resultado de otros varios más proyectos, con casos de éxitos y fracasos, lo mejor que puedo decir es:

Un proyecto es un buen proyecto terminado y entregado, SI SOLUCIONA EL PROBLEMA DEL CLIENTE

No nos piden simplemente “necesitamos el sistema X”, sino, “necesitamos el sistema X que solucione el problema P”. Otras veces, nos dan más libertad “necesitamos una solución S que solucione el problema P”, pero es menos frecuente el caso. Pero muchas veces (la mayoría de ellas) nos piden “necesitamos el sistema X” sin poner muy en claro el problema que tiene que solucionar.

Para poner un ejemplo. Supongamos que nos piden “Necesitamos un Sistema de Producción”. Puede ser que el contexto del cliente sea:

“Somos una empresa productora familiar, que en los últimos años, con la entrada de la tercera generación en la gerencia, ha podido expandir el mercado en el exterior”

Entonces, puede el problema a solucionar puede ser uno de éstos, entre tantos:

1 – “Se nos ha ido de las manos la producción, necesitamos un sistema que nos permita manejar mejor la asignación de las máquinas. Hoy las desaprovechamos”

2 – “Las máquinas las asignamos bien, pero tenemos problemas en el seguimiento de los insumos que necesitamos y cuándo los necesitamos. No queremos tener stock de esos insumos en estos tiempos de cambio”

3 – “Nuestros principales clientes del exterior nos piden trazabilidad norma (y aquí viene una sigla desconocida para nosotros) de acá a fin de año, sino perdemos nuestro principal contrato con China”

4 – etc

Vean que entendiendo el problema podemos poner distinto énfasis en lo que vamos a construir, y con el representante del cliente, podemos tener más en claro qué es lo que aporta más valor al cliente. En el caso 1, tendremos que poner mayor esfuerzo en un plan de asignación de máquinas, y no tanto en el stock de insumos. En el caso 2, es al contrario. Y en el caso 3, tendremos que estudiar qué es eso que piden de trazabilidad.

Pero vean a lo que voy: podemos entregar el mejor sistema de producción, que asigne con algoritmos de inteligencia artificial las máquinas de la mejor forma posible, escrito con todos los patrones encima, con la mejor UI para desktop, web, tablet, y hasta TV,  pero no es la solución del problema del cliente, si estamos en el caso 3.

ESO ES LO QUE HAY QUE ENTENDER PRIMERO.

A ver, de nuevo:

EL ENTREGABLE DEL PROYECTO DEBE SOLUCIONAR EL PROBLEMA DEL CLIENTE

Y acá entra la capacidad del representante del cliente para ponernos más en claro cuál es el problema real.

No quisiera terminar el post, sin comentar algo. Hay diferencia entre problema y solución. Como escribía arriba, muchas veces nos piden el sistema. Pero tenemos que esforzarnos, como profesionales, para ver si el sistema inicial pedido soluciona o no el problema, o si es el mejor camino para solucionar el problema. En general, eso ya se definió antes de llegar el proyecto a nuestro equipo. Pero igual deberíamos tenerlo en cuenta. Tal vez, en vez de hacer sistema S, podemos hacer sistema S’ que tenga algunas características sugeridas por nosotros que mejoren alcanzar la solución del problema.

Siempre recuerdo a Henry Ford, diciendo: “Si le hubiera preguntado a mis potenciales clientes qué querian, me hubieran pedido ‘caballos más rápidos’”.

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

Nuevo Podcast de 32minutos.net: Agilidad con Martín Salías

Monday, April 22nd, 2013

El sábado pasado apareció publicado un podcast en el que participé con @martinsalias, conversando sobre agilidad en general. Fue gracias a la gente de http://www.32minutos.net/, @roundcrisis, @dvilchez, @jorgegamba.

El podcast en:

07×03 Agile con Ángel Java López y Martín Salias

Hemos charlado de todo, los principales temas:

  • Disposición al cambio
  • Entrega continua
  • Retrasar la toma de decisiones
  • Product owner
  • Empresas y administración
  • Equipos
  • Stand up
  • Retrospectiva
  • Equipos remotos

 

Vean que Martín toco varios de esos temas, contando experiencias en proyectos y equipos reales. Yo continué sobre la facilidad que da lo ágil para abrazar el cambio, y tomar decisiones ALAP (“as late as possible”). Si tienen alguna duda, le preguntan a @martinsalias 😉

Gracias a 32minutos!

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez