Estaré en la III Jornada de Tecnologías Java en la Universidad de Alicante

Dentro de dos semanitas, el 1 de Diciembre tendré el placer de participar en la III Jornada de Tecnologías Java en la Universidad de Alicante a las que muy amáblemente me invitó a participar Domingo Gallardo.

El título de la charla es "Desarrollo y pruebas de proyectos Java en un entorno ágil" y bueno hablaré un poco sobre lo que voy contando aquí en este blog. Meteré bastantes batallitas irlándesas que es donde más me he empapado de todo lo que implica el agilismo, pero sobre todo intentaré explicar lo que significa para mi el ser un profesional del software, que es lo que siempre he querido ser, y como conseguirlo aplicando técnicas ágiles.

La charla lleva la coletilla Java pero será simplemente para poner algunos ejemplos. El 95% por cien de la presentación se puede aplicar a cualquier lenguaje. Pues nada, que os animo a pasaros por allí.

Ofertas de trabajo en Abiquo, Barcelona

Diego Mariño, co-fundador de Abiquo me manda una serie de ofertas para que las publique por aquí, a falta de estar Jobsket listo para empresas :) Tal como anda la cosa es algo raro que alguna empresa busque de golpe más de cinco personas, pero esta empresa está en una fase importante de expansión y puede ser una buena oportunidad si alguien vive o no tiene problemas en mudarse a Barcelona. Además, que no se puede decir que haya muchas empresas innovadoras y donde pueda trabajar en cloud computing en España (¿hay alguna otra?) al tiempo en que compites contras superpotencias como Amazon, IBM, Microsoft, etc. así que seguro que hay emoción.

Os dejo por aquí los enlaces a las mismas por si no conocéis la empresa:

Java Architect

Tasks and responsibilities

* Develop standards and guidelines for the products
* Rollout and train guidelines to development teams
* Coordinate technical decisions
* Review and approve technical designs
* Manage the consistency, integrity and reliability of the architecture
* Advise senior management on current and future technologies
* You will report directly to the Chief Technology Officer



Senior Java Developer

Key Experience:

Core Java, Hibernate, Spring, Web Services, Java Software Engineer/Developer



Java Engineer

Key Experience:

Core Java, Hibernate, Spring, Web Services, Java Software Engineer/Developer.



Senior Flex Developer

We have 2 important opportunities available for highly skilled experienced senior flex/java developers to join the team. You should have more than 2 of years of development experience with Flex (client-side) and Java Developing (server-side) with a smattering of design and usability. It is equally important being formerly a hands on developer.



Virtualization Expert

Key Requirements

* Master’s or Bachelor’s Degree in Computing Science
* VMWARE, XEN, KVM, VirtualBox, Hyper-V (Installation and Administration)
* Storage Systems (OpenStorage, netApp, dell equalogic, etc)
* Network (Virtual Switch, network infrastructure, etc.)
* Programming skills (scripting, JAVA, etc.)
* Excellent communication skills (English & Spanish)



SysAdmin

Tasks and responsibilities

* Coordinate technical decisions
* Review and approve technical designs
* Manage the consistency, integrity and reliability of the architecture
* Advise senior management on current and future technologies
* Give support to the customers
* Maintain multiple services (web server, DNS, etc)
* Maintain and improve development environment
* You will report to the Chief Technology OfficerTasks and responsibilities



QA Test Engineer

* Test requirements and specifications for incorrect or incomplete information, assumptions and conclusions
* Apply that knowledge in the development and implementation of test plans, test objectives and test scheduling
* Organise and carry out functional and non-functional testing within an iterative Scrum-based development environment
* Collaborate closely with developers, product managers and support engineers to correctly identify, prioritise and resolve issues
* Create, review and maintain robust automated regression and data-driven tests
* You will report directly to the Chief Technology Officer

Todos los detalles en el post de su blog. Mucha suerte si os apuntáis.

Tus builds de Hudson en Campfire

Ojeando los plugins de Hudson he descubierto de casualidad que desde hace un par de semanas está disponible un plugin para Campfire. Lo que quiere decir es que puedes configurar tus build para que publiquen sus resultados en Campfire. Para los que se nos olvida chequear el email y se nos pasa que hemos roto la build.

La página del plugin es esta y su instalación es trivial. Ojo que es necesario tener la última versión de Hudson para que funcione. Aquí tenéis el anuncio por parte de los autores. Una captura con la configuración:



Y su consiguiente resultado en Campfire:

Como sacar un producto en Internet con presupuesto 0

