Archivos

Visitamos GDG La Rioja

En Internet no existen provincias; todo está en la capital. Y buena muestra de ello pudimos comprobarlo por nosotros mismos durante la visita que realicé la semana pasada a La Rioja.

Con motivo de la presentación del GDG La Rioja en la universidad, tuve la oportunidad de conectar con la comunidad universitaria, desarrolladores locales y un puñado de excelentes startups que juegan en primera división.

La Rioja, una preciosa región del norte de España, además de por sus vinos, productos naturales y su calzado, empieza a ser conocida por algunas de sus empresas tecnológicas que sin renunciar a mercados globales, disfrutan de una de las mayores calidades de vida.

La visita arrancó con una reunión en la sede de la FER, Federación de Empresarios de la Rioja. Allí pude conocer las interesantes experiencias de 89Bits, CreativiTIC,  FunApps, JIG o Quantitas. Si bien no están todos los que son, son todos ellos excelentes representaciones de un tejido tecnológico en pleno desarrollo.

Tras esto llegó la presentación del Programa de Desarrollares de Google para España, los Grupos de Desarrolladores de Google Españoles, con especial mención al GDG La Rioja y un ejemplo práctico de difusión de tecnologías Go y AppEngine. El objeto de la charla fue destacar el papel que juegan los grupos de desarrolladores en la capacitación y formación continua de todos los desarrolladores, haciendo especial hincapié en como complementan a la formación universitaria.

A la luz de una sala abarrotada, parece que el tema fue de interés para todos los asistentes, que incluso compartieron su particular visión del logo de AppEngine. Tras la charla, conocimos a los representantes del colegio de Informática de la Rioja.

Finalmente, el día finalizó con un meetup con algunos desarrolladores en la zona conocida popularmente como el Laurel. Allí pude conocer a Juan Jose Bilbao, y su interesante proyecto de accesibilidad colaborativa EsAccesibleApp, que permite valorar la accesibilidad física de locales de ocio, imprescindible para la integración de personas con dificultades motrices o en silla de ruedas.

Durante el segundo día de mi visita, tuve la oportunidad de visitar el vivero de empresas del centro de tecnológico de la Rioja, también conocido como La Fombera, charlando con algunas de las empresas alojadas en el vivero que actualmente desarrollan tecnologías de gaming, realidad aumentada o motores de inferencia de aplicaciones diversas.

Finalmente, como colofón de este par de días, visité una interesante experiencia de formación profesional de tercer ciclo llevada a cabo por el Centro Educativo Los Boscos que en colaboración con la Federación de Empresarios de la Rioja forma profesionales TIC en una experiencia piloto en la región. En definitiva, dos días conociendo experiencias de innovación de enorme interés.



Felicidades a todos por su excelente trabajo y espero visitarles pronto de nuevo. Esto no hubiese sido posible, sin la ayuda de Eloy Mata, de La Universidad de la Rioja y el único, el inimitable, el fabuloso Mario Esquerro, que continua haciendo una labor exceptional en la región.

Gracias!

Andrés a.k.a almo i.e. @davilgrau es responsable en Google de relaciones con desarrolladores en España. Entre sus intereses se encuentran favorecer comunidades de desarrolladores de habla hispana, liderando programas estratégicos, contenidos de alta calidad para profesionales técnicos y favoreciendo un ecosistema alrededor de tecnologías software que incluya educación, empresas de base tecnológica e innovación social. Es además miembro asociaciones internacionales como IEEE, Computer Society y ACM.

PHP App Engine Apps y Conceptos File System


Si eres nuevo en App Engine, entonces el modelo de sistema de archivos puede ser un poco diferente de lo que has experimentado usando otras plataformas.
 

Con una aplicación App Engine, no puedes escribir al sistema de archivos donde tu aplicación es desplegada. Tu aplicación puede leer cualquier archivo desde la estructura del directorio desplegado, pero no puede escribir en ese sistema de archivo. En su lugar, la aplicación puede usar Google Cloud Storage (GCS) tanto para leer como para escribir archivos. Para convertir una aplicación y que pueda usar GCS para archivos escribibles tienes que seguir los siguientes pasos:

Otra de las consecuencias del modelo solo lectura para archivos de sistema es que si tu aplicación tiene un modelo de conexión ( ‘plugin’) como WordPress, no puedes instalar o actualizar plugins desde tu aplicación desplegada. En su lugar, necesitarás instalar o actualizar cualquier plugin localmente, y después volver a desplegar la aplicación.
Puedes encontrar mucha más información (en inglés) acerca de todo lo siguiente en la documentación del ambiente de ejecución de PHP.

El sistema de archivos de la aplicación
Con las aplicaciones de App Engine, el sistema de archivos “local” - el árbol directorio del proyecto, que es cargado junto a la aplicación desplegada- es de sólo lectura. Esta restricción se da por motivos de escalabilidad y seguridad; a veces, este tema es denominado como ‘sandboxing’. (muchos de los puntos débiles o vulnerabilidades comunes del framework están bloqueados por aplicaciones App Engine).
Puedes leer cualquier archivo en la estructura del directorio de despliegue, por ejemplo, tu aplicación puede leer plantillas implementadas o archivos de configuración. (Si en el código de tu aplicación quieres leer archivos que también suministras de forma estática puedes usar la directiva application_readable en el archivo de aplicación app.yaml).
Es importante señalar que  tu aplicación no puede crear o modificar archivos en este sistema local de archivos - por ejemplo, no puede escribir archivos caché ahí.
Debido a este sandboxing, si tu aplicación tiene un modelo de conexión ‘plugin’, como WordPress, no puedes instalar o actualizar plugins desde tu aplicación implementada. En su lugar, necesitarás instalar o actualizarlos localmente, en tu entorno de desarrollo, poniendo en marcha tu aplicación usando el  servidor de desarrollo de App Engine. Puedes hacer un test de la actualización localmente y, si quieres, volver a desplegar la aplicación con las actualizaciones. Si te sientes cómodo, puedes simplemente descargar y descomprimir los archivos del plugin directamente, moverlos al directorio adecuado y entonces volver a desplegar la aplicación; mejor que instalarlos a través de la consola de administración de WordPress  
Nota si estás haciendo algunos cambios en las bases de datos almacenados desde el servidor de desarrollo, como estableciendo opciones de plugin, estos por supuesto no se van a propagar a la aplicación implementada/desplegada, que está usando una base de datos diferente. Una vez que vuelvas a implementar tu aplicación con los nuevos archivos de plugin, puedes configurar el plugin en la aplicación implementada.
Google Cloud Storage
Para un archivo de sistema lectura/escritura, tu aplicación puede usar los recipientes de Google Cloud Storage (GCS). Google Cloud Storage es un servicio RESTful de almacenaje y acceso a objetos de datos en la infraestructura de Google. GCS es rápido, escalable y altamente disponible, con muchas capas de redundancia; y los objetos pueden ser almacenados en terabytes.
Para el tiempo de ejecución App Engine PHP existe un encapsulador de transmisión que soporta la mayoría de las funciones relacionadas con archivos de sistema estándar. Este encapsulador de transmisión te permite usar tus archivos PHP y directorios de funciones como file_put_contents, file_get_contents, fopen, y opendir. La información de archivo y directorio puede ser recuperado para los objetos GCS usando funciones como file_exists, is_writable, filesize, is_dir, etc.
Apuntas a un directorio GCS o archivo usando sintaxis como esta:
gs:///path/to/file
Para que puedas escribir código en tu app como este:
$fp = fopen("gs://my_bucket/some_file.txt", "w");
fwrite($fp, "Hello");
fclose($fp);
o este otro:
$options = [ "gs" => [ "Content-Type" => "text/plain" ]];
$ctx = stream_context_create($options);
file_put_contents("gs://my_bucket/hello.txt", "Hello", 0, $ctx);
 
