Linked

Fantástica la idea que han tenido 20 startups de Colorado: La Boulder Colorado Job Fair. Se trata de una feria de desarrolladores: como las de productos artesanos pero con programadores artesanos XD.

Básicamente van a abrir las puertas de la ciudad de Boulder, CO. a una especie de fiebre del oro, donde el metal ha sido sustituido por las startups del lugar y las caravanas las forman un montón de Jóvenes Pálidos. De entre todos los curriculum que reciban elegirán a 100 afortunados que viajaran a Boulder por tres días con todos los gastos pagados (¡cielos… dicho así parece un premio del rueda de la fortuna!).

Durante esos 3 días los futuros hackers conocerán la ciudad, se entrevistaran con todos los patrocinadores (que apoquinan cada uno 5.000$, vamos un poquito más que dos ayudas personales del plan de los 700B$) y el ultimo día tendrán conversaciones más en profundidad con las startups que más les interesen.

Los americanos son expertos en crear esas relaciones que ellos mismos llaman win-win, y esta aventura no es diferente. Por una parte las startups se aseguran un nutrido ejercito de desarrolladores que quizás descubran que una ciudad que ni siquiera sabían donde estaba acoge más de 200 startups en un entorno increíble.

Los desarrolladores encuentra un trabajo en startups innovadoras alejadas del cada vez más fashionable y agobiante mundo de Silicon Valley, con unos gastos medios en vivienda y servicios básicos mucho menores que los de California.

Y la ciudad… madre mía la ciudad. La ciudad y el Alcalde en concreto debe estar salivando con la pinta de foco tecnológico que empieza a tener Boulder. Nadie podría esperar una receta mejor para las vacas flacas que se avecinan.

Aquí solo nos queda mirar, admirar, envidiar… sonreír. En el País Vasco nos costaría incluso encontrar las 20 startups.

Share This

Today we launch a new weblog: lines of code. From time to time we’ve been asking ourselves what sense could have to blog about tech/dev/geek stuff here on Linked, our main company blog. The reason behind this is that we think many people is interested about what we’ve to say about the web business but the number of people interested on the hardcore side of web development is clearly smaller.

To give everybody what could potentially be more useful we’ve decided to start the new and shinny lines of code. Consider it our geek sandbox, full of code, dev ideas, references and quotes. So if fibers, bdd or github gemspecs make any sense to you, check it out or get the rss feed and enjoy.

PS: The language will be mainly english, but this shall not be an axiomatic principle so beware.

Share This

Como deciamos ayer la salida de tog es inminente y con ella termina un ciclo y empieza otro. La primera versión publica de un proyecto open source, cuando este no es de un tamaño muy reducido, siempre tiene para nosotros un regusto agridulce. Por una parte el trabajo que has estado realizando ve la luz, y virtualmente cualquier persona del mundo puede reaprovecharlo, en mayor o menor medida. Ademas tu trabajo pasa por arte de magia del incomodo estado del vaporware a ocupar un pequeño espacio dentro de las baldas del open source.

Como colofón, por pequeño, sencillo o prosaico que sea tu proyecto siempre encuentras a alguien, en alguna parte del mundo, a quien le has ahorrado unas horas de trabajo, le ha parecido interesante tu proyecto, le has evitado algunos quebraderos de cabeza o incluso todo a la vez. Este es el verdadero placer del open source y todos los desarrolladores deberían participar alguna vez en un proyecto de este tipo.

Pero por otra parte la primera versión publica de un proyecto también requiere de una cantidad importante de trabajo sucio. Me explico. Cuando utilizamos un proyecto de manera interna, para nuestra empresa o para un cliente, solo tenemos una capa de desarrollo. Nosotros pinchamos, cortamos, mediamos y lo que haga falta en la evolución de la libreria. Las repercusiones de nuestro trabajo nos afectan únicamente a nosotros y procesos/funcionalidades particulares de nuestra casuística pueden incluirse en el sistema sin miedo o, al menos, con pocos remordimientos.

En el momento en el que decidimos abrir nuestro software a terceras partes una nueva capa de desarrollo y responsabilidad se introduce: los desarrolladores que utilizan nuestras herramientas para sus propios proyectos. Para nosotros esta apertura va acompañada de un montón de puntos que deben ser revisados:

• Las interfaces pasan a ser más rígidas y esta rigidez se va haciendo mayor en el tiempo… hasta que nuestro software se vuelve legacy como decía David Heinemeier en la ultima Railsconf. Quizas no sea tan divertido como las fases embrionarias de un proyecto, donde de un dia para otro cambia totalmente el uso de una libreria, pero es un paso necesario para que los proyectos se estabilicen.

• Funcionalidades que hasta ese momento eran consideradas parte del proyecto deben ser extraídas, para que no interfieran con el uso de la herramienta que otros desarrolladores pueden hacer de la herramienta.

• Es necesario construir procesos para facilitar la instalación y uso de la herramienta. Mientras el proyecto es privado es muy habitual que ciertas tareas estén automatizadas dentro de nuestro entorno de trabajo. Cuando lo liberamos es necesario que este sea lo más autónomo posible.

• Limar las pequeñas asperezas que tiene cualquier proyecto software. Algunos métodos son renombrados para que el API sea mas homogénea, se añaden tests para caso excepcionales, controles extras sobre dependencias y un largo etcétera de pequeños detalles.

Todos estos puntos van en detrimento de lo que más nos gusta a los desarrolladores: añadir nuevas funcionalidades. Obviamente hubiera sido más gratificante haber dedicado un par de días a integrar, por ejemplo, OAuth dentro de tog, pero hubiera sido un flaco favor para los desarrolladores si por ello, por ejemplo, la documentación sobre que dependencias tiene tog hubiera sido inexistente o escasa. Por ello, esta y otras muchas funcionalidades tendrán que esperar hasta la siguiente versión de tog.

Hemos intentando que empezar a utilizar tog en una aplicación nueva o aplicarla sobre una aplicación existente sea un proceso sencillo e indoloro. Ese es el principal objetivo de la primera versión publica.

De ahora en adelante, en el nuevo ciclo que comentaba al principio, empezaremos a trabajar para dotarle de más funcionalidades: OpenSocial, Widgets, OAuth, más plugins… no hay limite para la extensibilidad de tog. Con el lanzamiento anunciaremos el roadmap que tenemos previsto y que creemos sinceramente que puede ser muy interesante.

Queda muy poco para que publiquemos tog. Os invitamos a todos a que le echéis un vistazo y nos digáis lo que os gusta, lo que no y cualquier cosa que este en el medio XD.

Share This