Diseño

Pesadilla en la cocina: tratando de subir Emancipia a Azure

22 mayo, 2019 by JGarciaz Leave a Comment

¡Hola! Hace un tiempo os hablé de mi proyecto con Emancipia, y en qué lo iba a desarrollar. Tras empezar a trabajar en ello, me di cuenta de que lo idea para esta aplicación era hacerla con MEAN. Creo que es ideal por las características propias que tiene la app actual, y hacia dónde quieren ir con el proyecto.

Aprovechando que soy Microsoft Student Partner, decidí subir mi primera versión de la app en la nube de Microsoft. Así podría comprobar su correcto funcionamiento.

Primeros intentos con Azure.

No soy experto en subir apps programadas en NodeJS a la nube de Microsoft. Así que decidí seguir uno de los numerosos tutoriales que aparecen en la documentación de Azure. Como ya llevo un tiempo en el mundo de la programación, no me sorprendí en absoluto cuando, al subir mi aplicación, esta no funcionaba. Al fin y al cabo, dependía de un elemento creado por Microsoft que tenía que detectar automáticamente la configuración de mi app. Todo apuntaba a un fracaso, y así fue.

Docker.

Mirando otras guías de Azure, vi que me recomendaban que usara Docker, que iba a ser más fácil. Decían que ni siquiera necesitaba conocer su configuración. Con un fantástico vídeo y Visual Studio Code ¡iba a poder subir mi app! Craso error. Si ya era difícil que el servidor configurase mi app automáticamente, conseguir que funcionase sin tener ni idea era aún peor.

En más de 20 horas de investigación solo había conseguido hacer funcionar un Docker container ya creado por otro usuario. Y también alguna aplicación de ejemplo de Microsoft, que funcionan siguiendo los tutoriales. Esto es algo curioso porque en otras tecnologías hasta los ejemplos suelen fallar.

Kudu.

Tras tantas horas de fracaso, he pensado en subir mi app a otras nubes. Creo que pueden ser más fáciles de trabajar, o tener ejemplos más actualizados y útiles. Además, también estoy mirando el framework Kudu para que me ayude con la configuración. Aunque tenga pinta de estar bastante en beta y no creo que funcione. Ya veremos…

Y ahora, tras desfogarme un poco, seguiré buscando la solución. Si la tenéis y queréis dejármela en los comentarios, os lo agradeceré. Y, si la encuentro, prometo traer un tutorial que funcione de verdad, para que vosotros no tengáis este problema.

Un saludo a todo el mundo ????

Nuestra experiencia en Volvo.

26 febrero, 2019 by Clare Leave a Comment

Los pasados meses de Noviembre, Diciembre y Enero hemos estado trabajando en un proyecto para la Universidad, en relación con Volvo Construction Equipment. JGarcía y yo, junto con otros cuatro compañeros de la carrera, teníamos que crear una aplicación Android para que nuestro cliente, Volvo CE, pudiera controlar sus máquinas autónomas desde el móvil.

Desde el primer día, nuestro contacto en la empresa fue amable y cercano con nosotros. Nos asignaron la empresa un lunes por la tarde. Como en el reparto me tocó ser el contacto con el cliente, le envié un email presentándome y pidiéndole una reunión para comentar el proyecto. Rápidamente me contestó para ofrecernos ir a la empresa al día siguiente, con un tour por ella y comida y todo.

La toma de contacto con Volvo CE.

Fuimos hasta Eskilstuna, la ciudad en la que se encuentra la sede de Volvo CE en Suecia. Fue aproximadamente una hora de viaje en autobús, que está ofrecido gratuitamente por la universidad. Llegamos a la empresa y nos apuntamos como visitantes. Nuestro contacto bajó a recibirnos y luego nos enseñó brevemente dónde trabajaba, y dónde podíamos dejar nuestras cosas. Según el horario sueco, lo primero era comer, ya que eran cerca de las 12.

Después de la comida, en la que pudimos conocernos un poco mejor, procedimos a conocer todas las instalaciones. Fue un tour rápido, pero muy completo, y la verdad es que aprendimos mucho de cómo se trabajaba en la empresa y cómo querían que nosotros nos acoplásemos un poco desde fuera.

Por último, tocaba la reunión que habíamos establecido para apuntar los requerimientos. Nuestro cliente nos había preparado un dossier en el que hablaba de la aplicación que quería y las máquinas autónomas en las que planeaban utilizarla.

Ellos habían pensado en un plan con tres pasos:

Desarrollar un prototipo de la aplicación para ver si la idea era plausible.
Conectar el prototipo con el CoPilot, una tablet que está instalada en la cabina de control de las máquinas.
Conectar la aplicación con las máquinas autónomas y probarla.

Aunque al principio se habló de desarrollar todos los pasos nosotros, pronto nos dimos cuenta de que el tiempo que teníamos no iba a llegar para todo. Decidimos centrarnos únicamente en el primer paso, y dejar al equipo de Volvo CE encargarse de los dos restantes cuando se nos acabara el plazo.

El desarrollo de la aplicación.

Empezamos desarrollando la documentación que teníamos que entregar en la Universidad a la par con la aplicación. Cada documento tenía sus fechas límite, y estaban bastante ajustadas, así que fuimos trabajando rápido para no dejarnos nada en el tintero.

Cada semana teníamos una reunión con los profesores, en la que les enseñábamos las horas que habíamos trabajado desde la última vez que nos vimos y nuestro progreso.

También cada semana teníamos una reunión virtual con el cliente. Utilizamos Skype For Business, y le enseñábamos nuestros progresos gracias a la función de presentar pantalla. De esta forma, podíamos conseguir críticas para mejorar antes de que fuese demasiado tarde.

Diseñamos el Plan del Proyecto, en el que hablábamos de cómo íbamos a organizar el trabajo y las fases que tendríamos, y creábamos unos cuantos diagramas que nos pedían en clase.

Luego comenzamos con el proyecto. Utilizamos Android Studio para crear el código fuente de la aplicación, y GitHub para el control de versiones. Creamos un branch para cada programador, en el que íbamos subiendo nuestros cambios, y un branch en el que íbamos uniendo los cambios de todos.

También utilizamos GitHub como control de tareas, con su herramienta: GitHub Projects. Funciona de manera similar a Trello. Puedes crear distintos proyectos, y tareas dentro de ellos, que se pueden asignar a los programadores y a fechas de entrega.

De esta forma, teníamos más controlado qué tenía que hacer cada programador.

La entrega.

Al final conseguimos hacer una aplicación que reunía la mayoría de las características que nuestro cliente buscaba. Y lo hicimos en el tiempo estipulado por la Universidad, es decir, dos meses.

Concertamos con nuestro contacto en la empresa una reunión para realizar el Test de Aceptación. Teníamos que dejarle probar la aplicación en persona, y que decidiera si aquel producto era lo que él quería.

Fuimos de nuevo a Eskilstuna al Test, al que nuestro contacto había invitado a otros 12 trabajadores de Volvo CE. Sin embargo, por otros compromisos, solo asistieron dos trabajadores más.

Expusimos brevemente nuestro trabajo a los nuevos clientes, y luego arrancamos la aplicación en un par de dispositivos móviles para que la probaran.

Nos dieron algunas críticas de cosas que podrían mejorarse, pero en su mayor parte estaban muy contentos con el trabajo que habíamos realizado.

Esa noche, antes de la presentación en la Universidad, aún pudimos añadir algunas cosas de las que nos habían sugerido.

El vídeo.

En la presentación en la Universidad creamos un vídeo para que pudieran ver cómo funcionaba, que subimos a nuestro canal de YouTube. Aquí podéis verlo.

Y nada más que añadir. Espero que os haya gustado conocer nuestra experiencia.

¡Nos vemos la semana que viene con un nuevo post!

Cómo mejoramos el sistema al diseñar laisladelfaro

23 enero, 2019 by JGarciaz Leave a Comment

