Почему вы не прошли очередное собеседование? Вы можете прочитать кучу причин, про непрофессионализм, незнание какого-то фреймворка, софт-скилы и т.п. Главная причина - вы не понравились, вы не идеальны с точки зрения собеседующего, как человек вы ему неприятны, вы расходитесь во взглядах на жизнь. И простого подчинения политике компании на словах тут недостаточно. Я утверждаю это на основании моего довольно интересного опыта. У меня 2 стэка - PHP(Laravel и Symfony) и Ruby(Rails). Сравнивая десятки собеседований на эти 2 стэка(да, у меня два разных резюме, об этом ниже), я пришел к очень интересным выводам.
Разработчик
Архитектура ИТ решений. Часть 1. Архитектура предприятия
I. Вступление
Архитектура распределяет массы и объемы.Недавно столкнулся со следующей ситуацией, одна крупная ИТ компания подбирала для себя архитектора, с целью доработки компьютерной платформы «собственного исполнения». Такая работа, естественно, требовала привлечения специалиста высокой квалификации. А как это сделать дешево и сердито, чтобы призванный варяг был «и чтец и жнец и на дуде игрец»? Решили без всяких излишеств разработчика ПО, поименовать архитектором, и заполучить помимо кодировщика, еще и профессионала, способного разобраться с чужими решениями, до проектировать их на свое усмотрение, принимать самостоятельные решения и т.п…
Вдохновение превращает инертный камень в драму.
Ле Корбюзье.
Когда стали выяснять, а как же в организации вообще обстоит дело с архитектурой, обозначились следующие тенденции. Есть ряд высококвалифицированных разработчиков, позиционируемых как архитекторы. Помимо непосредственно создания кода, они выполняют достаточно низкоуровневое проектирование различных технологических систем и задают вектор и горизонт их развития. Решения представлены ими в основном в виде текстовых описаний, разбавленных небольшим количеством схем, в основном производных от диаграмм компонентов. Каждый из архитекторов представляется уникальным и эксклюзивным носителем знаний, а по сути — является узким местом в процессе производства программных продуктов. Ведь на практике без его постоянных уточняющих консультаций, воспользоваться результатом евонной деятельности практически невозможно. Полная, логически выстроенная, структурированная картинка сложного решения есть лишь в его голове.
Быть тимлидом, ч.1: Люди
Всем привет. Меня зовут Семён, я руковожу разработкой партнёрских сервисов в ДомКлик. О роли тимлида сказано и написано много: бесконечное число книг, технических и не очень, тренинги, конференции, каналы и прочее. Проблема в том, что ни одна книга не даёт рецепта «серебряной пули», которая позволила бы эффективно управлять людьми и процессом разработки, не совершая ошибок. Поэтому каждый тимлид со временем создаёт свой фреймворк работы, который помогает справляться с ежедневной рутиной, при этом не забывать про развитие, делать это эффективнее и совершать меньше ошибок. Форма у этого фреймворка может быть любая: где-то его формализуют и делают частью бизнес-процессов компании, а где-то он может существовать в виде чек-листа в заметках тимлида. Главное, чтобы он был, чтобы им пользовались, актуализировали и развивали. В этой серии статей я хочу описать свой взгляд на работу тимлида, поделиться опытом и лайфхаками. Кого заинтересовал — прошу под кат.
Что ученые должны знать о железе для написания быстрого кода
Программирование сегодня используется во многих областях науки, где отдельным ученым часто приходится собственноручно писать код для своих проектов. Для большинства ученых, однако, компьютерные науки не являются их областью знаний; они изучили программирование по необходимости. Я считаю себя одним из них. Хотя мы можем быть достаточно хорошо знакомы с программированием со стороны софта, мы редко имеем даже базовое представление о том, как железо влияет на производительность кода.
Цель этого урока — дать непрофессиональным программистам краткий обзор особенностей современного оборудования, которые нужно понимать, чтобы писать быстрый код. Это будет дистилляция того, что мы узнали за последние несколько лет. Этот учебник будет использовать Julia, потому что она позволяет легко продемонстрировать эти относительно низкоуровневые соображения на высокоуровневом интерактивном языке.
Как работать с джуниорами?
Рассказывать будет Серёжа Попов, CEO Лига А. и директор по талантам в HTML Academy. В Лига А. работа с джуниорами поставлена на поток: половина фронтендеров компании — это выпускники HTML Academy. Выпускники приходят в компанию на стажировку, где им помогают развиваться, а 95% тех, кто после стажировки ищет другую работу — трудоустраивается.
Серёжа уже больше 3 лет выполняет роль наставника для джуниор-фронтендеров и научился работать с ними так, чтобы новички быстро росли до крутых специалистов и приносили пользу компании. Нюансами, принципами, правилами и секретами работы, он поделился в докладе на TeamLead Conf 2020, а мы расшифровали.
Практическое руководство по разработке бэкенд-сервиса на Python
TL;DR: Вот репка на GitHub с приложением, а кто любит (настоящие) лонгриды — прошу под кат.
Где порешать реальные задачи для кандидатов в Яндекc: тренировка на Codeforces и разбор
Разборы и код сознательно спрятаны в спойлеры. Если вы готовитесь к собеседованиям в большие IT-компании, попробуйте решить одну или несколько задач, прежде чем смотреть разбор. Отправить решение для проверки можно на Codeforces — ответ придёт сразу же (ссылка на Codeforces и примечание). Код представлен на Python, C++ и Java. Важно: авторский «олимпиадный» код не предназначен для продакшена, он написан исходя из того, что система будет проверять его автоматически.
Fault Tolerance Web Architecture for Our Cloud Solutions
Hi Habr,
I'm Artyom Karamyshev, a system administration team leader at Mail.Ru Cloud Solutions (MCS). We launched many products in 2019. We've aimed to make API services easily scalable, fault-tolerant, and ready to accommodate rapid growth. Our platform is running on OpenStack, and in this article, I describe all the component fault tolerance issues that we've resolved.
The overall fault tolerance of the platform is consists of its components fault tolerance. So, I'm going to show you step by step tutorial about all levels where we've found the risks.
Устройство Helm и его подводные камни
Typhon freight hauler concept, Anton Swanepoel
Меня зовут Дмитрий Сугробов, я разработчик в «Леруа Мерлен». В статье расскажу, зачем нужен Helm, как он упрощает работу с Kubernetes, что поменялось в третьей версии и как с его помощью обновлять приложения в продакшене без простоя.
Это конспект по мотивам выступления на конференции @Kubernetes Conference by Mail.ru Cloud Solutions — если не хотите читать, смотрите видео.
Начинаем работать в STM32CubeMX. Часть 1
Часть 3
Приветствую аудиторию хабра, и хочу предложить вашему вниманию первый пост, посвященный использованию среды разработки STM32CubeMX, написанный для тех, кто хочет начать изучение STM32 «с нуля».
Я планировал написать несколько постов, рассмотрев несколько периферийных устройств микроконтроллера и их конфигурирование в STM32CubeMX. Но эти посты не заменяют фирменной документации и не претендуют на полноту. В них будут рассмотрены только некоторые, наиболее, на мой взгляд, типичные, примеры использования периферии STM32.
Надеюсь, кому-то этот материал будет полезен.
Знай сложности алгоритмов
Статический анализ в Go: как мы экономим время при проверке кода
Привет, Хабр. Меня зовут Сергей Рудаченко, я техлид в компании Roistat. Последние два года наша команда переводит различные части проекта в микросервисы на Go. Они разрабатываются несколькими командами, поэтому нам понадобилось задать жесткую планку качества кода. Для этого мы используем несколько инструментов, в этой статье речь пойдет об одном из них — о статическом анализе.
Статический анализ — процесс автоматической проверки исходного кода при помощи специальных утилит. Эта статья расскажет о его пользе, кратко опишет популярные инструменты и даст инструкции по внедрению. Её стоит читать, если вы не сталкивались с подобными инструментами вовсе или используете их несистематически.
В статьях по этой теме часто встречается термин «линтер». Для нас это удобное название простых инструментов для статического анализа. Задача линтера — поиск простых ошибок и некорректного оформления.
Микросервисы на Go с помощью Go kit: Введение
В этой статье я опишу использование Go kit, набора инструментов и библиотек для создания микросервисов на Go. Эта статья — введение в Go kit. Первая часть в моем блоге, исходный код примеров доступен здесь.
MongoDB от теории к практике. Руководство по установке кластера mongoDB
- Вступление. Кратко о масштабировании
- Некоторые примеры развертки mongoDB и их описание
- Шардинг mongoDB
Пункты 1 и 2 — теоретические, а номер 3 претендует на практическое руководство по поднятию кластера mongoDB и больше всего подойдет тем, кто столкнулся с этим в первый раз.
Разбор квалификации чемпионата по программированию среди бэкенд-разработчиков
Первого июня состоялись финалы нашего чемпионата по программированию. Имена победителей уже известны. В скором времени они получат свои награды, а мы тем временем начинаем публиковать разборы задач чемпионата. Сначала разберём задачи квалификационного этапа среди бэкенд-разработчиков.
Квалификация длится неделю, а количество участников исчисляется тысячами, так что подготовка задач, оказывается, непростое дело. В общей сложности нам нужно было сделать 24 задачи и разделить их между четырьмя вариантами так, чтобы варианты оказались сопоставимы по сложности.
В этот раз мы придумали шесть задач, для каждой из которых можно было придумать несколько альтернативных формулировок: одна придуманная задача порождала сразу четыре! Тем самым варианты получились сопоставимыми настолько, насколько это вообще возможно.
Поэтому я не буду публиковать разборы всех 24 задач. Вместо этого я разберу шесть задач одного из квалификационных вариантов: другие решаются похожим образом.
MongoDB Go Driver туториал
UPD: туториал обновлен в связи с выходом релизной версии.
Хорошие новости! Официальный драйвер go для mongoDB вышел в релиз.
Немного поразмыслив я решил перевести статью с официального сайта mongoDB вместо того, чтобы писать материал самостоятельно(данный перевод отличается от статьи).
Вот что будет в данном туториале:
- Установка mongo-go-driver
- Соединение с mongoDB с помощью mongo-go-driver
- Использование BSON объектов
- Использование CRUD методов
Построение отказоустойчивой (fault tolerant) системы
Архитектура и архитекторы
Большинство разработчиков, скорее всего, представляют себе архитектуру только в приложении к конкретному проекту, т.е. можно часто услышать от них «архитектура ПО», однако это лишь малая часть того, что входит в общее понятие. Условно можно разделить глобальное понятие на несколько частей, от общего к частному. Можете представить их в виде пирамиды:
- Бизнес архитектура
- Архитектура информационных систем (потоки данных)
- Технологическая архитектура
Таким образом, разработчики чаще всего говорят о технологической архитектуре приложения.
Бизнес архитектура, она же Enterprise, является представлением того, как эффективно воспроизвести цели бизнеса и стратегию путем создания, улучшения и объединения ключевых требований, принципов и моделей для успешного развития бизнеса и достижения поставленных целей. Определение взято из английской википедии. Архитекторы уровня Enterprise должны ориентироваться на бизнес потребности и проводить анализ потоков данных, т.е. покрывают два указанных пункта. Архитекторы уровня Solution занимаются технологическими аспектами проектов. Так же стоит упомянуть не обозначенных здесь Infrastructure Architect, людей, которые занимаются глобальным развитием и анализом технических возможностей по реализации проектов.
Микросервисные паттерны проектирования
В ближайшее время читайте пост о русском переводе долгожданной книги "Создание Микросервисов" Сэма Ньюмена, которая уже отправилась в магазины. Пока же мы предлагаем почитать перевод статьи Аруна Гупты, автор которой описывает самые интересные паттерны проектирования, применимые в микросервисной архитектуре
CQRS. Факты и заблуждения
CQRS — это стиль архитектуры, в котором операции чтения отделены от операций записи. Подход сформулировал Грег Янг на основе принципа CQS, предложенного Бертраном Мейером. Чаще всего (но не всегда) CQRS реализуется в ограниченных контекстах (bounded context) приложений, проектируемых на основе DDD. Одна из естественных причин развития CQRS — не симметричное распределение нагрузки и сложности бизнес-логики на read и write — подсистемы Большинство бизнес-правил и сложных проверок находится во write — подсистеме. При этом читают данные зачастую в разы чаще, чем изменяют.
Не смотря на простоту концепции, детали реализации CQRS могут значительно отличаться. И это именно тот случай, когда дьявол кроется в деталях.
Информация
- В рейтинге
- Не участвует
- Откуда
- Санкт-Петербург, Санкт-Петербург и область, Россия
- Зарегистрирован
- Активность