Java developer, Teamlead
Как я научился проходить архитектурные секции
Нам нужно поговорить…
В ЦФТ эту проблему решили регулярные встречи с инженерами один на один. Встречи помогают: вовремя выявить проблемы в работе, профессионально развиваться, повышать мотивацию и находить новые смыслы. О том, как готовиться ко встречам, какие вопросы задавать и как регулярно их проводить, расскажет Михаил Емельянов. Теперь вы будете знать, что делать, если инженер сказал: «Нам нужно поговорить...»
Михаил Емельянов — Head of Android Department в ЦФТ. В IT-разработке 12 лет, с Android — 10, из которых 2 года руководит командой Android-разработки в ЦФТ. Разрабатывал проект мультимедиа, различные проекты в финтехе и запускал стартапы.
Советы руководителю от руководителя
Недавно меня попросили поделиться на внутренней конференции «секретами управления» с другими руководителями. Поводом стала низкая текучка в моём подразделении и здоровый дух внутри команды — так было на всех моих работах. Я отказался, сославшись на то, что не делаю для этого ничего особенного. Сработала внутренняя установка «не будь выскочкой».
Потом я вспомнил, что живу в мире пустозвонов, не стесняющихся нести «знания» в массы: бизнес-консультанты без бизнеса, карьерные консультанты без карьеры, коучи по чему угодно после двухмесячных курсов от таких же коучей. Неопытные умы, наслушавшись их, думают, что так мир и устроен, а потом огорчаются, что ничего не вышло. А опытные крутят у виска и отмалчиваются.
Поэтому выключаю тумблер «не будь выскочкой» и делюсь «секретами».
Тут не будет стандартных «делегируй», «налаживай процесс», «стой в правильной позе на стендапе» — об этом написано уже достаточно. Будет о другом.
Программист не должен решать задачи бизнеса
Книги для тимлидов и руководителей проектов. Часть 2
Итак, я просил ответить на вопрос какие книги из статьи вы читали?
Результаты опроса:
Название книги |
Количество голосов |
Процент |
Том ДеМарко. Deadline. Роман об управлении проектами |
247 |
54% |
Фредерик Брукс. Мифический человеко-месяц, или Как создаются программные системы |
174 |
38% |
Джоэл Спольски. Джоэл о программировании |
165 |
36% |
Том Демарко и Тимоти Листер. Человеческий фактор. Успешные проекты и команды |
148 |
32% |
Джейсон Фрайд, Дэвид Хайнемайер Хенссон. Rework. Бизнес без предрассудков |
108 |
24% |
Джеффри Янг и Уильям Саймон. iКона. Стив Джобс |
94 |
21% |
Том ДеМарко, Тимоти Листер. Вальсируя с Медведями: управление рисками в проектах по разработке программного обеспечения |
70 |
15% |
Том Демарко, Тимоти Листер. Балдеющие от адреналина и зомбированные шаблонами. Паттерны поведения проектных команд |
51 |
11% |
Кармин Галло. iПрезентация. Уроки убеждения от лидера Apple Стива Джобса |
48 |
11% |
Патрик Ленсиони. Смерть от совещаний |
21 |
5% |
Патрик Ленсиони. Пять пороков команды. Притчи о лидерстве |
19 |
4% |
Патрик Ленсиони. Пять искушений руководителя: притчи о лидерстве |
16 |
4% |
Патрик Ленсиони. Три признака унылой работы. История со смыслом для менеджеров (и их подчиненных) |
11 |
2% |
А теперь еще один бонус — список книг по заданной тематике, которые прислали нам читатели:
Стажёр Вася и его истории об идемпотентности API
Идемпотентность — звучит сложно, говорят о ней редко, но это касается всех приложений, использующих API в своей работе.
Меня зовут Денис Исаев, и я руковожу одной из бэкенд групп в Яндекс.Такси. Сегодня я поделюсь с читателями Хабра описанием проблем, которые могут возникнуть, если не учитывать идемпотентность распределенных систем в своем проекте. Для этого я выбрал формат вымышленных историй о стажёре Васе, который только-только учится работать с API. Так будет нагляднее и полезнее. Поехали.
«Не так важны инструменты, как умение мыслить о системах, которые они создают». Большое интервью с Мартином Клеппманом
Мартин Клеппман (Martin Kleppman) – исследователь в Кембриджском университете, работающий над CRDT и формальной верификацией алгоритмов. Его книга «Designing Data-Intensive Applications», опубликованная в 2017 году, стала бестселлером в области хранения и обработки данных.
Kevin Scott (CTO в Microsoft) однажды сказал: «Эта книга должна быть обязательной для инженеров-разработчиков. Это редкий ресурс, объединяющий теорию и практику, помогающий разработчикам глубже продумывать дизайн и реализацию инфраструктуры и систем обработки данных». Что-то похожее говорил и Jay Kreps — создатель Apache Kafka и CEO Confluent.
А прежде чем заняться академическими исследованиями, Мартин работал в индустрии и стал сооснователем двух успешных стартапов: Rapportive (купленный LinkedIn в 2012 году) и Go Test It (куплен RedGate).
Этот хабрапост – развернутое интервью с Мартином. Примерные темы обсуждения:
- Переход от бизнеса к академическим исследованиям;
- Предпосылки написания Designing Data-Intensive Applications;
- Здравый смысл против искусственного ажиотажа и рекламы инструментов;
- Ненужность теоремы CAP и другие ошибки индустрии;
- Полезность децентрализации;
- Блокчейны, Dat, IPFS, Filecoin, WebRTC;
- Новые CRDT. Формальная верификация на Isabelle;
- Дискуссия про event sourcing. Низкоуровневый подход. XA-транзакции;
- Apache Kafka, PostgreSQL, Memcached, Redis, Elasticsearch;
- Использование всего этого в реальной жизни;
- Порог входа в доклады Мартина и конференция Hydra.
Интервью провёл Вадим Цесько (@incubos) — ведущий разработчик в команде Платформы компании Одноклассники. Научные и инженерные интересы Вадима касаются распределённых систем и хранилищ данных, а также верификации программных систем.
Kubernetes захватит мир. Когда и как?
Оригинал интервью в виде подкаста послушайте на DevOps Дефлопе — русскоязычном подкасте о DevOps, а ниже — текстовая версия.
Здесь и далее вопросы задает Виталий Хабаров инженер из Express42.
Отучаемся от токсичных практик на код-ревью
Код-ревью частенько порождают споры. При подготовке лекции «Отучаемся от токсичного поведения на код-ревью» на конференции AlterConf я была готова услышать кучу возражений и критики. Но совершенно не ожидала, что сообщество настолько поддержит идею. Я предполагала сопротивление, но сообщество очень доброжелательно и с одобрением приняло меня.
Меня попросили поделиться слайдами, но теперь я подумала, что слайды сами по себе малополезны и вырваны из контекста: им не хватает объяснений. Поэтому решила опубликовать эту статью. Позже организаторы конференции выложили видеозапись.
Добро пожаловать в Кремниевую долину
Как я стала частью этой системы
Мне повезло, я живу в Кремниевой долине. Здесь я родилась, выросла и в настоящее время работаю продакт-менеджером в Google. Здесь отличная погода, низкий уровень преступности, и хорошее финансирование у школ. У взрослых есть хорошая непыльная работа, а детям открыты миллионы возможностей. Здесь люди наслаждаются суширрито по 15 долларов и запивают их 6-долларовым кофе третьей волны. Улицы заполнены теслами и беспилотными автомобилями.
Одинадцать скрытых жемчужин Java 11
Java 11 не представил никаких новаторских функций, но содержит несколько жемчужин, о которых вы могли ещё не слышать. Уже смотрели на новинки в String
, Optional
, Collection
и других рабочих лошадках? Если нет, то вы пришли по адресу: сегодня мы рассмотрим 11 скрытых жемчужин из Java 11!
Как рекомендовать музыку, которую почти никто не слушал. Доклад Яндекса
Плюс у нас есть такие исполнители, которые называются композиторами и обычно проставляются правообладателями просто веером. Только у одного Моцарта было «записано» более миллиона композиций.
— Всем привет! Меня зовут Даниил Бурлаков, я руковожу командой рекомендаций в Медиасервисах. Сегодня хочу рассказать про некоторые проблемы, которые мы решаем, когда занимаемся рекомендациями в Музыке.
Топ 6 оптимизаций для netty
(Не обращайте внимание на пики, это баги при деплое)
Эта статья будет полезна всем тем кто работает с netty или только начинает. Итак, поехали.
Нативный Epoll транспорт для Linux
Одна из ключевых оптимизаций, которую стоит использовать всем — это подключение нативного Epoll транспорта вместо реализации на java. Тем более, что с netty это означает добавить лишь 1 зависимость:
<dependency>
<groupId>io.netty</groupId>
<artifactId>netty-transport-native-epoll</artifactId>
<version>${netty.version}</version>
<classifier>linux-x86_64</classifier>
</dependency>
и автозаменой по коду осуществить замену следующих классов:
- NioEventLoopGroup → EpollEventLoopGroup
- NioEventLoop → EpollEventLoop
- NioServerSocketChannel → EpollServerSocketChannel
- NioSocketChannel → EpollSocketChannel
Дело в том, что java реализация для работы с не блокирующими сокетами реализуется через класс Selector, который позволяет вам эффективно работать с множеством соединений, но его реализация на java не самая оптимальная. Сразу по трем причинам:
- Метод selectedKeys() на каждый вызов создает новый HashSet
- Итерация по этому множеству создает iterator
- И ко всему прочему внутри метода selectedKeys() огромное количество блоков синхронизации
В моем конкретном случае я получил прирост производительности около 30%. Конечно же, эта оптимизация возможна только для Linux серверов.
Приглашая опытного разработчика, вы не покупаете, а продаёте
Есть много причин, почему некоторым не удаётся привлечь талантов. Однако все команды, которые делали это с лёгкостью, поняли один простой факт о текущей ситуации на рынке:
При найме сеньоров не компания выбирает кандидата, а кандидат выбирает компанию.
Проще говоря:
Приглашая опытного разработчика, вы не покупаете, а продаёте.
[Видео] Почему взрываются ракеты, что скоро появится в Kotlin и как спасти код ревью
6 декабря мы провели очередной Java-митап. Там говорили вот о чём:
- о разработке Moira — системы экстренного реагирования на инциденты (про ракеты — здесь);
- о контрактах в Kotlin, задачах, проблемах и улучшениях для DSL;
- о том, как роботом выбирать ревьюеров в большой команде разработчиков;
- о том, как научить все компоненты генерировать графики и метрики на боевой среде;
- о правильной обратной связи для обнаружения проблемных релизов.
В этом посте — пять докладов, которые сделают вашу жизнь лучше, разработку более приятной, а новый год — ещё более новым.
Методика оценки знаний инженера. Путь архитектора и путь эксперта
Параметров, на самом деле, много. Но у нас есть замечательный пример, как сложное можно визуализировать достаточно простым и наглядным способом.
Я говорю про (думаю всем известный) квадрант Гартнера.
Эта статья о том, как был применен подобный подход визуализации для оценки уровня знаний и навыков сетевых инженеров в одной российской компании.
Двумерный подход
При проведении вышеупомянутого опроса было принято решение отображать уровень знаний инженера в двух измерениях. Величина, откладываемая по оси OX характеризует глубину знаний а по оси OY – широту технического кругозора.
Конечно, важно изначально ограничить круг рассматриваемых тем, в соответствии с требованиями компании. В нашем случае это были R&S, Security, Service Provider.
Теория счастья. Закон арбузной корки и нормальность ненормальности
• Случайности случайны?
• Головокружительный полёт бутерброда с маслом
• Закон арбузной корки и нормальность ненормальности
• Закон зебры и чужой очереди
• Проклятие режиссёра и проклятые принтеры
• Термодинамика классового неравенства
В этой главе мы начнём с анализа арбузов и их корок, выясним их связь со знаменитым законом Мерфи и убедимся со всей строгостью в том, что о вкусах не спорят.
Теория счастья. Случайности неслучайны?
В этой главе мы порассуждаем о предопределённости полёта монетки, о топографических картах, о математических катастрофах и о природе случайности. А по пути заглянем в такие разделы математики, как теория мер и теория динамического хаоса.
Лучшие работодатели в ИТ 2018: ежегодный рейтинг «Моего круга»
В середине 2018 года мы на «Моём круге» запустили сервис оценки работодателей, с помощью которого каждый сможет узнать, что думают о компании как о работодателе её сотрудники. И сегодня рады представить первый ежегодный рейтинг компаний «Лучшие работодатели в ИТ 2018, по версии «Моего круга». Этот рейтинг мы хотим сделать доброй традицией и выпускать ежегодно.
С момента запуска сервиса порядка 5000 сотрудников поставили свои оценки более чем 900 компаниям. В итоге, на данный момент публичную оценку получили 150 компаний, собравших мнения о себе от 10 и более сотрудников. Именно эти компании и стали участниками нашего нынешнего рейтинга.
Сотрудники оценивают своих работодателей по 12 качествам, по каждому ставят оценку от 1 (полностью не согласен) до 5 (полностью согласен). Из оценок сотрудников вычисляется средняя оценка каждого качества (как среднее взвешенное), а из оценок качеств — средняя оценка компании в целом (как среднее арифметическое). Эти средние оценки компании в целом мы и сравниваем, чтобы построить рейтинг. Подробнее о системе оценок и правилах их расчёта.
Ещё мы сравниваем оценки компаний по каждому из 12 качеств, и если компания вошла в тройку лидеров по данному качеству, мы присваиваем ей соответствующую номинацию.
Компании в рейтинге соревнуются в 4 «весовых» категориях:
- Огромные компании (xbig). Для компаний численностью более 5000 сотрудников, «нормальной» (средней медианной) является оценка 3.6.
- Большие компании (big). Для компаний от 1000 до 5000 сотрудников — 4.2.
- Средние компании (medium). Для компаний от 100 до 1000 сотрудников — 4.5
- Небольшие компании (small). Для компаний от 10 до 100 сотрудников — 4.6.
Информация
- В рейтинге
- Не участвует
- Откуда
- Санкт-Петербург, Санкт-Петербург и область, Россия
- Работает в
- Зарегистрирован
- Активность