Source: http://dottonetto.com/home/
Timestamp: 2013-05-18 15:58:01+00:00

Document:
por ajaest In the server side:
&#91;system@pc&#93;$ nc -v -l 10000  | gzip -d &gt; output.file
Some details about the arguments and tools:
nc: the BSD netcat tool implementation. There exists a GNU implementation often refered as gnu-netcat or netcat-traditional that can be launched either using the nc command or the netcat one.
-l: listen to incoming TCP transmissions by default bounded to the default localhost hostname. A bounding hostname can be specified after the port number
-v: verbose output through stderr output stream
10000: the listening port
gzip -d: the gunzip compressor, the option -d sets it in decompressing mode. Since it has no more arguments, the compressed stream is extracted from the pipe and sink to the stdout stream.
> output.file: redirects stdout stream to the file output.file in current working directory.
Then in the client side:
&#91;system@pc&#93;$ cat file.input | gzip | nc -v -w 30 myserver.domain.net 10000
About non previously commented arguments and commands:
cat file.input |: display file.input content through the standard output stream and redirect it throug pipe.
gzip |: without commands, compress data stream received from pipe and displays it through the standard output stream. It then redirects this output through pipe.
| nc -v: transmits raw TCP packages generated from content received from pipe and display verbosed information.
-w 30: timeout. If the pipe input stream is idle for more than 30 seconds or no connection can be established in that time the process is terminated. If no value is specified, there’s no timeout.
myserver.domain.net 10000: the destination host name or IP address is myserver.domain.net and the listening port is 10000
por ajaest The Carcaj Project Logo
Not, this is not yet a detailed explanation of what exactly is going to be the Carcaj Project (that will come in the follwing posts). I know that the project description is a bit confusing and not very specific, but we’re still at the preliminary stages of the project and in order to explain it properly I’d like to use very concrete examples that can be based on the first sketch of the system architecture. For now, please feel satisfied with the brief and original project description:
Carcaj will be an application-oriented NodeJS web framework focused in the development of application portals, i.e., web pages that contains very different utilities framed under the same user interface which share resources and code.
There is room for experimentation there, so the project will be guided by the objective of building a web portal with some very different small applications, with an special focus in testing different architectures and API designs.
On the other hand, this post is intended to summarize the main infrastructure and tools that will be used to track the Carcaj Project. I’ll try to briefly introduce all the resources and technologies that will be used as well as link it to theirs URLs. So, there we go:
The Carcaj Project TRAC system - http://project.ajaest.net/carcaj/ - https://project.ajaest.net/carcaj/
This will be the main project webpage, containing the documentation wiki, project organization documentation, ticketing system and and source code browse system. It’s based on the well known Trac system.
The Carcaj Project GIT repository - http://git.rep.ajaest.net/carcaj - https://git.rep.ajaest.net/carcaj
The source code control version system will be Git, almost all branches will be open since the begining for free cloning in a yet-to-deploy SSHed or HTTPSed system, what means that the links above are not up yet. The repo is already working but I have to configure a secure cloning edge point, so in the meanwhile you can browse or download the source code from the Trac portal’s “Browse Source” Tab.
The Carcaj Project Blog and Feed - http://dottonetto.com/home/category/carcaj/
In the blog I’ll mainly post large articles of heavy updates of the project, as well as specially relevant entries of the Trac’s portal Wiki. The URL above is really the “Carcaj” tag category reference of my personal blog Dottonetto in Spanish, but all Carcaj entries documentation and posts will be in English.
The Carcaj Project Twitter account - https://twitter.com/CarcajProject
In the twitter account I’ll publish any comment or deviation that crosses my mind related in even distant ways with the Carcaj Project, as well as references to the blog entries or updates related to the project or the technologies that it uses. It’s intended to become the most straightforward way to be up-to-date with the project status, and the main channel to get non-technical feedback about the project.
So, this it’s all. In following post I’ll try to explain more deeply about the objectives of the project, roadmapping and some preliminary technical information.See you!
Etiquetas: app, application, carcaj, git, nodejs, platform, project, The Carcaj Project, trac, web
por ajaest La guía oficial de la Gnome Foundation es un muy buen punto de partida para cualquier desarrollador que quiera introducirse en el mundo de Gnome/GTK+ en C++, pero no existe una versión oficial en formato ebook o PDF. Generalmente no suele pasar mucho tiempo hasta que alguien hace el trabajo de maquetarlo correctamente, pero esta vez no he sido capaz de encontrar ninguna versión en condiciones de la guía de programación oficial de gtkmm para poder pasármela al tablet, así que he acabado haciendo mi propia versión. Podéis descargárosla desde el siguiente link:
Programming with gtkmm 3 (PDF)
por ajaest Cuando empecé a investigar sobre las herramientas de desarrollo para Gnome me topé con el nombre de Anjuta varias veces. Anjuta es el IDE oficial del proyecto Gnome, ofrece un soporte sólido para el desarollo de programas GTK mediante los lenguajes de programación C y sus bindings para C++, Java, JavaScript y Vala.
La verdad es que el aspecto de la herramienta es bueno, incluye hasta un diseñador de interfaces WYSIWYG, pero receloso como soy de duplicar el conocimiento, me mostraba reticente a tener que aprender a usar una nuevo entorno de desarollo. Por ello y antes de ponerme manos a la obra, me propuse investigar si existía alguna forma de usar una herramienta que era por mí de sobra conocida: el IDE Eclipse.
Eclipse era originalmente un IDE destinado principalmente al desarrollo de aplicaciones Java, pero con el paso del tiempo fue ganando soporte para otros idiomas a través de plugins y builds específicos. Para C/C++ en particular, existe el plugin CDT, que añade soporte básico para compilación, enlazado, debugging, resaltado y autocompletado para este lenguaje. Configurar CDT y compilar usando la librería estándar de C/C++ es bastante fácil, sin embargo no se puede decir lo mismo del proceso para añadir soporte a librerías externas/no estándar como GTK, sobre todo para un novato como yo. La información que existe en internet sobre el tema es difusa y en muchos aspectos inexacta, y la interfaz de configuración de Eclipse no ayuda demasiado.
Es por ello que he decidido redactar este tutorial paso a paso sobre como configurar Eclipse para desarrollar en C++/GTK. No soy un experto, así que agradeceré cualquier corrección o experiencia que pueda añadir exactitud al proceso.
Parto de una distribución Linux-Fedora 16 de 64 bits, con Eclipse para Java instalado. Las instrucciones para la instalación de paquetes serán las propias para este sistema operativo, así que tendrás que buscar el nombre del paquete correspondiente si usas otro. Si añades los comandos de tu distribución en los comentarios para instalar cada uno de los paquetes que aparecen en este tutorial gustoso los añadiré junto a los de Fedora.
Instalando soporte para C++/GTK
Primero, tenemos que instalar el compilador de C++. Para Fedora, podemos usar el comando de consola:
yum instal gcc-c++
Las librería GTK, así como las librerías de Gnome fueron diseñadas para C99, lo que significa el soporte para otros lenguajes se hace mediante bindings. En particular, el binding de GTK para C++ se llama gtkmm. En principio, instalar gtkmm debería ser suficiente para instalar como dependencia las librerías necesarias para desarrollar en GTK. El comando para Fedora sería:
yum install gtkmm30
Instalamos también las librerías de desarollo de gtkmm. Técnicamente, instalar las librerías de desarrollo debería resolver las dependencias necesarias para instalar gtkmm.
Técnicamente, el sistema está listo para compilar.
Instalando Eclipse y el plugin CDT
Hay que instalar el plugin CDT para añadir soporte para C/C++ a eclipse. El comando en Fedora sería
Si no tienes instalado Eclipse, la resolución de dependencias de esta del paquete lo instalará también.
Creando un proyecto y activando el entorno de desarollo para C++/GTK
Arrancamos Eclipse, abrimos el menú contextual desde el explorador de proyectos, seleccionamos “New Project” > “C++ Project”.
Creando un nuevo proyecto en C++
Vamos a crear una carpeta de código fuente y a incluir un fichero de C++ con un ejemplo muy simple de ventana en GTK para Gnome 3. Al final usaremos este código, en las primeras imágenes hemos usado una versión más corta para probar el autocompletado más tarde:
Gtk::Main kit&#40;argc, argv&#41;;
Gtk::Button button&#40;&quot;Hello World&quot;&#41;;
window.add&#40;button&#41;;
button.show&#40;&#41;;
Gtk::Main::run&#40;window&#41;;
Como se puede ver en la imagen, Eclipse no reconoce ni las cabeceras ni las instrucciones de gtkmm.
Eclipse marca la semántica de gtkmm no reconocida
El primer paso será hacer que Eclipse reconozca la semántica y el autocompletado de código para gtkmm. Para ello, tenemos que indicarle a Eclipse en qué directorio puede encontrar los archivos de cabecera y las definiciones de funciones y símbolos necesarios. En el explorador de proyectos de Eclipse, pulsamos el botón derecho sobre el nombre del proyecto y elegimos la opción “Properties” del menú contextual.
A continuación navegamos a través de las opciones de la barra lateral hasta alcanzar las opciones de construcción del proyecto(C/C++ Build ->Settings->GCC C++ Compiler->Includes). Usando el botón de añadir, añadimos el directorio donde se encuentran las cabeceras de gtkmm en nuestro sistema operativo. En Fedora 16, ese directorio se encuentra en la ruta /usr/include/gtkmm.
Incluyendo los archivos de cabecera de gtkmm para habilitar el autocompletado y el reconocimiento de sintaxis
Configurando el compilador
Mediante la combinación de teclas CTRL+B le indicaremos a Eclipse que compile y enlace los archivos binarios a partir del código fuente. En el estado actual, Eclipse no será capaz de compilar porque pese a poder resolver los símbolos específicos de gtkmm, no será capaz de resolver las referencias a otros símbolos dentro de gtkmm.h, así como enlazar los archivos binarios de objetos donde se implementa la funcionalidad de GTK. Para ayudarnos a configurar de manera rápida el compilador y la localización en el sistema de archivos de las dependencias viene en nuestra la herramienta pkg-config.
Resolviendo dependencias de una manera rápida y sencilla con pkg-config
Lo que viene a continuación es una pequeña explicación de como funciona pkg-config. Si ya sabes como funciona, o te da igual mientras funcione, pasa al siguiente apartado
pkg-config es, a grosso modo y entre otras cosas, una herramienta de configuración y resolución de dependencias. Permite a través de una cadena que representa una librería o recurso obtener una cadena de texto preformateada según el estandar de argumentos de entrada de gcc que contiene las definiciones necesarias para poder compilar el recurso especificado.
Un ejemplo es la mejor manera entender como funciona. Si ejecutamos el siguiente comando desde la consola:
&#91;user@laptop&#93;$ pkg-config --libs --cflags gtkmm-3.0
-DGSEAL_ENABLE -pthread -I/usr/include/gtkmm-3.0 -I/usr/lib64/gtkmm-3.0/include -I/usr/include/atkmm-1.6 -I/usr/include/giomm-2.4 -I/usr/lib64/giomm-2.4/include -I/usr/include/pangomm-1.4 -I/usr/lib64/pangomm-1.4/include -I/usr/include/gtk-3.0 -I/usr/include/cairomm-1.0 -I/usr/lib64/cairomm-1.0/include -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/gtk-3.0/unix-print -I/usr/include/gdkmm-3.0 -I/usr/lib64/gdkmm-3.0/include -I/usr/include/atk-1.0 -I/usr/include/glibmm-2.4 -I/usr/lib64/glibmm-2.4/include -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/sigc++-2.0 -I/usr/lib64/sigc++-2.0/include -I/usr/include/pango-1.0 -I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng12  -pthread -lgtkmm-3.0 -latkmm-1.6 -lgdkmm-3.0 -lgiomm-2.4 -lpangomm-1.4 -lgtk-3 -lglibmm-2.4 -lcairomm-1.0 -lgdk-3 -latk-1.0 -lgio-2.0 -lpangoft2-1.0 -lpangocairo-1.0 -lgdk_pixbuf-2.0 -lcairo-gobject -lpango-1.0 -lfreetype -lfontconfig -lgmodule-2.0 -lcairo -lsigc-2.0 -lgobject-2.0 -lgthread-2.0 -lrt -lglib-2.0
&#91;user@laptop&#93;$ _
La linea de retorno de la instrucción(la segunda), sería la lista de argumentos que habría que pasarle al compilador para que pueda resolver las dependencias de un archivo de código fuente que use cualquier recurso de gtkmm versión 3.0.
Como puede verse, mediante el argumento de compilador -I se incluyen los directorios donde se encuentran las cabeceras y archivos de objetos, dependientes del sistema operativo y la configuración local del usuario. Quizás os suene la importación -I/usr/include/gtkmm-3.0, que especifica el directorio que hemos usado antes para activar el autocompletado en Eclipse. También es interesante ver que especifica las opciones -lgkt-3 -lgtkmm-3.0, que mediante la opción -l de gcc especifica que se va a usar la librería gtkmmm para el enlazado.
En esta llamada a pkg-config hemos usado tres argumentos:
--cflags: ordena a pkg-config que devuelva en la cadena todos los argumentos que el compilador necesitaría para poder compilar(ojo, no enlazar) un código fuente que contenga referencia a recursos y símbolos agrupados en el paquete de nombre especificado.
--libs: ordena a pkg-config que devuelva en la cadena todos los argumentos que el enlazador necesitaría para poder enlazar código fuente y objetos que contengan referencias a recursos y símbolos agrupados en el paquete de nombre especificado.
gtkmm-3.0: es el nombre del recurso, también llamado paquete, para el cual se quieren obtener las dependencias. Los paquetes con las definiciones de dependencias normalmente se instalan automáticamente cuando instalamos el paquete de desarrollo concreto mediante el gestor de paquetes de nuestro sistema operativo. Por ejemplo, cuando antes hicimos:
en alguna parte del sistema de archivos se instaló un archivo llamado “gtkmm-3.0.pc” que contenía las definiciones de dependencias para gtkmm.
Aparte del paquete que hemos usado para gtkmm versión 3, existen otros paquetes como gtk+3.0 o zlib. Por poner un ejemplo, considerando la instalación de mi sistema operativo similar a la de cualquier programador, más de 120 paquetes de resolución de dependencias están instalados. Las definiciones de paquetes instaladas en el sistema operativo pueden mostrarse ejecutando el siguiente comando:
También existen paquetes de dependencias para versiones antiguas y para compilado multiplataforma. Si hubiésemos querido obtener las dependecias para gtkmm 2.4 en vez de la 3.0, nos hubiera bastado con cambiar el nombre del paquete a gtkmm+2.4.
Llegados a este punto, la potencia de pkg-config viene de la combinación de esta orden con la sintaxis específica de bash. Una sentencia que contenga otra sentencia en la misma línea encerrada entre comas francesas 「`」 se ejecutará sustituyendo el contenido de las comas por la cadena de salida de la sentencia entre comas. Un ejemplo:
&#91;user@laptop&#93;$ echo &quot;Esto está fuera de las comas francesas`echo &quot;'Y esto está dentro de las comas'&quot;`&quot;
&quot;Esto está fuera de las comas francesas 'Y esto está dentro de las comas'&quot;
La utilidad de esta funcionalidad se demuestra al permitirnos combinar gcc y pkg-config de la siguiente manera:
&#91;user@laptop&#93;$ g++ main.cpp -o main.bin `pkg-config --libs --cflags gtkmm-3.0`
Podemos saber cuál es realmente el comando ejecutado usando echo de la siguiente manera:
&#91;user@laptop&#93;$ echo &quot;g++ main.cpp -o main.bin `pkg-config --libs --cflags gtkmm-3.0`&quot;
&quot;g++ main.cpp -o main.bin -DGSEAL_ENABLE -pthread -I/usr/include/gtkmm-3.0 -I/usr/lib64/gtkmm-3.0/include -I/usr/include/atkmm-1.6 -I/usr/include/giomm-2.4 -I/usr/lib64/giomm-2.4/include -I/usr/include/pangomm-1.4 -I/usr/lib64/pangomm-1.4/include -I/usr/include/gtk-3.0 -I/usr/include/cairomm-1.0 -I/usr/lib64/cairomm-1.0/include -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/gtk-3.0/unix-print -I/usr/include/gdkmm-3.0 -I/usr/lib64/gdkmm-3.0/include -I/usr/include/atk-1.0 -I/usr/include/glibmm-2.4 -I/usr/lib64/glibmm-2.4/include -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/sigc++-2.0 -I/usr/lib64/sigc++-2.0/include -I/usr/include/pango-1.0 -I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng12  -pthread -lgtkmm-3.0 -latkmm-1.6 -lgdkmm-3.0 -lgiomm-2.4 -lpangomm-1.4 -lgtk-3 -lglibmm-2.4 -lcairomm-1.0 -lgdk-3 -latk-1.0 -lgio-2.0 -lpangoft2-1.0 -lpangocairo-1.0 -lgdk_pixbuf-2.0 -lcairo-gobject -lpango-1.0 -lfreetype -lfontconfig -lgmodule-2.0 -lcairo -lsigc-2.0 -lgobject-2.0 -lgthread-2.0 -lrt -lglib-2.0&quot;
Se ve el resultado, ¿No? La sentencia anterior compila el archivo main.cpp y expande la orden pkg-config de tal forma que añade al final de la sentencia todas los argumentos necesarios para resolver cualquier dependencia necesaria para gtkmm. Esta instrucción con esta sintaxis tan elegante soluciona de una tacada la mayoría de los problemas de compilación dependiente del entorno y nos va a servir ahora para finiquitar la configuración de compilación de Eclipse de una manera rápida y sencilla.
Resolviendo dependencias en Eclipse usando pkg-config
Finalmente, vamos a lograr compilar el programa anterior añadiendo la sentencia pkg-config a la configuración de montaje de Eclipse. Abrimos el menú de configuración del proyecto pulsando el botón derecho sobre el nombre del proyecto y seleccionamos “Properties/Propiedades”.
Primero configuramos el compilador para añadirle dependencias. Seleccionamos “C/C++ Build ->Settings->GCC C++ Compiler->Miscellaneous” y en el campo de texto “Other flags” añadimos el siguiente token:
`pkg-config --cflags gtkmm-3.0`
Atención con las comas francesas 「`」, son importantes. Consulta el apartado “Resolviendo dependencias de una manera rápida y sencilla con pkg-config” para más información.
Configurando la resolución de dependencias en el compilador de eclipse con pkg-config
A continuación vamos a configurar el enlazador. Seleccionamos también desde el menú propiedades del proyecto ”C/C++ Build ->Settings->GCC C++ Linker->Miscellaneous” y en el campo de texto “Linker flags” añadimos el siguiente token:
`pkg-config --libs gtkmm-3.0`
Configurando la resolución de dependencias en el enlazador de Eclipse con pkg-config
Técnicamente está listo para construir el proyecto. Lo que hemos hecho es indicar a Eclipse que añada las sentencias de resolución de dependencias al final de la instrucción que usa para llamar al gcc.
Compilando…¡Hola Mundo!
En Eclipse-CDT podemos configurar varias configuraciones de compilación personalizadas. Por defecto, Eclipse añade a todos los proyectos nuevos las configuraciones “Debug” y “Release”, aplica la primera por defecto. Toda la configuración que hemos hecho hasta ahora se ha aplicado a la configuración de “Debug”, así que si en este momento compilar mediante “Release” obtendremos el mismo resultado que al principio. Habría que reconfigurar de nuevo “Release” o cualquier nueva configuración de manera análoga a lo hecho anteriormente para hacerlo funcionar.
Si pulsamos CTRL+B construiremos el proyecto usando la configuración por defecto “Debug”. La salida por consola debería ser algo parecido a los siguiente:
**** Build of configuration Debug for project Hola_Mundo ****
g++ -I/usr/include/gtkmm-3.0 -O0 -g3 -Wall -c -fmessage-length=0 `pkg-config --cflags gtkmm-3.0` -MMD -MP -MF&quot;src/main.d&quot; -MT&quot;src/main.d&quot; -o &quot;src/main.o&quot; &quot;../src/main.cpp&quot;
Building target: Hola_Mundo
g++ `pkg-config --libs gtkmm-3.0` -o &quot;Hola_Mundo&quot;  ./src/main.o
Finished building target: Hola_Mundo
Eclipse genera una carpeta con el nombre de la configuración en la cual crea todos los archivos necesarios para construir el proyecto basándose en la configuración de construcción de éste. Por ejemplo, para la configuración “Debug” creará una carpeta de mismo nombre en la raíz del proyecto conteniendo el código objeto, una estructura de makefile, el binario,etc..
La carpeta "Debug" y todo su contenido fueron autogenerados después de construir el proyecto
Ninguno de los archivos autogenerados al construir el proyecto debe ser modificado manualmente. Eclipse reescribe todos los archivos cada vez que se le ordena construir el proyecto, así que todos los cambios se perderán. Si quieres editar alguna de las configuraciones, por ejemplo la del makefile, tendrás que hacerlo cambiando el campo correspondiente en las opciones del proyecto.
Si pulsamos CTRL+F11 ordenaremos a Eclipse arrancar la última versión construida del proyecto. ¡Hola Mundo!
por ajaest Tan fácil como instalar el paquete “sendmail” y hacer lo siguiente:
user@user:~$ echo &quot;
To: destinatario@dominio.com
From: remitente@dominio.com
Subject: Este es el asunto
En la siguiente línea va el contenido del mensaje
&quot; | sendmail destinatario@dominio.com
Atención con las comillas, una comilla abierta en bash te permite seguir escribiendo en la siguiente línea.
por ajaest La obra de Haruki Murakami rebosa de pequeñas conversaciones de gran valor entre sus personajes. En la conversación a continuación participan dos personas, Watanabe y Nagasawa.
Watanabe, el narrador, se considera a sí mismo la persona más corriente del mundo. La vida no tiene especial interés para él, pero sin embargo no es un ser depresivo. Se limita a dejarse llevar por las corrientes de la vida, observando la extrañeza del mundo desde la posición privilegiada de aquel que no tiene especial interés por nada,.
El otro interlocutor, Nagasawa, es de aquel tipo de personas que puede con todo. Cualquier cosa complicada parece sencilla si él lo realiza. Esto le lleva a acaparar siempre todo lo que esté a su alcance, a lograr cualquier meta, porque, según él, “cuando a tu alrededor todo son oportunidades, es muy difícil pasar de largo sin aprovecharlas”.
La amistad de Watanabe y Nasagawa nace cuando éste último le destaca por encima de los demás miembros de la residencia, mediocres según él y entre otras razones , por no haber leído la obra “El gran Gatsby“, de Scott Fitzgerald.
La conversación tiene lugar en la habitación de Nasagawa, en una residencia de estudiantes de Tokyo:
-¿No hay nada en la vida que te dé miedo? -le pregunté.
-No soy tan estúpido -dijo Nagasawa-. Por supuesto, muchas veces la vida me da miedo. Como a todo el mundo. La diferencia está en que no lo admito como premisa. Quiero llegar hasta donde pueda empleando todas mis fuerzas. Tomando lo que quiero, dejando lo que no quiero. Así es como vivo. Si meto la pata, me detengo y lo reconsidero. Si uno le da la vuelta a esta sociedad injusta, entiende que en el mundo puede explotar sus posibilidades.
-Eso me parece muy egoísta, la verdad.
-¡Yo no me quedo mirando al cielo esperando que caiga la fruta! A mi manera, me esfuerzo mucho. Me esfuerzo diez veces más que tú.
-Tal vez tengas razón -reconocí.
-Por eso a veces miro alrededor y me siento asqueado. Me digo: ¿por qué no se esfuerzan más estos tíos? Lo único que saben hacer es quejarse.
-¿Por ejemplo, mientras otros se quedan satisfechos al saber que han encontrado un empleo, tú empiezas a estudiar español?
-A eso me refiero. Antes de la primavera, dominaré el español. Ya hablo inglés, alemán y francés. Y el italiano, bastante bien. ¿Crees que todo eso se consigue sin esfuerzo?
El fumaba un cigarrillo; yo pensaba en el padre de Midori. A éste jamás se le había ocurrido estudiar español siguiendo unos cursos de la televisión. Probablemente, tampoco había pensado nunca en la diferencia entre esfuerzo y trabajo. Tal vez estuviera demasiado ocupado para ello.
extraido de「Norwegian Wood (ノルヴェイの森）」, de Haruki Murakami. Traducción de Lourdes Porta. Edición en España por Tusquets, 2011
por ajaest Dice el refrán que más vale tarde que nunca, al fin tras un par de meses en el que los exámenes y un viaje han detenido completamente el desarrollo de JavaDiKt, puedo decir con orgullo que hoy ha sido publicada una nueva versión.
Las mejoras en esta versión se han enfocado principalmente en arreglar los numerosos fallos que la anterior trajo bajo el brazo:
La última vez prometí que me pondría a mejorar la bases de datos, pero he considerado que arreglar estos fallitos era prioritario. Aunque los cambios parezcan pocos, puedo asegurar que han llevado bastante trabajo. El bug del lanzador para mac en particular ha sido especialmente tedioso de arreglar(si realmente está arreglado, espero que sí).
En otro orden de cosas, últimamente he estado alguna que otra cosilla con Android, y he llegado a la conclusión de que trasladar JavaDiKt a la plataforma de Google es viable. Por eso, voy la planificada reforma de la base de datos se va a centrar en que ésta sea compatible sin cambios tanto en PC como en móvil, en detrimento de hacer más estable su interfaz a corto plazo. Esto demorará ligeramente los planes que tenía de liberar la base de datos como API antes de Septiembre, pero el objetivo merecerá la pena.
Finalmente, comunicaros que el repositorio oficial de JavaDiKt ha cambiado de servidor. Seguiré usando la mayoría de las funciones de la forja de Red Iris(registro, ficheros, etc…) pero los últimos cambios en el código solo podrán obtenerse desde la siguiente dirección usando un cliente SVN usando como nombre de usuario y contraseña “guest”:
http://local.ajaest.net/rep/JavaDiKt/
El código fuente seguirá siendo empaquetado y subido a la forja cada 2 versiones como siempre.
Con esto y un bizcocho… poco más que añadir. No me queda más que despedirme de vosotros, intentaré que no pase tanto tiempo entre entrada y entrada, los próximos meses iré revitalizando el blog poco a poco.
por ajaest Premiados en el V Concurso Universitario de Software Libre. De arriba a abajo y de izquierda a derecha: José Antonio Jiménez Carmona de "Predesys", Raúl Jiménez Ortega de "GeoRemindMe", Javier Angulo Lucerón de "Terminal Previewer", Sergio Garcia Mondaray de "Yakito", Miguel Sempere Sánchez de "SocialSight", Rubén Dugo Martín de "GeoRemindMe", Luis A. Arce González de "JavaDiKt" y David Saltares Márquez de "IberOgre y Sion Tower"
Terminada la fase final del V Concurso Universitario de Software Libre, después de muchas risas mezcladas con interesantes debates y ponencias, fueron entregados los premios de las distintas categorías:
Premio especial del Concurso Universitario de Software Libre a “Yakito“, de Sergio Garcia Mondaray de la Universidad de Castilla la Mancha.
Premio al mejor proyecto de Accesibilidad a “Geo Remind Me“, de Raúl Jiménez Ortega, Anna Peña Martínez y Rubén Dugo Martín de la Universidad de Granada.
Premio al mejor proyecto de Comunidad a “IberOgre y Sion Tower“, de David Saltares Márquez de la Universidad de Cádiz.
Premio al mejor proyecto de Educación a “JavaDiKt“, de Luis A. Arce González de la Universidad de Sevilla.
Premio al mejor proyecto de Innovación a “Predesys“, de José Antonio Jiménez Carmona de la Universidad de Sevilla.
Premio al mejor proyecto de Sistemas a “TP (Terminal Previewer)“, de Javier Angulo Lucerón de Universidad de Castilla la Mancha.
Enhorabuena a todos los ganadores, que tienen proyectos fantásticos y ademas son gente de puta madre. La experiencia ha sido fantástica, y la verdad, me anima muchísimo a pasarme por la !NotBarraLibreCamp de Cádiz el 27 de mayo.
Por mi parte, yo me voy contentísimo con el reconocimiento que le ha sido dado a mi proyecto. Hablando sinceramente, ha llegado más lejos de lo que pensaba allá por Octubre del año pasado, cuando empecé a esbozar a lápiz la interfaz de JavaDiKt en la hoja de un cuaderno.
Pero este premio no significa la final del proyecto. Aunque los dos próximos meses estaré hasta el cuello de exámenes y trabajos, el desarrollo de JavaDiKt volverá con fuerza en Julio. Estoy convencido a convertir JavaDiKt, tal y como dice su eslogan, en el diccionario de Kanjis definitivo.
Y a todos aquellos que apoyaron el proyecto, ya sea descargando, evaluando , usando, difundiendo,… ¡Muchas Gracias! ¡Sin vuestra ayuda sin duda ésto no sería posible!

References: resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución