What is black and white and read all over?

Noto emoji, a new black and white emoji font with less color, may gain us more in the long run

Posted by Jennifer Daniel, Creative Director – Emoji & Expression

Seven different black and white emojis in 5 collumns: cat, donut, chicken, flower, sheep, mouse, donut, doll 

In 1999 — back when Snake 🐍 was the best thing about your phone 📱 — there were three phone carriers in Japan 🗾 . On these phones were tiny, beautiful pictures called emoji (meaning “picture” and “character” in Japanese 🥰). These 176 images were very simple — think 8-bit tech — and as a result were exquisitely abstract and tremendously useful when texting Twenty years later 👶🕛🕐🕑🕒🕓🕔🕕🕖🕗🕘🕙🕚🧓, emoji are a global phenomenon 🌎. Now, our phones have fancy retina screens and somewhere along the way an important part of what made emoji so handy was left by the wayside: their simplicity. That’s why we’ve created a new emoji font: a monochrome Noto Emoji (a black and white companion to Noto Emoji Color).

Noto Emoji works like any other font you might use: You can change any character’s color, size and weight. Download it and give it a whirl.

Noto Emoji webpage

What’s old is new again 🔙

Over time, emoji have become more detailed. Instead of representing broad concepts there has been a trend to design emoji to be hyper realistic. This wouldn’t be a problem except skeuomorphism’s specificity has resulted in the exclusion of other similar concepts in your keyboard. Today we have “💃” … but what about other types of dance? Hula dancing? Belly dancing? Salsa dancing? Boogie woogie? By removing as much detail as possible, emoji could be more flexible, representing the idea of something instead of specifically what is in front of you (that … is what your camera is for 😂).

Example of Noto Emoji cycling through different customizations like font color, size, and variable weights 

We also want to make sure emoji keep up with platform technology. We’ve got dark mode … we’ve got light mode … and now you can change the color of your emoji font so it can operate with the same dynamism as your operating system. Noto Emoji is also a variable font — opt for a “light” grade if it appears small 💪 or “bold” if you want them to have some weight. 💪 .

When translating our color emoji to black and white: some details can be removed, others will need to be completely redrawn. 

New designs, fewer details

To design something simple seems like it would be … well, simple … but it’s deceptively complex 😅

At first the approach seemed obvious — simply redraw the Noto Emoji Color designs in black and white. They are iconic, they will be legible. Done deal. Easy peasy, lemon squeezy. Not so fast. The removal of color is no trivial task. Take for example: Flags.

four flags in color - Sweeden, Denmark, USA, Brazil. Then four flags in black and white - SE, DK, US, BR.

You can’t simply convert flags into black and white. You wouldn’t be able to tell the difference between Finland and Sweden. You could redraw the flags but that puts them at risk of being incorrect. Instead, we leveraged the ISO’s country codes. These sequences of letters are unique and represent each country. As a result, black and white flags have a much more contemporary aesthetic — kind of like bumper stickers 😜.

Let’s also take a look at the process involved to redesign the people emoji. For some characters, color is baked into the concept (like skin tone or hair color). It simply didn’t look right to replace color with hash marks or polka dots. And that my dear is how the blobs came back. Say hello (again) to our little friends.

Early sketch as we explored black and white designs

Likable. Nostalgic. Relatable without maintaining a distinction between genders. Google’s blob emoji were really something special. Cute, squishy, and remarkably friendly. We were able to bring back a little bit of what made them special while simultaneously discarding the parts that weren’t working. Most notably, the blobs’ facial expressions were wildly inconsistent but that was very easily fixed in black and white mode. It’s important emoji work cross-platform. The real world is not black and white but in emoji land we can finally have our favorite little dancer back 💃.

So here we are today, dancing into the future with our favorite new emoji font. We can’t wait to see how you use it. Visit Google Fonts to download or embed onto your website. Happy emoji-ing! 🐒🐒🎉🐬

AWS adds new management features for EC2 key pairs

