Mostrando las entradas con la etiqueta python. Mostrar todas las entradas
Mostrando las entradas con la etiqueta python. Mostrar todas las entradas

miércoles, julio 31, 2013

PyPy 3

Buenas noticias[1]. Han liberado PyPy3 2.1 beta 1. Es la primera versión de PyPy que es compatible con Python 3.
PyPy es un intérprete de Python que se basa en un compilador JIT (Just In Time [2]) que tiene un desempeño muy competitivo, tanto, que está "postulado" para sustituir el intérprete CPython[3].
[3] CPython es el intérprete de Python que mantiene la Python Software Foundation, y el más utilizado. Es una implementación de Python escrita en lenguaje C (de ahí su nombre). Se considera la "implementación de referencia".

domingo, septiembre 02, 2012

Detalles sobre una instalación nueva de Ubuntu 12.04 en mi oficina

La gran pesadilla hasta ahora ha sido el proxy y el firewall de mi lugar de trabajo.
Desde las versiones 11.X de Ubuntu empecé a utilizar el entorno Unity de Ubuntu. Al principio no me gustó mucho pero empecé a entender las razones de su diseño: por ejemplo, el principio de que los píxeles valen [1]. Luego de darle una oportunidad y en la medida en que iba actualizando mi sistema hasta llegar al 12.04, creo que ya Unity tiene bastante madurez y puedo decir que me gusta el entorno. Ahora, en ese proceso he venido acarreando las aplicaciones que tenía instalada desde el 11.X y se que hubo muchos cambios en cuanto a las aplicaciones instaladas por omisión en un entorno Ubuntu. Así que por la curiosidad de entender qué es lo que la gente de Ubuntu define como su escritorio (si es que podemos seguir usando esa metáfora o ya es hora de pensar en una nueva) o mejor dicho, su sistema, quise hacer una instalación desde cero y darle una oportunidad a las aplicaciones que ellos sugieren y experimentar bien cómo se integran al resto del sistema (y cómo lo hacen, es algo que también me llama la atención); excepción: Emacs, ya instalado.
Sin embargo, hacer esto en una organización que tiene un firewall y un proxy clásicos, no es tan divertido. Así que quise dejar aquí algunas notas de las cosas que tuve que tomar en cuenta antes y después de la instalación desde cero en mi oficina.
[1]Tal vez hago referencia a otro libro acerca de diseño, pero solo con ir a la Guía del escritorio de Ubuntu se puede uno enterara de que el diseño del nuevo Ubuntu busca minimizar las distracciones, aumentar el espacio de trabajo y ayudar al usuario a realizar sus tareas.

Respaldo

Por supuesto, este es el primer paso. Respaldar los datos importantes: documentos, imágenes, música, etc. Basta con copiarlos en un medio de almacenamiento externo como un CD/DVD o un disco duro externo.
Sin embargo, con respecto a los correos electrónicos y los contactos tuve que hacer algunos pasos adicionales.
Primero, he estado usando Evolution hasta ahora. Por ahora bastaría con el respaldo clásico, y se supone que importar esos correos desde Thunderbird es directo porque teóricamente usan el mismo formato de correo: Mbox. Sin embargo, hay una consideración en mi caso: había usado Evolution desde hace tiempo que me enteré que tenía los correos en un formato de correo viejo: Maildir que es mejor exportarlos a Mbox antes de hacer el respaldo, para que no tenga que instalar Evolution al final para poder transformar los correos a Mbox (tal vez no fuera necesario, pero era un riesgo que no tenía que pasar). Para esto, usé un script que recomendaron en una respuesta en AskUbuntu . Al final, el respaldo es un archivo en formato Mbox que debe guardarse en el medio de respaldo elegido.
Con respecto a los contactos desde Evolution, simplemente clic derecho a la libreta que se quiera respaldar y se exporta (normalmente a formato Vcard)
Luego del respaldo, viene la instalación. No escribiré al respecto, solo que instalé de la forma más directa: "siguiente siguiente siguiente".

La Red (el caso del Proxy)

