Creación de un paquete de servicios web para un modelo de datos JAVA

Una vez creado nuestro paquete con la aplicación Java para interactuar con los servicios web como hemos visto en la lección anterior, vamos a realizar las tareas que habíamos dicho paso por paso. Es decir, vamos a crear un servicio web con una operación para añadir un usuario con su nombre de usuario, password, un nombre de piloto y una nave con su cantidad de armamento, otro para obtener una lista de usuarios con pilotos y naves y otro para hacer un login con usuario y password, para ello:

CREAR DIRECTORIO DE XML:

  1. Dentro de las propiedades del Proyecto Java Web “Excalibur” en la categoría de Sources  -> Package Folder -> Add Folder -> creamos el directorio “XML” dentro de “src” y de etiqueta (label) ponemos “XML”. Aquí vamos a colocar nuestros ficheros WSDL para ver como se construyen servicios web a partir de estos, pero primero el método sencillo…ahora se puede añadir al esquema de forma gráfica cualquier dato y se formatea por el sistema ,podemos crear un servicio web a partir del fichero…

CREAR SERVICIO WEB

  1. En el paquete “es.ugr.battlegalactica.servicios” -> botón derecho  -> New -> Web services -> Web Service -> “construccionNexus”. Añadir el constructor de la clase y la variable estática Nexus nexus de ésta clase, que se incializa en dicho constructor…

CREAR OPERACIÓN PARA AÑADIR UN USUARIO CON SUS PILOTOS Y SUS NAVES ASOCIADAS

  1. Segundo botón en el código dentro de la clase “construccionNexus” -> “Insert Code…” -> “Add Web Service Operation” -> le llamamos “crearUsuarioConPilotosYnaves”
  2. En return type (tipos devueltos) ponemos java.lang.Long y así, si es -1 ha ocurrido un error y en otro caso es el ID del nuevo usuario
  3. Para los parámetros necesitamos que tenga: un nombre y password de usuario,un nombre de piloto  y un nombre de nave; por lo que empezamos por añadir el primer campo con name: “datos_usuario” , type: Choose -> find type -> buscamos “usuario” y seleccionamos el del modelo de datos de BSGModelo, ahora hacemos lo propio para “datos_piloto” -> Piloto y “datos_nave” -> Viper. Pinchamos en “OK” y se genera el código en Java, sólo hemos de meter los datos correspondientes que nos pasa tan amablemente el servicio web a la base de datos de Nexus ,tal como hacíamos en Prueba.java…
    la función de la operación debe quedar así:

    @WebMethod(operationName = "crearUsuarioConPilotosYnaves")
    public Long crearUsuarioConPilotosYnaves(@WebParam(name = "datos_usuario")
    Usuario datos_usuario, @WebParam(name = "datos_piloto")
    Piloto datos_piloto, @WebParam(name = "datos_nave")
    Viper datos_nave) {
     
    if (nexus.obtenerUsuario(datos_usuario.getUsuario())!=null ){
    //El usuario ya existe, salir!
    return new Long(-1);
    }
     
    //Añadir Viper
    Viper v  = null;
    try { //Buscar viper:
    v = nexus.obtenerViper(datos_nave.getNombre());
    } catch (ViperNoEncontradoException ex){
    //La nave no existe, la añadimos
    v = new Viper(datos_nave.getNombre());
    v.setArmamento(datos_nave.getArmamento());
    } finally {
    //En otro caso, la nave es la misma?
    if (!v.getId().equals(datos_nave.getId())){
    //No es la misma, error
    return new Long(-1);
    }
    }
     
    //Añadir piloto:
    Piloto p = null;
    try {
    p = nexus.obtenerPiloto(datos_piloto.getId());
    } catch (PilotoNoEncontradoException ex){
    //NO Existe el piloto, crearlo
    p = new Piloto(datos_piloto.getNombre(), datos_piloto.getDestreza(),
    v.getId());
    nexus.guardarPiloto(p);
    } finally {
    //El piloto existe, tiene la misma ID?
    if (!p.getId().equals(datos_piloto.getId())){
    return new Long(-1);
    }
    }
    ArrayList<Long> lista_pilotos = new ArrayList<Long>();
    lista_pilotos.add(p.getId());
     
    //Añadir el usuario con los datos almacenados ya en Nexus:
    Usuario u = new Usuario(
    datos_usuario.getUsuario(),
    datos_usuario.getPassword(),
    lista_pilotos );
     
    nexus.guardarUsuario(u);
     
    return u.getId();
    }

    Para probarla primero hacemos click con el segundo botón del ratón en el proyecto Excalibur > Deploy ,esto instalará la aplicación web con la nueva operación compilada, ahora vamos a la lista de servicios web y pulsamos en test Web Service, ya podemos añadir usuarios con un piloto y una nave

CREAR OPERACIÓN PARA HACER UN LOGIN CON USUARIO Y PASSWORD

  1. Una vez creado un usuario en la base de datos la función para hacer un login es tan simple como esta:
    @WebMethod(operationName = "hacerLogin")
    public String operation(@WebParam(name = "usuario")
    String nombre_usuario, @WebParam(name ="password") String contrasena) {
    //TODO write your implementation code here:
    Usuario u = nexus.obtenerUsuario(nombre_usuario);
    if (u==null) return "El usuario no existe";
    else if (u.getPassword().equals(contrasena)){
    return "Acceso concedido";
    } else {
    return "Contraseña inválida";
    }
    }

    Recordar que para testear los servicios podemos hacerlo en SOAP UI:

CREAR OPERACIÓN PARA OBTENER UN LISTADO DE USUARIOS

  1. Es simplemente crear un listado a partir de recorrer el array de estos y devolverlo para que lo analice sintácticamente el sistema y devuelva la construcción XML correspondiente:
    public List<Usuario> listadoUsuarios() {
    List<Usuario> listado = null;
    for (Iterator<Usuario> iter = nexus.listarUsuarios(); iter.hasNext(); ){
    listado.add(iter.next());
    }
    return listado;
    }

Buenas prácticas de programación: Los servicios web son un tipo de comunicación, añadir lógica de programación resulta en algo no-generalizable y por lo tanto ,no reutilizable. Resumiento: hay que hacer una conversión de los datos de un modelo de datos en un modelo de datos de un servicio web,i.e.,las clases con su lógica de programación en Java a un modelo del servicio y luego el paso inverso. Entre medias están las páginas web u otros clientes que los utilizan con su propia lógica. Por ello se recomienda diseñar los servicios web lo último, cuando ya tenemos todo lo que necesitamos en cuanto a datos y lógica interna con ellos, separar cada fichero WSDL para cada servicio es recomendable por si necesitamos cambiar algo y nos cuesta menos trabajo.

CREAR CLIENTES PARA CONECTARSE A LOS SERVICIOS WEB

  1. En el proyecto “Excalibur” creamos el paquete “es.ugr.battlegalactica.servicios” y dentro de este -> segundo botón del ratón-> New -> Other -> Web Services -> Web Service Client -> seleccionamos del proyecto “Excalibur” el Servicio Web “construccionNexus” -> OK ; y ahora en package ponemos “es.ugr.battlegalactica.clientes”. Esto debe crearnos todas las clases Java para comunicarse con las operaciones del Servicio Web. Pero para saber que funcionan usamos un JUnit Test , creamos un paquete llamado “es.ugr.battlegalactica.clientes” y dentro un nuevo JUnit Test para clases existentes, elegimos la clase a testear y hacemos como en la primera lección las unidades de prueba.

< Volver al curso de Arquitectura de Servicios Web con JAVA y PHP

Embeber clases de C++ como una extensión de PHP usando Zend

Vamos a ir un poco más lejos que la última vez cuando analizábamos la gran ventaja de usar el lenguaje C++ frente a PHP, por su potencia al estar compilado para la máquina, en lugar de interpretado como PHP, sobre todo a la hora de usar algoritmos que requieren de un tiempo de ejecución mayor, a pesar de que, su orden de ejecución no es muy elevado; al cambiar de tecnología se nota demasiado.

En este caso vamos a echar mano del framework de la empresa Zend que casualmente se utiliza en Magento como base y alguna otra tienda ( soloprecios.es ) también,… este artículo de la zona de programadores de Zend Framework, nos recomienda primero echar un vistazo al manual para escribir una extensión…, en este punto, quizás , os decantéis por olvidaros de Zend y queráis echar un vistazo a la herramienta que usan en FacebookHiHop, sinceramente os recomiendo leer  los informes de las unidades de prueba realizadas por Sebastian Bergmann primero.

En el artículo de paulosman, se explica cómo configurar el makefile (para compilar C++) para que se incluya la extensión de PECL con phpize , además es tan apañao que incluye incluso una macro para hacer la llamada a la función ZEND_GET_MODULE() que necesita el framework para asociar la clase con PHP, tras realizar estos pasos podemos usar :

 php -d"extension=nombre_de_mi_extension.so" -m

para añadir la extensión recién compilada (tras usar phpize y make) a Apache u otro servidor (con Zend) ,ahora que tenemos el esqueleto básico de dicha extensión cargada en el servidor, el sistema de construcción de PHP sabe que tiene que compilar las clases C++ (definidas e implementadas fuera de la extensión) que se sincronizarán por medio de los objetos en C++ de Zend y la función externa ZEND_GET_MODULE(nombre_de_mi_extension)

¿Alguna duda?, aquí estamos…

Presentación: xUnit y JUnit – Diseño de Software Orientado a Objetos

Charla que dí para la asignatura Diseño de Software Orientado a Objetos de la Universidad de Granada en el año 2007

Algunos consejos para mejorar como arquitecto de aplicaciones web

Leyendo por Internet he encontrado a un experienciado programador llamado Jim Plush que nos habla en su blog (donde demuestra que es un fanático de todo lo Zend) sobre lo que deberíamos conocer para mejorar siendo programadores web [de php o lo que sea].

Vamos a poner estos consejos para mejorar como arquitecto de aplicaciones web en modo lista:

  • Conocer qué ofrecen las versiones de PHP 4 y 5 , conocer las mejoras de la versión 6:
    En la versión 4 existe la posibilidad de especificar en las declaraciones de las funciones y operaciones de clases, las variables por referencia o por valor, esto se hace siempre por referencia a partir de la 5, en esta además se pueden especificar partes públicas y privadas en las clases además de poder usar el patrón Singleton y autocarga de clases, la versión 6 añade Unicode para nombrar clases, variables y funciones de la tabla de símbolos, y eliminan register_globals, magic_quotes y safe_mode, y atención : paso por referencias peligroso!
  • PHP, ASP.NET y Ruby on Rails, cuándo es mejor utilizar uno u otro lenguaje y sus tecnologías directamente asociadas que implican también otra forma de pensar y actuar frente a los problemas que puedan ocasionarse…
    Si vas a construir un sitio que necesite ser escalable y muy grande (una gran red social o una tienda que vaya a sufrir muchísimos cambios) entonces es mejor utilizar RoR, en otro caso, si necesitas un lenguaje con el que construir una aplicación web puedes usar PHP o ASP, el segundo es más fácil para los que les gusta diseñar con un IDE y el primero para los que quieren tener un motor potente de un gestor de contenidos o hacerlo todo desde cero o con un framework de aplicaciones rápidas…
  • Ser capaz de realizar programas con sockets para implementar servicios (ftp, telnet, etc.)…un programa con sockets puede ser un plugin de WordPress que haga fetching (algoritmo capturador de contenidos) desde una URL, esto lo publicaré en futuro no muy lejano, mientras podéis ver un ejemplo de programación con sockets en PHP
  • Programación Orientada a Objetos: POO
    + por qué especificar un método como privado o público
    + conceptos que son útiles de conocer: interfaces, constructores, destructores, private-public-protected, herencia, polimorfismo, métodos estáticos, etc.
  • Bases de datos: conocer qué es la normalización de base de datos y como exportar/importar esquemas de bases de datos con XML (además de saber como comprimir una base de datos con ZIP o GZIP y enviarlo por mail como adjunto)…ejemplo, además es imprescindible antes de empezar a crear las tablas, hacer nuestro diagrama de E/R
  • Patrones de diseño
  • Control de código fuente (SVN, CSV, etc): esto sirve sobre todo para trabajar en equipo y mantener un control sobre los cambios que vamos realizando en nuestro código fuente (usaremos OHLOH)
  • Unit Testing o Pruebas de Unidad
  • Ser parte de la Comunidad, participar en foros, debates, ayudar a extender los conocimientos, contribuir con algún proyecto aunque sólo sea traduciéndolo a tu idioma…OsCommerce, OpenCMS, Joomla, WordPress, etc.
  • Habilidades con JavaScript, conocer los framework JS existentes (JQuery,  Prototype, MooTools, Dojo, ext,etc.) y hacer ejemplos donde arreglar los problemas de compatibilidad entre ellos…
  • Habilidades con CSS (utilizar CSS dinámico): diseñar online el esqueleto XHTML+CSS de una web
  • Conocer el modelo de caja y cómo AJAX  “encaja” perfectamente en esto :)
  • Saber qué es y como se contruye un sistema gestor de contenidos
  • Usabilidad y Arquitectura de la Información
  • Integrar las redes sociales en nuestra aplicación: login, registro, etc, con facebook, gmail, twitter, menéame, (sharethis),etc.
  • Conocer las herramientas de ayuda para el arquitecto integrables en el navegador: firebug ( y derivados ) ,selenium, etc.
  • Pasión por mejorar (ganar amigos e influenciar para generar más conocimientos que compartir)

Para los avanzados que ya han superado todos los puntos anteriores también tenemos los siguientes:

Patrones de diseño: Elementos reutilizables para la web

La Ingeniería del Software aplicada a la web requiere una inversión inicial para “hacer las cosas bien”, mientras más vueltas a la cabeza le das a un problema, más manejo cogemos para solucionarlo en un futuro, además de mejorar nuestro ingenio y agudizar nuestras habilidades.

Desde hace mucho tiempo que programamos en PHP o cualquier otro lenguaje al nivel del software Orientado a Objetos, para este artículo he utilizado como bibliografía el libro “Design Patterns” de la élite-grupo formada por: Erich Gamma, Richard Helm, Ralph Johnson y John Vlissides de la editorial Addison Wesley. Es más, en la mayoría de enlaces que pongo a la Wikipedia se copian literalmente (bueno no literalmente porque se traducen del inglés al español) toda la teoría de este libro, directamente. Ahora además , ¡veremos la parte práctica!

¡¡Pero primero, …un poco de teoría!!

 

 

 

 

 

Ya os estaréis preguntando de qué demonios va esto de los patrones de diseño y cómo los podemos utilizar en la construcción de una aplicación web para hacer el proceso, si cabe, más divertido :] …para explicarlo, se debe de conocer primero qué es un patrón de diseño, concretamente deberíamos conocer el Modelo-Vista-Controlador o bien,MVC, alguna de sus variantes y, llegado este punto, recordar lo que es un catálogo de patrones de diseño, a los que pertenecen los siguientes:

  • Abstract Factory (patrón de diseño): provee de una interfaz (una clase) para crear familias de objetos relacionados o dependientes sin especificar sus clases concretamente
  • Adapter (Adaptador): convierte la interfaz de una clase en otra permitiendo a ambas trabajar juntas, las hace compatibles.
  • Bridge (o Handle/Body) – enlace : desacoplar una abstracción de su implementación, así, ambas pueden variar independientemente, i.e., para poder conectar una abstracción con diferentes implementaciones de forma transparente.
  • Builder (constructor): separa la construcción de un objeto complejo de su representación de forma que el mismo proceso de construcción puede crear diferentes representaciones.
  • Chain of Responsibility (cadena de responsabilidad) : permite la posibilidad de que un objeto que envíe una petición a más de un receptor, con un criterio establecido que funciona como una cadena.
  • Command (petición de operación): encapsula una petición como un objeto, así le es posible parametrizar clientes con diferentes peticiones, hacer una cola o guardar un registro de peticiones y solventar posibles operaciones que se puedan deshacer.
  • Composite (constructor de objetos complejos): compone objetos en tres estructuras para representar parte o toda una jerarquía. Permite a los clientes tratar objetos individuales y composiciones de objetos uniformemente.
  • Decorator: adhiere dinámicamente funcionalidades adicionales a un objeto, proveyendo así una alternativa flexible a las subclases para extender la funcionalidad.
  • Facade: provee de una interfaz unificada a un conjunto de interfaces en un subsistema de aplicaciones web, definiendo una interfaz de alto nivel que hace al subsistema fácil de usar.
  • Factory Method: define una interfaz para crear un objeto, pero permite a las subclases decidir qué clase instanciar.
  • Flyweight: compartir para soporte eficiente de un amplio número de objetos granulados finos (Granularidad: Grado de especificación de la información que contiene un elemento de datos. Una tabla de hechos de granularidad fina contiene muchos hechos discretos )
  • Interpreter: Dado un lenguaje, define una representación de su gramática acompañada de un intérprete que usa la representación para interpretar sentencias en el lenguaje
  • Iterator: provee de una forma de acceder a los elementos de un objeto agregado secuencialmente sin exponer su representación subyacente
  • Mediator: define un objeto que encapsula la forma en la que un conjunto de objetos interactúan. Es decir, coordina la relación entre sus asociados y permite su interacción independientemente
  • Memento: sin violar la encapsulación, captura y externaliza el estado interno de un objeto para poder restaurar dicho estado en otro momento


  • Observer (observador): define una dependencia “de uno a muchos” entre objetos de forma que cuando un objeto modifica su estado interno, todos sus dependientes son notificados y actualizados automáticamente
  • Prototype: clona objetos, se especifica que tipos de objetos crear usando un instancia prototipo, después se crean nuevos objetos copiando a este
  • Proxy: provee de un substituto único (subrrogate o placeholder: parámetro de substitución) para controlar el acceso a otro objeto
  • Singleton: asegura que una clase sólo tenga una instancia, además provee de un punto global de control de acceso a este
  • State: permite a un objeto alterar su propia “conducta” cuando su estado interno cambia, es decir, puede cambiarse de clase como de piel
  • Strategy: define una familia de algoritmos, encapsulando cada una y haciéndolas intercambiables; Permite que el algoritmo varíe independientemente de los clientes que lo usan
  • Template Method: define el esqueleto de un algoritmo en una operación, delegando algunos pasos a subclases de forma que estas pueden redefinir ciertos pasos de un algoritmo sin cambiar la estructura del mismo
  • Visitor: representa una operación que debe ser llevada a cabo sobre los elementos de la estructura de un objeto. Permite definir una nueva operación sin cambiar las clases de los elementos con los que opera

Organizando el catálogo

Ahora que conocemos el contenido del catálogo de los patrones de diseño, debemos saber más acerca de su espacio, es decir, a qué ámbito, qué propósito tienen, donde enmarcarlos en definitiva a la hora de utilizarlos. Como hemos visto en sus descripciones, hay objetos y clases, algunas clases son abstractas, por lo que necesitan ser construidas desde otra clase que sí se puede instanciar y que hereda de la primera sus características. En el caso de las clases , según su propósito tenemos para crear contenido el patrón Factory Method, para estructurar el mismo elegimos el Adapter (Adaptador) y como comportamiento los patrones de diseño de clases: Interpreter y Template Method.

Sin embargo, a la hora de seleccionar qué patrones de diseño utilizar para enfocar los objetos, encontramos para el apartado creativo los patrones: Abstract Factory, Builder, Prototype y Singleton; en cambio, para el estructural : de nuevo podemos coger al Adaptador, Bridge, Composite, Decorator, Facade, Flyweight y Proxy. En el caso de los comportamientos de los objetos: Chain of Responsability, Command, Iterator, Mediator, Observer, State, Strategy, Visitor.

¡¡Pasamos a un ejemplo práctico!!

Un ejemplo de software libre que usa patrones de diseño para comunicar un servicio de vídeo de Flash con un objeto Flash incrustado en un HTML con comunicación asíncrona por XML (con AJAX) es AMFPHP, un ejemplo de profesionales utilizando patrones de diseño en una aplicación Flash con esta plataforma es: Digital Tutors.

Ahora que somos unos amos de los patrones veamos un ejemplo, saber cuáles de ellos nos harán falta es sencillo, para este ejemplo vamos a construir un generador de formularios, como por ejemplo el de Fabrik, en PHP.

Para empezar necesitamos una clase principal que utilice el patrón Singleton, para ello lo único que tenemos que hacer es crear una clase llamada Singleton (en un alarde de imaginación) con una variable estática llamada instancia y comprobar en la función constructor si dicha variable está vacía, entonces creamos una instancia de la clase Singleton que almacenamos en aquella, en otro caso no,evidentemente…aunque, personalmente, prefiero guardar punteros (pese a que dicha práctica no se continúe en PHP5 y 6 [deprecated]), echad un vistazo a este framework.

Ahora que tenemos una clase principal (usando el patrón Facade para poder crear una clase para presentar el contenido y otra para administrarlo) , $web, vamos a asignarle un modelo de datos del patrón MVC modificado con el uso del patrón Composite, en este caso es una clase llamada $formularios,  y su vista (o visualizador) asociémosla a la anterior y llamémosla clase $html_formularios, sirve de conexión con las plantillas HTML de modo que usaremos un patrón Bridge como controlador incrustado en el visualizador o vista, así, se pueden crear distintas implementaciones para controlar las acciones de los formularios generados, ejemplo: al enviar un formulario para almacenar datos en la base de datos que se apliquen distintos filtros a cada campo. Dichos campos siguen el patrón Abstract Factory, y para pasar de un tipo a otro, por ejemplo de un tipo campo de texto a un tipo área de texto (<input type=”text”/> a <textarea/>) utilizamos un patrón Adapter, evidentemente, para construir los campos usamos un Builder.

Esta clase abstracta Builder debe encargarse de crear las reglas de actualización de estados, es decir, de las dos posibilidades que hay: notificar automáticamente a los objetos asociados cuando el estado interno de un campo cambia o dejar que el usuario lo haga, tomamos la primera para evitar dar más trabajo al programador y realmente no es mucho más ineficiente hacer las notificaciones automáticas puesto que no hay demasiados objetos en un formulario que dependan de otros y además tenemos las reglas en cascada del sistema de base de datos (llaves externas). La clase Builder se llama dentro de cada constructor de cada Modelo de Datos y se denomina $constructor, que toma los campos que lee el Modelo de datos de la base de datos y construye las Chain of Responsibility en función de su esquema de llaves (Foráneas o ExternasPrimarias) ,para construir dicho esquema podéis usar la herramienta de vuestro motor de sistema de base de datos. En mi caso uso MySQL Workbench, aquí un ejemplo con activadores (triggers): revisión 1. Finalmente, la relación queda almacenada en una estructura de datos de la clase del Modelo de datos y en este caso usamos un funciones aunque lo mejor sería hacerlo con otra clase que encapsularíamos mediante el patrón Command o incluso podríamos usar un patrón Decorator para hacer lo mismo que hago en mi caso pero añadiendo las funcionalidades extra en los objetos.

Para crear los formularios asociados al modelo de datos donde se recogen un conjunto de campos se puede utilizar un patrón Factory Method, de modo que usaremos Iterators y Mediators para conectar $formularios asociados a la clase principal $web con las clases del patrón Factory Method, así, usando la configuración de un esquema de formulario (aquí se puede usar el patrón Strategy) almacenado en la base de datos podemos matener una correlación con los datos insertados por los usuarios de forma transparente e inteligente. Para mostrar dichos datos usaremos Visitor de forma que se pueden mostrar datos en distintos formatos sin modificar el visualizador del MVC. Si en nuestra administración queremos poner un comando deshacer, podemos asociar un patrón Memento, pero debe de estar unido a un patrón Observer, para que cuando un campo cambie, cambie los formularios asociados a este así como los campos que son interdependientes, ejemplo: un listado de pacientes de un hospital, si cambiamos en una hoja del historial el tamaño de su campo Nombre o el contenido del mismo, (además de actualizarse en cascada por el esquema de la base de datos) debe notificarse al resto de objetos implicados.

 

La intención de este post es comenzar con la primera iteración en el proyecto para construir webs usando Ingeniería del Software sin tener que perder tiempo de desarrollo, sino, más bien, haciendo las cosas bien desde el principio y para que las próximas veces ni tan siquiera tengamos que preocuparnos por la base para empezar a implementar la web.

 

 

 

Para la versión JavaScript y JQuery de los patrones de la web usad el siguiente libro.

* Actualización (Junio 2011): Libros recomendados en este servidor: Code as Design de Jack Reeves – Presenta la noción de que la programación es fundamentalmente una actividad de disco y que solo al final como representación de este diseño se encuentra el código en sí mismo. Y el otro libro es : Managing the Development of Large Software Systems de Winston Royce – ilustrativo documento donde se explica genialmente el proceso de diseño de software tal como debería ser el ciclo de desarrollo como una cascada de agua “waterfall”.


¿Por qué usar Unit Tests?

Si os haceis preguntas sobre la diferencia al construir aplicaciones web entre un ingeniero informático y un informático que ha estado estudiando en el nivel de Formación Profesional o un Ciclo Formativo Superior, éstas  se encuentran en la escalabilidad y eficiencia de un sistema de aplicaciones. Hay quien dice que una aplicación de escritorio no tiene mucho que ver con una aplicación web, pero lo cierto es que cada vez más, estas últimas van substituyendo a las primeras,  y sino, mirad los últimos paquetes de programas de Google o Microsoft.

Hablando con profesionales de la programación de Microsoft he comprendido la importancia de tener una educación universitaria para realizar el mismo trabajo con la habilidad de un ingeniero y no cabe duda que el trabajo de los ingenieros y doctorados de Google es bastante bueno…

Para explicarlo pondré un ejemplo: las unidades de prueba o también conocidas en inglés como Unit Test. Normalmente , la gente de Microsoft no suele hacerle mucho caso a las prácticas de la Ingeniería del Software, de hecho, conocí a una eminencia de la programación de Microsoft una vez en una presentación que expuso, le pagaban por dar charlas sobre .Net en las Universidades, en los Microsoft University Tours; tenía una gran pasión por lo que hacía, escribió un libro…y precisamente uno de los profesores de mi Escuela de Informática lo tenía y lo había estado analizando…casi todas las páginas contenían comentarios sobre errores comunes de la teoría de la programación, eficiencia en tiempo y en espacio, escalabilidad, elegancia del código, …un horror…

Así que no me extrañó cuando leí un artículo que se anunciaba como “It’s OK Not to Write Unit Tests!“, donde su autor, Chris, empleado de Microsoft, dice que Unit Test sólo es un test, una prueba…bien, esto es un error, una unidad de prueba no sólo sirve para ver que una refactorización ha funcionado, para conseguir encontrar bugs o mejorar el diseño inicial en cualquiera de sus fases; porque esto es una forma de intentar economizar esfuerzos a vistas de la empresa para demostrar que hemos perdido mucho tiempo a causa de un motivo sólido: la creación de estas unidades de prueba. Sin embargo, no menciona por ningún lado que sirve para probar que el programa responde como se espera en todos los casos, i.e., desde el caso base a cualquiera de las opciones que necesitan de una entrada y una salida.

En el IV Concurso Universitario de Software Libre (donde presenté 3 proyectos consecutivos: MüchiGame, zenphp y PIE) se está debatiendo intensamente sobre si la Ingeniería del Software es necesaria vesus la necesidad de ganar dinero vendiendo productos versus la necesidad de un Colegio de Informáticos que certifiquen dichos productos como de calidad así como asignar un responsable para el diseño del mismo.

En cualquier caso, hace un tiempo escribí sobre cómo mejorar las prácticas de la Ingeniería del Software orientado a aplicaciones web, además de cómo hacer Unit Tests, concretamente con PHP.

Aquí os dejo un pdf para aprender a usar PHPUnit:

practicad mucho!
footer
jbelon © | sitemap.xml