Разработка

Роадмап для начинающих питонщиков

Изучение Python может показаться сложным, но с правильным подходом и пониманием ключевых аспектов процесс станет понятным и увлекательным. Привет, я Иван Чернов, senior system architect, кратко расскажу, как начать вкатываться в Python, с какими проблемами сталкиваются новички и как их преодолеть.

Первые шаги

Определяемся с направлением, в котором вы хотите развиваться. Это может быть веб-разработка, машинное обучение, DevOps и т. д. Каждое направление требует своих знаний и навыков. Поэтому важно понять, что конкретно вам интересно и на какой позиции не будет скучно или слишком сложно.

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

Когда определились с направлением и изучили теорию — проходите курсы с практическим обучением или начинайте работать с кодом сами. Всегда лучше писать, чем читать. Как только вывели “Hello, World!”, переходите к обучающим программам, где первые задачки применимы к жизни. Например, на некоторых курсах учат разрабатывать Telegram-бота под ваши нужды. Это отличная практика для понимания процессов.

Также можете прочитать базу «Питона» — книгу “Automated Boring Stuff with Python”. В ней много практических задач, которые помогут вам освоить язык. А ещё есть полезный курс “Learning How to Learn”, который учит, как правильно учиться, опираясь на достижения нейронауки.

Этап, на котором новички отваливаются

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

Чтобы облегчить старт, можно для начала научиться использовать онлайн-среду разработки, например Replit. Можно просто зайти на сайт, выбрать язык Python и сразу приступать к написанию кода. 

Replit — это сервис для вайб-кодинга. В нём можно быстро экспериментировать с задачами и сразу видеть результат. Так вы сконцентрируетесь именно на изучении языка, а не на технических сложностях.

Тут есть большое «но»: на вайб-кодинге далеко не уедешь. Использование онлайн-сред — это чит-код, который облегчает старт, но не учит решать реальные проблемы. Так что с комплексной инфраструктурой всё же придётся разобраться.

Концептуальные вопросы

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

Например, в Python переменная может принимать разные значения, что противоречит математическим представлениям. Это может привести к путанице и неправильному пониманию основ программирования. 

Важно понимать, что программирование — это не только про то, как писать код, но и о то, как мыслит как программист. Необходимо развивать критическое мышление и осознавать, что многие концепции, которые мы учили на уроках математики, могут быть неверными в программировании. 

Советы начинающим питонщикам

• Постоянная практика. Пишите код каждый день, хотя бы немного. Работайте над проектами, которые вас интересуют, и решайте проблемы, которые вас раздражают. Я в 2010-м хотел, чтобы дома лампочка включалась по голосу. С помощью Python удалось сделать это.

• Изучайте чужой код. Чтение и понимание чужого кода поможет вам увидеть, как другие решают задачи и какие подходы используют. Однако не стоит изучать рандомный код. Лучше ищите тот, что поможет улучшить ваши проекты. 

• Go sport, go team. Физическая активность способствует лучшему усвоению информации. Поэтому не забывайте делать перерывы и заниматься спортом.

Заключение

Определитесь с направлением, изучите теорию, но не медлите с практикой. Не пугайтесь сложностей инфраструктуры: всегда можно нагуглить или спросить на форумах. Пользуйтесь онлайн-средами, но не делайте большую ставку на вайб-кодинг. Не бойтесь начинать и ошибаться — и у вас всё получится.

Если вдруг кто не знал, как я. Для обозначения графических схем архитектуры программного продукта, которые изображают маркетологи и продуктовые менеджеры в презентациях, т.е. те которые не совсем технические, существует термин - это "маркетектура".

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

Но это ещё не всё. То что мы привыкли считать технической архитектурой, т.е. описывающей компоненты и их взаимодействие, тоже имеет термин - это "тархитектура".

Время от времени я вольно или невольно возвращаюсь к теме RS-триггера. Время проходит, а «народ», как не понимал его, так и не понимает. Таблица истинности (ТИ), запрещенные состояния упорно всплывают, как непотопляемый Ванька-встанька. Но сколько раз твердили миру, что ТИ – это про истинно комбинационные схемы, а RS-триггер - посконно последовательностная схема (последовательностная – это не ошибка). А запрещенные состояния? Кто, где и каким указом запретил их?  Так он и послушался?! Все в сумме - верх безграмотности! Чем бы это не оправдывалось. Например, желанием упростить описание.

