domingo, 25 de marzo de 2012

Compatibilidad y usabilidad

Recuerdo que la palabra compatibilidad era una palabra de uso común, cuando desarrollabas alguna aplicación web, de uso público o corporativo y hasta la fecha lo sigue siendo, tenías que instalar diferentes versiones de browser como Explorer, Firefox, Crome, etc. o al menos los más importantes y a veces en diferentes versiones de los mismos todo para ver la compatibilidad del java script y css.

Con la llegada de los dispositivos móviles, así como de las tablets, llego la movilidad, la posibilidad de interactuar con alguna web o aplicación nativa desde un Smartphone, por lo que a la palabra compatibilidad se le agrego la palabra usabilidad en el mundo de los smartphones.

En el mundo de las aplicaciones web ya hoy en día no solo basta con ver la compatibilidad en los browser, sino también con ver la compatibilidad en los smartphones y tables, el problema no viene que el html sea soportado, ya que todos hoy en día soportan webkit o si no tienden a soportarlo y al html5,  sino que hay que pensar en las resoluciones de pantalla, tipo de pantalla, tipo de teclado, velocidad de la red celular, velocidad de procesamiento, etc. Ya que a diferencia de una computadora o una laptop el Smartphone o la tableta es más limitada en comparación con estas.

Al hecho que sean dispositivos más limitados en cuestión de procesamiento/transmisión de datos, también se suma el tamaño, con lo cual se hace evidente que se debe optimizar el contenido y la forma en como el usuario interactúa con el sitio web/aplicación, llegando a considerar la palabra usabilidad.

También tenemos que considerar que los precios hoy en día hacen que su uso sea más común en personas de todo tipo hoy en día, a diferencia de hace muchos años cuando el tener un Smartphone como un iphone era para un nivel social alto o un blackberry era considerado para altos ejecutivos de empresas con un costo elevado para una persona común y corriente.

A mí parecer uno puntos importantes al momento de considerar la usabilidad son:
  • El marcado al cual está dirigida la aplicación o página.
  • El tipo de dispositivo.
  • Seguir un estándar en las aplicaciones.

Debemos considerar el mercado, ya que si nuestra aplicación se dirige a personas con poca experiencia o simplemente es para una empresa en la que su personal no es de gran nivel académico, en ese caso deberemos considerar el hecho que simplificar lo más posible la aplicación y el hecho de que mientras menos cosas tenga que hacer mejor, es más si podemos fijar algunas acciones que se ejecuten automáticamente sin la intervención del usuario es mejor, o por ejemplo si es un juego para niños pequeños su uso debe ser muy intuitivo con imágenes y muy fácil, por el contrario si es un juego para adultos en el que el mercado este habituado a aplicaciones más complejas, pero a mi parecer siempre con la idea de que mientras más fácil e intuitivo sea mejor, me ha pasado que incluso en un proyecto para una empresa de transportes, el kilometraje sea obtenido automáticamente por el gps, y que los usuarios hallan batallado para escribir 2 campos, kilometraje inicial y kilometraje final, y esto sucede porque los transportistas no son personas habituadas al uso de un Smartphone, en este caso se procedió a simplificar más la aplicación, mientras que en otros casos se han agregado módulos a estas sin lo que los usuario tengan problemas, siempre con la característica de la simplicidad al momento de integrarlos.

El tipo de dispositivo es importante por ejemplo una aplicación para arqutectos puede ser adaptada fácilmente a una tableta, en la cual podamos cargar un formulario de avance de obra, un plano de los tipos de construcción para poder hacer anotaciones sobre el dibujo o sobre fotos que se puedan tomar desde la tableta, pero eso no sería factible si fuera un Smartphone sin pantalla touch, hay que pensar en las ventajas y limitaciones de los mismos al momento de desarrollar la aplicación y ver la manera de aprovechar estas.

Debemos ver al momento de desarrollar la aplicación si existe un referente popular en el mercado ue cumple con las expectativdo a interactuar losestión de usabilidad tiene altos porcentajes de éxito a diferencia de aplicaciones demasiado complejas o demasiado simples para el usuario final, algunos factores importantes son como bien mencionamos, el mercado, el dispositivo y el uso de un estándar, siempre equilibrando la facilidad con la versatilidad requerida por el usuario final.

sábado, 14 de mayo de 2011

Videos de android, Iphone y otras cosas

Acá les comparto unos links interesantes, la verdad que hoy en día en Internet se puede encontrar información muy buena casi sobre todo, creo lo único que hay que ponerle es un poco de esfuerzo y voluntad para aprender y tener la voluntad de querer aprender, si nos vamos a cerrar de mente mejor ni preguntemos.

Android connect: es un grupo de desarrollo de google que se ha organizado para compartir y aprender mediante cursos y conferencias sobre android.
https://sites.google.com/site/androidconnect01/

Videos sobre el desarrollo en iphone, son oro puro:
http://devup.ideateca.com/iphone/2011/es/videos


SG Virtual, es un congreso en linea formado por profecionistas para compartir información.
http://www.sg.com.mx/sgvirtual/2011/agenda

La importancia del test

Seguimos recordando frases, pero una que es muy importante que quizás no se le ha prestado la atención debida o no se tiene la cultura a menos que en el trabajo nos lo impongan, es al test, para esto cito un texto de Fabio Maulo. El cual nos revela una gran verdad y experiencia que hay que tener en cuenta:

