Conferencia ESRI 2014 – Urbagis – Solución sobre tecnología ArcGIS Online

portada-tweet

Sólo queda una semana para la conferencia de ESRI. Además, del stand que solusoft tendrá en la conferencia, me complace anunciaros que también tendremos presencia en el track de ingenierías.

El miércoles 22 de Octubre a las 16:30, junto con Sinergis, presentaremos su producto UrbaGIS, una herramienta utilizada por los ayuntamientos para la prevención de los riesgos de incendios en urbanizaciones.

UrbaGIS es un ejemplo de lo que solusoft puede desarrollar para potenciar todas las posibilidades de la tecnología ArcGIS OnLine de ESRI.

El anuncio de la charla lo tenéis en el siguiente enlace.

 

solusoft en la Conferencia ESRI España 2014

expositor_2014_v5

solusoft estará en la Conferencia de ESRI España 2014 los próximos días 22 y 23 de Octubre.

Como partners de ESRI, solusoft puede potenciar el uso de ArcGis Online con soluciones a medida aportando valor en la experiencia de usuario, integración de sistemas, adaptación a lógica de negocio, herramientas de captura de datos, etc.

Si estás interesado ven a conocernos en el stand que tendremos en la conferencia.

Retroworks en GamesUPM

Retroworks

Mañana, viernes 10 de enero de 2014, tendremos una ponencia del grupo de programación Retroworks en el marco de conferencias que ofrece el Master de Diseño y Desarrollo de la Universidad Politécnica de Madrid.

Amamos los videojuegos y nos gusta crearlos, por eso, hemos invitado a Retroworks a que nos cuenten como lo hacen en una máquina tan importante en nuestra historia como el spectrum (Sí, actualmente hay grupos de programación realizando videojuegos para esta máquina, ej: Los Amores de Brunilda).

Nada frena a la creación de videojuegos y mucho menos las “posibles” limitaciones técnicas de una máquina como el spectrum. Si estas interesado puedes venir a escuchar a Fco. Javier Velasco (pagantipaco), Javier Peña, Luis García y Augusto Ruiz a la Escuela Universitaria de Informática de 17 a 19 horas en el Salón de Grados. El acceso es libre y gratis para todo el mundo interesado.

Os dejo la dirección de la escuela en el siguiente enlace EUI.

¿Cuántos records se habrían logrado sin ayuda de la tecnología?

Eddy Merckx

Viernes 10, 6:30 de la mañana y salgo a correr con mi compañero (y amigo) de carrera de los Viernes. El frío apenas nos deja hablar y a mi me da por pensar en una charla que presencie hace unos dos meses. Relaciona la tecnología con el deporte y la actividad física.

Pues resulta que en 1972 Eddy Merckx recorrió 49.431 metros en una hora. En 1996 Chris Boardmand recorrió 56.375, es decir, 6944 metros (casi 7 kilómetros más en una hora). A primera vista no tiene por que sorprendernos, ya que estamos acostumbrados a ver como se baten records constantemente, en multitud de especialidades deportivas. Sin embargo, este último ciclista recorrió 49.441 metros (es decir 10 metros más que los realizados 24 años antes y casi 7 kilómetros menos que los realizados cuatro años antes) realizando la prueba de la hora con una bicicleta de las mismas características que la que utilizó Eddy Merckx.

¿Podríamos decir que es doping tecnológico? Lo que está claro es que en algunos aspectos hemos ganado mucho pero en otros probablemente no. Todo el deporte ha evolucionado mucho en multitud de aspectos, los atletas son más y más profesionales, los métodos de entrenamiento han evolucionado (¿o no?), los equipamientos y las instalaciones son mejores y hacen posible que las condiciones para la competición sean mejor, sin embargo, 24 años después la diferencia son 10 metros.

Esta reflexión hace que me cuestione multitud de cosas. ¿La tecnología nos ayuda y beneficia en nuestra vida diaria?. ¿O ya no sabemos que hacer sin dicha tecnología?. ¿Realmente necesitamos toda la tecnología que utilizamos?
Solo se que cada vez aparecen más compañeros de profesión que “inventan nuevos” métodos de entrenamiento, ejercicios, tendencias, etc. Realmente son mejores estos nuevos ejercicios que los anteriores. Un claro ejemplo es el Pilates (tiene una antigüedad de casi 100 años).