И пусть, сцепив зубы - упростили, зажав совесть в кулак – запретили и, наступив на гордость, пошли на поводу. Однако, казалось бы, можно, сохранив реноме, намеком, эзоповым языком сказать, что картина-то другая.  Но совесть и гордость не страдают, а Эзоп просто отдыхает, т.к. почти невозможно отыскать источники, где истина о триггере открывается без прикрас и упрощений.  А потому те, кто глаголет о триггере, похоже, как его представляют, так о нем и пишут. Их совесть, и гордость ни что не беспокоит. Но, как быть с реноме?

Может, я что-то не понимаю? Конечно, не в RS-триггере.  С ним мне давно все ясно, как и понятна его роль в нынешнее бурное время становления параллелизма.

Но беда в том, что искусственный интеллект в лице того же DeepSeek «гонит» о триггере все ту же чушь. Его несложно, правда, убедить  в обратном. Конечно, обосновывая, конечно, доказывая. И надо отдать ему должное  он все схватывает буквально на лету, а  о чем-то, что тоже поражает, даже догадывается. Это обнадеживает. Не зря ли только?   

Однако, ИИ быстро забывает, чему его учишь. А это уже другая беда. Возможно, не такая уж большая, т.к. учить – не проблема. При этом, у человечества есть все, чтобы поставить точку в понимании RS-триггера, а заодно и параллелизма и, исправив учебники, научить этому и ИИ. Но оно почему-то эту точку не ставит? Что мешает?

А что вы думаете о RS-триггере? И в целом о ситуации?      

Сентябрь: много вакансий у нас в SSP SOFT

Наступает осень, а значит и высокий сезон в IT. У нас больше 20 вакансий в командах аналитиков, девопсов, QA и разработчиков. Полный и актуальный список вакансий здесь: https://spb.hh.ru/employer/5648224.
Но откликаться на хх необязательно — внизу дадим прямые контакты с нашим HR.

Напомним, кто мы: компания SSP SOFT занимается заказной разработкой и IT-аутсорсингом. Наши спецы помогают внешним клиентам реализовывать задачи в e-commerce, финтехе, медтехе, управлении инфраструктурой и других отраслях.

Рабочие места в офисах в Москве (топ локация в ЦАО) и в Томске, а также у нас много сотрудников, которые работают удаленно из разных регионов России. Формат «онлайн» или «оффлайн» обсуждаем.

Резюме на вакансии 1С, Elixir, Ruby, девопс и инфобез — рассмотрим в приоритетном порядке.

• Data Scientist

• DevOps-инженер

• Data Scientist

• DevOps-инженер

• Сетевой инженер

• Тестировщик 1C

• QA Auto Java

• Automation QA Engineer (Lead)

• Elixir разработчик

• Middle Java Developer

• Ruby Developer

• Jira Developer

• С++ Developer (Senior)

• Ведущий разработчик 1С (ERP, УХ)

• Разработчик 1С (ЗУП)

• Разработчик DWH

• Аналитик DWH

• Ведущий аналитик 1С ERP

• Аналитик 1С (Управление недвижимостью и арендой)

• Аналитик 1С (регламентированный учет)

Мы ценим сотрудников — работа без лишней бюрократии — акцент на задачи, которые приносят результат и развитие профессиональных навыков.
🎁 Наши бонусы: ДМС со стоматологией, обучение за счет компании, бонусная программа.

👉 В SSP SOFT мы рассматриваем найм с прицелом на долгосрочную совместную работу. Многие сотрудники у нас работают по 5 лет и более.

Резюме можно направить нам напрямую в Telegram или на почту job@ssp-soft.com.

А для ускоренного рассмотрения пож-та отправляйте резюме HR-ру в Телеграм с пометкой "Нашел(ла) вас на Хабре", приложив сопроводительное письмо.

Как триггерить события для плагинов на манер Joomla 5+?

В Joomla 6 должны удалить метод triggerEvent(), с помощью которого раньше вызывались события для плагинов. Теперь чтобы в своём коде вызвать событие для плагина и получить от него результаты нужно:

• создать объект класса события

• передать в него именованные параметры

use Joomla\CMS\Event\AbstractEvent;
use Joomla\CMS\Factory;
use Joomla\CMS\Plugin\PluginHelper;

// Грузим плагины нужных групп
PluginHelper::importPlugin('system');
// Создаём объект события
$event = AbstractEvent::create('onAfterInitUniverse', [
    'subject' => $this,
    'data'    => $data, // какие-то данные
    'article' => $article, // ещё материал вдовесок
    'product' => $product, // и товаров подвезли
]);
// Триггерим событие
Factory::getApplication()->getDispatcher()->dispatch(
    $event->getName(), // Тут можно строку передать 'onAfterInitUniverse'
    $event
);
// Получаем результаты
// В случае с AbstractEvent это может быть не 'result',
// а что-то ещё - куда сами отдадите данные.
// 2-й аргумент - значение по умолчанию, 
// если не получены результаты
$results = $event->getArgument('result', []);

Плюсы такого подхода - вам не нужно запоминать порядок аргументов и проверять их наличие. Если вы написали свой класс события, то в плагине можно получать аргументы с помощью методов $event->getArticle(), $event->getData(), $event->getProduct() и подобными - реализуете сами под свои нужды.

Если такой класс события написали, то создаёте экземпляр своего класса события и укажите его явно в аргументе eventClass

use Joomla\Component\MyComponent\Administrator\Event\MyCoolEvent;

$event = MyCoolEvent::create('onAfterInitUniverse', [
    'subject'    => $this,
    'eventClass' => MyCoolEvent::class, // ваш класс события
    'data'       => $data, // какие-то данные
    'article'    => $article, // ещё материал вдовесок
    'product'    => $product, // и товаров подвезли
]);

Ожидаемо, что класс вашего события будет расширять AbsractEvent или другие классы событий Joomla.

🙁 Есть неприятный нюанс - нельзя просто так вызывать событие и ничего не передать в аргументы. Аргумент subject обязательный. Но если вы всё-таки не хотите туда ничего передавать - передайте туда пустой stdClass или объект Joomla\registry\Registry.

Чат русскоязычного Joomla-сообщества.

Давайте поделим пользователей на опытных и тех кто не любит читать FAQ

Меня уже очень долгое время беспокоит необходимость пробиваться через ботов и ИИ помощников чтобы получить ответ от поддержки. Это касается и телекома / банков / маркетплейсов и много кого еще.

Я разраб, поэтому чаще всего сначала обращаюсь к документации / читаю сайт или FAQ / ищу в интернете информацию до того, как написать. Я не хочу никого отвлекать. Кроме того, часто приходится ждать ответа долго.

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

Давайте уже признаем, что есть люди, которые поискали сами и скорее всего им поможет только оператор! И бизнесу желательно с этим считаться... А вы как думаете?

Провидец поневоле

Пару дней назад писал (https://habr.com/ru/articles/944756/) про supply chain-атаки и то, что зависимостям доверять на 100% — плохая идея.

И вот — крупнейшая атака в истории npm.

8 сентября хакеры через фишинговое письмо угнали аккаунт известного разработчика. Скомпрометировали даже 2FA.

В npm вылетели вредоносные версии debug, chalk и ещё около 16 пакетов. Общий охват — 2.6 миллиарда загрузок в неделю.

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

Внимание! Ущерб!
Он оказался смехотворным, украли они… около $500.
По одной версии — даже меньше $50. Весь этот хай-тек-рэкет ради пары мем-коинов.

Но важен не ущерб, а охват. Взломали не маленький плагин с тремя установками в месяц, а пакеты, от которых зависит половина экосистемы.
Повезло, что жулики переоценили количество криптомиллионеров среди разработчиков)

От заката до рассвета. Почему контроля ИБ в рабочее время недостаточно

Привет! Сегодня вышел новый выпуск подкаста «Метод хакера», в котором заглянули за кулисы ночной жизни корпоративных систем.

Что происходит с информационной безопасностью, когда сотрудники уходят домой, а серверы остаются наедине с внешним миром? Увы, угрозы не придерживаются графика 9-to-5.

• Обсудили основные проблемы информационной безопасности в нерабочее время.

• Поделились инфой о типичных случаях нарушений и возможных последствиях.

• Отметили современные технологии защиты информации.

• Описали методы минимизации рисков в нерабочее время.

• Дали практические рекомендации по обучению сотрудников.

• Построили перспективы развития систем информационной безопасности.

Эксперт выпуска — Данил Никитин, presale компании InfoWatch.

Где слушать

• Сайт подкаста

• Яндекс Музыка

• Apple podcasts

• Spotify

• Deezer

• ЗВУК

• Castbox

• VK Podcasts

• mave.stream (Telegram)

• Mave

• Pocket Casts

• Podcast Addict

• Soundstream

До и после fine-tuning — что изменится в работе модели после дообучения? 🧠

Fine-tuning, или дообучение — это дополнительное обучение уже готовой модели на специализированных данных, чтобы она лучше выполняла узконаправленные задачи.

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

Для чего же подойдет fine-tuning?  👇

1. Исправление слабостей, если модель в чем-то проседает. Иногда стартовая модель не очень хорошо решает базовые задачи: путает термины, особенно если они схожи, или дает сложные нечитаемые ответы. Такое бывает, когда в обучающем датасете больше данных, например, на английском, а пользователи общаются на русском. Проблема решится, если дообучить модель на качественных данных с хорошими примерами, чтобы та поняла, что от нее требуется.

2. Обеспечить работу с минимумом задержек. В некоторых сервисах важно, чтобы модель отвечала мгновенно, а не обращалась за информацией к внешней базе знаний — это увеличивает время ответа. Вы можете дообучить модель на собственных данных, чтобы она быстро получала нужные сведения.

3. Глобально изменить датасет. Бывает, что многое из той информации, что использует модель, устаревает, или существенно меняются требования в предметной области. Тогда есть смысл собрать побольше качественных данных и провести дообучение на них.

4. Генерация текстов в специфичном стиле. Допустим, вы хотите, чтобы модель заполняла документацию в конкретном формате, использовала юридический стиль, оформляла тексты по ГОСТ или писала как Достоевский. Подогнать стиль ответов модели под нужный формат — задача, которую можно решить с помощью fine-tuning.

🤔 Что в итоге? Fine-tuning незаменим, если нужно поменять стиль ответов, подогнать тексты под конкретный формат, исправить изначальные слабости. Или когда важно, чтобы модель давала ответы без задержек и не ходила во внешние источники. Подробнее про fine-tuning, а еще про RAG и промпт-инжиниринг читайте в нашей статье. 

А для дообучения вы можете использовать Evolution ML Finetuning — технология LoRA позволит сэкономить ресурсы GPU и ускорить процесс. Доступны модели из Hugging Face: сравнивайте их между собой, выбирайте подходящую и точечно настраивайте под свои задачи.

Я проснулся, делал зарядку и размышлял о поиске работы, и вот что я осознал:

Эйчары не понимают бизнес.

Бизнес не понимает эйчаров.

Эйчары не понимают технарей.

Технари не понимают эйчаров.

Бизнес не понимает технарей.

Технари не понимают бизнес.

Как следствие - эйчары нанятые бизнесом чтобы нанять непонятных для них технарей, нанимают еще хуже чем нанял бы бизнес, потому что эйчары не понимают ни бизнес, ни технарей.

Делегирование делегированием, а эффективность эффективностью.

Еще:

Бизнес конкурирует с бизнесом.

Эйчары конкурируют с эйчарами.

Технари конкурируют с технарями.

И все конкурируют со всеми.

Как следствие - на технических собесах технари с обеих сторон стремятся доминировать друг над другом. Так как решение о наеме принимает собеседующая сторона, то она имеет преимущество над соискателем и ему приходится подстраиваться.

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

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

Выводы:

Собеседования которые проводит не "бизнес" - не помогают бизнесу найти нужных людей, а наоборот мешают ему это сделать.

Бизнес который делегирует наем рано или поздно оказывается в положении "свой среди чужих, чужой среди своих", фактически самым ценным ресурсом компании - людьми - теперь владеет не Бизнес, а Технарь и HR.

Такие дела.

Вот еще интересные мысли о наеме, с которых все началось:

Бизнес строит воронку наема, из эйчаров и технарей, в несколько этапов, и вроде все логично, происходит отсев неподходящих и выбор подходящих.

Первичный отсев простейший и почти не требует затрат. Затраты начинаются на этапе собеседований. Фактически компания тратит силы, время и деньги на каждое собеседование.

Понимают ли они то что происходит во всей полноте? Похоже что нет, иначе процесс был бы устроен другим образом.

А происходит следующее: соискатель приходит на собеседование, обучается на нем правильно отвечать на вопросы, если проходит то устраивается на работу, если не проходит, то идет на следующее собеседование, и так пока не устроится.

Т.е. фактически компания которая дала отказ соискателю, затратила ресурсы, обучила соискателя, и передала его другой компании. Вот что происходит на самом деле.

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

А теперь вернись к началу, вероятно теперь станет понятно откуда взялись такие тезисы :)

P.S. Похоже всё это не является проблемой только потому, что получается микро-коммунизм в наеме. Одна компания обучает соискателей для другой, и та в свою очередь делает так же. По сути работает не система наема в компании, а побочные эффекты от нескольких систем наема разных компаний.

Откуда такие мысли:

Я уже 12 лет как в теме, и устраивался на работу сам, и искал людей на свои проекты, и собеседовал как технарь(в Android разработке) на проекты бизнеса. В общем я пощупал этого слона с разных сторон, и теперь когда я снова в активном поиске - это сложилось в объемную картину.

Поиск скомпрометированных зависимостей через Dependency Track

На днях стало известно о компрометации почти 2-х десятков npm-пакетов (подробнее в этой статье). Зловредный код может похищать криптовалюту. Это не первый раз, когда в зависимости попадает зловред (например, в 2022 году зловред удалял данные).

Один из вариантов поиска наличия скомпрометированных пакетов среди сотен проектов - использование Dependency Track. При этом поиск возможен и в транзитивных зависимостях тоже. На картинке ниже показан процесс. Заходим в раздел "Components", вводим название в формате "pkg:npm/$name$". Далее остаётся отсортировать по версии и найти среди них скомпрометированную (сейчас это легко - нужно смотреть самую старшую версию). Можно поиск производить сразу по конкретной версии. Пример:

pkg:npm/simple-swizzle@0.2.3

Если пакет нашёлся - можно не только узнать в каком именно проекте, но и увидеть где именно в дереве зависимостей проекта используется (нажать на иконку, обведённую красным).

Если знаете альтернативные варианты поиска скомпрометированных пакетов другими средствами - напишите в комментариях.

Совет по Joomla: значение переменной по умолчанию с помощью класса Joomla\Registry\Registry.

Очень часто в Joomla мы видим, что данные приходят не в виде массива или простого объекта (stdClass), а их нужно получать с помощью метода get(). Например, в плагине или модуле:

 $option = $this->params->get('my_option');

Это означает, что мы получили данные в виде объекта Joomla\Registry\Registry.

❓ Зачем это?

Возможность указать значение переменной по умолчанию. Лично для меня первое и самое важное - это возможность указать значение переменной по умолчанию, если его (значения) в параметрах нет.

Вы выпускаете новую версию своего мега-плагина и вводите в него новую опцию my_option. Мы используем её везде в PHP коде. Однако, мы же понимаем, что люди обновятся, а обновлять настройки плагина не полезут. Не полезут до тех пор, пока не станет любопытно "а что же там нового?" или что-нибудь не отвалится. И пока они не установят новый параметр и не сохранят настройки плагина - в коде он так и не появится.

