Bienvenido a Java Mexico

Java México es una comunidad de desarrolladores mexicanos en el lenguaje Java.

Este sitio es colaborativo, automáticamente al registrarte obtienes un Blog para compartir tus conocimientos o información acerca del lenguaje. Antes de publicar en tu blog o los foros por favor lee los lineamientos de publicación.

Para dudas y problemas con respecto al lenguaje Java puedes visitar los Foros de Discusión.

También puedes responder nuestra encuesta para saber en que estado vives!

<code></code>

Utiliza <code></code> al escribir codigo en el sitio

Asi esto:

Se ve asi:

public class Ejemplo {
    public static void main( String ... args ) {
        for ( String n : args ) {
            System.out.printf("Hola %s%n", n );
        }
    }
}

Estimacion: Negociacion y la diferencia entre hacer lo correcto vs Hacerlo correctamente (Parte 4)

En ingles hay un dicho: There is a difference betwee doing the right thing and doing the thing right.
La traduccion directa seria algo asi como hay una diferencia entre hacer lo correcto y hacerlo correctamente.

En la estimacion de software, y el proceso de negociacion que es necesario para que una consultora le
construya software a un cliente la diferencia entre una cosa y la otra es tremendamente importante.

Para "Hacer lo correcto" debemos entender claramente que es lo que el cliente realmente necesita (independietemente de lo que pida), en cambio, para "Hacerlo correctamente", no es relevante si lo que hagamos realmente le va a servir al cliente o no,lo que es importante es si lo que hicimos esta bien construido.

Un ejemplo extremo:

Un cliente viene y te describe un vehiculo monoplaza de transporte, que le permita viajar a donde quiera. Tu le de construyes una bicicleta, el pensaba usar el vehiculo en alaska, en la nieve, buscaba: una motonieve.

Finalmente, no importa que te tan bien hayas construido la bicicleta (hecha correctamente) al cliente no le sirve, por que lo que el necesitaba (hacer lo correcto) era que le construyeras una motonieve.

Lanzamiento de Java EE 7 - 12 de Junio

El Lanzamiento de la plataforma Java Enterprise Edition 7 es este 12 de Junio a las 11:00 am, tiempo de México.

Será un Live Webcast donde se tendrán actividades como: Presentación, sesiones de chat para hablar de HTML 5, las necesidades empresariales o como incrementar la productividad. Además demostraciones y explicaciones técnicas por parte de los líderes de las especificaciones de Java EE 7.

El registro para el evento es aquí: http://bit.ly/19LgcY2

Estimacion: Suponer es bueno, hay que suponer todo lo posible (Parte 3)

Antes de continuar con mas ejemplos concretos de supuestos, considero importante relatarles que cuando iniciaba con desarrollo de software me tope muchas veces con esta situación:


Lider del proyecto: El cliente dijo que la caracteristica XXX no le parece util. Que no entiende por que la hicimos asi si el necesitaba otra cosa
Programador: Es que yo supuse que...
Lider del proyecto: Pues, para la proxima vez no supongas: pregunta!
Programador: Lo siento, no vuelve a pasar

Y unos dias despues:


Programador: ¿Como debemos hacer la caracteristica YYY?
Cliente: Pues, de modo tal que maximisemos la eficiencia y demos valor al negocio...
Programador: Si, pero, la multiplicidad entre productos y pedidos es uno a muchos? o muchos a muchos?
Cliente: (de que habla este compadre?) Lo siento, tengo otra junta, luego lo vemos
Programador: Pero pero...

Y finalmente:

Estimación: ¿Es asumir la madre de todos lo males? ¿o quizá es suponer? ¿o mas bien, es nuestra propia ignorancia? (Parte 2)

Hace poco lei, un tweet que decia:

¿se dara cuenta la autora... que esta asumiendo que asumir es el problema?

Estimacion: Por que estimamos (Parte 1)

Hay quienes consideran que estimar es imposible y una perdida de tiempo, una inutilidad, hay quienes consideran que si puede hacerse, pero solo bajo ciertas condiciones y hay quienes piensan que el secreto en seguir un cierto método... Sin embargo yo quisiera antes de platicar al respecto de dichos puntos de vista, centrarme en una pregunta a menudo omitida en los artículos y libros de estimación:

Por que estimamos? Y no hablo de por que en el sentido teórico que típicamente se utiliza en los libros del tema, si no de, afuera, en el mundo real. No quisiera generalizar, asi que lo que diré a continuación lo digo acotado únicamente a mi experiencia.

No estimamos para saber cuanto tardara el proyecto, el cliente generalmente ya estableció un deadline que difícilmente moverá.

