Daniel Standage

@standage

Joined on Jul 10, 2017

  • mh01WL-005.v1 mh01WL-006.v3 mh01WL-010.v1 mh01WL-033.v1 mh01WL-070 mh01WL-087 mh02KK-134.v4 mh02SHY-001.v1 mh02USC-2pC mh02WL-002.v2
     Like  Bookmark
  • Prompt I'm writing a Python program. I have data in the following structure. { "A": [ 10, 11 ], "B": [ 20
     Like  Bookmark
  • Abstract Under construction. Background Microhaplotypes have emerged in recent years as a novel type of genetic marker with promising qualities, and interest in their applications continues to grow within the forensics, anthropology, and population genetics communities. A microhaplotype (microhap or MH) has been defined as a short region of DNA that 1) spans multiple common SNPs 2) exhibiting multiple allelic combinations that 3) can be spanned by a single next generation sequencing (NGS) read (CITATION Kidd 2014). In 2016, Kidd proposed nomenclature guidelines for microhaps (CITATION Kidd 2016). According to the proposed specification, each microhaplotype is assigned an identifier composed of a standard fixed prefix ("mh"), a two-digit chromosome label, a unique symbol representing the laboratory or principal investigator publishing the microhap, a hyphen, and a lab-specific number or designation. For example, mh05KK-170 refers to the Ken Kidd lab's microhap #170 on chromosome 5. This proposal has been adopted widely as a de facto standard in the forensic genetics literature (Table 1) and community resources like the MicroHapDB database (CITATION Standage 2020). Table 1. Identifiers of a representative set of microhaplotypes published by several independent laboratories.
     Like  Bookmark
  • import pathlib import random import re mouse_names = [ "mouse1", "mouse2", "mouse3", ]
     Like  Bookmark
  • Bioinformatics Twitter is having...a moment. What began as one man's exasperated rant against poorly documented and distributed code has bloomed into a protracted debate about what constitutes "good" bioinformatics software and which kind(s) of interfaces developers should be expected to provide if they "really" want people to use their software. For those that have been around long enough, this dialogue has a familiar tenor. I don't remember ever seeing a big controversy specifically about GUIs versus CLIs, but the dynamics on either side of the debate seem to play out again and again. Barring significant structural changes, we should expect to repeat variations of this argument with each new academic generation. Since before the term "bioinformatics" was in common use, developers of bioinformatics software have become accustomed to having their contributions trivialized ("they're just glorified techs; we at the bench are the real scientists") and their expertise exoticized ("they're geniuses, wizards, masters of the arcane; I could never learn that"). These attitudes are frankly insulting, both to bioinformaticians and to bench scientists. It is true---to an extent, when requirements are well understood and clearly articulated---that implementing bioinformatics software can be primarily a technical exercise (although the tendency to use "technical" as the opposite of "intellectual" is also mildly insulting). But the same can be said of bench work: when protocols are well established and the study system well understood, lab work is "just technical." The important intellectual component of bench work comes in the design and interpretation of experiments. The parallel in bioinformatics is the development of models and the design of software components and notation to guide implementation and build intuition, and the structuring and formatting of outputs to facilitate interpretation. Of course, when studying any sufficiently interesting or novel question, software requirements will be poorly understood at the onset and elastic throughout development. Crafting accurate and stable software under such conditions requires considerable training, experience, agility, and creativity. Insinuating that if bioinformaticians really cared they would provide a "simple" GUI is a fallacy that perpetuates a dismissive attitude toward the work that goes into bioinformatics software engineering. It's almost more uncomfortable when a biologist with a bench background introduces me to their friends as "a bioinformatician" with raised eyebrows and knowing glances, as if I'm an acolyte of some forbidden mystic art. Bench biologists routinely bring extensive domain expertise and technical competence to bear in the laboratory, interfacing with complex instrumentation and equipment to perform tasks of no small complexity. No bench scientist expects that they should be able to proficiently perform a sophisticated multi-stage lab procedure and interpret the outcome without a fair amount of time spent in reading, preparation, and trial & error. So it's a wonder that anyone regards bench scientists as incapable of using bioinformatics software for which menus, tabs, buttons, and drop-downs have not been provided. Nobody should pretend that this isn't condescending. Both sides of the ongoing debate can probably agree on the sad state of bioinformatics software, too much of which is poorly documented, not very portable, difficult to install, and unreliable. The disagreement lies, at least partially, in the role that GUIs can or should play in addressing this issue, and how the attitudes described above are reflected, implicitly and unwittingly, in the debate. With all that as context, I want to respond to a handful of common myths and fallacies about bioinformatics software, GUIs, CLIs, and related topics that have featured in the ongoing debate. (And just in case any reader is unfamiliar, a GUI is a graphical user interface, and a CLI is a purely textual command line interface.)
     Like  Bookmark
  • Murat Özel From a very young age, Murat Özel (moo-Raht Oer-zil) was fascinated by fire, which was a constant source of trouble for him. As a child, his curiosity sparked numerous house fires, severely damaging the family's kitchen in one case and consuming the entire house in another. His mother died delivering Murat, and while his father was affectionate, the demands of providing for the small family left little time for leisure or sentiment. As a teenager, Murat worked as an apprentice (and later journeyman) foreman at an explosives manufacturer in Ankara. The plant had produced explosives for the Ottoman Empire during the great war, but since Turkey had thus far remained neutral in the escalating European conflicts, the work had become slow and unprofitable. Although the job barely put food on the table, Murat wouldn't have traded the job for anything—it gave him unlimited access to the forge's fires and the chemical accelerants that powered the explosives produced by the plant. He would frequently bring trace excess materials home to fashion his own custom explosives—he never had nefarious intent, yet he frequently got himself in trouble at home and elsewhere with his tinkering. One fateful day at the factory, Murat slipped and fell into a vat of a fluid explosive reagent. The fluid was shallow and did little to break his fall, and thus he was knocked unconcious when his head struck. Fortunately, his mouth and nose remained uncovered, and he survived several hours half submerged before he regained consciousness. Murat nearly died from chemical poisoning, and his eyes were damaged by the exposure, requiring him to get spectacles with a strong prescription. But after only a couple of weeks he felt fully recovered and returned to work. His first day back at work, Murat felt a strange new sensation. He attempted to ignore it and focus on his work all day, but failing to shake the feeling, he soon realized he could control the intensity of the new sensation. Curious, he lowered the intensity until he could hardly detect it, and then elevated it almost to a fever pitch. At peak intensity, Murat's skin emitted an intense incendiary explosion that caused severe damage to some nearby equipment. Fortunately, he was able to explain the incident away as an industrial accident. Murat continued working at the factory into adulthood, as he saw the Nazi threat spread across Eastern Europe. It became clear that Turkey would not be entering the conflict any time soon, and wanting to do his part to fight back, Murat enlisted with a British grenadier corps that was recruiting in Ankara. He quickly mastered his new weaponry, but also proved himself as a master demolitions expert and borderline pyro-maniac.
     Like  Bookmark