Resumen de Agilismo.es en AdictosAlTrabajo

Que envidia la nota sobre el primer coding dojo organizado por agilismo.es en Madrid. En AdictosAlTrabajo publican una nota sobre como fue este evento. Destacan la edad de los participantes, parece que el preocuparse por tu código, por su calidad, por hacer bien lo que te gusta y en definitiva, por ser un buen profesional viene más a los treinta que a los veinte.

El video sirve para ponerle la cara a muchas de las personas que frecuentan Agile Spain. Y se nota que había muy buen rollo.

Instantáneas del almacén de Amazon en UK

Un poco fuera de contexto pero no puedo evitar poner esta foto:



Se trata del almacén de Amazon en Milton Keynes, al sureste de Inglaterra. Impresionante. Le dedican un artículo en el Daily Mail.

Update: Creo que el de Swansea no se queda corto:



Más instantáneas aquí.

Podcast sobre test de aplicaciones

En javaHispano han publicado un podcast hace unos días donde participan Alfredo Casado, Julio César Pérez y Jose Luis Bugarín y que se lo recomendaría a todo el mundo ya que explica muy bien el por qué es tan importante hacer testing, sus beneficios y todo lo que no perdemos al no hacerlo. Al igual que comentaba yo mismo en mi charla en Alicante, de la que todavía tengo pendiente el escribir varios posts, estamos en un momento donde una persona que no haga tests no se puede considerar un buen profesional. Señores, quitémonos el chip de monos picateclas porque el desarrollo de software es mucho más, y el testing es sólo una de las habilidades que un desarrollador ha de tener. Muy buen podcast.



El podcast lo podéis escuchar aquí mismo o descargaros el MP3 original desde la página de javaHispano.

Apúntate a la Beca Alzado 2009

Desde hace unas semanas se pueden enviar ya proyectos para la Beca Alzado 2009. Se trata de un concurso donde tan sólo hay que enviar una idea y la que el jurado considere la mejor se llevará un premio de 3000 euros. Lo mejor del concurso es que no hay ataduras de ningún tipo, es decir, el ganador del concurso no tendrá que ceder una parte de su empresa ni hacer nada a cambio. Tampoco hay ninguna fase de votación popular que tanto favorecen a los proyectos con comunidades establecidas, ni es necesario pues el mendigar votos por Internet o convertirte en fan del concruso en Facebook y estrategias similares que simplemente buscan promocionar el concurso.

En el 2008 nosotros ganamos la Beca Alzado y tengo que decir que todo lo prometido es cierto. Ninguna atadura. 3000 euros y listo. ¡Y que bien nos han venido! Quizás el hecho de que hubiese ganado un proyecto como Jobsket, tan complejo, esté echando un poco atrás a alguna gente este año, pero lo cierto es que me han comentado que el número de proyectos inscritos está siendo menor. Es por ello que os animo a todos a enviar vuestra ideas, ya que es algo que no lleva demasiado tiempo y si tenéis algo en mente, el ganar puede ser una enorme excusa para materializarlo.

Así que ánimo y mucha suerte a los que se presenten.

Transparencias III Jornadas Java de Alicante

Ayer estuve hablando en las III Jornadas de tecnología Java en Alicante donde estuve hablando de metodologías ágiles y de como aplicar algunos de sus principios en lenguaje Java.

Creo que la charla fue bien y bueno os dejo aquí las transparencias. Me reservaré unos cuantos posts para hablar de la parte de historietas de guerra que en las transparencias no queda muy claro lo que significa.

Desarrollo con Java y metodologías agiles

View more documents from Jobsket.

Una pena no poder poneros el video pero a mitad de la charla se le acabó la pila al micrófono así que dejo de funcionar y no se oía nada por el streaming.

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.

Hablando sobre Jobsket en Inconformia.tv

María Encinar me ha hecho una entrevista para inconformia.tv una iniciativa muy interesante que ha creado y en la que María realiza entrevistas cortas, no más de cinco minutos, a emprendedores gallegos.

Nada, os dejo aquí el video por si alguno quiere conocer como nació Jobsket y cuales son nuestros planes para el futuro.



Y tengo que mejorar las caras porque así a simple vista parece que me estoy cagando.

Una VC que no invierte, ¿es una VC?

Ahí va un post bastante crítico, que tengo un poco oxidado el blog. Hace unos días estuve en un evento donde una firma de capital de riesgo exponía sus productos, su experiencia y explicaba en qué consistía el capital de riesgo, todo lo bueno y todo lo malo inherente a esta forma de obtener financiación, una serie de consejos y anécdotas sobre todos los proyectos que iban recibiendo.

El nombre y los detalles quedarán en el anonimato. Eso sí, el ponente era muy, pero que muy accesible y franco, cosa que se agradece enormemente. El fondo se creó en el 2008 con una cantidad de 30 millones de euros, casi nada. En breve entrarán más inversores que ya están firmados y que ampliarán el capital hasta 40 millones de euros y su objetivo es el llegar muy pronto a los 100 millones de euros.

La charla como comentaba anteriormente fue muy directa, dejando claro que las empresas de capital de riesgo no son hermanas de la caridad y pretenden ganar dinero con nosotros, mucho dinero. Para ello pues harán todo lo que esté en sus manos llegando incluso a participar en la toma de decisiones de la empresa si fuese esto necesario, algo que parece lógico espcialmente si la inversión es grande.

