Lacarrismos del 19 al 25 de agosto: «la vuelta al cole»

Hola melones con jamones!

Semana que califico como «la vuelta al cole». Esta semana que vuelves a la actividad extra escolar pero que estás primero con la faena pendiente. Un remember: aún no me he pillado vacaciones y lo estoy llevando bastante bien.

Currele

Programar la herramienta de migración AsisT: Es un programa en java que realiza dos pasos: chequear que los datos de unos ficheros origen son acordes a una base de datos destino y migrar esos datos del origen al destino. Respecto a este tema no puedo aportar más información, sólo grandes conclusiones: AMO CON LOCURA EL TESTEO.

Los ficheros para migrar  (clientes, contactos, estados de los clientes, etc)  hacen que la aplicación esté creciendo desmesuradamente. Por cada fichero existe una clase de test con una función por cada campo a migrar para comprobar si la aplicación chequea que está bien o está mal (Ejemplo: «si pasas una fecha a null y es obligatoria la el test está ok si avisa del error») . Lo mismo para migrar esa información.

Mientras tanto, aún realizo cambios en el proyecto de migración. Que generalmente y sin quererlo, termino haciendo TDD.

Por ejemplo: Me peta el programa porque quiero que me inserte una fecha a null. Por lo tanto, genero una  funcionalidad que si detecta una fecha la inserte y si pone en una propiedad null, inserte null.

¿Qué está pasando? Que estoy arreglando cosas pero rompiendo otras.

testing

Existe una persona dentro del equipo, que está generando los ficheros csv a partir de los datos de la otra plataforma para que pasen por la aplicación de migración. Esta persona me dijo el otro día. «Voy a avanzar con más ficheros para migrar, ¿puedes pasarme una actualización?». Le dije: «Espera 5 minutos, voy a comprobar que no he roto nada».

Increíble pero cierto. En 5 min comprobé que los ficheros seguían en verde y generé una nueva versión del programa de migración.

aplause gif

Nadie me está diciendo cómo hacerlo o cómo no hacerlo. Lo estoy haciendo como a mí me viene bien para garantizar que mi jefe a finales de Septiembre, vaya al cliente y funcione todo perfectamente. Incluso cambiando alguna cosa la última semana puedo estar segura y tranquila que todo funcionará bien (volver a mirar el gif de los aplausos). (No os perdáis el desenlace xDD).

Incidencias de AsisT: atención al cliente y resolución de incidencias.

Lo que no es currele

Betabeers: Ando en un proyectillo con Betabeers. Esta semana he estado elaborando la documentación que tenía pendienteHe espabilado gracias a la visita de… Pablo Rodriguez.

¿Quién es Pablo Rodriguez? @Yondemon! Por los dioses de los dioses. De los creadores de betabeers, fundadores de la organización y programador por vocación (música de película de fondo). Hasta ahora sólo lo conocía por Hangout. ¡Por fin te pongo cara! jojo.

Bueno, estuvimos hablando del presente y futuro de Betabeers, de movidas varias  y de risas. El jueves nos juntamos unos cuantos del valley y el viernes había que hacer el terrible esfuerzo de enseñarle la marcha maña. (Gran noche!!)

Geeks talks: Probando, probando. Escribí para orientar la próxima quedada  del 4 de Septiembre (este banner ha sido patrocinado por Geeks Talks jajaja ).

BLOG: plasmé mis reflexiones en la montaña en este post Manifiesto del china chana: 10 filosofias de la montaña aplicadas a la vida.

Cada cosa que está escrita en el post lo puedo aplicar a algo del día a día y más concretamente de mi trabajo o ocio de programadora: el ambiente de buen rollito y colaborador de los eventos, las veces que me he lanzado a hacer una cosa sin formarme bien y al final he tropezado, la superación y motivación cuando salen las cosas bien, momentos difíciles en la vida, las retiradas a tiempo, etc.

Lo que más me ha encantado es el feedback que he tenido respecto al post. Es una satisfacción enorme cuando te escriben, comparten o te comentan personalmente sus opiniones.

En fin.  Ya ha empezado la semana del 26 al al 2 de Septiembre y como me siga enrollando se me van a solapar.

A ser felices! y comer perdices!

Manifiesto del china chana: 10 filosofias de la montaña aplicadas a la vida

China chana es una expresión que  significa “andar poco a poco”. Se utiliza para describir que no importan las prisas, ni la dificultad, si no que siguiendo el camino china china se consiguen las metas.

