Начну своё вступление издалека. Давным-давно, в далеких 2016-2017 годах вашему покорному слуге удалось съездить на полугодовое обучение в далекий город Ильменау (Германия), где он успешно (в общем и целом) закончил магистерскую программу Communications and Signal processing. Программа оказалась не из простых, однако сейчас о ней вспоминать даже приятно. Иногда...
"Какого дьявола я должен помнить наизусть все эти чёртовы алгоритмы и структуры данных?".
Примерно к этому сводятся комментарии большинства статей про прохождение технических интервью. Основной тезис, как правило, заключается в том, что всё так или иначе используемое уже реализовано по десять раз и с наибольшей долей вероятности заниматься этим рядовому программисту вряд ли придётся. Что ж, в какой-то мере это верно. Но, как оказалось, реализовано не всё, и мне, к сожалению (или к счастью?) создавать Структуру Данных всё-таки пришлось.
Загадочное Modified Merkle Patricia Trie.
Так как на хабре информации об этом дереве нет вообще, а на медиуме — немногим больше, хочу поведать о том, что же это за зверь, и с чем его едят.
В последнем выпуске подкаста "Цинковый прод" помимо всего прочего обсуждался так называемый парадокс Питона (The Python Paradox).
Как ни странно, на Хабре нет практически ни одного упоминания об этом парадоксе. При том, что, несмотря на свою простоту, мысль очень интересная
В далеком-предалеком 2004 году, когда язык Python был чем-то необычным, немейнстримовым, вышла статья Пола Грэма, в которой он поделился своим эмпирическим наблюдением: программисты на Питоне, которых он знает, гораздо сообразительнее, чем Java-программисты.
При подготовке наших образовательных программ мы периодически сталкиваемся со сложностями с точки зрения работы с некоторыми инструментами. И на тот момент, когда мы с ними сталикваемся, не всегда есть достаточно документации и статей, которые помогли бы с этой проблемой справиться.
Так было, например, в 2015 году и мы на программе “Специалист по большим данным” пользовались Hadoop-кластером со Spark на 35 одновременных пользователей. Как его готовить под такой юзкейс с использованием YARN, было непонятно. В итоге, разобравшись и пройдя путь самостоятельно, сделали пост на Хабре и еще выступили на Moscow Spark Meetup.
В этот раз речь пойдет о другой программе – Data Engineer. На ней наши участники строят два типа архитектуры: lambda и kappa. И в lamdba-архитектуре в рамках батч-обработки используется Airflow для перекладывания логов из HDFS в ClickHouse.
Все в общем-то хорошо. Пусть строят свои пайплайны. Однако, есть "но": все наши программы технологичны с точки зрения самого процесса обучения. Для проверки лаб мы используем автоматические чекеры: участнику нужно зайти в личный кабинет, нажать кнопку “Проверить”, и через какое-то время он видит какую-то расширенную обратную связь на то, что сделал. И именно в этот момент мы начинаем подходить к нашей проблеме.
В прошлой части мы с вами познакомились с базовыми командами Termux'а, настроили SSH соединение с ПК, научились создавать alias'ы и установили несколько полезных утилит. В этот раз нам предстоит шагнуть еще дальше, мы с вами:
В рамках ежегодного контеста ZeroNights HackQuest 2018 участникам предлагалось попробовать силы в целом ряде нетривиальных заданий и конкурсов. Часть одного из них была связана с генерированием adversarial-примера для нейронной сети. В наших статьях мы уже уделяли внимание методам атаки и защиты алгоритмов машинного обучения. В рамках же этой публикации мы разберем пример того, как можно было решить задание с ZeroNights Hackquest при помощи библиотеки foolbox.
raise прямо в коде, который вы читаете; «скрытые» запрятаны в используемых функциях, классах, методах.def divide(first: float, second: float) -> float:
return first / second
float. Типы проверены и можно запустить что-то такое: result = divide(1, 0)
print('x / y = ', result)
print исполнение программы никогда не дойдет, потому что деление 1 на 0 – невозможная операция, она вызовет ZeroDivisionError. Да, такой код безопасен с точки зрения типов, но его все равно нельзя использовать. 