Noticias Weblogs Foros Wiki Código

Planeta código

• Planeta
• Foros
• Trastienda
• WIKI

Sponsors:

• Posicionamiento web
• Ofertas hoteles Barcelona
• Abogados
• Insurance

Meta-Info

¿Que es?

Planeta Código es un agregador de weblogs sobre programación y desarrollo en castellano. Si eres lector te permite seguirlos de modo cómodo en esta misma página o mediante el fichero de subscripción.

subscripción

PlanetaCódigo en inglés

Puedes utilizar las siguientes imagenes para enlazar PlanetaCodigo:

Si tienes un weblog de programación y quieres ser añadido aquí, envíame un email solicitándolo.

Idea: Juanjo Navarro

Diseño: Albin

Bloggingg

Sun Certified Enterprise Architect for J2EE Technology

Febrero 22nd, 2005 - [Enlace local]

Este libro aborda la arquitectura J2EE de una forma muy global y no se centra en nada concreto. Está bien como una introducción, pero al no centrarse en nada en particular quedan muchas cosas en el aire. En tan poco tiempo explica tecnologías como UML, patrones de diseño, seguridad, internacionalización y protocolos, pretendiendo hacer una introducción sobre todo ello. Después de cada tema vienen unas preguntas de examen resueltas y comentadas, que están bastante bien porque afianzan los conocimientos. Lo recomendaría a las personas que se quieran introducir en la arquitectura J2EE.
David.

» Leer más, comentarios, etc...

Bloggingg

Sun Certified Enterprise Architect for J2EE Technology

Febrero 22nd, 2005 - [Enlace local]

» Leer más, comentarios, etc...

Pointer to (void)

Marketing

Febrero 17th, 2005 - [Enlace local]

» Leer más, comentarios, etc...

Pointer to (void)

Marketing

Febrero 17th, 2005 - [Enlace local]

Hoy ha llegado a mi casa un bonito pack de 6 CD's provenientes de Oracle, siguiendo la marcha de dar y tomar CD's gratuitamente. Tres de linux y el Tres de Windows, con guía de autoaprendizaje y en un estuche bastante apañado... hay que ver como tonterías de estas me siguen haciendo ilusión todavia al verlas...

Nada más por hoy, saludar a la gente de alemania desde aqui, que suerte teneis ;-) a mi el trabajo no me permite darme esas alegrias! Cosas que hay que tener en cuenta:

Un articulo sobre el OpenSource, The Economics of Commercial OpenSource, que la idea como idea esta muy bien, pero no deja de ser otro modelo comercial más. En realidad son tres estamentos que vale la pena leerse, en ingles, eso si. (Si se le ocurre a alguien de linux saltar ofendidisisimo en plan pataleta, aviso que paso de ese tipo de debates).

NHibernate o Hibernate para .NET, lo que ya me pareció una muy buena idea de parte de Java, pero que todavia está muy verde. CopyPaste, NHibernate is a .NET based object persistence library for relational databases. Pondremos algún ejemplo somnoliento un dia de estos. Un ejemplo en The Code Project.

Y ya, que hoy no tengo más tiempo.

» Leer más, comentarios, etc...

niko's mini factory

Utilización de EJBs en Spring

Febrero 14th, 2005 - [Enlace local]

Desde su introducción en la especificación EJB 2.0 en Septiembre 2001, las interfaces locales de los EJBs han probado ser de gran valor para el desarrollador.
Eliminan la obligatoriedad de distribuir nuestros objetos (ya que solo en algunos pocos casos es necesario), con la consiguiente mejora de performance, y por lo tanto eliminan la necesidad de lidiar con RemoteException en cada método. Es de destacar también que las interfaces locales utilizan llamadas por referencia, a diferencia de utilizar llamadas por valor (copias de objetos serializados) en la interfaz remota. Para ello, el servidor de aplicaciones instancia nuestros EJBs en la misma JVM que, por ejemplo, la capa de presentación web desde donde son llamados.
Pero no todo es color de rosa con los EJBs, ya que seguimos teniendo clases que son difíciles de probar (con JUnit, por ejemplo), y seguimos teniendo el añadido (en contraposición a utilizar POJOs para nuestros objetos de negocio) de complicar el desarrollo con interfaces y descriptores.

Pero veamos como utilizar Spring para simplificar el desarrollo en el caso que no poder reemplazar los EJBs por POJOs + AOP/ORM/JDBC.

