Plastic SCM aterrizando en la Universidad

jueves, febrero 21, 2013

A los "mergenarios" nos encanta nuestro trabajo: desarrollar Plastic SCM un sistema de control de versiones distribuido (DVCS). Pero todavía nos gusta más compartirlo y enseñarte como todo puede ser más fácil si utilizas un control de versiones.

El próximo miércoles 27 de Febrero tienes la oportunidad de compartir una jornada de trabajo con nosotros en la Universidad de Valladolid(UVA).

La ETSI de Informática oferta actividades culturales durante los miércoles del curso 2012/2013 para todos sus alumnos y tenemos la inmensa suerte de estar entre los elegidos para impartir un taller. Toda la información la puedes encontrar aquí.

Ya sabes, elige tu arma... El resto lo ponemos nosotros!!!

Os esperamos a todos!!!

Buscamos un "plugin-hacker"

miércoles, enero 09, 2013

Para mantener Plastic SCM al día tenemos que integrarnos con una larguísima lista de productos de terceros: desde Issue Trackers (JIRA, Mantis, Bugzilla, Trac, VersionOne...) a CI systems (CruiseControl, TeamCity, FinalBuilder...) pasando por IDEs (IntelliJ, Eclipse... Visual Studio también) y sistemas de Code Review...

Por alguna razón los desarrolladores de estos productos no dejan de sacar nuevas versiones ;-) así que supone un enorme esfuerzo mantenernos al día, probar sus últimos cambios, implementar fixes, mejoras, etc, etc.

Por eso estamos buscando un "plugin hacker" que se una al equipo para trabajar a tope en todas estas integraciones.

