Websockets

A raiz de mi post anterior (Asyncronous web frameworks). Me ha dado por mirar el soporte a websockets en el mundillo python.

Node.js lo soporta con socket.io.
Play también tiene soporte para websockets (verdad que Play2 es muy interesante?).

En cuanto a python, hay varias opciones. Enlazando con el post anterior lo mas interesante sería combinarlo con gevent. Podemos usar tanto gevent-websocket como gevent-socketio.

Aquí tenemos otro post, en el que ademas usa zeromq.

Mas opciones pythoneras:

• autobahnpython (sobre twisted)
• pywebsocket
• tornado

Por otro lado, la versión 1.3 de nginx incluirá websockets. Aunque parece que se puede hacer que lo soporte.

Referencias

• Websockets comparison (wikipedia)

Asyncronous web frameworks

Ahora mismo una de las guerras que tengo es progresar en javascript. Cosa que ya estoy haciendo sin necesitar empezar un nuevo proyecto, gracias a una migración que tenemos ahora entre manos en Youzee.

Dentro del mundo javascript, uno de los productos que están en ebullición es node.js. Y la pregunta que me hago es... ¿Me interesaría usarlo para futuros proyectos?

Estamos hablando de servir miles de peticiones concurrentes por segundo. Escalar puedes hacerlo con un webserver normal. Simplemente tienes que echarle dinero al tema y ya está. Se trata de poner mas hardware y a balancear. Pero porque vas a tirar dinero innecesariamente...

Por otro lado, tenemos el caso de uso del long polling, donde las conexiones son persistentes. Para este caso un servidor multithread no va a ser capaz de escalar con un gran número de clientes. Necesitaremos ir a un servidor basado en eventos y llamadas asíncronas  Ahí es donde node.js entra de lleno. node.js tiene la asincronía en su adn.

node.js claramente es una opción realmente interesante:

• la comunidad de javascript está realmente activa y el lenguaje está cobrando mucha fuerza
• node.js es realmente muy muy eficiente.
• tienes la ventaja de poder compartir código con la parte cliente
• nunca vas a tener el problema de bloqueos por llamar a código síncrono.

Ahora bien... ¿Que alternativas tenemos a node.js? A mi particularmente me interesa python. Es mi debilidad. Parece que la mejor opción sería usar gunicorn junto con gevent (pero no es la única, tenemos twisted, tornado, ...)

Creo que sólo una restricción me harían decantarme por gunicorn+gevent que el código tenga que ser python ya que lo mas eficiente a dia de hoy es node.js. Lo cual no quita a que el resto de servicios puedan ser python. Sólamente necesitaríamos que el frontend fuera node.js. 

Como ultima nota comentar que si no nos importa perder un poco de rendimiento gevent proporciona algo interesante y es que sin cambiar el modelo de programación consigues asincronía.

Otro lenguaje interesante es scala. Me apunté al curso de coursera, pero por falta de tiempo no puede realizarlo. Si podeis no dejeis de hacerlo que por lo visto es muy bueno.
Y en scala tenemos play2. 
Si hoy en día tuviera que usar algo corriendo sobre la jvm (restricción), lo tendría claro. Este sería el lenguaje. Se diferencia de javascript y python en que tiene tipado estático (y fuerte como python). Auna en él, la programación OO y la funcional.
¿La desventaja? Un lenguaje mas complejo de aprender que python y javascript. Pero play2 tiene una pinta fantástica.

Conclusión

play2, para mi ahora mismo tendría una curva de aprendizaje mas largo, por lo que para proyectos personales ahora mismo no lo consideraría. Eso si, gente que conozco que están empezando a trastear con play2 están encantados. 

A falta de ver mas comparativas a nivel de framework (por que a nivel de lenguaje, Scala tiene mejor rendimiento que python y javascript), profesionalmente lo consideraría si a nivel corporativo está como requisito que corra bajo jvm. 

Cuando me meta con Scala, fijo le doy una probazón.

A nivel general veo lo mas atractivo tanto para proyectos personales, como profesionales node.js. No sólo porque es el que da mas rendimiento, sino por que es ahora mismo lo está muy en boga. La opción de compartir código entre cliente y servidor es también muy interesante.

Python (gunicorm + gevent) lo usaría sin duda si el código tiene que ser python o sino quieres complicarte en crear servicios adicionales (nodejs + python services). La diferencia de rendimiento con node.js es pequeña. Vamos.. que es una combinación totalmente acertada.

Y no quería acabar sin comentar que se está trabajando sobre un estándar asíncrono para python 3.

Referencias

Javascript

• Rant de Ian Bicking

Python

• Charla de pycon muy buena de la gente de meebo: high-concurrency python web applications.
• Un par de librerías utiles para gunicorm+gevent (meebo): gevent-profiler y greins (daemon interface + several apps per process).
• Run gevent in production
• Which features are monkey patched by gunicorn gevent worker?       
• Is gevent + gunicorn scalable and stable for production use?
• Unicorn design
• How-does-Gunicorn-use-Eventlet-or-Gevent
• Asynchronous Servers in Python (a must read)
• Differences between gevent and tornado
• Tornado vs gevent benchmarks
• Benchmark of Python WSGI Servers (a must read)

Scala

• Breve post sobre play2
• Guido rant sobre scala
• Paper de google sobre performance (muy buena para scala)
• Does Java has an answer to node.js?

Comparativas

• Scala vs python tcp informal benchmark 
• Benchmark de scala, python y javascript.
• Node.js vs python solutions (II)
• Node.js vs python solutions (I)
• python vs ode vs pypy
• uwsgi vs gunicorn vs node benchmarks

Python + excel

La verdad... no se que fue primero si mi pensamiento en que estaría muy bien algo tipo excel en un entorno python o ver este artículo de Techcrunch, sobre DataNitro.

En Techcrunch referencian a:

• Pyvot
• Pyxll

Habrá que echar un ojo en profundidad para ver que ofrece DataNitro sobre ellos. Para usos comerciales ni Pyxll ni DataNitro son gratis, y parece muy similares.

Pyvot permite leer y manipular excel desde python, pero sin embargo no permite definir funciones en python que sean invocadas desde excel.

Echando un vistazo a este link del artículo,  me he encontrado con PyTools. Un plugging de Visual Estudio para python.

Buscando spreasheets en python sólo he encontrado:

• Pyspread
• Resolver (desarrollo abandonado)
• PyCells

Vamos... el único interesante parece Pyspread.

utc and localtime

Ayer vi una presentación muy interesante: Python for Humans.
En ella se comenta que a pesar de que python tiene su Zen (import this) hay modulos de la librería estándar que o bien no son simples o se podrían mejorar.

Un claro ejemplo es datetime. ¿Porque no se incluye la timezone por defecto?
En el momento que quieres hacer conversiones entre timezones, necesitas de modulos externos. Y de nuevo nos encontramos con otro de los problemas de python. La multitud de opciones... ¿Cual usar pytz o dateutil?

Os dejo con un programilla que convierte de utc a localtime usando los dos.


from datetime import datetime
import pytz
from dateutil import tz

# The problem with now and utcnow is that they don't set set tzinfo to None
now = datetime.now()
utcnow = datetime.utcnow()

# Wit this one, we are setting the tzinfo (using dateutil)
summertime = datetime(2012,7,1,23,30, tzinfo=tz.gettz('UTC'))

#--- Converson using dateutil
#    We are using naive timezones with the exception of summertime
#    Instead of using local datetime with tz.tzlocal() we are hardcoding it
print "*** Conversions using dateutil"
print 'now:', now.strftime('%Y-%m-%d %H:%M:%S')
print 'utc:', utcnow.strftime('%Y-%m-%d %H:%M:%S')
print 'summertime:', summertime.strftime('%Y-%m-%d %H:%M:%S')

UTC = tz.gettz('UTC')
HERE = tz.gettz('Europe/Madrid')
utcnow2 = utcnow.replace(tzinfo=UTC)
print 'utc localized:', utcnow2.astimezone(HERE).strftime('%Y-%m-%d %H:%M:%S')
print 'summertime localized:', summertime.astimezone(HERE).strftime('%Y-%m-%d %H:%M:%S')

#--- Converson using pytz
#    Pay attention to how we can create a utc datetime with timezone using now()
#    Instead of using pytz.utz we could also use pytz.timezone('UTC')
madrid = pytz.timezone('Europe/Madrid')
utc_with_timezone = datetime.now(tz=pytz.utc)
utc_withouth_timezone = datetime.utcnow()

print
print "*** Conversions using pytz"
print 'with:', utc_with_timezone.strftime('%Y-%m-%d %H:%M:%S')
print 'withouth:', utc_withouth_timezone.strftime('%Y-%m-%d %H:%M:%S')
print 'with localized:', utc_with_timezone.astimezone(madrid).strftime('%Y-%m-%d %H:%M:%S')

# astimezone cannot be applied to a naive time zone so we need to do like with dateutil
# and firtsly we need to localize the datetime
utc_withouth_timezone = pytz.utc.localize(utc_withouth_timezone)
print 'without localized:', utc_withouth_timezone.astimezone(madrid).strftime('%Y-%m-%d %H:%M:%S')
print 'summertime localized:', summertime.astimezone(madrid).strftime('%Y-%m-%d %H:%M:%S')

Salida:

*** Conversions using dateutil

now: 2012-11-13 12:17:01

utc: 2012-11-13 11:17:01

summertime: 2012-07-01 23:30:00

utc localized: 2012-11-13 12:17:01

summertime localized: 2012-07-02 01:30:00

*** Conversions using pytz

with: 2012-11-13 11:17:01

withouth: 2012-11-13 11:17:01

with localized: 2012-11-13 12:17:01

without localized: 2012-11-13 12:17:01

summertime localized: 2012-07-02 01:30:00

Vamos que da un poco igual usar uno que otro...
En el caso de pytz en lugar de usar localize() podríamos haber hecho uso de replace() como si se hace con dateutil.

Si teneis que usar offets, en lugar de zonas, dateutil los soporta. Mi balanza a priori se inclina para dateutil por ese motivo. Ejemplo:


from datetime import datetime
from dateutil import tz

HERE = tz.tzlocal()
OFFSET = tz.tzoffset(None, 3600)
UTC = tz.gettz('UTC')

now = datetime.now(UTC)
here = now.replace(tzinfo=HERE)
offset = now.replace(tzinfo=OFFSET)

print 'here:', here.astimezone(HERE).strftime('%Y-%m-%d %H:%M:%S')
print 'offset:', offset.astimezone(OFFSET).strftime('%Y-%m-%d %H:%M:%S')

py.test

Allá por el 2006 usé py.test. Me gustó su simplicidad. Muy pythoniano. ¿Lo malo? Que estaba vinculado a pypy.
Posteriormente he estado usando pyunit, que es mas crosslang.
Hoy he descucierto que ya no tiene la dependencia que tenía con pypy y que lo puedes usar más fácilmente: pytest.org.

Mis editores de texto

Sublime Text 2 se ha convertido en mi editor de texto habitual (junto a vim).
Nunca he llegado a ser un crack del vim, pero me gusta. Desde que estoy en Youzee me manejo con un Windows 7, y tengo que confesar que ese probablemente sea el principal motivo. No llegue a tener un entorno de trabajo con vim para estar agusto al 100%.

Ahora tengo un entorno bastante decente, pero el que no le dedique otro intento tiene un culpable, que es ST2.

Hay alguna cosilla que puedo echar de menos con respecto a editores especializados, pero en esta vida no se puede tener todo...

Y el último editor que uso es  SciTE, en plan blog de notas y todolist.
No voy a justificar aqui el uso de ellos, simplemente quería comentar mis editores de trabajo y como los tengo tuneados.

Scite

use.tabs=0
tabsize=4
indent.size=4

font.base=$(font.monospace)
font.small=$(font.monospace)
font.comment=$(font.monospace)
font.text=$(font.monospace)
font.text.comment=$(font.monospace)
font.embedded.base=$(font.monospace)
font.embedded.comment=$(font.monospace)
font.vbs=$(font.monospace)

ST2

{
"color_scheme": "Packages/Color Scheme - Default/Monokai.tmTheme",
"default_line_ending": "unix",
"font_size": 10,
"theme": "Soda Dark.sublime-theme",
"translate_tabs_to_spaces": true,
"trim_trailing_white_space_on_save": true
}

Y uso los pluggings:

Package control
DocBlocktr
JsFormat
SublimeLiter

Vim

Vim lo tengo muy poco tuneado.
.vimrc


set expandtab
set shiftwidth=4
set softtabstop=4
set tabstop=4
set smartindent
syntax on


augroup filetypedetect
    au BufNewFile,BufRead *.pig set filetype=pig syntax=pig
augroup END

Y en .vim:


.
`-- syntax
    `-- pig.vim

Vamos... casi nada. Y de echo la sintaxis para pig, ya no la necesito :p