Привет, Хабр! Сегодня я бы хотел вместе с вами погрузится в увлекательный мир зависимостей, а точнее их внедрение.
И так, давайте сначала разберемся что же такое зависимость?
Зависимость - это объект (или функция, в Python все - это объект), который нужен другому объекту или функции для их нормальной работы. Почти в каждого объекта есть одна или несколько зависимостей. Существует 2 основных метода их получение: создание зависимости непосредственно внутри функции либо же инъекция (внедрение).
В этой статье хочу рассказать про нерандомность модуля random в стандартной библиотеке Python. С точки зрения криптографии и математики числа, генерируемые этим модулем, случайные лишь на вид — они порождаются детерминированным алгоритмом, что делает их псевдослучайными. Рассмотрим, как устроен генератор на основе алгоритма Mersenne Twister (MT19937), почему его выходы «нерандомны» в формальном смысле и какие практические следствия это имеет.
написано для новичков и плохо посвященных в тему людей…
Теперь всё, что раньше делали люди — создание курсов, проверку ответов, адаптацию персонализированных заданий — почти полностью взял на себя ИИ.
Duolingo — это уже давно не просто приложение с разноцветными совами и скучными заданиями. В 2025-м генеративный ИИ позволил Duolingo быстро создавать новые курсы, и за год почти удвоить число языковых курсов! Как им это удалось и что это значит лично для тебя — рассказываем подробнее...
Вот вам маленькая задачка на программирование: реализуйте такой макрос, который принимает в качестве аргумента числовое выражение (числа могут быть целыми или с плавающей точкой) и:
Недавно написал скептический комментарий по поводу необходимости алгоритмических интервью. Вспомнил примеры из своей практики, один из них вполне подходящий, можно сделать патч в opensource проекте.
Разработчики зачастую пишут код (скелет), используя наивные алгоритмы и не используя валидаторы (предполагая изменить код позже либо ошибочно предположив что объем данных будет небольшим).
Не так давно попался один тикет с жалобой на зависание in-house приложения которое обрабатывает adobe pdf документы (печатает в png изображение для web клиентов).
Приложение использует библиотеку apache pdfbox.
Запустил тест с проблемным pdf документом в котором использовались формы – компьютер “пошел на взлет”. Похоже на длинный цикл, хорошо пошел.
Жду пару минут, стало интересно.
Начался тротлинг CPU (перегрев, рабочая коробочка у меня небольшая, мобильная, с воздушным охлаждением и быстро нагревается при большой длительной нагрузке).
Привет, друзья!
В этой серии статей мы разбираем структуры данных и алгоритмы, представленные в этом замечательном репозитории. Это одиннадцатая часть серии.
Сегодня мы рассмотрим несколько простых, но интересных алгоритмов машинного обучения, а также один весьма любопытный статистический алгоритм.
Код, представленный в этой и других статьях серии, можно найти в этом репозитории.
Интересно? Тогда прошу под кат.
За годы своего развития 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, но под свои задачи и со своими фишками.
Ведь часто бывает так: хочется, чтобы какие-то проверки или скрипты запускались в определённое время — например, в обеденный перерыв у сотрудников можно поставить автоматическую проверку всех машин на наличие вредоносного ПО. Или наоборот — распределить рутинные проверки так, чтобы они не мешали основной работе.
