Федеральный корабль дураков

Накал идиотии таков, что хочу оставить для истории. На текущий момент в блокировке 16M+ адресов. Сверхкомпетентные кадры из Роскомпозора в азартной погоне за Дуровым очевиднейшим (при этом причина настолько прогнозируема ДО, что действия кажутся даже вот прям сознательными! хотя… не, чего это я, это ж федеральный орган) образом умудрились заблокировать (народ чинит там, где может) часть инфраструктуры следующего:

  • Viber
  • кассы Дикси (опровержение)
  • сервис доставки «Птичка»
  • Skyeng
  • Guild Wars 2
  • Vainglory
  • Guns of Boom
  • Cloudpayments
  • pCloud
  • NuGet
  • lifehacker.ru
  • GiveMe.ru
  • Gross.Wedding
  • Открытая наука
  • Microsoft (Microsoft Office 365, а также обновления Xbox и Windows)
  • Star Citizen
  • Splatoon 2
  • Tezis
  • Spotify
  • Альфа-Банк (часть банкоматов)
  • World of Warships Blitz
  • Total War: Arena
  • Taxamo
  • Ivideon
  • Fortnite
  • Playerunknown’s Battleground
  • Battle.net
  • Netflix
  • Nintendo Switch
  • Elite:Dangerous
  • DuckDuckGo
  • Twitch
  • PSN
  • не подтверждено: Steam, Uplay, Evernote

Надо ли говорить, что Telegram продолжает работу, а Дуров превращается в народного героя?

Источники: GT, В, МК, V, VC, ZM
Продолжу пополнять, конечно.

Категории RDBMS

Вариантов разделения RDBMS на категории много. Зайду с позиции практики и выбора базы на тыщу лет вперёд.
Сначала три постулата.
Во-первых, базы данных — это давно не только лишь SQL и «сделать пару запросов». Оно как внутри теперь напоминает на картинках город (погуглите [oracle 12c architecture diagram], красиво нарисовано), так и по обилию возможностей потрясает (слово сильное, но меня именно оно). В современном мире вы можете почти всю логику приложения сделать на стороне базы, снаружи оставив лишь тонкого клиента.
Во-вторых, при выходе за рамки простых SELECT вы теряете совместимость (возможность легко сменить одну базу на другую). Так же и в инфраструктуре — едва начинаете активно использовать средства репликации, мониторинга, бекапа и т.д., вы снова привязываетесь к определённой базе. Соответственно, едва выходите в production, вам с этим жить долго и счастливо.
В-третьих, если последние два года вы не следили за прогрессом в RDBMS, вы зря. Пересмотрите changelog’и, актуализируйте информацию в голове. До сих пор живы разработчики с мантрой «PostgreSQL не умеет в репликацию», это скучные разработчики, фу.
Так вот. Категорий тоже три.

Платформы. Вы большой и толстый энтерпрайз с большой нагрузкой, десятками схем, тысячами таблиц. Вам нужна RDBMS, которая всё это потянет, а также даст определённые гарантии по SLA и по живучести данных. И чтобы система безопасности была страшнее руководителя безопасников. И чтобы админы не стрелялись, ворочая этой махиной. И чтобы можно было данными оперировать с разных направлений (корпоративные порталы, бухгалтерия, админки, импорты/экспорты и т.д. — всё это отличающиеся по трудозатратам задачи). И вообще чтобы всё. Ой, и чтобы облака. И чтобы RDBMS as a service. И документации целый шкаф. И чтобы интегрировать можно было до бесконечности! И чтобы регулирующие и дестабилизирующие органы по своим ГОСТам принимали! И вон тот кусок поля под помидоры!!!
На этом рынке рулили три монстра: Oracle (Oracle Database), IBM (IBM DB2), Microsoft (MS SQL Server). С некоторых пор их двигает PostgreSQL, который выгодно отличается стоимостью поддержки, динамичнее развивается и вообще «бесплатен» при наличии энтерпрайзных возможностей.
Если угодно, это категория RDBMS уровня предприятий, где предприятия — заводы, банки, гос.учреждения и прочие масштабные ребята. Для эффективного использования требуется специально обученный персонал. Масштаб на конкретном примере: переход Я.Почты с Oracle на PostgreSQL — обратите внимание на объём данных, на RPS, на железо.

База как база. Собственно, то, с чем работает большинство разработчиков. Если у вас сайт как сайт, продукт как продукт, а то и просто надо какие-то данные где-то хранить, но от MongoDB слегка тошнит, да и честный ACID нужен, выбираете… правильно, MySQL (вместе с InnoDB, например). Справедливости ради, MySQL из штанишек вырос давным-давно. Крайне богатый SQL, нагрузку держит отлично, скорость работы вне претензий, стабильность тоже норм.
Почему не «платформа»? Давайте сразу: Oracle не будет выращивать конкурента своему платному продукту. Не будет никакого MySQL EBS, не будет MySQL Forms, умеющих работать с PM/SQL, которого тоже не будет. Вообще много чего не будет из энтерпрайза. Вы хотите хранить охрениарды данных и быстро работать с ними? Ок, вот MySQL. Вы хотите вокруг этих данных с плотной интеграцией разных частей выстраивать орбитальную станцию и продавать в аренду марсианам? Ну, если времени много и нервы титановые, у вас это получится (и получается, да). Но следующее поколение после вас покрутит пальцем у виска и ВСЁ ПЕРЕПИШЕТ.
Важно понять следующее: нет смысла сравнивать MySQL с другими в области хранения и получения данных. Он норм для этого, по иным бенчмаркам лупит ребят сверху. Проблема как его, так и в категории (в которой у MySQL нет конкурентов) начинается при выходе за границы этих потребностей. Это вот та точка, на которой постоянно буксуют джихады MySQL vs PostgreSQL. Вроде и по скорости равны. И SQL везде клёви. И так обе могут, и эдак. Да что ж за нафиг, почему одни после research’а выбирают одно, а другие другое? Да вот ровно потому и: при выборе стратегической RDBMS рассматриваются не только скорости и диалекты. И вот ровно тут MySQL так у границы топтаться и будет.
Категория RDBMS уровня небольших предприятий, одного продукта. Или огромного продукта для хранения данных без особой логической нагрузки (иными словами, половина приложения не на стороне базы в виде процедур и функций). Для эффективного использования… Тут тяжело. Все считают, что знают MySQL, простота LAMP в наших сердцах. По факту мало кто использует именно MySQL, лишь разворачивают быстренько, слегка тюнят, потом обстреливают простыми запросами. Им хватает. А так-то MySQL — сотни страниц документации и сотни features.