En el post de hoy comentaremos por encima cómo llevábamos a cabo el desarrollo del diseño de laisladelfaro anteriormente, y cómo trabajamos para diseñar ahora. Empecemos.

¿Cómo trabajábamos para diseñar antes?

Antes teníamos una copia de La Isla del Faro en nuestros ordenadores. Lo hicimos así para poder trabajar en local y, cuando teníamos tiempo para diseñar, arrancar Visual Studio Code (VSC). Al hacer eso, solamente teníamos que cargar la carpeta raíz de la web y desde ahí empezar a diseñar.

Cuando estábamos satisfechos con los cambios teníamos que subirlos al servidor. Para ello usábamos un plugin de VSC llamado ftp-simple. Este plugin permite, con una rápida configuración, conectarnos al servidor mediante ftp y subir los archivos modificados.

Sin embargo, cuando se subían teníamos que aceptar un mensaje de sobreescritura por cada archivo modificado. Como esto terminaba resultado pesado, e implicaba mucho tiempo que por desgracia no tenemos, decidí que había que tomar cartas en el asunto y cambiar el sistema.

¿Como lo hemos solucionado?

Ya que VSC me gusta mucho y quería seguir usándolo, decidí usar git. Para ello creé un repositorio vacío en el servidor y lo configuré para poder ser compartido y usado por otros ordenadores.

Lo primero que hice fue configurar el ssh para que no me pidiese la contraseña cada vez que quisiera acceder. En cambio, debía requerir una clave pública, para comprobar que quienes accedían éramos nosotros.

ssh-keygen -t rsa -b 4096
ssh-copy-id -i ~/.ssh/nombre user@host

nombre = como hayas nombrado al archivo en el paso anterior, o id_rsa si no has puesto ninguno.

user = usuario de acceso mediante ssh a tu servidor.

host = dirección ip o dominio de tu servidor.

De esta manera podiamos ejecutar los siguientes pasos cómodamente.

El siguiente paso era descargarnos el repositorio mediante ssh.

git clone --bare myproject ssh://user@server:/GitRepository/myproject.git

myproject = cómo quieres nombrar la carpeta del proyecto en tu ordenador.

user = cómo se llama el usuario ssh de tu servidor.

server = dirección IP o dominio del servidor.

/GitRepository/myproject.git = dirección donde esté ubicado el repositorio en el servidor.

Ahora deberemos meter la web que teníamos en local en ese repositorio.

Por último, deberemos configurar el repositorio del servidor accediendo al repositorio, a la carpeta hooks y creando un archivo llamado post-receive. Este archivo nos permitía cambiar los archivos de la carpeta del servidor cuando hacíamos un commit. Así, cuando subíamos un cambio, este se modificará automáticamente en el servidor.

De paso decidí configurarlo para trabajar con GitHub.

¿Qué hemos ganado?

Para empezar, hemos ganado un montón de velocidad en cuanto al desarrollo. Ahora, con un par de clics en VSC o un par de comandos en la terminal puedes ver los cambios en el servidor. Para verlo en VSC usamos las extensiones GitHub Build Status y Visual Studio Team Services.

Además, ya no tenemos que lidiar con el molesto mensaje de sobreeescribir archivos. Ni tampoco tenemos que acordarnos de qué archivos hemos modificado en esa sesión de trabajo, ya que del control de versiones se encarga git. Si hay un cambio que ya no nos gusta, podemos hacer un rollback y listo.

Tampoco necesitamos introducir la contraseña cada vez que queremos entrar mediante ssh. Y en este hilo, hemos ganado en seguridad, porque ahora solo nuestra clave privada puede conectarse con esa clave pública.

Como conclusión, podemos decir que aveces, un poquito más de tiempo configurando, se ahorra mucho más a la larga.

Y vosotros, ¿cómo lleváis a cabo el desarrollo de vuestras web?

RESTful API

15 diciembre, 2017 by JGarciaz Leave a Comment

Se conoce como API (del inglés: “Application Programming Interface”), o Interfaz de programación de Aplicaciones al conjunto de rutinas, funciones y procedimientos (métodos) que permite utilizar recursos de un software por otro, sirviendo como una capa de abstracción o intermediario. – Wikipedia

