Алгоритмы *

За годы своего развития C# существенно эволюционировал; одна из самых мощных фич языка — это сопоставление с образцом (pattern matching).

Работая недавно над небольшим хобби-проектом, я наткнулся на такую прекрасную строку кода C#.

if (person is not null and { Age: > 18 })

{}

Выглядит изящно. Откровенно говоря, она заставила меня призадуматься.

Годами я писал проверки на null и свойства-аксессоры классическим образом:

if (person != null && person.Age > 18)

{}

Функционально? Да. Удобочитаемо? Не особо. Безопасно? Спорно, особенно когда код становится сложнее.

Я решил создать шорт YouTube об этом современном синтаксисе. Это небольшое забавное напоминание о том, что C# позволяет при помощи сопоставления с образцом комбинировать проверки на null и обращение к свойству в одно условие.

Я понятия не имел, что это короткое видео приведёт к гораздо более глубокому исследованию, и покажет мне, насколько полезно и универсально сопоставление с образцом в современном C#.

Эта фича повышает читаемость, уменьшает объём бойлерплейта и обеспечивает более выразительную обработку логики.

В этой статье мы изучим различные типы образцов, поддерживаемых в C#, их работу и поймём, когда их использовать, на понятных примерах из реального мира.

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

История науки содержит массу примеров такой фразы «отсюда с очевидностью следует» или «легко получить», после которой пишется про как-то полученный результат. Эти фразы сбивают с толку читателя. Приятное исключение представляют работы Ньютона и Эйлера, с оригиналами которых мне довелось познакомиться. Если они демонстрируют вывод формулы, то не опускают даже, казалось бы, очевидных вещей все излагается последовательно без пропусков, подробно комментируется. На память приходит случай с Лапласом, где он получил урок

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

Выслушав вопрос учителя, Лаплас попросил его прийти на следующий день, но оказался не готов ответить и перенес встречу на неделю, но и недели оказалось мало, учителю пришлось покинуть Париж без ответов, но с обещанием от Лапласа, что тот его известит, когда ответ будет готов. Это случилось три месяца спустя.

Лаплас пригласил учителя стать своим помощником-вычислителем, на что учитель согласился. Лаплас (возможно в отместку) усадил учителя за расчеты астрономических таблиц (рутинный труд). Учитель посвятил таблицам более 20 лет и свой жизненный путь так за их расчетом и закончил.

Для лучшего понимания текста читателю желательно иметь распечатку СМ-модели перед собой, а еще лучше написать программу СМ-модели и поработать с ней. Такая программа позволит задавать на вход различные модули (числа N) сравнения для числовых колец.

От TAN-листов и SMS-кодов до Passkeys и FIDO2 — за 20 лет одноразовые коды прошли путь от бумажек до криптографии.

Почему TOTP стал стандартом? Чем push-уведомления лучше? И правда ли, что будущее — без паролей?

В статье — краткий и наглядный разбор всей эволюции OTP: алгоритмы, уязвимости, UX и рекомендации для современных систем.

Подходит к завершению серия моих публикаций про использование идей искусственного интеллекта для решения задачи коммивояжера (TSP).

В этой заметке помогаю разобраться в авторской реализации Deep Q-learning для TSP.

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

Если вы когда-нибудь замечали, что длинные коды двухфакторной аутентификации (TOTP) часто содержат повторы вроде 131448 или симметрии вроде 1221 — это не баг, а статистическая закономерность. Чем длиннее код, тем выше вероятность, что в нём встретятся простые или "запоминающиеся" фрагменты. Это нормально и не снижает безопасность.

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

С каждым новым спринтом кажется, что ты просто двигаешь тикеты по доске?
Не только тебе. Когда задачи теряют смысл, проект буксует, а мотивация тает где-то между дейликом и очередными «небольшими изменениями — вот здесь, здесь и здесь», возникает закономерный вопрос: где же те самые большие задачи, в которых хочется быть? Где простор для роста, свободы и влияния?

Если честно, мы знаем ответ. Но ведь так неинтересно! Поэтому мы нарисовали комикс о том, как карьерный тупик трёх IT-специалистов — разработчика, аналитика и DevOps-инженера — внезапно превращается в портал, за которым их ждут испытания: Legacy-Хаос, техдолг и поток данных, грозящий поглотить всё живое. Чтобы пройти их, героям понадобятся не суперсилы, а кое-что куда важнее: автоматизация, гибкие подходы и возможность делать то, что имеет значение. Погружаемся в комикс — и проверим, что будет, если карьерным мечтам действительно дать пространство для развития.

