JMTyton

Los code smells vienen a ser algo así como malas practicas a la hora de programar. Cosas que no están buenas hacer y que ensucian nuestro código. Probablemente el código compila y se ejecuta perfecto, pero se hace difícil de entender y de seguir. No hay ningún programa que lo hagamos totalmente solos por lo que es bueno mantener cierto orden en el código para que todo el que requiera usarlo lo pueda entender mas fácilmente. Un refactor es un cambio en el código, pero este cambio no agrega funcionalidad a lo que ya estaba, sino que se hace con el objetivo de ordenar las cosas y que sean mas entendibles. Son muy útiles para realizar rediseños. No es el objetivo del post hablar de refactores pero seguramente haga mención sobre ellos por lo que es importante saber que son. No, hay muchas cuestiones que entran en juego a la hora de decidir refactorizar. Sobre todo el criterio de cada uno. Probablemente estemos cortos de tiempos, como es muy normal que suceda, por lo que no seria bueno tocar código en un modulo que ya esta terminado y no vamos a volver a usar. También puede pasar que si nos tomamos un poco de tiempo arreglando el código el día de mañana nos ahorramos ese tiempo en entenderlo, o explicárselo a otra persona, o incluso puede ser mas fácil agregar funcionalidad sobre el nuevo código. También es importante saber que un método no se convierte en un long method al superar tantas lineas de código, sino que acá entra en juego un grado de subjetividad para decidir cuando estamos frente a un code smell. Un long method es un método que se extiende mas de lo necesario. No hay una formula mágica para reconocerlo, como dije antes no es un long method por superar las 10 lineas de código. Para mantener un método lo mas sencillo posible es bueno seguir estos 2 consejos. -Que el método haga una y solo una cosa -Que su nombre indique que hace y no como lo hace Los métodos que hacen varias cosas resultan mas complicados que los que realizan solo una, ¿parece obvio no? Pero no siempre resulta sencillo diferenciar una tarea de la otra porque pueden estar muy relacionadas entre si. Si tenemos un método que realiza 2 tareas es buena idea separarlos en 2 métodos distintos. Con respecto al nombre se puede decir que, si indica lo que esta haciendo en vez del como podemos abrir juego al polimorfismo, por ejemplo en vez de ponerle “buscarBinario” podemos llamarlo solo “buscar” y si mas adelante queremos implementar otro tipo de búsqueda como la secuencial las clases que implementen las búsquedas no deberían ser tocadas porque llamarían al método buscar. Cuando una clase se empieza a hacer muy extensa es síntoma que se esta convirtiendo en una god class. Por lo general tienen muchas variables de instancia y asumen responsabilidades que en realidad deberían estar delegadas en otra clase. Es normal caer en la god class para los que están dejando la programación estructurada para empezar con la orientada a objetos. En general las god class tienen estas características -Son difíciles de testear -Presenta conjuntos de métodos no relacionados que trabajan con distintas variables de instancia -Es difícil reutilizar debido a las variadas características que contempla -Hacer un cambio en la clase puede resultar dificultoso por no poder diferenciar las partes que son afectadas -Muchos de los cambios en el sistema repercuten en esta clase Para solucionarlo lo mas recomendable es buscar las variables de instancia que se relacionan y extraerlas en otra clase junto con todos los métodos que actúen sobre esas variables. Es importante que las nuevas clases tengan nombres que identifiquen bien que hacen y que responsabilidades tienen. De esta manera dividimos la god class en varias clases mas pequeñas con responsabilidades bien definidas. Es común ver como va creciendo la lista de parámetros de un método a medida que requerimos pasarle nuevos datos. Por lo general las clases que implementen este método deberían reunir todos los parámetros necesarios resultando en un código para nada lindo. Nos podemos encontrar con algo así. Tenemos un hotel, cuando una persona llega se debe registrar con su nombre, apellido, edad, dni, domicilio y habitación donde se va a hospedar class Hotel { void registrarPersona(nombre, apellido, edad, dni, domicilio, nroHabitacion); } y para invocarla haríamos algo así unHotel.registrarPersona(unaPersona.getnombre(), unaPersona.getApellido(), unaPersona.getEdad(), unaPersona.getDni(), unaPersona.getDomicilio(), nroHabitacion); Muchos de los datos son sacados de la misma persona. Por lo que podemos hacer algo como. Class Hotel { void registrarPersona(unaPersona, nroHabitacion); } No siempre es tan fácil de identificar la solución, hay que estudiar cada caso particular y ver el por que requiere tantos parámetros y de donde se obtienen. Este code smell se da cuando un método parece estar mas interesado en otra clase que a la que le pertenece. Nos deberíamos preguntar ¿El método esta en la clase correcta? Por lo general estos métodos usan muchos setters y getters de la otra clase. La solución mas sencilla es la de mover el método a la otra clase. También puede pasar que solo una parte del método sea la que debe ser movida a la otra clase. Una excepción a esta regla se da en los patrones de diseño strategy y visitor, no es el objetivo del post hablar sobre patrones de diseño, quizás mas adelante lo haga. Las data class son justamente clases que tiene unas cuantas variables de instancia y sus setters y getters, pero no presenta comportamiento propio. Esto se debe a una mala distribución de las responsabilidades de cada clase. Seguramente tenemos el comportamiento que le corresponde a esta clase distribuida entre las clases que la implementan. Esta fuertemente atada al Feature envy, ya que es un método de otra clase la que manipula los atributos de la data class. La solución es mover los métodos que usen los setters y getter injustificadamente a la clase que corresponde. También nos podemos encontrar con el caso de que sea solo una parte del método la que esta implicada por lo que deberíamos separarla del resto del método y luego moverla. Un message chain vendría a ser algo como esto. unaCosa.getXXX ().getYYY().getZZZ().hacerAlgo(); O sea partimos desde unaCosa le pedimos un atributo a este le pedimos otro y cuando llegamos al ultimo le mandamos el mensaje que realmente importa. Esto nos trae aparejado que todas las clases que intervienen terminan fuertemente acopladas a la estructura de navegación. Se pierde el encapsulamiento, porque a una clase no debería importarle como esta armada otra y viceversa. Lo mas seguro es que el comportamiento que queremos modelar corresponda a unaCosa de esa manera al llamar el mensaje quedaría algo así. UnaCosa.hacerAlgo(); y en el método hacerAlgo se delega a XXX la tarea. void hacerAlgo() { this.getXXX ().hacerAlgo(); } Y así hasta llegar a alguien que en realidad pueda completar la tarea. Parecería que la solución hace las cosas mas complicadas de lo que eran antes, pero hay que notar que si hacemos un cambio en la estructura de la clase no tendríamos que cambiar en todas las clases que lo implementen porque ahora las clases están menos acopladas. La regla de Demeter nos dice que una clase solo debería invocar métodos de: -si mismo (this, self) -de sus parametros -de cualquier objeto que él cree o instancie -de sus colaboradores directos La aparición de message chains son claras violaciones a la regla de Demeter. Casi todos los lenguajes de programación tienen tipos de datos primitivos. La primitive obsession es justamente abusar de estos tipos de datos primitivos. Es muy común para los que se están iniciando en el paradigma de objetos caer en este code smell. A veces es bueno representar, por ejemplo una clase Money que convine una cantidad y una moneda. Si en cambio usáramos los tipos de datos primitivos para esto nos veríamos en la obligación de repetir ciertos controles en todas las clases que requieran utilizar monedas. Otro ejemplo podría ser usar en una clase una colección, no es malo usar colecciones, pero por ejemplo si tenemos una serie de métodos a realizar sobre esa colección no es mala idea crear una nueva clase que contenga a la colección y delegar en ella todo el comportamiento que al manejo de la colección se refiera. El problema al realizar un switch o una serie de ifs es la duplicación. Es normal que tengamos que repetir el switch o los ifs en otra parte del programa y cuando tengamos que agregar una clausula al switch nos veríamos en un problema, ya que hay que buscar en todos los lugares donde se haga y agregarlo. Para solucionarlo la mejor herramienta que nos da el paradigma de objetos es el polimorfismo. Esto es porque la mayoría de las veces el swich esta hecho sobre un tipo de código. En general tendríamos que crear tantas clases como clausulas del switch que hereden de la misma el comportamiento común y que cada una redefina el método haciendo lo que le corresponde. También puede pasar que podemos delegar ese comportamiento en otra clase como sucede con el patrón strategy, pero como dije antes no es el objetivo del post hablar de patrones. A veces creamos una clase que en un principio tiene sentido, pero luego de unos refactors nos damos cuenta que perdió su responsabilidad porque tenemos otra clase que las adquirió. Lo mas común es que traslademos el comportamiento que quedo en la lazy class a la otra clase, no es bueno tener 2 clases con la misma responsabilidad. Este code smell aparece cuando nos planteamos “yo creo que tendríamos que abarcar este tipo de cuestiones por si se nos presentan el día de mañana” y así querer contemplar todos los casos posibles que puedan surgir y no son requeridas en este momento. Esto nos da un código mas complicado y difícil de mantener y si el día de mañana nos llega un nuevo requerimiento que no teníamos contemplado, porque es imposible contemplar todas las situaciones, nos veremos en un gran problema. Es simplemente cuando creamos una clase que hereda de otra cierto comportamiento que queremos reutilizar, pero también comportamiento que no requerimos. Lo mas fácil en estos casos es crear una clase hermana que tenga todo el comportamiento que no queremos que las otras hereden. Los comentarios muchas veces ayudan a explicar un poco mejor el código. Pero deberíamos preguntarnos ¿Por que es difícil de entender esta parte del código? En una de esas podemos detectar lo que buscamos y agrupando una parte del método en otro se vuelve mas entendible por lo que el comentario deja de tener sentido. Sin embargo hay muchas veces que comentar el código es la mejor salida. Para el final dejo el code smell que probablemente mas apesta, el código duplicado. Cuando nos encontramos con que repetimos la misma estructura de código en varias partes del código debemos pensar que estamos duplicando código y lo mejor es buscar una forma de unificarlo. Lo normal es que no sea exactamente el mismo método, hay que saber identificar la parte que se repite y separarla en un nuevo método para luego poder invocarlo desde donde sea requerido. Si el código se repite en varias clases es probable que tengamos que crear una clase nueva que tenga el comportamiento que se repite. O también podemos detectar que la parte repetida corresponde a una clase en particular y las otras deberían invocarlo. -Wikipedia http://en.wikipedia.org/wiki/Code_smell -Clases de técnicas avanzadas de programación (UTN-FRBA) -Experiencia personal