Базёнки. Маленькие и/или встраиваемые RDBMS. Тут веселее: SQLite, Firebird, Derby и т.д. Типичное применение — local storage в Google Chrome, туда SQLite воткнули.
Няшные тем, что кушают очень мало ресурса, но при этом вполне толковые. Понятно, что нагрузку на них не пустишь, ожидать серьёзную репликацию и failover тоже не стоит, но для своих целей всё давно уже хорошо заточено.
Категория… ну вот какая? Если вам требуется маленькое встроить или рядом поставить, но при этом чтобы не требовалось админство-админство. Пусть будет «категория RDBMS уровня модуля приложения». Квалификация персонала — встроить и забыть.

Вот как-то так. Деление условное, простое, но достаточное, чтобы включить размышлялку и подумать о том, как правильно выбирать RDBMS, на что повлияет выбор, на какие качества базы смотреть.
PS. Любопытно ещё следующее на фоне фанатских войн… Любая RDBMS что категории «платформа», что «база как база» — сложный насыщенный продукт. Споры разработчиков о том, что лучше — зачастую споры людей, которые понятия не имеют, какой уровень SQL поддерживается, при каких условиях какие lock’и и на чём, как конкретно работают виды репликации, какие особенности шардирования и т.п. Большинство из вас не использует MySQL или PostgreSQL. Вы используете условную RDBMS, в которой вам интересно малое подмножество SQL (ну откройте спецификацию языка и скажите, действительно ли вы его знаете), ну и сверху ещё несколько шняжек, с которыми у вас получилось работать. С остальным сталкивается эксплуатация (которая тоже не всегда может выделить из своих рядов специалиста), а также бойцы, которые пытаются иногда выйти за рамки «стандартного SQL». Но и среди них редко встретишь полноценного DBA, прошедшего полноценное [само]обучение по продукту (у которого 3500+ страниц документации, например). Потому споры эти бестолковы и смысла не имеют, только бы совочками помахать.

О сертификациях

К сертификациям в разработке отношение сложное. Как 15 лет назад мы с недоумением смотрели на коллегу, который сдал пару Java-экзаменов, так и сейчас в наших краях оно вроде как и бесполезно, да ещё и дорого, три экзамена — топовый смартфон, ага.
Что любопытно, на Западе и на Востоке всё диаметрально иначе. Если речь идёт о вендорных дипломах (Oracle, Microsoft, Cisco, Amazon и т.д.), статистически вы заметно повышаете свой доход. А уж админы и NOC’и без сертификаций… скажем, приветствуются далеко не везде. На деле у них чуть ли не на порядок (относительно разработки) всё это развитее, особенно если с Cisco работать.

