viernes, 11 de noviembre de 2016

Fiori para programadores con muy poco tiempo I

Aprendiendo Fiori

En internet hay una ENORME cantidad de recursos para aprender Fiori. Voy a intentar resumir en una serie de entradas en este blog los conceptos más importantes, de manera concisa y práctica.

Es difícil encontrar una definición concreta de que es exactamente SAP Fiori. Si buscamos por internet encontraremos gran cantidad de documentación que puede llegar a confundirnos un poco. Pero toda esa documentación podemos resumirla en lo siguiente:
  • SAP Fiori es el nuevo concepto de SAP para su interfaz de usuario:
    • Es un cambio importante en el que se modifican muchos términos. El más llamativo es el concepto de "Interfaz de Usuario" (En inglés "Graphic User Interface" o GUI) que ahora pasa a llamarse "Experiencia de Usuario" (En inglés "User eXperience" o UX). Por eso nos encontramos por todas partes la expresión "SAP Fiori UX"
  • SAP Fiori UX se compone de:
  • Aplicaciones con tecnología Fiori:
    • Aunque todo el mundo habla de "Programar en Fiori", este concepto es incorrecto. Las aplicaciones con tecnología fiori se desarrollan usando tres tecnologías:
      • HTML5 + CSS para la interfaz de usuario
      • Java Script para la lógica de la aplicación
      • jQuery para las interfaces de datos
      • A estas tres tecnologías, usadas conjuntamente, SAP las denomina SAPUI5
      • SAP ha creado una librería hecha en y para HTML5 (y CSS y javascript) con componentes (botones, etiquetas, layouts, etc.) que podemos usar en nuestras aplicaciones. Esa librería se conoce como SAPUI5. (Muchas gracias al gurú de Fiori que me ha comentado este pequeño error)

Primeros Pasos

SAP nos brinda una oportunidad excelente para aprender tecnología Fiori SAP HANA Cloud Platform, developer edition.

Comenzaré creándome un portal Fiori:





Una vez creado el portal, usando las herramientas de contenido, podríamos crear catálogos, grupos y roles adicionales (ya hablaré en otras entradas más adelante que son esas cosas) pero por ahora simplemente usaremos los de ejemplo que aparecen ya creados por defecto (Sample Catalog, Sample Group y los roles Anonymous y Everyone).

Para que el portal esté disponible tenemos que publicarlo:




Primera aplicación fiori

Desde el SAP Web IDE voy a crear mi primera aplicación FIORI:




En otras entregas entraré más en detalle de que ficheros se han creado, para nuestros primeros pasos me limitare a modificar un texto en un fichero que personalizará el texto que muestra la aplicación:


Guardamos y procedemos a desplegar la aplicación en HCP



Una vez desplegada, tenemos la posibilidad de registrarla en el portal FIORI creado previamente:




Podemos modificar su título, el icono y otras propiedades



Y por fin, seleccionamos el portal, catálogo y grupo en el que queremos publicar nuestra aplicación:


Puede ser un buen momento para guardar el código fuente en su propio repositorio Git.

Ejecutando nuestra primera aplicación

Vamos a nuestro portal:



Y pulsando es nuestra aplicación la ejecutamos:


Y para ser nuestra primera aplicación Fiori, yo creo que ya hemos hecho bastante.

viernes, 4 de noviembre de 2016

Repositorio Git remoto

Aplicaciones HTML5 y repositorios Git en HCP

En HCP tenemos un repositorio Git centralizado donde mantener una gestión de nuestras aplicaciones HTML5:

Tenemos tres opciones para crear un nuevo repositorio:
  • Crear uno directamente con el botón "New Repository"
  • Crear una aplicación HTML5 desde la sección "Applications"
  • Crear una aplicación HTML5 desde el WebIDE y luego hacer un deploy de la misma a HCP.
Veamos esta última opción:


  • Desde WebIDE creo una aplicación (MUY IMPORTANTE: No podemos inicializar el repositorio Git hasta después de hacer el deploy a HCP. De otra manera será prácticamente imposible conseguir vincular el repositorio Git local y el remoto) y en el momento que quiera, simplemente hago un deploy:



  • Si ahora acudimos a los repositorios HCP:

Los repositorios HCP tienen un URL que es el que nos permitirá poder usarlos en un entorno remoto para que diversos equipos puedan participar del desarrollo de la aplicación (Que es el propósito de los repositorios Git)


Si vamos a la URL del browser del repositorio veremos que hemos hecho el deploy de nuestra aplicación, y por lo tanto la aplicación como tal estará en HCP, pero no así sus fuentes. Es el momento de hacer un push de las fuentes al repositorio remoto. Para ello inicializamos el repositorio Git y lo vinculamos con el repositorio remoto:


Para que se cree el enlace entre la aplicación que está en HCP y sus fuentes, tenemos que hacer un fetch:


Realmente no traemos nada, porque el repositorio estaba completamente vacío. Pero esta acción crea el vinculo entre el repositorio remoto y el local. Para Git, aunque no hayamos traído nada, existen en nuestro espacio de trabajo cambios del repositorio remoto y cambios del local. Antes de poder mandar cosas al remoto tenemos que hacer un "merge":




Ahora simplemente metemos todos los ficheros en el stage y hacemos un "commit and push" lo que llevará los fuentes al repositorio:


Puede que tengamos algún error de que falten ficheros obligatorios o algo de la configuración, pero si queremos seguir adelante bastará con seleccionar el botón "Push" y después seleccionar sobre que rama queremos hacer el push.

Una vez finalizado el Push podremos ver en el repositorio remoto nuestras fuentes.

Clonando un repositorio externo

Supongamos que tenemos que trabajar en una aplicación que ya ha creado otro y ha guardado en su correspondiente repositorio Git (o bien hemos optado por las otras dos opciones posibles para crear un repositorio remoto). Lo primero que tenemos que hacer en nuestro entorno de desarrollo es clonar el repositorio Git remoto:


El usuario y la contraseña serán necesarios si nos queremos conectar a un repositorio que no sea en de nuestra propia HCP
Cuando clonamos un repositorio, WebIDE nos creara un fichero gitignore con los ficheros del sistema que recomienda ignorar en la gestión de versiones. Automáticamente nos recomienda hacer un commit y push de ese fichero al repositorio remoto. Podemos hacerlo mas tarde si queremos. Si en el repositorio remoto ya existe ese fichero es posible que nos haga esta pregunta.

Cuando clonamos un repositorio remoto tenemos que recordar:
  • Fetch nos traerá los últimos cambios del "head" del repositorio remoto
  • Merge nos mezclara los cambios del repositorio remoto con los nuestros (pueden existir conflictos que haya que arreglar manualmente)
  • Push llevará nuestros cambios al repositorio remoto
A fecha de hoy (31-Octubre-2016) WebIDE y HCP Git Repository no permiten la creación de ramas en el repositorio remoto. Por lo que podremos crear ramificaciones locales en el WebIDE pero todos los push irán a la rama principal del remoto. Aunque supongo que usando unc liente remoto de Git podremos crear ramas adicionales en el repositorio HCP e incluso hacer merge de las mismas (Pero es solo una suposición, no lo he llegado a probar)

Hacer un push no implica que llevemos la aplicación a HCP, si no que solo subiremos las fuentes. Para llevar la última versión a HCP tendremos que hacer un deploy.

Y con esto doy por terminada mi aventura con el repositorio Git (al menos por ahora...)

viernes, 28 de octubre de 2016

Ramificación en Git

Ramificación de un proyecto en Git

Cuando trabajamos en un proyecto en Git, podemos crear varias ramas independientes unas de otras, de manera que, por ejemplo, un equipo podría trabajar en corregir errores existentes mientras que otro equipo se encargaría de añadir nuevas funcionalidades sin tener que compartir los mismos archivos. Cada equipo trabajaría en su propia rama del proyecto. En esta entrada no hablaré de cómo trabajar varios equipos sobre el mismo proyecto, eso lo dej para otro día. Hoy me centraré en el trabajo con ramas.

