Сегодня в 15:00 — новый выпуск прямого эфира «Стальной микрофон» с директором по информационным технологиям «Северстали». Герой нового эфира — врач! Знакомьтесь:
Николай Сорокин — доктор медицинских наук, профессор факультета фундаментальной медицины МГУ им. М. В. Ломоносова, врач-уролог, онколог, онкохирург.
Вместе с гостем обсудим: - Когда пора идти к профильному врачу? - Будет ли полная роботизация медицины? - Дети врачей и айтишников — это будущие врачи и айтишники?
Расскажем, как проводить нагрузочное тестирование на Python
Ждем вас через час, в 18:30 мск, на митапе для Python-специалистов. Как обычно, поговорим обо всем, что волнует сообщество. Сделаем глубокий разбор экосистемы mypy и протестируем ее. Выясним, как запускать задачи по расписанию от cron/systemd timers до чистого Python. Узнаем, насколько сильно можно нагрузить систему, прежде чем она сломается. Все это — в компании экспертных спикеров из Selectel, Яндекса и Райффайзен Банка.
Приходите лично или подключайтесь к трансляции.
Программа
18:35-19:05 — mypy в неестественной среде обитания Сделаем обзор gradual typing в Python и экосистемы mypy, разберем отличия от линтеров и других анализаторов типа.
19:05-19:35 — Все идет по cron-у. Или нет? Поговорим о том, как запускать задачи по расписанию: от cron/systemd timers до чистого Python и библиотек вроде APScheduler, Celery, а также Kubernetes CronJob и Redis Queue.
19:35-20:00 — Ломай меня полностью Разберемся, зачем и как проводить нагрузочное тестирование.
Техническое интервью становится решающим этапом отбора в крупные технологические компании. Проектирование масштабируемых систем требует глубоких знаний и опыта — без правильной подготовки кандидат рискует потерять шанс получить работу мечты.
Поэтому Кирилл Борисов, SRE в VK, вместе с Владимиром Невзоровым, Senior backend developer, покажут реалистичный опыт прохождения технического интервью.
Для кого этот вебинар?
⭐️ Для тех, кто готовится к техническим интервью в крупных компаниях
⭐️ Для разработчиков, желающих углубить свои знания в проектировании систем
⭐️ Для всех, кто хочет повысить шансы на успешное прохождение технических собеседований
После вебинара вы поймете структуру и логику System Design интервью, ознакомитесь с алгоритмами проектирования высоконагруженных систем, чтобы в дальнейшем избежать распространённых ошибок.
Бывает, что работа надоедает — хочется попробовать себя в чём-то новом, но останавливает страх начинать с нуля. Спокойно: построить карьеру в IT можно и без глубоких знаний программирования или технического образования.
Есть профессии, где важнее внимательность, креатив и аналитическое мышление, а базовые знания можно получить за несколько месяцев. Собрали для вас топ-5 профессий с низким порогом входа — выбирайте, что по душе.
Всем привет! С вами Дарья Морозова, специальный корреспондент Мир Plat.Form. Мы продолжаем серию репортажей с крупнейших ИТ-конференций страны. И в этот раз мы отправились на конференцию Joker — место сбора Java-разработчиков из Санкт-Петербурга и не только.
Смотрите, как мы вычисляем джависта, проверяем, сможет ли ИИ нас заменить, придумываем смешные ИТ-поговорки и оцениваем мем рабочей недели (особенно актуально перед шестидневкой).
Создатель архитектурного стиля RESTРой Филдинг — считает, что REST-архитектура должна соответствовать пяти обязательным ограничениям. У него довольно жёсткая позиция, что если API не выполняет хотя бы одного ограничения, то это не RESTful API. И тут ничего не поделаешь, как автор идеи считает, так и правильно. Далее я буду говорить, что api REST или не REST именно по Филдингу.
Но шутка в том, что хотя каждый уважающий себя бекендер знает про REST, почти никто не делает RESTful API. Но не потому что это недостижимый идеал, а потому что REST для апи, почти никому не нужен.
В смысле не нужен? А вот так, давайте взглянем на модель зрелости REST сервисов Леонарда Ричардсона. На первом и втором уровне находятся ресурсы и http-глаголы, вещь полезная, я понимаю их пользу и ничего против них не имею. А вот на третьем уровне мы видим hypermedia controls, о котором я бы хотел поговорить подробнее.
Гипермедиа как средство управления состоянием приложения или HATEOAS. Благодаря этому ограничения клиент и сервер могут развиваться независимо друг от друга, а вся необходимая информация о том, что можно делать ресурсом, содержится в ответе этого ресурса. В общем, классический сайт. Мы открываем главную или какую-нибудь другую страницу и переходим между страницами. На страницах есть ссылки на другие страницы и формы для редактирования. Вот что говорит сам автор:
«REST API следует вводить без каких-либо предварительных знаний, кроме начального URI и набора стандартных типов данных. Все переходы состояний приложения должны определяться исходя из представлений или пользовательских манипуляций с ними, полученных клиентом от сервера»
— Рой Филдинг, Архитектурные стили и проектирование сетевых архитектур программного обеспечения.
Для меня это звучит так: вот у нас сайт, соответствующий принципам REST архитектуры, тогда он может отдавать свои ресурсы в разных представлениях — например, в виде html или json. HTML — это обычная веб страница, а json содержит только данные, без визуала. Нетрудно понять, что REST клиент для json представления выглядит не очень привлекательно.
Филдинг предполагал, что сервер может менять контракт как захочет, а клиент сможет его понять на основании гипермедиа. Вы встречали таких клиентов? На самом деле они есть, но про них мало кто знает. На практике в API HATEOAS не нужен ни программисту, ни программному клиенту. Программисту нужно описание контракта, с чем прекрасно справляются OpenAPI/Swagger, желательно автогенерённые из кода. А клиенту нужен четкий контракт, как создать товар или показать ленту. И меньше всего клиент хочет, чтобы контракт менялся, и тем более не хочет поддерживать средства обнаружения и подстройки под изменённый контракт.
В итоге перед программистом встаёт дилемма:
Не делать HATEOAS. Но тогда его апи нельзя называть RESTful.
ДелатьHATEOAS. Но тогда ему нужно будет "напихать ссылок" в ответы своего апи и поддерживать их просто чтобы называться RESTful. При этом, эти ссылки никто не будет использовать.
В итоге мы живём в мире, где бэкенд часто разрабатывают с использованием принципов REST, но при этом почти не существует RESTful апи. А те, что существуют, имеют пародийное название REST-like API или pragmatic REST. А 2-й уровень зрелости REST звучит так, как будто мы остановились на полпути к идеалу. Но ведь это не идеал: 3-й уровень зрелости часто бессмысленен или даже вреден.
На практике, все насколько смирились с ситуацией, что ослабили значение термина и называют api RESTful, даже если оно только частично следует принципам REST.
А было бы круто, если бы кто-то придумал новый, хороший термин для архитектурных практик, которые бы взяли всё лучшее и полезное из REST применительно к современным Web-api. Тогда бы начинающие бэкендеры сразу осваивали актуальные подходы, а не книги Филдинга из 2000-х, как я когда-то.
Сегодня — тот самый день, когда решительность имеет цену.
Скидка 15% на все IT-курсы, стартующие в октябре, действует до конца суток. Завтра она снизится до 10%. Ещё через несколько дней — до 5%. А потом и вовсе исчезнет.
Базовая книга по инжинирингу платформ – новому подходу к управлению программными системами, при работе с которыми требуется обслуживать множество разных аппаратных архитектур и операционных систем. Показано развитие концепции DevOps и объяснено, как учитывать запросы и возможности пользователей независимо от способа работы с приложением, минимизировать задержки при обработке данных и упрощать масштабирование и поддержку многоплатформенных продуктов. Описан комплексный подход к управлению продуктом с учетом потребностей клиентов, разработчиков, системных администраторов и предприятия в целом, актуальный на любых программных платформах.
Для специалистов DevOps, системных администраторов, руководителей команд
Все ждут «идеального момента», чтобы начать учиться новому. Спойлер: его не будет. Будет обычный день, как сегодня, и вы возьмете и начнете. Чтобы набрать темп, предлагаем залететь на нашу витрину за бесплатными курсами от известных школ. Забирайте и заряжайтесь мотивацией на большее:
Чтобы код был понятным, структурированным и компилировался без ошибок нужно постоянно совершенствовать свои навыки.
А лучшие помощники в этом — хорошие курсы, которые дают возможность углубиться в любимый язык программирования и разобраться во всех его тонкостях. Погнали разбираться вместе:
Java. Приложения для бизнеса, банковские системы, корпоративные сервисы и масштабные веб-приложения.
Python. Веб-сайты, скрипты для автоматизации и анализ данных.
PHP. Динамические сайты, CMS, интернет-магазины и серверная часть веб-платформ.
C++. Драйверы, ПО для железа и высокопроизводительные приложения.
Rust. Безопасное и производительное ПО, системное программирование, микросервисы и backend
Еще немного про доходы разработчиков - вот очень наглядный график диапазонов зарплат по разным странам, до налогов. Данные двухлетней давности, но наглядности это не уменьшает.
Актуально и для других айтишников, там цифры будут поменьше.
Парсинг Сохранённых сообщений Телеграм в локальный каталог
Всем привет. Позвольте рассказать вам, как скачать содержимое Сохранённых сообщений Телеграм к себе на ПК.
Для начала, ознакомьтесь с предыдущей статьёй - Парсинг чатов Телеграм. В ней описан процесс установки и первичной настройки десктоп клиента. Кратко, что у вас должно быть настроено: 1. Путь к хранилищу (локальная БД SQLite). 2. Путь к файлу сессии (в нём сохраняется служебная текущая сессия подключения). 3. Регистрация приложения на сайте Телеграм. 4. Настройки подключения клиента (хранится в таблице приложений).
Страница настроек
После успешного подключения к Телеграм, откроется доступ к меню Сохранённые сообщения. Заходим на третью вкладку Скачать, кликаем по кнопке Сбросить по-умолчанию, указываем локальный каталог на диске для скачивания файлов (например C:\OpenTgResearcher\SavedMessages). По необходимости, отредактируем первый ИД и количество потоков. Всё готово, кликаем по кнопке Запустить парсинг Телеграм. После чего можно идти пить кофе, пока ожидаем результат работы парсинга. Файлы будут скачаны в локальный каталог, а сообщения в соответствующую таблицу, их можно будет посмотреть на вкладке Содержимое.
Если вам нужна заказная разработка приложений либо вы в поисках разработчика моего уровня, сообщите пожалуйста мне в личку.
🧠 Стек технологий: - Разработка ПО: Console, ASP.NET Core Web API, Blazor, WinForms, WPF, UWP, WinUI - Хранение и передача информации: JSON, XML, SQLite - БД и ORM: MS SQL Server / PostgreSQL / SQLite, EF Core - Веб технологии: REST API / RESTful API, HTTP, TCP/IP, HttpClient, WebSocket - Брокеры сообщений: RabbitMQ (готов быстро освоить Kafka) - Контейнеризация: Docker / Compose (готов быстро освоить Kubernetes) - Архитектура ПО: ООП, шаблоны проектирования (Design Patterns) - Архитектурные подходы: TDD, DRY, KISS, SOLID, YAGNI, Clean Architecture, N-Tier Architecture - Фронт: небольшой опыт разработки Angular
Привет, Хабр. Сегодня делимся подборкой открытых уроков, которые пройдут в Otus на этой неделе. Уроки проводят преподаватели курсов в формате живых вебинаров — это шанс не только получить нужные знания, но и задать свои вопросы экспертам. Участие бесплатное (нужно только зарегистрироваться). Присоединяйтесь!
Мы знаем, что найти работу мечты — тот еще квест. Часто мешает даже не отсутствие опыта, а неуверенность в себе. Кажется, что все вокруг специалисты намного круче и вообще: зачем стараться, если все равно ничего не получится?
На самом деле все иначе: уверенность приходит в процессе — вместе с опытом и новыми прокаченными скиллами.
Автоматизируйте рутину с Ansible: бесплатный чек-лист для DevOps-инженеров
Делимся бесплатным чек-листом по основам Ansible, который поможет:
• Освоить написание плейбуков и ролей • Настроить автоматическое развертывание приложений • Внедрить Infrastructure as Code в GitLab • Организовать управление IT-инфраструктурой
Материал будет полезен как начинающим специалистам, так и опытным инженерам для систематизации знаний и подготовки к собеседованиям.
Ansible-навыки входят в топ-требований к DevOps-вакансиям — используйте эту возможность прокачать свой профиль.
Мы знаем, что путь SRE может быть непростым — нужно разбираться и в коде, и в железе, и в процессах, и даже в психологии. Становится особенно трудно, когда не понимаешь, что от тебя требуется и с чего начать.
Чтобы помочь не утонуть в этом море информации, мы составили бесплатный чек-лист «Навыки и компетенции SRE» — внутри вы найдёте конкретные критерии, а также комментарии от специалистов:
«Усредненный список навыков: автоматизация, работа с командой, работа с тойлом, инциденты и надёжность, обучение, принятие решений. Частота применения зависит от уровня, позиции, роли и компании» — Сергей Бухаров, Infrastructure Platform Technical Lead в Dodo Engineering
Делимся статьями Кирилла Казарина, Senior DevOps and SRE global manager в RingCentral Inc. и спикера курса «Администрирование Linux», о работе с CPU в Linux
1. CPU в Linux. Утилизация
Общее представление об использовании ресурсов CPU и методах анализа нагрузки.
Знакомая ситуация: нужно добавить новую функциональность, а одно небольшое изменение тянет за собой правки в десятках мест? Код превращается в хрупкую конструкцию.
Проблема часто кроется в отсутствии гибкой архитектуры. Ключ к её созданию — грамотное использование интерфейсов в C#.
Как подойти к расчету ROI для AI-проектов в DevOps?
Отвечает София Филиппова, AI engineer at Innova
Все любят красивую классическую формулу для подсчета ROI, но если вы хоть раз пробовали посчитать этот параметр для аишных проектов, то вы знаете, что так просто получить реалистичный прогноз не получится
Почему так происходит
В классическом подходе ROI считают по формуле: прибыль минус затраты, делим на затраты. В бытности AI всё несколько сложнее, потому что:
Модель может деградировать
Данные стареют
Инфраструктура дорожает
Людям требуется время, чтобы освоить аишные инструменты
Из-за всего этого первые месяцы после внедрения действительно часто уходят в минус. И только после прохождения периода адаптации и отладки система начинает реально помогать.
Как посчитать ROI реалистично
Определите работу для делегирования Чтобы оптимизировать процесс, нужно этот самый процесс для начала иметь. Крайне желательно, чтобы он был описан подробно со всеми развилками в сценарии.
Замерьте показатели до внедрения Сколько стоил процесс "вручную".
Заложите ramp-up Первые 3–6 месяцев скорее всего не дадут ощутимой прибыли, и это нормально.
Оцените риски и скрытые расходы Например:
Траты на GPU (если разворачиваете LLM локально)
Поддержку и переобучение моделей
Токены (если идете по облачному пути). Советую также составить минимум 3 сценария: худший, умеренный и лучший.
Учитывайте цену ошибок AI тоже ошибается, иногда дорого.
Смотрите в будущее ROI через год почти всегда выше, чем через три месяца.
Когда внедрение AI действительно окупается
Исследования 2025 года показывают:
Команды с MLOps-практиками ускорили релизы на 30%
Агентные системы показывают положительный ROI при чётком ограничении привилегий
Автоматизация инцидентов и оповещений окупается после полугода работы
Одна из главных мыслей здесь состоит в том, что успех внедрения ИИ в проект зависит в первую очередь от того, насколько грамотно его работу ограничил специалист. Если учитывать аспекты безопасности и иметь четко описанный процесс, который вы хотите передать AI-инструменту, у вас есть все шансы принести пользу своей AI-инициативой.
София Филиппова — одна из спикеров курса «AI в DevOps», где мы как раз разбираем, как считать ROI AI-проектов и внедрять их без лишних рисков.
Старт потока — уже через неделю, 20 октября. Если хотите не просто читать про AI, а научиться внедрять его в работу — присоединяйтесь!
Почему "давайте писать внимательнее" - плохое решение?
Такой ответ на баг звучит разумно, но он непроверяем: нельзя показать, что мы стали внимательнее, и нельзя доказать обратное. В терминах Поппера - нефальсифицируемая гипотеза, а значит, не инженерное решение.
Инженерное решение должно быть проверяемым:
тест падает - гипотеза неверна;
алерт сработал - защита работает;
фича-флаг не дал багу уйти - система выдержала.
"Внимательность" не измеряется, не тестируется и не гарантируется. Это не решение, а успокоение.