En nuestra vida tenemos de todo: alegrías, penurias, objetivos, proyectos, logros, fracasos, etc. En referencia a la vida y la montaña o el deporte empecé a observar similitudes entre la filosofía del montañero y la vida misma. Estos pensamientos los maduré mientras subía uno de mis grandes objetivos personales “El Monte Perdido”, pico del Pirineo Aragonés en el Parque nacional de Ordesa y Monte Perdido.

Como no quería que esos pensamientos se los llevara el viento, aquí los comparto con todos. Podéis estar de acuerdo o no. Es una simple opinión de una servidora. No os cortéis en comentar. Juntos, construiremos un mundo mejor 🙂  

1 – Mentalización: – ¿Ves esa cima? Pues no es, está detrás

Generalmente el objetivo no está visible. Hay que estar mentalizado de que aunque no lo veas, está ahí, y es alcanzable

2 – Saludos montañeros: ¡Hola!  ¡Buenos días!

Posiblemente la mejor regla no escrita de la montaña es saludar a todos con los que te cruzas por el camino. Esta práctica inspira hermandad, compañerismo, ayuda, respeto, alegría, educación y paz. Tu camino para conseguir el objetivo será mucho más divertido y entretenido si compartes, ayudas al de al lado, conoces a nueva gente o simplemente sonríes.

3 – Fuerzas de la naturaleza: Se acerca una tormenta

Las fuerzas de la naturaleza o los imprevistos en nuestra vida, aparecen sin más. No avisan, son molestos, pueden ser devastadores, desaniman, rompen los esquemas, la rutina y en definitiva no sientan bien. Aunque no lo quieras, están afectando tu vida, tu forma de actuar, de comportamiento o productividad. ¿Qué haces? ¿qué hay hacer?

Aguantar el chaparrón. Lo aguantas lo mejor que puedas. Todos somos diferentes y por ello  algunas personas lo llevan mejor, otras lo llevan peor. Lo que sí es cierto es que la tormenta pasa y saldrá el sol. Aunque todo se vea negro, lo mismo que vino, se irá.  De hecho, lo siguiente por venir va a ser mucho mejor. Ten paciencia y los pies en la tierra.

4 – Saber dónde está el límite: – Voy a subir hasta el Monte Perdido corriendo – ¡Al igual lo subes majo!

Establecer metas imposibles ocasiona frustración, angustia y desesperación al no conseguirlo. Empieza con objetivos asequibles, poco a poco  y superándote en cada paso. No te impacientes. China chana.

5 – No todos tenemos la misma capacidad: – Sube el monte como las cabras.

Asúmelo, el mismo esfuerzo con la misma preparación depende totalmente de la persona. Hay personas que tienen más facilidad y otras menos. No es motivo para desanimarse, sino para superarse dentro de nuestras limitaciones. El entrenamiento te dará la superación que estás esperando.

6 – Buen equipamiento: – Llevo botas de alta montaña, dos bastones, crampones, piolet, ropa de abrigo por si hace frío, etc.

Puedes alcanzar el objetivo sin ir totalmente equipado pero ¿es lo más efectivo? ¿ha sido seguro? ¿ha tenido consecuencias posteriores? Si no vas equipado en concordancia lo que puede pasar que te de más de un dolor , que tardes más tiempo de lo normal o algo mucho peor.

Por otro lado, lo que ocurre es que finalmente llevas mucha carga y  no has llegado a utilizar la mitad.

Así son las cosas. Te puedes arriesgar a que no pase nada, ¿pero si pasa? ¿te compensa ir prevenido?

Lo primero que hay que hacer es informarse bien del camino y determinar las mejores decisiones.

7 – Las prisas no son buenas

Un topicazo pero cierto. Las prisas por lo general, no son buenas. Eso sí, si tienes una tormenta encima, ya puedes salir por patas. 

El cómo van a afectar las prisas depende de la destreza de cada uno. Pueden salir bien o pueden salir mal.

Puedes arriesgarte para ver hasta dónde alcanzan tus posibilidades, pero si vas siempre con prisas, tenderás a caerte.

8 – Los atajos engañan: – No llegué al Ibón por culpa de pillar un atajo.

Los atajos son bonitos y preciosos, pero no son seguros ni fiables y pueden llevarte a no alcanzar el objetivo.

Como mentes inquietas que somos, nos gusta intentar saltarnos pasos, saltarnos un tema o ir al grano. Lo mismo que antes: puede salir bien, y otras mal. Si sale mal, hay  deshacer lo hecho e iniciar otro camino. ¿hasta qué punto merece la pena riesgo?  

Lamentablemente, los atajos son tan tan tentadores.

9 – Una retirada a tiempo es siempre una victoria: – Se acerca la tormenta. Es mejor volver.

