Mariano Reingart: Trazabilidad de Medicamentos, Operaciones Cambiarias y Remito Electrónico

En el proyecto PyAfipWs se ha agregado soporte para varios webservices:


Con estos servicios web el proyecto PyAfipWs se ha expandido más allá de los webservices de AFIP, incluyendo otras entidades y servicios, completando e integrando las funcionalidades más usadas por sistemas de gestión en Argentina, no solo para python sino que con la interfaz COM se pueden usar desde otros lenguajes en Windows (Visual Basic, Visual Fox Pro, Delphi, ABAP - SAP, etc.) e incluso con interfaces de texto o por linea de comando en otras plataformas (DOS, UNIX).
Próximamente se agregará soporte para archivos CSV, DBF (dBase, FoxPro, Clipper, etc.), extendiendo y facilitando aún más el acceso a estos servicios web desde lenguajes de programación legados.

Respecto a la librería PySimpleSOAP, se realizaron las siguientes mejoras para soportar los nuevos webservices:

  • Mejoras en analisis de WSDL (separando nombres de elementos y tipos complejos, reconocimiento de las diferentes partes de los mensajes, tag vacios)
  • Soporte de SOAP Header (encabezados para autenticación)
  • Soporte básico para WSSE (WebService-Security Extensions)
  • Ajustes por servidor, para formar el requerimiento según cada plataforma evitando incompatibilidades (por ej., no enviar tag vacio a JBoss-AS pero si )
Las modificaciones experimentales están en una rama propia del repositorio, ya que algunos cambios pueden introducir incompatibilidades hacia atrás o todavía no son del todo definitivos. Más información en:

Gracias a tener un desarrollo propio para la comunicación SOAP se pudieron solucionar estos y otros inconvenientes, incluso cuando otras soluciones para webservices fallaban o no se ajustaban a los requerimientos (que por cierto, ningun servicio web ha sido igual a otro, cada nuevo webservice introduce ligeras incompatibilidades, interpretaciones diferentes del standard SOAP o nuevas características).

El servicio COT no es un webservice tradicional ya que no utiliza XML para el requerimiento ni SOAP para la respuesta, teniendo su propio esquema, por lo que solo se uso SimpleXMLElement de PySimpleSOAP (manejo de xml simple estilo objetos), y se adapto un WebClient para codificar los métodos POST. 
Gracias a Matias Gieco por aportar los ejemplos iniciales que posibilitaron desarrollar el componente.

Más información sobre el proyecto en:


Anuncios completos:

Ramiro Algozino: Cómo actualizar Fedora 15 a 16 sin dolor

Después de un tiempo de usar Ubuntu 11.10 bastante conforme, con la llegada de Unity me ví en la encrucijada (?) de decidir si seguir con Unity o irme para el lado de Gnome3. Con la salida de Fedora15 teniendo la mejor implementación de Gnome3 a la fecha, decidí volver a la distro que había dado tantas satisfacciones.

Estuve usando Fedora 15 sin mayores problemas prácticamente desde que salió, incluso la personalicé bastante y quedé muy conforme con el resultado. Particularmente el tema Faience (del creador de los íconos Faenza) sumado a Zukitwo hace una combinación espectacular!

#EsTodoRisasHastaQue salió Fedora16, dado que había personalizado bastante mi instalación de F15, me daba mucha fiaca tener que instalar de cero F16 y reinstalar todas las aplicaciones y personalizaciones que había hecho (ni hablar que ni siquiera recuerdo como hice la gran mayoría). Investigando un poco me encuentro con preupgrade, que resulta ser un método soportado oficialmente para hacer upgrades de versiones en Fedora! 🙂

Cómo uso PreUpgrade?

Primero que nada hagan backup por las dudas! una vez que tengan listo el backup, hagan un update del sistema a las últimas actualizaciones  (yum update). Ahora que tienen todo actualizado y bonito, fijensé si tienen instalado preupgrade, en caso contrario con un ‘yum install preupgrade’ es más que suficiente, está en los repos oficiales de Fedora.

Cuando tengan todo esto listo, como root ejecutan el comando “preupgrade” y se les va a abrir una ventana desde la cual van a poder seleccionar a cuál versión de Fedora quieren actualizar, seleccionan, le dan siguiente y el ayudante comienza a bajar todos los paquetes necesarios, en mi caso fueron un poco más de 600 MB.

Una vez que el asistente haya terminado reinician el sistema y ya tienen F16 instalado! 😀

Oh no!

Si al reiniciar se encuentran con un hermoso cartel que dice “Oh no! Something has gone wrong. A problem has ocurred and the system can’t recover. Please contact a system administrator” y tienen la versión de 64 bits de Fedora instalada lo más probable es que este error se deba al paquete caribou. PreUpgrade lamentablemente instala la versión de 32 bits de este software y crashea el sistema. Para solucionarlo basta con un simple:


yum remove caribou

yum install caribou

Yum se debería encargar de instalar la versión de 64 bits con el último comando.

Se preguntarán.. ¿cómo hago para desinstalarlo e instalarlo si está Gnome no responde? Fácil, presinando Alt+Ctrl+F1, Alt+Ctrl+F2, etc. van alternando entre las distintas tty del sistema. Elijan alguna, logueensé como root o como su usuario y reinstalen caribou con los comando anteriores. Una vez reinstalado vuelvan a la tty que tiene la sesión de Gnome3 y presionen Ctrl+Alt+BackSpace y Voilá!! Disfruten de Fedora 16 😀

Nota: PreUpgrade tiene un montón más de opciones, como por ejemplo usarlo a través de VNC, o desde la CLI (consola). peguenlé una mirada a la entrada en la wiki aquí: http://fedoraproject.org/wiki/How_to_use_PreUpgrade

Actualización: Nautilus no arranca

Después de unos días me doy cuenta que nautilus no arranca.. 😦 Craseha con el siguiente error:

Traceback (most recent call last):
 File "/usr/lib64/python2.7/site-packages/gi/__init__.py", line 23, in <module>
 from ._gi import _API, Repository
ImportError: could not import gobject (error was: ImportError('When using gi.repository you must not import static modules like "gobject". Please change all occurrences of "import gobject" to "from gi.repository import GObject".',))

(nautilus:1733): Nautilus-Python-WARNING **: nautilus_python_init_python failed
Traceback (most recent call last):
 File "/usr/share/nautilus-python/extensions/nautilus_terminal.py", line 48, in <module>
 from gi.repository import Nautilus, Gtk, Gdk, Vte, GLib
 File "/usr/lib64/python2.7/site-packages/gi/__init__.py", line 23, in <module>
 from ._gi import _API, Repository
ImportError: cannot import name _API
Violación de segmento

Según éste bug, este error se da sólo en la versión de 64bits de Fedora y con la extensión nautilus-terminal. Para que arranque nautilus nuevamente debemos desinstalar este plugin de nautilus con el siguiente comando como root:

yum remove nautilus-terminal

Y listo… Nautilus debería funcionar nuevamente sin problemas 😀


alecu: Adding Proxy support to Ubuntu One

(TL;DR: Proxy support is a complex matter. We asked our Ubuntu One users to help us with a Proxy survey to understand how proxies are used. We’re releasing the results so other developers can benefit from it.)

During the past few weeks I’ve been working on researching the intricacies of adding proxy support to the Ubuntu One client. Allowing proxies to be used is not as easy as it sounds: our codebase relies on many different libraries and frameworks to access the network, and each of those libraries has a range of support for all the various proxy protocols and the many proxy authentication schemes, that varies from “incomplete” to “non-existent”.

Also we need it to work both for the Linux client and for the new Windows client; we need to test all this with a combination of Proxy server software, protocols, authentication schemes and configurations; and we need to take into account that our file synchronization protocol is not based on the very common and well supported HTTP protocol, but instead it uses a custom protocol optimized for our file synchronization use case, and like all non-HTTP protocols it requires special handling when crossing some types of proxies.

After multiplying of all the above issues, Proxy support ends up sounding a bit complicated in fact. So we decided to run a survey with the Ubuntu One users, asking them about the Proxies that they need to use, to help us understand the most common scenarios and to focus our development efforts.

At this point I need to send a huge “THANK YOU” to our Ubuntu One users: just a day after our initial tweet we got the help of a lot of users that need Proxy support. They filled in our small survey, but they gave us a lot of insight into this matter.

Here are the summary graphs (pdf, 93kb), and since the results of this survey may be useful for other developers wanting to implement Proxy support in their own projects we decided to also release the raw survey data (csv, 43kb).

And a few of my thoughts on the survey:

  • I expected most users to use a Proxy at work or at an educational institution, but did not expect so many people using proxies at home. From the “other” descriptions, they are mostly used for VPNs and for anonymizing proxies.
  • Most people don’t know the proxy brand, nor type of authentication that they need to use. I expected this, and it’s just fine! All proxy enabled software should just work.
  • Authentication schemes are more important than the small number of replies, since they are needed to support the big percentage of users that need to use credentials.
  • Site filtering may prove a big issue for some users: many proxy servers are configured to disallow access to video sites, likely on the basis of conserving network bandwidth, and those network admins may be reluctant to allow file synchronization services like Ubuntu One.
  • Protocol filtering will be a challenge for us: a significant number of proxy installations do not allow network traffic other than HTTP and HTTPS, so we’ll need to tunnel our synchronization protocol thru some of the allowed protocols, probably using the CONNECT HTTP method of some proxy servers. And there’s no easy solution for proxy servers that allow only HTTP or HTTPS but not CONNECT.
  • I didn’t expect so many answers in so short a time. Ubuntu One users rule!

Martín Cerdeira: Django-IDE: Video preview

Luego de escribir este post IPnaf IDE - La IDE definitiva para python, y recibir algunos comentarios que me hicieron pensar (y ver que, estaba un poco equivocado en mis comentatios), me dije "y por qué no puedo ser yo quién arme una IDE?"

Y así fue que, pensando un poco, me puse a intentar llenar un hueco que, creo que está lo suficientemente vacío como para que un esfuerzo allí, valga la pena.
Entonces, empezó a nacer Django-IDE.

Les dejo un video con una preview muy muy muuuuy temprana (no tiene para nada todos los features que va a tener), en fin, acá va:




Ver en youtube

What is Django-IDE good for?

Django-IDE helps you to:
  • Easily create Django projects.
  • Manage and edit existing project
  • Edit and Save your code, with a editor based on Ace.
  • Run and debug.
La estoy armando a pulmón, esto es, codeo un poco los findes, y cuando puedo...
Espero comments!!! :)

alecu: Cómo funciona un PyCamp

(Alfonso de la Guarda me contó que están organizando un PyCamp en Lima, y me preguntó como hacemos en PyAr para organizar un PyCamp. Como esto puede que le interese a más gente, respondo por acá).

Que buena idea hacer un PyCamp en Lima! Me encantaría poder asistir. Mientras tanto, les cuento como lo organizamos por acá:

Primero, anunciamos un lugar y fecha, e invitamos a toda la gente que tiene ganas de ir a anotar ideas y proyectos en una página del wiki. Por ejemplo, esta es la lista de temas propuestos en PyCamp 2011. La gente va viendo la lista de asistentes y temas y juntando ganas de ir. Todos tienen que hacer el depósito para pagar alojamiento, comida y conectividad cuanto antes, pero siempre hay alguno que termina asistiendo a último momento.

Una vez en el evento, durante el primer día hacemos la presentación de gente (donde cada asistente tiene 30-60 segundos para contar quién es) y la presentación de proyectos (donde cada persona que propuso un proyecto puede contar un poquito sobre el mismo). Luego medimos cuanta gente hay interesada en cada proyecto, levantando manos, y según la cantidad de interesados repartimos los proyectos en una grilla, para que los proyectos con más interesados comiencen “antes”. Esta es una foto de la grilla:

IMG16948.JPG

Nos resulta importante este paso, porque en la wiki no suelen anotarse todos los proyectos, y también para animar a los asistentes nuevos a que propongan o se enganchen en alguna actividad.

La idea de que los proyectos comiencen a distintas horas es para que si una persona está interesada en varios proyectos, que pueda asistir a la explicación detallada de cada uno que se suele hacer al principio del mismo, para enterarse más del estado del proyecto y poder participar tras el PyCamp.

