Представлен проект открытого бота на Python для Telegram с торрент клиентом. Решение умеет загружать файлы по магнет-ссылкам и ссылкам на Google-диск, есть поисковик торрентов и встроенный yt-dlp.
По мотивам IDEF0
"Ничто не исчезает бесследно и не возникает из ничего"
Закон сохранения, М.В.Ломоносов, 1748 год
Тут будет немного банального и очевидного, но часто банальное и очевидное забывается...
Задумаемся, что нужно, чтобы что-то получить в результате какого-то процесса.
Очевидно, что что-то надо подать на вход. ЧТО-ТО, что будет преобразовано в результате процесса и станет целевым продуктом, т.е. выходом.
Но этого мало. Нужно, чтобы это что-то КТО-ТО преобразовал. Т.е. нужен персонал, или человеческий ресурс.
Голыми руками преобразовывать будет? Нет. Значит, нужно оборудование. Т.е. преобразовывать ЧЕМ-ТО. Это технический ресурс.
Оборудование работает само по себе? Нет, оно потребляет энергию, плюс часто нуждается в ГСМ и т.п., что расходуется "в процессе процесса", но не входит в состав выходного продукта, хотя и необходимо для его получения. Т.е. нужен расходуемый ресурс.
Но и этого мало. Нужно знать, КАК выполнить процесс. Т.е. информация (инструкции, чертежи, технологические карты, спецификации, ТЗ и т.д.). Это управление.
Процесс происходит мгновенно? Нет, ему нужно время.
Всё входящее бесплатно? Нет, на всё это нужны деньги.
Может ли скрипач-виртуоз по инструкции к кофеварке электродрелью без электричества, но с канистрой бензина, из мешка цемента сделать яичницу? Вряд ли, правда? Значит, каждый ресурс, как и вход, должны отвечать определённым требованиям и иметь характеристики, СООТВЕТСТВУЮЩИЕ процессу и продукту.
И под конец - о, чудо! Каждый ресурс, как и вход, в свою очередь являются выходом какого-то процесса, который описывается ровно так же (из чего, кем, чем, на чëм, как). Персонал - процесс подготовки кадров, инструкции и чертежи - НИОКР, и т.д.
Можно всё это входящее либо иметь своё, либо заимствовать извне. А если своего не хватает, то откуда (кроме как извне) возьмётся что-то на выходе, да с приемлемым качеством, да в нужном количестве, и сколько времени и денег на это уйдёт?
Думаем, оцениваем, анализируем.
Челлендж для HR, тимлидов и скептиков!
Привет! Перед вами нечто среднее между стеком разработчика / резюме. Попробуйте оценить:
Junior, Middle или Senior? (или вообще кто это?)
Во сколько такие люди оцениваются нынче?
Взяли бы в команду? Или сразу в бан?)
⚠️ Некоторые детали с подвохом.
💻 HARD SKILLS
Языки программирования
Python, JavaScript, Java, Kotlin, C++, C#, SQL, AutoIt, Assembly, Go
Технологии, форматы, API
HTML, CSS, JSON, GeoJSON, DOM, Canvas API, WebGL, REST API, WebSocket, Bash/PowerShell
Базы данных
MariaDB, SQLite, Redis, PostgreSQL, Oracle,, MS Access
Фреймворки и библиотеки
Web Backend: Django, Flask, FastAPI, Node.js, Celery
Desktop GUI: PyQt, Tkinter, Lazarus
Mobile: Android SDK, Gradle
Визуализация и 3D: Three.js, OpenCV
Data Science: NumPy, Pandas, Matplotlib
GIS: QGIS
Медиа: FFmpeg
Frontend / Web-разработка
React, адаптивная верстка, интерактивные карты, кастомные UI-компоненты, работа с большими изображениями, клиентская логика, мини-движки визуализации
Backend / Сервисы
REST API, парсинг веб-данных, обработка данных, файловые пайплайны, работа с БД, deployment на localhost
Desktop-разработка
Многооконные приложения, панельные интерфейсы, файловые менеджеры, рендереры, конвертеры, кастомные инструменты, собственный табличный редактор (CSV/JSON/Excel)
Mobile / Android
Нативные проекты на Kotlin/Java, работа с ресурсами, манифестами, базовые UI-компоненты
Data / Computer Vision / ML
Обработка изображений, сравнение фото, фильтры, контуры, цветовые анализаторы, DPI/масштабирование, нейросетевые модели, работа с датасетами
GIS / Картография
Разбиение карт на тайлы, кастомные HTML/JS-карты, координатные системы, управление слоями, визуализация геоданных, интерактивные схемы
3D / Графика
Визуализация объектов, базовый шейдинг, анимации, работа с 3D-сценами, астрономические симуляции
Audio / Video обработка
Конвертация, рендер, аудиоэффекты, VST, визуализация звука
Automation / Инструменты
200+ кастомных утилит: пайплайны, GUI-редакторы, конвертеры, парсеры, визуализаторы, сборщики, веб-автоматизация (Selenium, ChromeDriver)
Build / DevOps
Сборка проектов, Git (локальный контроль версий), Firefox/Chrome DevTools, отладка
🧠 SOFT SKILLS
Системное мышление, архитектурное проектирование, UX/UI дизайн, rapid prototyping, постановка задач, анализ требований, визуализация идей, техническое чутьё, структурирование проектов, документация, логическое мышление
ИНСТРУМЕНТЫ РАЗРАБОТКИ И ДИЗАЙНА
Notepad++ (+ собственный редактор (пока Python syntax)), VS Code, Sublime Text, Android Studio, QGIS, Blender, Unity, Figma, Photoshop, Illustrator, CorelDRAW, Audacity, FL Studio, Adobe Premiere Pro, After Effects, Magix, Postman, curl, Total Commander, VirtualBox
МЕТОДОЛОГИИ И ПОДХОДЫ К РАЗРАБОТКЕ
Итеративная разработка (Rapid Prototyping), контроль версий, архитектурные паттерны (MVC, MVVM), модульное проектирование, рефакторинг кода, оптимизация производительности, отладка (логирование, DevTools), структурирование проектов, документирование кода
Дополнительный вопрос:
За какое время можно пройти путь от «Чёрное окошко — это какая-то магия, F12 — это что-то страшное...» до реального применения всего перечисленного выше в прототипах и рабочих проектах? Минимум по одному разу.
Иначе говоря: в стартовой точке известны были лишь названия языков программирования, а про циклы и алгоритмы что-то смутно помнилось из школьного учебника.
Сколько лет затрачено до текущего стека?
Представлен открытый проект Telegram Downloader, который умеет легально, быстро и легко скачивать любые файлы даже из защищённых каналов и чатов, где закрыта пересылка контента:
качает даже тяжёлые файлы за несколько секунд.
загрузки экспортируются в JSON-формат прямо на локальный диск.
работает локально — вся информация о загрузках будет только на локальном ПК.
не нарушает политику мессенджера.
WAT Medical выпустила умный браслет, заменяющий кофе и энергетические напитки. Гаджет eCoffee Energyband для этого бьёт током пользователя для бодрости.
У браслета две электродных накладки, которые прилегают к внутренней стороне запястья. По уверениям производителя, гаджет подаёт электроимпульсы, которые разгоняют кровь, помогают держать мозг в тонусе и повышать концентрацию. Из-за вреда электрических разрядов не рекомендуется долго носить такой браслет на одной руке. Каждые три часа следует менять запястье, на которое его надевают. Проблема в том, что из-за разрядов часть руки, например, кончики пальцев, могут на время онеметь.
Актуализировали версии языков в Apps ⌨️
Чтобы вы запускали приложения на более современных версиях, в которых появились новые функции и улучшение производительности.
Добавили версии:
➖ Python: 3.14, 3.13
➖ PHP: 8.4
➖ Node.js: v24
➖ Go: 1.25, 1.24, 1.23
➖ .NET: 9.0
➖ Elixir: 1.19, 1.18, 1.17, 1.16
➖ Java: 25, 21
➡️ Обновить окружения в Apps →
И вам наш продакт-менеджер, Артем Гринберг просил передать:
🤓 А еще готовим статью и вебинар о том, как мы переписали Apps и что именно в них изменилось. Скоро расскажем подробности.
Блокировка МТС 72 часа
Как известно, недавно вышло требование в рф о блокировке сим карт рф, которые были неактивны или в роуминге последние 72 часа. Кто не в курсе у подобных сим карт блокируются услуги смс и интернет на 24 часа.
Что происходит в МТС, замечу именно в МТС, потому как у других операторов такого замечено не было. Как минимум уже второй раз за последние 10 дней от мтс приходит смс следующего содержания: "Вы не пользовались сим картой последние 72 часа, доступ к мобильному интернету и смс временно ограничен на 24 часа в целях безопасности. Чтобы сразу восстановить доступ пройдите короткую верификацию -ссылка на поддомен мтс- Обратите внимание: капча работает только через мобильную сеть (WiFi и VPN нужно отключить)... ".
Теперь детали:
Сим карта находится постоянно на территории рф, до ближайшей границы оч.далеко, роуминг исключён;
Тариф на сим карте без абон.платы, разумеется без интернета. Как видно из смс от мтс выше, если я хочу разблокировать сим карту здесь и сейчас, то мне нужно её переставить в смартфон и включить на этой сим карте мобильную передачу данных, что даже при условии бесплатности ресурса мтс для капчи, скорее всего всё равно приведёт к списанию платы за интернет, т.к. после прохождения капчи услуги активируются и, например, приложение погоды полезет в интернет для обновления оной, либо любое иное другое приложение "обрадуется" интернету и полезет туда, не говоря уже о том, что в смартфоне могут быть свои кастомные настройки dns серверов и это для мтс уже будет сторонним тарифицируемым платным трафиком.
В случае же, если сим карта находится на удалённом объекте, например, в системе автосигнализации, то для того, чтобы пройти капчу, зачастую, нужно разобрать пол-машины, чтобы добраться до системы автосигнализации, вытащить сим карту, проделать действия выше и собрать всё обратно! МТС, вы согласны оплатить услугу автосервиса по разборке и сборке авто?
Такое происходит уже второй раз, т.е. вероятность какой-либо случайности, отладки системы и проч. - исключается. Это как раз уже получается системная проблема.
Сим карта всё время статична, находится в одном и том же месте, никуда не перемещается уже много лет. Оператор может легко отследить это технически, по регистрациям на базовых станциях.
Пишу на публичном ресурсе в т.ч. по причине того, что при первом подобном случае об этом было написано в поддержку мтс, где кстати в ответ, кроме шаблонного, "для моей безопасности это всё было заблокировано и для разблокировки я должен им предоставить паспортные данные владельца". Однако ответ на мой прямой вопрос, почему произошла блокировка, ведь сим карта никуда не уезжала и телефон не выключался", остался без ответа и более того, это повторилось.
Что ещё - такое происходит только на сим картах мтс. С сим картами других операторов такого нет, оно и логично, ибо такое и не должно происходить, если сим карта не в роуминге или в сети последние 72 часа.
МТС, просьба прокомментировать и написать всем, согласно какого такого закона вы блокируете сим карты абонентов? Вы хоть осознаёте, что вы создаёте, этим самым, потенциальную угрозу безопасности для своих абонентов, которые сами того не зная не будут получать смс от тех же государственных сервисов вроде госуслуг или банков, если последние, например, будут подвергнуты взлому? Или абоненты не получат важных смс от всеразличных охранных систем, в т.ч. автосигнализаций, трекеров наблюдения за животными, детьми, не будут извещены о различных параметрах умного дома, электрокотлов, систем обогрева и проч., из-за чего возможны аварии, кражи, угоны и даже пожары, и проч. Вы хоть осознаёте эти последствия?
ps Акцентирую внимание на следующем: Сим карта включена 100% и была включена всё это время каждый день. Успешно зарегистрирована в сети мтс. Никакой задолженности за услуги на сим карте нет. Сим карта находится далеко от границ рф и вариант пусть даже с временным роумингом на сим карте исключен полностью.
Вам не кажется, что порядок агрументов в обратной польской записи нелогичен? Почему 5 - 3 в ОПЗ это 5 3 - а не 3 5 - ? Как частично применить аргумент к функции? Т.е. как сделать каррирование оператора - ? Надо применить к нему предпоследний элемент стека, т.е. стек должен состоять как минимум из двух элементов, а для частичного применения достаточно было бы, чтобы на стеке лежал только один элемент.
Конечно можно каррировить оператор не первым, а последним аргументом, т.е. частично применить 3 к - и получить функцию, которая на вход будет принимать число, и вычитать из него 3. Для оператора минус вроде всё логично. А давайте рассмотрим оператор map : (a -> b) -> List<a> если к нему частично применить некоторую функцию (a -> b), это имеет определённый смысл - мы получим функцию, к которой можно применять различные данные (списки), а если мы поступим наоборот и частично применим к map некоторый список, то мы получим довольное нелепую конструкцию - список данных, к которым можно применять разные функции.
Подозреваю, что Ян Лукасевич определил такой порядок, чтобы визуально арифметические операции выгладели похожими на привычную нам инфикцную запись, но для более сложных функций, чем арифметические операторы такой порядок вызывает некоторые неудобства.
В игре Escape from Tarkov на магазине P90 долгое время висела надпись «Потом будет прозрачный» — после релиза её поменяли на «По ходу не будет». Игру делали девять лет, включая восемь лет и три месяца тестирования.
Предупрежден - значит, не потеряешь деньги. Как не попасть в плен “иллюзий фаундера”?
Как фаундер, я хорошо знаю это состояние: классная идея захватывает твой разум. Кажется, что нужно совсем немного, чтобы пришел оглушительный успех.
Важно посмотреть на ситуацию честно. Какие иллюзии бывают у фаундеров?
“Если продукт крутой - клиенты сами выстроятся в очередь”. Но правда оказывается жестокой: мир точно не ждал вашего проекта.
Что делать? Разговаривать с клиентами ДО первой строчки кода. Не спрашивать их, нравится ли им идея, а выяснять, готовы ли они заплатить конкретную цену за решение конкретной боли и почему?
Несколько лет назад, например, мы вместе с командой тестировали идею сервиса виртуальной очереди: подключившись к такой платформе любой бизнес (допустим, шиномонтажная мастерская) может управлять потоком клиентов. И по перспективности, и по потенциальному объему рынка идея была “живой”. Однако беседы с потенциальными клиентами раскрыли суть: платить за такой сервис они не будут. Прощаемся с иллюзией и идём дальше.
“Нас ждет быстрый рост”. Мечтаете увидеть диаграмму, растущую вверх, а по факту она напоминает кардиограмму умирающего. Это может демотивировать и провоцировать на необдуманные поступки. Здесь лучшее средство - отмечать микро-успехи. Первый постоянный клиент, первый “живой” отзыв от клиента. Рост - это лестница, шаг за шагом, и важно осознанно делать каждый из них.
Иллюзий может быть множество. Лучшая прививка от них - как можно быстрее позволить идее (даже если она существует на словах) столкнуться с реальностью. Для примера, только в прошлом году я внес на рассмотрение команде больше десятка идей, но ни одна из них не была реализована - это нормально. Делайте простые прототипы, проводите тесты, не бойтесь самой жесткой обратной связи. Именно после этого станет понятно, стоит игра свеч или нет.
Предупрежден - значит, не потеряешь деньги. Как не попасть в плен “иллюзий фаундера”?
Как фаундер, я хорошо знаю это состояние: классная идея захватывает твой разум. Кажется, что нужно совсем немного, чтобы пришел оглушительный успех.
Важно посмотреть на ситуацию честно. Какие иллюзии бывают у фаундеров?
“Если продукт крутой - клиенты сами выстроятся в очередь”. Но правда оказывается жестокой: мир точно не ждал вашего проекта.
Что делать? Разговаривать с клиентами ДО первой строчки кода. Не спрашивать их, нравится ли им идея, а выяснять, готовы ли они заплатить конкретную цену за решение конкретной боли и почему?
Несколько лет назад, например, мы вместе с командой тестировали идею сервиса виртуальной очереди: подключившись к такой платформе любой бизнес (допустим, шиномонтажная мастерская) может управлять потоком клиентов. И по перспективности, и по потенциальному объему рынка идея была “живой”. Однако беседы с потенциальными клиентами раскрыли суть: платить за такой сервис они не будут. Прощаемся с иллюзией и идём дальше.
“Нас ждет быстрый рост”. Мечтаете увидеть диаграмму, растущую вверх, а по факту она напоминает кардиограмму умирающего. Это может демотивировать и провоцировать на необдуманные поступки. Здесь лучшее средство - отмечать микро-успехи. Первый постоянный клиент, первый “живой” отзыв от клиента. Рост - это лестница, шаг за шагом, и важно осознанно делать каждый из них.
Иллюзий может быть множество. Лучшая прививка от них - как можно быстрее позволить идее (даже если она существует на словах) столкнуться с реальностью. Для примера, только в прошлом году я внес на рассмотрение команде больше десятка идей, но ни одна из них не была реализована - это нормально. Делайте простые прототипы, проводите тесты, не бойтесь самой жесткой обратной связи. Именно после этого станет понятно, стоит игра свеч или нет.
Представлен ИИ-сервис Vibetest Use, который тестирует сайты на прочность и ищет уязвимости. Параллельно запускаются сразу несколько проверок с помощью ИИ, которые ищут ошибки, битые ссылки или проблемы в дизайне. Работает на базе Claude. В качестве альтернативы можно запустить с бесплатным API от Google через Cursor.
Ближайшие события
Почему нужно использовать DTO
Data Transfer Object, термин, который для разработчиков на статических языках является чем-то самим разумеющимся, но вот остальные его могут не знать (даже если пользуются). Хотя в эпоху интеграций, фронтенд-бекенд, сервис-сервис, очереди, это крайне важная конструкция.
DTO это очень промежуточный объект между моделью в вашем коде и данными, которые вы отдаете наружу или принимаете от внешней системы.
Модель => DTO => json/protobuf/sql...
json/protobuf/sql... => DTO => Модель
Нафига? Почему не сразу преобразовывать из, допустим, json в нашу модель или наоборот? Тем более во всех экосистемах есть механизмы, которые позволяют упаковывать любые объекты, задавая правила преобразования через метаданные, аннотации или еще как-то. Пример из Java:
@Entity
public class User {
@Id
private Long id;
@JsonIgnore // приходится скрывать
private String passwordHash;
@JsonProperty("created_at")
private LocalDateTime createdAt;
// getters/setters ...
}
var json = new ObjectMapper().writeValueAsString(dto);Существует масса причин, почему это плохая идея. Для начала, это банальное нарушение MVC архитектуры. Модель начинает знать как о представлении, о том какие поля надо выдавать наружу, какие нет, как их переименовывать и так далее. Если это кажется натянутым, то вот вам реальные последствия.
Одна и та же сущность для внешнего мира редко представляется одним способом. В зависимости от задачи, это может быть один набор полей или другой. Как это разрулить? Дальше, здесь плохо контролируется процесс, легко может быть такое, что новое поле автоматически попало наружу, хотя вы этого не планировали, но забыли его исключить. А если нужны вычисляемые поля или другое представление (всегда в датах)? В такой ситуации модель будет наполняться доп свойствами и методами, которые готовят доп данные для преобразования, что ведет к сильному загрязнению кода. Что из этого относится к бизнес-части, а что к представлению? Проблема.
DTO позволяют отделить представление от модели в коде, создавая по сути промежуточный слой. Имея его, вы можете независимо развивать свою модель и API для взаимодействия с ним. И да, это один из аспектов MVC, конкретно Model-View.
Готовые DTO гораздо легче чем модели конвертировать в типы на TS если у вас есть такая потребность. Например мы наши DTO (используем Alba), превращаем в типы TS с помощью готового инструмента (Typelizer). С моделями так легко не получится.
За это конечно придется заплатить. В проекте появится папка, с большим количеством файлов. Но это с лихвой компенсирует все описанные выше проблемы. DTO очень простые и для их создания далеко не всегда надо с нуля писать классы. В той же java они генерируются с помощью mapstruct, в других языках свои механизмы.
Но это только базовая история. Если мы еще подключаем инструменты генерации из sql (как в go) или openapi как везде, то те самые DTO создаются вообще автоматически на основе описаний.
INSERT INTO links (original_url, short_name)
VALUES (sqlc.arg(original_url), sqlc.arg(short_name))
RETURNING *;DTO:
type CreateLinkParams struct {
OriginalUrl string `json:"original_url"`
ShortName string `json:"short_name"`
}Причем для update будет создана своя структура:
type UpdateLinkParams struct {
OriginalUrl string `json:"original_url"`
ShortName string `json:"short_name"`
ID int64 `json:"id"`
}Здесь отличается только id, но в реальных кейсах, отличий в создании или обновлении одной сущности обычно значительно больше, поэтому количество DTO тут становится еще больше.
DTO, кстати, должны быть имутабельны, иначе туда потечет логика
Больше про разработку в моем телеграм-канале Организованное программирование
Как собрать и внедрить свой корпоративный AI-чат
AI-чат — уже не просто модное словечко, а необходимый инструмент. Он облегчит коммуникацию, поможет автоматизировать задачи и повысить эффективность работы.
Зовем на вебинар, где расскажем, как развернуть собственное решение, чтобы оно отвечало требованиям безопасности и стабильно работало в вашем контуре.
Что еще обсудим:
Из каких open source решений на рынке мы выбирали и на чем в итоге остановились.
Почему свой AI-чат лучше SaaS? Приведем весомые аргументы.
Как собрать AI-чат, чтобы все было безопасно и не нарушало закон.
Какие архитектурные решения мы протестировали и к каким выводам пришли.
Будет интересно системным администраторам, IT-директорам, разработчикам и всем, кто хочет автоматизировать внутренние процессы с помощью корпоративного AI-чата.
📅 Когда? 27 ноября в 11:00 мск.
📍Где? Онлайн. Регистрируйтесь на странице вебинара — и до скорой встречи.
Держите порцию пятничного бреда: что, если скрестить механическую коробку и примитивный гидравлический автомат, обеспечивающий нормальную работу только на малых скоростях (упростив его за счёт этого), и прицепить его на место первой и обратной передач?
Следите за руками: там, где удобнее автомат (трогание в сложных условиях, раскачка в грязи, ползание отрезками в пробке) — врубаем «первую» (реально где-то до третьей) и едем, не насилуя сцепление и имеем все преимущества «плавного» преобразования. В нормальных условиях — перещёлкиваем на вторую и далее, имея все плюсы полного ручного контроля и плюсы по КПД (для того, чтобы оптимально выбрать передачу, нужно, как правило, знать будущее хотя бы на пол-километра вперёд, что определённым образом ограничивает возможности автоматики).
А поскольку автомат надо отцеплять от вала с обеих сторон (чтобы механика его «за хвост» не крутила) — можно заодно и придать ему функцию раздатки, ну, раз всё равно сцепные муфты ставить. Наши «первая» и «задняя» выходят на все четыре, раз уж мы всё равно собираемся пользоваться ими на малой скорости в лужах и ямах, а механика, работающая в условиях чистой дороги и экономии топлива — только на один мост с обычным дифференциалом (второй можно сделать с каким-нибудь необычным, чтобы гребли два от этого моста и как минимум одно от обычного).
Всё это пятничная чушь и пища для инженерных паззлов, конечно. Чисто поломать для развлечения голову «а как бы я это всё вписал в конструкцию». В наше время намного больше смысла в установке двух рекуперативных мотор-колёс вместо вторых обычных колёс (которые не ведущие). А если хочется оптимального ручного контроля (и заодно почувствовать себя пилотом «Сопвича», следящим за ста приборами одновременно) — такой гибрид с рекуперацией даёт в этом плане чуть ли не больше возможностей, чем любая механика (особенно если он с этой самой механикой и совмещён, и дважды особенно — на малокубатурных движках, которые и без электрики-то по жизни работают с полным сжатием, потому что находятся или в состоянии ХХ, или в состоянии «тапка в пол», без промежуточных значений, а уж если лишнее/недостающее берётся с мотор-колёс, то они вообще в своей стихии).
ЗЫ: добавил хаб «гаджеты», потому что вот. Не то что бы прямо в формате «гаджета», но в формате устанавливаемой опции-то уж точно.
ЗЫЫ: а что будет, если перевести классический мускулокар 60-х/70-х на пропан? Запас по мощности у него дикий, мы ничего особо не потеряем. А что мы получим в плюс? Цену за км? Возможность вписаться в современные экологические нормы?
Короче, всем пятницы :)
Скрытый налог: когда 1С висит, бизнес теряет деньги. Покажем, как «Монитор» снижает затраты с первой недели
Во сколько обходятся бизнесу простои из-за «тормозов» 1С? Компания может терять десятки тысяч рублей в день, а все потому, что команда технических специалистов ищет и не может найти ту самую ошибку. А можно превратить потери от простоев в компенсацию для бюджета.
25 ноября в 12:00 на вебинаре «Скрытый налог: когда 1С висит, бизнес теряет деньги» мы расскажем, как инструмент «Монитор» для 1С помогает бизнесу сокращать финансовые потери.
Спикер: Андрей Бурмистров, 1С-эксперт по технологическим вопросам крупных внедрений
В программе:
— примеры скрытых затрат при проблемах со скоростью работы в 1С;
— разбор ключевых функций Монитора (долгие запросы, блокировки, взаимоблокировки, ошибки технологического журнала, уведомления о событиях);
— ответы на вопросы участников.
Все участники вебинара получат в подарок 30-дневную триал-версию «Монитора» с бесплатной установкой от наших специалистов. За 1 день и 0 рублей вы увидите проблемы производительности вашей 1С!
ВАЖНО! С 1 января 2026 года меняется лицензионная политика продукта: на каждые 3 сервера необходимо будет покупать лицензию. До конца декабря есть возможность купить лицензию без ограничения по количеству серверов.
История, которая принесла нам миллион подписчиков
В этом кейсе рассказываем, как команда продуктовых дизайнеров прошла путь от идеи к реальному результату в мобильном банке. На старте был один запрос: сделать сервис, который будет действительно полезен и заставит клиента быстрее оформлять подписку на Альфа-Смарт.
Что за подписка? Это сервис, который позволяет клиенту улучшить свои привилегии и условия пользования продуктами за фиксированную стоимость в месяц.
В статье «Как мы запустили подписку в Альфа-Банке и собрали миллион подписчиков за полгода» история про то, как совместить креатив с аналитикой, провести десятки воркшопов и исследований, чтобы найти оптимальный сценарий. Если хотите узнать, как устроены самые успешные подписки в банке, какими фишками можно изменить отношение клиента к продукту и действительно выстроить лояльную аудиторию — переходите к кейсу по ссылке!
В маркетплейсе VK Cloud появилось сразу несколько новых решений, поэтому мы хотим, чтобы вы узнали, как с ними работать из первых рук во время вебинаров. Оба решения появятся в маркетплейсе накануне трансляций.
📌 26 ноября в 11:00 будем говорить о том, какие преимущества открывает РЕД База Данных. Почему это надежно, и как работает совместная поддержка в рамках SLA. Эфир проведет технологический евангелист VK Cloud Станислав Погоржельский и Алексей Бехтин, аналитик отдела разработки СУБД, РЕД Софт.
Что еще обсудим
🔷 Интеграция с прикладными системами. Как легко и быстро подключить РЕД Базу Данных к вашим приложениям, работающим в VK Cloud.
🔷 Кейсы и выгоды. Примеры из практики, демонстрирующие повышение производительности и снижение TCO (совокупной стоимости владения).
🔷 Разработка с помощью ИИ. Генерация приложения маркетплейса на Go с использованием СУБД РЕД База Данных.
📌 27 ноября в 11:00 начнем разговор про обеспечение безопасности данных в облаке с помощью Next Generation Firewall. Межсетевой экран позволяет контролировать трафик между ВМ, настраивать правила и вести мониторинг real-time.
Владислав Закрятин, инженер по предпродажной подготовке из Ideco, покажет в прямом эфире, как развернуть решение за 15 минут.
Кому точно стоит посетить вебинар
🔷 DevOps и SRE-инженерам.
🔷 Руководителям ИТ-направлений.
🔷 Всем, кто использует или планирует использовать облачную инфраструктуру.
Где учиться тестированию?
Привет! Мы на Хабр Карьере поняли: учиться намного проще, когда знаешь, с чего начать, а освоить новую профессию или развить имеющиеся навыки легко — достаточно выбрать качественный курс.
На нашей витрине много курсов по разным направлениям, а сегодня мы собрали для вас подборку для тестировщиков, ниже — ссылки на обучение ключевым направлениям:
— Автоматизация тестирования — создаёте скрипты, которые автоматически проверяют работу программы вместо ручного тестирования.
— Тестирование API — проверяете, как программы взаимодействуют между собой через интерфейсы.
— Тестирование веб-приложений — ищете баги и ошибки на сайтах и веб-сервисах.
— Кроссбраузерное тестирование — проверяете, как сайт или приложение работает в разных браузерах и на разных устройствах.
— Модульное тестирование — тестируете отдельные части программы (модули) на корректную работу.
— Нагрузочное тестирование — смотрите, как система ведёт себя под высокой нагрузкой или при большом количестве пользователей.
— Тестирование игр — ищете баги в играх, проверяете геймплей, графику и производительность.
→ на Хабр Карьере много бесплатных курсов — заглядывайте
