FisaDev

Apple vs Samsung

2011-04-21T17:14:00.000-03:00

Apple acaba de demandar a Samsung, alegando que toda su linea Galaxy son copias de los productos iPhone.

Es decir, Apple dice que esto:

es una copia de esto:

Hasta acá pueden discutir todo lo que quieran acerca de qué tan parecidos o diferentes son. Pero lo gracioso viene ahora. Samsung, un año antes de que salga el iPhone, estaba mostrando al mundo esto:

Repasemos los tres aparatos en el órden que fueron saliendo al mercado:

(Samsung F700 - Apple iPhone - Samsung Galaxy S)

En mi opinión Samsung simplemente siguió con su estilo, mientras que en el medio apareció Apple con productos que se le parecen. Pero si Apple quiere decir que Samsung le copió, entonces tendríamos que decir que en realidad ellos le copiaron a Samsung.

Apple, Apple... cada día me caes menos bien.

(me enteré de esto en una nota de Android Community)

Voto electrónico con Python y Ubuntu

2011-04-18T17:55:00.002-03:00

Buenas! Hoy escribo post largo, pero que creo que era necesario que alguien lo escriba :)

Hay mucha gente hablando sobre voto electrónico y lo que se hizo en Salta, pero laverdad es que pocos tienen conocimiento de qué se hizo realmente, cómo funciona, ydemás. Muchos opinólogos que sacan conclusiones acerca de lo magnífico o terrible que es,pero a partir de cosas que adivinan o inventan. Y remarco que pasa en los dos lados,tanto de parte de los detractores como de parte de los defensores de este sistema.

Así que primero lo primero: como le gusta decir a un amigo, "desasnémosnos". Empecemosentendiendo cómo funciona el sistema de voto electrónico que se utilizó en Salta.Como soy programador es lógico que mi explicación va a incluir unas cuantas cosas bientécnicas, pero también voy a abarcar otras más referidas al proceso.

Luego de la explicación también voy a incluir algunos de los planteos más comunes quesurgen, y las respuestas a esos planteos. Así que si durante la explicación se lesplantea algún cuestionamiento, estén atentos a si no lo respondo en esa sección.

Y recién después de eso voy a plantear mi opinión (por si a alguien le interesa, jeje),y dejar abierto el debate para que todos opinen y pregunten :)Por mi salud mental y la del debate, abstenerse de opinar quienes no tengan ganas deleer todo el post.

Ah, y casi me olvido: ¿por qué escribo yo sobre esto, y cómo se lo que se? Porque haceun tiempo empecé a trabajar para la empresa que desarrolla el sistema (MSA).¿Eso le quita objetividad a lo que digo? Puede que sí en la parte de opinión, pero no enlo referido al funcionamiento, es información y hechos verificables :)

No está de más aclarar que todo lo que digo en este post es opinión y palabramia y no de la empresa para la que trabajo, ya que se trata de mi blog personal. Asíque por cualquier cosa, yo (Juan Pedro Fisanotti, DNI 32.726.247) soy el responsable.

La parte objetiva: funcionamiento del sistema

Podemos dividir al sistema en tres grandes partes: el proceso de votación en sí, elrecuento por mesas, y el recuento final donde se transmiten y suman los recuentos detodas las mesas.

El hardware que vamos a usar:

Para la votación en sí y el recuento de las mesas se usan pcs especiales que vamos allamar "máquinas de votar" (más detalles después). Para transmitir la información delas mesas también se van a utilizar máquinas de votar (aunque no las mismas, sinootras dispuestas especialmente para la tarea). Y como se imaginarán los que tenganconocimientos técnicos, del "otro lado" hay servidores que van a recibir esainformación a la hora del recuento global (en este caso el "otro lado" está ubicadoen el tribunal electoral).

Las máquinas de voto merecen un poco más de explicación, ya que tienen algunascaracterísticas especiales:

Consisten en una valija con una pc todo en uno (pantalla táctil), una batería deemergencia, una impresora térmica, y un lector/grabador de RFID.
La pc no tiene ningún tipo de almacenamiento ni conexión a ninguna red. Sí tieneuna lectora de DVD.
La batería de emergencia garantiza alimentación suficiente para cortes no tanprolongados, mientras que si se espera una ausencia de energía prolongada lasmáquinas también poseen los cables necesarios para conectar una batería de auto, quele da autonomía suficiente para una votación completa.

Y finalmente, dentro de lo que podemos considerar como "hardware", están las boletasde voto electrónico. Son boletas con papel para impresión térmica, y un chip RFID depoco alcance dentro.Hay varios tipos de boletas: las que se utilizan para la apertura de las mesas, las devoto, y las de cierre y transmisión. Después vamos a ir viendo cuándo se utiliza cadauna.Es importante ya ir sabiendo que una vez que el chip se graba con datos, ya no puede seralterado. Se graban y se "queman" de manera que no se pueda modificar la informaciónalmacenada.

El software:

Para la votación en sí y el recuento por mesa las máquinas de votar van a usar unsistema que vamos a llamar "sistema de voto".Para la transmisión de los datos se va a usar un "sistema de transmisión".Y en los servidores vamos a tener el "sistema de recuento global".(Son todos nombres que pongo yo en este post para entendernos, vale la aclaración)

Tanto las máquinas de votar como los servidores corren Ubuntu (en el caso de lasmáquinas de votar, con modificaciones para que tengan solo lo necesario para elsistema). Y las aplicaciones desarrolladas por MSA para este sistema están escritascasi en su totalidad en el lenguaje de programación Python.¿Base de datos de los servidores? Postgresql. ¿Y de las máquinas? No usan ningún sistemade base de datos (después van a entender por qué no es necesario. Si les digo ahora quelas máquinas de voto no guardan info, probablemente no entiendan cómo puede serpor ejemplo que hagan el recuento, jeje).

¿Recuerdan que les conté que la máquina de votar no tiene ningún tipo de almacenamiento?Entonces, ¿cómo puede tener el sistema de votación o el de transmisión?Simple: ambos sistemas se distribuyen en CD antes de comenzar la votación (livecds deUbuntu customizados, con cada sistema ya instalado y configurado). Como pueden imaginarsehay medios para garantizar que estos CDs no sean alterados. Los mismos son generados enuna única tirada con la presencia de los fiscales, son precintados, y luego se abren eldía de la elección. Y para los más técnicos: cada CD tiene un detalle de los hashs MD5 detodos sus archivos, que un fiscal podría luego comparar contra el maestro que posee eltribunal electoral. [EDIT: ya no usamos MD5, ahora usamos SHA512]

Y la gente:

En el proceso van a participar las mismas personas de siempre (presidentes de mesa,fiscales, el tribunal electoral, etc.), y un grupo nuevo de personas: los técnicos enlas escuelas. La labor de estos técnicos va a ser la de soporte a las autoridades dela elección en cada escuela, y van a ayudar a transmitir los datos en conjunto con lospresidentes de mesa.

Ahora sí, votemos con el sistema. El proceso:

Arranca la mañana, los presidentes de mesa tienen que hacer la apertura de las mesas.Este proceso va a permitir que la gente comience a votar con la máquina.Para ello necesitan de:

Una máquina de votar (normalmente es una máquina por mesa, pero es posible plantearotros esquemas).
El sistema de votar (livecd).
Sus credenciales (con chip RFID que los identifica como presidentes de mesa).
Una boleta de apertura de mesa en blanco.

El presidente de mesa inicia el sistema de votar (que arranca automáticamente al bootearel CD), se identifica con sus credenciales que le permiten abrir la mesa que tiene asignada,y elige dentro del sistema la opción de apertura de mesa.Esto le grabará e imprimirá la boleta de apertura, que después va a poder utilizar paravolver a abrir la mesa en caso de reemplazo de la máquina o reinicio por cualquiermotivo (abajo explico un poco más esto de poder reemplazar la máquina o reiniciarla).Este acta impresa es el documento legal que el presidente de mesa requiere, y ademásel proceso de apertura le permite a la máquina saber qué opciones debe presentar alos votantes, ya que todos los livecds son iguales.

Abierta la mesa, elige la opción de poner la máquina en modo de votación, y ya está,tenemos una máquina preparada para que la gente comience a votar.

¿Y cómo votan las personas?

Pepe votante llega a la mesa, presenta su DNI. Normalmente a Pepe le habrían dado unsobre para que entre al cuarto oscuro. Pero en este caso le dan una boleta de voto (delas que les conté antes) que no tiene datos, y está en blanco en uno de los lados.Pepe se dirije a la máquina de votar, inserta su boleta en la máquina.

Vale aclarar en este punto: la boleta todavía está en blanco! en ningún momento la boletatiene datos sobre quién es Pepe. Y la máquina no tiene ningún tipo de conexión de red,aparte de que el presidente no tiene contacto con la máquina, por lo que el presidenteno puede decirle a la máquina de alguna manera "es Pepe el que está votando" (salvo queel presidente y la máquina hagan un curso acelerado de telepatía antes de empezar lavotación). Esto es crucial para que el voto sea anónimo.De hecho el presidente puede darle a Pepe cualquiera de las boletas que tiene, e inclusopodría darle a Pepe la opción de que elija la boleta que él prefiera.Y no está de más aclarar que la máquina también verifica que la boleta se encuentrevacía. En caso de no cumplirse esa condición, expulsa la boleta apenas se la ingresa

En la pantalla de la máquina aparecen las opciones para votar. Estas opciones van adepender de la votación, pero básicamente Pepe va a tocar la cara del candidato quequiera para cada cargo que se esté eligiendo (de cada candidato aparecen todos losdatos lógicos, como nombre, partido, etc.).

Importante: los candidatos aparecen todos del mismo tamaño, con los mismos datos, yen orden aleatorio cada vez que son mostrados, para no dar ningún tipo de ventaja.

Cuando Pepe ya ha elegido todo la máquina le pregunta si desea confirmar su voto. Pepepuede elegir no confirmarlo y volver a armar su voto, o confirmarlo. Al confirmarlo laboleta se imprime, y se guarda lo elegido por Pepe dentro del chip RFID.

Pepe debe cerciorarse de que lo que salió impreso en la boleta es lo que él queríavotar, ya que lo impreso es lo que cuenta. Y además puede verificar lo grabado en elchip pasando la boleta por el lector de la máquina, que le presenta por pantalla loque el chip contiene. Y puede hacer esto en cualquier máquina (que no poseen conexiónentre sí), con lo que en este punto tenemos una seguridad importante, una pieza enel rompecabezas que tenemos que acordarnos:

Hasta el momento del voto en sí incluido, es imposible que la máquina nos mienta, ya quelo que cuenta es lo que está en la boleta, y podemos ver lo impreso y el contenido delchip.

Sí, ya se, faltan cosas para estar seguros de todo el sistema. Sean pacientes :)

Finalmente, Pepe dobla su voto para que nadie vea lo impreso y lo deposita en unaurna de cartón, igual a las de las elecciones tradicionales (acá es donde empezamosa ver que este sistema es de boleta electrónica, pero no de urna electrónica. Algo quees crucial para ayudar a que sea transparente).

Después de Pepe vendrá Luis, Juan, José, y todos los votantes de esa mesa.

Y en este punto viene otra aclaración crucial: la máquina NO VA CONTANDO LOS VOTOS QUEGRABA E IMPRIME! No, no los cuenta. NO, como dije, no los cuenta. ¿Y cómo se cuentanentonces los votos? Paciencia, un poco más abajo lo voy a explicar. Pero ahora loimportante es eso, que la máquina no va contando los votos.¿Y por qué es tan importante? Porque le puede pasar cualquier cosa a la máquina, que nova a afectar a la votación. Si se apaga, un psicópata la parte con un hacha, le cae unrayo o lo que sea que le impida seguir funcionando, basta con buscar otra máquina,volver a hacer la apertura (que se hace rápidamente con la boleta de acta ya grabada),y listo. Seguimos votando.

Incluso nos permite independizar a la mesa de la máquina. Los votantes de una mesapodrían votar en cualquier máquina, ya que la única tarea de la máquina es emitir lasboletas electrónicas, y no ir llevando el recuento.Para los más técnicos: esto nos permite hasta aplicar un poco de teoría de colas ybalancear la carga entre las mesas.

Son las 6 de la tarde (o un poco más). Terminan de pasar todos los votantes, tenemos quecerrar la mesa y realizar el recuento.

El presidente de mesa sigue un procedimiento similar al de la apertura de la mesa consu credenciales y un acta de cierre en blanco, solo que en este caso elige laopción de cierre de mesa. Iniciado el proceso de cierre de la mesa llega el momento decontar los votos.Tradicionalmente se habría abierto la urna, contado a mano los votos contenidos en lossobres, y anotado el resultado en un acta en papel.En este sistema lo que hacemos es abrir la urna, sacar las boletas de voto, y pasarlasuna a una por el lector de la máquina, que va contando los votos y mostrándonos porpantalla lo que cuenta.Los fiscales también están presentes durante el recuento para fiscalizar el procedimiento,de la misma manera que podían hacerlo en el voto tradicional.Es importante recordar que las boletas tenían impreso el voto, y que el presidente esresponsable de observar que lo que dice la boleta es lo mismo que la máquina muestrapor pantalla al pasar el voto. Y en todo momento es posible ver el total de lo que lamáquina lleva contado.

