🚨 Напоминаем: Чёрная пятница в OTUS уже в разгаре!

Скидки до 15% на все курсы: программирование, машинное обучение, аналитика и другие востребованные digital-навыки.

Это отличная возможность вложить в себя и прокачать навыки, о которых давно мечтали.

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

😍 Новая неделя — новые возможности!

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

🦉 Что вас ждет:

Уникальные вебинары, которые помогут освоить новые навыки
Лекции от топовых экспертов индустрии
Возможность пообщаться с единомышленниками и задать вопросы профессионалам

🔗 Регистрация уже открыта!

#anons

Последний звонок: старт уже 30 ноября 🔔

В OTUS запускаются три востребованные программы специализации, которые помогут вам освоить новую профессию и выйти на карьерный трек. И теперь на этих программах работает Карьерный центр OTUS!

Мы помогаем:
✅ Составить профессиональное резюме.
✅ Подготовиться к собеседованию.
✅ Передать резюме в компании-партнеры, чтобы вы быстрее нашли работу.

Стартующие программы:
Специализация Python
Специализация Machine Learning
Специализация Системный аналитик

⏺ Запишитесь и начните карьеру с поддержкой профессионалов!

#Python #MachineLearning #аналитик #последний_шанс

Всем привет!
🤟 Сегодня в гостях у OTUS Дмитрий Панкрашов — Python Backend Developer в Сбере, автор канала DevIO | IT | GameDev и преподаватель курса “Python Developer. Professional” в IT в OTUS.
Дмитрий поделился личным опытом проектирования и внедрения системы автоматизации без четкого ТЗ и менторской поддержки, с какими ошибками он столкнулся в процессе и какие выводы сделал.

Обычно дети думают, что знают всё лучше родителей, а начинающие разработчики в этом смысле чем‑то похожи на детей. Они всегда всё знают лучше, чем их старшие коллеги. Но иногда бывает так, что джун на первой работе получает задачу спроектировать и реализовать систему целиком, и тогда его уверенность в том, что он точно знает, как и что надо делать, укрепляется, потому что он‑то сделал систему, а остальные только и могут рассказывать, что «хорошо делать хорошо, а плохо делать — плохо».

Когда‑то и я таким был. Устроившись на должность разработчика к подведу местного МинОбра (образования, не обороны!), мне поручили реализовать и внедрить в работу систему, рассчитанную на массовое использование. Система предназначалась для автоматизации процесса аттестации педагогических работников. Сотрудники школ, детских садов и других организаций могут подать заявление на присвоение категории, которая дает некоторую прибавку к зарплате. Заявление сопровождается отправкой портфолио, содержащим подтверждающие документы. Портфолио рассматривают эксперты, по результатам принимается решение о присвоении, либо отказе в присвоении категории.

Процесс, как водится, был «в бумаге» и требовалось перенести его и все данные «в компьютер». Технических заданий, дизайн‑документов, UML‑диаграмм, и прочего аналитического добра у меня, конечно же, не было. Были только утвержденные формы портфолио, и объяснения, как оно работает «на пальцах».
Как вы понимаете, этот текст не об успешном успехе и результатах внедрения, превосходящих все самые смелые ожидания, а о допущенных ошибках.

Ошибки — важная часть процесса обучения. Можно заучить «как правильно», и не понимать, почему же правильно именно так, а не по‑другому. А может, «правильно» делать надо не во всех случаях? А где можно срезать углы, и чем это черевато?

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

Ошибки проектирования

Все слышали поговорку «Семь раз отмерь — один раз отрежь»? Она в том числе и про проектирование.

Ошибка 1️⃣- Не проектировать вообще.
Максимум, что было у меня в голове после изучения бумажной формы портфолио — примерная концепция пользовательского интерфейса с деревом папок‑критериев оценки. На тот момент я мог еще нарисовать диаграмму потоков данных (по сути, схему базы данных, с таблицами и отношениями между ними), но, как я посчитал, без этого можно обойтись. Да и вообще, что там программировать?!

Ошибка 2️⃣-Проектировать только техническое решение.
Как показала практика, учитывать взаимодействие «пользователь — сотрудник — проверяющий», особенно, если оно может происходить в обход системы, все же нужно. Хотя бы для планирования возможных «дырок в заборе».

Ошибка 3️⃣- Я вообще‑то разработчик, а не эти ваши…
Любой разработчик минимально тестирует то, что пишет. Но «протыкал кнопки по предполагаемому user‑flow» и реальное использование — разные вещи, как выяснилось позже.

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

➡️ В следующем посте поговорим про технические ошибки.

#expert

Погружаемся в мир Linux

Хотите освоить установку Linux с флешки, но не знаете, с чего начать? Или вам кажется, что это для «гуру технологий»? 🤔
Мы уверяем: это проще, чем вы думаете, и абсолютно реально!

В нашей новой статье мы собрали всё, что нужно знать для подготовки и установки:
✨ Как выбрать дистрибутив
✨ Как создать загрузочную флешку
✨ Что важно знать перед установкой

👉 Читайте статью

#Otus #Linux

Как свести к минимуму ошибки в планировании и процессах?

Один из способов профилактики ошибок – постмортемы.

❕ В 19:00 на нашем открытом вебинаре «Как провести постмортем, чтобы не повторять ошибок?» вы узнаете:
Когда проводить постмортемы и как определить ситуации, заслуживающие анализа
Как анализировать инцидент: от описания – до выявления корневых причин и выработки решений
Как обсуждать сложные инциденты конструктивно: без конфликтов и недоверия

Будет интересно: CTO, COO, руководителям проектов, проект-менеджерам, тимлидам, руководителям и специалистам службы поддержки.

Вебинар проведёт Галина Баранова, СОО в Altasales

Бонус ❗️Всем участникам – скидка 5% на любой курс OTUS и полезный гайд

📹 Присоединиться к трансляции

#вебинар

Хотите повысить стратегическую ценность HR-процессов?

👩‍💻Присоединяйтесь в 19:00 к открытому вебинару «Как интегрировать HR-задачи в бизнес-цели компании?», на котором вы:

⭐️Научитесь анализировать инициативы с точки зрения пользы для бизнеса
⭐️Сможете оценивать действия HR на разных этапах работы с персоналом
⭐️Сможете в краткосрочной перспективе повлиять на стратегическую ценность HR-процессов

Вебинар проведёт Ксения Малова, руководитель академии TECH-RECRUITER.

Бонус❗️Всем участникам – скидка 5% на любой курс OTUS и полезный гайд.

📹 Присоединиться к трансляции

#вебинар

Типичный рабочий день айтишника на удалёнке 🤣🤣🤣

Как у вас сегодня с рабочим настроением?

Всем привет!

Сегодня пост-продолжение рассказа Дмитрия Панкрашова (Python Backend Developer в Сбере, автор канала DevIO | IT | GameDev) про опыт проектирования и внедрения системы автоматизации.

Первая часть

Самое вкусное и интересное — технические ошибки. Именно они во многом определили для меня отношение к этому проекту, как к неудачному. С одной стороны, мне можно и посочувствовать. Что я знал и умел на тот момент? И указать на ошибки было, в общем‑то, некому. С другой стороны, наделавшись велосипедов, столкнувшись с последствиями принятых мной решений, я могу проще относиться к начинающим разработчикам, которые точно знают, как надо. Потому что помню, как сам таким был.

Ошибка 1️⃣- Хранить файлы в базе данных
Как вам идея? Почему‑то мне показалось, что нет особой разницы между хранением на диске и в базе. В базе даже поудобнее, сразу связи видно, а на диске — вдруг чего где потеряется или затрётся? Загружаемые файлы, конечно, были ограничены по размеру. Сначала это было ограничение в 100Мб, потом приняли решение ограничить размер одного файла до 1Мб, но не ограничивать количество файлов. И что же стали делать люди, которым нужно отправить 100-страничный скан рукописных тетрадей? Конечно же, паковать все в архивы, с разбиением на тома. 300 томов по 1Мб, да еще и загружать это полдня, стараясь не пропустить том, и не загрузить одно и то же два раза (потом же не откроется ничего). Гвозди из этих людей можно делать! Но вернемся к базам. Хранить файлы в базе — решение плохое, в том числе и потому, что файл будет вычитан куда? Правильно. В память. А убирается он кем? Правильно. Сборщиком мусора. В результате на ровном месте получили тормозной и падающий по непонятным причинам хайлоад. Вот надо оно было?

Ошибка 2️⃣- Не учитывать поток пользователей
Сколько RPS (запросов в секунду) выдержит ваш сервис? А как вы это посчитали? Я был ответил — не знаю, никак не считал. Придут пользователи — разберемся. Пользователи пошли — начались ошибки. Тратя время на борьбу с ними, я все никак не мог прийти к мысли — а ведь можно было взять статистику за предыдущие годы и посчитать распределение аттестуемых по месяцам! В RPS это, конечно, никак не пересчитывается, но понять, даже примерно, к чему готовиться, и проверить приложение под нагрузкой перед его релизом возможность все же была.

Ошибка 3️⃣- Не собирать ошибки и метрики производительности
Это сейчас я знаю, что такое Sentry, ELK, Jaeger и т. д., а в то время анализ ограничивался постулатом «раз не пишут, значит, и проблем нет». А если проблемы были — сначала нужно было ошибку воспроизвести, потом исправить, и потом воспроизвести еще раз, чтобы провалидировать ее исправление. А уж про метрики производительности говорить даже не буду. До сих пор никто не знает, сколько там операции с базой времени занимают.

Ошибка 4️⃣- Бэкапы
Классика. Ситуация: в 2 часа ночи вспомнил, что обещал с утра сделать фичу. Естественно, забыл про обещание напрочь. Выхода нет — надо делать, раз обещал. И что‑то в систему войти не получается, сейчас себе в базе пароль поменяю. UPDATE users set password = «mYp@$$w0rd»; Поменял, отлично, работаем. С утра звонок — люди не могут войти в систему. Ну я‑то вхожу, вот смотрите, набираю mYp@$$W0rd, и я внутри. И только потом дошло, что кто‑то забыл написать WHERE id = 123. Мем смешной, ситуация страшная, да. Но ничего страшного по итогу не случилось, все, кто хотел, сбросили себе пароль через почту, а меня попросили так больше не делать. А был бы бэкап — можно было бы восстановиться, пусть даже перенося пароли из другой БД скриптом.

Описанное выше — далеко не всё, но самое яркое и запоминающееся. В свое оправдание говорить ничего не буду, но опыт был полезным и позволил изменить свое отношение к работе — в частности, научиться рефлексировать и задаваться вопросом «а не делаю ли я сейчас какую‑то ерунду?».

➡️ Про ошибки коммуникации поговорим в следующем посте.

#expert

Внимание!

До окончания акции «Чёрная пятница в OTUS» осталось меньше 12 часов 💣

⏳Начинаем обратный отсчёт

Поспешите

#Otus #акция #Чернаяпятница

❄️ Зима уже на пороге, а значит — время для новых начинаний и ярких возможностей!

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

Что вас ждет:
Уникальные вебинары, которые помогут освоить новые навыки
Лекции от топовых экспертов индустрии
Возможность пообщаться с единомышленниками и задать вопросы профессионалам

🔗 Регистрация уже открыта

Пусть эта зима будет не только холодной, но и продуктивной!

#anons