Sobre el Curso de Java y el Proyecto Certificate.

Recientemente he recibido una buena cantidad de mails y comentarios en algunos post de este blog, donde me preguntan si continuare con el proyecto certificate. Lamento decirles que ese proyecto ya esta muerto y enterrado, lo que no esta muerto es el curso de videotutoriales de java el cual hasta la fecha se le han ido añadiendo cosas, es solo que me encuentro sumamente ocupado y no he podido darme el tiempo para ordenar todo y subirlo a cualquier almacenamiento online gratuito.

En estos momentos estoy realizando material para capacitación en la realización de screencast como apoyo al aprendizaje en la educación 2.0, cosa que me tiene verdaderamente asorbido hasta el día de hoy.

Probablemente en los próximos meses pueda empezar a subir algunos videotutoriales, de momento y por las próximas dos semanas lo veo dificil.

Comunicación entre actividades en Google Android

Mi experiencia Ubuntu+Beryl + Java

Bueno, en este “break” que me he dado debido a la desaparición de certificate.educaleft.com he estado intentando algo que hace tiempo desisti por que simplemente no funcionaba: instalar Beryl en mi Ubuntu. Mi experiencia había sido muy grata hasta que probe instalar NetBeans 5.5 y no funcionó. La razon…muy simple: Beryl.

Estuve leyendo algunos blogs que daban ciertas posibles soluciones, sin embargo la única que me ha funcionado es la siguiente:

Primero debemos abrir una terminal y entrar como root y después abrir el siguiente archivo con este comando:

sudo gedit /etc/environment

Una vez abierto, colocamos esta línea al final:

AWT_TOOLKIT=”MToolkit”

Lo guardamos y al reiniciar ya debería funcionar el NetBeans. De no ser así tendremos que cambiar de gestor de escritorio a metacity y después volver a cambiar a Beryl.

Certificate desaparece!

Asi es, el dominio http://www.certificate.educaleft.com desaparece para darle cabida a http://www.locx24.educaleft.com la cual estará en construcción en los proximos méses, respecto al material que ya habia sido publicado haré unos ajustes y serán puestos en el nuevo servidor.

En estos momentos me encuentro desarrollado el material en videotutoriales del curso, para ser más preciso el capitulo 5: Estructuras de Almacenamiento, que hablará de Arrays en su totalidad y una que otra clase y metodos nuevos en la version 1.5 del Java SE.

Buen Día

Entrevista a Alberto Molpereces.

Al Molpereces creador de javaHispano muy amablemente me ha concedido una entrevista y nos habla de sus inicios y de como a base de mucho esfuerzo logró consolidar a javaHispano como uno de las mejores comunidades de Java en la Red.

Además tambien nos cuenda del porque dejó javaHispano y algunas otras opiniones. La entrevista integra a continuación:

El Diario de Locx24:Detrás de un personaje siempre hay una historia, ¿Cual es la tuya?

Al Molpereces:

Mi historia es en principio muy normalita, quizás simplemente soy un poco inquieto y obstinado, pero nada más. Nací y estudie en Bilbao, en el norte de España, y en el momento de empezar a trabajar decidí dar el salto a Alemania por distintas razones. Me pasé allí tres estupendos años, momento en el que volví a España, a Bilbao, dónde he estado hasta hace unos meses, cuando me he trasladado en Madrid.

En estos años he pasado por todas las etapas, desde programador, hasta dirigir un departamento de desarrollo, pero sin dejar nunca de programar y probar nuevas cosas. Incluso he llegado a tener mi propia empresa, Linking Paths.

El Diario de Locx24:¿Hace cuanto tiempo que navegas por la Red?

Al Molpereces:
Umm… ahora mismo no te sé decir, supongo que empecé a hacerlo en el 97, aunque en casa y de continuo supongo que 1998 es el año más correcto. Desde entonces digamos que no he pasado desconectado casi ni las vacaciones, aunque mi participación en temas en la red es cada vez menor.

El Diario de Locx24:¿En que momento de tu vida se te ocurrió hacer algo como javaHispano?

Al Molpereces:
A finales del año 2000. Por Septiembre u Octubre. Por aquel entonces empezaba a trabajar profesionalmente con Java y además empezaba a usar Linux en casa. La verdad es que me daban un poco envidia las comunidades de usuarios Linux, e incluso las comunidades de Java que había en otros países y en otros idiomas. Yo vívia en Alemania y trabajaba en inglés y alemán, pero aún estaba bastante ligado a España y solía visitar sitios en español (luego se me pasó). Tenía tiempo libre (en Alemania el horario de trabajo me lo permitía) y además ganas de hacer muchas cosas, así que contacte con unos cuantos interesados, compré el dominio, y listo.

