Java Roadtrip en España: dinos qué te gustaría oir en un evento para desarrolladores
javaHispanoOracle, javaHispano y Cuore organizarán un evento para desarrolladores en 5 ciudades españolas: Madrid, Barcelona, Bilbao, Sevilla y Castellón de la Plana. Los seminarios se distribuirán entre octubre y noviembre, serán gratuitos y se celebrarán en universidades de las citadas ciudades. Y desde javaHispano te pedimos tu colaboración para elaborar la agenda del evento.
Desde ahora y hasta el domingo 9 de septiembre puedes participar en esta encuesta votando por aquellos temas que te gustaría oir en un evento organizado por Oracle. Vota por los 4 temas que más te interesan. Y si te interesa alguna otra cosa dínoslo en Twitter usando el hashtag #javaroadtrip.
Una vez tengamos la información sobre vuestros intereses, elaboraremos una agenda que intentaremos que tenga el siguiente formato:
- Presentación sobre algún tema (45 minutos).
- Presentación sobre algún tema (45 minutos).
- Breve descanso.
- Hands on lab (2 horas 30 minutos).
Anunciaremos aquí la agenda definitiva, así como las fechas y lugares concretos donde se realizarán los seminarios.
Aquí tenéis la lista de posibles temas:
Reader Comments (16)
En mi opinión, la mayoría de los eventos están centrados en tecnologías, y esto tiene sentido, pero yo echo de menos poder asistir a eventos sobre principios y prácticas de diseño de software: orientación a objetos, arquitectura, testing...
Está bien saber que existe cierta implementación de JSF que funciona de cine en iPads, pero lo que seguro que necesito en mi día a día es diseñar correctamente cómo se crean objetos de una clase o cómo organizar un conjunto de clases en paquetes.
zemi, pero eso que preguntas es demasiado trivial como para exponerlo en una ponencia, ¿no crees?
¿Podrías concretar un poco máS? Porque la respuesta es que para crear una clase debes darle a new class, y para organizarla, pues debes organizar un conjunto de clases entre sí en paquetes.... ¿no?
Más de acuerdo no puedo estar zemi. Piensa que en este caso algo organizado por oracle es algo orientado a promover el uso de la tecnología que vende (oracle vende tecnología no vende practicas).
Para lo que dices hay otros eventos, como por ejemplo los organizados por agile-spain que se centran en las practicas y donde nos reunimos gente que usa variopintas tecnologías. Aunque también se habla mucho de practicas "de gestión de equipos" y no sólo de practicas técnicas, pero bueno... eso es otro debate.
De cuando en cuando también se organiza algún code retreat, coding dojo's y algún que otro open space sobre desarrollo (en madrid hicimos uno, en sevilla creo que se han echo uno o dos), estos son sitios estupendos para hablar más de las prácticas que de las tecnologías.
y jaime, crear objetos es una de las cosas más cruciales en diseño OO, no se trata de hacer "new" se trata de elegir cuando y donde crearlos, se trata de evitar el acoplamiento y hacer código testable, se trata de conocer los distintos patrones de creación de objetos (builders, factorias), se trata de gestionar correctamente el ciclo de vida de tus objetos, se trata de si usar o no usar alguna librería de DI para gestionarlo...
Yo me puedo tirar varias horas hablando sobre esto si es necesario (bueno... en realidad sobre casi cualquier cosa xd)
@jcarmonaloeches
En efecto, como dice Alfredo, hay muchas maneras de crear objetos, cada una tienes sus pros y sus contras, yo llevo unos cuantos años en esto y no siempre tengo claro cuándo utilizar una u otra.
De todas formas era un ejemplo. En general me refiero a que me gustaría eventos que me enseñasen "cómo hacer buen código" frente a "las novedades de la versión X de la librería Y" (que también están bien, pero como me han preguntado yo contesto :-).
@alfredocasado
como por ejemplo los organizados por agile-spain
Por alguno me he pasado pero siempre me he encontrado con la parte de gestión de proyectos, tendré que ver si asisto a alguno más centrado en programación.
A ver cuando publiquen el programa del CAS 2012, si tiene parte de programación me apunto.
Je je me ha hecho gracia lo de "trivial".
Vamos a ver, tenemos que hacer una funcionalidad amplia y compleja X y nos ponen la restricción que cada clase tenga como mucho 1 Kb, el objetivo de la restricción tonta anterior es obligarnos a dividir sí o sí la funcionalidad en clases (en la práctica tendrás otras razones no una limitación estúpida).
El caso es que dicha funcionalidad por muy bien o mal que se haga debido a la restricción del 1 Kb da lugar digamos que en torno a 1000 clases, a algunos les saldrán más y a otros menos, hablamos de una funcionalidad amplia y compleja, pero desde luego no 5 clases que una cosa es reutilizar código y otra es hacer magia.
Ahora bien ¿alguien en su sano juicio cree que la creación y gestión de esas 1000 clases "con un fin" que sean mantenibles y sin código repetido no es EL PROBLEMA?
Invito a contar a alguien las clases que hay aquí ojo que estás son las públicas, que están las privadas de implementación que incluye unas "poquitas" más.
Pues no es ninguna tontería lo de ponerse restricciones "muy burras" en ejercicios de practica para aprender a pensar de otra forma. De echo una charla de la software craftmanship del año pasado (por cierto zemi, si no tienes problemas con el inglés esta es justo lo que buscas, talleres sobre practicas y diseño, y de mucho nivel además) proponía hacer un ejercicio (la kata del cajero) con las conocidas objects calisthenics (http://www.bennadel.com/resources/uploads/2012/ObjectCalisthenics.pdf)
Ayuda a pensar de otro modo y se aprende muchísimo, se lo recomiendo a todo el mundo. Para quien no quiera leerse el pdf, las reglas son:
1. One level of indentation per method (control de complejidad ciclomatica)
2. Don’t use the ELSE keyword (la logica positiva es más sencilla de entender)
3. Wrap all primitives and Strings4. First class collections (creación de un dominio propio)
5. One dot per line (ley de demeter)
6. Don’t abbreviate (poner buenos nombres)
7. Keep all entities small (single resposability, kiss)
8. No classes with more than two instance variables (reducir acoplamiento)
9. No getters/setters/properties (evitar la "falsa" encapsulación, tell don't ask)
Es un ejercicio super chulo, evidentemente no te vas a poner estas restricciones en un proyecto real porque en ocasiones hay buenos motivos para saltarselas. Pero intentar programar con esto en mente con ejercicios de practicas ayuda muchísimo a mejorar como entendemos la OO. (yo lo ponía en clase habitualmente, a finales de curso eso si jeje).
ups, me comi la 4:
Rule 4: First class collections (dominio propio de nuevo, como la 3)
Cada cual tendra sus métodos de aprendizaje, yo no me rio de los tuyos no te rias tu de los mios. Una característica importante para poder crecer como profesional es la "humildad", cuando uno piensa que lo sabe todo... entonces mal asunto choces.
@alfredocasado
Gracias por el enlace de las Object Calisthenics.
La conferencia de software craftmanship que dices, ¿es http://www.softwarecraftsmanship.org.uk/ ?
Pues si me permites, opino que en este caso tus filtros te están fallando. No llevo 30 años en esto, pero si algo más de la mitad de eso programando (casi 20 ahora que me paro a pensarlo... oh my god!), y si algo he aprendido es que para llegar al mismo objetivo (ser un buen profesional) hay muchos caminos.
Un camino es trabajar y codificar para "la vida real" (lo siento, pero odio profundamente esta expresión, yo no vivo en el mundo de disney) donde te pagan por un trabajo y unos resultados y eso te impone una serie de restricciones (de tiempo, de recursos, etc,etc,). Otro camino es trabajar es proyectos open-source donde las restricciones son otras. Y otro camino es la practica deliberada, es decir, escribir código con el único objetivo de perfeccionar técnicas/practicas y luego si quieres puedes tirar el código a la basura, en este tecer camino es donde encajan y son realmente utiles ejercicios como el que proponía antes, y si además no lo haces sólo y lo compartes con otros profesionales (coding dojo's por ejemplo) las posibilidades de aprendizaje se multiplican.
Eso si, si te quedas sólo en un camino corres el riesgo de perderte muchas cosas. Yo te puedo asegurar que en los últimos 3 o 4 años con practicas como esta, con katas, coding's dojos, code retreats, haciendo pair con otros profesionales que no tenian nada que ver con mi entorno "normal" y saliendo de mi zona de confort (otros lenguajes, otros paradigmas) etc,etc... he aprendido más que en 10 años programando en la "vida real". Me gusta una frase que dice que "no es lo mismo tener 10 años de experiencia que un mismo año repetido 10 veces".
@zemi
Si esa misma, yo este año no pude ir, fui a la de 2011 junto con una "armada española" de unos 10 o así que nos juntamos para ir. De echo, en el enlace que has puesto, los dos flipaos de rojo del tercer video son parte de la armada jeje.
Además, aunque sólo sea por estar en Bletchley Park ya merece la pena pasarse.
1) Trabajo cotidiano (del que acabo valdao y consume la inmensa parte de mi vida)
2) Open source: sigo haciendo miguita a miguita pero es ya casi a rastras
3) Me falta hacer codings dojos y martirizarme un poco fuera de mi zona de confort (que poco me gusta esa frase) pero me temo que pare ello me falta un poco más DE VIDA xD
¡¡Qué cerca de Galicia están todos!!
Vamos a ver que nos vamos por las ramas chavales, todo el mundo sabe que programar no es trivial. La vida en general no es trivial. Yo sé cruzar un paso de cebra y hay miles de maneras y puntos de vista sobre cómo podré cruzar el paso de cebra gastando menos energía, reduciendo el nº de accidentes y haciendome el guapo para que las chicas de las pelis de terror (que normalmente mueren pero están muy buenas) me miren mientras pongo una cara de tipo duro pero sensible a la vez que interesante y pasota.
A lo que voy, que todo el mundo sabe que mantener una aplicación se puede complicar, pero no vamos a quedar, con la gente de Oracle, para hablar de cómo utilizar acoplamiento, o no acoplamiento, etc etc, aunque reconozco que es un tema interesante que nos podría ayudar a centrarnos en el curro, no es la temática en esta ocasión, pero bueno, igual hasta le doy una vuelta mentalmente y preparo algo, porque me parece interesante lo que propones y la desesperación generalizada del mantenimiento de aplicaciones cuando la duración de las mismas es relativamente medio - alto.
Es decir, ESO NO ES TRIVIAL, los principios de programación de Java, entiendo que SI SON TRIVIALES. No los relacionados con acoplación, cohesión, etc.... que favorecen el entendimiento mental y la organización mental de una aplicación (que para mí es la base del buen rendimiento de desarrollo). En fin.
Al grano, principalmente, la encuesta anterior sirve de base. Pero cualquier idea es bienvenida.
En fin chavales, ahí queda eso.
Por cierto Alfredo grata aportación por tu parte (desde tu experiencia) sobre los caminos que uno puede llevar. En general el nº de caminos en la vida es indeterminado o existen una serie de pautas para que a uno le vaya bien? Curiosidad filosófica existencial abstracta (y probablemente hipócrita no material) por mi parte, a ver cómo te comes esto :) JAJA
A mi me interesa el futuro de la plataforma - la JVM, lenguajes nuevos como Scala o Clojure, la nueva JDK8 etc. Vamos, información que puedo utilizar para planificar mi propio futuro, si merece la pena estudiar un tema u otro, etc.
Desde luego lo que no me interesa en el más mínimo son demos de la nueva funcionalidad de Weblogic!