Mapas en el Móvil

Pensando en como crear un mapa en un fichero jpg para visualizarlo en un móvil encontré algo mucho más avanzado:

Un programa para poder navegar por los mapas desde el móvil o PDA y las utilidades necesarias para generar los mapas, partiendo de los mapas de google maps.
El programa es gratuito y se llama Movile GMaps. Permite visualizar mapas de distintas fuentes como Google maps y Yahoo! maps entre otros.
La aplicación se conecta a Internet y permite navegar por los mapas desde el móvil. También puede usar el GPS del dispositivo o conectarse a uno externo mediante Bluetooth.
Si no queremos conectarnos a Internet, también permite leer los mapas desde la caché del programa, que podemos configurar su localización en la configuración del programa.

Para generar un mapa y cargarlo en la caché del Movile GMaps hay que seguir los siguientes pasos:

1) En www.mapcacher.com marcamos la zona de la que queremos obtener el mapa junto al tipo de mapa, la calidad y los zoom que queremos tener disponibles. Hay que tener en cuenta la limitación del espacio que tengamos en el dispositivo. En este punto generamos un dichero .map que contiene la información que usaremos en el siguiente punto.

2) Mediante la aplicación para Windows gMapMaker (de código abierto y en C#) descargamos los datos de la zona que se ha marcado en el punto 1. Le indicamos el directorio donde generar el mapa, cargamos el fichero .map antes generado y a descargar.

3) Copiamos la carpeta generada al dispositivo. Ejecutamos Movile GMaps y lo configuramos para que la cache apunte a la carpeta con el mapa.

Ya podemos navegar por el mapa y hacer zoom.

Aquí se describe uno de los varios métodos posibles y usando la aplicación para Windows, hay también script en Perl para generar el mapa.

Para una descripción más detallada puedes visitar el siguiente artículo.

Tip 12: Make It Easy to Reuse - Hazlo fácil de reutilizar.

Para evitar la duplicación hay que facilitar la búsqueda y uso de la información. Si es fácil de encontrar y usar, se usará y no se duplicará.

Utilidades de Windows

¿Cuantas veces se ha quedado un archivo abierto y no sabes cual es la aplicación
propietaria?

En los sistemas linux se encuentra el comando fuser, con Windows viene el comando de consola net file pero muestra los ficheros abiertos por una conexión de red.

Pero no es que Windows no tenga algo parecido, parece que no viene por defecto y tenemos que descargar la aplicación.

- Process Explorer. Con esta aplicación puedes comprobar los ficheros que está usando una aplicación.

- Handle. Es un programa para la linea de comandos que muestra todos los ficheros abiertos, entre otras cosas.

Hay muchas aplicaciones para comprobar como está funcionando Windows que no vienen con el sistema. Se puede encontrar una lista bastante amplia denominada Windows Sysinternals

Ahora también se pueden usar desde la web desde live.sysinternals.com, así nos aseguramos de que usamos la última versión disponible.

Control de Versiones: Etiquedas y Ramas

Las ramas y las etiquetas pueden tener muchos usos y por eso se puede hacer complicado su uso.

Las etiquetas se usan para marcar el proyecto cuando está en un determinado estado.
Las ramas representan una bifurcación en la historia del proyecto.

Deberíamos usar una rama cuando lanzamos una versión del producto o por ejemplo cuando vamos a implementar funciones experimentales. Cada release brach puede tener varias releases o puntos donde la aplicación fue puesta a disposición del cliente. Estos puntos de marcan con las etiquetas.

Los bugs se fijan en la release branch correspondiente y el cambio se fusiona en las restantes ramas. Si el bug es complicado se puede crear una rama y luego fusionarla con las restantes ramas. Nota: El programa SourceOfSite no dispone de opciones para fusionar ramas.
Se usan etiquetas para marcar el comienzo y el final del bugfixing.

Para decidir si necesitamos una rama tenemos que pensar que esa rama deberá ser mantenida, es decir, que habrá que modificar algún fichero y fusionarla con las otras ramas en un futuro. Si no se va a mantener una rama es mejor usar una etiqueta. Tampoco es buena idea crear una rama para una modificación especifica de la aplicación para un determinado cliente. Esto habría que hacerlo la propia aplicación.

Control de Versiones

¿Qué es?
Es un software que facilita el trabajo de un programador.

• Se podría considerar como el deshacer de un editor de textos pero para el código fuente.

• Permite a múltiples programadores trabajar sobre el mismo código de manera controlada.

• Mantiene un registro de los cambios realizados.

