Пятничное развлекательное

Немного разобраться в себе и окружающих поможет старый советский фильм Я и другие – 50 минут результатов психологических исследований. Способны ли вы идти против мнения толпы? Насколько точна ваша память? Есть ли на столе черная пирамидка или обе белые?

Частично схожие вопросы поднимаются в просто идеальном фильме Трасса 60. Как люди отнесутся к оригиналу картины известного художника, если выдать её за подделку? Как будет выглядеть город, где живут только адвокаты? Что будет, если легализовать наркотики? Описание получилось отстойным, но фильм, право, очень хорош.

#fun #films #edu

Господа, нас круглое число – 128. Планируем захват мира через 3...2...^C

#ToTheMoon

Нельзя не вспомнить классический комикс от xkcd correct horse battery staple для запоминания пароля.

Кстати, у нас уже была подборка про xkcd. Жми 🔥, если хочешь продолжения подборки

Как сформировать надёжный мастер-пароль для менеджера паролей, о которых мы писали ранее? Самым простым, при этом самым неломаемым вариантом будет кусок стихотворения со всей пунктуацией.

Я вас любил: любовь ещё, быть может,

Это почти идеальный пароль. Можно ещё добавить спецсимволов вместо пробелов или ещё как-то усложнить текст одному вам понятным образом.

PS: Не используйте свои любимые цитаты. Выбранный фрагмент должен иметь нулевую связь с вами, как личностью.
#skills #sudo #devfm

Bash — скриптовый язык с довольно неприятным синтаксисом. Но и на нём можно писать достойно. Встречайте – видео об идеальном bash-скрипте (или на рутубе).

#youtube #skills #devfm

Попроси программиста проверить 10 строк кода, он найдёт 10 проблем. Попроси его проверить 500 строк кода, он скажет: "выглядит норм".

На ревью кода надо отправлять небольшие наработки. Чем больше фрагмент кода для ревью, тем сложнее дать обратную связь. Либо легче — можно скипнуть внимательный анализ и просто проверить работоспособность, совершенно не вдаваясь в детали. Но польза от такого ревью невелика.

Как научиться писать хороший код? Прочитанное в книгах совсем не сразу преобразуется в ваш опыт. В разработке огромный пласт знаний образуется в результате практики написания и, что более важно, чтения чужого кода. Читайте чужой код, господа — это самый быстрый способ роста скилла разработки. Если код хорош — то вы научитесь как надо писать. Если код плох — вы увидите, как писать не надо, и сможете дать обратную связь (если вас об этом попросили, прошу заметить).

#procode #devfm

Давайте посмотрим на 10 строк кода.

Вроде всё хорошо. Классическое открытие файла с помощью контекстного менеджера with, классическая построчная обработка. Разбиваем строку, записываем в список словарей. Всё ли по канону? Неа:

1. Смотрим документацию: readlines возвращает список всех строк файла. Значит, для большого файла может быть беда. Современный питон позволяет итерироваться сразу по объекту file_. Просто пишем
for line in file_:

2. raw_line[0] и прочие индексы — это всегда ужас. Заменяем на
fio, login = line.split(";")

Вроде то же самое, но мы сразу понимаем, что было в строке. И тут же видим следующую проблему.

3. А что, если в строке нет двоеточия, или этих двоеточий больше одного? То есть нужна обработка ошибок на исключение ValueError, если справа split вернул не два значения. Добавляем try-except.

4. Частая проблема split — это лишние пробелы. Скорее всего, потребуется strip всем переменным после split.

Итого 4 ошибки на 10 строк кода

#python #codereview #devfm

Пятничное развлекательное

Проблемы с компьютером
Абстракция
Теперь без асбеста
Долг зовёт
Взгляды на конфиденциальность
Исследование
Обходной путь
Реалистичный критерий

#fun #xkcd

Hoverboard — небольшой интерактивный комикс... Как бы не так. Это почти бесконечное полотно с миллиардом отсылок. Простой выйдите за пределы карты. Саму карту и объяснение отсылок можно найти тут. А zoomable-карту от фанатов — тут

#fun #xkcd

Теперь посмотрим на переработанный код. Docstring вырезан для краткости. Код теперь крут:
1. Есть аннотация типов
2. С файлом работаем через контекстный менеджер, то есть закрыть не забудем — оно само
3. Не забыли про запрет использования file как ключевого слова, поэтому file_
4. При разбиении строки по точке с запятой используем именованные переменные
5. При ошибках — кастомные исключения. DownloadError название спорное, я бы заменил на ParsingError. Но если файл побился при скачивании, то самое то
6. Добавляем значения в список, не забывая обрезать лишние пробелы по бокам.

В общем, каждая строка на своём месте. Что можно улучшить? Я бы заменил result на logins, тогда и выходной словарик будет называться как надо.