El Diario de Locx24:Para que algo exista tiene que haber una razón, ¿Cuál es la de javaHispano?

Al Molpereces:
Un poquito ya lo he contestado en la pregunta anterior. La razón para crear javaHispano fué la de crear un sitio dónde pudieramos compartir conocimiento y experiencias todas las personas que trabajamos con java en el idioma español, puesto que queramos o no, aún hay muchas limitaciones en el idioma. Los que andabamos con Java por entonces (muchos de ellos) usábamos las news (es.comp.lang.java), y aunque había un grupo interesante de gente, yo pensaba que se podía hacer más, así que me embarque en la aventura de formar esta comunidad online. Existía la parte java de programacion.com, pero no era lo que buscaba, aunque nuestra competencia les vino bien para mejorar .

En todo caso, y por ser claro, la idea siempre fué la de crear grupo/comunidad, nunca una página personal.

El Diario de Locx24:
¿Con que dificultades te topaste al crear javaHispano?

Al Molpereces:

Supongo que la participación. Quizás yo era muy ambicioso, o muyingenuo, no lo sé. Pensaba que la gente estaría encantada con la idea y que se motivaría ella sola para participar. No fué así, obviamente. En los años que yo estuve “al mando” de javahispano (hasta Marzo2005), pasamos distintas épocas, la gente iba y venía, se unía y lo iba dejando (Leo Suarez, Emilí Miedes, Martín Pérez o Aitor García por citar algunos) y otros aun siguen (Abraham, Rugi, Lasterra, etc.).

Formabamos un grupo interesante, pequeño, con altas y bajas pero interesante y participativo, tanto que llegamos a organizar dos congresos a nivel nacional en España con un programa muy interesante.

Sin embargo esa limitada participación y quizás nuestra propia ignorancia fué la causa del declive de javaHispano como comunidad. Crecimos demasiado y no estabamos preparados para ello. Demasiadas cosas que hacer y poca gente. Algo que había hecho siempre, dedicarle tiempo a la gente para “acercarla” a la idea y convencerla de que participar era bueno para sus carreras, lo dejé de hacer por falta de tiempo, y el grupo fué menguando, o al menos no creciendo al ritmo necesario.

Con lo que volvemos a lo mismo, la mayor dificultad debió ser una mezcla de ambición e ingenuidad, aunque el resultado haya sido bastante bueno.

El Diario de Locx24:
¿Por qué crear una licencia javaHispano propia?, ¿Por qué no usar copyleft o creative commons?

Al Molpereces:

Buff… de eso ya ni me acuerdo. Era mediados del año 2002 si no recuerdo mal. Por aquel entonces no había tanta información en la red ni nosotros sabíamos tanto. Además, eso de ser un grupo de gente siempre causa que cada uno tenga su punto de vista y quiera añadir algunas cosas, como por ejemplo referenciar el sitio de javahispano cuando se republicara material, porque nunca hemos puesto impedimentos para compartir el material. En realidad, tampoco es obligatorio usar esta licencia para publicar en javaHispano. Pero en todo caso, es algo que se decidió así dentro del grupo, pero que hoy haría de otra manera si tuviera que volver a hacerlo.

El Diario de Locx24:
Hoy en día javaHispano sale hasta en revistas, ¿Cómo lograr llamar la atención así?

Al Molpereces:

Pues con trabajo, mucho trabajo y dedicación, de mucha gente. Nada sale de la noche a la mañana, pero todo es posible, eso es algo que no se tiene que olvidar nunca. Pero todo requiere su tiempo, y cada vez la gente tiene menos paciencia. JavaHispano empezó a despuntar como referencia a comienzos del 2003 creo yo, más de dos años después de su nacimiento y después de mucho trabajo.

El Diario de Locx24:
¿Cuándo empezaste a distanciarte de javaHispano?

Al Molpereces:

En Diciembre de 2004. La verdad es que salí muy tocado por el resultado del segundo congreso. Además en Marzo de 2005 cree mi empresa, y decidí centrarme en ella. Pensaba (y sigo pensando) de que era el momento de regenerar la página y el grupo, de dejar paso a nuevas ideas, porque por A o por B las mias ya no erán válidas.

El Diario de Locx24:
¿Qué consideras que le haga falta a javaHispano?

Al Molpereces:

Supongo que será políticamente incorrecto, pero voy allá. Desde el año 2004 javaHispano es una asociación sin ánimo de lucro legalmente constituida, esto es, es una organización de la que cualquiera puede formar parte y participar. Pero poca gente sabe esto. Y es que el día a día, como comentaba antes, ha hecho que el tiempo se invierta en “hacer cosas” (seguramente muchas necesarias, otras no), en lugar de dedicar tiempo a comunicar lo que es y conseguir nuevos apoyos, que los hay. JavaHispano se ha centrado en lo que ofrece en lugar de lo que es, y ese es parte del problema.

Es fácil decir algo del estilo de Jesucristo (“dejar que los niños se acerquen a mí”) y esperar que la gente se pelee por colaborar, pero la realidad es que hay que trabajar mucho y dedicarle tiempo para que la gente participe, darles ese sentimiento de comunidad y formar parte de algo, de implicación, para que la gente participe. Cuando empecé con esto, cuando la gente me hacía una consulta, la primera vez les contestaba, pero si necesitaban más ayuda, siempre les hacía el pequeño chantaje de que estaban obligados a escribir un artículo sobre el tema en cuestión para javaHispano. No siempre lo hacían, pero ayudaba. Eso y dedicarle tiempo a todo el que se acerca, claro.

Pero esto vuelve a tener que ver con la respuesta sobre mi distanciamiento. Y es que quizás esta es mi idea de javahispano y no la de el resto, de visitantes y miembros del grupo. Quizás el resto sólo quiere un portal de noticias, que es en lo que parece se ha convertido, no lo sé. Yo desde luego tengo poco interés en ese javaHispano, y en realidad lo visito muy poco últimamente (1-2 veces por semana). Aunque vuelvo a decir que esta es mi opinión personal, si el resto del mundo está contento así me parece muy bien.

En cualquier caso sigue siendo encomiable el esfuerzo de las personas que lo mantienen y luchan por ello cada día. Por ejemplo me ha sorprendido el hecho de la javacaup, aunque el mérito no sea de javahispano al 100%. Leí que lo iban a remodelar, no tengo claro lo que pasará entonces, les deseo toda la suerte del mundo, y que empiecen por encontrar su propia razón de ser para javaHispano.

El Diario de Locx24:
¿Qué opinión puedes darnos de Java y que les dices a sus detractores?

Al Molpereces:

No sé, hace tiempo que no me considero un evangelista de Java. Es lo que más uso, pero mi trabajo no consiste en convencer a nadie de que lo usen, sino de que si han decidido usarlo, lo hagan bien. Con Java, como cualquier otra plataforma se pueden hacer muchas cosas (eso sí, en unas más y en otras menos), pero hay que conocerla para hacerlo bien.

Aunque mi opinión ahora mismo es ciertamente crítica sobre Java. Me parece que a nivel global es posiblemente la mejor plataforma para muchas cosas (que no todo), pero sin embargo me parece que está en un momento en el que deberían repensarse algunas cosas, porque sinceramente, para las personas que tienen que empezar con ella ahora, da miedo.

Un programador que quiera hacer una aplicación web en Java ahora tiene que (debería) aprender a usar un framework de web, JSP, un framework de persistencia, un servidor de aplicaciones, y patrones de software, por no hablar de “añadidos” como librerías al estilo de jakarta-commons, temas como ant/maven y junit, etc. Y no es lo malo lo que tiene que aprender, sino que tiene mil opciones de cada una de ellas.

Poder elegir es bueno siempre que haya criterio, y me temo que no siempre lo hay por diversas razones (tiempo, referencias inválidas, dinero, etc). No quiero decir con esto que una herramienta tenga que servir para todo, tampoco, pero hay demasiada rigidez, fragmentación y ruido.

El Diario de Locx24:

Te agradezco mucho tú tiempo para esta entrevista y aprovecho para darte gracias públicamente por crear un espacio tan interesante como útil y sobre todo del universo de Java que es tan basto.

Al Molpereces: Nada, gracias a tí, ha sido un placer.

Si hay alguien más a quien agradecerle es a este personaje que sin duda puso su terron de arena en la Red y amplio el panorama de Java en el mundo Hispano.

Entrevista proxima a javaHispano.

Bien pues he mandado una petición para una entrevista a los creadores de javaHispano que tengo la esperanza que acepten para que todos podamos saber quien esta detras de esta maravilla del mundo hispanoparlante de Java.

Tambien acabo de enviar una petición de colaboración a la junta de javaHispano con el objetivo de recibir su apoyo para el proyecto certificate. Sobre todo con difusion para que este llegue a más gente, y tambien con ejercicios y material para el curso.

Bien dicen que la esperanza muere al último xD.

Buen Día.

Ejercicios de Java online.

