Когда мы говорим о децентрализации, мы уже давно не подразумеваем революцию, наоборот, только эволюционный подход, показывает себя оптимальным. И сегодня гораздо меньше людей делает ставку на появление кардинально новых институтов, вместо этого, DeFi стремится решить существующие проблемы, предлагая более эффективные подходы к областям, которые традиционно страдали от непрозрачности и коррупции.

И дело не ограничивается только финансами. Сегодня мы уже говорим о децентрализованных идентификаторах, рынках предсказаний, автономных организациях. Всем тем, что сегодня принято называть DeSoc или децентрализованным сообществом. И если целью DeFi является построение более доступной, прозрачной и эффективной финансовой системы, то DeSoc видит своей целью улучшение всего общества и его институтов.

Когда был максимальный курс доллара к евро?

Вот небольшая программа, вычисляющая это:

curl -s https://www.ecb.europa.eu/stats/eurofxref/eurofxref-hist.zip \ | gunzip \ | sqlite3 -csv ':memory:' '.import /dev/stdin stdin' \ "select Date from stdin order by USD asc limit 1;"

Результат: 2000-10-26. (Можете попробовать запустить её самостоятельно.)

В этой статье я хочу дать поверхностное представление о том, как работает взаимодействие с MOEX ISS на Python requests. Да, сегодня уже существуют готовые решения для работы с MOEX, например aiomoex. Но как по мне, лучше всегда сначала что‑то захардкодить и понять, как это работает под капотом. Если вы только знакомитесь с MOEX ISS или начинаете заниматься анализом временных рядов, думаю, вам эта статья будет полезна. Если же вы более продвинутый специалист, то вряд ли найдете здесь что‑то новое.

Эта история началась в начале марта этого года. ChatGPT тогда был в самом расцвете. Мне в Telegram пришёл Саша Кукушкин, с которым мы знакомы довольно давно. Спросил, не занимаемся ли мы с Сашей Николичем языковыми моделями для русского языка, и как можно нам помочь.

И так вышло, что мы действительно занимались, я пытался собрать набор данных для обучения нормальной базовой модели, rulm, а Саша экспериментировал с существующими русскими базовыми моделями и кустарными инструктивными наборами данных.

После этого мы какое-то время продолжали какое-то время делать всё то же самое. Я потихоньку по инерции расширял rulm новыми наборами данных. Посчитав, что обучить базовую модель нам в ближайшее время не светит, мы решили сосредоточиться на дообучении на инструкциях и почти начали конвертировать то, что есть, в формат инструкций по аналогии с Flan. И тут меня угораздило внимательно перечитать статью.

Современный мир насыщен данными, анализ информации становится критически важным инструментом для принятия обоснованных решений. Однако просто иметь данные не достаточно – необходимо извлечь из них ценную информацию. В этом процессе статистические тесты и проверка гипотез играют важнейшую роль. Они позволяют нам сделать выводы на основе данных, опираясь на строгие методы анализа, и тем самым способствуют принятию обоснованных решений.

Статистические тесты – это мощный инструмент, который позволяет провести объективную оценку данных и проверить гипотезы, основанные на этой информации. Они позволяют определить, насколько вероятно, что наблюдаемые различия или закономерности случайны, а не реально существующие в популяции. Статистические тесты позволяют избежать ошибок и предоставляют научно обоснованный подход к анализу данных.

Поговорим о том, как можно приближать значения различных ветвей W-функции Ламберта, а после применим полученные результаты для решения задачи поиска кратчайших доверительных интервалов.

Реализации анонимных сетей всегда стремятся быть как можно проще, доступнее для понимания, как на теоретическом, так и на программном уровнях. Такие условия становятся необходимыми вследствие одного из основных принципов построения безопасных программ — чем проще объяснить, тем легче доказать. Но к сожалению теория часто может расходиться с практикой, и то, что легко объяснить в теории, может быть проблематично объяснять на коде.

Вследствие этого, можно сказать just-for-fun, у меня появился вопрос: можно ли реализовать анонимную сеть настолько малую, чтобы её программный код смог понять даже начинающий программист за короткое время?

T был одной из лучших реализаций языка программирования Lisp и установил стандарт лаконичного дизайна, который был превзойдён лишь немногими более новыми диалектами. В этой статье Олин Шиверс вспоминает историю T.

...или точнее попытка декомплилировать знаменитый портфель от Рэя Далио и перестроить его с учетом современных реалий.

Меня всегда интересовало, как построить для себя пассивный инвестиционный портфель, который бы генерил доходность, сопоставимую с индексным фондом, но с меньшими относительными просадками в периоды кризисов. На первый взгляд, невыполнимая задача со стороны теоретиков эффективного рынка. Со временем размышления на тему привели меня к изучению так называемых “вечных” (permanent) портфелей. Одним из таких портфелей является портфель “На все времена” (All-weather или All-seasons portfolio).

Класс анонимных сетей с теоретически доказуемой анонимностью является достаточно интересным по той лишь простой причине, что таковым сетям не страшен глобальный наблюдатель, они способны работать и функционировать даже в заведомо враждебных и полностью прослушиваемых средах.

Хомяки приветствуют вас друзья!

Сегодняшний пост будет посвящен радиометру Atom-Scan, универсальному самодельному прибору, который может работать c разными счетчиками Гейгера включая слюдяные, а так же детектировать альфа, бета и гамма излучение. В ходе поста посмотрим как собрать такое устройство, где достать дефицитные радиокомпоненты и как правильно настроить схему чтобы все работало. По традиции смоделируем и напечатаем корпус на фотополимерном 3D принтере, проведем сравнительный тест счётчиков, а так же попытаемся разобраться какой дозиметр на сегодняшний день самый лучший.

Эту полу-шуточную теорию о проектном управлении я излагал коллегам по ИТ цеху лет 15 назад, и тогда же неоднократно слышал советы загрузить этот текст на Хабр, но руки не дошли. На днях, разгребая старые файлы наткнулся на свои записи и решил все таки поделиться ими с Вами. Частое употребление ключевого слова к сожалению, неизбежно и не отделимо для целостности этого текста, прошу принимать или нет 'as is'. Итак...

Каждая карьера развивается от Жопы к Жопе, и никак иначе. Хочешь повышения - ищи Жопу и принимай, как говорят в Америке, "challenge". Если Вам предлагают возглавить новый проект, либо занять какую то должность, да что угодно - знайте, там Вас ждет Жопа. Иначе не предложили бы, а сами бы справились. Равно как и если Вы ожидаете избавиться от надоевшей Вам сейчас деятельности, надеясь вырваться из "этого ада" и заняться "чем то новеньким" - будьте готовы встретиться с Большой Жопой.

Читателю не столь хорошо знакомому с теоретической информатикой может показаться удивительным, что нижние оценки известны лишь для малого числа задач. Когда оценивают сложность алгоритма, используют -нотацию — асимптотически верхнюю оценку на сложность алгоритма. Так, хорошо известно, что у сортировки слиянием сложность Из теории известно, что ни одна сортировка сравнениями не может сортировать асимптотически лучше чем за (пишут ), отсюда для сортировки слиянием берётся нижняя оценка. Верхняя оценка сложности алгоритма, решающего задачу, является и верхней оценкой сложности самой задачи, поэтому сортировки сравнениями имеют точную асимптотическую оценку .

Большинство нижних оценок имеют вид , где традиционно длина входа. Увы, наука чаще всего умеет доказывать только простые вещи в духе «для решения задачи необходимо считать весь вход». Даже для сортировок не ограниченных только доступом к сравнениям нижняя оценка остаётся открытым вопросом (при дополнительных ограничениях на вход за линейное время работает, например, Counting Sort). Чаще всего во вводных курсах по алгоритмам и книжках можно встретить нижние оценки для задач на взвешивание: поиск максимума за сравнение, одновременный поиск максимума и минимума за сравнений, и ещё несколько подобных задач. За исключением нескольких простых хорошо известных примеров, задачи на нижние оценки часто оказываются либо сложными, либо требуют знакомство со специальной (математической) техникой, нужной для их решения. Какого же было моё удивление, когда я встретил среди задач, используемых на вступительных испытаниях в Школу анализа данных Яндекса задачу на нижние оценки, которую можно решить достаточно простым способом!

Это глава 37 раздела «HTTP API & REST» моей книги «API». Второе издание книги будет содержать три новых раздела: «Паттерны API», «HTTP API и REST», «SDK и UI‑библиотеки». Если эта работа была для вас полезна, пожалуйста, оцените книгу на GitHub, Amazon или GoodReads. English version on Substack.

Перейдём теперь к конкретике: что конкретно означает «следовать семантике протокола» и «разрабатывать приложение в соответствии с архитектурным стилем REST». Напомним, речь идёт о следующих принципах: операции должны быть stateless; данные должны размечаться как кэшируемые или некэшируемые; интерфейсы взаимодействия между компонентами должны быть стандартизированы; сетевые системы многослойны.

Эти принципы мы должны применить к протоколу HTTP, соблюдая дух и букву стандарта: URL операции должен идентифицировать ресурс, к которому применяется действие, и быть ключом кэширования для GET и ключом идемпотентности — для PUT и DELETE; HTTP‑глаголы должны использоваться в соответствии с их семантикой; свойства операции (безопасность, кэшируемость, идемпотентность, а также симметрия GET / PUT / DELETE‑методов), заголовки запросов и ответов, статус‑коды ответов должны соответствовать спецификации.

Сейчас все облачные платформы, построенные по принципу Cloud Native, используют виртуализацию и контейнеризацию для реализации микросервисной архитектуры. Поэтому здесь и далее мы будем говорить о безопасности виртуальных машин (VM), понимания под ними как полную виртуализацию, так и паравиртуализацию и контейнеры (Docker и т.п.). Идеалом для пользователя облака было бы получить безопасность своих удаленных виртуальных машин такую же (или почти такую же), как при локальной работе. Как этого достичь?

Речь пойдет о технологиях, доступных уже сейчас, но применение которых еще должно найти свою нишу.

Глубокое понимание внутреннего устройства DRBD позволяет более тонко настраивать работу системы и правильно планировать ресурсы. К счастью, у команды DRBD уже есть отличная документация, которая довольно подробно разбирает эту тему. Мы опирались на нее в своей работе, и решили перевести и выложить в открытом доступе 17-ю главу — как удобную шпаргалку по внутреннему устройству DRBD. Так что это не обычная статья, а перевод части официальной документации (исходная нумерация разделов сохранена).

В этой главе представлена информация о внутренних алгоритмах и структурах DRBD. Она довольно подробно рассматривает внутреннюю работу DRBD, но делает это не настолько глубоко, чтобы служить справочником для разработчиков. Для этой цели рекомендуем обратиться к материалам, перечисленным в разделе Publications, и, естественно, к комментариям в исходном коде DRBD.