Y otra cosa importante es que cada chip tiene un serial único (similar a una dirección mac),que le permite al sistema evitar contar dos veces el mismo voto. Esto mismo se puedecomprobar con tranquilidad al realizar el recuento, pasando dos veces una misma boleta.El sistema rechaza el segundo intento informando que ya ha sido contada anteriormente.Y esto no implica un riesgo para el anonimato del voto porque como ya vimos, no existemanera práctica de asociar a la boleta con la persona que la utilizó.

Cuando se han pasado todos los votos el presidente de mesa le indica a la máquina devoto que se ha terminado el recuento, y la misma le imprime el acta de cierre con elrecuento realizado (lista de partidos con votos para cada uno y demás). Esta informaciónse imprime y se guarda en el chip del acta, y se vuelve a imprimir y guardar en el chipde una segunda boleta: la de transmisión.

Aquí un segundo punto crítico de control: al estar el recuento impreso en las boletas ypor haber podido controlar todo el recuento viendo lo que los votos tenían impreso, lamáquina de voto tampoco puede mentirnos hasta este punto. A este punto llegamos conun acta cuyos datos impresos son completamente verificables, donde la máquina no tuvoposibilidad de alterar esos datos sin que nosotros nos demos cuenta.Tema aparte es lo que se vaya a transmitir, ya llegamos a eso, pero es importante quesepamos que esas actas no pueden ser "inventadas" y que son la evidencia física de loque la gente votó.
¿Se dan cuenta de que hasta este punto siempre podemos controlar a la máquina? Adiferencia de la creencia de que es imposible estar seguro que lo que dice una máquinaes real, acá el proceso mismo nos permite tener esa seguridad. La clave está en elproceso, y no en la tecnología en sí.

Bien, tenemos los recuentos de las mesas, verificables y seguros. Llegó el momento detransmitir estos datos al tribunal electoral para realizar el recuento global.

El presidente de mesa se dirige a la máquina de transmisión (una por escuela), donde seencuentra el técnico responsable de esa escuela.El técnico inicia la máquina con el sistema (livecd) de transmisión, y conecta estamáquina a internet (por ADSL, 3G o conexión satelital, dependiendo del caso ydisponibilidad). Se autentica con su credencial y certificados SSL.Para los lectores con conocimientos técnicos: se usa SSL para cifrar la transmisión,con certificados para autenticar ambos lados, tanto al servidor como al cliente.

El técnico pasa la boleta de transmisión que trae el presidente (quien sigue a su lado)por el lector de la máquina. La máquina envía los datos al servidor, y el servidordevuelve una imágen con lo que debería tener impreso la boleta de transmisión (elrecuento).El técnico y el presidente de mesa verifican que el servidor reconstruyó un recuentoidéntico al impreso en la boleta de transmisión, y cuando ambos concuerdan en que escorrecto, vuelven a pasar la boleta por el lector y confirman la transmisión.

Del lado del servidor esa boleta se marca como ya recibida, y sus valores se agreganal recuento global de manera automática.Los más rápidos ya deben estar preguntando: ¿y qué pasa ahora con eso de que la máquinano puede mentir? ¿Los servidores no pueden manipular el recuento global?Bien simple: las actas de cierre y las urnas no se tiran a la basura, se guardan. Y portanto seguimos teniendo la evidencia física verificable, cierta, que las máquinas nopueden alterar. Tenemos las actas, que por el proceso sabemos que no tienen error. Esoevita que las computadoras puedan mentir.

Y aparte de esta seguridad, también se dispone de los mecanismos tradicionales deverificación: los partidos tienen dentro del tribunal electoral a sus fiscales, quepueden verificar que lo recibido se corresponde con lo que los fiscales en las mesasobservaron en el recuento.

Fin del proceso.

¿Y cómo se compara esto con la seguridad que todos tenemos sobre el sistema tradicional?Bueno, tendríamos que desmitificar un poco esa seguridad.

Comparemos por partes.

El sistema tradicional no nos otorga ninguna seguridad respecto a que los presidentesde mesa y fiscales realizan el recuento adecuadamente.En el sistema de voto electrónico expuesto, ellos también podrían alterar los valores,pero si analizamos bien vemos que les sería mucho más difícil, ya que elrecuento no es un simple papel escrito a mano, sino que se deben pasar votos reales poruna máquina. No podemos hacer que un voto para el candidato X cuente como un voto parael candidato Y, porque la máquina lee X y suma X. En papel tranquilamente el presidentepuede modificar esos valores (y hasta tiene boletas con las cuales rellenar las urnaspara que coincidan).Y si confían mucho en los presidentes de mesa y creen que estas cosas no pasan, entoncesmiren lo sucedido recientemente en Chubut, donde llegó a haber diferencia de 800 votosen un acta...Así que respecto al recuento en las mesas, el voto electrónico con el sistema planteadonos otorga más seguridad que el voto tradicional.

El sistema tradicional tampoco nos otorga ninguna seguridad respecto a la "transmisión"de los datos. Estoy seguro de que la gran mayoría de los que leen esto nunca antes sehabían preguntado "¿cómo se llevan las actas y las urnas para el recuento global?". En elsistema tradicional eso es clave, y sin embargo no tenemos manera de verificar que quiense haga cargo de dicho transporte (correo, gendarmería, etc.) no altere el contenido,modificando las actas o las urnas.En el sistema que explicamos también podría suceder que se alteren los contenidos de lasurnas y las actas, pero se encontrarían con un problema: deberían hacer que coincidancon lo que se transmitió antes, lo que les sería imposible, ya que lo transmitido se leedesde el chip RFID que no puede ser modificado una vez grabado, y además no es escrituraa mano sino una impresión.En este punto entonces también ganamos seguridad mediante el sistema de voto electrónico.

Aparte de esos puntos, en el sistema tradicional también eran posibles muchas otrastrampas, como el robo/ocultación de boletas del cuarto oscuro, que la digitalización yunificación de la boleta ya no permiten (esto es una ventaja también en los sistemas devoto en papel con boleta única). Además de el hecho de que al mostrar todos los candidatosen órden aleatorio y no depender de cuántos fiscales y boletas pueda poner cada partidoen las mesas, se favorece la igualdad de condiciones para los partidos, no perjudicandoa los más chicos.

Comparando entonces con lo que explicamos antes, objetivamente podemos afirmar queel sistema de voto electrónico implementado en Salta nos otorga seguridades que el vototradicional, en papel, no nos otorgaba. Y sigue siendo verificable, no se convierte enuna caja negra que no podamos controlar.Por ello es importante antes de creer que el sistema de voto electrónico expuesto esinseguro, ver si las inseguridades que planteamos no existen también en el sistema devoto tradicional (papel). Porque la realidad es que como todo sistema lo que se utilizóen Salta no es perfecto, pero sí mucho más seguro y controlable que el sistematradicional.

Algunas preguntas comunes (FAQ)

¿Pero X no es inseguro? Donde X es algún aspecto del proceso o sistema explicado.Antes de plantear una pregunta de este estilo, primero plantear si el mismo aspectoera o no seguro en el voto tradicional.Pongo esto primero, porque en muchos lugares las principales críticas que se le hacenal sistema son cosas que son igual o incluso menos seguras en el voto tradicional.Así que antes de plantear una pregunta de este tipo, piensen en cuál sería larespuesta para el voto tradicional.
¿Confiar en los presidentes de mesa para el recuento o la transmisión no es inseguro?Perfecto ejemplo de lo que planteé antes.Respuesta: también se confía en los presidentes de mesa en el voto tradicional. Sino podemos confiar en los presidentes de mesa, ningún sistema (papel o electrónico)va a ser seguro... Y de hecho, este sistema de voto electrónico limita mucho más lascosas malas que un presidente de mesa puede hacer.
¿Cuál es la principal ventaja de cambiar de sistema?En mi opinión la principal ventaja son las seguridades que este nuevo sistema nos day que el sistema tradicional no nos daba, que comenté antes.Y además de ello está la velocidad de recuento. En Salta por ejemplo, a las 21:15 yase tenía el 100% del recuento de las mesas electrónicas. Solo 3 horas, y estamoshablando no de Capital, sino de una provincia con geografía compleja, donde algunasde las mesas estaban ubicadas en escuelas perdidas en los cerros. Y se trataba de másde 700 mesas, es decir, más de 200.000 personas. Y en 3 horas con un recuento exacto,no un aproximado o una estimación.Y no falta quien pregunta: ¿pero eso no es mucho tiempo? ¿por qué demora tanto si lascomputadoras suman de manera instantánea?Simple: recuerden que el recuento en las mesas se hace pasando a mano cada boleta porla máquina, eso es un proceso manual (y es así por seguridad), que lleva tiempo(muchas veces demorado por las mesas que cierran tarde porque llega un colectivo devotantes a las 17:45, las discusiones con los fiscales, etc.).
¿Qué tanto se gana en la velocidad del recuento?Respondido antes :)
¿Las actas y los votos impresos en algún momento se cuentan a mano para estar seguros?Esto es decisión de la autoridad electoral. En el caso de Salta, sí, se realizó elrecuento manual y es ese el que cuenta como definitivo, mientras que el recuentoelectrónico es considerado provisorio. Dependiendo del caso, el tribunal electoraldecide si se deben examinar manualmente todas o parte de las urnas, pero esto yaes decisión de ellos. Lo importante es que el sistema permite hacer este recuentomanual, cosa que no es posible en sistemas de urna electrónica.Y enganchada a esta pregunta: Pero si al final van a contar todo a mano, ¿paraqué hacer el voto electrónico?Por todas las ventajas de seguridad que vimos antes, que por lo general el sistematradicional no nos garantiza.
Usan software libre para hacer el sistema (Ubuntu, Python, etc.) Pero, ¿el código delsistema desarrollado por MSA es abierto?Por el momento no. A mi personalmente me encantaría que lo sea, pero no soy quientoma esa decisión, y también hay razones válidas para no hacerlo. No es que la empresalo cierre por ser malvada y querer andar escondiendo cosas, es un poco infantil creerque una empresa es malvada por no abrir el código de lo que hace. El software librees algo genial, yo de hecho soy muy adepto a ello. Pero a la hora de abrir el códigode algo así de delicado hay muchas cosas a tener en cuenta.Igualmente es un tema que se habló en la empresa, la posibilidad existe e inclusohay buena predisposición al respecto. :)Y de todas maneras, por lo que vimos antes podemos darnos cuenta de que la seguridaddel sistema no depende de que se conozca el código, ya que son las boletas impresaslas que garantizan dicha seguridad.
¿El costo del sistema no es demasiado elevado en comparación al tradicional?En realidad no. Algo que la mayoría desconoce es que las máquinas son propiedad dela empresa, y el estado las alquila para la votación (algo considerablemente menoscostoso que comprarlas). Y además por lo general cuando realizan esta pregunta,desconocen mucho de toda la logística que requiere una elección tradicional, que noes menor, más la cantidad de boletas que deben imprimirse por persona (en el vototradicional recuerden que no basta con una boleta por persona. Para cubrir todaslas opciones se deben imprimir como mínimo tantas boletas como partidos haya porpersona).
¿No es inseguro que la transmisión se realice por internet?No gracias al cifrado por SSL y la autenticación de los dos extremos con suscertificados. Esto garantiza que los datos no van a ser alterados y que no pueden serespiados por alguien que escuche la conexión.
En países más avanzados, como Holanda, se prohibió el voto electrónico porque erainseguro. ¿Por qué ustedes creen que no lo es?Porque lo que se usó en esos países eran urnas electrónicas, algo que es muydiferente a este sistema. Es como decir que no hay que comer peras porque en algúnlugar se descubrió que las bananas son tóxicas. Sencillamente no son lo mismo.El principal problema acá es que la frase "voto electrónico" se utiliza para muchascosas que son muy distintas entre si.(nota completamente fuera de tema: yo soy alérgico a las bananas, pero me encantanlas peras, así que si ese razonamiento es válido sería una pena para mi :P)
¿Alguien no podría leer lo que tiene el chip de la boleta de un votante a distancia,y así dejaría de ser secreto su voto?El chip tiene muy poco alcance (unos centímetros). Y aunque tuviese más alcance comopara que alguien a la distancia lea los datos, sería imposible por la cantidad deinterferencia que habría. Recuerden que alrededor del votante hay varioscientos de boletas dando vueltas. Ni hablar del diámetro que debería tener una antenaque lea a distancia (metros).
¿Y mediante un ataque de Van Eck no sería posible ver las pantallas de las máquinas devoto a distancia?Esto se soluciona sencillamente ubicando a las máquinas cercanas entre sí, de esa maneragenerando la interferencia suficiente para que el atacante no pueda distinguir entreuna máquina y otra.
¿Qué pasa si se corta la luz?Explicado en la primer parte, cuando hablaba del hardware (batería de emergencia +posibilidad de usar baterías de auto).
¿Y si se rompe una máquina?Explicado también, no pasa nada. Se busca otra, se realiza la apertura, y se sigue.
¿La impresora se puede quedar sin tinta?La impresora no usa tinta, es térmica (lo aclaro porque hay gente que ha preguntadoesto en capacitaciones).
Otra pregunta que no haya puesto yo acá:Posteala en los comentarios, si tengo idea respondo, y si no averiguo :)

