​​​​#реклама #конференции

Долгожданная 7-я конференция, посвященная .NET фреймворку - .NET fwdays'21 в формате OFFLINE & ONLINE.🔥

🗓 Дата: 7 августа + дополнительные дни (3, 5 и 10 августа).
⏰ Время: 10:00 - 19:00 (UTC + 3).

.NET fwdays'21 -  это:
- доклады от топовых экспертов Microsoft, SoftServe, Eleks, DevRain и не только, которые поделятся собственным опытом;
- дополнительные эфиры с практическими форматами;
- Q&A сессии, где вы сможете задать все свои вопросы экспертам;
- новые знакомства и много общения;
- нетворкинг, розыгрыши от компаний-партнеров и не только.

Вы узнаете про лучшие практики:
- как можно использовать концентраторы событий Azure для обработки и хранения этих событий для создания собственного хранилища событий на базе Cosmos DB;
- подключения к другим службам Azure и к приложениям Kafka;
- как внедрить аутентификацию и авторизацию для мобильных приложений и сервисных служб с помощью платформы Microsoft Identity и не только.

Кому будет интересно?
- архитекторам, разработчикам и тестировщикам, которые используют .NET framework в своей работе;
- тем, кто хочет лучше разбираться в .NET, NET Core, C #, ASP.NET Core, Azure;
- как Junior-ам так и уверенным Senior-ам😉

Есть 3 варианта участия: FREE ONLINE, FULL ONLINE, OFFLINE & ONLINE.

Какой выбрать - решать только вам. На конференции будут внедрены все карантинные рекомендации. Количество мест "OFFLINE & ONLINE" ограничено.

Регистрируйтесь FREE ONLINE или используйте промокод:
fwdays_online - при покупке FULL ONLINE билета;
fwdays_offline - при покупке OFFLINE & ONLINE билета.

Детали по ссылке ➡️ https://bit.ly/3kn6MRt

Я много раз в своих выступлениях и тренингах затрагиваю тему различий между кодерами, разработчиками и инженерами. Такая же тройка есть и в области обеспечения качества: тестировщик, QC инженер и QA инженер. К сожалению, у нас в индустрии официальные позиции смазаны и зачастую не соответствуют реальности. На днях прочитал статью со схожими мыслями на эту тему. Ей я и хочу с вами поделиться. Приятного прочтения!

#реклама #java #митап

Java Meetup 29.07  | Ajax

Долучайтеся до офлайн Java Meetup від Ajax в Харкові!

📌 Вхід вільний, але необхідно попередньо зареєструватися:
https://forms.gle/hAE9cCzBKFfWW7E1A

Тема: досвід використання NATS у світі Java: переваги, недоліки, майбутнє.

RnD директор Олександр, відповідає в Ajax Systems за бекенд, серверну інфраструктуру та застосунки. З ним ми обговоримо NATS, детально розберемо, що таке messaging middleware, які проблеми вирішує. Розберемося  в альтернативах та як будувати складні системи на них. Заглибимося у кейс Ajax та наші архітектурні рішення на базі NATS.

Практична частина від Java Team Lead Євгена, що займається розробкою бекенду для наших B2B клієнтів - охоронних компаній. Обговоримо проблеми, з якими стикнулися в процесі розробки, який негативний досвід стрімінгу отримали? Поділимося, які переваги NATS відіграють ключову роль для Ajax, покажемо NATS у дії та розповімо про перформанс у нашому кейсі.

Після виступу нетворкінг зі спікерами та колегами.

Локація: Fabrika.space, Харків.
Реєстрація з 18:30.
Виступи з 19:00.
Нетворкінг з 21:00.

Важливо! На заході будуть дотримані всі карантинні обмеження.

🚨 Кількість місць обмежена.

Недавно я писал про участившиеся из-за удаленки случаи параллельной работы на несколько компаний. Эта тема вызвала много живых дискуссий как в комментариях к посту, так и в личке. Поэтому я решил поделиться своими мыслями, что с этим делать и как идентифицировать проблему.

