Angel "Java" Lopez : Desarrollo de Software, Programación

Entrevista y Podcast

lopez — Sat, 23 Mar 2013 10:47:32 GMT

Hoy paso a comentar dos entregables que se publicaron: una entrevista, y una charla como podcast.

El año pasado, el bueno de @santiagobasulto (desarrollador de software, emprendedor, programador Python, colaborador en proyectos de código abierto) tuvo la paciencia de hacerme una entrevista en persona, acá en Buenos Aires, tomándose el trabajo de viajar desde su La Plata en un día atareado. Estuvimos charlando como dos horas (en un bar histórico de la ciudad, donde se filmó la escena del billete y el mozo, de la película “Nueve Reinas”, les dejo como trabajo para el hogar averiguar cuál es). Justamente, ese bar tiene también algo que ver con la entrevista, porque he pasado por él varias veces en las décadas que llevo de programar.

Santiago la pasó en limpio, la pueden leer en:

http://charliedontcode.com/entrevistas/2012/08/12/entrevista-angel-java-lopez.html

Algo más de contexto, lo escribí hace algo más de cuatro años:

http://msmvps.com/blogs/lopez/archive/2008/12/31/treinta-a-241-os-en-desarrollo-de-software.aspx

Visiten el blog de Santiago:

http://charliedontcode.com/

Muy buena la escena de cine de donde toma el nombre (ya me imagino a @santiagobasulto cruzándose con Robert Duvall, acá en Buenos Aires, supongo que en otro bar histórico, La Biela ;-).

Y también tuve una charla, esta vez a distancia, con los buenos @roundcrisis @dvilchez, publicada hoy como podcast:

http://www.32minutos.net/?p=106

Ah! Pusieron una foto mía, debe ser la “clásica” ;-) (no me saco muchas fotos). Tratamos temas de desarrollo de software, algo de desarrollo ágil, insistí bastante sobre el tema TDD, también sobre generación de código como sistema experto, y “ver la luz”. Y hasta apareció algo de Anglish ;-).

Vean que han producido varios podcast en:

http://www.32minutos.net/

como el de Programación Funcional con el bueno de @martinsalias, o el de Node.js con @woloski, @jfroma y @theprogrammer. Hace unas semanas grabamos otro podcast, esta vez con Martin, para 32 minutos, y se conversó bastante sobre agilidad. Veremos si queda publicado en estos días. Estén atentos.

Les agradezco a los tres haberme permitido conversar y expresar algunas ideas, que pueden servir o no.

Pero lo bueno que están haciendo, es dejar entregables consumibles. Eso es importante. Internet (y la Web en particular) está permitiendo la generación de contenido y compartirlo con todos los interesados, de una forma accesible. Pienso que es una revolución tan grande como la de Gutenberg, y los primeros libros de Manuccio.

Nos leemos!

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

Remember the Links

lopez — Thu, 21 Mar 2013 14:30:28 GMT

Cuando investigo un tema, voy anotando qué recursos he utilizado, ya sea libros, notas, enlaces, etc. Es algo que he tomado como hábito, luego de adaptar una recomendación de Clifford Stoll en su libro The Cuckoo’s Egg: llevar una libreta (notebook) con lo que se hace (algo que Stoll recibió del premio nobel Alvarez). Cuando es algo que está público en Internet, desde hace años uso mi cuenta de Delicious para ir anotando esa información:

https://delicious.com/ajlopez

Y sí, también mantengo libretas (de papel) con notas, ideas y lo que fui haciendo para resolver algo.

Cada tanto voy publicado en mi blog en inglés (o en Anglish) lo que me pareció interesante compartir. Siempre pueden entrar en:

http://ajlopez.wordpress.com/category/links

Los temas que más me han importado en estos años:

Test-Driven Development
Artificial Intelligence
Node.js
CQRS
Distributed Computing
Bioinformatics
Smalltalk
Python
COBOL
Game Development
Genetic Algorithms
Socket.IO
Express
MongoDB

y mil temas más.

Aprovecho este post de recuerdo, para agregar otros posts con links de temas que no son de desarrollo de software, pero que pueden interesar:

Teoría de Categorías
Gauss
Fermat
Topología
Teoría de Números
Teoría de Grupos
Geometría
Astronomía
Historia de las Matemáticas
Matemáticas
Cálculo
Teoría de Cuerdas
Richard Feynman

y de nuevo, mil temas más.

Tantos temas interesantes, una sola vida

Nos leemos!

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

TDD y Baby Steps

lopez — Thu, 31 Jan 2013 14:04:27 GMT

Ya saben que TDD (Test-Driven Development) es uno de mis temas favoritos. Y no sólo porque me gusta, sino porque creo que es uno de los temas a difundir para mejorar la calidad de nuestro trabajo, tanto en el código entregado como en la calidad de vida de nuestro día laboral. Soy un convencido de que el código de producción escrito SIN TDD debería estar prohibido, directamente. Y si insisto con el tema, es porque no veo que se aplique y entienda TDD, por lo menos en estos lares, Buenos Aires y Argentina. Por ejemplo, escucho por ahí:

- “TDD es más lento”, no lo veo así, es un caso de “vísteme despacio que estoy apurado”.

- “TDD no es para los programadores junior”, no, cuanto más inexperto es el programador, más va a aprender y mejorar haciendo TDD y usando el cerebro, claro ;-) TDD no produce mejores programadores, pero los hace pensar en lo que están haciendo.

- “TDD es hacer test y code coverage”, por favor, no me presenten a una persona que piense así. O que piense que TDD es aprender a hacer test unitarios, sea lo que sea que “unitario” signifique.

- “TDD es aburrido”, para mí es como un juego, cada test en verde es como superar un nivel de juego.

Una de las actividades que me nacen naturalmente cuando hago TDD, es que lo que escribo va creciendo de a poco, de a “baby steps”, de a pasos de bebé. En vez de hacer un gran salto en la implementación, si uno realmente programa con TDD va agregando poco código en cada test que se agrega. Y no se agrega código que no nazca, que no tenga una traza que lo remita a la necesidad de un test. Esto consiga que el software que vamos creando, crezca como si fuera un organismo vivo, desarrollándose de a poco. Esto trae varias consecuencias:

- Cada código agregado tiene su función específica: hacer que un test pase a verde

- No aparece código “por las dudas” o por casos de uso todavía no implementados.

- No pensamos “por adelantado”, poniendo código que todavía no necesitamos (evitamos romper YAGNI).

- No se adopta tecnología o soluciones (librerías, frameworks, base de datos, etc… ) hasta el momento en el que REALMENTE se necesitan.

Y algo menos evidente:

- El código que vamos armando es pasible de refactorización en cualquier momento

- Y aún puede haber más que refactorización, sino también cambiar algo de nuestro diseño, sin grandes “dolores”

Ahora les advierto: no se puede aplicar todo esto con TDD, si parte del código QUE ESCRIBIMOS NOSOTROS no lo hacemos con TDD. Porque entonces vamos a "sufrir" cuando lleguemos un día a necesitar refactorizar, o rediseñar, y entonces la parte del código que habíamos escrito SIN TDD nos va a pesar y nos va a complicar ese paso de refactor o de rediseño.

Me gustaría mostrarles un ejemplo, pueden ver los posts y series:

TDD Paso a Paso

Escribiendo una aplicación con TDD

Escribiendo un Intérprete en .NET

VAN en Alt.NET Hispano: Desarrollando una Aplicación con TDD

con video en Desarrollando una aplicación con TDD desde cero con código en https://github.com/ajlopez/TddOnTheRocks/tree/master/TddApp

y mis posts de TDD.

Pero cada día, en mi cuenta de GitHub, voy haciendo commits por test, así que pueden entrar a algún proyecto y ver cómo va evolucionando. Por ejemplo, hoy voy a empezar a codificar SimpleKeeper (una especie de ZooKeeper pero en Node.js). Pueden en cualquier momento entrar a ver la lista de commits e ir revisando si cumplo o no cumplo con TDD y “baby steps”.

Algo muy interesante, y relacionado con este post, es:

Kent Beck’s Four Hats

Controlling the size of your checkout is a valuable coding skill. You should be able to take small, baby steps, and check-in at any time. There are a number of benefits. If you check-in frequently the merge to source control becomes trivial. Your colleagues won’t get annoyed, because that change which they need is never far away. Most importantly you are in control of your work.

Vean ahí los cuatro sombreros de Kent Beck.

Nos leemos!

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

Resoluciones del Nuevo Mes: Noviembre 2012

lopez — Wed, 07 Nov 2012 16:15:49 GMT

Revisión de mis resoluciones de Octubre:

- Dar una charla sobre lenguajes de programación en Javascript [completo] ver video
- Dar una chalar sobre Node.js/Socket.IO, aplicaciones web de tiempo real [completo] ver post
- Trabajar en PythonSharp [completo] ver repo
- Trabajar en AjTalk para Java [pendiente]
- Trabajar en AjConsorSite [parcial] solo tuve demo y reuniones
- Trabajar en GameServer [parcial] solo tuve demo y reuniones

Adicionalmente, estuve trabajando en:

- Actualizar mis ejemplos de Node.js [completo] ver repo
- Autómata celular en Javascript/Node.js [completo] ver repo
- Mejoras menores de AjTalkJs y AjLispJs
- Comenzar mi Basic Script (para Javascript/Node.js) [completo] ver repo
- Comenzar a portar AjGroups (librería de grupos finitos) a Javascript/Node.js [completo] ver repo

Para este nuevo mes:

- Trabajar en PythonSharp
- Dar una charla sobre Implementando Python, en PyCon 2012 Argentina
- Trabajar en AjTalk para Java
- Trabajar en AjTalk para Javascript
- Trabajar en BasicScript (quiero comenzar a usarlo para que se pueda definir la lógica de un juego ejemplo de mi GameServer)
- Comenzar páginas markdown con Tutorial de Java, en español
- Comenzar páginas markdown con Tutorial de Node.js en español

Nos leemos!

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

Día del Programador, en Buenos Aires, Córdoba y Rosario

lopez — Wed, 05 Sep 2012 14:45:58 GMT

A partir de la semana que viene, tendremos reuniones gratuitas, en tres ciudades de mi país, organizadas (en parte, por lo menos la de Buenos Aires) por el Microsoft User Group de Argentina, para festejar el día del programador:

http://www.programmerday.info/

El martes 11 de septiembre tenemos en Buenos Aires:

http://www.mug.org.ar/Eventos/3806.aspx

Martes, Septiembre 11, 2012
Lugar: Salón Dorado, Legislatura de la Ciudad de Buenos Aires, Perú 160.
Una jornada dedicada a compartir código y códigos. Se dice que el día 256 del año es el “Día del Programador”. Anticipándonos a la fecha invitamos a colegas y amigos a participar de este encuentro.

Orador: Rodo Finochietti,Daniel Cazzulino,Nico Paez,Johnny Haliffe,Fabio Maulo,Pablo Cibraro,Angel López

