I’m a web developer from Santiago, Chile. You may (not) know me because of Junkstr and Chevereto.

I code things like G\ Library PHP framework which helps anyone to build amazing web apps.

Upcoming: Quickty, Chevere.me

Catch me at Twitter, LinkedIn or at inbox@rodolfoberrios.com

6 Sep 2014

Desarrollo de Software hasta ahora

Últimamente he estado bastante productivo y contando desde abril hasta la fecha ya llevo 25 versiones (revisiones, versiones menores o como quieran llamarle) de Chevereto 3, lo que da por promedio un release por semana (harto) y me doy cuenta que es normal por que aun no llego a la etapa madura de esta versión mayor. Creo que me doy cuenta por que ahora soy algo más vivaracho que cuando comencé en 2007.

Entonces pensé que seria buena idea hacer un resumen con las cosas que he aprendido hasta ahora y que pueden ser de utilidad para otra persona o para mi futuro yo. Creo que es útil considerando que es un software que desarrollo y vendo directamente al usuario final.

Respeta el roadmap

El roadmap es la planificación a largo plazo de tu software y establece que features vienen antes o después de otras. Usualmente el roadmap sufre ligeros cambios producto del dinamismo propio de un proyecto de este tipo lo cual esta super bien. En mi caso cada cierto tiempo ajusto o corrijo el roadmap y trabajo en función del mismo lo que implica que, la mayoría de las veces, las peticiones de los usuarios se deben postergar indefinidamente. ¿Por qué tanta maldad? Es por que te va a quedar la cagá en el momento en que empieces a conducirte sin un plan a largo plazo. Da lo mismo si la competencia te esta presionando o si tienes la corazonada de que haciendo tal cambio lograras mejores resultados, cada incorporación al sistema debe pasar por el proceso de roadmap y si irrevocablemente debes agregar algo que no estaba planeado tienes que tratar de retomar inmediatamente el roadmap.

Ceder en momentos inoportunos

Una de las partes más traumantes del proceso es cuando con todo tu empeño sacas una nueva version bastante buena que incluye muchas funciones nuevas y que es universalmente bien recibida pero algunas personas te dicen la oración que causa guerras: ”¿Para cuando vamos a tener soporte para X?” lo cual es como ají en el poto por que en ese momento lo que te interesa es que se comente en el contexto de los cambios introducidos por esa version y en estar seguro que no se rompió nada entremedio. Siempre es entendible recibir peticiones sobre nuevas funciones pero te encargo lidiar con estas peticiones en el momento donde lanzas un nuevo release por que tristemente implica ignorar o finalmente ceder y en este último lamentablemente terminas cumpliendo bajo una incomoda presión lo que se traduce en un mal trabajo el cual haces solamente para callar a esa maldita vocecita y te pasas el roadmap por la raja.

Postergar eternamente los releases

A medida que agregas más características en tu software veras como cada vez es más difícil que todo funcione bien. Lógico, hay más componentes y es más probable que las cosas fallen. Es sensato que postergues las cosas para evitar más problemas a futuro pero los usuarios de tu software odian esta consideración si los atrasos son eternos. Esto me paso con la version 2.X donde ingenuamente no la desarrolle para ser amigable al cambio y agregar las cosas más simples me tomaba mucho tiempo. Mi solución fue invertir un año y medio en la version 3.X y hacerla mucho más amigable al cambio pero aun así no fui capaz de lanzar la version 3.0.0 que yo realmente quería lanzar. Para mi sorpresa los usuarios prefieren que lances algo aunque sea con bugs por que lo que quieren es probar algo real y ser parte de ese proceso.

Capturar el espíritu de los requerimientos

Cierto tipo de personas tiene una facilidad enorme para solicitar cualquier cosa que vean aplicada en otro producto/servicio y las cálidas palabras que te regalan como argumentos suelen ser del tipo “Si no hace X entonces el sistema no sirve para nada” o “Debería hacer X por que este otro sitio/servicio lo hace” y mi favorita de toda la vida: “Muchas personas lo necesitan”. Me encanta recibir peticiones pero lamentablemente la mayoría de las personas tienden a usar siempre estos argumentos que para mi valen hongo, lo que termino haciendo es tratar de captar el espíritu del requerimiento e ignorar el resto. Con captar el espíritu del requerimiento me refiero a tratar de validar o de entender por que te están pidiendo tal cosa y determinar bajo tu criterio cuantas personas se podrían ver beneficiadas al implementar el requerimiento o sugerencia en cuestión.

Si se ve así entonces es así