Я сразу пропускаю жестяковые варианты из мира микроменеджмента наподобие «решите сами за разработчика сколько времени ему нужно на задачу» или «грузите всех задачами х2 и некогда будет голову поднять даже». Будем говорить об адекватных вариантах из мира командной работы, где команда сама оценивает свою работу и планирует итерации.

Начнём с наиболее простого способа. Я давно являюсь большим сторонником оценки задач на планировании итерации в идеальных часах с учетом фокус фактора и уровня синьорности конкретного разработчика. Это даёт возможность в конце итерации сравнить реальную работу конкретного человека относительно командных оценок.

Командные оценки лишены якорнинга, поэтому могут неплохо служить базисом для сравнения. Для подсчета потраченного на задачи времени не нужно даже логирования времени в таск менеджмент системе. Достаточно просуммировать командные оценки по доведённым до DONE задачам, сделанным конкретным человеком.

В результате, если предполагалось в плане, что человек сделает задач в итерации на 40 идеальных часов, а он регулярно делает на 20-25, то это отличный повод поговорить. Такой подсчёт не является метрикой, но даёт неплохую диагностику. В результате разбора ситуации вы можете узнать о факторах, замедляющих разработку, неучтенной работе или действительно выявить проблему с недоработкой.

Чтобы дополнить картину, можно использовать статистику контрибьюшена из вашей системы контроля версий, а также статистику прохождения ревью кода. Обычно эти инструменты добавляют полезных диагностических данных к разговору. Например, если синьор девелопер по 2 дня проходит ревью и при этом на нем в это время нет других задач, то это очень странно.

Вторым очень действенным способом является парная работа над задачей. В рамках парной работы гораздо тяжелее отвлекаться на сторонние вещи, а уж на вторую работу подавно. Ну и снова таки, можно на практике увидеть что мешает эффективно работать конкретному человеку. В рамках парных сессий можно выявить реально очень большие проблемы, которые никто открыто нигде не поднимал, даже на ретроспективе.

Ну и последним способом, самым правильным на мой взгляд, является вынесение проблемы на ретроспективу. Но тут нужно быть очень аккуратным. Ведь на ретроспективе нужно избегать обвинений и поиска виноватых, а в незрелой команде в это легко скатиться для такого рода проблем.

Надеюсь, описанные способы натолкнут вас на какие-то полезные мысли и принесут практическую пользу. Напоследок пара советов от капитана очевидность:

- любая работа в итерации должна делаться по задаче в таск менеджмент системе;
- поддержку лучше выделять на ротирующихся дежурных;
- митинги, отпуска, обучение и другие активности нужно учитывать в планировании;
- без адекватного Definition of Done сложно что-то вообще измерять.

​​Горячий летний сезон на рынке IT продолжается! Можно попробовать свои силы на собеседовании и получить $5000 онбординг бонус.

#реклама #jobs #java

📣📣📣 Java Hiring Week
⏰ 26-30 июля, 2021 | онлайн

Мы приглашаем Java разработчиков уровня Middle/Senior/Lead/Architect с опытом работы от 2 лет стать частью нашей команды экспертов EPAM Anywhere.

Пройди техническое интервью и в течение 48 часов получи предложение присоединиться к EPAM Anywhere и бонус до $5,000 USD!

Сумма бонуса фиксирована независимо от оклада.

Хочешь узнать больше? Заполни регистрационную форму и узнай о платформе EPAM Anywhere и Java Hiring Week!

📌Зарегистрироваться -> https://epa.ms/w0Mu3

​​Кратенько про большую часть трансформаций. :)

​​IT нынче очень популярное направление и здорово, что компании организуют долгосрочное обучение для начинающих по различным направлениям. Причём совершенно бесплатно!

#реклама #java

Java — один из популярнейших языков программирования. От программ для пылесоса и смартфона до серверных приложений в больших корпорациях - технологии Java есть практически везде.

Узнай больше о возможностях применения языка на онлайн-лекции «Зачем изучать Java и как делать это эффективно» - и создавай IT-решения в сфере fintech, big data и для других сфер бизнеса.

Когда: 28 июля в 16:00.
Где: на YouTube-канале NIX.
Спикер: Елена Хацько, Java Developer Lead в NIX.