Чтобы ничего не отвалилось нам в коде нужно предположить сценарий по умолчанию, которому, соответственно, нужны значения параметров по умолчанию. Вот тут нам и поможет класс Joomla\Registry\Registry.

 $myOption = $this->params->get('my_option', 'default_value_if_null_or_not_exists'); // string по умолчанию

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

Полиморфизм и наследование

Каждый раз, когда я слышу от кого-то описание или определение полиморфизма, там присутствует слово "наследование".

> Объясните что такое полиморфизм? Ну это когда базовый класс и наследники...

Давайте по порядку. Полиморфизмов вообще существует больше чем один. Но, все таки, когда речь идет про массовое программирование (простите функциональщики), по умолчанию говорят о полиморфизме подтипов (subtyping). Упрощенно, в этом полиморфизме мы заменяем иф на общий метод для разных типов объекта. Таким образом сам объект (его тип) определяет реальное поведение, а вызывающий код про это не знает, он просто дергает метод (или методы):

function doSomething(logger) {
  // Где-то снаружи выбирается конкретный логгер
  // Разные логгеры могут работать сильно по разному
  logger.info('hey');
}

Что мы тут получили? Возможность менять поведение конфигурированием приложения (меняем тип объекта во время настройки), а не тем, что ходим по ифам где выбирается конкретная реализация и меняем там код.

Нужно ли для этого наследование? Вообще не нужно и вообще не подразумевается. Типами и подтипами во всех определениях являются интерфейсы или их аналоги, но не классы. Более того, в динамических языках у вас в принципе сами по себе классы могут быть никак не связаны, главное чтобы в них был реализован один и тот же полиморфный метод.

Кстати, для реализации полиморфизма подтипов классы тоже не нужны. Есть немало языков где он есть, но там нет ни классов ни ооп в привычном варианте.

Больше про разработку в моем телеграм-канале Организованное программирование

Байесовские А/Б-тесты: общая картина

-Блокнот: https://github.com/andrewbrdk/Bayesian-AB-Testing
-Все видео: https://www.youtube.com/playlist?list=PLqgtGAeapsOPpV0FqeXEpWosHBW8ZebYl

Finam X HSE AI Trade Hack: Хакатон для настоящих FinTech-энтузиастов

Хотите прокачать навыки в AI и трейдинге? Готовы создавать инновационные решения для финтеха? Тогда не упустите шанс принять участие в Finam AI Trade Hack — хакатоне от одного из ведущих брокеров на российском рынке «Финам»!

⏰ Регистрация до 19 сентября 23:59
💰 Призовой фонд: 1 200 000 руб.

Треки хакатона:

Forecast
Прогноз динамики цен с учётом новостей.
Задача: предсказать котировки на N дней вперёд, используя временные ряды и новостной контекст.

Trader
LLM-интерфейс к Trade API
Задача: реализовать MCP-сервер для получения рыночных данных и выполнения торговых операций через API FINAM.

Radar
Поиск горячих финансовых новостей.
Задача: создать сервис для автоматического поиска, анализа и оценки новостей, с возможностью генерировать черновики статей и постов.

Почему стоит участвовать:
🔸 Денежные призы
🔸 Оффер на работу в «Финаме»
🔸 Стильный мерч
🔸 Менторская поддержка
🔸 Доступ к API LLM

➡️ Подробная информация и регистрация

Работа с Bluetooth Low Energy (BLE):основные протоколы и практические советы.

Почему BLE до сих пор “ТОП”?
Потому что даёт годами работать от батарейки -“таблетки”, держит связь в шумной среде и уже давно вышел за рамки «умных браслетов». Ниже - короткая, но практичная шпаргалка: что в BLE за что отвечает, где производительность «прячется», и на чём чаще всего спотыкаются.

BLE-стек делится на две большие части:
- GAP - «как знакомимся и подключаемся»: роли Central/Peripheral, сканирование, реклама (advertising) и параметры соединения.
- GATT/ATT - «как обмениваемся данными после подключения»: сервисы, характеристики, дескрипторы и операции чтения/записи/уведомлений. (PunchThrough, cardinalpeak.com)