Pero la franqueza de la charla llega a su punto cúlmine cuando el ponente reconoce que este fondo, en algo más de año y medio de funcionamiento, ...... ¡no han hecho ni una sóla inversión! Aquí hablo de un fondo donde el plantemiento inicial era la inversión de 3 millones de euros por proyecto pero que debido a la falta de proyectos abrió su abanico a cualquier cantidad.

Y aquí es donde inocente de mi, no acabo de entender algo. Si tenemos un fondo tan bueno, que no desecha ninguna idea, que no desecha ninguna cantidad, que invierte en cualquier sector (cosas en las que el ponente insistió bastante), y que ha recibido en este momento algo más de 100 proyectos ¡¿cómo puede ser que no invierta en ningún proyecto?! ¿Tan malos eran? Porque haciendo unas cuentas muy fáciles, 100.000 euros de inversión, que por otra parte pueden ser mucho dinero para algunos proyectos, no són más que el 0,33% del capital de un fondo de 30 millones de euros. ¡¡¡Cómo puede ser que un fondo de capital de riesgo no pueda permitirse el lujo de tirar a la basura en el peor de los casos el 0,33% de su capital!!!

Y con esas toco irse, pensando en si tendría sentido alguno el enviar un plan de negocio a un fondo que ha desechado todo lo que le ha llegado. En defensa de los gestores del fondo, se dio a entender que los problemas podrían estar derivados del desacuerdo entre los socios a la hora de invertir. Y es que me imagino que quizás estos socios en épocas de crisis lo que menos les apetezca es darle su dinero a unos extraños y que prefieran simplemente aprovechar las ventajas fiscales de las S.C.R.

Imagen via spierzchala@flickr

Mañana, iniciador Galicia

Sé que estoy dejando un poquito de lado este blog, pero no os podéis imaginar la de tiempo que quita Jobsket. Y eso que me encantaría comentar un montón de cosas, pero nada, te metes en una cosa, en otra, en mejorar esto en aquello otro y al final es hora de dormir.

En fin, mañana toca un descanso y me voy pasar por Iniciador Galicia. Esta vez el presentador es Jacobo Lázare, fundador de DiscoAzul y de BidoBido.com, siendo este último el proyecto que está intentando lanzar ahora mismo con el patrocinio de Rudy Fernández.

El evento es en Coruña, en el ITE Caixa Galicia, y nada que si algún gallego lee esto, sé que es un poco apresurado pero en especial los de Coruña no deberías perdéroslo porque no es que abunden este tipo de iniciativas.

Unos días en Barcelona

Un post muy rápido para comentar que mañana Martes cojo un avión a Barcelona para pasar unos días. Aprovecharé para pasarme por el Iniciador Barcelona de este mes y ver como anda todo el tema de los emprendedores por la ciudad condal.

Estaré en total un par de días, llego el Martes y me voy el Jueves así que sería tiempo suficiente así que si a alguien de los que se pasa por este humilde blog le apetece quedar para tomar algo pues sólo tiene que mandarme un correo.

Saludos!

Paypal X

En webpayments.ie hablan más sobre un producto que promete revolucionar el mercado: Paypal X.

Todo comienza en Julio cuando en TechCrunch publican un documento filtrado que muestra los planes de Paypal de sacar un API para desarrolladores.

El caso es que desde ahora uno ya puede registrarse para la versión beta de este API que parece que será lanzada en Noviembre. Pero hasta que el API esté disponible, está claro que lo más curioso sobre este producto es el dominio que han escogido. Nada más y nada menos que X.com. En este post se cuenta la historia tras el nombre y el dominio, que también se puede ver brevemente en la entrada sobre Paypal en la wikipedia.

Básicamente x.com era un banco online fundado por Elon Musk (cofundador de Paypal) en el 1999 y que en el 2001 cambio su nombre a Paypal tras de algún modo comprar la compañía. Aún así el dominio quedó por ahí, apuntando a paypal, y vaya que no les habrá llevado visitas.



Total que por ahora no nos queda otra que esperar a Noviembre a que anuncien de que va el API en su developers forum y seguir su blog. Aunque bueno, si total ya sabemos que lo que saquen seguramente no funcionará en Europa, y mucho menos en España. Pero venga, voto de confianza por ahora porque se supone que será un API de pagos global. Ya veremos, ya veremos.

Pero que vaya, que a mi lo que me sigue gustando es el dominio x.com. ¿Cuánto valdrá ese nombre de dominio? :)

Programadores españoles vs. programadores europeos

Hay una pregunta bastante recurrente cuando hablo con gente que se dedica a esto del software en España sobre mi paso por Irlanda:

Y qué, allí en Irlanda en programación, un nivelazo, ¿no?.

En mis casi tres años por Irlanda no se puede decir que pueda extrapolar resultados a toda Europa pero sí que he tenido la suerte de trabajar con gente de muchísimos países diferentes. Irlandeses, ingleses, franceses, italianos, portugueses, eslovacos, polacos, serbios, croatas, lituanos, rusos, rumanos, holandeses, etc. En Irlanda tienen un problema importante que es la carencia de gente en lo que son las tecnologías de la información. Es algo conocido, y en parte sorprendente porque los salarios en el sector son bastante altos. Comentaban en un día en un debate que la percepción de la juventud sobre las TI es que es algo de geeks, y como un geek es casi sinónimo de impopularidad y fracaso con las mujeres, que muchos chicos deciden evitar la carrera.