La parte subjetiva: lo que yo opino

De lo explicado pueden sacarse un montón de conclusiones, pero creo que lo más evidentees que este sistema está lejos de ser "una computadora que uno no sabe como funciona yte puede mentir en lo que cuenta". Las numerosas instancias de control nos permitengarantizar la legitimidad de los resultados de manera simple, incluso otorgándonos másseguridad que en una votación tradicional.¿Sistema perfecto? Seguramente no. Pero sin dudas un avance respecto al voto en papel.Un sistema que nos da un poco más seguridad respecto a la base de nuestra democracia,la votación.

Y no puedo dejar de mencionar otra cosa que me llega más de cerca. Como pythonero,ubuntero, y amante del software libre en general, es un orgullo que esto pueda lograrseen base a estas herramientas. Debería ser algo que tengamos como ejemplo de todo loque se puede lograr en base a software libre, de su potencial y bondades. Algo quees logro de personas que también son miembros activos de las comunidades de softwarelibre de Argentina, que muchas veces se nutren en dichas comunidades y que sabendevolver lo que aprenden en tantos aportes (dando charlas, colaborando o iniciandoproyectos, respondiendo en listas de correos, etc.).

En resúmen, buena tecnología al servicio de un proceso electoral más claro y seguro :)

Ubuntu 11.04

2011-04-09T08:43:00.002-03:00

Ya se viene! Veremos si me adapto a unity o termino instalándole gnome normal.

Review Alienware M11X R2

2011-01-26T18:34:00.001-03:00

Ayer finalmente me llegó la máquina nueva: una Alienware M11X R2.
No voy a hacer una super review detallada, ya hay unas cuantas en la web (que me leí antes de comprarla), sino que solo voy a poner mi visión resumida.

Pero antes, las especificaciones:

Micro: Intel Core i7 640UM (quadcore, 2.26 Ghz)
RAM: 4GB DDR3 de 800Mhz (dual channel)
Video: Nvidia GeForce GT 335M (1GB de memoria)
Disco: 500GB SATA II de 7200rpm
Pantalla: WLED de 11', 720p
Otros: bluetooth, HDMI, display port, card reader, cámara, etc.

Puntos a favor:

Potencia: vuela, así de simple. Corre el COD4 Modern Warfare 2 con todos los gráficos en máximo, y ni lo siente.
Tamaño: tiene el tamaño de una netbook de 12', entra perfecto en la mochila, es portable. No entiendo todavía cómo entran las cosas que tiene dentro de un espacio tan reducido.
Diseño: futurista, me gusta más que cuando lo veía en fotos. Se ve y se siente muy robusta.
Duración de batería: 6 horas con poca exigencia, 2 horas jugando, es bastante.
Chiches: Se pueden personalizar los colores de todas las luces, tiene un indicador de batería abajo para cuando está apagada, puede cargar energía a otros aparatos por USB estando apagada, etc.

Puntos en contra:

Peso: acostumbrado a una netbook de 1kg, los 2kg y algo que pesa me resultan no tan cómodos en la espalda.
Pantalla reflexiva: la pantalla refleja demasiado, muy molesto usarla en ambientes bastante iluminados.
Soporte para Linux: desde Linux no puedo hacer varias cosas, como cambiar el color de las luces, o elegir qué aceleradora utilizar.
Puerto VGA: no tiene, tengo que conseguir un adaptador para poder usar mi monitor.

Fotos :)

La magia existe

2010-12-23T15:26:00.000-03:00

La magia existe. Los magos existen.

Personas con poder para crear mundos enteros y manipular sus leyes para volar, hacerse invisibles, o cualquier cosa que sus mentes sean capaces de imaginar. Magia que construye, conoce, transforma o destruye.
Magos que dedican sus vidas ocultas a perfeccionar sus habilidades mágicas, con largas horas de estudios y experimentos impensables. Que forman cofradías en las cuales comparten conocimientos, técnicas y descubrimientos. Cofradías donde los aprendices reciben el arte de manos de gurúes poderosos, y donde muchos combinan sus poderes para lograr cosas aún más increíbles.
Tan increíbles que su magia ya está presente detrás de la vida cotidiana del mundo. Pero son solo los magos quienes conocen y comprenden su verdadero poder y lo continúan aprovechando para transformar la realidad a gusto, a veces para bien y otras no tanto. Al tiempo que para el resto, son solo personas con gustos extraños.
No son quienes conocen solo un poco de magia, y esta se convierte en un simple medio para algún objetivo temporal. Los verdaderos magos descubren el placer en el solo hecho de conocer la magia, experimentar, descubrir. Crean y conjuran nuevos hechizos solo para llevar su poder al límite, y así cultivar su habilidad, expandir su entendimiento.

La magia existe. Los magos existen. La gente los suele llamar "programadores".

Charlas en las Jornadas de Software Libre de Junín

2010-12-02T09:50:00.000-03:00

Hace poco tuve la suerte de poder ir a las Jornadas de Software Libre que se organizan en Junín. El evento estuvo muy bueno, me sorprendió el nivel de la organización, y aprendí un montón en las charlas. Y de paso me invitaron a dar una charla de Django fuera de cronograma :)

Por suerte filmaron todas las charlas (algo que debería ser costumbre en este tipo de eventos), y hace unos días las subieron ya a blip.tv. Algunas de las charlas también se habían dado en PyConAr 2010, así que pueden aprovechar quienes se perdieron ese evento :)

Pueden ver todas las charlas aquí: http://unnoba.blip.tv/posts?view=archive&nsfw=dc

(y mi charla es esta)

PyConAr 2010

2010-10-18T20:36:00.000-03:00

Y pasó la PyConAr 2010!

La verdad que fue algo muy, muy bueno, desde varios puntos de vista:

Por el lado técnico fué genial aprender muchas cosas de parte de personas que tienen tantos conocimientos. El capital intelectual desplegado en la conferencia fue impresionante.
Desde profundizar en conceptos avanzados como los expuestos en la charla sobre tipado de Daniel Moisset, hasta comprender cosas que debería haber aprendido bastante antes, como unicode (Facu Batista).
La lista de cosas aprendidas sigue con docutils, empaquetado para windows, pymaemo, pygtk, los módulos de roberto, y unas cuantas más.
Y también me gustó y sirvió poder aportar mi pequeño grano de arena, con la charla de Django que espero haya salido bien :)

La verdad que con solo eso la conferencia ya valía la pena.

Pero también está el lado "comunitario", y en eso se sintió muy bien ser parte de una movida fuerte como es la de PyAr.
Esta bueno ver tanta gente comprometida por la difusión y evolución de una tecnología, al punto de regalar horas de trabajo, viajar desde lejos, compartir lo que conocen e incluso aportar económicamente a la causa, convencidos de que lo que tienen es algo que vale la pena difundir.
Viniendo de un pasado no tan lejano de estar metido en otras tecnologías (Microsoft, .Net, etc), todavía me sorprende lo que se logra con una comunidad sin estructuras jerárquicas, títulos oficiales, ni empresas que la banquen.

Y finalmente esta lo humano, el contacto de uno a uno.
Lo compartido en los momentos más informales, como el asado o la salida del sábado, es impagable. Conversaciones y debates con gente que además de ser profesionales tienen calidad humana. Gente que no tiene problemas en compartir una solución a un problema, conocimientos, consejos, junto con bromas, buena onda, y una cerveza de por medio :) (aunque yo no tome, igual me parece genial, jaja).

Así que gracias a todos los que de alguna manera ayudaron a hacer esta PyCon.
Espero ya al próximo evento, y ahora de vuelta al trajín diario, que por suerte este tiempo tiene bastante de Python en el medio (en la facu, en el trabajo fijo, y en el trabajo freelance, weeee! tengo suerte).

Se viene Ubuntu 10.10

2010-09-15T11:45:00.000-03:00

Se viene se viene!

Netbooks, "bajo rendimiento"?

2010-09-13T17:21:00.000-03:00

Hoy pensando me di cuenta de algo que me sorprendió un poco.

Para ubicarse:
Máquina: una netbook HP (modelo mini 1020) con un micro de 1.6 ghz, 2 gb de ram. Ni hablar que no tiene aceleradora de video ni nada por el estilo.
Sistema operativo: Ubuntu netbook edition 10.10, usando el escritorio de ubuntu normal, no el de netbook, con compiz fusion a full (muchos efectos activados).

Ahora los números:
Uso del procesador mientras...
...giro los escritorios en el cubo en 3D, con las ventanas también en 3D flotando sobre el cubo: 10%
...paso entre ventanas abiertas al estilo "albumes", en 3D: 10%
...abro GIMP (programa de edición de imágenes, estilo Photoshop): 50%
...instalo actualizaciones: 50%

¿Cómo puede ser que sobre tanta máquina si es una netbook, que en teoría es una máquina de "bajo rendimiento"?
De hecho uso esa máquina para casi todo. Para lo único que no puedo usarla es para juegos (por la falta de aceleradora).

Mi configuracion de Vim

2010-07-20T14:45:00.000-03:00

Vim es un editor de texto muy bueno. Es algo bastante diferente a lo normal, para quienes vienen de editores de código gráficos, sea el block de notas, Eclipse, o cualquier otro.
Se puede usar por línea de comandos y todas las cosas normalmente se hacen desde el teclado. Tiene un enfoque bien simplista, pero es super configurable y personalizable, hay cientos de plugins útiles.

En el PyCamp 2010 me lo mostraron por primera vez (algo había visto antes, pero no en profundidad), y en poco tiempo se convirtió en mi editor de cabecera para cualquier lenguaje o tipo de archivo de texto.
Con el tiempo aprendí a meterle mano y adaptarlo a mis gustos, y además de las 4 máquinas donde lo uso (incluyendo el celular), también algunos amigos estaban usando mi configuración. Así que me decidí a documentarla bien y subirla a algún lado, para ordenarla y para que si a otros les sirve también puedan aprovecharla.
Incluye cosas interesantes como un muy buen debugger para Python, autocompletado mejorado, navegador de clases, etc.

Info, descarga y demás yerbas aquí: fisa-vim-config

Programar programas que programan

2010-07-16T21:51:00.000-03:00

Lisp es un lenguaje bastante particular (lleno de paréntesis, jeje). Entre las características que tiene hay una que hasta donde conozco, no poseen otros lenguajes: permite modificar la sintaxis del lenguaje mismo.
Explicándolo sin entrar en demasiado detalle, uno puede escribir macros (que no son nada ni cercano a las macros de los otros lenguajes, solo el nombre tienen parecido), que son "programas que escriben programas". Lisp utilizará esas macros que escribamos para "leer" el código en la sintaxis que inventemos, y a partir de él "escribirá" código (programas) que finalmente serán los que se ejecuten.

Algo así:

inventamos una sintaxis
programamos una macro, que es una función que recibe código en esa sintaxis inventada, y genera código en la sintáxis normal
hacemos programas usando nuestra sintaxis inventada
lisp convierte nuestros programas con sintaxis inventada, en programas válidos, usando nuestra macro
lisp finalmente ejecuta los programas que se crearon en el paso anterior

Cosas interesantes en eso:

La macro es una función, pero recibe código como parámetro! En Lisp, la diferencia entre código y datos es bastante borrosa, uno puede manejar código como si fuesen datos fácilmente. El código son en realidad listas, y podemos transformarlas como a cualquier lista normal.
Programamos programas que programan! O sea, hacemos un programa que es capaz de crear código y después ejecutar el código que creó.
Si trabajamos en una empresa donde nos pagan por cada línea que programamos... a quien le pagan las líneas que nuestros programas programan? a nuestros programas?? :)

Con un poco de idea nomás, uno ya puede hasta crear macros que permitan escribir código lisp invertido, y que se termine ejecutando como si estuviese bien escrito, jeje.

Aplicaciones en Google Chrome

2010-07-07T11:07:00.001-03:00

Gracias a Tavo Tell me entere de la buena noticia: ya se pueden probar las apps en Chrome!
Es el esquema de aplicaciones que se va a usar en Chrome OS.

Aquí el tutorial sobre como activarlas e instalar las tres primeras: gmail, gdocs y gcalendar.
http://bit.ly/aYhdTq

En la web encontré alguien que armó una app para greader:
http://bit.ly/bK90vp

Y yo armé una app para twitter:
http://bit.ly/bgKFUf

(un detalle: si quieren bajar las aplicaciones y chrome les da un error de como deben ser servidas, o solo se les baja y no saben como instalarlas, entonces guarden el archivo, después cambien la extensión del archivo a zip, descompriman en una carpeta, e instalen desde la carpeta como instalaron las tres primeras)

Consola bpython

2010-06-29T17:56:00.000-03:00

Para los que no la conocen, bpython es una consola de python bastante interesante, con autocompletado, integración con servicios como pastebin, y otras cosas.

Pero no me gustaban los colores que trae por defecto, jeje, así que me arme mi theme estilo vim:

El archivo de tema es el siguiente:

[syntax]
keyword = y
name = k
comment = b
string = r
error = r
number = r
operator = k
punctuation = k
token = k
paren = k