Основное - по делу:
1) Реклама и роли
Legacy vs Extended Advertising: в Bluetooth 5 появилась расширенная реклама(Extended) и Periodic Advertising - удобно для «маячинга» и многоприёмников без подключения. (Novel Bits)Роли: Peripheral «светится» и ждёт подключения; Central сканирует и подключается. Это — GAP-уровень. (Punch Through)

2) Скорость, дальность и каналыPHY 1M - базовый; 2M PHY - больше скорость; Coded PHY (S=2/S=8) - для дальности и шумных сред; итоговый выбор - компромисс «скорость/дальность/надёжность». (RIOT Summit)
Для широковещания и энергосбережения в BLE 5.4 усилили «витаминку» для ESL/маячков: PAwR (Periodic Advertising with Responses), EAD (Encrypted AdvertisingData) и пр. - полезно для систем с множеством датчиков и электронных ценников. (Bluetooth Technology Website, silabs.com)

3) Пропускная способность: где «лежит» throughputATT MTU и Data Length Extension (DLE) увеличивают полезную нагрузку пакета (вплоть до ~251 байта данных на пакет) — ключ для высокой реальной скорости. (Punch Through, devzone.nordicsemi.com)
Настраивайте интервал соединения, slave latency и supervision timeout под задачу: меньше интервал — ниже задержка и выше пропускная способность, но больше расход батареи. Для потоков «почти-реального времени» ориентируйтесь на уведомления (см. ниже) и 2M PHY (если качество радио позволяет). Практические потолки зависят от хоста/ОС — тестируйте на целевых телефонах/ПК. (devzone.nordicsemi.com)

4) GATT-модель и событияNotify vs Indicate: оба «толкают» данные от сервера к клиенту; Indicate требует подтверждения на уровне протокола (надёжно, но медленнее), Notify — без подтверждения (быстрее, меньше оверхеда). Всегда добавляйте CCCD для (де)активации уведомлений. (Сообщество NXP, Thesis Pte Ltd, Reddit)Дизайн GATT: группируйте характеристики логически, минимизируйте количество сервисов и «глубокие» иерархии — это ускоряет discovery и упрощает кросс-платформенное поведение. (cardinalpeak.com)

5) Безопасность и приватностьLE Secure Connections (ECDH) — базовый стандарт для шифрования.Privacy: используйте RPA/Filter Accept List, а в BLE 5.4 — EAD для шифрованной рекламы (актуально для «маячков» с приватными данными). (Bluetooth Technology Website)

6) Мобильные ОС: подводные камниAndroid 12/13+: нужны runtime-разрешения BLUETOOTH_SCAN/CONNECT/ADVERTISE(диалог Nearby devices). Без них сканирование/подключение просто не начнётся.(Android Developers) iOS: в фоне реклама и сканирование ограничены — обычные рекламные PDU из бэкграунда не шлются; для сканирования в фоне задавайте конкретные UUID и включайте соответствующие background-моды. (Stack Overflow, Apple Developer)

7) Стек и инструментыДля «железа»: Zephyr Bluetooth Host (широко применим на MCU), NimBLE (легковесный стек от Apache Mynewt), BlueZ (Linux). Выбор стека влияет на доступность фич (DLE, Coded PHY, Periodic Adv). (docs.zephyrproject.org, Argenox)

8) Новшества, на которые стоит поглядыватьBLE 5.4 (PAwR, EAD) — для массовых устройств-«полок» и защищённой рекламы. (Bluetooth Technology Website)
Core 6.0: уточнения по таймингу кадра/интервалам в изохронных потоках (актуально для LE Audio/ISO). Если делаете аудио через BLE — изучите. (Bluetooth Technology Website)

Роняем прод в облаке быстро и качественно

Думаете, ваши облачные сервисы защищены от случайного (или намеренного) уничтожения? А если для «апокалипсиса» нужно отправить всего один GET-запрос?..

В новой статье «Один GET и облака нет: роняем прод в надежном облаке быстро и качественно» разложим по шагам, как устроена атака на инфраструктуру в Яндекс.Облаке:

• с чего начинается уязвимость и как её обнаружить

• как работает сервис метаданных и IAM-токены

• пошаговый разбор kill chain: от SSRF до полного удаления прод-ресурсов

