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 будут сделаны дополнительные ключевые слова. Но об этом позже )

Многое новое - это хорошо закомментированное старое
(из чатика SPb Reliability Meetup https://news.1rj.ru/str/spb_reliability )

Сегодня okmeter.io погорел вместе с дата-центром (https://habr.com/ru/news/t/546264/). Коллега пишет о DRP (https://news.1rj.ru/str/DOFH_ru/2411), а я вспомнил статью на Хабре про это

Готовим DRP — не забудьте учесть метеорит
https://habr.com/ru/company/ruvds/blog/523570/

ЗЫ Скрин не мой, скинули в личку

Записали выпуск "Цинкового прода" про рекурсивные CTE, выгорание, trunk-based dev и много чего еще

00:00 Приветствие
2:00 В PostgreSQL упал новый комит для рекурсивных CTE
20:17 Сгорел дата-центр OVHCloud
25:56 План сохранения онлайн бизнеса при пожаре в дата-центре
29:42 Про замедление работы Twitter Роскомнадзором
36:11 Выгорание - норма?
49:06 О мотивации к программированию
1:04:57 Налог на блогеров
1:08:10 Про Trunk Based и мертвый код
1:26:38 Как часто нужно менять работу/проекты, чтобы не впадать в стагнацию?
1:36:19 Red Hat и Google представили сервис для криптографической верификации кода
1:38:23 Любой ли команде нужен ресурсный менеджер?

https://www.youtube.com/watch?v=iQiCA7SUi2Y

Плюсовики токсично шутят )

https://twitter.com/0xfe0d/status/1370990926198411264?s=09

"Знание некоторых закономерностей освобождает от необходимости знать некоторые факты"

Как я уже написал, "схватывать суть" значит "отделять главное от второстепенного". Всех этому учили классе в пятом, на уроках литературы. Дают прочитать текст, а потом говорят написать по нему краткое изложение, обозначив основную суть. Когда ты маленький - это тебе кажется полной чушью, но с возрастом понимаешь важность таких упражнений. Теперь вам 25...40 и вы открываете документацию по какому-то неизвестному ранее фреймворку. Если вы - плохой разработчик, то вы бездумно копипастите примерчики и встаиваете в свой код. Но если вы ухватываете суть и понимаете зачем этот фреймворк, какую задачу он решает и как примерно это делает - то вам ни к чему держать открытой документацию. Вы уже знаете что "где-то тут должна быть вот такая вот функция" и можете предположить как она называется. В крайнем случае - вы лучше формулируете запрос в гугл. Потому что если вы не умеете видеть главное, видеть суть - то любая библиотека для вас это набор слабосвязанных функций. Половину рабочего времени вы будете проводить в гугле, хотя могли бы выдавать результат.

Коль скоро вы можете схватить суть кода и фреймворка, который вы используете - вы можете схватить суть и своего проекта. На практике это поможет осознать что, скажем, в данном конкретном случае можно обойтись одним php-файликом, а не городить конфиг вебпака на 50 экранов и поднимать кубокластер.

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

Как-то так.

(С) Pavel Novikov ( https://twitter.com/reinforced_sc )

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

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

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

Самый плохой эффект, который я видел - это эффект "срезания" премий. Т.е. если ты получил премию в этом месяце, и не получил в следующем, то это воспринимается ровно как штраф. Штраф выбивает из колеи и демотивирует так, что дальше некуда.

Всякие там звания "сотрудник месяца" - это вообще смешно в 99% случаев. Не видел, чтобы это работало.

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

Надо прислушиваться к мнению, относиться с уважением, дать максимальное количество полномочий (доступ к проду, принятие более менее ключевых решений без особого апрува), короче, чтобы проект воспринимался, как что-то личное.
Программисты идут в программирование, потому что им нравится программировать. Да блин, невозможно изучить (и продолжать изучать) СТОЛЬКО информации из под палки. А значит, надо лишь не мешать, убрать всё плохое. Построить процесс без стрессов.

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

В Chrome 90, который выйдет уже вот-вот, сделают автоматическое добавление https к адресу сайта, если не был указан протокол (при ручном вводе в строке браузера).

Это приведет к тому, что куча сайтов покажет 404 страницу. По разным оценкам больше 15% сайтов не настраивали себе https и не собирались.

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

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

Т.е. понятно, что letsencrypt настроить не так уж сложно, однако насильственные действия корпорации напрягают.

Прикольный сайт. Рассмотрены категории проблемных людей в разработке софта (там и разработчики, и qa, и менеджмент), и описано как с ними взаимодействовать.

Полезно примерить некоторые роли на себя и сделать выводы

https://www.howtodeal.dev/

Есть один канал, называется "Тимлид Очевидность", его ведет Женя Антонов (известная личность в узких тимлидских кругах). Там рассказывается о вещах, которые по идее должны быть очевидны любому тимлиду, но в этом и есть свообразная хитрость. Очевидное становится невероятным, когда его четче вырисовываешь в мозгу и обдумываешь.

К примеру, его пост про прозрачность и доверие: https://news.1rj.ru/str/general_it_talks/78

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

В общем, всем тимлидам и интересущимся крайне рекомендую канал. И надеюсь, что Женя еще раз придет к нам в подкаст, и расскажет что-нибудь интересное )