[interface]
background = d
output = k
main = k
prompt = k
prompt_more = k

3 tools

2010-06-13T18:08:00.000-03:00

The 3 tools I'm using at work, on one picture :)

(Guido: Python, Guido's t-shirt: Google App Engine, Pony: Django)

iPad news

2010-06-10T09:23:00.000-03:00

This is a screenshot of my Google Reader today :)

Videos PyDay Rafaela 2010

2010-05-21T10:42:00.001-03:00

Ya están disponibles los videos de las charlas del PyDay Rafaela 2010!

Pueden disfrutarlos aquí:
http://pydayrafaela.blip.tv/

PyDay Rafaela 2010

2010-05-09T17:53:00.001-03:00

Qué bueno que estuvo el PyDay Rafaela 2010!

Las charlas salieron muy buenas, y asistió una cantidad de gente bastante alta (fuimos unos 92 en total). Agradezco mucho a la gente que viajó desde otros lugares del país para venir a dar las charlas, y a los que participaron o ayudaron en la organización. Todos se pasaron, y permitieron que este evento se haga realidad dando un paso muy importante para la difusión de Python en nuestra zona. Gracias!!!

Por mi parte, tuve la suerte de poder dar una charla de Django. En estos días estamos organizando cómo subir el material y los videos de las charlas. Apenas tengamos las cosas subidas, posteo avisando.

Mientras tanto dejo una foto robada del blog de Juanjo :)

PyDay Rafaela 2010

2010-05-02T13:48:00.001-03:00

El 8 de mayo en la UCSE de Rafaela, hacemos un PyDay!

Es un evento donde se darán charlas sobre el lenguaje de programación Python. La entrada es gratuita, y quienes deseen participar pueden ya registrarse en el sitio del evento.
Para información y registración, el sitio es: http://www.pyday.com.ar/rafaela2010

Python es un lenguaje de programación poderoso y fácil de aprender. Cuenta con estructuras de datos eficientes y de alto nivel y un enfoque simple pero efectivo a la programación orientada a objetos. La elegante sintaxis de Python y su tipado dinámico, junto con su naturaleza interpretada, hacen de éste un lenguaje ideal para scripting y desarrollo rápido de aplicaciones en diversas áreas y sobre la mayoría de las plataformas.

Si pudiese...

2010-04-12T16:32:00.000-03:00

cd mundo
hg up -r -365
...

El más juego más grande del más mundo!

2010-03-27T17:39:00.001-03:00

Para quienes siempre quisieron participar en el desarrollo de un juego, esta es su oportunidad, y ni siquiera necesitan saber programar! :)
Gente de PyAr (Python Argentina) va a participar de la PyWeek, una semana de competencia en la que el objetivo es desarrollar un juego. Pero lo interesante es que van a permitir que cualquier persona pueda aportar contenido al juego, diseñando tus propios mini-juegos dentro de él.
Para enterarse de más y participar, entren a:

La prensa en China

2010-03-25T14:31:00.001-03:00

Cómo la mayoría sabrá, Google cerró su sitio de China (www.google.cn) por no estar de acuerdo con la censura que el gobierno de ese país le obligaba a tener. El gobierno habló públicamente sobre la decisión, pero también envió las siguientes instrucciones a todos los medios de prensa del país, acerca de cómo deben informar sobre el asunto.
Después de leerlas, siento pena por la población de China. Es una dictadura peor de lo que pensaba...

(sacado del Washington Post, lo traduje rápido para que lo puedan leer quienes no sepan inglés)

A todos los editores en jefe y administradores:
Google ha oficialmente anunciado su retirada del mercado de China. Este es un incidente de alto impacto. Ha desatado discusiones de los usuarios de internet que no están limitadas al ámbito comercial. Por ende por favor presten estricta atención a los siguientes requerimientos para el contenido durante este período:

A. Secciones de noticias:

1. Solo utilicen el contenido del sitio web del Gobierno Central; no utilicen contenido de otras fuentes.

2. Al hacer re-posting no deben cambiar el título. (n. del t.: re-posting = postear el contenido en otro sitio)

3. Las recomendaciones de lectura deben apuntar al sitio principal de contenido del Gobierno Central.

4. No produzcan páginas de tópico relevante; no creen sesiones de discusión; no lleven a cabo reportes de investigaciones relacionadas.

5. Programas en linea con expertos y estudiantes sobre esta materia deben solicitar autorización por adelantado. Este tipo de producción de programas auto iniciada está estrictamente prohibido.

6. Administren cuidadosamente los comentarios en los post de noticias.

B. Foros, blogs, y otros tipos de secciones interactivas:

1. No está permitido mantener discusiones o investigaciones sobre el tópico de Google.

2. Las secciones interactivas no deben recomendar este tópico, no posicionen este tópico y comentarios relacionados al inicio.

3. Todos los sitios por favor quiten todo texto, imagen y sonido y video que ataque al Partido, Estado, agencias del gobierno, políticas de Internet con la excusa de este evento.

4. Todos los sitios por favor quiten todo texto, imagen y sonido y video que apoye a Google, dedique flores a Google, pida a Google quedarse, felicite a Google y otros que tengan un tono diferente al de la política del gobierno.

5. En tópicos relacionados a Google, administren cuidadosamente los intercambios de información, comentarios y otras sesiones interactivas.

6. Administradores en jefe de las diferentes regiones por favor asignen esfuerzo humano específico para monitorear la información relacionada a Google; si existen información acerca de incidentes en masa, por favor repórtenlos con el tiempo suficiente.

Le solicitamos al Grupo de Monitoreo y Control un seguimiento inmediato del monitoreo y control de las acciones detalladas en las directivas anteriores; cuando cualquier problema sea descubierto, por favor ponganse en contacto con las respectivas sesiones con el tiempo suficiente.

Lineamientos adicionales:

-- No participen ni reporten en los comunicados de prensa/información de Google.

-- No reporten acerca de Google ejerciendo presión en nuestro país por medio de personas o eventos.

-- Los reportes relacionados deben poner nuestra historia/perspectiva/información en el centro, no provean a Google de materiales con los cuales atacar políticas relevantes de nuestro país.

-- Utilicen los puntos de vista acerca de Google abandonando China publicados por los departamentos relevantes.

Fuente: artículo del Washington Post

n900

2010-03-15T23:40:00.001-03:00

un detalle que vale mas que mil palabras: el n900 trae de fabrica una consola de linux instalada :)

PyCamp 2010, día 4

2010-03-08T18:51:00.002-03:00

Bueno, ya estoy en Retiro, en un rato estoy saliendo para Rafaela. Así que posteo el resumen de hoy. Probablemente después haga un post más completo con mis conclusiones de lso 4 días.

Algo muy interesante de hoy fué el hacking con OpenCV. Se hizo un programita que detecta cuando hay una cara cerca del monitor, si no hay nadie pone solo el protector de pantalla, y si hay alguien lo saca. Está genial :).

Y a la tarde se hizo el cierre, donde se expuso brevemente las cosas que se habían logrado en cada uno de los proyectos, y se charlaron algunas ideas para el próximo PyCamp, y PyCon.

Estoy muerto, pero estuvo todo muy, muy bueno. Después haré el resumen. Saludos!!

Pycamp 2010, día 3

2010-03-07T20:39:00.003-03:00

Resumen de hoy :)

A la mañana me quedé medio dormido, jeje, porque anoche nos habíamos quedado hasta las 4 a.m.

A la siesta participé en un mini-cursito de empaquetado de aplicaciones Python para Debian. La verdad que era más complejo de lo que esperaba, pero nada que un programador no pueda hacer. Conclusión: tengo que aprender setuptools

Más tarde participé en el Bug Day de Python: cada uno elegía algún bug de Python y trataba de mandar un parche con la corrección. No pude hacer ningún parche, pero aprendí un poco viendo código de cómo está hecho Python, lo que estuvo bueno.

Y ahora a la noche, después de comer empanadas y panqueques, vuelvo a programar un poco el juego que empezamos el sábado.

Saludos!!

update!: me acabo de enganchar en una reunión de otro juego que se va a desarrollar para una competencia, veremos que onda :)

PyCamp 2010, día 2

2010-03-07T18:32:00.000-03:00

Ayer no postee porque no tuve tiempo en todo el día, así que posteo ahora el resumen. Supongo que esta noche volveré a postear con el resumen de hoy

Lo más interesante de ayer fue el sprint de Django. Sprint = gente que se junta a programar, Django = framework para hacer desarrollo web usando Python, el mejor que probé hasta ahora. O sea, los que querían se juntaron para sobre todo corregir bugs en Django, para la versión nueva que va a salir dentro de unos días. Sinceramente fui más que nada para ver y aprender, porque pensaba que estaba a un nivel en el que yo no podía aportar mucho. Pero para mi sorpresa, terminamos corrigiendo un bug de Django juntos con Javi :). Mi granito de arena para Django, así devuelvo algo de todo lo que me está sirviendo.

Por la tarde me enganché en el momento de cocos2d (el framework para juegos que nació en un PyCamp anterior, que estamos usando para el juego que empezamos el sábado). Me enganché medio tarde, pero estuvo bueno, me ayudó a entenderlo mejor.

Finalmente, a la noche tuvimos el "fogón", pero sin fuego porque no se consiguió leña. Se empezó hablando de los temas más comunitarios, objetivos, realidad de Python en Argentina, etc. Se habló también de PyCon Atlanta 2010 y PyCon Argentina 2010. Y después se terminó hablando de política, sociedad, valores, ideologías, etc. Discusiones acaloradas pero muy interesantes. Algo parecido a los threads de PyAr, jajaja.

Hoy viene siendo interesante también, pero esta noche hago el resumen. Saludos!

PyCamp 2010, día 1

2010-03-05T21:22:00.003-03:00

No voy a hacer un post muy completo, eso lo dejo para cuando vuelva. Pero cada día voy a postear un breve resumen de como pasé/pasamos el día.

El viaje fue largo... salí de Rafaela el jueves a las 11 de la noche, y recién llegamos al lugar hoy a las 13, justo para la comida :).
El lugar muy bueno. Todavía no pude recorrer mucho, pero tiene hasta para hacer cayack (o como se escriba, jeje).

Está todo super organizado el tema de wifi, hay cables y antenas atadas con cinta por las paredes, jeje. Y por suerte no se necesitó usar mi router (hubiese sido para renegar nomás).

Lo primero que se hizo a la tarde fué presentar todos los proyectos, y anotar cuántos interesados había en cada uno. A partir de eso se organizó un cronograma, armado como para favorecer la participación el los proyectos más votados. Pero todos los proyectos quedaron en el cronograma, y cada uno elije en cuáles participar y cuáles no :).

De hoy, el proyecto en el que más participé y me interesó fue el de desarrollo de un juego de tipo "Tower Defense", usando la librería para juegos en Python COCOS2D. Es una librería que se había empezado a desarrollar en un PyCamp anterior, jeje.

La verdad que tenía miedo de no poder aportar mucho, pero en un rato nomás ya estaba a tono y codeando para modificar la lógica de disparo de las torres :D.

Y ahora, a la noche, algunos seguimos codeando, mientras otros están con juegos de mesa, o más relajados.

La gente hasta ahora genial!

Apple vs HTC

2010-03-04T15:38:00.005-03:00

Alguien vio el detalle de las pantentes que Apple esta usando para demandar a HTC? Es un desastre, tienen patentadas cosas que existen desde hace 20 años, que existían mucho antes de cualquier iPhone. No se cómo les da la cara para hacer algo así...
Una de las pantentes por ejemplo, es sobre tener objetos en memoria que se refieren a elementos en la pantalla. Cualquier programa con ventanas tiene eso! Existe desde hace décadas!!

Cualquiera que sabe de programación, viendo el detalle de las patentes aquí, puede darse cuenta del fraude que esto es. La mayoría de las pantentes son sobre cosas que no inventó Apple, y que existían desde hacía años antes que el iPhone...

Nunca me había gustado mucho Apple, pero después de esto, sinceramente la imagen que tenía de ellos cayó hasta lo más hondo. En lugar de competir haciendo mejores productos, están tratando de matar a la competencia con un fraude legal...

Debian en G1 con Android 2.1

2010-02-22T10:56:00.008-03:00

Bueno, después de lo que anduve renegando, pude hacer andar Debian en una HTC Dream con Android 2.1.
Anoche me senté un rato y armé tutoriales para que otros puedan hacerlo si les interesa, junto con los archivos necesarios.

Es algo bastante raro y específico, a pocos les va a interesar, pero para esos pocos escribo :)

En mi G1 estoy corriendo Android 2.1, con la ROM KiNgxKxlicK AOSP 2.1 versión 1.6.1

Aquí pueden bajarla, no voy a hacer un instructivo sobre cómo instalarla porque el tema de ROMs en Android es más que extenso, y hay muchos tutoriales dando vueltas por la web.

Puede que los pasos que detallo en este tutorial no funcionen exactamente igual en otras ROMs y otros dispositivos, pero con probar no se pierde nada más que tiempo :).

Lo que sí o sí es necesario, es que la ROM que estén usando sea rooteada (es decir, que tengan permisos de root). Si no es una ROM rooteada, no van a poder hacer andar ni el instalador, jeje.

