Chus Naval - Blog Personal

Conceptos básicos de Git

2017-02-20

Bueno en primer lugar, diré que no sabía exactamente como continuar con el tema de Git antes de comenzar la parte más práctica, así que ojeando un poco su web principal he visto que tienen colgado el libro: Pro Git incluida la traducción parcial al español del mismo. A partir de este he sacado un pequeño resumen de la sección 1.3 para que podáis haceros una idea rápida del tema.

La imagen que aparece en este artículo también ha sido extraída del mismo libro.

Diferencias internas
La principal diferencia de Git con el resto de VCS es que Git mantiene una instantánea de los ficheros existentes en el repositorio, y lo hace por cada commit o cambio de estado que realicemos, mientras que los otros VCS existentes en aquel momento lo que hace es ir almacenando las diferencias entre los ficheros. De hecho internamente Git funciona como un sistema de ficheros y si necesitáis más información al respecto os dejo un enlace a un artículo que encontré (está en inglés) donde se detalla mejor todo esto.

Que es el Stage en Git
El stage es una etapa de Git previa a realizar un commit. Cuando pasas un fichero a stage se deja en un indice de Git que permite llevar un control de aquellos cambios de los que estás más o menos seguro que vas a realizar pero de los que no quieres realizar un commit todavía, ya que forman parte de un desarrollo/cambio más grande.

A mi la verdad es que esto me parece útil ya que es bastante fácil que hagas cambios de muchos ficheros en una misma jornada de trabajo y necesites ir diferenciando los cambios que son más o menos obvios de los que en un momento dado no estas del todo seguro.

Que es Git y como empece a usarlo

2017-01-26

Después de tanto tiempo con el blog parado, en este nuevo artículo me ha apetecido escribir algo y lo primero que se me ha ocurrido es comentar que es Git y porque empece a usarlo.

¿Que es Git?, pues curiosamente porque no suele suceder, en su propia web ya tenemos una definición muy buena de lo que es:

“Git es un sistema de control de versiones distribuidos, de código libre y gratuito, diseñado para manejar de todo desde pequeños hasta grandes proyectos con velocidad y eficiencia.”

Esta definición a los que llevan poco tiempo en esto de la programación, les proporciona al menos dos preguntas: ¿Que es un control de versiones?¿Y que significa que sea distribuido?

¿Que es un control de versiones? El control de versiones, es un sistema que permite almacenar y gestionar los cambios sucedidos en un proyecto de forma que podamos comprobar y administrar la evolución del mismo a lo largo del tiempo. Por ejemplo podemos ver la diferencia del estado actual de un proyecto con respecto a una versión desarrollada un mes antes y si quisiéramos también podríamos recuperar dicha versión.
¿Y que significa que sea distribuido? Tradicionalmente los ficheros del control de versiones se guardaban en un único servidor centralizado de forma que todos los programadores se conectaban al servidor y existía un supervisor encargado de gestionar las tareas principales del proyecto. En un sistema distribuido, cada usuario tiene una copia completa del proyecto por lo que puede realizar la gestión en su propio equipo y luego enviar una copia de los cambios realizados a los demás miembros del equipo o a un repositorio principal para facilitar el intercambio de las modificaciones pero sin las necesidad de una supervisión central del trabajo.

Algunos de vosotros os preguntaréis por que uso Git y no otro sistema de control de versiones, pues con respecto a eso os comentaré que yo comencé a usar Git principalmente para realizar pequeños proyectos con un compañero de trabajo con el que creaba herramientas de desarrollo para automatizar algunas tareas del día que eran tediosas. Gracias a Git pudimos desarrollar cada uno nuestra parte y sincronizar nuestros cambios de una forma sencilla manteniendo un ordenador de la empresa como repositorio principal. Después de esto al ver lo sencillo que es trabajar en Git y con la cantidad de proyectos existentes en GitHub, se convirtió en una de mis herramientas indispensables para trabajar.

Bueno, como no es plan de contarlo todo en un artículo, en las próximas semanas espero ir colgando nuevos artículos sobre Git.

Un saludo y gracias por leer mi blog.

Cambiar las cosas

2012-05-02

Hace poco leí que hacer aquellas cosas que te asustan es una de las mejores maneras de aprender, por que si realmente fallas aprenderás de tus errores. Si no fallas, sabrás que puedes hacer eso que te asusta. (Ojo que mis miedos, van más hacia el que dirán. No por ponerme a superar miedos debéis esperar que me lance a hacer escalada en hielo sin elementos de seguridad. Tampoco esperéis que lo haga con elementos de seguridad primero tendría que saber usar un piolet)