En fin que en todo ese tiempo la principal conclusión que saqué es que "hay de todo como en botica". En ese tiempo me encontré con auténticos ineptos y con verdaderos cracks. Recuerdo un chico eslovaco por ejemplo que era un genio absoluto, primero de su promoción y cualquier cosa que le comentabas por muy compleja que fuese la absorbía de inmediato. En general la gente de los países del Este era bastante apta, pero sí que notabas que unos eran muy buenos y otros tenían bastantes carencias. Nada de eso que me tiene comentado alguno "los excepcionales programadores rusos"... sí, quizás sean excepcionales, pero si después no hablan de poco nos valen.

El nivel de los irlandeses, seamos sinceros, en general es bajo, bastante bajo. Pero ojo, que también te encuentras con tipos excepcionales. Uno de los amigos que me llevé de mi estancia allí es un auténtico figura, simplemente impresionante, y otros estaban allí porque les pilló el tigre celta limpiando teclados, con todo el respeto para el que limpie teclados. En Irlanda es muy común encontrar gente bastante pobre tanto técnicamente como en cuanto a materia de negocios en puestos altos, ya que simplemente se encontraban en el sitio adecuado y el momento adecuado.

Después estamos los españoles. Los españoles en Irlanda tenemos fama de juerguistas. Que raro, ¿no? Por lo general, de desgraciados, aunque caemos bien porque al final los europeos se lo pasan pipa en España. En cuanto a las TI sin embargo, los españoles tenemos fama de buenos trabajadores. Y la verdad es que todos los españoles que he conocido en Irlanda que trabajen en esto del software están muy, pero que muy bien considerados. Y he tenido la suerte de conocer a verdaderos cracks. En serio, en cuanto a trabajo, ni punto de comparación con otros países. Quizás es que estamos acostumbrados a jornadas de 12 horas, y después cuando nos hacen trabajar 7 horas y media pues no nos llega a nada, pero por lo general los españoles eramos de lo más productivo allá.

Y nada, pues eso más o menos ha sido lo que he sentido yo en mi estancia por Irlanda. Las veces que he ido por otros países, sinceramente más de lo mismo. Así que si alguno se está cortando en la idea de emigrar, simplemente por complejo de inferioridad: que se lo quite de inmediato, porque sino igual está perdiendo una gran oportunidad y seguro que si se anima a viajar se llevará una desilusión por el nivel que va a encontrar. Aquí en España podemos estar bastante contentos con el nivel que tenemos en cuanto a formación y capacidades, y eso que en las empresas de formación poca y de sueldos menos aún.

Suerte si os animáis!

Imagen via Jesper@flickr

Agile Open Spain, Octubre 2009, Madrid

En Agile Spain han anunciado el Agile Open Spain un evento que promete ser muy interesante. Me permito copiar de su página web:

Con los objetivos de difundir las metodologías ágiles en España (Scrum, eXtreme Programming. Lean Software Development) y compartir experiencias, el viernes 23 de octubre por la tarde y el sábado completo tendrá lugar el primer Agile Open Spain en las instalaciones de la Escuela Universitaria de Informática en el Campus Sur de la Universidad Politécnica de Madrid.

El Agile Open Spain es un evento sin ánimo de lucro organizado de manera muy participativa. Esta diseñado para compartir entre los asistentes sus experiencias, ideas, experimentos y retos sobre metodologías ágiles (despliegue, planificación ágil, retrospectivas, ingeniería, herramientas, gestión de producto, calidad, etc.), basándonos en el formato de Open Space, para promover la colaboración y que la conferencia se convierta en aquello que sus asistentes deseen. No existe una agenda fijada, sino que entre todos crearemos la conferencia, elegiendo temas y participando. Contaremos con algunas de las personas que más saben de metodologías ágiles en España, así que ten por seguro que la conversación será interesante.

España no destaca por la cantidad de eventos independientes relacionados con el agilismo, así que esta se me antoja como una oportunidad muy buena para aprender, compartir y conocer experiencias, hacer networking, y en definitiva empaparse de todo lo que el agilismo puede ofrecer.

Podéis ver la localización aquí e inscribiros en el evento desde este enlace. El evento es gratuito y las plazas son limitadas.

Centros de datos

Me encanta. Siempre genial...



El original aquí.

Sharding, ¿sí o no?

Facebook, Digg y muchos otros utilizan una técnica denominada Sharding para escalar.

El Sharding es una técnica que consiste en particionar los datos de tu base de datos horizontalmente agrupándolos de algún modo que tenga sentido y que permita un direccionamiento más rápido. Una agrupación típica puede ser por id por ejemplo: "los usuarios del 1 al millón están en esta base de datos"; o por nombre "los usuarios cuyo nombre va de la A a la E" están en esta base de datos".

Típicamente estos shards, agrupaciones o segmentos estarán localizados en tablas en diferentes bases de datos y localizaciones físicas. El Sharding no tiene por qué estar basado únicamente en una tabla y una columna, puede ser a nivel de todas las tablas. Por ejemplo podríamos decir "todos los datos de usuarios cuyo perfil está en los Estados Unidos los redirigimos a la base de datos del servidor en Estados Unidos, y todos los de Asia van a la base de datos de Asia".

El Sharding como tal mejora la escalabilidad y el rendimiento al agrupar menos datos en tablas más pequeñas por lo que los accesos serán mucho más rápidos. En caso de tener múltiples servidores en múltiples localizaciones, el basar el Sharding en la localización geográfica permite también disminuir considerablemente la latencia.