Soy un desastre programando. No hay nada que hacer...
Estoy en varios proyectos algunos usado por miles de programadores, otros usado por decenas de miles usuarios y otros usado por mi y la tía Carlotta de AjL.
Digo que soy un desastre porque hay veces que para agregar funcionalidades tengo que tocar algo que ya existía y estaba funcionando bien y por alguna razón, agregando lo nuevo rompo lo viejo.... será que me enredo entre un proyecto y otro? será que estoy viejo ? bah?!?!?
Y si!!! Lo tengo que admitir, soy un humano que tiene que dar inteligencia a un estupido muy rápido (una compu).
Me equivoco.

Lo único que rescato de mi forma de trabajar actual es que me doy cuenta que rompí algo que estaba andando ante de que alguien mas lo suba a producción o se de cuenta probándolo en pre-prod.

Como hago?
Es una "magia" llamada TESTS.

El blog de Fabio Maulo: http://fabiomaulo.blogspot.com/
El blog de Anger Java Lopez(uno de tantos, pero es el que mas me gusta): http://msmvps.com/blogs/lopez/default.aspx

domingo, 24 de abril de 2011

Bueno o malo, pero programador!

Navegando en la red e encontrado este blog que me parecio muy bueno, sinceramente no le quitaria ni le agregaria nada, me parecio muy bueno realmente, recordando una frace de uno de mis ex-jefes "Hoy en dia cualquiera puede sentarse en una pc y programar, pero lo que hacemos, es automatizar una empresa de manera eficaz" y para eso hay que ser un buen programador o un buen analista, dependiendo el caso.

url: http://glnconsultora.com/blog/?p=84

Introducción

Hoy dia en las empresas de desarrollo de software o en aquellas organizaciones que cuentan con profesionales de IT entre sus filas, muchas veces habremos oido la expresión sobre que tal o cual persona es un buen o mal programador. Tal afirmación, muchas veces es tan particular o relativa a quien la expresa, se suele pensar que esta sobreentendido quien cae en tal o cual vereda. Es por eso, que para no ser menos, se me ocurrio indagar un poco en la web para ver que opiniones hay al respecto y asi poder plantear la mia en este post. Dejo de lado el analisis del programador de su casa, o el que programa por mero hobby.

Un poco de análisis del tema

Existe un articulo en el cual se investigó este dilema. Este articulo e bastante conocido y lo comprobarán si prueban googlear al respecto. Aborda con mucha claridad determinando factores que influyen en la productividad de un programador: compromiso, eficiencia, por supuesto que el nivel tecnico, entre otras, que permiten afirmar que no sólo se debe medir por el número de líneas de un desarrollador, ni solo en el tiempo exclusivo de desarrollo. En este punto claramente coincido: ser un buen programador es algo que va obviamente mas alla de la cantidad de tiempo que se insuma en la tarea (los malos programadores muchas veces son los que mas horas estan en las oficinas y no por esto se vuelven buenos)
Entre las conclusiones del articulo, la mas significativa es la siguiente: existe una relacion 10:1 entre los buenos y malos programadores. Un buen programador equivale 10 malos programadores en cuanto a productividad se refiere. Y dentro del  tema de la productividad cita diferentes puntos a considerar en el perfil de un buen programador. A continuación algunos extractos:
Hay muchos aspectos en la productividad del desarrollador, pero todos se caen bajo un principio principal (tomando prestado un término de la industria financiera): TCO (Total Cost Of Ownership):
1 – Los buenos desarrolladores lo toman como propio, así que tú no tienes que hacerlo.
Una situación que me viene a la mente, fue con un desarrollador que había contratado (bajo un montón de presión para contratar a todos los que pudiese) como formador de la compañía. Entregué a este compañero un Proyecto para que lo llevase. Unos cuantos días después pasé por allí y no escuché consulta alguna de su parte, así que asumí que las cosas estaban yendo bien.

Dejé pasar unos días y pasé a ver cómo iba la cosa, y el desarrollador me dice que no entiende algunos requisitos y que ha estado haciendo un esfuerzo tratando de entenderlo todo este tiempo.
2 – Los buenos desarrolladores escriben código con menos errores
Esta es una de las primeras formas en que los buenos desarrolladores son más productivos que los desarrolladores medios.
Ellos hacen suyo el proyecto. En lugar de gastar una semana haciendo esfuerzos porque no entienden un requisito, un buen desarrollador toma decisiones y arroja algo de claridad.
Igualmente, un buen desarrollador no requiere que le des un empujoncito a cada momento para asegurarte de que están progresando. Si se atascan demasiado en un problema, ellos irán a ti o sus compañeros de trabajo para resolver el problema.
Un desarrollador que puede escribir código rápido, pero no toma como propios sus proyectos no es muy productivo, porque acaban malgastando tu tiempo.

3 – Los buenos desarrolladores escriben código mantenible
Una vez trabajé con un desarrollador que venía avalado por mi jefe por ser extremadamente rápido escribiendo código. ¡Y desde luego que era rápido! Pero también lo era para meter ‘bugs’ en el código. Su código era descuidado y difícil de entender.
La medidad clave que no figuraba en su medida de productividad era la cantidad de productividad perdida por el equipo de QA, intentando reproducir errores introducidos en su código, junto con el tiempo gastado en arreglar estos errores por otros desarrolladores.
Todos se enfocan en su tiempo para la ‘terminación’, pero no en el coste total de propiedad de ese código. El código no está completo cuando un desarrollador dice que está completo. No es el momento de parar el cronómetro. Es cuando QA ha dado su SI cuando puedes parar el cronómetro, por el momento.

Como me gusta decir, la productividad no trata de correr mucho. Trata de velocidad media. Tú puedes ir rápido, pero si vas en la dirección errónea, no estás ayudando a nadie.
De la mano con el escribir menos errores, está el escribir código entendible y mantenible. Tran pronto como una línea de código aparece en pantalla, estás en modo mantenimiento sobre esa línea.
El código que es frágil y difícil de cambiar, malgasta horas y horas de ciclos de desarrollo cuando intentas enmendar un sistema con actualizaciones y nuevas funcionalidades. Escribiendo código mantenible, un buen desarrollador puede hacer estos cambios más rápidamente y también aumenta la productividad de su equipo, quien más adelante tendrá que trabajar con ese código.
4 – Los buenos desarrolladores hacen más con menos código
Otro sello distintivo de un buen programador es que saben cuándo no escribir código.

Salvo unas cuantas excepciones, el síndrome NIH (Not Invented Here-No inventado aquí) es un asesino patológico de la productividad.
He visto a desarrolladores comenzar a escribir sus propios frameworks para la validación de formularios hasta que les he apuntado que ya hay uno escrito en ASP.NET que hace el trabajo (No es perfecto, pero es mejor que el que les he visto escribir).
Todo ese tiempo gastado reinventado la rueda se ha perdido porque alguien ya había escrito ese código para ti. Y en muchos casos, hizo un trabajo mejor porque era su único objetivo. En tal situación, encontrar una librería existente que nos de el trabajo hecho puede darnos un enorme impulso a la productividad.
La advertencia en este caso es ser cuidadoso y evitar las librerías no extensibles y rígidas de terceras partes, especialmente para requisitos muy especializados. Puedes perder un montón de tiempo intentando meter una ficha redonda en una caja cuadrada.
Incluso cuando tú debas inventar aquí (NHI), los buenos desarrolladores tienden a escribir menos código (pero todavía legible) que hace más. Por ejemplo, en lugar de escribir una máquina de estados para parsear texto de un gran String, un buen desarrollador puede usar una expresión regular (Ok, alguno dirán que un regex no es legible. Pero es más legible que miles de líneas de texto de código de parseo).

Y por casa como andamos?

Del extracto anterior se desprende claramente que un buen programador sera aquel que mejor salga parado al evaluar su relación para con su codigo (legible, mantenible, documentado, sin bugs), con sus compañeros de equipo (no romper builds, ayuda a otros programadores), con su proyecto (costo de propiedad, ownership). Un buen programador es un todo, no una mera parte tecnica. Un buen programador debe ser responsable con todo y todos los que intervienen, junto con él, en la construcción de un sistema informático.
Es entonces en este sentido, que todo programador deberia (antes de que lo hagan otros) evaluarse en estos temas y tomar acciones correctivas en el caso que se encuentre fallando. Esta evaluación no es sencilla y deberá considerar los conocimientos técnicos, optimización del tiempo, comunicación con el equipo, que postura tengo hoy para con el proyecto y cliente, etc.
Concentrandonos un poco en el aspecto ténico o de producción, el buen programador aprovecha su tiempo para codificar los requerimientos, de la manera mas practica y eficiente posible. Pero ¿que es aprovechar el tiempo?, bueno, digamos que de las 8 horas que trabajamos, cuantas en definitiva las estamos abocando correctamente a producir resultados esperados y utiles para el proyecto.  Saber cuanto tiempo invertimos (o perdemos) en determinados temas será vital como punto de inicio para la mejora de cada uno. Una forma que me parece apropidada y practica de implementar, es que dia a dia los programadores, al tomar o asignarsele una tarea de relevancia, al cerrarla completen un registro de cuanto tiempo insumieron en produccion neta de dicha funcionalidad,  cuanto tiempo tuvieron que investigar, cuanto tiempo estuvieron tratando de comprender lo que debian hacer, cuanto descansaron, cuanto tiempo tuvieron en corrección de bugs, etc. Aquel programador que la mayoria del tiempo se encuentre investigando puede denotar necesidades de capacitación en la temática investigada, quien pierda mucho tiempo tratando de comprender las tareas que se le asignan denotará que el problema de su mal rendimiento por ahi viene de antes, desde el momento mismo de la especificación del requerimiento.
Cada minuto de trabajo es vital, y la optimizacin del tiempo es un tema que no deberia dejarse de lado. Entendiendo como distribuimos nuestro tiempo podemos observar que insumimos mucho tiempo en descansos o pausas, lo cual puede ser sintoma de problemas de concentracion, dispersion, etc. Para este tipo de situaciones,  existen tecnicas como la de Pomodoro que nos servira apra ir ganando atencion en lo que hacemos.

Productivos  y no productivos

Finalmente, nos quedarian algunas palabras respecto a la paga que recibe un programador, sobretodo la relación entre una de un buen programador en relacion a la de otro malo. El articulo de Brooks destacada ademas que existe una realidad que indica que los malos programadores cobran mejor que los mejores programadores.
Aqui, mi opinión concuerda con la de muchos, en cuanto a que todo programador debe recibir una paga acorde a su productividad, no unicamente considerando que tantas horas estuvo frente a la maquina. Esta productividad, en su forma mas sencilla, es una relación directa entre cuantas actividades tomó o le asignaron para realizar y cuantas pudo cerrarlas sin errores (aprobadas por Pruebas y QA). En este punto juega un papel preponderante la estimación de esfuerzo que se haga de cada actividad que ejecuta un programador. La estimación no deberia ser de una unica persona ya que esto podria generar situaciones como ser una disputa sobre si se subestimo una actividad en relacion a lo que llevo realmente. Aqui, lo mejor son tecnicas agiles, como planning poker o delphi.
El pago por productividad, en contraste con el pago por horas al mes, evita que los programadores no tan eficientes puedan recibir pagas mejores que la de un buen programador, en relacion a lo que producen. No obstante, la medicion de la productividad es bastante dificil en la profesion de un programador, ya que  intervienen muchas cuestiones que pueden atentar con la tarea, como ser especificaciones de funcionalidades muy vagas que retrasan el inicio del desarrollo, o la inclusion de cambios en lo ya codificado que hacen que se tenga que rehacer una funcionalidad ya concluida. Será tarea entonces de tomar medidas para evitar estas situaciones y que la labor de los programadores sea lo suficientemente “limpia” como para poder considerarla para evaluarlo. Algunos autores, como Martin Fowler directamente afirman que la productividad es algo que no puede medirse.
La productividad y el pago por la misma, es la punta de un iceberg que iremos descubriendo en otros posts ;-).

Conclusiones

Un programador es un rol fundamental en el desarrollo de software, cada vez mas solicitado, demandado por pequeñas y grandes empresas. Es la bala de plata que muchos lideres buscan para poder cerrar sus proyectos, hasta que cuando se encuentran ante alguno, lanzan un dilema muy viejo: éste…será  bueno o malo programando?.
La respuesta a esa pregunta dependerá de muchos elementos; los aspectos técnicos pueden ser los mas faciles de probar, via pruebas de codificación, examenes y demas, pero los que muchas veces mas imperan, el compromiso, la responsabilidad, la proactividad, si realmente le gusta lo que hace, son muy dificiles de descubrir de antemano. Se asoman luego semanas o meses de trabajo en un proyecto y su tratamiento no depende de meras capacitaciones (¿como se hace responsable a alguien? ¿cuanto tiempo lleva esto?).
Si somos programadores a esforzarse para ser un programador profesional e íntegro. Esto es lo que cuenta. Si somos de los que lideran o coordinan programadores, deberemos analizarlos desde perspectivas mas alla de cuestiones técnicas. Para ambos casos, deberemos buscar mecanismos que nos brinden indicadores para decidir que tan bueno o malo se és.
Saludos
Gastón Guillerón
gguilleron@glnconsultora.com

sábado, 21 de agosto de 2010

Parte 3.- Java Me Basico

Bien ahora pasemos a un pequeño tutorial de java me para móviles y posiblemente ahora se haga la pregunta ¿Y por que java me? ¿Hay otras formas de programar en móviles como con HTML 5 y php?.

Bueno con java podemos modelar un diseño de clases hacer modelos de testing, es decir poder hacer desde una aplicación sencilla hasta una compleja usando diferentes metodologías y técnicas, y si podemos hacer una pagina y que se vea en un browser pero pues al ser una pagina web se debe renderizar siempre o bien tratar de usar ajax para lo mismo, es decir lidiar con la interfase del sistema cuando en realidad deberíamos concentrarnos en el negocio, también el usar una aplicación web no es offline como una aplicación nativa, o bien tratar de usar Widgets con HTML y java script pero no es algo que se modele a raiz de una clase ahí ya es programación estructurada.

Los Widgets son pequeñas aplicaciones de web independientes que puedes instalar y usar en tu teléfono. Esas aplicaciones ofrecen las funciones específicas y frecuentemente usadas, como pronósticos del tiempo o noticias en la Internet. Para usar los Widgets, tu aparato debe tener el soporte necesario.

Las aplicaciones nativas permiten una manipulación de APIS de manera nativa y directa.

En realidad me parece que depende del objetivo de la aplicación como se puede diseñar, por ejemplo si es informativa igual y es con Html 5 o bien con un Widget, pero si es de un proceso de negocio complejo como ventas, con Gps, e imprime y cobra con tarjeta como que es mejor con algo nativo como java igual tomar en cuenta el crecimiento de la aplicación.
En resumen pueden ser de 3 tipos los desarrollos móviles y depende de el enfoque del negocio lo que deberíamos usar, posteriormente se mostraran mas información de otras tecnologías:
  • Nativas.
  • Widgets.
  • Html 5 
Algunas tecnologías móviles y herramientas comunes pueden ser:  
  • Java ME, Netbeans y Eclipse.
  • Blackberry con Java ME y Java nativo de blackberry, Visual Studio(plugin) y Widgets.
  • Iphone con cocoa y monotouch(c#).
  • Android con Motodev, Eclipse y proximanente Monodroid(c#).
  • Widgets java script y html con Aptana.
  • Phone gap con java script, multiplataforma.
  • Windows Phone con Silverlight y Expression.
  • Windows Mobile(Descontinuado ahora es el Windows Phone)

Mi recomendación es siempre conocer y revisar las necesidades del cliente, crecimiento y no enfocarse en una moda o lo que nos parece que es lo más sencillo pero es muy limitado en cuanto al crecimiento a veces lo barato sale caro.

1) Tipos de Aplicaciones.

Pago único. Se hace un único pago y no hay problema de gestionar licencias.
Renta. Acá se pone énfasis en tener el control y poder gestionar las licencias y pagos cada cierto tiempo, mediante un sistema de gestión de licencias.
Patrocinio. Acá se pone énfasis en poder gestionar contenido de publicidad como puede ser imágenes o videos.

2) Características de móviles.