Horario: 9:00 a 13:00 hs. Atención el evento comienza y termina puntualmente.

Sesiones estrictamente dedicadas a programación a cargo de conocidos picadores de código. Si sos analista, gerente de proyecto u otra gente que "no compila", pero te interesa compartir el momento, estás invitado.

09:00 - Acreditación

09:10 - Aplicaciones web de punta a punta - Rodolfo Finochietti
09:40 - TDD y Mocking – Daniel Cazzulino
10:10 - Pharo Smalltalk – Nico Paez

10:40 - Break

11:00 - Node.js - Johnny Haliffe
11:30 - Colas en Azure - Fabio Maulo
12:00 - Web API - Pablo Cibraro
12:30 - Sistemas distribuidos - Angel López

El miércoles 12 de Septiembre, habría reunión en Córdoba:

http://www.mug.org.ar/Eventos/3807.aspx

Día del Programador - Córdoba
Miércoles, Septiembre 12, 2012
Lugar: Colegio Universitario IES Siglo 21, Salón SUM - Buenos Aires 563, Córdoba.
Una jornada que organizamos en conjunto con el IES21 dedicada a compartir código, experiencias y novedades. Se dice que el día 256 del año es el “Día del Programador”. Justo en coincidencia con la fecha invitamos a colegas y amigos a participar de este encuentro.

Orador: Matías Iácono, José Romaniello

Horario: 18:00 a 22:00 hs, acreditación a partir de las 18:00 hs.

Temario:

Introducción a Node.js - José Romaniello

Servicios RESTFul con WCF, jQuery y JSon. - Matías Iácono

Introducción a Visual Studio 2012 - Matías Iácono

Y el lunes 24 de septiembre (revisar, puede que hoy se declare feriado nacional, por el bicentenario de la batalla de Tucumán):

http://www.mug.org.ar/Eventos/3808.aspx

Día del Programador - Rosario - Aplicando Metodologías Ágiles y TDD con MVC3
Lunes, Septiembre 24, 2012
Lugar: SUM UTN Facultad Regional Rosario, Zeballos 1341 Planta Baja, Rosario Pcia de Santa Fe.
Una jornada ágil con código y demos. Se dice que el día 256 del año es el “Día del Programador”. PAra celebrarlo, unos días pasada la fecha, invitamos a colegas y amigos a participar de este encuentro.

Orador: Sebastián Pilafis, Sebastián Scandolo, Máximo Jesús García, Pablo Giménez Parera

Sebastián P.: Solutions Manager en Velocity Partners. Ingeniero de Sistemas (UNC). MCP. CSM.
Sebastián S.: Sr Team Lead en Velocity Partners. Licenciado en Ciencias de la Computación (UNR). Docente de la cátedra Análisis de Sistemas e Ingeniería de Software de LCC en la UNR. CSM.
Máximo: Sr .Net Developer en Velocity Partners. MCTS.
Pablo: Sr .Net Developer en Velocity Partners. MCTS.

Horario: 18:30 a 21:30 hs

Comenzaremos con una introducción a los fundamentos de Agile y conceptos Scrum. Posteriormente desarrollaremos Test Driven Development como técnica de diseño con ejemplos. Para culminar, exploramos MVC3 con un ejemplo integrador de las tecnologías y metodologías vistas.

Los tres eventos requieren registración, y son gratuitos.

Nos leemos!

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

Mentoring en Desarrollo de Software

lopez — Thu, 29 Mar 2012 16:44:15 GMT

Estoy preparando una charla virtual (VAN) para Alt.NET Hispano, sobre varios lenguajes de programación (Clojure, Javascript, Erlang, Python, Ruby, Scala). Investigando sobre las comunidades de esos lenguajes, me encuentro con la página de la gente de Python Argentina:

http://python.org.ar/pyar

Ayer encontré ahí esta interesante propuesta en línea

Adopta a un newbie

Leo ahí

gente se postula como mentores
gente se postula como mentados
los intereses comunes se juntan
se acuerda la forma de intactuar (IM, Skype, en persona)
el mentor dedica unas horas semanales a ayudar al mentado
el mentado documenta lo que va aprendiendo en un blog
al terminar el proceso presenta una charla de lo aprendido en un evento (PyDay, PyCamp, PyCon etc.)
todos felices

Me gusta que se documente lo que se vaya aprendiendo en un blog, así queda disponible la experiencia para otros. Ya conocía la idea de mentoring, que me parece excelente. Ver mis enlaces en:

http://delicious.com/ajlopez/mentoring

Recomiendo en especial:

The mentor manifesto

The Mentor Manifesto

Be socratic.
Expect nothing in return (you’ll be delighted with what you do get back).
Be authentic / practice what you preach.
Be direct. Tell the truth, however hard.
Listen too.
The best mentor relationships eventually become two-way.
Be responsive.
Adopt at least one company every single year. Experience counts.
Clearly separate opinion from fact.
Hold information in confidence.
Clearly commit to mentor or do not. Either is fine.
Know what you don’t know. Say I don’t know when you don’t know. “I don’t know” is preferable to bravado.
Guide, don’t control. Teams must make their own decisions. Guide but never tell them what to do. Understand that it’s their company, not yours.
Accept and communicate with other mentors that get involved.
Be optimistic.
Provide specific actionable advice, don’t be vague.
Be challenging/robust but never destructive.
Have empathy. Remember that startups are hard.

Desmystifying Mentoring

Myth #1: You have to find one perfect mentor
Myth #2: Mentoring is a formal long-term relationship
Myth #3: Mentoring is for junior people
Myth #4: Mentoring is something more experienced people do out of the goodness of their hearts