¿Cuándo se necesita hacer Sharding? Principalmente cuando el volumen de datos comienza a ser inmanejable. A tablas más grandes, más lentos son los accesos. No es lo mismo acceder a una tabla de diez mil usuarios que a una tabla de diez millones de usuarios. También comentan en el blog del que hablaré en breve que es bueno hacer Sharding cuando el volumen de escrituras es demasiado grande para un único servidor. En bases de datos, escrituras=bloqueos, bloqueos=contención de recursos, contención de recursos=mala experiencia de usuario, a parte del problema con la sincronización con slaves.

Todo esto viene a cuento de que en el blog de rendimiento de MySQL nos advierten de por qué no deberíamos hacer Sharding prematuramente. El problema principal es que Sharding se ha convertido en una palabra de moda. A fin de cuentas, si Facebook lo hace, ¿por qué no lo voy a hacer yo? Pues porque yo no tengo 120 millones de usuarios activos, ¿quizás?

Mi opinión es que en general estoy de acuerdo con el no hacer Sharding desde el principio, pero sólo si este va a impactar en la estructura de la base de datos. Es decir, dividir los usuarios de la A-E, la F-M, ... etc. a bote pronto parece como una mala decisión, al menos sin saber si vamos a tener cien usuarios o cien mil.

Pero planificar para Sharding no siempre tiene por que ser una mala decisión. En Java por ejemplo hay herramientas que nos lo facilitan. En general, el particionar por aplicación o por país además no son decisiones demasiado relevantes y que no tienen porque impactar el desarrollo en sobremanera, al tiempo que en el futuro facilitan enormemente la escalabilidad del servicio. Eso sí, hay que tener claro que a mayor número de shards mayor mantenimiento. No es lo mismo actualizar un índice en una tabla que hacerlo en cinco, especialmente porque al hacerlo en cinco es más fácil el dejarse uno olvidado.

Mi CV

Los que seguís este blog ya sabéis que ando metido en Jobsket, y a ello estoy dedicando mis esfuerzos. Jobsket es la razón por la que quizás no estoy actualizando tan a menudo como debiera.

De hecho, en los dos en los últimos dos meses hemos trabajado tanto que apenas he tenido tiempo para bloggear. Dos meses y dos releases. La última la hemos anunciado hoy y viene con muchos cambios. Uno de ellos, y que a alguien quizás le interese es la posibilidad de incrustar tu CV en la web al más puro estilo scribd, docstoc y demás.

Aquí os dejo mi CV.

También ofrecemos otras formas de promoverlo como el CV en miniatura que se ve en este blog a la derecha, o un par de iconos de promoción nuevos que hemos añadido, además de poner "bookmarkearlo" en facebook, twitter, friendfeed y similares.

Así que nada, si queréis tener vuestro CV en su formato original en vuestra web para promoverlo o lo que sea, ya sabéis, sólo tenéis que registraros en Jobsket :)

El peor "unsubscribe" de la historia

Normalmente yo no escribo sobre usabilidad de usuario, porque no soy el más adecuado para hablar de ello, para eso ya hay gente muy buena por la blogosfera que lo hacen fenomenal. Pero es que estos días he estado anulando varias de mis subscripciones a boletines, y me he encontrado de todo.

Pero el premio al peor "unsubscribe" que he visto jamás se lo lleva el de Diageo. Ojo a la pantalla para anular la subscripción a su boletín:



Pero no les llegaría simplemente con un campo de texto para el correo....

Por cierto que no soy alcohólico, es que en Irlanda al menos la Guinness manda gratis merchandising muy chulo a casa :)

Dentro de twitter: sobre como funciona su equipo de gestión de operaciones

Hace unas semanas fue la Velocity 09 y en blip.tv están disponibles los videos. ¡Vaya montón de conferencias interesantes! El otro día estuve echándole un vistazo a la de Twiter de John Adams: "Fixing Twitter: Improving the Performance and Scalability of the World's Most Popular Micro-Blogging Site"


(perdón que me cargue el blog con este video, tengo que buscar una plantilla más moderna)

Como acostumbro, he tomado unas notas porque me gusta tenerlas por aquí de referencia.

• Su equipo de operaciones está formado por 8 personas. Funcionan más como un equipo de arquitectos de sistemas que como un centro operacional a la usanza. Se encargan de controlar la escalabilidad, el rendimiento, la disponibilidad, la planificación de la capacidad, etc.


• El mantenimiento de servidores está subcontratado con NTT America, así que ellos no tratan con los servidores físicos.


• No utilizan clouds. Lo intentaron pero no es para ellos. Comentan que por ciertas razones, no les funcionó. Uno de los argumentos que esgrimen es que necesitan métricas e información muy exacta.


• Crecer es doloroso. Hay un miedo institucionalizado a cualquier cambio. Así que ellos se rigen por un Mantra común. Buscar el punto más débil y solucionarlo. Después, proceder al siguiente punto más débil.


• Un consejo. Instrumetar todo lo que podáis. Pero ojo con instrumentar demasiado, especialmente con MySQL o Memcache por ejemplo.


• Utilizan herramientas como RRDTool, Ganglia o MRTG. Con el output de estas herramientas crean cuadros de mando. Ahora mismo tienen sobre 1200 métricas. Toda la compañía tiene acceso a los cuadros de mando. También agregan métricas de fuentes externas, por ejemplo de NTT America.



• Para recoger los datos de error, utilizan Google Analytics!


• Monitorizan todos los despliegues. Así pueden correlacionar los despliegues con las estadísticas del sitio web como puede ser la latencia. De esa forma detectan cambios hechos por desarrolladores que pueden tener un fuerte impacto.


• Otro consejo, si no habéis empezado a gestionar vuestra configuración. Hacerlo ya. Vale la pena. Ellos controlan los cambios en los ficheros usando diff y SVN. Tienen hooks de pre-commit y post-commit. Para hacer un cambio siempre debe ir acompañado de un comentario que especifique quien ha aprobado ese cambio. Una vez entra en el SVN se manda un correo a una lista de revisores. Los revisores reciben en su email el diff y aprueban el cambio o no. Si todo el mundo lo aprueba, el cambio se aplica.


• Para la comunicación utilizan Campfire. Muy contentos con el.


• Para atacar los problemas en los diferentes subsistemas utilizan fichas con "planes de ataque". Estás fichas incluyen, el síntoma, cual es el cuello de botella, el vector de elementos afectados y la solución propuesta. Este es un ejemplo:



• CPU, ahora consiguen más por menos. Pasaron de AMD a Intel Xeon y consiguieron un 30% de rendimiento más. Cambiando de dual y quad core a 8 cores consiguieron otro incremento del 40%.


• Rails. Ok, ruby es lento, pero hay formas de contrarestar esto. Tuvieron muchos problemas y mucho análisis que hacer, pero casi siempre el problema era debido, no a ruby sino a otras razones. La caché y la invalidación de la caché es un problema gordo, pero es más de memcache. ActiveRecord sí que les fue un problema ya que genera queries que a veces pueden tener muy mal rendimiento, lo que hace que la base de datos vaya más lenta y que la latencia en las colas se incremente. Otros problemas fueron la corrupción de datos en Memcache y el lag en la replicación de datos.


• El disco duro es la nueva cinta. La Web 2.0 no es posible sin enormes cantidades de memoria RAM. Los gráficos sociales ocupan mucha memoria. Facebook o Twitter, ambos tienen enormes pools de instancias de memcache.


• Twitter es tiempo-real pero hacen muchísimo caching. Utilizan diferentes pools de memcache para diferentes subsistemas para así prevenir la evicción prematura de datos. Los TTL van de 20 a 60 segundos pero para los usuarios que no usan mucho twitter pueden ser mayores. La mayor parte de los timelines se pueden
cachear ya que no varían demasiado. La creación de una página genera de 100 a 300 peticiones de memcache. Han contribuido varias optimizaciones a la librería de memcache de rails. Por ejemplo, cambiaron el algoritmo hash de MD5 a FNV lo que les supuso un aumento del rendimiento de 200x 300x. Han contribuido al Open Source Cache-Money una cache read y write-through para Ruby.

• Pero hay que tener cuidado. Cachear todo no es la mejor política. Ellos han tenido problemas de datos obsoletos, corrupción de las instancias de memcache, corrupción de los hash, etc.


• Utilizan colas de mensajería para la comunicación entre los diferentes demonios. Empezaron a desarrollarlo con Erlang, y les gustó, pero necesitas programadores con experiencia en erlang :S Así que cambiaron a Scala. Crearon Kestrel una solución interna que funciona como memcache.


• Otra de sus experiencias es lo que casi todas las webs de este tamaño comentan. Las bases de datos relacionales no son la panacea. Ellos se han saltado muchas normas porque la consistencia de los datos no resulta un gran problema para el tipo de aplicación que es Twitter.


• Hacen mucho cacheo web. Especialmente en Twitter Search. Utilizan Varnish.


• Muchos problemas con Mongrel al no ser multi-threaded, ya que tanto el tráfico interno como externo consume muchos recursos en forma de instancias de Mongrel. La solución para ellos ha sido mover muchas tareas fuera del ciclo de requests para hacer éste mucho más corto y ahorrar recursos. Muchos demonios externos.


• Sobre MySQL, nada que no se haya contado. Que las bases de datos relacionales no son muy aptas para los grafos sociales. Problemas de replicación. Un buen sharding es muy importante. Matan cualquier query que esté durando demasiado tiempo. Lo utilizan como mecanismo de auto-defensa.

Y eso es más o menos todo. Quizás me haya pasado con las notas, pero me ha parecido una charla muy interesante.

Cuenta gratis en Pingdom

Nota muy rápida por si alguien no está subscrito al blog de Pingdom. Ayer anunciaron que desde ahora pasan a ofrecer gratuitamente su herramienta de monitorización de sitios web. No es una trial, es una cuenta totalmente gratis, incluyendo 20 alertas SMS. Eso sí, está limitada a un único sitio web o servidor.

Podéis coger vuestra cuenta aquí. Servicios parecidos son ExternalTest del que Enrique Domínguez me cedió amablemente invitaciones para los lectores de este blog o webpagetest.

Edit: Muy rápido. Después de haberme dado de alta, aclaro lo de las limitaciones porque es algo engañoso. El límite es por un único chequeo, y no por servidor o página web. Es decir, para un mismo sitio web no podrás crear varias alertas sino tan sólo una. Le resta un poco la utilidad pero bueno... es gratis.

La historia de HOTorNOT

Allá por el año 2000 apareció una web llamada HOTorNOT. ¿A quién no le ha llegado alguna vez algún correo con un enlace de alguien? O ¿quién no ha pasado aunque sea unos minutos puntuando chicas y chicos? Recuerdo que allá por esas fechas me llegó uno de esos correos y al ver la web pensé, "puf, vaya chorrada, que perdida de tiempo". Pues esa perdida de tiempo se convirtió sin duda en uno de los sitios webs más populares del mundo, derivando posteriormente a un sitio de citas que convirtió a sus creadores en millonarios.

