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

Накал идиотии таков, что хочу оставить для истории. На текущий момент в блокировке 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 страницах можно было и больше сделать.