Por un lado, un usuario que se enfrenta por primera vez a una aplicación iPhone se encuentra con elementos intuitivos y sencillos de utilizar. Por otro lado, cuando este usuario vaya avanzando en su proceso de aprendizaje irá descubriendo que la mayor parte de las aplicaciones disponibles para este terminal comparten esos elementos de la interfaz, y por tanto, utilizar una nueva aplicación no le supondrá tener que aprender a manejarla.

Hay unas cuantas aplicaciones disponibles que en su afán por diferenciarse del resto han intentado reinventar la rueda. Con esto solo han conseguido tirar a la basura todo el excelente trabajo hecho por Apple y como resultado han obtenido una aplicación poco intuitiva para el usuario acostumbrado a una serie de elementos comunes en todas las aplicaciones de iPhone.

Muchas veces, no es necesario reinventar los elementos existentes para poder hacer algo diferente. Un ejemplo bastante típico es el de Postage de la empresa RogueSheep quienes han sabido hacer una aplicación que parece diferente pero que utiliza los elementos característicos (y alguna innovación como es la selección de tipografía).

Fijaros como gracias a un cambio en la tonalidad y la utilización de iconos nuevos han conseguido un diseño diferente pero intuitivo. Al fin y al cabo mantienen la barra de navegación superior y también utilizan “tabs” o pestañas en la parte inferior, dos patrones muy típicos en las aplicaciones para iPhone.

Las aplicaciones para móviles deben ser sencillas. Hay que pensar que la plantalla es pequeña y por tanto tendremos que tener especial cuidado con el tamaño del texto que no debe ser ni muy grande ni muy pequeño, con la cantidad de elementos que mostramos y con la disposición que hacemos de estos. Ha de haber un balance general. Veamos un ejemplo de lo que no se ha de hacer:

A la derecha podemos ver la primera versión de la aplicación TripLog. En este caso se observan varios errores de diseño de los que hemos hablado antes. Por un lado se han utilizado demasiados elementos, por el otro, estos no están alineados dando una sensación de desorden y confundiendo al usuario. A la izquierda, podemos ver la versión actual de la aplicación. En este caso a pesar de que hay demasiados elementos estos están mejor alineados y mejoran un poco la percepción que se tiene.

Como ya hemos dicho, siempre tiene que haber un balance. Cuando el contenido de una vista es excesivo y observamos que sobran elementos, tenemos que replantear el flujo de trabajo de la aplicación. La mejor manera de conseguirlo es tener en mente los modelos o patrones por defecto que Apple ofrece. Haciendo un repaso de ellos veremos que el 99% de las aplicaciones existentes se basan en uno de estos patrones o elementos.

Barra de navegación / Navigation bar

Barra con elementos de control

Barra con elementos de navegación

Barra multisegmentos

Barra con título sin elemento

Barra de herramientas / Toolbar

Permite ejecutar acciones sobre la vista actual, normalmente se coloca en la zona inferior

Un ejemplo

Barra de pestañas / Tab bar

Permite cambiar de vista

Un ejemplo: En la aplicación Clock de iPhone la barra de navegación permite cambiar entre los diferentes modos

Aun quedan muchos otros elementos por mostrar: tablas, botones, alertas, etc. Sin embargo, estos son los principales elementos de control sobre las diferentes vistas y son los que ayudan a definir el flujo de nuestra aplicación. Haced el ejercicio de ver cuántas de las aplicaciones de iPhone que utilizáis se basan en alguno de estos controles y veréis que la gran mayoría los utilizan. Como ya hemos dicho, son la clave para conseguir una experiencia de usuario agradable y un proceso de aprendizaje sencillo e intuitivo.

Así han aparecido multitud de metodologías de desarrollo ágil como pueden ser Extreme Programming o Scrum. Parte de la filosofía de estas metodologías consiste en reducir al mínimo el proceso de documentación y evitar mantener largas reuniones para tomar las decisiones necesarias.

Sin embargo, que el desarrollo se haga de manera ágil no significa que se deba obviar el proceso de captura de requisitos, testeo y documentación. Por el contrario, consiste en utilizar otro tipo de técnicas que permita realizar estos procesos de manera sencilla y productiva.

En 21projects y en muchas otras empresas de desarrollo se utiliza una herramienta de gran valor y potencial. Se trata de Trac. En la web de este proyecto open source se define a la herramienta de la siguiente manera:

Trac is an enhanced wiki and issue tracking system for software development projects. Trac uses a minimalistic approach to web-based software project management.

Resumiendo, Trac es una herramienta que permite llevar un control de las funcionalidades y errores del código que se está implementando. Sin embargo, Trac es una herraminta mucho más completa que esto, pues está construido sobre una wiki que permite documentar todo el software sobre una única plataforma, integrando la documentación con el control de funcionalidades y errores a implementar así como también con el propio código a través de un repositorio de Subversion del cual ya se habló en un post anterior.

Conozco mucha gente que después de haber probado Trac en su equipo de desarrolladores han dicho frases como: “No se como puedo haber vivido hasta ahora sin una herramienta como Trac”. Y la verdad es que, aunque no se trata de una herramienta imprescindible, sí que resulta extremadamente útil. Además de las opciones básicas de Trac, también es posible instalar nuevos plugins que cubren desde la integración de repositorios Git hasta la gestión de metodologías ágiles como Scrum.

¿Pero qué significa todo esto a la hora de la práctica? Lo mejor es verlo con un ejemplo. Veamos como sería el proceso de creación de un nuevo proyecto en el equipo de 21projects (Trac puede utilizarse para cualquier tipo de lenguaje, ya sea una aplicación web, desarrollo para iPhone o Android o bien para gestionar documentación, imágenes o cualquier otro tipo de contenido).

Captura de requisitos:

En esta fase, nos reunimos todo el equipo de desarrolladores (y el cliente, si se trata de un proyecto para terceros) bien en persona o utilizando un documento compartido en GoogleDocs para definir cuáles son los requisitos de la aplicación. Normalmente, primero desarrollamos los casos de uso básicos de la aplicación y a partir de ellos creamos la lista de requisitos, siempre en colaboración directa con el cliente.

De esta fase saldrá una lista de requisitos funcionales con una descripción de cada uno, dejando claro qué es lo que se espera y que ha de tener para que se considere que ese requisito está “hecho”.

Integración de los requisitos en Trac:

A partir de este momento, procederíamos a ingresar en Trac cada uno de los requisitos como un nuevo Ticket. En Trac, cada funcionalidad a implementar o cada bug debe ser introducido como un Ticket, que estará asociado a una persona y a un Milestone del proyecto así como a una serie de propiedades adicionales como pueden ser la versión del desarrollo, el tipo de Ticket, o la severidad de este. Un Milestone es un hito de desarrollo que se propone. Dentro de Trac podemos crear tantos Milestones como queramos y ponerles una fecha límite. Así, se podría decidir crear un nuevo Milestone que representa el lanzamiento de la primera versión del producto y todos los Tickets de esta iteración serán agregados a este Milestone.

Interfaz de creación de Tickets

Trás haber ingresado todos los Tickets en el sistema, cada desarrollador participante podrá decidir en qué funcionalidad va a trabajar y asignarse ese Ticket, que quedará marcado con su nombre para que los demás sepan que él está trabajando en su implementación.

Mientras el desarrollo esté en curso, podremos utilizar la Wiki de Trac para ir documentando todo el proceso. Aunque esta Wiki tiene una sintaxis particular que viene reflejada en la documentación de la aplicación, sus posibilidades son muy amplias e interesantes, ya que por ejemplo, cada vez que pongamos el caracter “#” seguido de un número se creará un enlace automáticamente al Ticket que tenga asignado ese número (cada Ticket tiene un identificador numérico único).

En nuestro caso, utilizamos la página principal de nuestro Trac (que es una página wiki) para enlazar los diferentes documentos que utilizamos, mantener una lista de enlaces externos de interés y documentar los proyectos propios y de clientes así como las ideas de posibles proyectos futuros.

Página principal del Trac de 21projects

De esta manera, es posible ir documentando todo el proceso de desarrollo, incluir imágenes, enlaces y crear una documentación fácil de modificar y sobre todo, muy potente gracias a las funcionalidades de Trac.

Cada vez que un desarrollador acabe con la implementación de un Ticket, deberá marcar ese Ticket como resuelto y trás haber subido el código al repositorio Subversion, este cambio se reflejará en Trac a través de la sección que nos permite navegar por nuestro código.