Valoremos más los éxitos anteriores, cuando los materiales eran más rudimentarios, y no debemos dejarnos deslumbrar por los grandes éxitos conseguidos, los records deben realizarse en las mismas condiciones. Al final la diferencia puede ser solo de 10 metros y eso nos pone en nuestro lugar.

http://www.youtube.com/watch?v=cHhuRfSFfwg&feature=related

Think Different

Este es un homenaje a los locos. A los inadaptados. A los rebeldes. A los alborotadores. A las fichas redondas en los huecos cuadrados. A los que ven las cosas de forma diferente. A ellos no les gustan las reglas, y no sienten ningún respeto por el statu quo. Puedes citarlos, discrepar de ellos, glorificarlos o vilipendiarlos. Casi lo único que no puedes hacer es ignorarlos. Porque ellos cambian las cosas. Son los que hacen avanzar al género humano. Y aunque algunos los vean como a locos, nosotros vemos su genio. Porque las personas que están lo suficientemente locas como para pensar que pueden cambiar el mundo…son quienes lo cambian.

 
Texto publicitario 60 seg para reforzar la imagen de marca de Apple cuando ésta necesitaba resurgir (y a la vuelta de Steve Jobs).

GIT. Configuración de Proyectos

GIT

GIT – Configuración de Proyectos

A continuación, se explica la configuración de proyectos para trabajar con un repositorio GIT desde máquinas MAC y con XCODE 4. La adaptación a cualquier otra máquina de lo aquí indicado es sencilla.

Aunque GIT es un repositorio distribuido vamos a tener una copia del proyecto centralizada en un servidor windows (ORIGIN). Será en este servidor donde se hagan las copias de seguirdad diariamente del código fuente. Cada programador tendrá en su máquina una copia clonada del repositorio central.

Trabajos Previos en los MAC:

Antes de poder trabajar con el repositorio en un proyecto son necesarias las siguientes actuaciones en los equipos MAC:

  1. Instalación de la herramienta GIT. La podemos bajar desde la siguiente URL:http://git-scm.com/download. La herramienta también está disponible en los repositorios internos de información UMOV.
  2. Instalación de XCODE 4. Disponible desde http://developer.apple.com. Son 4GBytes de instalación. El paquete instalable también se encuentra disponible en los repositorios internos de información UMOV.
  3. Acceder mediante SAMBA a la carpeta compartida del servidor ORIGIN. Típicamente, algo del estilo smb://máquna.dominio/Trabajos. Al ser ORIGIN una máquina Windows accedemos por protocolo SAMBA. Podemos acceder de muchas otras formas pero hemos considerados ésta la mas sencilla según nuestras instalaciones de sistemas.

Creación del Proyecto en ORIGIN:

A continuación, se describe como debe crearse el proyecto en ORIGIN desde XCODE 4 con control de versiones GIT. Los pasos a realizar son:

  1. Abrimos XCODE 4 y seleccionamos la opción de New Project.
  2. Cuando nos lo indique le decimos que deseamos crear el proyecto con control de versiones GIT. En ese momento nos dirá que pongamos una ruta. Tendremos que poner la ruta del directorio raíz de ORIGIN en la que queramos tener el código. Típicamente será una ruta del estilo /Volumes/Trabajo/UMov/iPhone
  3. La creación del proyecto XCODE inicializa un repositorio git (ver carpeta oculta .git) con una rama MASTER preparada para trabajar. La preparación la hace con copia extraída del fuente. Esta copia no se tocará directamente por los programadores y no debe confundir nunca. Los programadores utilizarán su código fuente en repositorio local. En nuestro caso no hacemos copias –bare (desnudas) que no incluyen la copia extraída.
  4. Si abrimos Window/Organizer desde XCODE tendremos una vista de repositorios y ahí tendremos el nuevo creado. Desplegamos las opciones de este repositorio nuevo y vemos como en la parte inferior hay icono para crear nuevo branch.
  5. Creamos branch DEVELOP a partir de master (*).
  6. En ORIGIN en el repositorio creado hay que ejecutar el siguiente comando para permitir hacer correctamente los posteriores push. Se puede ver como se añade línea de configuración en .git/config

git config receive.denycurrentbranch ignore

(*) Seguimos mecanismo de trabajo propuesto en http://nvie.com/posts/a-successful-git-branching-model/ donde tenemos el brach MASTER en el que dejamos las versiones definitivas tagueadas con versión y la copia de desarrollo sobre la que se trabaja habitualmente.

Creación del Proyecto en las Máquinas del Programador (CLONE):

