Este blog está orientado a toda la gente que quiera ver y participar en temas de ing. de software, TI, redes y otras áreas de la computación.

miércoles, mayo 24, 2006

¿Quieres aprender JAVA?

Estudiando JAVA para realizar proyectos personales me encontré con este libro:

Java For Artists: The Art, Philosophy, and Science of Object-Oriented Programming
by Rick Miller and Raffi Kasparian
ISBN: 1932504052

La verdad quedé sorprendido. Este libro habla de muchos temas interesantes como el paradigma de Programación Orientada a Objetos, de las diferentes metodologías para crear sistema completos, Extreme Programming, entre otros. Lo que hace a este libro excepcional es que esta dirigido a estudiantes de carreras como Ing. en Sistemas, Electrónica o cualquier otra en que necesites programar. El material que provee es avanzado pero ya quisiéramos muchos habernos encontrado con un libro dirigido a estudiantes que tocara estos temas. El autor explica todo tan sencillo que hace que los temas ya no luzcan tan avanzados o complejos. La verdad hace ver a muchos tutoriales, libros y sitios oficiales un poco rolleros e inalcanzables.
Ya sea para aprender algo nuevo o reforzar tus conocimientos, te recomiendo le des una checada a este libro. Para aquellos que tienen cuenta en www.books24x7.com ahí lo pueden encontrar.

martes, mayo 16, 2006

Introducción a ASP.NET – Formularios Web

Quiero mostrarles como funcionan los formularios Web y algunas de sus características. Primero vamos a crear un proyecto de Web utilizando Visual Studio .NET. Bajo el menú principal de File -> New -> Project se encuentra la opción de ASP.NET Web Application. Aquí Visual Studio nos pregunta por un directorio virtual en vez de una ruta física ya que estamos trabajando con un sitio Web. Esto es interesante porque como podemos ver ya de un inicio estamos trabajando bajo un ambiente Web y se nota que todo va encaminado a que funcione en Internet.



Lo primero que nos damos cuenta al ver nuestra pantalla es que aparece una forma muy parecida a la que sale cuando creamos una aplicación de Windows. En un proyecto de Web este control se llama Web Form.
Dibujar una forma es tan sencillo como arrastrar controles a donde se requieran y acomodarlos con el ratón. Solo arrastrando controles (es decir, sin tener que codificar aun nada) podemos dibujar una forma así:


Si nos fijamos bien, hay una pestaña que dice HTML abajo del lado izquierdo. Si nos vamos ahí podemos ver mucho código parecido al lenguaje de marcación HTML. Esto no es solamente lenguaje de HTML sino que tiene etiquetas de controles de asp. Como podemos ver, Visual Studio se encargo de poner el código necesario para mostrar nuestro formulario.



Pero ¿qué es lo interesante de esto? ASP.NET divide una página Web en dos archivos distintos. Uno de presentación (Es el que hemos estado viendo y consta de las pestañas: diseño y HTML) y otro del código para poder visualizar y manipular los controles. Cada archivo es único e interactúan entre sí.
El archivo de presentación es en realidad una página HTML en formato XML, y etiquetas de ASP.NET. Estas etiquetas se utilizan para asignar a cada control de ASP.NET (como una caja de texto, etiqueta de texto, botón de radio, etc.) sus propiedades y localización en la página Web. Cuando un cliente o explorador solicita una página Web, ASP.NET se encarga de reemplazar las etiquetas por los controles verdaderos de HTML y regresarlo en forma de página Web al explorador del cliente. Esto sirve para que ASP.NET pueda identificar el tipo de Explorador usado por el cliente y mandarlo adecuadamente para que la página sea compatible 100% con el cliente.
En el archivo de código se escribe toda la lógica de la página Web. Aquí se escriben las acciones o eventos de cada control. Como podemos ver, el tener 2 archivos separados evita el código mezclado y nos ayuda a tener separada el código lógico de lo gráfico.
Si vienes de desarrollar en ASP clásico o alguna vez tuviste que crear una página Web en ASP a mano, podrás apreciar todas estas características y regocijarte por todo el tiempo extra que te va a quedar utilizando Visual Studio y las ventajas proporcionadas por ASP.NET.