The importance of Trust and Mentorship for Startups

Pero me resultó novedoso que una comunidad en Argentina fomentara esta práctica. Sería interesante ver esto aplicado en otras comunidades, como Ruby Argentina, Alt.NET Hispano, o en grupos de usuarios como el MUG de Argentina.

También en empresas, consultoras, fábricas de software. Si Ud. va a proponer un programa así, recomendaría que fuera público, abierto, con cierto soporte de la consultora (tantas horas disponibles por persona), pero que sea emergente, no un programa formal. Es decir, que sea la gente la que se proponga como mentor o mentado en distintos temas. Eso permite ver quienes son más proactivos, y tienen ganas de compartir y aprender. Expone habilidades que quisiéramos tener en los miembros de nuestros equipos ágiles: curiosidad, capacidad de comunicación, inquietud, disciplina, etc.

Nos leemos!

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

Enlaces, Novedades y Recursos

lopez — Sat, 24 Sep 2011 10:49:46 GMT

Mi sitio personal comenzó como una forma de compartir recursos y enlaces de distintos temas, pero desde hace unos años directamente uso mi Delicious, dejando mi sitio para publicar material de cursos presenciales.

En mi blog en inglés he publicado colecciones de enlaces sobre temas que me interesan. Están bajo la categoría Links. Hay enlaces en inglés, pero también en español. Espero que algunos temas les sirvan, otros les resulten nuevos pero interesantes. En general, los publico primero en email privado en mi cliente principal (espero que alguien los lea, además de mi Tía Carlota ;-) y luego encuentran su curso para ser publicados en mi blog en inglés. He aquí los post publicados:

Closures
C# 5
Windows 8 and WinRT
Ruby
Lambda Calculus
Erlang
Node.js (2)
Haskell
Mock Objects
Scalability
MapReduce
TDD
Git
Domain-Driven Design
Game Development
REST
Javascript
HTML5
Windows Azure
Node.js
Object Oriented Programming

Para conseguir los tutoriales o videos de esa colección, ver el post mi Delicious sobre la forma en que “taggeo” estos enlaces.

Nos leemos!

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

Los Principios de la Buena Programación

lopez — Wed, 17 Aug 2011 10:27:16 GMT

Encuentro en estos días el post The Principles of Good Programming, de Christopher Diggins.

Christopher Diggins is a software developer and freelance writer. Christopher loves programming, but is eternally frustrated by the shortcomings of modern programming languages. As would any reasonable person in his shoes, he decided to quit his day job to write his own ( www.heron-language.com ). Christopher is the co-author of the C++ Cookbook from O'Reilly. Christopher can be reached through his home page at www.cdiggins.com.

Me gustaría transcribir en mis palabras la lista de principios de ese post. Veamos:

DRY – Don’t repeat yourself – No repetirse a sí mismo. Podría remontarme a Ada Lovelace y su idea de rutinas para encontrar el germen de este principio. Funciones, métodos, clases son todos artefactos que fueron apareciendo en la historia de la programación para evitar la repetición. Ver http://en.wikipedia.org/wiki/Don%27t_repeat_yourself

Abstraction Principle – Principio de Abstracción. Es una forma de llegar al DRY de arriba. “Cada pieza de funcionalidad significativa en un programa debe ser implementada en un sólo lugar del código fuente”. Ver http://en.wikipedia.org/wiki/Abstraction_principle_(programming

KISS (Keep it simple, stupid) – Manténgalo simple, estúpido! Tal vez mi principio preferido. Ante tanta complejidad accidental, temas de tecnologías, frameworks y librerías, la mejor solución a un problema es la más simple. Menos código, menos bugs. Ver http://en.wikipedia.org/wiki/KISS_principle

Avoid Creating a YAGNI (You aren’t going to need it) – Evitar crear algo que no vamos a necesitar. Es común tratar de ver el futuro y comenzar a crear abstracciones que todavía no estamos usando. Una de las razones por las que prefiero trabajar con TDD (Test-Driven Development) es que nos permite alcanzar éste y otros principios (como el KISS y los que siguen abajo) de una forma natural. Muchas veces digo: “No hay que cruzar al puente antes de llegar al puente”. Ver http://en.wikipedia.org/wiki/YAGNI

Do the simplest thing that could possibly work – Haga lo más simple que funcione. Siempre hay que preguntarse ¿qué es lo más simple que tengo que escribir para que esto funcione? De nuevo, TDD me lleva a este principio. Al no introducir complejidad a cada paso, vamos manteniéndonos en el camino de la simplicidada. Ver http://c2.com/xp/DoTheSimplestThingThatCouldPossiblyWork.html

