Marcos Dione: trace2csv

   Publicado:

Remember this? Ok, maybe you never read that. The gist of the post is that I used strace -r -T to produce some logs that we «amassed[sic] [...] with a python script for generating[sic] a CSV file [...] and we got a very interesting graph». Mein Gott, sometimes the English I write is terrible... Here's that graph again:

This post is to announce that that Python script is now public. You can find it here. It's not as fancy as those flame graphs you see everywhere else, but it's a good first impression, specially if you have to wait until the SysAdmin installs perf or any other tool like that (ok, let's be fair, l/strace is not a standard tool, but probably your grumpy SysAdmin will be more willing to install those than something more intrusive; I know it happened to me, at least). It's written in Python3; I'll probably backport it to Python2 soon, so those stuck with it can still profit from it.

To produce a similar graph, use the --histogram option, then follow the suggestions spewed to stderr. I hope this helps you solve a problem like it did to me!


profiling python

Mariano Reingart: Diplomatura abierta en Software Libre

   Publicado:


El año pasado se inició la Diplomatura en Software Libre que impulsamos en la Universidad del Este (La Plata). La primer promoción de estudiantes ya completaron los cursos, destacándose academicamente los siguientes trabajos finales integradores:
Felicitamos y agradecemos a todos los participantes (tanto estudiantes como docentes, tutores colaboradores, personal de la universidad y ONGs: SoLAr, CAdeSoL, FACTTIC) que hicieron posible la primer edición.
Como contribución a la comunidad y para aquellos interesados, a continuación se detalla más información sobre la misma, incluyendo la Edición 2016 que está comenzando este mes (próximo encuentro 14/05).

Organización

La diplomatura son cursos de extensión universitaria orientados a un público en general (estudiantes, docentes, desarrolladores en empresas públicas o privadas y miembros de la comunidad), y no requiere experiencia previa en estas tecnologías. Por ello, abarca distintos módulos con contenidos para cada nivel (desde principiantes a usuarios intermedios/avanzados) y se distribuyen en una serie de 8 cursos a lo largo de un año para contemplar la dedicación mínima necesaria.

Primer cuatrimestre (Mayo, Junio, Julio, Agosto):

Seminario Sw. Libre
(1 mes)
Bases de Datos PostgreSQL
(1 mes y medio)
Redes de computadoras GNU/Linux (1 mes y medio)
Programación I Python
(4 meses)

Segundo cuatrimestre (Septiembre, Octubre, Noviembre, Diciembre):

Ingeniería de Sw. Libre (1 mes)
Sistemas Operativos GNU/Linux
(1 mes y medio)
Desarrollo Web HTML web2py
(1 mes y medio)
Programación II C C++ Python
(4 meses)

Los temarios tentativos y planificaciones iniciales pueden descargarse desde nuestro portal, con información sobre los objetivos, unidades temáticas (generalmente una por semana), metodología, criterios de evaluación, actividades, referencias y bibliografía.

Son 4 cursos por cuatrimestre, pero el único en paralelo es el de programación (contemplando los tiempos necesarios para presentar los contenidos y reforzar conocimientos de aquellos que no tengan una base en estos temas).
Los encuentros presenciales son un sábado vez por mes (opcionales) y la mayor parte de los trabajos y prácticas se realizan a distancia por el campus virtual u otros medios.

Los contenidos por el campus virtual son para una cursada completamente "asincrónica" según la disponibilidad del estudiante (documentos PDF de lectura, enlaces páginas, foros y actividades que no requieren un horario específico). Eventualmente se coordinan sesiones de chat o hangouts para tratar algún tema en particular.

Académicamente, la carga horaria aproximada mínima es 4 hs de dedicación por semana por curso, más los encuentros presenciales y desarrollo de trabajos prácticos.

Encuentros Presenciales:

Se llevan a cabo 8 encuentros presenciales (optativos y recomendados), donde se dictan clases presenciales y talleres sobre los módulos de cada mes, generalmente en cuatro tramos (horario de 8.00 a 16.00):
  • Presentación expositiva de los temas teóricos
  • intervalo (cafe) 
  • Trabajo práctico individual y grupal en PC
  • almuerzo libre
  • Laboratorio de programación en PC
  • intervalo (cafe)
  • Actividad sobre el trabajo final integrador y cierre
Frecuentemente las charlas en los intervalos y almuerzo complementan la parte académica con interesantes debates sobre temas de actualidad relacionados al software libre, aportando experiencias y reflexiones útiles sobre muchos de los contenidos teóricos, en un ambiente distendido, cordial y ameno.

Materiales libres y abiertos:

Principalmente se utiliza la bibliografía libre y abierta publicada por la Universitat Oberta de Catalunya (UOC OpenCourseWare):
Todos los contenidos están fuertemente orientados al Lenguaje de Programación Python, por lo que se utiliza el material de Algorítmos y Programación I (Apunte FIUBA)

También como referencias se pueden ver algunas presentaciones Universidad Carlos III de Madrid (OCW UC3M) y la documentación oficial / sitios de las comunidades locales, como Python ArgentinaPostgreSQL Argentina, web2py, etc.
Para los estudiantes más avanzados, se incluyen artículos optativos sobre el kernel de linux, optimización de consultas, firewalls, etc.

Como complemento se recorren apuntes propios y trabajos académicos (desarrollados al cursar la Maestría de Software Libre de la UOC):
Para el curso "Ingeniería del Software Libre" se presentan metodologías ágiles ("Scrum y XP desde las Trincheras"), el Proceso de Software Personal (materiales de estudio autodidacta), entre otros materiales y recursos.
A modo de ejemplo, se utilizan como referencia varios de los temas investigados en mi tesis de la maestría: "Desarrollo rápido de software libre de alta calidad", entre otras lineas de trabajo.

Actividades y Trabajos Prácticos:

Para una cursada más dinámica y flexible, adaptamos la mayor parte de las actividades optativas para ser realizadas por el Campus Virtual de la Universidad, mediante los Foros y en ocasiones Wiki / Glosario. Este año planteamos incrementar el uso de las herramientas de Cuestionarios de Auto-Evaluación y Chats para mejorar las cuestiones de virtualidad y seguimiento.

En el campus de la universidad se desarrollan debates diversos, por ej: "Licenciamiento de Software (Libre)", "Estructura y funcionamiento de internet", "Comparativas entre motores de bases de datos", etc. También aquellos estudiantes que lo crean conveniente, pueden publicar internamente sus exámenes resueltos para compartirlos y discutir las alternativas / correcciones, comentar dudas, etc.

Se proveen ejercicios modelos y ejemplos concretos, como la Bases de Datos Dell DVD Store 2, tutoriales de programación, sitios y herramientas interactivas, etc.

Estamos analizando materiales de estudios de reconocidos MOOCs y certificaciones, avanzando en contenidos comunes que permitan a los estudiantes certificarse luego en esas tecnologías.

Para las prácticas más técnicas (programación, bases de datos, redes/sistemas operativos) hemos implementado un "Laboratorio Virtual de Software Libre" en un portal educativo abierto a la comunidad: www.softwarelibre.org.ar/moodle
Utiliza el módulo "VPL" de Moodle para facilitar las entregas y corrección automatizada ágil, completamente online (con editor de texto, consola de ejecución y depuración completamente vía web, para poder experimentar libremente sin riesgos y sin necesidad de instalar las herramientas en la PC):


En este sentido, estamos avanzando en un curso comunitario masivo y en linea para enseñar programación de computadoras ("Python para Zombis": documento de trabajo y presentación resumen), traducción al Español de materiales como Python Module of The Week, etc. Ver abajo los exámenes resueltos con más información al respecto.

Obviamente al ser una diplomatura en Software Libre, el código fuente resultante de las prácticas es trabajado y se publica de manera abierta en el repositorio en GitHub:  https://github.com/UniversidadDelEste

Exámenes:

Las actividades de evaluación son mixtas, con estrategias tradicionales y alternativas más modernas (incluyendo multimedia), buscando un aprendizaje critico, constructivo y significativo. Se contemplan tanto el desarrollo y participación en el campus / encuentros, como el resultado final.
Generalmente se realizan a distancia vía un examen domiciliario (con entrega por el Campus Virtual):
  1. Seminario de Software Libre: investigación-acción sobre Wikipedia (PDF)
  2. Bases de Datos PostgreSQL: desarrollar un mini-proyecto sobre datos abiertos (PDF)
  3. Redes de computadoras GNU/Linux: redactar un capítulo/sección de libro libre (PDF)
  4. Programación I Python: desarrollar una actividad de evaluación automatizada (PDF)
  5. Sistemas Operativos GNU/Linux: presentación multimedia sobre temas a elección (PDF)
  6. Desarrollo Web: trabajar sobre una aplicación web2py o similar (PDF)
  7. Programación II C+Python: analizar el proyecto hello de la Free Software Foundation  (PDF
  8. Ingeniería de Software Libre: trabajo final en forma de artículo (PDF)
Si bien hay fechas limites, los estudiantes pueden determinar su propio ritmo de cursada y entrega de actividades, dentro de los limites razonables de cada curso (procurando trabajar en grupo y con acompañamiento docente adecuado).

En la carpeta pública se encuentran ejemplo variados de exámenes de programación resueltos (Python), desde ejercicios simples (PDF, ODT), intermedios (ODT, ODT) y más avanzado (PDF). Además de servir como evaluación, documentan la configuración de una actividad automatizada en la plataforma Moodle (VPL: Laboratorio Virtual de Programación, ver arriba) que puede ser útil como tutorial para otros docentes.
También se pueden mencionar exámenes resueltos de bases de datos PostgreSQL (sobre datos abiertos y públicos): "Encuesta Nacional de Gastos de los Hogares " (PDF), "Elecciones CABA 2013" (PDF), "Censo Hogares y Viviendas" (PDF), "Cajeros Automáticos CABA" (PDF) y "Trabajo Práctico" (ZIP), entre otros.

Gracias a los alumnos por compartirlos dentro de los lineamientos de la dipolomatura para generar recursos educativos libres y abiertos.
Recordar que son documentos académicos preliminares (pueden no estar realizadas las correcciones y observaciones realizadas por los docentes), y revisar la licencia de publicación.

Edición 2016:


Para 2016 esta abierta la inscripción

http://ude.edu.ar/extension/diplomaturas/software-libre-combinada/

También buscamos profesores y tutores que estén interesados en colaborar con el equipo docente (para más información ver propuesta académica completa)
Proximamente se publicará un repositorio institucional con todos los trabajos académicos, y anunciaremos más novedades (invitados, eventos, etc.) vía @softlibre y en el portal.
Desde ya se agradece difusión y toda sugerencia es bienvenida

Juanjo Conti: 1er meetup de Python en Santa Fe

   Publicado:

Cómo surgió

Durante 2006, 2007 y 2008 se llevaron a cabo en la UTN de la ciudad de Santa Fe tres eventos denominados "Python en Santa Fe".

Para muchas personas de la ciudad y alrededores fue su primer contacto con el lenguaje, incluso con la programación.

Luego de eso, las actividades relacionadas con Python llevadas a cabo por porsonas de la ciudad se fueron canalizando a travéz de PyAr, el grupo de usuarios de Python Argentina y si bien nos encontrábamos en eventos a nivel nacional en distintos puntos del país (PyCons, PyCamps, PyDays) casi no nos volvimos a juntar.

El año pasado se empezó a usar mucho la plataforma de meetup.com en la ciudad (hay por ejemplode Ruby, de JavaScript, de Postgres...). Lo que me gusta del esta es que te permite descubrir comunidades que no conocías y que se reúnen en tu misma ciudad (lo que implica conocer nuevas personas, proyectos, etc...).

Fue por eso que hace un par de meses, sin muchas expectativas, cree el Meetup de Python en Santa Fe. Rápidamente llegamos al límite del plan gratuito de 50 miembros y pedí ayuda a la Python Software Foundation para tener una cuenta paga. Luego de aceptar las solicitudes pendientes llegamos a 66 pythonistas en Santa Fe y ya no pude huir del peso del deber: le puse fecha a nuestro primer evento. Uno de los asistentes se encargó de hablar con la gente de un bar y todo estuvo listo.

La idea del primer meetup fue entonces un encuentro social, sin charlas ni slides.

La meetup en sí

La meetup fue muy distinta a lo que me había imaginado que sería.

Habían confirmado unas 17 personas. A muchas de ellas no las conocía. Pensé encontrarme con muchos programadores Python. ¿Podría ser posible esto? ¿Gente que no esté en la lista de PyAr? ¡Hasta había preparado una pequeña encuesta!

No fue así.

  • Más de la mitad faltó sin avisar.
  • De los programadores que fueron, los conocía a todos.
  • Fue gente que sabía poco de programación, pero estaba muy entuciasmada en participar.

Esto último fue lo mejor. Hablamos de dos temas principalmente y de cómo podíamos ayudar con Python. Uno fue arte digital y el otro el banco de alimentos que se está por abrir en la ciudad.

Tal vez pronto surgan novedades de alguna actividad interdiciplinaria relacionado a estos temas.

PyConAr

En un momento de la meetup fuimos intervenidos :) Llegaron tres miembros de la cooperativa Coprinf y nos contaron sobre la organización que se está llevando a cabo para la próxima PyConAr que va a ser en Bahía Blanca y está organizada por un conjunto de cooperativas.

Nos contaron que la idea es que este año el foco esté en la comunidad (en contraste a la anterior que se sintió demasiado empresarial) y en esta línea una de las ideas es que haya un colectivo que salga del norte, pase por varios lugares donde haya comunidades (incluído Santa Fe) y llegue hasta Bahía Blanca.

Se quedaron casi una hora y estuvo re bueno que pasen.

El lugar

Un apartado especial para el lugar.

La música estaba un poco más fuerte de lo deseado y hasta toco una banda. Tenías que arrimarte para escuchar lo que estaban diciendo en la otra punta de la mesa.

Las luces y la ambientación estaban buenas. Nos gustaron unas pinturas en las paredes que cambiaban de color con la luz e incluso vimos cuando las seguían pintando en vivo.

Como nota de colar, la pizzeada no fue tal ya que el bar se había quedado sin pizzas. Nos trajeron unas picadas que si bien estuvieron ricas, terminaron costando un poco más que el precio que nos habían dado para la "pizza libre".

Facundo Batista: Ordenando fotos

   Publicado:


Hace un par de semanas sucediose el PyCamp. En este tipo de eventos, como en tantos otros, o paseos, o reuniones, o lo que sea, pasa que uno lleva "la cámara", pero no la usa todo el tiempo.

Con "la cámara" me refiero al dispositivo para sacar fotos de mejor calidad que uno tiene. Puede ser una reflex toda pipona, o una point and shoot berretona, o algo intermedio (o "bridge") como la que tengo yo (una Canon G15).

Canon G15

Y uno no la usa todo el tiempo por dos razones. La primera es que en general, a menos que sea una point and shoot finiiiiita, molesta un poco llevarla: te ocupa al menos una mano, o rellena bastante un bolsillo, o hay que llevarla al cuello, o hay que llevar todo un bolso al hombro.

La segunda razón es que como las cámaras en los teléfonos avanzaron bastante, uno siempre termina sacando fotos al voleo más con el celular que con otra cosa, y deja para momentos "más cuidados" el usar "la cámara".

Y me pasa todo el tiempo. Ejemplo típico del del PyCamp: tengo la cámara en la mochila, donde la guardé luego de sacar un par de fotos donde estábamos trabajando, pero luego fui a otro lado a preguntarle algo a alguien, y tuve ganas de sacar una determinada foto, y en el momento lo resolví con el teléfono. No iba a volver a buscar la cámara grande. O la sacaba con el teléfono, o no la sacaba.

Entonces, esta combinación de factores hizo que, en los últimos tiempos, termine con una serie de fotos de la cámara grande, más una serie de fotos del teléfono. Separadas.

Yo miro/edito las fotos con distintas herramientas. Pero en general, las veo ordenadas por el nombre del archivo. Entonces, tener dos series de fotos separadas me jodía bastante.

Es por eso que me armé un pequeño script que agarra todas las fotos de un directorio y las renombra en función de la fecha/hora que tiene guardada la foto, quedando ambas series efectivamente mezcladas de forma cronológica al ordenarlas por el nombre del archivo.

Un par de detalles con respecto al script.

  • Todavía está en desarrollo, pero está bastante estable y las últimas veces que lo usé anduvo 100% ok
  • Asume que las fotos de "la cámara" tienen el formato IMG99999.JPG, siendo los 99999 cinco dígitos cualesquiera. Si este no es tu caso, vas a tener que pedirme una mejora, o toquetear vos misma/o el código.
  • Tenés que tener fades instalado, para que te maneje automágicamente las dependencias (acá tenés una explicación al respecto). Si no querés instalar fades, arreglate.

Enjoy.

Facundo Batista: PyCamp 2016

   Publicado:


Durante este finde largo de semana santa hicimos la edición 2016 del PyCamp, el que para mí es el mejor evento del año.

Se realizó nuevamente en La Serranita, un lugar muy lindo y muy cómodo, el Complejo Soles Blancos. A diferencia del año pasado, que fue en Agosto, esta vez a la noche sólo estuvo bastante fresco, :). Las tardes eran con un lindo calorcito, y las noches y madrugadas estaban fresconas, ideal para pasear por la calle o dormir!