Uno de los espacios se reserva para una reunión de PyAr (generalmente el sábado a la noche, junto con el asado), donde se charlan cuestiones administrativas del grupo. Y además alguna tarde/noche suele haber alguna actividad, tal como una excursión o algo similar. Y por las noches suelen haber juegos de mesa, de rol y torneos de metegol o Armagetron.

IMG16983.JPG

Pero más allá de la grilla, el PyCamp es “caótico”, en el buen sentido del término. Cada participante tiene libertad de sumarse o restarse de algún proyecto en el momento en que le interese o aburra. Hay proyectos que terminan ocupando la mayor parte del tiempo, por el entusiasmo que los asistentes le ponen al mismo, y hay algunos propuestos que no llegan a tener quorum. Hay participantes que terminan trabajando solos (y eso está bien) y hay otros que terminan descubriendo afinidad y arman un grupo que persiste luego del PyCamp (y eso es lo mejor).

En resumen, el mayor esfuerzo para hacer un PyCamp es conseguir el lugar, asegurarse que tenga una conexión a internet razonable y gestionar las reservas; esta es la infraestructura para que entre todos los participantes vayan organizando las actividades de la manera que les resulte más intersante.

PD: acá hay muchos posts con fotos y más info: http://python.org.ar/pyar/PyCamp

Joaquin Sorianello: Decaer como cesio 137

(leer escuchando esto)


Decaer.

Dejar que la vida lleve hacia abajo.

Mojar la medialuna en el café.

Prometerse a uno mismo que no llegará tan abajo.

Mirar el mar.

Esconderse en la bruma de la mañana.

Llorar por lo que paso.

Reirse de uno mismo.

Lo mas que se pueda.

Sonreir como si no importara el vuelo de los mirlos.

Prometerle a la mañana.

Que ella.

Será, por adelantado,

la dueña de la mañana.

Recordar los cuatro años.

Por que allí,

Y solo allí.

Aprenderas a decaer,

lentamente,

como el cesio 137.

Pablo Alejandro Costesich: Lenguaje S (Lógica Computacional)

En el libro Computability, Complexity and Languages de Davis y Weyuker se describe un lenguaje de programación Y (S para algunos). Dicho lenguaje, sencillo, cumple algunas propiedades teóricas interesantes y es empleado en cátedras de Lógica Computacional.

El código de un programa en S es algo como:

[A1] IF X1 != 0 GOTO B1
Z1 <- Z1 + 1
IF Z1 != 0 GOTO E1
[B1] X1 <- X1 - 1
Y <- Y + 1
Z1 <- Z1 + 1
IF Z1 != 0 GOTO A
(Función Identidad, Página 17 de Computability, Complexity and Languages)

Es un lenguaje simple, con tres instrucciones: incrementar o decrementar una variable. y saltar a una etiqueta si una variable no es cero.

El rango de las variables es [0, +inf) y toman como valor inicial cero. Además, decrementar una que está en cero no cambia su valor.

También están las etiquetas, que permiten nombrar instrucciones y saltar a ellas mediante IF. Si se salta a una etiqueta inexistente el programa termina. Una extensión al lenguaje es la existencia de macros, similares a las de C.
En el Lenguaje S es conveniente probar los edge-cases antes de empezar a probar formalmente el programa, o tener una ayuda para hacer un seguimiento de la ejecución del mismo.

Como el lenguaje es simple decidí implementar un intérprete y un compilador con una reducida máquina virtual (por el momento sólo en Python). Están bastante incompletos (pero funcionan) y necesitan un lexer-parser real. Aclaro que fue una solución Quick n' Dirty.

El código está en GitHub y bajo licencia NewBSD. Cualquier sugerencia constructiva es bien recibida, por lo que agradezco mucho cualquier fork y pull-request, bug report o comentario.

Martín Cerdeira: IPnaf IDE - La IDE definitiva para python

Dentro del titulo mentiroso, que usé para atraer la atención (el plan B era poner "cerveza gratis!") encierro un pensamiento mío, pero que creo que muchos compartimos. Pero, primero lo primero:

IPnaf IDE quiere decir: IPnaf Please Not Another Fucking IDE!!

Aunque, debería ser "not another fucking python IDE!" Y a qué me refiero con esta misteriosa frase?? He visto, y ultimamente mucho mas, una proliferacion de lo que hacen llamar IDEs. Pero, me voy a centrar en IDEs para el lenguaje pythyon: cito, spyder, Ninja, entre otros, que aparecieron como "somos la IDE definitiva".

