viernes, febrero 24, 2006

XglHowto - Ubuntu Wiki

Linux en general (y Ubuntu en particular) también tendrá transparencias y 3D en el intefaz de usuario (a la Vista y Mac)


XglHowto - Ubuntu Wiki

jueves, febrero 02, 2006

miércoles, enero 18, 2006

http://www.jboss.com/products/seam

EJB 3.0 + JSF para crear sitios de forma declarativa, como el artículo que escribimos pero bien.

http://www.jboss.com/products/seam

sábado, enero 07, 2006

Página en la q tienen plantillas para documentar proyectos completamente. Desde requisitos, ámbito, diagramas, etc...

http://readyset.tigris.org/

Además, todo esto está sacado de una entrada de barrapunto

http://barrapunto.com/article.pl?sid=06/01/06/078239

lunes, agosto 08, 2005

Plataforma para la ejecución distribuida de Java - ProActive

Es una plataforma que permite ejecutar un proceso escrito en Java en múltiples máquinas. La plataforma te oculta todos los detalles de sincronización por la red y esas cosas. Es LGPL.

ProActive

miércoles, mayo 18, 2005

miércoles, abril 27, 2005

Ant Web Start Task

Una tarea ant que te prepara la aplicación para que sea publicada con Java Web Start. Para no tener que hacer "a mano" el jar, firmarle, el html, el jnlp, bla bla bla

Ant Web Start Task

miércoles, marzo 30, 2005

SOFIA| JSP GUI Java Development Framework - Class and Tag Libraries

SOFIA| JSP GUI Java Development Framework - Class and Tag Libraries

Framework y conjunto de APIs de utilidades para construir aplicaciones web que tiran de base de datos. En plan lo que estamos haciendo de OSIM pero parece que bien :). Por supuesto es open source así que no estaría de más mirarselo un poco más despacio.

sábado, marzo 19, 2005

Invocar métodos de objetos en el servidor desde javascript en el cliente !!! y recibir el resultado sin recargar la página ¡¡¡

DWR (Direct Web Remoting) GMail parece misteriosamente rápido, no tiene que recargar ninguna página y todo parece suave. Eso es porque es capaz de recibir fragmentos HTML del servidor sin recargar la página, lo hace en segundo plano. Para hacer eso con Java, tenemos DWR.

miércoles, marzo 16, 2005

Tutorial de Java en Español de JavaHispano

Un tutorial bastante currado de Java en castellano, con transparencias y todo. Tiene principios de la orientación a objetos, Java básico, Java avanzado, etc...

Pagina del tutorial

martes, marzo 15, 2005

Libro Gratuito en Español de compiladores con Java

Java a tope: Traductores y Compiladores con Lex/Yacc, JFlex/Cup y JavaCC: "El presente volumen introduce al lector en uno de los aspectos m�s potentes de la inform�tica tradicional: el an�lisis y comprensi�n de ficheros de texto. Las t�cnicas y herramientas que aqu� se examinan, se encuentran ampliamente difundidas y no est�n orientadas exclusivamente a la construcci�n de compiladores e int�rpretes, sino que establecen un marco general con el que el inform�tico puede analizar textos con cualquier otro objetivo. Cualquier transformaci�n sem�ntica imaginable computacionalmente puede hacerse realidad, desde el procesamiento de datos tabulares hasta la conversi�n de subt�tulos en pel�culas para ordenador, pasando por la transformaci�n de programas fuente, generaci�n de �ndices anal�ticos, de materias, etc.

Los primeros cap�tulos presentan una panor�mica general de los conceptos b�sicos que sustentan estas t�cnicas, a la vez que se exponen las herramientas Lex y Yacc y sus contrapartidas JFlex y Cup que generan analizadores sint�cticos y lexicogr�ficos en lenguaje Java. Tambi�n se estudia con profusi�n el funcionamiento de La herramienta JavaCC como representante m�s extendida de los generadores de an�lisis sint�cticos descendentes.

Los cap�tulos siguientes se centran en la utilizaci�n de estos metaprogramas introduciendo t�cnicas generales de gesti�n sem�ntica (tablas de s�mbolos, asociaci�n de atributos, mejora de gram�ticas, etc.) aplicadas a las diferentes fases que se siguen en la construcci�n de un traductor. El texto culmina con una introducci�n al manejo de la recursividad y de la memoria din�mica en tiempo de ejecuci�"

jueves, marzo 03, 2005

Eclipse es un IDE para cualquier lenguaje????

Chris Laffra, Chris Daly, Elwin Ho, Michael Scharf, Mark Melvin

This Technology Exchange discusses the impact of adding multiple programming languages to eclipse. Adding a new programming language can be quite an effort and involves studying the extensive eclipse editor framework, a large set of collaborating plugins, and the numerous extension points the platform provides.

The innovative JDT sets the bar high with great support for editing, navigation, build integration, debugging, and refactoring. To develop similar support for other languages can be quite an effort. Even extending existing language IDE components, such as new refactorings for JDT, can be equally difficult. Developing tooling that spans across various development tools and languages can be a challenge. Providing the end-user with a comprehensive and cohesive set of tools is sometimes out of reach. One might argue all this justifies a dedicated top-level eclipse project on multi-language IDEs.

Attend this exchange to hear experiences from various IDE developers and see what they mean by "language support" and what issues they ran into. Whether you plan to write an eclipse IDE for your favorite language, extend existing development tools, are a tool provider, or just an interested user, this session is for you.

martes, febrero 08, 2005

Creación de aplicaciones Web diréctamente de la BD

El OpenToro es una Gestor de Contenidos escrito en Java que permite el desarrollo ágil de aplicaciones web que gestionen bases de datos. Usar el OpenToro significa simplemente olvidarse de escribir innumerables SQLs y JSPs cada vez que queremos realizar una web con acceso a base de datos.
En la web podrás encontrar un tutorial de 30 páginas con información completa sobre cómo usar el OpenToro.

http://www.sourceforge.net/projects/opentoro


viernes, febrero 04, 2005

Java en los primeros cursos universitarios

Parece ser que la gente de ACM está creando librerías, documentación, ejercicios y

demás recursos para enseñar Java en los primeros cursos de las ingenierías informáticas.

Es MUY INTERESANTE porque tratan el problema de raíz, lo especifican bien y proponen
librerías para solventarlo. Una maravilla.

http://www.acm.org/education/jtf/

viernes, enero 14, 2005

martes, enero 04, 2005

Articulo en Español sobre Aplicaciones de Escritorio

Un artículo muy bueno de los amigos de JavaHispano sobre la creación de aplicaciones con interfaz gráfica de usuario.

http://www.javahispano.org/articles.article.action?id=94

viernes, diciembre 31, 2004

Generador de portales en Java y en español

Es el motor creado para mostrar javahispano.org, lo han hecho ellos y es BSD.

http://canyamo.sourceforge.net/

Además también está siendo usado para el cliente web de jLibrary, una interesante aplicación para catalogar documentos.

miércoles, diciembre 22, 2004

jLibrary

Puede ser interesante para la gestión documental que queremos hacer para artículos.

http://jlibrary.javahispano.net/

viernes, diciembre 17, 2004

User-defined logical structures

En eclipse ya se pueden definir formas más adecuadas para mostrar en depuración los valores de las variables. Especialmente útil para colections, puede ampliarse a cualquier clase que construyamos.

Esto es lo que pone en la lista de mejoras:

User defined logical structures

The Java debugger now lets you control what gets shown in the variables view for different types of objects. For example, collections can be displayed as a simple array of values, instead of the gory details on how that particular collection object is implemented.

This is done from the Java > Debug> Logical Structures preference page, where you associate with a specific class or interface either a single expression (for example, this.toArray()) or a series of named expressions. When the object is to be shown in the variables view, the expressions are evaluated to produce the values to display.

3D Interactivo??

https://ensmer.dev.java.net/

¿Que meter en un generador de compiladores?

Pues eso, antes de que se me olvide hay que recordar que en el compilador hay que ver:

- El uso de XML para definir o especificar el compilador
- El uso de anotaciones para definir o especificar el compilador
- El uso de AOP para constuir las acciones semánticas del compilador
- Hay que usar el patrón observador jerarquico y compararlo con AOP.
- Usar la separación entre la API pública del AST formada por interfaces y las clases de implementación. Sobre todo por la herencia múltiple y porque no se quieren publicar a las herramientas que hagan uso de él ciertos métodos usados internamente.
- ¿Cómo representamos en el AST los errores sintácticos?. ¿Haciendo objetos dummy que elevan RuntimeExceptions cuando se crean como resultado de una recuperación de errores?
- ¿Cómo usar gclib para crear visitadores en tiempo de ejecución de forma eficiente?
- Hay que tener un formato para serializar un AST con los atributos establecidos en disco.
- Hay que ver cómo reconocer bajo demanda el fuente para que no esté siempre en memoria si no es necesario. Puesto que el AST estará formado por objetos normales, habrá que usar reflection o algo. La idea es que en vez de modificar una clase del AST el desarrollador creará una clase con una referencia a la del AST. De forma que sea posible dejar en memoria estos objetos y serializar el AST.
- Hay que usar un nuevo tipo de visitadores que permitan ejecutar acciones para los objetos de determinadas clases. Pero no recorrer el árbol completamente, si no sólo los objetos de las clases "marcadas". Por ejemplo, realizar un fase de búsqueda previa y luego ejecutar las acciones semánticas. El objetivo es mantener en caché la lista de objetos para que las acciones posteriores se realicen más rápidamente.
- Realizar el patrón observer jerarquico sólo para algunas clases. De forma que no tiene porque realizarse en todos los objetos.
- Para que la gente sepa como usar la API del AST. Se debe proporcionar una herramienta que transforme un código válido en el lenguaje de programación en un código Java que permita construir ese mismo código fuente usando la API, eso ayudará mucho a comprender la API.
- Hay que tener el soporte de ficheros y directorios en la propia API generada por el compilador, de forma que los visitadores puedan recorrer estos elementos como objetos del AST.
- Por supuesto, los ficheros se pueden mapear a buffers de texto, es decir a componentes de texto Swing.
- Compilación incremental
- Generación de pretty-printers
- Modificar el orden de recorrido de los visitadores de una forma más ordenada. Por ejemplo, si en la lista de miembros aparecen intercalados métodos, atributos y otros tipos, puede ser interesante recorrer todos los miembros de un tipo todos a la vez. Además, este tipo de ordenaciones deberán poder ser accedidas a travás de métodos a listas de esos tipos. De una forma automática.
- Soporte para una sintaxis que permita especificar consultas sobre el código. Algo así como patrones de código que se "acojen" a códigos específicos. Es decir, crear una API de búsqueda genérica, independiente del lenguaje.
- Objetos que no están en el fuente pero que son "puestos automáticamente" por el compilador, por ejemplo, el constructor sin parámentros, la llamada al constuctor de la clase padre, el import de java.lang, etc... Es decir, hay que poder configurar en el visitador si se recorren estos objetos o no, porque no están realmente en el código. La clase Node, debe disponer de un método para saber si ese objeto es ficticio o no.
- Dejar la gramática disponible en runtime (si es necesrio). Esto podría permitir metaprogramación pero más semántica, más orientada a la gramática. Por ejemplo para crear gráficos más simples, vistas en modo árbol, etc... Hay que ver cual es la mejor forma de representar esta gramática.
- Hay que hacer que los errores sintácticos sean (en la medida de los posible) cercanos a la especificación de alto nivel por interfaces. Es decir, hay que usar nombres coherentes para los interfaces, y los errores tienen que referenciarlos a ellos, no a la gramática.
- El sistema de proporcionar formas para la depuración de la gramática. De alguna forma sencilla y estándar el usuario debe poder ver el progreso de reconocimiento. Por ejemplo proporcionar una miniherramienta tipo ENVIDO pero para depurar la gramática.
- Se deben proporcionar formas de reconocer partes de la gramática aisladas. Creando talblas nuevas (poco eficiente pero rápido de desarrollar) o bien de forma integrada al analizador LALR.
- Investigar las formas de representar un AST "ambiguo". Es decir, un AST que realmente no es un árbol si no muchos árboles en ciertas partes. Se podría mantener en memoria la primera alternativa de las posibles y luego ir cambiándolas bajo demanda, para probar su viabilidad con métodos semánticos.


Registro para saber lo que el alumno sabe de Java

La idea es usar el registro de uso para analizar la forma de aprendizaje de los alumnos. No sólo evaluando con el resultado final de un ejercicio, si no por el proceso que lleva a su resolución.

Grabar el uso de la herramienta

En JIdea se registra el uso de la herramienta para alertar al usuario de las características que usa y las que no usa. Sobre todo para que no pasa que llevas mil años usando un programa y llega alguien y te descubre una funcionalidad que llevabas desde el principio buscando y nunca habías encontrado.

Proyecto Educativo de Eclipse

http://eclipse.org/ecesis/

miércoles, diciembre 15, 2004

Comparativa de los sistemas de pesistencia en Java, desde Sun

Muy buena comparativa de los sistemas de persistencia en Java. Además está realizada por Sun y se supone que se ha realizado para la próxima generación de sistemas de persistencia que están preparando, que (se supone) unificará todos estos mecanismos o al menos los integrará.

http://research.sun.com/techrep/2004/smli_tr-2004-136.pdf

domingo, diciembre 12, 2004

http://cglib.sourceforge.net/

Herramienta para generar código en tiempo de ejecución. Es algo así como la metaprogramción de escritura, no sólo de lectura cómo reflection de Java.

API para crear un pool de conexiones JDBC

http://proxool.sourceforge.net/

¿Que sistema de persistencia usar?

Sólo JDBC, DODS, JDO, EJB, Hibernate, Castor????

Habrá que mirarlos todos, de una vez por todas, para hacerse una idea de lo que usar cuando necesitemos persistencia.

viernes, diciembre 03, 2004

Groovy: Evolución de Java en Java

Un lenguaje con muchas mejoras al lenguaje Java, ejecutado en la JVM y como Servlet, desde el que se pueden usar APIS en Java y con integración con Eclipse, JIdea, etc...

¿Que mas se puede pedir?

Es open source y está siendo desarrollado en el JCP (Java Community Process)

http://groovy.codehaus.org

Apache BSF II (Debugger Framework)

Debugging support has been added to BSF over the last year. In its current form, only debugging of Javascript in JSPs is supported. The focus has been to design an API that would permit a generic debugging framework for multiple scripting engines; however, this has remained an goal for BSF 3.0. Included in the debugging support for BSF 2.3 is a rudimentary command-line debugger named jsdb, which acts as a client to a debugging server that is managed by the BSFManager.
An example of a production debugger using the BSF debugging engine is at http://www.eclipse.org/.

Apache Bean Scripting Framework

http://jakarta.apache.org/bsf/

Bean Scripting Framework (BSF) is a set of Java classes which provides scripting language support within Java applications, and access to Java objects and methods from scripting languages. BSF allows one to write JSPs in languages other than Java while providing access to the Java class library. In addition, BSF permits any Java application to be implemented in part (or dynamically extended) by a language that is embedded within it. This is achieved by providing an API that permits calling scripting language engines from within Java, as well as an object registry that exposes Java objects to these scripting language engines.

Entre otros, BSF soporta:

JavaScript
Java
XSL

Ideal para hacer herramientas educativas para estos lenguajes.

Espiritu de Java

"It's more important that Java programs be easy to read than to write."
- Graham Hamilton,
Sun Fellow in the Java Platform Team, Sun Microsystems

We're starting to think about potential language features for Dolphin. I've been reflecting on the principles that James Gosling so brilliantly infused into the original Java language and which we've tried to preserve as it evolves. The core principle involves making programs easy to understand. The Java language is powerful but simple, easy to read, with a consistent, clear meaning. It's more important that Java programs be easy to read than to write. That may sound trivial, but it isn't.

Looking back at C++, there were a whole set of factors at work that make reading source code difficult: First, the C++ language itself became very complex. Many new ideas were added incrementally and, unfortunately, the seams show. Second, the C++ language consciously chose to emphasize "power" and "flexibility". That sounds nice initially, but, unfortunately, it also means that there is very little you can rely on and almost any simple program statement can have weird side effects. In C++ the statement "a = b;" must be approached with caution. Finally, the macro pre-processor reinforced the "power" aspect, but again at risks to comprehension.

The Java language took a very different approach through attempting to be an unobtrusive language. As a developer, you should be able to focus on what your application code is doing and on how it interacts with libraries. Code should do what it seems to do -- developers shouldn't need to worry about clever language side effects or about what "=" means this week.

This focus on clarity and readability has affected the Java language in deep ways. It has led to a focus on keeping the language simple and clear. It has led to fairly conservative uses of syntax and minimized the places where user defined code can modify base semantics. For example, there's a strong focus on having "one language" which means the same thing everywhere. A Java developer should be able to start reading a chunk of new Java source code and rely on a consistent set of language semantics. So part of Sun's investment in the Java language includes a strong focus on both a very precise specification (currently driven by Sun's esteemed computational theologist Gilad Bracha) and also an extensive language compatibility test suite.

Principles are good, but so are pragmatics. If we stuck too rigorously to our principles, we'd probably never dare make any changes to the language. It is natural for things to evolve, and we want to be able to make developers more productive, within the spirit of the language. But we are also very conscious that adding individually useful features may slowly undermine the deep values of the language.

Looking forward to Dolphin, I suspect we'll stay conservative on changes, as each change adds complexity. We're unlikely to add a macro preprocessor or any general form of operator overloading, or full-blown AOP, or any other mechanism for redefining and obscuring core semantics. But we will look for new language ideas that help developers with common problems. For example, one area I'm personally interested in is some kind of "friends" import mechanism to make large multi-package projects easier to manage.