Una edición más me ha apuntado a la piweek. En esta ocasión me he apuntado a última hora puesto que en principio en estas fechas iba a estar de vacaciones.
En esta ocasión, del equipo de Alea Soluciones, he conseguido liar a https://twitter.com/jaimegil
Cómo sigo con mi cruzada personal por aprender algo de javascript, hemos decido implementar un pequeño visualizador de eventos https://github.com/aleasoluciones/eventsview
No tenemos muchas pretensiones en cuanto a las funcionalidades a realizar, el objetivo en mi caso es seguir aprendiendo, por lo que me importa mucho más tener la mente abierta que realmente tener una funcionalidad interesante.
De momento hemos realizado un pequeño listado de eventos que se va refrescando por ajax y lo hemos separado en dos objetos de vista, un presenter y un repositorio.
Estábamos planteándonos probar a implementarlo usando react (una vez más, sólo por aprender).
Una cosa muy interesante que he aprendido es lo importante que es tener acceso a alguien experto en UX. En este caso Jaime y yo teníamos la idea preconcebida de como queríamos hacer el visor de eventos, pero una conversación de unos 10/15 minutos con Esther Moreno (experta en UX de kaleidos) y hemos cambiado y simplificado la idea que teníamos. Nos hemos ahorrado un montón de trabajo innecesario y gran cantidad de software a mantener :-)
En Alea Soluciones, nos vendría muy bien contar con algún tipo de "UX as a service" para mejorar la interacción con nuestras aplicaciones, que aunque no es mala, si que se nota que está pensada por un grupo de programadores con buenas intenciones pero a los que nos faltan conocimientos avanzados de UX y de diseño. Concretamente en mi caso, se nota mucho que siempre he trabajado en procesos de backend.
Además del visor de eventos, estamos dándole un empujón a la fantástica biblioteca de asertos expects que usamos al hacer TDD en python.
Está biblioteca creada por Jaime nos permite crear aserciones en los tests al estilo rspec y aunque es muy potente, Jaime tenia algunas mejoras pendientes que no estaba pudiendo llevar adelante. Así que mejor ocasión que la piweek para darle un poco de cariño.
En esta ocasión hemos comenzado por un cambio interno de diseño para mejorar los mensajes generados cuando los asertos no se cumplen. Este cambio que puede parecer menor, en realidad es muy importante puesto que en este tipo de utilidades los mensajes son los que ayudan al desarrollador a identificar el problema lo antes posible, por lo que sucede como con los lenguajes en que los mensajes de error pueden ser una diferencia significativa en su facilidad de uso...
Esto es lo que han dado de si los dos primeros días de piweek... seguiremos informando
1 comment:
Respecto al tema de UX, tengo la sensación de que por narices tiene que venir algún experto (de afuera) de UX.
Para mi, con dicha actitud, no se valora ni incentiva que cualquier miembro del equipo pueda meterse en dicho ámbito. Por ejemplo: como tiene que se algún experto en UX, pues pa'qué me voy a meter :-(
Aclaraciones:
- No lo digo por mi.
- Pienso que tenemos compañeros si controlan algo de UX.
- Si estoy de acuerdo que vendría bien alguién que controle más, para que eche una mano de vez en cuando. Pero esto no implica pensar siempre en que tiene que venir alguien. Se puede aplicar lo mismo para código backend
Guay respecto a la piweek
Post a Comment