Hay un chiste de Xkcd donde, la idea más o menos es que, alguien dice "uh, hay n maneras de hacer x! No puede ser, hay que generar un standard. Horas luego hay n+1 maneras de hacer x"

Y es así. Siempre. Siempre?? Bueno, no siempre, pero en el 99.9% de los casos. Otras veces, ese pensamiento da lugar a innovaciones. Pero, es lo común?? Diríamos que no.

Vuelvo a los ejemplos que cité: Spyder y Ninja. Ambas las bajé, instalé y probé. Aclaro que no tengo nada en contra de quienes la desarrollan (ni los conozco) ni me parece que su trabajo y esfuerzo sea malo. Al contrario. Pero, veo que está desperdiciado. Gente con talento claro, pone esfuerzo en cosas que ya existen y, sin innovaciones reales. A qué me refiero??

Spyder y Ninja [0] son, sin duda esfuerzos de desarrollo y diseño. Pero, que son? Editores de texto lindos y python friendly. Nada más. Ah, y que ejecutan código. Nada que no puede hacer con Emacs y un poco de tiempo + macros.

Debugger? No, gracias. [1]

Ojo, no es que sea fácil hacer un debugger como la gente, que corrar el código paso a paso y podamos inspeccionar varibles, ejecutar código en el contexto de ejecución, editar código on the fly, hacer remote debugging etc. [2]
Pero, es lo que falta!! (en general) Y si, es más lindo ponerse a escribir la IDE desde cero [3], y luego agregarle esas funcionalidades superstar, pero, primero hay que hacer el editor, el highlighter, el buscador de código, el generador de plugins, el pseudo intellisense, etc. Y, para cuando llegamos a las funcionalidades breakers, rockstar, "la papa", quizá el proyecto ya murió.

"No necesitamos esos features de maricones". Diría el macho programmer. (y esto me hizo acordar a otro chiste de Xkcd) pero, la realidad es que, cuando más cómodo esté uno, mejor trabaja y más se puede concentrar en el problema puntual que esté resolviendo.

Por qué no tomar una IDE existente y opensource y mejorarla en vez de arrancer una from scratch?

Entonces, si se van a poner a programar, aviso, no necesitamos más IDEs =) 

EOF

[0] Elegí Spyder y Ninja porque son 2 que recuerdo haber visto últimamente, y que además las instalé y probé.

[1]  Creo que Spyder estaba implementando pdb y winpdb. De todos modos, mi punto sigue en pie.

[2] Acá es cuando alguien me va a decir, "vos, porque estás acosbumbrado a visual basic" Puedo asegurar que he programado en editores de texto plano como en Visual Studio, Eclipse o Netbeans. Uno puede usar un debugger o usar prints, pero, las funcionalidades rock star en las IDEs, son geniales!! No es que uno no pueda vivir sin ellas, pero, si existen, mucho mejor!!

[3] Es como el caso de las n distribuciones de Linux. Ya hay suficientes en variedad como para parar un poco, si tenés tantas ganas de laburar en una distro, contribuí con una que exista!!!

Martín Cerdeira: It Sucks!

Ultimamente he tenido que interactuar con varios productos de una empresa "muy conocida" (que tienen, entre otros productos un CRM y un ERP) y, me he topado con un viejo amigo: los webservices.

Y, claro, no es que no los conociera pero, hacía mucho que no me topaba y, ya había olvidado lo feo que son, lo lentos, lo roto que está el modelo en general (SOAP, REST o POX, da igual)

O lidias con librerias horrendas, o parseas xmls.

Y me pregunto: Por qué? No deberíamos (los informáticos) facilitar el acceso a los datos?? No debería ser todo, cada vez más fácil y lindo?

OData, ya es algo, pero, como todo, hasta que sea realmente un standard, vamos a seguir sufriendo con, mixturas de tecnologias (y tampoco se si es la solución al problema)

En fin, mi opinón es que, en lo que es acceso a datos abierto y fácil para todos, We Suck!

Lecturas relacionadas:
SOAP
REST SOAP POX