Por que estimamos entonces? Estimamos para ver si podemos hacer algo que quepa dentro del tiempo y presupuesto que ya están establecidos y que le suene al cliente a lo que pidió (por que si algo es cierto es que la mayoría de los clientes no sabe realmente lo que quiere hasta que no se le han hecho un par de demostraciones de avance )

El lenguaje de programación (casi) perfecto

1. Cero frameworks

Depender de un framework muchas veces no es nada bueno. Algunos dejan de ser actualizados o de plano dejan de existir. O la documentación es minima o nula.

Que el lenguaje tuviera lo necesario para crear aplicaciones web o de escritorio.

2. Documentación automática

Nos gusta tener (más no leer) documentación completa del lenguaje/proyecto que vamos a usar/modificar. Si al terminar de escribir nuestro código se generará la documentación de manera automáticamente mejor aun.

3. Manejo de dependencias

Algo así como @Grapes de Groovy, el programador solo se preocupa de escribir el código. Nada de andar viendo que librería o clase le hace falta a su proyecto.

4. Generador de pruebas automático

Al terminar de escribir el código se crearan las pruebas unitarias de manera automática. Aunque tal vez seriamos más flojos y dependientes.

5. Un IDE integrado

No tener la necesidad de instalar alguno. Que el lenguaje no tuviera tan solo el compilador sino también un editor de código.

Ejemplo de un equipo de fútbol

Pongo esto aquí por si a alguien le sirve.

import java.util.Scanner;

class Equipo {
    private String nombre;
    private int juegosJugados;
    private int juegosGanados;
    private int juegosEmpatados;
    private int juegosPerdidos;
    private int golesFavor;
    private int golesEnContra;

    public int calcularPuntos() {
        return juegosJugados * 3 + juegosEmpatados;
    }
    public int calcularBono() {
        return calcularPuntos() * 100
        + golesFavor * 500
        - juegosPerdidos * 500
        + (juegosJugados % 2 == 0 ? 5000 : 0);
    }
    public String toString()  {
        return String.format("Nombre: %-20s, Bono: %-10d, Puntos: %-10d", nombre, calcularBono(), calcularPuntos());
    }
    public static Equipo creaEquipo( String nombre, int jj, int jg, int je, int jp, int gf, int ge ) {
        Equipo e          = new Equipo();
        e.nombre          = nombre;
        e.juegosJugados   = jj;
        e.juegosGanados   = jg;
        e.juegosEmpatados = je;
        e.juegosPerdidos  = jp;
        e.golesFavor      = gf;
        e.golesEnContra   = ge;
        return e;
    }

}

JSE - Ejemplo básico de inyección de dependencias con CDI, DeltaSpike, Weld; persistencia: Batoo JPA con H2,Transacción incluida

Bueeeeeno... pues resulta que andando de ocioso, quise hacer algo en JSE que incluyera algo de inyección de dependencias. Estuve viendo opciones y me pareció buena idea hacer algo con CDI (de spring hay hartos ejemplos) y las casi recién nacidas extensiones de Apache Delta Spike y para la parte de persistencia, vagando por las internetes me encontré con Batoo que clama ser mucho más rápido que Hibernate (éso es ooooootro tema) y pues decidí incluirlo para mi ejemplo, para la base de datos usé H2; manos a la obra:

De entrada, como acá en el trabajo no puedo usar Maven, tuve que bajar y configurar todo casi a mano, la lista de jars queda así:

-guava-14.0.1.jar
-commons-lang-2.6.jar
-validation-api-1.0.0.GA.jar
-bonecp-0.7.1.RELEASE.jar
-h2-1.3.171.jar
-commons-dbutils-1.5.jar
-commons-io-2.4.jar
-asm-3.3.1.jar
-deltaspike-cdictrl-weld-0.3-incubating.jar
-deltaspike-core-api-0.3-incubating.jar
-deltaspike-core-impl-0.3-incubating.jar
-deltaspike-jpa-module-api-0.3-incubating.jar
-deltaspike-cdictrl-api-0.3-incubating.jar
-deltaspike-jpa-module-impl-0.3-incubating.jar
-weld-api.jar
-weld-spi.jar
-weld-se.jar
-batoo-annotations-2.0.1.0-RTM.jar

WaveMaker para la gente que les gusta los RADs

Aqui les dejo Wavemaker una herramienta de desarrollo agil para generar aplicaciones web con spring, hibernate y algunas otras monerías incluidas, es bastante sencillo su entorno ademas de que produce aplicaciones standard, .war que se pueden entregar en la nube mediante cloudfoundry o en servidores locales dentro de splices containers, la verdad es que esta bastante sencillo de utilizar, existe una comunidad en latica bastante buena, existe documentación en videos, tiene sus limitaciones pero para aplicaciones que requieran ABCE es bastante bueno, les recomiendo le echen un vistazo.

Distribuir contenido