Skip to main content

DNA Cassette Tape Can Store Every Song Ever Recorded

3 months 2 weeks ago
Researchers in China have developed a "DNA cassette," a retro-styled plastic tape embedded with synthetic DNA strands that can store up to 36 petabytes of digital data -- enough to hold every song ever recorded. New Scientist reports: Xingyu Jiang at the Southern University of Science and Technology in Guangdong, China, and his colleagues created the cassette by printing synthetic DNA molecules on to a plastic tape. "We can design its sequence so that the order of the DNA bases (A, T, C, G) represents digital information, just like 0s and 1s in a computer," he says. This means it can store any type of digital file, whether text, image, audio or video. One problem with previous DNA storage techniques is the difficulty in accessing data, so the team then overlaid a series of barcodes on the tape to assist with retrieval. "This process is like finding a book in the library," says Jiang. "We first need to find the shelf corresponding to the book, then find the book on the corresponding shelf." The tape is also coated in what the researchers describe as "crystal armor" made of zeolitic imidazolate, which prevents the DNA bonds from breaking down. That means the cassette could store data for centuries without deteriorating. While a traditional cassette tape could boast around 12 songs on each side, 100 meters of the new DNA cassette tape can hold more than 3 billion pieces of music, at 10 megabytes a song. The total data storage capacity is 36 petabytes of data -- equivalent to 36,000 terabyte hard drives. The research has been published in the journal Science Advances.

Read more of this story at Slashdot.

BeauHD

CodeSOD: The Getter Setter Getter

3 months 2 weeks ago

Today's Java snippet comes from Capybara James.

The first sign something was wrong was this:

private Map<String, String> getExtractedDataMap(PayloadDto payload) { return setExtractedDataToMap(payload); }

Java conventions tell us that a get method retrieves a value, and a set method mutates the value. So a getter that calls a setter is… confusing. But neither of these are truly getters nor setters.

setExtractedDataToMap converts the PayloadDto to a Map<String, String>. getExtractedMap just calls that, which is just one extra layer of indirection that nobody needed, but whatever. At its core, this is just two badly named methods where there should be one.

But that distracts from the true WTF in here. Why on Earth are we converting an actual Java object to a Map<String,String>? That is a definite code smell, a sign that someone isn't entirely comfortable with object-oriented programming. You can't even say, "Well, maybe for serialization to JSON or something?" because Java has serializers that just do this transparently. And that's just the purpose of a DTO in the first place- to be a bucket that holds data for easy serialization.

We're left wondering what the point of all of this code is, and we're not alone. James writes:

I found this gem of a code snippet while trying to understand a workflow for data flow documentation purpose. I was not quite sure what the original developer was trying to achieve and at this point I just gave up

[Advertisement] Picking up NuGet is easy. Getting good at it takes time. Download our guide to learn the best practice of NuGet for the Enterprise.
Remy Porter