For more than a decade, we’ve been investing in Canada to become a go-to cloud partner for organizations across the country, from Vancouver to my hometown of St. John’s and every city in between. Whether they’re in financial services, media and entertainment, retail, or another industry, a rapidly growing number of Canada-based organizations are choosing Google Cloud to help them build applications better and faster, store data, and ultimately deliver awesome experiences to their own users.
To support our expanding customer base in Canada, we’re excited to announce a new Google Cloud Platform region coming to Toronto. We’re working constantly to bring you new cloud products and capabilities in Canada, and our goal is to allow you to access those services quickly and easily — wherever you might be in the country. That’s why we decided to build this new region in Toronto, complementing our existing one in Montréal, which marked Google Cloud’s official arrival in Canada when we opened it in 2018.
Like Montréal, the new region will have three zones, allowing organizations of all sizes and industries to distribute apps and storage to protect against service disruptions. It will also launch with our core portfolio of Google Cloud Platform products, including Compute Engine, App Engine, Google Kubernetes Engine, Bigtable, Spanner, and BigQuery.
And the benefits don’t stop there. The Toronto region will provide distributed, secure infrastructure to help you meet disaster recovery and compliance requirements—something our customers have been asking for, especially financial institutions, public sector organizations, e-commerce providers, and other businesses operating in highly regulated industries.
While we’re thrilled about this news, don’t take it from us. We asked some of our customers with Canadian roots for their take on the upcoming cloud region. Here’s what they had to say:
David Furlong, SVP Artificial Intelligence, Venture Capital and Blockchain, at Banque Nationale: “Paired with their existing Montréal region, Google Cloud’s Toronto region will benefit the Canadian financial industry, enabling highly regulated organizations to perform disaster recovery while meeting data residency requirements.”
Ken Pickering, CTO at Hopper, the popular travel booking app: “Having already collaborated closely with the Google Cloud team in Montréal, where we’re headquartered, we look forward to their Toronto expansion. Google Cloud services are allowing us to bring a lower-latency travel planning and booking service to our customers. The second Canada region will allow us to extend that experience to more people around the world.”
Andrew McCormack, CIO at Payments Canada, a national payment clearing and settlement system that uses Google Cloud solutions like Apigee to digitize and manage its hybrid cloud environment: “System performance and security are critical for us an organization that clears and settles hundreds of billions of dollars every day. Google’s new Toronto cloud region will help us continue to modernize our infrastructure, strengthen our resilience, and create a digital platform for innovation.”
Today, Google Cloud customers around the world are currently served by 22 cloud regions and 67 zones. When we complete it in 2021, Toronto—along with three additional cloud regions we announced today on the other side of the world, Delhi, Doha, and Melbourne — will be part of our worldwide network of secure and reliable infrastructure.
The beta channel has been updated to 81.0.4044.43for 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 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.
Stadia Games and Entertainment is setting out to change the way we play, enjoy and create video games. With Stadia, the creative possibilities are limitless. But we can’t build those experiences without a talented team of game designers, artists and storytellers. We started that journey with the opening of Stadia’s first original games studio in Montreal late last year. Today, we’re adding a new Stadia Games and Entertainment studio in Playa Vista, California, which will be led by an industry veteran, Shannon Studstill.
The new Playa Vista studio will focus on delivering exclusive games, using new gameplay mechanics, creative ways to play together and unique interaction models that we’re just starting to explore. While we’re not ready to share specific game plans yet, rest assured we are listening to what gamers want and adding our own Stadia twists to create new IP and experiences.
I’ve been a fan of Shannon’s for a long time, and have admired her award-winning work leading Sony’s Santa Monica Studio and the industry defining franchises like God of War that have won fans all over the world. She has an extensive background in product development and creative leadership, but most importantly, she’s a visionary who, as the Studio Director, will lead and inspire the Playa Vista teams. We’re thrilled to welcome her to the Stadia family!
Stadia is designed to be the one destination for all the ways we play. It’s key to bring on talent that not only has success in delivering the industry’s best content, but also has creative ideas around how to embrace this new and unique way to create.
Building a world-class studio piece-by-piece is a unique opportunity that you don't often get in the game industry.And we want to do it with you.
Think about how much you read on your phone every day: catching up on the news, scanning a new blog, finally reading the article that everyone is talking about. This may require reading a lot of text, which can be a barrier for people with visual or reading difficulties, or who simply need a little help getting through meatier articles.
With Google Assistant, your browser can now read web articles out loud. Whenever a web article is displayed on your browser in your Android phone, you can say, “Hey Google, read it” or “Hey Google, read this page” it will immediately read aloud the content of the web page. To help you follow along, your browser will automatically scroll the page and highlight words as they're read aloud. You can also alter the reading speed and choose from multiple voices. Speaking of which, the web pages are read aloud in expressive and natural voices, aiming to use the same intonation and rhythm that you'd use if you were reading it aloud yourself.
If the original content isn’t in your native language, Google Assistant can trigger your browser to read aloud in 42 languages. You can use the translation menu to select the desired language, and all pages will be automatically translated and read out in that language.
Websites don't need to do anything special to enable this functionality. Webmasters that prefer not to use this feature can use the nopagereadaloud tag. If you’re a developer, you can add the ability for Google Assistant to read aloud content in your mobile app using Actions on Google.
With this new experience, we hope to remove language barriers and help a wide variety of people access information from the web more easily.
On a clear, dark night, you can see a faint glowing band of billions of distant stars across the sky: the Milky Way. Parts of it are visible on moonless nights throughout the year, but the brightest and most photogenic region, near the constellation Sagittarius, appears above the horizon from spring to early fall.
A few weeks ago, Sagittarius returned to the early morning sky, rising in the east just before dawn—and now is the perfect time to photograph it. Thanks to the astrophotography features in Night Sight on Pixel 4, 3a and 3, you can capture it with your phone.
Before you head outside to catch the Milky Way, here are a few tips and tricks for taking breathtaking night time photos of your own.
Get out of town, and into the wilderness
The Milky Way isn’t very bright, so seeing and photographing it requires a dark night. Moonlight and light pollution from nearby cities tend to obscure it.
To observe the brightest part of the Milky Way during spring, try to find a location with no large city to the east, and pick a night where the moon isn’t visible in the early morning hours. The nights between the new moon and about three days before the next full moon are ideal. For early 2020, this includes today (March 4) through March 6, March 24 through April 4 and April 22 through May 4. Look for the Milky Way in the hour before the first light of dawn. Of course you’ll want to check the weather forecast to make sure that the stars won’t be hidden by clouds.
Do your research
You can utilize tools to help track the rise and set of the sun and moon that will help you find the best time for your photo shoot. A light pollution map helps you find places to capture the best shot, and star charts can help you find constellations and other interesting celestial objects (like the Andromeda Galaxy) so you know what you’re shooting.
Stay steady and settle in
Once you’ve found the perfect spot, open the Camera App on Pixel and switch to Night Sight, and either mount the phone on a tripod, or support it on a rock or anything else that won’t move. Whatever you do, don’t try to steady the phone with your hands. Once stable, your phone will display “Astrophotography on” in the viewfinder to confirm it will use long exposures to capture your photo (up to four minutes total on Pixel 4, or one minute on Pixel 3 and 3a, depending on how dark the environment is).
Get comfortable with the camera features
To ensure you get great photos, explore all of the different options available in the Camera App. Say, for example, you are in the middle of taking a picture, and a car’s headlights are about to appear in the frame; you can tap the shutter button to stop the exposure and keep the lights from ruining your shot. You will get a photo even if you stop early, but letting the exposure run to completion will produce a clearer image.
The viewfinder in the Google Camera App works at full moon light levels, but in even darker environments the on-screen image may become too dim and grainy to be useful. Try this quick fix: Point the phone in what you think is the right direction, then tap the shutter button. Soon after the exposure begins, the viewfinder will show a much clearer image than before, and that image will be updated every few seconds. This allows you to check and correct which way the phone is pointing. Wait for the next update to see the effect of your corrections. Once you’re satisfied with the composition, tap the shutter button a second time to stop the exposure. Then tap the shutter button once more to start a new exposure, and let it run to completion without touching the phone.
The phone will try to focus automatically, but autofocus can fail in extremely dark scenes. For landscape shots you may just want to set focus to “far” by tapping the down arrow next to the viewfinder to access the focus options. This will make sure that anything further away than about 15 feet will be sharp.
Venus above the Pacific Ocean about one hour after sunset at Point Reyes National Seashore in California, captured on Pixel 4.
Use moonlight and twilight to your advantage
Astrophotography mode isn’t only for taking pictures when it’s completely dark outside. It also takes impressive photos during nights with bright moonlight, or at dusk, when daylight is almost gone and the first stars have become visible.
No matter what time of day it is, spend a little extra time experimenting with the Google Camera App to find out what’s possible, and your photos will look great.
Aurora borealis near Kolari, Finland, on a night in February. Photo by Ingemar Eriksson, captured on Pixel 4.
Creating content your audience loves takes time, but making it profitable shouldn’t. That’s where Google AdSense comes in.
With AdSense, trusted advertisers show their ads on your site, generating revenue for you to keep creating great content and take your business to the next level. AdSense gets you the best of Google’s automation and is fully customizable. Plus, signing up is free and easy.
Join more than 2 million publishers who are already earning money from their sites with Google AdSense. Get started today!
Posted by Carrie J. Cai, Senior Research Scientist, Google Research and Philip J. Guo, Assistant Professor, UC San Diego
As machine learning (ML) increasingly impacts diverse stakeholders and social groups, it has become necessary for a broader range of developers — even those without formal ML training — to be able to adapt and apply ML to their own problems. In recent years, there have been many efforts to lower the barrier to machine learning, by abstracting complex model behavior into higher-level APIs. For instance, Google has been developing TensorFlow.js, an open-source framework that lets developers write ML code in JavaScript to run directly in web browsers. Despite the abundance of engineering work towards improving APIs, little is known about what non-ML software developers actually need to successfully adopt ML into their daily work practices. Specifically, what do they struggle with when trying modern ML frameworks, and what do they want these frameworks to provide?
In “Software Developers Learning Machine Learning: Motivations, Hurdles, and Desires,” which received a Best Paper Award at the IEEE conference on Visual Languages and Human-Centric Computing (VL/HCC), we share our research on these questions and report the results from a large-scale survey of 645 people who used TensorFlow.js. The vast majority of respondents were software or web developers, who were fairly new to machine learning and usually did not use ML as part of their primary job. We examined the hurdles experienced by developers when using ML frameworks and explored the features and tools that they felt would best assist in their adoption of these frameworks into their programming workflows.
What Do Developers Struggle With Most When Using ML Frameworks? Interestingly, by far the most common challenge reported by developers was not the lack of a clear API, but rather their own lack of conceptual understanding of ML, which hindered their ability to successfully use ML frameworks. These hurdles ranged from the initial stages of picking a good problem to which they could apply TensorFlow.js (e.g., survey respondents reported not knowing “what to apply ML to, where ML succeeds, where it sucks”), to creating the architecture of a neural net (e.g., “how many units [do] I have to put in when adding layers to the model?”) and knowing how to set and tune parameters during model training (e.g., “deciding what optimizers, loss functions to use”). Without a conceptual understanding of how different parameters affect outcomes, developers often felt overwhelmed by the seemingly infinite space of parameters to tune when debugging ML models.
Without sufficient conceptual support, developers also found it hard to transfer lessons learned from “hello world” API tutorials to their own real-world problems. While API tutorials provide syntax for implementing specific models (e.g., classifying MNIST digits), they typically don't provide the underlying conceptual scaffolding necessary to generalize beyond that specific problem.
Developers often attributed these challenges to their own lack of experience in advanced mathematics. Ironically, despite the abundance of non-experts tinkering with ML frameworks nowadays, many felt that ML frameworks were intended for specialists with advanced training in linear algebra and calculus, and thus not meant for general software developers or product managers. This semblance of imposter syndrome may be fueled by the prevalence of esoteric mathematical terminology in API documentation, which may unintentionally give the impression that an advanced math degree is necessary for even practical integration of ML into software projects. Though math training is indeed beneficial, the ability to grasp and apply practical concepts (e.g., a model’s learning rate) to real-world problems does not require an advanced math degree.
What Do Developers Want From ML Frameworks? Developers who responded to our survey wanted ML frameworks to teach them not only how to use the API, but also the unspoken idioms that would help them to effectively apply the framework to their own problems.
Pre-made Models with Explicit Support for Modification A common desire was to have access to libraries of canonical ML models, so that they could modify an existing template rather than creating new ones from scratch. Currently, pre-trained models are being made more widely available in many ML platforms, including TensorFlow.js. However, in their current form, these models do not provide explicit support for novice consumption. For example, in our survey, developers reported substantial hurdles transferring and modifying existing model examples to their own use cases. Thus, the provision of pre-made ML models should also be coupled with explicit support for modification.
Synthesize ML Best Practices into Just-in-Time Hints Developers also wished frameworks could provide ML best practices, i.e., practical tips and tricks that they could use when designing or debugging models. While ML experts may acquire heuristics and go-to strategies through years of dedicated trial and error, the mere decision overhead of “which parameter should I try tuning first?” can be overwhelming for developers who aren't ML experts. To help narrow this broad space of decision possibilities, ML frameworks could embed tips on best practices directly into the programming workflow. Currently, visualizations like TensorBoard and tfjs-vis make it possible to help see what's going on inside of their models.
Coupling these with just-in-time strategic pointers, such as whether to adapt a pre-trained model or to build one from scratch, or diagnostic checks, like practical tips to “decrease learning rate” if the model is not converging, could help users acquire and make use of practical strategies. These tips could serve as an intermediate scaffolding layer that helps demystify the math theory underlying ML into developer-friendly terms.
Support for Learning-by-Doing Finally, even though ML frameworks are not traditional learning platforms, software developers are indeed treating them as lightweight vehicles for learning-by-doing. For example, one survey respondent appreciated when conceptual support was tightly interwoven into the framework, rather than being a separate resource: “...the small code demos that you can edit and run right there. Really helps basic understanding.” Another explained that “I prefer learning by doing, so I would like to see more tutorials, examples” embedded into ML frameworks.Some found it difficult to take a formal online course, and would rather learn in bite-sized pieces through hands-on tinkering: “Due to the rest of life, I have to fit learning into small 5-15 minute blocks.”
Given these desires to learn-by-doing, ML frameworks may need to more clearly distinguish between a spectrum of resources aimed at different levels of expertise. Although many frameworks already have “hello world” tutorials, to properly set expectations these frameworks could more explicitly differentiate between API (syntax-specific) onboarding and ML (conceptual) onboarding.
Looking Forward Ultimately, as the frontiers of ML are still evolving, providing practical, conceptual tips for software developers and creating a shared reservoir of community-curated best practices can benefit ML experts and novices alike. Hopefully, these research findings pave the way for more user-centric designs of future ML frameworks.
Acknowledgements This work would not have been possible without Yannick Assogba, Sandeep Gupta, Lauren Hannah-Murphy, Michael Terry, Ann Yuan, Nikhil Thorat, Daniel Smilkov, Martin Wattenberg, Fernanda Viegas, and members of PAIR and TensorFlow.js.
Posted by Carrie J. Cai, Senior Research Scientist, Google Research and Philip J. Guo, Assistant Professor, UC San Diego
As machine learning (ML) increasingly impacts diverse stakeholders and social groups, it has become necessary for a broader range of developers — even those without formal ML training — to be able to adapt and apply ML to their own problems. In recent years, there have been many efforts to lower the barrier to machine learning, by abstracting complex model behavior into higher-level APIs. For instance, Google has been developing TensorFlow.js, an open-source framework that lets developers write ML code in JavaScript to run directly in web browsers. Despite the abundance of engineering work towards improving APIs, little is known about what non-ML software developers actually need to successfully adopt ML into their daily work practices. Specifically, what do they struggle with when trying modern ML frameworks, and what do they want these frameworks to provide?
In “Software Developers Learning Machine Learning: Motivations, Hurdles, and Desires,” which received a Best Paper Award at the IEEE conference on Visual Languages and Human-Centric Computing (VL/HCC), we share our research on these questions and report the results from a large-scale survey of 645 people who used TensorFlow.js. The vast majority of respondents were software or web developers, who were fairly new to machine learning and usually did not use ML as part of their primary job. We examined the hurdles experienced by developers when using ML frameworks and explored the features and tools that they felt would best assist in their adoption of these frameworks into their programming workflows.
What Do Developers Struggle With Most When Using ML Frameworks? Interestingly, by far the most common challenge reported by developers was not the lack of a clear API, but rather their own lack of conceptual understanding of ML, which hindered their ability to successfully use ML frameworks. These hurdles ranged from the initial stages of picking a good problem to which they could apply TensorFlow.js (e.g., survey respondents reported not knowing “what to apply ML to, where ML succeeds, where it sucks”), to creating the architecture of a neural net (e.g., “how many units [do] I have to put in when adding layers to the model?”) and knowing how to set and tune parameters during model training (e.g., “deciding what optimizers, loss functions to use”). Without a conceptual understanding of how different parameters affect outcomes, developers often felt overwhelmed by the seemingly infinite space of parameters to tune when debugging ML models.
Without sufficient conceptual support, developers also found it hard to transfer lessons learned from “hello world” API tutorials to their own real-world problems. While API tutorials provide syntax for implementing specific models (e.g., classifying MNIST digits), they typically don't provide the underlying conceptual scaffolding necessary to generalize beyond that specific problem.
Developers often attributed these challenges to their own lack of experience in advanced mathematics. Ironically, despite the abundance of non-experts tinkering with ML frameworks nowadays, many felt that ML frameworks were intended for specialists with advanced training in linear algebra and calculus, and thus not meant for general software developers or product managers. This semblance of imposter syndrome may be fueled by the prevalence of esoteric mathematical terminology in API documentation, which may unintentionally give the impression that an advanced math degree is necessary for even practical integration of ML into software projects. Though math training is indeed beneficial, the ability to grasp and apply practical concepts (e.g., a model’s learning rate) to real-world problems does not require an advanced math degree.
What Do Developers Want From ML Frameworks? Developers who responded to our survey wanted ML frameworks to teach them not only how to use the API, but also the unspoken idioms that would help them to effectively apply the framework to their own problems.
Pre-made Models with Explicit Support for Modification A common desire was to have access to libraries of canonical ML models, so that they could modify an existing template rather than creating new ones from scratch. Currently, pre-trained models are being made more widely available in many ML platforms, including TensorFlow.js. However, in their current form, these models do not provide explicit support for novice consumption. For example, in our survey, developers reported substantial hurdles transferring and modifying existing model examples to their own use cases. Thus, the provision of pre-made ML models should also be coupled with explicit support for modification.
Synthesize ML Best Practices into Just-in-Time Hints Developers also wished frameworks could provide ML best practices, i.e., practical tips and tricks that they could use when designing or debugging models. While ML experts may acquire heuristics and go-to strategies through years of dedicated trial and error, the mere decision overhead of “which parameter should I try tuning first?” can be overwhelming for developers who aren't ML experts. To help narrow this broad space of decision possibilities, ML frameworks could embed tips on best practices directly into the programming workflow. Currently, visualizations like TensorBoard and tfjs-vis make it possible to help see what's going on inside of their models.
Coupling these with just-in-time strategic pointers, such as whether to adapt a pre-trained model or to build one from scratch, or diagnostic checks, like practical tips to “decrease learning rate” if the model is not converging, could help users acquire and make use of practical strategies. These tips could serve as an intermediate scaffolding layer that helps demystify the math theory underlying ML into developer-friendly terms.
Support for Learning-by-Doing Finally, even though ML frameworks are not traditional learning platforms, software developers are indeed treating them as lightweight vehicles for learning-by-doing. For example, one survey respondent appreciated when conceptual support was tightly interwoven into the framework, rather than being a separate resource: “...the small code demos that you can edit and run right there. Really helps basic understanding.” Another explained that “I prefer learning by doing, so I would like to see more tutorials, examples” embedded into ML frameworks.Some found it difficult to take a formal online course, and would rather learn in bite-sized pieces through hands-on tinkering: “Due to the rest of life, I have to fit learning into small 5-15 minute blocks.”
Given these desires to learn-by-doing, ML frameworks may need to more clearly distinguish between a spectrum of resources aimed at different levels of expertise. Although many frameworks already have “hello world” tutorials, to properly set expectations these frameworks could more explicitly differentiate between API (syntax-specific) onboarding and ML (conceptual) onboarding.
Looking Forward Ultimately, as the frontiers of ML are still evolving, providing practical, conceptual tips for software developers and creating a shared reservoir of community-curated best practices can benefit ML experts and novices alike. Hopefully, these research findings pave the way for more user-centric designs of future ML frameworks.
Acknowledgements This work would not have been possible without Yannick Assogba, Sandeep Gupta, Lauren Hannah-Murphy, Michael Terry, Ann Yuan, Nikhil Thorat, Daniel Smilkov, Martin Wattenberg, Fernanda Viegas, and members of PAIR and TensorFlow.js.
Posted by Carrie J. Cai, Senior Research Scientist, Google Research and Philip J. Guo, Assistant Professor, UC San Diego
As machine learning (ML) increasingly impacts diverse stakeholders and social groups, it has become necessary for a broader range of developers — even those without formal ML training — to be able to adapt and apply ML to their own problems. In recent years, there have been many efforts to lower the barrier to machine learning, by abstracting complex model behavior into higher-level APIs. For instance, Google has been developing TensorFlow.js, an open-source framework that lets developers write ML code in JavaScript to run directly in web browsers. Despite the abundance of engineering work towards improving APIs, little is known about what non-ML software developers actually need to successfully adopt ML into their daily work practices. Specifically, what do they struggle with when trying modern ML frameworks, and what do they want these frameworks to provide?
In “Software Developers Learning Machine Learning: Motivations, Hurdles, and Desires,” which received a Best Paper Award at the IEEE conference on Visual Languages and Human-Centric Computing (VL/HCC), we share our research on these questions and report the results from a large-scale survey of 645 people who used TensorFlow.js. The vast majority of respondents were software or web developers, who were fairly new to machine learning and usually did not use ML as part of their primary job. We examined the hurdles experienced by developers when using ML frameworks and explored the features and tools that they felt would best assist in their adoption of these frameworks into their programming workflows.
What Do Developers Struggle With Most When Using ML Frameworks? Interestingly, by far the most common challenge reported by developers was not the lack of a clear API, but rather their own lack of conceptual understanding of ML, which hindered their ability to successfully use ML frameworks. These hurdles ranged from the initial stages of picking a good problem to which they could apply TensorFlow.js (e.g., survey respondents reported not knowing “what to apply ML to, where ML succeeds, where it sucks”), to creating the architecture of a neural net (e.g., “how many units [do] I have to put in when adding layers to the model?”) and knowing how to set and tune parameters during model training (e.g., “deciding what optimizers, loss functions to use”). Without a conceptual understanding of how different parameters affect outcomes, developers often felt overwhelmed by the seemingly infinite space of parameters to tune when debugging ML models.
Without sufficient conceptual support, developers also found it hard to transfer lessons learned from “hello world” API tutorials to their own real-world problems. While API tutorials provide syntax for implementing specific models (e.g., classifying MNIST digits), they typically don't provide the underlying conceptual scaffolding necessary to generalize beyond that specific problem.
Developers often attributed these challenges to their own lack of experience in advanced mathematics. Ironically, despite the abundance of non-experts tinkering with ML frameworks nowadays, many felt that ML frameworks were intended for specialists with advanced training in linear algebra and calculus, and thus not meant for general software developers or product managers. This semblance of imposter syndrome may be fueled by the prevalence of esoteric mathematical terminology in API documentation, which may unintentionally give the impression that an advanced math degree is necessary for even practical integration of ML into software projects. Though math training is indeed beneficial, the ability to grasp and apply practical concepts (e.g., a model’s learning rate) to real-world problems does not require an advanced math degree.
What Do Developers Want From ML Frameworks? Developers who responded to our survey wanted ML frameworks to teach them not only how to use the API, but also the unspoken idioms that would help them to effectively apply the framework to their own problems.
Pre-made Models with Explicit Support for Modification A common desire was to have access to libraries of canonical ML models, so that they could modify an existing template rather than creating new ones from scratch. Currently, pre-trained models are being made more widely available in many ML platforms, including TensorFlow.js. However, in their current form, these models do not provide explicit support for novice consumption. For example, in our survey, developers reported substantial hurdles transferring and modifying existing model examples to their own use cases. Thus, the provision of pre-made ML models should also be coupled with explicit support for modification.
Synthesize ML Best Practices into Just-in-Time Hints Developers also wished frameworks could provide ML best practices, i.e., practical tips and tricks that they could use when designing or debugging models. While ML experts may acquire heuristics and go-to strategies through years of dedicated trial and error, the mere decision overhead of “which parameter should I try tuning first?” can be overwhelming for developers who aren't ML experts. To help narrow this broad space of decision possibilities, ML frameworks could embed tips on best practices directly into the programming workflow. Currently, visualizations like TensorBoard and tfjs-vis make it possible to help see what's going on inside of their models.
Coupling these with just-in-time strategic pointers, such as whether to adapt a pre-trained model or to build one from scratch, or diagnostic checks, like practical tips to “decrease learning rate” if the model is not converging, could help users acquire and make use of practical strategies. These tips could serve as an intermediate scaffolding layer that helps demystify the math theory underlying ML into developer-friendly terms.
Support for Learning-by-Doing Finally, even though ML frameworks are not traditional learning platforms, software developers are indeed treating them as lightweight vehicles for learning-by-doing. For example, one survey respondent appreciated when conceptual support was tightly interwoven into the framework, rather than being a separate resource: “...the small code demos that you can edit and run right there. Really helps basic understanding.” Another explained that “I prefer learning by doing, so I would like to see more tutorials, examples” embedded into ML frameworks.Some found it difficult to take a formal online course, and would rather learn in bite-sized pieces through hands-on tinkering: “Due to the rest of life, I have to fit learning into small 5-15 minute blocks.”
Given these desires to learn-by-doing, ML frameworks may need to more clearly distinguish between a spectrum of resources aimed at different levels of expertise. Although many frameworks already have “hello world” tutorials, to properly set expectations these frameworks could more explicitly differentiate between API (syntax-specific) onboarding and ML (conceptual) onboarding.
Looking Forward Ultimately, as the frontiers of ML are still evolving, providing practical, conceptual tips for software developers and creating a shared reservoir of community-curated best practices can benefit ML experts and novices alike. Hopefully, these research findings pave the way for more user-centric designs of future ML frameworks.
Acknowledgements This work would not have been possible without Yannick Assogba, Sandeep Gupta, Lauren Hannah-Murphy, Michael Terry, Ann Yuan, Nikhil Thorat, Daniel Smilkov, Martin Wattenberg, Fernanda Viegas, and members of PAIR and TensorFlow.js.
Editor’s Note: Guest authors Diego Moreno and Sophia Deng (@sophdeng) are from Gigster, a firm that builds dynamic teams made of top global talent who create industry-changing custom software.
Prelude: Data input & management … three general choices
Google Cloud provides multiple services for gathering and managing data. Google Forms paired with Google Sheets are quite popular as they require no engineering resources while being incredibly powerful, providing storage of up to 5 million rows of data and built-in analytics for small team projects.
At the other end of the spectrum, to support a high volume of users or data, Google Cloud provides advanced serverless platforms like Google App Engine (web app-hosting) and Google Cloud Functions (function/service-hosting) that can use Google Cloud Firestore for fast and scalable data storage. These are perfect for professional engineering teams that need autoscaling to respond to any level of user traffic and data input. Such apps can also be packaged into a container and deployed serverlessly on Google Cloud Run.
However, it's quite possible your needs are right in-between. Today, we're happy to present the Gigster story and their innovative use of Google Apps Script—a highly-accessible service conventionally relegated to simple macro and add-on development, but which Gigster used to its advantage, building robust systems to transform their internal operations. Apps Script is also serverless, meaning Gigster didn't have to manage any servers for their application nor did they need to find a place to host its source code.
The Gigster story
Gigster enables distributed teams of software engineers, product managers and designers to build software applications for enterprise clients. Over the past five years, Gigster has delivered thousands of projects, all with distributed software teams. Our group, the Gigster Staffing Operations Team, is responsible for assembling these teams from Gigster’s network of over 1,000 freelancers.
Two years ago, our team began building custom software to automate the multi-stage and highly manual team staffing process. Building internal software has allowed the same-size Staffing Operations Team (3 members!) to enjoy a 60x reduction in time spent staffing each role.
The Apps Script ecosystem has emerged as the most critical component in our toolkit for building this internal software, due to its versatility and ease of deployment. We want to share how one piece of the staffing process has evolved to become more powerful over time thanks to Apps Script. Ultimately, we hope that sharing this journey enables all types of teams to build their own tools and unlock new possibilities.
End-to-end automation in Google Sheets
Staffing is an operationally intensive procedure. Just finding willing and able candidates requires numerous steps:
Gathering and formatting customer requirements.
Communicating with candidates through multiple channels.
Logging candidate responses.
Processing paperwork for placement
To add complexity, many of these steps require working with different third-party applications. For awhile, we performed every step manually, tracking every piece of data generated in one central Sheet (the “Staffing Broadcast Google Sheet”). At a certain point, this back-and-forth work to log data from numerous applications became unsustainable. Although we leveraged Google Sheets features like Data Validation rules and filters, the Staffing Broadcast Sheet could not alleviate the high degree of manual processes that were required of the team.
The centralized Staffing Broadcast Google Sheet provided organization, but required a high degree of manual entry for tracking candidate decisions.
The key transformation was integrating Sheets data with third-party APIs via Apps Script. This enabled us to cut out the most time-consuming operations. We no longer had to flip between applications to message candidates, wait for their replies, and then manually track responses.
To interact with these APIs, we built a user interface directly into the Staffing Broadcast Google Sheet. By introducing an information module, as well as drop-down lists and buttons, we were able to define a small set of manual actions versus the much wider list of tasks the tool would perform automatically across multiple applications.
By integrating Google Apps Script with third-party APIs and creating a user interface, we evolved the Staffing Broadcast Tool to centralize and automate almost every step of the staffing process.
doPost() is the key function in our staffing tool that facilitates third-party services triggering our Apps Script automations. Below is a snippet of how we listened to candidates' responses from a third-party messaging application. In this case, queueing the third-party message in a Google Sheet so it can be processed with improved error-handling.
/** * Receive POST requests and record to queue. */ doPost(e) { var payload = e.postData.contents; SpreadsheetApp.openById(SPREADSHEET_ID) .getSheetByName("Unprocessed") .appendRow([payload]); return ContentService.createTextOutput(""); // Return 200 }
Almost all manual work associated with finding candidates was automated through the combination of integrations with third-party APIs and having a user interface to perform a small, defined set of actions. Our team’s day-to-day became shockingly simple: select candidates to receive messages within the Staffing Broadcast Tool, then click the “Send Broadcast” button. That’s it. The tool handled everything else.
Leveraging Sheets as our foundation, we fundamentally transformed our spreadsheet into a custom software application. The spreadsheet went from a partially automated datastore to a tool that provided an end-to-end automated solution, requiring only the click of a few buttons to execute.
Evolution into a standalone application
While satisfied, we understood that having our application live in Google Sheets had its limitations, namely, it was difficult for multiple team members to simultaneously use the tool. Using doGet(), the sibling to doPost(), we began building an HTML frontend to the Staffing Broadcast Tool. In addition to resolving difficulties related to multiple users being in a spreadsheet, it also allowed us to build an easier-to-use and more responsive tool by leveraging Bootstrap & jQuery.
Having multiple users in a single Google Sheet can create conflicts, but Apps Script allowed us to build a responsive web app leveraging common libraries like Bootstrap & jQuery that eliminated those problems while providing an improved user experience.
When other teams at Gigster got wind of what we built, it was easy to grant access to others beyond the Staffing Operations Team. Since Apps Script is part of the G Suite developer ecosystem, we relied on Google’s security policies to help deploy our tools to larger audiences.
While this can be done through Google’s conventional sharing tools, it can also be done with built-in Apps Script functions like Session.getActiveUser() that allow us to restrict access to specific Google users. In our case, those within our organization plus a few select users.
To this day, we continue to use this third version of the Staffing Broadcast Tool in our daily operations as it supports 100% of all client projects at Gigster.
Conclusion
By fundamentally transforming the Staffing Broadcast Tool with Apps Script, Gigster’s Staffing Operations Team increased its efficiency while supporting the growth of our company. Inspired by these business benefits, we applied this application-building approach using Apps Script for multiple tools, including candidate searching, new user onboarding, and countless automations.
Our team’s psychological shift about how we view what we are capable of, especially as a non-engineering team, has been the most valuable part of this journey. By leveraging an already familiar ecosystem to build our own software, we have freed team members to become more self-sufficient and valuable to our customers.
To get started on your Apps Script journey, we recommend you check out the Apps Script Fundamentals playlist and the official documentation. And if you're a freelancer looking to build software applications for clients, we’re always looking for talented software engineers, product managers or designers to join Gigster’s Talent Network.
Thank you to Sandrine Bitton, the third member of the Staffing Operations Team, for all her help in the development of the Staffing Broadcast Tool.