Para hacer andar Debian en Android, me basé en el contenido de dos foros que hablaban sobre el tema, más algunas modificaciones de las que me di cuenta solo. Al final agrego los links a esos foros para quienes quieran profundizar o ver la info original. El verdadero mérito va para los autores de esos posts, ya que lo que yo hice fueron pequeñas modificaciones sobre su trabajo.

Finalmente, asumo que quien quiere correr Debian en su celular es porque conoce un mínimo de Linux. No me voy a detener a explicar cómo editar un archivo de texto por línea de comando, ni cosas por el estilo, jeje.

Qué tal anda?

La verdad que anda mucho mejor de lo que yo esperaba. Recordemos que se trata de un celular, un aparato con recursos muy limitados. Pero con esos recursos se puede llegar incluso a levantar una interfaz gráfica.

Sin interfaz gráfica es un pájaro: vuela. Con la interfaz gráfica es un reptil: se arrastra, jeje.

Además, al levantar la interfaz gráfica puede suceder que el equipo se quede sin memoria RAM y empiece a cerrar aplicaciones para liberar memoria. Y al cerrar aplicaciones, puede cerrarnos el Debian que está corriendo de fondo, lo que resulta muy molesto.

Yo particularmente lo uso por linea de comandos, sin nada de interfaz gráfica, así que no tengo problemas.

Me puede romper el celular?

En los posts originales aclaran que lo que se hace no afecta al sistema operativo del celular (Android), por lo que no debería haber riesgos. Igual no me hago responsable por lo que a cada uno pueda pasarle en su celular por seguir los pasos que aquí detallo.

Tutorial

A) Instalar Debian

Bajar los archivos necesarios desde este link: debian_aosp21_fisadev.zip

Conectar el celular a la PC en modo de almacenamiento, o sacarle la SD y conectarla a la PC con un adaptador o lector de tarjetas.

Crear en la memoria SD una carpeta con nombre "debian", y descomprimir dentro los archivos que contiene el zip.

Volver a colocar la SD en el celular, o desconectarlo de la PC.

Por seguridad, reiniciar el celular, ya que en algunas ocasiones el sistema de archivos queda como de solo lectura.

Desde un emulador de consola/terminal en el celular, ejecutar:
```
su
cd /sdcard/debian
sh installer.sh
```

B) Iniciar Debian y configurar las cosas básicas

Con lo hecho antes Debian ya está instalado, pero necesitamos levantarlo y hacer algunas configuraciones iniciales.

Desde un emulador de consola/terminal en el celular, ejecutar:
```
su
cd /sdcard/debian
sh bootdeb
```

Esto va a iniciar Debian. Cuando haya terminado de iniciar (les deja el prompt para empezar a escribir), ejecutar:
```
sh /scripts/onetime.sh
```
Esto nos va a pedir configurar una contraseña para el usuario root. Háganlo, es necesario.

Agregamos algunos repositorios básicos. Editamos el archivo /etc/apt/sources.list agregándole al final:

deb http://ftp.debian.org/debian lenny main contrib non-free
deb-src http://ftp.debian.org/debian lenny main contrib non-free

Agregamos la configuración básica para que pueda utilizar la conexión de internet wifi del celular. Editamos el archivo /etc/network/interfaces y le agregamos al final:

auto tiwlan0
iface tiwlan0 inet dhcp

Después de hacer esto, tenemos que salir de Debian ejecutando:

exit

Ahora, cada vez que queramos levantar Debian, ejecutamos:

su
cd /sdcard/debian
sh bootdeb

Y siempre hay que salir usando "exit" (y no cerrando la aplicación así nomás)

Con esto ya es suficiente para tener un Debian desde línea de comandos. Los tutoriales que siguen son completamente opcionales.

C) Aumentar el tamaño del sistema de archivos

El Debian que tenemos instalado corre sobre un sistema de archivos contenido en un archivo de imagen, el debian.img. Esa imagen puede resultar un poco chica si vamos a instalar un entorno gráfico, o muchas aplicaciones. Así que si necesitamos hacerla más grande, estos son los pasos:

Prestar atención a dónde se debe ejecutar cada comando, si en el celular o en la PC!.

Conectar el celular a la PC en modo de almacenamiento, o sacarle la SD y conectarla a la PC con un adaptador o lector de tarjetas.

Copiar el archivo debian.img de la SD a una carpeta en la PC, que a partir de ahora llamaremos PATH_PC

Desde la consola/terminal de la pc, ejecutar esto reemplazando TAMAÑO por el tamaño que queramos. Ejemplo: para 3.5 GB poner 3500999999:

cd PATH_PC
dd if=/dev/zero of=debian2.img seek=TAMAÑO bs=1 count=1 
mke2fs -F debian2.img
mkdir debian
mkdir debian2
mount -o loop debian.img debian
mount -o loop debian2.img debian2
cd PATH_PC/debian
cp -R -f * PATH_PC/debian2
umount debian
umount debian2

(si no funciona reinicar la pc y volver a intentar)

cd PATH_PC
rm -r -f debian
rm -r -f debian2
rm debian.img
mv debian2.img debian.img
chmod a+x debian.img
chmod 777 debian.img

Copiar el archivo debian.img de la PC a la carpeta debian de la SD.

Volver a colocar la SD en el celular, o desconectarlo de la PC.

Por seguridad, reiniciar el celular, ya que en algunas ocasiones el sistema de archivos queda como de solo lectura.

Desde un emulador de consola/terminal en el celular, ejecutar:
```
su
cd /sdcard/debian
sh bootdeb
```
(eso nos inicia Debian, ya deberían saberlo, jeje)
```
cd /var/lib/dpkg/updates
rm -r -f *
dpkg --configure -a
```

Después de hacer esto, tenemos ya un Debian con mucho más tamaño para jugar :D

D) Instalar un entorno gráfico

Para asombrar a nuestros linuxeros amigos, podemos instalar un entorno gráfico completo y jugar con nuestro Android como si fuese una PC de escritorio. Se arrastra de lento, y a veces se cierra solo por falta de memoria, pero anda al menos por los segundos necesarios para causar el efecto "waaaaah!" :)

Recordemos que si queremos instalar un entorno gráfico, deberíamos aumentar el tamaño del sistema de archivos.

Como los pasos no cambiaron del tutorial original, les dejo directamente el link a ese tutorial (si en algún momento desaparece, tengo una copia local, pidanme y la subo):

Instalar entorno gráfico.

(Está en inglés, si alguien necesita traducción, pida nomás)

E) Links originales

Instalar Debian en HTC Dream.

Cambiar el tamaño del sistema de archivos.

Instalar Debian en HTC Hero.

Windows PowerShell

2010-02-19T10:42:00.002-03:00

Alguien vió lo que es PowerShell? Es una uber-copia de la consola de Linux, pero para Windows y hecha por Microsoft. Y no digo que es copia porque los veo parecidos o porque sea fan de Linux. Lo digo porque pusieron hasta los mismos comandos! "ls", "ps", "diff", "more", "man", "cp", "mv"...

Al menos no me siento tan "fuera de casa" en la maquina del trabajo, jeje...

Hackers vs. Crackers

2010-02-16T01:27:00.011-03:00

En un post de Buzz recomendé un libro para "hackers", e inmediatamente (ni 5 minutos) alguien por chat me preguntó por qué lo recomendaba a "piratas". Me hizo acordar que la mayoría tiene una idea bastante errada de lo que significa la palabra "hacker", así que posteo esta lectura obligatoria para cualquiera que quiera usar esa palabra:

(extracto de un escrito de Eric Raymond. El tipo no me cae bien, pero acá tiene razón)

Existe una comunidad, una cultura compartida, de programadores expertos y magos de las redes, cuya historia se remonta décadas atrás a los tiempos de los primeros miniordenadores de tiempo compartido y los tempranos experimentos con ARPAnet. Los miembros de esta cultura crearon el término "hacker". Los hackers construyeron Internet. Los hackers hicieron de Unix el sistema operativo que es hoy día. Los hackers hacen andar Usenet. Los hackers hacen funcionar la WWW. Si eres parte de esta cultura, si has contribuido a ella y otras personas saben quién eres y te llaman hacker, entonces eres un hacker.

(...)

Existe otro grupo de personas que se llaman a sí mismos hackers, pero que no lo son. Son personas (generalmente varones adolescentes) que se divierten irrumpiendo ilegalmente en ordenadores y haciendo "phreaking" en el sistema teléfonico. Los auténticos hackers tienen un nombre para esas personas: "crackers", y no quieren saber nada de ellos. Los auténticos hackers opinan que la mayoría de los crackers son perezosos, irresponsables y no muy brillantes, y fundamentan su crítica en que ser capaz de romper la seguridad no le hace a uno un hacker, de la misma manera que ser capaz de arrancar un coche con un puente en la llave no le convierte en ingeniero de automotores. Desafortunadamente, muchos periodistas y escritores utilizan erróneamente la palabra "hacker" para describir a los crackers; esto causa enorme irritación a los auténticos hackers.

La diferencia básica es esta: los hackers construyen cosas; los crackers las destruyen.

Para el que le interese, este es el texto completo.

Google Buzz

2010-02-12T10:53:00.005-03:00

Qué me gusta y qué no me gusta de Google Buzz:

Una buena excusa para no usar Facebook, así la gente deja de insistirme en que me una al "libro de caras".

Lindo reemplazo para Twitter, me es más cómodo tenerlo integrado en el correo que tener que loguearme en otro sitio nuevo.

Mucha gente que conozco lo puede ver, no como me sucedía con Twitter (no es tan usado por estos lados).

Se integra bien con otras cosas que uso, como Blogspot, Google Reader y Picasa Web. De hecho este post es de mi blog, y aparece solo tambien en Buzz :D.

Cómodo, simple, no sobrecargado. Bien a la "google way"

Se puede desactivar, aunque muchos no se den cuenta. Vean abajo de todo de Gmail.

Se metió un poco a la fuerza, no daba muchas opciones para no probarlo, y el link para desactivarlo es casi invisible.

Todas las cosas son públicas por defecto: posts, listas de seguidores, etc. A mi no me afecta, pero a mucha gente sí, y por ello no debería ser de esa forma.

Me llegan los Buzz a la casilla de correo, odio eso. Por cada Buzz nuevo en una conversación que haya participado, me aparece un no leído en dos lugares diferentes: Buzz y Recibidos, y tengo que sí o sí archivarlo o eliminarlo desde Recibidos (si lo leo desde Buzz, el mail no leído sigue estando). Eso es MUY molesto.

No es tan visualmente fácil darse cuenta de los Buzz no leídos.

Python Regular Expressions

2010-01-29T10:07:00.004-03:00

Bueno, me complace anunciarles mi pequeño aporte a la comunidad pythónica:

Python Regular Expressions

El sitio aún es beta, revienta en unos cuantos lugares. Pero lo voy a seguir puliendo en mis ratos libres.

Espero que les guste y les sea útil!

If en los templates de Django 1.2 (alpha)

2010-01-27T08:54:00.004-03:00

Una de las cosas que mencioné en el post anterior sobre frameworks web, fue que en Django el sistema de templates tenía algunas cosas que no me terminaban de convencer.

Más específicamente, no me agradaba demasiado que sea bastante limitado (aunque sea intencionalmente), y que redefinía una sintaxis a veces rara para cosas que eran comunes, y que todos estamos acostumbrados a hacer de otra manera.

Ejemplo: si queríamos hacer un If comparando si dos variables son iguales, en lugar de un clásico "if a == b", teníamos que escribir algo como "ifequals a b" (una sintaxis que me recuerda más a LISP que a Python, jeje).

En estos días se liberó la versión 1.2 alpha 1 de Django, y para mi felicidad, descubrí que el tag "if" de los templates está muy renovado. Ahora lo veo mucho más natural y Pythónico!

Entre otras cosas, permite hacer cosas como "if a == b", "if a < b", o con cualquier otro operador de la lista normal de operadores de comparación.

También permite mezclar ands y ors en la misma sentencia, algo que antes no se permitía y limitaba un poco.

Notas de release de Django 1.2 alpha 1.

Link directo a la sección sobre el tag if.

Rails, Django, Web2py

2010-01-25T16:07:00.029-03:00

No voy a hacer una comparación objetiva. Lo aclaro desde el principio.

Lo que quiero escribir en este post es simplemente un breve resumen de mi opinión sobre los tres frameworks basado en mi propia experiencia. Es super subjetiva, y estoy abierto a que me cuenten los demás qué opinan.

No quiero con esto convencer a nadie de usar uno u otro framework. Creo que lo mejor es que cada uno experimente y decida por sí mismo.

Por razones de longitud, no voy a incluir las cosas buenas o malas que son comunes a los tres frameworks. Ya todos sabemos que plantean metodologías avanzadas, agilizan el desarrollo, etc. Voy a destacar solo lo que en mi experiencia, diferenció (para bien o para mal) a cada uno.

Rails

Fue mi puerta de entrada al mundo del desarrollo web, tengo que reconocerle eso. Si no fuese por Rails nunca me hubiese agradado ese mundo.

Tiene algunas utilidades que para un novato pueden ayudar mucho, aunque después no se usen tanto. Ej: scaffolds.

