Inquietudes, recursos y un salto al vacio

Recursos, inquietudes y un salto al vacío

Si tuvieras que elegir una tecnología en la que especializarte, es más o menos como un salto al vacío si no tienes en cuenta tus inquietudes. Como programador me he sometido a continuas reflexiones sobre dónde debería especializarme, muchas más de las que me hubiera gustado. Estar en momentos donde te cuestionas tus propios conocimientos y las decisiones que has tomado hasta el momento no es 100% beneficioso siempre, ya que te resta dedicación al estudio de tu campo para estar buscando las alternativas que el mercado demanda o que tus inquietudes necesitan.

Seguramente, si no eres de la comunidad de Rails o de Ruby, no habrás estado siguiendo la última polémica surgida con las altas esferas de los desarrolladores de Rails. No te preocupes, te hago un mini resumen. Existen muchas opiniones sobre las bondades y limitaciones de Rails en la propia comunidad, pero la corriente más crítica es la que mantiene la idea de que el framework fue desarrollado por DHH para construir Basecamp y, que todo va orientado según las necesidades y criterios de DHH para su proyecto. En esta línea, muchos desarrolladores terminan dejando la comunidad por no estar en sincronía con las decisiones que se toman, siempre con la idea de que éstas están sujetas al ideal en cuestión. La última polémica la generó Piotr Solnica (si no lo sigues, ya estas tardando) con un artículo en su blog que generó mucha polémica en la comunidad: My Time with Rails is up.

*   *   *

Polémicas a parte, Piotr planteaba algo que todo programador nos pasa a menudo en nuestra vida profesional: ¿Estamos usando la mejor tecnología, los mejores recursos? Obviamente muchos puristas dirán que no importa la herramienta sino el mecánico, totalmente de acuerdo. Pero es posible que muchas de las paredes que nos encontramos en nuestro día a día se deban a que estamos usando una herramienta que no concuerda con nuestra forma de ver las cosas, de buscar y plantear las soluciones.

Para que te hagas una idea, voy a plantear 3 escenarios. El primero mi background actual, dónde estoy trabajando. El segundo, con lo que estoy jugando a ver que puede pasar al primer escenario y, por último, las herramientas y tecnologías que me gustaría que pasaran a los estados anteriores.

Mi background actual

Bueno, si me conoces o has leído algo escrito por mí en redes sociales, sabrás que soy desarrollador de Ruby y Ruby on Rails. Trabajo con bases de datos relacionales la mayor parte del tiempo pero me apoyo mucho en NoSql como Redis. Me peleo a diario con frameworks de Javascript como jQuery y últimamente, con ReactJS que está entrando tímidamente en este paso (y me alegro).

A parte de las herramientas y las técnicas que uso a diario, éste es mi estado actual. No quiero ponerme pedante con clean code y estas cosas que más que unos skills las considero un must.

¿Con qué estoy jugando?

MongoDB y ReactJS son los dos juguetes más predominantes que tengo. El primero ya lo llevo usando un tiempo pero no consigo hacerlo pasar al paso anterior por diferentes motivos. El primero es que nunca me lo HAN requerido en los puesto en los que he estado y, el segundo, el no haber tenido la oportunidad de trabajar con más compañeros expertos en este sistema. Es cierto que lo incluí en la última fase de Sociack en producción, pero sigo pensando que fue muy amateur y por ello, no lo cuento.

ReactJS se encuentra a caballo entre este y mis herramientas de trabajo, te explico por qué. Hace 4 semanas empezamos a usarlo en mi empresa (KitmanLabs), pero iba de segundo de abordo en este proyecto. Mi background es más de Backend que de FrontEnd y mi compañero (Michael)  es lo contrario, mis tareas se enfocaban a “hacer la cama” para que él se centrara en ReactJS y D3. Pero no por ello me quede sin jugar :). Creé mi componente y ayude a mejorar los que implementó y, tengo que decir que la vida en componentes esta muy molondria.

¿Con qué me gustaría jugar?

Aprovechando que estoy metiendo medio pie en ReactJS, siempre me ha interesado poder desarrollar mis proyectos con su versión en dispositivos móviles. Aprovechar ReactJS para crear componentes usables en Web y móvil a la vez va a ser algo que, más temprano que tarde, va a llegar.

La rama Data Science. Se está poniendo cada vez más de moda tener a un científico de datos cuando tu aplicación coge cierto volumen de usuarios y de datos, para que esta persona empiece a explorar caminos de explotación de estos datos. Me interesa por tener una base muy teórica, por las posibilidades que ofrece en una época en la que las API’s están más presentes que nunca (y menos que mañana) y en la que aún estamos en pañales en esta rama. Trabajar con macro conjuntos de datos para sacar patrones es algo que me apasiona pero, a su vez, me aterra por no saber aún que puerta es la que me llevará a adentrarme en este campo con el añadido que Ruby no tiene cabida (aún, echa un vistazo al proyecto 3×3) en el sector.

*    *    *

Si eres programador, te sentirás más o menos identificado con esta lista de deseos. Si no lo eres, seguro que en tu sector tienes el gusanillo de probar nuevas tendencias o técnicas que están siendo muy utilizadas o en auge. Es una constante en nuestras carreras.

Para enlazar ambas partes de mi artículo, planteo la duda: como Piotr en su artículo (a parte de roces ideológicos), ¿están nuestras herramientas y recursos en concordancia con nuestras inquietudes? Si quiero desarrollar cosas para analizar datos, debería estudiar R y/o Python o Julia. Si me gustan los dispositivos móviles, ¿por qué no empiezo con IOS o Android? ¿Me irá bien con React Native?