Uso de envío de datos a través de la red del Carrier.
Manejo de Web services.
Manejo de Web client.
Manejo de Sockets.
Uso de envío de datos a través de WiFi.
Uso del GPS.
Uso de los mapas.
Uso de la cámara.
Uso de la multimedia para reproducir video.
Uso de la multimedia para reproducir música.
Uso de la multimedia para grabar video.
Uso de la multimedia para grabar música.
Uso del envío/recepción de sms.
Uso del envío/recepción de msm.
Uso del envío/recepción de mail.
Uso del envío/recepción de pin.
Uso del teléfono para hacer una llamada o recibirla.
Almacenamiento de datos usando SQL Lite si lo permite u algun otro metodo.
Uso de periféricos externos:
Código de barra.
Impresoras.
Lector de tarjeta de cobro.

3) Java 2 ME.

J2ME es la plataforma para el desarrollo de aplicaciones móviles.
Existen dos tipos de aplicaciones en J2ME las CDLC y las MIDP
Las aplicaciones CDLC es concebido como una base para otras plataformas como MIDP. Su funcionalidad es escasa
Las aplicaciones MIDP (Mobile Information Device Profile) cuenta con una mayor funcionalidad y puede ser utilizado en prácticamente cualquier PDA

4) MIDlet.

Este paquete permite a las aplicaciones MIDP (midlets) interactuar con el entorno, sobre el cual la aplicación se está ejecutando.
Un midlet siempre heredará de la clase javax.microedition.midlet.MIDlet
Las aplicaciones MIDP deben contar con al menos un MIDlet.

5) Ciclo de vida de un midlet.

Cuando un MIDlet se termina de cargar el estado que toma es el pausado.
Ya que se inicializa el MIDlet este pasa al estado activo.
El MIDlet puede pasar del estado activo al pausado a través de sus propios métodos o que el sistema operativo lo pause para responder a una llamada.
El MIDlet puede ser destruido independientemente de su estado activo o pausado.

6) Metodos de un MIDlet.

Las clases que heredan de javax.microedition.midlet.MIDlet deben implementar los tres métodos abstractos que tiene la clase MIDlet
startApp
pauseApp
destroyApp
Estos métodos pueden ser declarados como protected o como public si van a ser llamados desde otro elemento.

7) startApp()

Este método cambia el estado del MIDlet a activo.
Definición:
protected abstract void startApp ()
Un MIDlet inicia su carga con el constructor y de no haber un error pasa al estado pausado.
Con este método se inicia la ejecución del MIDlet hasta que regrese al estado pausado o destruido.

8) pauseApp()

Cambia el estado del MIDlet a pausado
Sintaxis: protected abstract void pauseApp ()
Guarda la información del estado actual de nuestra aplicación y libera los recursos que ella pudiera estar ocupando.
Al reactivarse nuestra aplicación se llama al método startApp.
Nota: es muy recomendable que en el método startApp pueda distinguir cuando es ejecutado por primera vez, de las veces que es reanudado el sistema.

9) destroyApp()

Es el método al cual se llama cuando la aplicación debe terminar.
Sintaxis:
protected abstract void destroyApp (boolean unconditional)
Este método cambia el estado del MIDlet a destruido.
El MIDlet puede pedir que no quiere entrar en el estado Destruido lanzando una excepción MIDletStateChangeException. Lo cual evita que la aplicación no termine. Para concluir con la aplicación, ignorando cualquier excepción que se diere durante la ejecución de este método; establecemos a true el parámetro unconditional.

10) Otros metodos.

Existen otros tres métodos para el cambio de estado de un MIDlet.
El llamado a cualquiera de ellos no causa la ejecución de los métodos que anteriormente fueron descritos.
Estos métodos son:
public void notiyPaused ();
public void notiyDestroyed ();
public void resumeRequest ();
Para cambiar al estado de pausado, destruido y activo respectivamente.

11) Ejemplo de un MIDlet.

//Usamos la clase MIDlet
import javax.microedition.midlet.*;
//Nuestra clase debe de heredar de la clase MIDlet
public class MiMIDletEjemplo extends MIDlet
{
  //Constructor
  public Ejemplo1( )
  { }

  //Método que se llama cuando pasamos de Pausado a Activo
  protected void startApp( )
  { }

  //Método que se llama cuando pasamos de Activo a Pausado
  protected void pauseApp( )
  { }

  //Método que se llama cuando se destruye el midlet
  protected void destroyApp(boolean incondicional)
  { }
}

12) Display.

Representa el controlador lógico de la pantalla del dispositivo, donde el Midlet colocará su interfaz.
El objeto Display no se crea, se obtiene con el método getDisplay().
Por cada MIDlet sólo existe una instancia del objeto Display.
Sólo un MIDlet podrá tener el control de la pantalla.
El método getDisplay, generalmente, se ejecuta una vez y se guarda la referencia del objeto Display.
public static Display getDisplay (MIDlet midlet);

13) Metodos de Display.

