Добавление ивента в календарь

Мы знаем, что у многих есть проблема с добавлением события себе в календарь. Мы проверили ещё раз и выяснили, что добавить себе событие в мобильном приложении календаря невозможно - ни на Android, ни на IOS. Гугл календарь не принимает свои же созданные события 😔 Это выглядит как системная ошибка на стороне сервиса, к сожалению, мы ничего не можем с этим сделать. Тут тоже про это писали https://stackoverflow.com/questions/63886313/google-calendar-event-link-not-opening-google-calendar-app-event-creation-with-d

Поэтому пока мы предлагаем следующее:

Пожалуйста, добавляйте себе события в календарь через браузер. Там все отлично работает🙌.  А мы займёмся поиском вариантов как и где ещё можно организовать регистрацию и напоминая о наших событиях с большим удобством и надёжностью

На занятии курса [Технический Лидер] один из участников задал вопрос – “Допустим, выкатили на прод версию с ошибкой и поломали всю систему микросервисов. Быстро пофиксить не удается. Как провести откат системы к работающему состоянию?” Тема интересная и на занятии мы ее рассмотрели подробно. Приводим коротко спектр доступных опций.

5 сценариев отката неудачного релиза

Когда можем себе позволить downtime:

1️⃣Сценарий – нет ни документации, ни версионирования, ни плана 😱. Придется собрать лидов и сеньоров всех команд, ответственных за неисправные сервисы. Вместе разобрать логи ошибок, локализовать их в каждом микросервисе и откатить до рабочего состояния БД. Вариант только для экстренных случаев, требует несколько часов совместных титанических усилий.

2️⃣Сценарий – есть скрипты Liquibase / Flyway, есть версионирование структуры базы. Команда каждого микросервиса отдельно от других откатывает код до старой версии. Если в процессе миграции были объемные изменения данных – в хранимой процедуре должен быть подготовлен скрипт, который производит миграцию в обратную сторону. Такой вариант занимает уже полчаса-час.

Когда нужно без downtime:

3️⃣Сценарий – запретить изменения в базу, но оставить доступ на чтение. Пользователи не могут полноценно пользоваться сервисами, но могут, например, посмотреть отчет за какой-то период. Для этого варианта нужен подготовленный фронтенд с feature flags. С клиента на бэкенд будут приходить только select, но не update. В это время можно спокойно (относительно) реализовать один из предыдущих сценариев.

4️⃣Сценарий – каждая команда делает релизы независимо друг от друга и есть реестр версий каждого сервиса. В таком случае, через средства автоматизации весь прод откатывается к последнему чекпоинту, когда комбинация микросервисов с разными версиями работала. Каждый микросервис, который обновился, откатывается до нужной версии независимо от других. За такой реестр должен отвечать кто-то над всеми командами разработки – архитектор или delivery-менеджер.

5️⃣Сценарий – в релизе сложные изменения в большой системе. Пример: меняем KV-базу на реляционную. Параллельно работают два варианта кода – со старой базой и с новой. В старую базу добавляется поле “переведено в новую БД”. Все апдейты, которые попадают в старую базу, дублируются в новую и, когда это происходит, в старой БД меняется значение этого “feature flag” каждой записи. Если с новой версией что-то не так – старая продолжает работать.

А с какими сценариями сталкивались вы? Делитесь в комментариях 👇

👋 Всем привет!

13 августа в 20.00 GMT+3 пройдет последний летний Архитектурный Треп прежде чем мы уйдем на небольшие каникулы до сентября 🤗

Завтра будем общаться на тему Шаблонов Проектирования. Обсудим:

• Наиболее важные шаблоны проектирования, почему?
• Ваши любимые шаблоны проектирования и ситуации их применения?
• Примеры реальных проектов, где применение шаблонов проектирования существенно улучшило архитектуру и качество кода, а где существенно ухудшило
• Ошибки при использовании шаблонов проектирования, как избежать?

Модерировать будет Сергей Русак. Задать свой вопрос и зарегестрироваться можно на сайте

До завтра 🙌

