Local blog for Italian speaking developers
È ora di "Hello, World": VM, container, PaaS e FaaS a confronto
9 luglio 2018
Pubblicato da Dmytro Melnyk, Product Marketing Manager
Vuoi creare applicazioni su
Google Cloud Platform
(GCP) ma non sai da dove cominciare? Questo ero io solo pochi mesi fa, prima di fare parte del team di calcolo di Google Cloud. Per prepararmi al colloquio, mi sono guardato un sacco di interviste sulle talk presentate a
GCP Next 2017
per tenermi al passo con lo sviluppo di applicazioni su GCP.
Poiché non c'è modo migliore di imparare se non fare, ho deciso di creare un'applicazione web "Hello, World" su ogni prodotto di calcolo di GCP: Google Compute Engine (VM), Google Kubernetes Engine (container), Google App Engine (PaaS) e Google Cloud Functions (FaaS). Per rendere questo esercizio più divertente (e finirlo in un fine settimana), ho cronometrato tutto, preso appunti e pubblicato i risultati in un
lungo post su Medium
, che potrebbe interessarti se pensi di intraprendere lo stesso percorso.
Allora dove eseguo il mio codice?
A un livello elevato, la questione di quale opzione di calcolo utilizzare è... dipende. In generale, si riduce a considerare i seguenti tre criteri:
Il livello di astrazione (a cosa vuoi pensare)
I requisiti tecnici e vincoli
La direzione del tuo team e la tua organizzazione
Il Google Developer Advocate
Brian Dorsey
ha fatto un'ottima presentazione lo scorso anno su
Deciding between Compute Engine, Container Engine, App Engine
ed eccone un riassunto:
Come regola generale, gli sviluppatori preferiscono sfruttare i livelli più elevati della scala di astrazione di calcolo, perché ci consentono di concentrarci sull'applicazione e sul problema che stiamo risolvendo, evitando al tempo stesso attività indifferenziate quali la manutenzione del server e la pianificazione della capacità. Con Cloud Functions, bisogna solo pensare al codice che viene eseguito in risposta agli eventi (il paradiso per gli sviluppatori!). A seconda dei dettagli del problema che stai cercando di risolvere, i vincoli tecnici possono farti abbassare il livello. Ad esempio, se hai bisogno di un kernel molto specifico, potresti trovarti a livello base (Compute Engine). Una buona risorsa sulla navigazione di questi punti decisionali è
Choosing the right compute option in GCP: a decision tree
.
Quale linguaggio di programmazione devo usare?
GCP
supporta ampiamente i seguenti linguaggi di programmazione
: Go, Java, .NET, Node.js, PHP, Python e Ruby (dettagli e runtime specifici possono variare a seconda del servizio). Il linguaggio migliore dipende da molti fattori, tra cui l'attività in questione e le preferenze personali. Visto che non avevo molta esperienza concreta di sviluppo del backend, ho scelto Node.js.
Spiegazione veloce per chi non conoscesse Node.js: è un runtime JavaScript asincrono progettato per creare backend di applicazioni web scalabili. Cerchiamo di decifrare questa frase:
"Asincrono" significa supporto di prima classe per operazioni asincrone (rispetto a molti altri linguaggi sul lato server in cui si potrebbe dover pensare a operazioni asincrone e threading, ossia una mentalità totalmente diversa). È ideale per la maggior parte delle applicazioni cloud con molte operazioni asincrone.
Node.js è anche il modo più semplice per chi proviene dal mondo dei frontend (dove JavaScript è il linguaggio di fatto) per iniziare a scrivere il codice di backend.
C'è anche
npm
, la più grande raccolta al mondo di codice gratuito riutilizzabile. Ciò significa che puoi importare molte funzionalità utili senza scriverle.
Non male, no? Io ne sono convinto!
Pronti, partenza, via!
Per prepararmi al colloquio, ho iniziato da Compute Engine e VM e poi sono passato ai livelli del servizio di calcolo-scala di astrazione, a Kubernetes Engine e Container, ad App Engine e app, e infine a Cloud Functions. La seguente tabella fornisce un rapido riepilogo, inclusi i link, del mio percorso e alcune risorse con cui iniziare.
Dal punto A al punto B
Tempi e risorse iniziali
Compute Engine
Passaggi di base:
Crea e configura un'istanza VM
Configura l'ambiente di sviluppo Node.js
Scrivi il codice "Hello, World"
Avvia il server Node
Esponi l'app al traffico esterno
Comprendi come funziona la scalabilità
Consulta
Building with virtual machines
.
4,5 ore
Creating a VM Instance
Installing Node.js
How to create an http server
Running Bookshelf on GCE
Node.js and GCP
Kubernetes Engine
Passaggi di base:
Scrivi il codice "Hello, World"
Pacchetto dell'app in un container
Invia l'immagine in modalità push a Container Registry
Crea un cluster Kubernetes
Esponi l'app al traffico esterno
Comprendi come funziona la scalabilità
Consulta
Building with Docker containers
.
6 ore
Dockerizing a Node.js web app
Kubernetes Engine quickstart
Working with Container Registry
Hello Node codelab
App Engine
Passaggi di base:
Scrivi il codice "Hello, World"
Configura un file di progetto app.yaml
Implementa l'applicazione
Comprendi le opzioni di scalabilità
Consulta
Building on top of app platform
.
1,5 - 2 ore
An overview of App Engine
Configuring your App
Design best practices
Cloud Functions
Passaggi di base:
Scrivi il codice "Hello, World"
Implementa l'applicazione
Consulta
Building with code functions
.
15 minuti
cloud.google.com/functions/
Cloud Functions overview
HTTP Functions
Confronto tempi-risultati
Anche se potrebbe essere un po' come confrontare mele e pere, ecco un riassunto dei miei risultati (per inciso, si riferisce solo a come creare un'applicazione web "Hello, World" da zero, tutte le altre questioni, come l'esecuzione dell'app in produzione, sono a parte).
Il confronto tempi-risultati potrebbe essere molto diverso a seconda dei vari fattori, compreso il livello di esperienza con una determinata tecnologia. Il mio obiettivo era carpire i fondamenti di ogni opzione nello stack di calcolo GCP e valutare il carico di lavoro necessario per andare dal punto A al punto B. Detto questo, se ci fosse una competizione tecnologica trasversale in
stile jet da combattimento contro un'automobile
per creare un microservizio HTTP scalabile da zero, non esiterei ad affrontarla contro un grande maestro di Kubernetes come
Kelsey Hightower
con Cloud Functions!
Per ulteriori informazioni sullo sviluppo di applicazioni in GCP, consulta
Computing on Google Cloud Platform
. Ricorda che riceverai un credito gratuito di 300 $ se ti
registri
.
Buon lavoro!
Altre letture su Medium:
Parte 1 Overview of compute service-abstraction ladder
Parte 2 Building with virtual machines (Compute Engine)
Parte 3 Building with containers (Kubernetes Engine)
Parte 4 Building on top of PaaS (App Engine)
Parte 5 Building with FaaS (Cloud Functions)
Che anno! La Google Cloud Platform nel 2017
10 gennaio 2018
Pubblicato da Alex Barrett e Barrett Williams, editor del blog Google Cloud
La fine dell'anno offre opportunità per riflettere . . . e per fare liste. Visto che ci siamo lasciati da poco alle spalle il 2017, abbiamo pensato di rivedere alcuni degli annunci di prodotti, white paper e guide su
Google Cloud Platform
(GCP) più memorabili, in base alla loro popolarità con i nostri lettori.
Raccogliendo le informazioni per questo post, sono emersi alcuni chiari temi sui vostri interessi riguardo a GCP:
Amate sentire parlare di
infrastruttura avanzata
: CPU, GPU, TPU e "tubature" migliori per la rete e più regioni.
Il modo in cui
finalizziamo la nostra infrastruttura
sembra interessare costantemente, così come i suggerimenti su come utilizzare i servizi di sicurezza.
L'
open source
è sempre molto apprezzato dal pubblico, soprattutto se presenta soluzioni cloud-native a un vecchio problema.
Vi sentite ispirati dall'
innovazione offerta da Google
: tecnologie esclusive sviluppate per affrontare problemi interni sulla scala di Google. Quindi, senza ulteriori indugi, ecco a voi le storie più lette del 2017.
Infrastruttura all'avanguardia
Se credete nella teoria "più grande è, meglio è" per le infrastrutture cloud, allora quest'anno è stato il massimo per voi. All'inizio del 2017 abbiamo annunciato che la GCP sarebbe stata la
prima a fornire nel cloud l'architettura Intel Skylake
, le
GPU per Compute Engine e Cloud Machine Learning
sono divenute disponibili al pubblico e Shazam ha parlato del
perché le GPU nel cloud hanno un loro senso
. In primavera avete divorato un articolo sulle
prestazioni delle TPU
e un altro sul
cluster di calcolo basato su cloud (allora) più grande
. Non solo abbiamo annunciato altri
nuovi modelli GPU
, ma Compute Engine ha iniziato a offrire
tipi di macchine con enormi 96 vCPU e 624 GB
di memoria.
E se queste novità non hanno attirato la vostra attenzione, l'ha sicuramente fatto l'infrastruttura di rete Google Cloud. Avete letto avidamente argomenti come
Espresso, la nostra architettura all'avanguardia
, il
Controllo della congestione TCP BBR
e la maggiore latenza di Compute Engine con
Andromeda 2.1
. Vi sono piaciute anche le storie sulle nuove funzionalità di rete:
Interconnessione dedicata
,
Livelli di servizi di rete
e il singolare approccio di GCP a sneakernet:
Transfer Appliance
.
A cosa servono le grandi infrastrutture se non sappiamo dove metterle? Il 2017 è stato anche un anno di grande espansione geografica. Abbiamo iniziato l'anno con sei regioni e lo abbiamo concluso con 13, aggiungendo la
Virginia del Nord
,
Singapore
,
Sydney
,
Londra
, la
Germania
,
Sao Paolo
e
Mumbai
. Quest'anno siamo anche andati oltre i nostri confini terrestri e ci siamo
espansi su Marte
;)
Sicurezza innanzitutto
Google ha sempre fatto tutto il possibile per
proteggere la nostra infrastruttura
e questo è stato l'anno in cui abbiamo discusso alcune di queste tecniche avanzate nella nostra famosa
serie Security in plaintext
. Ne elenchiamo alcune:
7 ways we harden our KVM hypervisor
,
Fuzzing PCI Express
e
Titan in depth
.
Sono stati anche molto apprezzati i nuovi servizi di sicurezza GCP:
Cloud Key Management
e
Certificati SSL gestiti per applicazioni App Engine
. Avete anche preso a cuore un white paper sul modo di implementare
BeyondCorp come alternativa più sicura alla VPN
e il supporto delle
Leggi sulla protezione dei dati GDPR
europee per tutta la GCP.
Sviluppo aperto e ibrido
Pensando a GCP e all'open source, ci viene in mente Kubernetes. Abbiamo reso open source la piattaforma di gestione dei container nel 2014, ma quest'anno abbiamo dimostrato che GCP è la soluzione ottimale per eseguirla. È costantemente tra i primi servizi cloud a eseguire l'ultima versione (recentemente
Kubernetes 1.8
) e offre
funzionalità di gestione avanzate
pronte all'uso. A partire da quest'autunno è certificato come una distribuzione conforme Kubernetes e ha un nuovo nome:
Google Kubernetes Engine
.
Kubernetes è un primo passo indipendente dalla piattaforma verso il cloud. Di conseguenza, molti di voi si sono interessati a storie su Kubernetes e sui container in scenari ibridi. Basta pensare a
Pivotal Container Service
e al ruolo di Kubernetes nella nostra
nuova partnership con Cisco
. Molti sviluppatori sono rimasti colpiti da
Cloud Container Builder
, uno strumento autonomo per la creazione di immagini di container, indipendentemente da dove vengano poi distribuite.
Ma i nostri sforzi nell'ambito dell'open source non si sono limitati a Kubernetes, abbiamo anche dato un contributo significativo a
Spinnaker 1.0
e a lanciare i progetti
Istio
e
Grafeas
. Anche la serie "
Partnering on open source
" ha avuto molto successo grazie anche a HashiCorp, Chef, Ansible e Puppet. Gli sviluppatori attenti alla disponibilità hanno apprezzato la missiva del team di Customer Reliability Engineering (CRE) sulle
versioni canary
e, con
API design: Choosing between names and identifiers in URLs
, il nostro team Apigee team ha introdotto un modo elegante di avere la proverbiale torta e mangiarsela pure.
Innovazione Google
Spanner di Google è leggendario nell'ambito dei database distribuiti, quindi molti di voi hanno apprezzato l'annuncio di
Cloud Spanner
e la discussione su come sfidi il
Teorema della PAC
. Avere un database scalabile che offre una forte coerenza
e
grandi prestazioni può davvero cambiare la concezione di ciò che è possibile, proprio come nel caso di
Cloud IoT Core
, la nostra piattaforma per connettere e gestire "cose" su larga scala. Invece i CRE mostrano come Google gestisce
un evento imprevisto
.
Il 2017 è stato anche l'anno in cui il machine learning è diventato accessibile. A chi opera con grandi set di dati, abbiamo mostrato
come utilizzare Cloud Dataprep, Dataflow e BigQuery
per pulire e organizzare i dati non strutturati. Abbiamo scoperto che
non è necessario un PhD per imparare a usare TensorFlow
e, per chi apprende visivamente, abbiamo spiegato come visualizzare una varietà di architetture di reti neurali con
TensorFlow Playground
. Un Developer Advocate di Google ha persino insegnato al figlio, che frequenta la scuola media, come applicare TensorFlow e l'algebra lineare di base al
gioco di sasso-forbice-carta
.
L'elaborazione del linguaggio naturale è divenuta un pilastro nelle applicazioni basate sul machine learning, eccone un
esempio leggero e facilmente riconoscibile
. Abbiamo anche lanciato l'
API Video Intelligence
e dimostrato come il Cloud Machine Learning Engine semplifichi il processo dell'
addestramento di un rilevatore di oggetti personalizzati
. I maker tra di voi hanno apprezzato molto il post su come
aggiungere il machine learning ai progetti IoT
con l'AIY Voice Kit di Google. Quando si dice l'accessibilità!
Infine vogliamo ringraziare tutti i nostri clienti, partner e lettori per la fedeltà e il sostegno dimostrati tutto l'anno. Continuate a seguirci anche
questo
anno. Se pensate che abbiamo avuto molto da dire nel 2017, non sapete cosa vi aspetta!
Guida alle soluzioni: creazione di app per veicoli connessi con Cloud IoT Core
7 agosto 2017
Pubblicato da Charles Baer, Solutions Architect
Grazie a Internet of Things (IoT), i veicoli si stanno evolvendo da prodotti autonomi incentrati sul trasporto a sofisticati endpoint connessi a Internet spesso capaci di comunicare in modo bidirezionale. I nuovi flussi di dati generati dai veicoli moderni connessi favoriscono la creazione di modelli di business innovativi come assicurazioni basate sull'utilizzo, nuove esperienze all’interno del veicolo e forniscono basi solide per progredire nel campo della guida autonoma e della comunicazione tra veicolo e veicolo (V2V).
Nel mezzo di questo processo, a Google Cloud siamo entusiasti di contribuire per rendere questo mondo una realtà. Recentemente abbiamo pubblicato una
guida alle soluzioni
che illustra i diversi servizi offerti da
Google Cloud Platform
(GCP) in questo ambito.
Una valanga di dati
I veicoli possono produrre fino a 560 GB di dati ciascuno al giorno. Questa valanga di dati rappresenta un’opportunità incredibile e al tempo stesso un’enorme sfida per le piattaforme che connettono e gestiscono i dati dei veicoli, tra cui:
Gestione dei dispositivi
. La connessione dei dispositivi a qualsiasi piattaforma richiede autenticazione, autorizzazione e la capacità di inviare il software di aggiornamento, configurazioni e monitoraggi in modalità push. Questi servizi devono essere scalabili per accomodare eventualmente milioni di dispositivi e offrire una disponibilità costante.
Inserimento dei dati
. I messaggi devono essere ricevuti, elaborati e archiviati in modo affidabile.
Analisi dei dati
. La complessa analisi dei dati di serie temporali, generata dai dispositivi, deve essere utilizzata per ottenere informazioni su eventi, tolleranze, tendenze ed eventuali errori.
Applicazioni
. La logica delle applicazioni a livello aziendale deve essere sviluppata e integrata con fonti di dati esistenti che possono provenire da terze parti o da data center in locale.
Modelli predittivi
. Per prevedere i risultati a livello aziendale devono essere sviluppati modelli predittivi basati sui dati attuali e storici.
I servizi GCP, tra cui il
Cloud IoT Core
recentemente lanciato, forniscono una robusta piattaforma di computing che sfrutta il
modello di sicurezza end-to-end
di Google. Diamo un'occhiata a come possiamo implementare una piattaforma per veicoli connessi utilizzando i servizi Google Cloud.
(fai clic per ingrandire)
Gestione dei dispositivi
: per ottenere gestioni e comunicazioni sicure dei dispositivi, Cloud IoT Core consente di semplificare la connessione sicura dei dispositivi distribuiti a livello globale con GCP per poi gestirli centralmente. IoT Core Device Manager fornisce l'autenticazione e l'autorizzazione, e IoT Core Protocol Bridge abilita la messaggistica tra i veicoli e la piattaforma.
Inserimento dei dati
: Cloud Pub/Sub rappresenta un punto di inserimento dei dati scalabile in grado di gestire grandi volumi di dati generati dai veicoli che inviano la posizione GPS, il numero di giri del motore e le immagini. I servizi di archiviazione scalabile di Cloud BigTable sono particolarmente adatti per la memorizzazione e l’analisi dei dati di serie temporali.
Analisi dei dati
: Cloud Dataflow può elaborare pipeline di dati che uniscono i dati del dispositivo del veicolo con quelli del veicolo aziendale e del cliente, per poi archiviare i dati combinati in BigQuery, che costituisce un potente motore di analisi as-a-service e si integra con strumenti di visualizzazione comuni come Tableau, Looker e Qlik.
Applicazioni
: Compute Engine, Container Engine e App Engine, forniscono tutti componenti di computing importanti per la piattaforma per veicoli connessi. Compute Engine offre un’ampia gamma di tipi di macchine che lo rendono il servizio ideale per qualsiasi componente di integrazione di terze parti. Esegue e gestisce container che garantiscono un elevato grado di flessibilità e scalabilità grazie alla loro architettura a microservizi. Infine App Engine è una piattaforma scalabile serverless ideale per i servizi di frontend per applicazioni consumer e mobili.
Modelli predittivi
:
TensorFlow
e
Cloud Machine Learning Engine
forniscono un sofisticato framework di modellazione e un ambiente di esecuzione scalabile. TensorFlow offre il framework per sviluppare modelli personalizzati di rete neurale profonda ed è ottimizzato per prestazioni, flessibilità e scalabilità
,
tutti fattori critici quando si sfruttano i dati generati da IoT. Machine Learning Engine garantisce un ambiente scalabile per addestrare i modelli TensorFlow utilizzando hardware specializzato nelle infrastrutture di computing di Google, tra cui GPU e TPU.
In sintesi
I veicoli si stanno trasformando in avanzati dispositivi IoT con piattaforme tecnologiche mobili integrate a cui terze parti possono connettersi e offrire servizi avanzati. GCP fornisce una piattaforma sicura, robusta e scalabile per collegare dispositivi IoT che spaziano da sofisticate autoradio a semplici sensori a bassa potenza. Per saperne di più sulla prossima generazione di veicoli connessi grazie a GCP, leggi il seguente paper:
Designing a Connected Vehicle Platform on Cloud IoT Core (Progettare una piattaforma per veicoli connessi su Cloud IoT Core)
.
!--
-->
Pianificare task affidabili su Google Compute Engine
27 agosto 2015
Molti sistemi richiedono operazioni pianificate, ma riuscire ad eseguirle in modo affidabile in un ambiente distribuito può essere sorprendentemente difficile.
Immaginate di provare a eseguire un servizio cron UNIX standard in una serie di macchine virtuali. Le singole macchine vengono però attivate e disattivate a causa del sistema di autoscaling e partizionamento della rete. Un task importante potrebbe non essere mai eseguito perché l'istanza è stata disattivata diventando non disponibile. In altri casi un compito destinato ad essere eseguito una sola volta potrebbe essere ripetuto da molti server quando il sistema crea nuove istanze.
Utilizzando il
servizio Cron di Google App Engine
per lo scheduling e
Google Cloud Pub/Sub
per la messaggistica, è possibile costruire un programma di pianificazione distribuito in grado di girare su più macchine virtuali. In questo articolo viene spiegato il funzionamento del nostro
sistema di pianificazione dei task per Google Compute Engine
insieme ad un esempio di
codice disponibile su GitHub
.
In questo modello di progettazione, una applicazione App Engine schedula eventi sul servizio di cron. Quando il servizio Cron chiama i gestore di eventi l'applicazione App Engine utilizza Cloud Pub/Sub per ritrasmettere l’evento sulle istanze Compute Engine in esecuzione.
Quando le singole istanze ricevono un messaggio, viene eseguito uno script che corrisponde al Cloud Pub/Sub. Questi script vengono eseguiti in loco proprio come se fossero gestiti dal Cron localmente. In realtà, tramite questo modello di progettazione
è possibile riutilizzare gli script Cron già esistenti
.
Utilizzare Cloud Pub/Sub per la messaggistica distribuita significa avere la possibilità di pianificare un evento per essere eseguito solo su uno dei molti server, o eseguire l'attività su più server contemporaneamente.
Per una spiegazione dettagliata di questo modello di progettazione è disponibile un articolo sulla
creazione di Task Affidabili su Google Compute Engine
, che include un
esempio di implementazione
disponibile su GitHub. Sentitevi liberi di fare richieste di pull o aprire issues direttamente sul repository.
Pubblicato da Preston Holmes, Solutions Architect
Pubblicati i video della Google Cloud Platform Dev Conf Milano
13 dicembre 2013
L'8 Novembre il Politecnico di Milano, dipartimento di Elettronica, Informatica e Biomedica, ha ospitato una nuova tappa della
Google Cloud Platform Dev Conf
, evento dedicato alle tecnologie cloud di Google. Di seguito alcuni dei video delle sessioni presentate.
Applicazioni Java su Google App Engine
Applicazioni PHP su Google App Engine
Continua a leggere...»
Etichette
Android
Firebase
machine learning
Google Cloud Platform
GDL
Eventi
Google Developers Live
Google Play
TensorFlow
App
Chrome
Cloud
api
GDLItalia
GDE
GDG
Google Assistant
iOS
Kotlin
Actions on Google
Deep Learning
AppEngine
AMP
BigQuery
Cloud Functions
Flutter
Android Studio
Google Developers Expert
Università
Google AppEngine
JavaScript
AI
Android Wear
GAE
Google Play Store
HTML5
Maps
security
Android App Development
AngularJS
IoT
Kubernetes
Annunci
Cloud Firestore
Cloud Machine Learning
Google I/O
Polymer
Android Things
Community
DevTools
Google App Engine
intelligenza artificiale
Entrepreneurship
Firebase Analytics
GSoC
Games
Google Cast
ML
open source
Crashlytics
Dart
Diversity
Drive
Google Data Studio
Google Play Games
TensorFlow Lite
Android Developers
Android O
Cloud Spanner
Cloud TPU
Compute Engine
DevFest
Google Compute Engine
Google Developers
Material Design
Mobile
PWA
Python
Startup
AIY Project
ARCore
Android Jetpack
AndroidDev
Androidq
Apps Script
Artificial Intelligence
Augmented Reality
Firebase Cloud Messaging
Google Cloud
Google Maps
Gsuite
IO19
ML kit
Research
VR
coding
unity
#io19
AR
Android Dev Summit
Android Developer
Android Q
Cardboard
Cloud AI
Coral
Developers
Dialogflow
Firebase Realtime Database
Gmail
Google AI
Google Cloud Messaging
Google ContainerEngine
Google Play Console
Kotlin Coroutines
NLP
Programming
Responsive Design
TensorFlowjs
Testing
WTM
Women
beacons
cloud storage
developer
node JS
student programs
women techmakers
API Cloud Vision
Add-ons
Android P
AndroidDevStory
Animation
AutoML
Brillo
Classroom
DSC
Database
Developer Student Clubs
Edge TPU
Fabric
Featured
Flutter Web
G Suite
GWT
GoLang
Google
Google Brain
Google Cloud Next
Google Container Engine
Google Developer Groups
Google I/O Extended
Graph
Hosting
Instant Apps
Keras
Livedata
Mobile Sites
Prediction
Privacy
Project Tango
SDK
Stackdriver
Tales
UI
Udacity
Virtual Reality
Web
Web Development
YouTube
analytics
android security
api.ai
courses
google io
indies
natural language processing
reti neurali
sign-in
young developers
2d Animation
3d
AIY
ARkit
Adversarial Learning
Alpha
Android App
Android App Developmen
Android App bundle
Android Architecture
Android Architecture Components
Android Auto
Android Automotive OS
Android Dev Summit Android Developer
Android Developer Challenge
Android Developers GooglePlayAwards
Android Development
Android Go
Android Instant App
Android Pie
Android Q Scoped Storage
Android Q audio
Android Styles
Android audio playback capture
Android codelabs
AndroidTV
AndroidX
Angular
Aogdevs
Api Design
App Development
App Distribution
Apps
Architecture
Architecture Components
Arduino
Best Practices
Betatesting
Bugs
C++
Certification
Cloud Anchors
Cloud Next
Cloud Run
Cloud Service Platform
Cloud Shell
Cloud Study Jam
Coached Conversational Preference Elicitation
Commerce
Community Connector
Computer Science
Consistency
Containers
Converge
Conversation Design
Crash Reporting
DLS Design
Dagger
Data Science
Databases
Dependency Injection
Design
Developer Communities
Developer Community
Developer Culture
Developer Story
Developing Media Apps
Development
Eager
Edge TPU Dev Board
Education
Emulatore Android
Error Message
Eslint
Europe
Firebase Extensions
Firebase Summit 2019
Firebasehosting
Flutter 1.5
Flutter at IO
FlutterDark
GCE
GDD
Game Development
Gboard
Gesture Navigation
Glass
Go
Google AI Quantum
Google App Script
Google Cloud Functions
Google Cloud billing
Google Coral
Google Developer Days
Google Home Hub
Google IOS Android
Google Identity Platform
Google Launchpad
Google Lens
Google Now
Google Photos
Google Play Devs
Google Play Indie Games Festival
Google Play Instant
Google Plus
Google codelabs
Google+
GoogleDevWeekly
GoogleLaunchpad
GooglePlay
Graphics
Healthcare
I/O
IO
IO19 Flutter
In-app Billing
Indie Games
Indie Games Festival
Indie games showcase
Indie showcase
Ingress
Instant Games
Issues
Java
Jetpack
Knative
Kotlin Beginners
Kotlin Everywhere
Kotlin codelabs
Lighthouse
Live Caption
Live Streaming
Localization
Location
M-Theory
Mondaygram
Monetization
NYT
NativeScript
Navigation
Neural Graph Learning
Neural Structured
Nodejs
OS
OS Updates
Olivex
One Time Codes
Online Education
PHA
Performance Monitoring
Policy
Posenet
Project Mainline
Project Treble
Quantum Computing Theory
Reactive Programming
Regression
Remote Config
Resonance Audio
Room
Scoped Storage
Semantics
Semi Supervised Learning
Serverless
Sms Retriever Api
Sms Verification
Speech Recognition
Swift
Tensorflow Core
Tensorflow Hub
Test Lab
Text
Tokenizer
Tpu
Transformers
UX
UX Design
UX Research
Universal Sentence Encoder
Unsupervised Data Augmentation
Unsupervised Learning
User Experience
Viewmodel
Voice
WWW
Wear OS
WebAssembly
Widget
Women in Tech
WomenTechmakers
android kotlin
app stability
assistant
audio recording
augmented faces
authsub
best practices and updates
billing
botnet
business
c++ games
cancer
chatbot
chrome privacy
codelab
codelabs
competition
daydream
designer
dominio .dev
error handling
event
firebase games
firebase gdc
firebase hosting
firebase unity
game center authentication
game testing
games authentication
gdc
google summer of code
googledevelopers
grow
hashcode
indie
indie developers
internship
kids
machine intelligence
machine learning accelerator
maker
multi-platform
nearby
oauth
openid
performance
persistent AR
privacy sandbox
prizes
prototype
purchase flows
queries
realtime
responsible AI
security rules
showcase
solutions challenge
startup africa roadtrip
startup times
students
summer of code
unity crashlytics
verify apps
win
Archivio Blog
2020
feb
gen
2019
dic
nov
ott
set
ago
lug
giu
mag
apr
mar
feb
gen
2018
dic
nov
ott
set
ago
lug
giu
mag
apr
mar
feb
gen
2017
dic
nov
ott
set
ago
lug
giu
mag
apr
mar
feb
gen
2016
dic
nov
ott
set
ago
lug
giu
mag
apr
mar
feb
gen
2015
dic
nov
ott
set
ago
lug
giu
mag
apr
mar
feb
gen
2014
dic
nov
ott
set
ago
lug
giu
mag
apr
mar
feb
gen
2013
dic
nov
ott
set
ago
lug
giu
mag
apr
mar
feb
gen
Feed
Follow @GoogleDevsItaly
