#ubuntu-classroom-es 2012-08-28
<Hewerson> Ola
<Hewerson> buenas tardes!
<Conrado> ignore #ubuntu-classroom CRAP NOTICES SNOTES CTCPS JOINS PARTS QUITS KICKS MODES WALLOPS NICKS DCC DCCMSGS CLIENTNOTICES CLIENTCRAP CLIENTERRORS HILIGHTS
<Conrado> whre's the traduction?
<chilicuil> wop, hola gus-tavo, ya listo para tu sesion?, creo que me quede dormido, como han estado las charlas?
<chilicuil> hola Conrado , veo que has estado siguiendo el canal desde las 16:00 utc, la introduccion, debio correr a mi cargo, sin embargo, no he podido llegar a tiempo.., gus-tavo tenia asignada las sesiones que aparecen con su nick en la wiki, de no tener otros problemas, comenzare a interpretar las siguientes sesiones, una vez que finalice ogra
<Conrado> ok
<Conrado> chilicuil
<Conrado> gracias
<chilicuil> no para nada, una disculpa, espero que igual hayas podido seguir las charlas en #ubuntu-classroom
<chilicuil> ogra ha terminado, ahora bilal se encargarÃ¡ de la sesion sobre 'Desarrollo de ubuntu para jovenes' (Ubuntu development for the youth!)
<chilicuil> recuerden entrar a #ubuntu-classroom-chat para seguir las discusiones y para hacer sus preguntas
<chilicuil> utilicen el prefijo QUESTION: para identificarlas
<chilicuil> si no estan seguros de como hacer su pregunta, haganla por aqui, y les ayudaremos a traducirla
<chilicuil> comienzo ahora mismo
<chilicuil> Hola, mi nombre es Bilal Akhtar y he estado involucrado con la comunidad de Ubuntu por al menos 2 aÃ±os
<chilicuil> como se daran cuenta (o pronto lo haran), hay muchas otras formas de contribuir a Ubuntu ademas de la programacion
<gus-tavo> hola chilicuil, yo voy  a interpretar la ultima sesion de hoy, necesito ayuda con lernid
<gus-tavo> hay una forma de que se conecte a ubuntu-classroom-es?
<chilicuil> durante la sesion, no olviden hacer todas sus preguntas, y de utilizar QUESTION: como prefijo, por ejemplo, QUESTION: Why is Ubuntu so awesome?, y tratare de responderlas
<gus-tavo> asi no hay que cambiar de solapas para ver el ingles junto a la ventana de espaÃ±ol
<chilicuil> si, gus-tavo , con un cliente de irc, por ejemplo, xchat, irssi
<chilicuil> o abrir dos sesiones del mismo cliente, y acomodar las ventanas
<chilicuil> lo que yo hago, es interpretar, en la version inglesa y pegar en la espaÃ±ola
<gus-tavo> ahi esta, hago eso, gracias !
<chilicuil> siguiendo, con la intepretacion.., En fin, permitanme comenzar con un pequeÃ±o resumen de lo que se considera por desarrollo de Ubuntu
<chilicuil> Daniel Holbach durante la primera sesion de hoy, dio una charla titulada 'Introduccion al desarrollo de Ubuntu', que se trato justo sobre esto
<chilicuil> yo solo hare un pequeÃ±o repaso sobre ello, para obtener mas detalles, pueden leer los logs de su sesion
<chilicuil> Ubuntu es un sistema operativo completo, como tal, esta hecho a partir de muchos pequeÃ±os fragmentos, llamados 'paquetes'
<chilicuil> cada paquete esta escrito en un determinado lenguaje de programacion, es compilado y a partir de eso, se crea un paquete 'binario'
<chilicuil> el instalador de Ubuntu, aquel que usan para instalar Ubuntu, hace poco mas que descargar e instalar varios de esos programas
<chilicuil> una pregunta frecuente que obtengo de prospectos a desarrolladores, es "En que lenguaje de programacion esta escrito Ubuntu?, que lenguaje deberia aprender para desarrollar a Ubuntu?"
<chilicuil> la mayoria de los programas importantes de Ubuntu, como el kernel (el kernel es el software que se encarga de pegar en una sola capa, el software y hardware de su computadora, controlar los drivers, etc), o las librerias de bajo nivel estan escritas en C
<chilicuil> los paquetes de escritorio, que forman la parte visual de Ubuntu, estan escritos en varios otros, la mayoria en C, C++, o python
<chilicuil> esta es la razon, por la que sugiero a todos los que me hacen esa pregunta, aprender python
<chilicuil> algunos ejemplos de estos programas son: El centro de software (escrito en python), Unity (C++), Nautilus el manejador de archivos (C), Gwibber (python), etc~
<chilicuil> recomiendo python, porque es facil de aprender, y al mismo tiempo les enseÃ±a las bases de la programacion, para que poco despues puedan moverse a C
<chilicuil> FlowRiser ha pregunta sobre referencias, o tutoriales para aprender python
<chilicuil> bilal lo felicita por la pregunta, y responde que le recomienda empezar por la documentacion oficial http://docs.python.org
<chilicuil> http://docs.python.org/tutorial/index.html
<chilicuil> para c++, menciona que hay cientos de tutoriales, algunos de los cuales son, cprogramming.com y cplusplus.com
<chilicuil> ademas de esos, recomienda hacer una busqueda rapida en google para encontrar otros
<chilicuil> coalitians ha preguntado si es verdad que java no muy popular dentro de la comunidad de Ubuntu
<chilicuil> bilal le responde, que si lo es, pero que no tanto como C o python
<chilicuil> y da el ejemplo de LibreOffice, cuyo codigo esta escrito en java
<chilicuil> ademas de LibreOffice, otro ejemplo popular es Eclipse, aun asi, los ejemplos de java son menos que los que se podran encontrar de C y python, esto es porque java requiere una maquina virtual para funcionar, como OpenJDK o Sun Java VM
<chilicuil> en caso de conocer java, sugiere que se aprenda C, ya que los 2 lenguajes son muy similares, y C es muy ocupado dentro de la comunidad de Ubuntu
<chilicuil> CuppaT ha preguntado si se le podria recomendar un IDE (entorno de desarrollo)
<chilicuil> bilal le recomienda que utilice vim, aunque menciona que tiene una curva de aprendizaje alta, asi que para los que no deseen aprender a usarlo, Gedit tambien es una buena alternativa
<chilicuil> tambien sugiere Geany
<chilicuil> coalitians pregunta si en Ubuntu hay aplicaciones en python que esten siendo migradas a la version 3.x del lenguaje de programacion
<chilicuil> bilal responde que en parte, y agrega que python 3.x no es compatible con su antecesor, python 2.x por lo que algunas aplicaciones aun no se han actualizado
<chilicuil> se espera que un futuro proximo, todos los programas que vienen incluidos en el CD de Ubuntu hayan sido portados a python3, y puedan deshacerse de python2
<chilicuil> recomienda que en caso de estar aprendiendo de 0, comiencen con python 3
<chilicuil> thotp pregunta cuales son las principales diferencias entre las aplicaciones en c/c++ de ubuntu y windows
<chilicuil> bilal responde que la principal diferencia reside en el stack, es decir, mientras Ubuntu usa GTK+ y QT como librerias base para programar aplicaciones graficas, Windows utiliza WPF y WinForms
<chilicuil> aunque la sintax es la misma~
<chilicuil> ademas de eso, agrega que las aplicaciones en GTK+ y QT pueden funcionar en Windows
<chilicuil> como nota relacionada, barry hablara sobre programacion en python3 en la siguiente sesion
<chilicuil> reanalizando la discusion de C en windows vs ubuntu, dice que para aprender la sintaxis basica, no importara desde que plataforma lo aprenda
<chilicuil> aunque sugiere que se aprenda en Ubuntu, ya que sera la plataforma para la cual se va a programar
<chilicuil> kamilnadeem pregunta que para un nuevo estudiante de ciencias de la computacion, cual es el mejor camino?
<chilicuil> bilal responde que seguramente en su universidad le enseÃ±aran algunos lenguajes, aunque si fuera el, comenzaria a estudiar C, puesto que seguramente se lo enseÃ±aran de cualquier forma
<chilicuil> eklok pregunta como ser un buen programador, cuantas hrs son necesarias al dia?
<chilicuil> bilal responde que no tiene que ver con el numero de horas, calidad != cantidad
<chilicuil> y dice, que la mayoria de las personas tienen agendas muy apretadas, y que muchas contribuciones se pueden hacer en 1 hr o menos
<chilicuil> dice que lo mas importane, es encontrar algo que puedas y te guste hacer
<chilicuil> FlowRiser pregunta por tutoriales para aprender c++
<chilicuil> bilal responde que para programar aplicaciones graficas, es mejor consultar las guias de Gtk, y para programaciÃ³n a secas, cplusplus.com, recomienda que comiencen aprendiendo la sintaxis antes de intentar cosas mas avanzadas, como la programacion en GTK
<chilicuil> menciona que aunque muchas personas aprenden a programar en las escuelas y universidad, en la comunidad de Ubuntu, se aprende a traves de mejorar los programas
<chilicuil> lo que ha largo plazo es mejor, que cualquier cosa que les puedan enseÃ±ar en la aulas
<chilicuil> recomienda comenzar por python, c y por ultimo c++, si no se tiene idea de programacion
<chilicuil> si se conoce java, entonces lo mejor desde su punto de vista, sera: Java -> C -> python
<chilicuil> raki1 pregunta cual es mejor, GTK+ o QT
<chilicuil> bilal responde que ambos son muy buenos, y agrega que QT tiene algunas caracteristicas extra, auqnue GTK es mas facil de aprender
<chilicuil> SamTate pregunta si cree qeu Vala es un lenguaje adecuado, despues de JS y PHP
<chilicuil> bilal responde, que aunque es un buen lenguaje, limpio sobre todo, para nuevos programadores recomienda asignarle menos prioridad
<chilicuil> esto, porque Vala aun no es un lenguaje muy comun
<chilicuil> despues de js y php, recomienda C
<chilicuil> siguiendo con la sesion.., por que los jovenes deberian estar interesados en el desarrollo de Ubuntu?
<chilicuil> bueno, primero, como ya se habia comentado, aprenderan a traves de ejemplos, de cuestiones practicas
<chilicuil> esto les ayudara a entender la programacion, mas alla de cualquier curso que se pueda dar en cualquier escuela
<chilicuil> aprenderan a resolver problemas criticos, tanto en la tecnica, como en la metodologia
<chilicuil> obtendran la ayuda de cientos de talentosos desarrolladores alrededor del mundo
<chilicuil> aprenderan a trabajar en equipo
<chilicuil> y los conoceran al mismo tiempo, haran amigos dentro de la comunidad
<chilicuil> como punto extra, se vera bien en su resumen, si piensan trabajar en el campo de las IT
<chilicuil> los colocara un nivel arriba de sus compaÃ±eros de clase
<chilicuil> contribuir a Ubuntu, es realmente, una excelente manera de pasar el rato
<chilicuil> algunos podrian pensar que es una perdida de tiempo
<chilicuil> sin embargo, es importante recordar, que el control sobre la cantidad de tiempo que le dedican la tienen ustedes
<chilicuil> ustedes deciden el tiempo que deseen y la hr
<chilicuil> y si encuentran problemas, hay muchas personas que estaran felices de ayudarlos
<chilicuil> ya sea a traves de sitios, como Ask Ubuntu, los foros, o a traves de las listas de correo ubuntu-devel@lists.ubuntu.com, ubuntu-motu@lists.ubuntu.com
<chilicuil> tambien, pueden obtener ayuda en los canales de irc, #ubuntu-app-devel para preguntas sobre desarrollo de aplicaciones, o #ubuntu-motu para preguntas sobre empaquetamiento de esas aplicaciones
<chilicuil> raki1 pregunta sobre algunas guias de GTK
<chilicuil> bilal le recomienda http://developer.gnome.org/
<chilicuil> helderc pregunta sobre partes de Ubuntu (no Kubuntu) donde se utilize QT
<chilicuil> bilal menciona que unity 2d, solia usar qt, y que Ubuntu trata a QT, como una libreria de primer nivel
<chilicuil> mesutcangurle pregunta por que Ubuntu no tiene mentores para nuevos miembros, o tareas sencilla para comenzar
<chilicuil> bilal responde que hay platicas para reactivar al grupo de mentores
<chilicuil> y sobre las formas colaborar, existen alternativas, se puede ayudar via upstream, es decir, ayudando en los proyectos originales, como en el caso de Nautilus
<chilicuil> pueden verse una lista de bugs en http://launchpad.net/ubuntu/+source/nautilus/+bugs
<chilicuil> y para enviar un parche, se puede descargar el codigo fuente, arreglar el problema, y enviar el parche
<chilicuil> si desean conocer a detalle el procedimiento para enviar estos parches, tumbleweed tendra una sesion completa para ese tema maÃ±ana
<chilicuil> tambien pueden ayudar, clasificando bugs, encontrando reportes duplicados, preguntando por mas datos, en los reportes que no sean claros
<chilicuil> o ayudando con la traduccion de ubuntu
<chilicuil> https://wiki.ubuntu.com/Translations , el equipo hispano, es especialmente activo
<chilicuil> otras formas de ayudar, incluyen, escribir documentacion, o haciendo pruebas de los alpha y beta de Ubuntu
<chilicuil> en fin, ahora contestare algunas de las preguntas que me suelen hacer
<chilicuil> primera, existe una remuneracion economica por ayudar a Ubuntu?
<chilicuil> lo que suelo responder, es que si se obtiene una recompensa, aunque esta no es economica, es de conocimientos
<chilicuil> segunda, como se pueden obtener permisos para subir los cambios?
<chilicuil> existen diferentes tipos de desarrolladores en Ubuntu https://wiki.ubuntu.com/UbuntuDevelopers
<chilicuil> cada uno de ellos, tiene permisos para subir modificaciones a diferentes partes
<chilicuil> sin embargo, en todos ellos es el mismo, una vez, que tengas un buen historial, con buenas y sustentadas contribuciones
<chilicuil> puedes aplicar para cualquier membresia
<chilicuil> una de las cosas que olvide mencionar, es que tambien puedes ayudar, creando paquetes para los programas que aun no estan disponibles en Ubuntu, de esto hablo un poco mas Daniel, en la primera sesion
<chilicuil> pueden aprender, como hacer esto en developers.ubuntu.com
<chilicuil> FlowRiser: pregunta como puede modificar y crear temas para el screen de login de ubuntu
<chilicuil> bilal responde que tendra que hechar un vistazo en la documentacion de lightdm
<chilicuil> ajitesh pregunta, cual es mejor para el desarrollo de ubuntu, c++ o python
<chilicuil> bilal responde que aunque c/c++ es mas poderoso, python es mas facil de aprender
<chilicuil> y que en realidad depende de lo que se quiera desarrollar
<chilicuil> por ejemplo, para aplicaciones con interfaz grafica, generalmente es mejor usar python, mientras que para crear cosas de bajo nivel, drivers, etc, es mejor usar C
<chilicuil> con eso termina la sesion de bilal, ahora barry hablara sobre desarrollo con python3
<chilicuil> todo tuyo gus-tavo
<gus-tavo> ops tarde, me he demorado
<chilicuil> sin problemas, gus-tavo , venga que no tenemos una audiencia tremenda, bien podrian quedar unicamente los logs
<gus-tavo> ben72 pregunta: hay manera de correr las versiones 2 y 3 de python en el mismo sistema ubuntu?
<gus-tavo> si, corriendo 'python! (aka /usr/bin/python) en cualquier sistema ubuntu harÃ¡ correr la Ãºltima verson de python 2, para ubuntu 12.04 en adelante es python 2.7
<gus-tavo> para correr python 3 se necesita explicitamente correr 'python3' Ã³ /usr/bin/phython3'
<gus-tavo> puedo hablar de las diferencias entre python 3.2, por defecto en la distribucion ubuntu, y python 3.3 mÃ¡s tarde
<gus-tavo> nickE68 pregunta: Quantal usara Python 3.3?
<gus-tavo> No, python 3.2 sera todavÃ­a la version por defectho, la 3.3 no va a estar lista al momento del freeze. va a estar por defecto en la version 13.04
<gus-tavo> quantal tiene la version 3.3 disponible  a traves de: apt-get install python3.3
<gus-tavo> e invocado a travÃ©s de 'python3.3'
<gus-tavo> asÃ­ pueden jugar con las nuevas caracteristicas
<gus-tavo> quantal tendra la 2.7, 3.2 y 3.3 con las dos primeras como por defecto
<gus-tavo> entonces, por que portar a python 3?
<gus-tavo> nunca habra un python 2.8, les puedo asegurar : )
<gus-tavo> lo que implica que py2 nunca tendra alguna nueva caracterÃ­stica
<gus-tavo> y el arreglo de errores, a traves de los canale oficiales tomara mas que lo usual
<gus-tavo> eventualmente 2.7 solo tendrÃ¡ correcciones de seguridad, pero supongo que desarrollos upstream estarÃ¡n menos interesados en matener la 2.7 a medida que pase el tiempo
<chilicuil> hola alvaro_ , bienvenido, si andas un poco perdido, los logs generados hasta el momento en http://irclogs.ubuntu.com/2012/08/28/%23ubuntu-classroom-es.html
<chilicuil> y en http://irclogs.ubuntu.com/2012/08/28/%23ubuntu-classroom.html para la sesion en Ingles
<gus-tavo> los modulos quedaran obsoletos
<gus-tavo> py2 tiene tambiÃ©n muchas errores, algunos pequeÃ±os otros grandes
<gus-tavo> y mas importante imo: py3 soluciona el problema entre bytes vs. text
<gus-tavo> (la mayorÃ­a : )
<gus-tavo> significando, tenemos el potecian de hacer aplicaciones py3 mas robustas
<gus-tavo> para usuarios no hablantes  ingles
<gus-tavo> mas sobre bytes vs cadenas mas tarde
<gus-tavo> cuÃ¡les son los planes de ubuntu para py3?
<gus-tavo> estamos en una larga carrera para deprecar python2. hemos esperado a portar todo en las imÃ¡genes de intalacion para py3 en 12.10, pero encontramos unos bloqueos problematicos y no va a pasar para la 12.10
<gus-tavo> tal vez para la 13.04, definiitivamente para la proxima lts
<gus-tavo> py2.7 nunca sera removida del archivo, pero va a estar en el universo para la 14.04, si podemos
<gus-tavo> hablemos acerca de portar
<gus-tavo> dejenme darles uno enlaces primero:
<gus-tavo> este es uno de los mejores recursos disponibles para entender como portar tu aplicacion py2 a py3
<gus-tavo> http://python3porting.com/
<gus-tavo> coalitians pregunta:
<gus-tavo> desde que el desarrollo para 12.10 se congelÃ³, no hay actividades de portar ahora?
<gus-tavo> coalitians: tendriamos definitivamente una ffe para el servicio backend de gwibber portada a py3- tal vez haya otras pocas, pero a la larga hecha con los esfuerzos de portado para 12.10, desde aqui esto seria un error a arreglar
<gus-tavo> los enlaces arriba hablan de estrategiss, dan ejemplos de codigo para la conversion de idimas comunes, un poco de extensiones c, y mucho mas
<gus-tavo> y he escrito un numero de blog posts que encontrarÃ¡n explicativas:
<gus-tavo> http://tinyurl.com/7tb3jkn
<gus-tavo>  http://tinyurl.com/7famvx3
<gus-tavo> http://tinyurl.com/6ufpvfq
<gus-tavo> tambien hay una pÃ¡gina en la wiki ubuntu con ayuda especifica para portar, incluyendo como empaquetar librerÃ­as python y aplicaciones para py3 o para py2/py3
<gus-tavo>  https://wiki.ubuntu.com/Python/3
<gus-tavo> tambien les voy a ddar este enlace para la charla de pycon 2012. les recomiendo que vean esto antes de que hagan cualquier trabajo significante con py3. Es la mejor descripcion para el tema bytes vs. cadenas. realmente una gran charla
<gus-tavo> http://pyvideo.org/video/948/pragmatic-unicode-or-how-do-i-stop-the-pain
<gus-tavo> hablemos de las estrategias para portar
<gus-tavo> permitanme decirles que si comienzan con un nuevo proyecto python, les sugiero que vayan directo a py3. tienen que asegurarse de que cualquier dependencia (ej. librerias de terceros que quieran usar) esttÃ©n disponible para py3 en ubuntu
<gus-tavo> hemos trabajado fuerte estos ultimos ciclos para asegurar el soporte py3
<chilicuil> hola mary_, bienvenida, si andas un poco perdida, los logs generados hasta el momento estan en http://irclogs.ubuntu.com/2012/08/28/%23ubuntu-classroom-es.html
<chilicuil> y en http://irclogs.ubuntu.com/2012/08/28/%23ubuntu-classroom.html para la sesion en Ingles
<gus-tavo> y hemos portado en upstream algunos paquetes (dbus-python)
<gus-tavo> por supuesto, no todo esta disponible, pero *mucho* estÃ¡ hecho, asÃ­ que probablemente estarÃ¡n en una gran ventaja con quantal
<mary_> gracias!
<gus-tavo> roadmr pregunta: que camibon recomendas si yo quiero portar una aplicacion usando gstreamer a Python3?
<gus-tavo> desafortunadamente no tengo mucha experiencia con gstreamer, asi que no estoy seguro que version py3 esta disponible, asi, donde (upstream, debian, ubuntu)
<gus-tavo> "pienso" que no esta, pero no me marques por eso : )
<gus-tavo> para el nuevo codigo, que acerca de portar codigo existente a py3?
<gus-tavo> preguntate esto: necesitas mantener soporte py2?  y si es asi, cuanto tiempo atras necesitas el soporte??
<gus-tavo> recomendarÃ­a altamente nada mas alejado que py2.6 (no esta disponible en niguna forma en quantal)
<gus-tavo> recomendarÃ­a al menos py2.7 para algun exento 2.6 tiene muchos caracteristicas portadas que pueden hacer portado, y soportando py2 y py3 mas facil
<gus-tavo> a traves de cosas como "from__future__impor"
<gus-tavo> asi cuando comiencen a portar, la primera cosa a hacer es correr su codigo con 'python2.7 --3'
<gus-tavo> chilicuil, termino, no traduzco mas ?
<gus-tavo> me quede muy atras
<chilicuil> gus-tavo: ya no hay mas sesiones por delante, si aun te queda tiempo, podrias terminar la sesion, si no, no hay problema puedo ayudar con el resto
<gus-tavo> bueno, vos podes terminar de traducir ?
<chilicuil> si gus-tavo , gracias por tu tiempo, terminando igual harÃ© la interpretacion de las charlas a las cuales no pude llegar
<chilicuil> y anexo los logs a la wiki =)
<gus-tavo> bueno, no entendi mucho, espero estar mas afilado maÃ±ana :)
<chilicuil> seguro gus-tavo, gracias =)!
<chilicuil> siguiendo con la interpretacion...
<chilicuil> a traves de cosas como "from__future__impor"
<chilicuil> asi cuando comiencen a portar, la primera cosa a hacer es correr su codigo con 'python2.7 --3'
<chilicuil> la opcion -3 les mostrara advertencias sobre cada caracteristica de su programa que no pueda ser convertido facilmente con el programa 2to3 (mas sobre eso en un momento)
<mary_> luego en el log cuando se termine las sesiones estaran disponibles en la misma direccion arriba?
<chilicuil> por el contrario, si su programa corre bien con 'python2.7 -3', el proceso de transicion sera muy simple
<chilicuil> mary_: si, tambien a traves de https://wiki.ubuntu.com/SemanaDesarrollador , ambas las inglesas y sus interpretaciones espaÃ±olas
<gus-tavo> si mary, en ingles, las traduccines tambien estan en la wiki
<gus-tavo> https://wiki.ubuntu.com/SemanaDesarrollador
<chilicuil> 2to3 es un framework de transformacion de codigo, puede tomar la mayoria de las caracteristicas de un programa escrito para python2 y convertilo a codigo para python3
<chilicuil> mi opinion personal es que la salida que devuelve 2to3 es una excelente inicio, pero su codigo no deberia usarse para sistemas en produccion
<chilicuil> desde mi punto de vista, se deberia usar un unico codigo base y tener cuidado en como se programa, tambien se deberia usar imports from-future tanto como sea posible
<chilicuil> existe una libreria llamada 'six' (creo que se instala con $ apt-get install python-six) que puede simplificar el mantenimiento de su codigo fuente
<chilicuil> todos estos tips estan bien, sin embargo, si quisiera recalcar algo, seria tener *muy bien* definido la diferencia entre los modelos de datos (por ejemplo, entre los datos del programa, y las cadenas, legibles por humanos)
<chilicuil> si tienen varios errores del tipo UnicodeErrors, significa que no estan siendo suficientemente claros en esa division
<chilicuil> esta division, es uno de los grandes beneficios (y dolores de cabeza) de actualizar su codigo a py3, sin embargo, una vez que lo hagan, sus usuarios de lenguas que no sea el Ingles dejaran de tener esos errores 'UnicodeErrors'
<chilicuil> BlessJah pregunta si es posible escribir codigo en py3 que tambien funcione en py2?
<chilicuil> barry contesta que hacia abajo no hay mucha diferencia, asi que definitivamente debe ser posible
<chilicuil> espero que todos hayan entendido la diferencia entre bytes y cadenas
<chilicuil> bytes son datos en binario, ejemplo: imagenes, audio, video, etc
<chilicuil> mientras que cadenas, es texto que puede ser leido por otras personas
<chilicuil> en py2 se tienen 2 diferentes tipos de cadenas, str que tambien se conocen como cadenas de 8 bits, y que pueden ser utilizadas como cadenas de texto, o como datos binarios
<chilicuil> tambien existe el tipo unicode, que son justo esto, cadenas en unicode legibles para humanos
<chilicuil> el problema de py2 es que comunmente mezclaba ambos, muchas veces en formas que no eran correcta, y que provocan algunos problemas 'UnicodeErrors'
<chilicuil> en py3 se tienen bytes que *solo* pueden ser tratados como datos binarios
<chilicuil> y str que solo son unicodes
<chilicuil> estos 2 tipos no se mezclan, no existen metodos de conversion de uno a otro que sean automaticos
<chilicuil> por ejemplo, no se pueden concadenar uno sobre otro, sin hacer una conversion *explicita*
<chilicuil> asi que si tienes una cadena unicode, puedes convertirla a bytes, aunque para eso, debes conocer el encoding en el que se encuentran (la mayoria de las veces en utf-8, aunque tambien es frecuente que esten en latin-1 o algun otro)
<chilicuil> para ir de bytes a str, tienes que decodificarlo, otra vez, para hacer eso, debes ser claro en el encoding al que quieres convertirlo
<chilicuil> otro punto importante a recordar es que en py3, la funcion open() abrira los archivos en el modo binario por defecto
<chilicuil> a diferencia de py2, py3 tambien tomara un argumento que establezca el encoding a utilizar
<chilicuil> open('mi_archivo', encoding='utf-8')
<chilicuil> de esta manera, se estaran leyendo cadenas del archivo codificadas en unicode
<chilicuil> esto es genial (asumiendo que su archivo, realmente utilice la codificacion utf-8 en primer lugar :)
<chilicuil> en py3, ya no se usa el prefijo u'', las cadenas literalmente se guardan como unicodes
<chilicuil> (de hecho: el prefijo u'' se volvio a introducir py3.3, pero lo que he dicho anteriormente escencialmente es correcto)
<chilicuil> para escribir bytes literalmente, se usa el prefijo b''
<chilicuil> ejemplo: este es el byte: b'foo'
<chilicuil> y esta, la cadena: 'foo'
<chilicuil> otra nota rapida sobre esto es que ahora pueden usar de forma segura el modulo 'gettext' en py3, puesto que gettext siempre devolvia unicodes como resultado de su ejecusion
<chilicuil> hay mas preguntas sobre este tema, o puedo continuar con otro?
<chilicuil> NickE68 pregunto sobre los archivos donde no se sabe el encoding de antemano, pregunta si existe una libreria que pueda adivinarlo
<chilicuil> barry responde que si existe, pero que ahora mismo no recuerda su nombre, aunque parece que esta relacionada con el proyecto mozilla
<chilicuil> en general, recomienda probar con algunos encodings si no se sabe, por ejemplo, primero utf-7, luego latin-1, luego ascii.., y asi
<chilicuil> roadmr pide una aclaracion sobre eso de que 'gettext' siempre devuelve unicodes, esto se refiere a 'cadenas'?, en lugar de 'bytes'?
<chilicuil> barry contesta que si, y agrega que desafortunadamente en py2,  gettext.gettext('foo') siempre devolvia una cadena de 8 bits que causaba problemas, ademas de eso, el api para analizar unicodes en py2 era muy dificil de usar y no se usaba por defecto
<chilicuil> en py3 por el contrario, gettext.gettext('foo') siempre devuelve un tipo 'str', es decir una cadena en unicode
<chilicuil> barry agradece por pasarle el tipo puntual, que es python-chardet
<chilicuil> regresando a la sesion., durante los siguiente 17 minutos, dare un tour sobre los principales cambios y nuevas caracteristicas en py3 de las que vale la pena estar informado
<chilicuil> no es de ninguna manera, una lista completa
<chilicuil> hay varios documentos, sobre los nuevos cambios, para cada nueva version de python 3, pero hasta donde se, no una sobre las diferencias entre por ejemplo python 2.7 y python 3.2
<chilicuil> aunque la liga que les di hace rato sobre porting a python esta muy cerca
<chilicuil> sientanse libres de preguntar, cualquier cosa mientras comento esta lista
<chilicuil> mcuhas partes de la libreria standard 'stdlib' han sido modificadas
<chilicuil> lo que significa que algunos modulos antiguos, y modulos que estaban siendo actualizados, fueron finalmente eliminados
<chilicuil> muchos de estos modulos no los extraÃ±aran, a menos que esten haciendo procesamiento de imagenes sobre irix, en cuyo caso preguntaria, que estan haciendo aqui? =)
<chilicuil> muchos otros modulos, han cambiado de ubicacion, algunos otros los movieron a paquetes
<chilicuil> por ejemplo, la funcion urlparse() ahora es parte de urllib.parse.urlparse()
<chilicuil> para conocer todas estas diferencias, la mejor guia que pueden revisar es http://docs.python.org/py3k/library/~
<chilicuil> algunas funciones integradas en python tambien han sido modificadas o removidas del todo
<chilicuil> por ejemplo, la funcion reload() se puso en imp.reload()
<chilicuil> para las funciones que se han eliminado, y que son de este tipo, existen generalmente buenas alternativas
<chilicuil> por ejemplo, la funcion callable() se quito, pero ahora pueden si la funcion existe, llamandola ;), o a travÃ©s del modulo 'inspect'
<chilicuil> otro gran cambio, que me trajo muchos problemas, al menos hasta que aprendi la nueva forma (y despues de empezar a usar "from __future__ import print_function" en mi codigo py2)
<chilicuil> fue que la funcion el predicado 'print' se ha convertido en funcion, por ejemplo: print('hello world')
<chilicuil> esto fue muy problematico, pero tiene mucho sentido, eventualmente ustedes tambien comprenderan por que el cambio :)
<chilicuil> recuerdan como python2 solia tener 2 tipos de clases?, las clasicas y las nuevas?
<chilicuil> bueno, con py3, se eliminaron las clasicas
<chilicuil> lo que significa que ya no tiene que heredar de objetos
<chilicuil> o usar el truco "__metaclass__ = type" para obtener las geniales caracteristicas de las clases con 'el nuevo estilo'
<chilicuil> asi que supongo, que ahora tendremos que dejarle de llamar 'el nuevo estilo', puesto que es el unico que queda =)
<chilicuil> py2 solia tener 2 tipos de enteros, int y long
<chilicuil> py3 ha eliminado long, asi que solo queda 'int'
<chilicuil> automaticamente se encarga de como representar internamente los enteros pequeÃ±os y grandes
<chilicuil> tambien se elimino el sufijo 'L' para los enteros
<chilicuil> jsjgruber-l82-p ha preguntado si existen algun tipo de float que tenga una presicion elevada en py3
<chilicuil> barry responde que si, pero que el hace muy pocos calculos en python, asi que no puede darle una referencia exacta
<chilicuil> agrega, que conoce un tipo 'decimal', pero que no esta accesible por defecto
<chilicuil> siguiendo con la lista, los metodos de dict.iter*() ya no existen en python3, es decir, ya no existen mas las funciones .iterkeys(), .itervalues(), o .iteritems()
<chilicuil> para estos casos, se puede usar .keys(), este metodo devuelve iteradores y *no* listas concretas
<chilicuil> asi que probablemente tendran que analizar el valor que regrese, list(dict.values())
<chilicuil> la sintaxis para capturar excepciones se cambio (algunso de estos cambios tambien se hicieron en py2.6 y py2.7)
<chilicuil> "except Foo, e" se cambio por
<chilicuil> "except Foo as e"
<chilicuil> exec tambien se convirtio en funcion, exec()
<chilicuil> file() se quito, y en su lugar se recomienda el uso de open()
<chilicuil> tambien se elimino xrange(), para los que deseen una funcionalidad similar, tendra que regresar a range(), que ahora devuelve un iterador
<chilicuil> filter() y map() tambien devuelven interadores
<chilicuil> una vez mas, para las funciones que devuelven iteradores, tienen que usar list() para crear una lista concreta
<chilicuil> los imports absolutos ahora son los que usan por defecto, asi que tendran que hacer explicito su deseo de usar imports relativos
<chilicuil> 1/2 ahora regresa 0.5
<chilicuil> 1 / 2 ahora regresa 0.5
<chilicuil> 1/2 (junto) devuelve la vieja forma de representar los flotantes
<chilicuil> coalitians pregunta como y donde tienen que estar para ser parte de la comunidad de python en Ubuntu
<chilicuil> barry responde que sugiere entrar al canal #debian-python en OFTC, a #ubuntu-devel y a #python (estas ultimas 2 en freenode)
<chilicuil> y aclara que no existe un foro unicamente para python en Ubuntu, aunque considera que deberia existir uno
<chilicuil> NickE68 pregunta si existe una lugar donde se listen los paquetes que necesiten ser portados a Ubuntu 13.04
<chilicuil> barry: responde que si, y da las siguiente ligas
<chilicuil> https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0AiT4gOXSkmapdFA1anRkWERsaXgtWnllUG9QWXhDVWc&pli=1#gid=0
<chilicuil> https://blueprints.launchpad.net/ubuntu/+spec/foundations-q-python-versions
<chilicuil> https://wiki.ubuntu.com/Python/FoundationsQPythonVersions
<chilicuil> ademas de eso, invita a lo contacten en #ubuntu-devel para mayor informacion, estara feliz de ayudar
<chilicuil> con eso termina la excelente sesion de barry =)
<chilicuil> ahora, tomare 10 minutos, y regresare a subir los logs a la wiki, y a interpretar las sesiones que hicieron falta, Daniel Holbach "Introduccion al desarrollo de Ubuntu"
<joshua1983> buenas tardes, ya estan listas las traducciones en irclogs.ubuntu?
<chilicuil> joshua1983: hola, joshua, si, varias de ellas, http://irclogs.ubuntu.com/2012/08/28/%23ubuntu-classroom-es.html , ahora mismo, estoy actualizando la wiki para reflejar los cambios
<chilicuil> comienzo con la interpretacion de "Introduccion al desarrollo de Ubuntu", por Daniel Holbach
<chilicuil> antes de comenzar me gustaria dar unos cuantos tips, que les ayudara a disfrutar del evento
<chilicuil> primero, asegurense de entrar a #ubuntu-classroom-chat
<chilicuil> #ubuntu-classroom es solo para la clase, la platica y preguntes se hacen en #ubuntu-classroom-chat
<chilicuil> si tienen alguna pregunta, haganla usando el prefijo QUESTOIN:
<chilicuil> ejemplo, QUESTION: Can you recommend any good music for a late-night hacking session?
<chilicuil> si tienen problemas para hacer su pregunta en ingles, haganla en este canal, y con gusto les ayudaremos a hacerla en la sesion original
<chilicuil> tambien, es buena idea que revisen https://wiki.ubuntu.com/UbuntuDeveloperWeek si desean conocer el calendario de las charlas que se estaran haciendo
<chilicuil> dos de las preguntas mÃ¡s frecuentes que se hacen son: 1.- abran logs disponibles?
<chilicuil> para esa pregunta, la respuesta es si, se pondran en https://wiki.ubuntu.com/UbuntuDeveloperWeek/
<chilicuil> para la interpretacion, los logs estaran disponibles en https://wiki.ubuntu.com/SemanaDesarrollador
<chilicuil> la segunda pregunta es: 'como puedo ignorar todo el ruido que se genera, cuando las personas y entran de la sala?'
<chilicuil> para esa pregunta, la respuesta es, escriban "/ignore #ubuntu-classroom CRAP NOTICES SNOTES CTCPS JOINS PARTS QUITS KICKS MODES WALLOPS NICKS DCC DCCMSGS CLIENTNOTICES CLIENTCRAP CLIENTERRORS HILIGHTS" en la ventana de este canal
<chilicuil> sin el " obviamente
<chilicuil> en fin, eso es todo lo que dire, sobre aspecto organizacionales, que comiencen las sesiones! =)
<chilicuil> mi nombre es Daniel Holbach, he estado trabajando en Ubuntu por casi todo el tiempo que lleva existiendo y siempre me ha gustado nuestra comunidad de desarrolladores
<chilicuil> he trabajado durante aÃ±os para canonical, comence en el equipo Desktop, y despuÃ©s como parte de nuestra comunidad de desarrolladores
<chilicuil> durante esta sesion, les mostrare como funciona en general el desarrollo de Ubuntu
<chilicuil> al principio parecera un caos, puesto que siempre hay personas modificando cosas por todos lados, sin embargo, pronto se daran cuenta de lo facil que es :)
<chilicuil> tambien me gustaria responde la mayor cantidad de preguntas posibles
<chilicuil> si voy demasiado rapido, o lo que digo no les hace sentido, comentenlo =)
<chilicuil> Ubuntu esta hecho de miles de diferentes programas, todas ellos escritos en diferentes lenguajes, cada componente - ya sea una libreria de software, una herramienta del sistema, o una aplicacion grafica, esta disponible como un paquete, y el codigo fuente de dicha aplicacion integrado en el
<chilicuil> los paquetes de codigo fuente consisten en la mayoria de los casos, de 2 partes, el codigo fuente en si, y metadatos que describen el paquete, esto incluye las dependencias, el copyrigh y las instrucciones sobre como compilar el programa
<chilicuil> una vez que el paquete se compila, el proceso de construccion creara un paquete binario, estos paquetes binarios son los archivos .deb que los usuarios instalan
<chilicuil> cada vez que se libera una nueva version del programa, o que alguien hace una modificaciÃ³n, el paquete debe subirse a Launchpad, ahi, sera recompilado
<chilicuil> los paquetes .deb que resulten, seran distribuidos a traves del archivo y los diferentes mirros de ubuntu alrededor del mundo. Las urls que se encuentran en /etc/apt/sources.list apuntan a esos repositorios
<chilicuil> todos los dias, diferentes imagenes de Ubuntu se crean, por ejemplo, ubuntu desktop, ubuntu server, kubuntu, etc. Estas imagenes para CD se utilizan para hacer pruebas y hacer comentarios sobre los planes de lanzamiento
<chilicuil> como nota al margen, debo mencionar que durantes los ultimos 2-3 ciclos, hemos comenzado a crear un enorme laboratorio de QA, en el se varias pruebas en toda clase de programas, esto obviamente tambien es tomado en cuenta para modificar los planes de lanzamiento
<chilicuil> el desarrollo en Ubuntu, depende de alguna forma, del estado del ciclo en el que se este
<chilicuil> liberamos una nueva version de Ubuntu cada 6 meses, esto solo es posible debido a que establecemos fechas estrictas donde prohibimos hacer mas cambios (freeze dates)
<chilicuil> con cada nueva de estas fechas, se va sugiriendo a los desarrolladores introducir menos modificaciones
<chilicuil> si hechan un vistazo a https://wiki.ubuntu.com/QuantalQuetzal/ReleaseSchedule veran las fechas importantes para la version actual de Ubuntu, la 12.10
<chilicuil> como podran ver, acabamos de pasar la fecha de congelamiento (feature freeze)
<chilicuil> esta fecha, es la primera de las que se daran para detener el desarrollo, y se da despues de haber avanzado la mitad del ciclo. Despues de esta fecha, la mayoria de las caracteristicas que contendra la proxima version de Ubuntu deberan estar hechas, el resto del ciclo se utiliza para pulir la distribucion, y para corregir los bugs que se encuentren
<chilicuil> despues de esta fecha, se empiezan a prohibir cambios en la interfaz grafica, en la documentacion, en el kernel, etc.., una vez hecho esto, se liberan las versiones beta, las cuales se prueban en gran cantidad de usuarios debido a su madurez
<chilicuil> y se comienzan a solucionar unicamente los errores criticos, cuando ya no hay mas errores importantes, se convierte en la version final, y esa es la que se pone a disposicion del publico en general
<chilicuil> alguna pregunta hasta el momento?
<chilicuil> marcos pregunta si QA significa 'Question and Answer' o 'Pregunta y respuesta'
<chilicuil> a lo que dholbach responde que de hecho significa 'Quality Assurance' o 'Aseguramiento de la calidad'
<chilicuil> lo que a su vez significa que es donde se hacen toda clase de pruebas, tanto automaticas como manuales, tambien es donde se hacen pruebas de la integridad de los CD, y donde se verifica que los sistemas son instalables, entre otras cosas
<chilicuil> QA es lo que hace que Ubuntu en lugar de ser bueno, sea excelente
<chilicuil> conner_bw pregunta sobre el criterio para definir que 'ya no hay ningun problema critico'
<chilicuil> dholbach responde que aunque no hay un criterio extremadamente formal, el que se pierdan datos, o que existan aplicaciones cruciales que no funcionen (y con aplicaciones cruciales se definen las que vienen en un sistema Ubuntu por defecto) es sin duda un critero que se toma en cuenta para decidir si esta o lista la distribucion
<chilicuil> agmenor_ pregunta sobre la version de Ubuntu que tiene que correr si el un desarrollador de aplicaciones
<chilicuil> dholbach responde que en su caso, seria suficiente que usara la ultima version estable, es decir, la version 12.04
<chilicuil> aunque si desea modificar a Ubuntu directamente, necesita correr la ultima version en desarrollo, es decir Ubuntu 12.10
<chilicuil> esto es, porque los cambios que se hacen deben probarse antes de su inclusion
<chilicuil> paulo_gomes pregunta que es lo que pasa, cuando una nueva aplicacion es liberada, pasada la fecha de congelamiento de ubuntu, se tiene que esperar hasta la proxima version de Ubuntu?
<chilicuil> dholbach responde que depende, si el software es liberado antes de la fecha de congelamiento, puede incluirse sin problemas, si es una actualizacion que arregla problemas importantes, puede que pase incluso despues de la fecha de congelamiento de Ubuntu, sin embargo, conforme vayan pasando los dias, cada vez sera mas dificil convencer al equipo que se encarga de la liberacion (el release team)
<chilicuil> esto es por una buena razon: se necesita tiempo para probar las cosas
<chilicuil> hablare sobre eso, un poco mas adelante
<chilicuil> conner_bw vuelve a preguntar sobre el criterio para definir los errores criticos que impiden el lanzamiento de Ubuntu, esto lo hace, porque usando 12.04 esta inscrito a algunos bugs que a su consideracion son muy importantes, y que no detuvieron que Ubuntu precise se liberara, por ejemplo la integracion del launcher de LibreOffice
<chilicuil> dholbach responde que algunas veces se tienen que tomar decisiones que permitan liberar Ubuntu el dÃ­a en el que esta marcado, este proceso no es facil, pero tiene que hacerse
<chilicuil> Liverpudlian pregunta si las aplicaciones se desarrollan de diferente manera cuando se crean para versiones LTS
<chilicuil> obounaim pregunta sobre la ulr del equipo QA
<chilicuil> dholbach da la liga https://wiki.ubuntu.com/QATeam/ y sugiere que se lea como introduccion
<chilicuil> dholbach responde a Liverpudlian que definitivamente, y agrega que muchas personas deciden utilizar esas versiones por mucho tiempo, asi que los autores se esfuerzan por hacer que sus aplicaciones sean incluidas
<chilicuil> C1sM0 pregunta si los archivos .deb se crean automaticamente una vez que el codigo fuente se sube a launchpad
<chilicuil> dholbach responde que si, aunque eso puede tardar un poco, porque se organizan en filas, debido a la falta de maquinas asignadas para compilar que se tienen en launchpad
<chilicuil> sin embargo, la espera comunmente es de menos de 1 hr
<chilicuil> nja pregunta porque la seccion de trabajo en el calendario de lanzamiento de quantal dice A-2 en lugar de A-1
<chilicuil> dholbach responde que realmente no esta seguro, y pregunta si se refiere a lo que aparece en http://status.ubuntu.com/ubuntu-quantal/
<chilicuil> sugiere que tal vez se deba a que la ultima liberacion intermedia fue Alpha 2, aunque confirma que no tiene idea
<chilicuil> marcos pregunta si el concurso App Showdown acepta aplicaciones privativas / comerciales
<chilicuil> dholbach responde que hasta donde sabe, no
<chilicuil> dholbach pide que por el momento, las preguntas y la charla se centre en el desarrollo de Ubuntu por si mismo, y se deje el tema de las aplicaciones para las siguientes sesiones, agrega que parte de lo que ahora mismo se discute (como las fechas de congelamiento) aplican para ambos temas
<chilicuil> _et pregunta si usan C-I para compilar los paquetes
<chilicuil> dholbach responde que no conoce de C-I, pero que todos los programas, se compilan en launchpad, que es un plataforma de software libre hecha a partir de Zope/Python, y que el sistema de compilacion por si mismo se hace con la ayuda de 'sbuild'
<chilicuil> ziviani pregunta sobre la personas que definen las caracteristicas que se implementan en un cilo, y tambien sobre que pasa, con aquellas que no pudieron implementarse antes de la fecha de congelamiento (freeze date)
<chilicuil> dholbach responde que aquellas caracteristicas que no pueden completarse, se dejan para el siguiente ciclo, y que las decisiones sobre lo que se hace las toma el equipo de lanzmiento (el release team), y los respectivos lideres de los sub equipos de ubuntu
<chilicuil> nja pregunta porque la aplicacion Lernid tiene integrada una terminal
<chilicuil> dholbach responde que es porque cuando los ponentes deciden hacer algun ejercicio, los asistentes pueden correrlo en su sistema
<chilicuil> marcos pregunta si las versiones estables, como Ubuntu 12.04.1 aceptan nuevas caracteristicas
<chilicuil> dholbach responde que no, que lo "unico" que se acepte son actualizaciones de seguridad, correccion de errores pequeÃ±os, nuevas traducciones y cuestiones por el estilo, que sean seguras de implementar
<chilicuil> y agrega que con los recursos actuales es muy dificil concentrarte en ambas versiones (la 12.04 y la 12.10 por poner un ejemplo)
<chilicuil> Henrich pregunta si existe una lista donde pueda ver las maquinas que crean los paquetes
<chilicuil> dholbach responde que si, y le pasa el link https://launchpad.net/builders/
<chilicuil> tambien agradece la avalancha de preguntas =)
<chilicuil> asegura que aunque sus dedos le duelen, aun no ve sangre, asi que cree seguro continuar
<chilicuil> miles de aplicaciones, billones de lineas de codigo, cientos de colaboradores, requieren mucha comunicacion y planeacion para mantener altos niveles de calidad
<chilicuil> asi que al comienzo de cada ciclo, se organiza el Ubuntu developer Summit, donde tanto desarrolladores como contribuiores se reunen para hablar sobre las caracteristicas de la siguiente version de Ubuntu
<chilicuil> cada idea se discute, y se toman anotaciones sobre la informacion requerida para implementarla, de los cambios que se necesitan hacer en otros lugares, del plan para probarla, etc
<chilicuil> todo esto se hace en un ambiente abierto y transparente, asi que incluso cuando no puedan asistir en persona, siempre pueden participar en linea, escuchar los streamcast, hablar con los asistentes y suscribirse a la lista de modificaciones y especificaciones de cada tema, de esta forma, siempre pueden mantenerse al dia
#ubuntu-classroom-es 2012-08-29
<chilicuil> comenzare con la interpretacion de la ultima sesion del dia de hoy, 'Configuracion del entorno, para el desarrollo de Ubuntu'/'Getting set up for Ubuntu development' por Daniel Holbach
<chilicuil> durante esa charla se configura el entorno, las herramientas y todo lo que sea necesario para que puedan aprovechar el resto de las sesiones, y para que puedan involucrarse con el desarrollo de Ubuntu
<chilicuil> si logramos terminar a tiempo, podemos incluso avanzar un poco mas, y analizar algun paquete
<chilicuil> esta sesion sera practica, les sugiero que tengan abierta por lo menos una terminal
<chilicuil> hay ciertas cosas que necesitan hacer para tener un sistema listo para el desarrollo de Ubuntu
<chilicuil> algunas de ellas son; configurar sus equipos para modificar paquetes, y para subir sus cambios a Launchpad, la plataforma de desarrollo de Ubuntu
<chilicuil> esto es lo que haremos:
<chilicuil> - Instalar programas para empaquetar programas. Esto incluye: utilidades especificas de Ubuntu, software de cifrado (para que podamos verificar quien ha hecho los cambios), y software para transmitir de forma segura datos entre la plataforma y su computadora
<chilicuil> - Crear y configurar una cuenta en launchpad
<chilicuil> - Configurar software para poder recompilar paquetes en su equipo, para interactuar con otros desarrolladores, y para enviar parches a Launchpad
<chilicuil> es recomendable hacer el trabajo de empaquetamiento usando la version en desarrollo de Ubuntu, de esta forma, pueden hacer pruebas en el mismo entorno donde seran integrados
<chilicuil> asi que tendran que correr Ubuntu Quantal (12.10) de alguna forma
<chilicuil> no teman, podran hacerlo a traves de un entorno chroot, de una maquina virtual, o por algun metodo parecido
<chilicuil> aunque si les es posible, lo mejor seria que pudieran hacer las pruebas en un entorno que utilicen todos los dias
<chilicuil> https://wiki.ubuntu.com/UsingDevelopmentReleases explica algunos metodos para correr la ultima version de forma segura
<chilicuil> si alguno de ustedes utiliza 12.04, no importa, pueden seguir las instrucciones, y luego repetirlas en su entorno de desarrollo
<chilicuil> existen un numero de utilidades que les hara la vida mas facil como desarrolladores de Ubuntu, analizaremos algunas mas tarde, por lo pronto, para instalarlas, copien y peguen este comando en su terminal
<chilicuil> $ sudo apt-get install packaging-dev
<chilicuil> esto tomara unos minutos, asi que dejenlo funcionando
<chilicuil> al finalizar tendran instalado el siguiente software
<chilicuil> - gnupg, el gnup privacy guard contiene herramientas que necesitan para crear llaves criptograficas, con estas llaves se firman los archivos que se suben a Launchpad
<chilicuil> - pbuilder, esta es una herramienta para recompilar los paquetes, en un entorno limpio y completamente aislado
<chilicuil> - ubuntu-dev-tools (y devscripts, que figura como dependencia directa), es una coleccion de scripts que permiten automatizar algunas de las tareas de empaquetamiento
<chilicuil> - bzr-builddeb (y bzr, como dependencia), sirve para obtener un sistema de control de versiones basado en Bazaar, esta es una forma relativamente nueva de trabajar con los paquetes en Ubuntu, a mediano plazo permitira que varios programadores de Ubuntu puedan colaborar mas rapido y facilmente
<chilicuil> - apt-file, es una herramienta para encontrar el paquete al que pertence determinado archivo
<chilicuil> - y obviamente muchas otras cosas buenas que no cubriremos en esta guia introductoria :)
<chilicuil> alguna pregunta hasta aqui?
<chilicuil> NickE pregunta sobre la maquina virtual que usa TestDrive
<chilicuil> dholbach responde que la ultima vez que vio, usaba kvm
<chilicuil> nja pregunta si es necesario correr "apt-file update" despues de instalar ese metapaquete
<chilicuil> dholbach responde que no cree que sea necesario. nota del interprete: si que es necesario, por lo menos una vez justo despues de la instalacion
<chilicuil> conner_bw pregunta si bzr esta grabado en piedra, o si algun dia se podra usar git en su lugar
<chilicuil> dholbach responde que no lo sabe, y que tal vez seria mejor preguntar en #launchpad
<chilicuil> agrega que aunque personalmente le gusta trabajar con bzr, porque es facil de aprender, comprende que otras personas prefieran trabajar con otros sistemas de control de versiones, como git, o hg
<chilicuil> la buena noticia es que Launchpad puede importar ramas de git, y de otros sistemas, asi que despues de importarlos pueden trabajar con bzr nativamente
<chilicuil> en fin, vayamos a la accion!
<chilicuil> el primer paso es hacer que las herramientas de empaquetamiento conozcan sobre ti, asi que por favor, abran su archivo ~/.bashrc con editor de texto, y agreguen algo como esto al final
<chilicuil> export DEBFULLNAME="Bob Dobbs"
<chilicuil> export DEBEMAIL="subgenius@example.com"
<chilicuil> reemplacen el nombre y correo con los suyos :)
<chilicuil> ahora, guarden el archivo, y cierren y vuelvan a abrir su terminal, o utilicen el comando:
<chilicuil> $ source ~/.bashrc
<chilicuil> (si no utilizan bash como shell, editen el archivo correspondiente a la shell que usen)
<chilicuil> una vez que lo hayan hecho, las herramientas de empaquetamiento utilizaran su nombre y direccion cuando tengan que introducir un nombre de autor
<chilicuil> nja pregunta si Lernid utiliza bash como la shell por defecto
<chilicuil> dholbach responde que si, que Lernid utiliza la shell que suelas utilizar, siendo esta por defecto bash
<chilicuil> una vez que hayan completado este paso, crearemos la llave GPG
<chilicuil> si ya tienen una llave de este estilo, con esa basta, no tienen que crear otra
<chilicuil> GPG se utiliza por GNU Privacity Guard, y es una implementacion libre del estandarn OpenPGP que permite firmar y cifrar archivos, esto puede ser util de diferentes formas
<chilicuil> en nuestro caso, es importante que firmen los archivos que modifiquen para que podamos identificar aquellos lugares donde trabajaron. Cuando suban un archivo a launchpad, solo les permitira hacerlo, si puede determinar de forma exacta quien lo esta haciendo
<chilicuil> para crear una llave GPG, utilicen:
<chilicuil> $ gpg --gen-key
<chilicuil> GPG les preguntara sobre el tipo de llave que desean generar, escojan la opcion por defecto (RSA y DSA). Despues les preguntara sobre el tamaÃ±o de la clave, el tamaÃ±o por defecto (2048) esta bien, sin embargo 4096 es mas seguro
<chilicuil> una vez hayan contestado, les preguntara si desean que expire la llave en determinado momento, contesten con '0', lo que significa que su llave nunca expirara
<chilicuil> las ultimas preguntas son sobre su nombre y correo electronico. Escojan los datos que estaran usando para el desarrollo de Ubuntu, pueden agregar mas correos electronicos despues
<chilicuil> no es necesario poner un comentario. Dejenlo vacio, despues de esto, tendra que configurar una clave, escojan una que sea segura (acepta espacios en blanco)
<chilicuil> con esta informacion GPG creara su llave, esto puede tomar un poco de tiempo, ya que necesita recoger bytes aleatorios, para que los pueda tomar mas rapido, hagan que su computadora realice alguna operacion que haga uso intensivo del cpu
<chilicuil> tambien podemos dejar que la genere mientras configuramos el resto del entorno, abran otra terminal
<chilicuil> ahora crearemos la llave SSH
<chilicuil> SSH obtiene su nombre de Secure Shell/Shell segura, y es un protocolo que permite intercambiar datos de una forma segura sobre una red. Es comun usar ssh para accesar a consola remotas, y para transferir archivos de forma segura. En nuestro caso, utilizaremos la segunda caracteristica, para enviar cambios a Launchpad
<chilicuil> para crear una llave SSH, ejecuten:
<chilicuil> $ ssh-keygen -t rsa
<chilicuil> el nombre por defecto, comunmente esta bien, asi que dejenlo de esa forma (si ya tienen una clave anterior, entonces pueden seleccionar otro nombre). Se recomienda que tambien establezcan una contraseÃ±a para esta clave
<chilicuil> para esta llave*
<chilicuil> nja pregunta si la contraseÃ±a se puede cambiar despues
<chilicuil> dholbach responde que si
<chilicuil> el siguiente paso, es configurar pbuilder
<chilicuil> pbuilder les permitira compilar paquetes en su maquina, esto tiene 2 ventajas:
<chilicuil> - la compilacion se hace en un entorno limpio y minimalista, esto asegura que se pueda compilar en un sistema que no haya sido alterado
<chilicuil> - no hay necesidad de instalar todas las dependencias localmente, se instalan en su lugar temporalmente en el entorno pbuilder
<chilicuil> mm, una tercera ventaja, es que pueden tener varios entorno en una misma maquina, por ejemplo, varias versiones de Ubuntu o Debian al mismo tiempo
<chilicuil> usar pbuilder es muy facil, utilicen:
<chilicuil> $ pbuilder-dist version_de_ubuntu create
<chilicuil> para crear un nuevo entorno
<chilicuil> en el caso de Ubuntu quantal, pueden crear un nuevo entorno con:
<chilicuil> $ pbuilder-dist quantal create
<chilicuil> esto tomara algunos minutos, ya que descargara todos los paquetes necesarios para crear una instalacion "minimalista", los paquetes que se descarguen se guardaran en una cache
<chilicuil> hay alguna pregunta hasta el momento?
<chilicuil> jsjgruber-l82-p pregunta para que se necesita un archivo ~/.pbuilderrc
<chilicuil> dholbach responde que en ese archivo, se pueden configurar muchas cosas, por ejemplo, el uso de mirrors adicionales, la instalacion de paquetes por defecto, etc
<chilicuil> la pagina man de pbuilder: $ man pbuilder
<chilicuil> describe las cosas que pueden agregar, aunque en la mayoria de los casos, no se requiere
<chilicuil> exodus hace el siguiente comentario: imagina que estoy creando un paquete que tiene dependencia a otros paquetes, y esos paquetes a su vez aun no estan disponibles, por ejemplo, el paquete A, depende del paqeute B y del C. Una vez que compilo B & C, pbuilder conoce de la existencia de estos paquetes, y entonces puedo compilar A. Hay alguna configuracion especial para esta clase de problemas?
<chilicuil> dholbach responde que es una excelente pregunta, y continua diciendo que efectivamente algunas veces querras seguir determinada secuencia en la construccion de los paquetes, por ejemplo cuando quieres actualizar algunas librerias de libalgo1 a libalgo2
<chilicuil> para estos casos, se tiene que configurar pbuilder para que re utilice los paquetes que ha compilado
<chilicuil> lengau pregunta porque pbuilder requiere permisos de super usuario (root)
<chilicuil> dholbach responde que porque chroot internamente lo requiere para crear un sistema minimalista separado del sistema de donde fue invocado
<chilicuil> TheLordOfTime pregunta como hacer que pbuilder utilice los paquetes que ya han sido compilados, retomando el caso hipotetico de exodus
<chilicuil> dholbach responde que lo mejor seria ver https://wiki.ubuntu.com/PbuilderHowto y que en caso de que este desactualizado, se pregunte en #ubuntu-motu
<chilicuil> ahora, asumire que GPG ha terminado de crear la llave :)
<chilicuil> si es asi, habran obtenido un mensaje similar a este:
<chilicuil> pub   4096R/43CDE61D 2010-12-06
<chilicuil>     Key fingerprint = 5C28 0144 FB08 91C0 2CF3  37AC 6F0B F90F 43CD E61D
<chilicuil> uid                  Daniel Holbach <dh@mailempfang.de>
<chilicuil> sub   4096R/51FBE68C 2010-12-06
<chilicuil> para este caso, el ID de la llave es: 43CDE61D
<chilicuil> una vez que tengan estos datos, tendran que subir la parte publica a un servidor de llaves, de esta forma el mundo podra identificar los mensajes y archivos que les pertenezcan, en una consola:
<chilicuil> $ gpg --send-keys <ID>
<chilicuil> este comando subira la parte publica a un servidor de llaves, aun tendran que esperar a que se sincronice con el resto de servidores en el mundo (lo cual puede tardar algunos dias), para que todos puedan verificar sus archivos
<chilicuil> nja pregunta el proposito de estas llaves
<chilicuil> dholbach responde con un ejemplo, si intentas subir algun paquete a launchpad (a un repositorio personal), el sistema verificara si ese paquetes fue realmente hecho por ti
<chilicuil> la llave GPG, es un seguro que se rompe, cuando una tercera persona intenta modificar los archivos
<chilicuil> la llave SSH la utiliza Bazaar, y sirve para enviar esos datos a traves de una coneccion segura
<chilicuil> con las configuraciones que hemos hecho hasta el momento, el siguiente paso es configurar el equipo para que funcione con launchpad
<chilicuil> launchpad es la pieza central de infraestructura que usa Ubuntu
<chilicuil> no solo almacena todos los paquetes y el codigo fuente de cada uno, tambien guarda traducciones, reportes de bugs, y la informacion de las personas que trabajan en Ubuntu, asi como los equipos a los que pertenecen
<chilicuil> Launchpad tambien se utiliza para enviar parches, revisarlos e integrarlos en la distribucion
<chilicuil> la integracion, se hace generalmente a traves del patrocinio de los parches de otras personas, esto quiere decir: 'subir un paquete en nombre de alguien mas'. esta es la unica forma de colaborar con Ubuntu, si quieres enviar un parche y no tienes permisos para modificar el archivo
<chilicuil> tendran que crear una cuenta en launchpad y dar una cantidad minima de informacion. esto les permitira descargar y subir codigo fuente, enviar reportes de bugs, entre algunas otras cosas
<chilicuil> ademas de Ubuntu, launchpad ofrece sus servicios, a cualquier proyecto de software libre, https://help.launchpad.net/ contiene mas informacion
<chilicuil> si aun no tienen una cuenta, pueden obtenerla en: https://launchpad.net/+login , si tienen una pero no recuerdan su id, puede saberlo, si entran a https://launchpad.net/~ y despues se fijan en el nick que este despues del ~
<chilicuil> TheLordOfTime menciona que ha escuchado del codigo de conducta (CoC) y se pregunta si debe firmarlo para desarrollar ubuntu
<chilicuil> dholbach responde que si, y agrega que si desea formar parte de algun equipo, convertirse en un miembro oficial (y con eso, obtener derecho a votar, obtener un alias @ubuntu.com y en general ser reconocido por su trabajo) tendra que firmarlo
<chilicuil> no hay ninguna clausula oculta, no tendran que pagar por algo que no quieren
<chilicuil> el codigo de conducta basicamente dice que seran amables, unos con otros
<chilicuil> eso, generalmente es algo con lo que estarias feliz de cumplir :)
<chilicuil> man_let pregunta si hay cosas en las que puedan ayudar personas no tan inteligentes
<chilicuil> dholbach responde que existen diferentes formas de involucrarse, y que estas actividades incluyen la mayoria de intereses, habilidades o preferencias personales
<chilicuil> el proceso de registro en Launchpad, les preguntara por un nombre que pueda usar cuando tenga que mostrar un nombre. Se sugiere que usen su nombre real, de esta manera, las personas pueden empezar a conocerse de mejor manera, unas a las otras
<chilicuil> tambien, cuando se registre una nueva cuenta, se enviara un link con los pasos necesarios para verificar la cuenta, si no lo reciben, verifiquen que no este en su carpeta de spam
<chilicuil> la pagina de ayuda https://help.launchpad.net/YourAccount/NewAccount les dara mas informacion sobre el proceso, y las opciones de configuracion que pueden modificar
<chilicuil> una vez que tengan su cuenta, tendran que decirle cual es su llave GPG, para esto necesitaran el fingerprint, en una consola ejecuten:
<chilicuil> $ gpg --fingerprint <email@address.com>
<chilicuil> lo que les imprimira algo como esto:
<chilicuil> pub   4096R/43CDE61D 2010-12-06
<chilicuil>     Key fingerprint = 5C28 0144 FB08 91C0 2CF3  37AC 6F0B F90F 43CD E61D
<chilicuil> uid                  Daniel Holbach <dh@mailempfang.de>
<chilicuil> sub   4096R/51FBE68C 2010-12-06
<chilicuil> vayan a https://launchpad.net/~/+editpgpkeys y copien lo que esta despues de "Key fingerprint" en la caja de texto, para este ejemplo es:
<chilicuil> 5C28 0144 FB08 91C0 2CF3  37AC 6F0B F90F 43CD E61D
<chilicuil> una vez hecho esto, hagan click sobre 'Import Key'
<chilicuil> Launchpad utilizara el fingerprint para buscar su llave en los servidores de Ubuntu, si la encuentra les enviara un correo cifrado, una vez leido el mensaje podran hacer click en el enlace que se indique, y con eso habran confirmado su llave
<chilicuil> si su cliente de correo soporta OpenGPG, les preguntara la constraseÃ±a que configuraron cuando crearon la llave
<chilicuil> de regreso al sitio de launchpad, hagan click sobre el boton 'Confirm', y con eso habran linkeado su llave con su cuenta
<chilicuil> si tienen dudas sobre como finalizar el proceso, hechen un vistazo a https://help.launchpad.net/YourAccount/ImportingYourPGPKey
<chilicuil> cuando terminen, pueden hacer lo mismo para su llave ssh
<chilicuil> abran https://launchpad.net/~/+editsshkeys y tambien el archivo ~/.ssh/id_rsa.pub en gedit
<chilicuil> verifiquen que estan abriendo ~/.ssh/id_rsa.pub (la parte publica), y no ~/.ssh/id_rsa (la parte personal)
<chilicuil> :)
<chilicuil> copien los contenidos de ese archivo, y peguenlos en la caja de texto, luego hagan click en 'Import Public Key'
<chilicuil> si tienen dudas en algun paso de este procedimiento, revisen https://help.launchpad.net/YourAccount/CreatingAnSSHKeyPair
<chilicuil> thotp pregunta si las llaves gpg cambian cuando se reinstala el sistema operativo
<chilicuil> dholbach responde que sera mejor que haga una copia de seguridad del directorio ~/.gnupg
<chilicuil> la ultima cosa que me gustaria comentar, antes de que comencemos con la sesion de preguntas y respuestas, es bazaar, bazaar es un programa que se utiliza para almacenar los cambios en el codigo de una manera logica, para intercambiar cambios, y para fusionarlos, incluso cuando el desarrollo se esta haciendo al mismo tiempo. Se usa con el nuevo metodo de desarrollar Ubuntu de manera distribuida en la modificacion de paquetes
<chilicuil> lo primero que se tiene que hacer es configurar a bazaar con su nombre y correo, ejemplo:
<chilicuil> $ bzr whoami "Bob Dobbs <subgenius@example.com>"
<chilicuil> $ bzr launchpad-login subgenius
<chilicuil> el primer comando, tomara su nombre y correo, estos datos se utilizaran para firmar sus mensajes de modificaciones (commits). El segundo comando sirve para configurar su ID en launchpad, de esta forma, el codigo que suban desde su maquina sera asociado a su cuenta
<chilicuil> de nuevo, si no pueden recordar su ID pueden ir a https://launchpad.net/~ y ver hacia donde los redirecciona, el nombre que este despues del ~ es su ID
<chilicuil> y eso es basicamente todo lo que tienen que hacer
<chilicuil> una cosa que tal vez deseen hacer, es abrir desde Ubuntu "propiedades del software" y asegurarse que la pestaÃ±a que dice 'Sources' esta activada, una vez lo hayan hecho, podran descargar el codigo fuente de cualquier aplicacion de Ubuntu
<chilicuil> eklok pregunta de donde se puede sacar la motivacion para trabajar con esto todos los dias. Menciona que el siempre se lo propone, pero al final del dia falla
<chilicuil> dholbach responde que son las personas y la sensacion de saber que si un error es solucionado, no solo se arregla para el, sino para millones de usuarios
<chilicuil> tambien dice, que aprende terminan aprendiendo algo nuevo, lo que le parece fantastico
<chilicuil> agrega, que algunas veces puede ser dificil solucionar algun problema, pero que siempre se puede preguntar por ayuda
<chilicuil> man_let pregunta lo que pasaria si 2 personas tuvieran la misma llave publica
<chilicuil> dholbach responde que ya ha escuchado de colisiones entre llaves gpgp, pero que son muy raras, asi que no podria darle una respuesta mas especifica, le gustaria que alguien mas le enviara un link que explicara a detalle el tema
<chilicuil> envia http://www.gnupg.org/gph/en/manual.html#AEN282  y espera que eso pueda ayudar a obtener una respuesta
<chilicuil> alguna otra pregunta?
<chilicuil> continuando con la sesion, si han seguido todas las instrucciones hasta el momento
<chilicuil> deberian poder seguir el siguiente ejemplo
<chilicuil> en una consola ejecuten:
<chilicuil> $ bzr branch ubuntu:hello
<chilicuil> lo que descargara una rama del programa 'hello' en Ubuntu, junto con todas sus revisiones (historial, versiones anteriores)
<chilicuil> despues de haber hecho eso, ejecuten:
<chilicuil> cd hello
<chilicuil> bzr bd -- -S
<chilicuil> lo que compilara un paquete de codigo fuente a partir del repositorio - de esta forma se reconstruira el paquete en su forma original, y en las modificaciones que se agregan, para hacer que se compile como un paquete de Debian/Ubuntu
<chilicuil> si escriben:
<chilicuil> $ ls
<chilicuil> veran algunos archivos como:
<chilicuil> hello_2.8-2.debian.tar.gz  hello_2.8-2_source.changes
<chilicuil> hello_2.8-2.dsc            hello_2.8.orig.tar.gz
<chilicuil> si los ven, ejecuten a continuacion:
<chilicuil> $ pbuilder-dist quantal build ../hello_2.8-2.dsc
<chilicuil> lo que compilara el paquete 'hello', dentro de la instancia de pbuilder que habiamos creado con anterioridad
<chilicuil> lo primero que hara, sera descargar las dependencias, y posteriormente compilarlo
<chilicuil> el paquete resultante, estara disponible en ~/pbuilder/quantal_result/
<chilicuil> nja pregunta porque obtiene el siguiente mensaje de error: http://paste.ubuntu.com/1172150/
<chilicuil> dholbach responde que el error que obtuvo es una advertencia, y que se puede ignorar por el momento
<chilicuil> gpg: skipped "Santiago Vila <sanvila@debian.org>": secret key not available
<chilicuil> gpg: /tmp/debsign.16cckC0A/hello_2.8-2.dsc: clearsign failed: secret key not available
<chilicuil> se refiere, a que la ultima persona que trabajo en el paquete fue Santiago Vila, y que no tenemos su llave GPG, como debia de esperarse
<chilicuil> pudimos haber agregado "-us -uc" a "bzr bd -- -S" para que no mostrara ningun error
<chilicuil> pero como decia, se puede ignorar por el momento
<chilicuil> con estos pequeÃ±os pasos, 3-4 comandos, fuimos desde una rama del codigo fuente (con todas las revisiones de Ubuntu incluidas), a un paquete de codigo fuente (unicamente de la ultima revision) - esto es lo que se sube a launchpad para su compilacion), y finalmente fuimos a un paquete binario (.deb)
<chilicuil> esto solo es una probada, espero que encuentren muchas otras cosas interesantes durante las siguientes sesiones, que los ayuden a unirse al grupo de desarrolladores de Ubuntu
<chilicuil> haganme un ultimo favor, y agreguen a marcadores http://developer.ubuntu.com/packaging/html/
<chilicuil> e intenten seguir a @ubuntudev en identi.ca/twitter/facebook/gplus
<chilicuil> marcosb pregunta si -us -uc no es en realidad un comando para pbuilder, o si lo es para bzr
<chilicuil> dholbach responde que efectivamente, los parametros son para $ bzr db (y que todo lo que va detras de -- se envia a debuild/dpkg-buildpackage internamente)
<chilicuil> espero que se animen a probar el desarrollo de Ubuntu, que aprendan mucho, que ayuden a crear del mundo un mejor lugar, y que hagan un puÃ±ado de amigos en el proceso :)
<chilicuil> dholbach pregunta si hay mas preguntas, tal vez pueda resolver otro par antes de que Oliver "ogra" Grawert comience su charla sobre ARM
<chilicuil> nja pregunta sobre que es lo sigue despues de correr: "bzr bd -- -S -us -uc"
<chilicuil> dholbach responde que $ pbuilder-dist quantal build ../hello_2.8-2.dsc
<chilicuil> y agrega que tambien deberia poder encontrar las instruccines precisas en http://developer.ubuntu.com/packaging/html/
<chilicuil> y en los logs que se generen y que se publiquen en: https://wiki.ubuntu.com/UbuntuDeveloperWeek
<chilicuil> marcosb comenta: otra sesion para aprender a hacer parches para el paquete hello? :)
<chilicuil> dholbach responde que si, y agrega que hubiera sido muy complicado querer abarcar mas en 2 horas :)
<chilicuil> alucardni pregunta como puede hacer que $ bzr bd invoque a pbuilder para crear un paquete binario
<chilicuil> dholbach responde que no se puede, que tiene que correr ambos comandos
<chilicuil> pero que seria genial tener un plugin para bzr, que simplifique el proceso a un solo paso
<chilicuil> gracias a todos por estar aqui, espero que pueda saber de ustedes pronto, ogra, todo tuyo :)
<chilicuil> y con esta termina la interpretacion de la sesiÃ³n, pueden consultar los logs del resto de las interpretaciones en https://wiki.ubuntu.com/SemanaDesarrollador , saludos cordiales
<chilicuil> hola KervinRodriguez, bienvenido, dentro de algunos minutos comenzara el segundo dia de la semana del desarrollador, las platicas generales se daran en #ubuntu-classroom (es una buena idea a unirse a ese canal), en este canal, se estara haciendo una interpretacion simultania, tambien si tienes algun problema para plantear tu pregunta en ingles en #ubuntu-classroom-chat puedo ayudarte, las sesiones de ayer estan disponibles en https
<KervinRodriguez> Gracias
<meropachanguero> hola
<jossed> buenos dias
<gus-tavo> bienos dias jossed
<FTG> hola
<chilicuil> buenos dias a todos, hola gustavo_ =)
<joshua1983> buenos dias chilicuil
<gus-tavo> soy el mismo, logeado dos veces :)
<chilicuil> genial, al menos parecera que somos mas ;)
<jossed> jajjaja
<jossed> si
<chilicuil> wop, acaba de comenzar =)
<gus-tavo> Comienza la sesiÃ³n :9
<gus-tavo> Michael Terry, es quien mantiene los paquetes de Quickly
<gus-tavo> Usualmente da charlas durante la Semana del Desarrollador, como esta, quiere saber si les gustaria hablar de algo mas tecnico o no
<gus-tavo> Comienza con una rapida intro a Quikly y los planes para 12.10 y 13.04
<gus-tavo> Quicly es un forma de comenzar a desarrollar muy rÃ¡pida
<gus-tavo> Y no tener que preocuparse mucho acerca del empaquetado o como enviar la app a Ubuntu
<gus-tavo> Hay algunas opiniones sobre la elecciÃ³n (como Python, GTK+) que Ubuntu hace, para ofrecer una mejor experiencia
<gus-tavo> Hay muchas "plantillas" que Quickly ofrece para otras cosas (como HTML5 o Flash)
<gus-tavo> Por que usar Quicly o integrarse al desarrollo ?
<gus-tavo> La razÃ³n es que si queres comenzar a desarrollar sin importar mucho acerca del empaquetamiento
<mwallacesd> =)
<gus-tavo> Siempre  hay muchas cosas para hacer, y hay planeado mucho trabajo
<gus-tavo> en 12.04 hay tres plantillas, la nomal Python+GTK, una interfaz de linea de comandos y otra de juegos flash
<gus-tavo> Tambien estan HTML5, Qt, Qt Quick, y una Unity Lens mantenida por la comunidad
<chilicuil> bienvenido mwallacesd , en este canal se hace la interpretacion en tiempo real de #ubuntu-classroom, si tienes alguna pregunta para la sesion, y no estas seguro de como hacerlo, tambien podemos ayudarte, si no tienes problemas con Ingles, igual podemos darnos apoyo uno al otro, todos aqui estamos de una forma u otra interesados en el desarrollo de Ubuntu
<gus-tavo> eklok pregunta: se puede trabajar con Quickly via teminal e interfaz grÃ¡fica?
<gus-tavo> Ahora, estÃ¡ diseÃ±ado para ser usado solamente via terminal
<gus-tavo> Michael Hall trabaja en un interfaz grÃ¡fika
<gus-tavo>  https://launchpad.net/quickly-gtk
<gus-tavo> skizobass pregunta: puede usar Eclipse, PyDev para escribir una App Python con quickly y luego publicarla en el Software Center?
<gus-tavo> Si y no
<gus-tavo> No tenemos una integraciÃ³n con Eclipse o PyDev
<gus-tavo> Pero puedes escribir una app y pegarte dentro de un proyecto Quickly con un pequeÃ±a suma de trabajo
<gus-tavo> Lo que da Quicly es un proyecto esqueleto
<jossed> que nos ofrece Quicly en desarrollo
<jossed> que nos ofrece Quickly en desarrollo
<gus-tavo> Y si tiras algo del codigo,  y te adhieres al tuyo, tenes las mayorias de las ventajas que ofrece Quicky
<joshua1983> pregunta: esa estructura creada por Quickly es el estÃ¡ndar para desarrollar aplicaciones en ubuntu?
<gus-tavo> ben72 pregunta: in 12.04 quickly es el paquete a obtener?
<gus-tavo> sSi
<jossed> se conecta contoda las base de datos o hay q utilizar librerias_
<gus-tavo> FlowRiser pregunta: Como es el actual flujo de trabajo de Quickly?
<gus-tavo> Digamos que comienzas un proyecto
<gus-tavo> Abres la Terminal
<gus-tavo> corres "quickly create ubuntu-application  test-project"
<jossed> pero es orientada a la web o son para aplicaciones de escritorio
<gus-tavo> La app Ubuntu es elegida en ese paso y elijes una plantilla
<gus-tavo> En nuestro caso, queremos la default-ubuntu-recommendation, que es Python+GTK
<chilicuil> jossed: acabo de hacer tu pregunta sobre base de datos en #ubuntu-classroom-chat
<jossed> ok
<gus-tavo> Ahora, crea el esqueleto y y lo lanza
<gus-tavo> Cierra este proyecto, "cd test-project" y estÃ¡s sobre el nuevo proyecto
<gus-tavo> Ahora puedes editar el codigo con "quickly edit" o empaquetarlo con "quickly package". Vamos a esos comandos mas tarde
<gus-tavo> skizobass pregunta: Puedo escribir y organizar el codigo (clases, paquetes, et,) como en Eclipse?
<chilicuil> jossed: acabo de hacer tu segunda pregunta sobre aplicaciones web vs aplicaciones de escritorio =)
<gus-tavo> No estoy seguro como hace Eclipse, espera.
<jossed> ok >(
<jossed> si me responde me madas las respuesta a mi correo que tengo q salir ok es jsdrnt@gmail.com gracias
<gus-tavo> El esqueleto por defecto te da un directorio/modulo-Python para tu codigo
<chilicuil> jossed: las respuestas estaran accesibles como parte del log, te lo mandare todo junto, que te diviertas
<gus-tavo> y tambien un modulo Python que tiene su propio codigo boilerplate
<gus-tavo> Colocas todo tu codigo en tu modulo y Quickly lo envuelve
<jossed> ok
<gus-tavo> Si quieres importar codigo existente en Quickly, tienes que reemplazar un modulo con tu codigo
<gus-tavo> Pero asi como van clases, Python y Quickly recomiendan una-clase-por-archivo
<gus-tavo> puedes hacer como quieras. no es estricto, como Java
<gus-tavo> nja pregunta: estaras cubriendo algo de Python en esta sesion?
<gus-tavo> No lo tengo planeado, hay mejores recursos para eso
<SergioMeneses> gus-tavo, puse un tuto bastante bueno de python en el canal de chat
<gus-tavo> No hay mas preguntasm comencemos a usar Quickly
 * SergioMeneses is still working
<gus-tavo> Antes que lo olvide, Quickly tiene un tutorial embebido
<SergioMeneses> gus-tavo, el fin de semana sera q miro lo de la semana xD
<gus-tavo> Si no me quieren escuchar repetido
<gus-tavo> corre "quickly tutorial" en tu directorio
<SergioMeneses> :O
<SergioMeneses> exelente aporte
<gus-tavo> FlowRiser pregunta: Veo que la mayoria de los lenguajes que usa no requiere compilar el codigo, hay alguna chance de usar Cpp y una plantilla GTK?
<gus-tavo> Es una posibilidad
<gus-tavo> pero no lo hemos hecho aun
<chilicuil> oh si, creo que muchos de nosotros tendremos de sobra con eso: $ quickly tutorial
<gus-tavo> El sistema de plantillas le permite a alguien eschibir algo como una plantilla fÃ¡cilmente
<gus-tavo> Tenemos un progreso con la plantill Vala, que esta compilada
<gus-tavo> Pero en general, usuarios nuevos prefieren lenguajes no compilados, como HTML o Python
<mwallacesd> SergioMeneses, nos puede pasar el tuto aqui?
<gus-tavo> peaceisid pregunta; para usar quickly, debo saber programar en python?
<gus-tavo> Si, al menos para la plantilla recomendada por defecto
<gus-tavo> pero, nuevamente, no va a ser necesario en el futuro
<gus-tavo> estamos hora
<SergioMeneses> gus-tavo, mwallacesd http://mundogeek.net/tutorial-python/
<mwallacesd> Gracias SergioMeneses
<gus-tavo> coalitians pregunta: Quickly esta en python?
<gus-tavo> Si, el proyecto esqueleto y Quickly en si
<gus-tavo> BebopSteve pregunta: con "quickly edit", que hay de especial?  o puedes usar tu editor preferido?
<gus-tavo> Puedes usar el editor de tu elecciÃ³n, puedes asignar EDITOR o QUICKLY_EDITOR variables de entorno para cambiarlo
<gus-tavo> NickE pregunta: Quickly tiene soporte para Python 3?
<gus-tavo> No aÃºn
<gus-tavo> Queremos soportarlo, pero eso no pasara hasta 13.04
<gus-tavo> chilicuil pregunta: quickly soporta el acceso a bases de datos? o necesito usar librerias?
<gus-tavo> Para eso, no se necesita nada especial, Quickly las soporta
<gus-tavo> Solo impota el modulo apropiado Python
<gus-tavo> No limita tu eleccion en como escribes tus app. Es solo un envoltorio, para proveer integracion dentro de Ubuntu
<gus-tavo> Otro comando util para cambiar tus app, es "quickly design"
<gus-tavo> que traera el editor Glade, una interfaz grÃ¡fica
<gus-tavo> Como usar Glade es enteramente otra charla, trata de ser un constructor interfaces con apunta y clika
<gus-tavo> Te ayuda a entender GTK un poco cuando lo usas
<gus-tavo> Pero la idea bÃ¡sica es que puede crear nuevas widgets un el panel a la izquierda, colocrlos en el medio y ajustar las propiedades del widget en la zona inferior derecha
<gus-tavo> chilicuil pregunta: Quickly esta planeado para producir app de escritorio o app web?
<gus-tavo> Ahora, app de escritorio
<gus-tavo> Tenemos una plantilla HTML5 en el conjunto de la comunidad
<gus-tavo> Pero aun esta diseÃ±ado para el escritorio (corre Python por debajo)
<gus-tavo> green7 pregunt: Necesitamos conocer GTK para usar Quickly?
<gus-tavo> Si, para la plantilla estÃ¡ndar
<gus-tavo> como para Glade
<gus-tavo> nja pregunta: Donde recomendarias aprender Python?
<gus-tavo> Dive into Python es muy bueno
<gus-tavo> http://www.diveintopython.net/
<gus-tavo> Digamos que te sientes a gusto con Glade, y has hecho algunos cambios (y podemos volver a ellos)
<gus-tavo> Si quieres ver como se ve tu proyecto, corre "quickly run"
<gus-tavo> lo que cargara todos los archivos editados y te mostrara el estado actual del proyecto
<gus-tavo> un lindo truco Quickly hace es que cuando agregas un eidget, respondes frecuentemente a eventos de usuario que hay en el
<gus-tavo> como clicks
<gus-tavo> Quickly lo hace facil
<gus-tavo> Si agregas un widget llamado boton1
<gus-tavo> puedes escribir un mÃ©todo en la clase ventana llamada on_boton1_clicked (self, widget, data=None)
<gus-tavo> y es todo lo que necesitas alli
<hephisto> buen dia alguno conoce algun tutorial de AS3
<gus-tavo> Quicky lo notificara y ancla el widget a tu mÃ©todo
<gus-tavo> Necesitas usar el formato on_WIDGETNAME_SIGNALNAME
<gus-tavo> y la seÃ±al cambiara de acuardo al tipo de seÃ±al
<gus-tavo> Vean la documentacion GTK para detalles en una seÃ±al dada
<gus-tavo> green7 pregunta: hay una diferencia entre packaging y quickly run?
<gus-tavo> si
<chilicuil> hephisto: hola, este canal es sobre las sesiones de la semana del desarrollador, https://wiki.ubuntu.com/SemanaDesarrollador, ahora mismo estamos hablando de quickly, una herramienta para crear aplicaciones en python en Ubuntu, para soporte general, usa #ubuntu-es =)
<hephisto> si estaba mirando eso gracias  esta interesante  y me interesa
<gus-tavo> cuando haces quickly run hace solo quick spot-check
<gus-tavo> corre todos los archivos desde done estan en el directorio de tu proyecto
<gus-tavo> pero quickly package crea archivo paquete Debian
<gus-tavo> que puedes instalar en tu sistema si eres root
<gus-tavo> Digamos que cuando corremos 'quickly package' en nuesto test-project
<gus-tavo> nos dara un archivo como ../test-project_0.1_all.deb
<gus-tavo> si corremos 'sudo dpkg -i ../test-project_0.1_all.deb' lo instalamos
<gus-tavo> Y lo verÃ¡s en el Dash
<gus-tavo> antes de empaquetar seriamente tu app, lo mejor es llenar alguna informacion en el archivo 'setup.py'
<gus-tavo> como pagina web y autor
<gus-tavo> al correr 'quickly license' para especificar la licencia de tu programa
<gus-tavo> porque toda esa informacion es importante antes de comenzar la distribucion
<gus-tavo> dejenme hablar algo acerca  del empaquetamiento
<gus-tavo> digamos que pensamos que esta app por defecto es genial
<gus-tavo> y la queremos distribuir a amigos
<gus-tavo> primero, debemos correrla localmente con 'quickly package'
<gus-tavo> asegurarnos que instala bien
<gus-tavo> pero si queremos distribuirla a una comunidad amplia, deberias asignarle un PPA
<chilicuil> gus-tavo: acaba de comenzar la segunda sesion, podrias pausar la interpretacion?, si quieres puedo terminar lo que hizo falta
<gus-tavo> ok chilicuil,
<gus-tavo> gracias
<chilicuil> gracias gus-tavo =), van un poco rapido estos chicos
<chilicuil> vale, para la segunda sesion, tendremos a coolbhavi que nos hablara del equipo consultor de desarrolladores de Ubuntu, o el 'developer advisory team' en ingles
<chilicuil> == Por que estamos aqui? ==
<chilicuil> el equipo de consultores, es un conjunto de personas que intentan hacer el desarrollo de ubuntu un poco mas social, con la esperanza de hacer que cada vez mas personas se involucren
<SergioMeneses> chilicuil, gus-tavo no se desordena mucho el log?
<chilicuil> esto significa, que nos enfocamos en las personas que recien comienzan, y les ayudamos a introducirse en el mundo de desarrollo de Ubuntu
<chilicuil> SergioMeneses: lo pondre todo junto, en un pastebin ;)
<SergioMeneses> chilicuil, aaaa ok jeje good one!
<chilicuil> == El proceso en general ==
<chilicuil> tenemos 4 formas lograr esto
<chilicuil> primero, contactamos a las personas interesadas por correo (hacemos esto dependiendo de la cantidad de contribuciones que hayan hecho, si vemos que son constantes, nos comunicamos con ellos)
<chilicuil> NOTA: hay probabilidades de que ya hayas recibido este correo si sueles enviar parches
<chilicuil> despues de esto, organizamos una entrevista con los candidatos, y les preguntas sobre su experiencia con el proceso
<chilicuil> en esa misma entrevista, les preguntamos cuales son sus objetivos dentro de la comunidad
<chilicuil> cuando hemos terminado con el segundo punto, les hacemos sugerncias (no confundir con el proceso de mentores, uno a uno), y seguimos pendientes de sus contribuciones
<chilicuil> por ultimo, si sentimos que un candidato ya esta listo, le ayudamos a enviar su aplicacion para entrevistarse con el DBM (el council que aprueba nuevos desarrolladores oficiales)
<chilicuil> nja: pregunta sobre los privilegios que se ganan cuando se es parte del DMB
<chilicuil> coolbhavi responde que no podria contestar esa pregunta porque el no es miembro de ese council
<chilicuil> NickE pregunta si el objetivo entonces el objetivo del equipo es convertir  desarrolladores casuales, en oficiales?
<chilicuil> coolbhavi responde que si, de eso se trata
<chilicuil> BebopSteve pregunta si entre sus planes esta crear un sitio web con informacion que pueda ayudar a los nuevos desarrolladores
<chilicuil> coolbhavi responde que si, y que lo respondera de mejor forma conforme avance la sesion
<chilicuil> siguiendo con la charla, seguramente algunos de ustedes se estan preguntando, ok, estoy interesado, donde comienzo?
<chilicuil> a lo que yo responderia, si te interesa convertirte en un desarrollador de Ubuntu, nuestro equipo esta aqui para lograrlo
<chilicuil> == eso quiere decir que me asignaran un mentor? ==
<chilicuil> desafortunadamente la respuesta a esa pregunta es "no". Solo damos sugerencias (como ligas de los equipos, o de introduccion al desarrollo), sin embargo si en algun momento tienen algun problema, pueden preguntar en #ubuntu-motu, el canal de los desarrolladores MOTU o preguntar en la lista de correo ubuntu-motu@lists.ubuntu.com
<chilicuil> FlowRiser pregunta que es lo que pasa, si no es tan buen programador?
<chilicuil> coolbhavi responde que no tiene que preocuparse mucho por eso, ya que no todas las personas comienzan siendo excelentes programadores
<chilicuil> == Entonces, como pueden ayudarme para que me sea mas facil involucrarme en el desarrollo de Ubuntu ? ==
<chilicuil> empezar es relativamente facil, pueden empezar hechandole un vistazo a http://developer.ubuntu.com/packaging/html/ , y si desean tener algo en que trabajar, pueden consultar la iniciativa de correcion de bugs disponible en https://wiki.ubuntu.com/UbuntuDevelopment/BugFixingInitiative
<chilicuil> NickE pregunta sobre el significado de la palabra MOTU
<chilicuil> coolbhavi responde que son las iniciales del equipo Master Of The Universe (DueÃ±os del universo, en referencia del repositorio -universe)
<chilicuil> y del -multiverse
<chilicuil> skizobass pregunta si hace falta estar certificado en alguna tecnologia para ser parte de Ubuntu
<chilicuil> coolbhavi responde que no, solo se necesita querer ser parte =)
<chilicuil> == Que clase de personas estamos buscando? ==
<chilicuil> buscamos desarrolladores (que apenas se hayan integrado, o que ya tengan tiempo de haberlo hecho) y que no han aplicado para obtener derechos para modificar el archivo (los repositorios), tambien nos interesa saber de aquellas personas que despues de haber colaborado han dejado de hacerlo, nos interesa saber cuales han sido las causas, y si podemos ayudar
<chilicuil> == He contribuido por X meses, puedo aplicar para convertirme en desarrollador de Ubuntu?, me pueden ayudar? ==
<chilicuil> definitivamente :) (aunque como regla, y segun el DMB, el tiempo minimo debe ser mayor a 6 meses de contribuciones continuas). Tambien es buena idea que se pongan en contacto con el desarrollador que ha estado subiendo los cambios por ustedes (sponsor) y que le piden que agregue comentarios en su wiki de aplicacion
<chilicuil> BebopSteve pregunta, cual es la diferencia entre poder subir, y contribuir?, no se se supone que si contribuyes, es por que puedes subir cosas?
<chilicuil> coolbhavi responde que hasta que tengas permisos para modificar el archivo por ti mismo, los cambios que desees enviar tienen que pasar por otro desarrollador previamente aprobado
<chilicuil> FlowRiser comenta que le gustaria que le aclaran el tema de sponsor (patrocinado), no se supone que hacemos esto gratis?
<chilicuil> coolbhavi responde que el proceso en el que otro desarrollador sube cambios por uno que aun no puede hacerlo se llama patrocinio 'sponsoring', y al que lo hace patrocinador 'sponsor'
<chilicuil> skizobass pregunta si es necesario ser programador de python, o cuales son otras formas contribuir?
<chilicuil> coolbhavi responde que no es necesario, pero que especialmente en Ubuntu no es una mala idea
<chilicuil> FlowRiser pregunta si existe una lista con diferentes actividades organizado por nivel de dificultad (aplicaciones, kernel, modulos, etc)
<chilicuil> coolbhavi responde que si, y que si desea verlas, puede leer las paginas de los diferentes equipos (desktop, kernel, etc), o revisar la wiki del equipo MOTU
<chilicuil> NickE comenta, entonces si envias suficientes contribuciones  ganas la confianza de tu patrocinador hasta que tu mismo te conviertes en uno?
<chilicuil> coolbhavi responde que asi es exactamente como funciona, despues de obtener permisos para modificar el archivo, te abras convertido en desarrollador de Ubuntu :)
<chilicuil> TheLordOfTime pregunta si todos los desarrolladores oficiales automaticamente se convierten en patrocinadores (sponsors)
<chilicuil> coolbhavi responde que si, como desarrallores oficiales puede subir sus cambios, o los de otras personas
<chilicuil> == Bueno esto suena interesante, como puedo ayudar a mejorar la iniciativa? ==
<chilicuil> si te ha gustado la idea, y deseas ayudarnos, nos gustaria escuchar tus comentarios
<chilicuil> por favor, busquen el reporte de comentarios del ultimo ciclo: http://fridge.ubuntu.com/2012/04/17/developer-advisory-team-report-12-04-feedback-from-new-contributors/
<chilicuil> == Perfecto!, quienes son los actuales miembros del equipo, y como puedo ponerme en contacto con ellos? ==
<chilicuil> todos los miembros pueden verse en toda su gloria aqui: https://launchpad.net/~ubuntu-developer-advisory-team/+mugshots
<chilicuil> para cualquier comentario/queja/sugerencia sientanse libres de ponerse en contacto con cualquiera de ellos :)
<chilicuil> creo que es todo, como aun queda algo de tiempo pueden hacerme mas preguntas =)
<chilicuil> NickE pregunta si el trabajo dentro del equipo se divide por areas de especializacion, o si todos pueden ayudar con cualquier cosa?
<chilicuil> coolbhavi responde que aunque algunos de los miembros tienen amplios conocimientos, en su conjunto, pueden ayudar a las personas con cualquier cosa que este relacionado con el desarrollo de Ubuntu
<chilicuil> skizobass pregunta donde puede enviar sus programas si estan hechos en python
<chilicuil> coolbhavi: responde que el 'Application review board' es el encargado de revisar ese tipo de cosas y le sugiere que lo envie con ellos
<chilicuil> marcosb pregunta si la junta de revision de aplicaciones 'the app review board' se encarga de aprobar todos los programas, o solo para los programas comerciales
<chilicuil> coolbhavi responde que el ARB es para las aplicaciones libres, otro equipo se encarga de evaluar los programas comerciales
<chilicuil> aqui, hago una pausa, alguien desea interpretar la siguiente sesion, sobre corregir bugs en ubuntu que dara Stefano (tumbleweed])?
<chilicuil> stadtfeld pregunta si solo se le brinda ayuda a las personas que han enviado parches, o si es a todos por igual
<chilicuil> coolbhavi responde que a todos
<chilicuil> alucardni pregunta si puede aplicar para obtener derechos en los repositorios si ha estado enviando parches a Debian
<chilicuil> coolbhavi responde que si, pero que depende del impacto que tus modificaciones hayan tenido en ubuntu
<chilicuil> y se puede aplicar para obtener una membresia PPU (per package/por paquete)
<chilicuil> pueden encontrarlo en facebook a traves de la cuenta facebook.com/bshankar o en google+
<chilicuil> con eso termina la sesion de coolbhavi
<chilicuil> ok, si no hay inconvenientes entonces comenzare la interpretacion de la tercera sesion, durante ella, Stefano Rivera nos hara un breve resumen de como trabajar con algunos bugs de Ubuntu, la platica se ha estructurada para ser facil de seguir
<chilicuil> comenzare ahora
<chilicuil> veo que tenemos muchas personas en la sala, pueden regalarma en 'hi' en #ubuntu-classroom-chat?
<chilicuil> oh si, si se tienen algunos problemas durante la sesion, no olviden entrar a #ubuntu-motu una vez haya finalizado
<chilicuil> bien, mi nombre es  Stefano Rivera y soy desarrollador de Debian y Ubuntu
<chilicuil> vivo en sudafrica
<chilicuil> y justo ahora, estoy en el apartamento de un amigo, con mi laptop en la esquina y una conexion 3G, asi que espero no desaparezca repentinamente
<chilicuil> estoy aqui, para decirles como trabajar con upstream
<chilicuil> que quiere decir esta palabra?
<chilicuil> bueno, Ubuntu esta hecho de ~20 000 paquetes de codigo fuente (los que en su conjunto crean mas ~40 000 paquetes binarios - .debs)
<chilicuil> como desarrolladores de Ubuntu, escribimos una parte muy pequeÃ±a de todos ellos
<chilicuil> todo lo demas, viene de otros proyectos
<chilicuil> y estos proyectos son los que llamamos upstream
<chilicuil> cada proyecto libera una nueva version de su programa, cuando pasa eso, lo empaquetamos, y despues de algunos cambios hacemos que se integre con Ubuntu, eso es lo que entregamos a nuestros usuarios
<chilicuil> tambien nos encargamos de filtar muchos de los reportes que originalmente deberian ir para esos proyectos
<chilicuil> y solo reenviamos los validos
<chilicuil> suena divertido, no? =)
<chilicuil> jeje, bueno, he mentido un poco en eso
<chilicuil> espero que todos sepan para este momento, que Ubuntu se deriva de Debian
<chilicuil> pues bien, la mayoria de los problemas que encontramos en Ubuntu, tambien afectan a debian
<chilicuil> asi que debian es un proyecto upstream especialmente importante para Ubuntu
<chilicuil> enviamos muchos cambios para alla
<chilicuil> https://wiki.ubuntu.com/Debian/ForUbuntuDevelopers
<chilicuil> un poco mas adelante dare mas detalles sobre como hacer eso
<chilicuil> por ahora, hablare de los proyectos upstream en general
<chilicuil> generalmente es buena idea tratar de arreglar los bugs, tan cercanos del proyecto original como sea posible
<chilicuil> esto se hace, para no duplicar el trabajo, y compartir las mejoras a la mayor cantidad de personas posibles
<chilicuil> marcosb pregunto si se le puede explicar lo que significa la nomenclatura de los paquetes, por ejemplo en hello_1.1-1ubuntu1.deb o en hello_1.1-1upstream1.deb
<chilicuil> tumbleweed responde que si
<chilicuil> todos los paquetes .deb tienen nombres del tipo nombrepaquete_version_arquitectura.deb
<chilicuil> la version es especialmente importante para saber cual es el paquete anterior, y cual el siguiente
<chilicuil> los paquetes que se hacen en Debian, y en sus derivados tienen otra version que luce como esto 1.0.0
<chilicuil> no hay ningun '-1' al final
<chilicuil> si un desarrollador de debian empaqueta la version 1.0.0 de un programa, el paquete tendra la version 1.0.0-1
<chilicuil> -1 significa que es el primer paquete de su clase en Debian
<chilicuil> si alguien hace un cambio en ese paquete en Ubuntu, la version sera 1.0.0-1ubuntu1
<chilicuil> si en Ubuntu se empaqueta la version 1.0.1 del programa antes que en debian, se llama 1.0.1-0ubuntu1
<chilicuil> etc
<chilicuil> por supuesto, hay algunas personas que no siguen estas reglas, sin embargo en la mayoria de los casos aplica
<chilicuil> en fin, estabamos hablando de porque es buena idea colaborar con los proyectos upstream
<chilicuil> y esta es la razon, si enviamos un parche a los desarrolladores originales, y ellos liberan una nueva version con nuestra mejora, se benefician todos
<chilicuil> los usuarios de otras distribuciones (no solo de ubuntu), los de otras plataformas com wygwin o macports, o las personas que lo descargan desde el sitio oficial
<chilicuil> ademas de eso, los programadores del proyecto original, pueden darte buenas sugerencias para mejorar tus programas/parches
<chilicuil> nadie su codigo, como ellos
<chilicuil> espero que ya tengamos claro porque es buena idea, trabajar con los proyectos upstream
<chilicuil> como pueden encontrar un bug para comenzar a trabajar?
<chilicuil> bueno, hemos puesto una buena cantidad en https://wiki.ubuntu.com/UbuntuDevelopment/BugFixingInitiative
<chilicuil> los primeros son unicamente para Ubuntu, estos no requeriran ningun esfuerzo extra
<chilicuil> asi que es una buena idea comenzar por ellos
<chilicuil> despues de esos, estan otros ejemplos que no solo afectan Ubuntu, y los parches que se hagan para ellos tendran que reenviarse a los proyectos originales
<chilicuil> (que es de lo que realmente hablaremos hoy)
<chilicuil> otra buena estrategia para comenzar a involucrarte es tomar algun paquete que te interese, y que no este bien mantenido
<chilicuil> algun proyecto con algunos bugs abiertos de los cuales nadie se haya hecho cargo
<chilicuil> puede ser que incluso algunos de ellos, solo se corrigan en nuestra distro, algunos desarrolladores de Ubuntu pueden ser flojos :)
<chilicuil> existen *muchos* programas como estos en los repositorios
<chilicuil> en Debian, cada paquete tienen un mantenedor explicito asociado que debe velar por el programa
<chilicuil> pero en Ubuntu, muchos de esos paquetes no son vigilados por nadie
<chilicuil> hay una lista de algunos de ellos en http://qa.ubuntuwire.org/neglected/
<chilicuil> AmberJ_ pregunta, en un comentario anterior alguien dijo que si se modifica un paquete en Ubuntu, la version seria 1.0.0-1ubuntu1, que pasa si nadie lo modifica?
<chilicuil> tumbleweed responde que entonces se mantiene la misma version que en Debian
<chilicuil> como he dicho anteriormente, la mayoria de los paquetes en los repositorios son versiones sin modificar de Debian
<chilicuil> en Ubuntu existe sin embargo, una forma ligeramente diferente de compilar algunos programas
<chilicuil> pero a la mayoria de los programas, no se les hacen modificaciones
<chilicuil> siguiendo con la sesion, como soluciono el bug?
<chilicuil> bueno, esa una pregunta un tanto dificil de contestar, y depende en gran parte de la clase de bug con el que estemos tratando
<chilicuil> todo lo que puedo decir, es como meter sus manos en el codigo fuente, y que hacer una vez que este arreglado
<chilicuil> dholbach cubrio la primera parte de ese proceso ayer
<chilicuil> de todas formas, dejenmen recordarselo
<chilicuil> se debe instalar el paquete packaging-dev
<chilicuil> eso les dara muchas herramientas necesarias
<chilicuil> deben descargar el codigo fuente de la aplicacion con el problema, esto lo pueden hacer con: $ pull-lp-source PAQUETE
<chilicuil> marcosb pregunta si aprendera a hacer parches en esta sesion
<chilicuil> tumbleweed responde que si, y agrega que eso suena como algo interesante
<chilicuil> siguiendo con la charla.., hay 2 formas de en Ubuntu de descargar el codigo fuente, la forma tradicional, usando las herramientas de Debian, y con bzr
<chilicuil> durante esta sesion les hablare principalmente de la forma clasica, porque aun sigue siendo mas popular, y encuentro que es mas rapido de esa forma
<chilicuil> asi que, si han descargado y extraido el codigo fuente con pull-lp-source
<chilicuil> podrian agregar su solucion facilmente
<chilicuil> una vez llegados a este punto, podrian tener que hacer varias cosas, gracias a las diferentes formas en las que se empaquetan los programas
<chilicuil> podrian correr "what-patch" para que clase de parches usa el paquete
<chilicuil> pongamos como ejemplo, que se esta usando quilt, este es el formato mas comun actualmente, espero que dentro de poco sea el unico que quede
<chilicuil> si es asi, podran correr: $ quilt new NOMBREDEMIPARCHE
<chilicuil> despues: $ quilt edit ARCHIVO
<chilicuil> y para finalizar $ quilt refresh, lo que creara el parche
<chilicuil> pueden encontrar el resultado en debian/patches
<chilicuil> la mayoria de las veces, cuando trabajen con paquetes en debian, esta es la forma en la que se generaran
<chilicuil> este parche es el que puedes enviar a upstream
<chilicuil> como puedes encontrarlos?
<chilicuil> bueno, empecemos por Debian
<chilicuil> pueden ver informacion detallada sobre cada programa en http://packages.qa.debian.org/
<chilicuil> http://packages.qa.debian.org/$PAQUETE
<chilicuil> asi que por ejemplo, para el paquete 'hello', pueden ir a http://packages.qa.debian.org/hello
<chilicuil> ojo, que estoy hablando de paquetes de codigo, y no de paquetes binarios
<chilicuil> como desarrolladores, la mayor parte del tiempo estaremos trabajando con paquetes de codigo
<chilicuil> los binarios (.deb) solo se crean cuando el programa este listo
<chilicuil> en packages.qa.debian.org (tambien conocida como el PTS) encontraran una ista de bugs
<chilicuil> en la esquina superior derecha pueden ver los bugs de cada paquete, en la izquierda quien esl mantenedor
<chilicuil> y en el centro el historial de versiones
<chilicuil> bien, revisando en el historial, encontramos que solo tiene 1
<chilicuil> que pasa si encontramos el bug que estabamos buscando, bueno, pues vamos a el y hecharemos un vistazo para ver cual es el progreso que se ha hecho
<chilicuil> tal vez hasta haya un parche, o tal vez se haya enviado el parche al proyecto original
<chilicuil> podemos ver que el bug aqui (bugs.debian.org/621716) ha sido reenviado al proyecto original
<chilicuil> desafortunadamente no tenemos un link porque ha sido enviado a un correo
<chilicuil> algunos proyectos no tienen un sistema de control de bugs (bugtracker) y por lo tanto lo unico que modemos decir es: "se lo enviamos al correo"
<chilicuil> marcosb pregunta si existe otro mecanismo para crear parches ademas de quilt
<chilicuil> tumbleweed responde que lamentablmente si, existen otros dos, dpatch y cdbs-simple-patch (aunque ambos se usan cada vez menos)
<chilicuil> y algunos paquetes no tienen ningun sistema para manejar los parches
<chilicuil> eso significa que todos los cambios que se han hecho, tanto en Ubuntu como en Debian estan mezclados en un solo y enorme diff
<chilicuil> esta forma es la mas facil para modificar paquetes, pero es dificil entender los cambios que se estan haciendo
<chilicuil> calmi pregunto si existe un sistema para evitar bugs duplicados
<chilicuil> tumbleweed responde que si, que antes de enviar un nuevo reporte busques si ya existe y agrega que launchpad es realmente bueno haciendo esto
<chilicuil> una vez que introduces un titulo, hace una busqueda de bugs similares
<chilicuil> en debian, la herramienta estandard, $ reportbug, tambien muestra una lista de bugs parecidos antes de poder enviar el tuyo
<chilicuil> marcosb pregunta si se le puede indicar como crear paquetes con dpatch y dbs-simple-patch?
<chilicuil> tumbleweed dice que desafortunadamente no los cubrira por el momento, y que los paquetes que los utilizan son tan raros que no deberia preocuparse por ellos
<chilicuil> hablemos unicamente de los paquetes que no tienen ningun sistema de parches
<chilicuil> la forma mas simple de obtener un parche de estos es hacer tus cambios, agregar una nueva entrada en el archivo /debian/changelog (con dch) y compilar el paquete
<chilicuil> despues se puede usar "debdiff" para crear el parche, por ejemplo $ debdiff foobar_0.1-1.dsc foobar_0.1-1ubuntu1.dsc
<chilicuil> en fin, regresemos a lo estaba diciendo antes
<chilicuil> si ya buscamos en el tracker de debian, y no encontramos el bug en el que estamos trabajando
<chilicuil> nos podemos preguntar, el bug en el que trabajamos se genero en Debian?
<chilicuil> si es asi, sera mejor que hagamos el reporte nosotros mismos
<chilicuil> algunas veces, si el problema esta en upstream, podemos trabajar en una solucion temporal para Debian/Ubuntu mientras los cambios se aplican en el proyecto original
<chilicuil> o si es un problema muy serio, podemos crear un parche para la version estable de las versiones en Ubuntu/Debian
<chilicuil> si no encontramos razones para reenviarlos a Debian, podemos solo reenviarlos a upstream (en caso de que aplique)
<chilicuil> podemos encontrar sus paginas de varias formas, la mayoria de los proyectos tienen una pagina oficial, podemos buscar esa pagina en el archivo /debian/control
<chilicuil> tambien la podemos encontrar en el PTS, para el paquete hello, http://packages.qa.debian.org/hello es http://www.gnu.org/software/hello/
<chilicuil> a su vez, esa pagina nos dice que el bugtracker se encuentra en savannah http://savannah.gnu.org/projects/hello/
<chilicuil> asi que eventualmente llegaremos al bugtracker de upstream
<chilicuil> ahora podemos crear un reporte en su sistema (claro, primero debemos fijarnos si no ha sido reportado o solucionado con anterioridad)
<chilicuil> y anexarles el parche que hemos creado, \o/, si es asi lo habremos logrado =)
<chilicuil> muchos proyectos no estan interesados en las versiones de sus programas que estan en las distribuciones de linux, pues las pueden considerar demasiado antiguas
<chilicuil> asi que lo mejor que pueden hacer es ver, si la version mas nueva de ese programa, aun tiene ese problema
<chilicuil> como investigar eso, dependera de cada proyecto
<chilicuil> lo que yo suelo hacer, es intentar reproducir el error en mi computadora
<chilicuil> de esta manera puedeo saber, si se ha arreglado o no
<chilicuil> y me puedo poner en el mismo lugar que la persona que lo reporto en primer lugar
<chilicuil> tambien ayuda a redactar un buen reporte a upstream
<chilicuil> jsjgruber-x-p_ pregunto que es lo que pasa si los desarrolladores de upstream no te contestan
<chilicuil> tumbleweed responde que se puede solucionar en Debian/Ubuntu
<chilicuil> ahora hablare un poco del sistema de reportes de bugs, el BTS que esta en bugs.debian.org
<chilicuil> cuando lo usen, hay links en cada paquete que los llevara a diferentes secciones, bugs.debian.org/PAQUETE, bugs.debian.org/NUMEROBUG
<chilicuil> notaran que no hay forma de agregar comentario, o llenar otros bugs
<chilicuil> esto es porque todo el sistema esta controlado via email
<chilicuil> tal vez crean que eso es arcaico, pero hasta el momento ha funcionado bien
<chilicuil> ben72 pregunto que pasa cuando el parche es muy pequeÃ±o, vale la pena agregarlo como comentario?
<chilicuil> tumbleweed responde que si, y que de hecho asi es como muchas veces se envian los parches
<chilicuil> algunas veces el problema es tan facil de solucionar que podria bastar con describir el proceso
<chilicuil> por el contrario, si es muy grande, tal vez prefieran dividirlo en varios parches
<chilicuil> marcosb pregunta si despues de agregar la entrada en changelog y el parche con quilt, se debe generar el paquete con debuild -us -uc y ejecutar despues debdiff?
<chilicuil> tumbleweed: responde que primero debe ejecutarse $ debuild -uc -us -S
<chilicuil> y luego $ debdiff
<chilicuil> agrega que la -S provoca que unicamente se construya el paquete del codigo fuente, y no el binario
<chilicuil> por lo que es mucho *mas* rapido
<chilicuil> y con eso termina la sesion
<chilicuil> con eso termino mi participacion el dia de hoy, si alguien mas desea ser voluntario para interpretar algunas de las sesiones de maÃ±ana, es bienvenido =) https://wiki.ubuntu.com/SemanaDesarrollador que pasen un excelente dia, los logs estan disponibles desde esa misma pagina o desde http://irclogs.ubuntu.com/2012/08/29/%23ubuntu-classroom-es.html#t15:01
<Alexander> hola
<Guest11820> hola
<Guest11820> hola
<Guest11820> como estas?
<Guest11820> como estan?
<Guest11820> hola
<chilicuil> hola Guest11820 , bienvenido, las interpretaciones terminaron hace rato, puedes ver los logs de ayer en https:///wiki.ubuntu.com/SemanaDesarrollador o en la pagina en Ingles https://wiki.ubuntu.com/UbuntuDeveloperWeek
<chilicuil> dentro de unas hrs se subiran los logs de las charlas de hoy a la wiki, si quieres verlas ahora mismo puedes buscarlas aqui http://irclogs.ubuntu.com/2012/08/29/%23ubuntu-classroom-es.html#t15:01
<chilicuil> maÃ±ana sera el ultimo del evento, comienza a las 15:00 UTC
* ChanServ changed the topic of #ubuntu-classroom-es to: Bienvenido a las interpretaciones de la semana del desarrollador, puedes ver los logs en https:///wiki.ubuntu.com/SemanaDesarrollador, la proxima sesion sera el dia 30 de Agosto a las 15:00 UTC
#ubuntu-classroom-es 2012-08-30
<chilicuil> necesitaran una llave gpg y ssh para hacer esto, deberan leer la documentacion para conocer los por menores
<chilicuil> https://help.launchpad.net/YourAccount/ImportingYourPGPKey
<chilicuil> https://help.launchpad.net/YourAccount/CreatingAnSSHKeyPair
<chilicuil> sin embargo, de nuevo, supongamos que ya lo han hecho, y que tienen su repositorio PPA
<chilicuil> $ quickly share --ppa mterry/testing
<chilicuil> empaquetara su programa y lo subira a su repositorio de pruebas
<chilicuil> 'quickly share' le pondra un nombre como 0.1public1 al paquete de prueba
<chilicuil> no es un bonito nombre, pero esto es asi, porque 'quickly share' se supone que se usa para compartir varias versiones previas de los programas
<chilicuil> cuando su programa este listo para produccion, pueden utilizar $ quickly release
<chilicuil> lo que subira su paquete, y le asignara una version mas elegante, como 12.08
<chilicuil> nja pregunta que editor recomendaria para programar en python
<chilicuil> mterry responde que como es ludita, es decir, que no le agradan mucho las maquinas, prefiere usar un editor simple como gedit
<chilicuil> y aclara que tal vez el no sea la mejor personas para responder esa pregunta
<chilicuil> recomienda que escuche las respuestas que el resto de las personas le sugieran en el canal de discusion
<chilicuil> regresando a la charla
<chilicuil> una vez que he hablado un poco de 'share' y de 'release'
<chilicuil> hablare de 'submitubuntu'
<chilicuil> supongan que han seguido mejorando su aplicacion, y ahora consideran que es perfecta
<chilicuil> tal vez querran enviarla al centro de software de Ubuntu
<chilicuil> en ese caso pueden utilizar el comando
<chilicuil> $ quickly submitubuntu
<chilicuil> lo que tambien subiera esa version a su ppa
<chilicuil> pero que ademas hara algunos cambios en el empaquetamiento que son necesarios para los programas que quieren ser parte del repositorio -extra
<chilicuil> si quieren probar el paquete que se genera con el comando 'submitubuntu', pueden correr quickly de esta forma:
<chilicuil> $ quickly package  --extras
<chilicuil> lo que hace basicamente quickly es poner los datos de su programa en /opt, en lugar de mezclarlos con el resto del sistema (/usr/bin, /usr/share, etc)
<chilicuil> green7 pregunta si el recomendaria usar quickly en lugar de pygtk
<chilicuil> mterry responde que si la aplicacion que esta haciendo la esta haciendo para compartirla en ubuntu, si
<chilicuil> agrega que quickly solo es una interfaz alrededor de pygtk
<chilicuil> que ayuda con el empaquetamiento y la integracion, ademas de tener cierta cantidad de magia como la que existe entre Glade y su codigo
<chilicuil> ironhalik pregunta sobre la compatibilidad de quickly con las versiones anteriores de Ubuntu
<chilicuil> mterry responde que no deberian existir muchos problemas
<chilicuil> quickly agrega cierta cantidad de codigo en las aplicaciones (por ejemplo, el directorio test_project_lib)
<chilicuil> que bien podrian quedar iguales en caso de que se quisiera migrar alguna aplicacion hecha con quickly para versiones anteriores
<chilicuil> el unico que problema que podria haber, seria con las dependencias
<chilicuil> por ejemplo, si su programa dependiera de otros que no existen, o que son mas nuevos de los que existen en la version de la distribucion a la cual se quiere migrar
<chilicuil> sin embargo quickly por si mismo deberia funcionar bien, la version del 12.04 usa introspeccion de gobjetos para los bindings en GTK/python
<chilicuil> no se que tan estable sea eso, supongo que es muy probable que no funcione en 10.4
<chilicuil> aunque deberia en Ubuntu 11.10 al menos
<chilicuil> gigix pregunta si quickly hace dependiente un programa de Ubuntu
<chilicuil> mterry responde que no
<chilicuil> que quickly solo ofrece atajos para hacer el proceso de desarrollo en Ubuntu mas facil
<chilicuil> por ejemplo, ayudando a crear paquetes .deb de los programas, o ayudando a distribuirlos (subiendolos a un ppa)
<chilicuil> sin embargo, el propio codigo de la aplicacion no depende de alguna caracteristica de Ubuntu
<chilicuil> FlowRiser pregunta por tutoriales de GTK
<chilicuil> mterry recomienda http://developer.gnome.org/
<chilicuil> http://developer.gnome.org/gtk3/stable/ (resumen del api)
<chilicuil> y http://developer.ubuntu.com/resources/
<chilicuil> marcosb pregunta si hay planes para agregar plantillas para Ruby
<chilicuil> mterry responde que no
<chilicuil> ben72 pregunta si hay alguna forma de forzar a quickly para que funcione con python 3, y agrega que en la sesion de ayer les enseÃ±aron que debe usarlo en lugar de python2
<chilicuil> mterry felicita a ben72 por la excelente pregunta
<chilicuil> y admite que quickly tiene una importante falla en esto
<chilicuil> esta de acuerdo en que las nuevas aplicaciones deberian crearse con python 3
<chilicuil> sin embargo, aun no hay podido migrar quickly para que use python 3
<chilicuil> especialmente con el empaquetado
<chilicuil> asi que lo que recomienda es utilizar quickly para hacer una aplicacion
<chilicuil> y que posteriormente se migre a python 3
<chilicuil> (lo cual deberia ser muy facil)
<chilicuil> sin embargo, sin hacen esto, ya no podran correr 'quickly package', 'share', 'release' o 'submitubuntu'
<chilicuil> =(
<chilicuil> sin embargo pueden tomar el paquete en python 2 que genera quickly, modificar el directorio /debian, migrar sus programa a python 3, y hacer que vuelva a funcionar el empaquetamiento
<chilicuil> al menos no tendran que comenzar de 0
<chilicuil> quickly tiene otras caracteristicas
<chilicuil> por ejemplo 'quickly save'
<chilicuil> este comando guardara sus cambios en un sistema de control de versiones llamado bzr (bazaar)
<chilicuil> sera como guardar su avance cada vez que hagan cambios que se relacionen entre si
<chilicuil> tambien pueden usar bzr directamente (por ejemplo $ bzr diff) para ver los cambios que han estado haciendo, etc
<chilicuil> bzr es muy bueno, y esta integrado con Launchpad, por ejemplo, podrian hacer $ bzr push lp:~mterry/+junk/test-project
<chilicuil> y eso enviaria su codigo al sitio (en mi cuenta, claro, para su caso, sera otra diferente)
<chilicuil> +junk es un truco de launchpad, de esta manera pueden subir archivos sin tener que definir un proyecto
<chilicuil> si ya han definido un nombre de proyecto en launchpad, entonces pueden usarlo
<chilicuil> en fin, todo eso, son cosas de launchpad y no quickly
<chilicuil> solo queria mencionar el comando $ quickly save
<chilicuil> otro buen truco es $ quickly add dialog new-dialog
<chilicuil> supongamos que quieren agregar un dialogo para guardar, o una ventana de error. En ese caso, quickly les ayuda un poco
<chilicuil> creara el codigo y lo agregara a glade (aunque tendran que cerrar Glade y volverlo a abrir con $ quickly design
<chilicuil> tambien tendran que correr de nuevo $ quickly edit para abrir los archivos recien creados
<chilicuil> despues de esto, veran el codigo generado, y la nueva interfaz en glade
<chilicuil> por lo que solo tendran que importarlo en su ventana principal con "from nombre_proyecto.DialogName import DialogName"
<chilicuil> e instanciarlo con "d = DialogName()"
<chilicuil> pueden correr $ quickly help para ver todos los comandos disponibles, y la ayuda particular de cada uno, como con $ quickly help save
<chilicuil> skizobass pregunta, cuando se crea un nuevo dialogo con Quickly, como se separa ese archivo del script principal?
<chilicuil> mterry responde que quickly creara un nuevo archivo en python (en test_project/ por ejemplo)
<chilicuil> asi que si se utiliza $ quickly add dialog hello
<chilicuil> se creara un archivo en test_project/HelloDialog.py
<chilicuil> (espero que le haya atinado al nombre)
<chilicuil> nja pregunta si hay algo parecido a .toString() en python
<chilicuil> mterry responde que si, str()
<chilicuil> y que se usa de la siguiente manera, si se tiene un objeto 'o'
<chilicuil> se puede hacer str(o) para obtener una cadena
<chilicuil> skizobass pregunta si quickly separa el codigo de cada nuevo dialogo
<chilicuil> mterry responde que si, siempre y cuando se use el comando $ quickly add dialog para generarlo
<chilicuil> y agrega que los programadores no tienen porque seguir esa forma de trabajo
<chilicuil> que pueden organizar el codigo como mejor les parezca
<chilicuil> pero cuando quickly tenga que generar codigo, lo hara asi
<chilicuil> vale, parece que casi se me ha acabado el tiempo
<chilicuil> se que esta introduccion fue muy simple, pero espero que ahora tengan una mejor idea de lo que es quickly
<chilicuil> y por que querrian usarlo
<chilicuil> de nuevo, recomiendo que utilicen los comandos "quickly help" y "quickly tutorial" para aprender a usarlo por su cuenta
<chilicuil> http://developer.ubuntu.com/resources/app-developer-cookbook/all-recipes/ tambien les puede ser de ayuda
<chilicuil> al igual que http://developer.ubuntu.com/resources
<chilicuil> nja pregunta si en python es posible usar un constructor con diferentes argumentos
<chilicuil> mterry responde que si y no
<chilicuil> es decir, siempre se usa el mismo metodo
<chilicuil> pero puedes tener argumentos que sean opcionales, por ejemplo __init__(option1=None, option2=None)
<chilicuil> mterry agradece a todos por sus preguntas, y finaliza su sesion
<Cayo> hola buenas tardes a todos!
<chilicuil> hola Cayo, bienvenido
<chilicuil> dentro de poco comenzara el tercer dia del desarrollador, asegurate de tambien entrar a #ubuntu-classroom y #ubuntu-classroom-chat
<Cayo> ah que bueno
<Cayo> y como fue los dos otros dias, estaba sin internet, y no pudo participar :(
<chilicuil> pues bien, el primer dia fueron introducciones, ayer fueron temas de programacion, hubo buena participacion, en general hemos podido interpretar mas de la mitad de las charlas
<chilicuil> si te lo perdiste puedes hecharle un vistazo a los logs en espaÃ±ol e ingles en https://wiki.ubuntu.com/SemanaDesarrollador
<Cayo> muchas gracias!
<chilicuil> ha comenzado el ultimo dia de la semana del desarrollador
<chilicuil> Daniel Holbach recuerda que el canal #ubuntu-classroom sera usado unicamente para la sesion, y #ubuntu-classroom-chat para la discusion y para hacer preguntas
<chilicuil> si tienen alguna pueden hacerla usando el prefijo QUESTION
<chilicuil> ejemplo QUESTION: Is it true some of your teammates can discuss Metallica albums for hours?
<chilicuil> las preguntas van en ingles, si tienen algun problema para formularla, pueden escribirla aqui, y con gusto les ayudare a plantearla
<chilicuil> comenzare con la interpretacion
<GridCube> Hola
<chilicuil> buenos dias, mi nombre es David Planella y trabajo en Canonical como parte del equipo que se encarga de administrar la comunidad (Community), sin embargo hoy vengo con las intenciones de hablarles sobre programacion en Ubuntu
<chilicuil> hola GridCube, bienvenido
<chilicuil> esta sesion, sera un poco diferente de las que se han dado hasta el momento
<chilicuil> voy a hablar sobre como crear aplicaciones para Ubuntu
<chilicuil> en lugar de mantenerlas o trabajar en la plataforma en si
<chilicuil> las dos son igualmente de entretenidas, asi que sientanse libres de escoger entre cualqueira de las dos
<chilicuil> siendo asi durante la siguiente media hr, hablare sobre como enviar sus aplicaciones a Ubuntu
<chilicuil> para que puedan aparecer en el Centro de Software y puedan ser distribuidas a millones de personas
<chilicuil> sin embargo, no solo sera una presentacion, me gustaria que todos participaran e hicieran sus preguntas al final de la sesion
<chilicuil> recuerdenlas que para hacerlas deben usar el prefijo QUESTION y hacerlas en #ubuntu-classroom-chat
<chilicuil> durante la charla me estare refiriendo constante a varios lugares del sitio de desarrollo de Ubuntu
<chilicuil> http://developer.ubuntu.com
<chilicuil> comencemos
<chilicuil> Creando su aplicacion
<chilicuil> =======================
<chilicuil> bueno, el primer paso es un tanto obvio, primero tendran que crear una aplicacion
<chilicuil> esto es basicamente ese momento maravilloso en que convierten una buena idea en un programa funcional
<chilicuil> no hablare mucho de esta parte, porque esta mas alla de esta sesion
<chilicuil> sin embargo, dare un par te tips para los que les interese
<chilicuil> el primer tip, es que usen las aplicaciones que ya estan en los repositorios
<chilicuil> muchos de estas aplicaciones son muy poderosas y son suficientemente flexibles
<chilicuil> asi que ademas de ayudarles a desarrollar sus programas, les enseÃ±aran buenas practicas de programacion
<chilicuil> si eso no fuese suficiente, es software libre (y tambien gratis)
<chilicuil> pueden ver una guia de estas aplicaciones en
<chilicuil> http://developer.ubuntu.com/get-started/quickly-workflow/
<chilicuil> quickly es el nombre del proyecto, que pone todas estas herramientas en un solo lugar
<chilicuil> si queiren saber mas sobre el tema, mterry dio una charla sobre ello durante esta semana del desarrollador
<chilicuil> asi que pueden darle un vistazo en los logs
<chilicuil> tambien pueden ver una introduccion en el siguiente video
<chilicuil> http://developer.ubuntu.com/get-started/
<chilicuil> Que tipo de aplicaciones se aceptan
<chilicuil> =====================================
<chilicuil> hay miles de aplicaciones en los repositorios de Ubuntu, varias de ellas llegan de diferentes formas
<chilicuil> y se podrian clasificar en diferentes tipos, algunos son programas del sistema, otras aplicaciones desarrolladas por Ubuntu, etc
<chilicuil> sin embargo todas ellas se someten a estrictas reglas de seguridad, y calidad, ademas de ser software libre
<chilicuil> para diferencias estas aplicaciones de otras utilizare el termino "proceso de aplicaciones para desarrolladores"/"the app developer process"
<chilicuil> para responder algunas preguntas, basicamente existen 3 tipos de aplicaciones que pueden ser aceptadas a traves de este proceso
<chilicuil> * aplicaciones comerciales
<chilicuil> * aplicaciones con licencia comercial, pero que son gratis
<chilicuil> * aplicaciones libres
<chilicuil> pueden notar como ademas de aceptar software libre, fomentamos el software comercial, esto es para dar darles oportunidad a los autores de estos programas y para poder hacer algo de dinero para Canonical
<chilicuil> 1.- Como enviar tu aplicacion
<chilicuil> ===============================
<chilicuil> bien, cuando llegues a este punto ya tendras un programa y querras compartirlo con el resto del mundo
<chilicuil> la buena noticia, es que el proceso que hemos creado es facil de usar y lo puedes hacer desde un navegador, asi que puedes enviarlo y estar al pendiente del estado de tu aplicacion todo el tiempo desde el sitio web
<chilicuil> https://myapps.developer.ubuntu.com
<chilicuil> notaran que ha sido hecho facil de usar a proposito, lo unico que necesitan es crear una cuenta para poder comenzar
<chilicuil> pueden registrarse gratis y en un par de minutos, el proceso esta basado en el sistema de login unico de Ubuntu (SSO), si ya tienen una cuenta en otros servicios relacionados con ubuntu, entonces sera aun mas rapido
<chilicuil> hubo un netsplit, asi que perdi parte del log de la segunda charla, seguire interpretando en la tercera: "Adding test cases with UTAH"
<chilicuil> comenzare con la intepretacion, gema aprovecha para saludar a todos
<chilicuil> hola, mi nombre es Gema Gomez-Solano y trabajo para el equipo de calidad (QA team) en Canonical
<chilicuil> voy hablarles sobre UTAH, o el sistema de automatizacion de pruebas de ubuntu (Ubuntu Test Automation Harness)
<chilicuil> basicamente es una herramientas que hicimos para empezar a tener un orden en las pruebas que estabamos haciendo
<chilicuil> asi que nos gustaria compartirla en caso de que otras personas tengan el mismo problema
<chilicuil> UTAH se supone que es un programa para ayudar durante todo el proceso de pruebas
<chilicuil> la pagina del proyecto esta en https://launchpad.net/utah
<chilicuil> en fin, comencemos por describirla con poco mas de detalle
<chilicuil> el proceso general es tomar una imagen iso de algun lugar, instalar la imagen en una maquina real/virtual y devolver los resultados
<chilicuil> antes de tener esta herramientas estabamos trabajando con varias cosas que requerian modificarse a detalle para resolver problemas muy particulares
<chilicuil> asi que teniamos que hacer pruebas de imagenes iso, para hacer pruebas de posibles regresiones del kernel, para verificar las actualizaciones...
<chilicuil> y lo haciamos en maquinas virtuales de 32, 64 bits y arquitectura ARM
<chilicuil> asi que tenias varios scripts, cada uno resolvia un problema especifico
<chilicuil> esta situacion no era unica del equipo de pruebas (QA), lo mismo ocurrio en los equipos de desarrollo
<chilicuil> existia mucho codigo que se estaba repitiendo en varios lugares
<chilicuil> asi que empezamos a construir esta herramienta para unificar todo lo que estabamos haciendo
<chilicuil> ahora las pruebas pueden hacerse en cualquier lenguaje y despues integradas en UTAH para que puedan correr como parte del sistema
<chilicuil> tambien se puede configurar para que corran determinadas pruebas a cierta hora, para eso usamos jenkins
<chilicuil> pueden usar cron o cualquier otro sistema que les acomode para ese caso
<chilicuil> esperamos que UTAH tambien nos ayude a reproducir bugs
<chilicuil> hola Guest27302, en este canal se hace la interpretacion de #ubuntu-classroom, estamos hablando sobre automatizacion de pruebas de testing, si tienes alguna pregunta puedes hacerla en #ubuntu-classroom-chat, si tienes problemas con el Ingles, puedes hacerla aqui y la hare por ti alla =)
<chilicuil> cada vez que encontremos un bug con este sistema, deberiamos ser capaz de enviarle un archivo con las instrucciones precisas a un desarrollar, y el podria reproducirlo
<chilicuil> eso sin tener que preocuparse por la instalacion
<chilicuil> intentamos hacer que todas las pruebas se automaticen
<chilicuil> La estructura de pruebas en UTAH
<Guest27302> gracias soy nuevo en el mundo ubuntu, GNU/linux en general
<chilicuil> las pruebas (cases) son la unidad mas pequeÃ±a de ejecucion en UTAH, ponemos cada una de estas pruebas en diferentes archivo, asi podemos escoger cualquier de ellos en dterminado momento, esto funciona incluso si el testcase recive parametros y llama a otros dependiendo de ello
<chilicuil> los testcases pueden agregarse o quitarse, asi cada persona tiene control sobre su entorno
<chilicuil> los testcases deben dejar el sistema en el mismo estado en el que lo recibieron, hemos llegado a esta politica despues de considerar que es una buena politica para evitar tener problemas con otros testcases
<chilicuil> de esta forma tambien podemos hacer independiente el orden en el que se pueden correr las pruebas, ninguna depende de otra
<chilicuil> los testcases tambien pueden agruparse en grupos
<chilicuil> las suits de testcases son grupos de testcases cuya finalidad es probar cierta funcionalidad y que se mantienen en buen estado en su conjunto
<chilicuil> por ejemplo, el grupo de pruebas sera mantenido por un desarrollar que tiene mucha experiencia en esa parte del proceso
<chilicuil> tambien tenemos listas de pruebas, estas lista se aseguran de ejecutar un grupo de testcases al mismo tiempo
<chilicuil> estas listas podrian ser diferentes entre digamos, ubuntu quantal y ubuntu precise, esto es porque puede ser que quieras probar diferentes cosas dependiendo de la distribucion
<chilicuil> en fin, hemos hablado sobre como UTAH nos ayuda a probar las instalaciones de Ubuntu
<chilicuil> asi como de que las pruebas de UTAH pueden ser hechas en cualquier lenguaje y devuelven errores en una forma estandard
<chilicuil> UTAH analiza los logs que se generan en stderr y stdout (salidas estandard)
<chilicuil> UTAH soporta reinicios, asi si una prueba necesita que el equipo se reinicie, UTAH lo hara y despues continuara donde se quedo
<chilicuil> los testcases tienen tiempo de expiracion, los grupos de testcases tambien lo tienen, e incluso se puede definir un tiempo para todo el proceso
<chilicuil> esto es especialmente importante cuando haces pruebas completas, a la mayoria de las personas no les gustaria que un servidor se quedara en el mismo estado durante mucho tiempo, solo porque una prueba ha fallado
<chilicuil> las listas de pruebas (runlists) pueden escoger pruebas especificas de los grupos de pruebas
<chilicuil> cual es el estado actual del sistema?
<chilicuil> bueno, ya estamos usando UTAH para hacer pruebas en el tiempo de arranque de Ubuntu
<Guest27302> Felicitaciones por tu labor *chilicuil*
<chilicuil> y empezamos a migrarlo al sistema de pruebas de ISO
<chilicuil> no tienes porque, lo hago con mucho gusto, y ademas me ayuda a entender mejor los temas, no suelo ser bueno reteniendo cosas =), continuo
<chilicuil> la parte mas dificil a la que nos hemos enfrentado al hacer esta migracion es decirdir como modificar la estructura de las pruebas, para que puedan agregarse facilmente en el futuro
<chilicuil> tambien estamos trabajando para automatizar las pruebas en la arquitectura ARM
<chilicuil> TheLordOfTime pregunta como puede obtener UTAH para empezar a usarlo
<chilicuil> gema agradece la pregunta y agrega que la documentacion del proyecto se encuentra en http://utah.readthedocs.org/en/latest/index.html ahi encontrara esa informacion
<chilicuil> agrega que tal vez tambien quiera inscribirse a la lista de correo para obtener noticias frescas https://lists.canonical.com/mailman/listinfo/ubuntu-utah-devel
<chilicuil> o para preguntar en caso de que tenga problemas configurando el sistema
<chilicuil> jsjgruber-l85-p pregunta si es posible usar UTAH para hacer pruebas en aplicaciones graficas
<chilicuil> gema responde que es una buena pregunta, y que por el momento no es posible, pero que se esta trabajando en esa caracteristica
<chilicuil> agrega que la razon por la por el momento no es posible es porque UTAH se conecta a la maquina donde hara las pruebas de forma remota a traves de ssh
<chilicuil> siendo de esta forma, aun no se ponen de acuerdo como comenzar la sesion X para empezar a hacer las pruebas graficas desde ahi
<chilicuil> sugiere una vez mas que se unan a la lista de correo si desean hacer sugerencias al sistema o si tienen cualquier otra pregunta
<chilicuil> ahora hablara un poco mas sobre como hacer testing de una formas mas general
<chilicuil> y eso no se limitara a UTAH
<chilicuil> marcosb pregunta sobre sistemas de pruebas que puedan usarse en Linux
<chilicuil> gema responde que ademas de UTAH en ubuntu tambien se tiene autopilot
<chilicuil> Xpresser o checkbox, que se usa para hacer algunas pruebas manuales y certificaciones
<chilicuil> gema dice que las preguntas pueden dirigirse directamente a #ubuntu-classroom
<chilicuil> la sesion se tornara una mesa redonda =)
<chilicuil> he preguntado si nicolas skaggs es parte de su equipo, o si los equipos estan divididos por funciones
<chilicuil> gema ha respondido que el es el coordinador de las pruebas de testing de la comunidad, asi que trabajan con el en pruebas que benefician la parte abierta de Ubuntu
<chilicuil> agrega que nick no es parte del equipo pero que se suelen comunicar con mucha frecuencia con el
<chilicuil> tambien menciona que en canonical y con la ayuda de la comunidad se crean testcases que luego pueden ser usados por nosotros, los usuarios
<chilicuil> he preguntado porque no habia escuchado del sistema UTAH en los correos que Nicolas envia con frecuencia en la lista de testing de la comunidad
<chilicuil> y gema ha respondido que porque UTAH aun esta en fase de pruebas, sin embargo Nicolas pregunta por el casi todos los dias, asi que espera que pronto se pueda empezar a usar en 'produccion'
<chilicuil> aun hay algunos minutos, si tienen alguna pregunta sientanse libre de hacerlas
<chilicuil> todas son bienvenidas, no hay preguntas demasiado basicas
<chilicuil> gema agrega que si alguien se siente curioso por ver los resultados de las pruebas actualeas, puede hechar un vistazo a https://jenkins.qa.ubuntu.com/
<chilicuil> y si alguien quiere participar, puede comenzar a hacerlo leyendo la wiki https://wiki.ubuntu.com/QATeam/
<chilicuil> gema se despide y sugiere que si alguien mas esta interesado entre a #ubuntu-testing
<chilicuil> dentro de breve comenzara la sesion sobre webapps en Ubuntu, durante este ciclo ubuntu ha agregado caracteristicas al launcher que hacen que puedan correr gmail como si tratara de otra aplicacion, sobre ello ira la sesion
<chilicuil> lamalex y alex-abreu seran los ponentes durante esta sesion
<chilicuil> ambos son parte del equipo 'webapp' de canonical
<chilicuil> comienzo la interpretacion ahora
<chilicuil> Canonical desarrollo la idea de webapps para intentar cerrar el trecho que hay entre las aplicaciones web y las de escritorio
<chilicuil> la diferencia a veces no es muy clara, y la unica barrera que hay entre ellas suele ser tecnologica
<chilicuil> no somos los primeros en intentar esto claro esta, pero creemos que vale la pena intentarlo
<chilicuil> hace poco rick spenser intento fusionar el desarrollo de aplicacion html5 con aplicaciones de escritorio, incluso hizo un demo, sin embargo aunque el resultado es bueno, deja mucho a desear
<chilicuil> lo que estamos intentando hacer es integrar las aplicaciones web a traves de un api en javascript que los autores de las aplicaciones web pueden usar para hacer que su programa se comporte como si estuviera hecho para el escritorio
<chilicuil> la idea es que con esa API se exponga a otros scripts para que se pueda hacer la integracion desde varios puntos
<chilicuil> a traves de esta API, los scripts tendrian acceso a varias caracteristicas, como el menu de mensaje, el de sonido, el lanzador (con su icono, listas de acceso, etc)
<chilicuil> tambien podrian tener acceso al dash (donde se pueden ir agragando acciones), arrastrar y soltar, cambio de ventanas (alt-tab), entre otras cosas en las que estamos pensando
<chilicuil> hasta que llegue un punto en que la integracion se sienta bien
<chilicuil> pensamos que la integracion se puede lograr de 2 formas basicamente
<chilicuil> 1.- a traves del navegador (con firefox o chromium), si fuera asi tendrian un script asociado que integrara 'nativamente' las aplicacions con Ubuntu a traves del acceso directo a nuestra API
<chilicuil> 2.- usando un lanzador (con un icono de la aplicacion) que iniciara un programa que ya sido integrado, esto iniciaria el navegador (el que usaran por defecto) en un modo especial "chromeless"
<chilicuil> de esta forma se quitarian todos los elementos del navegador dejando unicamente la vista de las pestaÃ±as
<chilicuil> el menu podria ser diseÃ±ado para abarcar un minimo (y en el futuro podria expanderse con comandos especificos de cada aplicacion web)
<chilicuil> la idea de tener el navegador sin muchos elementos graficos es que se puedan acomodar varios tipos de aplicaciones web que esten relacionados (que pertenezcan a un mismo sitio web por ejemplo)
<chilicuil> por ejemplo, google docs
<chilicuil> todos tus documentos tendrian que abrirse en la misma ventana
<chilicuil> y una vez que saliera de esa pagina se abriria otra ventana del navegador como si tratara de otra aplicacion
<chilicuil> estamos muy emocionados que este trabajo ofrezca tantas oportunidades de colaboracion con la comunidad de Ubuntu
<chilicuil> ahora que hemos descrito la idea, hablaremos un poco mas de como se integran los componentes y haremos un tutorial de como hacer un script para este sistema
<chilicuil> esperamos que en este ultimo apartado sea el mas util para la comunidad, entre mas aplicaciones web sean integradas mejor sera su uso en Ubuntu
<chilicuil> planeamos que el resultado de todo esto lo podamos sugerir en las charlas con las organizaciones de estandarizacion de las tecnologias web, lo que a futuro podria traer una mejor integracion multiplataforma, empezando con Ubuntu
<chilicuil> comencemos con los scripts de usuario, este es codigo en javascript que integra una aplicacion web con ubuntu
<chilicuil> hay de 2 tops, los scripts de usuario y los scripts nativos (userscripts/native)
<chilicuil> un script de usuario es basicamente un script de greasemonkey, esa clase de scripts se injectan en el navegaddor y se ejecutan mientras la pagina se carga, se comportan como codigo javascript ordinario
<chilicuil> ~estos son los que se instalan con el paquete unity-webapps
<chilicuil> lo que hacen es analizar la estructura DOM y hacen varias llamadas al API de aplicaciones de web de Unity (http://developer.ubuntu.com/api/ubuntu-12.04/javascript/unity-web-api-reference.html) esto provoca que se puedan intercambiar mensajes con el lanzador, con el HUD, con el menu de mensajes entre otros
<chilicuil> estos son los puntos mas importantes, el resto del stack se trata de modificar algunos bits para que funcione sin problemas
<chilicuil> esto funciona bien, sin embargo nuestro objetivo es que los desarrolladores web integren nuestra API directamente en sus aplicaciones para que ya no sean necesarios estos scripts (refiriendose a los scripts de greasemonkey)
<chilicuil> nos gustaria que fuera de esta manera para que los desarrolladores originales, fueran los que modelaran su aplicacion para que brindara la mejor experiencia posible en el escritorio
<chilicuil> hasta el momento aunque pocos, hemos visto que algunos desarrallores web han empezado a usar nuestra API
<chilicuil> por ejemplo Rd.io
<chilicuil> como se ha comentado, estas extenciones son las que manejan las modificaciones que se hacen a la aplicacion web a traves de nuestra API
<chilicuil> siendo asi, existen dos extensiones, una para firefox y otra para chromium y pueden verlas en chrome://extensions
<chilicuil> sin detallar mucho (aunque si asi lo requieren pueden preguntar), cada pestaÃ±a del navegador tiene un script asociada a ella, este script se comunica con otro que esta corriendo en el background de la pagina y que verifica si hay algun script de integracion disponible para el sitio
<chilicuil> ese mismo script tambien ofrece sus servicios a los scripts 'normales' de las paginas para que puedan usarlo de la forma nativa
<chilicuil> la logica que se esconde detras de la extension de firefox es muy parecida a la que esta en chromium, aunque en el caso de firefox se utiliza una version modificada de greasemonkey para cargar e inyectar los scripts de usuario
<chilicuil> en ubuntu Quantal por ejemplo, intalamos firefox con un parche que extrae cierta caracteristica de firefox 17 que nos permite obtener el XID de una pestaÃ±a, usamos este identificador para mantener la ubicacion de la aplicacion
<chilicuil> desde el punto de vista de la extension, los datos se envian a traves de la API, que a su vez envia los comandos a un servicio que esta corriendo en segundo plano en Ubuntu
<chilicuil> existen dos procesos, context-daemons y webapps-service
<chilicuil> webapps se encarga de las tareas comunes (que no estan relacionadas a ningun sitio en particular)
<chilicuil> mientras que context-daemons hace la integracion dependiendo de cada tipo de pagina que se haya cargado
<chilicuil> si escriben D-feet (el navegador de dbus) y escriben webapp
<chilicuil> veran el nombre de los servicios
<chilicuil> tambien podran ver algunos procesos privados, los privados representan cada uno la aplicacion web, estos se crean cada vez que se abre gmail, google docs, twitter, etc
<chilicuil> bien, ahora vayamos a la parte del tutorial
<chilicuil> mucha de la informacion que dejemos tambien esta accesible en webapps.ubuntu.com
<chilicuil> y en http://developer.ubuntu.com/resources/app-developer-cookbook/unity/integrating-tumblr-to-your-desktop/
<chilicuil> este tutorial se centrara en el centro de administracion de tumblr, asi que si no tienen una cuenta en tumblr, pueden 1) crear una o 2) intentar probar lo que haremos con un servicio similar
<chilicuil> usaremos firefox en este ejemplo, pero pueden probarlo con chromium, de hecho los invitamos a que vayan ahora mismo a tumblr.com con chromium
<chilicuil> una vez ahi, presionen ctrl+shift+j para abrir la consola javascript
<chilicuil> en este lugar es donde trabajaremos durante el resto del demo, el primer paso siempre sera cargar el objeto unity y siempre se hace de la misma forma
<chilicuil> en su consola JS escriban "window.Unity = external.getUnityObject(1);"
<chilicuil> el parametro 1 es para escoger la version de la API, asegurense que su script usa la version adecuada
<chilicuil> tengan en cuenta que este script se ejecutara cada vez que abran ese sitio web
<chilicuil> una de las cosas que casi siempre bera es una funcion llamada isCorrectPage()
<chilicuil> esta funcion no es obligatoria, pero sugerimos que se use
<chilicuil> esta funcion se asegura que el sitio web tenga todos los elementos que se esperan de el antes de comenzar
<chilicuil> si nos referimos a este tutorial veremos que isCorrectPage es una funcion que llama a su vez a Unity.init
<chilicuil> Unity.init es la funcion principal de nuestros scripts de usuario, inicializa el proceso context-daemon y agrega un icono al lanzador de aplicaciones
<chilicuil> toma los parametros a partir de un diccionario que acepta 3 cosas
<chilicuil> nombre, url_del_icono, onInit
<chilicuil> el nombre es.., el nombre de la aplicacion, muy obvio, no?
<chilicuil> url_del_icono es la url de donde se puede obtener el icono, puede tener la forma icon:// si se trata de un icono que esta en la maquina cliente, o la direccion web si esta disponible en Internet
<chilicuil> asegurense de seleccionar un nombre que sea significativo, ese nombre se mostrara cuando se le pregunte al usuario si desea dar permisos para correr el script
<chilicuil> en este ejemplo, la url del icono la hemos sacado de http://assets.tumblr.com/images/logo.png
<chilicuil> entonces la linea queda como:
<chilicuil> Unity.init({name: "Tumblr", iconUrl: "http://assets.tumblr.com/images/logo.png", onInit: wrapCallback(setupTumblr)});
<chilicuil> en onInit se definie el nombre de la funcion que hara el verdadero trabajo
<chilicuil> una vez que el proceso se haya inializado en Ubuntu, se comunicara con el script y todo empezara a funcionar
<chilicuil> como no nos queda mucho tiempo, no vemos la razon para estudiar esto a mayor profundidad
<chilicuil> sin embargo nos gustaria volver a recomendar que leyeran http://developer.ubuntu.com/resources/app-developer-cookbook/unity/integrating-tumblr-to-your-desktop/
<chilicuil> y que hicieran sus preguntas en #ubuntu-webapps si les surge cualquier pregunta
<chilicuil> alguna pregunta?, comentario?
<chilicuil> una vez que se llame a la funcion que pongan en onInit tendran un icono que podran usar y estaran listos para usar el resto de la API para integrar la aplicacion
<chilicuil> en fin, gracias a todos por asistir, espero que la sesion haya sido informativa sino que hasta inspiradora
<chilicuil> ahora vayan y escriban sus propios scripts para traer al escritorio sus aplicaciones web favoritas
<chilicuil> ademas de hacer sus preguntas en #ubuntu-webapps pueden hacerlas en askbuntu.com, si hacen esto, no olviden agregar la etiqueta "webapps"
<chilicuil> con esto termino la interpretacion de la sesion sobre webaaps y me retiro un momento, ahora mismo se esta dando la charla sobre programacion de u1db (la api de ubuntu one) en #ubuntu-classroom
<chilicuil> regresare en 1 hr para interpretar la mesa redonde que se organizara para concluir la semana del desarrollador
<chilicuil> preparen todoas sus preguntas ;)
<chilicuil> los logs de los 2 dias anteriores estan en: https://wiki.ubuntu.com/SemanaDesarrollador en el caso que quieran repasar algun tema, lamentablemente no hemos podido interpretar todas las charlas, pero esperamos que al menos las mas interesantes lo esten, ahi mismo estan los links para las versiones originales en Ingles
<chilicuil> hola gus-tavo =)
<gus-tavo> hola chilicuil, como estas ? llegue tarde a la sesion :(
<gus-tavo> llegaste interpretarla toda?
<chilicuil> si gus-tavo , casi me quedo atras =), te gustaria ayudar con la ultima?, Developers Roundtable ?
<gus-tavo> si, voy a estar a la computadora aunque no creo que escriba tan rapido :), voy a necesitar ayuda para temninar !
<chilicuil> seguro, cuando te canses me avisas y te ayudo a terminar
<gus-tavo> gracias ! pero te aviso por este mismo canal, despues podes borrar esas entradas en el log?
<chilicuil> si se ponen en un pastebin (menos profesional) si, si apunto a irclogs.ubuntu.com no
<gus-tavo> bueno, enseguida entonces comienzo, y cuando me quede atras te aviso, gracas
<chilicuil> gus-tavo: nop
<chilicuil> gus-tavo: todavia no, me referia a la sesion que comenzara dentro de 20 min
<gus-tavo> si, si, te entendi, faltan 15 min aproximadamente
<chilicuil> ahh, ok =)
<gus-tavo> En esta sesion basicamente queremos interactuar con los desarrolladores, si eres un dessarrollador, saludos, y que comiencen las preguntas !
<gus-tavo> pueden compartir sus experiencias como desarrolladores mas tarde,
<gus-tavo> alguna pregunta?
<gus-tavo> wan26 pregunta: Quiero comenzar a desarrollar pero no se como empezar
<gus-tavo> wan26: seguro que mucha gente tiene el mismo problema o/
<gus-tavo> alguien mas ?
<gus-tavo> bdrung dice: comencÃ© como desarrollador Ubunto haciendo mis investigaciones. necesitaba una nueva version de matplotlib y trate de actualizar el paquete
<gus-tavo> bdrung, podrias contarnos mas de tu experiencia? La tuya es como la mÃ­a, haciendo mis propias investigaciones
<gus-tavo> bdrung: esa es una buena motivacion para comenzar a trabajar en software libre
<gus-tavo> encontrar algo es facil: probablemente has experimentado un error que te hace querer una nueva version de un programa, pero no esta actualizado
<gus-tavo> hace 4 aÃ±os, participe en una fiesta de empaquetado en la que dholbach explico como se hacia el empaquetamiento
<gus-tavo> vi todas las herramientas en un corto periodo de tiempo y fui capaz de usarlas
<gus-tavo> el empaquetado son varias herramientas de la linea de comandos y formatos de archivos
<gus-tavo> ScottK: encontrar el error es un comienzo, pero no es lo que me sostiene. Pienso que la gente deberia hacer un poco para que el mundo sea un mejor lugar y  contribuier al software libre es parte de lo que hago por eso. un par de aÃ±os atras escribi:
<gus-tavo> https://skitterman.wordpress.com/2009/05/31/back_home_from_uds_karmic/
<gus-tavo> bien, alguien mas quiere compartir sus experiencias?
<gus-tavo> chilicuil pregunta: tengo una pregunta, si no molesta mientras estÃ¡n hablando de sus experiencias. cuÃ¡les son sus herramientas favoritas/mÃ¡s usadas en el paquete ubuntu-dev-tools?
<gus-tavo> hay un montÃ³n: syncpackage, wrap-and-sort, sponsor-patch me vienen a la mente
<gus-tavo> syncpackage es para sincronizar un paquete desde Debian a Ubuntu. si no tienes derechos para subir, probablemente uses requestsync
<gus-tavo> wrap-and-sort hara que tu archivo debian/control se vea bien (al menos para mi)
<gus-tavo> cdunlap pregunta: donde encontrar alguna de estas fiestas de empaquetado?
<gus-tavo> los desarrolladores usan las herramientas de una forma muy distinta, y eso esta bien
<gus-tavo> yo uso syncpackage todo el tiempo, pero nunca uso las otras dos
<gus-tavo> sponsor-patch es para esponsorear un paquete para alguien mas, este descarga el paquete fuente, le aplica los parches propuestos, prueba el resultado. esta herramienta me permite concerntrarme en mirar solo los cambios propuestos
<gus-tavo> pienso que todavia se estan haciendo las fiestas de empaquetado, pero no hay necesidad de esperar. yo aprendi antes de que existieran. si tienes algo en que trabajar, solo zambullete y comienza, la gente en #ubuntu-motu estara contenta de ayudarte si tenes tropezon
<gus-tavo> deberias intentar con wrap-and-sort! :)
<gus-tavo> hay mucha documentacion (mas que abrumadora!), pero asi como estes tratando como y no esperar a las soluciones, hay gente que te ayudara
<gus-tavo> no te preocupes por no aparecer como que no sabes del tema cuando preguntes. He estado haciendo esto desde el 2007 y todavia tengo preguntas
<gus-tavo> no puedo recordar cuendo tuvimos la ultima fiesta de empaquetado. La Semana de Desarrollador Ubuntu es un evento equivalente que puede dispararnos hacia el desarrollo
<gus-tavo> me he dado cuenta de que la gente escribe diferentemente codigo , como tratar con eso si tengo otro estilo, o hay algun estilo general al que adherir?
<gus-tavo> el mayor problema que veo es gente que comienza a desarrollar es que no comienza por sÃ­ sola. este no es un trabajo regular con un jefe frente a ti diciendo que es lo que se necesita hacer hoy. Tenes que encontrar la motivacion a tener algo hecho. si lo encuenteas, es probable que lo termines, porque el conocimiento tecnico para la mayoria de las actividades de empaquetado no son complejas
<gus-tavo> (hay mucho de esto, pero las piezas individuales no son duras)
<gus-tavo> calmi pregunta: para los desarrolladores con experiencia: pueden abstraer su punto de vista ? ej, pueden ponerse en la posicion de - diremos a tu padre con pocos conocimientos de computadoras, como hacer las cosas?
<gus-tavo> wan26: la distribucion de paquetes e primariamente un trabajo de integracion, no tenemos que escribir mucho codigo desde cero. si estas trabajando en un parche para solucionar un error, o mejor en Ubuntu, generalmente queres adherir al estilo del upstream, por la consistencia y maximizar las chances de que el parche sea aceptado
<gus-tavo> es dificultoso. a menudo le pregunto a la gente que es nueva en el desarrollo que arreglen la documentacion antes de hacerlo yo, ellos estan mejor posicionados para escribir que funciona para la audiencia de nuevos desarrolladores que yo
<gus-tavo> chilicuil pregunta: usan un sistema de desarrollo distribuido (ramas/fusiones) o adhieren al estilo debian de produccion de parches? piensan que la forma de Ubuntu esta lista para ser usada de forma segura para los nuevos contribuidores? cuales son algunas de las cosas alli que Ubunto no puede manejar?
<gus-tavo> nunca uso UDD
<gus-tavo> trate, pero lo encontre complejo y las herramientas no estan maduras
<gus-tavo> creo que es un error enseÃ±arle a la gente desde que entran a la rama que estÃ¡ desactualizada, tiene que hacerlo a la vieja escuela, tambien necesitan ese conocimiento
<gus-tavo> calmi: buena pregunta. Ayudo a mucha gente en mi vecindario a mantener Ubuntu. viendo como interactuan con una computadora veo las diferencias en el uso. trabajo rapido y casi siempre en la lines de comandos, pero eso no explica de que otros hagan lo mismo
<gus-tavo> si queres envolverte con Debian (que lo recomiendo), estas en el mejor de los conocimientos con mas herramientas en general
<gus-tavo> dicho esto, me encantan las ramas de empaquetado que son generadas con cada subida. hace muy facil ir atras y figurar que es lo que ha cambiado, cuando y porque
<gus-tavo> es una herramienta sorprendente de anÃ¡lisi
<gus-tavo> alguna pregunta o ideas?
<gus-tavo> bdrung: raramente uso UDD. hago la mayoria de mi trabajo con algunas herramientas de control de version Debian (en la mayoria de los casos: git)
<gus-tavo> eso nos trae otro buen punto. los dos, bdrung y yo somos desarrolladores Debian
<gus-tavo> comenzamos con Ubuntu y migramos para comenzar a trabajar en Debian tambien
<gus-tavo> muchos desarrolladores Ubuntu son tambien desarrolladores Debian (tanto como conozco) Que los hace a Uds. tambien comenzar a participar en Ubuntu?
<gus-tavo> para los paquetes que mantengo, en la mayoria de los casos los subo a Debian y sincronizo
<gus-tavo> comence en Ubuntu
<gus-tavo> Mas gente se beneficia si haces las cosas en upstream
<gus-tavo> exactamente
<gus-tavo> jincreator: comencÃ© en Ubuntu y luego Desarrollador Debian (DD)
<gus-tavo> tambien si algun cambio es hecho en Ubuntu, lo porto a Debian, eso es menos trabajo para Desarrolladore Ubuntu
<gus-tavo> Es importante. Debian tiene en orden de magnitud mas desarrolladores que Ubuntu, es critico para mucho que las cosas se hagan alli
<gus-tavo> haciendo cosas en Ubuntu te dara una diferencia (diff) entre Debian y Ubuntu. Asi un Desarrollador Ubuntu necesita mantener esta diff. toma tiempo que puede ser usado para algo mÃ¡s
<gus-tavo> Tambien los mantenedores de paquetes Debian son expertos en sus paquetes, asi trabajar con gente Debian te dara una buena retroalimentacion que es dificil de obtener en Ubuntu, donde la mayoria de los desarrolladores son generalistas y pocos paquetes tienen dedicados un mantenedor
<gus-tavo> Debian tiene cerca 1000 desarrolladores. Ubuntu alrededor de 150
<gus-tavo> Conozco a desarrolladores Debian que se han integrado en Ubuntu
<gus-tavo> ne orden de dificultad, como clasificaria las tareas que hacen?
<gus-tavo> generalmente, parece ser el deseo de aprender acerca de problemas con paquetes (Ubuntu tiene muchos usuarios y archivos con muchos errores) o considerar preocupante acerca de los usos de los derivados de Debian como Ubuntu, extensiÃ³n natural del Contrato Social de Debian.
<gus-tavo> eso depende. haciendo una tarea especifica la primera vez puede ser dificil. haciendola la decima vez es facil
<gus-tavo> digamos, que comienzas contribuyendo arreglando algun error, escribiendo algun parche, que es los siguiente? como vas del digamos contribuidor casual a desarrollador Ubuntu?
<gus-tavo> quiero decir, men encontre creando un parche para un paquete ubuntu mucho mas facil (si no es uno dificil) que fusionando o trabajando con FTFBS, nunca logre arreglar algunos de esos
<gus-tavo> stadtfeld: usualmente la gente es considerada seriamente como ubuntu dev si han contribuido al menos seis meses
<gus-tavo> chilicuil, me tengo que ir !
<chilicuil> gus-tavo: ok, gracias o/
#ubuntu-classroom-es 2012-08-31
<chilicuil> stadtfeld: una vez que contribuyes por lo menos 6 mesos y el desarrollador que sube tus cambios no quejas sobre los parches, puedes aplicar para obtener derechos sobre el archivo con el DMB (developer membership board)
<chilicuil> algunas veces ellos mismos te diran cuando creen que estas listo. Si esto sucede y  consideras que tienes la suficiente experiencia puedes preguntarles que dejen un comentario en tu pagina wiki para la junta de aprobacion
<chilicuil> chilicuil: arreglar un FTBFS (paquetes que no compilan) tambien requiere un tipo de parche, lo mas dificil de conocer es lo que debe llevar
<chilicuil> standfled: tambien podrias preguntarle a los desarrolladores que suben parches por ti si consideran que estas listo, en mi caso, me lo sugirieron antes de que se me pasara la idea por la cabeza
<chilicuil> chilicuil: es muy util conocer el lenguaje de programacion en el que esta hecho el paquete (y algunas veces la forma en la que se compila) para arreglar un bug FTBFS
<chilicuil> chilicuil: generalmente depende de la experiencia de cada uno lo que se considera facil o dificil
<chilicuil> la cosa mas dificil es empaquetar un programa desde 0, y no porque sea especialmente dificil, sino porqe para hacer eso necesitas conocer todos los detalles del sistema de empaquetamiento, creo que es lo unico que deberian evitar hacer las personas que quieren empezar a desarrollar ubuntu
<chilicuil> convertirse en un desarrollador de Ubuntu es un gran paso, quiere decir que a partir de ese momento podras subir codigo sin necesidad de que sea revisa por otros y que probablemente se usara en millones de maquinas
<chilicuil> es por esto, por lo que es muy importante que la comunidad tenga tiempo para conocerte antes de que pueda confiar en ti lo suficiente para otorgarte ese privilegio
<chilicuil> calmi pregunta sobre la relacion que existe entre los programadores de Ubuntu y sus derivados 'oficiales' como k/x/lubuntu o linux mind
<chilicuil> no se de ninguna relacion especial
<chilicuil> se que Ubuntu por ejemplo trabaja muy duro para enviar parches a Debian, lo se porque yo mismo lo he hecho literalmente cientos de veces
<chilicuil> sin embargo, no recuerdo haber visto nunca a un desarrollador de linux mind haciendo lo mismo
<chilicuil> Ubuntu tiene muchas distribuciones derivadas, y no creo que haya alguien en Ubuntu al que le interese eso
<chilicuil> supongo que no existe mucha relacion
<chilicuil> por otro lado, tambien es posible que haya trabajado con desarrolladore de Linux mind sin darme cuenta
<chilicuil> la diferencia entre Ubuntu/Kubuntu/Xubuntu solo esta en el CD, los desarrolladores son los mismos, todos trabajamos sobre los mismos repositorios. La diferencia radica en que se seleccionan diferentes programas para llenar cada CD
<chilicuil> jsjgruber-x-p_ pregunta si se pueden obtener permisos para subir paquetes sin haber creado jamas uno desde 0
<chilicuil> si, es posible, siempre y cuando hayas trabajado lo suficiente en otras areas
<chilicuil> calmi hace un comentario: entonces cada desarrollador trabaja para si mismo, excepto los programadores del duo Debian/Ubuntu?
<chilicuil> calmi: no podemos responder eso
<chilicuil> se que por ejemplo los programadores de Sabily estan activos en Ubuntu/Debian
<chilicuil> asi que por lo menos, ahi tenemos una excepcion, los desarrolladores de Ichthux tambien lo eran
<chilicuil> asi que no, hay excepciones
<chilicuil> calmi: linux mint usa los repositorios (binarios, .debs) de Ubuntu y agregan otros mas, Ubuntu usa los paquetes de codigo fuente de Debian
<chilicuil> tambien veo desarrolladores de otras distribuciones derivadas activos en Debian
<chilicuil> pregunto si las personas que les ayudaron a convertirse en desarrolladores de Ubuntu aun siguen por ahi, y sobre la relacion entre la cantidad de desarrolladores que entran y los que salen
<chilicuil> calmi: todas las actualizaciones que se hagan para Ubuntu llegaran a Linux Mint
<chilicuil> una de las cosas que quiero recalcar es que la participacion en Ubuntu se basa en los meritos y tipos de contribucion
<chilicuil> no importa para quien trabajes
<chilicuil> jincreator pregunta sobre la cantidad de hrs que invierten en Ubuntu todos los dias
<chilicuil> entre algunas de las cosas que hago es ser miembro del equipo del archivo, las personas que son parte de este grupo se encargan de verificar que los nuevos programas que se agregan son legales, tanto para Canonical como para Ubuntu, esto lo hago incluso cuando no trabajo y nunca lo he hecho para ellos
<chilicuil> chilicuil: la mayoria de ellos aun se encuentran activos, algunos un poco menos que antes, el trabajo y las ocupaciones de la vida pueden cambiar el tiempo que le inviertes a Ubuntu
<chilicuil> jincreator: varia mucho, por ejemplo durante esta semana he invertido menos de 2 hrs (incluyendo la hr que estoy ocupando aqui), otras semanas me la puedo pasar todo el dia
<chilicuil> bdrung agrega que el 1 hr a la semana para el DMB y entre 0 y 60 hrs durante la semana para correciones de paquetes
<chilicuil> algunas veces me la he pasado toda la noche, cuando algo no funciona y soy el unico disponible para solucionarlo
<chilicuil> bdrung agrega que en esta semana solo ha estado 1 hr (que esta precisamente) porque esta enfermo
<chilicuil> jincreator agradece las respuestas y espera que bdrung se recupere pronto
<chilicuil> con esto termina la sesion, y la semana del desarrollador
<chilicuil> gracias por haber leido, con esto termino y me despido
<chilicuil> los logs estaran disponibles en http://wiki.ubuntu.com/SemanaDesarrollador
<chilicuil> y los proximos eventos en https://wiki.ubuntu.com/Classroom_ES
<chilicuil> saludos o/