A veces resulta increíble como ciertas tonteras causan un efecto eye catching como por ejemplo poner un parallax o cambiar la animación de un elemento. Es curioso como funciona pero lo concreto es que es el recurso más útil para mantenerse vigente, al menos visualmente. A las personas les encanta que se vea “moderno y profesional” por que si no lo ven de esa manera les da lo mismo si debajo hay un motor V8 o un raton corriendo en una rueda de ejercicio. No digo que debas enfocarte sólo en el aspecto estético pero si no le das importancia nadie va a notar tus esfuerzos globales.

La voy a romper con esta feature

Este es clásico: Súbitamente te viene la necesidad de agregar cierta característica y estas seguro que sera tan grande como para marcar un antes y un después. Malas noticias por que casi nunca es así. Me paso hace rato cuando hice un panel de administración de imágenes para la antigua versión 2.X y a pesar de todo lo bueno que era ese feature, no logró ni mover el piso. Muy rara vez una feature introducida en un release menor logrará esa explosiva mejora que si aprecias claramente en un release mayor. Para ejemplificar esto ultimo puedo decir que la versión 3.X ha generado 6-7 veces más interés que la versión mayor anterior.

No dudar tanto cuando te digan “esto no funciona”

Creo que el hilo negro es ligeramente más viejo que la incredulidad de que tu fantástica creación no funciona como es esperado. Es muy normal que te manifiesten este tipo de cosas y también es normal que las personas sean extremadamente minuciosas en los detalles. Mentira, no se dan la paja ni de decirte que versión esta usando y con cuea te dicen en donde pasa. Cuando se reporta un incidente es normal no creer y pensar que simplemente te están rompiendo las bolas o están usando una version obsoleta. Aun me cuesta lidiar con esto pero al menos en mi experiencia lo mejor que puedes hacer es primero creer lo que te dicen y luego trata de obtener todos los detalles para poder replicar el incidente. Creo que esta es la parte más difícil para mi por que cuando eres incapaz de replicar el problema aun tienes al usuario sin respuesta y empiezas a acumular presión. Al final siempre tienes que recordar que eres humano y que te equivocas.

Cercano y abierto

Creo que esto ya es decision propia de cada uno pero me carga la impersonalidad que tienen las cosas actualmente, como si las hueas se construyeran solas y no hay una persona o un grupo de personas detrás. En Chevereto cada cliente sabe quien soy yo, que otros proyectos tengo, que opino sobre ciertos requerimientos, etc. Creo que es uno de los pocos casos donde puedes ir directamente con el desarrollador principal y comunicarte con el y no sólo mediante un canal sino varios (email, twitter, foro, facebook). No lo hago por un tema de ego o por que tenga la necesidad de mear mi creación sino por que me gusta que me manden mails pidiendo/criticando/felicitando/extorsionando por que hay alguien que les responderá y no un mail automático tipo “Su mensaje ha sido recibido. Buen finde.” que tanto color si no eres el Papa responde los mails.

Haz lo mejor para tu proyecto

Independiente de lo popular o impopular de tus decisiones tienes que saber obrar en el sentido de hacer crecer tu proyecto respetando tu objetivo principal. Cuando comencé con Chevereto muchas cosas eran distintas, para partir era Open Source y nunca pensé que seria mi sustento. En mi caso lo de Open Source no funciono y lo transforme en un producto comercial pero no renuncie a mi objetivo principal el cual siempre ha sido poner al alcance, de cualquier persona común y corriente, una herramienta competitiva para poder montar un sistema propio para compartir imágenes.
Creo que cuando renuncias a tu objetivo principal ya no te queda mucho por hacer y vives lo suficiente para ver como te conviertes en algo que no eres.

7 Jul 2014

Incubadoras y aceleradoras en Chile

Hace ya bastante rato que nos bajamos sólitos del entorno incubación/aceleración en Junkstr y me gustaría dedicar unos breves párrafos sobre el tema para que otros vean por que no deberían perder su tiempo en meterse en estos cachos.

Primero que todo aclarar que acá en Chile inversión en el área web no hay o si la hay es muy pequeña y/o difícil de conseguir. Esto es por que la inversión que hay en Chile es en negocios de otro tipo y en web son pocas las empresas y emprendedores relacionados con web que están en condiciones de invertir su dinero en una empresa con un producto orientado a la web. Lo que tenemos en Chile es financiación de proyectos relacionados con el área web y es la pega que hacen las incubadoras y las aceleradoras.

