Archivo

Archivo para la categoría ‘programación’

Control de Versiones: Manejando las diferencias entre distribuido y centralizado

sábado, 25 de julio de 2009 Sin comentarios

VCSsDando vueltas por ahí, me entero que es muy sencillo utilizar localmente versionado de código fuente (gracias a los sistemas de control de versiones distribuidos, como por ejemplo Mercurial, GIT y Bazaar) para luego subir/actualizar los cambios a un repositorio Subversion principal. Es decir, en vez de usar los comandos svn como clientes de un servidor Subversion, es posible utilizar alguno de estos sistemas distribuidos como clientes «consumidores» del repositorio principal, para luego aprovechar sus importantes ventajas en forma local.

En principio, admito que no conozco ningún VCS distribuido, más que nada por vagancia (je), pero esto en particular sí lo necesito de vez en cuando, principalmente cuando no estoy conectado, y/o cuando los cambios que hago con respecto a trunk son profundos, llevan tiempo y quiero tener un control más «fino» en lo que hago.

A ver, habiendo nombrado primero los sistemas más conocidos (por mí), se desprende que tenemos:

  • Logo MercurialMercurial-Svn: Si bien el autor del artículo que me inspiró a escribir esto (Vadim Zeitlin, desarrollador de wxWidgets) comentaba que le gusta muchísimo Mercurial por su fácil uso, al momento de probar esta extensión para subir los cambios al servidor SVN de wxWidgets tuvo problemas de performance, uso de memoria, etc. De todas maneras, el código fuente en el repositorio de wxWidgets es bastante grandote (~330MB), así que quizás funcione bien para proyectos chicos/medianos, y más si uno ya conoce Mercurial.
  • Git-Svn: Bueno, citando nuevamente a Vadim, parece que critica un poco lo complicado de los comandos Git, sin embargo termina recomendándolo en forma rotunda por su velocidad y poca utilización de espacio extra en el disco*. Acá parece haber un tutorial cortito para utilizarlo (Google me devuelve muchísimos enlaces más por si es poco).

Git Version Control

En fin, recién me sumerjo en la lectura y experimentación de todo esto, pero para aquellos que trabajan contra un servidor SVN** y suben sus cambios con poca frecuencia al repositorio principal, «rompiendo todo» cada vez que lo hacen (guiño, guiño), me parece que esto les viene perfecto.

BazaarAdemás, tengo entendido que no es difícil usar Bazaar (por poner uno de ejemplo), y realmente está muy cool poder volver atrás en los cambios que uno hizo desde que hizo el checkout/update del SVN, mientras desarrolla, y sin tener que conectarse a Internet (VPN/SSH/etc.).

(*) Cuando el cliente de control de versiones distribuido hace un checkout del repositorio Subversion, no sólo descarga la última versión de trunk, sino que descarga todas las versiones pasadas de todas las ramas existentes, con lo cual el consumo de espacio en disco local pasa a ser un asunto importante. Git, según Vadim, parece tener poco overhead en este sentido comparado con la extensión de Mercurial.

(**) Una de las cuestiones que no le hacen perder valor e importancia a SVN es que, al ser centralizado, sigue siendo relevante en empresas que quieren tener un control más o menos estricto de su código; por lo tanto, la migración a sistemas distribuidos no siempre estará bajo su radar. Es por eso que hablo de «diferencias» en el título del post y no de una «futura migración», es decir, que los distribuidos sean los «nuevos vecinos de la cuadra» no quiere decir que vengan a reemplazar a los viejos y conocidos. 🙂

¡Saludos!

Categories: codear, programación, python, ubuntu-ar Tags:

Applets Java en Ubuntu de 64 bits recargados

sábado, 18 de julio de 2009 Sin comentarios

java_logoAyer actualicé mi Ubuntu 9.04 (64 bits) y vi que había una actualización de los paquetes «sun-java6«, que corresponden a la Máquina Virtual Java. Para mi sorpresa, se trata de una actualización bastante importante de todos los paquetes de la implementación distribuida por Sun de Java (que aún no es lo mismo que el proyecto OpenJDK), y que incluye (después de ¡6 años de espera!) una implementación del Java Plugin de Sun para 64 bits.

Lo bueno es que ya puedo probar la nueva versión del plugin Java (incluida a partir de Java 6 Update 10) sobre Linux x86-84 en forma totalmente nativa.

Acá hay un video de un técnico de Sun, Kenneth Russell, donde describe todas las nuevas características del Java Plugin «recargado»:

La presentación del mismo en pdf está acá. Para información detallada y ejemplos para correr en el navegador, vayan a este link. Las novedades son muchas e importantes, y aunque la gente de Sun debería haberle dado importancia a esto hace tiempo, mejor tarde que nunca; les sugiero pegarle una mirada.

Saludos!

Categories: codear, linux, programación, ubuntu-ar Tags:

PostgreSQL 8.5

sábado, 4 de julio de 2009 Sin comentarios

No, no me equivoqué de número de versión. 🙂pgsql_logo

Si bien PostgreSQL 8.4 ya salió y tiene unas cuantas novedades, quisiera hacerme eco de lo que está en la cola de parches a aprobar para integrar la nueva rama de desarrollo de PostgreSQL 8.5. Esta lista está compuesta por cosas como:

  • GRANT ON ALL IN schema: Una manera de otorgar permisos a todos los objetos de un esquema.
  • Machine-readable explain output v2: Salidas del comando EXPLAIN fácilemente legibles por otro software, es decir, fácilmente parseables para su procesamiento. El comando explain aceptaría como segundo parámetro el formato (además de los actuales) la keyword FORMAT, quedando así: EXPLAIN FORMAT [TEXT | JSON | XML]. Está bueno porque abre la puerta del desarrollo de herramientas de auto-tunning, basado en reglas estilo Sistema Experto.
  • SE-PostgreSQL: Security-Enhanced PostgreSQL, una mejora sustancial en la seguridad del SGBD y en el nivel de detalles del sistema de privilegios.
  • Replicación Sincrónica: Si algo le faltaba a PostgreSQL es una manera de replicación sincrónica integrada en el gestor. Esperemos que esto sí entre, aunque está bastante discutido el asunto porque es un cambio relativamente «gordo» en los internals del código, pero por lo que leí de estas discusiones parece haber consenso en llevarlo adelante e implementarlo. Por mi parte… ¡lo necesito ya! 🙂
  • \dL para listas los lenguajes utilizados en psql: Es una nueva característica en psql, la de poder listar los lenguajes instalados en la base de datos (plpythonu, plpgsql, etc.).
  • Estadísticas de esperas por bloqueos: La idea es poder tener un historial de los bloqueos sufridos por los clientes en la BD, para poder detectar problemas y saber bien qué pasa en todo momento.

Bueno, de más está decir que no hay ninguna garantía de que todo esto sea finalmente integrado en 8.5, sino que se está evaluando al mejor estilo Software Libre: peer-review, discusión de estrategias del proyecto, consenso en la comunidad de desarrolladores y posterior aceptación/pedido de mejoras/rechazo. Así que veremos cómo sigue.

Saludos!
Marcelo

\dL for languages

Categories: codear, linux, programación, sysadmin, ubuntu-ar Tags:

Renderizando PDFs en Python con Poppler

sábado, 2 de mayo de 2009 3 comentarios

Buenas… hoy voy a mostrar una forma de renderizar archivos PDF dentro de nuestras aplicaciones y desde Python, para casi cualquier plataforma con la estemos trabajando.

Introducción
Si bien cuando se arma una aplicación de escritorio se suele «llamar» a un software externo (Acrobat Reader, Fox-It, Evince, etc.) para que muestre el contenido de un archivo PDF, generalmente queda «feo»; nuestro programa pierde la interacción y el control de lo que el usuario hace con el mismo, implica superponer un programa arriba del otro, etc. Esto suele producir una experiencia dificultosa para el usuario de nuestro querido programa, y como corresponde, los programadores nos ponemos tristes. 🙁