Los chicos de TetuanValley han creado hace poco una escuela para Startups y hace unos días pedían en Twitter videos de empresas o personas que tuvieran algunos consejos para los equipos de la escuela.

En Jobsket nos hemos animado a mandar algo, y fruto de esto es el video que podéis ver a continuación:

Bootstrapping tips for the guys at TetuanValley from Jobsket on Vimeo.

Un colega me comentaba el look vagabundo que tengo en ese video, jejejeje, pero es que eso es parte de uno de los tips. ¡Ahorro de Costes! Así que hay que ahorrar hasta en crema de afeitar :D

En fin, el video está en inglés, pero un inglés de ese de los nuestros así que debería ser fácil de entender. Por si alguien no lo entiende os resumo los consejillos:

• No buscar dinero de VCs o Business Angels al principio, al menos si no tienes contactos. Porque sólo con la idea es enormemente difícil, y si encima sois todos técnicos entonces hay 0 posibilidades.


• Trabajar a tiempo parcial manteniendo el trabajo normal. Eso debería servir para ahorrar algo de dinero y forzar un poco de sacrificio. El sacrificio es bueno para ver si todos los socios están en el mismo barco.


• Ahorrar por todas partes. Por ejemplo, nada de lujos como el cloud computing, con un simple servidorcillo virtual llega más que de sobra para tener ir prototipando.


• No planear a largo plazo. Iteraciones de desarrollo y crecimiento muy cortas y que siempre generen algo "palpable". Pensar en tener algo a 4, 6, 12 meses es una locura, porque eso nunca pasa. Cuando no se tiene financiación, nunca se sabe cuando puedes tener una oportunidad para enseñar tu producto o cuando alguien se va a interesar por el. Por eso es muy importante forzarte a que cada poco tiempo, por ejemplo dos semanas, haya que desplegar un producto totalmente funcional. A partir de ahí, construir incrementalmente.


• Buscar concursos buenos, bonitos y baratos. Los concursos nos permiten validar nuestra idea. Si ganamos o quedamos finalistas, significa que hay gente a la que le gusta. Si nunca llegamos a las finales, hay que obtener feedback porque es posible que no nos demos cuenta de algo que el resto de gente sí que está viendo en nuestro proyecto y que evita que triunfe. Si ganamos, es dinero barato porque muchas veces estos concursos no piden parte de tu compañía. La beca alzado 2009 es uno de esos concursos ideales. Desconfiar de otros concursos que buscan más su autopromoción (ej: para participar tendrás que invitar a 100 amigos de tu Facebook al concurso) que el ayudar al emprendedor.

Y nada más. ¡Espero que a alguien le sirva de algo!

Benchmarking IT Industry 2009 : España por los suelos

Ninguna sorpresa. He llegado a un informe del mes pasado de la publicación británica The Economist donde analizan la fuerza de la industría de las TI en diferentes países de todo el mundo. Podéis ver vosotros mismos el informe desde este enlace.

Como era de esperar, la clasificación de España, por los suelos. En el mundo hemos nos colocamos en el puesto 25 justo por encima de potencias IT como son la republica Checa, Chile, Hungría, Eslovenia, Portugal, Lituania o Grecia por ejemplo. El número es mejor, aunque no la clasificación si nos limitamos a Europa Occidental. Ahí ocupamos el puesto 14, sólamente por encima de Portugal y Grecia.

Ahondando un poco en las razones, la puntuación para lo que el informe llama "Entorno de investigación y desarrollo" es prácticamente tercermundista, superando sólo a países como Portugal, Polonia, Mexico, Tailandia, Turkia, Bulgaria, Colombia, y en fin... supongo que os imaginais el resto de la lista.

Como siempre, por la cola. ¿Cuántas crisis tendrán que llegar para que espabilemos?

Google es como Ikea...

Durante las últimas semanas han coincidido los lanzamientos de una serie de productos por parte de Google. A diferencia de lo que sucede en otras ocasiones donde estos lanzamientos pasan más o menos sin pena ni gloria, en esta ocasión estos lanzamientos han causado bastante inquietud en la comunidad emprendedora. Por una parte tenemos el lanzamiento de Google Maps Navigation que ha demostrado la parte más temible de Google y que es la capacidad de hundir las acciones de empresas a priori sólidas como TomTom o Garmin simplemente con un anuncio.

Poco después Google agitó el mercado emprendedor español, donde tanto abundan los comparadores de todo tipo, lanzando un comparador de hipotecas, que parece ser que será el primero de una serie de comparadores. Otros dos servicios que causan enorme inquietud en los emprendedores españoles, y me imagino que internacionales, son Google Music y Google Books.