Итак, вы простой советский разработчик в размышлениях «а нафига». Вот мои ответы мне на эти «нафига». Собирал и осмыслял много лет, пока не собрал критическую массу, после чего сдвинул жопу с тёплого стула. Внимайте.
Во-первых, мотивация выучить то, до чего иначе руки не дотягиваются. Девять из десяти разработчиков знают области разработки на уровне «знаю только то, что применяю в своей работе на ПупкинСофт Ltd». Мне это стыдно и скучно, но всё равно не хватает пинка, чтобы вернуться к азам. Провалил экзамен — выбросил в окно 7 ящиков шотландского эля — жалко, блин. Лучше выучу.
Во-вторых, в процессе подготовки узнаёшь много интересного и немало полезного. У вас не получится тупо зазубрить ответы на билеты, т.к. билеты не публикуются. Приходится зубрить темы целиком, что приводит к просветлению головы и автоматическому повышению квалификации. Заодно это хорошее лекарство от избыточной самоуверенности, спеси и зазнайства. До подготовки ты крутой и всё знаешь, а тут вдруг того не знаешь, этого, сего и ещё про вон ту конструкцию даже не догадывался. Поневоле задумаешься о том, сколько раз за годы на основе такого невежества озвучивал совершенно идиотские суждения.
В-третьих, лидам полезно самим пройти распространённые сертификации из их области, чтобы объективнее оценивать наличие сертификатов в резюме. Как минимум, сможете сократить или упростить собеседования, что на потоке уже хорошо.
В-четвёртых, весь мой опыт говорит следующее — вы никогда не угадаете, какая бумажка вам поможет в будущем, но совершенно точно ни одна позитивная бумажка о ваших достижениях не будет лишней (ну, помимо диплома о первом месте на поселковой олимпиаде по информатике). Выстрелить в вашу пользу может в совершенно случайный момент. Да даже тем, что у рекрутера глаз зацепился и ваше резюме легло на верх стопки — уже это может сдвинуть жизнь на 90 градусов.
В-пятых, сертификаты действительно показывают профессиональный уровень их владельца. Да, там много наивных вопросов. Да, задачи бывают идиотскими. Фигня в том, что многие разработчики не могут ответить на эти вопросы и не могут решить эти задачи. Люди, может, и хорошие, но на Python-собеседовании на 10 минут уходят в себя, не в силах вспомнить, есть ли в языке тернарный оператор. И если я увижу в резюме хотя бы entry level сертификат (обычно они про синтаксис), я буду знать — этот боец знает, где какой оператор.
В-шестых, однажды вы можете мигрировать. Я минут тридцать ради fact checking листал job-сайты США и всё так же вижу много вакансий, в которых так или иначе, но варианты следующего: «Must possess at minimum an Oracle Certified Associate Java SE x Programmer certification or must obtain an Oracle Certified Associate Java SE x Programmer certification within 120 days after hire». Да, обычно это крупные бюрократизированные конторы. Но вы уверены, что уже через год от переезда нанявший вас стартап не развалится и вы не будете лихорадочно искать любое место?
В-седьмых, сертификации и сертификаты — объективная часть мира разработки. Никого не волнует ваше мнение о том, нужны ли они, полезны ли они, что они показывают и т.п. Они есть. Через них прошли миллионы разработчиков. Они влияют на оклады, на контракты, на собеседования. Вы либо принимаете правила игры и хоть ознакомительно осваиваете этот угол ринга, либо бестолково бунтуете, отрицая, либо равнодушно игнорируете, пока не столкнётесь. Как по мне, мудрее ознакомиться до того, как возникнет нужда.
В-восьмых, наконец, это fun. Не, правда. Годный вариант отойти в сторону от рутины и вспомнить, что такое учебники, билеты, экзамены, волнение «сдал? завалил?» Мне понравилось. Теперь точно буду в год хоть по два сертификата получать, чтобы развлечься.

Итого… Ну, понятно, что я в основном вижу лишь плюсы. Правда, важно помнить главное: сертификация — она для вас, она в ваших интересах, она решает ваши задачи и проблемы. Вас не будут носить на руках на следующий же день от сдачи, не будут на собеседованиях чествовать красной дорожкой. Это стратегический вклад кирпичика в вашу стену специалиста. Без остальных кирпичиков (интеллект, дисциплина, множество знаний из разных областей, трудолюбие и т.д.) не стоит ничего.
PS. Подчеркну: речь не про Курсеры и Брейнбенчи, речь про те экзамены, которые вы сдаёте производителям софта / железа, получая сертификат соответствия знаний стандартам производителя.

О жизни после 30

Раз за разом сталкиваюсь в сети с копипастой мнения о том, как трудно после 30 лет (или 35, или 40, да любое приятное глазу число) найти работу программистом. Даже бывают интервью со «старичками», мол, расскажите, как вам живётся-то, уникальные существа.

За последние лет пять я пару раз поднимал руку в режиме «свободная касса», ну и вообще был открыт предложениям даже из исследовательского любопытства. Безусловно, те, кого смущал мой возраст или потенциальный overqualified, не писали письма и не звонили. В то же время писавших и звонивших было много. Одна рекордная неделя словила в себя 20+ вызовов на собеседование. География: Россия, Украина, Латвия, Польша, Германия, США, Ирландия, Англия, Австралия, Вьетнам, Япония.
Так на что всё-таки влияет возраст? На него примеряют рабочий стаж и типичные рабочие пути развития. Если разработчик в 40 лет знает только один язык и только одну RDBMS, это странно. Если разработчик в 20 лет знает десять языков, пять RDBMS и пять NoSQL, это смешно (да, самые богатые на buzzwords резюме — резюме студентов). Если к 50 годам ни разу не был teamlead’ом, это интересно (не может или не хочет или не было возможности — выясняется на собеседовании). Также [условно] 30+ лет — это повод на собеседовании отдельно проверить, не выгорел ли, не устал ли от профессии, остался ли ещё задор и запал (об этом ниже).
Есть большой соблазн закрыть глаза на объективные (или важные субъективные) причины того, что вы кому-то куда-то не подходите. Внезапно да, чем больше стаж, тем большего от вас ожидают. Тем с бОльшим интересом читают резюме. И собеседуют не про таблицу умножения. И на позицию джуниора не возьмут, пусть вы туда и захотите. К вам выше требования, т.к. человек, который за 10+ лет опыта работы по специальности не нарастил знания и умения до этих повышенных требований, вызывает оправданные сомнения.
Есть ещё категория граждан, у которых проблема не с возрастом, но с затвердеванием и унылостью сознания. Человек устал. Или выгорел. Или осознал, что разработка не его, но идёт по инерции и кушать привык. Или отвык учиться. Молодым на азарте выучил, освоил, по накатанной как-то телепался, а груз невыученного уже тащит ко дну. Или закостенел в самодовольстве «я и так всё знаю, ничего не надо» (привет чувакам с Java 1.6 и Python 2.7). Да, на то, чтобы так сформировался взгляд на мир, потребовались те 10+ лет. Но проблема-то не в возрасте, а во взгляде. И собеседующий, созерцающий вас, тоже всё это видит, если не пофигист.
Ну а если вас куда-то ну совершенно точно не взяли из-за возраста (и это не экспедиция на Марс), уверяю, вы в таком месте и сами не захотите работать, там неумные. Например, у них молодой и энергичный коллектив 20-летних звёзд эстрады, а тут ты со своей постной физиономией. Непорядок.