Los métodos más usados del objeto Display son:
Displayable = getCurrent(); Retorna el objeto Displayable que actualmente se muestra en pantalla para dicha aplicación Midlet.
Display = getDisplay(MIDlet m); Obtiene la instancia del objeto Display.
Boolean = isColor(); Indica si el Display del dispositivo soporta colores.
Int = numColors(); Regresa el número de colores que el dispodivo soporta.
Void = setCurrent(Alert alert, Displayable nextDisplayable); Muestra un objeto Alert y el objeto Displayable cuando el objeto Alert desaparezca.
Void = setCurrent(Displayable nextDisplayable); Establece el objeto Displayable en el Display. Muestra el objeto Displayable en la pantalla.
Boolean = vibrate(int duration); Solicita la operación de vibrar al dispositivo.

14) Objeto Displayable.

Este tipo de objetos contiene la información que va a ser visualizada.
Exiten dos tipos de objetos Displayable
Screen – Clase base para utilizar el API de alto nivel del interfaz de usuario.
Canvas – Estructuras que pueden acceder a eventos de bajo nivel.

15) Tipos de screen.

Existen dos tipos de Screen:
Screen con estructura predefinida: Alert, List y TextBox, que encapsulan componentes de interfaz complejos y que las aplicaciones no pueden enriquecer con nuevos componentes.
Screen genérica: Form, las aplicaciones pueden llenar este tipo de pantalla con texto, imágenes u otros componentes de interfaz de usuario.

16) Objeto Alert.

Esta clase permite mostrar un mensaje (y opcionalmente una imagen) al usuario.
Es como un pop-up o un MessageDialog.
Los constructores de la clase Alert son:
public Alert(String title);
public Alert(String title, String alertText, Image alertImage, AlertType alertType);
Por defecto el tiempo que permanece un Alert en pantalla está determinado por el dispositivo o puede ser cambiado usando el método setTimeout() que especifica el tiempo en milisegundos (o usando la constante Alert.FOREVER)

17) Objeto List.

Esta clase hereda de Screen.
Con ella podemos mostrar una lista de opciones seleccionables.
Existen tres tipos de selección en un List:
EXCLUSIVE – Cada elemento de la lista cuenta con una opción de selección. Cuando el usuario selecciona un elemento, el elemento anteriormente seleccionado deja de estarlo.
MULTIPLE – Cada elemento de la lista cuenta con un cuadro de selección, el usuario puede marcar cuantos elementos desee.
IMPLICIT – Este tipo de selección es parecida a la EXCLUSIVE en el sentido que sólo un elemento puede ser seleccionado. Pero su selección es automática con tan sólo poner el foco en el elemento.

18) Constructores de List.

El objeto List cuenta con los siguientes constructores:
List(String title, int listType)
List(String title, int listType, String[] stringElements, Image[] imageElements)
El objeto List tiene un comando por defecto (SelectCommand), el cual sirve para cuando deseamos seleccionar un elemento de la lista y sólo se activa si la lista cuenta con al menos un elemento.

19) Commands.

Los commands son constructores que encapsulan la semántica de una acción.
Para crear un comando iniciamos con la declaración de una variable de tipo command
Command exitCommand;
Creamos la instancia:
exitCommand = new Command("Salir", Command.EXIT,2);
Los parámetros que se pasan al momento de crear la instancia son:
Título o etiqueta del command
Tipo del Command
Prioridad del Command

20) Tipos de Commands.

OK – Confirma una selección
CANCEL – Cancela la acción actual
BACK – Traslada al usuario a la pantalla anterior
STOP – Detiene una operación
HELP – Muestra una ayuda
SCREEN – Tipo genérico para uso del programador referente a la pantalla actual
ITEM – Tipo genérico para uso del programador referente a un elemento de la pantalla actual

21) Listener de comandos.
Para agregar un Command a un objeto Screen:
screen.addCommand(exitCommand);
Finalmente, para poner al objeto Screen a la “Escucha” de la selección de los comandos, ejecutamos el método setCommandListener.
screen.setCommandListener(this);

22) CommandListener.

Todo Screen que vaya usar Commands requiere de la implementación de la interfaz CommandListener.
public class HelloWorld extends MIDlet implements CommandListener
Al impletar dicha interfaz debemos redefinir el método commandAction.

public void commandAction(Command c, Displayable s)
{
  // Salir
  if (c == exitCommand)
 {
    destroyApp(false);
    notifyDestroyed();
  }
}

23) La clase Form.

La clase Form es una subclase de Screen, que contiene un número arbitrario de Items, como imágenes, texto y listas de selección.
La clase Form tiene dos constructores:
Form(String title)
Form(String title, Items[] items)
El número de Items que se encuentran contenidos en un Form se obtiene ejecutando el método size() de la forma.

24) Metodos para manejar los items de un form.

int append(Image img)
int append(Item item)
int append(String str)
void delete(int itemNum)
void insert(int itemNum, Item item)
void set(int itemNum, Item item)
Item get(int itemNum)
void deleteAll()

25) Clase Item.

Es la superclase usada por todos los componentes que pueden formar parte de un Form.
La clase Item es una clase abstracta por lo que sólo puede ser instanciada a través de sus clases derivadas.
Todos los ítem tiene un campo label o etiqueta, que es una cadena que va con el ítem.
Para ver y poner esta etiqueta tenemos dos métodos:
public void setLabel(String label)
public String get Label()