El año que viene, Ikea abre en La Coruña. Todas las tiendas de muebles de la ciudad y alrededores están acongojadas. Ya sabéis, es el "El año que viene llega Ikea, vamos a cerrar la mitad". Más o menos como con los libros, la música, la salud, el gps, los comparadores o cualquier otra cosa sobre la que Google lanza un proyecto. Al fin y al cabo, Ikea es tan grande, tan todopoderosa, tan "fashion", tan barata, tan todo, que no se nos puede ocurrir como alguien podría no comprar en Ikea.

Pues bien, que me perdonen los fans de Ikea que sé que hay muchos, pero a mi no me gustan los muebles de Ikea, y como a mi a muchos otros. Lo primero es que Ikea no es precisamente barato. A ver, me corrijo, porque en Ikea hay cosas baratísimas, pero claro, la calidad de estas cosas está en niveles de bajo cero. A no ser que te guste sentarte en dos bandas de espuma baratas grapadas a unas placa de aglomerado sin cubrir de 1 cm. de espesor. Vamos, que los sofas y mesas de un piso en el que vivimos y que eran de Ikea se levantaban con una mano. Eso sí, un sofá 80 euros. Poco duró en casa, evidentemente.

Hace unos años Ikea abrió en Oviedo. La gente estaba loca por ir. De hecho, aún hoy hay mucha gente que va desde Galicia hasta allí a comprar. Las tiendas de muebles de la zona estaban en modo pánico, porque además Asturias siempre ha sido la zona del norte de España más proclive en lo que respecta a la fabricación de mueble. Pues bien, hoy en día, tras unos años de Ikea operando, si les preguntas a aquellos que estaban aterrorizados por la llegada de Ikea te dirán "¿Ikea? Bah, esos nada. Vendemos nosotros más que ellos".

Evidentemente, no es cierto, porque Ikea factura millones. Pero lo que sí que es cierto es que las ventas de las tiendas y fábricantes han aumentando, lejos de disminuir como se vaticinaba antes de la llegada del gigante sueco. ¿Por qué? Pues porque Ikea lejos de ser un depredador de mercado ha venido a ser un catalizador de las ventas de otras fábricas y tiendas tradicionales. El público de las mueblerías tradicionales no es el público de Ikea. A Ikea se va a por mueble barato, "que de el pego", y esa gente ya no te iba a una mueblería tradicional, sino a outlets. Y los clientes de siempre que se compran algo en Ikea, la mayoría encuentran que los muebles buenos son carísimos, y que si compran los baratos pues los tienen que cambiar a los pocos meses ya sea porque se desmontan, porque no aguantan las embestidas de los niños o porque se les ha ocurrido mirar como están hechos y se han asustado.

Y tras este super rollo, engancho las dos historias :) ¿Alguien se acuerda de jaiku, google catalog, google notebook, google bookmarks, google mashup, etc.? Incluso proyectos gomo google health, Google Scholar, Google Blog Search... ¿alguien los usa? Bueno el Google Health lo dudo la verdad. El Blog search yo lo uso, pero tan de vez en cuando. Otro más, Google Reader. Yo lo uso pero cambiaría sin problemas. ¿Google App Engine? Iba a revolucionar el hosting, y tras tantas caidas y fallos ya da miedo usarlo, ahí no me cogen ni de broma. Muchos de estos proyectos tienen sus usuarios, pero no dejan de ser usuarios que buscan algo gratis (i.e. que ya no iban a comprar tu servicio de ningún modo) o que ni se molestan en buscar alternativas mejores, simplemente lo escogen porque es más sencillo. Pues lo mismo que hacemos muchos con Google Docs, y que no se te ocurra hacer una hoja de cálculo seria con Google Docs porque después te va a dar la risa. ¿Google Wave? Visto lo que dice la gente, ni creo que lo pruebe.

Así que si nuestro producto es bueno, diferenciador, sí ofrecemos algo de calidad, sí tenemos nuestro grupo de fieles clientes contentos con la atención que les prestamos, pues yo creo que no habría nada que temer por mucho que Google entrase en nuestro nicho de mercado. Al contrario. Google trae mucho más atención al sector, publicidad, crea competencia, nos obliga a mejorar nuestro servicio y la atención que le prestamos al cliente, y en definitiva redunda en mejorar nuestro producto.