En fin, visionario que es uno, eh :) En Mixergy, un sitio web sobre startups, Andrew Warmer, su fundador, entrevista a uno de los creadores de HOTorNOT, James Hong. La entrevista dura casi hora y media y en ella hablan prácticamente de todo. Si no se os da demasiado bien el inglés hablado, también está la transcripción en el sitio web.

Os dejo aquí unas notillas de lo que a mi me ha parecido más interesante:

• Os decía que un sitio para perder el tiempo. Claro, de esos sitios que los programadores pensamos "vaya chorrada, esta parida la hago yo en dos horas". Bueno a ellos les llevó dos días, y consiguieron llegar hasta 7 millones de dólares en ingresos. No está nada mal para una idea chorra.


• Nunca quisieron dinero para crecer más. Evitaron el capital de riesgo, no porque fuese malo sino porque ellos no lo veían. Ellos simplemente querían algo que generase constantemente dinero sin buscar aspiraciones más altas.


• Nunca tuvieron más de cinco empleados. James define esa como una de las claves. No tenían burocracia ni grandes infraestructuras que mantener. Todo lo que querían hacer lo sacaban rápidamente.


• Sus fundadores, vivieron tranquilamente de HOTorNOT durante varios años. Sólo trajeron empleados porque se cansaron del modo de vida, de estar siempre pendientes y pensando en el proyecto.


• En 2005, 2006, las cosas cambiaron. Las redes sociales comenzaron a aparecer y el futuro en HOTorNOT parecía mucho más incierto. Los costes eran menores así que decidieron volver, hacer el sitio libre y apuntarse a la moda de las redes sociales, aunque la cosa no funcionó.


• Al pasar el sitio a un modelo de negocio free, buscaron monetizar con anuncios. En esos momentos el entusiasmo decreció. James comenta en la entrevista que perdieron la alegría por el proyecto y que tampoco tenían los conocimientos necesarios para moverse en ese mundo. Además, al hacer libre la web, comenzaron a aparecer los spammers y timadores, buscando estafar a la gente con transferencias de dinero. Un problema bastante grande en este tipo de sitio web. En 2008 buscaron un vendedor y vendieron HOTorNOT.


• Hablan también de cuando comían allá por el año 2000 con los creadores de YouTube y otras startups conocidas, que coincidían normalmente en la misma cafetería. Todos se conocían y hablaban. A ellos les comentaron la idea de crear un sitio web para compartir videos. Se les ocurrió crearlo pero con un modelo muy poco tradicional para la época, invirtiéndo pero dándole a ellos el 51% de la empresa, ya que no tenían mucho interés en dedicarse a ello. Pero por esa época habían contratado un CEO al que no le gustó la idea de darle ese porcentaje de una compañía a meros empleados... El resto es historia.


• MySpace, Friendster, YouTube. Mirando en archive.org las primeras versiones de todos esos sitios web, todos tenían el estilo HOTorNOT. Todos intentaron hacer algo similar cuando salieron pero ninguno lo consiguió. Pero sin embargo, todos consiguieron triunfar con ideas diferentes.


• HOTorNOT se defendió de todos estos gigantes al principio consiguiendo que la prensa hablase de ellos. Si la prensa habla de ti, no tiene tiempo para hablar de tus competidores. Nadie quiere hablar de los segundos, y su idea era innovadora y llamba la atención.


• Al principio no intentaron ganar dinero hasta que aseguraron el tema de costes. Se buscaron la vida. Por ejemplo los servidores se los pagó RackSpace, a cambio de que ellos les hiciesen publicidad.


• Lo que más importa es siempre el producto. A la hora de monetizar HOTorNOT no pensaron demasiado en planes de negocios, no hicieron análisis de precios, ni de la competencia, ni cifras a varios años. Simplemente pensaron como se conoce la gente en los bares, y lo imitaron. ¿Cuánto cuestan dos cervezas? 6 dólares. Ese es el precio de subscripción. Lo paga uno y listo. Con el tiempo, los registros mostraban que casi siempre el que pagaba la subscripción era el hombre. Como en muchos casos, las copas en la vida real.


• La clave de su éxito, la facilidad de uso. HOTorNOT se usa con un click. Todo mascado y sencillo. Hacerle fácil la vida al usuario.

No está nada mal para una "chorrada"!!! Yo voy a ver si se me ocurre alguna, que ya va siendo hora :)

Software Libre distinto de Software sin Compromiso

¿Quién no conoce a estas alturas la frase "Software Libre distinto de Software Gratis"? No creo que sea necesario explicarla. Pero a cuento de un hilo en una lista de un proyecto Open Source (que tampoco quiero mencionar, porque no importa demasiado y porque es algo que se ve en muchas partes), pues llevo varios días pensando en lo frecuente que es el ver como en las comunidades de Software Libre se utiliza el hecho de tratarse de software abierto para excusar otros problemas.

Es especialmente frecuente el ver aparecer este tipo de excusa cuando las críticas arrencian, cuando los usuarios reclaman funcionalidades que sería difícil implementar, cuando carecemos de los recursos necesarios para hacer dichas funcionalidades, o cuando simplemente no nos apetece gastar nuestro tiempo en eso. ¿Por qué afirmo esto? Pues porque lo he visto en infinidad de ocasiones, y voy más allá, porque tengo que confesar que he utilizado dichas excusas en muchas ocasiones.

