Читать в телеге. Когда-то там были посты не только от меня.
Чтение тредов твиттера
В твитере люди иногда делают длинный тред с фактами (1 факт - 1 твит). Звучит по-уебански, но таки уж люди, они и в инстаграме статьи-лонгриды пишут. Так вот, есть специальный бот, чтобы из треда с сотней твитов сделать обычную статью: https://threadreaderapp.com/. Типа упоминаешь его твитом и он разворачивает тред.
Сравнение веток в Intellij Idea
Intellij Idea в новых версиях умеет сравнивать между собой ветки - причем как по логу коммитов, так и по файлам. Для этого надо в выборе ветки выбрать compare.
Свободное место на файловой системе
Чтобы не попасть в просак при работе со свободным местом в ФС и всем таким рекомендуется ознакомится со статьей. Можно для разогрева прочесть эту.
Даже если есть место на диске, новый файл может не создаться из-за того, что:
- кончились свободные inode
- кончились свободные inode для пользователя (для root есть специальный резерв)
- может быть коллизия хэша имени в индексе каталога (поэтому много файлов в одной папке хранить плохо)
Значения по умолчанию в dict в питоне
В питоне dict.get(key, default_value)
вычисляет все свои аргументы сразу. Вроде мелочь, но конструкция lookup.get(z, int(z))
может поломаться. Ее ожидаемое поведение - попробовать получить что-то из словаря по ключу, а если не получилось - то по преобразованному в число ключу. Но поскольку int(z)
вычисляется сразу, то на обычной строке ввод ломается. А если эта конструкция где-то глубоко, и ты хочешь быстро написать скрипт и свалить, то можно начать грешить на скрытые юникод символы и прочую дичь по непривычке. В scala, например, вычисление значения по умолчанию - ленивое.
Java становится похожа на Kotlin
Java с каждой версией все больше и больше похожа на Kotlin/Scala/C#. И если раньше была вполне очевидная ниша для enterprise-языка с низким порогом вхождения, то сейчас это уже получается весьма странный зверь.
В 8 java завезли функциональные методы работы с коллекциями, лямбды и Optional.
В 10 java добавили var.
С 12 java switch
может быть выражением.
В 13 java добавили тройные кавычки для строковых литералов.
В грядущей 14 версии добавят:
- записи (как data-классы Kotlin)
- паттерн матчинг в стиле C#
if (obj instanceof String) {
String s = (String) obj;
System.out.println(s.toUpperCase());
}
Но есть и довольно клевая фича, которая выгодно отличает от других: хорошее описание для NPE, которое говорит, в каком именно методе цепочки была ошибка, а не тупо строчку:
Exception in thread "main" java.lang.NullPointerException: Cannot invoke "String.toUpperCase()" because the return value of "Address.getStreet()" is null
at Program.getStreetFromRequest(Program.java:10)
at Program.main(Program.java:6)
В 15 java обещают sealed типы. Движение в сторону здорового паттерн-матчинга.
См. также википедию и статью на хабре.
Сравнение производительности web-фреймворков
Нейминг
There are only two hard things in Computer Science: cache invalidation and naming things — Phil Karlton.
Про инвалидацию кэша поговорим как-нибудь в другой раз, сейчас про именование методов.
Всякие банальности наверно говорить не стоит: и так понятно, что метод f()
- вообще донное название, переменная должна быть существительным, метод - глаголом.
Базовые советы неплохо расписаны в этой статье (которая у нас висит на заглавной странице Redmine, если кто не помнит).
Недавно на хабре подняли еще один вопрос про нейминг. https://habr.com/ru/post/484860/. Суть примерно такова - не надо в названии отражать, как функция работает. Надо писать, что полезного она делает.
Вообще, у нас в отделе вопрос нейминга решается обычно так:
- Попробуй назвать сам. Если совсем туго - возможно нарушен SRP или другая практика, код надо отрефакторить.
- Попроси помочь старшего друга, но хотя бы 2-3 варианта предложи сам.
- Спроси команду. “Если хочешь что-то понять - объясни другому”. Если объясняешь человеку, который не в контексте - то, во-первых, сам сконцентрируешься на важном и лучше поймешь, что делает функция, во-вторых, незамыленный взгляд/слух способствует новым идеям и/или объективному подходу к теме.
- Совсем тяжелые случаи выносим на голосование.
Мониторинг приложения
Как понять, сколько запросов система обрабатывает в секунду? Как долго обрабатывает запрос? Какие очереди забиваются?
На эти вопросы вы можете ответить, если обложите ваше приложение метриками - счетчиками, таймерами и т.п., которые будут отправляться в какое-нибудь хранилище. А уже из него можно их читать, строить статистику, визуализировать и мастрячить дашборды. Или алерты, когда какая-то метрика отклоняется от нормы.
Вообще тема довольно широкая и “в минутку” ее тяжело уложить.
У нас в отделе для этих целей раньше использовалась ganglia + graphite, сейчас - TICK-stack. Серьезные ребята с нагрузкой побольше могут использовать Prometheus, если ближе к железу/сисадминству - то это Zabbix. Можно еще подобные шутки построить в elastic-стеке, а вообще штук для мониторинга - пруд пруди.
TICK-stack у нас с задачей справляется, хотя он довольно молод, еще не так стабилен, как хотелось бы и к нему есть претензии. Например, если в influx забился диск, он это честно обнаруживает и пишет в логи, но потом даже при свободном месте он ничего не делает и продолжает якобы нормально работать (вместо того, чтобы обнаружить новое место и продолжить писать). Приходится рестартить.
Работа с легаси-кодом
Как работать с легаси кодом? Т.е. как себя вести в ситуации, когда наткнулся на старый код и понимаешь, что его надо серьезно отрефакторить (не важно по какой причине - устарел, появились новые компетенции в команде и поняли, что так писать не стоит, новая фича только с костылями пролезет и т.п.)?
Варианты примерно такие (можно и нужно комбинировать):
-
Закладывать в оценку таска время на рефакторинг. Это может быть явно прописано или учтено в рисках. Если рефакторинг мелкий, то этого времени обычно хватает.
-
Сделать “чтобы работало”, и добавить таск на рефакторинг в трекер задач. Будет время - выполним задачу. Обычно это связано с глобальным рефакторингом - то есть тяжелой задачей. Если реально без этого рефакторинга никак - то стоит еще раз подумать о приоритетах.
А вообще лучше придерживаться правила, что после работы с участком кода он должен стать лучше:) Все-таки над этим кодом потом работать тебе и твоему коллеге. И работать с техдолгом нужно - иначе код превратится в огромного страшного монстра, которого проще будет сжечь, чем исправить :)
Поиск тикета в Redmine
Если в поиске рейдмайна вбить число, то вас редиректнет на тикет с таким номером. Мелочь, а приятно.
Очень весело искать тикет по тексту, содержащий год:)