Ciro Santilli @cirosantilli  40

The first thing we had to do with the sample was to extract the DNA present in the water in a pure form for the PCR.

We did that with a Qiagen DNeasy PowerWater Kit.

As you would expect, this consists of a purification procedure with several steps.

In each step we take a physical or chemical action on the sample, which splits it into two parts: the one with the DNA and the one without.

We then take the part with the DNA, and throw away the one without the DNA.

The first steps are coarser, and finer and finer splits are done as we move forward.

More generic PCR information at: Section "Polymerase chain reaction".

Because it is considered the less interesting step, and because it takes quite some time, this step was done by the event organizers between the two event days, so participants did not get to take many photos.

PCR protocols are very standard it seems, all that biologists need to know to reproduce is the time and temperature of each step.

We did 35 cycles of:

This process used a Marshal Scientific MJ Research PTC-200 Thermal Cycler:

We added PCR primers for regions that surround the 16S DNA. The primers are just bought from a vendor, and we used well known regions are called 27F and 1492R. Here is a paper that analyzes other choices: academic.oup.com/femsle/article/221/2/299/630719 (archive) "Evaluation of primers and PCR conditions for the analysis of 16S rRNA genes from a natural environment" by Yuichi Hongoh, Hiroe Yuzawa, Moriya Ohkuma, Toshiaki Kudo (2003)

One cool thing about the PCR is that we can also add a known barcode at the end of each primer as shown at Code 1. "PCR diagram".

This means that we bought a few different versions of our 27F/1492R primers, each with a different small DNA tag attached directly to them in addition to the matching sequence.

This way, we were able to:

Input: Bacterial DNA (a little bit)
... --- 27S --- 16S --- 1492R --- ...

|||
|||
vvv

Output: PCR output (a lot of)
Barcode --- 27S --- 16S --- 1492R

Finally, after purification, we used the Qiagen QIAquick PCR Purification Kit protocol to purify the generated from unwanted PCR byproducts.

Once we had the amplified 16S DNA, we were almost ready to start sequencing!

Because Ciro's a software engineer, and he's done enough staring in computers for a lifetime already, and he believes in the power of Git, he didn't pay much attention to this part ;-)

According to the eLife paper, the code appears to have been uploaded to: github.com/d-j-k/puntseq. TODO at least mention the key algorithms used more precisely.

Ciro can however see that it does present interesting problems!

Because it was necessary to wait for 2 days to get our data, the workshop first reused sample data from previous collections done earlier in the year to illustrate the software.

First there is some signal processing/machine learning required to do the base calling, which is not trivial in the Oxford Nanopore, since neighbouring bases can affect the signal of each other. This is mostly handled by Oxford Nanopore itself, or by hardcore programmers in the field however.

After the base calling was done, the data was analyzed using computer programs that match the sequenced 16S sequences to a database of known sequenced species.

This is of course not just a simple direct string matching problem, since like any in experiment, the DNA reads have some errors, so the program has to find the best match even though it is not exact.

The PuntSeq team would later upload the data to well known open databases so that it will be preserved forever! When ready, a link to the data would be uploaded to: www.puntseq.co.uk/data

Protocols are the biologist term for "recipe".

I found that a lot of biology comes down to this: get the right recipe, follow it well even though you don't understand all the proprietary details, and pray.

Includes its own copy of sqlite3, you don't use the system one, which is good to ensure compatibility. The version is shown at: github.com/mapbox/node-sqlite3/blob/918052b538b0effe6c4a44c74a16b2749c08a0d2/deps/common-sqlite.gypi#L3 SQLite source is tracked compressed in-tree: github.com/mapbox/node-sqlite3/blob/918052b538b0effe6c4a44c74a16b2749c08a0d2/deps/sqlite-autoconf-3360000.tar.gz horrendous. This explains why it takes forever to clone that repository. People who don't believe in git submodules, there's even an official Git mirror at: github.com/sqlite/sqlite

It appears to spawn its own threads via its C extension (since JavaScript is single threaded and and SQLite is not server-based), which allows for parallel queries using multiple threads: github.com/mapbox/node-sqlite3/blob/v5.0.2/src/threading.h

Hello world example: nodejs/node-sqlite3/index.js.

As of 2021, this had slumped back a bit, as maintainers got tired. Unmerged pull requests started piling more, and better-sqlite3 Node.js package started pulling ahead a little.

As claimed on their README, their operation truly appears to be 10x faster than the node-sqlite package!! It is insane!! How can that other package still exist at all?

The only big problem was the lack of ORM, but people are looking into that by adding it to Sequelize:

At least they have a fucking clear course schedule unlike the undergrad.

Isomers were quite confusing for early chemists, before atomic theory was widely accepted, and people where thinking mostly in terms of proportions of equations, related: Section "Isomers suggest that atoms exist".

Microwave only found applications into the 1940s and 1950s, much later than radio, because good enough sources were harder to develop.

One notable development was the cavity magnetron in 1940, which was the basis for the original radar systems of World War II.

Not done yet as of 2020! Will be done one day for sure.