Cuando estaba en pleno desarrollo de jLibrary, era común el que llegase gente pidiendo cosas que podrían hacerse. Y la verdad es que siendo un equipo pequeño, no te queda más remedio que filtrar. A veces te llegaban sugerencias fenomenales, pero es que no te quedaba más remedio que cerrar la conversación con un "es un proyecto de Software Libre, puedes contribuir". Que conste que más de una vez funcionó, pero la mayor parte de las veces, la petición queda ahí, en una simple petición, y nunca recibías ningún parche.

Y no creáis que no me daba rabia el tener que sacar la excusilla de marras. Al contrario, me daba muchísima. Cuantas veces tengo pensado, ojalá tuviese aquí diez commiters totalmente motivados o un buen presupuesto para implementaros todo lo que pedís. Pero por desgracia, ni los tenía, ni parece que tuve la capacidad de convicción para atraerlos. Pero entonces, ¿por qué esa rabia? Pues porque para mi el Software Libre, por mucho que tengas esa excusa tan a mano y tan socorrida, no está exento de responsabilidad.

Cuando creas un proyecto abierto en Internet, eso tiene una responsabilidad enorme. O quizás soy yo que simplemente me lo tomo muy a pecho. Pero para mi, al abrir un proyecto le estás pidiendo a la gente que lo pruebe. Estás creando una comunidad. Una comunidad de personas que ponen su confianza en ti y en tu producto, aunque sea sólo para invertir treinta minutos en descargárselo, instalarlo, y probarlo. Si pasan de esa fase, incluso puede que lo comiencen a usar, y esos minutos pasan a ser horas, días, semanas, meses o años de confianza en tu software.

Y tú, como creador del software, necesitas de esa comunidad y su confianza. Porque al final lo que quieres es que tu producto lo usen más y más personas. Y después, con suerte, te harás famoso, podrás vivir de ello o vendrán y te comprarán por varios millones de euros, como ya ha pasado con muchas empresas. Pero sin confianza ni compromiso, nada de nada.

Pero hay gente que piensa que como es Software Libre, pues ya está, lo usas si quieres y punto, y si quieres mejorarlo pues no te quejes tanto y ponte a ayudar. Este argumento, tiene alguna base cuando utilizas un proyecto que lo mantienen cuatro gatos, sin ningún tipo de apoyo, pues como era el nuestro, y que a fin de cuentas es gente dedicando su tiempo libre a hacer algo que a otros les reporta un beneficio económico. Y digo alguna base, porque a fin de cuentas el creador siempre tiene sus motivos para crear el software e iniciar ese compromiso con sus usuarios.

Pero sin embargo, ¿qué argumentos se puede tener cuando tienes capital de sobra?, ¿o cuando te han comprado?, ¿o cuando eres una gran compañía? Por ejemplo, digamos que te compra una compañía que acaba de recibir varios millones de euros en inversión, tus usuarios te piden que redirijas un poco el proyecto para solucionar determinados problemas, y ¿tu respuesta es pedirle a los usuarios que en vez de protestar ayuden? Mal vamos. Más bien habría que pedirle a quien te ha comprado que ponga recursos para que el proyecto salga para adelante.

Os soy franco, para mi el argumento de "es software libre, puedes ayudar" no es válido cuando el proyecto pasa una determinada raya, la raya de la inversión, la raya del mega-éxito, o cuando simplemente están sustentados por compañías enormes. Proyectos como Alfresco, Spring, JBoss, Glassfish, MySQL, ... Señores, en muchas de estas compañías, ni te aceptarán los parches en caso de que los tengas, pues porque quizás no tengan tiempo, o porque sean parches que hagan conflicto con otros clientes, etc. (en una empresa en la que trabajé nos pasó algo de esto con Hibernate). Ellos han elegido el camino del Software Libre, y el Software Libre, ni es gratis, ni está exento de la responsabilidad hacia sus usuarios.

Un porcentaje de estos usuarios, seguramente alto, serán gorrones que no aportan nada, ni hacen contratos de mantenimiento, ni van a cursos oficiales, ni tienen sus certificaciones, pero.... son tus usuarios. Tú has escogido el modelo de negocio. Para bien o para mal. Y si los usuarios protestan normalmente es que el río agua lleva.

Perdón por el rant, pero es que el topicazo de "es libre, menos protestar y más ayuda" lo llevo fatal. Hasta cuando soy yo el que lo tiene que decir.

Imagen via schoschie@flickr

UBS y Citi deshaciéndose de parte sus departamentos de IT

Hoy me he encontrado con un par de noticias muy interesantes, dan para mucho que hablar. Reportaban en Finextra que Citi está intentando vender su plataforma IT a alguna multinacional India. Mencionan Tata Consultancy Services y Wipro como posibles compradores. También referenciaban a UBS como otro gran banco que se está intentando deshacer de sus plataformas de IT, más concretamente de sus centros de Polonia y la India.

Si consiguen vender sus departamentos, serán unos genios. Porque a ver quien se cree que sus plataformas las pueden vender a otras firmas. Bueno, tampoco hay que ser talibanes del software, todos sabemos lo buenos que los vendedores pueden llegar a ser, y si nos dicen que la plataforma de trading del Citi va a funcionar sin problemas en el Banco Etxeverria, pues seguro que habrá algún directivo que hasta se lo crea.

En fin, a mi estas noticias me hacen reflexionar. Pensar lo abajo que estamos en la escalera de decisión y lo poquita cosa que puede ser un programador para un super-banco como este. Y es que el ahorro de costes en IT parece que no tiene fin. Empiezas con tu cubículo en Suiza, el banco ahorra costes y te subcontratan a una empresa Suiza, el banco ahorra costes y te subcontratan a un centro de producción en Polonia, el banco ahorra más costes y te venden a una empresa de subcontratas India.