Можно возразить, что это мой личный опыт, у других иначе и т.п. Слава духам, как было на старте карьеры много знакомых, так и осталось. Десятки, если не сотни, людей, которые как тогда были сверстниками, так ими и остались. Большинству 30+ лет. Почти все, кто хотел, работают. Кто разрабами в окопах, кто лидами. Многие разбросались по миру. Вроде бы ни у кого не было явно выползшей проблемы из озвученных выше. Да, оно могло быть под ковром, да и не все мне всё рассказывают. Но такая фигня вызвала бы достаточно много смеха и лулзов, чтобы всплыть.
PS. Сегодня по Skype первично собеседовал разработчика. Ему 40 лет и у него всё хорошо.

Книга: Oracle Certified Professional Java SE 8 Programmer Exam 1Z0-809

z809
SG Ganesh, Hari Kiran Kumar, Tushar Sharma.
Oracle Certified Professional Java SE 8 Programmer Exam 1Z0-809: A Comprehensive OCPJP 8 Certification Guide.
Apress, 2015.
За последние пару лет это самая скучная книга по разработке, что читал. Авторы взяли список экзаменационных тем и пересказали его в режиме «напоминаем, что есть такой класс, вот его несколько методов из десятков, вот пример кода, где мы тривиально используем класс, всё».
Так и читается. Очень поверхностный каталог без внятного объяснения семантики, без глубокой проработки тем, без всего. Разве что 175 задачек полезны (90 разбросаны по главам, 85 в mock exam).
Если предыдущая книга меня ушатала уровнем школьного учебника для первых классов, то эта ввергла в пучины умственной депрессии. И ладно бы действительно готовила к сдаче, но нет, буквально всё вам надо будет дополнительно подбирать на стороне.
Рекомендовать не могу. Разве что в качестве расширенной шпаргалки к списку тем на повторение. Но на 475 страницах можно было и больше сделать.

Тимлид в трёх лицах

Одна из вечных тем — что такое [хороший] teamlead? И вечные споры и дискуссии. Как водится, у меня своя точка зрения. Тимлид — набор из трёх ролей, который может быть хорошим в одной ситуации и плохим в другой. Эта неоднозначность и небинарность является, как считаю, причиной споров.

Психолог (люди). Решение психологических проблем команды, тонкая манипуляция, дипломатия, разнообразная мотивация, гашение конфликтов, подбор подходящих друг другу людей и т.д.
По сути это социальные навыки, soft skills. То, к чему должно быть расположение от природы, породы и анамнеза. Если у вас в быту не получается с эмпатией или вы непробиваемый эгоист (видящий всё сугубо через Я, Я, Я!), о роли психолога можно забыть. Тут прокачивать с нуля не получится, особенно уже сформированным личностям.
Примеры типичных задач:

  • Открыть рот и связно озвучить мысли так, чтобы было понятно, о чём речь. Без этого выше табуретки никак.
  • Открыть рот и звуками убедить кого-либо в чём-либо так, чтобы этот кто-либо понял, захотел, сделал. Первый шаг к тимлиду.
  • Подбор подходящих коллективу людей. Не запихивать тихонь в клетку с тиграми, не топить тигров в пруду тихонь.
  • Выслушивать. Очень важное умение, дающееся не всем. Слушать не себя, не перебивать, запоминать слова, интонации.
  • Объяснять, почему повышают или не повышают. Не самая приятная обязанность, но надо.
  • Донести критику или одобрение. Как, собственно, самому уметь принимать как одно, так и другое.
  • Управлять конфликтами. Они были, есть и будут. Люди не травоядные и некоторая доза конфликтов даже нужна. Задача психолога не допустить их перехода в системную проблему.
  • Определять человеческие факторы производства и понимать, что с ними делать дальше. Вася апатичен и вяло работает? Почему? Он изначально такой или есть внешняя причина? О, так он сова, а его запихнули в жёсткий утренний график. Давайте попробуем его на вторую половину дня. Попробовали, Вася начал отжигать напалмом и повеселел.
  • Внедрение мотивации в членов команды. Федя слабо работает. Если Феде доходчиво объяснить цели, выгоды и соответствие работы ценностям Феди, он будет работать сильнее. Или не будет. Феди всякие бывают.

Тимлид работает с командой и организует команду. Команда — люди. Человек, у которого психолог на нуле или даже в минусе, успешным тимлидом быть не может. Это просто невозможно.


