Publicado por Roy Glasberg, director mundial, Programa Launchpad y Launchpad Accelerator
Launchpad Accelerator nos da la oportunidad de trabajar con programadores excelentes que están superando desafíos importantes en todo el mundo y de brindarles capacitación, ya sea mediante la modernización del ...
 Publicado por Roy Glasberg, director mundial, Programa Launchpad y Launchpad Accelerator
Launchpad Accelerator nos da la oportunidad de trabajar con programadores excelentes que están superando desafíos importantes en todo el mundo y de brindarles capacitación, ya sea mediante la modernización del comercio digital en todo África, la provisión de acceso a herramientas multimedia que respaldan la educación para personas con necesidades especiales o el uso de IA para simplificar operaciones comerciales.

Por eso, redoblaremos esfuerzos y abriremos las inscripciones para la próxima clase del programa a más países por primera vez, a partir de hoy. Esta es la lista completa de los nuevos países añadidos:
  • África: Argelia, Egipto, Gana, Marruecos, Tanzania, Tunes y Uganda
  • Asia: Bangladesh, Myanmar, Paquistán y Sri Lanka
  • Europa: Estonia, Rumania, Ucrania, Belarús y Rusia
  • Latinoamérica: Costo Rica, Panamá, Perú y Uruguay

Estos países se suman a la lista más amplia de países que ya forman parte del programa, entre los que se incluyen: Argentina, Brasil, Chile, Colombia, República Checa, Hungría, la India, Indonesia, Kenia, Malasia, México, Nigeria, Filipinas, Polonia, Sudáfrica, Tailandia y Vietnam.

El proceso de inscripción para el programa gratuito finalizará el 2 de octubre de 2017 a las 9 a. m. PST. Más adelante, durante el año, se invitará a los programadores seleccionados de la lista al espacio de Google Developers Launchpad en San Francisco para que disfruten de 2 semanas de capacitación con todos los gastos pagos.

¿Cuáles son los beneficios?


La capacitación en la sede central de Google incluye instrucción intensiva que otorgarán más de 20 equipos de Google, instructores expertos de las empresas de tecnología más importantes y miembros de la industria de capital de riesgo de Silicon Valley. Los participantes recibirán instrucción sin cargo, créditos para productos Google y asistencia de relaciones públicas, y continuarán trabajando en colaboración estrecha con Google cuando regresen a sus países durante el programa de 6 meses. Conoce las experiencias de otros estudiantes aquí.

¿Qué buscamos cuando seleccionamos startups?


Cada startup que se inscribe al Launchpad Accelerator se considera de forma holística y con sumo cuidado. A continuación, se muestran las reglas generales de nuestro proceso, para que comprendas lo que esperamos de los candidatos.

Todas las startups del programa deben cumplir con los siguientes requisitos:
  • Deben ser startups tecnológicas.
  • Deben apuntar a sus mercados locales.
  • Deben tener una adaptación del producto al mercado comprobada (más allá de la etapa de ideación).
  • Deben tener sus sedes en los países antes mencionados.

Además, estamos interesados en saber la clasificación de las startups en cuestión. También consideramos lo siguiente:
  • El problema que se intenta resolver. ¿De qué forma se crea valor para los usuarios? ¿Cómo se enfrenta un desafío real para la ciudad, el país o la región de origen?
  • ¿Tiene el equipo de gestión una actitud de liderazgo y el impulso necesario para convertirse en una influencia?
  • ¿Se compartirá lo aprendido en Silicon Valley para beneficio de otras startups en el entorno local?
  • Si tu país no figura en la lista, no te pierdas las actualizaciones. Esperamos continuar sumando países al programa en el futuro.

Queremos conocer tu opinión y evaluar la manera en que podemos trabajar juntos para mejorar tu empresa.
Participantes de la Clase 4

Por Lorne Kligerman, Gerente de producto

Una función de seguridad clave para programadores y administradores de aplicaciones es la posibilidad de permitir o rechazar solicitudes entrantes en función de las direcciones IP de origen. Esta capacidad puede ayudarte a realizar pruebas de producción sin exponer tu app al mundo, bloquear el acceso a tu app desde ubicaciones específicas o bloquear solicitudes de un usuario malintencionado.
 Por Lorne Kligerman, Gerente de producto

Una función de seguridad clave para programadores y administradores de aplicaciones es la posibilidad de permitir o rechazar solicitudes entrantes en función de las direcciones IP de origen. Esta capacidad puede ayudarte a realizar pruebas de producción sin exponer tu app al mundo, bloquear el acceso a tu app desde ubicaciones específicas o bloquear solicitudes de un usuario malintencionado.

Hoy, nos entusiasma anunciar la versión beta del firewall de Google App Engine. Con el firewall de App Engine, solo debes proporcionar un conjunto de reglas, ordenarlas por prioridad y especificar una dirección IP, o un conjunto de direcciones IP, para bloquear o permitir, y nosotros nos ocupamos del resto.

Cuando el firewall de App Engine recibe una solicitud que configuraste para que se rechace, muestra una respuesta HTTP 403 Forbidden sin siquiera alcanzar tu app. Si tu app está inactiva, se evitará la ejecución de nuevas instancias, y si recibes mucho tráfico, la solicitud rechazada no agregará carga ni te costará dinero.

El firewall de App Engine reemplaza la necesidad de una solución basada en código dentro de tu app que permite el ingreso de solicitudes, pero que puede costarte recursos y exponer tu app.


Primeros pasos con el firewall de App Engine 


Puedes configurar las reglas del firewall de App Engine en Google Cloud Console, en la App Engine Admin API o en la herramienta de línea de comandos de gcloud.

Imaginemos que deseas probar tu aplicación y permitir el acceso únicamente a navegadores de la red privada de tu empresa. Abre tus reglas de firewall en Cloud Console. Verás una regla predeterminada que habilita todo el tráfico hacia tu app.

Primero, agrega una regla nueva que permita tráfico solo del rango de direcciones IP que provengan de tu red privada. Luego, actualiza la regla predeterminada para rechazar todo el tráfico.


Como en el caso de la semántica típica del firewall, el firewall de App Engine evalúa primero las reglas con un valor de prioridad más bajo y luego las reglas con valores más altos. En el ejemplo anterior, primero se evalúa la regla de permiso con un valor de prioridad de 100 y luego la regla predeterminada.

Para asegurarte de que tu conjunto de reglas del firewall funcionen de la forma prevista, puedes probar una dirección IP para ver si una solicitud que proviene de esa dirección se permitiría o se rechazaría.

En Cloud Console, haz clic en la pestaña Test IP de la sección Firewall Rules.

La respuesta indica si la solicitud puede continuar y señala la regla específica del firewall que vinculó la dirección IP proporcionada.
Con el firewall de App Engine es fácil configurar el acceso a la red para tu app y concentrarte en lo más importante, tu app, sin preocuparte por el control del acceso en tu código. Consulta la documentación completa aquí.

El firewall de App Engine está disponible en versión beta; por ello, debes evitar usar esta funcionalidad en entornos de producción. Si tienes preguntas o inquietudes, o si algo no funciona como esperabas, puedes realizar una publicación en el foro de Google App Engine, registrar un problema público o comunicarte a través del canal de App Engine en Slack (#app-engine).

Publicado por Takeshi Hagikura, ingeniero de programas para programadores
Desde el anuncio de ConstraintLayout en Google I/O, el año pasado, hemos continuado mejorando la estabilidad del diseño y la compatibilidad del editor de diseño. También agregamos nuevas funciones específicas de ...
 Publicado por Takeshi Hagikura, ingeniero de programas para programadores
Desde el anuncio de ConstraintLayout en Google I/O, el año pasado, hemos continuado mejorando la estabilidad del diseño y la compatibilidad del editor de diseño. También agregamos nuevas funciones específicas de ConstraintLayout que te ayudarán a compilar varios tipos de diseños, como la introducción de cadenas y la configuración del tamaño como proporción. Además de estas funciones, obtendrás un beneficio de rendimiento importante al usar ConstraintLayout. En esta esta publicación, te mostraremos los beneficios que puedes obtener de estas mejoras de rendimiento.

¿Cómo se dibujan las vistas en Android?


Para entender mejor el funcionamiento de ConstraintLayout, demos un paso atrás y observemos la forma en que Android dibuja vistas.

Cuando un usuario invoca una vista de Android, el marco de trabajo del sistema operativo indica a la vista que se dibuje a sí misma. El proceso de dibujo incluye 3 etapas:
  1. Medición
    El sistema realiza un recorrido de arriba a abajo en el árbol de vistas para determinar el tamaño de cada ViewGroup y cada elemento View. Cuando se mide un ViewGroup, también se miden sus elementos secundarios.
  2. Diseño
    Se produce otro recorrido de arriba a abajo, y cada ViewGroup determina las posiciones de sus elementos secundarios usando los tamaños establecidos en la etapa de medición.
  3. Dibujo
    El sistema realiza otro recorrido de arriba a abajo. Para cada objeto del árbol de vistas, se crea un objeto Canvas a fin de enviar una lista de comandos de dibujo a la GPU. En estos comandos se incluyen los tamaños y las posiciones de los objetos ViewGroup y View que el sistema determinó durante las dos etapas anteriores.
Figura 1: Ejemplo de cómo en la etapa de medición se recorre un árbol de vistas.

Para cada etapa del proceso de dibujo se requiere un recorrido de arriba a abajo del árbol de vistas. Por lo tanto, cuantas más vistas incorpores dentro de cada una (o anides) en la jerarquía de vistas, más tiempo y recursos de cómputo deberá emplear el dispositivo para dibujar las vistas. Al mantener una jerarquía plana en tus diseños de apps para Android, podrás crear una interfaz de usuario rápida y receptiva para tu app.


El costo de una jerarquía de diseño tradicional


Teniendo en cuenta esa explicación, creemos una jerarquía de diseño tradicional que utilice los objetos LinearLayout y RelativeLayout.
Figura 2: Ejemplo de diseño.

Supongamos que deseamos compilar un diseño como el de la imagen anterior. Si realizas la compilación con diseños tradicionales, el archivo XML contendrá una jerarquía de elementos similar a la siguiente (para este ejemplo, omitimos los atributos): 
<RelativeLayout>
  <ImageView />
  <ImageView />
  <RelativeLayout>
    <TextView />
    <LinearLayout>
      <TextView />
      <RelativeLayout>
        <EditText />
      </RelativeLayout>
    </LinearLayout>
    <LinearLayout>
      <TextView />
      <RelativeLayout>
        <EditText />
      </RelativeLayout>
    </LinearLayout>
    <TextView />
  </RelativeLayout>
  <LinearLayout >
    <Button />
    <Button />
  </LinearLayout>
</RelativeLayout>

Si bien siempre se pueden realizar mejoras en este tipo de jerarquía de vistas, seguramente deberás crear una jerarquía con algunas vistas anidadas.

Como se mencionó antes, las jerarquías anidadas pueden afectar negativamente el rendimiento. Observemos la forma en que las vistas anidadas afectan el rendimiento de la IU usando la herramienta Systrace de Android Studio. Llamamos, mediante programación, a las etapas de medición y diseño para cada ViewGroup (ConstraintLayout y RelativeLayout) y activamos Systrace mientras se ejecutan las llamadas de medición y diseño. El siguiente comando genera un archivo de información general que contiene eventos claves, como pasadas de medición y diseño de alto consumo de recursos, que ocurren durante un intervalo de 20 segundos: 
python $ANDROID_HOME/platform-tools/systrace/systrace.py --time=20 -o ~/trace.html gfx view res

Para obtener información detallada sobre cómo puedes usar Systrace, consulta la guía Análisis del rendimiento de la IU con Systrace.

Systrace destaca automáticamente los (diversos) problemas de rendimiento de este diseño y te ofrece sugerencias para solucionarlos. Al hacer clic en la pestaña “Alerts”, verás que para dibujar esta jerarquía de vistas se requieren 80 pasadas de alto consumo de recursos por las fases de medición y diseño.

Activar tantas etapas de medición y diseño que consumen muchos recursos no es de ninguna manera la opción ideal. Una actividad de dibujo de tal magnitud podría provocar omisiones de fotogramas que resultarán evidentes para los usuarios. Podemos concluir que el diseño tiene un bajo rendimiento debido a la jerarquía anidada y a la característica de RelativeLayout, que mide cada uno de sus elementos secundarios dos veces.
Figura 3: Observación de las alertas de Systrace para la variante de diseño que utiliza RelativeLayout.

Puedes revisar todo el código que utilizamos para realizar estas mediciones en nuestro repositorio de GitHub.

Beneficios de un objeto ConstraintLayout


Si creas el mismo diseño usando ConstraintLayout, el archivo XML contendrá una jerarquía de elementos similar a la siguiente (nuevamente, se omiten los atributos): 
<android.support.constraint.ConstraintLayout>
  <ImageView />
  <ImageView />
  <TextView />
  <EditText />
  <TextView />
  <TextView />
  <EditText />
  <Button />
  <Button />
  <TextView />
</android.support.constraint.ConstraintLayout>

Como se muestra en este ejemplo, ahora el diseño tiene una jerarquía completamente plana. Esto de sebe a que ConstraintLayout te permite compilar diseños complejos sin tener que anidar elementos View y ViewGroup.

Por ejemplo, observemos TextView y EditText en el medio del diseño:
Al usar una variante RelativeLayout, debes crear un nuevo elemento ViewGroup para alinear EditText verticalmente en TextView: 
<LinearLayout
    android:id="@+id/camera_area"
    android:layout_width="match_parent"
    android:layout_height="wrap_content"
    android:orientation="horizontal"
    android:layout_below="@id/title" >

    <TextView
        android:text="@string/camera"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:layout_gravity="center_vertical"
        android:id="@+id/cameraLabel"
        android:labelFor="@+id/cameraType"
        android:layout_marginStart="16dp" />

    <RelativeLayout
        android:layout_width="match_parent"
        android:layout_height="wrap_content">

        <EditText
            android:id="@+id/cameraType"
            android:ems="10"
            android:inputType="textPersonName"
            android:text="@string/camera_value"
            android:layout_width="match_parent"
            android:layout_height="wrap_content"
            android:layout_centerVertical="true"
            android:layout_marginTop="8dp"
            android:layout_marginStart="8dp"
            android:layout_marginEnd="8dp" />
    </RelativeLayout>
</LinearLayout>

En cambio, al usar ConstraintLayout, puedes lograr el mismo efecto simplemente agregando una limitación desde la referencia de TextView hasta la referencia de EditText sin crear otro elemento ViewGroup:
Figura 4: Limitación entre EditText y TextView. 
<TextView
      android:layout_width="wrap_content"
      android:layout_height="wrap_content"
      app:layout_constraintLeft_creator="1"
      app:layout_constraintBaseline_creator="1"
      app:layout_constraintLeft_toLeftOf="@+id/activity_main_done"
      app:layout_constraintBaseline_toBaselineOf="@+id/cameraType" />

Al ejecutar la herramienta Systrace para la versión de nuestro diseño que usa ConstraintLayout, verás muchas menos pasadas de medición y diseño de alto consumo de recursos durante el mismo intervalo de 20 segundos. Esta mejora de rendimiento tiene sentido ahora que deseamos mantener una jerarquía de vistas plana.
Figura 5: Observación de las alertas de Systrace para la variante de diseño que utiliza ConstraintLayout.

En una nota relacionada, compilamos la variante ConstraintLayout de nuestro diseño usando solo el editor de diseño en lugar de editar el archivo XML manualmente. Para lograr el mismo efecto visual usando RelativeLayout, probablemente hubiéramos necesitado editar el archivo XML de forma manual.

Medición de la diferencia de rendimiento


Analizamos el tiempo que demora cada pasada de medición y diseño para dos tipos de diseño, ConstraintLayout y RelativeLayout, usando OnFrameMetricsAvailableListener, que se introdujo en Android 7.0 (nivel de API 24). Esta clase te permite recopilar información fotograma por fotograma sobre la representación de la IU de tu app.

Al llamar al siguiente código, puedes comenzar a grabar acciones de la IU fotograma por fotograma: 
window.addOnFrameMetricsAvailableListener(
        frameMetricsAvailableListener, frameMetricsHandler);

Una vez que hay disponible información sobre el tiempo, la app activa el callback frameMetricsAvailableListener() . Puesto que nos interesa el rendimiento de la medición y el diseño, al obtener la duración real del fotograma llamamos a FrameMetrics.LAYOUT_MEASURE_DURATION. 
Window.OnFrameMetricsAvailableListener {
        _, frameMetrics, _ ->
        val frameMetricsCopy = FrameMetrics(frameMetrics);
        // Layout measure duration in nanoseconds
        val layoutMeasureDurationNs = 
                frameMetricsCopy.getMetric(FrameMetrics.LAYOUT_MEASURE_DURATION);

Para obtener más información sobre los demás tipos de datos de duración que FrameMetrics puede recibir, consulta la referencia de la API FrameMetrics.

Resultados de la medición: ConstraintLayout es más rápido


Nuestra comparación de rendimiento muestra que ConstraintLayout presenta una mejora del 40% en el rendimiento respecto de RelativeLayout:
Figura 6: Medición/diseño (unidad: ms, promedio de 100 fotogramas).

Como se muestra en estos resultados, ConstraintLayout probablemente tenga un mejor rendimiento que los diseños tradicionales. Además, ConstraintLayout ofrece otras funciones que te ayudarán a compilar diseños complejos y de alto rendimiento, como se discutió en la sección beneficios de un objeto ConstraintLayout. Para obtener información detallada, consulta la guía Compilar una IU receptiva con ConstraintLayout. Te recomendamos usar ConstraintLayout en los diseños de tu app. En casi todos los casos en los que antes hubieras necesitado un diseño profundamente anidado, ConstraintLayout será tu opción de diseño de confianza para lograr un rendimiento óptimo y hacer más sencillo el uso.

Apéndice: Entorno de medición


Todas las mediciones anteriores se realizaron en el siguiente entorno.


Dispositivo Nexus 5X
Versión de Android 8.0
Versión de ConstraintLayout 1.0.2


Lo que viene


Consulta la guía para desarrolladores, la documentación de referencia de la API y el artículo sobre Medium para comprender plenamente lo que ConstraintLayout puede ofrecerte. Una vez más, gracias a todos los que compartieron comentarios y problemas durante los meses transcurridos desde el lanzamiento de nuestra versión alfa de ConstraintLayout. Nos complace haber podido lanzar a principios de este año la versión 1.0 de ConstraintLayout lista para producción. Mientras continuamos mejorando ConstraintLayout, no dejes de enviarnos comentarios a través del espacio de seguimiento de problemas de Android.



Ya está disponible Firebase Admin SDK para Go. Es el cuarto lenguaje de programación que se suma a nuestra creciente familia de Admin SDK, que ya incluye compatibilidad con Java, Python y Node.js. Los Firebase Admin SDK permiten a los programadores de aplicaciones acceder mediante programación a servicios de Firebase de entornos seguros. Complementan los SDK de cliente de Firebase, que permiten a los usuarios finales acceder a Firebase desde sus navegadores web y dispositivos móviles. En la versión inicial del Firebase Admin SDK para Go se incluyen algunas funciones de Firebase Authentication: creación de tokens personalizados y verificación de tokens de ID.


Ya está disponible Firebase Admin SDK para Go. Es el cuarto lenguaje de programación que se suma a nuestra creciente familia de Admin SDK, que ya incluye compatibilidad con Java, Python y Node.js. Los Firebase Admin SDK permiten a los programadores de aplicaciones acceder mediante programación a servicios de Firebase de entornos seguros. Complementan los SDK de cliente de Firebase, que permiten a los usuarios finales acceder a Firebase desde sus navegadores web y dispositivos móviles. En la versión inicial del Firebase Admin SDK para Go se incluyen algunas funciones de Firebase Authentication: creación de tokens personalizados y verificación de tokens de ID.

Inicialización del Admin SDK para Go


De forma similar a otros Firebase Admin SDK, el Go Admin SDK se puede inicializar con diferentes credenciales de autenticación y opciones de cliente. En el siguiente fragmento de código, se muestra la manera de inicializar el SDK usando una credencial de cuenta de servicio obtenida en la Firebase console o en la Google Cloud console: 
import (
  "golang.org/x/net/context"

  firebase "firebase.google.com/go"
  "google.golang.org/api/option"
)

opt := option.WithCredentialsFile("path/to/key.json")
app, err := firebase.NewApp(context.Background(), nil, opt)

Si ejecutas tu código mediante infraestructura de Google, como Google App Engine o Google Compute Engine, el SDK puede detectar automáticamente las credenciales predeterminadas de la aplicación en el entorno. En este caso, no necesitas especificar explícitamente ninguna credencial al inicializar el Go Admin SDK: 
import (
  "golang.org/x/net/context"

  firebase "firebase.google.com/go"
)

app, err := firebase.NewApp(context.Background(), nil)

Creación de tokens personalizados y verificación de tokens de ID


La versión inicial de Firebase Admin SDK para Go permite crear tokens personalizados y verificar tokens de ID para Firebase. La creación de tokens personalizados te permite autenticar usuarios usando tu propio mecanismo de autenticación o almacenamiento de usuarios: 
client, err := app.Auth()
if err != nil {
  return err
}

claims := map[string]interface{}{
  "premium": true,
  "package": "gold",
}
token, err := client.CustomToken("some-uid", claims)

El token personalizado que se genera puede enviarse a un dispositivo de cliente, donde se puede usar para iniciar un flujo de autenticación con un SDK de cliente de Firebase. Por otro lado, la verificación con token de ID facilita la identificación segura del usuario cuya sesión se encuentra activa en tu servidor: 
client, err := app.Auth()
if err != nil {
  return err
}

decoded, err := client.VerifyIDToken(idToken)
uid := decoded.UID

Para obtener más información sobre el uso del Firebase Admin SDK para Go, consulta nuestra guía de configuración de Admin SDK.

Lo que viene


Tenemos pensado expandir aún más las capacidades del Go Admin SDK implementando otras API útiles, como la administración de usuarios y Firebase Cloud Messaging. Este SDK también es de código abierto. Por lo tanto, te invitamos a que explores nuestro repositorio de Github y participes en el proceso de desarrollo notificando problemas y enviando solicitudes de incorporación de cambios. A todos los “Golang gophers”, ¡feliz codificación con Firebase!

Por Mary Koes y Deepak Tiwari, gerentes de producto 

Cuando anunciamos la disponibilidad general de Google Stackdriver, nuestro conjunto de supervisión, registro y diagnóstico integrado para aplicaciones que se ejecutan en la nube, observamos un gran entusiasmo en nuestra comunidad de usuarios y también recibimos comentarios reveladores ...
 Por Mary Koes y Deepak Tiwari, gerentes de producto 

Cuando anunciamos la disponibilidad general de Google Stackdriver, nuestro conjunto de supervisión, registro y diagnóstico integrado para aplicaciones que se ejecutan en la nube, observamos un gran entusiasmo en nuestra comunidad de usuarios y también recibimos comentarios reveladores:
  • Análisis: las métricas basadas en registros son geniales, pero desearías poder extraer también etiquetas y valores de los registros. 
  • Exportación: te agrada mucho poder exportar registros fácilmente, pero es difícil administrarlos entre cientos de proyectos. 
  • Controles: agregar todos los registros en una sola ubicación y exportarlos a varios destinos es genial, pero deseas poder determinar los registros que van a Stackdriver Logging. 
  • Precio: deseas aumentar el espacio con Stackdriver sin preocuparte demasiado por el costo de registrar todos esos datos. 
Te escuchamos; por eso hoy anunciamos varias actualizaciones para Stackdriver y nuevos precios, a fin de ofrecerte la flexibilidad que necesitas para expandirte y crecer.

A continuación, te informamos más sobre lo que viene.

Análisis simplificado con métricas basadas en registros 

Stackdriver se creó con el concepto de que al unir varias señales de registros, métricas, seguimientos y errores se puede proporcionar una mejor estadística que con cualquier señal individual. Las métricas basadas en registros son un ejemplo excelente. Por eso las métricas nuevas y mejoradas basadas en registros son:
  • Más rápidas: redujimos el tiempo que transcurre desde que una entrada de registro ingresa hasta que se refleja en una métrica basada en registros de cinco minutos a menos de uno. 
  • Más fáciles de administrar: ahora puedes extraer etiquetas definidas por los usuarios del texto de los registros. En lugar de crear una nueva métrica basada en registros para cada valor posible, puedes usar un campo en la entrada de registro como una etiqueta. 
  • Más potentes: puedes extraer valores de los registros y convertirlos en métricas de distribución. Esto te permite representar de forma eficiente muchos puntos de datos en cada momento. Stackdriver Monitoring luego puede visualizar esas métricas como un mapa de calor o por percentil. 
En el ejemplo anterior se muestra un mapa de calor producido a partir de una métrica de distribución extraída de un campo de texto en las entradas de registro.

Tony Li, Ingeniero de confiabilidad en planta del New York Times, explica cómo se usan las nuevas etiquetas definidas por los usuarios aplicadas a proxies para mejorar la confiabilidad y el rendimiento a partir de registros.
“Con las métricas basadas en registros, podemos supervisar errores que ocurren en varios proxies y visualizar la frecuencia según el momento en que ocurren para determinar regresiones o configuraciones erróneas”.
El proceso más rápido se aplica a todas las métricas basadas en registros, incluidas las que se basan en recuentos y están disponibles en general. Las métricas de distribución y las etiquetas de usuario ahora están disponibles en versión beta.


Administra los registros de tu organización con exportaciones agregadas 


Stackdriver Logging te permite exportar registros a GCS, PubSub o BigQuery usando receptores de registros. Escuchamos comentarios sobre el hecho de que la administración de exportaciones entre cientos o miles de proyectos en una organización puede resultar tediosa y estar sujeta a errores. Por ejemplo, si un administrador de seguridad de una organización quisiera exportar todos los registros de auditoría a un proyecto central en BigQuery, debería configurar un receptor de registros en cada proyecto y validar la presencia de un receptor activo para cada proyecto nuevo.

Con las exportaciones agregadas, los administradores de una organización o una carpeta pueden configurar receptores una sola vez, y estos son heredados por todos los proyectos secundarios y las subcarpetas. Esto permite que el administrador de seguridad exporte todos los registros de auditoría de su organización a BigQuery con un solo comando:

gcloud beta logging sinks create my-bq-sink 
bigquery.googleapis.com/projects/my-project/datasets/my_dataset 
--log-filter='logName= "logs/cloudaudit.googleapis.com%2Factivity"' 
--organization=1234 --include-children

Las exportaciones agregadas ayudan a garantizar que en futuros proyectos los registros se exporten correctamente. Debido a que el receptor se configura en el nivel de organización o carpetas, también evita que un propietario de un proyecto individual lo desactive.

Controla el proceso en Stackdriver Logging con filtros de exclusión 

Todos los registros que se envían a la Logging API, independientemente de que los envíes tú o los servicios de Google Cloud, siempre han ido a parar a Stackdriver Logging, donde pueden buscarse en el Visor de registros. Sin embargo, recibimos comentarios en los cuales se afirmaba que los usuarios deseaban más control sobre los registros que se transfieren a Stackdriver Logging, y los tuvimos en cuenta. Para abordar esto, los filtros de exclusión ya están disponibles en la versión beta. Los filtros de exclusión te permiten reducir costos, mejorar la relación señal/ruido al disminuir la cantidad de registros con exceso de intercambio de información y administrar el cumplimiento bloqueando los registros de una fuente o estableciendo coincidencias con un patrón por la disponibilidad en Stackdriver Logging. La nueva página Resource Usage te permite visualizar los recursos que envían registros y los que se excluyen de Stackdriver Logging.


Esto facilita la exclusión de algunos o todos los registros futuros de un recurso específico. En el ejemplo anterior, excluimos el 99% de los registros exitosos del balanceador de cargas. Sabemos que la elección y la libertad de elegir cualquier solución son importantes, por lo que todos los registros GCP están disponibles, independientemente de los filtros de exclusión de registros, para la exportación a BigQuery, Google Cloud Storage o cualquier herramienta de terceros a través de PubSub. Además, Stackdriver no aplicará tarifas por esta exportación, aunque BigQuery, GCS y PubSub sí lo harán.

A partir del 1 de diciembre, Stackdriver Logging ofrecerá 50 GB de registros por proyecto por mes gratis 


Nos comunicaron el deseo de aumentar el espacio con Stackdriver sin preocuparse por el costo de registrar todos esos datos; por eso, a partir del 1 de diciembre, aumentaremos la asignación de registros gratuitos a un límite líder en la industria de 50 GB por proyecto por mes. Este incremento apunta a acercar la potencia de las capacidades de búsqueda, almacenamiento, análisis y alerta de Stackdriver Logging a todos nuestros clientes.

¿Necesitas para tus registros una capacidad superior a la asignación mensual gratuita de 50 GB? Puedes registrarte en el nivel Premium de Stackdriver o en el excedente de registros en el nivel Básico. Después del 1 de diciembre, los registros adicionales tendrán una tarifa plana de USD 0,50/GB.


Los registros de auditoría todavía son gratuitos y están disponibles por 13 meses 

También exceptuaremos los registros de auditoría de actividad administrativa de los límites y el excedente. Estarán completamente disponibles en Stackdriver sin cargo. Ahora podrás conservarlos por 13 meses en lugar de 30 días.

Sigamos conversando 


Esperamos acercar la potencia de las capacidades de búsqueda, almacenamiento, análisis y alerta de Stackdriver Logging a todos nuestros clientes. Tenemos pensadas muchas más funciones increíbles, entre las cuales se incluyen un selector de intervalo que se lanzará en septiembre para facilitar la visibilidad de la periodicidad de los resultados de las búsquedas. Siempre esperamos más comentarios y sugerencias sobre cómo mejorar Stackdriver Logging. No dejes de enviarnos tus preguntas y comentarios.

¿Te gustaría recibir más información sobre estas nuevas funciones?

Por Chang Luo y Bob Liu, ingenieros de software 

En las partes 1 y 2 de esta serie, te mostramos cómo compilar una app de guía turística conversacional con API.AI y Machine Learning API de Google Cloud. En esta parte final, aprenderás a extender esta app a los dispositivos compatibles con el Asistente de Google (Google Home, algunos teléfonos Android y iPhone, y Android Wear). También compilaremos esto sobre el agente API.AI existente que se creó en las partes 1 y 2.
 Por Chang Luo y Bob Liu, ingenieros de software 

En las partes 1 y 2 de esta serie, te mostramos cómo compilar una app de guía turística conversacional con API.AI y Machine Learning API de Google Cloud. En esta parte final, aprenderás a extender esta app a los dispositivos compatibles con el Asistente de Google (Google Home, algunos teléfonos Android y iPhone, y Android Wear). También compilaremos esto sobre el agente API.AI existente que se creó en las partes 1 y 2.

Nuevos intents para Actions on Google

En la parte 1, tratamos las relaciones de los contextos de entrada y salida de la app.

El contexto where requiere que el usuario suba una imagen que no sea compatible con el Asistente de Google. Podemos modificar la relación contextual como se muestra a continuación.

Agregaremos tres intents nuevos: hours-no-context, ticket-no-context y map-no-context. Cada intent configurará location como contexto de salida, de modo que otros intents puedan usar la ubicación como un parámetro de entrada. 


Habilitar la integración de Actions on Google 


Ahora habilitaremos Actions on Google para que admita el Asistente de Google.

  1.  Abre tu consola API.AI. En la pestaña Integrations, activa la integración Actions on Google.
  2. En el diálogo emergente, en Additional triggering intents, agrega todos los intents que desees admitir en el Asistente de Google. El sistema fijará automáticamente el intent Welcome como el intent Welcome predeterminado. También puedes hacer clic en SETTINGS en Actions on Google para visualizar el diálogo de configuración en el futuro. Ten en cuenta que el intent inquiry.where requiere la carga de una imagen y no funciona en el Asistente de Google, de modo que no debes agregarlo a la lista de intents de activación. En la sección Nuevo intent para Actions on Google discutimos cómo agregar un nuevo intent para abordar esto. 
  3. Una vez que termines de agregar todos los intents que desees admitir en Google on Actions (por ejemplo, el intent hours-no-context) a la lista de additional triggering intents, toca el botón UPDATE y TEST en la parte inferior. Esto generará un cuadro de color verde. Presiona el botón VIEW para acceder al simulador web de Actions on Google. 
    Si es la primera vez que usas la consola de Actions on Google, te indicará que actives Device Information y Voice & Audio Activity en tu centro de controles de actividad.
    De forma predeterminada, estas configuraciones están desactivadas. Si ya las activaste, no verás el aviso. 
  4. Después de activar estas dos configuraciones, vuelve al simulador. Ya estás listo para probar la integración en el simulador. Comienza escribiendo o diciendo “Talk to my test app”. El simulador responderá con texto del intent Welcome predeterminado. Luego, podrás probar la app como si estuvieras en la consola de prueba API.AI. 

Diferencia entre las API tell() y ask() 

Como mencionamos en la parte 2, existe una diferencia sutil entre las API tell() y ask() cuando implementamos Cloud Function con el Actions on Google SDK. Esto no genera una diferencia notable en las partes 1 y 2, pero sí en la parte 3, cuando integramos Actions on Google. tell() finalizará la conversación y cerrará el micrófono, mientras que ask() mantendrá la conversación abierta y esperará la siguiente entrada del usuario.

Puedes probar la diferencia en el simulador. Si usas tell() en Cloud Functions, deberás decir nuevamente “talk to my test app” después de activar los intents con el webhook de Cloud Functions, como el intent inquiry.parades “Are there any parades today?”. Si usas ask(), aún estarás en la conversación de la app de prueba y no necesitarás volver a decir “talk to my test app”.

Próximos pasos 

Esperamos que en este ejemplo se demuestre la manera de compilar una app simple impulsada por aprendizaje automático. Para obtener más información sobre cómo dar los primeros pasos, te recomendamos probar lo siguiente:

Puedes descargar el código fuente de github.