В программе:
● Java: актуальность, перспективы и популярность направления;
● где и как используется Java;
● как проходит учеба в NIX и как попасть на бесплатную программу обучения по Java.

Присоединяйся по ссылке.

Для кого:
● студентам и выпускникам технических специальностей;
● начинающим разработчикам;
● всем желающим построить карьеру в IT.

Java — твой идеальный путь к успеху в IT!

​​​​Хайринг дни с крутыми бонусами проводят не только большие аутсорсеры, но и крутые продуктовые компании! Flo могу лично рекомендовать как отличное место работы, так как лично знаю их VP of Engineering и несколько команд по проведенным тренингам.

#реклама #jobs

Измени свою жизнь за выходные: пройди интервью, стань частью команды Flo, получи бонус 5000$ и перейди на Scala или Python! 🚀

31 июля компания Flo Health проведет онлайн hiring event для Senior Backend Engineers в офисы в Минске и Вильнюсе, с возможностью релокации в Литву.

Кандидатам с большим опытом работы с другими back-end языками программирования и заинтересованным в переходе на Scala/Python компания предложит обучение. Flo планирует переобучать инженеров с помощью курсов на внешних ресурсах, воркшопов с лидерами отрасли, а также менторства.

🔗 Ссылка на регистрацию https://boards.greenhouse.io/flohealth/jobs/4611459003?gh_src=tgxpinjection, если ты Senior #Scala Engineer или хочешь перейти на Scala.

🔗 Ссылка на регистрацию https://boards.greenhouse.io/flohealth/jobs/4611443003?gh_src=tgxpinjection, если ты Senior
#Python Engineer или хочешь перейти на Python.

Зарплата для Минска 3900-6000 € на руки, для Литвы 3000-4500 € на руки.

Для участия приглашаем Senior инженеров (6+ лет опыта на схожей позиции). По результатам ивента Flo предложит самым сильным кандидатам присоединиться к международной команде, которая каждый день помогает миллионам женщин во всем мире быть здоровыми и лучше понимать сигналы своего организма.

⏩Заполни регистрационную форму, ⏩ дождись подтверждения от рекрутера, ⏩ пройди интервью 31 июля (суббота, с 10:00 до 18:00) и ⏩ получи оффер в течение 24 часов!

Flo Health App, мобильное приложение №1 в сфере женского здоровья, которое выбирают более 190 миллионов женщин по всему миру и 41 миллионов активных пользователей в месяц. Команда более чем 100 опытных инженеров создает приложение для женского здоровья на основе искусственного интеллекта, применяя технологии машинного обучения, которые позволяют предоставлять точные прогнозы цикла и овуляции, а также персонализированную ленту материалов о здоровье, подобранные для каждой конкретной женщины на основании введенных симптомов и поставленных целей.

Для связи: @ali_aksandra

​​Образование - это всегда прекрасно! А ещё лучше, если оно бесплатное. Особенно когда ты только начинаешь карьеру в IT или активно развиваешься в ширину. Данный пост как раз об этом.

#реклама #образование

Чем больше ты знаешь и умеешь, тем больше ты стоишь. Но знания тоже стоят денег. Правда, из любого правила есть исключения.

Образовательная платформа GeekBrains открыла бесплатный (!!!) доступ к 40 своим курсам.
Это уникальный шанс получить новый навык, понять, нравится ли выбранная специальность, и решить, нужно ли продолжать по ней обучение.

GeekBrains предлагает курсы по шести востребованным направлениям:

- программирование: Git, Python, Java, С, C#;
- разработка игр: основы геймдева, дизайн, цифрового рисунка;
- маркетинг: Instagram, VK, WordPress, сторителлинг;
- аналитика: кластеры, машинное обучение, Data Science;
дизайн: Photoshop, Illustrator, Figma, дизайн интерьера;
- менеджмент: HR, продакт-, проджект-менеджмент.

Можете выбрать курс самостоятельно, а можете заполнить анкету и получить рекомендации от самой платформы. Регистрация на бесплатные курсы только до 31 июля, но проходить их можно в течение двух месяцев.

Времени не так много, начните обучение прямо сейчас: https://gb.ru/link/lijiFT

​​Пятница, она и в отпуске пятница! Поэтому картинка на злобу дня для поднятия настроения.