Parte 2.- EL Testing

Aca se presenta un poco de información hacerca de los test y tratar de hacer conciencia de probar las cosas de manera adecuada.

1) Definiciones - Testing.

Según IEEE standards 1999. “El testing de software es el proceso de analizar un producto de software para detectar las diferencias entre el comportamiento real y el pretendido, y para evaluar las funcionalidades y características no funcionales del software”

2) ¿Por qué es necesario el testing?
  • Identificar fallos
  • Reducir defectos en producción
  • Mejorar la calidad de la aplicación de los usuarios
  • Incrementar la fiabilidad
  • Para asegurar que los fallos no impactan a los costes y a la rentabilidad
  • Para asegurar que los requisitos son satisfechos
  • Para asegurar que los requisitos legales son conocidos
  • Proveer una medida de calidad 
3) El gran axioma del testing.

Axioma: “El Testing sólo puede mostrar la presencia de defectos, no su ausencia” (Dijkstra).

Corolario: Un test sólo es exitoso si encuentra errores.

4) Conceptos: Casos vs datos de test.
  • Casos de test: descripciones de condiciones o situaciones a testear.
  • Según IEEE standards 1999: “Es un conjunto de condiciones de ejecución sobre los valores de entrada y resultados esperados generadas para satisfacer un objetivo particular”
  • Crear casos de test es un proceso creativo.
  • Datos de test: lotes de datos necesarios para ejecutar un caso de test.
  • Crear datos de test es muy laborioso... Y poco creativo.
5) Casos de test.
  • Lo ideal sería probar el programa en todas las situaciones posibles
  • Una de las mayores dificultades es encontrar un conjunto de tests adecuado:
  • Suficientemente grande para abarcar el dominio y maximizar la probabilidad de encontrar errores
  • Suficientemente pequeño para poder ejecutar el proceso de testing con cada elemento del conjunto y minimizar el costo del testing  
6) Equipo de trabajo.

Líder de proyecto
  • Definición de la estrategia de testing
  • Elaboración del plan
  • Control del proyecto
  • Interacción con el cliente
Tester Diseñador
  • Definición de los casos de prueba
  • Poblado de las condiciones de prueba
Tester ejecutor
  • Ejecución de los casos de prueba
  • Detección y registro de incidentes
7) Testing de Unidades.
  • Se trata de probar módulos sueltos
  • Fase informal previa:
  • Ejecutar pequeños ejemplos
  • Hay herramientas que analizan automáticamente la sintaxis de los programas (¡e incluso “opinan” sobre fuentes potenciales de error!)
  • Fase de prueba sistemática:
  • Pruebas de caja blanca (o transparente): Se mira con lupa la estructura del código escrito
  • Pruebas de caja negra: Se prueba la funcionalidad del módulo sin atender a su contenido 
8) Testing de Integración.
  • Involucran varios módulos
  • Pueden ser estructurales o funcionales
  • Estructurales: como las de caja blanca, pero analizando llamadas entre módulos
  • Funcionales: como las de caja negra, pero comprobando funcionalidades conjuntas
  • Se siguen utilizando clases de equivalencia y análisis de valores frontera
  • Las pruebas finales consideran todo el sistema, cubriendo plenamente la especificación de requisitos del usuario
9) Testing del Sistema.

Realiza una batería de pruebas completa del sistema para tener información fiable de que el software cumple los requerimientos de prestaciones y funcionales solicitados.
Ejemplos:
  • Pruebas de Desempeño
  • Pruebas de Carga
  • Pruebas de Stress
10) Testing de regresión.
  • Repetir las pruebas tras cada modificación
  • Repetir sólo pruebas de verificación
  • Pruebas de unidades
  • Pruebas de integración
  • Conservar y actualizar los programas de prueba  
11) Plan de Testing.

Es un conjunto de pruebas
Cada prueba debe:
  • Dejar claro qué tipo de propiedades se quieren probar
  • Dejar claro cómo se mide el resultado
  • Especificar en qué consiste la prueba
  • Definir cuál es el resultado que se espera
  • Las pruebas “angelicales” carecen de utilidad 
12) TDD (Desarrollo guiado por pruebas, o Test-driven development).

Es una práctica de programación que involucra otras dos prácticas: Escribir las pruebas primero (Test First Development) y Refactorización (Refactoring). Para escribir las pruebas generalmente se utilizan las pruebas unitarias (unit test en inglés). En Primer Lugar se escribe una prueba y se verifica que las pruebas fallen, luego se implementa el código que haga que la prueba pase satisfactoriamente y seguidamente se refactoriza el código escrito. El propósito del desarrollo guiado por pruebas es lograr un código limpio que funcione (Del inglés: Clean code that works). La idea es que los requerimientos sean traducidos a pruebas, de este modo, cuando las pruebas pasen se garantizará que los requerimientos se hayan implementado correctamente.

14) Metodologías basados en pruebas.

TDD

DDD

BDD

Se puede encontrar mas información de estos temas en las VAN de Alt Net Hispano, en donde se han tratado y mostrado ejemplos de los mismos.

Parte 1 - Conceptos generales

A continuacion se presentan un curso de formación de programacion en java para moviles, si bien se basa en java me, en el curso de formación tambien se adentra dentro del mundo de la calidad y estandarización para tener un estandar en el desarrollo, tambien se omite la parte del uml puesto que se pueden documentar en muchos lugares con esa información.