#python #codereview #devfm

Словарь student (или result) во вчерашнем примере не является удобной конструкцией, ФИО доступно как student["fio"]. Кроме того, мы демонстрируем наружу внутреннее представление, нарушая принцип инкапсуляции. Замена словаря на список, например, заставит переписать весь код, который использует эту структуру данных. Какой может быть выход?

Создадим класс Student и превратим словарь в экземпляр класса. Можно использовать namedtuple из collections, но мы пойдём своим путём. Бонусов много:
1. Мы скрываем внутреннее устройство студента. Наружу мы отдаём только пару полей, откуда мы их берём никто снаружи не знает
2. Можем к студенту добавлять методы. Например, вывод фамилии с инициалами в стиле Иванов И.И. — теперь это в нашей власти
3. Можем добавить новые способы создания этого студента, например, данные брать из базы данных.

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

#python #codereview

Нельзя использовать goto

Часто говорят, что goto плох. А собственно, почему?

В ассемблерном коде на машинном уровне все управляющие конструкции (if, while, for и другие) преобразуются в набор команд с безусловным переходом jmp. А такой переход — самый настоящий goto. То есть ты весь такой изящный во фраке пишешь циклы, а наглый компилятор/интерпретатор выкидывает всю красоту и делает goto.

Так почему же сам goto является признаком плохого кода, если он на самом деле везде?

Ответ кроется в умении сохранять контекст. Человек может в голове держать 5-9 сущностей, больше не получается. Поэтому придумали функции, и придумали держать их небольшими — для снижения когнитивной сложности. Конструкция if переведёт тебя в одну из веток ниже, циклы for и while выполнят тело цикла или выбросят за его пределы. Команда goto сложность привносит — прыжок может быть куда угодно. А повышение сложности всегда приводит к росту числа ошибок.

Ну а ещё из-за goto может напасть велоцираптор.

#procode #devfm

— Без требований программирование представляет собой искусство добавления багов в пустой текстовый файл
— Тесты позволяют улучшать API
— Наличие "и" в описании функции — это плохо
— Магическое число 7
— Важность умения запускать код без IDE
— Мой любимый git add -p

Полезные и не очень советы в статье Чему я научился на своём горьком опыте (за 30 лет в разработке ПО). Какие-то пункты устарели, какие-то не универсальны, с какими-то я не согласен.

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

Кстати, пример с getUserMessage(userId, true) в питоне решается именованным параметром getUserMessage(userId, retrieveFullMessage=true)
#procode

Пятничное развлекательное

В августе у многих появляется время почитать. Порекомендую вам очень опасную художественную книгу. Автор — Элиезер Юдковский, американский специалист по искусственному интеллекту, исследующий проблемы технологической сингулярности и выступающий за создание дружественного искусственного интеллекта (ИИ).

Чем же опасна эта книга? После неё другие книги начинают выглядеть слабо. В этом романе персонажи ведут себя разумно и логично (не путать с "правильно"). В заданных условиях они действуют так, что их мотивация понятна.

Тут нет клише "давайте разделимся" из фильмов ужасов, тут нет бессмысленного маховика времени, который выдаётся первокурснице для посещения занятий. Но тут есть используемый в сюжете маховик времени. Речь идёт о книге Гарри Поттер и методы рационального мышления. Да-да, спец по ИИ написал фанфик по Гарри Поттеру. Это ли не причина его прочитать?

#fun #books

Некоторые вещи разработчику в среднем не нужны. Например, как устроен процессор. Нет в нашем любимом Python регистров процессора, мы максимально далеки от них. Тем не менее у меня для вас древняя (2013 год) статья-перевод Путешествие через вычислительный конвейер процессора (оригинал на gamedev).

Как писал Джоел Спольски в Законе дырявых абстракций, надо знать на один уровень абстракции глубже, чем уровень на котором вы работаете. С этой точки зрения разбирать смежные области является хорошей идеей.

Но вообще, конвейер — это просто интересно. Что такое hyperthreading? А спекулятивное выполнение и предсказатель переходов — слышали о таких штуках? В 2017 году с их помощью были реализованы уязвимости Meltdown/Spectre, наделавшие много шума. Об этом позже
#skills

Месяц назад мы обсуждали, что можно сделать с неработающим кодом. Два дня назад своё видение дебага и отладки раскрыл канал Диджитализируй в ролике Кладём баги на лопатки (24 минуты). Он касается следующих тем:
1. локализация проблемы
2. изучение проблемного участка с помощью отладчика или логгирования. Рассматриваете пример логгирования endpoint-а вебсервера
3. тезис "не доверять ни одному фрагменту кода"
4. бан фразы "у меня всё работает"
5. рассуждения о коде как структуре