Dicho esto, voy a escribir algo que necesito decir hace mucho tiempo y quizás por miedo al que dirán, no me he atrevido hasta ahora:

De que va todo esto:

Llevo cinco años trabajando en una consultora de Madrid, mi trabajo según a quien le preguntes es el de programador (si me lo preguntas a mi), consultor (a mi jefe), jefe de equipo (a mis compañeros), con algo de ordenadores (a mis padres)... el caso es que trabajamos desarrollando software en un proyecto propio que vendemos a varias entidades financieras. El proyecto es una buena idea, quizás no la estemos ejecutando de la mejor forma posible, (últimamente no estamos satisfechos con como ocurren las cosas, ni con el número de incidencias, ni con la calidad de nuestro código, etc...) pero la idea es buena y siempre me ha gustado.

Pero de los continuos problemas, es algo de lo que llevo mucho tiempo quejandome, pero solo eso, quejas y más quejas... es cierto que he ido colaborando y proponiendo soluciones como implementar TDD, pero no me siento satisfecho. (Un poco como Rajoy con sus reformas, nunca estoy satisfecho)

Por lo tanto es hora de intentar hacer las cosas de otra forma, intentar tirar del carro por otro camino para llegar a situaciones y destinos distintos, arriesgando bastante más. (No como Rajoy que intenta las mismas cosas que criticaba de oposición o peor y con el mismo mal resultado) Siempre he asumido mi parte de culpa en todo lo que sucedía (otra cosa que no hacen Rajoy, ZP,...) pero sin duda me ha faltado intentar poner algo más de mi parte para buscar soluciones y no culpables.

En el último año, en mi vida, han sucedido muchas cosas; alguna de ellas tan imprevistas como dolorosas, pero gracias a todas ellas he logrado darme cuenta de que principalmente soy feliz en casi todos los ámbitos de mi vida, menos en uno, mi trabajo, y me paso allí la mayor parte del día.

Hay que hacer las cosas de una forma distinta y sobretodo divertirse en el proceso, ya que no divertirse es el mayor error que uno puede cometer en la vida. Te debes a ti mismo y a los que te rodean divertirte y disfrutar con ellos, sobretodo si tienes la suerte de poder trabajar en lo que te apasiona.

Hay que tomarse la vida de otra forma y terminar de aprender algunas ideas que me están haciendo cambiar mi trabajo y mi vida a mejor:

Divertirse, no me cansaré de repetirlo.
Recuerda que es lo que te apasiona y hazlo. (aunque sea en tu tiempo libre)
Casi nada es tan grave en la vida tómatelo con calma.
Si algo te asusta, hazlo.
Prueba nuevas formas de hacer las cosas o hacer nuevas cosas directamente, es una gran forma de aprender.
Mejor hecho que perfecto.

Conclusión de todo esto:

Alguien me dijo una vez que mientras unos sueñan en saber como funcionan las cosas, otros piensan en por que no hacerlas de forma distinta; al final todo esto se resume en la diferencia de las personas que se dedican a observar como funciona su mundo y las personas que se arrancan a cambiarlo.

Yo quiero ser de los segundos ¿y tú?

Hackers y urbanismo

2012-01-28

Últimamente tengo la inevitable sensación de que la programación y algunas artes plásticas están relacionadas. En concreto y tras leer Hackers and Painters veo que existen puntos en común entre la pintura y la programación. No quiero iniciar aquí una guerra sobre si la programación es una ciencia o un arte. Yo creo que la ciencia de la programación es para los que diseñan algoritmos de búsqueda más eficientes y con formalismos y demostraciones matemáticas. En una empresa no se piden demostraciones formales por lo que la mayoría del código existente no es algo científico, no existe una respuesta óptima (es decir única) para los problemas diarios. Si no estas de acuerdo con esto puedes dejar de leer este artículo ya mismo.

Lo que más me interesa en este momento es encontrar la posible relación entre la programación y la arquitectura, por que quizás en mi mente (que quizás es un poco soñadora) no dejar de ver que un programa no es más que una ciudad de código, donde existe relación con las teorías del urbanismo arquitectónico.