Don’t make me think – No me haga pensar. Hay un libro de Steve Krug con este título (Don't Make Me Think: A Common Sense Approach to Web Usability, 2nd Edition) Así como la interfaz tiene que ser algo que no nos haga pensar ¿y ahora, cómo lo hago? el código que escribamos tiene que ser consumible de la misma forma: evitar lo “tricky”, los nombres de las funciones deben declarar claramente lo que hacen, etc. Por ejemplo, a veces veo código Fluent que hay que hacer un curso en la NASA para ver qué hacen, de tanto lambda que aparece en los parámetros ;-). Pero tengo que reconocer que pueden ser útiles una vez uno entiende el concepto.

Open/Closed Principle – Principio Abierto/Cerrado. Uno de los principios S.O.L.I.D. (ver http://en.wikipedia.org/wiki/SOLID_%28object-oriented_design%29) Entidades de software (clases, módulos, funciones) deben estar abiertas a la extensión, pero cerradas a la modificación. Hay que escribir clases, no para que otros las modifiquen, sino para que otras las usen y extiendan.

Write Code for the Maintainer – Escriba código para el que va a mantenerlo. Yo diría: escriba código para sí mismo dentro de seis meses. Otro punto donde TDD me ayuda. No hay que escribir código “cool”, hay que escribir código claro que haga cosas “cool”. Muchas veces veo código brillante, pero inmantenible. Tomemos nuestro tiempo, y pongamos “algo de amor” en el código ;-). Dice el post que comento: “Escriba el código como si el que tuviera que mantenerlo fuera un sicópata asesino que conoce donde vives” Ver http://c2.com/cgi/wiki?CodeForTheMaintainer

Principle of least astonishment – Principio del menor asombro. Se aplica en general a la interfaz de usuario, pero también se puede aplicar al código. El texto del código no debe provocar sorpresa. Ejemplo: el nombre de una función debería corresponder con lo que hace. Hasta la indentación del código y las convenciones ayudan. Ver http://en.wikipedia.org/wiki/Principle_of_least_astonishment

Single Responsability Principle – Principio de Responsabilidad Unica. Un componente de código (clase, función) debe ejecutar una única y bien definida tarea. Otro de los principios S.O.L.I.D. Ver http://en.wikipedia.org/wiki/Single_responsibility_principle

Minimize Coupling – Minimizar el acoplamiento. Cada componente (bloque de código, clase, función, etc.) debe minimizar las dependendencias de otros componentes. Por ejemplo, usar lo menos posible variables en común. Cuando un componente A tiene que usar el componente B, debe tratar de conocer lo menos posible de B: por ejemplo, sólo consumir lo necesario de su funcionalidad, y no entrar en temas como crear a B (de ahí el uso de inyección de dependencias). No hacer cosas como B.propiedad.propiedad2.metodo() (un caso de la ley de Demeter de más abajo). El minimizar el acoplamiento trabaja junto con el maximizar la cohesión. Ver http://en.wikipedia.org/wiki/Coupling_%28computer_programming%29

Maximize Cohesion – Maximizar Cohesión. Un componente debe tener funcionalidad altamente relacionado. Evitar implementar en un componente dos funcionalidades que no están relacionadas, cumpliendo tareas que no tienen relación. Ver http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29

Hide Implementation Details – Ocultar Detalles de Implementación. Ejemplo, no exponer variables de estado interno: preferir propiedades controladas o mejor, directamente métodos. Concentrarse en exponer lo que los demás van a consumir, antes que los detalles de cómo cumplimos con nuestra tarea. Esto permite llegar a cambiar la implementación sin afectar al resto del sistema. En lenguajes tipados como C# y Java, se puede llegar a algo de esto consumiendo interfaces definidas. http://en.wikipedia.org/wiki/Information_Hiding

Law of Demeter – Ley de Demeter. Los componentes de código deben comunicarse con los directamente relacionados. Usar B si se referencia desde A, pero evitar usar B.C.D.metodoE(). A se relaciona directamente con B si lo recibe en su constructor, o como parámetro de un método. También se puede tomar como “directo” la funcionalidad heredada de una superclase. Ver http://en.wikipedia.org/wiki/Law_of_Demeter

Avoid Premature Optimization – Evitar la Optimización Prematura. Otro caso de “no hay que cruzar el puente hasta llegar al puente”. Hay que evitar pensar en optimizar código, si apenas lo estamos armando. Ir armando el código de tal forma que podamos refactorizarlo, cambiar implementación, concentrar los cambios en pocos lados (todo esto ayudado por los otros principios, y TDD) para cuando llegue el tiempo de optimizar (si es que llega). Para optimizar, hay que medir, no intuir. "We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil" - Donald Knuth. http://en.wikipedia.org/wiki/Program_optimization

Code Reuse is Good – El Reúso de Código es Bueno. Aprovechar código ya escrito, si es buen código (esperamos que cumpla los otros principios). Mejora el tiempo de desarrollo, y si es código ya usado y probado, mejora el resultado. Ver http://en.wikipedia.org/wiki/Code_reuse

Separation of Concerns – Separación de Preocupaciones. Un componente no debe ocuparse de dos o más tareas, especialmente si tienen poca relación no accidental entre sí. Por ejemplo, el manejo de la autorización a ejecutar un método debería quedar, en lo posible, fuera del código de ese método. Ver http://en.wikipedia.org/wiki/Separation_of_concerns

Embrace Change – Abraza el cambio. El cambio es una constante en el desarrollo de software: cambio en los requerimientos, la funcionalidad, la tecnología, la evolución de un sistema exitoso. No hay que luchar contra el cambio, sino trabajar para estar preparado para él. Programación ágil, TDD, integración continua, Scrum, iteraciones cortas, revisión en cada iteración, son todas prácticas que soportan este principio. Ver Extreme Programming Explained: Embrace Change (2nd Edition)

Alguno más? Comentarios? Supongo que puedo escribir algún post de cada uno, con algún ejemplo. Veremos! ;-)

Nos leemos!

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

Aprendiendo Java

lopez — Wed, 11 May 2011 11:24:25 GMT

Ya varias veces me preguntaron por Twitter sobre recursos de Java para estudiar. Sea este post un intento de respuesta a esta pregunta, ampliada: no sólo recursos, sino, qué estudiar de Java (lo que dependerá del trabajo a encarar), y estudiar algo más amplio: programar.