Introducción a ASP.NET – ASP vs ASP.NET

Empecé a escribir acerca de Web Services pero me di cuenta que va ligando con ASP.NET. ASP.NET es muy extenso e importante porque abarca casi todo lo necesario para hacer proyectos de Web con el framework de .NET.
Veamos de donde viene esta tecnología. Hace ya algunos años atrás cuando el auge del Internet iba creciendo y creciendo, los desarrolladores de aplicaciones se vieron con la necesidad de crear o traspasar sus aplicaciones a Internet.
La primera opción que funcionó fue cuando Microsoft sacó el producto Visual InterDev. Este permitía crear páginas Web que contenían código para ser ejecutado por el Internet Information Server (IIS). Estas aplicaciones debían ser instaladas en el servidor para que cuando un explorador (Internet Explorer, Netscape, etc.) hiciera una petición de ejecución al servidor, este procesara la aplicación y regresara el resultado al explorador. Estos fueron los inicios de ASP o Active Server Pages.
Las desventajas eran que los desarrolladores tenían que rediseñar y reconstruir sus aplicaciones para migrarlas al modelo de Web y que el código dentro de una página Web (archivo con extensión .asp) estaba mezclado con HTML y Script, situación que hacía muy difícil mantener el código ya que no era legible o amigable. (A esto se le llama código spaghetti porque en un párrafo estaban mezclados varios lenguajes).
Otra desventaja importante es que una solución en ASP debe llevar consigo mismo toda la lógica de negocio ya que el servidor se va a encargar solamente de interpretar su contenido. Tomando esto en cuenta, es obvio que la reutilización de código es casi nula ya que cada archivo de ASP se comporta como una isla, situación poco deseadas para la reutilización y administración eficaz de código.
La arquitectura en capas con la tecnología ASP era muy complicada ya que los controles de presentación (formas, cajas de texto, etiquetas, etc) debían ir dentro de cada archivo .asp. Esto ocasionaba tener una mezcla de código de capas de presentación, negocio y hasta de datos.

Cuando Microsoft lanza la tecnología .NET incorpora los proyectos de Web dentro de Visual Studio .NET. Esto provee una interfaz para desarrollar aplicaciones de Web muy sencilla. La construcción de la capa de presentación es similar a un proyecto de Windows. Se arrastran controles hacia el área deseada y se acomodan con facilidad. La lógica para que estos controles interactúen es separada (como en las formas de Windows) en otro archivo a parte. Esto da como resultado un archivo de presentación y un archivo de lógica o negocios. ¿Qué tiene esto de maravilloso? Que la parte que contiene la lógica de la página Web es compilado y tratado como ensamble permitiendo incorporar conceptos tales como clases, espacios de nombre, etc.
Otra característica importante de ASP.NET son las mejoras sustanciales con respecto al manejo de la persistencia de la información (estado), ya que brinda la posibilidad de que los diferentes componentes que integran una página puedan mantener en forma automática su contenido a través de las diversas peticiones de la misma.
Por último, en bes más sencillo la depuración y detección de errores ya que utiliza herramientas del framework .NET para ayudar al buen manejo de errores y excepciones.
Ahora que entendemos los maravilloso que es ASP.NET y sus ventajas con respecto a su antecesor, podemos meternos más a fondo y hasta desarrollar una pequeña aplicación como demostración.

miércoles, marzo 08, 2006

Introducción a Web Services.

