Любимому подкасту "Цинковый прод" исполнилось 100 выпусков!

Для тех, кто никогда о нем не слышал, вот топовые выпуски:

https://youtu.be/slE11sPm8fQ (кубернетис: что, для чего, и где, и даже на Raspberry Pi)

https://youtu.be/aVVTNg_mI7U (Дмитрий Пацура продает nodejs и ругает php)

https://youtu.be/xI-VWPZ3XQQ (выпуск с Брагилевским)

Нужны ли созвоны?

Напишу свои мысли, а вы докиньте в коменты свои.

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

Минусов очного общения дофига. Многие сходу не могут вспомнить какие-то детали, и просто обещают потом посмотреть. Кто-то отложил важные дела ради митинга, а митинг оказался ни о чём. Кто-то из-за созвона потерял контекст. Кто-то просто устал, кто-то не пожрал.

Капец.

В целом, предпочтительнее, конечно, письменный формат. Но есть исключения.

1) Созвон для быстрого решения проблемы. В асинхронной текстовой коммуникации есть большая беда: скорость. Петя что-то написал, Вася ответил через час, Зоя ушла на обед, Криштиану вообще не заметил сообщения. В итоге можно целый день обсуждать проблему, хотя ушло бы 5 минут. Когда упал прод, круче всего собраться за одним компом вдвоем-втроём и быстро всё порешать.

2) Delivery sync. Когда взаимодействуют несколько команд, бывает полезно видеть картину происходящего в целом. Протолкнуть пару задач до прода, выяснить кто кого блокирует, прощупать подвисшие вопросы. Договориться о стратегии, чтобы никто никого не блокировал в будущем. Почему тут хорош созвон - к такому митингу не надо готовиться, чистый обмен информации о состоянии дел. Кроме того, присуствуют все ответственные люди, не надо отдельно каждому писать и ждать. На практике занимает 10 минут (!) в день, не больше. Польза огромная, из личного опыта говорю.

3) Обсуждение новой сложной задачи, особенно затрагивающей несколько команд. Даже если кто-то (архитектор, системный аналитик или тот, кто взял на себя эту роль) разобрался в задаче, продумал, кто с чем взаимодействует, и написал доку, всё равно сложно всё учесть. У людей неизбежно будут вопросы, вопросы будут зачастую одинаковые. Даже если кто-то будет есть пиццу и лишь фоном поприсутствует на таком созвоне, это уже будет полезно: в мозгу осядут необходимые термины, контекст.

4) Созвоны для общения команды. У нас стендапы по утрам больше нужны для того, чтобы люди не забыли, что они не сферические human resources, пообсуждали новости, пошутили, постебались друг над другом. Это важно.

Короче, как обычно, нет чёрного и белого, всё бывает нужно.

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

Ну и конечно, нельзя, чтобы созвоны постоянно рвали конекст. Дни без митингов и всё такое.

Я как лид, которого всё время дергают, вбил себе в календарь несколько часов подряд в день под названием "программирование", таким образом на эти часы никто не может меня забронировать.

Вообще, если считаете что созвон тупой, лучше его проигнорировать и попросить записать. Потом промотать на x3 скорости. Это экономит время.

Оформил мысли из некоторых предыдущих постов чуть подробнее, в виде статьи на хабре
https://habr.com/ru/post/543490/

Сейчас гуляют по интернету красивые картинки про развитие БД (https://youtu.be/thuG2PXVbBU ), но непонятно, откуда данные.

По опросам разработчиков на stackoverflow, расклад совершенно другой: https://insights.stackoverflow.com/survey/2020#technology-databases

Итак, на вопрос, можно ли наследовать класс Пингвин от класса Птица, большая часть людей ответили "да" или "нет".

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

Дело в том, что когда мы пишем программу, мы не оперируем настоящими животными, мы лишь моделируем их, т.е. строим модель для решения определенных задач, а не для всего на свете.

Пингвин и птица в разных бизнес-контекстах могут быть описаны совершенно по-разному.

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

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

Более того, в одном и том же софте могут присутствовать сразу оба варианта. В различных bounded context могут быть разные модели.

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

Забавный тред про языки программирования

https://twitter.com/_bravit/status/1364488062428921858

Раст можно изучать и на русском языке:

Растбук https://doc.rust-lang.ru/book/

Rust by example: https://doc.rust-lang.ru/stable/rust-by-example/

Книга по асинхронному программированию: https://doc.rust-lang.ru/async-book

Лекции Кладова
https://www.youtube.com/playlist?list=PLlb7e2G7aSpTfhiECYNI2EZ1uAluUqE_e

Чем синьор отличается от джуна?

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

Это способность построить в голове модель того, что происходит в создаваемом софте. И помнить ее долго хотя бы в общих чертах.

Вам может быть насрать на выгоды бизнеса (привет, @fillpackart :) ), или вы наоборот упоролись и живете только работой. Вы можете знать или не знать детали реализации gc в jvm и вертеть на хую красно-черные деревья.