El mundo de Java se ha ido expandiendo desde la aparición pública en 1995 del lenguaje, Java Virtual Machine, y librería de clases, de la mano de Sun. Siguieron versiones del lenguaje y librería. El mayor cambio ha sido en las versiones 1.5 y 1.6, donde aparecieron nuevas “features” del lenguaje, y se esperan más para el 1.7. Sin embargo, para gran parte de lo que se necesita para COMENZAR a aprender Java, es suficiente con saber manejarse con lo común a cualquier versión. Como saben, hace un tiempo Oracle compró a Sun, y veremos qué pasa con el desarrollo de las nuevas versiones, y el futuro de Java en general.

Para estudiar Java, hay que recordar:

- Se implementa sobre una JVM (Java Virtual Machine) multiplataforma
- Tiene una extensa librería de clases
- Como lenguaje, es orientado a objetos
- No tiene un entorno “prefijado” o preferido de desarrollo (IDE, Integrated Development Environment)

Paso a enumerar algunos recursos. Primero, el burro por delante ;-)… Tienen un curso incompleto pero espero que interesante, en mis recursos en línea:

Curso: Introducción a Java

Ahí también tienen otros cursos en línea. Luego, pueden ver ejemplos en mi Skydrive, de los cursos de Java que fui dando: Ejemplos de Java.

Luego, lo más recomendable en línea debe ser lo que había armado Sun, ahora bajo la égida de Oracle:

The Java Tutorials

Comenzaría por Learning the Java Language, Essential Java Classes, Collections. Tienen en esa página temas más especializados.

Visitaría a la gente de Java Hispano: http://www.javahispano.org. En especial su documentación http://www.javahispano.org/documentacion/ que es variada (en nivel, calidad, algunos elementos también tienen sus años).

Pero ahora viene parte de mi respuesta a la pregunta extendida: ¿Qué estudiar de Java? Yo recomiendo:

- Estudiar el lenguaje, que es sencillo, concentrándose en los conceptos de objetos
- Comenzar a estudiar la librería, con algunas colecciones.
- Seguir con algo que todos manejamos en otros lenguajes: acceso a archivos, descubriendo que en Java tenemos streams en general. Ver algo de sockets para ir viendo que “leer/escribir” es algo que se puede abstraer desde java.io. Ver ejemplos en mi Skydrive ClaseIo.zip, ClaseClienteServidor.zip.
- Ver acceso a base de datos usando JDBC.

Luego, lo que venga después, depende de lo que quieran hacer y el trabajo que tengan que encarar. Si tienen que hacer aplicaciones de escritorio, seguramente tendrán que elegir estudiar: Swing (ver los tutoriales de Java, por ejemplo Swing, Creating a GUI with Swing) o SWT The Standard Widget Toolkit. Si tiene que hacer aplicaciones web (algo casi inescapable en estos días), recomiendo:

- Bajar, instalar y jugar con el Tomcat de la fundación Apache
- Sólo si es necesario, ver JBoss (en mi opinión: “too much”, un Application Server que ha ido creciendo a partir de las especificaciones de Sun. Tiene una arquitectura microkernel, y eso es interesante. Pero para desarrollo web, aprendan con Tomcat.

Y comiencen a estudiar JavaServer Pages: sé que no es la “última tecnología web” pero si no entienden JSP no van a poder entender todo los modelos web de Java. Estudien en ese momento el modelo de Servlets, que es la base de todos los modelos. Luego, estudien Javascript en el cliente, y Ajax. Les debo enlaces sobre ese tema. Ver por ahora http://delicious.com/ajlopez/javascript+tutorial y http://delicious.com/ajlopez/ajax+tutorial.

Otro ámbito sería la programación para dispositivos móviles. Ahí les debo recomendaciones y enlaces, porque nunca me ha tocado aún ese tipo de programación.

Algo más, antes que me olvide: NO ESTUDIEN Enterprise JavaBeans, a no ser que su vida esté en peligro. Esa especificación de Sun, a pesar de las mejores de 3.x, debería ser borrada de la historia humana. Tengo una teoría: los extraterrestres existen, nos vienen observando desde hace décadas. Vieron que manejamos armas nucleares, tuvieron gran debate, pero decidieron: “Démosle una oportunidad a los terráqueos”. Vieron que seguimos con guerras. Debatieron de nuevo: “Veamos de seguir dándoles una oportunidad”. Sus científicos de computación vieron que desarrollamos EJB (Enterprise JavaBeans) y Web Services sobre WCF (Windows Communication Foundation) y decretaron inmediatamente: “No tienen cura, están completamente perdidos en la irracionalidad, declaremos cuarentena” ;-).

Había planteado que en Java no hay una IDE prederminada. Pueden hacer todo desde la línea de comando, si quieren, y configurar su editor preferido para compilar y lanzar las aplicaciones que construyan. Pero recomiendo bajarse y estudiar el Eclipse. Van a encontrar diferentes versiones, ya preparadas, algunas orientadas a desarrollo web. Lo bueno de Eclipse: es sencillo, multiplataforma, maneja sus propios widgets gráficos basados en SWT (con lo que se adapta al sistema gráfico nativo), tiene una comunidad activa, es muy usado en los ambientes de desarrollo, está al nivel de cualquier IDE comercial. Es fácil de instalar y desinstalar (prácticamente copiar archivos). Sólo tendrán que tener paciencia en la elección de los plugins que quieran usar: Eclipse es totalmente extensible por plugins, y de ahí que uno extrañe un poco lo que se tiene en .NET: una IDE (el Visual Studio) que tiene prácticamente todo lo necesario para programar sistemas “out-of-the-box”. Pero Eclipse “out-of-the-box” es totalmente adecuado para estudiar Java. El tema es configurarlo para el trabajo que encaren: he ido a consultoras donde cada máquina y proyecto tienen un Eclipse distinto ;-)