Voy a presentar una situación. Imaginen una empresa donde hay varios sistemas y cada uno hace funciones distintas. Es necesario que trabajen entre si para cumplir con un objetivo. Ahora bien, en un mundo ideal todas las aplicaciones estarían hechas en la misma plataforma y lenguaje de programación y sería muy fácil hacer que se comunicaran los sistemas. Pero esto casi nunca sucede. Un sistema puede estar en Delphi de Borland, otro en C# con la plataforma de .NET y otro en Visual Basic 6. Como vemos, sería complicado hacer que los sistemas se hablen directamente ya que están hechos con herramientas distintas y no muy compatibles. Hay muchas formas de hacerlos comunicarse pero la óptima y la que voy a tratar es a través de Web Services. (Servicios de Web). El chiste es que siguiendo estándares preestablecidos y una forma de comunicación que todos puedan entender cada sistema (sin importar el lenguaje en que esta construido) ofrezca un servicio para que otro lo pueda utilizar. La forma en que los WS se comunican es por HTTP el cual utiliza TCP/IP que es un protocolo de Red muy famoso y estándar en el mundo. El estándar para pasar datos mas utilizado es SOAP que incorpora a XML. XML es un lenguaje con el cual se pueden leer e interpretar datos. XML también goza de reglas y estándares que lo hacen muy fácil de entender y de adoptar por todas las plataformas y lenguajes de programación. Entonces ya tenemos el medio de comunicación (TCP/IP) y el lenguaje universal (XML). Ahora el objetivo es que cada WS sea autónomo y pueda hacer sus tareas sin que tenga dependencias. Es decir, Si nuestro sistema necesita la lista de empleados de una empresa lo mas probable es que un Web Service del sistema de Recursos Humanos la proporcione. Si necesita saber los sueldos de los empleados un Web Service del sistema de finanzas será el encargado de dar la información. A nuestro sistema no le importa como le hizo cada WS para generar su información. Solo le interesa que lo mande en el formato adecuado (XML) y que le llegue correctamente (por HTTP y TCP/IP). Como ven la idea general es muy clara. Desarrollar una herramienta que proporcione información o tareas a varios sistemas montados en diferentes plataformas. Existen varias reglas y otras cosas interesantes de Web Services las cuales voy a tratar en mis siguientes publicaciones. Voy a hacer un Web Service e ir poniendo como lo hice. Después de entender bien los WS hablare de SOA que es una arquitectura basada en servicios.

Cambiando de tema…

Hola, ¿qué les parecieron las publicaciones de los dispositivos móviles y J2ME? Yo la verdad aprendí mucho. Hay todavía mucho que debo estudiar y la verdad es que tengo por ahí un proyecto en desarrollo pero por el momento voy a dejar este tema. Me llama mucho la atención lo que es Web Services y SOA. En mi trabajo hemos estado viendo estos dos conceptos y me di cuenta que necesito entenderlos bien. La mejor forma para lograrlo es publicar en mi blog. Asi que espero la siguiente serie les guste. Va a ser muy interesante.

miércoles, marzo 01, 2006

J2ME Wireless Toolkit y Mi 1er. Programa.

Para desarrollar mi primera aplicación para mi celular voy a utilizar el J2ME Wireless Toolkit. Existen otros IDEs (Integrated Development Environment) pero el J2ME Wireless Toolkit es el más sencillo de usar y es totalmente gratis. Lo primero que debes hacer es bajarlo aquí.
Ahora bien, para nosotros los nuevos en el mundo Java hay que saber que para escribir código fuente basta con escribirlo en cualquier editor de texto. Solo hay que asegurarse que la extensión de ese archivo sea .java y listo.
Vayamos paso por paso para crear un programita sencillo. Primero abre el J2ME Wireless Toolkit. Escoje “New Project” y ponle nombre a tu proyecto y al MIDlet. Yo nombre “Firma” a mi proyecto y “MiFirma” al MIDlet class.
Cuando creas un nuevo proyecto El toolkit crea una estructura de folders para tu proyecto como se ve en la imagen de abajo.