Логистик (процессы). Понимание и выстраивание процессов производства. Спектр задач тут большой и включает в себя много всякого разного ранга: схема статусов у тикетов согласно проекту, элементы CI, распределение зон ответственности, протоколы безопасности, чеклисты реакции на мониторинг, организация нужных встреч, контроль планов и само планирование, и т.п., и т.д. Фактически всё, что является дорогой между пунктами A (задумка продукта) и Z (продукт в production’е).
По сути это навык организации, который начинается с самоорганизации. В какой-то мере тоже личностная характеристика в основе. У человека должно быть стремление к упорядочиванию окружающего, да и внутреннего. Чёт не верю я в раздолбаев, успешно спроектировавших и построивших сборочный цех софта. Подчеркну — речь о повторяемом процессе, а не про одноразовый [случайный] win.
Примеры типичных задач:

  • Организовать коммуникации внутри команды и команды с внешним миром. Живые встречи, каналы мессенджеров, рассылки, знакомство людей друг с другом.
  • Организовать отчётность (срезы статуса) как по отдельным задачам, так и всего в целом. В любой момент должно быть понятно состояние системы.
  • Организовать инфраструктуру производства. Где разработка, где тестирование, где боевые сервера, где сборочные фермы и т.п.
  • Определить зоны ответственности. Не должно быть кода, серверов, задач и любого иного, над чем не стоит конкретный человек с пониманием, что это его песочница, за успехи в которой хвалят, за поражения ругают.
  • Спланировать разработку продукта. Ох, планирование, да. Отдельная огромная тема.
  • Определять и убирать слабые звенья. Например, регулярные формальные встречи, на которых все зевают или играют в Тетрис под столом.

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


Специалист (разработка). Глубокое знание предметной области, контроль качества реализации продукта. Пожалуй, самая очевидная и самая распространённая роль из-за обычая брать тимлидов из среды разработчиков.
Хоть я ниже допускаю вариант слабого специалиста (и его компенсации) в тимлидах, но это больше теория. На практике всё сложнее. Если тимлид тотально слабее в матчасти своих бойцов, он не может выполнять чуть ли не половину функций — не научит, не проверит, не проконтролирует. Как если первоклашку поставить ведущим разработчиком на уроках матана девятого класса, много он там со своими счётными палочками наводит, ага.
Но есть ещё нюанс. По миру ситуация меняется, а вот на просторах xUSSR команды разработчиков всё ещё в массе мужские со всеми приметами мужского коллектива. Разработчики не будут уважать тимлида, если он не является в какой-либо смежной области заметно более сильным специалистом. Не примерно равным, но заметно более — это важно. Может, всё-таки и будут, но не как разработчика. А без уважения всё становится сложнее. Хочешь не только по трудовой быть тимлидом? Изволь спросонья озвучить лекцию по булевой алгебре и вариантах рекурсии. Нет? Удачи.
Примеры типичных задач:

  • Разработка софта. Если программист не программирует, он теряет квалификацию.
  • Определение стратегии технического развития. Примитивный пример: вводить ли в стек новый язык?
  • Определение квалификации членов команды. Надо понимать, можно ли давать Петрову задачу по проектированию схемы данных из ста таблиц или Петров не знает, что такое primary key (очевидно, сам тимлид должен быть на уровне задачи).
  • Подтягивание квалификации членов команды. Как быть ориентиром (наш Вася крутой, я хочу стать крутым, учусь у Васи быть Васей), так и микролекциями, литературой, дискуссиями, кодом и т.д.
  • Ревью кода и решений. Тимлид должен понимать и уметь в хороший код, чтобы контролировать создание оного членами команды.
  • Обеспечение или контроль инфраструктуры производства и продукта в рамках компетенции. Оптимально ли настроена база данных? Те ли типы инстансов в облаке? Куда и как складываются логи? Почему так долго собирается билд?

Простота роли в том, что её можно сознательно прокачать, если голова на нужной позиции. Сложность лишь количественная — очень много чтения, осмысления и экспериментов, потому «ах, да я во всём крут» не получится никак.


И вот тут проблема: людей, совмещающих в себе все три роли на высоком уровне, [почти] не бывает. Хотел бы сказать, что их вообще нет, но остерегусь, мало ли. Общение с компьютером с детства развивает специалиста, но не способствует росту психолога. Психолог развивает с друзьями модные soft skills, пока на полке пылятся так и не открытые учебники по программированию. Логистик рождается в муках опыта, наблюдений, размышлений и снова учёбы.
Я пока видел только два действительно работающих способа решения.
Во-первых, в Яндексе боевые пары, которые забавно напоминают ролями семью. Менеджер (часто девушка) — психолог+логистик, тимлид (часто мужчина) — специалист+логистик. Соответственно, вдвоём они представляют собою универсального лида. Менеджер (мама) утирает слёзы, смягчает конфликты, обеспечивает социализацию команды, организует логистику продукта, организует само понимание продукта (а то эти роботы без тени сомнения напишут двумерного коня в кирпичном эфире), служит посредником между командой и внешним миром, напоминает команде о пользователях, вообще душа и человечное лицо команды. Тимлид (папа) организует разработку проекта, карает и поощрительно трогает плечо, сам укладывается под танк на амбразуру авралов, укладывает других, корректирует планы согласно уровням разработчиков. Если сработались, результат офигительный. Если нет, всё идёт на дно и по дну, в чём и риск такого варианта относительно единоличной диктатуры.
Во-вторых, подбор команды под тимлид(а|ов). Если нет умения или желания возиться с психологией, набор зрелых взрослых людей без явных проблем с головой — это делает ненужным развитого психолога. Если слабый специалист в лидах, набор строго сильных разработчиков, которых не надо контролировать или выращивать — лиду достаточно не вмешиваться. Если проблемы с логистиком, набор опытных (сильные не всегда опытные, потому набор выше из другой оперы) разработчиков, они сами организуются — слабый логистик там же и обучится.