Aunque existen muchas otras funcionalidades que vienen con Trac por defecto y muchas más que pueden añadirse a través de nuevos plugins, os dejamos que experimentéis con esta fantástica herramienta que permite mejorar la gestión de un nuevo proyecto software tanto a nivel de código como a nivel de documentación. Otra fantástica idea es abrir el Trac para que los usuarios u otras empresas puedan ver lo que hacemos e incluso colaborar añadiendo nuevos Tickets al encontrar un bug en la aplicación.

Si tenéis cualquier duda acerca de esta herramienta u os interesa utilizarla en vuestro negocio y no sabéis como empezar contactad con nosotros, estaremos encantados de ayudaros.

Descubrí el otro día la presentación Thinking Visually de David Armano, y me produjo una buena sensación asi que busqué el vídeo de su charla en Chicago. Lo acabo de ver confirmando las buenas vibraciones y recibiendo los buenos consejos que da cuando quieres comunicar algo visualmente. Para empezar una frase que hace pensar:

Los ojos no son responsables cuando es la mente la que ve

Podéis ver en la presentación los 6 pasos que utiliza él, nosotros variamos y especializamos un poco su uso para nuestros proyectos. Lo voy a denominar la técnica OSEC, cuatro pasos para desarrollar una buena interfaz o envoltorio:

1. Observa. Ve el mundo con los ojos de un niño. Tienes que observar todo sobre el proyecto, preguntar todo lo que se te ocurra, ver qué hacen los competidores, qué esperan los clientes o cuáles son las tendencias.
2. Sintetiza. Analiza todo y con todo lo que has sacado, pregúntate cuál es la esencia; qué es lo que se quiere transmitir, qué es lo que se quiere hacer. Separa lo esencial de lo que no es necesario.
3. Esboza. Coge un papel y dibuja los esquemas, las interfaces de las pantallas principales expresando la esencia; constrúyete los casos de uso dibujándolos y comprueba que es eso lo que se quiere conseguir. Dibuja en papel tanto como quieras. Espera un día, y vuelve a pensar desde cero. Si ves que algo no cuadra, vuelve al punto 2 y pregúntate de nuevo qué es lo importante.
4. Construye. Ya sabes lo que quieres conseguir así que es hora de ponerse manos a la obra. Sé fiel a tus dibujos, pero no intentes hacerlo simétrico. A veces cuando dibujamos y pensamos no nos damos cuenta de ciertas dificultades. Rodea esos problemas para que se siga manteniendo esa sencillez.

Con estos 4 pasos conseguimos mejorar la idea inicial, potenciando lo diferencial y haciéndolo tremendamente intuitivo. Cada uno tiene su método así que estamos encantados de escuchar el vuestro y saber qué puntos añadiríais.

Como recomendación del autor me estoy leyendo ahora mismo el libro Don’t make me think! que es una referencia en el campo de la usabilidad web. No hay más que ver la media que tiene en Amazon (4,5/5 sobre más de 500 críticas). Ya comentaré más adelante sobre las conclusiones que estoy sacando.

• Los usuarios cometen más errores porque no ven lo que escriben y por tanto se sienten menos confiados.
• Cuando la gente comete errores suele escoger contraseñas fáciles de escribir o copia y pega de un archivo. Ambas opciones hacen que haya riesgos de seguridad importantes.

Asi que el propósito inicial de ocultar la contraseña a ojos ajenos provoca que escojamos contraseñas más fáciles de romper. En el ordenador puede ser más necesario ocultar la contraseña aunque Jakob propone tener un checkbox donde cambiar si la mostramos o la ocultamos (plugin de jquery).

Sin embargo en el móvil no lo veo necesario ya que es un aparato personal con una pantalla que ves tu solo, y por lo tanto no supone tanto riesgo de seguridad. La comodidad que le das al usuario de ver lo que está escribiendo supera con creces los posibles peligros de ojos ajenos. Esta es una opinión personal que intento compartir con nuestros clientes, pero supone un cambio en la mentalidad de seguridad.

Ahora bien, si entramos en el aspecto técnico y el campo de contraseña se convierte en un simple input los navegadores o el sistema operativo en el caso de los móviles puede guardar en caché la contraseña y mostrarla la próxima vez que teclees. Algo totalmente erróneo como bien apunta Mike Andrews. La mayoría de los usuarios que comentan en este artículo no creen que esto deba aplicarse a la Web. Incluso sería vulnerable a los virus que hacen capturas de pantalla de tu ordenador.