• Permite llevar múltiples versiones del código mientras se continua trabajando sobre dicho código.

¿Qué se debería guardar?
Para saber que debemos guardar en el repositorio haz la siguiente pregunta: ¿Si no tengo una versión actualizada de x, ¿podría compilar, probar y distribuir la aplicación? Si la respuesta es no, entonces x debe guardarse en el repositorio.

Además de los ficheros anteriores, también se debe guardar cualquier cosa que ayude a entender la aplicación, ya sea documentación interna o externa, el texto de los correos electrónicos que hayan sido importantes en el desarrollo de la aplicación, información,....

No se deben guardar los ficheros que se pueden generar con ficheros ya existentes, por ejemplo: la documentación que generamos mediante la documentación incluida en el código fuente usando herramientas auxiliares.

Tags - Etiquetas
Es un nombre que se asigna a un conjunto de ficheros en un estado determinado del proyecto. De este modo podemos recuperar esos ficheros tal y como estaban en ese momento.

Branches - Ramas.
Se llama Trunk a la rama principal del código donde se trabaja normalmente. Es decir, los ficheros del repositorio donde hacemos los cambios diariamente.
Pero, si estamos próximos al lanzamiento de la aplicación, no podemos añadir más funcionalidad pues esa funcionalidad será para una futura versión, y seguramente no estará termianda para el lanzamiento de la aplicación. Entonces, lo que podemos hacer es crear una rama que contendrá el código fuente para una determinada versión de la aplicación. Es lo que se conoce como release branch.

Cuando creamos una rama tenemos 2 proyectos con un futuro distinto para cada uno de ellos. De esta manera tenemos el código de la aplicación que vamos a lanzar y el de la futura versión perfectamente diferenciados.
Si después del lanzamiento de la aplicación se encuentran fallos se corregirán en la rama correspondiente, así podemos generar la misma versión con los fallos corregidos, y esos cambios para reparar el bugs en la release branch se fusionan con la rama principal o trunk branch.

En general, un proyecto tendrá una rama principal (trunk), y por cada lanzamiento podemos añadir otra rama (release branch). Una release branch no cambia mucho durante su vida, sólo para corregir los fallos que se puedan encontrar.

Los cambios significativos en la vida de un proyecto se marcan amenudo con etiquetas. Una etiqueta podría contener el código usado para lanzar una determinada versión de la aplicación.

Merging - Fusionando.
Esos cambios se deben añadir también a la rama principal para que estén corregidos en la próxima versión.
Se pueden fusionar los cambios hechos para fijar el error en la rama correspondiente con la rama de la siguiente versión sin usar el copiar y pegar.
Mantener el código entre las distintas ramas puede ser complicado, por eso es recomendable no tener muchas ramas.

Logs
Cuando un fichero es modificado y puesto en el repositorio se puede añadir una nota. En esa nota no se explica el cambio realizado, ya que este se puede obtener al ver las diferencias entre los ficheros. Lo que debemos poner en el log es el por que se ha realizado el cambio. Si el cambio es para fijar un bug se debe poner la identidad del bug en la aplicación que usemos para llevar el control de errores.

Tip 11: DRY—Don't Repeat Yourself - No te repitas

Un programador reune, organiza, mantiene y utiliza conocimientos. Se documentan en las especificaciones, cobran vida al ejecutar el código y se usan durante los test al comprobar los resultados.
Estos conocimientos no son estables y cambian durante el desarrollo de la aplicación.

Una buena costumbre es no duplicar el conocimiento. Debe ser expresado en un sólo lugar, así, si este conocimiento cambia, sólo habrá que modificarlo en dicho lugar.

La mayoría de las duplicaciones se pueden encontrar dentro de las siguientes categorías:

• Duplicación impuesta. Parece que no hay elección, el sistema parece que requiere de duplicación. Con un poco ingenio puede que se evite la duplicación. Al documentar el código se está duplicando información, para evitarla, el propio código debe ser la documentación de bajo nivel, mientras que los comentarios sería la explicación de de alto nivel.
  
• Duplicación inadvertida. A veces se está duplicando la información por errores en el diseño. Por ejemplo, una linea esta compuesta por 2 puntos o por un punto y un ángulo y una distancia. Una clase que define la linea tiene información duplicada si tiene 2 puntos y una longitud.
  
• Duplicación impaciente. Se duplica porque parece más fácil copiar y pegar y modificar un poco. En ese momento puede resultar beneficioso, pero a la larga requerirá más tiempo.
  
• Duplicación multiprogramador.Varios programadores duplican información. Para evitarlo lo mejor es una buena comunicación entre programadores.
  