Para utilizar un EJB tradicionalmente se ocultan las búsquedas JNDI detrás de un Service Locator que nos devuelve un objeto EJB Home, el cual a su vez utilizamos para obtener el EJB real (local o remoto) mediante una llamada al método create.
Esto no nos libra de tener que implementar también un Business Delegate para despegar al cliente de la utilización directa de la API de EJB, y por lo tanto de las RemoteException lanzadas por su método de networking.

El método de Spring para simplificar lo anteriormente expuesto es la utilización de proxys dentro del ApplicationContext, que nos libran de escribir un nuevo Service Locator y/o Business Delegate para nuestro objeto de negocio.
Utilizando el mismo ejemplo que la documentación de Spring, lo primero que haremos será seguir las buenas prácticas y construir una Business Methods Interface para nuestro componente. Este patrón nos asegura una correcta sincronización entre el nuestro objeto de negocio y la interfaz (local o remota), ya que ambos implementan la misma Business Method Interface. Otra razón para utilizar este patrón, es que nos será mas fácil intercambiar una implementación EJB por otra POJO, si mas adelante lo consideramos necesario:

public interface MyComponent {
    ...
}

Luego expondremos una propiedad en el objeto cliente (un web controller en el ejemplo de Spring):

private MyComponent myComponent;

public void setMyComponent(MyComponent myComponent) {
    this.myComponent = myComponent;
}

y finalmente configuraremos las dependencias en el xml de configuración de Spring:

<bean id="myComponent"
      class="org.springframework.ejb.access.LocalStatelessSessionProxyFactoryBean">
    <property name="jndiName"><value>myComponent</value></property>
    <property name="businessInterface"><value>com.mycom.MyComponent</value></property>
</bean>

<bean id="myController" class="com.mycom.myController">
    <property name="myComponent"><ref bean="myComponent"/></property>
</bean>

Lo que sucede luego, es que Spring (gracias a AOP) crea un proxy para el EJB, el cual implementa dinámicamente nuestra Business Methods Interface (MyComponent) y hace las búsquedas JNDI necesarias para encontrar el EJB Local Home (el cual pone en cache).
Ante cada llamada del cliente a myComponent, Spring hará la llamada correspondiente a create para obtener el EJB y al correspondiente método en el objeto de negocio.

Si por cualquier razón queremos cambiar la implementación del objeto de negocio de un EJB a un POJO, simplemente cambiamos la definición del bean en Spring sin necesidad de tocar una sola linea de código en el cliente:

<bean id="myComponent"
      class="com.example.MyBusinessObject">
</bean>

Esta facilidad para cambiar de EJBs a POJOs, sugiere que es posible, en una aplicación existente que utiliza extensivamente EJBs, ir reemplazando primero la infraestructura de configuración de dependencias, luego la de acceso a los objetos de negocio y finalmente la implementación misma de estos objetos. Asi resulta mucho menos traumático para el equipo de desarrollo, y menos estresante para la dirección.

Actualización: El artículo Pro Spring: Spring and EJB (en inglés) presenta el mismo tema en forma mucho mas extensa.

» Leer más, comentarios, etc...

El juego de la vida en C ofuscado

Febrero 12th, 2005 - [Enlace local]

Dide se ha dedicado a programar el algoritmo del juego de la vida en C ofuscado, aquí tenéis el resultado:

El código

Algunos lo hemos programado completo en ensamblador

» Leer más, comentarios, etc...

Se ofrece trabajar con Linux y Open Source

Febrero 10th, 2005 - [Enlace local]

Mi compañero de curro David Currie (¿a que mola la rima? ) me ha pedido que enlace un post suyo por si hay alguien interesado en trabajar para la empresa OpenSistemas, que es con la que estoy colaborando actualmente.

Por si alguien está interesado reproduzco a continuación la información:

Para los que les interesa trabajar con Linux, C/C++, y con tecnologías Open Source, mi empresa (OpenSistemas) está buscando ahora mismo a gente para varios puestos de desarrollador junior. Los detalles de la oferta están en InfoJobs, y poco más puedo añadir excepto que (en mi opinión) las condiciones pueden ser bastante ventajosas tanto a nivel personal como profesional.

Si no tenéis cuenta en InfoJobs, o preferís hacernos llegar un curriculum por correo, me lo podéis mandar a mi personalmente a dcurrie(at)opensistemas(dot)com o bien a la dirección de la empresa, info(at)opensistemas(dot).com.