Como una alternativa tenemos, en plataformas Windows, y estando el Acrobat Reader instalado previamente, la posibilidad de embeber en nuestro programa el mismo como un control ActiveX (hay otras alternativas) pero en el resto de las plataformas este problema no tenía solución (que yo conociera, al menos), ni siquiera algo más «liviano». El resultado de embeber todo el Acrobat Reader es más o menos lo que hacen los navegadores web cuando tienen el plugin de Adobe instalado y hacemos click en un link a un archivo PDF de la web:

(Después de 1 minuto, y si el usuario no cerró la ventana, aparece esto)

Hace unos días, en la lista de usuarios de las bibliotecas wxPython preguntaron si se podía renderizar un PDF dentro de una ventana del mismo programa, pero sobre Linux, y buscando la solución me encontré con un binding Python para Poppler.

Solución: Poppler-Python sobre Cairo
Veamos, Poppler es una biblioteca de código abierto desarrollada en C con el objetivo de renderizar (es decir, interpretar y dibujar) archivos PDF, siendo la evolución del viejo Xpdf. Es una pieza de software imprescindible en el escritorio de cualquier Sistema Operativo Libre, ya que es un trabajo bárbaro el que hace, y además es la piedra fundamental de programas como Evince y Okular (más allá de que el PDF es un formato de archivo universal). Y lo mejor es que dibuja sobre cualquier contexto de dibujo de Cairo, así que donde haya Cairo y compilador de C, puede estar Poppler*.

Hasta acá, bien, Poppler se puede utilizar desde C (como lo hace Evince, el visor de PDFs de Gnome). Pero ‘ete aquí que me encontré con estos bindings de Poppler para Python, y si bien el ejemplo que éstos incluyen utiliza PyGTK, en realidad, sólo necesita de un Canvas Cairo (GTK dibuja mucho sobre Cairo y provee mecanismos para que el desarrollador lo utilice también); es el mismo Cairo que incluye wxPython a partir de la versión 2.8.9.0 (aunque se puede utilizar con ctypes desde versiones anteriores a la 2.8.9).

Un poco de Código
En fin, voy a tratar de explicarlo mejor, esta es la manera de renderizar un PDF dentro de una aplicación PyGTK. Voy a pegar acá abajo lo relevante:

    def __init__(self):
        [...]
        self.document = poppler.document_new_from_file (uri, None)
        self.n_pages = self.document.get_n_pages()
        self.current_page = self.document.get_page(0)
        self.scale = 1
        self.width, self.height = self.current_page.get_size()
        [...]
        self.dwg = gtk.DrawingArea()
        self.dwg.set_size_request(int(self.width), int(self.height))
        self.dwg.connect("expose-event", self.on_expose)
 
[...]
 
    def on_expose(self, widget, event):
        cr = widget.window.cairo_create()
        cr.set_source_rgb(1, 1, 1)
 
        if self.scale != 1:
            cr.scale(self.scale, self.scale)
 
        cr.rectangle(0, 0, self.width, self.height)
        cr.fill()
        self.current_page.render(cr)

Como se puede ver, Poppler-Python se encarga de cargar el archivo, devolver la cantidad de páginas, etc., mientras que con GTK creamos el contexto de dibujo Cairo, y todo lo que hacemos es decirle a Poppler «dibujá acá, en este contexto Cairo».

Entonces me puse a jugar con wxPython para hacer lo mismo, !y funciona!

Acá está el ejemplo:

#!/usr/bin/env python
import wx
import wx.lib.wxcairo
import sys
import poppler
 
class MyFrame(wx.Frame):
 
    def __init__(self):
        wx.Frame.__init__(self, None, -1, "Cairo Test", size=(500,400))
        self.Bind(wx.EVT_PAINT, self.OnPaint)
        uri = "file://" + sys.argv[1]
        self.document = poppler.document_new_from_file (uri, None)
        self.n_pages = self.document.get_n_pages()
 
        self.current_page = self.document.get_page(0)
        self.scale = 1
        self.width, self.height = self.current_page.get_size()
        self.SetSize((self.width, self.height))
 
    def OnPaint(self, event):
        dc = wx.PaintDC(self)
        cr = wx.lib.wxcairo.ContextFromDC(dc)
        cr.set_source_rgb(1, 1, 1)
 
        if self.scale != 1:
            cr.scale(self.scale, self.scale)
 
        cr.rectangle(0, 0, self.width, self.height)
        cr.fill()
        self.current_page.render(cr)
 