Pero no es sólo visitar la librería de clases, y ver el Eclipse. Hay que aprender a programar, a pensar en objetos, y sobre técnicas de programación que hoy tenemos disponibles. Para el tema de pensar en Java con objetos, no sólo programar, pueden bajarse el libro Thinking in Java de Bruce Eckel, la tercera edición:

http://www.mindviewinc.com/downloads/TIJ-3rd-edition4.0.zip (hay que hacer un curso para encontrar este enlace desde http://www.mindview.net/Books/TIJ/ ;-) Tiene otros libros para bajar de Bruce Eckel desde http://www.mindviewinc.com/downloads/

Otra cosa, una opinión sobre la certificación: pienso que no hace falta, sólo para el currículum y búsqueda de trabajo. La mejor certificación es la experiencia en el desarrollo. Vean que Java es más que un lenguaje, es una tecnología con amplia librería de clases, utilitarios, librerías adicionales, servidores, etc. Es un mundo muy amplio. Vayan de a poco, aprendiendo las partes que recomendé y luego viendo las partes que necesitan para cada trabajo en particular. También van a encontrar que muchas veces tiene sus “bordes ásperos”, y hay que armarse de paciencia para conseguir algún resultado.

Un ejemplo de algo que se necesita en Java, pero no he visto que sea necesario en .NET, es el utilitario Maven. Van a tener que aprenderlo. Pero es un ejemplo de algo que a muchos en el ambiente Java les fascina, pero yo lo veo de otra manera: es una gran herramienta para solucionar un problema, que no DEBERIA ser un problema tan grande. A mucha gente le gusta, porque soluciona la complejidad de tantas librerías con tants versiones: pero es un remedio que oculta el problema inicial, la complejidad de esa tarea. Si tienen que estudiar Maven, recomiendo antes estudiar algo más simple, ubicuo, entendible y poderoso: el Apache Ant.

Cuando dominen JDBC para acceder a base de datos, pueden comenzar a estudiar y usar Hibernate. Parece que no terminan nunca los temas ;-). Bueno, uno más: para tener un panorama de los problemas y soluciones al desarrollo de Java, recomiendo estudiar (lo simple primero, luego sólo los temas que necesitan) el Spring Framework, donde encontrarán también nuevos utilitarios que se montaron para facilitar el desarrollo en Java. Al estudiar Spring, verán distintas implementaciones de interfaz web, como usar MVC (Model-View-Controller), sus distintas implementaciones, y otras tecnologías como JavaServer Faces.

El mejor libro para ir entendiendo cómo todo eso se usa en conjunto, lo comento en mi post:

Agile Java Development With Spring, Hibernate And Eclipse

Quiero aprovechar este post para agregar algunos puntos que van más allá de la programación en Java. Primero, Uds. no tienen que ser “programadores Java”. Sólo al principio. Uds. tienen que, diría, luchar, esforzarse por ser “desarrolladores de software”, es más, “desarrolladores de software profesionales”: gente que se toma en serio el trabajo que realiza, y trata cada mes, semana, día, de aprender algo nuevo y mejorar en las prácticas que realiza. Tiene que pensar más allá de “programar en Java”. Tienen que pensar en “desarrollar software”. Ya no hay programadores de un lenguaje. Para ver algunos temas casi imprescindibles en nuestra profesión, les recomiendo el libro de @karlseguin: Foundations of Programming. Para los que estudian Java, encontrarán que tiene más orientación a .NET, pero no se engañen: todo lo de ese libro se puede aplicar a otras tecnologías. Traten también de ser polyglot programmers, cosa que si aprenden Java, conseguirán estudiando los lenguajes y tecnologías montadas sobre la JVM, como Scala, Groovy, Clojure, JRuby, y más.

Me recomiendo a mí mismo ;-) leer:

Aprendiendo de Jason Bourne
Programmer Competency Matrix
What is your strategy for become a better developer

Si son seguidores de esto blog (es decir, yo y mi Tía Carlota ;-) ya saben lo que viene ahora:

- Estudien y apliquen Test-Driven Development (TDD, leer mis posts sobre el tema)

- Trabajen en équipos ágiles (leer mis posts sobre Scrum)

Van a aprender que la complejidad de Java (todos lo que hay que tener en cuenta para armar una aplicación profesional) fue en gran parte madre de mi iniciativa sobre generación de código.

Si están en Buenos Aires, o en Argentina, hay varias actividades ágiles, ver actividades en Latinoamérica en:

http://www.agiles.org/

TDD es prácticamente un “must be done”. Pueden estudiar TDD en curso presencial, acá en Buenos Aires, con el bueno de @hernanwilkinson:

http://www.10pines.com/content/construcci%C3%B3n-de-software-robusto-con-tdd

Finalmente, les recuerdo que voy coleccionando enlaces sobre Java en:

http://delicious.com/ajlopez/java+tutorial
http://delicious.com/ajlopez/java+example

Vean que de cada tema del universo, tengo enlaces en delicious ;-) ;-)

Bueno, ya es tiempo de cerrar este post, e irme a luchar contra el Efecto Coto. Cualquier duda, recomendación, les pido colaboren con comentarios. Pero más allá de todo esto, de Java y demás, siempre recuerden, parafraseando a Rambo II: “La mejor herramienta es una mente despierta” ;-)