Стремящийся стать хорошим тимлидом понимает свои слабые и сильные роли. Плохой не понимает.
Плохой психолог устраивает показушные игры в «давай поговорим» или «вы можете подойти ко мне с любым вопросом». Хороший и так знает / чувствует, что происходит, а с вопросами к нему и без напоминаний подойдут. // Я, к слову, фиговый психолог, но все и так знают, что злобное бревно. Компенсирую тем, что пытаюсь выстроить процессы, при которых в психологе нет нужды — ясные правила поощрений, тщательный подбор адекватной команды, прозрачность всей работы всех и т.п.
Плохой логистик тащит всё хайповое как сорока в гнездо. Вчера у нас был водопад, сегодня скрам, завтра коворкинг на хакатоне с интенсивным митапом тренеров по TDD без ТЗ. Другой вариант плохого в силовом напяливании идеалистических схем на неподходящий коллектив. Да, отверстие круглое, а болт квадратный, зато я сильный. Хороший делает так, что именно эти люди делают продукты именно этой категории максимально эффективно с учётом ротации кадров, фазы Луны и законодательства Гаити. Если не получается, оставляет всех в покое и смотрит, какую схему выработает команда — сначала смотрим на народную тропинку, а потом на её месте асфальтируем дорожку.
Плохой специалист всем просто мешает. Арнольд два дня оптимизировал тяжёлый запрос к базе, а тимлид зарезал, так как не понял текст запроса (ридабилити пострадало! скорость нинужна!). Плохой специалист не может аргументировать решения, потому тупо насаждает свои субъективные вкусы. Хороший специалист не мешает команде, особенно если команда решает задачу по результату лучше, чем сам смог бы. Также он каждое своё решение объясняет так, что решение становится очевидным. В конце концов, если чего не знает, так и говорит: да хрен его знает, разберитесь сами, потом меня научите.

Безусловно, всё ещё сложнее на пару порядков, всегда есть исключения и всё такое. Но мне схема выше удобна простотой и практичностью модели, от которой я могу отталкиваться, не затрачивая недели на принятие решений или на понимание явлений.
PS. Тем, кто обратил внимание на то, что по тексту в Яндексе менеджеры девушки, скажу следующее (и это нередко упоминалось в беседах с коллегами) — в Яндексе [не]удивительно много умных, энергичных и красивых женщин. Мне приятно называть их именно девушками.

Python и попкорн

Не всегда получается донести до собеседников причину, по которой я смотрю на мир Python с попкорном в руках. Попробую тут.
Сразу две вводные.
Python — инструмент. Если в нём что-то не устраивает, скорее всего, вы применили инструмент не к той задаче. Oy vey iz mir! Я написал на Python прошивку к реалтаймовому процессингу на карточных чипах, а оно не работает! Плохой, плохой Python! Очевидно, дело не в языке, но в ДНК специалиста. У правильно применяющих всё хорошо. У них, впрочем, и с BASIC хорошо будет. Голова на плечах рулит.
Python — не универсальный инструмент и не панацея от криворукости (уже писал, что на самом деле писать хороший код на Python сложнее, чем на Java/C++), но из-за кажущейся простоты порога входа получил армию фанатов. Часть критики Python вызвана желанием потыкать палочкой этот вот детский сад, для которого нет большего счастья и радости, чем не указывать типы. Так вот, это эссе не критика, не замахивание на святое и не всё то, что желает читать стремительно наполняемый кровью мозг.

Потреблению попкорна способствует история Python 3 и поддержки оной версии сообществом. Сегодня у меня в очередной раз всколыхнулся потому, что хотел почитать логи MongoDB более цивилизованно (aka с помощью mtools). Открываю, вижу «mtools is not currently compatible with Python 3», закрываю.

Шёл 2006 год (12 лет назад он был). Гвидо создаёт PEP 3000. Или лучше назад отойти? Не понять, какой год считать годом появления Python 3, т.к. Гвидо о нём думал ещё раньше. Скажем, в 2004 году запостил флеймообразующий постик «Optional Static Typing to Python» (у питонистов тогда знатно глаза и пальцы разгорелись, понадобились умиротворяющие постики). Как ни крути, но если вам кажется, что Python 3 — что-то новое, ну вот пару-тройку лет назад появилось, то нет. Более того, уже в декабре 2008 года был выпущен Python 3.0 final.
Добавлю фона для сравнения.
Kotlin — разрабатывается с 2010 года (думаю, всё-таки раньше начали), первый релиз в 2011 году. Swift — разрабатывается с 2010 года, первый релиз в 2014 году. Go — разрабатывается с 2007 года, первый релиз в 2009 году. Rust — разрабатывается с 2006 года, первый релиз в 2010 году. Эти даты должны вам помочь увидеть живую практику других языков. За 2..4 года разработка, воодушевлённый народ начинает фигачить вовсю тоже уже через 2..4 года, хоть у Swift особенный кейс, там один вендорный язык для вендорной платформы заменяется другим, потому особо выбора не было.

Что же произошло с 3.0? А ничего. Он сразу утонул под критикой. Вот удобная известная статья, в которой всё основное собрано. Шли годы. Вышел 3.1 (2009), 3.2 (2011), 3.3 (2012). Воз стоял на том же месте. Питонисты всё так же расползались по двум лагерям. В основном (я обгуглился переписок, интервью и прочего тех лет) война шла на трёх фронтах.
Во-первых, критиковали производительность. Бенчмарки, в которых 3.x был заметно медленнее 2.7, взывали к разуму. Но… матёрые сторонники прогресса (да и Python’а в целом) отбивались аргументом «нам и не надо!» С технической точки зрения аргумент настолько меня забавляет, что детализирую. Вот хороший пример — Python норм, проблема не в нём, а если в нём, напишите важное на C/C++ или юзайте Cython. Знаю немало питонистов. Живых таких реальных мужчин от 20 до 35 лет возрастом. С удовольствием представляю, как они пишут быстрокод на C/C++, ага. Гвидо, между тем, придерживался той же аргументации (говорящий заголовок статьи: «Van Rossum: Python is not too slow»):