Creando varias ramas

Comienzo creando un nuevo proyecto y creando un repositorio Git específico para él como ya expliqué en mi primera entrada. Y le añado un par de versiones:


Lo primero que nos encontramos en el repositorio Git, ya sea en el historial o en el panel Git, es la rama en la que estamos trabajando:

Crear una rama es tan simple como pulsar en el signo "+" del panel Git. Cada nueva rama hereda todas las versiones (commits) de la rama que indiquemos como Source:




Ahora puedo modificar un fichero y crear una versión, exclusiva de la rama con la que esté trabajando:


Fusionando ramas.

Normalmente las ramas se crean con el objetivo de terminan fusionando sus cambios con la rama principal:





En este caso era fácil porque los cambios de "Experimental" no tenían conflictos con "Master". ¿Qué ocurriría si "Master" y "Experimental" tuvieran versiones distintas del mismo archivo?


La operación de Merge utilizará la versión más moderna (esto hay que tenerlo en cuenta a la hora de mezclar, porque podríamos terminar perdiendo los cambios de la rama "donante" si la rama "receptora" es más moderna). Pero si las dos ramas son contemporáneas la operación de mezcla dará un error y la única manera de continuar será resolviendolo a mano:


Los signos "<<<<<<"; "=====" y ">>>>>>" forman parte de la sintaxis de Git. Son marcadores para que sepamos donde comienzan y terminan los conflictos y de donde provienen. PAra resolverlos tenemos que borrar lo que no queramos conservar, incluidos todos los indicadores, y dejar en el fichero solo lo que queramos quedarnos. Hasta que no borremos TODOS los marcadores el sistema seguirá marcandonos que existe un conflicto. Una vez resuelto el conflicto solo quedaría hacer un commit a la rama "receptora" para terminar la fusión.

Una rama donante, una vez que se fusiona con la receptora, puede borrarse (no tiene sentido conservarla, sus cambios ya han sido transferidos). Para borrar una rama, simplemente pulsamos en el símbolo "-" del panel Git.

Para terminar de sacarle todo el partido a Git solo falta saber como usarlo para que trabajen sobre el mismo repositorio varios equipos. Pero eso es otra historia que contaré en mi siguiente entrada.

viernes, 21 de octubre de 2016

Gestión de versiones en Git

Stage, Head y Pila de versiones

En Git tenemos versiones de nuestros ficheros en tres sitios distintos. El cómo pasar los ficheros a estos sitios lo vimos en mi anterior entrada:




Stage

El stage no guarda versiones de los ficheros, simplemente indica que ficheros se guardarán en la versión que generemos cuando hagamos Commit. Si modifico un fichero y lo guardo con el botón "Save", aparecerá en la lista del Stage, pero no entrará en el stage hasta que seleccione su casilla:

La versión del espacio de trabajo y la actual son distintas. La versión no será modificada al hacer commit porque no tiene la casilla marcada.
En este punto podemos descartar los cambios del espacio de trabajo simplemente desmarcando la casilla del Stage del fichero correspondiente y pulsando en la flecha "discard":


El resultado dependerá de que estemos viendo en el espacio de trabajo al hacer el discard del stage. Si estábamos en modo comparar ficheros, como en la imagen anterior, el fichero se queda como esté, pero aparecerá marcado como modificado. ¡Es como si no hubiéramos pulsado al botón de guardar después de modificarlo! Si cerramos el fichero sin guardar es como si no lo hubiéramos modificado. Si por el contrario habíamos cerrado la comparación y estábamos viendo el fichero modificado y guardado. El botón Discard dejara el fichero tal cual estaba antes de que lo modificáramos. En ambos casos el resultado final es el mismo. El fichero vuelve a su estado original.

 Head y Pila de versiones

Cada vez que hacemos commit, git crea una nueva versión de los ficheros que estén en el stage. Las versiones se guardan en la pila de versiones. La más reciente es la que esté en la cima de la pila, lo que se conoce como Head.