No existen los fracasos, existe la cordura mental. Si no es alcanzable o viable, lo dejas, y punto. No está mal establecerse objetivos ociosos. Lo importante es finalmente saber decir NO y si ya se ha empezado, saber decir hasta aquí .

Es fácil decirlo, pero más difícil hacerlo. En ocasiones queremos conseguir algo con locura sin pararnos en pensar si es lo mejor para nosotros mismos. Arriesgar o retardar la decisión puede llevar a más frustración personar y no solo eso, que el equipo de la expedición salga perjudicado. Encontrar el equilibrio en esta decisión, creo que lo aporta la experiencia.

10 – Motivación y superación: Objetivo conseguido, ¿qué es lo siguiente?

Al final, lo que mueve tu vida, lo que impulsa tu día a día es la motivación personal. No hay mayor motivación que alcanzar el objetivo y superarse.

No importa si se repite, conseguirlo en mejor estado, en mejor forma, en mejor tiempo, o con un incremento de actividad, te va a llevar a una subida de adrenalina que engancha, ocasiona felicidad y una satisfacción indescriptible.

La vida puede parecer días de sol o puede parecer montañas; pueden parecer llanuras de flores o puede parecer tormentas.

¿Con qué hay que quedarse? Lo importante es disfrutar del camino y que si hay alguna complicación; respiremos, tomemos aire y continuemos hacia delante. Seguro que arriba, hay una vista preciosa esperándonos.

Valle de La Pineta desde Monte Perdido

Valle de La Pineta visto desde Monte Perdido 3.355 m. Parque Nacional de Ordesa

Lacarrismos del 12 al 18 de Agosto: alcanzar los objetivos

 

Buenas noches amigüitos.

Esta semana de puente, la puedo considerar como una semana alucinante. No, no tiene nada que ver con proyectos, eventos, charlas, ni nada por el estilo. He conseguido un gran objetivo personal: Subir el Monte Perdido.

¿Por qué lo comento aquí? No es mi objetivo inicial comentar estas cosas en mis resúmenes, pero me siento tan orgullosa y he sacado tantas similitudes con los proyectos personales y la vida misma, que lo tengo que compartir.

Los que me conozcan ya sabrán mi pasión por la montaña. La montaña es ideal para desconectar, principalmente: porque no hay cobertura ¡bravo!

Siempre he hecho excursiones sencillas, pero últimamente, necesitaba más. Me encontraba ociosa, fuerte y motivada. Del cielo y de la mano de mi familia me vino esta gran ocasión: desde Gabarnié (Francia) ir a la Brecha de Rolando (2.840 m), la Gruta Helada de Casterets, acampar a las puertas del refugio de Goriz  (2.200 m), al día siguiente coronar el Monte Perdido (3.355 m) y volver a la pradera (1.310 m).

En horas: 8 horas aprox de travesía el primer día y 11 horas aprox de travesía el segundo día (Con travesía incluyo descansos, comidas y disfrutar de la vista).

Ha sido una experiencia inolvidable: disfrutar de las vistas preciosas del valle de Ordesa, alcanzar retos y objetivos personales, ver que estás fuerte y que puedes alcanzar lo que te propones. ¡Ah! Y que no tengo ni ampollas, ni rozaduras, ni agujetas (sí, me siento muy orgullosa de decirlo).

Como todo en esta vida, la travesía no fue perfecta. El primer día nos alcanzó la tormenta mientras andábamos. Cuando llegamos al refugio, montamos la tienda de campaña de urgencia, calándonos y con unos entrañables relámpagos de fondo.

Esta hazaña me ha hecho madurar un post que publicaré mañana: «La teoría del china chana: 10 teorías de la montaña aplicables a tu vida».

Por ahora os dejo con estas foticos hechas con el móvil.

Saludos! Paz! y amor!

Cima del Monte Perdido

Cima del Monte Perdido

Casterets

Casterets

La brecha de Rolando

La brecha de Rolando

Vistas del valle de Ordesa

Vistas del valle de Ordesa

El cilindro y el lago helado

El cilindro y el lago helado

Monte Perdido

Monte Perdido

Vistas del valle de Ordesa

Vistas del valle de Ordesa

Cola de Caballo

Cola de Caballo

 

 

 

 

 

Lacarrismos del 5 al 11 de Agosto: «Reset»

Apagar y volver a encender ha sido siempre y será la solución mejor para el informático. Para la vida personal, ni te cuento.

Semana de nadar, boulder, montaña, amigos, familia, spa… rica, rica. En una situación trabajando en jornada de verano, meditando y buscando la paz interior puedo afirmar que no estoy en mi mejor momento pero que me encuentro con muchísimas ganas de retomar los cursillos, proyectillos, colaboradora, etc. Incluso a medio gas, siempre se aprenden nuevas cosas.