🎙Уже завтра пройдет первый круглый стол, посвященный теме развития сеньора в технического лидера. Мы разберем 5 реальных кейсов - как складывается карьерный путь у пяти инженеров в ИТ индустрии (спойлер: очень по разному)

Вопросы из регистраций, которые разберем:

▪️ Кто такой техлид и как понять, что ты уже он?
▪️ В какой момент на проекте возникает необходимость в техлиде?
▪️ Как продать себе как техлида?
▪️ Как в идеальном мире могут ужиться в одной небольшой команде техлид с тимлидом? Как им очертить границы и разделить ответственности?
▪️Как развиваться, если на текущем месте работы задач полно, но они не подходят для практики развития техлда?
▪️ А нужны ли техлиды? Глядя на вакансии складывается впечатление, что все должности техлидов заняты и нужны просто разработчики.

Успевайте еще сегодня прислать свой вопрос в форме регистрации, чтобы мы успели включить его в общее обсуждение. Завтра будет горячо🔥. До встречи!

Вот и все! Последняя часть статьи От хаоса к стандарту: создание универсального шаблона микросервисов уже в нашем LinkedIn.

❗️Кстати, завтра автор статьи Павел Макул будет одним из участников круглого стола про путь развития из сеньоров в техлиды. Приходите и задавайте свои вопросы!

По просьбам участников нашего коммьюнити мы также опубликовали все части статьи в нашем блоге. Если по каким-то причинам вы не могли прочитать эту историю в LinkedIn – найти ее можно по вот этой ссылке.

👉 Для тех, кто пропустил, – Павел, выпускник курса [Технический Лидер], поделился своей историей, как он пришел в команду обычным Senior BE-разработчиком, увидел много технических проблем и инициировал масштабный процесс по их исправлению. От разбития существующей SOA-архитектуры по DDD до серии Tech Talks и развития культуры разработки в компании.

Мы уже писали, что август будет горячий месяц, посвященный разнообразным дискуссиям, поэтому 22 августа приглашаем вас на круглый стол с архитекторами.

👥 Участвовать будут:

Максим Аршинов, Solution Architect в EPAM Spain
Сергей Бабицкий, Solutions Architect, TOGAF Certified
Антон Дворников, Principal Solution Architect, SEI Certified

🎙 Ведущий: Павел Вейник, Solution Architect, Staff Engineer

Участники поделятся своими исторями профессионального развития и ответят на вопросы:

‣ Какие знания и навыки оказались наиболее важными для перехода от инженера к роли архитектора?
‣ Какие технические навыки являются наиболее критичными для роли архитектора в ИТ?
‣ Как принимать решения, последствия которых будут влиять еще через год или два?
‣ С какими вызовами и проблемами ежедневно сталкивается архитектор?
‣ Как архитектор влияет на формирование культуры в команде и в компании?

🔗 Узнать подробнее и зарегистрироваться

🚀 Через час стартуем Карьерный навигатор в формате круглого стола

Путь развития из Senior в Techlead: живой опыт пяти инженеров

Присоединяйтесь

Друзья! Вчера прошел Карьерный навигатор в формате круглого стола – Путь развития из Senior в Techlead: живой опыт инженеров.

🎬 Запись уже на нашем YouTube-канале. Приятного просмотра!

Получилось увлекательное обсуждение. Участники поделились, как им удалось стать техлидами, с какими проблемами пришлось столкнуться, что нужно для роста выше уровня senior, и как в этом помогает курс [Технический лидер] 😉.

К сожалению, не успели ответить на все вопросы, заданные при регистрации. Но мы обещали ответить на них – значит ответим, stay tuned!

Обязанности, долгосрочные цели, зарплата – как техлиду договариваться о повышении?

Это еще одна крайне интересная тема, которую подняли на занятии курса [Технический Лидер]. Делимся результатами обсуждения с вами!

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

В таких инициативах, как и в самой должности техлида, всегда много нюансов. Вот четыре главных вопроса, которые помогут очертить границы:

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

