Текст написан иностранным агентом – лицом, проживающим за пределами России (в Канаде). Иллюстрации взяты из открытых источников - если не указано иное, из Википедии.

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

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

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

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

В этом руководстве рассмотрен простейший алгоритм поиска пути, основанный на алгоритме Дейкстры. Этот алгоритм также известен под названием поиск по первому наилучшему совпадению, ключевая логика у него общая со многими другими алгоритмами, например, A*, заливка методом наводнения и диаграммы Вороного.

Здесь мы рассмотрим практическое применение этого алгоритма. Вам понадобятся базовые знания программирования и языка Python.

В этой статье мы рассказываем об основах и применении одного из самых мощных законов статистики - теоремы Байеса. 

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

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

Хотел бы написать небольшой цикл статей посвященных тому, как я написал свою RTOS с какими трудностями столкнулся и зачем вообще писать свою RTOS если уже есть FreeRTOS, RTX, embOS и т.д. список достаточно большой.

Начнем с того, что по мере работы я сталкивался с тем, что часть разработчиков (и я в том числе когда-то и сам) относятся к RTOS как к некоторому черному магическому ящику, мол что-то там происходит как-то все это работает и лучше туда не лесть, а то поломается ящик и проекту «ХАНА». И все хорошо пока хорошо, но как только появляются проблемы, то начинаются бессонные ночи с отладчиком, сроки по проекту горят, а самое главное и коварное, что ошибки в RTOS отловить крайне сложно. Зачастую они имеют плавающий характер и такие эффекты как переполнение стека, инверсия приоритетов, взаимные блокировки, и все, что связанное со средствами синхронизации отладить крайне сложно.

Cо всем этим я решил разобраться в корне, и чисто в академичесеких целях начал писать свою RTOS, чтобы так сказать прочувствовать все изнутри.

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

При написании RTOS, я осознанно отказался от поддержки проприетарных архитектур как AVR, PIC и мой выбор пал на семействе CORTEX, поскольку cortex-mX, на сегодня самая распространенная архитектура в Embedded.

Всем привет! Я занимаюсь разработкой и управлением проектами, а поэтому постоянно изучаю все, что прямо и косвенно может пригодиться в работе. Многими полезными находками, работающими принципами и собственными выводами хочется поделиться - когда-то мне самой конструктивных советов и внятной теории очень не хватало, о чем я жалею.

Сегодня делюсь очень полезным инструментом - пирамида аргументации от основателя YCombinator Пола Грэма, которая помогает работать с критикой, избегать бессмысленных споров и не грустить из-за существования хейтеров.

Пирамида аргументации Грэма, описанная им в эссе «Искусство возражать» — хороший инструмент, помогающий вырваться из этого порочного круга. Она четко структурирует возможные варианты критических комментариев – и связывает их с истинными намерениями оппонента. Теперь вы всегда можете идентифицировать "ступень" и понять: стоит ли критика вашего внимания — или это грязь под ногами, которую просто надо перешагнуть.

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

Критическая уязвимость в Java, в библиотеке log4j, которая используется в тысячах сервисов, начиная от Minecraft и заканчивая Apple Cloud, быстро превращается в серьезную угрозу для организаций по всему миру. Уязвимости подвержены сервера Apple, Valve, Microsoft и других.

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

Однако сейчас иногда и этого недостаточно, и для больше безопасности многие компании стараются придерживаться принципам Zero trust (или сеть с нулевым доверием). Построить такую сеть, оказывается, можно как раз используя технологию VPN.

Но зачем

Знаю, о чем вы думаете — Kubernetes? На домашнем сервере? Кто может быть настолько сумасшедшим? Что ж, раньше я согласился бы, однако недавно кое-что изменило мое мнение.

Я начал работать в небольшом стартапе, в котором нет DevOps разработчиков со знанием Kubernetes (в дальнейшем K8s), и даже будучи старым ненавистником K8s из-за его громоздкости, был вынужден признать, что мне не хватает его программного подхода к деплойментам и доступу к подам. Также должен признать, что азарт от укрощения настолько навороченного зверя давно будоражит меня. И вообще, K8s захватывает мир — так что лишние знания не навредят.

Еще одна технология из Star Trek оказалась больше наукой, чем фантастикой. Ученые под финансированием DARPA создали так называемую «warp bubble» — область пространства, способную расширяться или уменьшаться быстрее скорости света. Об этом сообщает бывший специалист НАСА по варп-двигателям Гарольд Уайт. Это первый настоящий «пузырь варп-движения», созданный в лаборатории. Который, как минимум, подтверждает, что такое возможно. И, по словам Уайта, устанавливает новую перспективу для тех, кто захочет создать первый космический корабль, способный к деформации.

Привет, Хабр! В современном мире абсолютное большинство сайтов используют HTTPS (Google даже снижает рейтинг сайтов работающих по HTTP в поисковой выдаче), а подключение к различным системам происходит по протоколу TLS/SSL. Поэтому любой разработчик рано или поздно сталкивается с этими технологиями на практике. Данная статья призвана помочь разобраться, если вы совершенно не в курсе что это такое и как оно устроено. Мы разберем как работает соединение по протоколу TLS, как выпустить собственные сертификаты и настроем TLS в Spring Boot приложении. Поехали!

Физика. Кто-то её любит, кто-то нет, но определённо это неотъемлемая часть нашего существования. В этой статье мы рассмотрим как самому создавать физические симуляции используя всего 2 библиотеки Python.
К концу статьи мы сделаем интерактивную симуляцию взаимодействия тел и поймём основы использования библиотеки Pymunk.

В этом туториале вы сможете создать симуляцию тел как на гифке сверху!

В процессе обратной разработки прошивок иногда возникает задача по ее эмуляции, например, для фаззинг тестирования или детального изучения поведения в динамике. На практике обычно для этого хватает фреймворков avatar2, unicorn, qiling и подобных. Однако они поддерживают далеко не все платформы и имеют ряд ограничений для решения таких задач. При разработке эмулятора PLC я столкнулся с тем, что ни один фреймворк для эмуляции не поддерживал требуемую платформу.

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

Меня зовут Андрей Булов. Я простой питерский технарь, архитектор, разработчик, DevOps технический менеджер. Сейчас работаю в Quantori.

Я не буду описывать самоорганизующиеся команды, а расскажу про алгоритм их создания. Это мой личный опыт — я так работаю с командами (их было 30+). Он перекликается с Management 3.0, моделью Херши-Бланшар, LeSS, Sсrum и даже SAFe, а также со многими другими софтовыми областями. И в нем есть конкретика на уровне действий.

Для ленивых: я исследую окружение, проектирую дизайн культуры, объясняю правила и делегирую задачи команде. Я не поддерживаю внедрение самоорганизации через фреймворк. Видео моего выступления об этом на конференции TeamLead Conf 2021 можно посмотреть здесь.

Часто вижу, что помимо обработки исключений, люди мучаются кое с чем еще, а именно с логированием.

Большинство людей не знают, что писать в логи, поэтому решают логировать все, что угодно, думая, что все подряд – это в любом случае лучше, чем ничего, и, в конечном итоге, просто создают шум. А шум – это информация, которая никак не помогает вашей команде понять, в чем дело и как решить проблему.