Si tienes una computadora portátil, sufrirás las consecuencias de hacer todo lo que aquí se indica, porque cada vez que se cambie de lugar de acceso a Internet, habrá que volver a configurar el proxy.
Después de instalar el sistema lo primero que se haría es actualizar el sistema, pero esto no es tan trivial en mi oficina. Primero se debe configurar la red.
Si fuera el caso de una computadora nueva en la organización, habría que decirle al departamento de IT cuál es la dirección MAC de la máquina. Pero ya que estoy usando la misma máquina de siempre, no hace falta.
Luego, conectarse no debería ser muy difícil en Ubuntu: se conecta el cable y listo, o si se quiere usar la red inalámbrica, basta con colocar la contraseña cuando se pida.
La parte fastidiosa del cuento es el proxy.
Le Proxy
El malo de la película. No tienen idea cuánto lo odio, cuántas horas me ha hecho perder... ¡TE ODIO PROXY!. (Proxy suena a nombre de mujer, tenía que ser, que mujer tan enrollada).
El problema es que aparentemente soy la primera persona en la organización que no usa la Internet solo con Firefox, sino que a veces necesito wget y/o curl, bajar cosas con Emacs (paquetes de Emacs), Gwibber para el Twitter, todo el tema de APT para mantener mi sistema actualizado (y como no existe un repositorio en la organización...) o a veces conexiones no web: IRC y FTP por ejemplo (esta última parte no entiendo qué tiene que ver con el proxy, pero es así, aparentemente; si alguien puede explicarme por qué puede un proxy como squid fastidiar al IRC, se lo agradezco).
Bueno, empezamos con lo básico. La configuración del proxy en Ubuntu se hace en la configuración de red: SUPER seguido de 'red' y ENTER, o en el menú de configuración que se encuentra en el menú de arriba a la derecha.
Ahí hay una configuración por cada interfaz de red que tenga la máquina y por último está la configuración del proxy. Se puede determinar que no hay proxy; o configurar un proxy manualmente, en cuyo caso habría que colocar el nombre o la IP del proxy y el puerto; o, como en mi caso, la configuración automática, en donde se coloca la url de un archivo de configuración automático.
En un mundo ideal, esto debería bastar: todas las aplicaciones que eventualmente hagan uso de la web deberían verificar esta configuración para saber cómo usar el proxy. Pero en este aspecto, Ubuntu no es para nada ideal. Aquí una opinión: ¿Cómo es que con la configuración de red de Gnome basta para que todas las otras aplicaciones se puedan conectar a la red pero no puedan saber cuál es el proxy. El problema es peor y más triste aún: hay aplicaciones gráficas (de Gnome) que no usan esta configuración del proxy, por ejemplo Gwibber y Empathy (de hecho, hasta ahora no he podido resolver esto, así que me conecto al IRC por el webirc de Freenode).
Para que aplicaciones como wget y curl funcionen con el proxy, deben estar definidas las variables de entorno http_proxy y https_proxy.
Las variables de entorno http_proxy y https_proxy deben tener la url de conexión al proxy de la organización. Para que queden permanentemente establecidas esas variables, se coloca lo siguiente en el archivo .bashrc (ajustar a cada caso):
http_proxy="http://proxy.leorg.org:1080/"
https_proxy="https://proxy.leorg.org:1080/"
export http_proxy https_proxy
Todavía falta algo para poder hacer un apt-get update. Resulta que al hacer sudo apt-get update las variables de entorno se pierden, así que para mantenerlas hay que invocar sudo con la opción -E. Pero si queremos usar las interfaces gráficas de APT, como el Gestor de actualización o el Centro de software de Ubuntu hay un problema: ellos no los invocamos normalmente desde la consola, así que no tenemos tiempo de pasarles las variables de entorno a través del sudo.
La solución, seguir las recomendaciones de este artículo, editar el archivo apt.conf:
Acquire::http::Proxy "http://proxy.leorg.org:1080";
Acquire::https::Proxy "http://proxy.leorg.org:1080";
Pero hay un detalle que todavía causa problemas con las interfaces gráficas de APT y el proxy. A veces, un paquete invoca algún script durante el proceso de instalación, y este puede a su vez intentar conectarse a la web con programas como wget. Bueno, como es gráfico y obtuvo las credenciales por otro medio diferente de sudo (por lo cual no le pudimos decir con la opción -E que conserve las variables de entorno) entonces, ese wget no va a saber cómo conectarse al proxy. La solución, es fijar las variables de entorno del proxy al sudo. Para ello se usa el programa visudo y se agrega lo siguiente:
Defaults env_keep = "http_proxy https_proxy ftp_proxy"
Con todo esto, ya tenemos bien dominado a todo lo que es APT, y varias aplicaciones que no toman la configuración de Gnome, pero todavía me quedan pendientes:
  1. Emacs y ELPA
  2. Empathy
  3. Gwibber