• что именно можно уронить, имея доступ к облаку

• простые и эффективные превентивные меры — и почему их раньше не внедряли

Проверьте свои облачные настройки — пока кто-то не проверил их за вас!

Data Sapience приглашает на онлайн-конференцию «Kolmogorov Online Day» ⚙️

Дата: 18 сентября 📆
Время: 16:00 ⏰
Формат: онлайн 🌐

Что будет представлено:
▪️Достижения Kolmogorov AI: этапы развития, ключевые результаты;
▪️«Тессеракт» — обзор нового ПАКа для создания доверенных моделей ИИ;
▪️Срез практик MLOps — объективный взгляд на тренды и подводные камни, а также подходы к работе с AI от независимых экспертов;
▪️Демонстрация возможностей Kolmogorov AI для построения фабрики ИИ-агентов.

Вебинар будет полезен тем, кто хочет:
▪️Автоматизировать и ускорить вывод моделей в production;
▪️Наладить эффективный MLOps и перейти от экспериментов к промышленной эксплуатации;
▪️Найти подходящие инструменты и узнать об опыте создания надежной, масштабируемой и высокопроизводительной инфраструктуры для ML-моделей.

🔗 Зарегистрироваться на конференцию

Сегодня, 9 сентября, в мире ИТ вспоминают первый компьютерный баг

В 1947 инженеры Гарвардского Mark II под руководством Грейс Хоппер разбирались с поломкой реле. В какой-то момент они нашли причину — внутри застряла настоящая моль. Её аккуратно извлекли, приклеили в журнал отладки и подписали: «Первый реальный случай бага».

До этого слово “bug” использовали в инженерной среде, но именно этот случай сделал его легендой ИТ.

Забавно, что сама моль сохранилась — её до сих пор можно увидеть в Смитсоновском институте.

С тех пор баги перестали быть буквальными насекомыми, но последствия стали куда серьёзнее.

Вспомнить хотя бы Heartbleed — уязвимость в OpenSSL, обнаруженную в 2014-м. Одна ошибка в библиотеке, которая отвечает за шифрование, открыла доступ к памяти миллионов серверов по всему миру. Пароли, ключи, данные — всё оказалось под угрозой. В СМИ её называли «самым громким багом десятилетия».

Через несколько лет весь мир обсуждал уже Log4j. Казалось бы, скромная библиотека для логирования на Java, использующаяся в тысячах приложений. В декабре 2021 обнаружили, что через неё можно удалённо выполнить произвольный код. За считаные часы уязвимость стала глобальной катастрофой: под угрозой оказались банки, облачные сервисы и даже игровые платформы вроде Minecraft.

В обоих случаях баг оказался не меньше, чем та самая моль в реле. Только если в 1947-м инженер мог достать насекомое пинцетом и продолжить работу, то сегодня одна ошибка в коде способна обрушить бизнес-систему мирового масштаба.

И это, пожалуй, самое важное напоминание: в ИТ нет «мелких багов». Любая ошибка может стать той самой «молью», остановившей работу огромной машины.

А какой баг стал самым запоминающимся для вас?

Как машинки помогли выявить лучших продавцов

Когда я работал исполнительным директором в Smartykids, в нашем отделе продаж было 12 менеджеров. Мы пытались по-разному мотивировать продавцов и фокусировать их на результате.

У нас в офисе был установлен колокол. Когда приходила оплата, ответственный за оплату менеджер шёл и бил в колокол.

Также мы купили магнитную доску и расположили на ней 12 машинок. У каждого менеджера был месячный план в 1 млн рублей. Каждый день на планёрке менеджеры двигали эти машинки. Так все видели, кто сколько продал в этом месяце.

Вначале это работало хорошо. Продавцы включились, стали бодрее выполнять планы. Но постепенно рос дух соперничества, и спустя 3 месяца отстающие продавцы стали выгорать. С большинством из них мы в итоге попрощались.

Это пример простенькой визуализации, которая фокусировала сотрудников на результат. Для таких экспериментов вам даже не нужны навороченные дашборды. Можно начать с простых инструментов, которые под рукой.