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

Мы знаем, что у многих есть проблема с добавлением события себе в календарь. Мы проверили ещё раз и выяснили, что добавить себе событие в мобильном приложении календаря невозможно - ни на 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)

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