viernes, 24 de mayo de 2013
Software Companies
Here in Spain the no culture of real software companies, making awesome products. Because our bussiness is rentting programmers for typing for 8hours per week. This is aour software ecosystem.
I´ve found a list of real software companies (out from Spain of course).
One of them (platform45) says: "We love building software". It´s amazing.
domingo, 19 de mayo de 2013
Algunos trucos para generar código limpio
Hace unas semanas estuve en un curso de introducción al TDD, dado por Carlos Ble.
Estas son algunas de las ideas que apunté:
.Código.
-No escribir ninguna línea de producción sin un test que esté en rojo.
-formas de hacer tdd: tdd inside-out <--> tdd outside-in
-Escuelas de tdd: school U.K. - school U.S.A.
-Programar con método. Ser metódico. Disciplina y esfuerzo.
-Escribir código para la máquina o para las personas: profesionalidad. Escribir código para otros seres humanos.
Poner cuidado en el código.
-Libro: Clean Code - Robert C. Martin
-Videos: cleancoders.com
-No solo un punto de retorno. Cuando antes se termine, mejor, para no poner ruido al código.
-Un método no debe de tener más de 5 líneas.
-Método hagan una cosa --> SOLID
-Métodos que sean de 2 ó 3 líneas, con un nombre muy muy bueno. Mal nombre es contra-producente, para no entrar a ver lo que hace.
-No comentar el código. Salvo un frameWork, una api y una clase añadirle la información de su contexto. Salva guardar la expresividad del código.
-Pensar antes de añadir un comentario, para no mentir y no estar invirtiendo tiempo en el mantenimiento.
-La función ideal no debe de tener parámetros. Puede tener como máximo 3 parámetros, pero no parámetros booleanos. Si tienes demasiados parámetros tiene que pasar un objeto.
-Clases no tener más de 2 ó 3 público y 2 ó 3 métodos privados. Con una cantiadad de 25 y 200 líneas.
-Nada de duplicidad y nombres expresivos.
-Números mágicos
.Unit Test.
-Agrupar los test, por contexto.
-Test repetible e inocuo. Si trabaja con la base de datos, luego tiene que limpiarla.
-Los test, no tienen que depender, unos de otros.
-Test muy rápidos y unitarios.
-No hay verdades absolutas
-Test de integración, necesita un entorno de verdad, igual al de producción. Comprobar integración con los sistemas.
-Los test de base de datos, son de end2end, pero se hacen al final, son costosos y tienen que ser pocos, porque son muy lentos
-Dejar una línea entre Arrange, Act & Assert.
.Doubles.
-Cuando un objeto tiene varias dependencias, es mejor hacer uso de una factoria.
-Stub devuelve cosas, no tiene memoria
-Spy, tiene memoria, recuerda lo que ha pasado
-Mock, tiene memoria, y falla si se tiene que hacer otra llama y no se hace.
También hicimos una kata, para validad contraseñas, con las siguientes reglas:
-Al menos 4 carácteres.
-Al menos un número y una letra
-Al menos una mayúscula
-Al menos una minúscula
El resultado está en mi cuenta de github
Me gustó mucho el curso, por todo.
Estas son algunas de las ideas que apunté:
.Código.
-No escribir ninguna línea de producción sin un test que esté en rojo.
-formas de hacer tdd: tdd inside-out <--> tdd outside-in
-Escuelas de tdd: school U.K. - school U.S.A.
-Programar con método. Ser metódico. Disciplina y esfuerzo.
-Escribir código para la máquina o para las personas: profesionalidad. Escribir código para otros seres humanos.
Poner cuidado en el código.
-Libro: Clean Code - Robert C. Martin
-Videos: cleancoders.com
-No solo un punto de retorno. Cuando antes se termine, mejor, para no poner ruido al código.
-Un método no debe de tener más de 5 líneas.
-Método hagan una cosa --> SOLID
-Métodos que sean de 2 ó 3 líneas, con un nombre muy muy bueno. Mal nombre es contra-producente, para no entrar a ver lo que hace.
-No comentar el código. Salvo un frameWork, una api y una clase añadirle la información de su contexto. Salva guardar la expresividad del código.
-Pensar antes de añadir un comentario, para no mentir y no estar invirtiendo tiempo en el mantenimiento.
-La función ideal no debe de tener parámetros. Puede tener como máximo 3 parámetros, pero no parámetros booleanos. Si tienes demasiados parámetros tiene que pasar un objeto.
-Clases no tener más de 2 ó 3 público y 2 ó 3 métodos privados. Con una cantiadad de 25 y 200 líneas.
-Nada de duplicidad y nombres expresivos.
-Números mágicos
.Unit Test.
-Agrupar los test, por contexto.
-Test repetible e inocuo. Si trabaja con la base de datos, luego tiene que limpiarla.
-Los test, no tienen que depender, unos de otros.
-Test muy rápidos y unitarios.
-No hay verdades absolutas
-Test de integración, necesita un entorno de verdad, igual al de producción. Comprobar integración con los sistemas.
-Los test de base de datos, son de end2end, pero se hacen al final, son costosos y tienen que ser pocos, porque son muy lentos
-Dejar una línea entre Arrange, Act & Assert.
.Doubles.
-Cuando un objeto tiene varias dependencias, es mejor hacer uso de una factoria.
-Stub devuelve cosas, no tiene memoria
-Spy, tiene memoria, recuerda lo que ha pasado
-Mock, tiene memoria, y falla si se tiene que hacer otra llama y no se hace.
También hicimos una kata, para validad contraseñas, con las siguientes reglas:
-Al menos 4 carácteres.
-Al menos un número y una letra
-Al menos una mayúscula
-Al menos una minúscula
El resultado está en mi cuenta de github
Me gustó mucho el curso, por todo.
jueves, 16 de mayo de 2013
sábado, 11 de mayo de 2013
Mi resumen de SaveInformaticOS
El pasado sábado 27 de abril estuve en el Open Space SaveInformaticOS
Sigo a JM Beas. Además se celebraba en mi universidad. Fue la primera vez que asistía a un evento de este tipo. Se iba a tratar el problema de nuestra profesión. Como era normal salió el tema de las cárnicas.
Creo que la solución para los males que estamos viviendo son:
-Estudiar, formarse, porque la empresa no se va a preocupar en formar, eso es algo que atañe a cada.
-Mejorar muchísimo como programador.
-Acercarse a lo que es la artesanía de software. Hacer commits a un repositorio público. Hacer proyectos, para demostrar lo que se vale.
-Tener esa actitud de mejora constante, a pesar del paso de los años.
-No va a ser fácil, pero creo que la recompensa va a merecer la pena.
Muy buenas sensaciones en general.
He visto a gente que realmente quiere cambiar, tiene ganas de mejorar. También he visto a gente que disfruta de su situación, por estar en una empresa de producto y se ha dado cuenta del difícil que se están poniendo las cosas. Pero he visto a gente que sufre por su ambiente laboral.
He puesto caras a personas que leo sus blogs, como el de Agustín Cuenta, kinisoftware, Laura Morillo, Alfredo Casado.
Me ha gustado que el CEO de Aspgems, ha dicho que el modelo de la sucontratación, va a morir, porque es insostenible, tal y como se está moviendo el mercado, la bajada de precios tan fuerte.
Me he encontrado a varios profesores de universidad y la verdad es que a la universidad española se la ha apretado bastante, porque la carrera deja bastante que desear. Yo creo que tiene que establecer unas bases sólidas, como por ejemplo paradigmas de programación (orientación a objetos, funcional, lógica, ...), patrones, diseño, ... Con esos conceptos en la cabeza luego el lenguaje o el framework de moda, es lo de menos. Después en el mundo laboral hay que seguir estudiando y ver los distintos caminos que se pueden tomar. Se ha hablado del mentor, para seguir progresando, cosa que me parece muy interesante y recomendable.
Hubo un debate sobre cómo veíamos el futuro. Yo no dije nada, porque tampoco quería trollear, pero para ser sincero lo veo muy negro, porque cada vez veo más paro, más crisis, catástrofes naturales más frecuentes y la tensión bélica entre los paises se puede oler a distancia. Pero solo es una opinión, espero estar equivocado.
Mientras tanto a trabajar, que para eso me pagan, a seguir mejorando y si se puede a disfrutar del recorrido.
Sigo a JM Beas. Además se celebraba en mi universidad. Fue la primera vez que asistía a un evento de este tipo. Se iba a tratar el problema de nuestra profesión. Como era normal salió el tema de las cárnicas.
Creo que la solución para los males que estamos viviendo son:
-Estudiar, formarse, porque la empresa no se va a preocupar en formar, eso es algo que atañe a cada.
-Mejorar muchísimo como programador.
-Acercarse a lo que es la artesanía de software. Hacer commits a un repositorio público. Hacer proyectos, para demostrar lo que se vale.
-Tener esa actitud de mejora constante, a pesar del paso de los años.
-No va a ser fácil, pero creo que la recompensa va a merecer la pena.
Muy buenas sensaciones en general.
He visto a gente que realmente quiere cambiar, tiene ganas de mejorar. También he visto a gente que disfruta de su situación, por estar en una empresa de producto y se ha dado cuenta del difícil que se están poniendo las cosas. Pero he visto a gente que sufre por su ambiente laboral.
He puesto caras a personas que leo sus blogs, como el de Agustín Cuenta, kinisoftware, Laura Morillo, Alfredo Casado.
Me ha gustado que el CEO de Aspgems, ha dicho que el modelo de la sucontratación, va a morir, porque es insostenible, tal y como se está moviendo el mercado, la bajada de precios tan fuerte.
Me he encontrado a varios profesores de universidad y la verdad es que a la universidad española se la ha apretado bastante, porque la carrera deja bastante que desear. Yo creo que tiene que establecer unas bases sólidas, como por ejemplo paradigmas de programación (orientación a objetos, funcional, lógica, ...), patrones, diseño, ... Con esos conceptos en la cabeza luego el lenguaje o el framework de moda, es lo de menos. Después en el mundo laboral hay que seguir estudiando y ver los distintos caminos que se pueden tomar. Se ha hablado del mentor, para seguir progresando, cosa que me parece muy interesante y recomendable.
Hubo un debate sobre cómo veíamos el futuro. Yo no dije nada, porque tampoco quería trollear, pero para ser sincero lo veo muy negro, porque cada vez veo más paro, más crisis, catástrofes naturales más frecuentes y la tensión bélica entre los paises se puede oler a distancia. Pero solo es una opinión, espero estar equivocado.
Mientras tanto a trabajar, que para eso me pagan, a seguir mejorando y si se puede a disfrutar del recorrido.
miércoles, 8 de mayo de 2013
Ejercicios para hacer en la oficina
Lo malo de trabajar en una oficina delante del ordenador, es que tarde o temprano aparecen los dolores de cuello y espalda. Algunos ejercicios que recomiendan para combatir este mal tan extendido.
Coding & Age
Suscribirse a:
Entradas (Atom)