Como la vez pasada, hice Buenos Aires - Córdoba (Capital) en micro, y de ahí a La Serranita en auto (a la vuelta lo mismo). Es más, el trayecto de ida lo manejé yo (porque Pancho estaba rotazo), y la vuelta la hizo él, con lo que pude disfrutar más del paisaje.

Alta vista

Como todos los PyCamps, este se dividió mucho entre lo que es Python propiamente dicho, y lo que son otras actividades. Arranquemos con lo que es programación propiamente dicho.

El proyecto más largo en el que participé fue un Tower Defense: el típico jueguito donde uno ubica torres que atacan un flujo de enemigos que se vienen encima, y en función de la habilidad de colocar qué torres y dónde, uno se defiende mejor o peor. La idea era no sólo diseñar y armar el juego, sino también crear una inteligencia artificial que aprendiera a ubicar las torres.

En esto se anotaron casi todos, así que fue con lo primero que arrancamos. Lo más interesante fue la organización. En seguida separamos lo que es "core" de la "ai", y un grupo se quedó arriba y otro nos fuimos para la sala de abajo. No sé bien qué hicieron los de AI, arriba, pero abajo armamos entre todos la estructura básica del core, nos separamos en pequeños grupos, y atacamos todo el código en paralelo, charlando las interfaces/APIs a medida que íbamos agregando o solucionando cosas.