IRC no web es lo que más extraño.

Restauración

Para la restauración del respaldo, solo con respecto al correo y los contactos fue algo diferente a trivial (de resto, una simple copia).
Instalé el complemento de Thunderbird llamado ImportExportTools, luego hay que darle clic derecho a la bandeja de entrada, menú Importar/Exportar, opción Importar mbox y elegir Importar uno o más archivos con sus subcarpetas. En ese momento, una ventana de diálogo te permite elegir el archivo mbox a importar, que será el que se respaldó antes de instalar Ubuntu.
Los contactos se importan desde la vista de Libreta de direcciones, en el menú Herramientas, opción Importar.

Algunos paquetes que instalé luego

Emacs
La versión de Emacs que proveen los repositorios oficiales de Ubuntu es la 23. Pues la versión 24 trae una gran cantidad de mejoras que no quería perderme, entre los que más me interesan está el nuevo sistema de gestión de paquetes ya oficialmente soportado por Emacs.
Para poder instalarlo a la Ubuntu registré un PPA (Personal Package Archive) que mantiene unos paquetes de Emacs bien actualizados. Lo conseguí gracias a este artículo.
Los pasos que seguí:
$ sudo apt-get update
$ sudo add-apt-repository ppa:cassou/emacs
$ sudo apt-get update
$ sudo apt-get install emacs24 emacs24-el
Con esto ya tenemos el Emacs24 instalado. Irónicamente, el sistema de gestión de paquetes, la principal razón de instalar esta versión de Emacs, no funciona al 100% porque el proxy no le permite conectarse a los repositorios. Se puede configurar el proxy en Emacs, pero no he podido hacer que funcione todavía.
Otra cosa que tengo pendiente es instalar el soporte completo al idioma español en Emacs y el diccionario de Aspell.
Retoque a LibreOffice
De un excelente artículo acerca de cosas que retocar en Ubuntu después de instalarlo, rescaté, entre otras cosas, la habilitación del menú global para LibreOffice.
Lamentablemente en esta nueva versión de Ubuntu LibreOffice no hace uso del menú global, que es la nueva forma de interactuar con las aplicaciones en Ubuntu, exactamente igual que en MacOS. Se trata de que el menú de todas las aplicaciones se funde con la barra superior del sistema que ya contiene otras cosas como el espacio para las notificaciones, ahorrando bastantes píxeles verticales (que aparentemente son más importantes que los horizontales, ya que el lanzador no desaparece de manera automática como hacía antes).
Para hacer que LibreOffice respete el menú global, basta con instalar el paquete lo-menubar:
$ sudo apt-get install lo-menubar
Restricted Extras
Sin entrar en polémicas, por los mp3 y otros formatos de video:
sudo apt-get install ubuntu-restricted-extras
Cabe acotar que este paquete invoca a un script que intenta bajar archivos de la Web. Si el proxy no está configurado en sudoers (y en todos lados por si a caso) entonces fallará.
Y para escribir en el blog
  • python-docutils
  • rst2pdf
  • mercurial
Solo faltaría configurar mercurial con por lo menos los datos personales del usuario:
$ cat > ~/.hgrc
[ui]
username = Jesús Gómez <jgomo3@gmail.com>
Ctrl-D

Siempre me toca hacer lo siguiente en el Terminal de Gnome

Estoy muy acostumbrado a las combinaciones de teclas de Emacs en el terminal, pero la tecla ALT y F10 disparan otros eventos propios del entorno gráfico (seleccionan el menú de la aplicación, en este caso el terminal de Gnome).
Para evitar que esto pase y funcionen como en Emacs, se modifican las configuraciones pertinentes en la opción Combinaciones de teclas... en el menú Editar. Ahí, se desactivan las teclas de acceso al menú y F10.

Decepciones

  • ¡¡¡PROXY!!! No entiendo cómo no hay una solución única a este rollo.
  • Tenía la esperanza de que una actualización limpia desapareciera ese bug de Firefox tan maldito: arrastra una imagen y TODO el sistema se congela por un minuto aproximadamente.

miércoles, noviembre 23, 2011

Ciclo redactar publicar con Blogger