Tip 10: It's Both What You Say and the Way You Say It - Es tanto lo que se dice como la manera en que se dice.

Un programador se comunica de muchas formas diferentes, en el grupo de trabajo, con el usuario final, con el ordenador,... por lo tanto debe hacerlo bien. Algunas ideas para llevarlo a cabo son:

Saber lo que se quiere comunicar. Hay que planear lo que se quiere comunicar y refinarlo para comunicar lo que realmente queremos.

Conocer a la audiencia. Para eso algunas preguntas que podemos hacernos son:
¿Qué quieres que aprendan?
¿Qué interés tienen en lo que pretendes comunicar?
¿Cuantos detalles quieren?
¿Cómo pueden motivarse para que escuchen?

Elegir el momento. La última hora de un viernes generalmente es un mal momento para realizar cualquier comunicación. También se pueden presentar ocaciones en las que una propuesta sea aceptada por algún acontecimiento que haya sucedido.

Elegir el estilo. En algunos casos puede valer con unas lineas, un correo. En otros se puede necesitar un documento detallado. Si hay dudas, lo mejor es preguntar.

Hay que hacerlo bonito. No sólo el contenido es importante, el formato, el tipo de letra, las faltas de ortografía,...

Implicar a los destinatarios para que nos comenten que les parece el documento.

Escuchar. Si escuchamos seremos escuchados. Hay que animar a hacer preguntas para hacer de la presentación un dialogo.

Siempre responder en el momento, aunque la respuesta sea que lo vas a mirar. Hay que mantener a las personas informadas para que no sientan que nos hemos olvidado del asunto.

Tip 9: Critically Analyze What You Read and Hear - Analiza criticamente lo que leas y oigas

No hay que creer todo lo que se lee, hay que analizarlo.
No sabemos los intereses que puede haber detrás de ese artículo que estamos leyendo.

Tip 8: Invest Regularly in Your Knowledge Portfolio - Ampliar conocimientos regularmente.

El Knownledge Porfolio de un programador es como una cartera de inversiones y por lo tanto hay que:

- Invertir regularmente: Aunque sea una pequeña cantidad, la suma es lo importante.
- Diversificar: Cuantos más conocimientos diferentes se tengan mas valor tiene el programador.
- Administrar el riesgo: No hay que especializarse demasiado en una tecnología.
- Compra barato, vende caro: Aprender alguna tecnología que está empezando puede ser duro, pero la ventaja de ser de los primeros en usarla puede tener grandes recompensas.
- Revisa y reequilibra: Esta es una industria muy dinámica, lo que hoy es última tecnología mañana puede estar anticuada.

Los consejos que nos dan para conseguirlo son:

- Aprender al menos un lenguaje cada año.
- Leer un libro técnico cada trimestre.
- Leer libros no técnicos también, porque no hay que olvidar que los ordenadores los usan personas.
- Asistir a clases.
- Participar en grupos locales.
- Experimentar con distintos entornos, si en el trabajo usas Windows en casa usa Linux por ejemplo.
- Estar actualizado, subscribiendose a listas de noticias sobre tecnología,...
- Conéctate, navega por Internet para encontrar información que te puede ser útil.

Todo esto necesita tiempo, y no se dispone de mucho, por lo que hay que tener preparado algo para leer en los tiempos muertos.

Tip 7: Make Quality a Requirements Issue - Haz la calidad un requerimiento.

El alcance y la calidad de un sistema debería estar especificado en la tabla de requisitos.

Los usuarios finales deberían probar el software e indicar si es lo suficientemente bueno para sus necesidades. Luego se podrá añadir más funcionalidad o no. Un software bueno hoy es preferible a un software perfecto mañana.

Hay que saber cuando parar, se puede echar a perder el código si se intenta refinar en exceso. Puede no ser perfecto, pero no hay que preocuparse, podría no ser perfecto nunca. Hay que dejar un tiempo que haga su trabajo.

Tip 6: Remember the Big Picture

Se debe revisar continuamente lo que pasa alrededor, no sólo lo que estás haciendo tu.

Puede ser que se estén haciendo cambios pequeños que pasan desapercibidos, pero muchos cambios pequeños al final es un cambio muy grande.

Tip 5: Be a Catalyst for Change - Se un catalizador para el cambio.

Hay ocasiones en las que un programador sabe lo que quiere hacer, pero no encuentra apoyo (ya sea de sus superiores o de compañeros) para llevarlo acabo.