En este  link encontrarás más detalles y otros ejemplos (en inglés).
Antes de que un código de este tipo funcione en tu aplicación, necesitarás configurar GCS en un proyecto Google Cloud y autorizar tu aplicación de App Engine para este proyecto tal y como se describe aquí (en inglés).

En la mayoría de los casos, una vez has redefinido tus rutas a gs:// URIs, tus llamadas de sistema de archivos trabajarán como lo hacían antes. Debes revisar las opciones de configuración para tu aplicación antes de implementarla. Por ejemplo, puede que necesites direccionar directorios de cache a GCS.
Sin embargo, GCS no es el típico archivo de sistema ya que soporta el anexo de archivos (objeto). En lugar de anexar a un archivo, debes escribir una nueva versión de este archivo que incluya el contenido actualizado.
Un contexto en el que esto puede surgir es en el de registro (logging), y una buena alternativa es simplemente usar syslog. Todas las llamadas a syslog de tus aplicaciones, y la transmisión del error estándar, serán incluido en los logs de la consola de Admin de tu aplicación, donde puedes buscarlos. También puedes usar  Logs API para acceder a los logs de forma programada. Puedes también descargar los logs usando el comando appcfg.py request_logs.


‘Incluyendo’ archivos de GCS
Puedes incluir o requerir archivos de GCS en tu aplicación.  Esto, por ejemplo, te permite escribir/leer plantillas que están almacenadas en caché o plantillas recopiladas. Por motivos de seguridad,  necesitas habilitar expresamente este componente. Esto se puede hacer especificando qué recipientes contienen archivos inclusivos, usando la directiva google_app_engine.allow_include_gs_buckets en tu archivo php.ini:
google_app_engine.allow_include_gs_buckets = "bucket_1, bucket_2"
Puedes usar este componente para usar modelización de librerías como Twig o Smarty con tu aplicación de PHP App Engine app.
Cargando archivos a GCS desde tu aplicación
Tu aplicación no puede usar el sistema de archivos solo lectura para almacenar archivos subidos. En su lugar, puede usar GCS para almacenar archivos cargados (y GCS es magnífico para manejar archivos de gran tamaño, incluso muchos archivos de ellos). App Engine hace este proceso muy directo.
Para subir archivos desde tu aplicación, generas un  URL especial de carga de archivos, especificando un operario resultante como “callback”, y usas esta URL especial en la forma de carga. Una vez el archivo está cargado, el operario “callback” recibe una petición de POST, desde la que la carga puede ser procesada. Más información aquí ( en inglés).
Si estás poniendo en marcha WordPress on App Engine, hemos construido un plugin que, entre otros componentes, soporta la carga y acceso a media desde GCS, así que todo lo que necesitas es instalar el plugin.
Similar, para otras aplicaciones, probablemente necesites modificar los formularios de carga de manera que usen esta URL de carga generada, que entonces llamarán de vuelta al operativo existente, que puede procesar el archivo temporal de la misma forma que lo hacían antes.
Una vez que tu aplicación está escribiendo archivos de manera exitosa en GCS, hay una serie de formas para que tu aplicación pueda acceder a ellas y ponerla en servicio, esto además de usar GCS como un encapsulador de transmisión.
En resumen
Con aplicaciones App Engine, tu aplicación puede leer desde la estructura de directorio implementada, pero no puede escribir sobre ella. En su lugar, puede usar GCS para hacer eso. Hay tres cosas importantes que probablemente tengas que hacer, para poder convertir una aplicación y que use GCS:
Finalmente, el ‘sandboxing’ del sistema de archivos de la app dicta que no puedes modificar este sistema de archivos desde tu aplicación implementada. Así que, para plugings de WordPress y similares, necesitarás instalar/actualizar plugins localmente usando el servidor de desarrollo y volviendo a implementar la aplicación.
 
Post original creado por Amy Unruh, Developer Programs Engineer