🚧 Какие ограничения? Бюджет, ресурсы, люди, сроки. Команда сеньоров с миллиардом долларов добьются совсем других результатов, чем два мидла со стареньким сервером. В больших организациях бывает так, что о работе никто не должен знать, пока не будет, что показать.

🗣 Какие у меня полномочия? Могу ли я нанимать/увольнять людей? Нужно ли мне договариваться со всеми самостоятельно или я могу продавливать какие-то решения от имени, например, CEO?

💰 Что я за это получу? Это абсолютно нормальный вопрос, которого адекватный руководитель вполне ожидает. Больше зарплата, выше грейд, одноразовый бонус – об этом нужно договориться заранее и договориться четко (а еще лучше где-то зафиксировать). А то может получиться “ну ты работай хорошо – получишь премию”.

Крайне важное условие, которое обязательно нужно обсудить заранее, – порядок отчетности. Это будут 1-1 митинги с руководителем раз в месяц или еженедельные репорты? Что это дает:

🔺 Степень интереса и вовлеченности руководителя в задачу.
🔺 Возможность сделать свою работу и промежуточные результаты заметными для руководства.
🔺 Площадку для того, чтобы передоговориться если, например, в процессе оказалось, что задача не на 3 месяца, а на 3 года.

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

✨ Круглый стол с Архитекторами уже на этой неделе

В этот четверг четыре опытных архитектора соберутся вместе, чтобы рассказать о своем пути от роли разработчика до позиции Solution Architect, поделятся какие проекты и задачи больше всего способствовали профессиональному росту, какие hard и soft скиллы must have, как развивать стратегическое мышление и многое другое.

👥 Участники:

Антон Норко, Solution Architect
Максим Аршинов, Solution Architect в EPAM Spain
Сергей Бабицкий, Solutions Architect, TOGAF Certified
Антон Дворников, Principal Solution Architect, SEI Certified

🎙 Ведущий: Павел Вейник, Solution Architect, Staff Engineer

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

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

❓Как инженеру дорасти до СTO?
Попробуем разобраться на круглом столе 29.08

👥 Участники:

Юрий Морозов, CTO в Neocode
Сергей Зотов, CTO в SWAG42
Юрий Полосов, CTO стартапа B2B2C Gambling Platform
Илья Шкиренко, Co-founder & CTO в Platto и Interaksi, Fractional CTO и Tech Advisor, ментор стартапов в ULTRA.VC и Founder Institute

🎙 Ведущий: Павел Вейник, Solution Architect, Staff Engineer

Вопросы для обсуждения:

◆ Кто такой CTO и чем эта роль отличается от других технических ролей в ИТ компании?
◆ Какая мотивация становится CTO?
◆ Как изменить мышление с «выполнения задач» на «стратегическое руководство»?
◆ Как управлять командой: найм, онбординг, процессы, увольнения.
◆ Отношения с CEO и другим топ менеджерами.
◆ Баланс между техническими знаниями и управленческими обязанностями на позиции CTO.
◆ Частые ошибки инженеров, стремящихся стать CTO

🔗 Узнать подробнее и зарегистрироваться

😇 Через час начинаем круглый стол с Архитекторами. Успевайте присоединиться. Подробнее

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

🎥 Запись ивента уже на нашем YouTube-канале. Приятного просмотра!

А еще участники круглого стола поделились большим списком литературы и полезных ресурсов для тех, кто хочет стать архитектором. А мы делимся этим списком с вами:

The Goal: A Process of Ongoing Improvement
Impact Mapping
Оргуправленческое мышление: идеология, методология, технология
Software Architecture in Practice, 3rd Edition
Time Management for System Administrators
A Minimal Approach to Architecture as Code: Documenting the Modern Way
EventStorming
Шкура на кону. Скрытые асимметрии в повседневной жизни
Требования для программного обеспечения: рекомендации по сбору и документированию
System Design Interview – An insider's guide
System Design Interview – An Insider's Guide: Volume 2
Основы ТРИЗ: Теория решения изобретательских задач

С кем техлиду сверять правильность архитектурных решений?

Самый очевидный ответ на этот вопрос – обратиться за ревью к более опытным коллегам. Но техлид очень часто оказывается в положении “самого умного человека в комнате”. Особенно в небольших компаниях. В таком случае есть 4 пути:

1️⃣ Не обязательно искать совета только у более опытных инженеров. Коллеги с сопоставимым и даже меньшим опытом, вероятно, работали с другими технологиями и сталкивались с другими проблемами, а потому могут взглянуть на текущую задачу под немного другим углом.

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

2️⃣ Если в команде нет эксперта по конкретному вопросу, имеет смысл привлечь внешнего архитектора для консультации или аудита. Такой человек сможет непредвзято посмотреть на техническое решение.

Привлечь внешнего эксперта можно не всегда – есть NDA, риски утечки и другие издержки. Так что такое решение 100% нужно согласовывать с руководством.

3️⃣ Найти ментора. Этот путь похож на предыдущий, и риски те же. Отличие в том, что с ментором вы сможете консультироваться более регулярно и по разным вопросам, а не только в рамках одного решения.

4️⃣ Прийти на курс [Технический Лидер] и попасть в коллектив senior+ инженеров, которые сталкиваются с похожими проблемами. Отдельные аспекты своих архитектурных решений вы сможете обсудить на занятиях с другими участниками курса и преподавателем.

А пакет Architect включает в себя несколько сессий архитектурного консультирования с Павлом Вейником общей длительностью 5 часов.

❗️ Важно помнить

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

Всем продуктивного понедельника! 🧑‍💻

В четверг 29 августа мы проведем еще один круглый стол. В этот раз мы пригласили 4 действующих СТО, чтобы поговорить об этой роли и том, как инженеру дорасти до СТО.

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

🔗 Регистрируйтесь и задавайте свои вопросы, будет интересно!

👋 Привет! Во время круглого стола с архитекторами осталось много вопросов, которые не успели обсудить. После мероприятия на них ответили Сергей Бабицкий, Антон Дворников и Максим Аршинов.

Публикуем первую часть ответов:

Хочу двигаться дальше, но семья не готова к снижению зарплаты, пока я переучиваюсь с фронта. Какой дадите совет?

Сергей: Учиться параллельно, насколько это возможно. Понимаю, что это может быть в ущерб времени, проведенному с семьей. Лично я столкнулся с похожей ситуацией и научился вставать каждый день в 4:30 утра, чтобы с 4:30 до 6:30 изучать книги. Это был долгий и трудный период, но другого выхода я не видел. К сожалению, в такой ситуации кто-то должен пожертвовать чем-то — либо вы, либо ваша семья. Выбор непростой, но такой путь может принести свои плоды.

Максим: Идти во фронтенд-архитекторы.

Как быстро вырасти после двухлетнего перерыва (учеба на магистратуре) с позиции мидл?

Сергей: Рекомендую активно читать книги, проходить онлайн-курсы, смотреть образовательные видео на YouTube и самое главное — начинать что-то делать на практике, например, работать над пет-проектом. Также полезно записывать незнакомые термины и понятия в блокнот и не вычеркивать их, пока вы не узнаете о них всё необходимое.

Максим: Брать на себя ответственность и читать книжки.

Как вообще эта идея пришла в голову "Мне нужно стать архитектором", помните? Или "Как-то само"? 😃

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

Как рисковать, пробуя что-то новое, и не сталкиваться с проблемами спустя год-два?

Сергей: Важно заранее осознать и принять все возможные последствия вашего решения. Если вы готовы к этим последствиям и понимаете их, то можете смело идти на риск.

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

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

В чем ключевое отличие архитектора от сеньора?

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

Максим: Это другая работа. Архитектор знает больше, чем сеньор. И знает другие вещи.

Мы к вам с очередным анонсом! 🔥

В следующую среду, 4 сентября, проведем еще один круглый стол. Мы уже поговорили с техлидами и архитекторами, вот вот пообщаемся с СТО, но как будто бы упустили что-то очень важное. Пора исправляться!

В этот раз спустимся на ступеньку ниже и обсудим позицию senior разработчика: в чем отличия сеньора от мидла, какие задачи и проблемы решает senior, какие навыки и знания нужны, чтобы считать себя сеньором, и самое важное – где их взять.