На разобранном примере кода с добавлением логгинга в связи с нехваткой времени куча недоработок:
— можно настроить, чтобы имя функции само выводилось в логгере, а не вписывать руками
— непонятно, где какие уровни логгера ставить. У него везде debug
— начиная с python 3.8, в f-строках можно писать f"{var=}" вместо f"var = {var}", тогда будет выведено var=значение

#youtube #procode

Год назад на хабре вышла занятная статья Письмо преподавателям вузов. Хватит губить будущее ИТ. В ней модератор хабра поднимает следующую проблему. Кто-то из преподавателей сделал автомат за зачёт при публикации на хабре, которая набрала +4 рейтинга. В результате на хабр набежала толпа студентов с материалами разного уровня, в том числе со слёзными просьбами пропустить статью из песочницы.

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

Хотите я расскажу, что из вуза реально нужно в работе?

— Умение работать с литературой, источниками и технической документацией, отличать фуфло от профессиональных материалов, уметь определять актуальность и совместимость информации с реальной рабочей задачей.
— Знание фундаментальных основ специальности и специализации. В ИТ знания нужно обновлять быстро и непрерывно, поэтому важно иметь хорошую основу, на которую будет ложиться актуальная теория и практика.
— Умение анализировать, синтезировать, декомпозировать идеи и задачи, выделять главное.
— Способность представить свой труд — на конференции, в статье на Хабре, в печатном издании, на ковре у директора, на митинге перед тимлидом.
— Навык здравой оценки своих знаний и пробела в них.

Такие вот дела. Напомню, что мы рассказывали правильный порядок анализа предметной области.
#edu #sudo

Meltdown — одна из нашумевших уязвимостей последних 5 лет (2017 год) для процессоров Intel. В статье на хабре на примере рассматривается эта неприятная беда, возникшая на стыке
— спекулятивного (упреждающего) выполнения инструкций процессором. Мы недавно говорили о важности конвейера
— кэширования результатов вычислений
— косвенной адресации памяти
— timing-атаки из криптографии, когда нападающий смотрит за временем выполнения операций.

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

Защита от уязвимости возможна только путём существенной потери производительности. Обычно речь про 20-30%. В блоге касперского говорят, что Meltdown ещё актуален.

Для желающих поковырять подобного есть статья про Spectre, примерно ту же уязвимость для процессоров AMD. Она куда более сложная в реализации и описании.
#skills

В python есть неочевидные конструкции, например, else у цикла for. Часть с else выполнится, если цикл завершился сам, без break.

Хорошее применение — если есть два вложенных цикла (внимание! вычислительная сложность O(n^2), старайтесь избегать такого), и при завершении внутреннего надо завершить и внешний. Например, с помощью pandas разбираем эксельку с построчной обработкой, и в случае ошибок надо прекращать сразу оба цикла.

Если внутренний цикл прошёл целиком, то выполнится continue на строке 8, и внешний цикл продолжится. Если внутренний цикл на строке 5 завершится по break, то else не выполнится и мы попадём на строку 10 в break внешнего цикла.

Без for-else это решается флагом, который проверяется на внешнем цикле — то есть куда менее изящно.

Пример взят тут

#python #codereview

Посмотрим на свежую статью по сравнению брокеров сообщений — систем, реализующих шаблон издатель-подписчик (pub/sub, publisher-subscriber). Шаблон позволяет реализовать асинхронную обработку сообщений с множественными писателями и читателями. Например, загрузка видео на youtube требует его переконвертацию под множество размеров (144p, 240p и так далее). Такое поведение можно реализовать на брокере сообщений — вкинули пул заданий на преобразование, и эти задания будут обрабатывать те сервера, которые сейчас свободны. Полученную схему можно относительно легко масштабировать, добавляя новые узлы-обработчики или сервисы-загрузчики новых видео.

Статья A Fair Comparison of Message Queuing Systems сравнивает Kafka, RabbitMQ, RocketMQ, ActiveMQ и Pulsar. Статья является отличным примером правильного сравнительного анализа. Дан обширный ввод в предметную область. Обзор публикаций маловат, но это единственный недочёт. Далее выдвинуты обоснованные критерии сравнения, разделённые на блоки: особенности (язык, сообщество, протоколы, ...), качество обслуживания (надёжность, масштабируемость, ...), производительность (задержки и пропускная способность). Для каждого из критериев написан абзац текста с описанием и обоснованием важности. Ранее мы критиковали статью с хабра за невнятные критерии. Теперь у нас есть отличный пример правильной формулировки критериев сравнения. Следом идёт сжатое описание каждой из сравниваемых систем, по каждой сформулированы плюсы и минусы.

Следом описана методика тестирования и конфигурация оборудования стенда. После приведены графики измеряемых параметров, даны рассуждения "кого когда лучше применять" и краткое заключение.

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

#sudo #edu #devfm