Una idea que he tenido hoy al respecto es que por ejemplo Japón tiene una filosofía urbanística totalmente distinta a la de un país europeo. (Hay que tener en cuenta que por ejemplo Tokio se rehizo después de la guerra mundial con más prisa que orden y que debido a su densidad de población sus necesidades son distintas a las de Madrid). Esto me ha llevado a pensar si existe una diferencia cultural a la hora de programar entre Tokio y Madrid. En principio parece claro que si ya que los medios, necesidades y los problemas de los clientes son distintos, pero por otra parte hemos de tener en cuenta que algunos de los mejores manuales de programación se han extendido por todo el mundo, uniformando muchos de los criterios que se usan a la hora de desarrollar, y que si tenemos patrones de diseño es por que hay soluciones comunes a problemas comunes.

No obstante, y como decía al principio considero que una parte de la programación esta relacionada con el arte; por ejemplo yo soy partidario de la filosofía Literate Programming y por lo tanto creo que uno debe programar su código como si de escribir un libro se tratase, para tratar de mejorar la relectura del código, mantenimiento, etc…

De ser así y dado que la literatura de cada región depende de muchos factores culturales, entre los que destaca por encima el propio idioma, un código de un programa seguramente se explique de distinta forma en distintas civilizaciones aún usando en ambas como lenguaje de programación C y siendo en ambas una referencia para aprender a programar en C, el manual de Kernighan y Ritchie.

Esta diferencia debería ser más acentuada sin duda si observamos que las bibliografías de las distintas universidades se basan generalmente la disponibilidad de las traducciones de los textos o en libros escritos directamente por el profesorado de la facultad.

Al final, creo que no puedo llegar a una conclusión directa en este artículo, pero por otra parte el artículo no se trataba de esto. Hackers y urbanismo: o sobre la posible relación entre el código fuente y el diseño en la arquitectura y el urbanismo y seguir buscándola, es de lo que va este ejercicio.

Aclarando tu código...

2011-10-30

El recurso más sencillo para aclarar el código de una aplicación es borrar aquel código que sobra. Ocurre a veces que en proyectos de larga duración, debido a las prisas, (sobretodo si no existen pruebas unitarias automatizadas) a los desarrolladores les entra cierto miedo y modifican métodos o funciones realizando llamadas a nuevos métodos y dejando sin uso partes del código. (digo miedo por que esto suele pasar cuando se usa el viejo principio de “Si funciona no lo toques”).

Cuando esto ocurre la aplicación crece innecesariamente por que se termina por no analizar si los tipos de datos estan bien abstraidos o si existe la necesidad de “refactorizar” y al final duplicamos código y tarde o temprano algunos métodos se quedan sin sentido en nuestras clases.

Cuando esto ocurre, por favor: Borra el código que sobra. Lo único que hace es estorbar, te dificulta un nuevo análisis de la aplicación (un programador se pasa leyendo código un 60% de su tiempo), se termina por mantener código que no va a ningún sitio, etc…En el peor de los casos, la funcionalidad del código sobrante termina por ser erronea con respecto a los nuevos requisitos o contiene errores de funcionamiento no descubiertos aún y corremos el riesgo de que alguien use dicho código sin saberlo.

Hay quien cree que eso sería perder funcionalidad pero si de verdad necesitas esa funcionalidad, le darias uso. Además siempre tenemos repositorios donde podemos ver la historia del desarrollo con la opción de recuperarlo. Por todo esto, cualquier código que sobre y que puedas borrar, borralo ya que es una manera muy sencilla de mejorar la salud de tu aplicación.

Un saludo

PD: Si usas Intellij Idea tienes por defecto la capacidad de encontrar código sin uso, en Eclipse existe un plugin llamado UC Detector que funciona bastante bien.

El código como conjunto

2011-05-18

Una de las cosas que aprendí leyendo Clean Code es que tu código debe ser tan claro como si escribieses una novela, no obstante el 70% del tiempo que estas programando estas en realidad leyendo código. Esta idea cambio totalmente mi forma de programar, he seguido varias de las pautas que Uncle Bob nos indica y con ello creé un proceso para que de forma genérica en el proyecto en el que trabajo se pudiese generar un fichero de texto a partir de una consulta a base de datos.

Esta funcionalidad tiene por supuesto unos cuantos requerimientos más y todos ellos he procurado hacerlos de forma automática para que el equipo de trabajo se ahorrase trabajo. Y la verdad que se nota la diferencia el código esta mucho más claro… pero tiene un problema…