Starting today, AWS customers have access to additional features to manage their EC2 key pairs. Customers can view the creation date and public key material for existing and new key pairs created using EC2 key pairs. Customers will also be able to create ED25519 key pairs in ppk format in addition to pem format and create key pairs using CloudFormation templates.

Amazon RDS for PostgreSQL now supports M6i and R6i instances with new instance sizes up to 128 vCPUs and 1,024 GiB RAM

Amazon Relational Database Service (Amazon RDS) for PostgreSQL, version 11 and higher, now supports M6i and R6i instances. M6i instances are the 6th generation of Amazon EC2 x86-based General Purpose compute instances, designed to provide a balance of compute, memory, storage, and network resources. R6i instances are the 6th generation of Amazon EC2 memory optimized instances, designed for memory-intensive workloads. Both M6i and R6i instances are built on the AWS Nitro System, a combination of dedicated hardware and lightweight hypervisor, which delivers practically all of the compute and memory resources of the host hardware to your instances.

How can App Engine users take advantage of Cloud Functions?

Posted by Wesley Chun (@wescpy), Developer Advocate, Google Cloud

Introduction

Recently, we discussed containerizing App Engine apps for Cloud Run, with or without Docker. But what about Cloud Functions… can App Engine users take advantage of that platform somehow? Back in the day, App Engine was always the right decision, because it was the only option. With Cloud Functions and Cloud Run joining in the serverless product suite, that’s no longer the case.

Back when App Engine was the only choice, it was selected to host small, single-function apps. Yes, when it was the only option. Other developers have created huge monolithic apps for App Engine as well… because it was also the only option. Fast forward to today where code follows more service-oriented or event-driven architectures. Small apps can be moved to Cloud Functions to simplify the code and deployments while large apps could be split into smaller components, each running on Cloud Functions.

Refactoring App Engine apps for Cloud Functions

Small, single-function apps can be seen as a microservice, an API endpoint “that does something,” or serve some utility likely called as a result of some event in a larger multi-tiered application, say to update a database row or send a customer email message. App Engine apps require some kind web framework and routing mechanism while Cloud Function equivalents can be freed from much of those requirements. Refactoring these types of App Engine apps for Cloud Functions will like require less overhead, helps ease maintenance, and allow for common components to be shared across applications.

Large, monolithic applications are often made up of multiple pieces of functionality bundled together in one big package, such as requisitioning a new piece of equipment, opening a customer order, authenticating users, processing payments, performing administrative tasks, and so on. By breaking this monolith up into multiple microservices into individual functions, each component can then be reused in other apps, maintenance is eased because software bugs will identify code closer to their root origins, and developers won’t step on each others’ toes.

Migration to Cloud Functions

In this latest episode of Serverless Migration Station, a Serverless Expeditions mini-series focused on modernizing serverless apps, we take a closer look at this product crossover, covering how to migrate App Engine code to Cloud Functions. There are several steps you need to take to prepare your code for Cloud Functions:

  • Divest from legacy App Engine “bundled services,” e.g., Datastore, Taskqueue, Memcache, Blobstore, etc.
  • Cloud Functions supports modern runtimes; upgrade to Python 3, Java 11, or PHP 7
  • If your app is a monolith, break it up into multiple independent functions. (You can also keep a monolith together and containerize it for Cloud Run as an alternative.)
  • Make appropriate application updates to support Cloud Functions

    The first three bullets are outside the scope of this video and its codelab, so we’ll focus on the last one. The changes needed for your app include the following:

    1. Remove unneeded and/or unsupported configuration
    2. Remove use of the web framework and supporting routing code
    3. For each of your functions, assign an appropriate name and install the request object it will receive when it is called.

    Regarding the last point, note that you can have multiple “endpoints” coming into a single function which processes the request path, calling other functions to handle those routes. If you have many functions in your app, separate functions for every endpoint becomes unwieldy; if large enough, your app may be more suited for Cloud Run. The sample app in this video and corresponding code sample only has one function, so having a single endpoint for that function works perfectly fine here.

    This migration series focuses on our earliest users, starting with Python 2. Regarding the first point, the app.yaml file is deleted. Next, almost all Flask resources are removed except for the template renderer (the app still needs to output the same HTML as the original App Engine app). All app routes are removed, and there’s no instantiation of the Flask app object. Finally for the last step, the main function is renamed more appropriately to visitme() along with a request object parameter.

    This “migration module” starts with the (Python 3 version of the) Module 2 sample app, applies the steps above, and arrives at the migrated Module 11 app. Implementing those required changes is illustrated by this code “diff:”

    Migration of sample app to Cloud Functions

    Next steps

    If you’re interested in trying this migration on your own, feel free to try the corresponding codelab which leads you step-by-step through this exercise and use the video for additional guidance.

    All migration modules, their videos (when published), codelab tutorials, START and FINISH code, etc., can be found in the migration repo. We hope to also one day cover other legacy runtimes like Java 8 as well as content for the next-generation Cloud Functions service, so stay tuned. If you’re curious whether it’s possible to write apps that can run on App Engine, Cloud Functions, or Cloud Run with no code changes at all, the answer is yes. Hope this content is useful for your consideration when modernizing your own serverless applications!

Amazon Chime SDK offers API endpoints for media pipeline in Oregon, Frankfurt, and Singapore

Amazon Chime SDK lets developers add intelligent real-time audio, video, screen share, and messaging to their web applications. Media Pipelines allow developers to capture the contents of Amazon Chime SDK WebRTC media sessions to the Amazon Simple Storage Service (Amazon S3) bucket of their choice. Starting today, the Amazon Chime SDK now has media pipeline API endpoints in US West (Oregon), Europe (Frankfurt), and Asia Pacific (Singapore) AWS Regions.

AWS Snow launches Large Data Migration Manager for planning and managing large data migrations from your premises to AWS

Today, AWS Snow Family launches Large Data Migration Manager, a new feature that enables you to plan, track, and manage your large data migrations when using multiple Snowball Edge service products. You can now easily plan and monitor your jobs from a minimum of 500 Terrabytes to petabyte scale data migrations. Using Large Data Migration Manager eliminates the need for you to manually track all of your Snow jobs and the status of their data ingestion.  

Amazon RDS for Postgres now supports M6i and R6i instances with new instance sizes up to 128 vCPUs and 1,024 GiB RAM

Amazon Relational Database Service (Amazon RDS) for Postgres, version 11 and higher, now supports M6i and R6i instances. M6i instances are the 6th generation of Amazon EC2 x86-based General Purpose compute instances, designed to provide a balance of compute, memory, storage, and network resources. R6i instances are the 6th generation of Amazon EC2 memory optimized instances, designed for memory-intensive workloads. Both M6i and R6i instances are built on the AWS Nitro System, a combination of dedicated hardware and lightweight hypervisor, which delivers practically all of the compute and memory resources of the host hardware to your instances.

How GDSC students are using their skills to support communities in Ukraine

Posted by Laura Cincera, Program Manager Google Developer Student Clubs, Europe

Revealing character in moments of crisis

The conflict in Ukraine is a humanitarian crisis that presents complex challenges. During this time of uncertainty, communities of student developers are demonstrating extraordinary leadership skills and empathy as they come together to support those affected by the ongoing situation. Student Patricijia Čerkaitė and her Google Developer Student Club (GDSC) community at the Eindhoven University of Technology in the Netherlands organized Code4Ukraine, an international hackathon that brought diverse groups of over 80 student developers together on March 3-4, 2022, to develop technology solutions to support people affected by the conflict in Ukraine.

Even far from the conflict in the Netherlands, they felt compelled to make an impact. “I have relatives in Ukraine; they live in Crimea,” says Patricijia. “In my childhood, I used to spend summer holidays there, eating ice cream and swimming in the Black Sea.”

Patricijia sitting at desk in black chair looking back and smiling

Patricijia working on the details for Code4Ukraine.

Rushing to help others in need with technology

Time was of the essence. The organizing team in Eindhoven contacted other students, connected with communities near and far, and sprang into action. The team invited Ukrainian Google Developer Expert Artem Nikulchenko to share his technology knowledge and first-hand experience of what is happening in his country. Students discussed issues faced by Ukrainians, reviewed problems citizens faced, and ideated around technology-centric solutions. Feelings of exasperation, frustration, and most importantly, hope became lines of code. Together, students built solutions to answer the call: Code4Ukraine.

Blue and yellow emblem that says Code 4 Ukraine

Then, gradually, through a collaborative effort, problem solving, and hours of hard work, the winners of the Code4Ukraine Hackathon emerged: Medicine Warriors, a project built by a diverse, cross-cultural group of undergraduate students and IT professionals from Ukraine, Poland, and Georgia, aiming to address the insulin shortage in Ukraine. The project gathers publicly available data from Ukrainian government notices on insulin availability across Ukraine and presents it in an easily readable way.

Photograph of the Medicine Warriors application design

Photograph of the Medicine Warriors application design

Helping: at the heart of their community

One member of the winning team is the GDSC chapter lead at the National Technical University of Ukraine Kyiv Polytechnic Institute, Ekaterina Gricaenko. “In Ukraine, there is a saying: ‘друг пізнається в біді,’ which translates to, ‘you will know who your friends are when the rough times arrive,’” says Ekaterina. “And now, I can say that the GDSC community is definitely on my family list.”

Photograph of Ekaterina Gricaenko, GDSC Lead

Ekaterina Gricaenko, GDSC Lead, Kyiv Polytechnic Institute

The Code4Ukraine initiative’s goal of bringing others together to make an impact offers a prime example of what the Google Developer Student Clubs (GDSC) program aims to achieve: empowering student developers in universities to impact their communities through technology.

Reflecting on her experience leading the Kyiv GDSC chapter, Ekaterina says, “I started my journey with GDSC as a Core Team member, and during that time, I fell in love with our community, goals, and key concepts. Then, I decided to become a lead, to share my enthusiasm and support students as they pursue their professional dreams.

The Kyiv GDSC has organized over 18 workshops, written over 200 articles, run multiple study groups, and reached over a thousand followers on social media. “It’s incredible to realize how far we have come,” Ekaterina says.

A visual collage displays multiple activities organized by GDSC KPI

A visual collage displays multiple activities organized by GDSC KPI, led by Ekaterina Gricaenko.

Getting involved in your community

Through efforts like Code4Ukraine and other inspiring solutions like the 2022 Solution Challenge, students globally are giving communities hope as they tackle challenges and propose technical solutions. By joining a GDSC, students can grow their knowledge in a peer-to-peer learning environment and put theory into practice by building projects that solve for community problems and make a significant impact.

Photo of students in class in the upper right hand corner with a sign in the center that says Become a leader at your university

Learn more about Google Developer Student Clubs

If you feel inspired to make a positive change through technology, applications for GDSC leads for the upcoming 2022-2023 academic year are now open. Students can apply at goo.gle/gdsc-leads. If you’re passionate about technology and are ready to use your skills to help your student developer community, then you should consider becoming a Google Developer Student Clubs Lead!

We encourage all interested students to apply here and submit their applications as soon as possible. The applications in Europe will be open until 31st May 2022.

Use IAM to control access to a resource based on the account, OU or organization that contains the resource

Today, AWS Identity and Access Management (IAM) introduced a new way that you can control access to your resources based on the account, Organizational Unit (OU) or organization in AWS Organizations that contains your resources. AWS recommends that you set up multiple accounts as your workloads grow. Using a multi-account environment has several benefits including flexible security controls by isolating workloads or applications that have specific security requirements. With this new IAM capability, you now can author IAM policies to enable your principals to access only resources inside specific AWS accounts, OUs, or organizations.