Buenas muchachos, les quiero presentar mi banda en la cual canto y toco las guitarras rítmicas. Pueden encontrar mas información y descargar nuestro material de nuestra pagina web www.alquimiahardrock.com.ar A futuro tenemos proyectado varias fechas por capital y alrededores. Un tributo a Ritchie Blackmore, junto a Arpeghy. Telonear a Rhapsody of fire en el teatro flores teniendo el honor de tocar unos temas con Hugo Bistolfi (tecladista de rata blanca). Y a fin de año entrar a grabar nuestro primer disco en los estudios de la nave de oseberg. Pueden descargar de nuestra pagina la preproducción de lo que va a ser el disco y que cuenta con la participación de Javier Yuchechen, ex Selidor, Ariadna Project, y que actualmente está trabajando nuevo material como solista. Alquimia es una banda oriunda de la ciudad de Zárate, Buenos Aires, que nace a fines del 2008. El estilo se define como Hard Rock y Power Metal Melódico, con influencias de grandes bandas como Deep Purple, Rainbow, Europe, Whitesnake, y Rata Blanca. Es formada por Juan Facundo Collado (Teclados), Nicolás Teti (Guitarra), Juan María Collado (Guitarra) y Matías Teti (Bajo) el 14 de septiembre de dicho año. Completa la formación el baterista Federico Delgado, quien luego terminaría abandonando la banda por cuestiones personales. A finales de 2009 Nicolas compone los primeros temas de la banda y surge la idea de grabar un disco demo para tener material que facilitara la idea de conseguir cantante. El demo consta de 5 temas, uno de ellos instrumental, y jamás fue publicado. En el transcurso de la grabación el grupo conoce a Damian González (baterísta), quien meses después se uniría al grupo. El 5 de Junio de 2010 el grupo entró a el estudio Bebop de la ciudad de Zárate a grabar su primer EP titulado Por el Sendero, el cual incluyó dos de los temas del demo inedito. Durante la grabación Damián abandonó la banda, y recomendó en su lugar a Norberto Cristaldo. El reconocido cantante Javier Yuchechen (Ariadna Project, Selidor, Skiltron) fue invitado a ser la voz del álbum. Por el Sendero fue publicado el 9 de Febrero de 2011 y al cabo de 5 días logró mas de 500 oyentes, recibiendo por parte de ellos excelentes críticas. Unos días antes del lanzamiento el grupo se reúne y acuerda que Norberto ya no seria más parte de este proyecto y que Juan María sería el cantante estable de la banda. Poco tiempo después Simon Carballo ya ocupaba la batería. Con esta formación, después de casi 3 años de ensayos, la banda se presenta por primera vez en vivo el 23 de Julio (de 2011) en CBGB (Capital de Buenos Aires). Con 1 disco editado en estudio, la agrupación fue invitada en reiteradas oportunidades para participar de diversos festivales de rock en la capital; compartiendo así, escenario con ex miembros de Rata Blanca, Temple y Mala medicina. Dos de las últimas presentaciones del 2011 fueron en Club M, para el concurso Jack in Black organizado por "dontpaymusic" (discográfica de Adrian Barilari), logrando así clasificar a la final (aún pendiente de llevarse a cabo). Actualmente se encuentra tocando en vivo presentando Por el Sendero y nuevos temas que formarán parte de su próximo material discográfico. Preproducción 2012 La preproducción es uno de los pasos mas importantes en la producción musical. Su objetivo es idear, organizar y estructurar lo que luego va a ser llamado disco. Preproducción 2012 es un material en calidad demo grabado de manera independiente que tiene como único fin compartir nuestra múscia y adelantar parte de nuestro próximo material discográfico a grabar en la nave de oseberg. Para mas información no olviden pasar por la web de la banda www.alquimiahardrock.com.ar. Un abrazo y que sea rock.