Участники:

Алексей Залётов, Senior Software Engineer
Нафиса Юлдашева, Senior Python Backend Developer
Алексей Гурьянчик, Senior Java Developer

Ведущая:

Светлана Семёнова, Senior Unity Developer

📆 4 сентября
🕗 20:00 (GMT+3)

🔗 Регистрируйтесь и задавайте свои вопросы!

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

🔗 Регистрируйтесь и оставляйте вопросы в форме!

Как переходить на событийную архитектуру (подход), когда все на RESTах и «по-старинке»?

Сергей: Это непростой процесс, который требует готовности и согласия всех участников на всех уровнях. Важно, чтобы все понимали как преимущества, так и недостатки такого подхода. У каждой компании и проекта обычно свой путь перехода, и здесь нет универсального рецепта.

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

Сергей: В целом, это так, но лишь частично в отношении ответственности. Избежать ответственности не получится. Если вы не готовы принимать на себя ответственность, то эта роль, возможно, не для вас.

Какие отношения складываются между архитекторами и разработчиками?

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

Сложно ли найти/менять работу? Вакансий в открытом доступе мало, как происходит поиск?

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

Максим: Да, сложно. Лучше искать по знакомству. Вакансий меньше, но зато они более интересные и денежные.

Похоже, что эта работа в основном про System Design + soft skills (поправьте, если не так). Подразумевается, что hard skills к моменту перехода на данную должность уже на высоком уровне, но есть ли что-то, на что нужно обратить особое внимание?

Сергей: Hard skills всё еще должны быть на хорошем уровне. Без них и способности быстро учиться, вам будет очень, если не невероятно, сложно справляться с задачами на этой позиции.

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

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

Как набирать знания о сложных распределенных системах и расти, если в повседневной работе этого не касаешься?

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

Всем хорошей пятницы! (желательно без релизов 😉)

Вчера прошел супер интересный круглый стол с CTO. Беседа получилась очень живой и увлекательной – участники разговаривали на час больше, чем планировали.

Запись ивента уже на нашем YouTube. Приятного просмотра!

Спасибо Юрию Морозову за ответы на часть вопросов, которые не успели обсудить!

Стал недавно CTO, какие шаги:

- Узнать структуру подчинения и отчетности.
- Забрать на себя всю инфраструктуру, платные подписки итд. Если передачи знаний не было - проще всего это делать через счета в бухгалтерии. Поверьте, нет более лучшего способа реверс-инжиниринга, чем движение денег со счетов компании )
- Проверить бекапы :)
- Первое время - только наблюдать (не менять, не увольнять, никаких необычных движений).

Конфликт - способ решения проблемы?

Как ни странно, да.
Рекомендую "Пять пороков команды" Ленсиони и базовые курсы по конфликтологии (есть бесплатные на ютубе)

Как думаете СТО должен управлять процессом разработки?

Зависит от размера компании и уровня лидов.
Если есть, на кого смело можно делегировать - делегируйте, но будьте всегда готовы вмешаться и предложить свое решение.

Стартап 40-50 тел. Кого ставить главным?

Прекратите называть живых еще людей телами.

На каких скиллах сфокусироваться?

Sometimes the only choices you have are bad ones. But you still have to choose. (c) Doctor Who

Дает ли вам эта должность дозу дофамина?

Дофамина - нет.

Людей терзает необъятность вечности, и потому мы задаемся вопросом: услышат ли потомки о наших деяниях? Будут ли помнить наши имена, когда мы уйдём, и захотят ли знать, какими мы были, как храбро мы сражались, как отчаянно мы любили?..

Как управлять несколькими командами/департаментами?

У вас теперь одна команда - ваши лиды. Ими и управляйте.

Можно ли вырасти в CTO без бекграунда разработчика?

Думаю, можно, если иметь хороший общий технический бекграунд (саппорт, девопс).
Впрочем, там тоже кодики пишут, так что вопрос терминологии.

Если ваш вопрос остался нераскрытым – задавайте в комментариях, пообщаемся!