Bueno pues leyendo como de costumbre las noticias más recientes de JavaHispano me entero de la existencia de un sitio formidable y tambien con un excelente sistema de simulación de compilación del codigo, es decir si nosotros queremos compilar el codigo que hemos realizado de alguno de los ejercicios o problemas publicados existe la posibilidad de realizar un analisis lexico y semantico del mismo como de un compilador de Java se tratara.

El sitio JavaBat.com es gratuito y creado por Nick Parlante, profesor universitario en Standford, para ayudar a practicar java por internet.

Excelente sitio para profesores de programación que deseen crear una cuenta y formar grupos de usuarios por ejemplo de alumnos suyos de diversos grupos y materias.

¡Por fin me llegó Solarios 10 a domicilio!

Despues de esperar un largo mes y medio, por fin tengo en mis manos mis DVD’s de Solarios 10, digo, no sere el primero ni el ultimo pero me servirá muchisimo para le curso de certificación o mas bien el Curso guía de certificación de Solaris 10 que estoy elaborando.

Para quien lo quiera estudiar el link se encuentra en la sección de enlaces interesantes y si andas un poco perezoso pues aquí lo tienes: ir a Certificate.

El paquete contiene un estuche y dentro de él contiene dos DVD’s para dos tipos de arquitectura diferentes: SPARC (arquitectura Sun) y x86/x64 (intel), además de un DVD extra que contiene herramientas de desarrollo como Sun Studio 11, Sun Java Studio Enterprise 8, o el NetBeans 5.0 (que modernos xD).

Pero bueno nada es perfecto, de todas formas estoy contento con ese envio, aunque sigo esperando otros dos; las distribuciones de Linux Ubuntu, Edubuntu, y Kubuntu. Además de OpenSolaris que tambien estoy esperando.

Poximamente entrevista al Prof. Jesús Conde “OutKast”….no se la pueden perder.

Buen dia.

F3 la nueva esperanza de Sun Microsystems

Al parecer SUN ha estado desarrollando un nuevo lenguaje de programación llamado F3, por lo que en el blog del desarrollador (Chris Oliver) se ven unas notas que describen cómo es el lenguaje, es un lenguaje de script que termina generando código Java para obtener como resultado algo muy similar a lo que sería una aplicación Flash.

En el blog mencionado es posible ver demos de la aplicación y algunas capturas, la verdad es que hasta el momento no lo encuentro interesante pues pareciera una rara mezcla entre Flash y OpenLaszlo.

Fuente: OsNews

Tips para programar en Linux

Si hemos programado en Windows pero estamos interesados en la programación en Linux, estos consejos resultan especialmente útiles para cambiar algunas de las ideas y minimizar el choque ocasionado por el cambio de cultura cuando encontramos diferentes ideas y formas de pensar.

EVALUAR CADA ALTERNATIVA DISPONIBLE

A diferencia de la Interfaz de Programación de Aplicaciones (API) unificada en Windows que provee a los programadores con un único método para alcanzar un cierto objetivo, Linux provee diversas formas de alcanzar el mismo objetivo. Por ejemplo hay una variedad de cajas de herramientas (toolkits) de abstracción de la Interfaz Gráfica de Usuario (GUI), siendo las más importantes QT y GTK para escribir programas de Interfaz Gráfica de Usuario. Además, no se necesita elegir entre C o C++. Hay muchas opciones para programar, incluyendo la escritura de una serie de comandos en un archivo de texto para el intérprete de comandos (shell scripting), Perl, Python, Gambas, Java, Mono(Plataforma .NET) y PHP. Así que no siempre hay que tener una idea fija de que se necesita aprender del modo “difícil”.

No hay que abrumarse con las opciones. Sólo hay que ser consciente de ellas y tomar aquellas herramientas y técnicas con las que nos sintamos mejor.

LOS IDEs NO SON NECESARIAMENTE MÁS PRODUCTIVOS

Los programadores que han utilizado extensamente el Visual Studio de Microsoft para realizar sus desarrollos posiblemente se sientan incómodos al adaptarse a la manera en que se hacen las cosas en Linux. Aunque hay algunos Entornos Integrados de Desarrollo (IDEs, por sus siglas en inglés) bastante decentes en Linux, incluyendo a Kdevelop, Anjuta y Eclipse, pudiéramos encontrar que utilizando un editor de texto y creando un archivo de descripción (make file, en inglés) sea una mejor idea a largo plazo.

Cuando desarrollamos aplicaciones de Software Libre, posiblemente no queramos atar el desarrollo a una plataforma o a un Entorno Integrado de Desarrollo específicos, teniendo en cuenta que nuestro código será compartido y que otros programadores pudieran contribuir en el proyecto. A pesar de que los Entornos Integrados de Desarrollo no son una mala idea, posiblemente encontremos que al desarrollar proyectos más pequeños utilizando un editor de texto simple y un archivo de descripción sea una mejor idea.