Fue genial. El primer día ya teníamos como un 80% de lo que logramos finalmente, y luego seguimos trabajando. El producto fue un core a todo lujo, con gráficos y todo (usamos pyglet), más una inteligencia artificial que aprendía eficientemente a ubicar las torres. Impecable.

Screenshot del TD

De los proyectos que llevaba yo, en el que más se enganchó la gente fue fades. Como con Nico tenemos los issues bien claritos y clasificados, los chicos encontraban enseguida algo para hacer. Metimos varios fixes y cerramos muchos issues, se avanzó bastante. También se anotaron varios para trabajar en la web de PyAr, se avanzó un poco, sobre problemas de formateo y links rotos (porque no existen, pero también porque apuntan mal internamente en el wiki). No hicimos tanto, quedó pendiente para seguir en otro momento. También otro grupo (principalmente Matu Varela, Mati Barrientos y Toni) estuvieron con la integración del sitio de PyAr y unos bots de Telegram, que originalmente estaban planeados para desparramar info, pero sobre los cuales luego armaron esquemas de moderación de noticias, eventos y trabajos postulados.

Con otros proyectos estuve también bastante tiempo, pero con menos gente. Para Linkode estuvimos charlando mucho con Mati Barrientos y Pablo Celayes, sobre los próximos planes a nivel de interfaz. Decidimos ir a algo como una "single page application" pero que apenas es tal, porque la interfaz de linkode es muy sencilla. Así y todo, la idea es que el "cliente web" use la API de linkode como cualquier otro cliente. Más allá de toda la charla y la decisión de cómo seguir para adelante, Matías va a estar liderando todo el lado "javascript" de linkode, metiendo código él y revisando/empujando el de otros.

