Знаете, как при
Ctrl+Shift+F PhpStorm затирает текущие результаты?Хитрый трюк: нажмите Open Results in New Window, потом правым кликом на таб → View Options → Open Results in New Tab.
🔁 После этого при каждом поиске будут появляться отдельные новые вкладки с результатами.
✅ Так гораздо проще: переключаться между запросами, сравнивать, не терять текущий контекст. Особенно при сложных рефакторингах или поиске across project.
Библиотека пхпшника #буст
Please open Telegram to view this post
VIEW IN TELEGRAM
👍9🔥1
🧠 Asymmetric Visibility в PHP 8.4: Новый способ управления доступом к свойствам
PHP 8.4 представил функцию Asymmetric Visibility, которая позволяет задавать разные уровни видимости для чтения и записи свойств. Это новая концепция, которая, хотя и не получила широкого распространения, имеет огромный потенциал для улучшения инкапсуляции и безопасности данных в приложениях.
🔑 Что такое Asymmetric Visibility?
Теперь можно задавать разные уровни видимости для геттеров и сеттеров свойств. Например, вы можете позволить свойству быть доступным для чтения из внешнего мира, но ограничить его изменение только внутри класса или его подклассов. Это позволяет вам лучше контролировать доступ к внутренним данным объекта.
Вот как выглядит синтаксис:
Пример:
Это означает, что свойство $title можно читать публично (через геттер), но изменять только внутри класса.
⚙️ Как это работает?
В PHP 8.4 вы можете установить видимость для получения (геттера) и изменения (сеттер) свойств отдельно. Например, можно настроить так, чтобы свойство было доступно для чтения всеми, но изменять его могли только методы класса или его наследники. Это улучшает инкапсуляцию, позволяя скрывать внутренние изменения данных, но предоставлять доступ к их чтению.
🔍 Когда это полезно?
Такая возможность особенно полезна в ситуациях, когда необходимо скрыть детали реализации объекта, но при этом предоставить доступ к его состоянию. Например, если нужно разрешить чтение информации, но не позволять её изменять извне, или наоборот — запретить доступ к данным, но предоставить возможность их обновления через методы класса.
⚠️ Ограничения и нюансы:
🔸 Только для типизированных свойств: Ассиметричная видимость работает только с типизированными свойствами.
🔸 Более строгая видимость для сеттеров: Видимость сеттера должна быть такой же или более строгой, чем у геттера.
🔸 Финальные свойства: Если свойство имеет приватный сеттер, оно считается финальным и не может быть переопределено в подклассе.
💡 Почему это важно?
Asymmetric Visibility — это полезный инструмент для повышения гибкости и безопасности данных в приложениях. Он позволяет ограничить возможность изменения состояния объекта, сохраняя при этом доступность данных для чтения. Это помогает минимизировать риски и улучшить архитектуру вашего кода.
👉 Читать статью
PHP 8.4 представил функцию Asymmetric Visibility, которая позволяет задавать разные уровни видимости для чтения и записи свойств. Это новая концепция, которая, хотя и не получила широкого распространения, имеет огромный потенциал для улучшения инкапсуляции и безопасности данных в приложениях.
🔑 Что такое Asymmetric Visibility?
Теперь можно задавать разные уровни видимости для геттеров и сеттеров свойств. Например, вы можете позволить свойству быть доступным для чтения из внешнего мира, но ограничить его изменение только внутри класса или его подклассов. Это позволяет вам лучше контролировать доступ к внутренним данным объекта.
Вот как выглядит синтаксис:
[GETTER_VISIBILITY] [SETTER_VISIBILITY(set)] [TYPE] $propertyName;Пример:
protected private(set) string $title;Это означает, что свойство $title можно читать публично (через геттер), но изменять только внутри класса.
⚙️ Как это работает?
В PHP 8.4 вы можете установить видимость для получения (геттера) и изменения (сеттер) свойств отдельно. Например, можно настроить так, чтобы свойство было доступно для чтения всеми, но изменять его могли только методы класса или его наследники. Это улучшает инкапсуляцию, позволяя скрывать внутренние изменения данных, но предоставлять доступ к их чтению.
🔍 Когда это полезно?
Такая возможность особенно полезна в ситуациях, когда необходимо скрыть детали реализации объекта, но при этом предоставить доступ к его состоянию. Например, если нужно разрешить чтение информации, но не позволять её изменять извне, или наоборот — запретить доступ к данным, но предоставить возможность их обновления через методы класса.
⚠️ Ограничения и нюансы:
🔸 Только для типизированных свойств: Ассиметричная видимость работает только с типизированными свойствами.
🔸 Более строгая видимость для сеттеров: Видимость сеттера должна быть такой же или более строгой, чем у геттера.
🔸 Финальные свойства: Если свойство имеет приватный сеттер, оно считается финальным и не может быть переопределено в подклассе.
💡 Почему это важно?
Asymmetric Visibility — это полезный инструмент для повышения гибкости и безопасности данных в приложениях. Он позволяет ограничить возможность изменения состояния объекта, сохраняя при этом доступность данных для чтения. Это помогает минимизировать риски и улучшить архитектуру вашего кода.
👉 Читать статью
🔥4❤3
В мире программирования существует множество идеологий написания кода: Unix-way отвечает за коммуникацию, Agile — за гибкость, DRY и KISS — за чистоту и читаемость. Все они улучшают качество кода, но их слабое место — ориентация на индивидуальную работу. Именно поэтому появился новый, социальный подход к программированию.
SOSAL — это современная идеология, основанная на предположении, что над проектом работает команда самых разных людей. Этот подход помогает сделать процесс разработки максимально удобным и продуктивным для всех участников.
SOSAL строится на пяти принципах:
1. Socially-Conscious Code (Социально-осознанный код)
Главная ценность командной работы — кооперация. Чтобы кодовая база была дружелюбной, важно не только знать язык программирования, но и придерживаться его стиля, писать чисто и использовать идиоматичные решения. Это облегчает вхождение новых участников в проект и ускоряет совместную работу.
2. Open by Default (Открытость по умолчанию)
Код должен быть открыт, если нет веских причин для обратного. Комментируйте так, будто ваш код читает новичок. Если решение не очевидно или требует времени на понимание, обязательно оставьте комментарий.
3. Simple Scalability (Сбалансированная масштабируемость)
Пишите код, который легко масштабировать, но избегайте преждевременных оптимизаций. Простота не означает примитивность, а сложность — не признак качества.
«Преждевременная оптимизация — корень всех зол.»
4. Agile Adaptivity (Адаптивность выше догм)
Код должен быть готов к изменениям, даже если они кажутся маловероятными. Используйте гибкие решения, например, готовые библиотеки для конфигурации, чтобы облегчить будущие доработки. Балансируйте между принципом YAGNI и возможностью эволюции кода.
5. Learning-Driven Logic (Логика, основанная на обучении)
Пишите код так, чтобы он учил вас и других. Рефакторинг — это не наказание, а возможность применить новые знания. Экспериментируйте, но всегда оставляйте после себя чистый и понятный код.
Будете ли вы использовать подход в своих проектах?
Please open Telegram to view this post
VIEW IN TELEGRAM
😁24👍8😢2
💻 Подборка новостей по PHP за неделю:
🔹 JetBrains Junie для PhpStorm — новая эра агентных IDE: Junie способен выполнять объёмные задачи самостоятельно, выводя продуктивность на новый уровень.
🔹 Laravel 12.19 — добавлены атрибут
🔹 Filament v4 Beta — переработанный интерфейс, повышенная производительность, больше контроля при создании интерфейсов. Бета-версия уже доступна для тестирования.
🔹 Symfony 16–22 июня — активная разработка Symfony 7.4 и 8.0: добавлена интеграция с FrankenPHP, удаляются устаревшие функции, улучшена гибкость контроллеров.
Библиотека пхпшника #свежак
🔹 JetBrains Junie для PhpStorm — новая эра агентных IDE: Junie способен выполнять объёмные задачи самостоятельно, выводя продуктивность на новый уровень.
🔹 Laravel 12.19 — добавлены атрибут
UseEloquentBuilder, каст AsFluent, middleware FailOnException для очередей, улучшенные тестовые ассерты и другие нововведения.🔹 Filament v4 Beta — переработанный интерфейс, повышенная производительность, больше контроля при создании интерфейсов. Бета-версия уже доступна для тестирования.
🔹 Symfony 16–22 июня — активная разработка Symfony 7.4 и 8.0: добавлена интеграция с FrankenPHP, удаляются устаревшие функции, улучшена гибкость контроллеров.
Библиотека пхпшника #свежак
👍2
Forwarded from Библиотека задач по PHP | тесты, код, задания
Каким будем массив $b после выполнения кода?
👍2
Forwarded from Библиотека задач по PHP | тесты, код, задания
Каким будем массив $b после выполнения кода?
Anonymous Quiz
51%
$b = array(4, 5, 6, 1, 2, 3 )
12%
Ошибка
21%
$b = array( 1, 2, 3, 4, 5, 6 )
15%
$b = array( 4, 5, 6 )
👍8❤1
Проблема: при обработке больших объемов данных важно не только их собрать, но и правильно структурировать для дальнейшего анализа. Обычные SQL-запросы могут стать громоздкими и сложными, особенно когда речь идет о масштабируемости и производительности.
Решение: в книге «Analytics Engineering with SQL and dbt: Building Meaningful Data Models at Scale» авторы описывают, как использовать dbt (data build tool) для построения и трансформации данных. dbt позволяет создавать чистые, поддерживаемые и легко масштабируемые модели данных, используя простые SQL-запросы, что значительно ускоряет процессы аналитики.
Пример кода:
-- Пример модели dbt для расчета среднего чека по категориям товаров
WITH base AS (
SELECT
category_id,
SUM(order_amount) AS total_sales,
COUNT(DISTINCT order_id) AS total_orders
FROM raw.orders
GROUP BY category_id
)
SELECT
category_id,
total_sales / total_orders AS avg_order_value
FROM base
Преимущества:
— Dbt позволяет быстро разрабатывать и тестировать модели данных, сокращая время от идеи до реализации.
— Подходы, описанные в книге, позволяют строить модели, которые легко масштабируются по мере роста данных.
— Акцент на совместной работе между аналитиками и инженерами способствует более эффективному решению задач.
Еще больше полезных книг — в нашем канале @progbook
Please open Telegram to view this post
VIEW IN TELEGRAM
👍3😁1
📏 Единый стиль форматирования кода: как улучшить использование скобок и фигурных скобок в PHP
В статье предлагается новый подход к оформлению синтаксиса в PHP, который основывается на логике языка, а не на исторических привычках из других языков программирования, таких как C или Java. Цель — создать стиль, который будет унифицированным, систематичным, последовательным и лёгким для запоминания.
🔑 Что предложено?
Унификация: одна и та же правило применяется ко всем соответствующим конструкциям — будь то функции, управляющие структуры или вложенные выражения.
Системность: каждое правило следует прямо из синтаксической структуры, а не из лексической категории (ключевое слово, идентификатор и т. д.).
Последовательность: одинаковое обращение с конструкциями без произвольных исключений.
Лёгкость запоминания: устранение контекстных различий и эстетических отличий, не имеющих функционального значения.
📚 Как это работает?
Нет пробела перед открывающимися скобками: Например,
Открывающие фигурные скобки всегда на той же строке, что и управляющая структура: Например,
Закрывающие фигурные скобки на новой строке, выровненные с началом блока.
🚫 Почему стоит отказаться от исторических конвенций?
Ранее использованные в таких стандартах, как PSR-2 и PSR-12, подходы взяли за основу стиль, присущий языкам, подобным C, что ведет к путанице и необходимости запоминать исключения. Например, скобки в функциях и управляющих конструкциях должны располагаться по-разному, хотя структура этих конструкций схожа. Эти отличия не улучшали читаемость кода, а наоборот, только увеличивали когнитивную нагрузку.
🔥 Преимущества нового подхода:
Упрощённое восприятие кода.
Совместимость с инструментами автоматического форматирования, такими как PHP-CS-Fixer или линтеры.
Чистый и вертикально структурированный код, который легче воспринимать.
📈 Специальные случаи: if/elseif/else и try/catch/finally
Предлагается установить правило, что все блоки (например,
💡 Советы для новых конструкций:
Стрелочные функции (fn): не ставить пробел между
Тернарные выражения (? :): использовать скобки для сложных вложенных выражений и ставить пробелы вокруг
👉 Читать статью
В статье предлагается новый подход к оформлению синтаксиса в PHP, который основывается на логике языка, а не на исторических привычках из других языков программирования, таких как C или Java. Цель — создать стиль, который будет унифицированным, систематичным, последовательным и лёгким для запоминания.
🔑 Что предложено?
Унификация: одна и та же правило применяется ко всем соответствующим конструкциям — будь то функции, управляющие структуры или вложенные выражения.
Системность: каждое правило следует прямо из синтаксической структуры, а не из лексической категории (ключевое слово, идентификатор и т. д.).
Последовательность: одинаковое обращение с конструкциями без произвольных исключений.
Лёгкость запоминания: устранение контекстных различий и эстетических отличий, не имеющих функционального значения.
📚 Как это работает?
Нет пробела перед открывающимися скобками: Например,
if($x) и while($y) — это всегда одно правило, независимо от того, является ли конструкция управляющей или функцией.Открывающие фигурные скобки всегда на той же строке, что и управляющая структура: Например,
function foo() { или if($x) {.Закрывающие фигурные скобки на новой строке, выровненные с началом блока.
🚫 Почему стоит отказаться от исторических конвенций?
Ранее использованные в таких стандартах, как PSR-2 и PSR-12, подходы взяли за основу стиль, присущий языкам, подобным C, что ведет к путанице и необходимости запоминать исключения. Например, скобки в функциях и управляющих конструкциях должны располагаться по-разному, хотя структура этих конструкций схожа. Эти отличия не улучшали читаемость кода, а наоборот, только увеличивали когнитивную нагрузку.
🔥 Преимущества нового подхода:
Упрощённое восприятие кода.
Совместимость с инструментами автоматического форматирования, такими как PHP-CS-Fixer или линтеры.
Чистый и вертикально структурированный код, который легче воспринимать.
📈 Специальные случаи: if/elseif/else и try/catch/finally
Предлагается установить правило, что все блоки (например,
if, elseif, else, try, catch, finally) должны начинаться с новой строки после закрывающей фигурной скобки предыдущего блока. Это улучшает структуру и читабельность кода, делая его более понятным и логичным.💡 Советы для новых конструкций:
Стрелочные функции (fn): не ставить пробел между
fn и открывающей скобкой.Тернарные выражения (? :): использовать скобки для сложных вложенных выражений и ставить пробелы вокруг
? и :.👉 Читать статью
🥱5🌚2
🕵️ Команда дня: Поиск всех вызовов функции
Зачем это нужно?
Если вы работаете с большими проектами и хотите быстро найти все места, где используется определённая функция, команда
Простой пример: у вас есть функция
Пример использования:
Результат:
Если функция
Разные варианты:
Поиск по всем PHP-файлам:
Если вы хотите искать только по PHP-файлам, можно уточнить расширение:
Игнорирование регистра:
Если не важно, как написана функция (например,
Показать только имена файлов:
Если вам нужно только увидеть, где эта функция вызывается (без строк с кодом):
Почему это полезно?
🔹 Быстро находите все места использования функции. Например, перед изменениями или удалением функции важно удостовериться, что вы не затронете другие части кода.
🔹 Удобно для рефакторинга. Когда вы хотите заменить одну функцию на другую, эта команда покажет, где необходимо провести изменения.
🔹 Не требует IDE. Для поиска не нужно открывать IDE, достаточно консоли и нескольких команд.
🧠 Дополнительно: Сложные запросы
Если необходимо искать более сложные структуры или несколько функций сразу, вы можете использовать регулярные выражения с
Библиотека пхпшника #буст
grep -R «functionName(» ./srcgrep— это утилита командной строки для поиска по тексту в файлах. Ключ-Rпозволяет искать рекурсивно по всем файлам в директории, а«functionName(»— это строка, которую мы ищем (в данном случае — вызовы функции).
Зачем это нужно?
Если вы работаете с большими проектами и хотите быстро найти все места, где используется определённая функция, команда
grep может быть настоящим спасением.Простой пример: у вас есть функция
sendEmail, и вам нужно узнать, где она вызывается в коде — эта команда делает всё быстро и эффективно, без лишних кликов в IDE.Пример использования:
grep -R «sendEmail(» ./srcРезультат:
Если функция
sendEmail вызывается в нескольких местах, результат будет выглядеть так:./src/Controllers/NotificationController.php:42: sendEmail($user->email, $subject, $body);./src/Services/EmailService.php:56: sendEmail($user->email, $subject, $body);
Разные варианты:
Поиск по всем PHP-файлам:
Если вы хотите искать только по PHP-файлам, можно уточнить расширение:
grep -R --include=»*.php» «sendEmail(» ./srcИгнорирование регистра:
Если не важно, как написана функция (например,
sendemail или sendEmail), добавьте флаг -i:grep -Ri «sendemail(» ./srcПоказать только имена файлов:
Если вам нужно только увидеть, где эта функция вызывается (без строк с кодом):
grep -Rl «sendEmail(» ./srcПочему это полезно?
🔹 Быстро находите все места использования функции. Например, перед изменениями или удалением функции важно удостовериться, что вы не затронете другие части кода.
🔹 Удобно для рефакторинга. Когда вы хотите заменить одну функцию на другую, эта команда покажет, где необходимо провести изменения.
🔹 Не требует IDE. Для поиска не нужно открывать IDE, достаточно консоли и нескольких команд.
🧠 Дополнительно: Сложные запросы
Если необходимо искать более сложные структуры или несколько функций сразу, вы можете использовать регулярные выражения с
grep. Например, для поиска всех вызовов функций, начинающихся с get:grep -R -E «get[A-Za-z0-9_]*\(» ./srcБиблиотека пхпшника #буст
😁8👍3🔥3
🔥 Последняя неделя перед стартом курса по AI-агентам
Старт курса уже 5го числа! Если вы планировали вписаться — сейчас ПОСЛЕДНИЙ шанс забронировать место
На курсе:
— разложим LLM по косточкам: токенизация, SFT, PEFT, инференс
— соберём RAG и научимся оценивать его адекватно
— построим настоящую мультиагентную систему — архитектуру, которая умеет расти
— разберём CoPilot, сломаем через prompt injection (спасибо Максу)
— и наконец, посмотрим, как это работает в MCP и реальных кейсах
📍 Это 5 живых вебинаров + раздатка + домашки + чат с преподавателями
И главное — возможность реально разобраться, как проектировать системы на LLM, а не просто «поиграться с API»
👉 Курс здесь
Старт курса уже 5го числа! Если вы планировали вписаться — сейчас ПОСЛЕДНИЙ шанс забронировать место
На курсе:
— разложим LLM по косточкам: токенизация, SFT, PEFT, инференс
— соберём RAG и научимся оценивать его адекватно
— построим настоящую мультиагентную систему — архитектуру, которая умеет расти
— разберём CoPilot, сломаем через prompt injection (спасибо Максу)
— и наконец, посмотрим, как это работает в MCP и реальных кейсах
📍 Это 5 живых вебинаров + раздатка + домашки + чат с преподавателями
И главное — возможность реально разобраться, как проектировать системы на LLM, а не просто «поиграться с API»
👉 Курс здесь
😁2
🛠️ Система очередей и Job'ов Laravel: От создания таблицы до развертывания в продакшене
Очереди в Laravel — незаменимый инструмент для обработки ресурсоёмких задач в фоне: отправка писем, обработка видео, нотификации и многое другое. В этой статье мы пошагово разберём весь процесс работы с job'ами — от создания нужных таблиц до запуска очередей в продакшене через Supervisor. Вы узнаете, как отслеживать и повторно запускать проваленные задания, автоматически чистить старые, настраивать задержки и количество попыток, а также использовать батчи для групповых операций. Если вы хотите уверенно управлять фоновыми задачами в Laravel — этот гайд станет вашей настольной инструкцией.
👉 Читать статью
Библиотека пхпшника
Очереди в Laravel — незаменимый инструмент для обработки ресурсоёмких задач в фоне: отправка писем, обработка видео, нотификации и многое другое. В этой статье мы пошагово разберём весь процесс работы с job'ами — от создания нужных таблиц до запуска очередей в продакшене через Supervisor. Вы узнаете, как отслеживать и повторно запускать проваленные задания, автоматически чистить старые, настраивать задержки и количество попыток, а также использовать батчи для групповых операций. Если вы хотите уверенно управлять фоновыми задачами в Laravel — этот гайд станет вашей настольной инструкцией.
👉 Читать статью
Библиотека пхпшника
👍2❤1
💬 Вопрос от подписчика: как сохранить PHP-код чистым и поддерживаемым?
👇 Делитесь своим опытом — что реально помогает вам не утонуть в хаосе?
🚀 Используете ли вы стандарты, линтеры, слои, DDD, maybe Laravel-пакеты или IDE-фишки?
Обсудим в комментариях!
Библиотека пхпшника #междусобойчик
«Чем больше растёт мой PHP-проект, тем сложнее за ним следить. Маленькие фиксы превращаются в грязные заплатки, а кодовая база становится всё менее управляемой.
Как вы поддерживаете чистоту и читаемость кода в долгосрочной перспективе? Есть ли какие-то советы по структуре, неймингу или полезные инструменты для поддерживаемости?»
👇 Делитесь своим опытом — что реально помогает вам не утонуть в хаосе?
🚀 Используете ли вы стандарты, линтеры, слои, DDD, maybe Laravel-пакеты или IDE-фишки?
Обсудим в комментариях!
Библиотека пхпшника #междусобойчик
👍2🤔2❤1
Forwarded from Библиотека программиста | программирование, кодинг, разработка
Прописаны все виды команд JOIN, а также их визуал.
Крайне полезная штука — сохраняем.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍8🥱4❤1👾1
События vs сообщения. Понимаете ли вы разницу и почему это важно?
🧠 «Будем отправлять события в Rabbit!» — фраза, с которой всё начинается… и всё рушится 😅
Слишком часто в проектах путают события, сообщения и транспорт. В итоге появляются боли, магия и код, в котором невозможно разобраться. А потом слышим:
А дело-то не в Messenger'е, а в архитектурных решениях.
🔥 В статье, на которую обязательно стоит потратить время:
🔸 разбор, что такое событие в приложении (и почему это не сообщение);
🔸 почему Symfony EventDispatcher нельзя тащить в домен;
🔸 как выглядит простой, но правильный
🔸 когда события превращаются в сообщения — и почему транспорт (Rabbit/Kafka/etc) должен подбираться последним, а не первым;
🔸 и почему «всё в одном классе» — верный путь в дебаг ад.
📌 Отдельная тема - как событие из домена превращается в сообщение и уходит в Rabbit через Symfony Messenger.
Да, Messenger — это не центр вселенной, а всего лишь инструмент доставки. И это важно понимать.
👉 Хабр
💬 А ты как реализуешь события в своих проектах? Используешь ли отдельный dispatcher для домена?
🧠 «Будем отправлять события в Rabbit!» — фраза, с которой всё начинается… и всё рушится 😅
Слишком часто в проектах путают события, сообщения и транспорт. В итоге появляются боли, магия и код, в котором невозможно разобраться. А потом слышим:
Symfony Messenger? Фу, я на нём проект писал — не взлетел!
А дело-то не в Messenger'е, а в архитектурных решениях.
🔥 В статье, на которую обязательно стоит потратить время:
🔸 разбор, что такое событие в приложении (и почему это не сообщение);
🔸 почему Symfony EventDispatcher нельзя тащить в домен;
🔸 как выглядит простой, но правильный
DomainEventPublisher;🔸 когда события превращаются в сообщения — и почему транспорт (Rabbit/Kafka/etc) должен подбираться последним, а не первым;
🔸 и почему «всё в одном классе» — верный путь в дебаг ад.
📌 Отдельная тема - как событие из домена превращается в сообщение и уходит в Rabbit через Symfony Messenger.
Да, Messenger — это не центр вселенной, а всего лишь инструмент доставки. И это важно понимать.
👉 Хабр
💬 А ты как реализуешь события в своих проектах? Используешь ли отдельный dispatcher для домена?
👍3🔥3
🔥 Сегодня стартует курс по AI-агентам!
Онбординг уже сегодня, но ещё можно вписаться — ПОСЛЕДНИЙ ШАНС это сделать.
Мы больше года собирали мультиагентные системы: экспериментировали, переделывали и в итоге — оформили всё в 5 плотных вебинаров.
😤 «А можно ли вообще научиться чему-то за 5 вебинаров?!»
Если вы хотите просто послушать — нет
Если хотите разбираться и делать — да
➡️ На курсе:
— мы не читаем слайдики, а работаем в коде в реальном времени
— можно задавать вопросы прямо на вебинаре
— после каждого вебинара есть домашка и поддержка в чате
И главное — вы получаете системное понимание, а не набор хаотичных туториалов.
⚡️Если вы думаете, что успеете потом — не успеете.
Старт сегодня:
— а те, кто вписался сейчас, будут вас опережать — в проектах, на грейде и в зарплате
Знакомьтесь, эксперт нашего курса:
Никита Зелинский — Chief Data Scientist МТС, Head of ML Platforms, руководитель центра компетенций по Data Science.
❗Стартуем сегодня — забронируй свое место
Онбординг уже сегодня, но ещё можно вписаться — ПОСЛЕДНИЙ ШАНС это сделать.
Мы больше года собирали мультиагентные системы: экспериментировали, переделывали и в итоге — оформили всё в 5 плотных вебинаров.
😤 «А можно ли вообще научиться чему-то за 5 вебинаров?!»
Если вы хотите просто послушать — нет
Если хотите разбираться и делать — да
➡️ На курсе:
— мы не читаем слайдики, а работаем в коде в реальном времени
— можно задавать вопросы прямо на вебинаре
— после каждого вебинара есть домашка и поддержка в чате
И главное — вы получаете системное понимание, а не набор хаотичных туториалов.
⚡️Если вы думаете, что успеете потом — не успеете.
Старт сегодня:
— а те, кто вписался сейчас, будут вас опережать — в проектах, на грейде и в зарплате
Знакомьтесь, эксперт нашего курса:
Никита Зелинский — Chief Data Scientist МТС, Head of ML Platforms, руководитель центра компетенций по Data Science.
❗Стартуем сегодня — забронируй свое место