amaslenn's


Гео и язык канала: не указан, Английский
Категория: Блоги


Заметки обо всем, что вижу, слышу и думаю.
Telegram: @amaslenn

Связанные каналы

Гео и язык канала
не указан, Английский
Категория
Блоги
Статистика
Фильтр публикаций


Читаем с ребенком «Ветер в ивах», встретилось там вот такое:

„– Многие могут решить, – начал он, – что наиболее злостным преступлением является кража, и это так. Но оскорбление полиции карается гораздо строже, и это правильно. Допустим, за воровство будет начислено двенадцать месяцев, это не очень много; за нарушение правил дорожного движения добавим ещё три года, это не слишком строго; и пятнадцать лет за оскорбления, нанесённые полицейским при исполнении ими своих обязанностей, – чудовищные оскорбления, даже если поверить одной десятой того, что мы слышали от свидетелей.“

Воровство — год
Нарушение ПДД — три года
Оскорбление полиции — 15 лет

Англия, 1908.


Берешь ты такой айпадик почитать, ну или с ноутом уютно устраиваешься на диване. И стрельнет какой-нибудь Х открыть, который с этого устройства и не открывал никогда.

— Введите логин ваш с паролем.

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

— А недостаточно этого! Двухфакторку ты имел неосторожность включить годы назад! Покидай уютное гнездышко свои да и беги за телефоном, ибо только он подтверждением существования твоего является.

Так и понимаешь необходимость жилеточки вассермановской.


Python circular dependencies

I found myself in a legacy project. Very hard to introduce modifications, one particular reason is multiple "utils" and "common" modules in multiple folders. Imports are manually hacked with sys.path.append(...).

At some point I do from module import symbol and that introduces a circular dependency which goes deep into source code. StackOverflow suggested (I lost the link) a nice solution: import module and then when needed just do module.symbol. This importing approach is lazy and doesn't raise any issues. And in runtime all symbols are resolved already, so it works nicely.

#python #legacy






Legacy

Recently watched this video: https://www.youtube.com/watch?v=Rryo6CoKamE

In fact, this is my favorite type of tech videos when ugly old code is refactored into something readable and maintainable. I especially enjoyed Uncle Bob's videos on this matter, highly recommended.

From the title I expected that this would be about something big, yet the example was based on a function under 100 lines long. An especially funny moment was when Arjan called in "big". He-he, I'd call it maintainable compared to some other examples I had to work with.

Anyway, a bigger example would make it impossible to go through in half an hour, plus I learned a very practical trick: convert all conditionals to == instead of mixing == and != (watch the video to understand more). I'm going to use it quite soon. I even did that before, but by skipping some steps and extracting common code to a class earlier. Sometimes it led to failing tests or issues.

At the end he suggests an algorithm for refactoring legacy code, and I liked that. Yet each step of that algo can be explained to a single book or something. And that something I missed from this video, this is something I need right now.

I think I might expand my thoughts on this later.

#python #legacy #refactoring




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

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

Работая только с «задачами», можно никогда не увидеть ничего крупного законченного: задача же это что-то маленькое. А отсутствие фидбека на свою работу демотивирует.

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


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

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

Проще всего такой процесс организуется в рамках одного репозитория. Но и в рамках монореп тоже можно.

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

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

Без явного отображения мейнтейнера и его проактивной позиции (== не ждет пинков, а сам регулярно смотрит ПРы) в код ревью, требовать обязательного код ревью нет смысла.


В старых книгах часто пишут, что код не должен находится в нерабочем состоянии долгое время. В этих же книгах пишут, что билд проверяется компиляцией (если она нужна) и тестами.

У тех, кто не застал разработку до гита и гитхаба, может возникнуть вопрос: как билд вообще может быть сломан? Точнее, ну сломан он в моем пулл реквесте, и чо?

И действительно, ничо. В этом нет ничего плохого, нормальный процесс.

Речь же про время, когда проверки на новый код запускались не до мержа, а после. Это как сейчас настраивать СИ только на пост-мерж в мастер. А в случае СВН, пре-коммит проверки сделать было крайне сложно, поэтому проверяли уже постфактум. И СВН еще довольно современное изобретение.

Отсюда и правило: залили в мейнлайн проблемный код — править его надо очень быстро.

#дедандрей




Давно заметил за собой, что если сел за работу без плана, скорее всего протуплю над какой-нибудь фигней. Занятно встретить базовые советы об эффективности в книге по ТДД.

What should you test? Before you begin, write a list of all the tests you know you will have to write. The first part of our approach to dealing with programming stress is never to take a step forward unless we know where our foot is going to land. When we sit down to a programming session, what is it we intend to accomplish?

Дальше у него еще про списки идет: один для "вот прям щас", еще пара для планов на неделю или месяц. При возникновении очередной идеи он осознанно добавляет ее в один из списков или признает ее несостоятельной и не добавляет никуда.

#tdd #gtd


Для себя

Я иногда делаю какие-то маленькие улучшалки в коде для себя. Ну, чтобы удобнее было. Иногда это мелкий рефакторинг, иногда новая фичка в утилите, которую часто использую. Речь про внутренние скрипты и инструменты, к коду которых есть доступ.

Часто коммитить и шарить это не хочется. То ли код не оч, то ли вот тут надо параметр добавить вместо хардкода. И бывает, что когда приходится делать настоящее изменение, состояние репы уже "грязное".

Селектив коммит в гите (git add -p) тут спасает, но это и неудобно и долго. Да и частенько всякие мелочи просачиваются внутрь коммита, приходится править.

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

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

Делитесь своей работой, кароч.


Забавно, что тех, кто использует ТДД постоянно и тех, кто не пишет код одинаковое количество.

Очень хочется понять ситуацию тех, кто постоянно использует ТДД: как дошли до этого, какие технологии используете и поддерживают ли вас ваши коллеги (если такие есть).

А еще хочется понять тех, кто тесты никогда не пишет: при условии, что код-то вы пишете, как вам живется? На сколько вы уверены в фиксах в легаси коде?

Приглашаю всех поделиться своими историями в комментах к этому посту. Тут уж без анонимности :)

А я тем временем читаю Кента Бека, появляются мысли на этот счет: https://amaslenn.medium.com/thought-on-tdd-b720a0edb5cf


Пишите ли вы тесты на свой код? (опрос анонимный, ваш босс ничего не узнает)
Опрос
  •   TDD!
  •   Иногда да, иногда нет
  •   Никогда не пишу тесты
  •   Не пишу код
20 голосов




Проверка почты

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

А в МС как-будто и Тимс никто регулярно не читает, в т.ч. и 1:1 чаты. И это очень круто. Если и сам научишься относится к Тимсу не как к источнику срочных дел.


Если надо вытащить из мкв только одну дорожку звука (ну вот скачали кинчик с торрентов и он весь на флешку не влезает, а смотреть все равно только с одним звуком будешь), то ффмпег в руки:
ffmpeg -i in.mkv -c:v copy -c:a:0 copy out.mkv

1. Видео копируется полностью как есть, никакого транскодирования нет, это быстро.
2. Для аудио указывается номер трека, причем это номер именно аудио трека, а не всех дорожек в контейнере.
2.1. Аудио тоже копируется, никакого транскодирования.

P.S. сервисы подписки удобнее, но реальность сложнее.

#ffmpeg #terminal


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


Сегодня я впервые за последние три с половиной года посетил офис не как гость. Пришел на свое рабочее место.

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

Короче, у людей есть рост. Офигенно.

Показано 20 последних публикаций.