Por cierto, solo quiero aclarar que a mi no me pagan por traer a gente, para los que cuestionen mis motivos .

Enlace al post original

P.D: A mi tampoco me pagan comisión (pero podrían)

» Leer más, comentarios, etc...

Pointer to (void)

Pato flameao

Febrero 9th, 2005 - [Enlace local]

» Leer más, comentarios, etc...

Pointer to (void)

Pato flameao

Febrero 9th, 2005 - [Enlace local]

Nota a los lectores habituales (si es que alguna vez hubo alguno): Este post se desvía de la línea habitual de este blog. Pasa al siguiente post.

Comentando con Frenética estos días atrás ha surgido la tentativa de, sin intentar ofender ni promulgar la rabieta por no entender, intentar reestablecer la cordura de la plebe, aka Bloggers Minimalistas.

Lo que parece un movimiento sin predecentes, me deja cada vez más atónito. ¿Por qué no consigo entender el significado de todo esto? ¿Por qué la gente comenta apresurando las últimas membranas de su teclado? Veamos unas cuantas posibilidades de porqué existen estos blogs:

1. "Ellos", los que escriben y los que comentan, están definitivamente en un nivel cognitivo muy superior al nuestro. A alguna autora se le ha visto levitar fruto de su alto nivel de reacción entre sus conexiones sinápticas, que rozan la precognición. Mientras tanto, yo me dejo haches y acentos en este texto.
2. Realmente es todo una broma a escala planetaria de aquellos que escriben y no pueden ser nombrados más que cuando les editan un libro. Envidia cochina, eso si. Los que comentan creen que deben demostrar que su nivel intelectual esta a la altura, y simplemente comentan mientras los autores del postexplosivodecomentarios (copyright de este termino por mi, xfa) se ríen llenado sus arcas.
3. Son espías provenientes de algún lugar recóndito de alguna galaxia vecina, que hablan en clave. Yo me decanto asertiva y definitivamente por esta posibilidad.
4. Hablan otro idioma, pero que comparte las mismas palabras y construcciones gramaticales que el nuestro. Eso si, la semántica, totalmente distinta.

A donde llegaremos señores. Cierto es que el arte abstracto puede ser una buena referencia: Que un "gran artista" pinte una línea negra sobre un lienzo de 10x15 cm y lo cuelgue a mitad de una pared de 10 metros de largo en mitad del Guggenheim, es posiblemente una desviación positiva, porque permite explorar nuevos terrenos sobre el descubrimiento del subconsciente. Que exista gente que haga lo mismo con palabras es, literalmente, un error pues las palabras son solo una verbalización del consciente con ciertos matices, al mas puro estilo homeostato, que en ningún caso pueden producir una "desviación positiva" si pierden EL SIGNIFICADO de esas propias verbalizaciones. Cuando hablas, solo traduces. Cuando pintas, te expresas.

Papá de Belén, usted tiene mucho que decir. Comente ;-)

Y eso si, los comentarios son lo mejor. ¿porqué comentan? ¿tan malo fué mi último post sobre integración continua? Si la regla es, cada 3 palabras de post minimalista - un comentario, mi último post debería haber sido publicado en el Times, como cuando El País regala un diccionario enciclopedico: "Pointer to (void), comentarios a Integración Contínua. vol. 1"...

Por cierto, si alguna editorial esta dispuesta a publicarme un libro del corte de este blog, o un articulo, o una columnita o lo que sea, salgo barato, casi diría que puedo escribirlo gratis.

Buenas noches y perdón por el incendio.

PD: Puedes leer más de este flaming post en el blog de Frenética.

» Leer más, comentarios, etc...

niko's mini factory

Libros de Spring

Febrero 9th, 2005 - [Enlace local]

Al mismo tiempo que el valor de Spring comienza a ser reconocido y es adoptado en las empresas, nuevos libros hacen su aparición y ayudan al proceso.
Hasta el momento:

Spring Live (€33.60 o €23.40 digital)
Spring in Action (€23.20)
Pro Spring (€23.21)

Spring Live es para iniciarse en el framework y es un libro eminentemente "práctico", casi un tutorial de alto nivel. Y tiene la ventaja de que si compramos la versión digital, obtenemos actualizaciones y nuevos capítulos en forma periódica.
Los otros dos libros son muy recientes, pero los comentarios que he oído dicen que son de libros para usuarios mas avanzados.
Y por ahora están solamente en inglés.

» Leer más, comentarios, etc...

Argumentos variables en C/C++

Febrero 9th, 2005 - [Enlace local]

Frecuentemente me he preguntado cómo se las apañan algunas funciones como printf () o scanf () para permitir al programador realizar llamadas con una lista indeterminada de argumentos. Ayer aprendí el método en el que, al parecer, se basan para funcionar. Existe una librería de C llamada stdarg.h la cual contiene un pequeño conjunto de macros y un tipo de datos preparado para definir funciones que trabajen con listas de argumentos variables, donde nosotros en la/s llamada/s indicaremos el número de argumentos (parámetros actuales) que necesitemos. Las herramientas que stdarg.h nos aporta son:

• va_list : es el tipo de dato utilizado para declarar la variable que será utilizada con las macros que ofrece stdarg.h. Define un puntero a la lista de argumentos variable y en entornos como Dev-C++ o el compilador GCC se trata de un alias de un puntero a caracter (typedef char * va_list;).
• void va_start (va_list ap, last); : macro que se encarga de inicializar una variable pa (parámetro de argumentos) para poder utilizarla con el par de macros restantes. last es un argumento fijo que hay que pasar siempre a la función, como primer parámetro, ya que le sirve como referencia a va_start para saber dónde localizar la lista de argumentos variables (estos argumentos estarán en posiciones de memoria adyacentes a last, de ahí a que se le deba pasar siempre un argumento “estático” a la función).
• type va_arg (va_list ap, type); : macro con la que recorreremos la lista de argumentos variable. Devuelve el contenido del siguiente de estos argumentos.
• void va_end (va_list ap); : macro encargada de finalizar el uso de la variable ap previamente inicializada con va_start.

Bien, el mecanismo para emplear estas macros sin obtener resultados inesperados es básicamente siempre el mismo: lo primero de todo es declarar correctamente una función que utilizará lista de argumentos variable. Para ello se emplea un parámetro fijo inicial pasado por valor y, seguidamente, el operador especial ... (”puntos suspensivos”) que indica la lista de argumentos variable. Algo así:

tipo_f foo (tipo_p bar, ...);

Hago especial hincapie en el paso del parámetro bar puesto que como dije éste servirá de referencia a va_start para saber dónde encontrar el inicio de la lista de argumentos variable. Normalmente este parámetro fijo contendrá el número de argumentos con que la función fue llamada o, también, puede ser un puntero a la primera posición de una cadena de caracteres (como es el caso de printf () o scanf ()).

Lo siguiente es declarar una variable que sea del tipo de dato valist. Seguidamente se debe emplear vastart para inicializar dicha variable y, al final, emplear va_end. En conjunto quedaría algo así:

tipo_f foo (tipo_p bar, ...)
{
    va_list pa;
    tipo_p param;
	
    ...
	
    va_start (pa, bar);
	
    ... por aquí se podría usar va_arg -> param = va_arg (pa, tipo_p);
	
    va_end (pa);
    return;
}

Esta técnica, a priori, parece no tener demasiadas aplicaciones prácticas en la vida real. A mí al menos no se me ocurren demasiadas y, tal vez, como curiosidad está la mar de bien Aunque lo cierto es que creo que la utilización de funciones con lista de argumentos variables podría venir muy bien para procesos de refactorizaación de código fuente; para según que casos / funciones concretas que tengamos hechas tal vez pueda valer.

Es un tema interesante y seguramente no haya quedado del todo claro con mis escuetas explicaciones. Os recomiendo la lectura de un artículo muy logrado sobre el tema que justamente ayer encontré en El Rincón del Programador y con el que he aprendido a utilizar un poco este juego de macros que trae stdarg.h. El documento que digo es [ éste ] Además también se puede leer información práctica en las páginas man, [ aquí ]

Y ahora de la teoría a la práctica. Esta mañana en clase he estado jugando un poco con lo dicho anteriormente, sobre todo para afianzar lo aprendido ayer y hacer algún ejercicio chorra de prueba. El siguiente programilla lee por línea de comandos de dos a cuatro caracteres e imprime por pantalla una concatenación de ellos. Para cada número de argumentos, se utiliza una función que trabaja con una lista de argumentos variable. El código está hecho en plan guarro y, obviamente, solo sirve para liar un poco la cosa y aportar algún ejemplo algo más extraño a lo que personalmente he podido encontrar buscando por ahí (aunque, a fin de cuentas, es lo mismo).