Sin más, y para cerrar desde este modestísimo espacio, no me queda más que apelar a la tranquilidad, que el tener a Google en el mercado muchas veces trae beneficios que dolores de cabeza (a no ser que cotizes en bolsa) , y que si nuestra oferta es lo suficientemente buena seguro que no hay Google que nos tosa :)

¡Hay que respetar la build!

En una de mis últimas empresas, allá por Irlanda (como pasa el tiempo, oiga) teníamos unos 30 desarrolladores. De entre todos estos, unos 10 estaban en Polonia, los demás estábamos en Irlanda. A parte de todo esto teníamos una consultora en el Reino Unido con unas 10 personas que se dedicaban a mantenimiento. Todas estas personas podían tocar la build.

El principal, con mayúsculas, problema con el que nos encontrábamos era la cantidad de commits que se hacían. El proyecto estaba en una fase fuerte de crecimiento así que había montones de funcionalidades que subir. Esto hacía que los commits fuesen constantes, y difíciles de controlar. Y como en toda época de rush, como no, las revisiones de código destacaban por su ausencia.

Total, que con tal cantidad de commits simultáneos, por muchos tests que hiciésemos (que se hacían) era muy habitual el romper la build. Pero ese no era el problema. El problema de verdad es que la gente seguía haciendo commits cuando la build estaba rota, lo cual presenta varios problemas:

1. No sabes que tu código va a funcionar. Por mucho que esté funcionando en tu build local, al estar la build rota, no tienes la certeza de los cambios que ha subido otra gente, así que nunca sabes si esos cambios te pueden afectar.


2. Si no se protege la build, os cambios se acumulan. Todos esos cambios, son cambios no probados en un entorno de integración. Cuanto más tiempo pase, más grande es el problema. Cuantos más commits se acepten con una build rota, más problemas potenciales están entrando en el código. El número de errores crece. El código se vuelve más inestable.


3. A mayor número de cambios, más difícil es el recuperar la build. Si los cambios se van acumulando y acumulando, nos encontraremos que al corregir el primer error aparecen más errores. La única solución que queda es ir corrigiendo error tras error hasta que la build vuelva a funcionar. Cuanto más código incontrolado permitamos, más tiempo nos llevará arreglar la build.


4. En el peor de los casos, no hay otra solución que volver atrás. En el peor de los casos nos encontraremos con que el código que se ha subido se cruza y no queda más remedio que revertir los cambios, con la consiguiente perdida de tiempo. Los equipos tendrán que pararse y ver por qué sus funcionalidades se han solapado.

Todo esto se ilustra en la captura de pantalla siguiente:



Entre 1 y 2 hay un montón de commits. Llega un momento en el que alguien se da cuenta de que se ha roto la build, y comienza el proceso de arreglar la build. En 2 se arregla algo, pero no es suficiente. En 3 algo más, pero sigue sin ser suficiente. En 4 finalmente se arregla, pero han sido necesarios 10 arreglillos para conseguirlo. Cuando si la build se hubiese arreglado en el momento de detectar el error no se hubiese perdido tanto tiempo.

¿Soluciones?

• Involucración del equipo. La build debe de ser colectiva y todo el mundo tiene parte de responsabilidad en controlar que esté siempre sana. Muy a menudo la responsabilidad recae sobre el jefe de equipo, y si este falta se hace la vista gorda. Esto al final perjudica a todos. Si alguien ve que la build está rota, debe alertar de ello e investigar a ver qué está pasando.


• No hacer commits si la build está rota. Tan simple como esto. Si la build se rompe, lo mejor es no hacer commits. No importa que el código sea muy urgente. Como desarrolladores, si hacemos commits, puede ser mucho peor para nosotros. Es mucho más efectivo el esperar a que la build esté estable y subir el código con la seguridad de que no vamos a romper nada. Además, así nadie nos meterá en el lio de arreglar la build después ;)


• La técnica de la botella. Si las dos primeras no funcionan, la técnica de la botella es super-efectiva. Ya había escrito sobre eso aquí. Se compra una botella, que sea grande que hará falta. Cada vez que alguien rompe la build, se ponen 50 céntimos, un euro o algo así. Que no sean 10 céntimos porque entonces no duele demasiado :) Esto es mano de santo. En cuanto alguien ve que se va dejando un par de euros al día, pasa a ser mucho más cuidadoso con los cambios que hace. Además tras unos meses se puede hacer una cena a la salud de la build. La desventaja de este sistema es que no funciona demasiado bien con equipos deslocalizados :)