Это все неважно, если вы не можете натренировать свою серую нейросеть так, чтобы держать в голове систему в целом. То, что относится к той части софта, за которую вы отвечаете.

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

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

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


Крутые шахматисты могут держать в голове десяток партий на сеансе одновременной игры.

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

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

Еще неплохо бы уметь объяснять происходящее другим: объясняя, лучше запоминаешь и выкристаллизовываешь суть.

Я тут песенку сочинил про Golang. Очень простые слова, подпевай!
Ваш crossjoin

Cover версия нашей подписчицы NastyPasty в ответочку на https://news.1rj.ru/str/crossjoin/45

Книжка "Грокаем алгоритмы".

Смотрю оглавление:

- предисловие

- благодарности

- о книге
-- структура книги
-- как работать с книгой
-- для кого предназначена эта книга
-- Условные обозначения
-- об авторе
-- от издательства

- Глава1. Знакомство с алгоритмами

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

-- Введение
-- Что вы узнаете об эффективности алгоритмов
-- Что вы узнаете о решении задач

сука, и только после этого началось про бинарный поиск.

Это какая-то жесть ))

Станислав Осипов: "На собеседовании по Zoom кандидат включил рядом второй комп заранее, который все время работал в режиме голосового поиска по моим вопросам и его ответам. Комп кое-как заматчил только три из десятков вопросов. Кандидат ощущал провал затеи и очень страдал."

Хозяйке на заметку ))

Гугл анонсировал Flutter2.

Основные новшества:
Flutter для web стал production-ready. PWA, SPA - вот это всё.

Алсо, Flutter запартнерился с Canonical и Microsoft, чтобы можно было делать десктопные приложения. Canonical даже пообещали для своих будущих приложений использовать флаттер как выбор номер 1.

Вообще, список девайсов был расширен: от складных устройств (а ля Surface Duo) до автомобилей (Toyota).

Ну а обычные андроиды и айфоны были поддержаны с самого начала. Теперь flutter можно считать полноценным кросплатформенным фреймворком

Jareny Petuh Driven Development (увидел где-то в фейсбуке)

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

Т.е. ресивер или локальная переменная - это норма сократить log до l или writer до w - так как вы тут же видите, что это такое, какого типа и т.д. Однако, если вы достаете что-то из недр структуры, то названия должны быть, конечно, более говорящими.

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

Как готовиться к прохождению технического собеседования.

Так как подготовка к проведению собеса довольно трудоёмкое мероприятие, зачастую большая часть вопросов просто берется тупо из гугла. Поэтому вбиваете в гугл "%вашязык% вопросы на собеседовании" и учите по первым двум-трем ссылкам (дальше никто не пойдет, это трудоёмко). Еще имеет смысл вбить "задачи на собеседовании" и прорешать часто повторяющиеся. Чтобы покрыть любителей лайвкодинга.

Можно на двух языках, рус и англ, чтоб наверняка.

Это даст огромное преимущество на большинстве собесов, а времени займет не так много.

Ну и совет тимлидам. Спрашивать базовые вопросы все же наверно надо, но помимо этого нужно напирать на реальный опыт. "Какую интересную/сложную задачу ты решал, расскажи в деталях, что делал именно ты" - хорошая точка старта для беседы.

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

Рекурсивные CTE в Postgresql

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

К примеру, у вас есть записи ( id, parent_id, name ), и вам надо построить поддерево для определенного id.

Как это всё работает.

На самоме деле, название "рекурсивные CTE" не совсем удачное, больше подошло бы "итеративное CTE".

Пример:

WITH RECURSIVE r AS (
SELECT id, parent_id, name
FROM geo
WHERE parent_id = 4

UNION

SELECT geo.id, geo.parent_id, geo.name
FROM geo
JOIN r
ON geo.parent_id = r.id
)
SELECT * FROM r;

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

Первая часть (та что до UNION) - это так называемый anchor, он выполняется в начале, это первая итерация.

Далее в цикле выполняется вторая часть. Это очередная итерация, которая работает в связке с предыдущей (джойнится на результат предыдущей итерации).

Это всё работает до тех пор, пока очередная итерация не вернёт 0 строк результата.

Т.е. получается, что мы в первом запросе нашли все элементы где parent_id = 4, потом нашли элементы, где parent_id - это id из первого запроса, и т.д., пока не кончится.

В случае, если в таблице граф с циклическими связями, то эти итерации не кончатся никогда )

Для того, чтобы бороться с этой проблемой в postgres 14 будут сделаны дополнительные ключевые слова. Но об этом позже )