Пользователь
Внимание: повествование будет идти в стиле "здравствуй дорогой дневничок", без критики и срывов покровов. Я строго против публичной критики компаний в разрезе процесса интервью. Хотят устраивать 5 алгораундов - их дело, они будут платить тебе деньги и вправе решать как они собеседуют. С другой стороны, я считаю, что могу высказывать свое мнение без конкретных имен. Все описанные компании не российские. Извиняюсь за англицизмы.
Предисловие Около года назад я задался целью получить оффер от FAANG. Как следствие, постоянной частью моей жизни стали тематические форумы, площадки и вся сопутствующая атрибутика. Спустя какое-то время я попробовал себя на собеседованиях в околоFAANGoвые компании: Lyft, Spotify, Booking и т. д, где-то успешно, где-то не очень. В это же время мне порекомендовали попробовать пройти собеседование в Тинькофф банк, который внедрил схожий процесс. После стандартного общения с HR менеджером была получена ссылка на описание процесса собеседования. “Хм, почти что FAANG + тех. интервью по Primary Skill”, - подумал я и сказал, что готов приступать. В тот же час было назначено 2 интервью: техническое и coding, а вот 3 этап, system design, нужно было заслужить успешным прохождением первых двух. Почему именно эти 2 части являлись основополагающими, осталось неясным.
Акт первый, технический
В назначенный час я встретился со своим интервьюером. Собеседование выглядело “добротным” и стандартным в заданной проф. области, оттого местами скучным. Было много задач на ревью кода и обсуждения специфики языка, в частности...
Продолжение. К предыдущим постам и карте цикла.
Знаете, что случается, когда и архитектура вроде получилась и команда подобралась нормальная? Приходит ПОЦ. Пилотная версия. Проверка боем. Да, вы уложились в сроки и даже прошли всё внутренние проверки и тестирование на стороне клиента (UAT, SIT, PPT, ETC), так что теперь вас ждёт всё более худшее – то, что не нашли. Потому что там точно что-то спрятали. Может и не вы, но в конце точно прозвучит: «доктор, это вам!».
Всем привет, это PsyHaSTe и сегодня я хотел бы рассказать о том, куда меня занесла нелегкая в процессе оптимизации и рефакторинга кода решения тестового задания из статьи товарища novar (кто пропустил — рекомендую ознакомиться). Какие проблемы были у этого решения? Почему все-таки человеку отказали в работе? Что можно с этим сделать? Ответы на эти и многие другие вопросы оказались слишком длинными для комментария и вылились в статью с подробным разбором, примерами и альтернативной реализацией задания.
Если вам интересно кто в здравом уме мог для выполнения поставленной задачи написать код сочетающий монады с goto, а также одновременно сократил объем кода и увеличил его производительность, то добро пожаловать под кат. И, конечно же, самое вкусное, связанное с оптимизациями на базе работы JIT — в конце. Итоговую версию решения тестового можно посмотреть на гитхабе по ссылке.
В моей практике не раз были ситуации, когда хотелось посмотреть, какие именно запросы долго тупили в базе в определённый (конкретный) момент времени. А может, запросы не тупили, но каких-то запросов было слишком много.
Ключевое слово — в конкретный момент времени. Например, база непонятно от чего напряглась на 5 минут, потом всё само рассосалось, и очень хочется знать, почему. Отчёты за сутки, присылаемые dba на основе pg_stats_statements, не всегда проясняют ситуацию. Другие графики и логи могут помочь. Но всё же хочется не гадать на кофейной гуще, а конкретно посмотреть, что такому-то запросу в такое-то время было плохо, или его было много.
Можно, конечно, подключить системы а ля okmeter, но okmeter стоит денег. Да ещё и отсылает запросы в чужое облако — что, понятно, не в каждой организации можно считать безопасным.
На удивление, сделать такой мониторинг самому занимает всего полчаса времени, буквально с помощью нескольких строк Go-кода и палок.
Программисты пишут код (удивил, да?) Если это пет-проект, то вы вольны делать со своим кодом все, что хотите. Но когда над одним проектом работает несколько человек или даже целая команда, рано или поздно встаёт вопрос о необходимости код-ревью. Кому отдать на ревью? Как ускорить этот процесс? Как равномерно распределять реквесты по ревьюерам? Вопросов много, а ответы не так очевидны. В этой статье расскажу, с какой проблемой мы столкнулись в команде автотестирования в Wrike, как у нас устроен процесс ревью и зачем нам понадобился самописный сервис.
Распределенные приложения сложны и влекут за собой свой собственный караван трудностей с отладкой и исправлением проблем в продакшене. Хотя микросервисная архитектура и дает возможность справляться силами меньшей команды, которая работает автономно и фокусируется на разных областях бизнеса, из-за своего распределенного характера она подкидывает нам новые проблемы. Например, в случае возникновения проблемы во время бизнес-транзакции, запрос необходимо отслеживать от начала и до конца, что может охватывать несколько служб и инфраструктур. Некоторые из трудностей таковы:
Однажды я гулял в парке и следом шел мужчина с большой собакой. Нам навстречу шла семья из четырех человек: родители, малыш в коляске и девочка лет 6-ти. Девочка увидела собаку и закричала: "собака большая кусаться опасная". Т.е человечек просто накидывал важные слова, не заботясь о том, как их правильно увязать. С тех пор это мой персональный синоним "нет времени формулировать".
Когда мне на работе выдали ноутбук HP ENVY 15, ассоциация возникла похожая: нет времени распаковывать и облизывать - он слишком мощный, давайте его сразу в бой. Поэтому я забрал его на дачу (здравствуй удаленка>отпуск>удаленка) и спустя полтора месяца могу рассказать о нем как о довольно интересном впечатлении.
Сегодня мы посмотрим, как маленькие оптимизации в нужных местах приложения могут неплохо повысить его производительность. Убрали создание лишнего итератора в одном месте, избавились от упаковки в другом, а в итоге получается результат, несоизмеримый с правками.
Когда-то давно в дебрях Интернета я случайно нарвался на матрицу компетенций программиста от Джозефа Сиджина, которая помогла мне правильно оценить свою стоимость на рынке труда и выработать пути по дальнейшему самосовершенствованию. Шло время, проекты в которых я участвовал, росли. Росли, росли и выросли до такого состояния, что в этих проектах потребовалось участие не только программистов, но и аналитиков. Помня положительный эффект от матрицы Д. Сиджина, в какой-то момент я решил найти такую же шкалу компетенций, но уже для аналитиков. И, что неудивительно, нашел.
Архитектура приложения — это его технологическая база, которая учитывает риски проекта, бюджет, требования и ограничения, потребности в масштабировании.
Помимо разработки архитектуры, на старте требуется приблизительно оценить объем и стоимость проекта. Для этого мы в своей практике используем одну из проверенных методологий создания архитектуры ПО — Attribute-Driven Design (ADD). При этом мы опираемся на атрибуты качества того или иного IT-продукта. На их основе мы на этапе оценки (пресейла) создаём архитектурную концепцию системы.
Рассмотрим этапы работы с архитектурной концепцией, возможные сложности и решения, исходя из опыта нашего Архитектурного комитета. Мы надеемся, что статья будет полезна архитекторам и разработчикам, желающим освоить методологию ADD, и может быть интересна смежным специалистам.
Чтобы оставаться продуктивным, эффективным, адекватным и быть полным сил, нужно спать, двигаться и учиться. Особенно это важно тем, кто по специфике своей работы много думает и принимает ответственные решения. Гаджеты, сотни медиа и социальных сетей, которые воюют за наше внимание, не помешают.
О мифах продуктивности и здоровом сне по просьбе Мегаплана рассуждает научный журналист, популяризатор науки, автор научно-популярных книг, лауреат премии «Просветитель» Ася Казанцева. Мы долго искали возможность пообщаться с ней и очень обрадовались, когда это удалось сделать.
Современные микросервисные архитектуры являются событийно-ориентированными, реактивными и придерживаются хореографического подхода (в противовес к централизованному контролю через оркестратор), что позволяет им быть слабо связанными и легко изменяемыми, не так ли?
В этой статье я просуммирую свой опыт работы с хореографией микросервисов и укажу на различные препятствия и последствия данного подхода. Я использую типичный пример из бизнеса — процесс “клиентской адаптации” (в зависимости от отрасли, вы могли слышать о нем как об открытии счета). Для представленной очереди событий ниже, я использую Apache Kafka, но не беспокойтесь если используете другой стек, для него будут применимы все те же понятия.
Пару лет назад друзья скинули очень забавный комикс под названием “Сова — эффективный менеджер”. Я посмеялась, подумала, что смешно, такого же не бывает, как классно утрированы ситуации. Но очень скоро этот комикс стал моей реальностью — в нашей команде появился он: “эффективный” менеджер, и стало не до смеха.
Итак, с этого момента начинается вызов для продакт/проджект менеджера и команды. В ходе этой истории все стороны понесли огромные потери: и инвестор, и продукт, и команда. Но главное, что из подобных ситуаций выход есть, а масштабы бедствия можно локализовать и сократить.
