Исследование. Кроме очевидных последствий вроде замусоривания сети и приближения теории мертвого интернета к реальности, еще и неявные. Во-первых, на чем обучаются нейронки? На корпусах текстов, преимущественно из интернета. Вот только если они тоже сгенерированы нейронками, то получается «кровосмешение» со всеми вытекающими. Во-вторых, уже сейчас тяжело что-то найти — давайте использовать нейропоиск, да? А будет ли он фильтровать нейрослоп? И если наклепать миллион сайтов с «правильной» информацией — что будет показано пользователю?

Если смотреть на проблему шире, то проблема не супер новая: популярность контента очень слабо коррелирует с его качеством. В тех же соцсетях будет больше показов у кликбейтов, спорных тем, и прочего топлива для флейма. Ок, тиктоки теперь снимает и озвучивает нейронка — сильно ли это повлияет на их среднюю полезность? Опять же, SEO не вчера изобрели.

Че делать с этим — неясно. Какой-нибудь “доверенный интернет”? Видел такие попытки, выглядят… странно. Википедия? У нее тоже проблемы. Библиотеки? Arxiv больше не принимает обзоры без ревью — слишком много говна. Опять же, мусорные научные журналы существовали и до нейронок. Каталоги сайтов? Они уже были в 2000-х, не выжили. Какая-нибудь маркировка сгенерированного контента? Удачи с регулированием интернета :/ Внезапно рекламщики пытаются бороться, не давая деньги полудохлым сайтам с нейрослопом, но даже если это приживется, то какие-нибудь соцсети и прочий вебдваноль это не спасет. А инженеры? Вот в топе HN на этой неделе клон HN, генерирующий правдоподобные комментарии, даже сам автор один раз перепутал с настоящим.

Видимо, надо накрываться простыней и ползти…

Каждый Slack — немного снежинка, потому что кроме стандартных унылых эмодзей и пары корпоративных лого там есть немного своих картиночек. Возможно, на основе нафорсенных мемов. Я уже в пару пространств добавил Гарольда, это мой духовный кумир на работе :harold: Еще у меня в заготовках Слоупок, подорожник (чтобы к больным прикладывать) и пара недовольных котов.

Откуда брать эмодзи? Самый популярный склад — Slackmojis. Можно добавить эффектов, например, тут. Еще есть специализированный генератор old man yells at, но других подобных сервисов я не нашел :( (если знаете — пришлите, пожалуйста). Наконец, можно сделать самому, но надо не забыть обрезать фон и проверить, что в уменьшенном варианте смотрится нормально.

Когда писал эту заметку, попалось еще несколько эАй-сервисов текст → эмодзи, но ни один из них не справился с “harold yells at java” :/

В IntelliJ можно “закрепить” довольно много чего: файл с кодом, запуск приложения, результаты тестов, результаты поиска. Основная идея в том, что закрепленная вкладка просто так не закроется — например, повторный запуск тестов не перезатрет результаты предыдущего запуска, а закрепленная вкладка с кодом не будет закрыта при превышении лимита открытых вкладок.

На прошлой неделе я еще узнал, что для тестов можно тупо посмотреть историю, но там даже на демонстрационном скриншоте 6 одинаковых конфигураций подряд, как запомнить “тот самый” запуск — неясно. Проще закрепить.

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

Из смешнявки узнал, что был конкурс на самое длинное сообщение об ошибке от компилятора. Хорошо дополняет конкурс по обфускации кода (про который, я думаю, многие уже знают). Жаль, что за последний год (2015) результатов не выложили, а предыдущие крутятся в основном вокруг включения файла самого в себя (но есть и прикол с Perl и без шаблонов не обошлось).

Хороший видос про серию экспериментов со сроком жизни аккумуляторов телефонов и как различные факторы на нее влияют. Можно поапплодировать автору за постановку эксперимента (даже контрольная группа есть!) и за преданность работе (первый эксперимент начался аж 2020).

Если вкратце, то разница не стоит беспокойства и пользователю не стоит париться о каком-то алгоритме зарядки. Если подробнее, то при быстрой зарядке батарея деградирует чуток быстрее, но лучше следить за тем, чтобы циклы были не полные (30-80% вместо 5-100%). А еще оставлять полностью заряженный телефон на зарядке — не страшно. Я попробовал быстро найти какое-нибудь научное исследование на тему, но ничего достаточно узкого и по делу не обнаружил.

Крутой блог, в котором автор делает красивые и интерактивные визуализации. В основном фокус на графику (например, про цветовые пространства) и физику (например, про шестеренки), но и для разработчиков есть полезное — например, про числа с плавающей точкой или про устройство GPS.

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

Вообще, никто толком не знает что это такое, “продуктивность”, а уж тем более — как это измерять. Есть метрики типа SPACE или DORA, но внедрять их в большую организацию — долго и дорого. А на дашборды никто толком может и не смотреть.

Многие популярные метрики производительности (как и подходы к организации процессов) имеют корни/аналоги в реальном производстве, однако конвеерный труд отличается от умственного труда. У последнего слишком большая вариативность, чтобы грести все под одну гребенку.

Количественные метрики не сохраняют контекст (тут можно еще вспомнить историю The Worst Programmer I Know, в которой разработчик с самыми низкими метриками больше всего повышал метрики команды), ну и самые сложные проблемы организационные, а не технические. (Да и что там говорить, когда мы качество кода померить не можем)

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

Иронично, что докладчик — CEO компании, основной фокус которой — создание инструментов для сбора и анализа этих самых метрик :) И что-то мне подсказывает, что продуктивность в некоторых компаниях может быть опасно близка к культу.

Хорошая статья про антипаттерн “лид — это щит команды” (от всех остальных). Вкратце, подобный подход, возведенный в абсолют, может быть вреден по следующим причинам:

• Команда изолируется от других команд и организации в целом, что приводит к противопоставлению “нас” и “их”.
• Лид выступает дополнительным (иногда лишним) звеном в процессах, и работает испорченным телефоном.
• Из-за изоляции команда отрывается от реальности и обратной связи.
• На самого лида падает куча нагрузки, хотя все люди взрослые, а лид — не нянька.
• Из похожей статьи можно добавить еще что команде-то может и будет хорошо, вот только компании это будет не в плюс: никаких эмерджетных эффектов.

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

Прикольная обучающая игра про примитивы синхронизации. Вы управляете несколькими потоками, цель — достичь “неправильного” состояния или блокировки. Примитивы из C#, но принципиально это ничего не меняет.