Когда тебя спрашивают про Питон, а ты только “Летающий цирк“ смотрел.
Всем добрый день! На днях позвонил товарищ и сказал, что проходит курс по Питону.
Сказал что понимает, что я пишу на 1С, но может ли он ко мне обращаться с вопросами. Хороший повод посмотреть что это за язык. Нужно какое-то ТЗ.
Пусть в SQL есть таблица «Prices» с двумя колонками. «Product», «Price». Требуется посчитать и вывести среднюю стоимость.
Средняя стоимость = Сумма/количество различных позиций.
Задача стоит. На чём её решать?
Есть компьютер с Windows 11.
В качестве движка БД думаю поставить SQLite. Так же нужно установить Python.
IDE наверное будет перебором, поэтому поставлю Sublime Text с каким-нибудь плагином. Так-с. Что я знаю о Python. Он полный по Тьюрингу. Блоки определяются отступами. Есть объекты…. Вроде всё.
Приступим. Что нам понадобится:
1. Установленная SQLite.
2. Созданная БД с нужными данными.
3. Объект «Подключение» в Python.
Так-с SQLite. На https://www.sqlite.org/download.html есть собранный для Windows. В принципе логично, но всё равно приятно… Ага, вот и первый нюанс. Есть DLL и есть tools.
Говорим на языке событий: что даёт ивент-шторминг и как его правильно провести
Привет! Я Иван Чернов, системный архитектор, в этом посте расскажу про ивент-шторминг.
В Островке есть набор сервисов, который разбит на логические блоки так, чтобы в рамках блока можно было итерировать: Островок, Островок B2B и Островок Командировки. При этом запускать новые фичи, которые будут сквозь эти слои прорезаться.
Мы растём по количеству и продуктов, и людей, нанятых для их разработки. Недавно начали толкаться локтями: не понимали, как качественно контрибьютить в большие кодовые базы, как они должны эволюционировать. Поэтому пришли к ивент-штормингу.
Что это за практика? На встрече с одной стороны сажаем бизнес, с другой — разработку. Просим бизнес рассказать, что и как он делает в работе с клиентом.
Ивент-шторминг проводится с фокусом на цикличную реактивность: происходит событие, которое визуально меняет что-то для пользователя, тот принимает решение и отдаёт команду, команда приводит к новому событию.
На этих циклах фокусируемся на доске в Miro во время встречи.
В ивент-шторминге 3 этапа:
1. Сейлзы выстраивают по циклам цепочку событий: от «клиента у нас ещё нет» до «клиент нас окончательно покинул». Даже в простых цепочках 20–30 действий. В готовом таймлайне есть happy pass: клиент успешно прошёл весь путь. И альтернативные пути: что-то пошло не так.
2. Проходим по таймлайну с конца, ищем ошибки. Выделяем ключевые события, которые нельзя откатить: клиент зарегистрировался, совершил бронирование, провёл оплату. Здесь происходит стык сервисов. На стыках обогащаем цепочку. Пишем, кто и что делает: актор-клиент зарегистрировался, подключился сервис юзер-менеджмента.
3. Выявляем, какие агрегаты работают с событием. Мапим команды: клиент регистрируется, в работе участвует команда регистрации.
Цепочка готова, мы получили полезный контекст, все одинаково понимают процессы и видят, что нужно делать, чтобы их улучшить.
Во время встречи составляем словарик. Если сейлз говорит непонятное разработчикам слово — мы его добавляем в словарь, и оно просасывается в наш интерфейс и кодовую базу. Всё это учит разработчиков понимать, на какие рычажки они влияют своим кодом.
Поделюсь советами, как круто провести ивент-шторминг.
Онлайн-формат
● Для проведения онлайн достаточно доски в Miro.
● Разбивайте встречу на три части, каждая встреча — один этап.
● На последней встрече отпустите бизнес, выявите агрегаты и сервисы, задействованные в таймлайне с разработкой.
● Максимум людей для успешной фасилитации онлайн — 8–10 человек.
● Ищите представителей бизнеса в оргчате выбранного домена: спрашивайте у руководства, «кто тут самый инициативный».
● Вам нужны работники «с полей», которые лучше всего шарят в процессах, и тимлиды первого уровня.
● Берите людей из разных направлений домена.
● Бизнес-участники должны понимать: ивент-шторминг — процесс обучения, они эксперты, а разработка — ученики. Им нужно говорить на своём языке, а не подстраиваться под разработку.
● Дайте участникам базовый словарь. Четыре самых важных слова: актор, команда, событие, термин.
● Важны вводные по времени и цели: на сессию уйдёт суммарно 6–8 часов, она даст единое понимание процессов.
Фасилитация
● На старте не бойтесь повторить все вводные.
● Дайте сейлзсам 10 минут на то, чтобы каждый выстроил индивидуальный таймлайн, дальше начинайте мёржить таймлайны с общим обсуждением.
● Событие — факт в прошедшем времени, его не отмотать. Следите, чтобы так и записывали.
● Первым делом простройте happy pass, иначе у вас не выстроится цельное видение процесса. Альтернативные ветки обозначьте на первом этапе, а достраивайте на втором, проверяя таймлайн с конца.
● Если бизнес утверждает, что два события происходят одновременно, это важная точка обсуждения.
● Организуйте пост-процессинг: важно передать разработке результаты, объяснить, какие процессы у нас уже верно реализованы, а где нужно обновление и дополнительное внедрение.
Что такое архитектура ПО и почему она не про красивые диаграммы
Изображение сгенерировано при помощи DALL-E 3
🏗️ Архитектура программного обеспечения — это не просто модное слово для повышения ставки на собеседовании. Это фундамент, на котором строится вся система.
Что это такое на самом деле? Архитектура ПО — это структура компонентов системы, их взаимосвязи, взаимодействия с внешней средой и принципы разработки. Звучит скучно? А вот и нет! Это как план города: без него у вас получится не Москва, а какая-то деревня Гадюкино с кривыми улочками.
Зачем это нужно?
Снижает сложность системы через декомпозицию
Определяет рамки развития (чтобы не росло как раковая опухоль)
Помогает команде говорить на одном языке
Экономит нервы и деньги в долгосрочной перспективе
Под капотом архитектура отвечает за: ✅ Разбиение системы на модули (как LEGO, только для взрослых) ✅ Способы взаимодействия компонентов (REST, RPC, события) ✅ Распределение ответственности между модулями ✅ Выбор технологического стека
Простой пример: Представьте интернет-магазин. Без архитектуры у вас будет один гигантский файл на 50,000 строк, где корзина покупок живёт рядом с логикой оплаты, а пользовательские данные перемешаны с каталогом товаров. С архитектурой — отдельные модули: UserService, CatalogService, PaymentService, каждый со своей зоной ответственности.
🔧 Давайте разберём базовые понятия архитектуры, без которых никуда. Это как алфавит — скучно учить, но без него читать не получится.
Компонент — часть системы, выполняющая изолированную функцию. Думайте о нём как о сотруднике в компании: у каждого своя роль, свои обязанности, и если он заболел — его можно заменить.
Пример компонентов:
Authentication Service (следит, чтобы чужие не лезли)
Notification Service (шлёт уведомления)
Data Storage (хранит данные, очевидно)
Интерфейс — способ взаимодействия между компонентами. Это как протокол дипломатии: все знают правила игры, никто не лезет с кулаками.
Типы интерфейсов:
REST API (классика жанра)
Message Queue (асинхронные сообщения)
RPC (удалённые вызовы)
Database API (работа с данными)
Связи — физические или логические каналы передачи данных между компонентами. Это как дороги в городе: определяют, кто с кем может общаться и как.
Примеры связей:
HTTP-соединения (веб-траффик)
TCP/UDP сокеты (низкоуровневая связь)
Message Brokers (Apache Kafka, RabbitMQ)
Database connections (пул соединений с БД)
Модуль — логическая группировка компонентов по функциональности. Это как департаменты в компании: HR, IT, Бухгалтерия.
Примеры модулей:
User Management Module (всё что касается пользователей)
Payment Processing Module (платежи и транзакции)
Analytics Module (метрики и отчёты)
Сервис — автономная единица бизнес-логики с чётко определённой ответственностью. Это как мини-приложение внутри большого приложения.
Примеры сервисов:
Order Service (управление заказами)
Inventory Service (управление товарами)
Billing Service (выставление счетов)
Хранилище данных — компонент, отвечающий за персистентность информации. Это как склад или архив компании.
Типы хранилищ:
Реляционные БД (PostgreSQL, MySQL)
NoSQL (MongoDB, Redis)
Файловые системы (S3, локальные диски)
Кэши (Redis, Memcached)
SLA — характеристики работы сервиса. Это контракт: "обещаю работать 99.9% времени и отвечать за 200ms".
Зачем нужны SLA:
Понимание ожиданий от системы
Планирование мощностей
Определение критичности сервисов
Основа для мониторинга
Практический пример: Сервис авторизации должен:
Отвечать за 100ms в 95% случаев
Быть доступным 99.95% времени
Выдерживать 1000 RPS
Чеклист для правильного проектирования: ✅ Каждый компонент имеет чёткую ответственность ✅ Интерфейсы документированы ✅ Связи (способы взаимодействия) определены ✅ Деление на сервисы произведено ✅ Способ хранения данных определен ✅ SLA определены и измеряемы ✅ Зависимости между компонентами минимальны
Помните: хорошая архитектура начинается с понимания базовых элементов. Без этого ваша система превратится в спагетти-код корпоративного масштаба.
Как устроена стажировка на backend в Альфа-Банке — вся правда изнутри
Хочешь знать, дают ли стажёрам настоящие боевые задачи, или ты просто будешь «перекладывать JSON-ы»?
Интересно, реально ли совместить учёбу и удалённую работу и почему документация — это не халява, а адреналиновый квест?
Не хочешь в очередной раз читать банальности о «стажёрском выживании», а узнать всё по-честному: от первой ошибки на собесе до рефакторинга в большом проде?
Меня зовут Кирилл, я студент 3-го курса НИУ МЭИ, направление — «Информатика и вычислительная техника», а также Junior Python Backend-разработчик в Альфа-Банке. Написал статью «Самое главное о том, как проходила моя стажировка на backend-разработчика» для студентов и ребят без опыта работы. Читайте, чтобы узнать, как в Альфе растят специалистов — и что делать, чтобы вам тоже предложили войти в команду после стажировки!
Что ты сделал для хип-хопа IT-инфраструктуры в свои годы? Писал UEFI и BMC для высоконагруженного оборудования
В YADRO есть распределенная команда, которая разрабатывает и сопровождает собственные программные реализации UEFI (BIOS) и BMC. Для самого разного оборудования — от серверов до телеком- и клиентского оборудования.
Реализуют программную поддержку новых аппаратных продуктов компании, определяют протоколы и методы взаимодействия между программными и аппаратными компонентами продуктов YADRO.
Проводят верификацию микрокода и выполняют проверку прошивок микросхем всех продуктов компании. Выстраивают стратегию тестирования.
Исследуют новые программные и аппаратные технологии для применения в продуктах. Рефакторят код для повышения производительности.
Придумывают методы безопасного обновления прошивок BIOS и BMC, чтобы обеспечить минимальный или нулевой даунтайм.
Добавляют новые фичи и меняют существующие — от WebUI до политик управления аппаратными компонентами.
Команде нужно больше инженеров — разработчиков на С/C++, тестировщиков, автоматизаторов и техлидов. Знакомься с вакансиями на сайте и вовлекайся в трушные инженерные задачи на современном технологическом стеке.
Под пост в телеграм про наш ответ аналог Grafana пришли руководители "Лаборатории Числитель" и конкретно "Пульта", в чью систему входит платформа мониторинга и анализа "Графиня".
Дмитрий Унтила и Владимир Утратенко любезно ответили на ряд вопросов по платформе, и я хотел бы подвести краткое резюме:
Запрос на аналог Grafana появился в момент продажи "Пульта", так как "не всем можно брать забугорный опесорс себе в контур. Потому решили делать. А название Графиня просто ради лулзов."
Графиня писалась с полного нуля. Хотя предложение взять за основу Grafana было, но команда смогла обосновать геморрой, который на неё упадёт, если взяться за доработку, и объяснила руководству, почему лучше сделать с нуля.
Время разработки: 3 месяца - MVP, 6 месяцев - 1 релиз.
На мое предложение сделать проект опенсорс Дмитрий Унтила пообещал подумать. Но, понятное дело, если это часть коммерческого продукта, прям сильно думать в лаборатории не будут))
Демо-стенда в интернете пока нет, можно только записаться на показ системы через форму обратной связи.
Благодарю парней за такой актив и обратную связь, рад, что у людей есть на это время!
Многие крупные компании применяют Go, а спрос на опытных инженеров, владеющих Go, высок как никогда. Онбординг проходит действительно быстро, и у нас есть успешные тому примеры. Все благодаря общей простоте языка и отсутствию function coloring. В карточках рассказываем, как это получилось у Кирилла в 2ГИС↓
Не говнокод, а плодородная почва для прекрасного кода будущего.
Знакомо ли вам это чувство, когда вы приходите в проект — и вам кажется, что вокруг один говнокод? Нет, не кажется. Я называю это "нарастающим циклом улучшения кода". Каждый новый разработчик уверен: до него было плохо, а теперь всё станет хорошо. И каждый следующий — тоже. Забавно, но никто не догадывается, что предыдущий думал ровно то же самое.
Наивный скажет: это просто борзость и переоценка собственной крутости. Но что, если это правда? Что если каждый новый код действительно лучше предыдущего? Ведь тот самый "говнокод", что вы нашли, вполне возможно, когда-то заменил ещё больший ужас. Просто вы этого уже не видите.
Так что всё хорошо: код проекта действительно улучшается. А твой код — плодородная почва для прекрасного будущего.
Язык Go называют одним из самых удобных для бэкенда. Дело тут не в примитивности: его специально стремились сделать простым и лаконичным, чтобы пользователям было легко работать с синтаксисом и понимать чужой код.
Если вы уже знакомы с Go, но не хватает практики, приглашаем пройти новый курс в Академии Selectel. С ним вы научитесь писать простые сервисы на Go и использовать его в некоторых рабочих задачах, а еще получите большую подборку ресурсов для погружения в этот язык.
Что делает данный код? Читает сообщения из first-topic, парсит из них поле user типа str, выполняет вашу логику обработки, отправляет новое сообщение в another-topic. Просто? Удобно? Да!
Что нам дает такой подход?
Декларативное описание, чего мы хотим. Не надо руками создавать коннекты и рулить потоком выполнения
Собрали обзор для тех, кто только начинает работать с базами данных — рассказываем, что такое шардирование и как этот способ решает задачи перераспределения нагрузки в БД.
Шардирование (или шардинг) представляет собой метод распределения данных между несколькими отдельными частями — шардами. Такой подход позволяет эффективно распределять нагрузку на систему, быстро масштабироваться и повышать отказоустойчивость системы.
Как это работает: каждый шард располагается на отдельном сервере или группе серверов, что позволяет выполнять запросы параллельно. Для гарантии отказоустойчивости шардирование обычно комбинируется с репликацией — созданием копий шардов. Без репликации отказ одного из серверов может привести к потере данных или недоступности части системы. При этом шардирование БД не заменяет процессы репликации и партицирования. Основная задача шардинга — разделить общую базу данных на части по определенным критериям.
Привет! Мы на Хабр Карьере собираем сотни онлайн-курсов в IT или digital на маркетплейсе курсов, и каждую неделю делаем подборки обучений для тех, кто хочет учиться какой-то специализации с нуля или для тех, кто уже в профессии, но чувствует, что хочет прокачать навыки. Сегодня — про программирование.
Вообще все курсы по специализации можно посмотреть здесь, а ниже оставляем ссылки по ключевым навыкам:
Разработка и клиентской, и серверной части. Обычно включает знание одного backend-языка, JavaScript/TypeScript и одного из фреймворков (React, Vue, Angular).
Ранее в Amvera Cloud, были возможны откаты только путём новой сборки из нужного коммита в Git-репозитории. Помимо этого, использовалась медленная технология сборки.
Мы ускорили сборки до 10 раз и сделали возможность быстрого отката к предыдущим версиям!
Стало легче откатывать приложение, в случае ошибок.
Подключить быстрые сборки можно в разделе проекта «Контроль версий».
Интерфейс управления версиями сборок
Новые сборки
Быстрее старых до 10 раз.
Позволяют откатываться к предыдущим версиям одной кнопкой. Это полезно, если вы случайно накатили баг и надо вернуться к прошлой версии.
Amvera Cloud – облако для простого запуска проектов со встроенным CI/CD (деплой идёт через Git или загрузку файлов в интерфейсе), бесплатными https-доменами, мониторингом работы приложений, встроенным проксированием до ведущих LLM и собственным инференсом LLaMA.
Вам не нужно думать о настройке инфраструктуры. Git push amvera master и ваш проект запущен. Зарегистрируйтесь и получите 111 рублей на тест.
В PEP 798 предлагается расширить возможности коллекций (списки, словари, множества) и генераторов, разрешив операции распаковки (* и **) внутри выражения.
Способ позволит лаконично в одну строку объединять произвольное количество итерируемых объектов в одну коллекцию:
[*it for it in its] # список с объединением итерируемых элементов в 'its'
{*it for it in its} # множество с объединением итерируемых элементов в 'its'
{**d for d in dicts} # словарь с комбинацией словарей в 'dicts'
(*it for it in its) # генератор с объединением итерируемых элементов в 'its'
В данный момент объединение списков мы осуществляем с помощью циклов:
# с помощью генератора
its = [[1, 2], [3, 4], [5]]
new_list = [x for it in its for x in it]
# с помощью метода extend
new_list = []
for it in its:
new_list.extend(it)
# для множеств и словарей с помощью метода update
new_set = set()
for it in its:
new_set.update(it)
new_dict = {}
for d in dicts:
new_dict.update(d)
# также возможно использовать генераторную функцию (yield)
def new_generator():
for it in its:
yield from it
Предложение распространяется также на асинхронные выражения.
В данный момент предложение находится на стадии черновика.
Как создать мультиаккаунт-ферму для любых целей: от TikTok до Amazon
Мультиаккаунтинг — основа множества задач: от продвижения в соцсетях и тестирования антифрод-систем до арбитража трафика, отзывов, заказов и автоматизации серых схем. Эта статья — техническое руководство по созданию собственной мультиаккаунт-фермы.
1. Зачем нужна мультиаккаунт-ферма
Массовое создание и управление аккаунтами востребовано в:
Огромное спасибо: Поддержка ChatGPT на sqlize.online восстановлена! 🎉
Привет, сообщество!
У меня есть невероятно крутые новости!
Благодаря вашей потрясающей щедрости и пожертвованиям, которые мы получили, мы собрали средства, необходимые для восстановления и продолжения интеграции ChatGPT на нашей платформе! 🥳
Ваша поддержка значит для меня очень много. Она напрямую покрывает расходы на API OpenAI, гарантируя, что такие функции, как генерация запросов на естественном языке и умная помощь по SQL, остаются доступными для всех.
Мы запустили sqlize.online как доступный инструмент для изучения и работы с SQL, и возможности ИИ являются ключевой частью этого проекта. Знание того, что многие из вас ценят этот сервис и помогли поддерживать его работу, по-настоящему мотивирует.
Это доказательство силы сообщества! Спасибо вам за веру в sqlize.online и за помощь в поддержке ресурсов для блага всех энтузиастов и профессионалов SQL.
Мы обязуемся продолжать совершенствовать sqlize.online и расширять ваши возможности в работе с данными.