• No permitir commits. Podríamos bloquear el repositorio de código fuente si la build se rompe. Esta es una solución bastante drástica que normalmente es perjudicial. Puede funcionar bien sólo cuando el equipo es pequeño. Si el equipo es grande y hay mucho código, esta medida tendrá el efecto de cuello de botella.


• Revertir automáticamente el código que ha causado el error. Esta fue la medida que se aplicó en la empresa que os comentaba antes. La situación era tan complicada que no quedó más remedio que revertir de inmediato cualquier código que rompiese la build. Es un poco drástico pero dada la magnitud del problema, fue necesario. La gente comenzó a ser mucho más cuidadosa cuando veía que sus cambios se rechazaban una y otra vez.


• Build en dos fases. En sistemas y equipos complejos. Otra alternativa es mantener dos builds. Una más inestable, en la que los desarrolladores van haciendo sus commits, y otra estable que nunca fallará. La primera sería una build permisiva, pero que como siempre, habría que respetar. La segunda aceptaría sólo código que ha pasado la primera build, y siempre estaría completamente estable. La idea es que si alguien necesita el código más reciente en cualquier momento, no tenga que esperar a que se arregle la build. Esto yo lo veo como un modelo complejo sólo apto para empresas grandes que tengan necesidades muy específicas.

En fin este tema daría para mucho hablar. Seguro que muchos estais familiarizados con el mismo y lo vivis en el día a día. Me encantaría leer vuestros comentarios y saber si tenéis este tipo de problemas y que hacéis vosotros para solucionarlos.

OWASP Podcasts y entrevista el manager de desarrollo seguro de Paypal

De OWASP ya he escrito en otras ocasiones. Es una asociación para la promoción de la seguridad en la red que no conocía, y con la que tuve contacto por primera vez en Irlanda, aunque tienen también su capítulo en España.

Una de las cosas que empezaron a finales del año pasado y que han desarrollado bastante este año es la publicación de un Podcast sobre seguridad bastante imprescindible para el que le interese estos temas. A mi personalmente muchos de los temas ahí ya se me quedan un poco grandes, sin embargo sí que me llamó un poco más la atención un podcast de hace unas semanas en el que hacían una entrevista a Andy Steingruebl (PayPal Secure Development Manager).

En el Podcast Andy comanta su experiencia en Paypal y realiza una serie de recomendaciones. He recogido unas cuantas notas del podcast que tenía pendientes de publicar y que pongo a continuación:

• CSRF y Cross-site Scripting son los problemas más grandes en la actualidad. Cosas como SQL Injection todavía están muy presentes pero existe más educación sobre ellas y las soluciones son mucho más conocidas.


• Una vez establecidos unos protocolos de acción y una buena metodología de trabajo los costes de hacer desarrollo de software seguro e inseguro no se diferencian tanto. Hay montones de librerías y utilidades disponibles en la red. El coste está más en conseguir la disciplina y la mentalidad en una organización para que se apliquen prácticas de desarrollo seguras.


• Aplicar técnicas de desarrollo seguro en metodologías ágiles es más complicado ya que se centran siempre en pequeñas ventañas de funcionalidades. Es posible, pero es más complicado que con metodologías adhoc.
  
  (sinceramente, aquí no le vi sentido a esto. Estoy bastante en desacuerdo. Me imagino que el problema es más de adaptar una gran empresa como Paypal y todos sus planes que tienen que realizar para auditorías de seguridad a las metodologías ágiles que otra cosa.)


• No reinventar la rueda. Reutilizar frameworks de seguridad.


• Aunque los IDEs incluyen herramientas de análisis estático todavía hay mercado para esas herramientas. Hay muchas compañías pagando por herramientas específicas para el análisis estático de código.


• Alguién sugería la necesidad de 150.000 profesionales del software. Andy se muestra en desacuerdo y opta más por la formación y aprendizaje como la solución. Educar a los desarrolladores e incluso incluir nociones de seguridad en la formación universitaria. Los desarrolladores no necesitan ser expertos en seguridad, pero sí que deberían tener conocimientos básicos sobre los ataques más comunes y sus soluciones, así como conocimientos de que herramientas y librerías utilizar para prevenir estos ataques.


• PCI no es una mala certificación ya que al menos fuerza a las personas a tomar algunas medidas de seguridad. Aún así, eso debería salir directamente de las empresas y no ser medidas encaminadas únicamente a pasar la auditoría.

Volviendo al tema del agilismo, el podcast en sí está bien pero la parte de que las metodologías ágiles hacían más difícil el desarrollo seguro no tiene ni pies ni cabeza.