# Quantum Computing

## Summary

Quantum computers are next-generation computers that take a novel approach for processing information. They're built on the principles of quantum mechanics. They can solve some difficult problems that are practically impossible using conventional computers. Due to certain quantum properties, quantum computers are a lot faster.

Conventional computing, nowadays called classical computing, uses transistors to process information. Quantum computing works at the level of atoms and subatomic particles. In fact, there's a limit to how much we can miniaturize transistors since beyond a certain point quantum effects come into play. This is where quantum computing becomes relevant.

Quantum computing is a subfield of quantum information science. Many aspects of quantum computing are yet to be understood. Building such computers and making them practical is still a challenge. As such, we expect classical computers to serve their purpose for many more decades.

## Discussion

### What are some possible applications of quantum computers?

**Cryptography** is one of the applications. Today's digital systems are secure because classical computers can't do integer factorization within a reasonable time. A quantum computer can do this using Shor's algorithm. Quantum computing when applied to cryptography would lead to more secure systems.

**Search problems**, or more generally optimisation of multivariate problems, are not efficiently solved using classical computers. A quantum computer programmed with Grover's algorithm can solve these problems in polynomial time.

In domains such as chemistry and nanotechnology, there's a need to **simulate quantum systems**. Classical computers are inefficient with such simulations. Quantum computers are better suited for this purpose. For example, modelling complex molecular interactions at atomic level can lead to drug discovery. Quantum simulations can help us build more efficient energy systems, better superconductors and newer materials.

**Machine learning** involves training models with lots of data. Quantum machine learning is being explored to speed up learning.

In general, where classical computers are overwhelmed by lots of data and endless calculations, quantum computers can fill the gap.

### Which are the essential quantum properties enabling quantum computing?

Three quantum properties are being harnessed for quantum computing:

    + **Superposition**: Given two states, a quantum particle exists in both states at the same time. Alternatively, we may say that the particle exists in any combination of the two states. The particle's state is always changing but it can be programmed such that, for example, 30% of the time it's in one state and 70% in the other state.
    + **Entanglement**: Two quantum particles can form a single system and influence each other. Measurements from one can be correlated from the other.
    + **Quantum Interference**: Trying to measure the current state of a quantum particle leads to a collapse; that is, the measured state is one of the two states, not something in between. External interference influences the probability of particle collapsing to one state or the other. Quantum computing systems must therefore must be protected from external interference.

### What are qubits and pbits?

In classical computing, the unit of information is the bit. It's value is either 0 or 1. In quantum computing, due to superposition, the classical bit is inadequate to represent a continuum of states. Therefore, quantum bit or **qubit** has been defined as the unit of quantum information.

To say that a qubit can be both 0 and 1 simultaneously can sound mystical. A simple analogy is to consider an x-y plane and a vector 45 degrees to the x-axis. This vector has both x and y components at the same time. Likewise, a qubit is both 0 and 1 simultaneously. We can visualize it as any point on the **Bloch sphere** with the poles representing 0 or 1.

Probabilistic bit or **pbit** is used as a simpler alternative to the qubit. The state of a pbit is a probabilistic combination of the two logical states 0 and 1.

A process called **conditioning** converts pbits to classical information. Similarly, another process called **measurement** converts qubits to classical information.

### What makes quantum computers compute faster than classical computers?

In classical computing, an n-bit number can represent a single value of range \([0, 2^{n-1}]\). In quantum computing, an n-qubit system represents all the possible \(2^n\) values at the same time. Alternatively, if we add a single bit to a classical computer, it's memory increases by one bit. The same change to a quantum computer doubles its memory.

Consider a 4-bit input. To process all 16 possible input patterns, a classical computer would execute its algorithm one input at a time. A 4-qubit quantum computer would process all 16 patterns at the same time. As more bits are added to a quantum computer, its processing power increases exponentially.

This is why a 50-qubit system can be compared to a classical computer handling billions of bits. A qubit counts for much more than a classical bit. Fifty-qubit is an approximate threshold at which quantum computers are able to perform calculations not feasible with classical computers.

### What does it take to build quantum computers?

To build a quantum computer, qubits must be housed in an environment that achieves minimum interference and maximum coherence. We need a method to transfer signals to qubits. We need classical computers to send instructions to qubits. Thus, it's not just about computing with qubits but also about converting from/to classical information.

Various **physical systems** can be used to build qubits: ion traps, crystal defects, semiconductor quantum dots, superconductors, topological nanowires, neural atoms in optical lattices, nuclear magnetic resonance (NMR) and more.

Just as transistors are combined in classical computing to implement Boolean logic using logic gates, there are various **quantum computing models**. Quantum circuit is one such model that uses quantum gates. Other models include one-way or measurement-based quantum computer (MBQC), adiabatic quantum computer (AQC), and topological quantum computer. Quantum Turing Machine (QTM) is of theoretical importance. All models are equivalent to one another.

**Quantum algorithms** have to be developed. These are often specific to the computing model.

### What does "quantum" refer to in quantum computing?

A simple answer is that the term "quantum" comes from quantum mechanics. In physics, it refers to properties of atomic or subatomic particles, such as electrons, neutrinos, and photons.

The real question is what aspects of quantum mechanics make quantum computing better than classical computing. There's no definitive answer though some theories have been put forward.

Interference, entanglement, quantum contextuality, logical structure of quantum mechanics and quantum parallelism have been proposed. All of these have their critics. We don't understand this very well. Perhaps this is why we have very few quantum algorithms.

A dominant theory is Quantum Parallelism Thesis (QPT), which in turn suggests Many Worlds Interpretation (MWI). Due to superposition, quantum computers compute on different input values simultaneously. In some sense, computations happen in parallel in many classical universes. Decoherence is used to distinguish one world from another. But this is at odds with the quantum circuit model and its coherence superpositions. Moreover, any measurement collapses the output state. Quantum algorithms must therefore construct 'clever' superpositions to increase the chance of obtaining a useful result.

### What are some practical difficulties of building quantum computers?

Challenges include fabrication, verification and architecture. Since quantum states are fragile, fabrication must be precise. Since any measurement collapses the state in a probabilistic manner, verification is difficult. Errors are more common than in classical computing and error correction is essential to the architecture.

Interactions with external environment results in decoherence. At best, we're able to maintain coherence for only a few microseconds. Coherence becomes harder to achieve with more qubits. Coherence requires that superconductors are cooled to near absolute zero.

Scaling up to more qubits on a single chip is another challenge. Today's systems need multiple control wires for every qubit.

For various reasons that we can simply call noise, qubits change state. We therefore need efficient error correction methods. One approach is to use many physical qubits (as many as 10,000) to map to a single logical qubit. This makes it even more difficult to build a useful quantum machine. Some consider quantum error correction to be the most important problem that needs focused research. Some even estimate that 99% of quantum computations will be spent for error correction.

## Milestones

1975

Poplavskii shows that it's computationally difficult to simulate quantum systems using classical computers. This view is reiterated by Feynmann at a conference in MIT in 1980.

1976

Polish mathematical physicist Roman Stanisław Ingarden publishes a seminal paper titled *Quantum Information Theory*. It's an attempt to generalize Shannon's information theory.

1980

Paul Benioff describes the first quantum mechanical model of a computer. He uses the Schrödinger equation to describe a **Quantum Turing Machine (QTM)**. Yuri Manin proposes the idea of quantum computing. Benioff further develops his QTM in 1982.

1982

Wootters, Zurek and Dieks state the **No-Cloning Theorem**. This states that it's impossible to make identical copies of an arbitrary unknown quantum state. The theorem is consistent with the uncertainty principle in quantum mechanics. The theorem implies that a qubit can't be copied. This is a problem for taking backups or error correction. However, it's a useful property for cryptography.

1985

David Deutsch at the University of Oxford describes the first **universal quantum computer**. Like its classical counterpart in the Universal Turing Machine (UTM), this can simulate any other quantum computer in polynomial time.

1994

Peter Shor at AT&T Bell Labs invents a quantum algorithm that can factor large integers lot faster than classical computers. Theoretically, this can break many cryptographic systems in current use. This sparks interest in quantum computing. In time, this is called **Shor's Algorithm**. Shor assumes that qubits maintain their states. In practice, decoherence is a problem.

1995

Shor and Steane independently invent the first **quantum error correcting codes**. This circumvents the no-cloning theorem.

1996

Lov Grover at Bell Labs invents the quantum database search algorithm. This is relevant to a variety of problems. In particular, brute-force search problems obtain quadratic speedup. In time, this is called **Grover's Algorithm**.

1998

Researchers at the University of Oxford **demonstrate a quantum algorithm** on a 2-qubit NMR quantum computer. IBM researchers achieve a similar demonstration. The same year Grover's algorithm is demonstrated on an NMR quantum computer.

2015

Cambridge Quantum Computing releases t|ket>, which could be the first **operating system** for quantum computing. This enables classical computers interface to quantum computers.

2016

IBM's 5-qubit quantum computer becomes **available on the cloud** for academics and researchers, leading to demonstrations in 2017.

Oct
2019

Google claims to have achieved quantum supremacy with a 53-qubit programmable superconducting processor. Named *Sycamore*, it's based on quantum logic gates. The machine completes a benchmark test in 200 seconds, what a classical supercomputer would take 10,000 years. However, IBM claims a supercomputer with more disk storage could solve the problem in 2.5 days. In August 2020, 12 qubits of Sycamore are used to simulate a chemical reaction.

Mar
2020

Honeywell reports on a demonstration of a quantum computer architecture based on trapped-ion QCCD (Quantum Charge-Coupled Device). This year sees more interest from start-ups pursuing trapped-ion QCCD. Trapped-ion quantum computers can be traced to 1995 but most companies (IBM, Intel, Google) focused on superconductors instead.

Quantum Computing


# Python 2 vs 3

## Summary

Python 3 was released to fix problems present in Python 2. The nature of these changes meant that Python 3 was incompatible with Python 2. It also meant that Python 3 did not carry forward the problems of Python 2. Some aspects of Python 3 have been backported to Python 2.6 and 2.7 to make the migration to Python 3 easier.

Python 2 was supposed to be retired in 2015 but slow adoption of Python 3 led to an extended deadline of 2020. Python 2.7 will receive updates till 2020 for security and bug fixes only.

As of February 2018, it's seen on Python 3 Readiness that 348 of 360 most downloaded packages from PyPI already support Python 3.

It's expected that if ever there should be a Python 4, it will be compatible with Python 3.

## Discussion

### What were the main issues with Python 2?

A `str` object could represent either text or binary data. This easily results in bugs because developers often don't use `unicode` type for text. Python 3 solves this by making all `str` Unicode and having `bytes` type to handle binary data. It's explicit and unambiguous. To support string literals involving non-ASCII characters, making Unicode as default is a good thing.

When functions are treated as objects in Python and can take arguments, `print` is an unnecessary exception. It's a statement in Python 2 but making it a function would be make it more flexible.

Division that should result in a `float` instead does truncation and results in an `int`. Python 2 needed extra functions/methods to minimize RAM usage but Python 3 does lazy evaluation by default. Although Python is strongly typed, Python 2 permits strange comparisons: `None < 3 < "2"`.

Nick Coghlan provides a detailed discussion of why Python 3 was defined in a backwards incompatible manner.

### I am new to Python. Should I learn Python 2 or Python 3?

Python 3 fixes many of the problems that are present in Python 2. Python 3 is also the future of the language since Python 2 will be retired in 2020. It's therefore recommended that beginners learn Python 3. Moreover, if you're going to write new code, Python 3 is the one to choose. Eevee's blog article gives a detailed explanation of all the good things in Python 3.

If you've to maintain legacy Python 2 code, it's still best to learn Python the right way from Python 3. Then you can study the differences between Python 2 and 3. The point is that the two versions are much more similar than different.

### What features of Python 3 have been backported to Python 2.7?

Backporting has been done mainly to aid in the eventual migration of Python 2 code to Python 3. A list of backports is documented in the official Python Docs and explained briefly in Eevee's blog.

As an example, `bytes` and `bytearray` are part of Python 3.x but they were backported to 2.6 but with very different semantics. In Python 2, `bytes` is really an alias of `str`. The purpose was really to aid converters such as `2to3`.

### What are the differences between Python 2 and Python 3 for data types?

Following is a summary of key differences:

| Python 2.X | Python 3.X |
| --- | --- |
| There's ASCII `str` type and `unicode` type, but no separate type to handle bytes of data | All strings (`str`) are Unicode strings; two byte classes are introduced: `bytes` and `bytearray` |
| Two types of integers: C-based integers (`int`) and Python long integer (`long`) | All integers are long but referred to by the `int` type |
| Return type of division is int if operands are integers: `5 / 4` gives `1`; `4 / 2` gives `2` | Return type of division is `float` even if operands or result are integers: `5 / 4` gives `1.25`; `4 / 2` gives `2.0` |
| `round(16.5)` returns a `float` of value 16.0 | `round(16.5)` returns an `int` of value 16 |
| Unorderable types can be compared | Comparison of unorderable types raises a TypeError |

### What are the other differences between Python 2 and Python 3?

Following is a summary of key differences:

| Python 2.X | Python 3.X |
| --- | --- |
| `print` is a statement: `print "Hello World!"` | `print()` is a built-in function: `print("Hello World!")` |
| `range()` returns a list of numbers while `xrange()` returns an object for lazy evaluation | `range()` returns an object for lazy evaluation similar to Python 2 `xrange()`; and `range()` method `__contains__` speeds up lookups |
| Functions/methods `map()`, `filter()`, `zip()`, `dict.items()`, `dict.keys()`, `dict.values()` return lists | These function/methods return objects for lazy evaluation |
| `raw_input()` returns input as `str` and `input()` evaluates the input as a Python expression | `input()` will return a string similar to Python 2 `raw_input()` |
| Raising exceptions: `raise IOError("file error")` or `raise IOError, "file error"` | Raising exceptions: `raise IOError("file error")` |
| Handling exceptions: `except NameError, err:` or `except (TypeError, NameError), err:` | Handling exceptions: `except NameError as err` or `except (TypeError, NameError) as err` |
| On generators, a method or function call: `g.next()` or `next(g)` | On generators, only a function call: `next(g)` |
| Loop variables in a comprehension leak to global namespace | Loop variables are limited in scope to the comprehension |

### What does the Python standard library provide to manage the incompatibility between Python 2 and 3?

The following are some modules that we can use:

    + `builtins`: To create wrappers around built-in functions, `builtins` is useful.
    + `future_builtins`: Function `map` and `filter` in Python 2 behave differently than in Python 3. To get Python 3 behaviour, use `from future_builtins import map, filter`.
    + `__future__`: In Python 2, to use `print()` only as a function, use `from __future__ import print_function`.
    + `2to3`: To convert Python 2 code to Python 3, this standard library can be used. It applies a series a fixers to do the conversion. It's based on `lib2to3` library, which can be used to add custom fixers. Python Converter is online conversion tool based on `2to3`.

### I have a legacy Python 2 codebase but would like to start supporting Python 3 as well. What can I do?

There are a few approaches that developers can take depending on the need:

    + `modernize`: This is useful when you want to partially support both 2 and 3 with the goal of eventually porting to Python 3.
    + `future`: This enables either Python 2 or 3 code to be used across both versions. It comes with scripts `futurize` and `pasteurize` for 2-to-3 and 3-to-2 conversions respectively so that a single codebase can be used. It's supported for versions 2.6+ and 3.3+. There is a cheatsheet that gives examples of writing compatible code.
    + `six`: This wraps over the differences between 2 and 3 without modifying code. This means the code can run on both versions.It's recommended to drop support for Python 2.6 and older if possible. If legacy code must be maintained, one can opt for commercial services such as from ActiveState.

Tools such as pylint, caniusepython3 and tox can help in checking or maintaining compatibility. Developers can also refer to a cheatsheet on writing compatible code; or get familiar with common migration problems.

## Milestones

Oct
2008

Python 2.6 is released. The development of this release is synchronized with that of Python 3.0. Thus, Python 2.6 incorporates some changes that are part of Python 3.0. This backporting is expected to make way for easier migration of Python 2.6+ code to Python 3.x. Module `future_builtins` has 3.0 semantics.

Dec
2008

Python 3.0 is released. It simplifies some of the unwieldy syntax that was in Python 2.x. It's not backward compatible with Python 2.x and hence it's release is seen as controversial. However, Python 3.x is the future of the language. Python 3.0 itself is deemed a failure due to slow IO.

Jun
2009

Python 3.1 is released and it supercedes Python 3.0 that was unusable.

Jul
2010

Python 2.7 is released. It includes some features introduced in Python 3.1. Python 2.7.x releases will receive bug fixes as well as backports from Python 3.x to make it easier in future to migrate that code to Python 3. It's the last 2.x release (there won't be a 2.8 release). It's expected to be retired in April 2020, implying that it will be maintained for 10 years since it's initial release.

Feb
2011

Python 3.2 is released. A year later, it's seen that with this release Python 3 gains traction.

Sep
2012

Python 3.3 reinstates the redundant syntax for Unicode string: `u'hello'`. This is done to enable easier migration from 2 to 3.

2013

Python 2.6 reaches end of life and at least one expert recommends (in 2016) that developers should move to 2.7 if moving to 3.x is not an option.

2016

Jake VanderPlas states that the scientific community should adopt Python 3 thanks to tools such as `six` and `future`. In 2013, VanderPlas had noted that moving to Python 3 was impossible (back then). In November, popular Python author Zed Shaw publishes a scathing article against Python 3. A day later, blogger named Eevee publishes a detailed rebuttal.

2017

A Python Developers Survey towards the end of 2017 done by JetBrains finds that 75% of respondents use Python 3. In the domain of data science, adoption is higher at 80%.

Apr
2020

The last major version of Python 2.7 is expected to be released in April. Following this, Python 3 will be the only one supported for bugs and security fixes.

Python 2 vs 3


# Gradle

## Summary

Gradle is an open-source build automation tool. A build process typically picks correct versions of project source code, resolves dependencies, assembles necessary assets, checks code against coding guidelines, executes unit tests, compiles code, and publishes the resulting software artifacts. Gradle can do all of these.

Gradle is performant, flexible and extensible. Via both convention and configuration, it balances ease of use and flexibility. Through plugins, the basic feature set of Gradle can be extended. It runs on the JVM and hence can be used on any platform. Gradle can be used for projects written in Java, C++, Swift, and more. Many IDEs and CI/CD tools support Gradle.

Since it's release in 2008, adoption of Gradle has grown steadily. In 2020, Maven continued to be the more popular build tool for traditional Java applications. However, Gradle is more widely used by Android mobile app developers.

## Discussion

### What are the main features of Gradle?

Gradle has dozens of features. These relate to authoring of build scripts, Gradle execution, and integrations to IDEs, languages and repositories.

Writing build scripts is made easy with Groovy or Kotlin Domain-Specific Language (DSL). Well-defined conventions make it easier for developers to write build scripts. However, Gradle is flexible enough to allow easy customization.

Gradle downloads and manages transitive dependencies. Even files can be declared as dependencies. Remote dependencies can be cached locally. By locking dynamic dependencies to specific versions, builds become deterministic and reproducible.

For performance, Gradle does incremental builds, skipping tasks and subtasks when their inputs haven't changed. It caches previous builds. It executes tasks in parallel. Build scans enable developers to analyse and compare past builds to find problems or optimize builds. Execution can be controlled via options. For example, some tasks can be excluded. Build can be configured to continue despite failures.

Gradle has specific features and support for Java, Groovy, Scala, Android, C/C++, Assembler, GCC, Clang, CUnit, etc. The Gradle Tooling API allows Gradle SDK to be used within IDEs and CI/CD tools.

### Which are the main building blocks of Gradle?

A **task** contains logic to execute something specific, such as compiling, testing or deploying software. Gradle comes with many in-built tasks and developers can create custom tasks. Tasks are composed of inputs, actions and outputs.

A **build** is the execution of a set of tasks. A **project** is what a build achieves. For example, assembling a jar, war or zip file can be a project. Projects can have sub-projects. A build can contain more than one project. A project's build script is named `build.gradle` or `build.gradle.kts`. Build happens in three phases: initialization (set up the build environment for relevant projects), configuration (which tasks to run) and execution (run tasks). Execution can be started from command line or from an IDE.

Gradle's design is minimalistic. It's extended by plugins. A **plugin** helps us reuse logic or configuration across projects. It helps us write more maintainable build scripts.

### How does Gradle compare against Apache Maven?

It's claimed that Gradle is 2x faster than Maven for most cases and 100x faster for large builds. This is mainly due to incremental builds, better build caching and the Gradle daemon. Gradle daemon runs in the background, thus eliminating JVM startup time. It caches information across builds. It watches the file system to determine what needs to be built even before a build is started. Gradle's Build Scan helps developers visualize and optimize builds.

Maven relies on XML for build configuration. Gradle scripts are in DSL. They're configuration but they're also code. They can be easier to maintain than XML.

Gradle is more flexible. It's Tooling API allows us to embed it into IDEs and other tools. Customization with Maven can be hard. While Maven has better support with IDEs, Gradle is getting better here, particularly with Kotlin DSL.

While Maven can override a dependency by version, Gradle has dependency selection and substitution rules. These can be declared once and used project-wide. Substitution enables composite builds across projects. In fact, it's been said that Maven is not suited for multi-project builds.

### What's the right way to organize a Gradle project?

Start by running `gradle wrapper`. Then launch Gradle with `gradlew` (Linux) or `gradlew.bat` (Windows). The wrapper automatically installs Gradle and eases future upgrades.

Follow common conventions in organizing files and folders. For example, keep Java and Kotlin files in separate folders. Keep unit tests separate from integration tests.

Gradle always looks for the `settings.gradle` file. Create at least an empty file to speed up the search for this file. Properties can be specified in `gradle.properties`. Properties specified in build scripts can be hard to maintain. Properties passed via the command line are useful for ad hoc scenarios.

Each task should write its output to a separate folder. This allows Gradle to apply incremental build for faster builds. Due to incremental build, there's no need to clean before a build.

When the build script file `build.gradle` becomes large and unmaintainable, it's a good idea to modularize it into multiple files and organize them within a `buildSrc/` folder. Thus declarations are separated from implementations. Additional dependencies can be in `buildSrc/build.gradle`.

### What are some best practices when using Gradle?

Write build scripts in a declarative manner. DSL enables this. Avoid writing imperative code in build scripts. Complex imperative code can be moved to a binary plugin.

When a project has many dependencies, the ordering of repositories might matter. The more often used repositories should be listed first.

Minimize logic during the configuration phase of a build. These would be executed every time even when the associated task is not executed.

Use multi-project or composite builds rather than triggering another build using the `GradleBuild` task type. Avoid inter-project configuration, such as depending on a task from another project.

On multicore systems, run tests in parallel with `test { maxParallelForks 3 }`.

Don't include passwords in build scripts or `gradle.properties` file.

Avoid using internal Gradle APIs. Their use can break build scripts if Gradle or plugins change. For example, don't use `org.gradle.internal.os.OperatingSystem`. Instead, call `System.getProperty("os.name")` from Apache Commons SystemUtils.

Use the Gradle lint plugin to enforce a coding style to build scripts. Follow conventions when declaring tasks. An example is to always declare `group` and `description` so that tasks become discoverable.

More best practices are shared by Liutikas and Zhuk.

## Milestones

2008

Dockter and Murdoch start working on Gradle. At this time, the project is open source and there's no commercial entity behind it.

2010

**Gradle Inc.** is founded. Some major open source projects migrate to Gradle for their build processes. Gradle wins the Springy Award.

Jun
2012

**Gradle v1.0** is released.

2013

Google's Android project adopts Gradle as the default build tool. Android Studio installation comes with the **Android Gradle plugin**. Over the years, a version compatibility matrix develops, mapping the versions of Android Studio, the plugin and Gradle.

Jul
2014

**Gradle v2.0** is released. This release removes many deprecated features and API. It simplifies the codebase. It improves performance, particularly for large builds. It uses Java 8 (Java 5 is no longer supported) and Groovy 2.3.2 (earlier this was Groovy 1.8).

2015

Gradle achieves **one million downloads per month**. A 2016 study of 10,000 projects shows that Maven is the most popular build tool (53%) while Gradle is used by only 11% of the projects. However, Gradle adoption continues to grow, reaching 10M downloads per month (2019) and 30M downloads per month (2022).

Aug
2016

**Gradle v3.0** is released. This release enables Gradle Daemon by default. There's better IDE support for IDEA and Eclipse. While Groovy remains the primary build language, now there's support for Kotlin as well. Java 9 is supported. **Gradle Cloud Services** is part of the release and *Build Scans* is the first such service. A build scan provides insights into a build and identifies problems. **Gradle Enterprise** (first released in June 2016) is an on-premise version of Gradle Cloud Services.

Jun
2017

**Gradle v4.0** is released. This release makes *Build Cache* production-ready for Java and Groovy compilation. Logging and terminal display are improved.

Nov
2018

**Gradle v5.0** is released. Builds are now faster. Fine-grained dependency management is supported. Kotlin DSL is now production-ready. This enables code completion, error highlighting, quick documentation and refactoring. Task timeouts and Java 11 support are further additions.

Nov
2019

**Gradle v6.0** is released. This release improves dependency management and performance. It adds support for JDK13.

Apr
2021

**Gradle v7.0** is released. With file system watching enabled by default, incremental builds are faster. Builds are made more secure by running integrity checks on the dependencies. There's support for Java 16. In multi-project builds, dependency versions can be shared using an experimental feature called *version catalogs*.

Gradle


# MongoDB

## Summary

MongoDB is a NoSQL database. More specifically, it's a document-oriented database. It stores data as *documents*. Documents themselves are organized into an abstraction called *collections*. Documents consist of key-value pairs. Thus, MongoDB's a hybrid of relational databases and key-value stores.

MongoDB came out in 2009 as a response to the limitations of relational SQL databases. These imposed strict schema that didn't suit some use cases. Schema migrations were a pain. Scaling was vertical and expensive. These are the problems that MongoDB set out to solve.

MongoDB can be deployed on-premise or on the cloud.  There are a host of tools to manage custom deployments. MongoDB is managed by MongoDB, Inc. Although the code is open, it's licensing is not really considered open source.

Despite some criticisms, MongoDB continues to grow in adoption. It's fully managed cloud service, MongoDB Atlas, is particularly popular.

## Discussion

### How does MongoDB organize data?

Whereas a SQL database organizes data into tables containing rows and columns, MongoDB organizes data into **collections** containing **documents** and **fields**. A MongoDB instance can manage multiple databases. Each database can have multiple collections. A collection encapsulates multiple documents that share some similarity.

A document is really a JSON document containing key-value pairs. Values can be numbers, strings, dates, arrays or even other JSON documents. Internally, documents are stored in a binary format called **Binary JSON (BSON)**. Objects in many programming languages can be mapped easily to MongoDB documents. This simplifies application code and dispenses with Object–Relational Mapping (ORM).

MongoDB has two storage engines: WiredTiger and In-Memory.

Consider a news article with title, image, URL, tags, and comments. In SQL, article attributes, image, tags and comments would be stored in separate tables. In MongoDB, the article and its associated image, tags and comments are stored in a single document. Retrieval of this data is simple without needing SQL's complex join queries. Thus, MongoDB employs a **document data model**.

### What are the main features of MongoDB?

MongoDB's key features relate to its document-oriented model. Being **schema-less**, the model is flexible and avoids schema migrations. If required, schema validation can be enabled.

Even without a schema, MongoDB supports **ad hoc queries**. This is powered by *MongoDB Query Language (MQL)*. Real-time aggregations are supported.

**Indexes** are supported for faster search. A primary key is automatically created for each document and this is indexed. In addition, secondary indexes are supported.

For reliability, **replica sets** are used, with each set containing duplicates of the data. These are also useful to load balance the reads. A typical replica set has one primary node and many secondary nodes.

Administrators can choose the right **speed-durability trade-off** as suited for the application. By default, journaling is enabled by which writes are flushed to journal file every 100ms. Journaling can be disabled for faster write performance and instead replicated for better durability.

MongoDB scales well due to **sharding**. Large collections are distributed across nodes. Queries are routed to relevant shards, thereby balancing the load. Sharding can be range-based, hash-based or tag-based. Individual shards are also part of replica sets.

### What are the use cases where MongoDB fits?

One critic of MongoDB, identified only two use cases for MongoDB: for storing semi-structured data where no strict schema can be imposed; and for prototyping, where we might experiment with different design choices for the schema.

In an alternative viewpoint, MongoDB is claimed to be suited for web applications, where data relations are common. This is attributed to MongoDB's abstractions (collections, documents), indexes, dynamic queries and aggregations.

In Agile methodology, quick iterations are essential. MongoDB saves time because it doesn't deal with schemas and migrations.

MongoDB has been applied to analytics and logging. Atomic updates (increment counters, append to arrays) and capped collections (keep only recent documents) are two features that are relevant here. Logs can be stored in the database rather than in files.

Caching is another use case. MongoDB can be used as a caching layer.

### What are the deployment options of MongoDB?

**MongoDB Community Server** or **MongoDB Enterprise Server** can be downloaded, installed and self-managed. This is available for various platforms (Windows, macOS, Linux). The enterprise version is also part of MongoDB Enterprise Advanced subscription. This gives comprehensive support even when you run MongoDB on your own infrastructure.

An alternative is to use MongoDB as a fully managed service in the cloud. This is called **MongoDB Atlas**. This comes with the proven benefits of cloud computing: availability, scalability, security, performance, automation, and more. As of October 2021, this is available for AWS, Google Cloud, and Azure.

### Which are the tools for managing or working with MongoDB?

Here are some useful tools:

    + **MongoDB Shell**: Called `mongosh`, it's a CLI to connect, query and work with a database. Available since v5.0, it deprecates an earlier shell called `mongo`.
    + **MongoDB Compass**: A GUI for MongoDB. Variants include Readonly Edition and Isolated Edition (disables unnecessary network connections).
    + **MongoDB CLI for Cloud**: Called `mongocli`, it's a CLI for managing cloud services such as MongoDB Atlas, MongoDB Cloud Manager, and MongoDB Ops Manager.
    + **MongoDB Database Tools**: Include useful utilities for binary import/export, data import/export, and diagnostics.
    + **MongoDB Connectors**: A set of connectors to interface with Business Intelligence (BI) tools, Apache Spark, Apache Kafka and Kubernetes.
    + **MongoDB Charts**: Data visualization for data stored in MongoDB Atlas and Atlas Data Lake.
    + **MongoDB Ops Manager**: For monitoring, backup, automation and query optimization. Part of MongoDB Enterprise Advanced subscription.
    + **MongoDB Cloud Manager**: It's a hosted management platform. Similar features as in Ops Manager but SaaS and updated more frequently. You need to install only relevant agents (monitoring, automation, or backup) in your own self-managed deployments. Less relevant if you're using MongoDB Atlas.

### What do you mean by MongoDB drivers?

Applications need to connect to MongoDB instances and run queries. Developers often write these queries at the application layer but connecting to a MongoDB instance is more complex and requires networking knowledge. To simplify the developer's job, the latter is implemented by MongoDB and provided as libraries. These are called **MongoDB drivers**.

Currently, drivers are available in Java, Node.js, C/C++, C#/.NET, Go, Python, PHP, Scala, Ruby, Rust and Swift. Apart from these, there are also community-supported drivers.

For some drivers, it's important to check for compatibility before installing them. For example, Rust driver version 1.0 doesn't support MongoDB 5.0 and all Rust driver versions requires at least MongoDB 3.6. In terms of language compatibility, Rust driver requires at least Rust 1.48.

While drivers help interacting with MongoDB programmatically, it's possible to do the same via MongoDB Shell (CLI) or MongoDB Compass (GUI). MongoDB Charts for visualization and MongoDB Connectors are other ways to interact with MongoDB.

### What are some criticisms of MongoDB?

MongoDB's document data model is ill-suited for social media data. For example, a user's activity stream will link to other users (friends, commenters, likers). This results in data duplication and an update nightmare to keep data consistent. Normalizing the activity stream and executing additional queries puts more burden on the application.

In 2015, Slootweg pointed out many of MongoDB's problems: data loss, ignored errors, slow, locking issues, insecure defaults, non-ACID, etc. If a developer uses Mongoose (a library for relations and schema validation), he proposes that PostgreSQL is a better option.

MongoDB's schema-less approach was blamed for data inconsistency and loss. Application code that attempted to ensure consistency become complex and buggy. Meanwhile, in the late 2000s and early 2010s, other NoSQL databases arrived that solved specific use cases in better ways: Redis for real-time data and caching, Cassandra for Big Data, Elasticsearch and Solr for search, InfluxDB for time-series (IoT) data, and more.

Most applications have relational data with schema and require migrations. MongoDB's ObjectIds are hard to work with. So are aggregation pipelines, which can hit memory limits. There's vendor lock-in to MongoDB, Inc.

### Where can I learn more about MongoDB?

Visit the official MongoDB website to learn more. You can download the MongoDB Community Server to try out the database. If necessary, you can later migrate to the MongoDB Enterprise Server. Alternatively, try the free tier of MongoDB Atlas.

Read the Getting Started guides. Read the official documentation. This includes installation guide, FAQ, command reference, tools, data modelling, and much more.

Check out the Developer Hub and the MongoDB Blog. Participate in the MongoDB Community Forum to get help or be informed of the latest developments.

As a developer, you can learn the basic database commands from Beugnet's MongoDB Cheat Sheet.

Among the books worth reading are *The Little MongoDB Book*, *MongoDB in Action* and *Practical MongoDB Aggregations*.

Those who prefer to learn from videos can check out these YouTube playlists: MongoDB Tutorial for Beginners and MongoDB Dev & Admin Tutorial Videos

## Milestones

2007

Eliot Horowitz, Dwight Merriman, and Kevin Ryan start a company named *10gen*. Their goal is to build a web-centric PaaS based on open source components. In the process, they realize that relational databases are hard to scale. Thus was born the idea for MongoDB. Horowitz recounts later that, "MongoDB was born out of our frustration using tabular databases in large, complex production deployments."

Feb
2009

**MongoDB 1.0** is released. By August, this version becomes generally available for production environments.

Dec
2009

MongoDB 1.2 is released with support for **aggregations**. This is implemented in Node.js via a Map-Reduce API. This is slow and queries are non-intuitive for developers. With the release of MongoDB 2.2 (August 2012), this is remedied with the **Aggregation Framework**. This is far more intuitive, powerful, efficient, and scalable. It soon becomes the go-to tool for developers. However, MongoDB continues to support Map-Reduce for legacy reasons.

Aug
2010

MongoDB 1.6 is released. Sharding is now production ready, thus making MongoDB **horizontally scalable**. Replica sets provide automated failover. They deprecate replica pairs used earlier.

2013

The LAMP stack has been popular web stack for many years. Valeri Karpov coins the term **MEAN**, a new web stack that stands for MongoDB, Express, Angular and Node. Variants of this stack such as MERN and MEVN also include MongoDB. In these stacks, MongoDB fulfils the database layer. Its JSON-like documents fits nicely with JavaScript frameworks.

Mar
2015

MongoDB 3.0 is released. **WiredTiger** storage engine is available. There's also a pluggable storage engine API. **MongoDB Ops Manager** is available.

Jun
2015

MongoDB Management Service (MMS) is renamed to **MongoDB Cloud Manager**. This is useful for monitoring, alerting, taking automated backups, upgrading without any downtime, and easily creating sharded clusters and replica sets. MMS was first released in 2011.

Dec
2015

MongoDB 3.2 is released. WiredTiger becomes the default storage engine. The previous default was MMAPv1. Config servers, which were previously mirrored, can now be deployed as replica sets. **Partial indexes** are supported, meaning that only some documents are indexed. This reduces storage requirements and performance costs for maintaining indexes. **Schema validation** is now possible on a per-collection basis during updates and insertions.

Jun
2016

**MongoDB Atlas** is launched as a fully managed database in the cloud, more commonly termed as Database as a Service (DBaaS). Due to automation, there's no need to manually install, configure, take backups, and monitor. For hybrid environments, MongoDB Cloud Manager can be used. For full on-premise deployments, MongoDB Ops Manager can be used.

Nov
2016

MongoDB 3.4 is released. Among the new features are **read-only views** and associating shards with one or more **zones**. To enable language-specific rules for string comparison, **collations** are introduced. Linearizable read concern level is introduced. Along with "multiple" write concern, this allows multiple threads to safely read/write on a single document.

Jun
2018

MongoDB 4.0 is released. **Multi-document transactions** are now possible. Transactions can be across multiple operations, collections, databases, documents, and shards.

Jan
2019

Amazon Web Services (AWS) launches **DocumentDB**, a database that emulates the MongoDB 3.6 API. Clients that use MongoDB can use DocumentDB as a drop-in replacement to MongoDB server. AWS could do this because MongoDB uses AGPL licensing. In anticipation of this, MongoDB, Inc. changed the licensing to **Server Side Public License (SSPL)** back in October 2018. SSPL required vendors to open source the entire stack. This move is not well received by the open source community. RedHat drops MongoDB from its RHEL distributions.

Jul
2021

MongoDB 5.0 is released. Native **time series collections**, clustered indexing, and window functions make it easier to run IoT and financial analytics. **Live resharding** can happen without any downtime. MongoDB Shell `mongosh` is introduced and it deprecates `mongo` shell.

MongoDB


# Language Modelling

## Summary

Consider the phrase "I am going \_\_\_". If we analyse large amounts of English text, the missing word is more likely to be 'home' rather than 'house'. This also implies that we can obtain the probability of a sequence of words.

A **Language Model (LM)** captures the probability of a sequence of words in the language. Equivalently, it tells us how likely a given word will follow a sequence of words.

Traditionally, N-gram models and their variants were used as language models. Since the early 2010s, Neural Language Models (NLMs) were researched. By 2019, pre-trained LMs were used for transfer learning to improve the performance of many downstream NLP tasks.

## Discussion

### Why do we need a language model when languages have well-defined grammar?

While natural languages have grammar, they also have a huge vocabulary. There's also considerable flexibility how words can be combined. Ambiguities occur naturally in human communication. Usage also changes with time. The end result is that grammatical rules and syntactic structures can't be specified for all use cases.

Language models therefore attempt to learn the "structure" of the language by analysing vast amounts of text. The approach is **statistical** rather than being based on brittle rules. In some sense, language models capture language syntax, semantics and even common sense knowledge.

While we commonly speak of a word sequence for language modelling, we can abstract the idea to a **sequence of tokens**. A token could be a sentence, a phrase, a word, an n-gram, morpheme, or letter. Where lemmatization is used, multiple surface forms are reduced to a single token. An LM specifies its method of tokenization.

### What are some applications of language models?

Language models are useful in applications that deal with **text generation**. Some examples are optical character recognition, handwriting recognition, speech recognition, machine translation, spelling correction, image captioning, and text summarization.

In speech recognition, the phrases "no eye deer" and "no idea" may sound similar. In spelling correction, "fill the from" may show no spelling errors but in fact "fill the form" is the correct phrase. In both these examples, an LM selects the more probable phrase. In machine translation, LM can tell that "high winds tonight" is a better translation than "large winds tonight".

Gmail's Smart Reply, which suggests short responses to emails, relies on an LM. In healthcare, LMs were shown to obtain generic representations from data of all patients. This led to better prediction models. LMs have been used for paraphrasing text.

Language modelling tasks themselves (such as predicting a word given surrounding words) have been useful in obtaining efficient word embeddings. These embeddings help represent words at the input of a neural network model.

### Which are the main approaches to language modelling?

There are two broad categories of language models:

    + **Count-based**: These are traditional statistical models such as *n-gram models*. Word co-occurrences are counted to estimate probabilities. Variants of n-gram models have also been proposed. *Clustering models* attempt to exploit similarities among words. *Caching models* exploit the fact that once a word is used, it's likely to appear again in that text. *Sentence mixture models* build different models for different sentence types.
    + **Continuous-space**: These use neural networks. They use *word embeddings* as dense word representations in a real-valued vector space. Words that are semantically similar are typically close together in the vector space. Such embeddings solve the data sparsity problem of n-gram models. Unlike n-gram models, these scale well as vocabulary size increases.

### Could you briefly describe n-gram models?

Suppose a sentence S has N words, \(w\_1...w\_N\). Since LM is about finding the probability of S, this is a **joint** probability measure over all N words. Typically, this is decomposed into a product of **conditional** probabilities \(P(S)=\prod\_{i=1}^N P(w\_i|w\_1,...,w\_{i-1})\), where each term is a probability of a word given the previous words in the sentence.

To simplify the problem, we apply **Markov assumption**. This is an approximation in which only some recent words matter. For a bigram model, a word is predicted based on only the preceding word. For an n-gram model, only the preceding (n-1) words are considered. For instance, given a bigram model for the phrase "the cat sat on the mat", \(P(S)=P(the)\cdot P(cat|the)\cdot P(sat|cat)\cdot P(on|sat)\cdot P(the|on)\cdot P(mat|the)\). We can get these probabilities by counting word co-occurrences. For example, \(P(cat|the)=P(the\,cat)/P(the)\).

One problem with n-gram models is **data sparsity**. This means that word sequences not seen in training, may be encountered in real applications, leading to zero probability. Techniques to solve this problem include smoothing, backoff and interpolation.

Typically, 5-gram models are a compromise between computational complexity and performance.

### How can I train or make use of a neural language model?

A neural language model can be learned in an unsupervised or semi-supervised manner but it needs lots of input text. Easy availability of text online (billions of words) has made this feasible. However, words at the input of a neural network must be represented as numbers. This is where word embeddings provide efficient representations.

To train the LM itself, we need a task on which the model has to learn. One task is to predict a word given its surrounding words; or predict the surrounding words given the current word. In fact, these two LM tasks were used when creating word2vec word embeddings. Training an LM in this manner is called **pre-training**.

A pre-trained LM can then be applied to a variety of NLP tasks. However, since each task is different, we do task-specific **fine-tuning** of the LM.

This two-phase approach is practical since a single pre-trained LM can be fine-tuned as the task demands. While pre-training is done on huge volumes of text, fine-tuning takes lot less effort.

### Could you describe some well-known pre-trained neural language models?

Among the well-known NLMs are ELMo, ULMFiT, BERT, GPT, and GPT-2. BERT in particular has spawned many variants: XLM, RoBERTa, XLNet, MT-DNN, TinyBERT, ALERT, DistilBERT, and more.

While ELMo and ULMFiT use LSTM, GPT-2 and BERT are based on transformer architecture. ULMFiT and GPT-2 are unidirectional while BERT is bidirectional. Most models can be applied to any downstream NLP task.

LM pre-training tasks themselves differ across models:

    + **Causal LM**: Used by GPT-2. Current prediction is based on previous hidden state.
    + **Masked LM**: Used by BERT. Some input words are masked and the task is to predict them. Since model is bidirectional, masking improves performance.
    + **Translation LM**: Used by XLM for better machine translation. An input sequence contains tokens from both languages, each with its language embeddings and position embeddings.
    + **Permutation LM**: Used by XLNet. It uses permutation to capture bidirectional context.
    + **Multi-Task LM**: Used by MT-DNN. Model is trained on multiple tasks such as classification, text similarity and pairwise ranking. This regularizes the model better.

### Which are the common techniques used in neural language models?

Models with more parameters or memory units perform better. Increasing the embedding size improves performance but causes undesirable increase in number of parameters. LSTMs are better than RNNs. LSTMs are much better than n-grams on rare words. Models tend to overfit on training data, for which dropout helps (10% for small models, 25% for large models). Character-level embeddings and softmax can reduce the number of parameters. They're also better at out-of-vocabulary words.

To predict the next word, we need to compute the softmax probability. This is expensive for a large vocabulary. Among the different approaches to simplify this are hierarchical softmax, noise contrastive estimation, importance sampling, and self-normalizing partition functions.

To handle rare words, there are neural LMs that make use of morphemes, word shape information (such as capitalization), or annotations (such as POS tags). The use of morphemes has led to morpheme embeddings. When combined with RNN, we obtain word embeddings. Some LMs use character-level embeddings at both input and/or output. This approach avoids morphological analysis.

### How can I evaluate the performance of language models?

The common measure of LM evaluation is called **perplexity**. It's a geometric average of the inverse probability of words predicted by the model. Thus, a lower perplexity implies a better model. Logarithm (base 2) of perplexity is also a common measure. This is called **cross-entropy**. As a thumb rule, a reduction of 10-20% in perplexity is noteworthy.

In practice, an LM is measured by how it performs in an actual application. This is called *extrinsic evaluation*, as opposed to perplexity that's seen as *intrinsic evaluation*. For example, in speech recognition, **Word Error Rate (WER)** is an extrinsic measure of an LM.

It's been difficult to compare LMs because they use different training corpora or evaluation benchmarks. Some published results are unclear about the computation complexity. Sometimes single-model performance numbers are not reported; only performance of ensemble models are reported. Language modelling can benefit from standardized pre-training corpus. Performance should be compared along with model size and resource consumption.

## Milestones

1980

Although smoothing techniques can be traced back to Lidstone (1920), or even earlier to Laplace (18th century), an early application of smoothing to n-gram models for NLP is by Jelinek and Mercer (1980). A better smoothing technique is due to Katz (1987). More smoothing techniques are proposed in the 1990s.

Jul
1989

Bahl et al. propose **decision tree** for language modelling in the domain of speech recognition. Each node has a yes/no question about preceding words. Each leaf has a probability distribution over the allowable vocabulary. Years later, it's noted that tree-based methods may outperform n-gram models but finding the right partitions are hard due to high computational cost and data sparsity.

1992

In decision tree approaches, as the tree grows, each leaf contains fewer data points. This data fragmentation issue can be solved by **exponential models**. Pietra et al. propose one such model using Maximum Entropy distribution. Similar models are proposed in the following years. In general, these models are computationally intensive.

1993

N-gram models look at the preceding (n-1) words but for larger n, there's a data sparsity problem. Huang et al. propose a **skipping n-gram model** in which some preceding words may be ignored or skipped. For example, in the phrase "Show John a good time", the last word would be predicted based on P(time|Show \_\_ a good) rather than P(time|Show John a good). Many such skipping models are proposed through the 1990s.

1995

Due to the success of n-gram models, researchers ignored knowledge-based approaches. Statistical approach eclipsed linguistic approach. N-gram models worked but had little knowledge of language or its deep structures. Well-known researcher Fred Jelinek notes that a combination of statistical and linguist approaches may be required. He notes that we must "put language back into language modeling".

Aug
1998

As a smoothing technique for LMs, the Kneser-Ney method was proposed in 1995. Chen and Goodman introduce a modification of this and name it **Modified Kneser-Ney Smoothing**. Unlike the single discount of Kneser-Ney, the modified method uses different discounts for one, two and more than two counts. Subsequently, Kneser-Ney smoothing on a 5-gram model becomes a popular baseline among researchers.

2001

Bengio et al. point out the **curse of dimensionality** where the large vocabulary size of natural languages makes computations difficult. They propose a **Feedforward Neural Network (FNN)** that jointly learns the language model and vector representations of words. They refine their methods in a follow-up paper from 2003.

2010

Since n-grams and FNNs use a fixed length context, Mikolov et al. propose using a **Recurrent Neural Network (RNN)** for language modelling. Using cyclic connections, information in RNNs is retained for longer time. RNNs can therefore capture long-term dependencies. Only the size of the hidden context layers needs to be fixed. In 2018, Noaman et al. extend this approach to better suit languages with rich morphology or large vocabulary. They tokenize a word into prefix, stem and suffix.

Jan
2013

At Google, Mikolov et al. develop a word embedding called **word2vec**. This is created by training the model on one of two LM tasks: continuous bag-of-words (predict current word based on surrounding words) or continuous skip-gram (predict surrounding words given current word). This is a **log-linear model** due to the use of hierarchical softmax.

Aug
2015

Kim et al. use character-level input embeddings. Input is fed into a CNN followed by a highway network. An LSTM layer does the predictions, which are still at word level. They show that these character-level models have fewer parameters and outperform word-level models, particularly for languages with rich morphology (Arabic, Czech, French, German, Spanish, Russian). In 2016, Jozefowicz et al. explore CharCNN and character-level LSTM at the prediction layer.

Jul
2018

Word embeddings such as word2vec have been popular since their release in 2013. However, they can't handle polysemy (same word, different meanings). This is because they produce a single representation for the word. They capture semantic relations but are poor at higher-level concepts such as anaphora, long-term dependencies, agreement, and negation. This is where LMs become useful. A good LM should capture lexical, syntactic, semantic and pragmatic aspects. NLP researcher Sebastian Ruder notes,

> It is very likely that in a year's time NLP practitioners will download pretrained language models rather than pretrained word embeddings.

Oct
2018

Devlin et al. from Google publish details of an LM they call **BERT**. It's deeply bidirectional, meaning that it uses both left and right contexts in all layers. In November, Google open sources pre-trained BERT models, along with TensorFlow code that does this pre-training. These models are for English. Later in November, Google releases **multilingual BERT** that supports about 100 different languages.

Jan
2019

Lample and Conneau adapt BERT to propose a cross-lingual LM. Model is trained on both monolingual data (unsupervised) and parallel data (supervised). At the input, each language gets its own language and position embeddings. The model uses *Byte-Pair Encoding (BPE)* in which sub-words are the tokens. This improves the alignment of embedding spaces across languages. They obtain state-of-the-art results.

Dec
2019

Here are some new applications of LM. LM enables end-to-end Named Entity Recognition and Relation Extraction, and thereby avoids external NLP tools such as a dependency parser. LM is applied to zero-shot text classification. This work suggests that LMs can be used for meta-learning. A convolutional quantum-like LM is used for product rating prediction. LM uses RNN along with deep topic model to capture both syntax and global semantic structure.

Language Modelling


# GitHub

## Summary

GitHub is a hosting platform for managing source code. GitHub offers source code management with version control and collaboration features. With GitHub, developers have a platform to work together on projects from anywhere.

GitHub is widely used to host and manage open source projects. There's also a licensed version of GitHub named GitHub Enterprise, which allows organizations to install and manage GitHub servers in a data centre or on enterprise cloud. Irrespective of GitHub's freely available hosted version or the enterprise licensed version, its main purpose is to:

* Facilitate version control of source code
* Track aspects of software development
* Collaborate using features such as Wikis, project boards, forking, pull requests and merging
* Provide uniformity in the developers' interaction with the platform

## Discussion

### What are the key terms a developer should know to understand GitHub?

We note a few terms:

    + **Repository**: A place for source code and other files of a project.
    + **Clone**: Download a copy of a repository into a local machine to work on it independently.
    + **Fork**: Copy another's repository into one's own GitHub account. Users usually can't directly update repositories owned by others but can they make changes to the fork.
    + **Branch**: Isolates code changes. A repository can have multiple branches, each serving a specific purpose, such as a bug fix, feature development or experimentation. Each branch doesn't affect the work on other branches.
    + **Pull Request**: Describe the changes and request for a review. Applicable to branches and forks. However, they can be also be used to initiate feature discussions.
    + **Merge**: Take finished work from one branch into a target branch.
    + **Fetch**: Bring changes from a remote repository to the local copy but keep the local copy untouched.
    + **Pull**: A combination of fetch followed by merge.

### What are the key features of GitHub?

Key features of GitHub include but are not limited to:

    + Distributed revision control, meaning that a clone is a complete copy and allows developers to work offline.
    + Collaboration features such as issues management, project boards, wikis, and adding reviewers to the changes being made in the repository.
    + Automation features such as auto labeling of issues, continuous integration, continuous deployment, and change approval based on events.
    + Team management features such as creating individual accounts, assigning individuals a custom role with defined permissions, inviting other members to collaborate on a repository, creating and assigning email notifications rules, and even imposing restrictions when so required.
    + Ability to check for code vulnerability in real time before it gets shipped to production
    + Other security features such as private repositories, two-factor authentication for user accounts, and security audit logs to track who has performed what actions and when.

### How is GitHub different from Git?

Git is a version control software whereas GitHub is a platform that enables multiple developers to collaborate on a project.

Git is installed on the user's machine or a server. Typically, a developer installs Git client tools and starts working on the project. When changes are ready to be shared with others, the developer can push them to a shared online repository. GitHub is one such platform for sharing and collaboration. It's a web-based service that hosts Git repositories.

While Git is focused on version control, GitHub uses Git but also offers many features not native to Git: forking, online editing, branch protection rules, user and team management, encryption key management, email notifications, task tracking, project wikis, marketplace for third-party tools, and more.

Git has its alternatives: Mercurial, Team Foundation Version Control (TFVC), Bazaar, CVS, SVN, Fossil, Perforce (Helix Core), and more. GitHub too has its alternatives. Amazon CodeCommit, Atlassian BitBucket and GitLab are some examples. Organizations can also create and maintain their own online platforms instead of using GitHub. This is called self-hosting.

### What are the high-level steps involved in getting started with GitHub?

To get started with GitHub, a developer should have internet access to interact with the hosting platform. The developer can begin with these basic steps:

    + Create a GitHub account
    + Create a repository or fork an existing repository
    + When creating a repository, control access using the visibility feature
    + Clone the repository, thereby making a local copy
    + Create a new branch
    + Add a new file: this can be any file, even a text file would do as a start
    + Commit and push the changes from local repository to remote repository on GitHub
    + Create a pull request, applicable when your GitHub repository is a fork another *upstream* repository
    + When others submit a pull request to your repository, review the pull request and merge it
    + Invite collaborators to contribute to the repository.

### What tools do I need to interact with GitHub?

A developer can use the following tools:

    + **Web Browsers**: GitHub platform is supported by the latest browser versions of Chrome, Firefox, Safari and Microsoft Edge.
    + **GitHub CLI**: A command-line tool, when installed in the user's system shall be used to interact with various features of the GitHub platform. Using GitHub CLI, a developer can create pull requests, manage bugs, and perform GitHub Actions.
    + **GitHub Desktop**: This is a GUI-based tool that simplifies the interaction with Git and performs actions related to GitHub branches, fetching or pulling changes into the local repository, committing the changes, and pushing the changes to the remote repository on GitHub.
    + **GitHub Mobile**: It's a mobile app compatible with Android and iOS devices, using which the users can manage notifications, collaborate on pull requests and issues, and interact with repositories in GitHub. GitHub Mobile app is currently in beta version and applicable for the GitHub Enterprise Server 3.0+ licensed versions.

### How can I maintain my project source code in the GitHub repository?

If the project involves only text files for version control, one can create and manage the files in the GitHub's user interface using the compatible browsers as a client-side tool. However, it's best to clone the repository to the local machine when the project involves a complex ecosystem such as a Java, Python or JavaScript-based web development. Cloning is also the solution when you want to group multiple file changes into a single commit.

As a prerequisite to perform cloning and working on the repository, you should have a GIT client tool (GIT CLI or GitHub Desktop) installed in the system. To clone, you can do either of these:

    + **GitHub CLI**: `gh repo clone <userName>/<repoName>`
    + **Git Bash**: `git clone https://github.com/<userName>/<repoName>`Create a feature branch in the local repository and start adding the files to the project. Once the changes are done, commit them. Then push the changes to the remote GitHub Repository.

### What are the best practices when using GitHub?

One of the best practices is to have a README file at the root path of the repository. This should capture high-level project information. While creating the repository, the repository owner can choose a suitable license.

Write descriptive commit messages. Don't commit directly to the main branch. Instead use branch and create pull requests. Main branch should always be deployable. Commit with the right email address. Don't commit project dependencies or temporary build or log files. Don't commit configurations since these may hold passwords and other secrets. Many of these can be avoided by writing your `.gitignore` file correctly.

Don't put passwords, API keys, SSH keys and other secrets in code. Secure your account with two-factor authentication (2FA). Use SSH keys and SSH Git URL, which are essential for 2FA.

Lock package versions for all project dependencies. Use GitHub's Code Owners feature for faster reviews. This automatically selects reviewers. Another useful feature is GitHub Organizations for easier access control.

GitHub has published a number of videos that share best practices in many areas: CI/CD, workflow strategies, managing projects, quality control, searching, getting insights, etc.

### How can I contribute to open source projects in GitHub?

GitHub has a search feature allowing developers to look for suitable projects. Once you've selected a project, fork the repository. This allows you to carry out the changes without impacting the original repository.

Read and understand the project guidelines to ensure your contributions will meet the criteria defined. As an example, see the guidelines from the Apache Kafka project.

Once the changes are made in the forked repository, create a pull request to the original project repository. Wait for the review comments from the original repository's collaborators. Address the review comments, if received any, and push the changes. Review gets done and your changes get merged to the original project repository.

Apart from feature development or fixing issues, there are other ways to contribute. These include documenting Wiki pages, providing clarification to issues reported by others, providing examples in the existing documentation, or enhancing the project's Readme file.

## Milestones

Oct
2007

The **first code commit** is done towards the development of the GitHub hosting platform.

Apr
2008

**GitHub's website** is made available by Tom Preston-Werner, Chris Wanstrath, P. J. Hyett, and Scott Chacon.

Jul
2010

GitHub reaches a milestone of hosting one million repositories on its hosting platform.

Apr
2013

GitHub adopts a **new logo** along with a mascot named *Octocat*. Name in the logo capitalizes "G" and "H".
 GitHub reaches a milestone of 3.5 million users. There are a total of 6 million repositories hosted on GitHub.

Oct
2018

**Microsoft acquires GitHub** on October 26, 2018.

Apr
2020

GitHub announces the creation and usage terms of **private repositories**. This is free with no limit on the number of collaborators. Also, users are now allowed to use all the core features of GitHub free of cost.

GitHub


# Android Things

## Summary

Android Things is an operating system released by Google for IoT and embedded devices. It's based on Android, which in turn uses the Linux kernel. It therefore has support for multitasking and virtual memory. It's meant to fit on devices with a limited memory footprint, although 512 MB is the minimum RAM requirement. Android Things therefore targets a different IoT segment compared to microcontroller-based IoT devices.

For Android developers, building IoT apps will be easier via Android Things. They can use familiar tools and interfaces: Android Studio, Android SDK, Google Play Services, Firebase and Google Cloud. Android libraries including Kotlin and RxJava can be used. In addition, Google certifies compatible System-on-Modules (SoMs) and provides the Board Support Package (BSP). **Android Things Console** will enable managed firmware and app updates to IoT devices.

## Discussion

### Why should I use Android Things for my IoT device?

If you're an Android developer, it's going to be easy getting into IoT app development with Android Things. You can use familiar tools and interfaces, along with Firebase and Google Cloud Platform. Google claims,

> If you can build an app, you can build a device

Android Things can run on both 32-bit and 64-bit platforms, on both ARM and x86-based processors. Google certifies SoMs that work with Android Things and also provides the necessary BSPs. The modular design of SoMs enables developers to use them on a development board while prototyping and reuse them on any custom carrier board designed for end products. Development boards such as NXP iMX7D and Raspberry Pi 3 are available for fast prototyping. Android Things Console enables easy management of over-the-air (OTA) firmware updates in a secure manner without service interruption.

At a layer above the OS, **Weave** comes in to enable different devices to communicate using shared schemas. Android Things comes with built-in Weave connectivity. It's to be noted that Weave can be used even without Android Things.

### How is Android Things different from Android?

Android Things uses the same lower layers of the stack as Android. For the application framework, while some APIs are not available in Android Things, the **Things Support Library** has been added. This library provides low-level hardware access (GPIO, PWM, I2C, SPI, UART, etc.), which is not possible with Android.

System apps and content providers typical on Android phones are not installed. In general, APIs that are not available are those that require user input or authentication. Displays are optional. There's no Play Store access for users to download and install apps. As developers, you will probably ship Android Things and your apps on your own custom hardware.

### What's part of the Things Support Library?

There are three parts to this:

    + **Peripheral I/O API**: Allows apps to access and control sensors and actuators using standard interfaces such as GPIO, PWM, I2C, SPI and UART.
    + **User Driver API**: Allows developers to extend framework services. Apps can inject hardware events that other apps can use via Android APIs. For example, a GPS module can update the framework of current location and other apps can use location manager APIs that are already part of Android.
    + **Cloud IoT Core**: Enables IoT data flow management within Google Cloud Platform.

### How does Android Things compare against MCU-based IoT platforms?

Android Things on a dual-core CPU with 512 MB RAM is not the right pick for just blinking LEDs or collecting and sending few bytes of data. It's better suited for gateways and edge devices that require local processing. Running Machine Learning inferences on the device is a possible use case.

This also means that Android Things is unsuitable for a range of processors from 8-bit MCUs to 32-bit ARM Cortex M-series cores. Devices powered by Android Things will also consume much more power than MCUs, although they may be better at implementing security.

### What are the hardware platforms that Android Things supports?

As on May 2018, the following are supported for production:

    + NXP i.MX8M (ARM Cortex A53, 64-bit + QC7000Lite GPU)
    + Qualcomm SDA212 (ARM Cortex A7, 32-bit + QC Adreno 304 GPU)
    + Qualcomm SDA624 (ARM Cortex A53, 64-bit + QC Adreno 506 GPU)
    + MediaTek MT8516 (ARM Cortex A35, 64-bit)Following are for prototyping and testing only:

    + NXP i.MX7D (ARM Cortex A7, 32-bit)
    + Raspberry Pi 3 Model B (ARM Cortex A53, 64-bit)We can note that this covers both 32-bit and 64-bit processors. While Intel Edison and Joule platforms support Android Things, the latter's website no longer lists them. NXP i.MX7D is an SoC, and it has an equivalent SoM and development board.

Both NXP and Intel SoMs include Wi-Fi and Bluetooth for connectivity. Android Things also supports IEEE 802.15.4 for LoWPAN connectivity for which Nordic nRF52840 is a supported platform.

### What tools and resources are available for working with Android Things?

The following may be a starting point for developers:

    + Android Studio command line (CL) tools: adb, apkanalyzer, dumpsys, logcat ...
    + android-things-setup-utility: CL tool to flash image
    + Android Things Console: manage images and push updates to devices
    + pio: access Peripheral I/O via adb shell (dev/debug)
    + lowpanctl: access LoWPAN via adb shell (dev/debug)
    + Android Things native library: access Peripheral I/O natively in C/C++ when extra performance is needed
    + Android Things main website and docs
    + Code samples
    + Peripheral Driver Library: open source driver code contributed by community that provide higher-level API on top of Peripheral I/O API
    + Google's IoT Developers Community on Google+
    + Hackster.io/google to get inspired by community projectsWhen using Intel hardware, UPM and MRAA libraries can simplify peripheral I/O interfacing. They offer an alternative to Google's Things Support Library and Peripheral Driver Library.

## Milestones

2011

Google makes a first attempt with IoT by announcing *Android@Home*, which never took off even as late as 2013.

May
2015

Google announces *Brillo* as the operating system for IoT devices. Brillo is derived from Android and uses the latter's lower layers: kernel and hardware abstraction layer. It's supposed that Brillo requires only 32 MB of RAM. This was later claimed to be a 'rumour'.

Dec
2016

Google rebrands Brillo as *Android Things*. Android Things is created based on developer feedback on Brillo. Unlike Brillo, which was based on C++, Android Things allows Android developers to code in Java and use familiar tools, interfaces and services they are already used to.

Dec
2017

Developer Preview 6.1 is released. It's based on Android 8.1 developer preview, can target apps using API level 27 and supports SDK 11.6. APIs are introduced for LoWPAN. It's clearly stated that this preview may have stability issues.

Jan
2018

At CES 2018 in Las Vegas, some vendors showcase products that include Android Things. In general, smart speakers integrate Android Things with Google Assistant while smart displays integrate Android Things with Google Cast.

Mar
2018

Developer Preview 7 is released with many new features in Android Things Console.

May
2018

Android Things 1.0 is released with long-term support for production devices. This includes support for new SoMs, and configuration and control of Peripheral I/O via Android Things Console.

Feb
2019

Google refocuses Android Things as a **platform for OEM partners**. Over the last year, Google has already been working with vendors of smart speakers and smart displays, shipping Android Things with Google Assistant built-in. Therefore, on the public developer platform, there won't be any further support for SoMs based on NXP, Qualcomm, and MediaTek hardware. On the Android Things Console, projects based on NXP i.MX7D and Raspberry Pi 3B will be limited to 100 devices for non-commercial use.

Jan
2021

From January 5th, Android Things Console doesn't allow new projects based on NXP i.MX7D and Raspberry Pi 3B. The Console can be used till January 5th, 2022 for existing projects. After that date, all project data include build configurations and factory images will be deleted.

Android Things


# Telegram Splitting Ultra Narrow Band

## Summary

Telegram Splitting Multiple Access (TSMA) is a technique in which a telegram or packet is broken up into many sub-packets. These sub-packets are then pseudo-randomly distributed over frequency and time. This makes the transmission resilient to interferers. Some sub-packets may be lost but data can still be recovered due to Forward Error Correction (FEC). Telegram Splitting Ultra Narrow Band (TS-UNB) is a protocol family that adopts TSMA.

TSMA was invented at Fraunhofer IIS. It was subsequently adopted by ETSI as part of the **Low Throughput Network (LTN)** standard. LTN specifies three different protocol families in the sub-GHz band and TS-UNB is one of them. Radio characteristics, PHY/MAC/link layers and profiles are specified for TS-UNB.

TS-UNB is commercialized under the trademark MIOTY and promoted by the MIOTY Alliance.

## Discussion

### What are the radio characteristics of TS-UNB?

TS-UNB is defined in license-free bands 868 MHz (Europe) and 915 MHz (US). Channel bandwidth is based on the TSMA mode: Narrow (25 kHz), Standard (100 kHz), and Wide (750 kHz). The corresponding carrier spacing is about 397 kHz, 2.4 MHz, and 28.6 MHz.

Radio-burst duration is based on the protocol mode: UL-ULP (15.14 ms), UL-ER (90.74 ms), and DL-TS-ULP (11.76-12.43 ms), for Ultra Low Power (ULP), Extended Reach (ER) and Time Splitting (TS). A radio burst is followed by radio idle time, thus limiting the duty cycle as per the TSMA pattern.

In DL-TS, a message is split and sent across many radio bursts. A set of radio bursts carrying one message is called a **radio frame**. Bursts are spread across 24 carriers (C0-C23). Carrier C24 is reserved for the optional Sync-Burst. Radio frame consists of core frame and extension frame:

    + Uplink: Core (24 bursts) plus additional extension frame (one radio burst for every extra byte) if PHY payload exceeds 186 bits.
    + Downlink: Core (9 bursts repeated to fill 18 bursts) plus optional extension frame (18 bursts per block, multiple blocks).

### What are the operation modes in TS-UNB?

TS-UNB has a few operation modes. An LTN system must implement one subset. Downlink modulation can be GMSK (with telegram splitting) or GFSK (with single burst) whereas uplink modulation is always GMSK (with telegram splitting). Variable MAC mode allows implementers to define custom MAC/link layers or use Wireless M-Bus.

The standard defines **TS-UNB Profiles**, which are sets of modes to enable interoperability between endpoints and base stations. The following profiles are defined:

    + **EU0**: For Europe. Telegram splitting. Single channel. 100 kHz bandwidth. Standard TSMA mode.
    + **EU1**: Similar to EU0 but dual channel.
    + **EU2**: Similar to EU1 but 750 kHz bandwidth and Wide TSMA mode.
    + **US0**: Similar to EU2 for U.S. bands.In addition, device classes are defined. **Class Z** devices are uplink only. **Class A** devices are capable of bidirectional communication, with downlink transmission at the base station triggered by an uplink reception. Class A devices negotiate at the link layer some operation modes. The configuration is fixed in the standard for Class Z devices.

### How is a TSMA pattern selected for the next transmission?

Within a radio frame (core + extension), the time-frequency allocation for transmission is called a **TSMA Pattern**. A group of patterns is called a **TSMA Pattern Group**. Patterns and their groups are fixed in the standard.

Uplink has three groups: UPG1 (8 patterns), UPG2 (8 patterns) and UPG3 (1 pattern). UPG1 is for a single transmission. UPG2 is for initial and repeat transmissions of a radio frame. UPG3 is to achieve low latency. Downlink has only one group called DPG (8 patterns).

For UPG1 and UPG2, the endpoint shall use the patterns in the sequence `(1,2,3,4,1,2,3,4,5,1,2,3,4,5,6)` and repeat this sequence. Pattern 6 is used only for attach process, pattern 7 for high priority messages and pattern 8 is reserved. For extension frame, the pattern is selected pseudo-randomly. In downlink, the pattern is selected pseudo-randomly based on the Header CRC field. The same pattern is used for both core and extension frames.

### What's frame repetition in TS-UNB?

For better performance due to redundancy, a radio frame may be repeated. This is possible in both uplink and downlink. In uplink, the initial and repeated radio frames shall have identical data. Applicable pattern is UPG2. In downlink, extended frame is not repeated. Downlink repeated frame uses the second half of the TSMA pattern.

Header CRC and Payload CRC fields of the uplink PHY payload are calculated and set by the endpoint. These fields are available to the base station. They determine the time offset and frequency offset for the repeat transmission. Time offset is zero for initial transmission. Frequency offset is zero for single channel transmission. Frequency offset is always the same for initial and repeat transmissions.

The use of repetition itself is configured at the link layer during the attach procedure.

### What are the PHY layer functions in TS-UNB?

TS-UNB doesn't define any **time synchronization** across the network. A radio frame starts when the first burst is sent by an endpoint. This starting point is randomly chosen by the endpoint.

In the downlink, **block slicing** happens. Each Block PSDU is limited to 24 bytes and gets its own CRC. This improves error detection. Moreover, if a Sync-burst is used on the core frame, it's also used on each extension frame, thus aiding the receiver.

Long sequences of zeros or ones can cause problems at the receiver. This is prevented by doing **data whitening** using the PN9 pseudo-random sequence generator.

For **error correction**, convolutional code at rate 1/3 is used.

Finally, PHY payload is split into many sub-packets. This is done via **interleaving**, which assigns the bits to each sub-packet and then places the bits in the correct order within each burst. In the uplink, CRC fields and PSI appear in core frame. In the case of DL-SB, PHY payload is sent in a single burst without splitting.

### What's the format of a TS-UNB radio burst?

Uplink PHY PDUs are sent out as multiple radio bursts over the radio frame. Each burst has 12-bit data, 12-bit pilot sequence (PS) and another 12-bit data. Pilot sequences differ for the core frame and the extension frame.

In downlink, the core frame is to used to acknowledge the uplink endpoint transmission. Thus, it may be used on its when there's nothing to send on the downlink. Extension frame carries the PHY PDUs in blocks. Each block has a slice of the PPDU called **Block PSDU** of at most 24 bytes. For DL-TS, each burst has at the minimum 8-bit PS, 12-bit data and another 8-bit PS. A burst in an extension frame can contain two more data fields of variable length.

A downlink Sync-burst may precede the core frame and therefore each block. A core frame Sync-burst has 5-bit PS, 12-bit data, and another 4-bit PS. Sync-bursts in the extended frame have variable number of pilot symbols depending on symbol availability.

### What are the MAC layer functions in TS-UNB?

MAC takes care of **scheduling**. While uplink transmission may start anytime, downlink transmission starts 16,384 symbols after receiving the last uplink radio burst. Time offsets are based on midpoints of the pilot sequence within each burst.

Response flag in the MAC header announces the downlink window. Both uplink and downlink MAC headers have a response flag. If set, the receiver is expected to **acknowledge** the reception. However, base station may ignore this flag due to its limited transmission duty cycle. When priority flag is set in the downlink, endpoint should acknowledge within a time window.

MAC does endpoint **addressing**. Downlink addressing is implicit in the timing and CMAC. Uplink addressing is via a 16-bit short address (received during attach procedure) or a globally unique IEEE EUI64 address.

MAC does **encryption** of its payload. Except for the attach packet request, all others are encrypted. AES128 algorithm is used. The attach procedure provides information to determine the 128-bit network key based on pre-shared private key. In addition, MAC generates and includes a 32-bit CMAC for the integrity and authenticity of each packet.

### What are the link layer functions in TS-UNB?

Link layer establishes and maintains a connection between the endpoint and the base station. It has a number of control segments to achieve this: Attach Request/Accept, Detach Request/Accept, DLRX-Status Query/Response, Link Adaptation Request/Confirm, and user-specific control segments. Attach requests are sent by endpoint. Detach requests can be sent by either end. Detach disconnects the endpoint from the network. Since class Z devices are unidirectional, they're pre-attached during manufacturing.

During attach request/accept and link adaptation request, endpoint and base station agree on the capabilities via the Endpoint Info field: single/dual channel, use of repetition, DL interblock distance, etc. A default configuration is used for the attach procedure.

Apart from its control functions, the link layer also relays to MAC data payload coming from the network layer above.

### What's the TS-UNB PDU structure at different layers?

At the link layer, the same format is used both in uplink and downlink. LPDU consists of control payload and data payload. Control payload can contain one or more control segments. Each control segment includes a 2-bit header to indicate the type of control message such as Attach, Detach, Link Adaptation, etc.

At MAC, fixed mode and variable mode have different formats. MPDU in variable mode has the same format in uplink and downlink. The chosen mode is indicated by the MMode field in PPDU. SIGN field is a Cipher-based Message Authentication Code (CMAC).

At PHY, uplink PSDU is 20-255 bytes. PSDU less than 20 bytes is zero-padded and padding is ignored for CRC calculation. Payload CRC is based on MPDU and MMode. Header CRC is based on Payload CRC and PSI. Packet Size Indicator (PSI) gives the actual size before padding. In the downlink, the same PPDU format is used for both DL-SB and DL-TS. Downlink PSDU is 7-250 bytes.

## Milestones

Sep
2011

Fraunhofer-Gesellschaft zur Förderung der angewandten Forschung e.V. files a German **patent** that introduces the concept of telegram splitting. Their analysis shows that the probability of losing a telegram decreases when it's split into more packets. Curve 170 in the figure shows packet error probability while other curves show telegram error probability. The patent is subsequently published in the U.S. as US20140176341 (June 2014).

Sep
2014

ETSI publishes an initial set of documents that specify the architecture, protocols, interfaces and use cases of **Low Throughput Networks (LTNs)**. At this point, there's no explicit mention of telegram splitting.

Dec
2015

Fraunhofer-Gesellschaft zur Förderung der angewandten Forschung e.V. apply for a German **trademark on MIOTY**. International and U.K. trademarks are filed in May 2016. Subsequently, these applications are approved and registered. MIOTY becomes the commercial name for Fraunhofer's LPWAN solution that adopts TS-UNB as the underlying protocol. Sisvel International manages the licensing of MIOTY and this is announced in April 2020.

Jun
2018

ETSI publishes two documents: **TS 103 357: Protocols for radio interface A** and **TS 103 358: LTN Architecture**. For the radio interface A, the standard defines three different families. TS-UNB is one of them, thus becoming an industry standard.

Telegram Splitting Ultra Narrow Band