​​Пока нас не накрыло очередной волной карантина, есть шанс собраться на тематическую тусовку вживую. Этим шансом решили воспользоваться ребята из Simplesense и запланировали на 7 августа провести 6-ю конференцию из серии Simplicity Day: Inspect & Adapt.

Это будет настоящая живая офлайн конференция, максимально безопасная и уютная, где приглашенные эксперты и гости смогут поделиться своим опытом и тем, чему научились за время локдауна, обсудить прогнозы на ближайшее будущее, разные подходы и инструменты помогающие организациям, командам и лидерам адаптироваться к регулярно меняющемуся окружению и потребностям!

Среди спикеров конференции:

- Dave Snowden
- Артем Быковец
- Наталия Тренина
- Евгений Лабунский
- Сергей Семенов
- Zuzana “Zuzi” Šochová
- и другие эксперты.

В этот раз SMPL DAY обещает быть очень атмосферной:

- современная локация PMHUB с просторными террасами и видом на Печерск;
- интересные спикеры с живой подачей информации;
- вкусные кофебрейки и обеды;
- afterparty с коктейлями и stand-up шоу.

В конце дня, после докладов, ребята организуют уютную after party без потребности куда-то ехать, на открытых террасах локации. Будет возможность выпить по бокальчику чего-то вкусного, послушать музыку и stand-up шоу, а также обсудить инсайты за день!

Если вы ещё не купили билет, то можете воспользоваться промо кодом на 10% скидку: SMPLDayXPinjection.

#конференции #agile

Когда количество команд в компании, использующих схожую инфраструктуру для разработки, начинает расти, появляется идея построения единой инфраструктурной платформы. Для этого многие строят специальные инфраструктурные команды с фокусом на разработку платформы. Идея в целом неплохая, но есть несколько опасных ловушек, о которых нужно знать перед стартом реализации.

Первая ловушка называется «платформа ради платформы». В неё можно легко попасть на этапе построения отдельной команды. Платформа строится ради обеспечения нужд продуктовых команд и облегчения их работы. Если платформенная команда не вовлечена в продуктовую разработку, а приоритеты в бэклоге задач выставляет лидер этой команды, то фокус может легко уйти в сторону разработки крутой платформы или использования интересных технологий.

Чинится это как минимум двумя способами. Можно раздать представителей инфраструктурной команды в продуктовые команды на 30-50% времени, чтобы они в полях глубже проникались проблемами и понимали что реально нужно командам. Это также будет полезно в рамках развития DevOps культуры в компании. Альтернативным вариантом, или дополняющим, является управление приоритетами в бэклоге задач представителями продуктовых команд (лучше всего для данной роли подходят техлиды). Для этого они собираются на регулярные встречи, где обсуждают самые горячие проблемы и расставляют приоритеты на ближайшее время в разработке платформы.

Вторая ловушка называется «убивающая поддержка». Чем больше начинают использовать платформу, тем больше времени начинает забирать ее поддержка. Дефекты, мелкие улучшения, инциденты и другие виды запросов начинают сильно перегружать платформенную команду. Без четко организованных процессов и SLA недовольство продуктовых команд растёт и начинается противостояние «мы - они», которое к добру не приводит.

Лечится снова таки как минимум двумя способами. Во-первых, все компоненты платформы должны быть максимально задизайнены на самообслуживание (self-service). То есть, любые типовые задачи как выделение ресурсов, модификация конфигурации и т.д. должны быть доступны для выполнения продуктовыми командами. Для общих задач поддержки четко поставленный процесс и SLA. Во-вторых, на старте использования платформы каждая команда должна найти выделенного инфраструктурного инженера на одну или несколько команд, который закрывает для них все вопросы платформенной поддержки. Это может быть инженер из платформенной команды на % времени.

Третья ловушка называется «а нам этого не говорили». Любая платформа предполагает определённые правила использования и стиль работы. Если он никак не формализован, то люди начинают работать как им кажется правильным, со всеми вытекающими проблемами. Ситуация усугубляется, если на платформу загоняют насильно, без мотивации ее использовать, знаний и опыта в используемом технологическом стеке.

Лечится традиционно двумя способами. Во-первых, формализацией гайдлайнов по использованию всех компонентов платформы. Чем большее количество вопросов они покрывают, тем меньше граблей и шишек будут собирать продуктовые команды. Во-вторых, программы обучения, онбординга и менторства для начинающих работу на платформе команд. Это позволит им получить не только начальные теоретические знания, но и поддержку на время адаптации.

Ну и напоследок, самый главный совет: постоянно собирайте детальную обратную связь с продуктовых команд об их опыте работы на платформе. Это лучший источник для понимания текущей ситуации и потенциальных проблем.

Я уже писал о своей вере в то, что в ближайшем будущем AI инструменты позволят решать типовые задачи в разработке и нам не нужно будет такое количество просто кодеров. Будут востребованы люди, обладающие навыками построения архитектуры и дизайна, умеющие декомпозировать и описывать задачу от бизнес требований до типовых операций.

Что я подразумеваю под типовыми операциями? Выставить HTTP эндпоинт, добавить валидацию полей DTO, найти сущности по критерию в БД, передать данные в другой сервис по HTTP с обработкой ошибок, добавить поддержку circuit breaker с определёнными правилами, смержить два потока данных по определенным правилам, записать или вычитать данные из файла… И так далее. В типичном проекте именно такими задачами заняты разработчики на 95% времени.

И вот недавно Microsoft анонсировал первую публичную попытку предоставления такого сервиса для разработчиков: GitHub Copilot. Он работает в режиме подсказок в IDE по имеющемуся контексту (комментарии, сигнатура метода и т.д.), который авторы концепта назвали AI pair programming. Сервис постоянно улучшается благодаря обучению на новом коде в момент использования.

Я посмотрел несколько практических демок и концепция мне очень понравилась. Она имеет одно важное неочевидное преимущество: люди учатся формулировать, что именно они хотят сделать перед тем как сделать, и пытаются лучше декомпозировать свою задачу, чтобы получить полезные подсказки от сервиса. Уже ради этого стоит его попробовать.

Пока это выглядит лишь простенький первый шаг в автоматизации части работы разработчиков. Многие вопросы ещё не решены в принципе:

- как быть с приватностью кода, ведь сейчас он автоматом загружается в сервис;
- использование лицензированного кода в подсказках;
- более сложные по структуре задачи, выходящие за рамки одного метода, функции или класса.

Тем не менее, уже есть области, где сервис может быть очень полезен:

- изучение языка программирования или технологического стека;
- обучение грамотной декомпозиции задач;
- прототипирование новой функции системы.

Мне кажется, это однозначно начало интересной эры в IT.

Недавно в одной из Telegram групп поделились ссылкой на документ с хорошим описанием концепции сообщества практиков (community of practice). Там даётся детальное определение данного термина, рассматриваются основные критерии и ответы на ключевые вопросы. В конце можно найти список литературы для более глубокого изучения вопроса.

Со своего опыта скажу, что очень мало организаций имеют у себя настоящие полноценные сообщества практиков. Причина неудачных попыток в основном одна и та же. Взращивание такого сообщества требует больших усилий и времени, а также культивации определенной культуры и ценностей. А компании хотят быстро и с минимальными усилиями. Поэтому выделяют бюджет, выбирают ответственного и строят план на квартал-год по внедрению. Результат почти всегда предсказуем. :(

Большое сообщество практиков вне организаций создать ещё сложнее. Это требует много энтузиазма и энергии от лидеров сообщества, а также продуманную модель вовлечённости участников. Иначе можно получить очень хрупкое псевдо-сообщество, которое разваливается как только у лидера заканчивается к нему интерес. В Украине я знаю один очень классный пример настоящего сообщества практиков - UkrOps. Прям вот по всем канонам. Если вы знаете ещё примеры настоящих сообществ практиков, поделитесь в комментариях.

​​Запоздавший пятничный пост на топовую тему обсуждения этой недели. :)

Летом что-то очень туго движется чтение книг. Но все таки я добавил в копилку прочитанных очередную техническую: «Istio: Up and Running». Давно была у меня в списке. Тема хорошо знакомая, но хотел структурировать знания и копнуть чуть глубже в основы.