El tiempo es limitado y hay más cosas que el trabajo en la vida, la gestión del tiempo para una buena conciliación familiar/social y profesional es un reto en sí. Así que todo con calma, paciencia y dedicación se puede solucionar. Pero no puedo ocultar que estoy impaciente por conocer cual será el próximo gran paso en mi carrera y si será en la dirección adecuada sabiendo cuales son mis inquietudes.

¿Cuáles son tus inquietudes? ¿Cuáles serán tus próximos pasos?

Prototipado

Prototipado: construyendo mejores aplicaciones.

Hace un tiempo que descubrí el prototipado como una nueva forma de documentar nuevas funcionalidades en un proyecto. No es un concepto nuevo para los desarrolladores pero es un nuevo paso en el flujo de trabajo para desarrollar aplicaciones.

Todo el mundo conoce la importancia de los usuarios en el proceso de desarrollo de nuestras aplicaciones. Son una de las fuentes para conocer si estamos construyendo una buena solución o vamos en el camino equivocado.

Otro pilar fundamental es el departamento de I+D. Normalmente, ellos no son gente con conocimientos técnicos y necesitan un punto intermedio para discutir cada detalle. Hasta ahora, contamos con algunas técnicas y procedimientos que nos permiten encontrar este punto: BDD, designs y herramientas de desarrollo rápido.

Y finalmente, el tercer factor que influye en el producto es el equipo de desarrollo. Aquí me encuentro yo. Necesitamos conocer los puntos críticos que nos encontraremos y es nuestra responsabilidad dar una estimación, al menos intentarlo :). Por ello, la información acerca de la nueva funcionalidad necesita ser lo más exacta posible para reducir el margen de error.

*   *   *

El prototipado es ese punto intermedio. Necesitaos construir algo lo suficientemente cercano al diseño que ha sido validado y al resultado final, al mismo tiempo. Y necesitamos  que todo se pueda cambiar rápidamente y con la menor cantidad de recursos posibles. La solución necesita ser práctica también porque se la enviaremos a un grupo reducido de clientes para explorar cómo la van a usar y obtener un valioso feedback de ellos.

En resumen, nuestro prototipo necesita ser:

  • Práctico
  • Representativo
  • Dinámico

¿Cómo lo haremos? La respuesta es: FrontEnd. Si piensas cómo es el proceso de fabricar un coche, el primer paso es el motor, la transmisión, las ruedas…Después el chasis y finalmente las cosas para conducir y demás. ¿Y si lo hiciéramos al revés? Crearíamos en primer lugar el chasis y todo lo que el cliente necesita para hacer un uso real de nuestro coche. Podemos validar la experiencia del usuario con el diseño y nosotros (el equipo de desarrollo) conoceríamos  muchos detalles como el espacio para el motor, la distancia con respecto al suelo, la aerodinámica y más detalles críticos y prácticos para nosotros. Éste es el concepto de prototipado.

*   *   * 

Las claves para crear buenos prototipos son encontrar exactamente el punto intermedio entre el diseño y producción. Por esta razón, necesitamos centrarnos solo en la interfaz con el usuario usando la tecnología que usaremos en la interfaz pero con datos de prueba.

Un ejemplo. En mi empresa (KitmanLabs), estamos usando ReactJS y Highcharts para crear gráficas geniales. Nuestro Backend es Ruby on Rails pero eso no es importante para el prototipo. Tenemos un proyecto publicado específicamente para nuestros prototipos usando datos de prueba para simular casos reales. Como un entorno de pre-producción (staging), podemos acceder a la plataforma de prototipos para visitar a nuestros clientes y discutir con ellos las nuevas funcionalidades y descubrir si serán útiles e importantes para ellos.  El prototipo sigue los diseños aprobados y usa ReactJS y Highcharts. Podemos modificar cualquier cosa rápidamente porque la parte más compleja es cómo procesamos los datos antes de mostrarlos en la interfaz. Después de ajustar el prototipo con el feedback de los cliente, recibir la validación de los departamentos de diseño y producto, sólo tenemos que crear el proceso de backend usando el mismo código que en el prototipo en la interfaz final, porque solventamos cualquier problema que apareció al representar el diseño aprobado. Ese el punto intermedio.

Espero que este artículo te sea útil, si quieres hablar mas sobre prototipado, déjame un comentario o envíame un email. Quiero saber tu opinión y experiencias.

Por cierto, estamos contratando :)

English version

find_each: accediendo a los datos por lotes

Find_each es el método que permitirá las consultas en lote para base de datos desde Ruby on Rails. Seguro que como cualquier mortal (desarrollador de RoR, of course) en alguna ocasión has planteado la consulta:

> MiModelo.all.each do |instancia| …

Es una mala práctica pero es una solución que a todo hijo de artesano se nos ha ocurrido en algún momento. Siempre es recomendable limitar la petición de datos de una tabla, sobre todo cuando esta sobrepasa con creces los registros de una tabla digamos que “normalita” ( < 10.000 registros). Empezamos a acusar un rendimiento bajo para accesos a la base de datos. Find_each es tu solución. Este operador de loop permite acceder a la base de datos por lotes. Veamos su uso en un ejemplo:

Suponemos que el modelo MyUsers es de 1 millón de registros (si somos la leche)

> MyUsers.all.each do |u| p u.name end #Mostramos el nombre de nuestros usuarios

Ineficiente como ella sola (trabajamos con un array en memoria de 1M de elementos). Veamos una solución con find_each:

> MyUsers.find_each(bacht_size: 1500) do |u| p u.name end

find_each va a acceder a la base de datos 1M/1.5K veces solicitando 1.5k de registros, ahora trabajamos con arrays de 1.5K elementos. Es decir, find_each es una combinación del uso de limit en nuestra consulta y un paginador. TACHAAN!!

Aquí os dejo la documentación sobre find_each en Apidock