Leyendo un internet, he descuibierto una entrevista a Raúl Murciano, que habla de cómo mejorar como programador. Lo copio literal:
"Personalmente recomendaría lo siguiente, tanto a la gente que esté pensando en ir a trabajar fuera como a los que busquen trabajo en España:
- Si te vas a dedicar a la programación o al desarrollo web, plantéate si te gusta ese trabajo y si te divierte aprender. Este sector avanza a un ritmo increíble y no tiene pinta de frenar. Es imposible saber de todo, pero sí que necesitas mantenerte un poco al día. Si eso no te divierte vas a tirar un montón de tiempo de tu vida a la basura y se te agriará el carácter. Incluso si lo piensas fríamente, no tiene sentido: cualquiera que le ponga un poco de entusiasmo lo hará mejor que tú en poco tiempo. Dedicarte a esto si no te gusta sólo porque hay más empleo es pan para hoy y hambre para mañana. Como contrapartida, si te gusta crear y experimentar dentro de este terreno, estás de suerte: hace mucha falta gente como tú. No todo es de color de rosa, pero si tienes tiempo, ganas y la actitud necesaria estoy seguro de que no te faltarán oportunidades. Y si te faltan, escríbeme: raul@murciano.net e intentaré echarte un cable en lo que pueda.
- Como añadido al punto anterior, los cambios que vivimos no sólo son tecnológicos. Por un lado, el programador de hoy en día ya no recibe sus especificaciones y se mete en su cueva durante meses hasta que termina el proyecto. Los proyectos ahora se redefinen de manera iterativa y parte de nuestro trabajo consiste en aportar conocimiento técnico para evaluar riesgos, costes y oportunidades. Por otra parte, la mayor parte de los proyectos involucran gente de distintas disciplinas y conviene no sólo saber trabajar en equipo (que también tiene lo suyo) sino aprender un poco de las áreas relacionadas con nuestro trabajo. Para ser un buen desarrollador front-end necesitarás comprender a tus compañeros de diseño y de back-end, y todos deberéis entender al diseñador/manager del producto en el que estáis trabajando. El perfil de ultra-especialista-en-mi-nicho existe pero hay que ser MUY bueno.
- A nivel de "empleabilidad", me parece importantísimo tener algo visible que puedas enseñar, ya sea a nivel profesional o algo que hayas hecho en tu tiempo libre. Un blog, unos experimentos en GitHub, algún cacharreo de fin de semana... Algo que te divierta hacer y de lo que podrías hablar durante una entrevista de trabajo. Tener un título universitario te puede venir bien para conseguir un visado, pero en mi experiencia eso suele ser lo de menos. Cada vez más gente se da cuenta de que somos lo que hacemos, y no lo que un papel dice que hemos estudiado. Y volviendo a lo que comentaba antes, el entusiasmo, la persistencia y la humildad necesarias para aprender a hacer las cosas un poquito mejor cada día. Creo que sin eso no somos nadie, en lo personal y en lo profesional."
Fuente
martes, 28 de mayo de 2013
viernes, 24 de mayo de 2013
New Little Pet Project: AudioPlayer
I´ve read somethings about sound in HTML5. So I´ve decided write some code playing with it.
The result is in my github account.
The result is in my github account.
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)