Aún así, no soy el primero que lo ve bien para los móviles (especialmente aplicaciones). En el GAP (una especie de guía de desarrollo para webs en versión móviles) tratan este mismo tema y recomiendan que se muestre el campo de contraseña.

Do not use password masks
Reading what is on the screen of a mobile device is often hard enough for the user of the device. Peeking over the shoulder of the user is less likely to disclose a password than observing the user’s keypress sequence.
For this reason, hiding user input to users themselves by replacing each character with a ‘*’ (star) symbol (or similar) will do very little to protect privacy, while making it generally harder to use the service. For this reason, users should be made enter passwords in clear text.
This practice does not detract from the aforementioned practice to avoid login and find alternative ways to identify users.
Caveat: In case of highly sensitive application (such as ‘Net Banking’), security requirements may force you to overlook this practice. For example, some users may perceive the lack of password obfuscation as a sign of slack security practices.

Y ya que hablamos de contraseñas varios consejos a la hora de diseñar vuestro servicio web:

• Las preguntas de seguridad son un arma de doble filo, porque mucha gente escribe respuestas muy fáciles de adivinar; como se ha podido demostrar con Britney Spears, Sarah Palin, etc. Yo no las recomiendo e intento evitarlas.
• No se debe enviar la contraseña al email cuando el usuario se registra. La razón es que si entran al email de ese usuario le pueden encontrar las contraseñas y producirse un robo en cadena. Las opciones son, o bien dejar al usuario que escoja su contraseña al registrarse (mi opción preferida) o mandarle una aleatoria al email pero obligarle a cambiarla nada más conectarse a la web (más trabajo para el usuario).
• También nos podemos plantear la duda de si obligar al usuario a escribir dos veces su contraseña. Desde este artículo rechazan esta convención. Argumentan que porque un 1% de los usuarios se equivoque al escribir la contraseña no tenemos que perder tiempo el 99% restante. En ese punto yo prefiero mostrarlo dos veces y compararlo mediante javascript antes de que dé a enviar. Si no lo hacemos así, puede que perdamos a ese 1% que se encuentre desorientado porque no funciona la contraseña que acaba de poner.
• Respecto a escribir dos veces el email, ahí si que no. El usuario puede ver lo que escribe, muy poca gente se debería equivocar.

Una situación curiosa se produjo en una web cuyo formulario de registro consistía en solo su email como nombre de usuario y la contraseña que querían poner. Notaron que mucha gente no se registraba y haciendo un test de usabilidad descubrieron que la gente creía que les estaban pidiendo la contraseña de su email. Por eso la gente no se fiaba y no se registraba. Algo parecido puede ocurrir ahora con las conexiones a Flickr, Google, Del.icio.us, etc. Si es posible no hay que pedir al usuario la contraseña de estos sitios, si no usar el protocolo OAuth para conseguir el permiso y dar mayor sensación de control a nuestros usuarios.

¿Qué opináis? ¿Cuáles son vuestras experiencias?

Con 21projects estamos todavía en las fases iniciales asi que estamos implementando las sugerencias que voy a proponer a continuación. Sin embargo, dichas sugerencias están basadas en artículos, en experiencias de conocidos y de marcas online, y por supuesto, en el sentido común.

1. No te dediques solo a vender, conoce a la gente

Cuando tenemos una tienda física, o cuando vamos a eventos; hablamos de todo tipo de asuntos, no sólo de promocionar nuestra empresa o producto. Lo mismo tenemos que hacer en Internet, ya sea en Twitter, redes sociales, foros o webs especializadas. Una mala estrategia es dedicarte solo a vender, tienes que darte a conocer, crear confianza, demostrar que no quieres solo ventas si no fans de tus productos. Aprende a escuchar, y ten conversaciones diversas como tendrías en la vida real.

Otra razón para poner en práctica esta forma de comunicación es la siguiente: puede que comiences una conversación con alguien que no va a ser cliente tuyo ahora mismo, pero tiene un círculo de amigos y conocidos a los que hablar de tu producto. Si eres muy pesado y sólo te preocupas de vender, no llegarás a ese círculo de gente; si eres transparente, agradable y le cuentas cosas interesantes, entonces estarás haciendo un gran trabajo para promocionarte, tanto a ti como a tu marca.

2. Presta atención a lo que dicen tus clientes y actúa

Gracias a Twitter o Google Reader podemos saber lo que dicen nuestros clientes o potenciales clientes prácticamente en tiempo real. No hace falta llegar al extremo de estar pendiente todo el tiempo, pero sí es muy recomendable dedicarle un rato cada día a seguir lo que dicen los blogs sobre tu producto, a seguir los twits y a responder a casi todo, agradeciendo el apoyo si es positivo, pidiendo consejo para mejorar en casi todas las ocasiones, y en analizar qué falla, si el comentario ha sido negativo.

Como bien se dice, es imposible controlar lo que se habla de ti; lo que tienes que hacer es seguirlo y si es negativo, intentar arreglarlo o saber cómo evitarlo para la próxima vez. Tampoco hay que pensar que todas estas acciones tendrán un beneficio inmediato, todo lleva su tiempo; pero si tu producto es bueno, ayudará a que se conozca cada vez más.

3. Participa en varias comunidades

Sabemos que tu tiempo es limitado, pero en cuantas más webs y redes sociales estés activamente, mejor. Por supuesto tendrás que elegir cuál te viene mejor. Yo elegiría Twitter y Facebook seguro. En España puede que Tuenti funcione en un futuro cercano si tu target es un público jóven, pero por ahora no es tan fácil. Luego iría a webs, blogs, foros o redes verticales de tu sector. Es básico que estés donde están los early adopters, aquellas personas que están dispuestas a ser los primeros en probar tu producto y ayudarte a mejorarlo. Tienes que moverte en foros, blogs; ir transmitiendo de forma natural tu opinión a muchos temas, compartiendo tu experiencia. Es importante recordar el punto 1, no hay que estar vendiendo en todos los mensajes. Si dejas un mensaje coherente e inteligente, la gente ya irá a tu web y te conocerá. Ganas más diciendo algo que aporte valor sin mencionar directamente tu producto, que poniéndolo (seguramente te borren el mensaje).

4. Comienza un blog de tu empresa

¿Por qué en vez de ir a Twitter a buscar potenciales clientes, no creamos nuestra plataforma donde comentar las novedades de nuestra empresa? Eso es lo que permite el blog, una herramienta donde comunicar los avances, los desarrollos y las novedades de tu empresa. Pero como ya he dicho antes, no te dediques solo a vender; comenta también acerca de las actividades que hacéis, o comparte vuestra experiencia en la tecnología o manera de enfocar las cosas. También es muy útil preguntar a vuestros lectores sobre cómo mejorarían vuestros productos o qué productos les gustaría tener.

Por último os dejo con 35 ejemplos de social media en empresas grandes, y una completa lista de cómo las empresas usan los blogs, crean comunidades o usan Facebook y Twitter para llegar a sus clientes. Y otro más de regalo con algunos ejemplos repetidos. Cada semana, intentaremos escoger un ejemplo de social media que ha tenido muy buenos resultados para explicar sus claves.

La gestión de los cambios que se producen sobre el software se convierte en algo indispensable cuando varios programadores trabajan sobre el mismo código. El utilizar una herramienta de este tipo facilita la labor de integrar el código de los diferentes participantes y sobre todo, permite llevar un control de los cambios que se han realizado sobre cada uno de los componentes software.

Los sistemas de control de versiones y configuraciones no solo se aplican al desarrollo de software, sino también a otros campos, como por ejemplo, documentos, imágenes o páginas web. En 21projects trabajamos con varios lenguajes de programación y todos ellos conviven en nuestro sistema de control de versiones. Incluso cuando desarrollamos para iPhone o Android, donde suele intervenir un único programador, también mantenemos todo el código en nuestro repositorio central, evitando así que pueda perderse el software debido a algún fallo en disco de nuestros PCs o algún otro inconveniente.

En este caso, vamos a hacer una introducción a la herramienta de gestión de versiones que utilizamos en 21projects. Subversion es una herramienta open source diseñada exclusivamente para sustituir a su antecesor, CVS, que presentaba algunos inconvenientes muy importantes a la hora de gestionar el software (por ejemplo, no es posible renombrar un fichero o eliminar un directorio que tenga archivos dentro). Subversion ha sido diseñado según una arquitectura cliente-servidor, en donde cada programador edita el código localmente y lo “sube” a un repositorio central, el servidor Subversion.

