Writing code is hard. Writing code that has to deal with parallelism and concurrency is harder. Doing all of that an keeping it efficient is challenging.
Today we’re announcing AWS Lambda Destinations for asynchronous invocations. This is a feature that provides visibility into Lambda function invocations and routes the execution results to AWS services, simplifying event-driven applications and reducing code complexity.
When a function is invoked asynchronously, Lambda sends the event to an internal queue. A separate process reads events from the queue and executes your Lambda function. When the event is added to the queue, Lambda previously only returned a 2xx status code to confirm that the queue has received this event. There was no additional information to confirm whether the event had been processed successfully.
A common event-driven microservices architectural pattern is to use a queue or message bus for communication. This helps with resilience and scalability. Lambda asynchronous invocations can put an event or message on Amazon Simple Notification Service (SNS), Amazon Simple Queue Service (SQS), or Amazon EventBridge for further processing. Previously, you needed to write the SQS/SNS/EventBridge handling code within your Lambda function and manage retries and failures yourself.
With Destinations, you can route asynchronous function results as an execution record to a destination resource without writing additional code. An execution record contains details about the request and response in JSON format including version, timestamp, request context, request payload, response context, and response payload. For each execution status such as Success or Failure you can choose one of four destinations: another Lambda function, SNS, SQS, or EventBridge. Lambda can also be configured to route different execution results to different destinations.
In this article, we will discuss how any organisation can use deep learning to automate ID card information extraction, data entry and reviewing procedures to achieve greater efficiency and cut costs. We will review different deep learning approaches that have been used in the past for this problem, compare the results and look into the latest in the field. We will discuss graph neural networks and how they are being used for digitization.
While we will be looking at the specific use-case of ID cards, anyone dealing with any form of documents, invoices and receipts, etc and is interested in building a technical understanding of how deep learning and OCR can solve the problem will find the information useful.
Creating an OS Thread or switching from one to another can be costly for your programs in terms of memory and performance. Go aims to get advantages as much as possible from the cores. It has been designed with concurrency in mind from the beginning.
M, P, G orchestration
To solve this problem, Go has its own scheduler to distribute goroutines over the threads. This scheduler defines three main concepts, as explained in the code itself:
The main concepts are: G - goroutine. M - worker thread, or machine. P - processor, a resource that is required to execute Go code. M must have an associated P to execute Go code[...].
Here is a diagram of this
Each goroutine (
G) runs on an OS thread (
M) that is assigned to a logical CPU (
P). Let’s take a simple example to see how Go manages them…
Serverless (in some people’s minds) currently encompasses:
- Anything that looks like “Function as a Service” like AWS Lambda, Google Cloud Functions, and Azure Functions
- Anything that can run a Function as a Service system, like OpenFaaS and similar
- Ok… lots of people think it’s a synonym for Function as a Service (spoiler: it’s not)
- Any solution that runs “on demand compute” such as Google App Engine (spoiler: it’s not)
- Anything that runs a container on demand like Google Cloud Run or Fargate (note: I like Cloud Run)
- Basically “on demand compute” of some description, some of which “scales to zero”
Handling character encodings in Python or any other language can at times seem painful. Places such as Stack Overflow have thousands of questions stemming from confusion over exceptions like
UnicodeEncodeError. This tutorial is designed to clear the
Exception fog and illustrate that working with text and binary data in Python 3 can be a smooth experience. Python’s Unicode support is strong and robust, but it takes some time to master.
This tutorial is different because it’s not language-agnostic but instead deliberately Python-centric. You’ll still get a language-agnostic primer, but you’ll then dive into illustrations in Python, with text-heavy paragraphs kept to a minimum. You’ll see how to use concepts of character encodings in live Python code.
News and announcements
- Flutter now supports the web. Open source, repo on GitHub.
- Flutter 1.5 ships to the stable channel (release notes). Includes preliminary support for targeting Windows, Mac and Linux operating systems. New plug-ins for in-app payment, state management. New samples for ML Kit-based image classification.
- Support for developing on Chrome OS and publishing apps to Chrome OS.
- Dart 2.3 released with new support for UI-as-code features including the spread operator, collection if and collection for; website and package siteoverhauled.
- New reference customers for Flutter announced: eBay, Sonos, and New York Times. The Assistant team is using Flutter for their smart display platform with Flutter, powering the UI of devices such as Google Nest Hub.
- Updates for the Visual Studio Code and Android Studio tooling extensions.
- Flutter training course published by App Brewery, in collaboration with Google. Thirty hours of videos and labs, at a subsidized price of just $10.
- Flutter Create award winners announced, along with demo reel.
- International community-organized Flutter hackathon on June 1st.