NO BUSCAR CARACTERÍSTICAS ESPECÍFICAS DE UNA DISTRIBUCIÓN

Pudiera sorprender a muchos programadores de Windows saber que prácticamente se puede no hacer supuestos de la configuración por defecto de Linux en la máquina del usuario final. Diferentes distribuciones usan diferentes ubicaciones de archivos de configuración y ajustes. A menos de que estemos escribiendo una utilidad de configuración del sistema para una distribución en particular, no hay que hacer supuestos específicos de una distribución. De igual modo nunca hay que forzar a los usuarios a que trabajen como un administrador, a menos de que el propósito exclusivo de la aplicación sea el de modificar ajustes específicos del sistema.

NO MODIFICAR NI TRATAR DE MODIFICAR ARCHIVOS DEL SISTEMA.

Además de no ser una buena práctica de programación, no se puede asumir que determinado archivo de sistema existe en la máquina del usuario final (debido a diferencias específicas de la distribución).

Tampoco podemos modificar archivos de sistema como un usuario “normal” (sin los privilegios necesarios) y no se supone que una aplicación normal de productividad sea ejecutada como administrador.

En la mayoría de los casos, encontraremos que apenas tenemos alguna razón buena para tocar archivos específicos.

SER VISUALMENTE CONSISTENTE

Los programadores de la Interfaz Gráfica de Usuario, especialmente programadores de GTK y QT, necesitan entender que estas bibliotecas son bastante modificables (el usuario final puede modificar la apariencia visual de la Interfaz Gráfica de Usuario en casi cualquier forma posible).

Por lo tanto, hay que evitar usar fuentes (de letra) o colores específicos en nuestra Interfaz Gráfica de Usuario. No es necesario. No hay que forzar al usuario final a que instale alguna fuente (de letra) particular en su sistema. Hay que dejar el despliegue visual de la aplicación exclusivamente a la biblioteca de la Interfaz Gráfica de Usuario que utilizamos. A menos de que estemos escribiendo un procesador de palabras casi nunca requeriremos manejar fuentes (de letra) en el código de nuestra aplicación.

ESTAR PREPARADOS PARA REALIZAR ALGO DE INVESTIGACIÓN

Linux no viene con una herramienta parecida al MSDN que nos proporcione documentación para cada herramienta de programación individual o para cada Interfaz de Programación de Aplicaciones que se encuentre disponible allá fuera. Esto no es práctico debido a que Linux no es desarrollado por una sola compañía. La mayoría de las veces si estamos utilizando bibliotecas de terceros, podremos encontrar documentación (ya sea a través de una descarga o en línea) en el sitio en Internet oficial del encargado de la biblioteca. También hay que estar conscientes de que muchas bibliotecas vienen con documentación incompleta o sin ella.

Posiblemente tengamos que buscar código de muestra o hasta archivos de cabecera para aprender más acerca de una biblioteca en particular. Lo bueno es que probablemente no nos topemos con esta situación con la mayoría de las bibliotecas populares de terceros, aunque siempre es bueno estar preparados (por si acaso).

NO EMPAQUETAR DEPENDENCIAS

Cuando estamos creando paquetes que pueden ser distribuidos no hay que incluir dependencias junto con nuestra tarball (Bola de Alquitrán, paquete de archivos creados con la utilidad Unix tar). Sólo hay que incluir el código fuente y ofrecer instrucciones de compilación (entre más genéricas, mejor). También hay que mencionar las dependencias que son requeridas en los archivos LÉEME (README) o INSTALACÍON (INSTALL) y en nuestro sitio en Internet.

Ya que la mayoría de las distribuciones Linux poseen sus propios sistemas de gestión de paquetes (y si nuestra aplicación es lo suficientemente buena, posiblemente pueda ser incluida en el depósito de paquetes oficial), debemos de dejar el manejo de las dependencias al usuario final que compila nuestro programa en forma manual o al encargado del paquete de la distribución que envía nuestra aplicación como parte de su paquete. Puesto que toda distribución Linux tiene una forma distinta de administrar las dependencias, no hay que intervenir con ellas creando una rutina de instalación que intente ser inteligente e instale otras bibliotecas.

Aparte de crear problemas con las versiones, resulta tedioso y engorroso incluir dependencias con el programa. También hay que probar y mantener las dependencias al mínimo, especialmente si nuestro programa tiende a usar bibliotecas exóticas de terceros.

Fuente original