Gente trabajando

Para cerrar todo lo hecho, y el PyCamp en sí, hicimos un video! Jose Luis Zanotti tiene pendiente de editarlo y armarlo, así mostramos todo lo que hicimos en un par de días...

Y por otro lado, hubieron varias actividades no relacionadas directamente con programar en Python.

El más centralizadamente coordinado fue un torneo de Tron, que ganó Jose Luis Zanotti Ya habíamos hecho algo parecido en el PyCamp de La Falda, hace varios años, y es notable como uno se engancha mirando a las personas que compiten y cómo juegan. También hubieron clases de sable, una tarde, y noches de juegos de mesa. Yo jugué dos veces al Resistance, un juego donde (aunque tiene soporte de fichas y tarjetitas) lo importante es la interacción entre las personas y como todos se tratan de convencer entre todos de que no son nazis.

La estrella de las actividades de "no programación" fue la reunión de PyAr (gracias Ariel por armar la minuta). Estuvo buenísima, por cuanto y cómo participaron todos. Charlamos de la próxima PyCon, de cómo venía el tema de la creación de la Asociación Civil, y también del PyCamp actual, y cosas que deberíamos mantener o mejorar. Luego de la reunión, un asadazo, que lo preparó (muy bien, como siempre), el anfitrión del complejo, Leandro.

En la reunión

Todas las fotos que saqué yo, acá.

Marcos Dione: ruby-cheatsheet-for-pythonistas

   Publicado:

In a shallow but long yak shaving streak, I ended up learning Ruby (again). Coming from a deep Python background (but also Perl and others), I sat to write down a cheatsheet so I can come back to it time and again:

module Foo  # this is the root of this namespace
# everything defined here must be referenced as Foo::thing, as in
Foo::CamelCase::real_method()

:symbol  # symbols are the simplest objects, wich only have a name and a unique value
:'symbol with spaces!'

"#{interpolated_expression}"  # how to iterpolate expressions in strings

/regular_expression/  # very Perl-ish

generator { |item| block }  # this is related to yield

%q{quote words}  # à la perl!
%w{words}  # same?

def classless_method_aka_function(default=:value)  # Ruby calls these methods too
    block  # ruby custom indents by 2!
end

method_call :without :parens

class CamelCase < SuperClass  # simple inheritance
    include Bar  # this is a mixin;
    # Bar is a module and the class 'inherits' all its 'methods'

    public :real_method, :assign_method=
    protected :mutator_method!
    private :query_method?

    self  # here is the class!
    def real_method(*args)  # splat argument, can be anywhere
        # no **kwargs?
        super  # this calls SuperClass::real_method(*args)
        # comapre with
        super()  # this calls SuperClass::real_method()!

        local_variable
        @instance_variable  # always private
        @@class_variable  # always private
        $global_variable

        return self
        # alternatively
        self
        # as the implicit return value is the last statement executed
        # and all statements produce a value
    end

    def assign_method=()
        # conventionally for this kind of syntactic sugar:
        # When the interpreter sees the message "name" followed by " =",
        # it automatically ignores the space before the equal sign
        # and reads the single message "name=" -
        # a call to the method whose name is name=
    end

    class << self
        # this is in metaclass context!
    end

    protected
    def mutator_method!(a, *more, b)
        # conventionally this modifies the instance
    end

    private
    def query_method?()
        # conventionally returns true/false
    end