#include <stdarg.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
	
char * get_mem (int);
char * concatena (int, ...);
	
int main (int argc, char **argv)
{
  size_t i, error = 0;
  char * cad;
	
  switch (argc)
  {
      case 3 :
        cad = get_mem (argc);
        strcpy (cad, concatena (argc, argv [1], argv [2]));
        break;
	
      case 4 :
        cad = get_mem (argc);
        strcpy (cad, concatena (argc, argv [1], argv [2], argv [3]));
        break;
	
      case 5 :
        cad = get_mem (argc);
        strcpy (cad, concatena (argc, argv [1], argv [2], argv [3], argv [4]));
        break;
	
      default :
        error = 1;
        break;
  }
	
  if (!error)
  {
    for (i = 1; i < argc; i++)
        fprintf (stdout, \"(%s) \", argv [i]);
	
    fprintf (stdout, \"-> %s\", cad);
    free (cad);
  }
  else
    fprintf (stderr, \"uso: %s car1 car2 [car3 car4]\", *argv);
	
  putchar ('\n');
  return 0;
}
	
char * get_mem (int args)
{
  char * result = (char *) malloc (sizeof (char) * (--args));
	
  if (result == NULL)
    exit (1);
	
  return result;
}
	
char * concatena (int args, ...)
{
  char * result;
  va_list pa;
	
  result = get_mem (--args);
  va_start (pa, args);
  *result = '\0';
	
  while (args--)
    strcat (result, va_arg (pa, char *));
	
  va_end (pa);
	
  return result;
}

Lo dicho, recomendado:

• Funciones en C con lista de argumentos variable

» Leer más, comentarios, etc...

niko's mini factory

El Patrón Business Methods Interface

Febrero 8th, 2005 - [Enlace local]

Un problema que tenemos al desarrollar EJBs es el de sincronizar los métodos de la interfaz local o remota con los métodos de la implementación.
Ya que la interfaz y el EJB tienen una jerarquía diferente, se da comunmente el caso en el cual la interfaz tiene una firma determinada para un método, pero el EJB otra.

Para solucionar el problema y capturar esta incoherencia en tiempo de desarrollo (en la compilación), se utiliza comunmente el patrón llamado Business Methods Interface. En este patrón la interface (local o remota) y la implementación (el EJB) implementan la misma interface (business methods).

Por ejemplo, si quisiéramos implementar ciertas funcionalidades de negocio en un EJB con interfaz local, crearíamos primero una Business Methods Interface, donde definiríamos nuestro métodos de negocio:

  public interface MyBusinessInterface {

    public void myBusinessMethod1 ( ... );

    ...

  }

y en base a ella crearíamos el EJB, con la implementación de estos métodos:

  import javax.ejb.SessionBean;

  public class ExampleEJB implements SessionBean, 

      MyBusinessInterface {

    public void myBusinessMethod1 ( ... ) {

      ...

    }

    ...

  }

y por último la interfaz local, extendiendo también de MyBusinessInterface:

  import javax.ejb.EJBLocalObject;

  public interface ExampleLocal extends EJBLocalObject, 

      MyBusinessInterface {

  }

En el caso de necesitar una interfaz remota, los métodos de la Business Methods Interface deberían lanzar RemoteException, tal como es requerido por la especificación de EJB.

De esta forma queda asegurada en tiempo de compilación la integridad de ambos componentes entre si.

» Leer más, comentarios, etc...

niko's mini factory

Inversión de Control e Inyección de Dependencias

Febrero 5th, 2005 - [Enlace local]

Gracias este post de Joaquin, me he enterado que Juan Antonio ha puesto en Java en Castellano la traducción del artículo de Martin Fowler Inversion of Control Containers and the Dependency Injection pattern.

» Leer más, comentarios, etc...

Dave Currie’s Weblog

Febrero 4th, 2005 - [Enlace local]

Os invito a echar un vistazo al nuevo blog de David Currie, un compañero de trabajo que es un crack

Este es su segundo blog, el primero lo abandonó, pero como dice el refrán castellano: “La cabra siempre tira al monte”.

En el encontraréis cosas de programación, análisis y arquitectura de software y otros temas de interés para los programadores y analistas. El blog está en inglés, que para eso es su lengua materna, pero le achucharemos un poco para que lo traduzca a español y portugués, que para eso es políglota

» Leer más, comentarios, etc...