Это тот редкий случай, когда книга не понравилась от слова совсем. Вот почему:

- Структура очень плохо продумана для восприятия материала. Большая часть книг серии up and running движутся по практическим задачам, постепенно раскрывая материал все глубже. Тут же накидывается на читателя куча теории разной глубины без мотивации по решению конкретной прикладной задачи.
- Многие из упоминаемых технологий уже устаревшие. Например, Helm 2 с Tiller и сам Istio в многокомпонентном исполнении.
- Начало про мотивацию использования Istio чересчур сильно разжевана, зато потом реально важным темам уделяется по полстраницы и приходится лезть за деталями в интернет.
- Постоянно упоминается о потенциальной работе Istio не на K8S, но потом все сводится к работе с K8S.
- Примеры на уровне статьи в интернете и демо приложения самого Istio.

Из плюсов книги отмечу разве что наличие теоретических вводных по каждой теме. Например, об авторизации и аутентификации для главы про mTLS.

Хочу добавить, что после прочтения книги появилась ещё большая уверенность в том, что Istio для большинства команд без глубокого понимания K8S и сетевого взаимодействия принесёт только боль и страдание. Такое количество новых точек отказа и неожиданного поведения в рантайме! Причём, появляется много новых способов тотально выстрелить себе в ногу и положить кучу сервисов…

Я бы рекомендовал использовать, только если есть уверенность в экспертности инфраструктурных инженеров и соответствующий опыт. Или смотреть на более простые решения для конкретных задач.

#книги #books #kubernetes

Давненько я не анонсировал никаких интересных мероприятий. 31 августа, в последний день лета, компания Yalantis запланировала провести свой первый DevOps митап. В программе два доклада о связи DevOps с архитектурой и миграции всего на EKS. Участие бесплатное, онлайн формат. Начало в 19:00 после рабочего дня. Подробности и регистрация по ссылке ниже.

#devops #kubernetes #архитектура #митап

https://dou.ua/calendar/39382/

Я только на этой неделе случайно натолкнулся на инициативу Agile 2, хотя она стартовала в 2020 году. Ценности и принципы нового движения стали ещё более обобщенные в стиле «за все хорошее и против всего плохого». Ждём первой методологии под сертификацию настоящих agile2-истов. Простите, фреймворк конечно же, а не методологию. Кодовое название можно взять НДНБ (нормально делай - нормально будет). :)

#agile

https://agile2.net/agile-2/the-values-and-principles-of-agile-2/

Пришла осень и активизировались организаторы образовательных мероприятий. Жаль только, что в офлайн формат мало кто пока рискует возвращаться. Хочу поделиться парочкой интересных анонсов.

Cloud Builders Community приглашает на DevOps Build-up, который пройдет 9 cентября. Участие онлайн, бесплатно. Язык докладов английский.

В программе доклады про использование Terraform/Ansible для управления большими кластерами в облаках и организации canary deployments. Также участников ждут два fireside чата про DevOps автоматизацию и как в GitLab с культурой ремоут поддерживают ментальное здоровье. Даже удивительно, что обошли стороной K8S. :) Докладчики из Oracle, Uber, Intellias и GitLab. Так что будет весьма разнообразно и интересно.

16 сентября компания Luxoft проведёт онлайн Java Meetup. В программе доклады про cloud-native разработку с MicroProfile и новый подход к многопоточности в Java с Project Loom. Докладчики из IBM и Luxoft.

Ссылки на детали и регистрацию ⬇️

#java #митап #devops

В дополнение к вчерашним анонсам митапов хочу добавить еще один. Многие из вас с переходом в онлайн начали использовать сервис онлайн-досок Miro. А вот интересно, как обстоят дела в команде разработки Miro. Чтобы осветить эту тему, ребята совместно с JUG.RU проводят 8 сентября онлайн митап.

В программе интересные доклады про процесс онбординга в компании, организацию регулярных частых релизов и использовании в Java коде подхода с fluent setters. После докладов состоится круглый стол, чтобы ответить на вопросы участников о специфике разработки в Miro.

Начало в 18:00, участие бесплатное по предварительной регистрации.

#митап

https://bit.ly/3BJttET