Аналитики: этонужнобизнесу! Менеджиент: Боги хотят больше кода! Больше кода для богов! Инженеры: Нифиганепонял, вот вам копипаста из соседнего проекта. Реальность: Вы родили очередную метрику формата "килограмм ежа на квадратный метод ужа" на которую всем будет плевать через три недели включая авторов. Кстати она у вас сломана.
...через 6 месяцев
Инженеры: мы не можем сделать эту фичу она поломает метрики. В частности еж-кг/уж-м2. Бизнес: Чииво? Аналитики! Аналитики: Это не мой проект, надо месяц на погружение. Менеджеры: Ломать нельзя! Богам надо больше кода и быстрее! Инженеры: Три недели. Бизнес: х..ли все так медленно? Чем вы там вообще занимаетесь?
...через 10 лет
Аналитики: этонужнобизнесу! Менеджиент: Боги хотят больше кода! Больше кода для богов! Инженеры: (1) найдите технического хозяина, (2) напишите спецификацию по стандарту, (3) договоритесь о SLO, (4) положите TCO+20% в бюджет, (5) мы напишем микросервис/пайплайн и т.д. Бизнес: блин это долго, сложно, дорого и нудно. Оно нам вообще надо? Инженеры: не благодарите!
Яндекс контора немаленькая, в описанной ситуации "надо узнать почему..." вероятно надо было узнать не так уж сильно. Рискну предположить что прямо даже наоборот.
Ща крамолу скажу, но мне кажется Gui для scm — это зло. Постоянно сталкиваюсь с тем, что джуны не умеют работать с git, не понимают как он устроен, каким образом на основе него можно решать ежедневные насущные задачи (ревью, изоляция дефектов, управление релизами и т.д.). Я заметил, что ситуация сильно улучшается за пару недель, если настаивать на использовании консоли. Мне кажется, люди просто начинают думать о scm как о базе данных и меньше как о файловом сервере. Конечно всегда будет ниша, но… Что касается Gui, мне кажется сейчас огромная дыра с точки зрения usability в области review. У Github, Gitlab и Atlassian интерфейс заточен под маленькие ревью — 5 строчек и три файла, из-за чего приходится резать изменения на маленькие коммиты, чтобы хоть как-то протащить их через ревью. В Gerrit процесс был более годный, подразумевающий колаборацию через код. Если посмотрите в open source проекты на github, там редко идут дебаты в ревью, большей частью люди общаются в issues. Мы вот недавно переехали с Gerrit/Jenkins на Gitlab и ревью доставляют страдания. Одно время даже думали в обратную сторону мигрировать…
Очень токсичную и циничную вещь скажу. Я просто старый брюзга, не обращайте внимания.
Мне кажется основной "настоящий" бенефит микросервисной архитектуры как-то стыдливо замалчивают, а зря. Суть в том, что микросервисный код — относительно короткоживущий. Месяцы, но не годы. А значит можно не заморачиваться на многие вещи.
Т.е. раз в 9-12 месяцев каждый сервис выкинули и переписали под новый стек, требования, новые регуляции, изменившийся профиль нагрузки и т.д. Не надо сложной архитектуры, не надо переживать несколько эволюций рефакторинга, не надо оптимизировать, не надо долго и нудно тестировать. CI не свалился — выкатываем на blue-green через K8s/Helm/CloudFormation, смотрим на процент 500 в New Relic, если что-то закривело — откатываем, и по-новой. Как едко выразился мой коллега — "говнокод-ориентированная архитектура".
А теперь, внимание, жахнем теорией заговора. С точки зрения цинично-прагматичного VP of development, это дает две очень полезные вещи:
разрабатывать можно дешевыми кодерами, которые умеют в CRUD + пакетную обработку запросов. Качество кода не особо важно, ибо живет все равно недолго. Оттуда и низкая стоимость поддержки: квалификация и зарплата ниже у "поддерживающих".
дешевые кодеры и их линейный менеджмент отлично заменяются без ущерба для процесса. Потому что научить копипастить можно и за неделю. 20% attrition rate в год? Да фиолетово. Надо увеличить команду на треть и потом сократить на половину? Не вопрос. Можем еще недорогих контракторов привезти. И матричную занятость без трекинга времени. В таком раскладе можно выжимать людей до сухой кости в промышленных масштабах. Отсюда и увеличение скорости разработки.
Конечно, Netflix и Co не про это. Но, судя по нажитому опыту, шансов в среднестатистической интернет-конторе, приехать к такому порядку вещей довольно немало. Так что я бы проталкивал микросервисы с оглядкой. У нас вот завели платформенную команду, которая отвечает за стандартизацию, делает starter-проекты, есть утилиты для генерации кода, автоматизация review, и куча всего прочего. Спасет или нет — не знаю, думаю через пару лет будет ясно.
TLA+ — в общем, не вполне космический корабль. По сути — печатная машинка с греческими буквами, которая может формально доказать пилоту почему никуда лететь не надо. Если пилот очень упорный, и может убедить машинку в неизбежности путешествия, машинка складывается в чемодан с удобной ручкой, чтобы пилот мог ее унести на место назначения. Говорят кто-то в Гугле смог верхом на этом чемодане доехать из Сан-Франциско до Бобруйска, но это не точно. Сделана Лесли Лампортом из другой печатной машинки LaTex стандартного образца.
Scala — парень по имени Мартин попытался отпилить приваренные капсулы от Java, а заодно выпилить лишние ручки с панели управления и сделать клевый штурвал по форме похожий на тот, что стоит на Haskel. Малость увлекся.
Теперь панель управления построена из 4D лего. Пилот, если разберется, может перестроить ее под себя. Где-то внутри корабля живет цивилизация разумных тараканов, благодаря которым пилот может крутить штурвал от Haskel не имея докторской степени по computer science. Корабль умеет трансформироваться в вертолет с воздушными шарами, в педальный реактор, и почему-то в тыкву. Иногда делает это спонтанно.
Где-то в районе конца первой версии другой парень по имени Евгений засунул в корабль C3PO, чтобы пилот мог общаться с тараканами (это про scala macros). Тараканы возмутились вмешательством в личную жизнь, и заявили решительный протест в ООН. Под давлением общественности и при поддержке муниципалитета г. Лондона к третьей версии большую часть C3PO выпилили, оставив левое ухо и правую лодыжку.
Scala пилоты — это дальнобойщики в смокингах. У них есть штурвал похожий на руль от Haskel, поэтому они считают себя умными. За них много чего делают тараканы, когда удается договориться, поэтому они еще и считают себя очень практичными и эффективными. Scala пилотов очень любят банкиры, потому что смокинги.
Капсулы от Java, кстати, по-прежнему болтаются за кораблем во время полета, но из-за других прибамбасов их практически незаметно. Мартин всех заверил, что они отвалятся сами когда придет время.
Здорово! Страшилка по теме, исключительно для контраста и в честь праздника:
Один коллега потрудившийся на аутсорсе в одной экзотической стране, рассказал про местный метод работы стаффинга, называемый им "карусель".
Грубо говоря контора сметает с рынка всех, кто умеет в stackoverflow. Процесс иногда тормозится, но, так как специалисты дешевые, а объемы большие, последнее случается нечасто. Наем 15-20% на фоне attrition rate 5-10% от числа инженеров = 5-10% роста в год.
Далее нанятых "распределяют" по активным проектам по принципу "где есть свободный стул", даже не уведомляя заказчика. Новичок получает в "начальники" одного из середняков и, по сути, начинает делать его работу. "Начальник" в это время начинает подкалымливать на другом проекте, либо так же подменяя какого-то сеньора, либо отсвечивая в качестве консультанта или спасателя за хорошую ставку. Естественно, ходит на митинги и отвечает на почту, но всю работу "делегирует".
Далее, если новичок тянет (читай, "начальник" может на него не отвлекаться), его добавляют в команду "официально" под предлогом "для спасения чего-нибудь" (благо, спасать у них всегда что-то надо). А если не прокатывает, "начальник" срочно ложится в больницу, попадает под слона, уезжает на свадьбу и т.д. В общем, так или иначе, джуна либо продают "как есть", с увеличением команды (и инвойса! профит!), или вписывают на позицию мида с сохранением рейтов последнего (инвойс тот же, но маржа больше! профит!).
А если не тянет (читай, "начальник" вынужден продолжать делать значительную часть своей работы), бедолагу высылают на другой проект. Кто совершил круг почета по всем проектам и нигде не был продан клиенту выкидывается обратно на улицу. Потому и название "карусель".
Начиная работать с новым клиентом, на проект загоняют неплохую команду (часто, кстати, укомплектованную суб-контракторами), а потом за пол-года "вымывают" специалистов. Получается долгосрочная маржа 50%+ даже при рейте а $15-25/час.
Ваша система тоже построена по принципу естественной фильтрации, но при этом остается честной и прозрачной, что очень здорово.
Если в публичной оферте сказано, что бесплатные яблоки, по усмотрению продавца, могут быть гнилыми, надкусанными или вообще перестать раздаваться — без проблем. Яблоки тут ни кто не портит, просто отказывается раздавать.
Я думаю ваша аналогия упускает важные детали. Аналог бы звучал так:
Фермер привез яблоки на рынок и предлагает попробовать желающим бесплатно, как и принято на рынке.
Бойкий предприниматель Хитрый нанимает бомжей, надевает на них фирменные футболки "бухло от Хитрого", и говорит им ходить к лотку, брать яблоки и носить ему, чтобы он смог сделать из них наливку.
На третий день фермер идет в Хитрому, грозит обвинить его в воровстве, и требует прекратить, но Хитрый его игнорит. Тогда фермер перестает давать бесплатные яблоки бомжам в фирменных майках, и предлагает Хитрому купить яблоки или вырастить самому.
Хитрый вызывает полицию и обвиняет фермера в недобросовестной конкуренции. Хитрый заявляет, что:
фермер давал ему бесплатные яблоки три дня подряд. На основе этого Хитрый спрогнозировал, что через 6 недель сможет поставить около 100л. наливки покупателям, и взял с них деньги за бухло вперед.
а теперь фермер перестал давать яблоки, так что у Хитрого нет возможности произвести 100л. наливки. Покупая яблоки он не сможет окупить затраты на производство и обанкротится.
Полицейский рассудил, что:
термин "воровство" в данной ситуации не применим, потому что пробные яблоки бесплатные, применить ст. 158 УК РФ нельзя, и следовательно (!) запрещение со стороны фермера — не правомерно
Хитрому нельзя запрещать собирать бесплатные яблоки через бомжей, потому что у Хитрого (!) есть обязательства перед клиентами, которые он не может исполнить без халявных яблок
Исходя из этого фермер — недобросовестный предприниматель, и впредь обязан раздавать яблоки всем, независимо от того, носят ли они футболку Хитрого или нет. То же теперь относится и ко всем продавцам на рынке, предлагающим товар "на пробу".
Когда фермер возмутился, полицейский объяснил, что если бы Хитрый гипотетически мог обойтись без халявных яблок, или если бы фермер вообще перестал их раздавать, проблем бы не было. А так — фермер своими действиями (!) поставил Хитрого в безвыходную ситуацию, и, следовательно, ведет нечестную конкуренцию.
Хитрый, конечно, гнида, но больше всего здесь коробит логика полицейского. 158 УК конечно применять нельзя, фермер сам виноват что на него сослался, но вот остальное — это лютый идиотизм.
Нарушает ли LinkedIn права пользователей, препятствуя третьей стороне использовать их контент — нет, п.3.1, т.к. выдача результатов является обработкой.
Нарушает ли LinkedIn права третьей стороны, препятствуя сбору публичных данных — нет (до этого прецедента), т.к. в отсутствие соглашения между сторонами означает что отношения регулируются по действующему закону. LinkedIn в праве сам определять как обрабатывать запросы из интернета, потому что сервис является его собственностью.
Наносит ли LinkedIn ущерб HiQ мешая им собирать данные? Да. Потому что HiQ — это компания-паразит, операционно на 100% зависящая от LinkedIn, при этом не платящая им ни копейки. И их деятельность без скрейпинга вообще невозможна. Соглашений с LinkedIn у них, как я понял, нет никаких, иначе бы им давно дали отлуп за нарушение TOS.
Решение суда создало прецедент, при котором (3) достаточно, при креативной трактовке CFAA, для изменения (2) в пользу истца.
ИМХО это совершенно несправедливое решение, даже если с юридической точки зрения придраться не к чему. А в свете изложенных выше соображений — еще и опасное.
LinkedIn license agreement 3.1: вы предоставляете бессрочную не-экслюзивную лицензию на свой контент, они могут его обрабатывать и модифицировать, но не обязуются хранить или обеспечивать доступность. А в п. 3.4 говорится что они могут забанить и отказать в доступе по целому ряду пунктов.
Напомню, что суд вынес свое решение отчасти базируясь на том, что HiQ может понести убытки если им отрубят халяву. Так что это именно "мы не можем, поэтому вы должны". Рассуждений про права на контент я там не видел. А распоряжаться своим сервисом они могут как хотят, вплоть до полного закрытия.
Труд робота измеряется сложностью алгоритма его реализации и стоимостью его эксплуатации. В частности стоимостью использования API, за которые скрейперы как раз платить и не хотят (да и не могут при 500М акков). Я в PDF не вижу запрета на противодействию любым роботам.
Там фокус как раз в том, что LinkedIn дискриминацией роботов (хаха!) нанес ущерб договоренностям HiQ по отношению к третьей стороне.
LinkedIn послал cause-and-desist ноту HiQ, утверждая что те нарушают пользовательское соглашение. Те в ответ обратились в суд, утверждая что LinkedIn своими действиями подрывает их бизнес. Суд принял решение на основе того, что таки да, подрывает, при том избирательно (а Гуглу, вон, не подрывает). Это при том что HiQ Гуглу не конкурент даже.
В Oppinion читаем:
LinkedIn has taken steps to protect the data on its website from what it perceives as misuse or misappropriation. [...] The instructions in LinkedIn’s “robots.txt” file [...] prohibit access to LinkedIn servers via automated bots, except that certain entities, like the Google search engine [...]
Дальше вообще обалденно. HiQ смогли даже irrepearable damage пропихнуть на основе того, что они:
LinkedIn also urges that even if there is no adequate alternative database, hiQ could collect its own data through employee surveys. But hiQ is a data analytics company, not a data collection company.
Т.е. "вам нужны данные — вы сами и собирайте у ваших клиентов, если хотите" — "мы не можем, поэтому вы обязаны нам предоставить"
Злой умысел тут не при чем. Ключевое слово — "необоснованно". Обоснованность в суде будет определять приглашенный истецом эксперт в коннотации "а возможно ли расценить...?". Сколько лет уже эта балалайка и в патентном троллинге и в compliance phishing практикуется.
А капча как раз не является нарушением этого закона, по крайней мере я не усмотрел. Капча отфильтровывает всех роботов, а не только скрейперов.
Шикарно. Теперь у поисковика есть полный резон "договориться" с владельцем сайта (MSFT, LinkedIn) за хорошее вознаграждение и проводить индексацию по не-публичному каналу. А потом показывать результаты только авторизованным у этого сайта пользователям. В обоюдных интересах, разумеется. Да еще и рекламку всунуть (еще 100500 очень релевантных результатов, только зарегистрируйся там-то).
Поди и наезды будут теперь в духе "вы поменяли структуру страницы, сделав ее необоснованно трудной для разбора и это сломало наш скрейпер; вы нарушили закон и причинили нам ущерб, не хотите ли договориться в досудебном порядке, господа?".
Когда уже будет обязательный IQ тест для законодателей? Идиоты.
Надо всех зайцев вслух пронумеровать и сообщить, что кто бы не прыгал, будут ловить минимального по номеру.
См. шутку про designated drunk и вообще про козлов отпущения.
Положим, зайцы собрались, выбрали "жертву". Жертва сигает через турникет, ее ловят, штрафуют, с гарантией, оставшиеся выплачивают бедолаге мзду за "ходку" превышающую штраф. Если штраф в 10 раз больше стоимости билета, минимальный размер группы, для который выбор жертвенного зайца имеет смысл — 11.
Т.е. равновесий по-прежнему два, просто одно из них начинает "работать" с определенных n? Получается, фишка в том, чтобы n было достаточно большим (напр. порядка количества мест в поезде)? Или есть вариант решения, похожий на задачу про инспекторов? Если так, то как он конкретно будет выглядеть для задачи про зайцев?
Каким образом задачки делают ваше интервью объективным?
Оч правильный вопрос. Ответ выше — задача является упрощенным вариантом того, что команда делала раньше. Пример — есть обработчик асинхронных запросов, многопоточный (в реальности был брокер сливающий данные из нескольких стримов Kinesis, в виде эдакого лямбда-кластера). Даем кусок кода брокера, просим добавить LRU кэш обработчиков, чтобы они не создавались на каждый чих. Примеры ошибок:
прекрасно написаный LRU кэш… запросов.
статической хэш-таблица, про LRU и многопоточность — ни слова
все завернуто в глобальные локи, обработчик стал практически однопоточным
старый код полностью заменен новым, включая части которые менять было не нужно (ирония: новый код перестал гарантировать обработку сообщений).
вместо кэша реализован синхронный пул обработчиков, хотя в контракте сказано что они реентерабельны.
отказ делать задание, предложение заменить Kinesis на другую технологию
Как думаете, что можно сказать о кандидате в каждом случае?
А какие задачки с уточками для менеджеров можно придумать, я наверное лучше сдержусь :)
Я годный (надеюсь) пример привел выше — приоритизация бэклога и планирование спринтов. Если придумаете что-то типа этого с уточками, буду признателен.
Обоснуйте? Кандидата просят рассказать ваше решение относительно простой задачи, про которую он заранее спокойно обдумал в течении часа. Чем это не типовая ситуация, кроме аргументов про "я с ними не бухал и потому боюсь".
1 обычно маловато все же для принятия решения, отсюда два. Непосредственный начальник и либо его коллега из другого отдела (того же уровня), либо ПО продукта.
Зашибись. А инженеров мы спрашивать не будем. Действительно, нафига. Большая насяльника решила, холопам радоваться. Не допускаете ли вы мысль, что инженеры по части оценки скиллов коллег несколько компетентнее эйчара, соседского начальника и ПО вместе взятых?
Возможно "Любители решать задачки" это одно из таких очень важных качеств, которые вы ищите.
Не задачки, а поставленные задачи. Повторюсь: задача на дом — это упрощенный вариант того, что когда-то делала команда. Например добавить LRU кэш куда-нибудь. Проверяется умение работать с кодом, читать тикет, оформлять коммиты, спрашивать уточнения, гуглить или спрашивать непонятное. Базовые вещи для инженера. Таки да, если сеньор не может вышеперечисленное — простите, нет.
У меня как-то было за две недели 24 собеседования… сколько времени у меня остается на сон и основную работу?
Ни фига себе! Снимаю шляпу. Я последний раз сходил на три. Правда до этого пару десятков завернул по телефону… Возможно ответ кроется в том, что ковровое бомбометание резюме не самый эффективный метод поиска работы для сеньора? Есть же LinkedIn, Glassdoor, бывшие коллеги...
5 человек — средний размер команды. Если кандидату не комфортно в переговорке с 4 людьми, наверное ему будет некомфортно и на стендапе с этими же 4 людьми. Кроме того дизайн — это субъективное упражнение. Отсюда и число 4:
Если 1 интервьювер — нет гарантии непредвзятости (залип юноша на симпатичную девушку или наоборот).
Если 2 — возможна ситуация, когда один за, а другой против, и не понятно прошел кандидат или нет.
Если 3 — уже лучше, но там перевес всего в один голос, т.е. ошибка первого рода (пропустили дурня) и второго рода (зарубили гения) равновероятны (должны ошибиться 2 человека сразу).
Для 4, чтобы получить ошибку первого рода надо чтобы ошиблись 3 человека сразу, а для второго рода достаточно по-прежнему ошибиться 2. С учетом того, что практическое упражнение стоит усилий с обеих сторон — такой подход оправдан.
У меня довольно много знакомых, которые вообще задачи не желают делать, причем корреляция такая, что чем выше скилл, тем меньше человек любит решать задачки.
Угу, бывают и такие. Благодарим, жмем руки, не связываемся. Для нас объективность — это один из главных критериев. В компании принято считать, что собеседование a-priori субъективно, следовательно, мы не можем гарантировать непредвзятость без формального этапа. С учетом того, что найм — это игра с нулевой суммой, поступать так было бы несправедливо по отношению к другим кандидатам.
Кстати, задачки дают даже менеджерам. На позицию продакт менеджера, например, дадут приоритизировать бэклог и разбить на спринты, а потом объяснить почему так. Без задачек могут нанять на роли, где решает либо история работы и мнение профессионального сообщества (executives), или сертификация (бухгалтерия).
Задачка "домой" дается только тем, кто смогли нарисовать адекватный дизайн на доске и связно объяснить. Это как раз ваша бумажная задача. У нас это порядка 30% от отфильтрованных по телефону и пришедших на интервью. За год это где-то с десяток-полтора у нас в отдел, из которых наймут 3-5.
Дизайн "слушают" 4 человека. Чтобы дать задачу, за кандидата должны проголосовать как минимум трое, один из которых будет проверяющим (ревьювером).
Ревьювер будет проверять, согласовывать упрощения, отвечать на вопросы и т.д. Ревью провести не 2 минуты, а как минимум час. Потому что проходит оно по всем внутренним правилам. Надо все собрать, прогнать тесты, прочитать код, контракты к нему, проверить исполнение контрактов, инварианты и т.д. Так что мы времени на проверку тратим приблизительно 30%-50% от того, что потратил кандидат.
Так что я думаю это просто еще один этап после бумажной фазы, призванный отфильтровать людей которые не могут аккуратно код писать, или с которыми никто не хочет работать.
Аналитики: этонужнобизнесу!
Менеджиент: Боги хотят больше кода! Больше кода для богов!
Инженеры: Нифиганепонял, вот вам копипаста из соседнего проекта.
Реальность: Вы родили очередную метрику формата "килограмм ежа на квадратный метод ужа" на которую всем будет плевать через три недели включая авторов. Кстати она у вас сломана.
...через 6 месяцев
Инженеры: мы не можем сделать эту фичу она поломает метрики. В частности еж-кг/уж-м2.
Бизнес: Чииво? Аналитики!
Аналитики: Это не мой проект, надо месяц на погружение.
Менеджеры: Ломать нельзя! Богам надо больше кода и быстрее!
Инженеры: Три недели.
Бизнес: х..ли все так медленно? Чем вы там вообще занимаетесь?
...через 10 лет
Аналитики: этонужнобизнесу!
Менеджиент: Боги хотят больше кода! Больше кода для богов!
Инженеры: (1) найдите технического хозяина, (2) напишите спецификацию по стандарту, (3) договоритесь о SLO, (4) положите TCO+20% в бюджет, (5) мы напишем микросервис/пайплайн и т.д.
Бизнес: блин это долго, сложно, дорого и нудно. Оно нам вообще надо?
Инженеры: не благодарите!
Яндекс контора немаленькая, в описанной ситуации "надо узнать почему..." вероятно надо было узнать не так уж сильно. Рискну предположить что прямо даже наоборот.
Ща крамолу скажу, но мне кажется Gui для scm — это зло. Постоянно сталкиваюсь с тем, что джуны не умеют работать с git, не понимают как он устроен, каким образом на основе него можно решать ежедневные насущные задачи (ревью, изоляция дефектов, управление релизами и т.д.). Я заметил, что ситуация сильно улучшается за пару недель, если настаивать на использовании консоли. Мне кажется, люди просто начинают думать о scm как о базе данных и меньше как о файловом сервере. Конечно всегда будет ниша, но… Что касается Gui, мне кажется сейчас огромная дыра с точки зрения usability в области review. У Github, Gitlab и Atlassian интерфейс заточен под маленькие ревью — 5 строчек и три файла, из-за чего приходится резать изменения на маленькие коммиты, чтобы хоть как-то протащить их через ревью. В Gerrit процесс был более годный, подразумевающий колаборацию через код. Если посмотрите в open source проекты на github, там редко идут дебаты в ревью, большей частью люди общаются в issues. Мы вот недавно переехали с Gerrit/Jenkins на Gitlab и ревью доставляют страдания. Одно время даже думали в обратную сторону мигрировать…
Очень токсичную и циничную вещь скажу. Я просто старый брюзга, не обращайте внимания.
Мне кажется основной "настоящий" бенефит микросервисной архитектуры как-то стыдливо замалчивают, а зря. Суть в том, что микросервисный код — относительно короткоживущий. Месяцы, но не годы. А значит можно не заморачиваться на многие вещи.
Т.е. раз в 9-12 месяцев каждый сервис выкинули и переписали под новый стек, требования, новые регуляции, изменившийся профиль нагрузки и т.д. Не надо сложной архитектуры, не надо переживать несколько эволюций рефакторинга, не надо оптимизировать, не надо долго и нудно тестировать. CI не свалился — выкатываем на blue-green через K8s/Helm/CloudFormation, смотрим на процент 500 в New Relic, если что-то закривело — откатываем, и по-новой. Как едко выразился мой коллега — "говнокод-ориентированная архитектура".
А теперь, внимание, жахнем теорией заговора. С точки зрения цинично-прагматичного VP of development, это дает две очень полезные вещи:
Конечно, Netflix и Co не про это. Но, судя по нажитому опыту, шансов в среднестатистической интернет-конторе, приехать к такому порядку вещей довольно немало. Так что я бы проталкивал микросервисы с оглядкой. У нас вот завели платформенную команду, которая отвечает за стандартизацию, делает starter-проекты, есть утилиты для генерации кода, автоматизация review, и куча всего прочего. Спасет или нет — не знаю, думаю через пару лет будет ясно.
Ну и до кучи:
TLA+ — в общем, не вполне космический корабль. По сути — печатная машинка с греческими буквами, которая может формально доказать пилоту почему никуда лететь не надо. Если пилот очень упорный, и может убедить машинку в неизбежности путешествия, машинка складывается в чемодан с удобной ручкой, чтобы пилот мог ее унести на место назначения. Говорят кто-то в Гугле смог верхом на этом чемодане доехать из Сан-Франциско до Бобруйска, но это не точно. Сделана Лесли Лампортом из другой печатной машинки LaTex стандартного образца.
Scala — парень по имени Мартин попытался отпилить приваренные капсулы от Java, а заодно выпилить лишние ручки с панели управления и сделать клевый штурвал по форме похожий на тот, что стоит на Haskel. Малость увлекся.
Теперь панель управления построена из 4D лего. Пилот, если разберется, может перестроить ее под себя. Где-то внутри корабля живет цивилизация разумных тараканов, благодаря которым пилот может крутить штурвал от Haskel не имея докторской степени по computer science. Корабль умеет трансформироваться в вертолет с воздушными шарами, в педальный реактор, и почему-то в тыкву. Иногда делает это спонтанно.
Где-то в районе конца первой версии другой парень по имени Евгений засунул в корабль C3PO, чтобы пилот мог общаться с тараканами (это про scala macros). Тараканы возмутились вмешательством в личную жизнь, и заявили решительный протест в ООН. Под давлением общественности и при поддержке муниципалитета г. Лондона к третьей версии большую часть C3PO выпилили, оставив левое ухо и правую лодыжку.
Scala пилоты — это дальнобойщики в смокингах. У них есть штурвал похожий на руль от Haskel, поэтому они считают себя умными. За них много чего делают тараканы, когда удается договориться, поэтому они еще и считают себя очень практичными и эффективными. Scala пилотов очень любят банкиры, потому что смокинги.
Капсулы от Java, кстати, по-прежнему болтаются за кораблем во время полета, но из-за других прибамбасов их практически незаметно. Мартин всех заверил, что они отвалятся сами когда придет время.
Здорово! Страшилка по теме, исключительно для контраста и в честь праздника:
Ваша система тоже построена по принципу естественной фильтрации, но при этом остается честной и прозрачной, что очень здорово.
Если в публичной оферте сказано, что бесплатные яблоки, по усмотрению продавца, могут быть гнилыми, надкусанными или вообще перестать раздаваться — без проблем. Яблоки тут ни кто не портит, просто отказывается раздавать.
Я думаю ваша аналогия упускает важные детали. Аналог бы звучал так:
Фермер привез яблоки на рынок и предлагает попробовать желающим бесплатно, как и принято на рынке.
Бойкий предприниматель Хитрый нанимает бомжей, надевает на них фирменные футболки "бухло от Хитрого", и говорит им ходить к лотку, брать яблоки и носить ему, чтобы он смог сделать из них наливку.
На третий день фермер идет в Хитрому, грозит обвинить его в воровстве, и требует прекратить, но Хитрый его игнорит. Тогда фермер перестает давать бесплатные яблоки бомжам в фирменных майках, и предлагает Хитрому купить яблоки или вырастить самому.
Хитрый вызывает полицию и обвиняет фермера в недобросовестной конкуренции. Хитрый заявляет, что:
Полицейский рассудил, что:
Исходя из этого фермер — недобросовестный предприниматель, и впредь обязан раздавать яблоки всем, независимо от того, носят ли они футболку Хитрого или нет. То же теперь относится и ко всем продавцам на рынке, предлагающим товар "на пробу".
Когда фермер возмутился, полицейский объяснил, что если бы Хитрый гипотетически мог обойтись без халявных яблок, или если бы фермер вообще перестал их раздавать, проблем бы не было. А так — фермер своими действиями (!) поставил Хитрого в безвыходную ситуацию, и, следовательно, ведет нечестную конкуренцию.
Хитрый, конечно, гнида, но больше всего здесь коробит логика полицейского. 158 УК конечно применять нельзя, фермер сам виноват что на него сослался, но вот остальное — это лютый идиотизм.
Итого имеем:
Решение суда создало прецедент, при котором (3) достаточно, при креативной трактовке CFAA, для изменения (2) в пользу истца.
ИМХО это совершенно несправедливое решение, даже если с юридической точки зрения придраться не к чему. А в свете изложенных выше соображений — еще и опасное.
LinkedIn license agreement 3.1: вы предоставляете бессрочную не-экслюзивную лицензию на свой контент, они могут его обрабатывать и модифицировать, но не обязуются хранить или обеспечивать доступность. А в п. 3.4 говорится что они могут забанить и отказать в доступе по целому ряду пунктов.
Напомню, что суд вынес свое решение отчасти базируясь на том, что HiQ может понести убытки если им отрубят халяву. Так что это именно "мы не можем, поэтому вы должны". Рассуждений про права на контент я там не видел. А распоряжаться своим сервисом они могут как хотят, вплоть до полного закрытия.
Труд робота измеряется сложностью алгоритма его реализации и стоимостью его эксплуатации. В частности стоимостью использования API, за которые скрейперы как раз платить и не хотят (да и не могут при 500М акков). Я в PDF не вижу запрета на противодействию любым роботам.
Там фокус как раз в том, что LinkedIn дискриминацией роботов (хаха!) нанес ущерб договоренностям HiQ по отношению к третьей стороне.
LinkedIn послал cause-and-desist ноту HiQ, утверждая что те нарушают пользовательское соглашение. Те в ответ обратились в суд, утверждая что LinkedIn своими действиями подрывает их бизнес. Суд принял решение на основе того, что таки да, подрывает, при том избирательно (а Гуглу, вон, не подрывает). Это при том что HiQ Гуглу не конкурент даже.
В Oppinion читаем:
Дальше вообще обалденно. HiQ смогли даже irrepearable damage пропихнуть на основе того, что они:
Т.е. "вам нужны данные — вы сами и собирайте у ваших клиентов, если хотите" — "мы не можем, поэтому вы обязаны нам предоставить"
Злой умысел тут не при чем. Ключевое слово — "необоснованно". Обоснованность в суде будет определять приглашенный истецом эксперт в коннотации "а возможно ли расценить...?". Сколько лет уже эта балалайка и в патентном троллинге и в compliance phishing практикуется.
А капча как раз не является нарушением этого закона, по крайней мере я не усмотрел. Капча отфильтровывает всех роботов, а не только скрейперов.
Ну jobs.google.com, например, пока не засудили, а он именно этим и занимается (https://cloud.google.com/talent-solution/job-search/docs/apis). Я думаю раньше этого не делали, т.к. коммерческого смысла не было. А теперь — есть.
Шикарно. Теперь у поисковика есть полный резон "договориться" с владельцем сайта (MSFT, LinkedIn) за хорошее вознаграждение и проводить индексацию по не-публичному каналу. А потом показывать результаты только авторизованным у этого сайта пользователям. В обоюдных интересах, разумеется. Да еще и рекламку всунуть (еще 100500 очень релевантных результатов, только зарегистрируйся там-то).
Поди и наезды будут теперь в духе "вы поменяли структуру страницы, сделав ее необоснованно трудной для разбора и это сломало наш скрейпер; вы нарушили закон и причинили нам ущерб, не хотите ли договориться в досудебном порядке, господа?".
Когда уже будет обязательный IQ тест для законодателей? Идиоты.
Вот для этого есть DbC (https://en.wikipedia.org/wiki/Design_by_contract). Там правда засада в том, что если уж вы все контракты верифицировали, то тестировать API скорее всего смысла нет.
См. шутку про designated drunk и вообще про козлов отпущения.
Положим, зайцы собрались, выбрали "жертву". Жертва сигает через турникет, ее ловят, штрафуют, с гарантией, оставшиеся выплачивают бедолаге мзду за "ходку" превышающую штраф. Если штраф в 10 раз больше стоимости билета, минимальный размер группы, для который выбор жертвенного зайца имеет смысл — 11.
Т.е. равновесий по-прежнему два, просто одно из них начинает "работать" с определенных n? Получается, фишка в том, чтобы n было достаточно большим (напр. порядка количества мест в поезде)? Или есть вариант решения, похожий на задачу про инспекторов? Если так, то как он конкретно будет выглядеть для задачи про зайцев?
Оч правильный вопрос. Ответ выше — задача является упрощенным вариантом того, что команда делала раньше. Пример — есть обработчик асинхронных запросов, многопоточный (в реальности был брокер сливающий данные из нескольких стримов Kinesis, в виде эдакого лямбда-кластера). Даем кусок кода брокера, просим добавить LRU кэш обработчиков, чтобы они не создавались на каждый чих. Примеры ошибок:
Как думаете, что можно сказать о кандидате в каждом случае?
Я годный (надеюсь) пример привел выше — приоритизация бэклога и планирование спринтов. Если придумаете что-то типа этого с уточками, буду признателен.
Обоснуйте? Кандидата просят рассказать ваше решение относительно простой задачи, про которую он заранее спокойно обдумал в течении часа. Чем это не типовая ситуация, кроме аргументов про "я с ними не бухал и потому боюсь".
Зашибись. А инженеров мы спрашивать не будем. Действительно, нафига. Большая насяльника решила, холопам радоваться. Не допускаете ли вы мысль, что инженеры по части оценки скиллов коллег несколько компетентнее эйчара, соседского начальника и ПО вместе взятых?
Не задачки, а поставленные задачи. Повторюсь: задача на дом — это упрощенный вариант того, что когда-то делала команда. Например добавить LRU кэш куда-нибудь. Проверяется умение работать с кодом, читать тикет, оформлять коммиты, спрашивать уточнения, гуглить или спрашивать непонятное. Базовые вещи для инженера. Таки да, если сеньор не может вышеперечисленное — простите, нет.
Ни фига себе! Снимаю шляпу. Я последний раз сходил на три. Правда до этого пару десятков завернул по телефону… Возможно ответ кроется в том, что ковровое бомбометание резюме не самый эффективный метод поиска работы для сеньора? Есть же LinkedIn, Glassdoor, бывшие коллеги...
Я все-таки надеюсь что мы не абсолютно левые. Мы будущие доброжелательные коллеги ;-)
5 человек — средний размер команды. Если кандидату не комфортно в переговорке с 4 людьми, наверное ему будет некомфортно и на стендапе с этими же 4 людьми. Кроме того дизайн — это субъективное упражнение. Отсюда и число 4:
Угу, бывают и такие. Благодарим, жмем руки, не связываемся. Для нас объективность — это один из главных критериев. В компании принято считать, что собеседование a-priori субъективно, следовательно, мы не можем гарантировать непредвзятость без формального этапа. С учетом того, что найм — это игра с нулевой суммой, поступать так было бы несправедливо по отношению к другим кандидатам.
Кстати, задачки дают даже менеджерам. На позицию продакт менеджера, например, дадут приоритизировать бэклог и разбить на спринты, а потом объяснить почему так. Без задачек могут нанять на роли, где решает либо история работы и мнение профессионального сообщества (executives), или сертификация (бухгалтерия).
Задачка "домой" дается только тем, кто смогли нарисовать адекватный дизайн на доске и связно объяснить. Это как раз ваша бумажная задача. У нас это порядка 30% от отфильтрованных по телефону и пришедших на интервью. За год это где-то с десяток-полтора у нас в отдел, из которых наймут 3-5.
Дизайн "слушают" 4 человека. Чтобы дать задачу, за кандидата должны проголосовать как минимум трое, один из которых будет проверяющим (ревьювером).
Ревьювер будет проверять, согласовывать упрощения, отвечать на вопросы и т.д. Ревью провести не 2 минуты, а как минимум час. Потому что проходит оно по всем внутренним правилам. Надо все собрать, прогнать тесты, прочитать код, контракты к нему, проверить исполнение контрактов, инварианты и т.д. Так что мы времени на проверку тратим приблизительно 30%-50% от того, что потратил кандидат.
Так что я думаю это просто еще один этап после бумажной фазы, призванный отфильтровать людей которые не могут аккуратно код писать, или с которыми никто не хочет работать.