Fuente: e-learningcenter.com

Podemos decir que, gracias a las API, podemos relacionar distintos tipos de tecnología. Esto se debe a que se comparten datos en un formato genérico que cualquier tecnología podría interpretar.

Consultas y Respuestas.

Si aún no os habéis dado cuenta, las páginas web funcionan esencialmente por Consultas y Respuestas. ¿Esto qué quiere decir? Pongamos un ejemplo.

Si un usuario quiere registrarse en este blog, realizará una petición para que el servidor le entregue la página de registro. Una vez que se la han entregado, el usuario rellenará los datos. Cuando pulse en enviar, el servidor leerá las respuestas.

Para saber cómo se leen los datos en el servidor, o cómo enviarlos, existen una serie de elementos de envío, como POST, GET o PUT.

Utilización de la RESTful API.

A su vez, para comprobar que los datos se han recibido correctamente, o han fallado, o te has comunicado de una forma incorrecta con el servidor, se han creado una serie de errores, como el famoso 404 o error Page Not Found.

Así pues, una RESTful API deberá manejar estas comunicaciones y estos errores, de forma que cuando alguien maneje la API sepa si todo ha ido correctamente, o si los datos se han pasado como debían hacerlo.

Todos estos datos se devuelven al servidor, o se envían a este en forma de Datos Estructurados. Algunos ejemplos pueden ser XML o JSON, del cual ya hemos hablado en el blog.

Ejemplo en una empresa.

Un ejemplo podría ser Emancipia. La aplicación que estoy desarrollando para ellos usa esta tecnología. De esta forma, trabajamos con el servidor para extraer y guardar datos en la base de datos. La programación en lado cliente interpretará esos datos, y se los mostrará a los clientes. Así, estos podrán interactuar con ellos. Además, si el día de mañana necesitamos hacer una aplicación de escritorio, o una app móvil, les resultará relativamente fácil implementarla. Esto se debe a que la extracción e inserción de datos ya estará creada en nuestro servicio RESTful.

Imagen de ejemplo de una API de Twitter. — Imagen de TweetDeck App, que usa la API de Twitter. Fuente: idownloadblog.com

Obviamente, no somos los primeros que implementamos una API en su empresa para poder trabajar mejor con sus aplicaciones. De hecho, hay empresas muy conocidas que no solo tienen una API para trabajo interno, sino que encima tienen funcionalidades abiertas para que desarrolladores ajenos a la compañía también puedan usar sus datos y enviar nuevos. Algunos ejemplos de estos casos son Facebook, Twitter, Google, Spotify, Amazon y Steam.

Si una empresa tiene este servicio disponible, lo normal es que sea fácilmente localizable. Con tan solo buscar el nombre de la empresa seguido de API debería aparecer.

Si estás empezando a programar y crees que esto debe de ser para programadores de nivel avanzado estás muy equivocado. Las APIs suelen venir perfectamente documentadas, lo cual es muy cómodo. Al final, extraer los datos que quieres de ellas es tan fácil como leer un archivo de tipo JSON o XML.

La importancia de las URL en el SEO

13 diciembre, 2017 by JGarciaz Leave a Comment

Hoy en día todo el mundo habla de posicionarse en Google. Hay un montón de estudios de buena praxis, e incluso Google tiene su propia guía para principiantes de Google, que te inicia en el SEO. Te recomiendo que le eches un ojo, porque quién va a explicarte mejor qué debes hacer para indexarte en Google que ellos mismos. Las URL, aunque parezca mentira, también juegan un factor importantisimo a la hora de indexarte en Google. Por ello, mi recomendación personal es que programéis vuestra web con URL amigables o ‘pretty URL‘.

URL amigables para el SEO.

Ejemplo de URL amigable. — Ejemplo de URL amigable: laisladelfaro.com/about-jgarcia/

