(disclaimer: я никоим образом не специалист в эволюции, так что не претендую тут на научность высказываемых идей и предположений).
Кажется, можно ставить два вопроса: либо считать изменчивость генотипов на множестве всех живущих людей — тогда архиватором сжать генотипы всего человечества, наверное можно, и наверное вы правы, что неважно.
Либо можно пытаться оценить потенциальную изменчивость генотипов — тогда мы очерчиваем множество геномов по фенотипу: организм должен быть жизнеспособен и всё ещё оставаться человеком.
Возможно, вот эта статья вас заинтересует. На первый взгляд кажется, что статей по теме не очень много, но они всё же есть.
Первый хакатон — это, видимо, Tele2 Hack?
Действительно худший хакатон из десятка, в котором я участвовал: чатбота компания уже самостоятельно делала, а все вменяемые задумки требовали интеграции в общую систему службы поддержки. Посмотрев на датасет и пообщавшись с менторами, подумал ещё часок над вариантами — и ушёл. Победители, сумевшие выкрутиться, — молодцы, но соревноваться на этой поляне было совершенно неинтересно.
Информационное содержание генома относительно референса посчитать полезно, но не думаю, что архиватор справится.
Замены происходят на всех позициях генома. Они не вполне независимы по разным причинам. В первую очередь из-за того, что варианты из поколение в поколение передаются большими «батчами» — целыми хромосомами. Соответственно сцепление вариантов зависит от расстояния между ними (кроссинговеру сложнее разделить близко расположенные варианты, так что близко расположенные варианты образуют гаплотипы — наборы вариантов, которые передаются между поколениями более-менее целиком).
Некоторые участки просто мутируют чаще, чем другие (например, участки активной транскрипции могут мутировать сильнее плотно замотанных участков) — это тоже даст вам зависимость вариантов на уровне расположения. Причем не по близости, а по функциональным характеристикам участков.
Некоторые виды мутаций случаются чаще других, причем это зависит от типа воздействия (например, ультрафиолет и табачный дым дают различающиеся мутационные подписи; всего подписей — десятки).
Ну и давление отбора, конечно, защищает определенные позиции от изменения (так синонимичные замены — т.е. изменения кодона, которые не меняют аминокислоту — случаются чаще несинонимичных).
Иногда варианты зависимы в самом банальном смысле, без скрытых параметров; например, по отдельности варианты могут встречаться, а когда они вместе — это летально.
При этом скорее всего все эти факторы немного отличаются в разных популяциях.
Стоит ещё отметить, что генетические варианты — это не всегда замены; иногда это инсерции или делеции (индели); размножение участка, перенос из хромосомы на хромосому итд. Ну и индель длины не кратной 3 может натворить куда больше проблем, чем сотня точечных замен: удаление/добавление одной буквы ломает рамку считывания — и белок будет абсолютно неправильным. Для архиватора же выкинуть 1 букву или 3 имеет мало разницы.
Добавлю, что VCF-ка, выдаваемая некоторыми популярными методами, не всю изменчивость в состоянии поймать. Это ведь часто не полногеномное секвенирование, а просто «чип», который определяет некоторые популярные варианты (разумеется не фазированно), предполагая, что остальные можно додумать по расположению.
И говоря откровенно мы пока довольно плохо понимаем, какие детали организации генома важны, а какие не слишком. Например, насколько важно, на какой хромосоме расположен ген, или важно только, что он есть. А ведь от таких вопросов вычисленная изменчивость может зависеть очень сильно.
Вы ведь знаете, какой именно комикс я процитирую? ;)
У нас есть как минимум два способа нумерации координат. Ген и имя гена — это отношение много-ко-многим. А про большинство файлов неясно, на какой вариант референсного генома опираются данные там описанные ;) И как минимум у первых двух проблем есть не только исторические причины. Так что всё плохо, но как это исправить — совершенно неясно. У нас проблемы не столько форматов, сколько онтологии: слишком много есть не вполне взаимозаменяемых типов объектов. Часто приходится пользоваться не тем, который идеально подходит, а тем, для которого есть данные — со всеми присущими логическими проблемами при «конвертации».
Оптимальность на уровне числа байт и даже скорости чтения далеко не во всех задачах нужна. А вот то, что вы можете работать с помощью cut, grep etc — весьма полезно. И вы невооруженным глазом видите данные, вам не нужно их открывать в специальной программе — это очень удобно.
Там где всерьез нужна скорость, разумеется, есть более сложные форматы. Это, например, бинарные форматы типа bam для хранения выравниваний ридов. Или вот bgzf (blocked gzip) — сжатие с поддержкой индексирования.
Всё сложно; начиная с того, что «ген» можно понимать по-разному.
Обычно геном обозначают некоторый участок ДНК, отвечающий за синтез некоторого белка (оставим в стороне множество генов, не являющихся белок-кодирующими).
ДНК сначала считывается в РНК (это зовется транскрипцией). Есть участок старта гена, зовущийся промотером. У эукариот, как вам правильно подметили, всё сложно. Промотер чётко не выделяется и вообще стартов транскрипции у гена может быть несколько разных.
Затем альтернативный сплайсинг делает из этих РНК несколько разных изоформ — «транскриптов». И только затем РНК превращается в белок в ходе трансляции. Этот последний этап — единственный более-менее стандартизованный. В генетическом коде, который используется при трансляции, есть последовательности нуклеотидов, маркирующих старт- и стоп-кодоны. Это наиболее похоже на то, что вы описываете, когда говорите про признаки начала и конца (называется это поиском открытой рамки считывания) — но это поиск скорее белка, чем «гена».
Но экспериментально вы можете отсеквенировать РНК и хотя бы понять, где начинается кончается область, которая транскрибируется — так вы имеете шанс поймать границы гена и, если повезет, границы интронов (участков, которые вырезаются при сплайсинге).
В каком-то смысле это про распределение нагрузки, да. Но не только. Скажем, если у вас баласировщик нагрузки не умеет держать долгие соединения, то вебсокеты просто не будут работать. Или будут обрубаться слишком длинные страницы (обыкновенные веб-страницы на 1Mb, например). Дело тут не в нагрузке, а в том, что нужно знать ограничения своих инструментов. Или если вы http-заголовки забываете прокинуть через прокси, то многие вещи в приложении могут отвалиться. Так что переезд из development-режима на production легко может оказаться проблемой даже для ненагруженного сайта.
Но вообще, программисту хорошо бы знать, например, обрабатывает ли инстанс приложения много запросов одновременно, один запрос одновременно или вообще один запрос за время жизни процесса. И проблему непонимания жизненного цикла приложения «балансировщик из коробки» не решает. :)
Было бы хорошо упомянуть среди необходимых знаний минимальное представление о том, что перед веб-сервером типа «приложение» стоит веб-сервер типа nginx, а где-то в промежутке случается веб-сервер типа unicorn (и всё это три разных вещи, которые зовутся веб-сервером, но решают совершенно различные задачи) — и какие ограничения бывают у этих слоёв.
Фуллстэк должен бы понимать, что делает его приложение, когда в него долбится одновременно два запроса. Он также должен понимать, какая часть системы отдает статику и кто отвечает за поддержание долгих соединений (раз уж про веб-сокеты заходит речь).
К теме про прекомпиляцию стилей и скриптов ещё небольшое дополнение — что нередко после компиляции готовые и минифицированные js/css-файлы отправляются на какой-нибудь CDN.
Мне кажется, вашу задачу решил бы обычный Plain Old Ruby Object с обычными валидациями в конструкторе. Это куда более явно, чем код в синтаксисе очередной библиотеки, пусть и популярной.
enum-ы реализуются тривиально, стоит ли ради них тащить библиотеку и её соглашения по синтаксису — неочевидно.
Я понимаю, что в этом весь смысл, но во многих случаях я точно знаю, что у меня в аргументе, и не хочу тратить силы на убеждение компилятора в том, что точно знаю, что делаю
Я немного выше написал, что большая часть кода, с которым мне приходится работать — скрипты. Описания всех схем и промежуточных типов, к которым мне приходится обращаться, увеличит размер кода раза в два, не давая взамен почти никакого профита. Охотно верю, что для крупных проектов статическая типизация имеет смысл, но для мелких проектов она даёт только проблемы.
Вероятно, у нас просто различаются задачи. У меня основной рабочий инструмент — скрипты и не слишком большие числомолотилки. Половина кода там будет тем самым проблемным местом, где статическая типизация бессильна, но тратит много сил на реализацию. Другая половина кода не настолько велика, чтобы нельзя было за время работы с ней не забыть, какого же типа объект передается в переменную с именем matrix.
Кажется, можно ставить два вопроса: либо считать изменчивость генотипов на множестве всех живущих людей — тогда архиватором сжать генотипы всего человечества, наверное можно, и наверное вы правы, что неважно.
Либо можно пытаться оценить потенциальную изменчивость генотипов — тогда мы очерчиваем множество геномов по фенотипу: организм должен быть жизнеспособен и всё ещё оставаться человеком.
Возможно, вот эта статья вас заинтересует. На первый взгляд кажется, что статей по теме не очень много, но они всё же есть.
Действительно худший хакатон из десятка, в котором я участвовал: чатбота компания уже самостоятельно делала, а все вменяемые задумки требовали интеграции в общую систему службы поддержки. Посмотрев на датасет и пообщавшись с менторами, подумал ещё часок над вариантами — и ушёл. Победители, сумевшие выкрутиться, — молодцы, но соревноваться на этой поляне было совершенно неинтересно.
Замены происходят на всех позициях генома. Они не вполне независимы по разным причинам. В первую очередь из-за того, что варианты из поколение в поколение передаются большими «батчами» — целыми хромосомами. Соответственно сцепление вариантов зависит от расстояния между ними (кроссинговеру сложнее разделить близко расположенные варианты, так что близко расположенные варианты образуют гаплотипы — наборы вариантов, которые передаются между поколениями более-менее целиком).
Некоторые участки просто мутируют чаще, чем другие (например, участки активной транскрипции могут мутировать сильнее плотно замотанных участков) — это тоже даст вам зависимость вариантов на уровне расположения. Причем не по близости, а по функциональным характеристикам участков.
Некоторые виды мутаций случаются чаще других, причем это зависит от типа воздействия (например, ультрафиолет и табачный дым дают различающиеся мутационные подписи; всего подписей — десятки).
Ну и давление отбора, конечно, защищает определенные позиции от изменения (так синонимичные замены — т.е. изменения кодона, которые не меняют аминокислоту — случаются чаще несинонимичных).
Иногда варианты зависимы в самом банальном смысле, без скрытых параметров; например, по отдельности варианты могут встречаться, а когда они вместе — это летально.
При этом скорее всего все эти факторы немного отличаются в разных популяциях.
Стоит ещё отметить, что генетические варианты — это не всегда замены; иногда это инсерции или делеции (индели); размножение участка, перенос из хромосомы на хромосому итд. Ну и индель длины не кратной 3 может натворить куда больше проблем, чем сотня точечных замен: удаление/добавление одной буквы ломает рамку считывания — и белок будет абсолютно неправильным. Для архиватора же выкинуть 1 букву или 3 имеет мало разницы.
Добавлю, что VCF-ка, выдаваемая некоторыми популярными методами, не всю изменчивость в состоянии поймать. Это ведь часто не полногеномное секвенирование, а просто «чип», который определяет некоторые популярные варианты (разумеется не фазированно), предполагая, что остальные можно додумать по расположению.
И говоря откровенно мы пока довольно плохо понимаем, какие детали организации генома важны, а какие не слишком. Например, насколько важно, на какой хромосоме расположен ген, или важно только, что он есть. А ведь от таких вопросов вычисленная изменчивость может зависеть очень сильно.
У нас есть как минимум два способа нумерации координат. Ген и имя гена — это отношение много-ко-многим. А про большинство файлов неясно, на какой вариант референсного генома опираются данные там описанные ;) И как минимум у первых двух проблем есть не только исторические причины. Так что всё плохо, но как это исправить — совершенно неясно. У нас проблемы не столько форматов, сколько онтологии: слишком много есть не вполне взаимозаменяемых типов объектов. Часто приходится пользоваться не тем, который идеально подходит, а тем, для которого есть данные — со всеми присущими логическими проблемами при «конвертации».
Там где всерьез нужна скорость, разумеется, есть более сложные форматы. Это, например, бинарные форматы типа bam для хранения выравниваний ридов. Или вот bgzf (blocked gzip) — сжатие с поддержкой индексирования.
Обычно геном обозначают некоторый участок ДНК, отвечающий за синтез некоторого белка (оставим в стороне множество генов, не являющихся белок-кодирующими).
ДНК сначала считывается в РНК (это зовется транскрипцией). Есть участок старта гена, зовущийся промотером. У эукариот, как вам правильно подметили, всё сложно. Промотер чётко не выделяется и вообще стартов транскрипции у гена может быть несколько разных.
Затем альтернативный сплайсинг делает из этих РНК несколько разных изоформ — «транскриптов». И только затем РНК превращается в белок в ходе трансляции. Этот последний этап — единственный более-менее стандартизованный. В генетическом коде, который используется при трансляции, есть последовательности нуклеотидов, маркирующих старт- и стоп-кодоны. Это наиболее похоже на то, что вы описываете, когда говорите про признаки начала и конца (называется это поиском открытой рамки считывания) — но это поиск скорее белка, чем «гена».
Но экспериментально вы можете отсеквенировать РНК и хотя бы понять, где начинается кончается область, которая транскрибируется — так вы имеете шанс поймать границы гена и, если повезет, границы интронов (участков, которые вырезаются при сплайсинге).
Но вообще, программисту хорошо бы знать, например, обрабатывает ли инстанс приложения много запросов одновременно, один запрос одновременно или вообще один запрос за время жизни процесса. И проблему непонимания жизненного цикла приложения «балансировщик из коробки» не решает. :)
Фуллстэк должен бы понимать, что делает его приложение, когда в него долбится одновременно два запроса. Он также должен понимать, какая часть системы отдает статику и кто отвечает за поддержание долгих соединений (раз уж про веб-сокеты заходит речь).
К теме про прекомпиляцию стилей и скриптов ещё небольшое дополнение — что нередко после компиляции готовые и минифицированные js/css-файлы отправляются на какой-нибудь CDN.
enum-ы реализуются тривиально, стоит ли ради них тащить библиотеку и её соглашения по синтаксису — неочевидно.
Я понимаю, что в этом весь смысл, но во многих случаях я точно знаю, что у меня в аргументе, и не хочу тратить силы на убеждение компилятора в том, что точно знаю, что делаю
Это ли не аргумент против того, что "паттерны — штука кросс-языковая"?
Я немного выше написал, что большая часть кода, с которым мне приходится работать — скрипты. Описания всех схем и промежуточных типов, к которым мне приходится обращаться, увеличит размер кода раза в два, не давая взамен почти никакого профита. Охотно верю, что для крупных проектов статическая типизация имеет смысл, но для мелких проектов она даёт только проблемы.
Вероятно, у нас просто различаются задачи. У меня основной рабочий инструмент — скрипты и не слишком большие числомолотилки. Половина кода там будет тем самым проблемным местом, где статическая типизация бессильна, но тратит много сил на реализацию. Другая половина кода не настолько велика, чтобы нельзя было за время работы с ней не забыть, какого же типа объект передается в переменную с именем matrix.
Вы предлагаете кодогенерацию в качестве решения проблемы? Спасибо, но нет.
Я не спорю, что сделать это возможно, но там, где мне достаточно обратиться к элементу, вам дополнительно приходится громоздить type matching.