Intel y sus futuros ARM: mejor Linux que Windows 8 Curiosas las declaraciones de una de las directivas de Intel -quizá tenga que realizar una aclaración en los próximos días- en las que parece dejar claro que Linux será una apuesta mucho más segura que Windows 8 a la hora de utilizar sus futuros chips SoC basados en la arquitectura ARM. Lo cuentan nuestros compañeros de MuyComputer, que señalan que el futuro sistema operativo de Microsoft, que se lanzará en cuatro versiones distintas, podría dar problemas en su versión para ARM a la hora de funcionar con aplicaciones anteriores. Eso haría que Linux se convirtiese en un potente aliado de las soluciones de Intel basadas en la arquitectura ARM, un mercado que el gigante de los semiconductores quiere tratar de incorporar a su amplio catálogo para competir con más garantías en el segmento de los dispositivos móviles. También hubo declaraciones a favor de Android, otra de las plataformas clave según Intel y que como todos sabemos tiene sus raíces también en el kernel Linux. Fuente: http://www.muylinux.com/2011/05/19/intel-y-sus-futuros-arm-mejor-linux-que-windows-8/

¿Que es ID3? ID3 es un estándar para agregar metadatos a los archivos. Es muy común en los mp3. Los metadatos sirven para agregar información al archivo, como el nombre del artista, álbum, numero de pista en el álbum, ect. Es muy útil cuando se tienen grandes colecciones para poder facilitar búsquedas por varios campos, por ejemplo por genero, artista, año, ect. Hay 2 formatos principales: -ID3v1: Es el primer formato que se creo. Para incluirlas se agrega un bloque de 128 bytes al final del archivo. Incluye las siguientes etiquetas. Una cabecera que identifica la presencia del bloque ID3 y su versión. Titulo: 30 caracteres. Artista: 30 caracteres. Álbum: 30 caracteres. Año: 4 caracteres. Un comentario: 30 caracteres. Genero musical: 1 carácter. Una de las desventajas de este modelo es que no permite el numero de pista. Por eso en la versión 1.1 se usan los 2 últimos caracteres para ese fin. Para distinguirlo de la versión 1.0 el carácter 29 tiene que ser un carácter nulo y el 30 almacena el numero de pista en formato byte. Si el carácter 30 es nulo y el 29 no lo es se presupone no especificado. -ID3v2: A pesar de ser suficiente en muchos casos, la versión 1.x presenta algunos problemas. Las longitudes de las etiquetas resultan insuficientes para algunas grabaciones. El uso de caracteres ASCII no permite el uso de lenguas no occidentales. El conjunto de etiquetas es insuficiente. Estamos atados a esas 6 etiquetas solamente, por lo que si queremos agregar compositor, obre, o hasta una imagen para la portada del álbum no podemos. No podemos agregar etiquetas no predefinidas. Por eso la versión 2 incluye las siguientes características. Utiliza caracteres Unicode, por lo que esta abierto a cualquier lengua. Las etiquetas se sitúan al principio del archivo. Por lo que facilita la difusión por internet mediante streaming, ya que no hay que terminar de descargar todo el archivo para saber las etiquetas. Las etiquetas son de longitud variable. Es posible incluir imágenes. Admite etiquetas definidas por el usuario. Tiene predefinidas más de 35 etiquetas. La letra de la canción se puede almacenar bajo e frame Lyrics3 en la TagID3, al igual que la portada del álbum. Las etiquetas pueden ser cifradas. Como modificarlas Ahora que ya está hecha la introducción al tema de las etiquetas ID3 vamos a lo importante como modificarlas. Hay muchas herramientas gráficas que facilitan la tarea como easytag. Pero yo me voy a centrar en las de linea de comandos. El hecho de que así sea es que tiene varias ventajas como poder hacer un script que luego automatice la edición. Empecemos por la mas sencilla id3. Para los usuarios de una distribución basada en Debian se instala con el clásico. sudo apt-get install id3 Esta herramienta solo trabaja con id3v1.1 La sinopsis es id3 -l file1 [file2 [file3...]] Los [ ] nos dicen que son opcionales, osea que podemos poner una lista de archivos de la longitud que queramos. El comando nos permite ver todas las etiquetas actuales de los archivos en cuestión. También podemos poner “id3 -l *.mp3” y así vemos las etiquetas de todos los archivos que terminen en .mp3. Se pueden hacer mas combinaciones pero no es el objetivo del post. Los que ya tengan experiencia en la consola van a saber darse cuenta. Algo interesante es agregarle un -R de la manera siguiente. id3 -R -l file1 [file2 [file3...]] De esta manera nos va a mostrar la salida de una forma mas ordenada que a mi me gusta mas, porque los distintos archivos quedan mejor separados. id3 -d file1 [file2 [file3...]] Ese comando nos sirve para eliminar todas las etiquetas de los archivos. También se puede usar con el *.mp3 como se comento para el anterior. id3 -L Este comando nos lista todos los géneros musicales disponibles y el numero que le corresponde. Y el mas importante id3 [-tTaAycg newdata] file1 [file2 [file3...]] El [-tTaAycg newdata] lo tenemos que remplazar por un identificador de la etiqueta que queremos modificar y el nuevo valor. Por ejemplo id3 -a Rainbow *.mp3 Si, estoy escuchando Rainbow, jaja. Volviendo al tema de esa manera modificamos la etiqueta artist por Rainbow. Si el artista tiene un nombre compuesto por varias palabras tenemos que ponerlo entre “ ”. Por ejemplo id3 -a “Deep Purple” *.mp3 También podemos agregar un -R para que el resultado se nos muestre como comentamos antes o editar varias etiquetas de una misma ves. id3 -R -a Rainbow -A “Difficult to cure” -y 1981 -g 79 *.mp3 Así editamos todo un álbum completo. El 79 es el genero Hard Rock. También podríamos haber puesto “Hard Rock”, pero si ponemos un genero que no esta predefinido no lo va a reconocer. Las etiquetas que podemos modificar y los código son: -t → titulo -T → track -a → artista -A → álbum -y → año -c → comentario -g → género Para terminar con el id3 quiero recordar que con -h se puede tener ayuda sobre el comando y si hace falta ampliar consultar el man id3 -h man id3 Ahora voy a explicar el id3v2 que es mas complejo y soporta tanto etiquetas id3v1 como id3v2. No me voy a detener a explicar muchas cosas ya que funcionan igual que con id3. Para instalar en los sistemas derivados de Debian basta con hacer sudo apt-get -install id3v2 La sinopsis es id3v2 [OPTION] [FILE] y las opciones soportadas son -h, --help → Muestra la ayuda. -f, --list-frames → Hace una lista de los frames, o tipos de etiquetas, predefinidas para id3v2. -L, --list-generes → Hace la lista de géneros para id3v1. -v, --version → Muestra la información de la versión. -l, --list → Muestra las etiquetas de los archivos. -R, --list-rfc882 → Muestra los resultados con el orden visto para id3 -d, --delete-v2 → Elimina todas las etiquetas id3v2 -s, --delete-v1 → Elimina todas las etiquetas id3v1 -D, --delete-all → Elimina todas las etiquetas, tanto id3v1 como id3v2 -C, --convert → Convierte las etiquetas id3v1 en id3v2. No borra las id3v1. -a, --artist ARTIST → Modifica la etiqueta artist por ARTIST. -A, --album ALBUM → Modifica la etiqueta album. -t, --song SONG → Modifica el titulo de la cancion. -c, --comment DESCRIPTION:COMENT → Modifica el comentario. -g, --genere num → Modifica el genero. -y, --year → Modifica el año. -T, --track num/num → Modifica el numero de pista. El /num es opcional, en lo personal no me gusta ponerlo. Para editar otras etiquetas basta con hacer id3v2 –FRAM newdata file.mp3 Donde el --FRAM se tiene que cambiar por el identificador del frame que se consultan haciendo id3v2 -f como se dijo anteriormente. Como regla son todos de 4 caracteres en mayúscula. Bueno eso es todo por hoy. Espero que sea de su agrado y cualquier duda pregunten.

