You are currently browsing the category archive for the ‘opinion’ category.

sHace dos semanas, en un grupo de Slack, preguntaron acerca de los conocimientos que debe posee un desarrollador front-end web. Luego de una acalorada discusión que levantaba pasiones, la mayoría coincidía en algunos puntos que me gustaría compartir en esta publicación. 🙂

Antesala

La crítica más fuerte vino con la pregunta acerca de “qué framework front-end X debería dominar un desarrollador” y la joya de la corona trató de “el valor de usuario que esta elección [del framework] genera”. Ambas tuvieron respuestas directas acerca del error de plantearse abiertamente esas preguntas, sin contextualizar.

Luego

Algunos comentamos en otro canal acerca de lo extraña de la pregunta y sobre nuestras experiencias entrevistando.

Las entrevistas en efecto son complejas. Tenemos que mostrar en unos 30 minutos para mostrar lo que podemos hacer. En ese tiempo, como entrevistador, eso es complicado asegurar que la persona tiene las habilidades que menciona. Principalmente porque no hay una única medida e incluso que no podemos esperar respuestas directas a preguntas abiertas. Si bien preguntamos sobre un tema específico, las preguntas del entrevistado son hechas a su discreción.

Desde ambas perspectivas, intentamos en esa charla e intentaremos ver en esta ocasión los temas que podríamos abarcar en el desarrollo front-end web.

Distracciones

No me parece que se deba hacer preguntas triviales como “qué es el box model” o “dime las diferencias entres ‘==’ y ‘===’ en JS”. Esto no nos dice mucho. Más que desear saber que sabemos HTML, CSS y JS, durante una entrevista esperamos demostrar que implementamos UIs, que construimos componentes visuales o que podemos usar utilitarios como underscore.js* y/o Lodash; por ejemplo:

  • Maquetar y manipular las interacciones de aplicaciones web conocidas como los sites de Spotify y Netflix, o las demos de Bootstrap y SemanticUI. (Los ejemplos tienen que ir contextualizadas a las habilidades y conocimientos que esperamos).
  • Implementar componentes visuales como un selector de fechas, un carrusel o un carrito de compras.
  • Codear funciones como clonar un objecto por profundidad o una función de rebote en eventos.

Ahora que comento sobre bibliotecas, algo que nos distrae del objetivo principal es pensar que necesitamos depender (y que las personas dependan) del último grito de la moda en frameworks para resolver una pregunta del entrevistador. Podemos preguntarnos el porqué reinventar la rueda si tenemos a jQuery, a React, a Angular y otros listos para producción. Obviamos lo evidente en nuestra profesión que tiene un cuerpo de conocimiento pequeño y cambiante: las tecnologías, los frameworks, las bibliotecas cambian con el tiempo y usualmente no hay que esperar mucho para ver esos cambios. Es más interesante ver cómo afrontamos los restos sobre los fundamentos sobre el desarrollo front-end que depender de declaraciones de alto nivel. Si no podemos responder esas cuestiones, al menos deberíamos explicar con detalles y razonar sobre lo que el framework o la biblioteca están haciendo internamente.

Debemos considerar que nuestras entrevistas se centren en la práctica y la codificación.

Entonces

Creo que es preferible iniciar con preguntas abiertas y dejar que el entrevistado se presente. Esa información nos ayudará a guiar la entrevista:

Generales

Es bueno saber cómo se desempeña con otras personas y ha visto que se maneja ante las situaciones que ha visto en sus equipos.

  • Qué es lo más interesante que ha visto en la implementación de su último proyecto.
  • Cuántas personas confirmaban su equipo.
  • En qué marcos de trabajo se ha desempeñado: Agile, Scrum, Kanban, etc.
  • Cuáles desarrolladores front-end de las comunidades conoce.
  • Ha oído de la “Gangs of four”.
  • Cuál es la diferencia entre pruebas unitarias y pruebas de integración.
  • Cuáles son los tipos de ataques web más usuales.
  • Que es duck typing.

Javascript