end

# extending classes
class CamelCase  # do I need to respecify the inheritance here?
    def more_methods ()
    end
end

obj.send(:method_name_as_symbol, args, ...)

begin
    raise 'exceptions can be strings'
rescue OneType => e  # bind the exception to e
    # rescued
rescue AnotherType
    # also
ensure
    # finally
else
    # fallback
end

=begin
Long
comment
blocks!
=end

statement; statement

long \
line

# everything is true except
false
# and
nil

variable ||= default_value

`shell`

AConstant  # technically class names are constants
# so do module names
A_CONSTANT  # conventionally; always public
# The Ruby interpreter does not actually enforce the constancy of constants,
# but it does issue a warning if a program changes the value of a constant

# case is an expression
foo = case
    when true then 100
    when false then 200
    else 300
end

do |args; another_local_variable|
    # args are local variables of this block
    # whose scope ends with the block
    # and which can eclipse another variable of the same name
    # in the containing scope

    # another_local_variable is declared local but does not
    # consume parameters
end

{ |args| ... }  # another block, conventionally single lined

# Matz says that any method can be called with a block as an implicit argument.
# Inside the method, you can call the block using the yield keyword with a value.

# Matz is Joe Ruby

# yield is not what python does
# see http://rubylearning.com/satishtalim/ruby_blocks.html
# block_given?