Navegando por una de las paginas linuxeras que visito a diario, para enterarme de lo nuevo en soft libre, me encontré con este articulo que esta interesante. http://www.muylinux.com/2011/04/27/%C2%BFpor-que-usamos-linux/ El tema es que estaba en ingles así que me tome la molestia de traducirlo. Le decimos a la gente que usamos linux porque es seguro. O porque es gratis, porque es personalizable, porque es libre (de otra manera*), porque tiene un excelente soporte de la comunidad... Pero todo eso son solo tonterías marketineras. Se lo decimos a los no linuxeros porque ellos no entenderían la verdadera razón. Y cuando decimos esas falsas razones, incluso podríamos llegar a creerlas. Pero bien en el fondo, la verdadera razón permanece. Usamos linux porque es divertido. Es divertido jugar con el sistema. Es divertido cambiar todas las configuraciones, romper el sistema, tener que ir al modo de recuperación para repararlo. Es divertido tener mas de un centenar de distros para elegir. Es divertido usar la linea de comandos. Déjenme decirlo de nuevo. Es divertido usar la linea de comandos. No es de extrañar que los no linuxeros no entiendan. El punto con los fans de linux es que usamos linux por nuestro propio bien. Seguro que nos gusta hacer el trabajo. Seguro que nos gusta estar seguros contra virus. Seguro que nos gusta cuidar nuestro bolsillo. Pero esos son solo los efectos secundarios. Lo que realmente nos gusta es jugar con el sistema, explorarlo, y descubrir los hechos fascinantes sobre el software que se encuentra dentro nuestro. *Lo dice porque en ingles repite 2 veces free, una vez para referir a lo gratis y otra vez para referir a lo libre. Bueno eso es todo, y si no les gusto la traducción quédense con la de google traductor que pone cualquier cosa. Para mi tiene toda la razón, ¿ustedes que opinan? Absténganse de hablar del sistema de las ventanas.

