Потому что все заказчики спят и видят что если год назад у них был 1 пользователь, а сейчас 100, то через год будет 10к, а через два 1М. И требуют масштабируемое решение.
Есть один проект с миллиардом просмотров в месяц. Похоже его создатели всё это время были в анабиозе и не слышали про микросервисы. А если бы добавили хотя бы десяток-другой микросервисов, сагу и это всё, то наверное вообще всё летало бы.
Я думаю смысл в том, чтобы быстро синхронизироваться, решить какие-то простые проблемы, быть в курсе чем занимаются другие. В чате это может быть дольше. Если митинг затягивается на полчаса, то вряд ли большинству людей интересно на столько глубоко погружаться в чужие задачи. Вопросы, которые интересны всем бывают далеко не каждый день.
Это 10 секунд на человека, 2 минуты всего. А за 15 минут вполне можно решить большую часть проблем.
А если у коллег вопрос возник?
Обычно вопрос к 1-2 людям, они вполне могут собраться отдельно обсудить.
Даже 15 минут на 12 человек - это 180 минут = 3 человеко-часа. Если полчаса посидеть, то это уже 6 часов - почти рабочий день. Я думаю, что частые долгие митинги на большое количество человек - зло. Чем больше людей, тем быстрее должен быть митинг или тем реже.
Мне сложно придумать такой пример. Если это только что-то связанное с гостайной, какими-то ноу-хау или чем-то не очень законным. Я ни разу не встречал таких людей. В любом случае я думаю, что нет никакого секрета в том как на проекте был организован процесс разработки, были ли аналитики, тестировщики, как велась работа с ветками в Git, как декомпозировались задачи, на сколько сложным было приложение (сколько сущностей в схеме данных, сервисов, модулей и т.д.), как была реализована аутентификация, авторизация и куча других технически вопросов, на которые вполне можно ответить, не раскрывая секретов. Или просто отказаться отвечать, это вообще не проблема.
Лично я думаю, что лайвкодинг используется в следующих ситуациях:
Если в компании очень большой поток кандидатов и нужно максимально просто и эффективно их отсеивать. Если отсеяли хорошего кандидата, ну, ничего страшного, завтра будет ещё десяток.
Если у самого интервьюера небольшой опыт или вообще нет опыта и он не может оценить кандидата, просто беседуя с ним.
Если собеседование на джуниорскую позицию без опыта.
Если нет времени, сил, желания запариваться с интервью, то гораздо проще дать очередному кандидату очередную задачку, чем думать, напрягаться, задавать какие-то вопросы.
Если хочется сделать интервью максимально объективным. Решил задачу за полчаса - ставим плюсик. Успел оптимизировать алгоритм - ставим два плюсика. Не сделал задачу - ставим минусик. В итоге суммируем оценки и превращаем кандидата в число. Сортируем этот массив, получаем N лучших кандидатов, делаем им оффер. Хотя у меня есть смутное ощущение, что при этом упускается что-то важное. У каждого кандидата свой уникальный опыт, свои уникальные качества, которые в итоговую сумму не попали, потому что мы даже не спрашивали соискателя о его проектах, интересах.
Вообще я наверное не против лайвкодинга и сам время от времени решаю какие-то задачки, что-то изучаю. И алгоритмическая секция наверное не сильно оскорбила бы мои чувства :) Но на текущем проекте я вообще не вижу никакого смысла давать людям алгоритмические задачи, для меня важнее на сколько человек может работать самостоятельно, декомпозировать сложные задачи, соотносить важность фичи и сложность её реализации, писать понятный код, который потом не нужно переписывать, что-то обсуждать, если задачу непонятно как делать или есть много вариантов решения.
И не нужно спрашивать как он будет варить шов. Можно спросить как он варил швы раньше, как готовил поверхность, какие электроды использовал, какое оборудование, что если был нужен широкий или длинный шов (он варил их в один проход или в несколько), просто вел электродом по прямой или зигзагом, какая была техника безопасности, варил ли он швы в каких-то сложных условиях (на трубе под большим давлением, на большой высоте, в замкнутом помещении, в угольной шахте, ... - если такое требуется на объекте), как проверял качество шва, бывало ли такое что он сварил шов, а потом всё развалилось нафиг. Причём на эти вопросы нет правильного и неправильного ответа. Они просто показывают на сколько человек погружен в эту тему или хочет в неё погружаться.
Практические задачи - это наверное тоже хорошо. Но, блин, всё-таки между ИТ и сваркой есть разница. Сварщик на работе будет реально варить швы и если он не смог сварить тестовый шов, наверное не сможет сварить и реальный - возможно они не сильно отличаются.
А в ИТ тестовые и реальные задачи обычно не имеют вообще ничего общего. Алгоритмические задачи просто проверяют как человек готовился к интервью. Если не готовился, то он его не пройдет, каким бы гением разработки он ни был. А если готовился, то скорее всего пройдёт независимо от того на сколько отстойный он разработчик. И вопрос нафига такое интервью вообще, что оно проверяет? Знание алгоритмов - это безусловно бонус, возможно более полезный чем знание английского на уровне upper-intermediate, умение вышивать крестиком, водительские права категории Б и т.д. И я считаю, что разработчикам очень полезно прокачиваться в алгоритмах. Но это никак не основной скилл разработчика.
Это видно уже после первых ответов на конкретные вопросы. Всегда можно провалиться в детали. Сначала спросить чем человек в принципе занимался, что это был за проект, кто им пользовался. Спросить чем конкретно занимался именно он - только бэком или иногда и фронтом. Занимался ли базой данных. Какие сущности были в схеме данных. Какие были сервисы, модули, классы. Можно задать много вопросов по процессу разработки, сколько человек было на проекте, как он с ними взаимодействовал. Бывало ли что в постановке задачи ошибка или постановка в принципе нереализуемая. Бывало ли что задача оказывалась сложнее, чем её изначально оценили. В зависимости от ответов можно проваливаться всё глубже и глубже. Или наоборот задавать вопросы всё шире и шире, чтобы понять на сколько целостное представление у него о процессе разработки вообще.
С одной стороны, такое интервью очень мягкое, потому что это просто беседа, к которой не нужно специально готовиться. Человек сам волен направить её в любую сторону, говорить о том, что ему ближе и интереснее. С другой стороны, это капец какое сложное интервью, потому что к нему невозможно подготовиться на курсах или решив сотню задач на литкоде. Представьте, что соискатель - это тот же Лев Толстой или человек с очень развитыми коммуникативными навыками, наверное самый мемный пример - это Mike Ross из Suits
или бабушка вашего соседа по этажу - кто угодно, и они полгода прокачивались в прохождении интервью на разработчика. Неужели вы не отличите человека, который реально что-то разрабатывал от человека, который просто красиво об этом рассказывает? Да, встречаются люди, которые на интервью не умолкают и очень складно говорят, но, блин, реальный опыт человека или если нет опыта, то его способности, мотивация видны, я не представляю как это можно скрыть. Конечно есть в некотором роде талантливые люди типа Элизабет Холмс, но она менеджер, и в разработке такое сложно представить. В конце концов, на испытательном сроке будет видно работает человек или нет.
На мой взгляд такое интервью проверяет реальный опыт человека. Или если опыта нет/мало, то позволяет понять чем он в принципе интересуется, как впишется в проект. В отличие от алгоритмических секций, которые проверяют одну единственную вещь - решал человек аналогичные задачки или нет. Если решал - это клёво, и наверное он не будет реализовывать алгоритмы с кубической сложностью там где достаточно линейной, возможно ему будет легче дебажить сложный код и т.д. Но сможет ли он писать понятный код - уже хз, хотя с этим проблемы бывают гораздо чаще чем с алгоритмами. Сможет ли в целом поддерживать качество кодовой базы, а не умножать хаос. Сможет ли он самостоятельно декомпозировать сложные задачи. Сможет ли нормально работать с аналитиками, другими разработчиками, тестировщиками. Меня лично это интересует в профессиональных навыках человека куда больше чем умение решать алгоритмические задачки.
Кто-то предупреждает, что задача выглядит такой простой что «давайте я напишу, а вы потом скажете, правильно ли я понял». Плюс: что предупредил о намерении. Минус: что не смог сформулировать план реализации – в реальной жизни тоже пойдет писать как можно быстрее.
На мой взгляд, если сделать ещё одну итерацию в развитии вашего подхода, то можно и не давать человеку искусственные задачи, даже простые, и не гадать: "Ага! Он не уточнил постановку задачи, пошел сразу удалять все тройки, не уточнил сроки реализации и важность каждого из требований. А что если мне нужно удалять только каждую четную по счету тройку, а нечетные оставлять? Что если удаление троек - это основная фича и её точно нужно реализовать, а вывод в консоль - второстепенная фича и её можно сделать во вторую очередь? Ну, всё, раз не задал эти вопросы даже на такой простой задаче, то что от него можно ждать на более сложных?"
Я немного утрирую, но если вас интересует как человек выстраивает коммуникацию, работает с требованиями, умеет ли декомпозировать, приоритезировать, планировать задачи, то можно тупо спросить его об этом! Как он всё это делал на прошлых проектах. Для этого даже не нужны никакие задачи, не нужно проводить какой-то сложный анализ поведения соискателя, анализировать его мотивы. Если человека спросить какими интересными проектами он занимался, какие задачи и каким образом решал, то (сюрприз!!!) он в большинстве случаев об этом сам расскажет.
Полностью поддерживаю, у меня такой же рецепт. Я ем что угодно и в любых количествах кроме мучного и сладкого. Когда я отказывался от хлеба, конфет и т.д., то чуть ли не по килограмму в день терял, а когда начинал есть, то столько же набирал. Причём это на столько простой и действенный способ, что на мой взгляд любой может попробовать следовать ему хотя бы одну неделю. Я просто не верю в то, что не будет ощутимого результата. Поначалу мне было сложно перестроиться, потому что я с детства привык есть хлеб, везде его предлагают. И даже сейчас условно раз в месяц я могу съесть что-то мучное. Но в целом в какой-то момент я просто перестал воспринимать это как еду.
Если вы тоже попробуете следовать этому рецепту, то не нужно относиться к этому как полному отказу от чего-то на всю оставшуюся жизнь и т.д. Или если вы не удержитесь и съедите какую-нибудь пиццу, то в этом нет вообще никакой проблемы. Воспринимайте это просто как эксперимент по проверке того оказывает такая еда какой-то эффект на ваше состояние или нет.
Every resource has a unique identifier that can represent a single resource or a set of resources. For instance, you can manage a Banking Account Resource that represents and defines a set of authorization policies for all banking accounts. But you can also have a different resource named Alice’s Banking Account, which represents a single resource owned by a single customer, which can have its own set of authorization policies.
Т.е. под ресурсом они имеют в виду и коллекцию (тип) ресурсов, и конкретные ресурсы.
Но сложно представить банковскую систему с миллионом пользователей, у каждого из которых есть свои банковские счета. И чтобы собственные правила доступа к каждому из этих миллионов счетов хранились в Keycloak.
Видимо это меня и сбивает, потому что обычно под ресурсом подразумевается конкретный объект. Например, в REST это может быть ресурсами:
https://example.com/api/articles/1
https://example.com/api/articles/2
https://example.com/api/articles/3
...
А статьи, новости и т.д. - это типы ресурсов, а не конкретные ресурсы. Или допустим в документации упоминается "fine-grained authorization", "fine-grained permissions" - у меня сразу возникают ассоциации с ограничением доступа на уровне отдельных объектов или даже отдельных атрибутов, с чем-нибудь типа Row-Level Security, но реально имеется в виду что-то более простое.
Спасибо, теперь кажется понял. По сути resource и scope - это возможно чуть более правильный вариант по сравнению с ролями. Но пообъектную проверку доступа через него всё равно не сделать.
Или пообъектной проверки и нет в Keycloak вообще? Интересно что имеется в виду под ресурсом в документации на сервер авторизации. Это типы ресурсов, например, "обычная статья", "платная статья" и т.д.? Или речь о конкретных ресурсах: "статья с идентификатором 123 про Keycloak", "статья с ид 234 про OIDC" и т.д.? Или ресурсом может быть что угодно: и тип ресурсов, и конкретный ресурс?
То, что в Keycloak можно описать правила доступа к типам ресурсов это понятно. Либо через роли, либо через скоупы. Но если нужно разделение доступа на уровне отдельных объектов, то по-моему Keycloak уже не очень подходит.
Не очень понимаю... Если нужно ограничить доступ по типам ресурсов, то можно использовать роли из Keycloak. Например, одна роль позволяет просматривать новости, другая - статьи.
Немного более сложный вариант. Допустим статьи могут быть двух типов: обычные для всех и премиальные для подписчиков. Это тоже можно решить через роли "обычный пользователь", "подписчик", "супер-подписчик" и т.д.
А если ещё более сложный вариант типа Google Документов? Пользователи могут создавать документы, выдавать к ним доступ другим пользователям. Причём, этих документов в системе миллионы. В Keycloak должна храниться информация о каждом таком документе? Затем в него отправляется запрос с id документа и id пользователя и Keycloak отвечает есть ли у пользователя доступ к этому документу?
Всё равно останется проблема, что записи в одном сервисе (само приложение), а разрешения для них - в другом (Keycloak). И нужно получать данные из двух источников, как-то мержить их. Здесь в принципе не сделать простую и быструю реализацию. Гораздо проще хранить и записи, и разрешения в одной базе и получать всё одним SQL-запросом.
"Критикуешь - предлагай" - это чудесный способ замалчивать проблемы.
Так и есть, это отличный способ задушить инициативу :) "Нужно что-то сделать, ну, сделай, в чём проблема, от меня-то ты что хочешь?" - немного более развернутый вариант этой фразы, который я иногда слышал.
Или это способ проверить а так ли человеку важно то о чем он говорит. Бывает, что люди критикуют просто ради критики и когда с ними соглашаешься, хорошо, давай сделаем, вот, первый шаг, вот второй, я тебе помогу с этим и этим и т.д., то запал почему-то сразу пропадает.
Или это способ пробудить в человеке инициативность, чтобы он не ждал одобрения и помощи от других, а сам приложил усилия.
Словом, такая простая фраза и столько вариантов интерпретации...
На мой взгляд, и с теми, и с теми сложно делать сложную работу. Когда человек видит только негативное и постоянно об этом говорит, то это демотивирует. Пусть не сразу, но через месяц, через год ты либо выгоришь, либо начнёшь превращаться в душилу.
С другой стороны, если ты постоянно видишь проблемы, пытаешься что-то улучшить, но годами ничего не меняется, то тоже ничего хорошего не будет.
Я думаю, что все эти конфликты связаны с тем, что люди чего-то ждут от других людей. Что для других так же важно качество кода, скорость сборки, простота деплоя, удобство процессов разработки, правильная архитектура, хороший проект, довольные заказчики, спасение мира, гармония во вселенной и т.д. А вполне возможно, что для них более важны совершенно другие вещи. Если тебя что-то не устраивает, то сделай лучше. Зачем капать на мозг другим людям? У них наверное своих проблем, задач, целей, интересов хватает?
Опять-таки и с другой стороны, если люди хотят что-то улучшить и если ты считаешь, что как минимум от этого не станет сильно хуже, то почему бы и нет?
В общем, я думаю, что нужно меньше ждать от других (особенно всяких моральных и трудовых подвигов) и больше делать самому, если хочется. Или не делать если не на столько сильно хочется :)
Мы тоже пытались реализовать авторизацию (не путать с аутентификацией - с ней всё норм) через Keycloak, но не взлетело. Например, как банально получить перечень записей, но отфильтровать те, к которым у пользователя нет доступа? Запрашивать все записи и потом по каждой отправлять запрос в Keycloak? Как это всё будет стыковаться с пагинацией? Допустим на странице должно быть 10 записей, из них доступ есть только к 7. Нужно дозапросить ещё 3 записи?..
Я просто не понимаю как это может работать хоть для сколько-нибудь сложного приложения. Хотя сам Keycloak клёвый. У нас приложение вместе с Keycloak, ApacheDS (для тестовых пользователей) и т.д. завернуто в Docker Compose. При запуске Keycloak автоматически импортируется json-конфиг с настройками realm, интеграцией с ApacheDS. Всё это легко разворачивается на стенде, на машинах разработчиков, в тестовом окружении.
Не имею ничего против Яндекс Браузера, в нём есть клевые фичи типа перевода видео на русский язык или Алиса. Хотя сам не пользуюсь. Но я думаю, что очень круто, что люди его делают, что это не просто скины для Chromium, а что в нём действительно есть что-то более сложное.
Но недавно столкнулся с интересной проблемой. Решил использовать в одной корпоративной системе CSS Subgrid, он не плохо поддерживается браузерами, учитывая что мобильные браузеры нам не нужны. И я немного удивился, когда увидел, что стили не работают в Яндекс Браузере. Стал разбираться, оказалось, что там Chromium 110. А не обновляются они скорее всего потому что хотят сохранить поддержку Windows 7 и 8. В более новых версиях эти ОС уже не поддерживаются.
Хотел написать какая плохая Windows, что заставляет пользователей переходить на новые версии с неудобным интерфейсом. Но посмотрел требования Chrome к Linux и macOS и там ситуация аналогичная.
Для меня лично открытый вопрос кто здесь злодей. Яндекс, который ради совместимости со старыми версиями ОС вынуждает меня делать костыли в CSS. Или Google, который подсадил всех на свой движок, а потом просто убирает поддержку старых ОС, которая возможно кому-то нужна.
Для меня это спорный вопрос. Сами термины вполне возможно что появились одновременно, когда люди начали противопоставлять монолиты и микросервисы. Но какой из подходов более новый и прогрессивный... Прообразы микросервисной архитектуры на мой взгляд были и раньше.
Когда-то давно я работал в медицинском центре. Там для каждого подразделения, под каждую задачу была своя небольшая информационная система. Делались они на чём угодно - FoxPro, Delphi + Firebird, Access, C# + MS SQL, Java. Сами по себе эти системы были вполне норм, писались умными людьми и решали свою задачу. Но когда их количество достигло критической массы, то стали возникать вопросы: 1) а почему отчеты, построенные в разных системах не бьются между собой? 2) как вообще собрать эти отчеты без ручной работы? 3) можно ли как-то уменьшить дублирование работы операторов, потому что часто они вносят в разные системы пересекающиеся данные? 4) можно ли как-то в одной системе посмотреть данные из другой системы, чтобы не устанавливать себе десятки приложений?
Нужно было всё это как-то интегрировать. И было два пути:
1) Довести всё это до труЪ микросервисной архитектуры. Прикрутить туда интеграционную шину, ETL-процедуры и т.д., чтобы данные гонялись из одной системы в другую.
2) Разработать единую модель данных для всего предприятия и сделать одну монолитную систему.
Естественно, сначала мы попробовали пойти первым путем, это более логично, чем всё переписать, но быстро надсадились, потому что некоторые ИС использовались просто для распечатки документов, и разработчики не запаривались даже с первичными и внешними ключами. Плюс в принципе тянуть данные из FoxPro - тот ещё гемор. Причём сложно винить разработчиков этих отдельных ИС, ровно по заветам микросервисной архитектуры они выбрали удобные для себя технологии и не тратили время на согласование своей схемы данных со схемами данных других ИС, что позволяло им очень быстро выпускать свои системы в прод, независимо разворачивать их - короче пользоваться основными преимуществами микросервисной архитектуры, хотя тогда этого термина даже и не было.
В итоге мы даже сделали единое хранилище данных, которое наполнялось лютейшими ETL-скриптами, накрутили OLAP-кубы и одну частную задачу построения отчетов решили.
Но потом всё-таки решили, что, нет, нужна единая каноническая модель данных для всего предприятия и одно монолитное приложение. Естественно это существенно упростило и работу ИТ подразделения, и жизнь пользователей, и на порядок увеличило возможности по использованию данных.
Какой из этих двух подходов более правильный и прогрессивный, ну, хз. Конкретно в этом случае для меня микросервисная архитектура - это тот же зоопарк ИС на максималках, который только усугубил бы проблемы. А модульный монолит с единой канонической моделью данных для меня выглядит куда более осмысленным и целостным решением.
Я согласен насчет минусов монолита:
Сложно распределить части приложения между независимыми командами. Хотя, блин, сейчас задумался. А в чём сложность? Стартовый модуль, точка входа в приложение должна быть у всех одна. Но для работы им не нужны все модули. Например, если они разрабатывают модуль для регистратуры поликлиники, то им совершенно не нужен модуль для стационара или аптеки. Достаточно чтобы в приложении была возможность запускать только доступные модули и отключать ненужные.
Сложность масштабирования. Во-первых, на сколько часто эта проблема действительно есть? Во-вторых, разве не проще её решить на уровне СУБД? В том же примере с медицинским центром у нас было несколько распределенных подразделений. В каждом из них просто был развернут свой экземпляр СУБД и данные синхронизировались.
В общем для меня единственный осмысленный сценарий использования микросервисов - это только если каждый микросервис это тупо отдельное приложение, которое практически не пересекается с другими микросервисами. Если у микросервисов разные заказчики, которые планируют использовать данные только из своего микросервиса.
А что если в какой-то момент всё-таки понадобятся целостные данные? Наверное это решится добавлением ещё кучки микросервисов в виде DWH, ETL, ... А что если схема данных в микросервисах на столько разная, что данные фиг соберешь? Это решается с помощью DDD, но тогда это уже не труЪ микросервисы, потому что каждой команде придётся сверяться с единой схемой данных и так быстро фигачить релизы в прод уже не получится.
Короче, я потерял последние доводы в пользу микросервисов. Я реально не понимаю зачем они. Ок, последний довод - это отсутствие единого архитектора на проекте. Хотя, блин, и микросервисная архитектура без архитектора вряд ли обречена на успех. Но наверное этот архитектор должен быть очень ленивый или занятой, чтобы запариваться с единой моделью данных, выбором единых технологий разработки, единой СУБД и т.д. Типа, вот, вам микросервисная архитектура, фигачьте в своих сервисах что хотите, мне пофиг. Ааа, пожалуйста, убедите меня кто-нибудь что это не так и микросервисная архитектура реально решает больше проблем, чем добавляет.
с опытом и тд, не вспомнил что значит буква d в солиде - всё, не прошел
Я не помню ни одной буквы из SOLID :) Не представляю зачем мне их помнить или спрашивать других людей об этом. И вообще кто сказал, что это какие-то основополагающие принципы?.. Я, например, считаю buttom-up design основополагающим подходом, при котором приложение по сути состоит из множества небольших осмысленных микрофреймвоков, которые можно повторно использовать в других проектах, нормально покрыть тестами. А SOLID, KISS, DRY уже автоматически из этого следуют. И если я не помню какие-то буквы, то это не значит, что мой код противоречит этим принципам.
Есть один проект с миллиардом просмотров в месяц. Похоже его создатели всё это время были в анабиозе и не слышали про микросервисы. А если бы добавили хотя бы десяток-другой микросервисов, сагу и это всё, то наверное вообще всё летало бы.
Я думаю смысл в том, чтобы быстро синхронизироваться, решить какие-то простые проблемы, быть в курсе чем занимаются другие. В чате это может быть дольше. Если митинг затягивается на полчаса, то вряд ли большинству людей интересно на столько глубоко погружаться в чужие задачи. Вопросы, которые интересны всем бывают далеко не каждый день.
Это 10 секунд на человека, 2 минуты всего. А за 15 минут вполне можно решить большую часть проблем.
Обычно вопрос к 1-2 людям, они вполне могут собраться отдельно обсудить.
Даже 15 минут на 12 человек - это 180 минут = 3 человеко-часа. Если полчаса посидеть, то это уже 6 часов - почти рабочий день. Я думаю, что частые долгие митинги на большое количество человек - зло. Чем больше людей, тем быстрее должен быть митинг или тем реже.
Мне сложно придумать такой пример. Если это только что-то связанное с гостайной, какими-то ноу-хау или чем-то не очень законным. Я ни разу не встречал таких людей. В любом случае я думаю, что нет никакого секрета в том как на проекте был организован процесс разработки, были ли аналитики, тестировщики, как велась работа с ветками в Git, как декомпозировались задачи, на сколько сложным было приложение (сколько сущностей в схеме данных, сервисов, модулей и т.д.), как была реализована аутентификация, авторизация и куча других технически вопросов, на которые вполне можно ответить, не раскрывая секретов. Или просто отказаться отвечать, это вообще не проблема.
Лично я думаю, что лайвкодинг используется в следующих ситуациях:
Если в компании очень большой поток кандидатов и нужно максимально просто и эффективно их отсеивать. Если отсеяли хорошего кандидата, ну, ничего страшного, завтра будет ещё десяток.
Если у самого интервьюера небольшой опыт или вообще нет опыта и он не может оценить кандидата, просто беседуя с ним.
Если собеседование на джуниорскую позицию без опыта.
Если нет времени, сил, желания запариваться с интервью, то гораздо проще дать очередному кандидату очередную задачку, чем думать, напрягаться, задавать какие-то вопросы.
Если хочется сделать интервью максимально объективным. Решил задачу за полчаса - ставим плюсик. Успел оптимизировать алгоритм - ставим два плюсика. Не сделал задачу - ставим минусик. В итоге суммируем оценки и превращаем кандидата в число. Сортируем этот массив, получаем N лучших кандидатов, делаем им оффер. Хотя у меня есть смутное ощущение, что при этом упускается что-то важное. У каждого кандидата свой уникальный опыт, свои уникальные качества, которые в итоговую сумму не попали, потому что мы даже не спрашивали соискателя о его проектах, интересах.
Вообще я наверное не против лайвкодинга и сам время от времени решаю какие-то задачки, что-то изучаю. И алгоритмическая секция наверное не сильно оскорбила бы мои чувства :) Но на текущем проекте я вообще не вижу никакого смысла давать людям алгоритмические задачи, для меня важнее на сколько человек может работать самостоятельно, декомпозировать сложные задачи, соотносить важность фичи и сложность её реализации, писать понятный код, который потом не нужно переписывать, что-то обсуждать, если задачу непонятно как делать или есть много вариантов решения.
И не нужно спрашивать как он будет варить шов. Можно спросить как он варил швы раньше, как готовил поверхность, какие электроды использовал, какое оборудование, что если был нужен широкий или длинный шов (он варил их в один проход или в несколько), просто вел электродом по прямой или зигзагом, какая была техника безопасности, варил ли он швы в каких-то сложных условиях (на трубе под большим давлением, на большой высоте, в замкнутом помещении, в угольной шахте, ... - если такое требуется на объекте), как проверял качество шва, бывало ли такое что он сварил шов, а потом всё развалилось нафиг. Причём на эти вопросы нет правильного и неправильного ответа. Они просто показывают на сколько человек погружен в эту тему или хочет в неё погружаться.
Практические задачи - это наверное тоже хорошо. Но, блин, всё-таки между ИТ и сваркой есть разница. Сварщик на работе будет реально варить швы и если он не смог сварить тестовый шов, наверное не сможет сварить и реальный - возможно они не сильно отличаются.
А в ИТ тестовые и реальные задачи обычно не имеют вообще ничего общего. Алгоритмические задачи просто проверяют как человек готовился к интервью. Если не готовился, то он его не пройдет, каким бы гением разработки он ни был. А если готовился, то скорее всего пройдёт независимо от того на сколько отстойный он разработчик. И вопрос нафига такое интервью вообще, что оно проверяет? Знание алгоритмов - это безусловно бонус, возможно более полезный чем знание английского на уровне upper-intermediate, умение вышивать крестиком, водительские права категории Б и т.д. И я считаю, что разработчикам очень полезно прокачиваться в алгоритмах. Но это никак не основной скилл разработчика.
Это видно уже после первых ответов на конкретные вопросы. Всегда можно провалиться в детали. Сначала спросить чем человек в принципе занимался, что это был за проект, кто им пользовался. Спросить чем конкретно занимался именно он - только бэком или иногда и фронтом. Занимался ли базой данных. Какие сущности были в схеме данных. Какие были сервисы, модули, классы. Можно задать много вопросов по процессу разработки, сколько человек было на проекте, как он с ними взаимодействовал. Бывало ли что в постановке задачи ошибка или постановка в принципе нереализуемая. Бывало ли что задача оказывалась сложнее, чем её изначально оценили. В зависимости от ответов можно проваливаться всё глубже и глубже. Или наоборот задавать вопросы всё шире и шире, чтобы понять на сколько целостное представление у него о процессе разработки вообще.
С одной стороны, такое интервью очень мягкое, потому что это просто беседа, к которой не нужно специально готовиться. Человек сам волен направить её в любую сторону, говорить о том, что ему ближе и интереснее. С другой стороны, это капец какое сложное интервью, потому что к нему невозможно подготовиться на курсах или решив сотню задач на литкоде. Представьте, что соискатель - это тот же Лев Толстой или человек с очень развитыми коммуникативными навыками, наверное самый мемный пример - это Mike Ross из Suits
https://www.youtube.com/watch?v=tcx3zwhEIOw
или бабушка вашего соседа по этажу - кто угодно, и они полгода прокачивались в прохождении интервью на разработчика. Неужели вы не отличите человека, который реально что-то разрабатывал от человека, который просто красиво об этом рассказывает? Да, встречаются люди, которые на интервью не умолкают и очень складно говорят, но, блин, реальный опыт человека или если нет опыта, то его способности, мотивация видны, я не представляю как это можно скрыть. Конечно есть в некотором роде талантливые люди типа Элизабет Холмс, но она менеджер, и в разработке такое сложно представить. В конце концов, на испытательном сроке будет видно работает человек или нет.
На мой взгляд такое интервью проверяет реальный опыт человека. Или если опыта нет/мало, то позволяет понять чем он в принципе интересуется, как впишется в проект. В отличие от алгоритмических секций, которые проверяют одну единственную вещь - решал человек аналогичные задачки или нет. Если решал - это клёво, и наверное он не будет реализовывать алгоритмы с кубической сложностью там где достаточно линейной, возможно ему будет легче дебажить сложный код и т.д. Но сможет ли он писать понятный код - уже хз, хотя с этим проблемы бывают гораздо чаще чем с алгоритмами. Сможет ли в целом поддерживать качество кодовой базы, а не умножать хаос. Сможет ли он самостоятельно декомпозировать сложные задачи. Сможет ли нормально работать с аналитиками, другими разработчиками, тестировщиками. Меня лично это интересует в профессиональных навыках человека куда больше чем умение решать алгоритмические задачки.
На мой взгляд, если сделать ещё одну итерацию в развитии вашего подхода, то можно и не давать человеку искусственные задачи, даже простые, и не гадать: "Ага! Он не уточнил постановку задачи, пошел сразу удалять все тройки, не уточнил сроки реализации и важность каждого из требований. А что если мне нужно удалять только каждую четную по счету тройку, а нечетные оставлять? Что если удаление троек - это основная фича и её точно нужно реализовать, а вывод в консоль - второстепенная фича и её можно сделать во вторую очередь? Ну, всё, раз не задал эти вопросы даже на такой простой задаче, то что от него можно ждать на более сложных?"
Я немного утрирую, но если вас интересует как человек выстраивает коммуникацию, работает с требованиями, умеет ли декомпозировать, приоритезировать, планировать задачи, то можно тупо спросить его об этом! Как он всё это делал на прошлых проектах. Для этого даже не нужны никакие задачи, не нужно проводить какой-то сложный анализ поведения соискателя, анализировать его мотивы. Если человека спросить какими интересными проектами он занимался, какие задачи и каким образом решал, то (сюрприз!!!) он в большинстве случаев об этом сам расскажет.
Полностью поддерживаю, у меня такой же рецепт. Я ем что угодно и в любых количествах кроме мучного и сладкого. Когда я отказывался от хлеба, конфет и т.д., то чуть ли не по килограмму в день терял, а когда начинал есть, то столько же набирал. Причём это на столько простой и действенный способ, что на мой взгляд любой может попробовать следовать ему хотя бы одну неделю. Я просто не верю в то, что не будет ощутимого результата. Поначалу мне было сложно перестроиться, потому что я с детства привык есть хлеб, везде его предлагают. И даже сейчас условно раз в месяц я могу съесть что-то мучное. Но в целом в какой-то момент я просто перестал воспринимать это как еду.
Если вы тоже попробуете следовать этому рецепту, то не нужно относиться к этому как полному отказу от чего-то на всю оставшуюся жизнь и т.д. Или если вы не удержитесь и съедите какую-нибудь пиццу, то в этом нет вообще никакой проблемы. Воспринимайте это просто как эксперимент по проверке того оказывает такая еда какой-то эффект на ваше состояние или нет.
Да, по ссылке написано:
Т.е. под ресурсом они имеют в виду и коллекцию (тип) ресурсов, и конкретные ресурсы.
Но сложно представить банковскую систему с миллионом пользователей, у каждого из которых есть свои банковские счета. И чтобы собственные правила доступа к каждому из этих миллионов счетов хранились в Keycloak.
Видимо это меня и сбивает, потому что обычно под ресурсом подразумевается конкретный объект. Например, в REST это может быть ресурсами:
https://example.com/api/articles/1
https://example.com/api/articles/2
https://example.com/api/articles/3
...
А статьи, новости и т.д. - это типы ресурсов, а не конкретные ресурсы. Или допустим в документации упоминается "fine-grained authorization", "fine-grained permissions" - у меня сразу возникают ассоциации с ограничением доступа на уровне отдельных объектов или даже отдельных атрибутов, с чем-нибудь типа Row-Level Security, но реально имеется в виду что-то более простое.
Спасибо, теперь кажется понял. По сути resource и scope - это возможно чуть более правильный вариант по сравнению с ролями. Но пообъектную проверку доступа через него всё равно не сделать.
Или пообъектной проверки и нет в Keycloak вообще? Интересно что имеется в виду под ресурсом в документации на сервер авторизации. Это типы ресурсов, например, "обычная статья", "платная статья" и т.д.? Или речь о конкретных ресурсах: "статья с идентификатором 123 про Keycloak", "статья с ид 234 про OIDC" и т.д.? Или ресурсом может быть что угодно: и тип ресурсов, и конкретный ресурс?
То, что в Keycloak можно описать правила доступа к типам ресурсов это понятно. Либо через роли, либо через скоупы. Но если нужно разделение доступа на уровне отдельных объектов, то по-моему Keycloak уже не очень подходит.
Не очень понимаю... Если нужно ограничить доступ по типам ресурсов, то можно использовать роли из Keycloak. Например, одна роль позволяет просматривать новости, другая - статьи.
Немного более сложный вариант. Допустим статьи могут быть двух типов: обычные для всех и премиальные для подписчиков. Это тоже можно решить через роли "обычный пользователь", "подписчик", "супер-подписчик" и т.д.
А если ещё более сложный вариант типа Google Документов? Пользователи могут создавать документы, выдавать к ним доступ другим пользователям. Причём, этих документов в системе миллионы. В Keycloak должна храниться информация о каждом таком документе? Затем в него отправляется запрос с id документа и id пользователя и Keycloak отвечает есть ли у пользователя доступ к этому документу?
Всё равно останется проблема, что записи в одном сервисе (само приложение), а разрешения для них - в другом (Keycloak). И нужно получать данные из двух источников, как-то мержить их. Здесь в принципе не сделать простую и быструю реализацию. Гораздо проще хранить и записи, и разрешения в одной базе и получать всё одним SQL-запросом.
Так и есть, это отличный способ задушить инициативу :) "Нужно что-то сделать, ну, сделай, в чём проблема, от меня-то ты что хочешь?" - немного более развернутый вариант этой фразы, который я иногда слышал.
Или это способ проверить а так ли человеку важно то о чем он говорит. Бывает, что люди критикуют просто ради критики и когда с ними соглашаешься, хорошо, давай сделаем, вот, первый шаг, вот второй, я тебе помогу с этим и этим и т.д., то запал почему-то сразу пропадает.
Или это способ пробудить в человеке инициативность, чтобы он не ждал одобрения и помощи от других, а сам приложил усилия.
Словом, такая простая фраза и столько вариантов интерпретации...
На мой взгляд, и с теми, и с теми сложно делать сложную работу. Когда человек видит только негативное и постоянно об этом говорит, то это демотивирует. Пусть не сразу, но через месяц, через год ты либо выгоришь, либо начнёшь превращаться в душилу.
С другой стороны, если ты постоянно видишь проблемы, пытаешься что-то улучшить, но годами ничего не меняется, то тоже ничего хорошего не будет.
Я думаю, что все эти конфликты связаны с тем, что люди чего-то ждут от других людей. Что для других так же важно качество кода, скорость сборки, простота деплоя, удобство процессов разработки, правильная архитектура, хороший проект, довольные заказчики, спасение мира, гармония во вселенной и т.д. А вполне возможно, что для них более важны совершенно другие вещи. Если тебя что-то не устраивает, то сделай лучше. Зачем капать на мозг другим людям? У них наверное своих проблем, задач, целей, интересов хватает?
Опять-таки и с другой стороны, если люди хотят что-то улучшить и если ты считаешь, что как минимум от этого не станет сильно хуже, то почему бы и нет?
В общем, я думаю, что нужно меньше ждать от других (особенно всяких моральных и трудовых подвигов) и больше делать самому, если хочется. Или не делать если не на столько сильно хочется :)
Мы тоже пытались реализовать авторизацию (не путать с аутентификацией - с ней всё норм) через Keycloak, но не взлетело. Например, как банально получить перечень записей, но отфильтровать те, к которым у пользователя нет доступа? Запрашивать все записи и потом по каждой отправлять запрос в Keycloak? Как это всё будет стыковаться с пагинацией? Допустим на странице должно быть 10 записей, из них доступ есть только к 7. Нужно дозапросить ещё 3 записи?..
Я просто не понимаю как это может работать хоть для сколько-нибудь сложного приложения. Хотя сам Keycloak клёвый. У нас приложение вместе с Keycloak, ApacheDS (для тестовых пользователей) и т.д. завернуто в Docker Compose. При запуске Keycloak автоматически импортируется json-конфиг с настройками realm, интеграцией с ApacheDS. Всё это легко разворачивается на стенде, на машинах разработчиков, в тестовом окружении.
Не имею ничего против Яндекс Браузера, в нём есть клевые фичи типа перевода видео на русский язык или Алиса. Хотя сам не пользуюсь. Но я думаю, что очень круто, что люди его делают, что это не просто скины для Chromium, а что в нём действительно есть что-то более сложное.
Но недавно столкнулся с интересной проблемой. Решил использовать в одной корпоративной системе CSS Subgrid, он не плохо поддерживается браузерами, учитывая что мобильные браузеры нам не нужны. И я немного удивился, когда увидел, что стили не работают в Яндекс Браузере. Стал разбираться, оказалось, что там Chromium 110. А не обновляются они скорее всего потому что хотят сохранить поддержку Windows 7 и 8. В более новых версиях эти ОС уже не поддерживаются.
Хотел написать какая плохая Windows, что заставляет пользователей переходить на новые версии с неудобным интерфейсом. Но посмотрел требования Chrome к Linux и macOS и там ситуация аналогичная.
Для меня лично открытый вопрос кто здесь злодей. Яндекс, который ради совместимости со старыми версиями ОС вынуждает меня делать костыли в CSS. Или Google, который подсадил всех на свой движок, а потом просто убирает поддержку старых ОС, которая возможно кому-то нужна.
Для меня это спорный вопрос. Сами термины вполне возможно что появились одновременно, когда люди начали противопоставлять монолиты и микросервисы. Но какой из подходов более новый и прогрессивный... Прообразы микросервисной архитектуры на мой взгляд были и раньше.
Когда-то давно я работал в медицинском центре. Там для каждого подразделения, под каждую задачу была своя небольшая информационная система. Делались они на чём угодно - FoxPro, Delphi + Firebird, Access, C# + MS SQL, Java. Сами по себе эти системы были вполне норм, писались умными людьми и решали свою задачу. Но когда их количество достигло критической массы, то стали возникать вопросы: 1) а почему отчеты, построенные в разных системах не бьются между собой? 2) как вообще собрать эти отчеты без ручной работы? 3) можно ли как-то уменьшить дублирование работы операторов, потому что часто они вносят в разные системы пересекающиеся данные? 4) можно ли как-то в одной системе посмотреть данные из другой системы, чтобы не устанавливать себе десятки приложений?
Нужно было всё это как-то интегрировать. И было два пути:
1) Довести всё это до труЪ микросервисной архитектуры. Прикрутить туда интеграционную шину, ETL-процедуры и т.д., чтобы данные гонялись из одной системы в другую.
2) Разработать единую модель данных для всего предприятия и сделать одну монолитную систему.
Естественно, сначала мы попробовали пойти первым путем, это более логично, чем всё переписать, но быстро надсадились, потому что некоторые ИС использовались просто для распечатки документов, и разработчики не запаривались даже с первичными и внешними ключами. Плюс в принципе тянуть данные из FoxPro - тот ещё гемор. Причём сложно винить разработчиков этих отдельных ИС, ровно по заветам микросервисной архитектуры они выбрали удобные для себя технологии и не тратили время на согласование своей схемы данных со схемами данных других ИС, что позволяло им очень быстро выпускать свои системы в прод, независимо разворачивать их - короче пользоваться основными преимуществами микросервисной архитектуры, хотя тогда этого термина даже и не было.
В итоге мы даже сделали единое хранилище данных, которое наполнялось лютейшими ETL-скриптами, накрутили OLAP-кубы и одну частную задачу построения отчетов решили.
Но потом всё-таки решили, что, нет, нужна единая каноническая модель данных для всего предприятия и одно монолитное приложение. Естественно это существенно упростило и работу ИТ подразделения, и жизнь пользователей, и на порядок увеличило возможности по использованию данных.
Какой из этих двух подходов более правильный и прогрессивный, ну, хз. Конкретно в этом случае для меня микросервисная архитектура - это тот же зоопарк ИС на максималках, который только усугубил бы проблемы. А модульный монолит с единой канонической моделью данных для меня выглядит куда более осмысленным и целостным решением.
Я согласен насчет минусов монолита:
Сложно распределить части приложения между независимыми командами. Хотя, блин, сейчас задумался. А в чём сложность? Стартовый модуль, точка входа в приложение должна быть у всех одна. Но для работы им не нужны все модули. Например, если они разрабатывают модуль для регистратуры поликлиники, то им совершенно не нужен модуль для стационара или аптеки. Достаточно чтобы в приложении была возможность запускать только доступные модули и отключать ненужные.
Сложность масштабирования. Во-первых, на сколько часто эта проблема действительно есть? Во-вторых, разве не проще её решить на уровне СУБД? В том же примере с медицинским центром у нас было несколько распределенных подразделений. В каждом из них просто был развернут свой экземпляр СУБД и данные синхронизировались.
В общем для меня единственный осмысленный сценарий использования микросервисов - это только если каждый микросервис это тупо отдельное приложение, которое практически не пересекается с другими микросервисами. Если у микросервисов разные заказчики, которые планируют использовать данные только из своего микросервиса.
А что если в какой-то момент всё-таки понадобятся целостные данные? Наверное это решится добавлением ещё кучки микросервисов в виде DWH, ETL, ... А что если схема данных в микросервисах на столько разная, что данные фиг соберешь? Это решается с помощью DDD, но тогда это уже не труЪ микросервисы, потому что каждой команде придётся сверяться с единой схемой данных и так быстро фигачить релизы в прод уже не получится.
Короче, я потерял последние доводы в пользу микросервисов. Я реально не понимаю зачем они. Ок, последний довод - это отсутствие единого архитектора на проекте. Хотя, блин, и микросервисная архитектура без архитектора вряд ли обречена на успех. Но наверное этот архитектор должен быть очень ленивый или занятой, чтобы запариваться с единой моделью данных, выбором единых технологий разработки, единой СУБД и т.д. Типа, вот, вам микросервисная архитектура, фигачьте в своих сервисах что хотите, мне пофиг. Ааа, пожалуйста, убедите меня кто-нибудь что это не так и микросервисная архитектура реально решает больше проблем, чем добавляет.
Я не помню ни одной буквы из SOLID :) Не представляю зачем мне их помнить или спрашивать других людей об этом. И вообще кто сказал, что это какие-то основополагающие принципы?.. Я, например, считаю buttom-up design основополагающим подходом, при котором приложение по сути состоит из множества небольших осмысленных микрофреймвоков, которые можно повторно использовать в других проектах, нормально покрыть тестами. А SOLID, KISS, DRY уже автоматически из этого следуют. И если я не помню какие-то буквы, то это не значит, что мой код противоречит этим принципам.