El fólder de bin contiene el MIDlet compilado (archivo .jar) y la descripción del MIDlet (archivo .jad). El fólder de lib esta ahí para que pongas archivos .jar adicionales que le quieras agregar a tu proyecto. El fólder de res contiene imágenes, archivos de textos u otros recursos del proyecto. Por último el fólder src contiene todo tu código fuente.
Ya verán que fácil es hacer un programita. Pueden copiar y pegar el código que presento abajo.

import javax.microedition.lcdui.*;
import javax.microedition.midlet.*;

public class MiFirma
extends MIDlet
implements CommandListener {
private Form mMainForm;

public MiFirma() {
mMainForm = new Form("Firma");
mMainForm.append(new StringItem(null, "Ari Kassin"));
mMainForm.addCommand(new Command("Exit", Command.EXIT, 0));
mMainForm.setCommandListener(this);
}

public void startApp() {
Display.getDisplay(this).setCurrent(mMainForm);
}

public void pauseApp() {}

public void destroyApp(boolean unconditional) {}

public void commandAction(Command c, Displayable s) {
notifyDestroyed();
}
}


Nombren el archivo “MiFirma” y recuerden ponerlo bajo el fólder src de su proyecto y con la extensión .java.
Ahora regresando al Toolkit solo aprieten el botón de Build y si no tienen errores en el código o en los nombres de sus archivos verán un mensaje de “Build Complete”.
Ahora falta que aprieten el botón de Run para lanzar un fabuloso simulador de un teléfono celular. Debe quedar algo como la imagen siguiente:



Que tal? Ahora pueden correr los demos que vienen en el J2ME Wireless Toolkit y ver varios ejemplos de lo que pueden hacer.
Pero hablemos un poco de que sucede al hacer una aplicación como esta. Primero, al apretar el botón de Build el Toolkit agarra todos los archivos .java dentro del fólder de src y los compila. Esta es una compilación especial ya que como sabemos, los archivos fuente deben ser compilados a un ambiente MIDP (Perfil de un dispositivo de telefonía celular). Después de compilar, ocurre una preverificación que se hace en 2 partes. La primera la hace el Toolkit a la hora de compilar y la segunda la hace en tiempo de ejecución justo antes de cargar el MIDlet al dispositivo. Con esto se corre la clase MiFirma que es la que se ve en el simulador.

Espero se les haya hecho interesante. En las siguientes publicaciones voy a profundizar en el tema y a hacer una aplicación mas grande con varias características interesantes.
¡Hasta pronto!

jueves, febrero 16, 2006

Blogs que te gustaría visitar

En mi sección de links enlisto varios blogs de personas que publican conocimiento e ideas dentro del mundo de TI y desarrollo de software. Primero que nada es gente que conozco, colegas de primera mano por así decirlo. Me agrada también que viendo la lista como un conjunto podemos darnos cuenta que existe la diversidad de temas e ideas.

Esta el blog de Carlos Madrigal que lleva un tiempo ya publicando y habla de muchos temas que normalmente soporta con sus mundialmente famosos (¡aunque no lo crean!) Podcasts del Pozo Técnico. Es buen cuate y publica casi diario así que leer TODOS sus blogs es el verdadero reto.

Efrén González sabe bastante del mundo de la tecnología. Tanto que tiene 2 blogs: tecnología y opensource. Mi favorito es el de opensource ya que en mi entorno es poca la gente que sabe de opensource así que bienvenido sea su blog.

El Raider o Luis Morales es muy bueno trabajando con SQL Server 2000. Puedes preguntarle acerca de queries, tablas, índices, etc. Yo lo hago a cada rato. Además siempre publica errores con los que se encontró en el trabajo y da una explicación muy buena de cómo los resolvió.

José Dévora esta preparando varios cursos de .NET y los quiere publicar en su blog. Cuidado con la piratería así que si los quieren usar pregúntenle. Seguro serán de mucha utilidad.

El blog de Teo Ortega habla de varias cosas útiles para entender mejor el desarrollo de software. El tiene experiencia en sistemas de .NET así que sería un buen recurso si algún día se te ofrece.