Здравствуйте. Со времени той, не очень удачной публикации прошло много времени, за которое у меня многое изменилось, поэтому переработка материала немного подзадержалась. Скажу сразу, что это пока выполнено только в симуляторе Logisim Evolution, и проект полностью готов в Gowin 1.9.11, но пока я не знаю как отключать оптимизацию модулей, поэтому битстрима пока нет, но код выложу. Почему я решился на публикацию - потому что к "железному" OnKeyUp прибавился такой-же антидребезг. В симуляторе работает, но в битстрим пока не реализовано. Как только выяснится что у разработчика уровень демократичности (свобода действий пользователя и документация) достаточен - битстрим будет здесь с немного переработанной публикацией. А пока - только в симуляторе, для полного ознакомления с схемой он необходим, но можно и через код под спойлером в конце.

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

В этой статье я расскажу о типах VRP-задач, их отличиях, и о готовых решениях, которые вы можете затестить в ваших кейсах уже сейчас. Поделюсь подходами и инструментам, которые открыл в ходе исследования темы, опытом их использования и причинами, по которым я сразу отказался от некоторых из них.

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

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

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

Давненько я ничего не публиковал на Хабре — пора это исправлять.

В этот раз хочу поделиться темой, которая кажется простой, но на деле вызывает интерес у многих разработчиков и системных администраторов: как создать свою легковесную систему планирования задач на Python. Что-то вроде мини-аналога cron, но под свои задачи и со своими фишками.

Ведь часто бывает так: хочется, чтобы какие-то проверки или скрипты запускались в определённое время — например, в обеденный перерыв у сотрудников можно поставить автоматическую проверку всех машин на наличие вредоносного ПО. Или наоборот — распределить рутинные проверки так, чтобы они не мешали основной работе.

Хочу поделиться знанием, которое не является секретом, в каких-то курсах по алгоритмам оно наверняка дается, но нагуглить его совсем не просто. Поэтому пусть будет.

Алгоритм Дейкстры можно обобщить на произвольную функцию длины пути, если только она удовлетворяет трем условиям:

Монотонность. При добавлении ребра к пути, его длина не уменьшается.

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

Оптимальность префикса. Если к двум путям приписать одинаковое ребро, то кратчайший путь останется кратчайшим.

Под катом я привожу доказательство корректности обобщенного алгоритма и показываю, как его применить в задаче на литкоде: Trapping rain water II.

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

Доброго времени суток.

В качестве первой статьи решил выбрать разбор реализации отечественного шифра «кузнечик». Постараюсь объяснить сложные вещи простым языком.

В качестве рабочего примера моя реализация на C.

Привет! Меня зовут Дмитрий Бандурин, я заместитель директора департамента биллинговых решений в компании «СИГМА». Моя команда регулярно выполняет нетривиальные задачи для стабильной работы высоконагруженных систем. Сегодня расскажу, как мы переработали логику обработки пакетных процессов в нашей системе массовых операций, на примере расчета дебиторской задолженности. Нам было необходимо, чтобы она справлялась с возрастающим объемом данных — и всё это в жестких временных рамках и в условиях многопоточности.

И это решит 95% проблем типичного стартапа. Как-то так повелось, что по всему СНГ и его окрестностям на работу набирают зумеров с колоссальным опытом в три года, и они начинают создавать идеальные архитектуры. Да, каждый из вас, как только получает возможность взять на себя хоть малейшую ответственность, сразу вспоминает все прочитанные и не прочитанные книги и пилит свою уникальную архитектуру, непохожую ни на что.

Зачем программисту алгоритмы?

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

Однако сами программисты нередко удивляются, зачем всё это? Действительно, работа наших коллег часто заключается в поиске и устранении ошибок в залежах legacy кода. Какие уж там алгоритмы? Даже те, кому посчастливилось участвовать в новом проекте знают, что зачастую новый проект состоит на 80% из чужого, уже кем-то написанного и найденного на просторах гитхаба кода, а новый код - это, по сути, клей и обёртки, которые позволяют склеить эти уже готовые запчасти между собой, чтобы получить заданный продукт.

Сегодня я прочитал на Хабре статью о подготовке к алгоритмическому собеседованию в Яндексе. Видно, что ребята относятся к делу всерьёз. Однако на вопрос, зачем всё таки это нужно, статья отвечает в том духе, что алгоритмическая подготовка показывает полезную готовность кандидата поотжиматься (отмечу при этом, что это не мнение Яндекса, а личное мнение человека, получившего этот опыт с обеих сторон - и кандидата и интервьювера).

Однако всё же, действительно ли основная польза алгоритмической подготовки сводится к тому, чтобы продемонстрировать работодателю свою сообразительность и готовность потратить время жизни на подготовку к собеседованиям, а в целом она не слишком полезна для нормального рабочего процесса? Или всё же алгоритмы нужны?