Agenda:

• Clase 1: Introducción Sockets API. Modelo OSI, entornos de ejecución.Introducción a Python. Socket API para UDP. Ejercicios.
  • Descargar en Formato ODP / Formato PDF.
  • Código de ejemplo: ZIP.
• Clase 2: Socket API para TCP. Código de ejemplo y ejercicios.
  • Descargar en Formato ODP / Formato PDF.
• Clase 3: Multiprogramación, concurrencia, paralelismo. Syscall fork() y relacionados. Ejemplos de servidor multiproceso. Procesos vs. Threads.
  • Descargar en Formato ODP / Formato PDF.
  • Código de ejemplo: ZIP.
• Clase 4: Sockets asincrónicos. Modelo de trabajo, syscall select(). Ejemplos de código. Introducción a Scapy.
  • Descargar en Formato ODP / Formato PDF.
  • Código de ejemplo: ZIP.

¡Saludos!

El video dura media hora, pero a mí me gustó muchísimo, aprendí mucho. Mikah Scott es una genia, y se propone investigar cómo customizar el firmware de una lectora/grabadora de CD/DVD/Blu-Ray, para dominarlo por completo, empezando por el microcontrolador ARM que posee. Por ejemplo, moviendo el láser en la posición que uno quiera y dispararlo. Habla un excelente y puntilloso inglés, así que se le entiende palabra por palabra, sugiero que lo vean incluso para practicar su inglés técnico.

Es muy interesante cómo usa Photoshop para visualizar el contenido de un firmware (?!??!?! ¡nunca se me hubiera ocurrido!), y cómo usa IDA (este sí es más lógico) para interpretar el código binario.

Además, usa vusb-analyzer en Ubuntu para visualizar el tráfico USB dumpeado con usbmon o similares, por ejemplo snifeado de una máquina virtual.

Por último, usa iPython para hacer que el ARM y el resto de los chips con los que interactúa (mt1939, dsp) haga lo que uno quiera (todavía está en avance).

Es increíble cómo en el ámbito de seguridad se usa Python (lo confirmé en la Ekoparty en estos días).

Insisto, se aprende muchísimo viendo este tipo de videos: herramientas, técnicas, trucos y fundamentalmente cómo abordar estos desafíos.

Saludos

PyPy without the GIL – Armin Rigo:
PyPy has a version without the Global Interpreter Lock (GIL). It can run multiple threads concurrently. But the real benefit is that you have other, new ways of using all your cores. In this talk I will describe how it is possible (STM) and then focus on some of these new opportunities, e.g. show how we used multiple cores in a single really big program without adding thread locks everywhere.

Python Profiling – Amjith Ramanujam:
This talk will give a tour of different profiling techniques available for Python applications. We’ll cover specific modules in Python for doing function profiling and line level profiling. We’ll show the short comings of such mechanisms in production and discuss how to do sampled profiling of specific functions. We’ll finish with statistical profilers that use thread stack interrogation.

Making Apache suck less for hosting Python web applications – Graham Dumpleton:
It is not hard to find developers who will tell you that Apache sucks for running Python web applications. Is there a valid basis to such claims or have they simply been misguided by the views of others? This talk will endeavor to shine a light on the realities of and limitations in working with Apache, as well as the challenges in implementing the mod_wsgi module for Apache.

Using futures for async GUI programming in Python 3.3 – Dino Viehland:
In Python 3.2 a new feature was added for concurrent programming – futures. In Python 3.3 generators have been extended to allow returning from a generator with a value. In this talk we’ll show how these features can be combined to create a rich and easy to use asynchronous programming model which can be used for creating highly responsive GUI applications or easy async programming.

Kivy: Building GUI and Mobile apps with Python – Mathieu Virbel / Thomas Hansen:
This talk will introduce the Kivy project (http://kivy.org). Kivy’s mission is to make building graphical user interfaces on any device fun, efficient, and pythonic.
The talk will focus on giving attendees an overview of how they can use kivy to build exiting UIs and mobile apps.

Make More Responsive Web Applications with SocketIO and gevent – Luke Sneeringer:
An explanation of how to implement a socket.io server in Python to serve websocket requests from browsers.

El resto de los videos del evento, acá: http://pyvideo.org/category/33/pycon-us-2013

Dejo en este post el mío, no sin un dejo de «vergüencita», je… (encima todavía no lo vi):

Cualquier duda me pueden consultar o comentar este mismo post. Espero próximamente escribir más en profundidad de ciertos aspectos que me quedaron afuera de la charla.

¡Saludos!

Terminó la PyCon Argentina 2012, y con ella vienen semanas menos movidas (espero). Este post es para agradecer a la organización, Mariano, Juan BC, y a todos aquellos que concurrieron y compartieron conmigo este evento que tanto nos gusta a los fanáticos de este lenguaje de programación.

Además, tuve el placer de dar una charla introductoria del protocolo SPDY, que pretende reemplazar a HTTP 1.1, y que muy probablemente ya estés usando sin darte cuenta.

En definitiva, los slides de mi charla, «Introducción a SPDY, ¿futuro HTTP 2.0?» se pueden ver más abajo en esta página, y también se pueden descargar en formato ODP y PDF.

En cuanto tenga el video, lo pondré a disposición también.

¡Muchas Gracias PyConAr!

De ahí en adelante (dado que el desarrollo es abierto a la discusión en general) me dediqué a profundizar en él, entender sus ventajas (lo cual implica entender algunas cosas feas de HTTP 1.1 y la Web de hoy en día), limitaciones, y cosas que faltan implementar. Me apasionó el tema, tanto es así que lo propuse como tema de Tesis para mis estudios y hasta ahora vengo bien (bien con las promesas a mi Director, claro está :-P).

Mi idea era con este post abrir una serie de artículos para documentar lo que voy aprendiendo sobre este protocolo, que cada vez tiene más hype en la industria, tanto que Twitter y Google ya lo implementan en sus servidores (Facebook está en camino), mientras que Chrome/Chromium y Firefox (Opera se está sumando) también lo usan si está disponible.

Personalmente me puse a probarlo y a tratar de implementarlo usando Python, forkeando un proyecto que ya existía y arreglando los problemas más obvios que encontré. Todavía tengo todo el código «atado con alambre», no bien testeado, y no estoy seguro si funciona del todo (jua!), pero de ahora en más voy a tratar de mejorarlo y mantenerlo mientras pueda, además de dejar algún rastro por aquí y por mi trabajo de investigación formal.

En resumen, el IETF draft de SPDY está disponible acá; tanto parece estar movilizando este protocolo, que el HTTPbis Working Group, encargado de definir un futuro HTTP 2.0, se está moviendo desde hace un tiempo para discutir las propuestas de SPDY. Y esto recién empieza…

Les dejo un video del último Google IO 2012 que es un excelente acercamiento técnico al tema:

Saludos

Durante el Python Day se darán pequeños cursos y charlas relacionadas a este lenguaje, creando un espacio en donde cualquier persona interesada pueda acercarse para preguntar, aprender y experimentar con esta herramienta.

Python es un lenguaje moderno, sencillo de aprender pero muy poderoso en cuanto a la cantidad de aplicaciones en las que es usado profesional y académicamente: en sitios web, en juegos, aplicaciones de escritorio y en scripting en general, etc…

El publico al que nos dirigimos es de todos los niveles, pero estamos muy interesados en acercar Python a quienes solo lo conocen de oído o directamente no saben de que tipo de lenguaje se trata. Tendremos charlas especiales para ellos.

Con esta misma invitación damos por iniciado el Call For Charlas; aquellos interesados ya pueden proponer nuevas charlas y son bienvenidos los colaboradores y empresas/entidades interesadas en participar y auspiciar la jornada.

Cualquier duda o consulta, puede visitar la página del evento, o contactarse vía mail a pydaylujan@gmail.com.

El encuentro se llevará a cabo en el pabellón 400 de la sede central de la UNLu (ver página Cómo Llegar)

La entrada libre y gratuita (previa inscripción web), ¡los esperamos!

HTTPS es la manera de establecer conexiones HTTP pero seguras, en el sentido de que previo al diálogo HTTP estándar pero luego de establecerse la conexión TCP contra el servidor, se negocia entre los participantes una conexión/sesión «especial» entre ambos.  Allí se intercambian certificados con el fin de autenticar contra quién se «está hablando», para luego, si hubo éxito en la dicha comprobación, encriptar (o no) todo lo que va para el otro lado, tanto del Servidor al Cliente (generalmente un navegador), como del Cliente al Servidor.

Todo eso forma parte de SSL 3.0 (hoy TLS 1.0), y si bien se puede utilizar para cualquier conexión TCP (SMTP, IMAP, etc., lo pueden usar también), su uso más común se da cuando uno entra a su casilla de Webmail o su cuenta del Banco desde el navegador;  lo que sucede allí es que nuestro navegador autentica al Servidor, y si todo va bien nos muestra el famoso «candadito» e informa que la sesión «es segura». Ahora bien, en esos casos, el Banco o Webmail no nos autentica a nosotros como Cliente y deja que cualquiera se conecte a su página, ya que eso requiere varios pasos más (sería realmente engorroso que sea obligatorio).

Sin embargo, en nuestra vida de programadores nos solemos encontrar con necesidades del entorno que nos obliguen a esta situación un tanto extrema y bastante más segura: que tanto el Cliente que desarrollamos autentique al Servidor como que el Servidor autentique al Cliente, amén de que la conexión muy probablemente deberá estar encriptada. Esto nos permitirá asegurarnos que los Clientes (software) que se conecten a nuestro Servidor sean únicamente quienes queremos que sean (o casi).

Python, dentro del módulo httplib nos provee de la clase HTTPSConnection, que maneja y nos abstrae en varias de estas cuestiones de SSL/TLS y nos deja trabajar a nivel HTTP (una capa más arriba). Lo que hay que observar bien (y que recién en la versión 2.7 de la documentación apareció en rojo), es que esta clase aún cuando uno le puede pasar como parámetro los paths a certificados, en realidad no hace ninguna comprobación de validez del certificado que el Servidor exporta. Con lo cual, hay un potencial problema: que nuestro cliente mande los datos a cualquier lado menos a nuestro Servidor de confianza.

¿Y cómo se fuerza a que nuestro programa Cliente chequee el certificado del Servidor? Armé esta clase que extiende sólo lo necesario a HTTPSConnection, que funciona en Python 2.6.x y que me permite hacer eso.

Le agregué un ejemplo en la llamada a __main__ para mostrar cómo se usa:

#!/usr/bin/env python
#-*- coding: utf-8 -*-

import socket
import ssl
import httplib

class HTTPSClientAuthConnection(httplib.HTTPSConnection):
    """ Class to make a HTTPS connection, with support for full client-based
        SSL Authentication.
    """

    def __init__(self, host, port, key_file, cert_file, ca_file, timeout=None):
        httplib.HTTPSConnection.__init__(self, host, key_file=key_file,
                                                   cert_file=cert_file)
        self.key_file = key_file
        self.cert_file = cert_file
        self.ca_file = ca_file
        self.timeout = timeout

    def connect(self):
        """ Connect to a host on a given (SSL) port.
            If ca_file is pointing somewhere, use it to check Server Certificate.

            Redefined/copied and extended from httplib.py:1105 (Python 2.6.x).
            This is needed to pass cert_reqs=ssl.CERT_REQUIRED as parameter
            to ssl.wrap_socket(), which forces SSL to check server certificate
            against our client certificate.
        """
        sock = socket.create_connection((self.host, self.port), self.timeout)
        if self._tunnel_host:
            self.sock = sock
            self._tunnel()
        # If there's no CA File, don't force Server Certificate Check
        if self.ca_file:
            self.sock = ssl.wrap_socket(sock, self.key_file, self.cert_file,
                        ca_certs=self.ca_file, cert_reqs=ssl.CERT_REQUIRED)
        else:
            self.sock = ssl.wrap_socket(sock, self.key_file, self.cert_file,
                                              cert_reqs=ssl.CERT_NONE)

if __name__ == '__main__':
    # Little test-case of our class
    import sys
    if len(sys.argv) != 6:
        print 'usage: ./https_auth_handler.py host port key_file cert_file ca_file'
        sys.exit(1)
    else:
        host, port, key_file, cert_file, ca_file = sys.argv[1:]
    conn = HTTPSClientAuthConnection(host, port, key_file=key_file,
                                           cert_file=cert_file, ca_file=ca_file)
    conn.request('GET', '/')
    response = conn.getresponse()
    print response.status, response.reason
    data = response.read()
    print data
    conn.close()

En cuanto a la generación de las claves de Cliente, Servidor y CA hay unos cuantos artículos y es relativamente sencillo una vez que se entiende qué se está haciendo. Por otra parte que en estos casos es muy común que el Servidor exija que el Cliente si o sí envíe su certificado o sino la conexión se deberá caer; esto en el caso del Servidor Apache está bien documentado.

Entiendo que en Python 3.2 esto está resuelto en la misma API standard de Python (en su momento abrí un ticket similar para usar esto con urllib2, que incluye cosas importantes como el manejo de cookies, por ejemplo), y comentaron eso.

Según me dijeron en PyAr, es casi seguro que este ejemplo no funcione en Python 2.7, así que en un futuro no muy lejano espero poder adaptar este código a dicha versión y seguramente lo estaré subiendo en esta página.

Saludos

Las vueltas de la vida y las ganas de experimentar y aprender te llevan a probar otros frameworks/librerías, como lo es wxPython; tanto es así que de vez en cuando tengo el placer de dar alguna charla al respecto [1], y una de las debilidades que le usualmente le encontraba es la falta de un componente «browser web» nativo y soportado en todas las plataformas (wxPython sólo incluye IE embebible como ActiveX en Windows).

En búsqueda de alternativas existe wxWebKit, pero al proyecto le faltan terminar algunas cosas para tener lista su versión «1.0», y si bien wxWebConnect funciona, no da soporte para wxPython, sólo wxWidgets desde C++. Eso nos deja con que en Linux/BSD no tenemos componente que nos dé esta posibildad, pero… si wxPython en estas plataformas utiliza GTK por debajo, ¿no podríamos usar pyWebkitGTK como componente para embeberlo en nuestra aplicación Python?

La respuesta por suerte es afirmativa, y en una rápida búsqueda en la Wiki de wxPython encontré un ejemplo de cómo hacerlo. Si bien podría copiar y pegar la receta, me gustaría «aggiornarla» un poquito, al menos traduciendo y explicando un poco más los comentarios.

Primero vamos a mostrar cómo se vería el módulo que incluye un widget HtmlPanel, wxwebkitgtk.py:

#!/usr/bin/env python
# coding:utf-8

"""
    wxWebkitGTK - Componente wxPython que embebe un navegador
                   utiliza la biblioteca Webkit GTK desde Python (PyWebkitGTK).

    Marcelo Fidel Fernández - http://www.marcelofernandez.info
    Basado en: http://wiki.wxpython.org/wxGTKWebKit
"""
import os
import wx
import gobject
gobject.threads_init()
import gtk, gtk.gdk
import webkit

class HtmlPanel(wx.Panel):

    def __init__(self, *args, **kwargs):
        wx.Panel.__init__(self, *args, **kwargs)
        # Aquí es donde se hace la "magia" de embeber webkit en wxGTK.
        whdl = self.GetHandle()
        window = gtk.gdk.window_lookup(whdl)
        # Debemos mantener la referencia a "pizza", sino obtenemos un segfault.
        self.pizza = window.get_user_data()
        # Obtengo el padre de la clase GtkPizza, un gtk.ScrolledWindow
        self.scrolled_window = self.pizza.parent
        # Saco el objeto GtkPizza para poner un WebView en su lugar
        self.scrolled_window.remove(self.pizza)
        self.webview = webkit.WebView()
        self.scrolled_window.add(self.webview)
        self.scrolled_window.show_all()

La «magia» consiste en que, sabiendo que pyWebkitGTK necesita un componente ScrolledWindow GTK como padre para funcionar correctamente, se utiliza la biblioteca PyGTK para buscar el ScrolledWindow GTK donde está embebido el wx.Panel de la clase (su «abuelo»), y reemplazar el hijo GTKPizza (un componente inventado por wxWidgets para funcionar) por el WebView de Webkit.

Aquí hay un ejemplo de cómo se puede utilizar este panel como widget de wxPython completo e independiente, copiando la funcionalidad básica del post de PyWebkitGTK, el archivo wxwebkitgtk_demo.py:

#!/usr/bin/env python
# coding: utf-8

"""
    wxSimpleBrowser - Navegador muy muy simple de internet, sólo de ejemplo,
                      que utiliza la biblioteca Webkit GTK desde wxPython.

    Marcelo Fidel Fernández - http://www.marcelofernandez.info
    Licencia: BSD. Disponible en: http://www.freebsd.org/copyright/license.html
"""

import sys
import wx
from wxwebkitgtk import HtmlPanel

DEFAULT_URL = 'http://www.python.org'

class wxSimpleBrowser(wx.Frame):

    def __init__(self):
        wx.Frame.__init__(self, None)
        self.TxtUrl = wx.TextCtrl(self, wx.ID_ANY, style=wx.TE_PROCESS_ENTER)
        self.TxtUrl.Bind(wx.EVT_TEXT_ENTER, self.OnTxtURL)
        self.Box = wx.BoxSizer(wx.VERTICAL)
        self.Box.Add(self.TxtUrl, proportion=0, flag=wx.EXPAND)
        self.SetSizer(self.Box)
        self.SetSize((800,600))
        self.Show()
        # Necesitamos tener mostrado el componente padre del Panel para que funcione,
        # por eso mostramos primero el Frame y después creamos el HtmlPanel
        self.HtmlPanel = HtmlPanel(self)
        self.Box.Add(self.HtmlPanel, proportion=1, flag=wx.EXPAND)
        self.SendSizeEvent() # Para acomodar el panel al tamaño del frame

    def OnTxtURL(self, event):
        self.Open(self.TxtUrl.GetValue())

    def Open(self, url):
        # Podemos acceder a todos los métods del objeto WebView
        # http://webkitgtk.org/reference/webkitgtk-webkitwebview.html
        self.HtmlPanel.webview.load_uri(url)
        self.TxtUrl.SetValue(url)
        self.SetTitle('wxSimpleBrowser - %s' % url)

if __name__ == '__main__':
    if len(sys.argv) > 1:
        url = sys.argv[1]
    else:
        url = DEFAULT_URL
    app = wx.App()
    browser = wxSimpleBrowser()
    browser.Open(url)
    app.MainLoop()

Creo que para la enorme funcionalidad que nos brinda el proceso de ponerlo en práctica es bastante simple, y aunque depende de PyGTK, ésta biblioteca hoy está disponible «de fábrica» en cualquier distribución moderna de GNU/Linux.

De aquí en más es ser muy sencillo dejar al lector el armado de un widget para wxPython que en Windows muestre el componente navegador de IE y en Linux un navegador Webkit.

[1] ¡La semana que viene voy a estar en la PyCon Argentina 2010 dando una charla de Introducción a wxPython!

¡Saludos!

Muchos (muchos) asistentes, muy buena onda, y una chorizeada + fernet a la noche inolvidables… En la sección de Charlas del blog están los slides de mi «Introducción a wxPython», más los ejemplos de rigor. También hice propaganda de Ubuntu en las Lightning Talks.

Acá hay un par de fotos… con los días van a ir apareciendo más cosas en el sito del evento… incluso los videos de las charlas.

Actualización: Acá están los videos de las charlas.

Gracias a los chicos de PyRafaela por la organización, dedicación y aguante…. ¡espero que se repita!

Saludos