Para conocer ventajas e inconvenientes adicionales de Subversion os dejo al final los enlaces a la Wikipedia y a su Web oficial. Existen otras alternativas a Subversion, como Git, de las que hablaremos en otro post. Lo realmente importante que quería transmitir en este artículo era el uso de Subversion (aka SVN) y algunas recomendaciones personales para evitar problemas.

Una de las grandes incógnitas que pueden surgir a la hora de decantarse por Subversion es si instalarlo en nuestros propios servidores o bien subcontratar el servicio a una empresa que se dedique a ello. En el caso de 21projects hemos decidido subcontratarlo y por ello no os vamos a explicar como instalarlo (aunque es muy sencillo). Los motivos para haber tomado esta decisión son los siguientes:

• Necesidad de centrarnos en nuestro business core y no dedicar tiempo a mantener las herramientas, que como Subversion, deben facilitar nuestra labor y no suponer un problema añadido.
• Bajo coste del servicio subcontratado.
• Los datos guardados en el repositorio son de gran importancia para nuestro negocio, es por ello que preferimos confiar en una empresa externa que se encargue de mantener backups periódicos de la información y que pueda ofrecernos garantías.
• Integración con otras herramientas cuyo mantenimiento e instalación no es trivial. Por ejemplo, Trac (hablaremos de esta herramienta en otro post).

Es por estos motivos que en 21projects hemos decidido confiar en otra empresa y delegar la responsabilidad de su mantenimiento. En nuestro caso trabajamos con RepositoyHosting, una empresa que ofrece un plan de precios muy sencillo y económico, con unas características más que de sobra y un plan de administración que aunque sencillo es muy cómodo. Adicionalmente, RepositoryHosting también ofrece Trac integrado lo cual era una condición indispensable a la hora de elegir la empresa.

Una vez que contratado el servicio, es necesario crear un repositorio para nuestros proyectos. Un repositorio puede comprenderse como un directorio con sus respectivos subdirectorios y ficheros. En dicho repositorio se almacenará el software y podemos elegir tener un único repositorio para todos nuestros proyectos o bien crear uno nuevo por cada proyecto.

Antes de comenzar con el uso de Subversion, quiero comentar que para organizar los proyectos se suele asumir un convenio. Se trata de crear por cada proyecto tres directorios bajo los cuales se guardará nuestro software. La explicación de cada uno de los directorios es la siguiente:

• Trunk: Directorio de un repositorio bajo el cual se encuentran los directorios y ficheros de nuestro proyecto.
• Tag: Directorio bajo el cual se almacenan las diferentes versiones o releases de nuestro software.
• Branches: Directorio donde se almacenan ramas de nuestro proyecto. Una rama es una desviación que se toma a partir de una versión del software para desarrollar alguna funcionalidad en paralelo con el desarrollo principal para su posterior integración. Hay empresas que trabajan realizando ramas nuevas por cada funcionalidad que se desea añadir y las hay que procuran no hacer ramas nuevas para evitar los posibles problemas de integración en un futuro. Nosotros preferimos una alternativa intermedia, procurando abrir una nueva rama cuando no es seguro que la funcionalidad a implementar se vaya a integrar con la versión principal (por ejemplo, para pruebas de concepto).

Por otro lado, queda comentar los principales comandos para trabajar con Subversion:

• Import: Comando utilizado para subir al repositorio la estructura inicial de nuestro proyecto.
• Checkout: Comando para descargar en un PC un proyecto desde un repositorio.
• Add: Comando utilizado para añadir un fichero a nuestro proyecto. No es subido al repositorio hasta que se indique con el comando “commit”. El comando add solo deja “marcado” ese fichero o directorio como parte del repositorio.
• Delete: Comando que permita marcar un fichero o directorio para ser eliminado del respositorio.
• Commit: Comando que nos permite subir al repositorio todos los cambios hechos sobre un proyecto en local.
• Update: Comando que nos permite actualizar nuestro proyecto en local desde el repositorio central.

Aunque existen clientes gráficos para la comunicación con un repositorio Subversion, voy a poner un ejemplo de cómo se interactúa con un servidor Subversion desde consola.

Primero creamos la estructura de directorios de nuestro proyecto en local:

mkdir miProyecto
cd miProyecto
mkdir trunk branches tags

