Early Stable Update for Android

Hi, everyone! We've just released Chrome 111 (111.0.5563.48/49) for Android to a small percentage of users: it'll become available on Google Play over the next few days. You can find more details about early Stable releases here.

This release includes stability and performance improvements. You can see a full list of the changes in the Git log. If you find a new issue, please let us know by filing a bug.

Harry Souders
Google Chrome

Chrome Beta for Android Update

Hi everyone! We've just released Chrome Beta 111 (111.0.5563.49) for Android. It's now available on Google Play.

You can see a partial list of the changes in the Git log. For details on new features, check out the Chromium blog, and for details on web platform updates, check here.

If you find a new issue, please let us know by filing a bug.

Harry Souders
Google Chrome

Early Stable Update for Desktop

The Stable channel has been updated to 111.0.5563.50 for Windows and Mac as part of our early stable release to a small percentage of users. A full list of changes in this build is available in the log.


You can find more details about early Stable releases here.

Interested in switching release channels?  Find out how here. If you find a new issue, please let us know by filing a bug. The community help forum is also a great place to reach out for help or learn about common issues.


Prudhvikumar Bommana

Google Chrome

Beta Channel Update for Desktop

The Beta channel has been updated to 111.0.5563.50 for Windows, Mac and Linux .

A full list of changes in this build is available in the log. Interested in switching release channels? Find out how here. If you find a new issues, please let us know by filing a bug. The community help forum is also a great place to reach out for help or learn about common issues.


PrudhviKumar Bommana

Teaching old labels new tricks in heterogeneous graphs

Industrial applications of machine learning are commonly composed of various items that have differing data modalities or feature distributions. Heterogeneous graphs (HGs) offer a unified view of these multimodal data systems by defining multiple types of nodes (for each data type) and edges (for the relation between data items). For instance, e-commerce networks might have [user, product, review] nodes or video platforms might have [channel, user, video, comment] nodes. Heterogeneous graph neural networks (HGNNs) learn node embeddings summarizing each node’s relationships into a vector. However, in real world HGs, there is often a label imbalance issue between different node types. This means that label-scarce node types cannot exploit HGNNs, which hampers the broader applicability of HGNNs.

In “Zero-shot Transfer Learning within a Heterogeneous Graph via Knowledge Transfer Networks”, presented at NeurIPS 2022, we propose a model called a Knowledge Transfer Network (KTN), which transfers knowledge from label-abundant node types to zero-labeled node types using the rich relational information given in a HG. We describe how we pre-train a HGNN model without the need for fine-tuning. KTNs outperform state-of-the-art transfer learning baselines by up to 140% on zero-shot learning tasks, and can be used to improve many existing HGNN models on these tasks by 24% (or more).

KTNs transform labels from one type of information (squares) through a graph to another type (stars).


What is a heterogeneous graph?

A HG is composed of multiple node and edge types. The figure below shows an e-commerce network presented as a HG. In e-commerce, “users” purchase “products” and write “reviews”. A HG presents this ecosystem using three node types [user, product, review] and three edge types [user-buy-product, user-write-review, review-on-product]. Individual products, users, and reviews are then presented as nodes and their relationships as edges in the HG with the corresponding node and edge types.

E-commerce heterogeneous graph.

In addition to all connectivity information, HGs are commonly given with input node attributes that summarize each node’s information. Input node attributes could have different modalities across different node types. For instance, images of products could be given as input node attributes for the product nodes, while text can be given as input attributes to review nodes. Node labels (e.g., the category of each product or the category that most interests each user) are what we want to predict on each node.


HGNNs and label scarcity issues

HGNNs compute node embeddings that summarize each node’s local structures (including the node and its neighbor’s information). These node embeddings are utilized by a classifier to predict each node’s label. To train a HGNN model and a classifier to predict labels for a specific node type, we require a good amount of labels for the type.

A common issue in industrial applications of deep learning is label scarcity, and with their diverse node types, HGNNs are even more likely to face this challenge. For instance, publicly available content node types (e.g., product nodes) are abundantly labeled, whereas labels for user or account nodes may not be available due to privacy restrictions. This means that in most standard training settings, HGNN models can only learn to make good inferences for a few label-abundant node types and can usually not make any inferences for any remaining node types (given the absence of any labels for them).


Transfer learning on heterogeneous graphs

Zero-shot transfer learning is a technique used to improve the performance of a model on a target domain with no labels by using the knowledge learned by the model from another related source domain with adequately labeled data. To apply transfer learning to solve this label scarcity issue for certain node types in HGs, the target domain would be the zero-labeled node types. Then what would be the source domain? Previous work commonly sets the source domain as the same type of nodes located in a different HG, assuming those nodes are abundantly labeled. This graph-to-graph transfer learning approach pre-trains a HGNN model on the external HG and then runs the model on the original (label-scarce) HG.

However, these approaches are not applicable in many real-world scenarios for three reasons. First, any external HG that could be used in a graph-to-graph transfer learning setting would almost surely be proprietary, thus, likely unavailable. Second, even if practitioners could obtain access to an external HG, it is unlikely the distribution of that source HG would match their target HG well enough to apply transfer learning. Finally, node types suffering from label scarcity are likely to suffer the same issue on other HGs (e.g., privacy issues on user nodes).


Our approach: Transfer learning between node types within a heterogeneous graph

Here, we shed light on a more practical source domain, other node types with abundant labels located on the same HG. Instead of using extra HGs, we transfer knowledge within a single HG (assumed to be fully owned by the practitioners) across different types of nodes. More specifically, we pre-train a HGNN model and a classifier on a label-abundant (source) node type, then reuse the models on the zero-labeled (target) node types located in the same HG without additional fine-tuning. The one requirement is that the source and target node types share the same label set (e.g., in the e-commerce HG, product nodes have a label set describing product categories, and user nodes share the same label set describing their favorite shopping categories).


Why is it challenging?

Unfortunately, we cannot directly reuse the pre-trained HGNN and classifier on the target node type. One crucial characteristic of HGNN architectures is that they are composed of modules specialized to each node type to fully learn the multiplicity of HGs. HGNNs use distinct sets of modules to compute embeddings for each node type. In the figure below, blue- and red-colored modules are used to compute node embeddings for the source and target node types, respectively.

HGNNs are composed of modules specialized to each node type and use distinct sets of modules to compute embeddings of different node types. More details can be found in the paper.

While pre-training HGNNs on the source node type, source-specific modules in the HGNNs are well trained, however target-specific modules are under-trained as they have only a small amount of gradients flowing into them. This is shown below, where we see that the L2 norm of gradients for target node types (i.e., Mtt) are much lower than for source types (i.e., Mss). In this case a HGNN model outputs poor node embeddings for the target node type, which results in poor task performance.

In HGNNs, target type-specific modules receive zero or only a small amount of gradients during pre-training on the source node type, leading to poor performance on the target node type.

KTN: Trainable cross-type transfer learning for HGNNs

Our work focuses on transforming the (poor) target node embeddings computed by a pre-trained HGNN model to follow the distribution of the source node embeddings. Then the classifier, pre-trained on the source node type, can be reused for the target node type. How can we map the target node embeddings to the source domain? To answer this question, we investigate how HGNNs compute node embeddings to learn the relationship between source and target distributions.

HGNNs aggregate connected node embeddings to augment a target node’s embeddings in each layer. In other words, the node embeddings for both source and target node types are updated using the same input — the previous layer’s node embeddings of any connected node types. This means that they can be represented by each other. We prove this relationship theoretically and find there is a mapping matrix (defined by HGNN parameters) from the target domain to the source domain (more details in Theorem 1 in the paper). Based on this theorem, we introduce an auxiliary neural network, which we refer to as a Knowledge Transfer Network (KTN), that receives the target node embeddings and then transforms them by multiplying them with a (trainable) mapping matrix. We then define a regularizer that is minimized along with the performance loss in the pre-training phase to train the KTN. At test time, we map the target embeddings computed from the pre-trained HGNN to the source domain using the trained KTN for classification.

In HGNNs, the final node embeddings of both source and target types are computed from different mathematical functions (f(): source, g(): target) which use the same input — the previous layer’s node embeddings.

Experimental results

To examine the effectiveness of KTNs, we ran 18 different zero-shot transfer learning tasks on two public heterogeneous graphs, Open Academic Graph and Pubmed. We compare KTN with eight state-of-the-art transfer learning methods (DAN, JAN, DANN, CDAN, CDAN-E, WDGRL, LP, EP). Shown below, KTN consistently outperforms all baselines on all tasks, beating transfer learning baselines by up to 140% (as measured by Normalized Discounted Cumulative Gain, a ranking metric).

Zero-shot transfer learning on Open Academic Graph (OAG-CS) and Pubmed datasets. The colors represent different categories of transfer learning baselines against which the results are compared. Yellow: Use statistical properties (e.g., mean, variance) of distributions. Green: Use adversarial models to transfer knowledge. Orange: Transfer knowledge directly via graph structure using label propagation.

Most importantly, KTN can be applied to almost all HGNN models that have node and edge type-specific parameters and improve their zero-shot performance on target domains. As shown below, KTN improves accuracy on zero-labeled node types across six different HGNN models(R-GCN, HAN, HGT, MAGNN, MPNN, H-MPNN) by up to 190%.

KTN can be applied to six different HGNN models and improve their zero-shot performance on target domains.

Takeaways

Various ecosystems in industry can be presented as heterogeneous graphs. HGNNs summarize heterogeneous graph information into effective representations. However, label scarcity issues on certain types of nodes prevent the wider application of HGNNs. In this post, we introduced KTN, the first cross-type transfer learning method designed for HGNNs. With KTN, we can fully exploit the richness of heterogeneous graphs via HGNNs regardless of label scarcity. See the paper for more details.


Acknowledgements

This paper is joint work with our co-authors John Palowitch (Google Research), Dustin Zelle (Google Research), Ziniu Hu (Intern, Google Research), and Russ Salakhutdinov (CMU). We thank Tom Small for creating the animated figure in this blog post.

Source: Google AI Blog


Introducing Service Weaver: A Framework for Writing Distributed Applications

We are excited to introduce Service Weaver, an open source framework for building and deploying distributed applications. Service Weaver allows you to write your application as a modular monolith and deploy it as a set of microservices.

More concretely, Service Weaver consists of two core pieces:

  1. A set of programming libraries, which let you write your application as a single modular binary, using only native data structures and method calls, and
  2. A set of deployers, which let you configure the runtime topology of your application and deploy it as a set of microservices, either locally or on the cloud of your choosing.
  3. Flow chart of Service Weaver Programming Libraries from development to execution, moving four modules labeled A through D from application across a level of microservices to deployers labeled Desktop, Google Cloud, and Other Cloud
By decoupling the process of writing the application from runtime considerations such as how the application is split into microservices, what data serialization formats are used, and how services are discovered, Service Weaver aims to improve distributed application development velocity and performance.

Motivation for Building Service Weaver

While writing microservices-based applications, we found that the overhead of maintaining multiple different microservice binaries—with their own configuration files, network endpoints, and serializable data formats—significantly slowed our development velocity.

More importantly, microservices severely impacted our ability to make cross-binary changes. It made us do things like flag-gate new features in each binary, evolve our data formats carefully, and maintain intimate knowledge of our rollout processes. Finally, having a predetermined number of specific microservices effectively froze our APIs; they became so difficult to change that it was easier to squeeze all of our changes into the existing APIs rather than evolve them.

As a result, we wished we had a single monolithic binary to work with. Monolithic binaries are easy to write: they use only language-native types and method calls. They are also easy to update: just edit the source code and re-deploy. They are easy to run locally or in a VM: simply execute the binary.

Service Weaver, is a framework that has the best of both worlds: the development velocity of a monolith, with the scalability, security, and fault-tolerance of microservices.

Service Weaver Overview

The core idea of Service Weaver is its modular monolith model. You write a single binary, using only language-native data structures and method calls. You organize your binary as a set of modules, called components, which are native types in the programming language. For example, here is a simple application written in Go using Service Weaver. It consists of a main() function and a single Adder component:
type Adder interface { Add(context.Context, int, int) (int, error) } type adder struct{ weaver.Implements[Adder] } func (adder) Add(_ context.Context, x, y int) (int, error) { return x + y, nil} func main() { ctx := context.Background() root := weaver.Init(ctx) adder, err := weaver.Get[Adder](root) sum, err := adder.Add(ctx, 1, 2) }
When running the above application, you can make a trivial configuration choice of whether to place the Adder component together with the main() function or to place it separately. When the Adder component is separate, the Service Weaver framework automatically translates the Add call into a cross-machine RPC; otherwise, the Add call remains a local method call.

To make a change to the above application, such as adding an unbounded number of arguments to the Add method, all you have to do is change the signature of Add, change its call-sites, and re-deploy your application. Service Weaver makes sure that the new version of main() communicates only with the new version of Adder, regardless of whether they are co-located or not. This behavior, combined with using language-native data structures and method calls, allows you to focus exclusively on writing your application logic, without worrying about the deployment topology and inter-service communication (e.g., there are no protos, stubs, or RPC channels in the code).

When it is time to run your application, Service Weaver allows you to run it anywhere—on your local desktop environment or on your local rack of machines or in the cloud—without any changes to your application code. This level of portability is achieved by a clear separation of concerns built into the Service Weaver framework. On one end, we have the programming framework, used for application development. On the other end, we have various deployer implementations, one per deployment environment.
Flow chart depicting Service Weaver Libraries deployer implementations across three separate platforms in one single iteration

This separation of concerns allows you to run your application locally in a single process via go run .; or run it on Google Cloud via weaver gke deploy; or enable and run it on other platforms. In all of these cases, you get the same application behavior without the need to modify or re-compile your application.

What’s in Service Weaver v0.1?

The v0.1 release of Service Weaver includes:

  • The core Go libraries used for writing your applications.
  • A number of deployers used for running your applications locally or on GKE.
  • A set of APIs that allow you to write your own deployers for any other platform.

All of the libraries are released under the Apache 2.0 license. Please be aware that we are likely to introduce breaking changes until version v1.0 is released.

Get Started and Get Involved

While Service Weaver is still in an early development stage, we would like to invite you to use it and share your feedback, thoughts, and contributions.

The easiest way to get started using Service Weaver is to follow the Step-By-Step instructions on our website. If you would like to contribute, please follow our contributor guidelines. To post a question or contact the team directly, use the Service Weaver mailing list.

The team is excited to host a Twitter Space with Kelsey Hightower on March 2nd, at 10am PST. Keep an eye out on the Service Weaver blog for the latest news, updates, and details on future events.

More Resources

  • Visit us at serviceweaver.dev to get the latest information about the project, such as getting started, tutorials, and blog posts.
  • Access one of our Service Weaver repositories on GitHub.

By Srdjan Petrovic and Garv Sawhney, on behalf of the Service Weaver team

Developer Journey – Women’s History Month: March 2023

Posted by Lyanne Alfaro, DevRel Program Manager, Google Developer Studio

In honor of Women’s History Month, it’s our pleasure to feature members across the Women Techmakers ecosystem for March’s Developer Journey profiles. These are community leaders who have explored, navigated and built using Google tools. They are active members of the broader Google Developers community.

In March, the WTM program will also celebrate International Women’s Day, centered on the theme “Dare To Be,” celebrating the courage and strength that this community demonstrates, made of thought leaders who are creating a world where women can thrive in tech. You can find more about the Women Techmakers program during IWD here.


Headshot of Ezinne Osuamadi smiling

Ezinne Osuamadi

Women Techmakers Mentor and Ambassador
Waldorf, Germany (A proud Nigerian!)
Software Developer/ Technical Product Manager
Twitter
Linkedln
Instagram

What Google tools have you used to build?

Android Studio, Firebase, Google Play Services, Google Analytics. I'm a mobile developer and recently started getting my hands on technical product management and agile product owner. The tools I use for development are Android as the framework and Android Studio as the integrated development environment.

Which tool has been your favorite to use? Why?

I would say Flutter. The Flutter toolkit has a layered architecture that allows for full customization. The fact that Flutter comes with fully-customizable widgets allows you to build native interfaces in minutes. I also love the fact that some of these widgets’ features like scrolling, navigation, icons, and fonts provide a full native performance on both iOS and Android. Flutter is one code base and it makes building mobile applications much easier. I don't have to build a separate app for Android, and another separate app for IOS. Another Flutter feature I like so much is the “hot reload.” It allows me to easily build UIs, add new features, and fix bugs faster. It also allows easy compilation of Flutter code to native ARM machine code using Dart native compilers.

Please share with us about something you’ve built in the past using Google tools.

The first app I built was for one of my former employers. It happened almost three years ago, and it was the first project I worked on when I started learning Flutter. I was super excited about it. It was a timesheet app targeted specifically for employees. The sole purpose of the app is for employees to be able to schedule tasks and also give a time slot to each task.

What advice would you give someone starting in their developer journey?

From my experience running an NGO called Ladies Crushing IT Africa and organizing a couple of tech events, I would say this: Don’t go into software development if you are not passionate or interested in it. Going into development because you think they pay developers well or because your friends are earning money from it is a wrong reason to start your development journey. A tech career journey should be about what you want to be in the future. Does it align with your future goals and objectives? How or what are strategies in achieving that path? Also note that the path to becoming a successful developer is a process. It is not all roses, and there are times when debugging will make it look difficult. But you should be resilient and diligent in making the most out of it when you encounter difficulties. It is always about continuous improvement. Never stop learning to keep yourself up to date with latest technologies and development tools.

 

Headshot of Patty O’Callaghan smiling

Patty O’Callaghan

GDG Glasgow and Women Techmakers Ambassador
Glasgow, Scotland
Tech Lead @ Charles River Laboratories
Twitter
Linkedln

What Google tools have you used to build?

I use the Chrome DevTools daily. I find them very helpful. I also enjoy working on projects using TensorFlow.JS and Firebase.

Which tool has been your favorite to use? Why?

I would have to say TensorFlow.JS and its pre-made models are my favorite. I enjoy the fact that I can build cool machine learning projects directly in the browser. Even developers unfamiliar with this technology can quickly build, train, and deploy machine learning models using just a few lines of code. Some kids at my code club have used TensorFlow.JS for amazing projects, like building class attendance applications using facial recognition, or a site that checks correct form while practicing karate at home, and another for studying with the help of an AI agent.

Please share with us about something you’ve built in the past using Google tools.

I've worked on several side-projects using TensorFlow.JS for my workshops. One of my favorites is an emotion recognition app, using the Teachable Machine. Additionally, for work, I used TF.JS to develop a machine learning solution that suggests taxonomies for articles based on their content. It analyzes over 30 taxonomies to find the best match for the given article.

What advice would you give someone starting in their developer journey?

First of all, focus on learning the fundamentals of programming. A strong foundation will benefit you in the long run. Practice coding regularly and find a mentor or a community to help you along the way. For example, contributing to an open-source project is an excellent way to learn. And remember: Making mistakes is a natural part of the learning process, so don't get discouraged if you encounter difficulties. Keep pushing forward!



Headshot of Alexis and David Snelling smiling

Alexis & David Snelling

Alexis – Women Techmakers Ambassador & Lead
Named as Top 10 Women founders to Watch in 2023 by Forbes Group
San Francisco, CA
CEO WeTransact.live
Twitter
Linkedln
Facebook
 

David – Google Developer Groups
San Francisco, CA
CTO WeTransact.live
Twitter
Linkedln
Facebook

What Google tools have you used to build?

Here’s just a few of the tools we’ve used:
  • Angular 15
  • Material Design
  • Google Cloud / Firebase
    • Authentication
    • Hosting
    • Firestore
    • Functions
    • Extensions
    • Storage
    • Machine Learning
  • PWA Standards
  • Chrome / DevTools
  • Android

Which tool has been your favorite to use? Why?

Firestore has been our favorite due to its scalability and real-time data capabilities, through websockets and triggers, the data flexibility, plus query capabilities. This is how we’ve built out our modern event-driven architecture to allow for a completely real-time application providing immediate data and collaboration across our entire white label application suite.

Please share with us about something you’ve built in the past using Google tools.

We built the WeTransact Innovation Platform: From Idea to ROI which offers a learning-based distributed social platform for learning, collaborating and presenting yourself and your innovations.

For customers, we’ve created a White Label SaaS Platform, licensed by universities, incubators, developer groups and any program looking to provide education, collaboration, and AI assisted auto generated presentation and communication tools. Our platform combines features similar to LinkedIn, Coursera, AngelList and Zoom in one simple and modern unified platform for communities to make collaboration & lifelong learning globally accessible to everyone. The WeTransact platform accelerates & scales your program’s impact to solve the world's biggest problems better together.

Here’s just a few other ways we’ve used Google tools:

What advice would you give someone starting in their developer journey?

There’s a few pieces of advice we’d offer! Among them is to start early. Find a friend who is already developing or shares your passion. Find an open source project that inspires you or represents something you're passionate about. Dig in, change stuff, break stuff and then learn why. Search is your best friend – use it to always question and reset your assumptions, learn new approaches, and practice not getting stuck in a “boilerplate” or “standard” solution to each problem. It’s not about memorizing – technology changes every day and you should too. Finally, know that it’s about the process and the journey, not the destination.