Bueno, eso es todo por hoy, salud, mis queridos chichipíos, vermú con papa fritas, y gud shou!!

Nos leemos!

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

Presentando Patrones de Diseño (Design Patterns)

lopez — Mon, 18 Oct 2010 09:31:24 GMT

Como ya había anunciado, el sábado 16 de Octubre participé de una VAN de la comunidad ALT.NET Hispano, sobre Patrones de Diseño. En cualquier momento, la gente de ALT.NET Hispano publica el video de la VAN (Des-conferencia virtual). Mientras, les dejo acá la presentación DesignPatterns.pptx.

La idea fue presentar algunos patrones a través de un ejemplo. Usé para eso el patrón Interpreter: estuvimos explorando el código de un intérprete escrito en C#. Lo pueden bajar desde mi proyecto Google AjCodeKatas (en el directorio Patterns), donde posiblemente vaya evolucionando, o pueden tomar la versión actual desde Patterns20101017.zip (noten que los namespaces que usé fueron elegidos para describir patrones, más que para un intérprete real). El ejemplo fue desarrollado con TDD (Test-Driven Design), pero no vimos el proceso en la charla: vimos el resultado, directamente. Para los que quieran ver un intérprete desarrollado usando TDD pueden seguir mi serie de posts sobre el tema en el tag TDD ejemplo: Escribiendo un intérprete en .NET (Parte 7).

También mencionamos código de NHibernate, pero no llegamos a verlo. Comenté sobre Facade y Strategy usando una aplicación de demo generada con AjGenesis y que usa NHibernate. Pueden bajar la versión actual (work in progress) de AjTestNh20101017.zip.

Acá va una lista de los patrones que vimos, y el código elegido para ejemplicar cada uno:

Interpreter: con el intérprete de expresiones que escribí como base de la charla.

Composite: con comandos en el intérprete. Uno de los comandos contiene una lista de comandos.

Template Method: lo encontrarán en el método Evaluate de las BinaryExpressions: se evalúan dos expresiones, y el resultado final se calcula invocando al método .Apply, que es reimplementado en las subclases.

Strategy: En vez de escribir un objeto de una clase por Strategy, escribí Func<obj,obj,obj> a aplicar dentro de la evaluación de ArithmeticBinaryExpression.

Decorator: a cada comando y expresión del intérprete, se le pasa un IContext, que tiene la responsabilidad de mantener los valores de las variables que manejamos. Lo decoré para tener un IContext que avise con eventos qué variables y valores se consultan y modifican.

Observer: usé directamente eventos de .NET, que son una evolución de este tema.

Adapter: cuando quise consumir un archivo como TextReader, con código del lenguaje a interpretar, necesitaba leer, no líneas, sino palabras del lenguajes (clase Token). El Lexer del ejemplo es un adapter para eso.

Abstract Factory: acá me aparté del intérprete y usé una implementación que termina usando los providers de ADO.NET, que a su vez funcionan como Abstract Factory.

Facade: junto con Strategy, son los más importantes a aprender. Todo Strategy nos deriva a composición en lugar de herencia, y a Dependency Injection, Inversion of Control y contenedores. Como Facade mencioné la “API de Negocios” que ya había comentado en otra VAN, y mostré una capa fina de servicio lógico en la aplicación de NHibernate que mencioné más arriba.

No llegué a presentar Facade en el ejemplo intérprete, pero pueden ver la clase Machine, que termina usando por debajo a Parser (otra especie de Adapter), Lexer, archivos, y Context, sin que tengamos que manejar esos objetos desde “afuera”.

Y también encontrarán un ejemplo de Visitor, que toma un programa del intérprete y lo “decompila” a texto.

Tiene más ejemplos y los diagramas UML (que usé en la charla) en:

http://www.dofactory.com/Patterns/Patterns.aspx

Terminó la presentación y vino una discusión, muy interesante. Alguien de Guatemala (disculpen, no recuerdo el nombre) necesitaba trabajar en un caso: para un sistema, hay que calcular el precio de los productos, pero esas reglas cambian mucho en el tiempo y por producto. Surgieron ideas: poner una Factory que genere la Strategy a aplicar en cada caso, y hasta tener una Strategy que interprete código que se levante de un texto. Me hizo recordar a sistemas de sueldos y jornales que ví acá en Argentina. Ahí mencioné que pueden usar el ejemplo de:

Un ejemplo de Dynamic Expressions

donde se compila una expresión lambda escrita en texto. Ahí se mencionan otras alternativas.

Otro camino es usar AjSharp como intérprete, ver los posts de AjSharp Debería escribir un post sobre cómo resolver un tema parecido al planteado en la VAN. También pueden ver a AjSharp como un intérprete mucho más terminado que el ejemplo de la charla. Es parte de AjCodeKatas y pueden verlo aquí.

Otro camino (debo post sobre mi charla en el pasado CodeCamp de Buenos Aires, sobre Intérpretes y Compiladores en .NET), es usar Dynamic Language Runtime:

http://dlr.codeplex.com/

Y hay también facilidades en .NET para compilar “on the fly”, usando CodeDOM, Reflection.Emit, y el compilador de .NET. Pero eso pienso que sería un camino más duro. Escribiré sobre eso en el post que debo sobre mi charla en el CodeCamp.

Gracias a la comunidad ALT.NET Hispano y en especial, al flamante MVP @jorgegamba y también al bueno de @fabiomaulo que me acercó información de nuevos patrones, y a todos los que colaboran con la grabación, edición del video y la organización de todas estas actividades.

Ah! Y en cerca del principio del video, hay una sorpresa … ;-)

Nos leemos!

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