Aquí va el resumen de la semana pasada.

Currele

Soluciones en AsisT

Lo defino así porque así lo he vivido. Ha sido una semana que han surgido nuevas peticiones en las instalaciones y soporte. Ante eso ha sido puro y duro buscar soluciones, transmitirlas, estimarlas y desarrollar las urgentes.

Experiencia de Git: Esta semana, aprovechando que era la única desarrollando,  he estado probando utilizar git-flow siguiendo el modelo de 4 ramas. Master, develop, Features, Hotfix.

Me ha gustado la experiencia de desarrollar toda en una y realizar commits y push sobre ella. La gran ventaja que he visto es que he tenido que solucionar un conflicto en vez de cada rama de desarrollo. Como observación no he hecho un pull request a desarrollo hasta que el responsable de mergear las ramas no volviera de sus vacaciones.

También, contra-pronóstico, he tenido que desarrollar un bug en  Hotfix. Nunca habíamos utilizado una rama distinta y «limpia» (sin ningún otro desarrollo) para subir un bug, utilizábamos ya los desarrollos hechos y probados e incorporábamos el bug solucionado. Para mí, utilizar Hotfix me da mayor seguridad para subir una versión de urgencia ya que subirla con pequeños desarrollos implicaría unas pruebas de integración que retrasaría la publicación de la versión o peor aún, subirla sin realizar las suficientes pruebas (no tenemos un sistema de integración continua).

Esta semana volveré a el desarrollo de historia de usuario por rama.

Lo que no es currele

Geek’s talks: Charla mensual para desarrolladores que quieren practicar inglés. Los orígenes los explico en este post. El pasado 7 de agosto se hicieron realidad. Los detalles de qué se hizo en el evento están aquí. En este resumen quería aprovechar para contar mi experiencia personal.

Fui al evento con bastante miedo de que no fuera nadie. ¿Las causas? Una lluvia torrencial que hasta a mí me había dejado incomunicada en la avenida navarra.  Me presenté con la filosofía: si no viene nadie, al menos me echaré una birra 🙂 Además, para conversar, sólo se necesitan dos personas 🙂

Grata sorpresa de estar 7 personas, empiezo a saludar en español… oh my cat! We must speak english. Cambio al inglés. Empieza la primera sesión de Geek’s Talks. Awesome!

Lo primero que hicimos fueron presentaciones personales: a qué nos dedicamos, porqué estamos en el grupo, qué esperamos de las charlas, etc. Es un gran momento para romper el hielo, conocernos y saber qué es lo que quiere aprender cada uno para orientar mejor las charlas. Cada uno tenía su propia opinión, algunos mejorar en lo técnico, otros en la gramática, otros en conversación, etc. Pero había un denominador común: ganas de mejorar y aprender.

Continuamos con el tema en cuestión: ¿Qué sistema de control de versiones utilizas? ¿Qué opinas de él? ¿Cosas buenas y malas? ¿Como utilizas el control de versiones? ¿Cosas buenas y malas?

Siendo la primera quedada me lancé a proponer un tema que a mí me venía bien en el ámbito profesional, pero la idea es que mediante la plataforma de Meetup se propongan temas para solucionar dudas de todos.

En esta charla quería sacar de conclusión si es mejor utilizar una rama por cada historia de funcionalidad o una rama feautures paralela a develop. Me llevé un saco de buenas ideas y creo que me decantaría por crear una rama por historia con una figura de persona mergeadora.

Guillermo Zanfra utiliza develop y master. El único problema que comentó es que hasta que hasta que no haces un push a develop, tienes todo tu desarrollo en local. Para el tipo de proyecto me parece que es buena solución. Este modelo es el típico a utilizar cuando una sola persona está en el proyecto

Por lo general en grandes proyectos utilizaban una rama por funcionalidad. Cuando subían esas ramas, se despreocupaban completamente de ellas. Existe una figura que las comprueba y realiza los merges con desarrollo.

Durante la conversación, anotamos vocabulario, gramática que dudábamos y algunos fallos de pronunciación 😉 Check the list!

Y cuando terminamos… continuamos hablando en inglés xDD. Nos fuimos por ahí cerca a cenar y hasta que no salimos del restaurante, continuamos nuestra andadura. Entre las cosas que comentamos fue la retro del evento. Estuvimos hablando de cómo mejorar en la siguiente iteración, técnicas para aprender, etc. No adelantaré detalles…. (más que nada porque ya me he liado bastante hablando xDD).

