Исследуем пакетный менеджер Nix и операционную систему NixOS.
Ранее мы разработали универсальный скрипт сборки для проектов autotools.
Сегодня мы обратимся к программе GNU hello, чтобы исследовать зависимости времени сборки и времени выполнения.
User
Исследуем пакетный менеджер Nix и операционную систему NixOS.
Ранее мы разработали универсальный скрипт сборки для проектов autotools.
Сегодня мы обратимся к программе GNU hello, чтобы исследовать зависимости времени сборки и времени выполнения.
На сайте hackerrank.com есть отличная задача. По заданному массиву short[] A;
найти максимальное количество его подмассивов, xor
элементов которых будет одинаковым. Сам этот xor
тоже нужно найти.
Максимальная длина массива равна 105, так что квадратичный алгоритм не укладывается в лимит по времени исполнения. Я в своё время с этой задачей не справился и сдался, решив подсмотреть авторское решение. И в этот момент я понял почему не справился — автор предлагал решать задачу через дискретное преобразование Фурье.
Метод конечных элементов (МКЭ) применяют в задачах упругости, теплопередачи, гидродинамики — всюду, где нужно как-то дискретизировать и решить уравнения сплошной среды или поля. На Хабре было множество статей с красивыми картинками о том, в каких отраслях и с помощью каких программ этот метод приносит пользу. Однако мало кто пытался объяснить МКЭ от самых основ, с простенькой учебной реализацией, желательно без упоминания частных производных через каждое слово.
Мы напишем МКЭ для расчёта упругой двумерной пластины на прочность и жёсткость. Код займёт 1200 строк. Туда войдёт всё: интерактивный редактор, разбиение модели на треугольные элементы, вычисление напряжений и деформаций, визуализация результата. Ни одна часть алгоритма не спрячется от нас в недрах MATLAB или NumPy. Код будет ужасно неоптимальным, но максимально ясным.
Размышление над задачей и написание кода заняли у меня неделю. Будь у меня перед глазами такая статья, как эта, — справился бы быстрее. У меня её не было. Зато теперь она есть у вас.
Информация – одно из самых неоднозначных и неопределённых понятий в науке и философии. Для гуманитария это любые сведения, которые можно запомнить и передать в устной или письменной форме. Для математика это абстрактная сущность, сохраняющаяся при вычислительном изоморфизме. Для физика-теоретика это набор квантовых чисел, характеризующих состояние элементарной частицы. Для программиста это цифровые данные, которые можно представить в двоичном коде и измерить в битах. Для философа-материалиста это отражение многообразия окружающего мира с помощью знаков и сигналов. Для философа-идеалиста это нематериальная, неизмеримая и нелокальная сущность, что-то связанное с духом или сознанием. Для эзотериков это некая метафизическая субстанция или информационное поле. Что же такое информация на самом деле? В данной лекции я покажу, что информация – физическая, объективная, измеряемая величина, в которой нет ничего субъективного и мистического. Заодно мы разберёмся, что такое энтропия по Шеннону, насколько избыточен естественный язык, в чём заключается принцип Ландауэра и обладает ли информация массой.
Небольшой обзор систем контроля версий, альтернативных git, и основанных на математической теории. Речь пойдёт о двух системах распределённого контроля версий: Darcs, написанной на Haskell, и Pijul, написанной на Rust. Обе они сейчас активно развиваются и предлагают свои сетевые репозитории. Оказалось, что про них на Хабре толком нет ничего, тогда как про git образовался целый хаб. Поскольку я люблю и использую Haskell, я остановил свой выбор на Darcs, и вот, спустя два месяца непрерывной работы над библиотекой геометрической алгебры для hackage, я готов поделиться впечатлениями от её использования.
На уходящей неделе мне попалась симпатичная, хоть и не новая мини‑серия статей на Дзен‑канале @zdgzdgzdg про процедурную генерацию лабиринта методом «коллапса волновой функции». Пока я читал эти статьи и знакомился с кодом, меня осенило: ведь это же вычисления в комонаде, погружённые в монаду! Я не издеваюсь, действительно, речь идёт о композиции двух паттернов функционального программирования: комонады Zipper
, превращающей локальные правила в глобальное состояние, и монады Random
, позволяющей генерировать случайные объекты.
И вот, в качестве баловства на выходных, я решил реализовать этот «квантовый» алгоритм генерации лабиринтов на Haskell, используя и комонады и монады, и вообще, ни в чëм себе не отказывая. И хотя язык программирования Haskell нужен не только для извращений, но именно для них он подходит идеально!
Стоило только появиться первым рынкам, как торговаться на них стало уже частью процесса продаж. Считалось, что тот, кто не торгуется, получил товар или деньги нечестным путем и дел с ним лучше не иметь. Как раньше, так и в нынешнее время в большинстве случаев создание благ и зарабатывание средств даются тяжелым трудом. Оптимальная цена товара или услуги в таком контексте выступает неким синонимом справедливости.
В данной статье речь пойдет о продаже авиабилетов, но материал также может быть полезен всем, кто заинтересован в оптимальном ценообразовании.
c
. Игреки нужны только для балансировки, это внутренние детали структуры данных, ненужные пользователю. Иксов на самом деле нет в принципе, их хранить не нужно."John"
◦ "Doe"
= "JohnDoe"
"foo"
, "bar"
) = "foo"
""
: с какой стороны к какой строке её ни приклеивай, строка не поменяется. А вот fst в этом отношении нам устроит подлянку: нейтральный элемент для неё придумать невозможно. Ведь public interface IMonoid<T> {
T Zero { get; }
T Append(T a, T b);
}
Kornia это open source библиотека для решения задач компьютерного зрения. Она использует PyTorch в качестве основного бэкенда и состоит из набора дифференцируемых процедур и модулей. Создатели библиотеки вдохновлялись OpenCV, и поэтому Kornia является его аналогом, но при этом в некоторых моментах превосходит. Главным преимуществом Kornia по сравнению с тем же OpenCV, scikit-image или с Albumentations является возможность обрабатывать изображения батчами, а не по одному изображению и возможность обрабатывать данные на GPU.
Приветствую, Хабр! Одной из интереснейших тем для обсуждения из современной криптографии, на мой взгляд, является тема эволюции криптографических ключей и связанных с ними протоколов, обеспечивающих наличие ряда дополнительных полезных свойств систем, основанных на асимметричных криптоалгоритмах.
Различные методы эволюции ключей (терминология не устоялась, предпочитаю использовать такой перевод словосочетания «key-evolving techniques») асимметричных криптоалгоритмов позволяют защититься от компрометации секретных ключей путем периодической модификации ключевых пар. Подобная защита направлена не на предотвращение компрометации секретного ключа, а на минимизацию последствий такой компрометации: поскольку ключи периодически модифицируются, эволюционируют, данные методы позволяют ограничиться отрицательным воздействием компрометации ключа на свойство целостности или конфиденциальности сообщений, зашифрованных или подписанных только в течение определенного, относительно короткого периода, оставляя защиту сообщений других периодов ненарушенной. Большинство протоколов с эволюцией ключей подразумевает достаточно активный обмен сообщениями между сторонами защищенного обмена данными. При этом бывают сценарии, когда возможности для интерактивного взаимодействия у сторон отсутствуют.
Далее предлагаю обсудить различные известные методы эволюции ключей (обеспечивающие различные полезные свойства криптосхем: от секретности в будущем до устойчивости к вторжениям), после чего описать возможный вариант протокола модификации ключевых пар для неинтерактивных применений.
На Хабре и на профильных форумах (типа 4pda) уже достаточно статей на тему того, как отказаться от GPON-роутера от МГТС и вывести интернет напрямую в свой роутер.
Большинство статей описывают опыт подключения к роутерам Mikrotik, прошивок SFP-GPON терминалов, странных хаков по выдёргиванию настроек и прочего. Мне же это всё не подошло и я пошёл иным путём. Требования я составил следующие:
На текущем месте работы столкнулся с необходимости собирать Docker образы для сервисов написанных на Rust. Обычно в таком случае пишется Dockerfile, который внутри докера просто собирает контейнер и все. Но все оказалось не так однозначно: такая схема довольно неплохо работает, когда у тебя есть x86_64 Linux машина, но любой шаг в сторону и начинаются большие проблемы.
Все довольно неприятно уже на Intel MacBook машинах, докер поедает довольно много ресурсов с хоста, а еще возникают всякие странные приколы с монтированием файловой системы и правами доступа. Но настоящий ужас начинается на Макбуках с Apple Silicon процессорами, где обычной виртуализацией уже не обойдешься и можно часами ждать сборки простого сервиса через qemu. Можно решать эту проблему через сборку контейнеров в CI, но когда разработчиков много, а им надо часто что-то пересобирать, то там образовывалась очередь.
Поэтому я начал искать пути, а каким же образом можно избежать в общем-то не нужной виртуализации и в результате нашел довольно успешный и универсальный подход, которым и хочу теперь поделиться.
Имплиситы (implicits) – одна из наиболее вызывающих опасения фич языка программирования Scala, и на то есть веские причины!
Во-первых, понятие имплиcитов довольно специфично для Scala. Ни один другой основной язык программирования не имеет подобной концепции. Это означает, что у начинающих разработчиков Scala нет шаблонов, на которые можно было бы опереться, чтобы правильно использовать имплиситы.
Во-вторых, в Scala 2 ключевое слово implicit используется слишком часто (подобно _
). Поэтому потребуется достаточное количество времени и практики, чтобы провести грань между различными вариантами использования имплиcитов. В этом отношении Scala 3 значительно улучшила ситуацию, введя специальный синтаксис для каждого случая использования имплиcита.
Данная публикация блога будет посвящена Scala 2, поскольку в настоящее время это наиболее используемая основная версия Scala. Однако по ходу статьи я буду упоминать о тех различиях, которые появились в Scala 3 относительно имплиcитов.
На работе я пишу почти исключительно на Python, с университетской скамьи остались некоторые знания C/C++, в одном pet-project использовал Haskell. С таким багажом знаний я взялся за написание компилятора на основе LLVM - зачем и что получилось я уже рассказывал в предыдущей статье.
Эту статью я пишу для тех, кто, как и я, заинтересован в изучении Haskell, создании собственных языков программирования, или хочет поиграться с LLVM - но не знает с какого конца подойти к задаче.
Я кратко расскажу про необходимый минимум знаний Haskell, про свои ошибки и к каким решениям я пришел - а так же про решения, к которым я не пришел, и про которые узнал позже - и как их можно интегрировать в ваш pet-компилятор. На все это я по возможности дам ссылки на изучение.
Привет, Хабр! Меня зовут Дмитрий Алексеев, я Data Scientist и являюсь участником профессионального сообщества NTA. Сегодня расскажу как использовать python и Linux «в связке», и как это поможет облегчить вам жизнь.
Достижение максимальной выразительности и абстракции домена при сохранении точности протокола актора с помощью библиотеки endless4s Scala.
Код, описывающий бизнес-логику, несомненно, является самым ценным активом в системе программного обеспечения. Также называемый кодом домена среди специалистов по доменно-ориентированному проектированию, он отражает опыт и ценностное предложение и постепенно аккумулирует в себя все богатство знаний. Хотя для зрелости таких углубленных моделей требуется время, тенденции и технологии программного обеспечения быстро меняются и даже подвергаются лицензионным изменениям, как это недавно произошло с Akka. Вместе с тем, по мере устаревания языка, методов и фреймворков, ценность программного обеспечения растет по мере расширения клиентской базы.