Requisitos y habilidades

  • Pasión por el software -> te tiene que encantar probar nuevas cosas, estar al día de lo último, aprender nuevas herramientas de desarrollo, entornos... de todo
  • Más pasión por el software -> tendrás que usar macs, linuxes, windows... sin venirte abajo...
  • Buen nivel de Java -> muchos de los plugins están escritos en Java
  • Buen nivel de C# -> porque el resto de los plugins son en C#...
  • Sería estupendo que tuvieras experiencia haciendo plugins de Eclipse, o de IntelliJ, o integrando JIRA con algún control de versiones... vamos, haciendo justo lo que hacemos aquí...
  • Conocimientos de control de versiones: cuanto más sepas de git, mercurial, subversion, perforce, ClearCase y por supuesto de Plastic SCM... mejor!
  • Inglés -> lo usamos a diario, y para hablar con los desarrolladores de todos estos productos será importante

    Responsabilidades

  • Estar al día de todas las mejoras y versiones de los productos de desarrollo con los que trabajamos (y de los que no trabajamos también)
  • Mantener y actualizar los plugins e integraciones actuales
  • Crear nuevas integraciones para nuevos productos o para nuevas versiones de los productos existentes

    Interesado?

    Te ofrecemos un sueldo competitivo, oportunidades de seguir avanzando en tu carrera, un entorno de trabajo flexible (trabajamos mucho, pero somos flexibles) y la posibilidad de unirte a un equipo de trabajo muy motivado que crea un producto para desarrolladores (es un privilegio ser un desarrollador haciendo productos para developers) que compite y se vende en todo el mundo.

    Nos gustaría alguien que pudiera unirse a nuestro equipo principal en Boecillo (Valladolid) pero consideraremos también trabajar desde fuera.

    Si alguna vez has querido competir con los más grandes del sector ... es tu oportunidad. Mándanos tu currículum a cv@codicesoftware.com.

  • We're looking for a FrontEnd web developer

    jueves, enero 03, 2013

    Año nuevo, vida nueva... así que si tienes ganas de cambiar y unirte al equipo que hace Plastic SCM... esta es una muy buena oportunidad... En Inglés, eso sí, que para este puesto nos hace falta... :)

    Description

    Plastic SCM is full featured distributed version control system, competing worldwide with best of breed SCM such as Perforce, ClearCase, Git and Subversion.

    Keeping plasticscm.com website looking fresh and clear is a big task. The site explains what is Plastic SCM all about and it has to keep the pace with our core development team, which currently is able to produce features faster than can be published! The site needs to be attractive to different audiences ranging from project managers to hard-core coders. This is why we are looking for a full-time Front End web developer to help us with the design and implementation of the site.

    The successful candidate will be passionate about coding and have an excellent eye for detail and an absolute commitment to making sure features on the website are well implemented and as bug free as possible.

    Key Responsibilities

  • Translating requirements and mockups into fully functioning features using HTML/CSS and JavaScript (new features, tutorials, campaigns and so on)
  • Day to day maintenance of the plasticscm.com websites and optimizing code for the best user experience
  • Working together with colleagues of product development, external agencies and marketing to improve usability and implement a/b tests
  • Eventually contribute to web interfaces in Plastic SCM, although initially plasticscm.com is the top concern

    Skills and Requirements

  • Expert in HTML, CSS and Javascript
  • Knowledge of version control systems
  • Excellent communicator with a pragmatic able to understand requirements
  • Solid experience with Javascript
  • Experience with graphical software (e.g. Photoshop)
  • Dealing with browser compatibility and implementing workaround
  • B.S. in Computer Science or equivalent degree would be a great to have (or equivalent work experience)
  • Deep understanding of the intricacies of rendering across browsers IE 7+ on Windows, Firefox, Chrome and Safari
  • Spoken and written English is a must since all the materials you'll handle and create will be in English
  • Design flair (yes, we need you to have a taste for beautiful interfaces...)

    Interested?

    We offer a competitive salary, with opportunities for career progression within our fast growing company. A flexible work environment and the chance to join a highly motivated team developing world class software, which is most likely a huge plus if you already live in Castilla y León. We need someone to join our HQ in Boecillo (Valladolid) although we're open to remote working alternatives after a initial on-site period. If you ever wanted to compete worldwide against the coolest product companies... the time has come!

    Send us a resume at cv@codicesoftware.com

  • Ingeniero de Soporte

    miércoles, octubre 10, 2012

    Códice Software desarrolla Plastic SCM, un sistema de control de versiones distribuido (DVCS) para desarrollos de todos los tamaños con la mejor implementación de “ramas por tarea” y totalmente visual.

    ¿De qué va el puesto?

    Necesitamos un “ingeniero de soporte”. ¿Qué es eso? Pues un desarrollador de software (nuestros clientes son desarrolladores… así que hay que hablar su mismo lenguaje) al que le guste el trato con la gente, resolver problemas complicados, y ser la primera línea de nuestro equipo de desarrollo.

    Alguno estará pensando: “pero si eso de ser de soporte es responder preguntas aburridas por email… paso!”.

    Bueno, de eso no va el soporte de un producto como Plastic SCM. Va más bien de:

    • Que te llegue un equipo de 50 developers que quiere montar Plastic SCM en dos continentes diferentes con dos backends de base de datos, y hay que ponerlos en marcha en tiempo record.
    • Que otro día tengas que echar una mano para resolver bugs de concurrencia en un sistema Linux al otro lado del mundo.
    • Que en vez de cincuenta, sean 1200 developers (sí, mil doscientos) con una base de código más grande que todo lo que hayas visto y hablando un idioma que no conozcas.
    • Que tengas que escribir un blogpost para explicar un escenario de uso de cualquiera de las características del producto.
    • Que tengas que echar una mano para hacer un webinar (en Inglés) contando como usar las funcionalidades de Plastic SCM.

    En el día a día vas a necesitar:

    • Conocimientos de desarrollo
    • Trabajo en equipo: vas a trabajar con gente
    • Dominio el Inglés (lo vas a usar todos los días)
    • Y muuuuchas ganas de aprender, trabajamos en lo que nos gusta

    En tu incorporación pasarás por un intenso proceso de formación, trabajando codo con codo con nuestra estrella del soporte, con el que librarás todas estas batallas y muchas más.

    Necesita refuerzos! Y tú podrías ser la persona que está buscando!

    ¿Qué te ofrecemos?

    • Competir contra software de nivel mundial como Perforce, Git, Mercurial, Subversion, ClearCase, Team Foundation Server, AccuRev… Luchar contra los mejores del mundo en el sector, cada día.
    • Retos de programación, problemas de software complicados, que pondrán a prueba tu mente cada día.
    • Evolucionar en una carrera técnica: siempre en contacto directo con el cliente, siendo pieza clave para que nuestros usuarios estén contentos.
    • Flexibilidad y libertad: controlar, de verdad, cómo y cuándo trabajas.
    • Incorporarte en un gran momento cuando todavía se puede ser parte del núcleo.
    • Remuneración económica muy competitiva.

    ¿Qué buscamos?

    Necesitamos ingenieros con talento y apasionados, ansiosos por unirse a nuestro equipo y hacer grandes cosas, y lo suficientemente locos como para competir contra el resto de grandes desarrolladores SCM.

    Necesitamos que demuestres amplios conocimientos en desarrollo de software, unas excelentes habilidades de programación y nociones en diferentes sistemas operativos así como en herramientas de SCM.

    Añade capacidad de comunicación y que hables Inglés muy, muy bien.

    Estamos interesados en perfiles y niveles de experiencia muy diversos, así que si de verdad te gusta desarrollar software, envíanos tu currículum a cv@codicesoftware.com y cuéntanos por qué eres el desarrollador que nos falta.


    Inch-Pebble Check-Ins, o cómo hacer desarrollo de software autodocumentado

    lunes, septiembre 17, 2012

    “Nada puede ser tan útil (valioso) como un comentario puesto en el lugar correcto” . Esta frase pertenece a Robert C Martin, autor de Clean Code.

    Existen comentarios denominados “buenos”. Son aquellos que necesitas, por ejemplo, para entender por qué se realizó cierto cambio en su día, puede ser porque tú no estabas presente, o ni siquiera formabas parte del equipo de desarrollo en ese momento.

    Pero también tenemos la cruz de la moneda, y claro, existen comentarios llamados “malos”. Son aquellos que intentan explicar un código que ya de por sí está mal escrito. El código debería ser autoexplicativo, hablar por sí mismo y darte todas las respuestas que necesitas cuando lo estás leyendo.

    La línea de separación entre ambos tipos de comentarios es muy fina. Es cierto que tener buenos comentarios ayuda y mucho. También emplear técnicas como diff debugging o de revisión de código ayudan a mantener nuestro software en perfecto orden. Pero hay una operación que dentro de los equipos de desarrollo se realiza miles de veces cada día: check-in.

    ¿Qué pasaría si utilizáramos el check-in como una herramienta más que nos ayudara a documentar el código que desarrollamos? ¿Qué pasaría si nuestros checkins contasen una historia?

    La técnica que se describe en este post, no sólo es buena cómo método de auto-documentación del código sino también sirve para captar la manera en la que en general el equipo trabaja. Además es un buen modo para enseñar a las nuevas incorporaciones dentro del equipo, las técnicas que se emplean y lo que necesitan aprender.

    El Problema: El Software Cambia

    Acepta el cambio para controlar el cambio

    El software siempre está cambiando. Cuanto más abierto de mente seas y mejor te adaptes a esta verdad, más control tendrás sobre el código.

    Michael Feathers en su libro “Working on effectively with legacy code” explica estrategias para entender los mecanismos de por qué el software cambia: añadir nuevas características, arreglar fallos, mejorar el diseño.

    En Plastic SCM trabajamos con el patrón de Rama-por-Tarea. Ponemos mucho hincapié en que los cambios hechos en las ramas tienen que estar revisados antes de proceder con la integración (merge). Esta revisión se puede hacer utilizando la vista de Diferencias, pero en ocasiones los cambios son tantos y tan pequeños que no es de gran utilidad.

    Voy a tratar de explicarlo mejor con un caso práctico. Hace un par de semanas, estaba desarrollando una nueva funcionalidad que precisaba algunos cambios, sobre el código legado y nuevos ficheros que incorporaran nueva funcionalidad.

    Esta nueva funcionalidad que se iba a desarrollar, necesitaba compartir código ya existente, con lo que la mayor parte del trabajo iba a consistir en hacer una refactorización del código para dejarlo preparado. Cuando terminé con los cambios, lo primero que hice fue ir a la vista de Diferencias para verificar todo lo que había hecho. En esta ocasión como los cambios eran pequeños, la vista de Diferencias me fue muy útil. Pero si hubiera muchísimos cambios, la vista de Diferencias no habría ayudado mucho porque el código tendría demasiados cambios, que no podría controlar.

    “Inch-Pebble” Check-Ins

    La traducción de “Inch Pebble” sería algo así como, “guijarros pequeños”. En español, guijarro ya trae de por sí el adjetivo pequeño. Definición de la RAE: Pequeño canto rodado. Quizá una traducción literal más adecuada sería algo como “micro cambios”. Pero sigamos con nuestro caso práctico.

    Todo el mundo sabe lo que es un hito, y todo el mundo sabe que tenemos que alcanzar ciertos hitos en nuestro trabajo. Pero ¿qué ocurre si esta suposición fuera errónea? ¿Qué ocurre si en vez de un único hito, nos esforzamos en alcanzar muchos pequeños hitos?

    En nuestro caso, marcar el camino con muchos guijarros. “Inch-Pebble” es un término acuñado por Johanna Rothman en el siguiente artículo. Lo he tomado prestado, para describir el proceso en el cual realizas check-in de tu código de manera frecuente, es decir con cada pequeño cambio haces un check-in. Usar la filosofía “Inch-Pebble” significa realizar check-in contínuos, y dejar fuera el realizar sólo uno o dos a lo largo del día.

    Lo que pretendía lograr con esto es mostrar los cambios que había ido realizando en mi tarea, pero en vez de hacerlo con un fichero de log, lo quería hacer mostrando los check-in que había ido realizando simplemente cuando modificaba o añadía unas pocas líneas.

    Las versiones modernas de los sistemas de control de versiones, se comportan de tal manera que agrupan todos los ficheros sobre los que hayas realizado check-in juntos. Cada una de estas agrupaciones lógicas se llama changeset, commit, transaction dependiendo de la nomenclatura que utilice tu sistema de control de versiones. De este modo, cada changeset ayudará por ejemplo a la persona que esté revisando el código a entender lo que se hizo, paso a paso, y por qué se hizo de ese modo.

    Vamos a pasar a ver todo lo que hice. Trabajé usando una rama, que era sobre la que realizaba todos los cambios. Y lo que fui haciendo es lo siguiente:

    • Moví un método privado desde la parte superior de la clase a la inferior, porque los privados deberían ir al final. Hice un changeset para describir este cambio.
    • Moví código heredado a una clase nueva, y lo combiné con código nuevo. Hice un nuevo changeset para indicar este cambio.
    • Creé un método nuevo para manejar parte de la nueva funcionalidad. Creé un nuevo changeset.

    Continué con más pasos hasta finalizar. Cada uno de ellos, lo más atómico que podía y con su changeset correspondiente.

    Ya he comentado que utilicé una sola rama para manejar estos cambios. ¿Qué significa esto? Significa sobre todo Libertad. Puedo hacer subidas de mi código a la rama, tan a menudo como quiera, sin preocuparme si rompo el build de la rama principal. El objetivo que tenía en mente era crear una secuencia documentada de cambios, de manera que si alguien se ponía a seguirla debería entender todos y cada uno de mis cambios. En realidad, era como estar grabando una película, escena a escena. Si lo piensas, es más fácil entender una refactorización paso a paso que mirar todo el proceso completo, cuando ha terminado.

    En mi opinión, este proceso se puede aplicar no sólo en la refactorización, sino también cuando añadimos nuevas funcionalidades. De este modo, se va grabando el modo de trabajo y tan sólo los resultados finales, porque el proceso en sí mismo es la grabación que se ha realizado en el sistema de control de versiones. Se guarda la información importante que puede ser reutilizada por otros desarrolladores para entender cómo se trabaja en el equipo.

    ¿Cómo ayuda Plastic SCM en todo este proceso?

    Lo primero es crear una rama, que es dónde vamos a trabajar y cambiamos el espacio de trabajo a esa rama.

    Figure 1: Nueva rama

    Ahora ya estamos listos para empezar a trabajar. Todos los cambios se harán en esta rama, y claro voy a hacer tantos check-in como necesite. Si vamos a la vista de Changeset, se pueden ir siguiendo de manera cómoda todos las actualizaciones que va teniendo la rama.

    Figure 2: Vista de Changeset

    Al final, si quiero saber cómo evolucionaron los cambios sobre el fichero original con el que empecé a trabajar, tendré la siguiente historia:

    Figure 3: Vista de Cambios Pendientes

    Figure 4: Historia de las Ramas (Inch-Pebble)


    Revisando los cambios: tengo mi película gracias a los changeset

    El hacer check-in con frecuencia, lo que produce es un conjunto de changeset que pueden ser revisados, uno a uno.

    Figure 5: Plastic SCM -- Rama Selecciona

    Figure 6: Vista de Menu Contextual


    Si seleccionamos el menú contextual de la Vista de Menú, tenemos tres opciones disponibles:

    • Ver los changeset de la rama
    • Explorar los changeset de la rama
    • Explorar el repositorio de la rama

    Si seleccionamos la vista de Changeset de la rama, lo que podemos ver es lo siguiente:

    Figure 7: Explorar los Changeset en la Rama (Plastic SCM GUI)


    Seleccionando “Explorar Changeset” en la rama, obtenemos la siguiente pantalla:

    Cada changeset contiene un conjunto de ficheros modificados, que afortunadamente están asociados a un comentario explicativo. Con las herramientas adecuadas, puedes inspeccionar de manera gráfica el contenido de cada changeset de modo que todos los pasos que tú has dado pueden ser seguidos por el resto de desarrolladores cómo si una cámara en vivo te estuviera grabando mientras estás desarrollando código.

    Figure 8: Explorar cada Changeset en cada Rama


    Conclusión

    Todo el proceso que he descrito no es nuevo, ni mucho menos, pero espero que haya servido para entender la gran ayuda qué nos brinda el realizar pequeños check-in de manera continua. No sólo porque realizando cambios o desarrollo a pasos pequeños es más fácil ir construyendo el código que lo pruebe todo. Sino que también, sirve como documentación propia, de manera que cualquiera que se acerque a mirar esos cambios, pueda entender si son correctos o no. Piensa además lo importante que es esto cuando estás trabajando en proyectos enormes, donde cada día se mueven miles de líneas de código.

    Las herramientas SCM pueden ayudar a grabar estas películas de autor, creadas a través de los changeset, siendo incluso más efectivas que utilizando las herramientas de revisión de código.


    No construyas equipos!

    miércoles, agosto 29, 2012

    Desde el año 2005 en el que empezaron David y Pablo como únicos integrantes del equipo de Plastic SCM, al que se unieron Borja y Dani en seguida, ninguna persona que se ha incorporado al equipo de desarrollo lo ha dejado. Ni lo han hecho por voluntad propia, ni se la pedido que lo hagan.


    Estamos en el año 2012, y el equipo de desarrollo de Plastic SCM está formado por 12 personas!!

    ¿Cual es el secreto?

    ¿Cual es el secreto? ¿Tienen la receta de la poción mágica de Panoramix?

    Pues la receta es que hacen lo que les gusta.

    El vivir experiencias de trabajo previas en otras empresas antes de arrancar Plastic SCM fue determinante a la hora de crear el equipo. Simplemente ayudaron a decidir todo lo que no querían para la persona que entrara en el equipo de desarrollo.

    David y Pablo tuvieron la suerte de trabajar junto a un equipo de mucho nivel en Sony (Bélgica). Vivieron de primera mano todos los valores que han tratado de fomentar en Plastic SCM.

    La lectura de libros como Peopleware, también han influido a la hora de como construir equipo, como encontrar a la gente adecuada.

    Trabajo variado, desafios constantes (Web, software de sistema, GUI, seguridad..), libertad para lanzar propuestas, confianza. Todo puede sonar a cuento, a sueño no posible, pero cuando hablas con cada uno de ellos lo que te transmiten es: Orgullo y Felicidad

    • Orgullo porque saben lo que hacen como desarrolladores, un producto que ayuda a su gente, desarrolladores.
    • Felicidad, porque crean con calidad y reconocen la influencia que genera lo que están creando.

    Uno de los 7 principios de Lean Software Development es: "Empower the team" No hay recursos, hay personas. No hay un líder que enarbola la bandera y al que se sigue.

    Hay pequeñas celulas que se van creando de modo que comparten su forma de trabajo: libertad con responsabilidad, confianza, esfuerzo, aprendizaje. Cada vez que hay una persona nueva, se va integrando en el equipo, de modo natural, como la pieza perfecta que se necesita en el puzzle.

    La mezcla de experiencia con la inexperiencia no es ningún problema. El equipo se encarga de arropar con paciencia y disciplina a las personas con menos experiencia. Así de manera natural se van creando esa espiral de trabajo: desarrollo, puesta en común del trabajo, proposición de ideas, responsabilidad de las tareas realizadas, seguimiento del producto, libertad,...

    Plastic SCM no han construido un equipo de desarrollo. Han permitido que todos sus valores sean los artifices de crear ese fantástico grupo que cada día lanza una nueva release del producto.



    "Pull" Mentoring

    jueves, agosto 23, 2012

    Recientemente se han producido tres nuevas incorporaciones en Plastic SCM. El equipo está creciendo con savia nueva. Para alguno de ellos no es su primer trabajo, pero para otros sí.

    Al incorporarte a un nuevo equipo lo que sobran son las ganas de trabajar. La primera semana, utilizando simil de montañeros, podríamos decir que estás en el campo base aclimatandote. Se imparte un training en el que te familiarizas con la que será tu arma de trabajo: Plastic SCM. A partir de ese momento, comienza tu escalada hacia la cima de la montaña.

    Mentor es un consejero o guía. Persona que da consejos, que dirige o encamina, como un sherpa en la montaña. En Codice Software no se nombra un sherpa por cada persona que entra, porque no tienes uno específico, tienes tantos sherpas como personas componen el equipo. Es verdad, que en esta escala hay un punto final, cómo una última referencia, pero en ningún momento hay que pensar que es más importante que el resto.

    El equipo de Plastic SCM apoya, aconseja, ayuda, responde pero en ningún momento está buscando Robocop's . El “mentoring” lo hace realmente la persona que entra. Cada uno de manera personal se marca si quiere subir a un K2 o simplemente se conforma con el Mulhacen. Es “pull” mentoring. Básicamente todas “las operaciones” que realizas ocurren así. Cada instante en el que preguntas, muestras tu trabajo, compartes las ideas … estás haciendo “pull”.


    Y cuando esto sucede:

    • Cada uno aprende las lineas base para realizar su trabajo
    • No necesitas que nadie te asigne las tareas
    • Las habilidades de las persona se van perfeccionando cada día de modo que dan más calidad tanto a su trabajo como al del equipo entero

    Aunque ya no seas un novato, sigues haciendo “pulling” cada día?