Tengo la intención de escribir varios artículos en este blog:
  • Despliegue en Django
  • Mi presentación de Git
  • La conferencia Mejorando la web
  • Cita al ensayo sobre SOPA creado por @danielmaxx
  • Algunas cosas viejas que escribí por ahí
Pero habiendo colaborado en algunas revisiones de El blog en español de Python Insider quise poner en práctica el mismo workflow que ellos aplican. Y es lo que estoy haciendo justamente ahora mientras escribo este artículo acerca del mismo workflow (y lo que haré de ahora en adelante).

Le workflow

El mencionado workflow está explicado en el wiki del proyecto de los blogs de Python. Pero básicamente se basa en utilizar un repositorio bajo control de versiones donde un convenio en el uso de los directorios permite distribuir el trabajo.
La parte interesante del workflow es que el trabajo de redacción no se hace en la interfaz que para ello disponga el sitio que almacena y publica los artículos (en nuestro caso, la interfaz web de Blogger), sino que se redacta en un archivo dedicado al artículo, y ese archivo se mantiene en control de versiones. Luego, cuando se esté conforme con el resultado, se publica utilizando un script que sube el archivo como si fuera el artículo (también pudiera usarse el copiar y pegar con la interfaz web).
En particular, el proyecto de los blogs de Python utiliza mercurial como sistema de control de versiones, bitbucket es donde almacenan su repositorio, reStructuredText es el lenguaje de marcas que utilizan para estructurar y formatear los artículos y un script en Python [1] muy específico para subir el archivo al blog.
Una de las más grandes ventajas de trabajar de esta manera es el soporte en la coordinación del trabajo de varias personas sobre el mismo producto que se obtiene al usar el sistema de control de versiones y un repositorio compartido.
Pero cuando se usa para un blog como el mío que solo tiene un autor, todavía hay ventajas.
Primero, el control de versiones. Pero esta vez, en vez de referirme al poder de coordinación, me refiero a la ventaja de contar con versiones que reflejen la evolución de lo que escribo y poder echar para atrás los cambios que quiera.
Segundo, escribir en tu lenguaje de marcas preferido ... punto.
Tercero, escribir en tu editor de texto preferido ... punto.

Ejemplo

Como ejemplo de cómo trabajar con este workflow voy a explicar cómo he escrito esta entrada y cómo lo publiqué.
Le script
El script en Python se llama rst2blogger.py. Se usa la siguiente manera:
$ rst2blogger.py <blog> <.rst>
Lo que hace es convertir el archivo .rst en un contenido en formato html y trata de subir ese contenido en el blog blog. Para ello te pide que te autentifiques con los servicios de Google.
Como este es un script que rápidamente se hizo para este workflow de los blogs de Python, entonces hay que modificarlo un poco para que sirva con el de uno.
Lo primero que hace el script después de todos los imports es definir un diccionario llamado BLOG_IDS, asocia una etiqueta al identificador único del blog. Entonces, simplemente se añade el blog de uno en ese diccionario. Por ejemplo, el identificador único de mi blog es 15836385 [2], entonces asocie el identificador jgomo3 con él. Queda algo así:
# local
import rst2post