Gracias a todos por el top, prometo que el lunes que viene subo las novedades y el progreso del proyecto. ¿Que es Open Tablature Editor? Open Tablature Editor es una aplicación que actualmente estoy desarrollando, con python + gtk, con el objetivo de brindar una versión libre del famoso guitar pro. Mi idea es publicarlo bajo licencia GPL, para que cualquiera pueda usarlo, estudiarlo, modificarlo y redistribuirlo a gusto, como una buena aplicación libre. ¿Por que no tuxguitar? En principio empece este proyecto porque tuxguitar no terminaba de adaptarse a lo que yo necesitaba. En su momento pensé hacer un fork de tuxguitar, que su ultima versión fue lanzada en el 2009, y que creo que los desarrolladores perdieron interés en el proyecto. Pero cuando empece a estudiar el código vi muchas cosas que no me gustaron y que iba a tener que reescribir. Entonces aproveche y también lo hice en un lenguaje que me sentara mas cómodo. Algunas cosas se transcribieron de manera casi idéntica y en otras cambie el diseño de manera de que sea mas ágil, simple, y menos redundante. Una de las cosas principales que se tomo fue el algoritmo para abrir archivos de guitar pro. ¿Por que Python? Como mencione antes, es un lenguaje que me resulta muy cómodo para escribir código. La sintaxis es muy limpia y fácil de seguir. Permite cosas como tipado dinámico, que es algo muy interesante. También me permite portabilidad entre sistemas operativos. ¿Por que gtk? Básicamente porque soy fanático de gnome. Aunque por otro lado también me permite cierta portabilidad entre sistemas, ¿de que sirve buscar portabilidad en un lenguaje si la librería que usas no la tiene? ¿Por que GPL? Principalmente para compartir y aportar mi granito de arena al soft libre. No me quiero detener en esto, los que entiendan el soft libre van a saber bien. ¿Quien soy? Yo estudio en la UTN-FRBA, actualmente estoy cursando analisis matematico II, ingles II (debido a la falta de materias para cursar por mi atraso en la rama de las matemáticas la curso y no la doy libre) y Administración de recursos. El viernes pasado di el final de sistemas operativos y me saque un 7, algunos sabrán lo complicado de esa materia, tanto en cursada como en final. Mi objetivo es este año terminar con las materias de 2do y 3ro que me quedaron para el año que viene ir por lo que falta de 4to. Curse de electiva técnicas avanzadas de programación, donde aprendí cosas muy interesantes como patrones de diseño, code smells (tengo un post que habla de eso, a los que programen en objetos les puede ser util), y tecnologías como svn, git, java, ect, ect, ect. ¿Cual es el estado actual del proyecto? Actualmente estoy trabajando en la presentación de las tablaturas y distintas cosas de la interfaz gráfica. El programa puede abrir archivos gp3 y buena parte de la intefaz esta quedando bastante bien. ¿Cuando es el lanzamiento? Pretendo que el lanzamiento se haga el 01/07, así que estoy trabajando duro para que así sea. ¿Cuales son los planes a futuro? Luego del primer lanzamiento, la idea es entrar de lleno en lo que es la edición de las partituras. No quiero decir que el resto de las cosas va a quedar igual, sino que siempre se va tocando por todos lados y se vuelve sobre los pasos para que el proyecto crezca en distintas direcciones. Mas adelante incluir la posibilidad de reproducir las partituras con la ayuda de un sintetizador midi por software, la posibilidad de imprimir, y por ultimo me gustaría crear una especie de repositorio de partituras donde sea mas fácil descargarlas y compartirlas. Esperemos que el proyecto llegue tan lejos para ver esas cosas hechas realidad. ¿Para que sistemas va a estar disponible? Mi idea es que pueda ser utilizado tanto en linux como en windows, así que para el lanzamiento espero poder hacer un instalador para windows y también los paquetes deb, y rpm para las principales distribuciones linux. Obviamente también va a estar disponible el código, de manera que cualquiera con un interprete de python lo va a poder correr. Por ultimo les dejo una imagen para que vean como va quedando la cosa Novedades 06/06/2011