Posee una comunidad muy activa y abierta, que lo hace conocer y avanzar mucho. Y además es una comunidad muy distendida, agradable.

Su documentación es muy buena, detallada y con ejemplos útiles. Realmente ayuda a aprenderlo.

Me obligaba a hacer las cosas de una determinada manera, cuando a veces prefería hacerlas de otra. No me dejaba demasiada libertad para elegir cómo hacer las cosas.

En algunos aspectos suele ser complicado innecesariamente (IMHO). En especial, las migrations y la estructura de archivos, que opino pueden simplificarse enormemente sin perder funcionalidad.

Django

Muy flexible. Propone una manera de hacer las cosas pero deja casi total libertad para hacerlas como uno considere mejor, y sin tener que "romper" nada o meterse en código extraño.

Enfoque más simplista, pero sin dejar de ser explícito y potente. (me gusta que sea explícito porque me ayuda a entender lo que sucede, y no tener que confiar en la "magia")

Aprovecha mucho el dinamismo de Python. Los CRUD de la aplicación de administración son un excelente ejemplo: detectan la estructura de los modelos y arman los forms y listados de forma dinámica.

Comunidad activa, abierta y agradable como la de Rails, y a veces bastante delirante.

Exelente documentación e información. El Django Book y la documentación oficiales son muy buenos.

No me termina de cerrar el sistema de templates. Entiendo el argumento de los diseñadores y la separación de lógica de presentación, pero creo que se le podría dar más potencia. Aunque me gusta muchísimo el sistema de bloques, da mucha flexibilidad.

Web2py

Muy, muy sencillo de instalar y poner en marcha por primera vez. En eso es ideal para novatos. Django y Rails están lejos en este aspecto.

También es muy sencillo de aprender y utilizar, a veces bastante más que Django o Rails.

Me gustó mucho la idea de poder editar los archivos del sitio, desde el sitio mismo. En tiempo de desarrollo resulta muy útil.

Pero su simplicidad se logra ocultando al desarrollador muchas de las cosas que suceden. Cuando surge un problema, no siempre se llega a comprender lo que está pasando.

Similar a lo que sucedía con Rails, suele obligar a hacer las cosas de una determinada manera y dificulta hacerlas de otra forma.

Prefiero mucho más un ORM como ActiveRecord o el ORM de Django, antes que la DAL que provee web2py.

Su desarrollo es cerrado. Todos pueden aportar ideas o parches, pero hay una única persona que es dueña del proyecto y que decide su destino, y el destino del aporte de cada uno.

Poca documentación. El libro oficial solo puede verse gratuitamente en scribd (muy molesto), y si se quiere el PDF hay que pagarlo.

Coloreando Python en blogs y html

2009-12-18T01:53:00.011-03:00

Algo que me hizo renegar bastante hace poco, fueron mis ganas de que el código de ejemplo en python que posteaba en el blog tuviese coloreo de sintaxis.

Pasé por varias opciones, y por lejos esta fue la que me resultó más práctica para usar en blogspot o cualquier otro sistema de blogs que permita editar el html del blog. Su practicidad se debe sobre todo a que no necesito hostear archivos extras en ningún lado.

Armé un instructivo bastante sencillo de cómo lograrlo:

1) Instalar Pygments

Vamos a generar un html localmente a partir de un archivo de python, usando el paquete Pygments. Para instalarlo, podemos hacerlo con easy_install (paquete "pygments"), buscándolo y bajándolo de PyPi, o bajando sus fuentes (más info aquí):

2) Generar el HTML con Pygments

Teniendo instalado Pygments, podemos usarlo para generar un HTML coloreado a partir de un archivo de código python. No voy a explicar todas las alternativas, solo la que a mí me resulta práctica (para más info, vean aquí):

$ pygmentize -O noclasses -o pagina.html codigo.py

Nos copiamos el contenido del html generado, lo ponemos dentro de nuestro post, y voila! Python coloreado en nuestro blog :D. Les dejo un ejemplito:

import antigravity 
 
print "wee, python!" 
 
class Foo:
    """Foo fighters""" 
    def __init__(self):
        self.bar = "donde sirven cerveza" 
        
    def baz(self):
        """Vamos al bazaar""" 
        print self.bar

Espero que les haya sido útil!

De Windows Mobile a Android

2009-12-17T12:08:00.005-03:00

Desde hace años que soy usuario de celulares con Windows Mobile. Los conocí por el trabajo (hacemos aplicaciones para ese tipo de aparatos), y rápidamente me entusiasmaron.

Lo que más me atraía era la idea de tener una computadora en el bolsillo. Y tengo que admitir que en gran parte es así con Windows Mobile: las aplicaciones, la manera de administrar los archivos, la interface, etc., siempre se sentía cierta similitud con el mundo desktop. Y me gustaba.

Pero a la mayoría de los usuarios comunes eso mismo les complicaba la existencia: no esperan eso de un celular, sino que buscan que sea mucho más simple y práctico que una pc.

Y se ve que esto es algo que quienes diseñaron Android conocían muy bien.

Hace poco más de un mes, decidí mudarme al mundo Android: me compré una HTC G1.

Al empezar a usarla el cambio se sintió. Era evidente que el objetivo del sistema operativo no era replicar una PC en el bolsillo, sino otra cosa diferente. Y por eso los primeros días me sentí "raro", como incómodo.

Pero esa sensación duró poco más de un día. Hoy ya no puedo imaginarme volver a Windows Mobile.

Comento un poco las principales cosas que me hacen pensar así, desde el punto de vista de usuario (no de desarrollador para la plataforma):

1) Verdaderamente táctil

Todo en Android está pensado para usar con los dedos. De hecho, la G1 ni siquiera trae stylus! (el "palito", jeje). Y no para dedos de aguja, todo lo contrario: tenés que usar las cosas con el dedo gordo, es la manera más cómoda y a la que mejor responde.

En Windows Mobile la interface del sistema operativo ni por casualidad es usable con los dedos. Hay interfaces de terceros más adaptadas para ello, como PointUI, o Touch Flo 3D, pero ninguna se acerca al nivel de usabilidad de Android. Siempre terminás sacando el stylus para realizar algunas tareas.

Parecería un tema superficial, pero de verdad es un aspecto central en un dispositivo móvil, es determinante en su facilidad de uso. No se puede, por ejemplo, caminar por la vereda mientras se está escribiendo con un palito sobre una pantalla de 3 pulgadas (al menos no sin correr el riesgo de chocarse un poste). Pero sí es posible hacerlo con una interfaz como la de Android, escribiendo con los dedos como lo hacemos con cualquier otro celular no táctil.

2) Practicidad:

Aparte del aspecto táctil, la otra gran ventaja de la interface de Android es su facilidad de uso, su practicidad.

Las funciones casi siempre están visibles, fácilmente accesibles. En comparación a Windows Mobile se usan poco los menúes y se aprovecha más la pantalla para mostrar botones grandes (y ni hablar que más lindos gráficamente :D).

Y donde hay menúes, también son grandes y con íconos (en Windows Mobile casi siempre son listas de textos a las que es difícil acertar si no es con el stylus).

Y la configuración de la mayoría de las cosas, en mi opinión, resulta bastante más sencilla. No hay opciones que uno vea y piense "y esto qué hará??", como pasaba en Windows Mobile (ejemplos: las opciones de "autenticación PAP o cHAP" para la línea de celular, o el tilde de "Funcionalidad de Red Avanzada" en la configuración de la conexión usb, ...).

3) Velocidad:

Windows Mobile pone tanto énfasis en la velocidad como el resto de los productos de Microsoft (Windows vista, Visual Studio, ...). Yo me había acostumbrado a esperar para cosas básicas, como abrir los mensajes.

Android no será tan rápido como iPhone, pero está bien por encima de Windows Mobile. Y eso es algo que se siente mucho en el uso diario del aparato.

4) Organización de la información:

En Windows Mobile estaba muy acostumbrado a manejar mis archivos en estructuras de carpetas, de igual manera que en mi pc de escritorio.

Cuando me mudé a Android me di cuenta de que, por más que podía hacerlo con aplicaciones de terceros, Android en sí mismo no me mostraba en ninguna parte un árbol de carpetas y archivos.

Primero me hizo sentir que de alguna forma me "restringía". Pero después entendí que es mucho más cómoda la manera en que Android me presenta la información: una idea más cercana a la de bibliotecas.

Para abrir una foto no tengo que navegar por carpetas hasta el lugar donde se haya guardado. En su lugar, entro a la aplicación Galería, que me presenta todo lo que es multimedia agrupado por tipos de elementos: videos, fotos, fotos sacadas con la cámara, etc. No necesito recordar dónde estaba almacenada :D.

(sí, tengo que admitir que la galería de HTC Touch Flo 3D era así. Pero eso es algo que no es parte de Windows Mobile, es una aplicación de HTC, un tercero).

5) Integración con herramientas web

Me encanta que todo lo que tengo en el celular esté perfectamente sincronizado con mi cuenta de correo en internet: contactos, calendario y correo.

(no tengamos en cuenta a Exchange, estamos hablando de usuarios finales)

Ya sé, en Windows Mobile también se puede sincronizar todo. Pero en Windows Mobile si quería mantener esas tres cosas tenía que tener el correo y los contactos sincronizados con Hotmail, y el calendario sincronizado con MyPhone.

Recordemos que Hotmail también tiene calendario... ¿será que en Microsoft creen que las personas viven dos vidas en simultaneo?, una planificada con el calendario de Hotmail, y otra planificada con el calendario del Celular (sincronizado con MyPhone).

En lugar de desarrollar MyPhone, ¿por qué simplemente no permiten sincronizar el calendario de Windows Mobile con el de Hotmail?

Conclusión

Esas son las cosas que como usuario me transformaron en partidario de Android. No hablo como desarrollador, por más que lo soy, sino como usuario diario de los celulares.

Ustedes que opinan?

Frameworks web y lenguajes

2009-12-10T11:38:00.005-03:00

Hace poco en la lista de correos de Ruby Argentina, alguien dijo una frase que me quedó picando en la mente: "Usar rails es la peor forma de aprender ruby :)".

Para quien no los conoce, Ruby es un lenguaje de programación muy interesante, y Ruby on Rails (o directamente Rails) es un framework para hacer aplicaciones web con Ruby (fué el que disparó a la fama al lenguaje).

(mas info sobre ruby aquí, y sobre Rails aquí)

No voy a debatir sobre las opiniones que salieron en la lista, y no voy a detenerme en qué habrá querido expresar la persona que lo dijo. Solo voy a comentar las cosas que a mí me hizo pensar.

Voy a generalizar un poco más, y "meter en la bolsa" a Django, un framework para aplicaciones web con Python bastante similar a Rails (info de Django aquí).

Me detengo solo en esos dos porque son los que usé para desarrollos reales, a los demás los conozco de vista/probar solamente.

La fiebre de la web (casi como la del oro)

La web es un terreno del desarrollo de software que está avanzando a velocidad imparable, no hace falta ser muy observador para darse cuenta (Google Docs, cloud computing, y muchas otras palabras de moda). Y por ello puede resultar tentador para alguien que nunca desarrolló web, pasarse a ese nuevo mundo de moda y con futuro.

Pero cuando la gente se pasa a una nueva tecnología esperando obtener beneficios de ella, y no solo por "amor al arte", generalmente espera resultados rápidos. Pocos estarían dispuestos a esperar un año hasta tener conocimientos como para poder hacer su primer sitio web.

Ahí es donde estos frameworks se ponen tentadores: una de las principales ventajas que ofrecen es el desarrollo rápido de aplicaciones. Rails tiene su famoso video de "un blog en 15 minutos", por ejemplo.

Y es verdad, comparados con otras tecnologías agilizan enormemente el desarrollo web. Traen resueltas un montón de problemáticas comunes. La aplicación de administración de Django es un ejemplo excelente: toda la administración del sitio ya resuelta "de fábrica" (autenticación, usuarios, permisos, ABMs de entidades, etc.).

Los caminos se separan

En este punto es donde nos encontramos con dos situaciones muy diferentes:

1) El desarrollador desktop de Python/Ruby, que aprovechando su conocimiento del lenguaje elije un framework web del mismo.

2) El desarrollador de otros lenguajes, que atraído por las ventajas de alguno de estos frameworks decide comenzar a desarrollar con él, lo que le implicará aprender también el nuevo lenguaje.

No hace falta decir que el camino para el desarrollador de la situación 1) es bastante simple. Además tengamos en cuenta que estos frameworks suelen seguir muy al pie de la letra la filosofía del lenguaje, por lo que se sentirá "como en casa".

Lo que preocupa es el camino del segundo desarrollador.

¿Por qué?

Aprendiendo a correr sin saber caminar

En primer lugar, estos frameworks asumen que uno posee conocimientos del lenguaje. Un tutorial de Django no va a explicar el manejo de listas de Python, por ejemplo.

Entonces va a ser una situación bastante normal la de encontrarse con partes de los tutoriales que no se lleguen a comprender del todo, porque al ver el código no "salta a la vista" tan fácil lo que está haciendo.

Y para empeorar la situación, muchas veces esto va a llevar a escribir código "porque estaba así en el tutorial", pero sin tener la menor idea de lo que hace. No es necesario mencionar los problemas de mantenimiento que una aplicación así puede tener...

Esa razón sola debería bastar para tener que aprender primero el lenguaje.

Y aunque logre entender dicho código, seguramente no va a conocer muchísimas cosas más que podría aprovechar del lenguaje para el desarrollo de su aplicación. Sus herramientas se van a limitar a lo que se muestra normalmente con el framework, probablemente desconociendo muchas otras facilidades que el lenguaje le brinda.

(mi post anterior habla sobre algo relacionado)

Como antes recordamos, estos frameworks también suelen seguir muy bien la filosofía de sus lenguajes respectivos. Por ende, alguien que no conoce esa filosofía tendrá un trabajo extra para "acomodarse" a la nueva manera de hacer las cosas.

Además, los frameworks toman muchas decisiones de diseño, y adoptan convenciones (muy fuertes sobre todo en Rails), que son buenas para el framework pero no necesariamente son buenas para otros entornos. El problema es que el programador que aprende el lenguaje desde dichas convenciones, seguramente asumirá que no existen otras maneras de hacer las cosas, o que si existen no son las correctas.

Este "vicio" no va a tener consecuencias directas en su etapa de desarrollador sobre ese framework, pero sí las va a tener cuando intente probar otros frameworks del mismo lenguaje, ya que no necesariamente el que aprendió es el mejor framework para todos los casos.

Conclusión

Por estas razones es que opino que antes de aprender uno de estos frameworks, es muy, muy saludable dedicar un tiempo a aprender el lenguaje a secas, sin web, como vino al mundo :D

De hecho, pude comprobarlo en mi experiencia personal:

- Intenté aprender Ruby on Rails directamente, sin conocer Ruby. Pude, pero seguramente no llegué a ver todo lo que es Ruby y a comprenderlo bien. Y me solía pasar de tener la sensación de que no sabía cómo funcionaban las cosas.

- Con Python me tomé el tiempo para aprender bien el lenguaje, y recién después comencé con Django. El pasaje fue natural, y me siento con mucho más control de lo que hago. Siento que lo entiendo y que puedo "sacarle bien el jugo".

¿Que opinan?

Python: Dinamismo aplicado

2009-12-09T13:39:00.020-03:00

Me suele pasar que cuando comento alguna característica superior de un lenguaje a otra persona que no lo conoce, la persona reaccione con frases del estilo "y eso cuando lo vas a usar en la realidad?", o "todo muy lindo, pero eso es para la teoría, en la práctica no sirve", etc...

Es normal, ya que al no estar acostumbrado a pensar de una manera distinta, no va a ver tan fácilmente la utilidad de dicha característica.

Estas no son grandes iluminaciones mías, jeje, son ideas que Paul Graham explicó muy bien en este artículo (recomendado).

Pero lo que sí puedo aportar desde mi humilde experiencia, es un buen ejemplo de cómo una característica puede sonar "muy rara", pero cuando es bien aprovechada, puede resultar "muy práctica".

Puede haber cientos de cosas equivocadas en lo que estoy por decir, estaría bueno que me hagan conocer al menos algunas :D

La característica "extraña"

Ahora es donde hace su entrada la característica "extraña" que tiene Python. Va a sonar "extraña" para quien no esté acostumbrado a cosas por el estilo, se entiende.

La característica es la función getattr: llamándola podemos obtener un atributo o método de un objeto.

Este ejemplo es bien ilustrativo:


yo = "juan pedro" 
met = getattr(yo, "upper") 
met()   #esto nos devuelve "JUAN PEDRO"

Para explicarlo un poquito:

Con getattr(yo, "upper") obtuvimos el método upper del objeto yo.

Atención! Dije "obtuvimos el método", no "el resultado de llamar al método". Son cosas bien diferentes.

Obtener el método es como darle un nuevo nombre con el cual después podemos llamarlo, como hicimos en "met()". Met es un nuevo nombre para llamar a ese método en particular, el método upper de yo.

Es destacable que usar una variable (met en este caso) es algo que hice solo para que sea más entendible a primera vista. Pero lo anterior perfectamente puede escribirse como:


yo = "juan pedro" 
getattr(yo, "upper")()   #esto nos devuelve "JUAN PEDRO"

No guardamos el método en una variable, simplemente lo llamamos en ese momento. Lo obtenemos y lo llamamos en una misma línea.

El problema

Tenemos una clase Foo. Esta clase Foo define 5 acciones diferentes, que se representan con 5 métodos: accion1, accion2, accion3, accion4, accion5.

La complicación se da en el hecho de que cada una de estas acciones es realizada comunicándose con un servicio, y hay 4 servicios completamente diferentes en los cuales se pueden realizar las acciones: A, B, C y D.

Ejemplo:

"Hacer acción 1 en el servicio B"

"Hacer acción 3 en el servicio D"

etc...

En la implementación, cada servicio cambia por completo el código que se tiene que ejecutar para realizar una acción. Es decir, el código de la acción 1 para el servicio A es completamente diferente al código de la acción 1 para el servicio B, etc.

La clase Foo necesita recibir el nombre del servicio como un parámetro de cada acción, para saber en qué servicio ejecutarla. De forma que después se utilice de la siguiente manera:


miFoo = Foo()    #creamos un nuevo objeto foo 
miFoo.accion1("A")   #llamamos a la accion 1 en el servicio A 
miFoo.accion1("C")   #llamamos a la accion 1 en el servicio C 
miFoo.accion3("B")   #llamamos a la accion 3 en el servicio B

Primer solución "no dinámica"

Para muchos de los que lean esto, la primera solución que les vendrá a la mente será que cada método (accionX...) tenga dentro de sí un gran if, para cada servicio. Algo así:


class Foo: 
  def accion1(self, servicio): 
      if servicio == "A": 
          #codigo de la accion 1 en el servicio A 
      elif servicio == "B": 
          #codigo de la accion 1 en el servicio B 
      elif servicio == "C": 
          #codigo de la accion 1 en el servicio C 
      elif servicio == "D": 
          #codigo de la accion 1 en el servicio D

Esto va a funcionar, eso no lo voy a negar. ¿Pero qué es lo que no me gusta de esta opción? No me gustan estas cosas:

1) Este if va a estar repetido en cada una de las acciones, que son 5. Cuando se agreguen o modifiquen servicios, tengo que mantener actualizado el mismo if en los 5 métodos "accionX".

2) El código rápidamente se hace ilegible cuando es mucho código por acción.

3) Da la sensación de que estamos "amontonando" peras con manzanas, que esto podría separarse un poco para ordenarse mejor.

4) Estos if son 2 lineas por cada acción y servicio, con lo que para 5 acciones en 4 servicios, son 40 líneas de código solamente en los if, no incluyendo el código de las acciones mismas. Son 40 líneas de código que no hacen lo que queremos hacer, y que las necesitamos solo para decidir qué código ejecutar.

Mejorando la solución "no dinámica"

Para el problema del amontonamiento y el orden, a más de uno ya se le debe haber ocurrido la solución. Algo así:


class Foo: 
   def accion1(self, servicio): 
       if servicio == "A": 
           self.accion1_en_A() 
       elif servicio == "B": 
           self.accion1_en_B() 
       elif servicio == "C": 
           self.accion1_en_C() 
       elif servicio == "D": 
           self.accion1_en_D() 
 
   def accion1_en_A(self): 
           #codigo de la accion 1 en el servicio A 
 
   def accion1_en_B(self): 
           #codigo de la accion 1 en el servicio B 
 
   def accion1_en_C(self): 
           #codigo de la accion 1 en el servicio C 
 
   def accion1_en_D(self): 
           #codigo de la accion 1 en el servicio D

No puedo negarlo, la separación en varios métodos ayuda un poco a la legibilidad y mantenibilidad. Consideremos esa parte como resuelta y correcta, nos olvidamos de los métodos "accionX_en_Y".

Pero tenemos todavía esto:


def accion1(self, servicio): 
   if servicio == "A": 
       self.accion1_en_A() 
   elif servicio == "B": 
       self.accion1_en_B() 
   elif servicio == "C": 
       self.accion1_en_C() 
   elif servicio == "D": 
       self.accion1_en_D()

Esto es lo que sigue sin gustarme. ¿Por qué?

Porque seguimos teniendo el problema de los ifs horribles desparramados por todos lados.

Seguimos teniendo que mantener esas 40 líneas de código que solo sirven para elegir el código a ejecutar.

Mi opinión es que debería poder hacerse de otra forma.

La rareza viene al rescate: La solución dinámica

Bien, en teoría la cosa rara debería ahora ayudarnos con nuestro problema. ¿Y cómo nos va a ayudar esa cosa rara de Python?.

Recordemos que nos habíamos olvidado del código de los métodos "accionX_en_Y", esos estaban aprobados :). Lo feo era el código que elegía cuál método ejecutar según el servicio.

Veamos entonces la versión "rara" de ese código:


def accion1(self, servicio): 
   getattr(self, "accion1_en_" + servicio)()

Se nota lo que falta?? Ya no tenemos al if!

Antes teníamos esas 40 líneas de ifs, 8 líneas por cada acción que solo decidían qué código ejecutar. Ahora esa decisión se toma con 1 línea en cada acción, con lo que nos quedan (con 5 acciones) un total de.... 5 lineas!

5 líneas contra 40 es un ahorro del 87% menos de código.

Cuidado. La cuestión no es "tener pocas líneas porque es más lindo". En este caso, la ventaja es no tener que mantener código repetitivo e innecesario.

Y no solo eso, ganamos también otra ventaja muy importante: Si mañana agregamos o sacamos servicios, no es necesario tocar nada del código que elige el método a ejecutar. Solo agregamos las implementaciones (métodos accionX_en_Y), y la clase sabrá por si sola llamarlos, sin que tengamos que decirle nada extra. Así de práctico.

Conclusión

En un ejemplo bastante simple, se ve cómo una característica "extraña", bien usada puede transformarse en una característica "práctica".

Y cuidado, porque cuando se empiezan a aprovechar estas características, resulta bastante molesto volver a los lenguajes que no las tienen... Es adictivo, jeje.

PD: crédito a C.B. que me mostró el artículo de Paul Graham :D

Aplicaciones favoritas de Android

2009-12-09T12:47:00.002-03:00

Otro día comentaré más de mi experiencia de haberme comprado un Android (les adelanto que no lo cambiaría por nada, jeje).

Hoy solo dejo un listado que me armé de mis aplicaciones preferidas. Podrán ver que me pasé un buen rato probando cosas :D

Mis Android Apps favoritas

Charla Python

2009-12-09T12:24:00.003-03:00

Desde hace rato ya que me "pythonisé". Viniendo del mundo .Net, en Python descubrí muchísimas cosas que me agradan y me hacen sentir más "comodo" (tipado dinámico, simplicidad, dry, etc.). Pero ahora no vienen al caso, otro día las comento más en detalle :D

Lo que sí viene al caso es que, por lo que me gustó Python, vengo no solo aprendiendo, sino que siempre les comento a mis compañeros de trabajo sobre las cosas que voy descubriendo. Y como en la empresa hace poco resurgió un proyecto de que demos charlas a la comunidad, entonces me propusieron dar una sobre Python (ya que les hinchaba tanto... jeje).

Así que el miércoles 2 de diciembre dí esta charla, que salió bastante bien. Poca gente, pero creo que les sirvió a ellos y a mí.

Para darla preparé una presentación, orientada más que nada a quienes vienen de .Net (no hace una comparación explícita, pero sí ordena los temas para que les resulten más familiares).

Aquí les dejo el link a la presentación:

http://docs.google.com/present/view?id=ddfg8qh9_92c6996nhh

Y también les dejo un link al sitio de PyAr, a la sección Charlas, de donde saqué mucho material para armar la mía. Gracias PyAr!!!:

http://python.org.ar/pyar/Charlas

Mi segunda aplicación libre: Cuoty

2009-12-09T12:20:00.005-03:00

Bueno, como verán sigo con el impulso de liberar software. :D

En este caso estoy migrando una aplicación que antes había desarrollado a pedido de una parroquia, para la gestión de los aportantes (cuotas, cobradores, etc.).

En ese momento la había desarrollado con .Net, pero en este momento la estoy migrando a Python+Django, y al mismo tiempo haciéndola libre.

Pueden sumarse al proyecto, seguirlo, o realizar comentarios en:

http://code.google.com/p/cuoty

Mi primer aplicacion libre: Wozo

2009-10-03T17:33:00.004-03:00

Bueno, con felicidad comento que acabo de liberar mi primer aplicación de Software Libre: Wozo.

Es un gestor de menues de comida, para empresas u organizaciones donde la gente pide comida para comer en el lugar.

La idea central es permitir administrar los pedidos de manera sencilla.

Está desarrollada con Python y Django.

Para quienes quieran usarla o participar en el desarrollo, la aplicación está en Google Code:

http://code.google.com/p/wozo/

Instalar Emacs on Rails en Windows

2009-07-08T09:55:00.002-03:00

Instalar Emacs con los plugins para Ruby on Rails en Windows no resulta tan complejo una vez que se entendió bien todo, pero lleva una serie de pasos que hay que seguir bien al pie de la letra.

Algunas cosas podrían hacerse diferente, pero yo explico la manera en la cual a mi me pareció mejor hacerlo, y no explico las otras porque el tutorial se haría interminable :D (convención sobre configuración, jeje).

1) Bajar la última versión de Emacs, los binarios completos para Windows. Al momento de hacer este tutorial, la versión era la 22.3, así que si hay nuevas versiones habría que validar nuevamente el tutorial.

2) Descomprimirlos en la carpeta que más nos guste.

3) La carpeta HOME

En Linux/Mac, cada usuario tiene una carpeta Home donde se almacena su información. Emacs utiliza esta carpeta para almacenar su configuración, y para buscar librerías y plugins extras. El problema es que en Windows esta carpeta no existe. Por lo tanto tenemos que decirle de alguna manera a Emacs, cuál será la carpeta que utilizaremos como Home.

Como hacerlo: con una variable de entorno de Windows.

- Click derecho en Mi PC,"Propiedades"

- Pestaña "Opciones Avanzadas"

- Botón "Variables de Entorno"

- En la sección de "Variables del Sistema", hacemos click en "Nueva".

Nombre: HOME

(respetar mayúsculas)

Valor: ruta de la carpeta que queramos usar como home

Ejemplo de Valor: C:\emacs_home\

4) Seguimos con la carpeta HOME:

Ya tenemos creada la Home, pero ahora hay que darle un poco de forma.

Creamos primero una carpeta que se llame ".emacs.d" . Nótese los puntos, la carpeta se llama PUNTO EMACS PUNTO DE. Esto genera un problema: el explorador de Windows no deja crear carpetas que empiecen con un punto.

Solución: lo hacemos desde la consola: abrimos la consola, nos posicionamos en la carpeta Home, y ejecutamos "mkdir .emacs.d"

(ver en el paso 6, como queda el árbol de directorios y archivos en la Home)

Además de esta carpeta, hace falta agregar un archivo de texto donde emacs leerá la configuración de los plugins: ".emacs". Una vez más, nótese los puntos, el archivo se llama PUNTO EMACS. Podemos crear el archivo con el block de notas, y ponerle otro nombre cualquiera. Después lo renombramos a ".emacs". Otra vez, Windows no deja nombrar archivos que empiecen con un punto. Una vez más, la solución está en la consola: vamos a la consola, nos posicionamos en el directorio Home, y ejecutamos "move nombre_anterior .emacs"

(ver en el paso 6, como queda el árbol de directorios y archivos en la Home)

5) Rellenar el directorio .emacs.d

Dentro de esta carpeta incluiremos todos los plugins y librerías que vamos a usar. En este caso, el plugin principal va a ser Emacs on Rails. Pero además, este necesita de otros plugins y librerías para funcionar. La lista completa, y como agregar cada uno al directorio de librerías:

- CEDET

Descarga: http://cedet.sourceforge.net/ (sección Downloads)

Versión: yo utilicé la 1.0pre6, porque la 1.4 es beta aún en el momento de hacer el tutorial

Instalación: descomprimir, y mover la carpeta "cedet-1.0pre6" dentro de ".emacs.d"

(ver en el paso 6, como queda el árbol de directorios y archivos en la Home)

- ECB

Descarga: http://ecb.sourceforge.net/ (sección Downloads)

Versión: yo usé la 2.40, la última al momento de hacer el tutorial

Instalación: descomprimir, y mover la carpeta "ecb-2.40" dentro de ".emacs.d"

(ver en el paso 6, como queda el árbol de directorios y archivos en la Home)

- snippet.el

Descarga: http://www.kazmier.com/computer/snippet.el (con esta url se accede directamente al contenido del archivo)

Instalación: crear un archivo con nombre "snippet.el", llenarlo con ese contenido, y mover el archivo a la carpeta ".emacs.d"

(ver en el paso 5, como queda el árbol de directorios y archivos en la Home)

- find-recursive.el

Descarga: http://www.webweavertech.com/ovidiu/emacs/find-recursive.txt (con esta url se accede directamente al contenido del archivo)

Instalación: crear un archivo con nombre "find-recursive.el", llenarlo con ese contenido, y mover el archivo a la carpeta ".emacs.d"

(ver en el paso 6, como queda el árbol de directorios y archivos en la Home)

- inf-ruby.el

Descarga: http://svn.ruby-lang.org/cgi-bin/viewvc.cgi/trunk/misc/inf-ruby.el?view=co (con esta url se accede directamente al contenido del archivo)

Instalación: crear un archivo con nombre "inf-ruby.el", llenarlo con ese contenido, y mover el archivo a la carpeta ".emacs.d"

(ver en el paso 6, como queda el árbol de directorios y archivos en la Home)

- ruby-mode.el

Descarga: http://svn.ruby-lang.org/cgi-bin/viewvc.cgi/trunk/misc/ruby-mode.el?view=co (con esta url se accede directamente al contenido del archivo)

Instalación: crear un archivo con nombre "ruby-mode.el", llenarlo con ese contenido, y mover el archivo a la carpeta ".emacs.d"

(ver en el paso 6, como queda el árbol de directorios y archivos en la Home)

- ruby-electric.el

Descarga: http://svn.ruby-lang.org/cgi-bin/viewvc.cgi/trunk/misc/ruby-electric.el?view=co (con esta url se accede directamente al contenido del archivo)

Instalación: crear un archivo con nombre "ruby-electric.el", llenarlo con ese contenido, y mover el archivo a la carpeta ".emacs.d"

(ver en el paso 6, como queda el árbol de directorios y archivos en la Home)

- emacs-rails

Descarga: http://rubyforge.org/projects/emacs-rails (sección Downloads)

Versión: yo usé la 0.5.99.5, la última al momento de hacer el tutorial

Instalación: descomprimir, y mover la carpeta "emacs-rails" dentro de ".emacs.d"

(ver en el paso 6, como queda el árbol de directorios y archivos en la Home)

6) Resumen: cómo quedó el árbol de directorios

Si hicimos todo bien, debería habernos quedado algo de esta manera:

home_configurada\.emacs (archivo)

home_configurada\.emacs.d\ (directorio)

home_configurada\.emacs.d\cedet-1.0pre6 (directorio, dentro debería contener los directorios "semantic", "eieio", "speedbar", "commons", y otras cosas )

home_configurada\.emacs.d\ecb-2.40 (directorio, dentro debería contener muchos directorios y archivos)

home_configurada\.emacs.d\emacs-rails (directorio, dentro debería contener muchos archivos)

home_configurada\.emacs.d\find-recursive.el (archivo)

home_configurada\.emacs.d\inf-ruby.el (archivo)

home_configurada\.emacs.d\ruby-electric.el (archivo)

home_configurada\.emacs.d\ruby-mode.el (archivo)

home_configurada\.emacs.d\snippet.el (archivo)

7) Rellenar el .emacs

El archivo .emacs dijimos que va a definir que plugins cargar, entre otras cosas. Para eso tenemos que rellenarlo con el siguiente contenido (el contenido se explica a si mismo, con comentarios):

;; rutas de las librerias previas

(add-to-list 'load-path "~/.emacs.d")

(load-file "~/.emacs.d/cedet-1.0pre6/common/cedet.el")

(add-to-list 'load-path "~/.emacs.d/ecb-2.40")

;; carga de ECB

(require 'ecb)

(require 'ecb-autoloads)

;; desactivar Tip of the Day de ECB

(setq ecb-tip-of-the-day nil)

;; activar abrir los archivos con click del mouse en ECB

(setq ecb-primary-secondary-mouse-buttons (quote mouse-1--mouse-2))

;; carga automatica de ECB

(ecb-activate)

;; activar semantic

(setq semantic-load-turn-everything-on t)

(require 'semantic-load)

;; activar rails mode

(add-to-list 'load-path "~/.emacs.d/emacs-rails")

(require 'rails)

;; activar resaltado de sintaxis en ruby mode

(add-hook 'ruby-mode-hook 'turn-on-font-lock)

;; activar autocompletar (ruby electric)

(defun try-complete-abbrev (old)

(if (expand-abbrev) t nil))

(setq hippie-expand-try-functions-list

'(try-complete-abbrev

try-complete-file-name

try-expand-dabbrev))

(add-hook 'ruby-mode-hook

(lambda()

(add-hook 'local-write-file-hooks

'(lambda()

(save-excursion

(untabify (point-min) (point-max))

(delete-trailing-whitespace)

)))

(set (make-local-variable 'indent-tabs-mode) 'nil)

(set (make-local-variable 'tab-width) 2)

(imenu-add-to-menubar "IMENU")

(require 'ruby-electric)

(ruby-electric-mode t)

))

(custom-set-variables

'(ecb-options-version "2.40"))

(custom-set-faces

)

8) Listo! ahora a usar Emacs

Para ejecutar Emacs, volvamos a la carpeta donde lo habíamos descomprimido. Dentro de ella, tiene que haber una carpeta "bin", y dentro de bin, un archivo "runemacs.exe".

Este es el archivo que hay que abrir para ejecutar Emacs bajo Windows.

Cualquier problema, revisar el tutorial (en especial el árbol de directorios en el paso 6), y el contenido del .emacs del paso 7.

Si eso no lo soluciona, o hay dudas, respondo por mail a fisadev@gmail.com

No soy un experto, pero puedo hacer mi mejor esfuerzo :)

Y no puedo dejar de agradecer a Gabriel Arellano, quien armó en el 2007 un tutorial para esto, que hoy me sirvió en gran medida para hacer funcionar todo, y para armar mi tutorial (el contenido del .emacs es en gran parte de su autoría, modificado solo por mí para adaptarse a las nuevas versiones).

Saludos

Instalar Ruby en Windows

2009-07-08T09:51:00.002-03:00

Bueno, la instalación de Ruby en Windows no es muy compleja si usamos la versión 1.8.6, que tiene un instalador que hace todo por nosotros.

Pero si queremos usar la 1.8.7 ya no es tan sencillo, ya que no hay un one-click installer de esta versión.

Luego de leer bastante para no hacer cualquier cosa, este es el pequeño tutorial que terminé armando sobre como instalar Ruby 1.8.7 en Windows:

1) Descargar los binarios de la maquina virtual de ruby, y extraerlos en alguna carpeta. Recomendable hacerlo en C:\ruby\

2) Agregar [carpeta_de_ruby]\bin a la variable de entorno PATH

Ejemplo: si ubicamos la maquina virtual de ruby en C:\ruby, a PATH tenemos que agregarle C:\ruby\bin

Para quien no sabe agregar rutas a PATH, se hace de esta manera:

- Click derecho en Mi PC,"Propiedades"

- Pestaña "Opciones Avanzadas"

- Botón "Variables de Entorno"

- En la sección de "Variables del Sistema", buscamos la que se llama "Path".

- La modificamos, agregando el directorio [carpeta de ruby]\bin al final, separado por ";".

Ejemplo:

Si Path contenía:

"C:\Archivos de programa\Microsoft SQL Server\80\Tools\Binn\;C:\Archivos de programa\IDM Computer Solutions\UltraEdit-32;C:\ruby\bin"

Ahora contendrá:

"C:\Archivos de programa\Microsoft SQL Server\80\Tools\Binn\;C:\Archivos de programa\IDM Computer Solutions\UltraEdit-32;C:\ruby\bin;C:\ruby\bin"

3) Librerias necesarias:

Para que ruby funcione correctamente, van a ser necesarias algunas librerias que en Windows no tenemos por defecto.

Algunas librerías no tienen un instalador, y es necesario copiarlas manualmente. En muchos sitios recomiendan colocar dichas librerías en la carpeta [carpeta_de_windows]\System32. Pero según los mas experimentados, no es una buena práctica. Lo recomendable es colocar estas librerías en la carpeta [carpeta_de_ruby]\bin.

Si poseen instalador, entonces logicamente hay que usar el instalador.

Estas son algunas de las librerías que seguramente se van a necesitar en cualquier máquina. Me tomé el trabajo de colocar los links para conseguir las últimas versiones:

- ssleay32.dll, libeay32.dll

http://www.slproweb.com/products/Win32OpenSSL.html

- zlib.dll

http://www.zlib.net/zlib123-dll.zip

(renombrar zlib1.dll a zlib.dll)

- iconv.dll

http://sourceforge.net/project/showfiles.php?group_id=25167&package_id=51458

- readline.dll

la versión que paso está hecha en Ruby, y me enteré de que existía gracias a la lista de Ruby Argentina :D

http://github.com/luislavena/rb-readline/downloads

(se instala ejecutando "ruby setup.rb" desde consola, estando en el directorio donde descomprimimos el archivo bajado)

- sqlite3.dll

http://www.sqlite.org/

4) Luego debemos instalar Gems, para poder utilizar el sistema de paquetes.

- Bajar la ultima version de gems desde http://rubyforge.org/frs/?group_id=126

- Descomprimirla en algún directorio

- Estando en el directorio desde la consola, ejecutar "ruby setup.rb"

Extra: Instalar Rails

Despues de instalar ruby y gem, se puede instalar rails como todos saben, haciendo:

"gem install rails"

Pero un detalle a tener en cuenta es que hay problemas con la versión 1.2.4 de sqlite3 en Windows, así que es conveniente instalar la 1.2.3:

"gem install sqlite3-ruby -v 1.2.3"