Los programadores en sus equipos locales tendrán que hacer lo siguiente:

  1. Ir a la carpeta raíz en la cual se quiere crear el proyecto. Nótese como la siguiente acción creará una nueva carpeta con todo el proyecto clonado. Por lo general, será una ruta del estilo /Users/usuario/GIT-Projects
  2. Ejecutamos el comando:

git clone /Volumes/Trabajo/UMov/iPhone/$proyecto$

donde $Proyecto$ es la carpeta del proyecto que se ha creado con control de versiones en GIT en ORIGIN

Con esto ya tendríamos el directorio clonado. Ahora tendremos que crear la rama Develop y conectarla con la propia en ORIGIN. Para ello, iremos a XCODE a organizer y en la sección Repositories seleccionaremos la opción crear nueva rama.

Ahora para hacer coincidir la ramas master / develop con las propias del servidor tendremos que abrir el fichero -config- dentro del directoroi .git y escribir las siguientes líneas en negrita:

 

[core]

repositoryformatversion = 0

filemode = true

bare = false

logallrefupdates = true

ignorecase = true

[remote “origin”]

fetch = +refs/heads/*:refs/remotes/origin/*

url = /Volumes/Trabajo/UMov/iPhone/ArrabeAsesoresRSS/

[branch “master”]

remote = origin

merge = refs/heads/master

[branch “develop”]

remote = origin

merge  = refs/heads/develop

 

Operativa de Trabajo

Ahora los programadores podrán trabajar con su XCODE 4 y hacer los commit contra su repositorio git. Pero hay dos operaciones que hay que hacer desde línea de comandos para tener actualizado ORIGIN:

  1. git pull -> Que permitirá actualizar la rama seleccionada (git branch) de ORIGIN a local.
  2. git push -> Que permitirá subir al servidor la rama seleccionada (git branch).

Como debe ser los programadores deben trabajar en DEVELOP y dejar MASTER para versiones finales. Por lo tanto, se hace necesario mezclar ramas, el comando es sencillo:

Estando en la rama MASTER si hacemos:

git merge develop

Se fusionarán todos los cambios de develop en la rama MASTER

Otros aspectos importantes

  1. git add .
  2. git commit
  3. git commit -a
  4. git status
  5. git log
  6. gitk: Herramienta gráfica. MUY INTERESANTE.
  7. Crear una rama: git branch develop -> Estando en la rama MASTER crea la rama DEVELOP
  8. git checkout RAMA -> Cambiamos al branch RAMA.
  9. Mezclar ramas: git merge develop -> Estando en MASTER se hace una mezcla con DEVELOP
  10. Volver atrás en un merge: git reset –hard HEAD
  11. Tagueado de ramas:git tag -a 1.0.7 -> Etiqueta la rama con la versión 1.0.7
  12. Borrado de ramas: git branch -d RAMA
  13. git log –oneline –decorate –graph

 

IMPORTANTE:

Podemos lanzar un proyecto XCODE con las herramientas nomarles de git: git init / git add . / git commit / git branch develop / git config receive.denycurrentbranch ignore en ORIGIN y luego hacer la copia en local con git clone.

En XCODE tendremos que añadir este repositorio manualmente desde Window / Organizer / Repositories / + (abajo del todo a la izquierda) / Add Working Copy

Con esto al abrir con XCODE el proyecto detecta la copia con GIT y es capaz de mostrarte los ficheros modificados.

TAGUEADO DE VERSIÓN

Los pasos a seguir para hacer un tag son los siguientes:

  1. Nos vamos a master en ORIGIN
  2. Ejecutamos una sentencia del estilo: git tag -a 1.0.7 donde 1.0.7 es el identificativo de versión.
  3. Ahora desde los repositorios locales hacemos un git pull y con esto arrastraremos el etiquetado de nuestra versión a la rama local.

 

XCODE 4 – Información de Archivos en Control Versiones

Cuando estamos trabajando con XCODE y control de versiones (también para SVN) nos aparecen estos gráficos identificativos al lado de los archivos:

XCODE 4 - git

Ignorar archivos con git

Desde git tenemos dos formas de que se ignoren archivos y/o carpetas siempre basado en patrones del estilo *nombreFichero

Estos patrones los podemos poner en:

$GIT_DIR/info/exclude

o

.gitignore (en la carpeta donde estén los archivos).

Si lo que se desea es excluir archivos que ya están en el repo deberemos ejecutar un comando del estilo:

git rm –cached fichero