De hecho es una pasada todo lo que han crecido estas empresas de subcontratación como Wipro. Resulta sorprendente que sean estas compañías las que estén pujando por el software de estos gigantes bancarios...

Nada, unas reflexiones a golpe de Martes.

Los superprofesionales del software

Domingo después de una dura semana de trabajo. Repasando mis feeds pendientes por leer me encuentro con este post de Javier Garzás sobre los superprofesionales del software.

Responsabilidad, conciencia, honestidad, resistencia, imparcialidad, perspectiva y pragmatismo. Excepcional lista. No puedo estar más de acuerdo.

Es difícil escoger sobre uno de estos puntos. Creo que todos son realmente importantes, y la falta de alguno de ellos puede desencadenar muchos problemas. Lo que sí que estoy seguro es que el de resistencia bajo presión es el más difícil de dominar.

Jobsket sale al público. Sube tu currículum ya!

Toca auto promoción. Ayer hicimos público el anuncio de que Jobsket está disponible públicamente para todo el mundo. Hasta ahora estábamos en una beta que requería registro, pero eso se ha acabado y a partir de ahora todo el mundo podrá acceder. Muchísimas gracias a todos los que habéis participado en la fase de pruebas.

De Jobsket ya he escrito en otras ocasiones. Así que no me voy a extender mucho más. Podéis leer y suscribiros a nuestro blog para tener más información.

De lo que nunca he hablado hasta ahora es del pequeño widget que desde unos meses está en la parte derecha de mi blog.

Visita mi CV

Este widget os lo damos desde Jobsket cada vez que subís vuestro currículum. Y no me diréis que no está mucho más chulo para promocionaros que el típico enlace en html :) Pues nada, que no tenéis más que subir vuestro currículum a Jobsket, y pinchar en "Compartir CV". Jobsket os da el código y lo podéis pegar en vuestra página web. Así además podréis ver cuanta gente está interesada en vuestro CV y muy pronto también quienes lo han visto!

Anda, que no lo promociono bien, ¡eh! Bueno eso, pues que si tenéis un CV es una buena forma de promocionarse, y de ayudarnos a nostros a promocionarnos claro :)

Sobre hackers, servidores virtuales y suicidios

De rebote, estos últimos días en el equipo de Jobsket nos hemos visto en medio de una situación tan rocambolesca como trágica. Tiene que ver con el servidor que utilizamos para desarrollo en Jobsket, y menos mal que se ha quedado en eso.

Os cuento, cuando empezamos con Jobsket, estábamos utilizando un servidor virtual que yo tenía contratado en los Estados Unidos. El precio era un poco alto y el tiempo de acceso también así que decidimos movernos a un centro de datos en UK para estar aquí en Europa. Todo esto que os voy a contar afecta sólo a nuestro servidor de desarrollo ya que el servidor de producción lo tenemos en otro lugar.

Como queríamos algo baratillo y funcional, ya que simplemente utilizamos esta máquina como integración, para los tests y eso, nos decidimos por VAServ que venían precedidos de muy buena fama en sitios como WebHostingTalk. Vaya por delante que la gente de VAServ siempre ha respondido prontamente y con eficacia.

Bueno, pues hace dos días recibimos un correo que comenzaba así:

"As many of you are aware, we were hacked today around 7pm GMT and portion of our service has been cut off (mostly US and portion of UK servers)."

Habían sido hackeados. Después de cambiar la contraseña, y de sentirme aliviado porque la tarjeta de crédito que había usado ya no está activa, pues me puse a investigar un poco sobre lo que había pasado. Aparentemente los hackers no se limitaron a robar datos, sino que han destruido buena parte de los datos que había en los diferentes servidores, con la gravedad que esto conlleva ya que este proveedor barato era enormemente popular con miles de clientes. Buena fé de esto da el hilo principal en WebHostingTalk sobre el tema que ahora mismo alcanza ya las 115 páginas.

En fin, la gente de VAServ lleva trabajando día y noche para solucionar el problema. Nosotros no teníamos nada demasiado importante ahí, salvo el sistema de integración continua que nos daría bastante trabajo de recuperar la configuración de las diferentes build, pero por suerte no hemos sido afectados por el ataque. Sí que lo han sido otros muchos a tenor de lo comentado en el foro, que tenían negocios más importantes.

Pero ahora viene lo grave. El ataque se debió al sistema de gestión que utiliza esta gente, HyperVM, un producto de la compañía LxLabs, una firma india fundada por K T Ligesh. Ayer, TheRegister reportaba el ataque que como podéis ver no nos ha afectado sólo a nosotros, sino que ha podido haber más de 100.000 sitios web afectados por el problema.

Pues bien, hace nada y según parece debido a la falta de interés de LxLabs se hizo pública la lista de vulnerabilidades de su producto, que incluye 24 bugs bastante graves. Como reportan en HostingFu el producto no era una maravilla, pero parece que lo peor ha sido la falta de interés.

Y ahora viene el final triste de la historia. El dueño de LxLabs, Ligesh, fue encontrado hoy ahorcado y se sospecha de suicidio. En el Times de India hablan de la pérdida de un contrato importante. Su madre y su hermana se habían suicidado hace cinco años, algo que también había afectado a Ligesh. Y parece que esto pudo ser la gota que colmó el vaso.

Una historia muy triste en la que nos hemos visto por en medio muy de refilón. Descanse en paz.