Las expectativas del nivel del desarrollador están respecto al conocimiento del lenguaje. Tendríamos que contemplar

  • Contexto de ejecución, especialmente alcance léxico y clausuras.
  • Hoisting, funciones y alcance de bloqueos, y expresiones de funciones y sus declaraciones.
  • Binding (especialmente call, bind, apply y el this léxico).
  • Prototipos de objetos, constructores y mixins.
  • Composición y funciones de órdenes superiores.
  • Delegación de eventos y bubbling.
  • Coerción de tipos (typeof, instanceof y Object.prototype.toString).
  • Manejar llamadas asíncronas con callbacks, promises, await y async.
  • Cuándo usar declaraciones de funciones y expresiones.

DOM

Como manipular el DOM es importante y es donde es más complicado hallar respuestas cuando dependemos de jQuery o sólo hemos desarrollado con React y Angular.

  • Seleccionar y hallar nodos usando document.querySelector y, en caso de necesitar retrocompatibilidad, document.getElementsByTagName.
  • Navegación transversal vertical (Node.parentNodem Node.firstChild y Node.childeNodes).
  • Navegación transversal horizantal (Node.previousSibling y Node.nextSibling).
  • Manipulación (agregar, retirar, copiar y rear nodos en el DOM. Cómo cambiar el text de un nodo y alternar, remover o agregar un nombre de clase CSS).
  • Desempeño (usar el DOM es costoso en procesamiento cuando tenemos muchos nodos, deberíamos conocer sobre fragmentos del documento y cacheado de nodos.

CSS

Tenemos que conocer al menos acerca de la estructura de elementos de una página, cómo los selectores para descendientes directo o los descendientes hijos son usados para ubicar elementos y cuándo usar clases o IDs.

  • Maquetado (ubicación de los elementos junto a otros y su distribución en columnas).
  • Responsive design (cambiar las dimensiones de los elementos según el ancho del navegador).
  • Adaptive design (cambiar las dimensiones según break points).
  • Nivel de especificación (cómo calcular el selector y cómo afecta a los atributos en cascada).
  • Adecuado namespacing y nombrado de clases.

HTML

Saber qué tags de HTML representan mejor el contenido que estamos tratando de mostrar y conocer sus atributos asociados.

  • Marcado semántico.
  • Atributos de tags (como disabled, async, defer, o cuándo usar data-).
  • Cómo declara el doctype y qué meta tags podemos usar.
  • Acceso a elementos visuales, por ejemplo, un input checkbox tiene un área de respuesta (usando un label con “for”). También el uso de role.

Diseño de software

Al parecer se obvia este rubro o se cree que que pertenece sólo a los desarrolladores back-end (o de plano, se obvia en ambos). Usualmente involucra conceptos como MapReduce, diseño distribuido de stores key-value o conocimientos como el princio CAP y los rankings. No debería ser sorpresa preguntar sobre las arquitecturas front-end de las aplicaciones comunes. Aunque estas preguntas suele ser abiertas, como “diseñar un sitio como Path” o “cómo construiríamos un servicio de compras”.

  • Renderizado (en el cliente (CSR), en el servidor (SSR) y el renderizado universal).
  • Maquetado (si estamos construyendo un sistema con múltiples equipos, necesitamos pensar acerca de la construcción de esos componentes y si requerimos que los equipos sigan un marcado consistente para su elaboración).
  • Manejo de estados como la elección de un flujo unidireccional de datos o el binding de datos a dos vías. También tenemos que pensar sobre seguirá una programación pasiva o reactiva, y cómo los componentes se relacionan entre sí.
  • Flujo asíncrono (de los componentes para comunicación en tiempo real con el servidor. Nuestro diseño considerará XHR vs llamadas bidireccionales. Podemos considerar preguntas sobre el soporte a navegadores antiguos teniendo que elegir entre iFrames ocultos, etiquetas script o mensajes XHR; de no ser así, podría proponerse web sockets o eventos hacia el servidor (SSE).
  • Separación de responsabilidades (patrones MCV, MVVM y MVP).
  • Soporte a varios dispositivos (la elección entre si se desea la misma implementación para la web, web mobile y aplicaciones híbridas, o se desea implementaciones separadas. Un sitio como Path podría considerar tres columnas para la web y una columna para dispositivos móviles. ¿Cómo lidiar con esto?
  • Manejo de recursos estáticos (en grandes aplicaciones no se estila tener equipos independientes como dueños de su codebases, las que podrían tener interdependencias y usualmente tienen su propio pipeline para el realese de cambios a producción. Nuestro diseño debe considerar cómo se construyen los activos con sus dependencias (code splitting), cómo se prueban (unit tests and integration tests) y el despliegue, También, cómo manejar los activos de terceros mediante un CDN o en línea para reducir la latencia de la red.

(El diseño de software front-end considera tantos temas que merecen una atención particular.) 😉

Desempeño web

Es importante que podamos reconoces que nuestro diseño y código impactan en el desempeño de la aplicación.

  • Ruta crítica de renderizado.
  • Service workers.
  • Optimización de imágenes.
  • Lazy loading y división de bundles.
  • HTTP/2 y server-push.
  • Cuándo hacer búsquedas previas de datos y cuándo precargarlas.
  • Reducir el flujo del navegador y cuándo promover un elemento a la GPU.
  • Diferencias entre la estructura, la composición y el pintado en el navegador.

Estructuras de datos y algoritmos.

Este tema fue el que levantó más polvo. No obstante, comprender algo del tiempo de complejidad Big-O y la diferencia entre cosas como O(n) y O(nlog\,n) no hace pupa. Los SPAs están de moda y ayuda entender cosas como el manejo de memoria. Conocer las estructuras de datos y algoritmos más comunes harán nuestro software más simple y nuestra vida más sencilla.

Cultura general de la Web

Es de esperar que sepamos lo esencial de las tecnologías y paradigmas que hacen funcionar a la web.

  • HTTP requests (GET y POST con el manejo de cabeceras como Cache-Control, ETag, Status Codes y Transfer-Encoding, por ejemplo.)
  • REST vs RPC.
  • Seguridad (cuándo usar JSONP, CORs o políticas de iFrames).

Conclusiones

Ser un ingeniero o desarrollador web requiere conocer muchas cosas. Pero no es necesario pretender aprender todo es linealmente. No hay un curso o libro que nos convierta en gurús del front-end. Ayuda mucho mantener la mente abierta a aprender sobre las piezas de software más intrincadas del producto final que nuestros usuarios tendrán.

Adicionalmente a las habilidades técnicas, tenemos que poder hablar de nuestros proyectos pasados, describir las situaciones más interesantes y los problemas que hemos enfrentado.

Obviamente, en toda la conversación y en esta publicaciones hay áreas que no se han considerado. No he tenido la intención de hacer un cuestionario ni temario. Hay cuestiones que podemos considerar importantes durante una entrevista que no están listadas aquí.

Yah volveremos con cosas relacionadas a este tema pronto. Suerte a todos. 😉

Anuncios

   Hace un par de días un amigo, César Verde, compartía un artículo sobre la situación de la matemática en el Perú; en sus palabras: “Un estudio realizado por el investigador Alvaro Delgado, una de las razones por la que el Perú figura en último lugar en el último lugar en matemática, según el último examen internacional Pisa, se debe a que la mayoría de los estudiantes peruanos dicen: ‘si estudio matemática, no voy a conseguir enamorada’. En lugar de estar asociada con la solución de problemas, creatividad, construcción, ingeniería y afines, la matemática es vista como un obstáculo para la vida social.”

   Uno puede ver un panorama interesante y desolador, para un investigador social y para un espectador de nuestra sociedad, respectivamente. No me gusta la idea de “adaptar a la moda, actualizar la imagen” de los estudiantes de matemáticas. No obstante, la idea de ser sede de un evento matemático es una idea bastante antigua (incluso aplicada en ciertos contextos por pocas organizaciones), que si hubiera sido considerada por las personas pertinentes, no leeríamos artículos como el mencionado. (Supongo que es de poco interés para las estructuras sociales.)

   Pienso que el problema de fondo —y esto es estrictamente personal— es en parte un “proceso” que ha desvirtuado en nuestra sociedad la idea de un matemático. Si ya carecíamos de programas educativos en comunicación, arte, música, etc., era puro sentido común darse cuenta que con la matemática esto es peor; sino comparemos con la realidad japonesa, aunque hay mejores ejemplos, pero leí sobre ellos hace mucho, mucho, tiempo atrás: usando algún buscador web debe ser posible hallarlos.

   Personalmente, me ha costado saber qué es hacer matemáticas y, más aún, cómo hacerlas. Ni imaginar cómo estarán las personan que han tenido menos contacto con libros de (verdaderas) matemáticas.

   Es evidente concluir que usando las mejoras en redes de comunicación e internet podríamos mejorar la divulgación (incluso se podría diseñar redes basadas en ondas radioeléctricas y llegar a más lugares donde la internet no puede —algo que conversé con un ingeniero de telecomunicaciones del ejército, pero llegamos a la conclusión que requiere inversión civil). Sin embargo, sigue latente el “para qué aprender”. (Por cierto, estoy preparando una publicación para mi bitácora sobre algo similar respecto a la filosofía.)

   Sobre lo último, pongo un ejemplo que puede permitir extrapolar una posible solución (no digo una definitiva ni factible). Considera la realidad sobre los “realities” actuales: ¿por qué unos sujetos que arman torres con vasitos, que tienden a “lacearse” el cabello, que, en resumen, hacen lo mismo que una persona de su edad hacía en el colegio son considerados íconos para la mayoría de la juventud? (¿Es que serán mentalmente niños?) La respuesta más simple es que sucede esto por la falta de “personajes icónicos” en otros aspectos. Veamos: tres a dos décadas atrás, la gente joven quería emular al “cholo Sotil” porque era el “ídolo de multitudes”, y ese deseo de emularlo invocaba tener disciplina (no quiero decir que todo era bueno, pero, vamos, se entiende mi punto: quienes querían ser como él necesitaban mantenerse entrenando, no hacer desarreglos; una vida desordenada era inconcebible.).

   En consecuencia, creo que falta que los paradigmas de matemáticos sean reconocidos en sociedad y, para ello, es necesario poner seriedad en la aplicación de las matemáticas en nuestras profesiones, cuya formación matemática es deficiente en muchos de los programas de estudio (al menos en ingeniería) de varias universidades (este tema está harto tratado, así que no comentaré más sobre ello).

   Sólo para que lo dicho en el párrafo anterior no quede en simples palabras, pongo un ejemplo que sucedió en una reunión de ingenieros de software: imagina un “programador” que tiene que mostrar una “valoración” de ciertos productos en función de los votos positivos y/o negativos de los usuarios. Veamos cómo proceder:

  1. valoración = (votos positivos) – (votos negativos). El problema aquí es que si tienes un producto con 60 votos positivos y 40 negativos: tiene 60% positivo. Supón un segundo producto con 550 votos positivos y 450 votos negativos: 55% positivo. Esto ubica al segundo producto con valoración=100, pero únicamente 55% positivos, sobre el primer producto con valoración=20, pero con 60% positivos. Error.
  2. valoración = promedio de votos = (votos positivos) / (total votos). También es un error: supón un primer producto que tiene 2 votos positivos y 0 votos negativos. Supón un segundo producto con 100 votos positivos y 1 voto negativo. Esto pone el segundo producto debajo del primero. Error.

La respuesta adecuada a la situación es usar el límite inferior del intervalo de confianza de Wilson para un parámetro de Bernoulli, que está bien documentada, cuya implementación puede ser trivial (incluso se puede programar en SQL) si uno fija el nivel de confianza de antemano.

   El problema de fondo es que “los profesionales” cometen este tipo de “sutilezas” a niveles que uno podría imaginar que es imposible que ocurran (v.g., uno de los ejemplos es de Amazon), y, lo peor, se justifican invocando a la filosofía KISS. (No digo que sea un error seguir los principios KISS, pero es análogo a querer adaptar, por ejemplo, los principios del catolicismo a mis gustos, sólo para justificar mis pecados.)

   Finalmente, ¿qué puede hacer el estado? Evidentemente necesitan un faro, una persona cabal que dirija las tareas:

  • Recluta, recluta, recluta… con las condiciones adecuadas.
  • Rompe el concepto de exámenes y asistencia a clases.
  • Realizar proyectos aplicables y publicables.

Así dicho, parece pura cháchara. Pero es un resumen de la receta de Solomon Lefschetz, quien llevó a Princeton, y el Edificio Fine, a ser el Olimpo matemático en la pos-guerra. (Sólo para precisar, el proceso de Princeton empezó justo antes de la pos-guerra, pero fue en esta época cuando alcanzó su auge.)

   Ya veremos…

Categorías