Como pueden ver, son una buena fuente de información y sobre todo EXPERIENCIA acumulada que te pueden ayudar. Lo mas importante es que al leernos nos motiva a seguir aprendiendo y pelear contra el mal de todos los Ing. en Sistemas: El quedarte atrás. Así que si quieres que tu blog aparezca en mi lista mándamelo y con gusto te obsequio un espacio.

miércoles, febrero 15, 2006

Perfiles y MIDP

Que tal, ¿cómo vamos con todo esto de la arquitectura de J2ME? La verdad es que ya he publicado una buena cantidad de blogs de teoría. Creo es importante ver que es un Perfil y un MIDP para poder ir con las armas adecuadas a tratar de escribir una aplicación en J2ME. Empecemos entonces.
Una vez que tenemos una configuración (un conjunto de APIs y una definición de una Virtual Machine) debemos seleccionar el perfil adecuado para el dispositivo móvil al que vamos a desarrollar la aplicación. El Perfil viene dando una serie de bibliotecas, clases y APIs específicas para programar en un aparato en particular. Todo lo que conforma un Perfil es lo único (ni mas ni menos) de cosas que soporta un celular o pager, por ejemplo. De ahí que el Perfil viene siendo la última capa de la arquitectura y la que tiene una interacción directa con el aparato al que se le esta ejecutando la aplicación.
Hoy en día ya existen varios perfiles para las configuraciones mas comunes pero es el perfil MIDP el mas famoso y al que yo me voy a enfocar.
MIDP viene de las siglas en inglés Mobile Information Device Profile y esta dirigido para utilizarse con la Configuración CLDC. Como podrán imaginarse el MIDP es un perfil para celulares, pagers y otros dispositivos pequeños.
Recuerden que una razón por la que quiero aprender a programar en J2ME es para hacer una aplicación y correrla en mi celular. Ya vimos mucha teoría y creo que estamos listos para algo más práctico. Para mi aplicación voy a utilizar la configuración CLDC con el Perfil MIDP 2.0. Voy a bajar el Wireless Toolkit de Java y empezar a ver como funciona. Mis siguientes publicaciones serán de el ambiente que debes tener para escribir tu aplicación y llevarla a tu celular. Hasta pronto.

Algunos comentarios y Perfiles.

Para mi buen amigo Poncho Flores, comento que efectivamente una KVM trabaja igual que la JVM solo que para un dispositivo móvil. Estas maquinas virtuales lo que hacen es interpretar un programa de Java de acuerdo al sistema operativo que invoca el programa. El proceso completo es el siguiente: Primero se escribe el código fuente en un archivo de texto con extensión .java , luego se compila ese archivo y se forma otro nuevo con extensión .class. Este archivo esta en bytecodes, lo que hace que la JVM lo lea e interprete de acuerdo al sistema operativo anfitrión. Asi se corren los programas con la tecnología Java. Pasa lo mismo con KVM, se sigue todo el proceso hasta que el SO del dispositivo móvil ejecuta el programa que invoca.
Carlos Madrigal tenía inquietudes acerca del KVM y la situación que no soporta JNI. El JNI sirve para poder combinar bibliotecas y aplicaciones escritas en el lenguaje Java y otras en código nativo. El que la configuración CLDC no soporte JNI solo significa que no se pueden combinar bibliotecas y aplicaciones de diferentes lenguajes. La forma en que se definen funcionalidad, aplicaciones, bibliotecas, etc. Para cada dispositivo móvil es escogiendo el Perfil correcto.
Hablare más de perfil en mi siguiente entrada de blog.

jueves, febrero 02, 2006

Características de CLDC

Voy a extenderme en esta configuración porque es la que se usa para hacer aplicaciones para teléfonos celulares. Recuerden que mis primeros pininos en dispositivos móviles van a ser en mi cel así que por eso la atención especial a esta configuración.