La semana pasada una compañera tenía que extender la funcionalidad del proceso para generar un Excel usando Apache POI, di por sentado que sería una tarea sencilla pero no esta siendo así y hemos tenido que dar unas cuantas vueltas al código.

Reflexionando sobre ello he aprendido una valiosa lección:

El código debe ser sencillo y bien estructurado…pero debe serlo en conjunto no vale sólo que cada clase, métodos y propiedades sean claros. Quien tenga que mantenerlo debe poder ver el conjunto y con ello las relaciones de tu negocio. Si esto no es así pues toca “refactorizar”.

Un saludo

Lo que me esta aportando Clean Code

2011-03-30

Estos últimos días entre pase y pase a producción del proyecto en el que trabajo, he logrado sacar el tiempo para leerme una buena parte de Clean Code; y no puedo evitar compartir lo mucho que me ha aportado.

Llevo trabajando como desarrollador durante unos cuatro años; se que no es mucho pero debería ser suficiente para programar de una forma más o menos correcta y productiva. Pues no es mi caso.

Me explico, yo sabía que estaba realizando unas cuantas cosas mal, bien por costumbres heredadas del proyecto o por falta de tiempo para pensar en lo que estaba haciendo…(se que no son excusas validas pero son las mejores que tengo). Llegué al punto de querer dejar esta profesión cuando siempre la he considerado mi única vocación.

Con Apprenticeship Patterns renové el optimismo, recuperé el gusto por el trabajo de desarrollador y aprendí que debía cambiar de actitud y asumir que tengo que ponerme el cinturón blanco para continuar aprendiendo. El caso es que al leer Clean Code he comprendido que realmente nunca he llevado puesto otro cinturón. El libro me ha hecho ver las cosas de un modo totalmente distinto desde el primer capítulo y creo que ahora es cuando estoy empezando a saber como algo de programación. Por eso aunque en estos cuatro años he aprendido unas cuantas cosas, ahora se que programar no es una de ellas.

Si algo parecido te pasa a ti, que sepas que tiene remedio: deja de quejarte, se optimista, lee mucho y practica…

Un saludo

Lectura de Apprenticeship Patterns

2011-03-05

Bueno en estos meses he empezado a leer libros que según he leido en blogs y twitter pueden ayudarte a mejorar como desarrollador de software.

El último que me he leido es Apprenticeship Patterns: Guidance For The Aspiring Software Craftsman. Un libro altamente recomendable con muchos consejos en forma de patrones para aquellos que de una forma u otra estamos empezando en el mundo de la programación.

Me gusta mucho la idea de que si bien uno de los objetivos de los programadores es no realizar tareas repetitivas, dada la juventud de este negocio, existen pocas referencias de los programadores más veteranos sobre como no cometer ciertos errores en nuestra carrera profesional que han cometido generaciones anteriores. Este es el punto de vista general del libro, el evitar que repitamos problemas.

Por otra parte el centro de la lectura es el patrón “The Long Road” y es que esta profesión hay que tener muy claro que si no eres Linus Torvalds o Richard Stallman, tienes un largo camino por delante antes de llegar a ser un buen programador, y es uno de los objetivos principales del libro enseñarnos a aquellos que estamos empezando uno de los posibles caminos a seguir para ser un buen programador.

Ahora he empezado a leer Clean Code: A Handbook of Agile Software Craftsmanship, cuando lo termine os comentaré lo que he aprendido de él.

Un saludo.

Objetivos del año

2010-12-31

Bueno se va acabando el año y parece que una vez más me he dejado los objetivos del año pasado por el camino; quizás por que nunca me lo he tomado muy en serio, quizás por que era más bien una lista de propósitos: El gachupas.

El caso es que estos últimos meses hay cosas que he ido arreglando en mi vida y me encuentro en un momento muy optimista, asi que va mi nueva lista objetivos alguno más genérico que otro (objetivo de todos modos):

Leer y aprender todo lo posible.
Crecer como profesional del desarrollo de software.
Disfrutar más de la familia y amigos.
Aprender Ruby.
Aprender Perl.
Aprender Groovy.
Remotar la carrera.
Mantener el blog.
Colaborar en algún proyecto Open Source.
Y por supuesto disfrutar de la vida siendo un geek.

Espero vernos dentro de un año para repasar esta lista y que pueda decir que he cumplido la mayoria de mis objetivos.

Un abrazo para todos.