Esta semana será corta y poco productiva: el miércoles me iré de puente (bravo).

Sólo me queda desear que paséis y disfrutéis de unas preciosas, hermosas y felices vacaciones! A ser felices y comer perdices!

 

 

Lacarrismos del 29 al 2 de Agosto «Take it easy»

Punto negativo. El viernes pasado no publiqué el resumen. Siendo realista y mis ganas de escaparme el fin de semana: durante el verano publicaré el lunes.

Este resumen lo titulo «take it easy» porque no siento que esté haciendo tantas cosas como acostumbro a hacer, pero por otro lado me siento más aliviada y tranquila: necesitaba bajar el ritmo porque entre que no me pillo vacaciones en agosto y no he parado en mucho tiempo voy a acabar majara (aún más de lo que acostumbro).

Al lio! ¿Qué hice la semana pasada?

Currele

AsisT: Despliegue de la versión 1.10.5 de AsisT.

    • Baterías de pruebas de la aplicación para desplegar la versión: pruebas en el entorno de pre-producción del funcionamiento de la aplicación con un terminal de teleasistencia en la propia oficina.
    • Git problems: experimenté bastantes problemas con git cuando hacía un pull request. Siempre conflictos a mergear y de todas las ramas así como un dolor de cabeza a la hora de solucionarlo. Esto me llevó a 2 conclusiones:
      • No estoy utilizando bien git.
      • Tengo que investigar más cosas sobre git.

Hasta hace una semana creaba una rama por cada historia. Las herramientas que utilizo con Git es Netbeans y consola. Cosas buenas:

    • Sabes que se ha desarrollado en esa rama y no se solapa con otros desarrollos.
    • SI existe una persona encargada de validar el funcionamiento o código antes de pasarlo a develop, al estar sólo la rama no solapa nada más de funcionalidad.
    •  Al final puedes decidir si esa rama quieres introducirla o no a develop sin solapamientos.
    • Puedes abrir varias ramas con distinta funcionalidad a la vez, una incluirla y la otra al no llegar a tiempo posponerla
    • Netbeans es la plataforma en la que desarrollo.

Cosas muy malas:

  • Tienes que solucionar cada conflicto con cada rama.
  • Crecimiento de ramas desmesurado tanto en local como en remoto.
  • En ocasiones pierdes el control de si finalmente esa rama ha sido validadad y subida por un pull request. (Imaginas que alguien la ha validado y está develop actualizado y que se le ha olvidado actualizar la herramienta de JIRA, pero no, es que no lo ha hecho).
  • Tienes que cambiar a develop cada vez que vas a crear una rama de forma que sea independiente. Aunque el código no tenga conflictos, está trabajando sobre código

Lo que he empezado a hacer.

  • Utilizar SourceTree como herramienta potentísima de Git: Higly recommended y eso que ahora solo he chapurreado. 
  • Seguir el modelo git flow: tienes una única rama «features» que haces todos los desarrollos de las ramas. (Por ahora la rama «hotfix» no he empezado a utilizarla). En realidad si haces buenos commits comentados, push cuando has terminado una historia y pull request de features a develop, la aplicación está muy organizada.
  • El validador que de el visto bueno en develop. En develop están todos los cambios. Para esta persona supone más tiempo cambiarse de rama, además que revisa el código cuando ya están hechas varias historias (para qué complicarse tanto la vida si pueden estar todas las historias juntas).
  • Si hay varios desarrollos en features y finalmente el otro no queremos subir el cambio: Esto espero que no me ocurra en la vida. Más que nada porque significará que soy una PAQUETE organizándome. Se empieza una cosa, se desarrolla y se termina. Si hay algo urgente, catastrófico, fugaz que hay que hacer, tendrá que ir a la rama «hotfix». Si es otro desarrollo, tendrá que esperar.
  • Si no he terminado un desarrollo para este sprint, entonces los cambios no los publicaré a develop .

Me acabo de enrrollar mucho XDD. Continuando con las cosas del curro:

  • Tag de la versión, actualización del jnlp,  publicación de las nuevas librerías, actulización de las bases de datos y comprobación que las instalaciones funcionan correctamente.
  • Documentación de hitos en la actualización.
  • Documentación «checklist» de funcionalidad que hay que hacer en el equipo  después de un despligue.

Y lo que no es currele

Reunión de Betabeers a nivel nacional.

  • Hangout: Temas a hablar organizativos, puesta en marcha de activdades, etc.

http://www.patriciagarciagil.com: cambios pequeños en la web.

Tarde en la colaboradora: estuve trabajando en mi nuevo blog 🙂

Mover el evento del 7 de Agosto: Geek’s talks.

Saludos!