Los dispositivos que encajan en CLDC tienen las siguientes características:

  • 160Kb y 512Kb de memorial total disponible.
  • Procesador de 16 bits ó 32 bits.
  • Poco manejo de energía y el uso constante de una batería.
  • Conexión a una red, casi siempre inalámbrica y con ancho de banda limitada.



Como podemos ver en la figura de abajo(1), CLDC se compone de las bibliotecas de CLDC, el Kilobyte Java Machina (KVM) y el lenguaje de programación Java.


El lenguaje de programación Java.
¿Ya ven como insisto en estudiar bien toda la arquitectura detrás de un lenguaje de programación? Pues aquí les va otra buena razón para hacer esto…
Debido a que el ambiente en el que corren las aplicaciones con configuración CLDC es muy limitada, hay cosas de Java que no son soportadas. Esto es que hay cosas que si puedes hacer normalmente en ambientes como J2SE y J2EE pero NO en J2ME y con la conf. CLDC. ¿Ven? Si no sabemos esto podríamos estar utilizando erróneamente el lenguaje de programación Java y se nos haría muy difícil saber porque en unas plataformas sirve y en otras no.
Estos son las principales cosas que NO puedes hacer en Java para configuración CLDC:

  • No hay soporte de tipo flotante. Esto es porque la cantidad requerida para este tipo de variables es muy alta.
  • No hay método finalize(). Ningún objeto debe esperar limpiarse antes de ser eliminado.
  • Hay limitaciones al trabajar con manejo de errores. El manejo de excepciones esta totalmente soportado pero el de errores si esta limitado.



JVM.
En CLDC el Java Virtual Machina se cambio a Kilobiye Virtual Machina. Esto es porque es una versón mas reducida de la original para poder encajar con el hardware de los dispositivos móviles. Sus limitantes principales son:

  • No hay soporte para Java Native Interface (JNI) es decir, no puedes escribir en otro código que no sea Java.
  • No soporta clases cargadoras a nivel java definidas por el usuario.
  • No soporta reflexión.
  • No hay soporte para referencias débiles.

Bibliotecas Java.
J2SE y J2EE contienen muchas bibliotecas que le otorgan al programador clases, métodos, funciones, etc. que puede usar y ahorrar tiempo de codificación y mas importante, evitar reinventar la rueda. En J2ME, no es posible poner todas estas bibliotecas así solamente un mínimo de bibliotecas están disponibles para el usuario.

Con esto podemos entender las características principales de CLDC y ahora podemos escoger el perfil para el dispositivo que quiero hacer mi aplicación. Mis siguientes publicaciones hablarán del perfil MIDP 2.0

¡Hasta pronto!

    (1) bibliografia: http://www.cs.helsinki.fi/u/campa/teaching/j2me/papers/J2ME.pdf

    Más sobre arquitectura de J2ME.

    Que tal, ¿está interesante esto de la arquitectura? A mi en lo particular me esta gustando mucho. Yo solía estudiar solamente un lenguaje de programación y conforme iba avanzando en un proyecto estudiaba lo que necesitaba de la arquitectura en que estaba basado ese lenguaje. La mayoría de las veces me funcionaba este método pero creo que es mejor hacerlo bien. Me refiero a entender primero las especificaciones de una idea o plataforma (como lo es J2ME) y luego poder aprender el lenguaje de programación y usarlo como herramienta de trabajo para diseñar verdaderos sistemas. Carlos Madrigal en sus ya famosos Podcasts del Pozo Técnico habla de este fenómeno y otros temas relacionados como el programador pragmático y lo que hace un verdadero arquitecto de software, los invito a darle una checada.
    Pronto empezaré a hacer mis primeras pruebitas en J2ME. Por lo pronto vamos a ver más a fondo el bloque de configuración.

    Existen 2 tipos de Configuración:
    • Connected Limited Device Configuration (CLDC)
    • Connected Device Configuration (CDC)
    Cada dispositivo móvil entra en una de estas configuraciones. Dependiendo de las características de hardware de los aparatos se sabe que configuración es la adecuada.