Cuando modificamos un fichero y hacemos doble click en la lista del stage estamos comparando la versión del espacio de trabajo con la versión guardada en el Head.


Para recuperar una version anterior solo tenemos que seleccionar en la pila la versión que queremos "revertir". CUIDADO la version seleccionada también será descartada y el nuevo Head será justa versión que esté por debajo:

Pila de versiones ANTES de descartar versiones

Las cosas no siempre salen bien y a veces git no es capaz de devolver todo a su versión adecuada, sobre todo si queremos revertir muchas versiones de golpe.



En el espacio de trabajo y en el Stage podemos ver los distintos problemas que se ha encontrado git y si no son mucho podemos tratar de irlos arreglando a base de comparar versiones y de mucha paciencia. O podemos resetear los cambios y volver a intentar revertir versiones de una en una:


Y por ahora lo dejamos aquí. En la siguiente entrega veremos una de las opciones mas interesantes de Git, la "Ramificación de Versiones".


jueves, 13 de octubre de 2016

Primeros pasos con Git

Repositorio Git en Web IDE

HCP proporciona un servicio de desarrollo en la nube, el SAP Web IDE. Permite los paradigmas de desarrollo: HTML5, SAPUI5/SAP Fiori y JavaScript.

Para los que venimos del mundo ABAP, lo primero que nos choca es la falta de una gestión de versiones del código fuente... Hasta que alguien nos habla de Git.

Tenemos dos servicios Git en HCP: uno local al Web IDE (del que hablaré en esta entrada) y otro "global" para la cuenta HCP denominado "Git Service" (del que ya hablaré en otra ocasión)

Iniciar un nuevo proyecto

Desde el Web IDE voy a comenzar un nuevo proyecto HTML5




En este momento tenemos un nuevo proyecto pero no está gestionado por Git. Para tener gestión de versiones necesitamos inicializar el repositorio:


Con esta acción inicializamos el repositorio Git Local. Al inicializar el repositorio local aparece una pantalla adicional que nos da la opción de enlazar nuestro repositorio local con uno remoto donde poder colaborar con otros desarrolladores (por ejemplo GitHub o el Git Service disponible en HCP). Si solo queremos trabajar con el repositorio local podemos pulsar en cancelar sin ningún problema.


Sabemos que nuestro proyecto está en un repositorio Git porque tenemos unos nuevos símbolos al lado de los nombres de los ficheros y carpetas, ha aparecido un nuevo fichero en nuestro proyecto (el .gitignore) y porque al pulsar en el botón del repositorio Git aparece algo en lugar de un workspace vacío:




Añadir ficheros al repositorio

Git solo gestionará los ficheros que estén en el "staging area". Ahora mismo solo es el .gitignore. Para añadir más solo tenemos que seleccionar la casilla que tenemos en la columna Stage. Si queremos añadir todos, pulsaremos en Stage All



Gestionando modificaciones

Probemos a modificar un fichero del proyecto, por ejemplo el i18n.properties. veremos que el repositorio Git cambia en cuanto guardamos los cambios pulsando en Save:



La M significa que el fichero está modificado con respecto al almacenado en el Staging area, y como podemos ver, el nuevo fichero no está en el repositorio. Haciendo doble click en el fichero podemos ver una comparación entre lo que hay en el staging area y en el workspace:


Para guardar los cambios en el staging area simplemente tenemos que volver a seleccionar la casilla correspondiente (y el contenido antiguo del repositorio se sustituirá por el nuevo del Worksapce)

Versiones

Por ahora hemos estado jugando con una especie de versión temporal, pero en el histórico del repositorio no tenemos ninguna versión como tal (simplemente tenemos la versión inicial de la inicialización del repositorio):



Para generar una versión tenemos que hacer un commit desde el repositorio Git:


La "decoración" de los archivos cambiará...


...y en el historial del repositorio tendremos una versión de nuestra aplicación


Y por ahora aquí lo dejamos. En otra entrada hablaré de que cosas podemos hacer con esas "versiones".