El problema es que las incubadoras y aceleradoras son un chiste. Desde notas convertibles por plata que no existe (Si, te hablo a ti Wayra) hasta viajes sin sentido al lindo Sillicon Valley (Ya, esa fue para IncubaUC). Pero esta bien, es la naturaleza de la incubadora. Las incubadoras existen para aprovecharse de la corporación de fomento y/o de la estupidez del emprendedor y rara vez hacen una pega con visión real a potenciar un producto. Si alguna vez te preguntaste “Como chucha esa wea ganó esta wea?” es por que hacen la pega al lote o mejor dicho la pega nunca ha sido realmente acelerar los proyectos.

En la amplia variedad de incubadoras y aceleradoras hay de todo pero el principal problema es que las que son con fondos privados son con fondos de tipos que tienen una concesionaria de autos o una cadena de completos. Ellos cuidan sus lucas nomas haciendo lo que saben y web no es algo que saben. ¿Le vas a pedir a ese tipo de financistas que te pasen plata?. Mejor aun… ¿De que te sirve ese tipo de financista?

Lo que una startup necesita es inversión. Bueno, cualquier buen negocio necesita eso. Por definición inversión involucra riesgo y ese riesgo es el factor que hace que un inversionista de verdad quiera que las cosas tomen su curso, más aun si es un inversionista con experiencia en el área. Toma real valor la definición de Inversionista ángel en este caso pero hasta esos se han puesto chantas.

Riesgo, mojarse el potito, invertir de verdad sin dejar empelota al emprendedor con una deuda millonaria si no funciona… Ah pero si funciona se quedan con % de participación y primera opción de compra. ¿No se pierden una verdad?.

Si eres emprendedor y crees en las incubadoras mándalas a meterse el contrato en la raja. Eso no es para ti. Vende tu auto, vive austero, sangra. Si aun así tu proyecto no puede ocurrir por que la plata es un factor entonces lo estas haciendo mal, hace algo que este a tu alcance y planifica como crecer.

17 Apr 2014

Chevereto 3

I can’t think in anything else in which I worked that hard and for such a long period of time, at least by my own without any help at all. That project is Chevereto 3.

When I started to develop this version the goal wasn’t remotely close to the final working product (you can see it here) and to be honest, I’ve always loved to work in Chevereto more than anything else, with the exception of Junkstr, and soon as I started to work on this third major release I decided to highly increase the bar regardless of the time and the complexity of the project.

I don’t know if you feel or see the same as I do but for me it is an amazing system and I’m so proud of it and I’m happy to keep feeling this when I release something.

Long life to the #1 image sharing script in the world.

14 Mar 2014

Introducing G\ Library

Long time ago I started to learn and working with PHP. It started mostly because I needed a way to make real my ideas and it was the most used web programming language in that days. It was a self learned thing which was actually a very long process and it also included other languages and web development technologies. Several year later PHP is still the most used web programming language and I keep working with it.

I’ve made Chevereto my trademark using PHP and I have plans for other scripts based in PHP so when I started to code the upcoming new major release of Chevereto I knew that I was ready to make a framework for my projects. The result was G\ Library which is an Open Source PHP framework which summarize all this years of learning and is the foundation for the next following years.

Actually I never liked frameworks until I noticed jQuery which isn’t a framework but I loved how jQuery was all about making certain core task better than anyone at least in those days. Remember that back in the day there was a lot of JS libraries like MooTools, Scriptaculous, etc. Well, I started with this last one and even when its effects were way better than jQuery it didn’t perform well the core tasks or make the syntax more simpler. That was where jQuery owned with its sleek an intuitive syntax to perform really casual stuff but also do more complex things.

For me frameworks are not about how many things they can do out of the box but how easy is to go big with it. A good framework is the one that helps you to perform core tasks and makes your coding less hassle so you can focus in the actual features of your app. G\ was coded with this philosophy in mind and it was developed side by side with Chevereto V3 so actually is not a work in progress but a real working thing.

G\ Library website has an intuitive documentation that will teach you the basic stuff and you can also get the code on GitHub. Hope that developers out there find G\ useful as I do and collaboration is welcome.

6 Dec 2013

700 lucas en cachureos

Entonces esta Junkstr y uno ya sabe que es un sistema que tiene que funcionar para quien vende y quien compra. La parte de quien vende o publica es fácil, es básicamente una UX que cualquiera ya se querría chorear para su propio proyecto y para quien compra es presentar un sistema intuitivo y fácil de cachurear. En este sentido ya estamos bien encaminados y hemos visto que funcionó bastante bien nuestra primera iteración.

Pero falta algo.

Necesitamos conocer como se dan los intercambios y las negociaciones. Cuales son las mejores estrategias de venta, la forma más optima de publicar, describir los artículos, etc. Motivado por la avaricia y el hype me puse como propósito vender CLP 700.000 en cachureos míos a través de Junkstr y comprar un Macbook (such computer, wow).

Read More