It is usually much more effective to take that one piece and replace that one function or module with a little bit of code you wrote in C or C++ rather than rewriting your entire system in a faster language, because for most of what you’re doing, the speed of the language is irrelevant.

Я б добавил, что разумнее сразу писать на чём-то, что потом не потребует внедрения ещё одного-двух языков в стек, но это наверняка будет гораздо менее выразительно, чем писать на Python. В любом случае репутация 3.x была подмочена, т.к. столько лет делают, а везде и заметно быстрее не стало.

Во-вторых, несовместимость. За то, что 3.x не собирался поддерживать выполнение кода 2.x, Гвидо был виртуально бит задолго до релиза 3.0, но стоял на своём упорно. Мигрируйте и будет вам счастье, даже сделали 2to3, всех проблем не решавший, но всё же. Один фиг предполагалось, что вы просмотрите глазами весь свой исходник. И ладно бы, но как быть с мегатонной библиотек? Что вам радости, если 80% всех зависимостей совместимы с Python 3, а 20% нет? Должны быть 100%. Как итог, каждый уважающий себя питонист раз в неделю ходи(л|т) на py3readiness.org, проверяя, ну когда же, ну блин же. И если в Java/C++ 99.99% проблем миграции вам укажет компилятор, то в Python не так. При неудачном забеге звёзд вполне можно получить выстрел в рантайме просто потому, что в какой-нибудь уголок забытый не заглянул глазами, не потрогал руками.
В-третьих, нафига? Линейных разработчиков вопросы стратегии и legacy не волнуют. Их волнует, чтобы переход с X на Y был пыщ-пыщ. А Python 3 сумму пыщ-пыщ добрал лишь вот относительно недавно. Версия 3.6 (конца 2016 года) в сумме с возможностями предыдущих версий выглядит прям вот интересно и убедительно. Правда, с опозданием. Я не зря выше остановился на 3.3. Кажется, что это версия, на которой в умах произошёл надлом. Четыре года от первого релиза, а лучше не стало. Работает медленно. Никаких увлекательных свистелок-перделок, которыми можно заманить жаждущих хлеба со зрелищами. Планетарная миграция даже не началась, да и куда мигрировать, если вы сидите на версии Django, которую никто даже и чесать не собирается? В общем, всё плохо. И вот это «всё плохо» в головах устаканилось намертво.

И всё. Сообщество знатно затвердело. Как одни слепо за Путина, а другие слепо за Навального, так и тут. Можно хоть монтировку согнуть об иные лбы, но лбы совершенно искренне не будут понимать, зачем им Python 3. В их мире Python 2.7 вечен, Python 3 вечно медленный (это давно не так), не поддерживается (это давно не так), в нём нет прикольных фич (это давно не так). В 2018 году (спустя 10 лет релиза!) мир вовсю осваивает четыре новых языка, но мир питонистов до сих пор не может перейти на тройку. Ну вот никак. Это постоянный цирк и бардак. Самый распоследний 2.7.x вышел в конце 2016 года. Ветка не поддерживается, ветка не развивается. Всё равно будем держаться за неё до последнего!
В финале докину ещё примеров того, как в стороне от цирка развивается планета. С 2011 года по 2017 год вышли C++11, C++14, C++17. Вышел PHP7 в 2015 году. Вы [не] будете смеяться, но даже успели выпустить стандарт Fortran 2008 и вот-вот доработают Fortran 2018 (ранее Fortran 2015). Ужасный, медленный и кровавый мир Java успел выродить Java 7, 8 и 9 (позавчера и 10). А, да, первый релиз MongoDB вышел в 2009 году. Блокчейны… криптовалюты… квантовые процессоры…
А Python 2.7 (ветка началась в 2010 году, напомню) вовсю в production’е. И до фига живых людей не хотят от неё отказываться. Потому со стороны вся эта смешная история и смотрится с попкорном. Слишком уж в разрыве от общей практики происходит, слишком фанатично (aka не профессионально) воюет сама с собою эта часть сообщества, чтобы не превратиться в многолетний анекдот.
PS. Да, на собеседования приходят питонисты, которые заранее говорят, что Python 3 не знают совсем. Его нет в их текущей работе, а вне работы причин узнать не было. Радуюсь. Восхищаюсь.
PPS. Полтора года назад уже затрагивал тему, но чуть иначе и менее ссылочно. Не могу сказать, что всё кардинально изменилось. Не-а.

Miscellanea XIX

Чем дольше разработчик работает на одном месте, тем больше у него багаж ситуаций, в которых сделали фигню и это прокатило. То на прод вне тестирования катнули. То руками пошевелили в мастере базы. То тихонько забили на инструкцию. А дальше роль личности. Либо этот багаж мотивирует больше никогда так не делать, либо человеческое берёт верх и качество специалиста падает. Потому на старичков надо смотреть внимательнее.

Вот занятно. До последнего поколения у языков были авторы-люди. C++ создал Страуструп, C создали Ритчи и Томпсон, Python Гвидо, Java Гослинг и т.д. Сейчас время больших батальонов, что косвенно выражается в уходе личностей за ширму. Да, у любого языка есть конкретные авторы, но Go — это Google, Swift — Apple, Rust — Mozilla, Kotlin — JetBrains. И вроде объективно ничего не изменилось, раньше языки тоже появлялись или активно развивались внутри компаний, но вот.

Между тем, в мире разворачивается драма из высших уровней кровавого энтерпрайза. Раскручивать содержание темы можно от Phoenix Pay System, ленивым кратко перескажу. В 2009 году правительство Канады решило заменить свою 40-летней давности систему начисления и выплат зарплат, ну и вообще автоматизировать и экономить. Выбор пал на IBM с Oracle. Пацаны вроде крутые, опытные, будет счастье. В 2016 году систему запустили, с тех пор мечтают погасить, ибо бракобажище получилось лютейшее, что при общих тратах бюджета в $790M несколько фраппирует канадскую общественность. С другой половины планеты одобряюще улюлюкают австралийцы, наступившие на эту мину ранее. Оба кейса интересны тем, что большой бизнес может по контракту поставлять неработающие решения за огромные деньги и не пострадать. Совсем другие правила игры.

ALGOL любопытен тем, что этот язык очень, очень повлиял на развитие программирования, но при этом почти не использовался в разработке. Даже была шутка 60-х: ALGOL нужен для того, чтобы описать алгоритм, а потом реализовать его на FORTRAN. Одна из основных причин, если верить копипасте из статей в статьи — чуваки не стандартизировали I/O, что для промышленной разработки фу и кака. Ситуацию в какой-то мере выправляли диалекты (вроде ALGOL W), но язык это не спасло. Как был очень влиятельным, но академическим, так и остался.

Иногда встречаю разработчиков, которые считают, что знают Java, если у них опыт работы и знание Java 7, не дальше. Народ. Между Java 7 (2011 год) и Java 8 (2014 год) пропасть (стримы, лямбды, default и static в интерфейсах, новый Time API и т.д.). В 2018 году вообще уже пора Java 9 осваивать и про Java 10 думать. Хочется спросить, почему за 4 года вне работы, если она прибила семёрку гвоздями, не освоил изменения? Пофиг было? Тогда зачем «джавист»? Не надо так.

1Z0-808 (Java SE 8 Programmer I)

1Z0-808 (Java SE 8 Programmer I) — сертификация начального уровня от Oracle, без которой не допустят до остальной линейки. Хоть весной уже и Java 10 выйдет, тесты пока не обновляют, у Oracle с этим туго. Потом можно будет сдать отдельный update.
70 (не 77, как иногда пишут) рандомных вопросов, 150 минут, проходные 65%. Темы про основы самого языка без вопросов о множестве библиотек (это счастье на следующих уровнях), достаточно знать лишь десятка два распространённых в быту классов. Во время сдачи никаких гаджетов, интернета, IDE, компилятора и т.п. Вас даже рукава попросят закатать, проверяя отсутствие шпаргалок. Пользоваться только головой.
Хоть уровень и junior, без подготовки могут быть сюрпризы. Java местами не самый очевидный язык, есть как формально верные, но неиспользуемые части (про них спросят), так и то, что понять не получается, надо просто запомнить в идеале именно так, как в JLS сказано.

Литературная подготовка включала в себя только чтение OCA Java SE 8 Programmer I Certification Guide — чтение унылое, скучное, но обязательное. Книга хороша тем, что настраивает голову на нужный лад. Вы многократно повторяете материал и знакомитесь с примерами вопросов для того, чтобы привыкнуть (это важно) к характеру сертификации. С этим управился за 18 дней.
Также купил mock exams у Enthuware. 600+ вопросов, потому развлечение эдак на 10..12 часов. Подспорье крутое, тут претензий нет, очень советую не пожалеть почти 600 рублей (ага, по рублю за задачку).
Во-первых, повторение материала, но с другого угла. Некоторые темы после марафона подготовки у меня от зубов отлетают — на задачу не более 15 секунд тратил.
Во-вторых, некоторые задачи там специфические. Их не должно быть на экзамене, т.к. нет в списке разделов от Oracle, но людям попадались.
В-третьих, смирение. Невозможно не впасть в оное после десятков задач, «сложность» которых сугубо механическая и на внимательность. Плохое форматирование, нетрадиционный порядок кода, запутанность имён, череда арифметики в циклах. Легко можно выбрать неверный ответ только потому, что в варианте не заметили замены двойной кавычки на одинарную.
В-четвёртых, уровень. Задачи качественно и количественно сложнее, чем на сертификации — часть времени и сил потратите на то, чего не будет в бою. Но если даже с учётом этого уверенно во всех тестах набрали проходной процент, значит, можно двигать на настоящую сдачу.

Проходил 15 марта в Softline. Сдал успешно на 95% за полтора часа. Боевой экзамен оказался настолько лёгким после подготовки, что я каждый вопрос раз пять вычитывал, выискивая хитрые подвохи. Но нет, подвохов почти и не было. Те три вопроса, в которых ошибся, сугубо из-за лени — влом было зазубривать прям вот до пуговки Time API, за что и поплатился.

22 дня на подготовку, в среднем полтора часа в сутки. 700 страниц учебника, около 750 тестовых задач, около 100 страниц дополнительного материала (JLS, статьи, Javadoc к JDK), почти 14000 рублей.