Las URL amigables, a diferencia de las convencionales, son URL que son perfectamente entendibles por un usuario de la página. Es decir, este sabe lo que está pasando al entrar en esa dirección. Por ejemplo, una URL amigable puede ser medida.com/volumen/metro-cubico. Esta URL, que me acabo de inventar sobre la marcha para medida.com, ayudará al usuario a identificar que dentro de medida se encuentra en el apartado de medidas de volumen, dando a intuir que puede haber otros apartados como el apartado distancia, y a su vez está informándose sobre metro cúbico.

Como podrás ver he puesto metro-cubico sin acentos y con un guion en medio separando las palabras. Esto es así porque con un – en medio en la mayoría de casos en informática y en concreto en Google se identifica que son dos palabras distintas. En cambio, si pones guion bajo u otras alternativas que se te puedan ocurrir, le dificultarás el trabajo a Google.

Por otro lado, muchos ya sabréis también que las tildes no son muy amigas de la informática y que muchas veces no se interpretan como deben. Por esto, es importante evitarlas.

Como verás, esa URL se interpreta mucho mejor que una URL convencional (como podría ser medida.com?p=12), donde no sabríamos que está pasando.

Agrupaciones.

Gracias a las agrupaciones, como en el caso de la pretty URL con /volumen/, Google va entender que eso puede ser una categoría. Esto hará que, posiblemente, al cabo del tiempo tu página se muestre en Google con enlaces a las categorías. Esto hará que tu página ocupe más en los resultados de Google y, por lo tanto, llame más la atención.

Por si tienes dudas a la hora de planificar tus URL, Google da más importancia a lo que aparece más a la izquierda. Así, por ejemplo, en medida.com daría más importancia a medida.com. Luego, con algo menos de importancia, estaría volumen y, por último, metro-cubico.

Por lo tanto, en un principio será más fácil que nos encuentren si buscan medida o buscan volumen que si buscan metro-cubico.

A mí el tema de SEO me llama mucho la atención y espero que a vosotros os enganche también. Sobre todo porque así os podré crear más guías sobre el tema.

Así que nada más que decir. Espero vuestro feedback y hasta la próxima ????

Proyecto Emancipia (Parte 2).

5 noviembre, 2017 by JGarciaz Leave a Comment

Bienvenidos de nuevo. Hoy continuaremos con la segunda parte del Proyecto Emancipia. En este apartado vamos a hablar de las herramientas que usaré para el desarrollo de la nueva app.

Netbeans.

La primera herramienta que os traigo es Netbeans. En esta herramienta desarrollaremos el código de Symfony y Angular. Si queréis instalarla para seguir lo que voy a contar, os dejo por aquí una guía de cómo hacerlo, por si necesitáis la ayuda.

Github.

La segunda herramienta es Github. Esta herramienta tan famosa entre los desarrolladores nos servirá para el control de versiones. Además, me vendrá bien por si en algún momento la lío, poder hacer un roll back. Para los que no lo sepáis, un roll back implica volver a antes de la operación que estaba realizando.

Brackets.

La siguiente que instalaré será Brackets. Me gusta mucho utilizarla para el diseño de la página. Principalmente, porque tiene muchos complementos interesantes que podrán ayudarme.

Cygwin.

Esta herramienta no es realmente necesaria. Sin embargo, creo que me facilitará la instalación posterior de herramientas útiles como Composer.

Azure.

También necesitaremos una cuenta con saldo en Azure, para poder configurar nuestro Web Service. Para quien no lo sepa, el Web Service es el lugar donde iremos subiendo los cambios útiles de nuestro proyecto.

Xampp.

Esta herramienta es útil para trabajar en local antes de subir los cambios a la web. Aunque pueda sonar banal, si una vez que hemos cambiado la web necesita alguna actualización, esta herramienta será cómoda para probar los cambios que queramos hacer sin tocar lo que ya está subido.

Apuntes, guías y tutoriales.

Por último, pero no menos importante, necesitaremos apuntes, guías y tutoriales, escogiendo los que más nos gusten. En mi caso, por ejemplo, para Symfony usaré la guía de Symfony; StackOverflow para preguntas y dudas, y los tutoriales de Victor Robles.