a= []  # array
a[0] == nil

ENV  # hash holding envvars
ARGV  # array with CL arguments

(1..10)  # range
(0...10)  # python like
5 === (1..10)  # true, 'case equality operator'

{ :symbol => 'value' } == { symbol: 'value' }  # hashes, not blocks :)

lambda { ... }  # convert a block into a Proc object

# you cannot pass methods into other methods (but you can pass Procs into methods),
# and methods cannot return other methods (but they can return Procs).

load 'foo.rb'  # #include like
require 'foo'  # import, uses $:
require_relative 'bar'  # import from local dir

It's not complete; in particular, I didn't want to go into depth on what yield does (hint: not what does in Python). I hope it's useful to others. I strongly recommend to read this tutorial.

Also, brace yourselves; my impression is that Ruby is not as well documented as we're used in Python.


python

Marcos Dione: ayrton-0.7.2.1

   Publicado:

ayrton is an modification of the Python language that tries to make it look more like a shell programming language. It takes ideas already present in sh, adds a few functions for better emulating envvars, and provides a mechanism for (semi) transparent remote execution via ssh.

A small update on v0.7.2:

  • Fix iterating over the log ouput of a Command in synchronous mode (that is, not running in the _bg). This complements the fix in the previous release.

Get it on github or pypi!


python ayrton

Marcos Dione: ayrton-0.7.2

   Publicado:

This time we focused on making ayrton more debuggable and the scripts too. Featurewise, this release fixes a couple of bugs: one when executing remote code with the wrong Python version and another while iterating over long outputs. The latter needs more work so it's more automatic. Here's the ChangeLog:

  • Fix running remote tests with other versions of Python.
  • Fix tests broken by a change in ls's output.
  • Fix iterating over the long output of a command à la for line in foo(...): .... Currently you must add _bg=True to the execution options.
  • Fix recognizing names bound by for loops.
  • Added options -d|--debug, -dd|--debug2 and -ddd|--debug3 for enabling debug logs.
  • Added option -xxx|--trace-all for tracing all python execution. Use with caution, it generates lots of output.

Get it on github or pypi!


python ayrton

Marcos Dione: ayrton-0.7.1

   Publicado:

A weird release, written from Russia via ssh on a tablet. The changelog is enough to show what's new:

  • Iterable parameters to executables are expanded in situ, so foo(..., i, ...) is expanded to foo (..., i[0], i[1], ... and foo (..., k=i, ...) is expanded to foo (..., k=i[0], k=i[1], ....
  • -x|--trace allows for minimal execution tracing.
  • -xx|--trace-with-linenos allows for execution tracing that also prints the line number.

Get it on github or pypi!


python ayrton

Marcos Dione: trip-planner

   Publicado:

For a long time I've been searching for a program that would allow me to plan (car) trips with my friends. Yes, I know of the existence of Google Maps, but the service has several characteristics that doesn't make it appealing to me, and lacks a couple of features I expect. This is more or less the list of things I want:

  1. Define the list of points I want to go to. No-brainer.
  2. Define the specific route I want to take. This is normally implemented by adding more control points, but normally they're of the same category as the waypoins of the places you want to visit. I think they shouldn't.
  3. Define stages; for instance, one stage per day.
  4. Get the distance and time of each stage; this is important when visiting several cities, for having an idea of how much time during the day you'll spend going to the next one.
  5. Define alternative routes, just in case you don't really have/make the time to visit some points.
  6. Store the trips in cookies, share them via a URL or central site, but that anybody can easily install in their own server.
  7. Manage several trips at the same time.

So I sat down to try and create such a thing. Currently is just a mashup of several things GIS: my own OSM data rendering, my own waypoints-in-cookies idea (in fact, this is the expansion of what fired that post) and OSRM for the routing. As for the backend, I decided to try flask and flask-restful for creating a small REST API for storing all this. So far some basics work (points #1 and #6, partially), and I had some fun during the last week learning RESTful, some more Javascript (including LeafLet and some jQuery) and putting all this together. Here are some interesting things I found out:

  • RESTful is properly defined, but not for all URL/method pairs. In particular, given that I decide that trip ids are their name, I defined a POST to trips/ as the UPSERT for that name. I hope SQLAlchemy implements it soon.
  • Most of the magic of RESTful APIs happen in the model of your service.
  • Creating APIs with flask-restful could not be more obvious.
  • I still have to get my head around Javascript's prototypes.
  • Mouse/finger events are a nightmare in browsers. In particular, with current leafLet, you get clicked events on double clicks, unless you use the appropriate singleclick plugin from here.
  • Given XSS attacks, same-origin policy is enforced for AJAX requests. If you control the web service, the easiest way to go around it is CORS.
  • The only way to do such calls with jQuery is using the low level function $.ajax().
  • jQuery provides a function to parse JSON but not to serialize to it; use window.JSON.stringify().
  • Javascript's default parameters were not recognized by my browser :(.
  • OSRM's viaroute returns the coordinates multiplied by 10 for precision reasons, so you have to scale it down.
  • Nominatim and OSRM rock!

I still have lots of things to learn and finish, so stay tunned for updates. Currently the code resides in Elevation's code, but I'll split it in the future.

Update:

I have it running here. You can add waypoints by clicking in the map, delete them by doublecliking them, save to cookies or the server (for the moment it overwrites what's there, as you can't name the trips or manage several yet) and ask for the routing.

trip-planner elevation openstreetmap osrm python flask leaflet javascript jquery

Share