if __name__=="__main__":
    app = wx.App()
    f = MyFrame()
    f.Show()
    app.MainLoop()

Y acá está la captura de pantalla obligada, luego de ejecutar «python ejemplo.py /path/al/archivo.pdf» (click para agrandar):

De esta manera, es posible utilizar Python, Poppler y wxPython (o PyGTK) para mostrar y manejar el contenido de un archivo PDF dentro de nuestra aplicación y en casi cualquier plataforma, sin recurrir a componentes de terceros. 🙂

Consideraciones:
Bueno, quisiera comentar que poppler-python parece ser un proyecto «joven», ya que todavía sólo está incluido en los repositorios de Ubuntu 9.04 en adelante. Con lo cual, en caso de utilizarlo en otras distribuciones y/o plataformas, hay que hacer un checkout desde sus repositorios y compilarlo; sus únicas dependencias son pycairo y poppler (0.10.x o posterior). Es muy sencillo hacerlo (el típico ./configure, make y make install), y no tuve ningún problema, utilizando Ubuntu 8.10.

En caso de querer utilizar Poppler-Python sobre el Cairo que incluye wxPython, lo mejor es utilizar una versión 2.8.9.x o superior de wxPython (ya con eso es suficiente, porque incluye Cairo en el paquete). Ubuntu 9.04 trae wxPython 2.8.9.1, Poppler 0.10.x y Poppler-Python en los repositorios, así que con un único apt-get ya tenemos todo lo necesario para hacer andar el ejemplo de arriba.

En mi caso, para probarlo en Ubuntu 8.10, tuve que compilar poppler desde los fuentes (traía la versión 0.8.x) y después compilar python-poppler, por un lado. Por el otro, para utilizar Cairo sobre wxPython 2.8.8.0 (el que viene en Ubuntu 8.10), llamé a Cairo con ctypes, como dice acá, y me quedó este ejemplo. Este procedimiento sería similar para cualquier otra distribución con versiones viejas de Poppler y/o de wxPython. Para la distribución de nuestro software todo se simplifica, ya que se puede usar tranquilamente Py2Exe, cx_Freeze o PyInstaller, por nombrar algunos. Pero eso es tema de otro post 😉

* Poppler denomina Frontend a las diferentes APIs que tiene para ser utilizado, entre ellas QT4 (base de KDE) y Glib (GTK principalmente, base de Gnome). Y tiene como backend (es decir, necesita para dibujar) no sólo a Cairo, sino que también puede dibujar sobre Splash (ignoro qué es, y Google no me devuelve nada relevante).

Bueno, espero que al menos le sirva a alguien, que lo aprovechen y lo mejoren!

Saludos
Marcelo

Categories: codear, linux, programación, python Tags:

PyCon Chicago 2009

miércoles, 8 de abril de 2009 Sin comentarios

Hace algunos días que están disponibles los videos (versión más «navegable» acá) de unas cuantas charlas de PyCon 2009 – Chicago (terminó hace unos pocos días), y como me apasionan este tipo de eventos, suelo dedicarle algún tiempo libre a ver las que más me interesan (que «filtro» por el título, no me queda otra).

Les dejo una lista de las más importantes según mi criterio* (aclaro, sin haberlas visto):

¡Puff! Son un montón, y revisando un poco los títulos, se ve que me interesaron los temas bien técnicos. Para cada uno tengo un motivo, pero en vez de gastarme escribiendo (el tiempo es tirano, je), prometo que a medida que las vaya viendo (cada una dura algo así como 40 minutos), voy a actualizar este post.

*Mi criterio de interesante tiene que ver con algo totalmente arbitrario, es decir, sólo lo que me gusta. 😛

Saludos
Marcelo

PD: Muy copado que podés levantar todo el canal completo de PyCon con Miro! Si lo tienen instalado, hagan click acá para registrarse al canal PyCon y bajar tranquilo los videos para ver offline y recibir las actualizaciones del mismo…

Categories: codear, programación, python, ubuntu-ar Tags: