1-2 августа в Перми мы проведем уже традиционную конференцию про разработку и управление в IT-компаниях — Ural Digital Weekend 2025. Сейчас уже готова программа всех секций.
Запустили продажу SSL-сертификатов для комплексной защиты сайтов и почтовых сервисов
SSL-сертификаты — цифровые решения, обеспечивающих безопасность передачи конфиденциальных данных пользователей. Они создают защищенное HTTPS-соединение, которое шифрует логины, пароли, банковские реквизиты и личную информацию.
У нас вы сможете приобрести все популярные типы SSL-сертификатов для бизнес-сайтов, личного блога, почтовых сервисов, финансовых организаций и других проектов, работающих с персональными данными пользователей, в частности из России и Беларуси:
🔑 DV — быстрая проверка домена.
🔑 OV/EV — расширенная проверка организации.
🔑 Wildcard — защита неограниченного количества поддоменов.
🔑 SAN — решение для мультидоменных проектов и почтовых сервисов.
Повышайте доверие своих пользователей и улучшайте поисковую оптимизацию!
Это заключительный эпизод курса «Паттерны и практики написания кода». В нём бэкенд-инженер Юра Афанасьев расскажет про истоки возникновения паттернов, а также объяснит, как урбанизм и проектирование городов помогли в создании книги «Паттерны проектирования». Напоследок Юра также разберёт два фундаментальных правила, описанных в книге «Design Patterns».
Подписывайтесь на канал AvitoTech в Telegram, там мы рассказываем больше о профессиональном опыте наших инженеров, проектах и работе в Авито, а также анонсируем митапы и статьи.
Как сделать неудачнуюплатформу для разработчиков?Обсудили в новом выпуске подкаста про 10 грехов DevEx 🔥
В этот раз наш гость Артём Арюткин, руководитель проекта офиса Яндекс, рассказал Cloud.ru про главные ловушки платформенной разработки, что не является DevEx, а также, какой должна быть идеальная платформа.
А еще в выпуске:
почему стандартные метрики вредны для реального положения дел в команде;
как когнитивная нагрузка убивает продуктивность (и при этом импортозамещение);
чем опасна «гибкость» инструментов и когда стандартизация спасает проекты;
почему онбординг новых разработчиков — лучший стресс-тест для платформы.
Вы знаете этих людей. Вроде умные, вроде опытные. Говорят правильные слова про 'стратегию', 'масштабируемость', 'долгосрочную перспективу'. Но почему-то через полгода таких разговоров оказывается, что:
баг, который 'уже почти пофиксили' никуда из прода не девался фича, которую 'вот-вот запустим' — всё ещё в черновиках команда уже тихо ненавидит слово 'архитектура'
А техлид? Техлид как будто ничего не замечает. Как это работает (точнее, не работает) Слова вместо кода
вместо пулл-реквестов - диаграммы. демо нет - зато вот вам слайды. вместо решений 'опять' 'давайте обсудим' (читай: 'я не хочу отвечать').
Бесконечный 'анализ'
'Надо подумать над архитектурой' = 'Я не уверен, но боюсь признаться' 'Это нетривиальная задача' = 'Мне лень разбираться'
Ответственность - это не про нас Любимый приём - щедро размазать вину:
'Это комплексная проблема' (на самом деле: 'виноваты все, а значит — никто').
Реальный кейс (чтобы было не абстрактно)
В одном проекте (Node.js, если важно) техлид 2 месяца 'прорабатывал подход' к рефакторингу. Провёл 8 митингов, написал 50 страниц документации.
А потом... уволился.
Оставив после себя: красивые схемы в Confluence ни одной строчки кода команду, которая теперь на рефакторинг смотреть не может
Как понять, что ваш техлид центральная часть системы самообмана?
главный результат его работы - не код, а презентации коронный вопрос - 'А как мы это будем масштабировать?' (но не сам масштабирует) после разговора с ним хочется или закодить, или закопать
Что прикажете с этим делать?
тупо запретить 'стратегировать' без кода* нет пулл-реквеста - нет права говорить про архитектуру.
ввести 'день испанского стыда' раз в месяц техлид показывает руками, что сделал. Не слайды - код.
Задавать всего один вопрос
'Что конкретно изменится после твоего решения?' Если ответ начинается со слов 'теоретически....' - это тревога.
Вывод Хороший техлид — не тот, кто красиво говорит о проблемах. А тот, кто их решает.
Если ваш 'архитектор' только генерирует документы, но не генерирует код - возможно, он уже ИИ.
P.S. Если после этого текста кто-то узнал своего техлида - это не совпадение
Запускаем трёхнедельный СI/CD практикум — будем учиться решать реальные задачи и применять best practices CI/CD.
Через 3 недели курса вы научитесь:
Разбираться в структуре пайплайна и GitLab CI
Читать документацию, находить и адаптировать решения под задачу
Обосновывать и отстаивать технические решения
Проводить технический траблшутинг
Определять, как автоматизировать повторяющиеся задачи и не делать руками то, что может сделать пайплайн
Автор практикума — Вячеслав Федосеев, TeamLead DevOps в «Честном знаке» и ментор курса DevOps Upgrade.
Курс для вас, если вы: уже работаете в IT от 1 года, знакомы с GitLab и GitLab CI (на базовом уровне) , хотите уверенно строить пайплайны и решать нестандартные кейсы
Если вы чувствуете, что теории недостаточно — необходимы опыт и фидбэк, присоединяйтесь к обучению — старт 21 июля.
Как DevOps-инженеру сэкономить часы работы и избежать ошибок с помощью AI-инструментов
Воркшоп с Виктором Чаплыгиным, Senior Engineer в международном GameDev холдинге.
Что будет на воркшопе:
Теория: кратко о том, как работают LLM в контексте разработки и эксплуатации. Обзор инструментов:
Cursor IDE — AI-интегрированная IDE с поддержкой кода и терминала;
PSP/PSS Baseline — стандарты безопасности Kubernetes.
Практика:
Настройка Cursor IDE — подготовка среды для продуктивной работы с AI;
Создание и отладка IaC (Kubernetes YAML, Terraform) с помощью AI-ассистентов: выявление и исправление ошибок;
Генерация понятной и структурированной документации к проектам с помощью AI;
Разбор реальных кейсов и работа с командной строкой: исправление, пояснение, улучшение команд и манифестов.
А ещё — личный опыт и лучшие практики применения GPT-ассистентов для повседневных DevOps-задач, от написания инфраструктуры до исправления ошибок и генерации документации.
Когда: 5 июля 2025 года
Узнать подробности и занять место на воркшопе — через бота.
Последние из группы Поведенческих паттернов: Хранитель и Шаблонный метод
В одиннадцатой серии курса «Паттерны и практики написания кода» вместе с бэкенд-инженером Юрой Афанасьевым завершаем тему Поведенческих паттернов. Последние два подхода, которые разберем в эпизоде: Хранитель и Шаблонный метод. Подробнее про их реализацию в коде, преимущества и недостатки — в эпизоде.
Подписывайтесь на канал AvitoTech в Telegram, там мы рассказываем больше о профессиональном опыте наших инженеров, проектах и работе в Авито, а также анонсируем митапы и статьи.
Развернуть высоконагруженную платформу в Managed Kubernetes, ориентированную и на b2b-, и на b2c-сегменты — задачка со звездочкой. Как это сделать, рассказываем в Академии Selectel на примере кейса компании TrendTech.
Вы узнаете, как компания:
обеспечила отказоустойчивость сервисов, сохранив возможность гибкого масштабирования;
автоматизировала обновление контента из более чем 5 000 источников данных;
обеспечила отдачу и надежное хранение тяжелых файлов;
развернула удобное окружение для команды разработки.
Перенимайте опыт TrendTech и используйте Managed Kubernetes для реализации своих проектов.
Всё о назначении и применимости Наблюдателя и Цепочки Обязанностей
Это десятая серия курса «Паттерны и практики написания кода»: вместе с бэкенд-инженером Юрой Афанасьевым продолжаем изучать тему Поведенческих паттернов. В новом эпизоде разбираем два подхода, связанных с отправкой и обработкой событий: Наблюдатель и Цепочка Обязанностей.
Подписывайтесь на канал AvitoTech в Telegram, там мы рассказываем больше о профессиональном опыте наших инженеров, проектах и работе в Авито, а также анонсируем митапы и статьи.
Это большая тема, о которой можно говорить очень много. Самое главное, что возможности применения ограничиваются только вашей больной фантазией. Вы строите интерфейс своего модуля или плагина и вам нужно подтянуть данные из сторонней системы (список чего-нибудь по какому-нибудь API), чтобы сохранить выбранный id в Joomla. Или сделать какую-то проверку и в зависимости от неё показать то или иное сообщение пользователю. Для этого подойдут свои пользовательские типы полей.
Интерфейс Joomla по большей части описан в XML-файлах. У каждого из них свои параметры. Некоторые не описаны в документации (manual.joomla.org), поэтому самым любопытным будет полезно заглянуть в собственно файлы фреймворка по пути libraries/src/Form/FormField.php, а так же в libraries/src/Form/Fields. У каждого класса поля перечислены его специфические свойства, которые можно описывать в XML. А в своём типе поля вы можете устанавливать эти значения программно.
В моём модуле WT Quick links под капотом происходят изменения. Теперь для работы (в админке) ему нужен вспомогательный плагин. А в самом модуле нам бы проверить, а не выключен ли он?
В Joomla есть тип поля Note - заметка. Его можно использовать для вывода примечаний.
<field type="note"
name="your_note_for_user"
label="Заголовок примечания"
title="Альтернативный способ для заголовка"
description="Текст примечания"
class="col-12 alert alert-info"
heading="h1"
close="true"
/>
heading- указывать уровень заголовка. close - позволяет закрыть это примечание.
В классе поля libraries/src/Form/Field/NoteField.php описана логика вывода. И в принципе оно нам подходит для нашей задачи. Но оно будет выводить сообщение всегда, а нам нужно только тогда, когда плагин отключён.
Поэтому берём и создаём свой класс поля, который мы унаследуем от NoteField. Это значит, что у нас в руках будет весь инструментарий стандартного поля Note + то, что мы сами добавим.
addfieldprefix - указываем namespace к нашему классу, может быть любой нам нужный
name - нельзя полю без имени...
Это означает, что Joomla будет использовать класс поля из файла modules/mod_wt_quick_links/src/Fields/SystempluginstatusField.php. А в классе поля будет написано следующее:
<?php
// namespace для атрибута addfieldprefix
namespace Joomla\Module\Wtquicklinks\Site\Fields;
// нельзя напрямую обращаться к этому файлу
defined('_JEXEC') or die;
// подключаем родительский класс для переопределения
use Joomla\CMS\Form\Field\NoteField;
use Joomla\CMS\Language\Text;
use Joomla\CMS\Plugin\PluginHelper;
// имя класса и имя файла точь-в-точь
class SystempluginstatusField extends NoteField
{
protected $type = 'Systempluginstatus'; // тип поля без "Field" в конце
protected function getLabel()
{
// если плагин не включён
if(PluginHelper::isEnabled('system','wtquicklinks')) {
// меняем свойства родительского класса поля
$this->class = 'alert alert-danger w-100';
$this->element['label'] = '⚠️ А-а-а-а!';
$this->element['description'] = 'Плагин не включён!!';
// и просто рендерим его с нашими свойствами
return parent::getLabel();
}
// А иначе всё хорошо, скрываем поле из виду.
$this->parentclass = 'd-none';
return '';
}
}
Просто и удобно. И людям приятно, что о них позаботились и рассказали почему что-то не работает.
В новом эпизоде курса «Паттерны и практики написания кода» вместе с бэкенд-инженером Юрой Афанасьевым продолжаем тему Поведенческих паттернов. На рассмотрении следующие два подхода: Команда и Посредник — разберёмся, какие задачи они решают, как выглядят соответствующие UML-диаграммы, а также какие особенности следует учитывать при реализации в коде.
Подписывайтесь на канал AvitoTech в Telegram, там мы рассказываем больше о профессиональном опыте наших инженеров, проектах и работе в Авито, а также анонсируем митапы и статьи.
Это восьмая серия курса «Паттерны и практики написания кода», где вместе с бэкенд-инженером Юрой Афанасьевым открываем новую тему — Поведенческие паттерны. Данная группа самая обширная из всех изученных, поэтому в новом эпизоде постепенно разберём первые два подхода: Стратегия и Состояние.
Подписывайтесь на канал AvitoTech в Telegram, там мы рассказываем больше о профессиональном опыте наших инженеров, проектах и работе в Авито, а также анонсируем митапы и статьи.
В развитие темы Bare Metal VM, над которой я время от времени размышляю начиная аж с 2010 года, предлагаю ознакомиться с интересным и, на мой взгляд, перспективным проектом OSv.
Ещё в 10-м году я подумывал над тем, что имея сервера приложений наподобие Томката и серьёзную взрослую изоляцию на уровне загрузчика классов - можно выкинуть подлежащую ОС со всеми её ненужными сервисами из нашего стека, оставив сервер приложений на голом железе. Тогда же выяснилось, что не я один так думаю, было коммерческое предложение Oracle JRockitVE. Судя по всему, наследница вот этого приобретения Bea.
Ранее я уже писал статью об этой идее на Хабре и пытался защищать в дискуссии.
Можно попробовать снова.
Ещё можно смотреть на развитие ОС на базе грааля. Или вспомнить про JaOS.
К современным ОС типа Линукса у меня есть много претензий, и есть несколько идей, которые можно было бы реализовать для их улучшения. Некоторые из них описаны в указанном проекте. Некоторые в том или ином виде наличествуют в специализированных коммерческих предложениях (Юникс) крупных вендоров типа АйбиЭм или того же Оракла. Это касается, например,
файлово-дискового стека,
оптимизации сети,
использования ГПУ в неожиданных местах,
гибкости в использовании СУБД при разработке с контейнером.