A continuación, subimos la estructura inicial al repositorio en el servidor central:

svn import miProyecto http://urlDelRepositorio/ -m "Initial import"

Ahora podemos borrar el directorio que habíamos creado inicialmente en local:

cd ..
rm -r miProyecto/

Finalmente, obtenemos una copia de trabajo del repositorio central:

svn checkout http://urlDelRepositorio/miProyecto/trunk miProyecto

A partir de este momento, comenzaríamos a programar y guardar los ficheros y directorios creados bajo el directorio miProyecto. Cada nuevo fichero o directorio creado deberemos marcarlo como parte del repositorio de la siguiente manera:

svn add file_or_dir_name

Una vez hemos terminado de hacer cambios, deberemos reflejarlos en el repositorio central en el servidor Subversion:

svn commit -m "Guardando los cambios recientes, agregada la funcionalidad X" http://urlDelRepositorio/miProyecto

Si otros programadores van a realizar cambios sobre el código, cuando queramos volver a trabajar en el proyecto deberemos obtener todos los cambios realizados sobre este a través del siguiente comando:

svn update

Para finalizar con este artículo, quiero destacar las dos reglas de oro a seguir para evitar problemas propios y evitárselos a los demás. Todos deberíamos tener estas reglas impresas en letra grande al lado de nuestra pantalla hasta haberlos interiorizado:

• Nunca harás un commit de código que no compile o tenga errores: Si lo haces, cuando otro programador haga un update su código también tendrá esos errores y por tanto no compilará.
• Siempre harás un update antes de empezar a trabajar sobre el código. De esta manera, te aseguras de estar trabajando siempre sobre la última versión del código.

Enlaces:
CVS – Wikipedia
SVN – Web oficial
SVN – Wikipedia

Una de las áreas del diseño no tan conocidas son los infogramas, las representaciones de datos e informaciones en gráficas de forma que aporten lo máximo posible manteniendo la sencillez al verlas. Las nubes de etiquetas, los votos de los electores, los mapas de pisos en venta o los mapas de expansión de la gripe A. The New York Times tiene un grupo de diseñadores y programadores trabajando juntos en nuevos infogramas representando la actualidad en mapas y gráficos de forma que aporten mucho más información.

Infograma de la gripe A por el New York Times

Muchas veces queremos mostrar datos y nos equivocamos al hacer tablas, o intentar explicarlo con palabras. Esto sucede en todo tipo de situaciones, ya sea al escribir una historia, hacer un trabajo para la universidad, preparar la presentación de un nuevo producto o intentar convencer a inversores de que tu servicio va a hacerse con el mercado. Cuando veas que algo no cuadra, párate a pensar en la esencia de lo que quieres transmitir y seguramente consigas hacerlo con la elegancia y buen hacer de estos siguientes infogramas.

Infograma de la historia de la automoción

Infograma de la densidad de población en USA

Infograma del tráfico global de Internet

Tienes mucho más ejemplos de infogramas en este artículo de Six Revisions con 40 ejemplos y en un artículo sobre este tema de la revista Fast Company.

Y tras mucho tiempo de experimentar a través de diferentes proyectos que hemos desarrollado, decidimos que era el momento de lanzarse a la piscina y comenzar a vivir esta experiencia para la que tanto tiempo nos hemos estado preparando. Aunque aún tenemos muchísimo que aprender, creemos que tenemos lo más importante que hay que tener para poder ofrecer a los demás una propuesta de valor: ilusión, pasión, tenacidad y perseverancia.

Hoy es el día, en que por fin anunciamos nuestra empresa, 21projects, una empresa dedicada a aquello que se nos da bien y conocemos. 21projects ofrece sus servicios de consultoría tecnológica y desarrollo de aplicaciones web y móviles.

Formamos parte de una nueva generación que ha nacido con la tecnología en sus manos. Y por ello, conocemos la tecnología con la que trabajamos, y sobre todo, disfrutamos al hacerlo. Lo que os ofrecemos es un servicio basado en la comunicación, la sencillez y una orientación clara hacia el usuario.

21projects está aquí para cambiar el mundo, pero queremos hacerlo paso a paso. El primero paso es convencerte del valor de lo que hacemos, para que el día de mañana se recuerde que cuidamos a nuestros clientes desde nuestro primer segundo de vida.

One, two, three… ¡lanzamos 21projects!