Instalaciones Interactivas - Hugh Kennedy @hughskennedy
Node puede servir de "glue" para diversos inputs y outputs:
- Robtótica: nodebots
- Audio
- web-audio-analyser: Analiza audio en tiempo real (por ejemplo, desde un micrófono)
- lopp-drop-app: MIDI looper, modular synth and sampler app
- LeapJS: Módulos para detección de movimiento
- Ectoplasmid Movimiento + webGL + Sonido utilizando Leap. Demo (hace falta el aparatito :P)
Evolución del lenguaje - Mathias Bynens @mathias
ES6 Incluye ciertas herramientas para contemplar caracteres unicode "astrales", que son aquellos cuyo código está en el rango [U+010000..U+10FFFF]
. En particular se habló sobre el uso del unicode flag en las expresiones regulares.
JS usa dos caracteres para representar símbolos astrales, entonces algunas cosas no salen como se espera (ejemplo, calcular el largo del símbolo literal)
- No se permiten escapes innecesarios de caracteres.
.
toma astrales usando el flag- Los cuantificadores matchean correctamente si se trabaja con el flag
- Uso de rangos sobre astrales
- Nuevos escapes de clases de caracteres, contemplando astrales
- El ignorecase en ES6:
\w
y\W
pueden no ser disjuntos - Se puede usar en el HTML pattern attribute
- Para browsers viejos hay que usar un transpiler si se quiere usar patterns con regex unicode. Regexpu
En el futuro se quiere incluir escapes unicode, como \alphabetic
\decimal_number
Notas varias sobre el tema en su sitio personal: mathiasbynens.be
El código es dato y viceversa - Hernán Rajchert @sherman3ero
- Stack buffer overflow exploit
- Category Theory for JS Programmers
- codemod: herramienta para refactoring de código
Es preferible que una solución sea precisa respecto al resultado obtenido. a que haga las cosas muy bien, pero que de vez en cuando pifie fuerte. ¿Hasta qué punto confiamos en el código de un módulo?
- El código explícito permite saber qué está pasando y tomar medidas correctivas que se adapten a nuestro caso de uso en caso de ser necesario. Con los módulos a veces no es tan sencillo.
- Ejemplo ilustrativo: con gulp programamos nuestras tasks, mientras que con webpack configuramos, pero la librería hace el trabajo.
Ethereum for node devs - Raúl Pino @p1nox
- ¿Qué es Ethereum? Algo como los bitcoins
- Ether es criptomoneda
- Blockchain: La base de datos distribuida que guarda las transacciones sobre ethereum.
- Smart contract: El protocolo que trasmite la info de las apps ethereum hasta la plataforma (se programa en solidity)
- EVM (Ethereum Virtual Machine): Ejecuta los smart contracts
- DAPP: Apps descentralizadas -> clientes del backend descentralizado
- Las transacciones usan gas, pero las consultas no
Microservicios - Erich de Souza Oliveira @Oliveira_Erich
Reactive manifesto:
- Tiempo de respuesta constante y veloz
- Tolerancia a fallas
- Elasticidad en función del tráfico del servicio
- Pase de mensajes
Para hacer microservicios en node:
- Router
- Inmutabilidad
- Módulos / namespaces
- Plugins (métricas)
Studio: Herramienta que brinda transparencia en la escalabilidad horizontal de un microservicio. Muy útil para tomar métricas. Para el clustering se usa broadcast si estamos trabajando en un ambiente "local" y Redis en caso de trabajar en cloud.
APIs HTTP escalables - Damián Schenkelman @dschenkelman
- Validación
- JSON Schemas para inputs
- Errores descriptivos para los devs: Status code + mensaje
- Documentación
- Automatizada
- Descripción detallada: no dejar detalles de su correcto uso a la imaginación del usuario
- Soporte hacia atrás: los usuarios de la API tienen que saber si una actualización de la misma tiene cambios que afectan a su aplicación. (se mencionó algo sobre una migración de mongoDB a elasticsearch, pero no tomé apuntes sobre ello)
- Control de acceso: Basandose en pruebas de stress, blacklisting a jwts específicos, límite en el consumo de la API - limitd.
Para esto puede usarse ratify, que es un plugin de hapi para validar inputs mediante JSON schemas y generar documentación de la API automáticamente en swagger
Communication vulnerability - Sharon Steed @sharonsteed
Memory Profiling for mere mortals - Thorsten Lorenz @thlorenz
- Los leaks en JS surgen cuando guardamos referencias a cosas que no necesitamos más.
- Surgen dificultades cuando guardamos cosas en acciones que se repiten mucho durante la ejecución de nuestros programas. Ejemplo: Si surge un error en una conexión y no se cierra la misma.
- devtools permite tomar snapshots del uso de memoria de un proceso
- Es recomendable no utilizar funciones anónimas, para poder identificar candidatas a generar leaks de manera más sencilla en el stack trace.
- En ES6 se usa mucho las arrow functions, así que hay que usarlas con cautela, porque no se pueden nombrar :)
- Recursos sobre la performance en V8: v8 perf
- Algunos flags útiles para npm
- --expose-gc
- --always-compact
- --inspect (usa devtools)
Ambient data - Anton McConville @antonmc
- Usar contenido del ambiente para obtener info sobre decisiones a tomar en el cotidiano -> contextual computing
- iBeacon
- Bluemix.net
Now & Next - Guillermo Rauch @rauchg
- Trabaja en zeit.co
- Sitio: rauchg.com
- now permite tener un "localhost" en cloud
now(src) -> build -> cloud & scale
. Elsrc
puede ser un dockerfile, un package.json o contenido estático.- los uploads pueden ser compartidos asignando un alias.
- next Framework para montar sobre React sin entender muy bien como funciona React. Tiene algunas cosas interesantes.
ndR: (después me distraje con el acento y no llegué a anotar las cosas que dijo sobre next)
On writing firendly documentation - Tracy Osborn @limedaring
- Escribir para el otro -> ¿Qué necesita saber el lector?
- No excederse en formalidades al escribir documentación
- No utilizar referencias culturales, dado que puede confundir a un lector que no esté familiarizado con ellas.
- Los términos técnicos deben ser explicados (no todos saben qué significan)
- Si no queremos/podemos explicarlos, podemos usar links.
- Enseñar, no decir -> teach, don't tell
- Los readmes y tutoriales, son introductorios, sirven para dar un quickstart al usuario interesado en un proyecto. Para usuarios avanzados, está la documentación. No hay que esperar que un usuario principiante lea una documentación completa antes de utilizar algo.
- "Readers have different backgrounds and experiences than you"
Node on the desktop - Felix Rieseberg @felixrieseberg
- Electron: apps desktop en node
- Levanta procesos similares a los de node. Hay uno principal y varios renderer que se levantan cada vez que surge una nueva pantalla (¿Por eso Slack es tan pesado?)
- Se pueden capturar navegaciones, como por ejemplo, cuando se hace un drag de un file al browser de la app electron.
- IPC: Inter process communication. Permite comunicación desde el proceso principal hacia los renderers
- Menúes de aplicación (barra de herramientas) -> pueden construirse a base de JSON y todas las apps vienen con opciones predefinidas.
Kill all humans (automation) - Stephan Bonnemann @boennemann
Muchas cosas triviales suelen consumir nuestro tiempo de trabajo, dado que los bots son mejores que nosotros haciendo cosas triviales, es mejor que nosotros nos dediquemos a automatizar y que ellos hagan el trabajo trivial
- GreenKeeper: Chequeo de actualización de dependencias automatizado
- Metadata en releases ayuda para que el usuario sepa si debe updatear o no
- FIX
- FEAT
- BREAKING CHANGE
- Semantic release - herramienta para publicar paquetes automáticamente
Internet of Peers - Mathias Buus @mafintosh
- dat.js Transmisión descentralizada de datos
- El problema con P2P es que necesitamos conexión entre clientes, lo cual suele ser difícil debido a los firewalls. La conexión a servers suele ser más trivial.
- UDP -> Stateless
- La forma de permitir que los clientes se conecten entre sí el utilizando hole punching que permite saltar firewalls
- A se comunica con B con el server como intermediario. Pasa a estar validado
- B se comunica con A de la misma manera
- A puede comunicarse con B sin server de por medio
- Hay herramientas que permiten saber si un sitio es hole punchable:
- [p2p test] chequeo de conectividad en una red
- hypervision: TV p2p(proyecto en curso).
- discovery-swarm: Chequeo de clientes disponibles para conexión p2p
- Node security project: [nodesecurity.io]
- nsp: chequeo de vulnerabilidades en aplicaciones node
- retire.js: vulnerabilidades en front-end
- SSL labs: ambientes locales que utilizan SSL (no omitimos SSL en ambientes de desarrollo)
Se armó un panel de debate con 4 exponentes, se hablaron de varios temas. Entre otros que no se mencionaron en el resto de nodeconf están:
- React Native
- Isomorphic apps
Real World Electron - Feross @feross
Los slides están acá
- Colaborador de Standard JS y webtorrent.io
- Para shippear aplicaciones electron a producción hay que tener en cuenta varios factores
- UX: Barra de menú, widgets, items de menú, badges
- Desktop != web: no esperar mismo comportamiento
- 90% app compartida -> 10% de features específicos para plataforma
- Code Signing: Si una app no está firmada, puede surgir una alerta dependiendo del OS indicando que nuestra aplicación no es confiable. Este es un potencial motivo para espantar a nuestros usuarios.
- Apple Developer Program (MacOS)
- Symantec, Comodo (Windows)
- Las apps se firman usando paquetes de NPM
- Build: evitar compilaciones nativas (usar js principalmente)
- Versiones según plataforma
- 32bit MSI -> funciona en ambos
- Mac disk image
- deb 32bit
- deb 64bit
- zip 32 y 64, rpm (opcionales)
- Descarga: ofrecer al usuario la descarga apropiada para su OS. Para eso se puede usar arch, que detecta el OS del cliente en el browser.
- Updates: silenciosos (sin alertas). Tener cuidado con la seguridad, dado que si nuestra aplicación agrega un bug en este aspecto, el usuario podría no enterarse.
- Seguridad: usar HTTPS, no cargar contenido remoto (si alguien puede extenderse sobre lo último sería genial)
- Download performance
- No ensuciar con dependencias innecesarias
- Electron -> electron-packager para no incluir ciertos archivos. asar genera un único archivo de aplicación para distribuir la app.
- Startup performance
- No requerir (hacer requires) innecesariamente en caminos críticos de la aplicación
- Lazy loading de componentes que no se utilizan siempre (el ejemplo del botón de chromecast: cargarlo cuando se detectan dispositivos chromecast, pero no frenar el rendering de toda la pantalla hasta que la detección concluya)
- Catchear errores en tiempo de ejecución y segfaults (generando reportes)
- Métricas de uso: Telemetry o cualquiera que permita trackear instalaciones, descargas, etc.
Micro(HAPI)ness - Diego Páez @carax
Axiomas para construcción de microservicios:
- No hay MS privilegiados
- Comunicación uniforme en el ecosistema de los MS
- Composición
Desafíos al construir Microservicios
- Discovery: Los MS no deben conocerse -> para eso es útil p2p (distributed hash tables)
- Visibility: Salud del sistema -> Distributed health check
- Resiliency: Tolerancia ante el fallo de un MS -> Additive Deployments: Todo lo que se deploye no debe romper nada anterior, sólo agregar cosas.
Framework para desarrollo de APIs
- Orientado a configuración
- Reemplaza middlewares por request lifecycles
- Plugins para modularizar
- Comunidad amplia -> release notes con tips de migración
Kademlia: Protocolo comunicación p2p
- Scaffolder de servicios p2p
- DHT -> HAPI -> Plugins (código de servicios)
Hacking your Nintendo in JS - Mike Matuzak @mmatuzak
- intermezzOS: intro a la construcción de OS
- nesly-split: lee headers y permite extraer datos del rom
- nesly-meld: toma un rom y un sprite y los mergea
- nesly-sound: sonidos en 8bits para NES :)
- nesly-assembler: 6502asm en JS
Fun with WEBGL - James Halliday @substack
Siéntanse libres de agregar lo que quieran, me limité a observar :P
Algunas cosas utilizadas para la magia: