PyConAr 2017

pycon-1.md

PyConAr 2017 - Día 1

El fin está cerca

Hernan Lozano Cima - @hernantz

Material adicional

Uno de los mayores problemas que se suele tener con cualquier lenguaje de programación es manejar fechas. Esto no necesariamente es un problema del lenguaje (aunque a veces sí, como en JS hasta que salió moment).

¿Por qué no estandarizar el calendario? Sencillamente porque hay factores económicos y sociales que hacen que no pueda existir un calendario. Un intento de hacerlo fue el International Fixed Calendar.

Problemas al manejar fechas

• El tiempo no es continuo, dado que en ocasiones las regiones cambian de hora por regulaciones gubernamentales o motivos económicos (ej. horario de verano)
• Los países no siempre tienen las mismas horas.

Timezones

Los timezones definen una zona y un offset respecto a un punto de origen, que se conoce como UTC=+00:00, que sería el timezone por default.

Existen bases de datos de timezones (zoneinfo) que cada uno maneja en función de sus necesidades y la criticidad de mantenerlas actualizadas.

Herramienas en python

En python, la herramienta "maestra" para manejar timezones es pytz

Para poder usarla, es necesario tener en claro que hay dos tipos de fechas en python:

• naive: sin datos de timezone
• aware: con datos de timezone

Siempre se recomienda trabajar con fechas aware (nunca se sabe cuándo podemos necesitar esa información).

Para poder trabajar con fechas que pueden estar en distintas timezones, es necesario saber que hay dos operaciones básicas:

• localize: definir el timezone de una fecha.
• normalize: pasar fechas de disintos timezones a un único timezone (en general UTC)

Problemas más puntuales

• ¿Qué pasa si trabajamos con horarios de verano y caemos en un horario que se repite? (Ej, a las 21 se retrasa una hora el reloj, entonces tenemos la hora 21 de antes de cambiar el horario y la hora 21 posterior a cambiar el horario). Para eso , podemos decirle a una fecha si es o no perteneciente a un período en el que se ahorra la luz (is_dst)
• Para no llegar a fechas inexistentes (ej, se adelanta una hora y caemos en el horario que se adelantó), usamos normalize sobre todas las fechas
• No usar replace para cambiar tz

Casos en los que el manejo de fechas es importante

• Calendarios
• Aerolíneas
• Scheduling, fechas recurrentes
  • dateutil: rrule (abstracción del manejo de fechas)
• Consultar por "el día de hoy": como "hoy" varía según el tz del usuario, es necesario estandarizar. No es lo mismo el "hoy" de Holanda que el de Argentina, por ejemplo, para saber los estrenos del día en Netflix
  • Uso de datetime.combine para no poner máximos y mínimos hardcodeados
• Filtros del tipo "antes/después de"
• Alertas, reminders, eventos recurrentes (próxima ocurrencia)

De .py a PyPI

Matías Bordese - @mbordese github

Material

• el-ega: resultados de futbol con python
• presentacion

Distribución de código python

• libs (esto es lo que nos interesa en esta charla)

• apps

• servicios

• PyPI.org: nueva interfaz de PyPI

• Package indexes on-premise: devpi, localshop

Formatos de paquetes

• source (.tar.gz), archivos y metadata para generar un paquete built
• built (.whl), todo lo necesario para poder ejecutar el paquete (con dependencias incluidas)

Requisitos para empaquetar

• pip
• setuptools
• wheel
• twine (para subir un paquete por https, no usar el upload de setup.py que lo hace por http)

El archivo setup.py de cualquier paquete llama al setup de setuptools, que es el que genera un paquete. Para saber qué parámetros se necesitan, consultar la doc de setuptools.

• Entrypoints: ejecutables disponibles en el paquete en base a una función del mismo. alias=modulo:funcion
• El archivo MANIFEST.in agrega archivos extra al paquete, que no son de python (documentación, etc). Sólo afecta a sdist (para el built, incluir en package_data del setup.py)

Sugerencias para distribuir una lib

• No freezar dependencias del paquete. Definir versiones mínimas
• Excluir los tests
• Mantener un versionado definido
• Licenciar
• Incluir README
• Classifiers: categorias que catalogan el paquete (status de desarrollo, licencia, versiones soportadas de python, etc)
• Evaluar si conviene tener los parámetros del setup en un archivo aparte (no es muy adoptado)

Pasos para subir un paquete

1. Probar localmente
2. Testear en staging de PyPI (ojo que no tiene todos los paquetes de PyPI prod)
3. Release

Hay templates de la PyPA que sirven para mejorar el proceso de empaquetado de nuestro código

Micropython

Gustavo Angulo - @woakas

MicroPython es una distribución de python para microprocesadores. Es un subset de CPython, no tiene todo el core ni libs que no sirven.

Ventaja: conexión por puerto serial. Acceso a REPL, consola de python que permite ejecutar código directamente en el micro.

• Se puede actualizar programas remotamente, sin flashear a mano.
• Hay threads _thread
• boot: setup de cosas ajenas al programa
• main.py: archivo que tiene el programa que se ejecuta en nuestro micro.
• Soporta interrupciones aunque hay un poco de overhead.
• Maneja excepciones (!!)
• Soporta webservers, pero es poco usual que se use un micro para ello.
• Tiene un gestor de paquetes: upip
• Tener en cuenta storage: nuestro programa no puede ser muy grande.
• Tener cuidado con loops infinitos

Equipos para iniciar: Groove + MSU

pycon-2.md

PyConAr 2017 - Día 2

Procesando 2.5 billones de mensajes diarios en tiempo real con Python y ZMQ

Pablo Díaz Ogni geeks.jampp.com

La empresa compra espacios de publicidad en tiempo real

Problemas

• Requerimiento: menos de 100ms por respuesta
• Distribuido (instancias muy potentes)
• Disponibilidad de los datos en tiempo real (plataforma Machine Learning)
• Múltiples sistemas se nutren de la data que se evalúa (interacción de usuarios con sitios, ofertas por espacios de publicidad, etc.)

Arquitectura inicial

Bidders gestionados por un load balancer, la data agregada se pushea a los loggers, que son los que escriben la base de datos. El tema es que la data agregada tiene un cierto nivel de desactualización respecto a la emisión de los datos en sí, por lo que no es tan sencillo que la plataforma de ML pueda procesarlas.

Solución

Publisher/Subscriber

Publishers publican (pasando por un proxy) El suscriber recibe del proxy, entre ellos no se conocen

ZeroMQ - sockets on steroids. Para python, pyzmq (cython)

• No hace falta persistir la data para que los publishers o los subscribers interactúen con ella. Las suscripciones de esta manera son dinámicas y no se requiere infraestructura (como puede ser hostear un rabbitmq).
• Soporta múltiples patrones de comunicación y protocolos (en particular jampp encontró útil el modelo pub/sub)

El publisher envía mensajes sólo si hay un subscriber del otro lado, el subscriber recibe los mensajes y puede elegir a cuáles suscribirse. Ambos se conectan a un único lugar.

JAMMP hizo una lib sobre zmq para poder procesar las biddings.

• Cada server tiene bidders que se comunican mediante un proxy
• Los suscribers reciben data de esos proxies

Subscriber (client-side)

• Conexión al proxy indicando los mensajes a filtrar mediante prefijos.
• Reciben los mensajes en un thread, encolándolos y cuando se consultan dichos mensajes, se vacía la cola
• También se escuchan cambios sobre los prefijos que manejan los mensajes

Proxy

• Conexión de publishers y suscribers
• recibe de subscribers y responde a los publishers con los prefijos que deben usar en los mensajes que envían
• ping a pub y sub

Publisher (server-side)

• Arma los mensajes con el prefijo necesario

Filtros

Los filtros definen a qué querés suscribirte, ya sea por región o por tipo de mensaje (bid, click, imp, etc)

Lightning talks

Material LTs

Carlos de la Torre

• @py_litox: Searching for aliens / uso de openCV para detección de círculos en distintas zonas a través de imágenes satelitales (kilimo + machinalis)

Anatomy of a code review

Ola Sendecka - @asendecka

• Hay dos tipos de code reviews: una más formal (inspección) que es muy costosa, y otra moderna, que se realiza de forma constante y su objetivo es convertir pequeñas partes de source original en source aceptado, logrando que el equipo se mantenga pendiente de lo que está haciendo el equipo, sin necesidad de esperar a que un gran feature se resuelva "por completo".
• Problemas de no tener Code Reviews: asumir la culpa individualmente, hacer todo por cuenta propia, burnout innecesario. El código es del equipo, no una unión de esfuerzos individuales aislados.
• Es necesario que el review sea recíproco, en caso de que un PR reciba una modificación de un reviewer, puede que el autor del feature original no pruebe las modificaciones, entonces hay parte del feature que no es revisada.
• Una forma de evitar que esto suceda es hacer reviews mediante comentarios, que deben ser tenidos en cuenta por el autor de un PR e implementados en caso de que el equipo llegue a un acuerdo.

Checklist

1. Linter (block-merge si no pasa el linter). En python, flake8 o PEP
2. Claridad de responsabilidades: ¿Al leer el código se entiende cuál es la tarea de cada una de sus partes?
3. diff: ¿Qué cambió respecto al código anterior?
4. Side effects: conocer otras partes del código nos sirve para entender si una modificación puede impactar en ellas. Indicar side effects ayuda a que el equipo aprenda dónde pueden influir sus modificaciones·
5. ¿Qué hace el código? Si no entendemos algo, pedir al autor que aclare su idea antes de sugerir cambios.
6. Probar código localmente.
7. Modularización: si hay código muy largo, sugerir una forma de separarlo en pasos en el review.
8. Excepciones correctamente manejadas (no hacer except-pass :P)
9. ¿Globales modificados? Evitar mutables para constantes. Tener cuidado con valores inmutables para parámetros por default (Python gotchas)
10. Casos borde contemplados (hacer foco en condicionales, ciclos, fechas). Escribir tests para ellos.
11. Reemplazar ciclos indefinidos con definidos (esto es medio polémico, lo que hacía era loopear sobre el dominio y chequeaba si se cumplía la condición para cortar). Su planteo era que en producción una falla en esos ciclos terminan explotando de peor forma.
12. Descripción breve del PR: ¿Cuál es la motivación por la cual se debe agregar ese código a la codebase? ¿Dicha motivación está cubierta en el código?
13. ¿Hay código muerto? Eliminarlo de la codebase.
14. Chequear docs y licencia de libs de 3ros. ¿La elección de la lib es consistete con el resto de la codebase? ¿Está en mantenimiento?
15. Performance: balance entre eficiencia y claridad de código.
16. Seguridad: proveer la información necesaria y suficiente al cliente de nuestra app. Estar atento a actualizaciones, buscar vulnerabilidades.
17. ¿Falta algo? tests, caching, métricas, logging, docs

Influencia de las tareas de code reviews: 75% - 25% entre mantenibilidad y funcionalidad.

• Modern code reviews in OS Projects: Which Problems do they fix? Bacchelli - Bird

Más allá del código

Si bien es necesario tener la capacidad de poder mejorar el código, también hay que tener en cuenta:

• Entender el negocio (podemos hacer código técnicamente robusto pero funcionalmente incompleto)
• Revisar el código de gente más experimentada (sin miedo): útil para aprender y analizar cómo alguien con mayor expertise resuelve un problema determinado.
• Mejorar el ambiente de revisión (CI)
• Achicar PRs, para no caer en la clásica inspección.
• Dejar que el autor fixee las sugerencias, que la revisión sea un proceso iterativo.
• Discutir soluciones alternativas antes de un review. Las code reviews son una instancia tardía para proponerlo, especialmente para funcionalidades muy largas.
• Ser respetuoso al sugerir, cuidar el lenguaje. El feedback negativo puede generar mal ambiente entre los colegas, o molestar individualmente a tus compañeros (frustración, enojo).

pycon3.md

PyConAr 2017 - dia 3

Introducción a Machine Learning con Python

Rafael Carrascosa - Rafa_Carrascosa

Objetivo de ML: Construir funciones sin programarlas explícitamente

• input: ejemplos
• output: funciones

actores de ML: modelo - entrenamiento (fit)

Scikit Learn

Además de ser una lib, provee sugerencias para aplicar buenas prácticas en ML. Los algoritmos de ML consumen los datos en un formato especial. Cada dato es un feature.

• Vectores de números
• cad item es un vector
• cada feature es una posicion del vector
• Los distintos datos se codifican distinto. Esto parece error-prone, pero es la forma en que se decidió abstraer al algoritmo de ML de problemas particulares.
• Qué se puede codificar en un vector?
  • bool
  • numeros
  • enum
  • texto
  • imagenes (deep learning)
  • secuencias
  • para otros tipos, se suele codificar en alguno de los tipos antes mencionados

Una vez armado un modelo. se entrena (fit). Este es un proceso costoso en tiempo. Recibimos un objeto con el modelo entrenado. Luego de entrenado el modelo, se predice en base a vectores de features

Train - test

El algoritmo de ML no aprende para memorizar, sino para descubrir (generalizar). Sin embargo hay algoritmos medio "grises" que tienden a memorizar. Para evitar que el modelo memorice, Se suele partir el dataset: entrenamiento y verificación

Algoritmos

• Decision trees
• Logistic regression
• Gradient boosting
• SVM
• Naive Bayes
• etc

TODOS los algoritmos tienen una forma única de recibir datos, por lo tanto, no hace falta cambiar demasiado el código para cambiar el algoritmo.

La habilidad al trabajar en ML es elegir un modelo correcto, con features adecuados para resolver el problema.

Clasificaciones

• binarias
• multicluster
• regresion: (predicción numeros reales)
• aprendizaje no supervisado

Deep learning

• Es una rama de ML que propone modelos propios para las mismas tareas que resuelve sklearn
• Útil para trabajar con imagenes
• Implica un costo de recursos importante en caso de que se aplique a otros campos de investigación.
• Difiere de ML en que no hay modelos de black-box, los modelos se configuran a mano: son flexibes pero requieren que uno se involucre bastante en hacerlo.
• Encontrar la configuracion para los cuales la predicción tengan la máxima eficacia (hay algoritmos que lo resuelven)
• La habilidad en deep learning es determinar cuántos números forman parte de la configuración y cómo se usan para predecir.

Keras

• Popular para deep learning
• Soportada por google (!)

Fashion MNIST

• Identificacion de tipos de prenda
• 10 clases de objetos
• features == pixeles crudos
• imagenes de 28x28

Usar ejemplo MNIST con Keras para profundizar - ejemplos Keras

Reconocimiento de objetos en imagenes

Ariel Rossanigo - @ArielRossanigo

Problemas de computer vision

• clasificación: determinar qué tipo de objeto hay en una imagen
• localizacion: encontrar la ubicacion de un elemento en una imagen
• detección: identificar qué objetos hay en una imagen
• segmentacion: además de encontrar los objetos, determinar qué pixel pertenece a cada objeto (el mas complicado)

Solución "out of the box"

Tensorflow provee modelos que permiten detectar objetos (github.com/tensorflow/models/tree/master/research/object_detection), con tutoriales de uso y entrenamiento de un reconocedor de objetos.

Bloques

• clasificador de imagenes
• detector de regiones

Clasificador de imagenes

Redes neuronales

• Ejemplo: Tensorflow mnist

Técnicas de perfeccionamiento

Convolución en deep learning: aplicar operaciones algebraicas en base a un kernel para obtener features automaticos respecto a una imagen. Independización de la posición para detectar elementos.

Parámetros a tener en cuenta:

• filters

• kernel_size

• strides

• padding

• activation

• Pooling: reduccion del tamaño de la imagen, obteniendo features equivariantes (no importa la orientación, rotación y el tamaño del elemento a identificar). tensorflow y deep minist

capas de convolución y max pooling detectan los features por nosotros, luego se realiza la clasificación sobre el output de las capas anteriores.

Detector de regiones

• sliding windows: Detección de números en patentes.
  • Loopear sobre regiones para predecir sobre ellas  - problemas: tamaños distintos de los objetos, si se cambian los tamaños de las ventanas, hay más imagenes para procesar y más tiempo de procesamiento
• R-CNN
  • selective search para proponer regiones
  • AlexNet: SVM para clasificar
  • linear regression para mejorar el box
• Fast R-CNN
  • disminucion significativa del tiempo de procesamiento
• Faster R-CNN
  • La detección de regiones pasa a computarse luego de definir los features
• SSD - Single shot detector
  • Gran red neuronal
  • Detección de imagenes en tiempo real (de 7 FPS a unos 50 FPS)

JupyterLab

Damián Ávila - @damian_avila

Desarrollador en Anaconda, contribuye al proyecto Jupyter

• blog
• github

Arquitectura Jupyter notebook

• Notebook app, el frontend que genera notebooks
• Kernel, procesos independientes que permiten correr código en un lenguaje de programación
• Documentos, artefactos autocontenidos que representan lo que hemos hecho (lo que solemos llamar "el notebook")

Componentes:

• Manejador de archivos
• Notebooks
• Terminales
• Editor de texto

Problemas

• necesidad de abrir muchos tabs para manejar componentes en simultáneo
• js desactualizado
• dificil de customizar

Jupyter Lab

Jupyter Lab es el nuevo cliente de jupyter, que se conecta al mismo notebook server que jupyter notebook.

• js moderno: npm, typescript, phosphorJS (herramientas para layouts dinámicos y performantes)
• diferenciación de modelos y vistas
• extensible (plugins/extensions)
• APIs publicas y privadas definidas y separadas
• Diseño, contrataron a diseñadores para mejorar la experiencia de la plataforma.

Sacan una beta (1.0) para principios de año que viene. La idea es deprecar el notebook viejo.

Features

• Layout customizable
• Dispoinibilidad de componentes en una misma ventana en el browser
• Configuración de layout persistente
• Drag & drop entre notebooks (!)
• Visualizar distintas secciones de un notebook en tabs
• Paleta de comandos para ejecutar acciones (con buscador). Keyword shortcuts configurables
• Settings: themes
• Se puede crear una consola para un editor de texto, se selecciona codigo de un .md y la consola lo ejecuta (!)
• Previewer de md
• Modo zen
• Visualización de otros archivos (png, geojson, csv, etc)
• Colaboración en tiempo real (con drive)
• Desktop app (electron)

Redes neuronales con Keras y Tensorflow

Juan Pedro Fisanotti - @fisadev

• github

Redes neuronales

Técnicas para evitar overfitting

• dropout: técnica para que la red no memorice de más (overfitting). Consiste en apagar conexiones de forma aleatoria.
• regularización de pesos: castigar pesos muy grandes.
• data augmentation: Inventar datos a partir de los existentes (tweaks a los datos base). Además de overfitting, salva el problema de datasets chicos.

Convoluciones

Alternativa para armar conexiones entre neuronas. En imagenes, identificar objetos en secciones de la imagen.

Keras en redes neuronales

• Deep learning == buzzword para redes neuronales profundas
• Keras es una lib para crear y entrenar redes neuronales
• Corre sobre TensorFlow o Theano
• Soporte para GPU (Nvidia) de forma transparente

Keras define las redes, tensorflow realiza los calculos, en caso de no tener aceleramiento, directo por CPU; en caso contrario corre por GPU mediante cuda + cudnn. La instalación de las herramientas par GPU es medio complicada, si bien hay cosas de docker, necesitamos los drivers para interactuar con nuestra GPU

De scraping a API

Agustín Benassi - @abenassi @datosgobar

github: datosgobar - abenassi

Página web datosgobar

Generación de bases de series de tiempo en organismos públicos - articulo

• Las entidades públicas necesitan contar con metadatos obligatorios, además se agregan campos adicionales (por parte del ministerio de modernización): specialType specialTypeDetail
• Hay un formato csv estándar mediante el cual cada organismo debe exponer sus datos, si los cumple, el proyecto de datos abiertos puede brindar una API.
• El scraping o la normalización no siempre es posible (ya sea porque el equipo de desarrollo de los organismos no tiene tiempo o bien porque no hay gente capacitada para hacerlo), para eso se realizó un trabajo con cada organismo para lograr que se acerquen a poder brindar sus datos de series de tiempo.
• Flujo de trabajo:
  1. metadatos en excel (a scrapear), scraping devolviendo JSONs en base a excels
  2. ETL (apertura y compilado)
  3. CSVs con datos, data.json (sin scraping), compilado
  4. ETL (db de la API)
  5. API

Como el scraping es riesgoso, en ocasiones se habla con los organismos para indicarles qué problemas tiene la forma en que exponen sus datos (los excels no siempre son estructurados)

API

Permite consultar time series disponibles en formatos diversos (json, csv). Próximamente en producción. Elastic search indexa resultados, para no calcularlos on the fly.