1) Conceptos generales.

  • Estándares. Son normas y protocolos internacionales que deben cumplir productos de cualquier índole para su distribución y consumo por el cliente final.

  • Calidad. Herramienta básica para una propiedad inherente de cualquier cosa que permite que esta sea comparada con cualquier otra de su misma especie.

  • Normas. Es un documento, establecido por consenso y aprobado por un organismo reconocido (nacional o internacional), que proporciona para un uso común y repetido, una serie de reglas, directrices o características para las actividades de calidad o sus resultados, con el fin de conseguir un grado óptimo de orden en el contexto de la calidad.

  • Metodología. Forma de organización y trabajo en equipo, como puede ser XP, Scrum, RUP.
2) Objetivos a cumplir en el desarrollo.

  • Reutilización de código o artefactos, al encapsular distintos componentes se pueden reutilizar en posteriores desarrollos, agilizando el tiempo de desarrollo y de mantenimiento.

  • Rapidez en el desarrollo, el uso de librerías base y métodos que maximicen la productividad y tiempos de respuesta. 

  • Calidad, el tener inspecciones así como normas asegura el desarrollo en base a un estándar lo que facilita el mantenimiento y la comprensión del sistema aun que hallan diferentes programadores.

  • Los anteriores puntos se alcanzan con las siguientes herramientas.

  • Uso de estándares de codificación (notaciones, documentación del código, herramientas a usar).

  • Uso de refactorización, y el uso de librerías. En una clase no puede haber código repetido, se debe buscar la refactorización, si es usado en más de una clase o bien más de un proyecto se encapsula en una librería.

  • Desarrollo en capas desacopladas.

  • El uso de inspecciones se refiere al echo de verificar periódicamente que se cumpla con los estándares no se hace un testing el cual se hace al fin de un modulo sino se busca que el producto cumpla con los estándares de programación, se busca mantener separado la inspección del testing para que no impacte al desarrollo al trabajar en parejas se busca que las inspecciones y los testing sean entre los elementos de los equipos, obviamente al hacer un testing se hace una inspección rápida pero ya con la certeza de que el código cumple un estándar.

  • Uso de documentos y checklist usados en todo el proceso para ir validando el proceso de desarrollo y testing.

  • Un modelo en espiral es mas dinámico y cambiante que uno en cascada, en cada ciclo se hace una retroalimentación y cambio principalmente en la parte de diseño de la aplicación y la interfaz de usuario, lo que se busca es el producto final sea lo que necesita el cliente para automatizar sus procesos además de cumplir con los lineamientos de usabilidad.

  • Los objetivos fundamentales son: la aplicación debe dar el resultado esperado por el cliente y debe de funcionar sin errores. 
3) Objetivos a cumplir hacia el cliente, ¿Qué espera un cliente?

  • Como empresa de desarrollo de software el objetivo es automatizar procesos y evitar duplicidad de tareas, por ejemplo automatizar una nomina, y evitar que el trabajador y el contador lleven cuenta de lo mismo, agilizando el proceso y descargando de funciones que no corresponden a diferente personal. 

  • Cumplir con los constraints (requerimientos) especificados del cliente, mismos que deben estar por escrito, los cambios deben ser notificados y aprobados para poder ser ejecutados.
4) Proceso de desarrollo por versión.

  • Análisis: obtención del domino de los procesos de los clientes a través de entrevistas, reuniones, cuestionarios (usando formatos para recavar información), así como definir requerimientos y especificaciones, si un cliente pide un elefante rosa en su sistema, debe llevar ese requisito, ni mas ni menos. 

  • Diseño: Diseño y modelado del sistema con UML.

  • Programación: En base a un diseño se procede a programar el sistema.

  • Implementación: Una vez que se ha revisado que no tenga errores y cumpla con los requisitos, se procede a implementar, capacitar y revisar que el sistema funcione y sea usado en la empresa.

  • Mantenimiento: Es la fase en la cual se da mantenimiento a posibles Bugs y adecuaciones de los clientes.
5) Generalizando.
  • La idea de la estandarización es análoga a la ISO 9000.
  • La idea básica de la ISO es que en un macroproceso tienes mini procesos y que estos deben tener conexión entre si y si todo el macroproceso funciona siempre de la misma manera sin desviación, obtienes siempre el mismo resultado.
  • Las normas más importantes en el software son:
  • CMMI.
  • ISO.
  • Moprosoft (norma mexicana).

6) Análisis y diseño. 
  • La documentación minima para tener un sistema es el diagrama de la base de datos, e nuestro caso usamos siempre como herramienta el Erwin data modeler, por su capacidad de exportar en diferentes motores los esquemas diseñados. 
  • Los diagramas UML para tener una documentación minima y práctica son los siguientes (Usando la herramienta Enterprise Architect):
  • Diagrama de casos de uso.
  • Diagrama de clases.
  • Diagrama de estados.

7) Otras herramientas hacia el cliente.

Cuestionarios sobre el negocio hacia el cliente para conocer a gran nivel como es su proceso de negocio, no estamos modelando simplemente conocer como es su proceso del cliente.

¿Cuantos vendedores tiene?
¿Los vendedores manejan rutas?
¿Manejan listas de precios?
¿Maneja un almacen mobil?
¿Cuantos productos manejan?
¿Formas de pago que manejan (Efectivo, Crédito Cheque u otro)?