BLOG_IDS = {
    'jgomo3':'15836385',                # jgomo3's blog
    'clienttest':'4574580403850978202',
Hay que aclarar dos cosas acerca del script:
  • Él pica el contenido en dos partes: el título, y el resto. Entonces, el título con el que sube el artículo va a ser el que le coloques como título principal en el .rst.
  • La primera vez sube el artículo como un borrador nuevo. Las siguietes veces que publique el mismo blog, simplemente actualiza el blog. Para publicar, se hace desde la interfaz administrativa de Blogger.
Como alternativa a este script, pudiera lograrse algo parecido con una combinación entre rst2html y googlecl.
Le repo
Creé un repositorio en bitbucket para mantener el blog (de ahora en adelante).
Luego, lo cloné en mi máquina para trabajar:
$ hg clone https://bitbucket.org/jgomo3/jgomo3-blog
Siguiendo el convenio de los blog de Python, definí dos directorios:
  • InProgress: que contiene los artículos "en progreso", es decir, los borradores.
  • Published: que contiene los artículo ya publicados en el blog.
$ install -d InProgress Published
Entonces, el trabajo es evidente. Cuando se quiere empezar un nuevo artículo, simplemente se crea un archivo en la carpeta InProgress. Luego, un hg add para hacerle seguimiento con mercurial. hg commit por cada cambio relevante que queremos recordar con mercurial y cuando queramos salvaguardar el trabajo en bitbucket, un hg push (así además puedes mostrar el trabajo a terceros para que le echen un ojo y si quieren pueden colaborar).
$ cd InProgress
$ hg add ciclo-redactar-publicar-blogger.rst

... Ciclo largo de trabajo
.
.    ... Ciclo corto de trabajo
.    .   $ [tu editor favorito o emacs] ciclo-redactar-publicar-blogger.rst
.    .   $ rst2html ciclo-redactar-publicar-blogger.rst > test.html
.    .   # Ver el archivo test.html en un navegador
.    ...
.
... $ hg commit

$ hg push
Le blog
Una vez esté terminado el artículo y se quiera publicar en el blog, se ejecuta el script:
$ rst2blogger.py jgomo3 ciclo-redactar-publicar-blogger.rst
Esto creará un borrador en Blogger. Entonces se navega a Blogger, se aprecia cómo se ve el borrador, se le asigna la fecha de publicación al artículo y se publica.
Por último, se mueve el artículo de la carpeta InProgress a la carpeta Published y se actualiza el repositorio en bitbucket:
$ hg mv ciclo-redactar-publicar-blogger.rst ../Published
$ hg commit
$ hg push
Le FIN
Como ya comenté, de ahora en adelante usaré esta técnica para escribir en el blog.
Por último, por si no lo notaron, mi editor favorito es Emacs, y dejo a su disposición un par de artículos que explican esta misma idea pero desde el punto de vista de un par de emacseros y usuarios del org-mode.
[1]Deben estar todos los archivos .py en el mismo lugar.
[2]Para saber cuál es el identificador único de tu blog en Blogger simplemente observa la barra de direcciones de tu navegador mientras lo editas.

martes, julio 27, 2010

Python ¿qué tiene 3 que no tenga 2?

Esta inquietud ha rondado por la cabeza de muchos desde que salió Python 3.0. En la lista de python-caracas Nhomar hace una pregunta simlar que se reduce a "Técnicamente, cuáles son las ventajas que traerá el python 3.X???". Más allá de los detalles menores como el hecho de que print ya no es una sentencia del lenguaje sino una función integrada, la inquietud real es saber ¿qué tiene Python 3 que no tenga Python 2?.

Luego de leer al respecto en varias fuentes, la respuesta que daré puede ser rara para algunos: nada. De echo, tiene menos. Quieren probarlo, solo les diré que es más fácil hacer que un código en Python 3 corra en Python 2 que lo contrario: puede verse a Python 3 como un subconjunto de Python 2.

No quiero escribir sobre lo nuevo de Python 3 (ya que pueden encontrar mucho material al respecto) sino de lo que he entendido fue la inspiración de Python 3.

Python 3 fue diseñado para honrar el principio "debe haber una-- y preferiblemente una --manera obvia de hacerlo" del Zen de Python[1].

Python 3 ha sido un intento por pulir aún más este lenguaje de pequeños detalles que sus creadores sentían incómodos y existían solo para mantener la compatibilidad hacia atrás del lenguaje. La solución fue eliminar esta compatibilidad. Parafraseando a Guido: "Es una oportunidad que él mismo se está dando para corregir esas decisiones de diseño equivocadas que tomó al principio del desarrollo de Python que no podría corregir sin romper el código de todos"[2].

Los cambios en la biblioteca dan testimonio de que se trata de una cuestión de honrar el sentido común en el diseño del lenguaje, pero sobre todo el Zen de Python referido. Por ejemplo:
  • Renombrar los módulos para que todos los nombres cumplan con la guía de estilo de Python (una sola forma de nombrar los módulos).
  • Eliminar la costumbre de tener dos nombres de módulos (uno de ellos con una c prefijada) si había una versión rápida implementada en C (un solo nombre de módulo).
  • Agrupar los módulos parecidos en un paquete común, por ejemplo, md5 y shasum ahora forman parte de hashlib (un solo punto de acceso para algoritmos similares).
La forma en que se trabaja con el texto es una evidente y clara forma de honrar el Zen. Ahora las cadenas son cadenas son cadenas y eso es todo (sí, énfasis redundando). Y si necesitas una manera de interactuar con los bytes que representan las cadena, tienes el tipo bytes y métodos para codificar una cadena en una secuencia tipo bytes. Todo está más claro ahora y bien separado.

Sin embargo, Python 3 trajo nuevos elementos al lenguaje, como la sentencia with, y la comprensión de conjuntos y diccionarios. Pero estos elementos han sido portados a Python 2 para hacer la transición a Python 3 más fácil.

[1] http://en.wikipedia.org/wiki/Python_3000#Version_3.0
[2] http://www.youtube.com/watch?v=s-fKcZ5pKLE#t=2m20s

Más enlaces sobre el tema:
http://www.b-list.org/weblog/2008/dec/05/python-3000/
http://diveintopython3.org/
http://www.ibm.com/developerworks/linux/library/l-python3-1/

miércoles, julio 21, 2010

Calendario de python-caracas

Actualización: Esta información ya no es relevante. El grupo python-caracas ya no existe, se fusionó con Python Venezuela.

Para mantener más organizado al grupo creé un simple calendario de Google dedicado a python-caracas. Pueden verlo si bajan un poco la página podrán ver el calendario en la columna derecha.

jueves, abril 15, 2010

jgomo3 en todos lados

Actualización

Lo que escribí en esta entrada del blog en el 2010, ya no es pertinente.

Principalmente, Friendfeed se detuvo el 2015.

Por otro lado, Mark Pilgrim, el autor de "Inmersión en Python", decidió en 2011 eliminar el rastro de sus actividades de la Internet, lo que implicó la eliminación de las páginas de sus libros. Nunca supe cuáles fueron bien sus razones, pero siempre he respetado su decisión y sigo agradecido por su aporte y deseándole una buena y larga vida.

Con respecto a los libros, afortunadamente habían archivos de sus páginas y el contenido sigue siendo público (gracias a las licencias con las que fueron publicados). Los libros mencionados pueden conseguirse actualmente en los siguientes enlaces:


Texto original

En el site de mark (el de diveintopython(3) y diveintohtml5) hay un enlace al final de la página denominado firehose (con un tooltip que dice: my comments here and elsewhere).

El día que lo vi, siempre me parecio una excelente idea. Yo quiero hacer lo mismo. La solución fácil: friendfeed.

Creé una cuenta en friendfeed y suscribí casi todos los periquitos de microbloging, bloging y demás cosas suscribibles en esa cuenta, y ahora, si alguien quiere ver mis comentarios solo debe consultar un solo lugar: mi cuenta de frienfeed.

martes, septiembre 09, 2008

Django en un minuto.

A propósito de la recién publicación de la versión estable 1.0 de Django quiero mostrarles este video de "presentación" donde se nos permite saborear las bondades de este framework.



Concretamente el video me pareció genial, dura solo un minuto y es capaz de abrir el apepito de saber más del framework, de investigar qué es eso tan especial que se aprecia en el video. La clave es que va al grano:

* ¿Qué es Django?
* Cómo iniciarse en Django
* Ventajas
** Es fácil y rápido
** Lo rápido que es empezar a trabajar con él
* Un sobrevuelo por el tutorial
* Enganches visuales
** Muestra el administrador web que impresiona
** Muestra unos sites profecionales que usan Django
* ¿Qué hacer luego de haberse iniciado?

La fuente del video la consiguen aquí.

lunes, abril 07, 2008

Filosofía Power Ranger

Ángela me comentaba que se bajó un tutorial de PHP, y se lo ofreció a una compañera de trabajo. Esta le rechazó la oferta argumentando que debe haber una manera de escribir código en Java y se traduzca a PHP si es necesario (me imagino que a la manera de Jython y JRuby, pero a la inversa).
Mientras Ángela me contaba esto, nos encontrabamos cenando Leonardo (mi hijo de cinco años para el momento de redacción de esta entrada), mi esposa Ángela y yo en el comedor.
Continuando con el cuento, me relata el resto de la conversación:

Ángela:
Pero es más rápido que hagas las cosas en PHP que en Java[1].

Cambio de contexto
En eso Leonardo inturrumpe, y el dialogo se traslada de la oficina de Ángela al comedor de la casa.


Leonardo
No siempre el camino más corto es el mejor camino.



... [SIN COMENTARIOS]

Momentos después, Leonardo nos confieza que aprendió esa máxima en Power Ranger Mystic Force.

[1] Supongo que más rápido aun es hacer el trabajo directamente en PHP si el lenguaje objetivo es PHP, que hacerlo en Java para luego traducirlo con alguna hipotética herramienta a PHP.