И с УФ лампы есть, их для лечения кожных заболеваний используют. Такое лечение вроде бы тоже светотерапией называется.
А какую пожизненную дозу витамина Д принимаешь ты?
Принимал небольшие дозы, типа 2000ME в день. Пробовал больше, но мне любые оральные дозировки помогают лишь отлепить стрелку спидометра от нуля, а добрать до физиологически нормальных 20-30 nm/mL так и не получалось.
И, если можно, названия тестов генотипирования или ссылка на Хеликс\Инвитро
Тестом было полноэкзомное секвенирование в UCLA, там же потыкали мои исходники на актуальные на тот момент SNPы перед тем как вручить их мне. Я не помню как называется моя кондиция, но суть в том, что с возрастом снизилась выработка одной из желчных кислот, которая по несчастливому совпадению и занимается всасыванием нужных жирорастворимых витаминов из ЖКТ.
Крутой материал! У самого семейная наследственная история SAD, мне лично помогает только передислокация в более солнечные места в зимний период.
Хотелось бы ещё чуть сильнее подчеркнуть важность витамина Д, для российских IT-работников это особенно актуально из-за постоянного нахождения внутри помещений в нечастые солнечные часы средней полосы России. Последний раз на сдаче уровней витамина Д у меня его вообще не нашли. И я четко помню интересное ощущение разливающейся по телу энергии в первые дни, когда я начал прием витамина в жидкой форме.
К сожалению, у меня и одного из родителей генетически сниженная усвояемость пищевого витамина Д. Особенность нашли при генотипировании и скорее всего она и является основной причиной SAD. Наверное проблему можно было решить лампами, но мне оказалось удобнее в зимние месяцы уезжать ближе к экватору или вообще на другую половну шара.
Мне вот тупо любопытно, это у меня одного так, или это распространённый кейс?
Первый случай — если компания с крупными R&D отделами, то и алгоритмы и математика в ней будут. В поисковиках с такими задачами сталкиваешься. Не то чтобы каждый день, но периодически во что-нибудь влипаешь.
Второй случай — считается, что железо дешевле программистов, но иногда у разросшейся компании наступает момент, когда оказывается выгоднее заняться оптимизацией, а не закидывать пожары железками. И в такие времена всплывают все аккуратно разложенные по кодовой базе тройные циклы for.
А иногда к коду сразу жесткие требования предъявляют, в HFT, например.
Другое дело, что на собесах задавать алгоритмические задачи любят сейчас все, вне зависимости от необходимости их использования в дальнейшем. Это такой удобный способ хоть что-нибудь проверить у человека, когда просто не знаешь что проверять.
Слюна не капает — чекд, разворот дерева написал — чекд. Ок, берем.
Для погромистов на настоящих языках Rust оставлю здесь crate https://docs.rs/fst/0.4.4/fst/
Эта реализация трансдюсеров — лучшая из всех что я встречал.
У меня на входе было 100 миллионов ключей со средней длиной 25 байт. У групп ключей часто встречался общий префикс от 7 байт и до двух третей всей длины строки. Ещё нужно было 8 байт для значения, в качестве value были числа от 1 до N. Итого 2.5Гб ключей + 800 Мб значений.
После засовывания всего добра в fst, выхлоп занял около 240 мегабайт в памяти, при этом вся структура сериализуется в файл и может mmapиться прямо из этого файла, не требуя никаких дополнительных приседаний.
LZMA на этих же ключах, соединенных через \n дал даже чуть больший размер и это без возможности RA и префиксного поиска.
Если же упороться дальше и сам выхлоп fst прогнать через LZMA, то байтов получится в два раза меньше — 116 Мб.
Из минусов — иммутабельность и необходимость класть ключи в отсортированном порядке, поэтому для миллиардов ключей придется вспомнить решения любимых задач на собеседованиях про merge sort на файлах.
Но для задачи из ОП-поста вроде можно обойтись и так.
Я иногда сталкивался с выстрелами в ноги из-за неявного приведения чего угодно к bool и соответствующей привычки программистов на Python. Из самой неприятной реальной ситуации было что-то типа
if token.user_id:
check_permissions(token)
где контекст ситуации подразумевал, что token без user_id может существовать и не требует проверок, так как его выписка осуществляется специальным образом. Где-то в другом месте затесалась бага, позволявшая выписать токен на user_id = 0, возможно это случилось из-за protobuf3 и его значений по умолчанию для всех полей.
Ну и в итоге в этом месте все усилия по авторизации были поделены на ноль и мы поимели дырищу в безопасности (inb4 хоть что-то у вас в безопасности).
После этого я всегда стараюсь использовать проверки if x is None, вместо простого if not x, хотя второе выглядит идиоматичнее.
Такое поведение вызывает сожаление. Я и сам вместе с большинством населения по-настоящему обратил внимание на коронавирус только в феврале-марте, когда финансовые рынки поехали вниз. Хотя времени у нас было с декабря прошлого года, но оно было упущено. До того значимость нарастающей эпидемии в лучшем случае игнорировалась, а в худшем — маскировалась действиями диссидентов.
С изменением климата ситуация в чем-то похожа. Действия топливных лоббистов и неразумных граждан заставляют нас терять время.
Но все же я вижу последнее время, что отрицание изменения климата постепенно маргинализируется и ставится на одну доску с другими отрицаниями типа отрицания существования ВИЧ или отрицания высадки американцев на Луну, что не может не радовать. Необходимо продолжать активно заниматься изучением климата и просвещением окружающих в этой области, только так получится добиться внесения этой проблемы в актуальную повестку.
К этому не стоит относится легкомысленно, человечество — это не процент территории, и не юниты, которых можно выделить и отправить на край карты. Одной из причин упадка Римской Империи стало похолодание и спровоцированное им великое переселение народов. К чему приведут миграции и перестройки из-за сильных климатических изменений в гораздо более густонаселенном мире тяжело представить. Вот основная угроза, а не превращение планеты в парник. Хотя и последнюю перспективу лучше не скидывать со счетов.
Довольно хорошо изученный пример — волны миграций из-за ближневосточных войн уже вызывают хоть и небольшое, но все же заметное социальное напряжение.
На космическом масштабе все пыль и ничего не имеет смысла, даже разговоры про смысл. Это я к чему — все идеи приспособления прекрасно выглядят на бумаге или в учебниках истории. А вот когда выяснится что ни конкретно вам, ни мне в новом прекрасном мире места не будет, то ситуация начинает выглядеть не так весело.
Если уж быть точным, то вы написали что осознание проблемы ничего не изменит, а не то, что кризис наступит в любом случае. Это все же разные вещи.
За оставшуюся часть ответа спасибо, так понятнее.
Совершенно непонятно что вы хотели сказать. Потепление для природы может и обычное явление, а вот для миллиардов людей, населяющих эту природу такое будет происходить впервые.
Не знаю в какой вселенной осознание проблемы ничего не меняет. В моей – меняет и более того, решение любой проблемы начинается с осознания наличия этой проблемы.
Меня больше всего удивляет то, что голос экологов сродни вопиющему в пустыне.
Неужели не очевидно, что человечеству пора бить в набат? Уж как я сам лично был далёк от алармизма и экодвижухи, но в последние годы появилось достаточно свидетельств того, что мы разогреваем планету и спустя десятилетия огромные территории превратятся в пустыни, а миграции людей разрушат весь привычный нам мир. Эти свидетельства невозможно игнорировать и даже закрывать на них глаза — последствия начнем ощущать и мы, и наши дети.
На каждом из нас лежит большая ответственность и очень хотелось бы призвать всех читателей к освещению проблемы среди своего окружения.
Рыночная капитализация к количеству кэша на счетах мало отношения имеет.
Если совсем упростить ситуацию, то у вас есть учетная книга. Допустим, что в ней сведенный баланс (читай маркеткап) — 7.7 миллиардов долларов. Вы берете кредит на 40 миллиардов. В книгу в столбец "кредиторская задолженность" пишете -40 миллиардов долларов, в столбец "свободный кеш на счетах" — +40 миллиардов долларов. По итогу, сведенный баланс как был 7.7 миллиардов, так и остался, потому что две новые позиции просальдировались.
Bazel умеет, он пересобирает только ту часть графа и перезапускает только те тесты, которые напрямую или транзитивно зависят от файлов, измененных с момента последнего запуска.
Если не секрет, сколько строк (или гигабайт) кода в ней?
Не секрет, если взять только *.py файлы и выкинуть контрибы — 1.1M LOC, порядка сотни сервисов. Самих контрибов из PyPI больше 10M LOC. Кроме этого, в репо живет столько же JS кода и на порядок меньше С++/Go. И это, кстати, было гораздо более весомым аргументом в пользу Bazel, чем менеджмент Python и его зависимостей.
Один requirements.txt на всю репу означает, что никакие части вашей кодовой базы не имеет конфликта версий
Это так. Монорепа использовалась с самого начала (2017 год), количество зависимостей в requirements.txt (полный список, через pip freeze) — 318.
Три описанных сценария комментировать не буду, потому что ни один из них в полной мере не подходит. Редкие пакеты действительно могут быть старыми. Наугад потыкал сейчас в наиболее известные пакеты (numpy, flask, scipy, sqlalchemy) — все версии в пределах последних 2-4 месяцев. Обновление пакетов правда занимает больше времени, чем в случае мультирепы из-за необходимости фиксить тесты во всех местах. Из хорошего — в GitLabе есть инструменты для коллаборативных PR, так что в особо запущенные тесты можно позвать более близких к коду людей. Из-за конфликта версий можно подвиснуть и иногда даже приходится лезть во внешние гитхабы для рассылки фиксов. Это тоже проблема, но она еще ни разу не становилась полным блокером.
по-хорошему эти пакеты еще должны проходить security audit (иначе вместе с новой версией можно притащить себе уязвимость)
Здесь риски были приняты, потому что аудит кода — далеко не единственный контур защиты. Откровенная упячка не пройдет ревью, менее откровенная упячка фиксится коллективным разумом, подписанным на security digestы. В общем и целом же компромис сдвинут в сторону более быстрой разработки.
Писать на интерпретируемом языке, а потом ждать сборки бинаря для меня до сих пор выглядит диковато.
Понимаю о чем вы, мне поначалу тоже казалось странным. Со временем перестаешь обращать внимание. Ну либо у меня уже развился стокгольмский синдром:)
Совместимость с PyPI — это возможность бесшовно вкорячивать пакеты с PyPI внутрь репозитория? Если да, то способ сделать такую монорепу есть.
Для bazel имеется набор правил https://github.com/bazelbuild/rules_python, в нем есть правило pip_import импорта внешних пакетов с PyPI. Они скачиваются и становятся доступными как объекты сборки наравне с собственными библиотеками монорепы. После первоначальной настройки вся работа заключается в том, что в корне репы поддерживается файл requirements.txt, а все бинарники в своих правилах сборки получают возможность указать необходимые зависимости из PyPI. Код импортирует эти зависимости как обычно.
При таком подходе герметичность может страдать, поскольку в bazel пока нельзя задавать контрольные суммы скаченных библиотек, а что там может случиться на pypi.org никто не знает. Эту проблему можно решить поддержкой собственного зеркала PyPI. Даже если отбросить разгерметизацию сборки, зеркало полезно, когда сборка начинает запускаться на десятках машин/сотни раз в день.
Правила сборки py_binary/par_binary из того же bazel позволяют запаковать код в нечто, похожее на монобинарь, вместе со всеми его зависимостями.
Ну и еще я знаю, что некоторые кладут в их монорепу сам код зависимостей. Про удобство рассуждать не могу, но такое тоже работает.
К примеру автоматически фиксировать новую версию общего кода только когда и если все автотесты прошли успешно для этого конкретного репозитория, а иначе уведомлять разработчиков «ребята, фиксите свой код и сливайтесь с новым общим».
В правильно построенном CI в монорепозитории так и происходит: на каждый PR запускается набор необходимых тестов и зеленый свет на влитие включается только после их успешного прохождения.
А неконсистентность может быть только на период пока код в репозитории ломается от новой версии общего кода, но это и монорепозиторий не решает.
Ровно эту проблему монорепа и решает! Если поддерживать тесты в зеленом состоянии в каждом влитом пулл-реквесте, то в любой момент времени HEAD версия репозитория валидна и готова к бою.
Ну а принуждение к исправлению проблем «здесь и сейчас» (т.е. перед влитием в мастер/транк) автором изменения вместо «потом и неизвестно кем», когда отработает некоторая механика — это и есть один из столпов монорепозиториев. Где-то такой подход считается более удачным. Но давайте не будем об этом спорить:)
Связанность все равно получается слабая, ведь головной репозиторий контролирует какой из коммитов сабмодуля сейчас используется. Изменения в сабмодулях не прорастут автоматом в головной репозиторий и общая кодовая база может стать немного неконсистентной. Так что сабмодули больше похожи на разделенные репозитории, чем на моно.
И с УФ лампы есть, их для лечения кожных заболеваний используют. Такое лечение вроде бы тоже светотерапией называется.
Принимал небольшие дозы, типа 2000ME в день. Пробовал больше, но мне любые оральные дозировки помогают лишь отлепить стрелку спидометра от нуля, а добрать до физиологически нормальных 20-30 nm/mL так и не получалось.
Тестом было полноэкзомное секвенирование в UCLA, там же потыкали мои исходники на актуальные на тот момент SNPы перед тем как вручить их мне. Я не помню как называется моя кондиция, но суть в том, что с возрастом снизилась выработка одной из желчных кислот, которая по несчастливому совпадению и занимается всасыванием нужных жирорастворимых витаминов из ЖКТ.
Крутой материал! У самого семейная наследственная история SAD, мне лично помогает только передислокация в более солнечные места в зимний период.
Хотелось бы ещё чуть сильнее подчеркнуть важность витамина Д, для российских IT-работников это особенно актуально из-за постоянного нахождения внутри помещений в нечастые солнечные часы средней полосы России. Последний раз на сдаче уровней витамина Д у меня его вообще не нашли. И я четко помню интересное ощущение разливающейся по телу энергии в первые дни, когда я начал прием витамина в жидкой форме.
К сожалению, у меня и одного из родителей генетически сниженная усвояемость пищевого витамина Д. Особенность нашли при генотипировании и скорее всего она и является основной причиной SAD. Наверное проблему можно было решить лампами, но мне оказалось удобнее в зимние месяцы уезжать ближе к экватору или вообще на другую половну шара.
Первый случай — если компания с крупными R&D отделами, то и алгоритмы и математика в ней будут. В поисковиках с такими задачами сталкиваешься. Не то чтобы каждый день, но периодически во что-нибудь влипаешь.
Второй случай — считается, что железо дешевле программистов, но иногда у разросшейся компании наступает момент, когда оказывается выгоднее заняться оптимизацией, а не закидывать пожары железками. И в такие времена всплывают все аккуратно разложенные по кодовой базе тройные циклы for.
А иногда к коду сразу жесткие требования предъявляют, в HFT, например.
Другое дело, что на собесах задавать алгоритмические задачи любят сейчас все, вне зависимости от необходимости их использования в дальнейшем. Это такой удобный способ хоть что-нибудь проверить у человека, когда просто не знаешь что проверять.
Слюна не капает — чекд, разворот дерева написал — чекд. Ок, берем.
Для погромистов на
настоящих языкахRust оставлю здесь crate https://docs.rs/fst/0.4.4/fst/Эта реализация трансдюсеров — лучшая из всех что я встречал.
У меня на входе было 100 миллионов ключей со средней длиной 25 байт. У групп ключей часто встречался общий префикс от 7 байт и до двух третей всей длины строки. Ещё нужно было 8 байт для значения, в качестве value были числа от 1 до N. Итого 2.5Гб ключей + 800 Мб значений.
После засовывания всего добра в fst, выхлоп занял около 240 мегабайт в памяти, при этом вся структура сериализуется в файл и может mmapиться прямо из этого файла, не требуя никаких дополнительных приседаний.
LZMA на этих же ключах, соединенных через \n дал даже чуть больший размер и это без возможности RA и префиксного поиска.
Если же упороться дальше и сам выхлоп fst прогнать через LZMA, то байтов получится в два раза меньше — 116 Мб.
Из минусов — иммутабельность и необходимость класть ключи в отсортированном порядке, поэтому для миллиардов ключей придется вспомнить решения любимых задач на собеседованиях про merge sort на файлах.
Но для задачи из ОП-поста вроде можно обойтись и так.
Да, imo так нужно писать всегда при возможности.
Я иногда сталкивался с выстрелами в ноги из-за неявного приведения чего угодно к bool и соответствующей привычки программистов на Python. Из самой неприятной реальной ситуации было что-то типа
где контекст ситуации подразумевал, что token без user_id может существовать и не требует проверок, так как его выписка осуществляется специальным образом. Где-то в другом месте затесалась бага, позволявшая выписать токен на user_id = 0, возможно это случилось из-за protobuf3 и его значений по умолчанию для всех полей.
Ну и в итоге в этом месте все усилия по авторизации были поделены на ноль и мы поимели дырищу в безопасности (inb4 хоть что-то у вас в безопасности).
После этого я всегда стараюсь использовать проверки if x is None, вместо простого if not x, хотя второе выглядит идиоматичнее.
Такое поведение вызывает сожаление. Я и сам вместе с большинством населения по-настоящему обратил внимание на коронавирус только в феврале-марте, когда финансовые рынки поехали вниз. Хотя времени у нас было с декабря прошлого года, но оно было упущено. До того значимость нарастающей эпидемии в лучшем случае игнорировалась, а в худшем — маскировалась действиями диссидентов.
С изменением климата ситуация в чем-то похожа. Действия топливных лоббистов и неразумных граждан заставляют нас терять время.
Но все же я вижу последнее время, что отрицание изменения климата постепенно маргинализируется и ставится на одну доску с другими отрицаниями типа отрицания существования ВИЧ или отрицания высадки американцев на Луну, что не может не радовать. Необходимо продолжать активно заниматься изучением климата и просвещением окружающих в этой области, только так получится добиться внесения этой проблемы в актуальную повестку.
К этому не стоит относится легкомысленно, человечество — это не процент территории, и не юниты, которых можно выделить и отправить на край карты. Одной из причин упадка Римской Империи стало похолодание и спровоцированное им великое переселение народов. К чему приведут миграции и перестройки из-за сильных климатических изменений в гораздо более густонаселенном мире тяжело представить. Вот основная угроза, а не превращение планеты в парник. Хотя и последнюю перспективу лучше не скидывать со счетов.
Довольно хорошо изученный пример — волны миграций из-за ближневосточных войн уже вызывают хоть и небольшое, но все же заметное социальное напряжение.
На космическом масштабе все пыль и ничего не имеет смысла, даже разговоры про смысл. Это я к чему — все идеи приспособления прекрасно выглядят на бумаге или в учебниках истории. А вот когда выяснится что ни конкретно вам, ни мне в новом прекрасном мире места не будет, то ситуация начинает выглядеть не так весело.
Если уж быть точным, то вы написали что осознание проблемы ничего не изменит, а не то, что кризис наступит в любом случае. Это все же разные вещи.
За оставшуюся часть ответа спасибо, так понятнее.
Совершенно непонятно что вы хотели сказать. Потепление для природы может и обычное явление, а вот для миллиардов людей, населяющих эту природу такое будет происходить впервые.
Не знаю в какой вселенной осознание проблемы ничего не меняет. В моей – меняет и более того, решение любой проблемы начинается с осознания наличия этой проблемы.
Меня больше всего удивляет то, что голос экологов сродни вопиющему в пустыне.
Неужели не очевидно, что человечеству пора бить в набат? Уж как я сам лично был далёк от алармизма и экодвижухи, но в последние годы появилось достаточно свидетельств того, что мы разогреваем планету и спустя десятилетия огромные территории превратятся в пустыни, а миграции людей разрушат весь привычный нам мир. Эти свидетельства невозможно игнорировать и даже закрывать на них глаза — последствия начнем ощущать и мы, и наши дети.
На каждом из нас лежит большая ответственность и очень хотелось бы призвать всех читателей к освещению проблемы среди своего окружения.
Автору большой поклон за статью.
Банки постоянно это делают. Важна не стоимость компании, а ее способность обслуживать кредит. Эти две величины связаны далеко не напрямую.
Полная стоимость включает в себя как кэш на счетах, так и задолженность.
За 7 миллиардов вполне можно купить компанию, на счетах которой 33 миллиарда долларов и 26 миллиардов кредиторской задолженности.
Рыночная капитализация к количеству кэша на счетах мало отношения имеет.
Если совсем упростить ситуацию, то у вас есть учетная книга. Допустим, что в ней сведенный баланс (читай маркеткап) — 7.7 миллиардов долларов. Вы берете кредит на 40 миллиардов. В книгу в столбец "кредиторская задолженность" пишете -40 миллиардов долларов, в столбец "свободный кеш на счетах" — +40 миллиардов долларов. По итогу, сведенный баланс как был 7.7 миллиардов, так и остался, потому что две новые позиции просальдировались.
Пошёл менять в резюме «удаленщика» на «викторианского джентельмена-ученого».
Bazel умеет, он пересобирает только ту часть графа и перезапускает только те тесты, которые напрямую или транзитивно зависят от файлов, измененных с момента последнего запуска.
Не секрет, если взять только *.py файлы и выкинуть контрибы — 1.1M LOC, порядка сотни сервисов. Самих контрибов из PyPI больше 10M LOC. Кроме этого, в репо живет столько же JS кода и на порядок меньше С++/Go. И это, кстати, было гораздо более весомым аргументом в пользу Bazel, чем менеджмент Python и его зависимостей.
Это так. Монорепа использовалась с самого начала (2017 год), количество зависимостей в requirements.txt (полный список, через pip freeze) — 318.
Три описанных сценария комментировать не буду, потому что ни один из них в полной мере не подходит. Редкие пакеты действительно могут быть старыми. Наугад потыкал сейчас в наиболее известные пакеты (numpy, flask, scipy, sqlalchemy) — все версии в пределах последних 2-4 месяцев. Обновление пакетов правда занимает больше времени, чем в случае мультирепы из-за необходимости фиксить тесты во всех местах. Из хорошего — в GitLabе есть инструменты для коллаборативных PR, так что в особо запущенные тесты можно позвать более близких к коду людей. Из-за конфликта версий можно подвиснуть и иногда даже приходится лезть во внешние гитхабы для рассылки фиксов. Это тоже проблема, но она еще ни разу не становилась полным блокером.
Здесь риски были приняты, потому что аудит кода — далеко не единственный контур защиты. Откровенная упячка не пройдет ревью, менее откровенная упячка фиксится коллективным разумом, подписанным на security digestы. В общем и целом же компромис сдвинут в сторону более быстрой разработки.
Понимаю о чем вы, мне поначалу тоже казалось странным. Со временем перестаешь обращать внимание. Ну либо у меня уже развился стокгольмский синдром:)
Совместимость с PyPI — это возможность бесшовно вкорячивать пакеты с PyPI внутрь репозитория? Если да, то способ сделать такую монорепу есть.
Для bazel имеется набор правил https://github.com/bazelbuild/rules_python, в нем есть правило
pip_importимпорта внешних пакетов с PyPI. Они скачиваются и становятся доступными как объекты сборки наравне с собственными библиотеками монорепы. После первоначальной настройки вся работа заключается в том, что в корне репы поддерживается файлrequirements.txt, а все бинарники в своих правилах сборки получают возможность указать необходимые зависимости из PyPI. Код импортирует эти зависимости как обычно.При таком подходе герметичность может страдать, поскольку в bazel пока нельзя задавать контрольные суммы скаченных библиотек, а что там может случиться на pypi.org никто не знает. Эту проблему можно решить поддержкой собственного зеркала PyPI. Даже если отбросить разгерметизацию сборки, зеркало полезно, когда сборка начинает запускаться на десятках машин/сотни раз в день.
Правила сборки
py_binary/par_binaryиз того же bazel позволяют запаковать код в нечто, похожее на монобинарь, вместе со всеми его зависимостями.Ну и еще я знаю, что некоторые кладут в их монорепу сам код зависимостей. Про удобство рассуждать не могу, но такое тоже работает.
В правильно построенном CI в монорепозитории так и происходит: на каждый PR запускается набор необходимых тестов и зеленый свет на влитие включается только после их успешного прохождения.
Ровно эту проблему монорепа и решает! Если поддерживать тесты в зеленом состоянии в каждом влитом пулл-реквесте, то в любой момент времени HEAD версия репозитория валидна и готова к бою.
Ну а принуждение к исправлению проблем «здесь и сейчас» (т.е. перед влитием в мастер/транк) автором изменения вместо «потом и неизвестно кем», когда отработает некоторая механика — это и есть один из столпов монорепозиториев. Где-то такой подход считается более удачным. Но давайте не будем об этом спорить:)