En estos casos lo que hay que hacer es trabajar en ello, hacerlo bien y cuando se tengan algunos resultados enseñarlos. Si es interesante te propondrán mejoras, e incluso se unirán al proyecto.

Es más sencillo unirse a algo que ya está en marcha que empezar desde cero.

Tip 4: Don't Live with Broken Windows - No vivas con ventanas rotas.

Las ventanas rotas son en éste caso: un mal diseño, decisiones o código erróneo,... Hay que arreglarlo tan pronto como se descubra. Si no hay tiempo se puede comentar el código, mostrar un mensaje,... lo que sea para evitar un posible problema e indicar que la situación está bajo control.

En general las leyes físicas no afectan al desarrollo de software, aunque la entropía ataca duro. La entropía es un termino de la física que hace referencia a la cantidad de desorden de un sistema. Desafortunadamente las leyes de la termodinámica nos dicen que la entropía en el universo tiende a incrementar.

Un coche abandonado puede pasar meses en perfecto estado, pero como se rompa una sola ventana, en horas estará desguazado.

Si te encuentras trabajado en un proyecto con algunas "ventanas rotas" es muy fácil pensar que todo el proyecto está en el mismo estado y no te molestarás en hacer buenos aportes al proyecto. Por la misma regla, si te encuentras en un proyecto donde el código está bien comentado, ordenado, limpio, elegante,... tendrás mucho cuidado para no desordenarlo.

Tip 3: Provide Options, Don't Make Lame Excuses - Proporciona opciones, No pongas malas excusas.

Un programador no tiene que tener miedo de admitir su ignorancia o un error cometido. Los errores los comete cualquiera, pero hay que tratarlos de manera profesional. Esto significa ser honesto y directo.

Cuando se comete un error hay que admitirlo honestamente y buscar soluciones. No hay que culpar a alguien o algo o poner excusas. En vez de buscar excusas hay que buscar soluciones.

Tip 2: Think! About Your Work - Piensa en tu trabajo.

Un programador debe pensar en lo que está haciendo mientras lo está haciendo. Tiene que hacer una evaluación de cada decisión que tome. Pensar constantemente en su trabajo y criticarlo en tiempo real.

Esto quitará algo de tiempo, pero la recompensa es una implicación activa en el trabajo que le gusta, el sentimiento de dominio sobre un creciente número de materias y el placer de sentir un continuo perfeccionamiento.

A la larga, el tiempo invertido se recompensará convirtiéndolo en un eficiente programador, escribiendo código más sencillo de mantener y pasando menos tiempo en reuniones.

InvokeRequired

Ya se que cuando queremos actualizar un formulario o control desde un thread distinto al que creo el control hay que usar el método Invoke o BeginInvoke pasandole un delegado a ejecutar.

Para no tener que definir el delegado podemos usar los metodos anónimos.

if( this.InvokeRequired )
{
    this.Invoke( (System.Threading.ParameterizedThreadStart)delegate( object o )
                      { UpdateProgressBar( current ); } , current );
}

o este si no necesitamos pasar parámetros

if( InvokeRequired )
{
    this.Invoke( (MethodInvoker)delegate() { StopTest(); } );
}

Tip 1: Care About Your Craft - Preocupate de tu oficio

Cada programador es único, con sus puntos fuertes y sus puntos débiles, pero los programadores pragmáticos comparten las siguientes características:

Se adapta rápidamente a nuevas técnicas y tecnologías. Le gusta intentar cosas nuevas.

Es curioso. Se pregunta qué son y como estarán hechas las cosas.

Es un pensador critico, no toma las cosas sin antes cuestionarlas.

Es realista, intenta comprender el fondo de cada problema para así conocer su dificultad.

Es un manitas, intenta familiarizarse y mantenerse al día con un amplio rango de entornos y tecnologías aunque en su trabajo sea un especialista en alguna materia.

Pragmatic Programmer, The: From Journeyman to Master

Este es el título de un libro que dice que me ayudará a ser un mejor programador, a hacer mejor mi trabajo. A ver si ses verdad.

Se basa en la experiencia de 2 programadores, Dave and Andy, que a lo largo de su carrera han recopilado información de como hacer las cosas para hacer mejor su trabajo, la han usado para superarse ellos mismos y han desechado lo que no funcionaba.
No es una teoría del desarrollo del software. Nos cuentan como programan ellos.
Programar es un trabajo lleno de detalles, no es sólo teclear comandos en un lenguaje de programación, es un arte.

A lo largo del libro va dando una serie de consejos para convertirse en un buen programador. Cada consejo está basado en su experiencia.

Aquí intentaré ir haciendo un resumen de cada uno de ellos.