За создание аниме-аватаров для чат-бота Grok в xAI платят до $440 тыс. в год. Разработчику нужно создавать реалистичных ИИ-аватаров, вовсю тестировать геймплей во всех ситуациях и работать с голосовыми командами. Требования — Python, Rust, WebSocket, WebRTC и опыт работы iOS.
Откровения евангелистов БЯМ (LLM) для целей софтостроения генерируются публикуются с высокой скоростью. Не только на хабре, LinkedIn заполнен ими "под завязку". Прочитывать всё невозможно, да и не нужно, но некоторый тренд в изложении присутствует.
К сожалению, авторы много пишут о процессе, забывая собственно цели. Упоминание о функциональной сложности программы, как правило, отсутствует. Длина описаний процесса может создать ложное впечатление о развесистой функциональности, хотя большинство примеров находятся на уровне "записная книжка". В этом нет ничего плохого, просто не забываем, что 30 лет назад RAD типа Delphi умели создавать такие же "книжки" без написания кода вообще: достаточно было "накидать" компонентов на форму, настроить, связать их, и нажать "Run".
Накидали, и что дальше?
За словами "писать на близком к естественному языку", скрывается постепенное создание быстро растущего "промпта" - детальной спецификации, местами - псевдокода. Как следствие, необходимо иметь версии таких "исходников", как и раньше для кода (об этом практически не пишут). Для сторонних пакетов, API служб и прочих зависимостей не забываем указывать версии. По сравнению с таким "псевдокодом" техзадание может показаться увлекательной беллетристикой. Речь идет по сути о конечных спецификациях, ведь программирование - не столько кодирование (от силы 20% времени), сколько детальное проектирование и стабилизация.
Размер спецификаций псевдокода вкупе с описаниями контекста среды могут превзойти собственно размеры генерируемого кода, написанного программистом на формальном ЯВУ. Спецификации придется так же хранить в Git, и нервно просматривать, что же изменилось в сценариях, почему, ***, вместо слова "опять" кто-то написал "снова".
Для детерминированности процесса желательно, чтобы моделька была в том же состоянии, что и на предыдущем этапе генерации, но для внешних БЯМ-сервисов это недостижимо. Напомню, что компиляторы и классические генераторы кода (CASE, MDD) - детерминированные.
На первый план выходят тесты, их нужно писать "больше и лучше", потому что под капотом теперь только "черный ящик", "белого" больше нет. Тесты нужно постоянно обновлять в зависимости от объема изменений. Если ваши новые спецификации меняют 20% существующей кодовой базы, то тестов придется менять вдвое больше, принимая 2:1 за стандартное соотношение тестов к коду. Для языков без статической типизации тестирование еще более усложняется.
В реальных проектах написание сотен строк в день - это режим стартапа, причем на "нулевом цикле". Достаточно быстро программист приходит к естественной норме десятков строк в день, остальное время занимает понимание текущего потока проблем, поиск ошибок, интеграция и стабилизация. Хороший программист минимизирует объем порождаемого кода. Нужно ли включать БЯМ для написания 50 строк в день - вопрос.
В процессе не предусмотрена роль юниоров. Перспектива - "уйти со сцены", не воспитав смены, достаточно сомнительная для бизнеса и весьма печальная в личном плане.
Напоследок накину немного философского. Евангелисты любят упоминать, что человеческий мозг и БЯМы работают на одних и тех же принципах. Часто выясняется, что курса "Аналоговые ЭВМ" на их потоке уже не было, что несколько удручает. Еще более простой вопрос на примере несуществующей (пока?) телепортации: "Человек на входе телепортера и на выходе - это одна и та же личность?"
По мнению специалиста по этике моделей в OpenAI Шона Гроува, в будущем наиболее ценными программистами станут те, кто умеет чётко формулировать мысли, а не просто писать код.
«Если вы умеете эффективно коммуницировать — вы уже умеете программировать», — утверждает он. Гроув считает, что программирование всегда было не столько про строки кода, сколько про структурированное выражение намерений: от понимания задачи и целей до их формализации в понятной форме как для людей, так и для машин.
Гроув называет код лишь «потерянной проекцией» (lossy projection) изначального замысла и ценностей. С развитием ИИ систем, по его мнению, главное умение программиста смещается от написания кода к созданию точных спецификаций и промптов, способных передать намерение максимально полно.
«Тот, кто пишет спецификацию — будь то менеджер, инженер, маркетолог или законодатель — и есть новый программист», — пояснил Гроув. По сути, будущее разработки смещается от технического исполнения к смысловому моделированию: важно не столько, как вы пишете код, сколько, что вы хотите выразить. ИИ берет на себя синтаксис, а человеку остаётся формулировать мысль — ясно, логично и недвусмысленно, полагает Гроув.
Чек-лист: твой проект скоро развалится, если…
Небольшой технический чек, который стоит пройти каждому, кто ведёт продукт или отвечает за разработку.
Если узнаете себя — возможно, пора не спешить с новой фичей, а разложить фундамент.
Весь проект держится на одном человеке
И он — не документация. Ушёл в отпуск — проект замер.
Задачи ставятся в личке, на встрече или в голове
"Я же в телеге писал задачу". Без трекинга всё разваливается.
Никто не может объяснить, что по приоритету
Всё срочно, всё горит, всё одновременно. Ну вы поняли.
Прод выкатывается вручную, или в пятницу вечером
Даже не баг, а фича. Проблемы по подписке.
Тестов нет, баги ловим по фидбеку
Багрепорт от клиента — это не QA.
Архитектура — это слово из чужого лексикона
Потому что “нам и так норм”. До первой перегрузки.
Вопросы “а как это работает?” решаются методом тыка
Потому что комментировать код — западло.
Бэкапы где-то есть… но никто не проверял
Олег говорил, что сохранял себе дамп локально
Ушёл один человек — и половина знаний ушла с ним
Значит, их не было в проекте — только в его голове.
Если вы загнули 3–4 пальца — значит пора встать и осмотреться.
Пока “всё работает” — это ещё не стабильность, это просто везение.
Некоторые проблемы уже рассмотрел подробнее в своих статьях
Хорошо ли вы разбираетесь в Python?
В Академии Selectel есть небольшой тест на владение синтаксисом Python. Он позволит оценить свои знания и отыскать пробелы. Вопросы подобраны для тех, кто уже не пугается None, но продолжает разбираться, что происходит «под капотом». Бонусом — подборка полезных материалов для изучения Python!
Парадигмы программирования заложенные в протоколы с обязательным исполнением.
Как в нашей народной, старой и доброй — эталонной сетевой модели OSI.
Все что нам надо по сути для успешного успеха, просто взять и заложить парадигмы программирования в обязательное условие к исполнению.
Закладывается экспертный орган, который разрабатывает обязательное внедрение Парадигмы. Закладывается стандарт. Пример — протокол IPv6. Плавный переход.
Мал по малу стандарт получает настоящий знак качества, и через десять лет, — те кто не пишут код в рамках модели, не получают «значок», и в итоге не попадают в магазин андройд или яблока. Точка. Ваше ПО мертво само сабой. И рынок цел и хомяки довольны.
Пример: Возвращаясь к модели OSI, где чисто гипотетически — создаем надстройку для производителей ПО, Операционных Систем и Железа.
Чисто иллюзорно представим:
на восьмой уровень прописываем достаточные и необходимые правила(Парадигмы) и способы взаимодействия конечного кода — для слоя ОС;
а на девятый уровень например выделяем основу для протоколов взаимодействия конечного пользовательского ПО в самом широком смысле. То есть Парадигмы для конечного слоя ПО, который общается с юзером и ОС.
В итоге с определенной долей вероятности, со временем, ваше ПО, ваша ОС или ваша Железка, — просто не попадет ни на рынок связи, не на военный рынок и не на потребительский рынок с рынком бизнесса. Ибо не будет соотвествовать стандартам качества. Simple.
Фича ради фичи
Как легко потерять смысл разработки, добавляя “полезности”
Сделаем ещё кнопку, она “точно нужна”
Добавим фильтр, и сортировку, и модалку, ну мало ли
Вот бы выгрузку в Excel, и график, и пуши!
…Проект набирает скорость. Только куда?
В чём проблема?
Когда цель — просто сделать больше фичей, а не решить конкретную задачу, продукт начинает разваливаться: интерфейс пухнет, команда тонет в «хотелках», релизы идут в спешке, а люди - даже не замечают большинство этих «удобств»
Парадокс: чем больше фич, тем хуже продукт
Потому что он уже не про ценность, а про “галочки” и “давайте сделаем ещё”.
У фичи должен быть KPI, надо ставить вопрос «а что изменится от нее?». Также их надо подчищать, если старые не используются: «больше ≠ лучше»
Хороший пример: есть множество платных плагинов для Notion, в которых тонна функций. Но пользователям часто нужна была именно интеграция с Гугл таблицами, они не хотели переплачивать за другие возможности плагина.
Один парень заметил это, и сделал элементарный плагин для интеграции Notion с Google Sheets, на чем начал зарабатывать хорошие деньги.
Людям не нужно «все и сразу», им нужна качественная точечная фича
Я пишу о таких штуках в Telegram-канале Техдир на пальцах — без кода и заумных слов. Только реальные кейсы, честные мысли и решения, которые работают.
Evolution free tier — ежемесячный объем облачных ресурсов, за которые не нужно платить 🙌
❓ Что за инструмент? Evolution free tier позволяет бесплатно использовать ресурсы платформы Cloud.ru Evolution. С free tier доступны виртуальные машины, объектное хранилище S3 и ресурсы для запуска контейнеров.
🖥 Особенности и преимущества. Во free tier вам доступны три сервиса:
Evolution Compute — виртуальная машина в следующей конфигурации: 2 vCPU (Intel Gold 6248R, 3 ГГц), 4 ГБ RAM (DDR4), 30 ГБ дискового пространства (SSD NVMe) и безлимитный исходящий трафик.
Evolution Object Storage — объектное хранилище S3 с ежемесячным объемом бесплатных ресурсов: 15 ГБ хранилища, 100 000 операций PUT, POST, LIST, миллион операций GET, HEAD и 10 ТБ исходящего трафика.
Evolution Container Apps — сервис для разработки и запуска контейнеров. В месяц доступны: 120 vCPU × час и 480 ГБ RAM × час.
Чтобы начать работу, достаточно выбрать готовый образ и приобрести публичный IP.
✍️ Где, как и для чего использовать. Evolution free tier подойдет для тестирования облачных сервисов и разработки небольших проектов: менеджера паролей, telegram-бота, сайта для личного блога или портфолио. Еще можно развернуть облачное хранилище для фото, видео и документов. Или развернуть собственный игровой сервер в Minecraft ⛏️
А чтобы быстрее запустить проект, используйте нашего нового AI-помощника Клаудию. Он подберет конфигурацию виртуальной машины, развернет ее, создаст SSH и виджеты мониторинга, настроит алертинг за вас.
Чтобы погрузиться в детали, читайте статью про сценарии использования Evolution free tier. В ней мы рассказали об опыте тех, кто уже запустил свой сайт, сделал учебный проект, начал тестировать гипотезы с бесплатными ресурсами облака.
Человек-комбайн
Почему зависимость от одного специалиста может утопить всю команду. Выглядит как супергерой. На деле — одиночка, от которого зависит всё.
Это «человек-комбайн». Его любят, на него надеются, он незаменим. До тех пор, пока всё не рухнет.
Первый этап
Команда обращается за всем именно к нему: помощь, проверка, советы. Он — живая документация и мозг проекта.
Для бизнеса всё выглядит отлично: «три в одном, да ещё и без лишних затрат».
Второй этап
Постепенно «комбайн» устаёт: таски неинтересные, общения слишком много, помощи просят постоянно.
Он начинает раздражаться, отказывать, “зависимые” замыкаются. Процессы начинают проседать — но пока это незаметно сверху.
Третий этап
Бизнес не замечает проблему, а специалист уже морально ушёл. Проходит немного времени, и вот он увольняется. И…
Судный день
Без него — никто не знает, как деплоить, где что лежит, как починить баг.
Документации нет, у разработчиков паника.
Прод падает. Клиенты жалуются. Команда — в ступоре.
Восстановление занимает недели. А иногда — проект просто не поднимается.
Как не угодить в ловушку?
Раздавайте ответственность. Не сливайте всё на одного “самого умного”. Растите дублирующих специалистов. Пишите документацию. Один супермен — это риск, а не преимущество.
Коромысло с одним ведром — всегда перевесит в одну сторону.
Я пишу о таких штуках в Telegram-канале Техдир на пальцах — без кода и заумных слов. Только реальные кейсы, честные мысли и решения, которые работают.
Repeater - планировщик для анализа данных, упрощенный Apache Airflow.
Repeater запускает задачи по расписанию. Задачи - последовательности консольных программ - описываются в toml-файлах. Запуски отображаются в веб-интерфейсе.
Пример задачи - запуск скриптов wiki_stats.py и wiki_pageviews.py импорта верхнеуровневой статистики Википедии в локальную базу.
title = "wiki"
cron = "0 55 * * * *"
[[tasks]]
name = "wiki_stats"
cmd = "python3 ./examples/wiki_stats.py"
[[tasks]]
name = "wiki_pageviews"
cmd = "python3 ./examples/wiki_pageviews.py --end_date={{.scheduled_dt}}"Бэкэнд написан на Go. Команды ниже запустят Докер-контейнер с сервисом и окружение для примеров:
- Repeater http://localhost:8080 - планировщик
- ClickHouse http://localhost:8123 и http://localhost:9000 - база данных
- ch-ui http://localhost:8001 - веб-интерфейс к базе данных
- Streamlit http://localhost:8002 - дашборды
git clone https://github.com/andrewbrdk/Repeater
cd Repeater
docker compose up --buildВ примерах импорт количества просмотров страниц Википедии, курса биткоина, статистики репозитория Линукса на Гитхабе. Графики в Streamlit http://localhost:8002 .
Интересны применения проекта. Попробуйте! Впечатления пишите в комментариях. Спасибо!
Репозиторий: https://github.com/andrewbrdk/Repeater
Привет, Хабр. Подготовили подборку бесплатных открытых уроков от Otus, которые пройдут на этой неделе по вечерам. Опытные практики проводят вебинары в живом формате, что позволит не только освоить новые знания, но и задать вопросы экспертам. Регистрируйтесь и присоединяйтесь!
7 июля, понедельник:
8 июля, вторник:
9 июля, среда:
10 июля, четверг:
14 июля, понедельник:
Расписание всех открытых уроков уже доступно в календаре мероприятий. Выбирайте темы, которые вам интересны, и подключайтесь онлайн.
О систематизации регламента в прикладном программировании.
Всем привет! Хабр, — ты лучший.
В соседних темах о вечном споре между ООП школой и ФП школой у меня родилась идея создать по настоящему регламентирующий орган, который бы навел порядок в этом «борделе».
Пусть на основе IETF, будь-то на основе ISO, не важно. И вот спустя некоторое время, я читаю о очередной заголовок последней конференции C++, которая оказывается проходит под флагом того самого уважаемого института (организации) ISO. Казалось бы, чего еще тебе надо Сергей, и чем ты так не доволен?…
Вот только это все «фуфло» и сколько бы вы там не встречались, ни одна из вышеупомянутых организаций не осуществила никакого видимого прорыва в главных двух проблемах конечного ПО — это дыры и согласованость. Согласованость это наиважнейшая проблема взаимодействия между вендорами железа, вендорами ОС и собственно вендорами ПО. Такая согласованость, которая реализовано в глубоко и много любимом мной и родной для меня сферой связи. Да-да, я снова врываюсь к вам с моей «писяной торбой» — это сетевая эталонная модель OSI. Это пример на который вы, сильные мира сего в сфере программирования, могли бы и опереться, взять на карандаш, так сказать.
Здесь все строго формализировано. Да вы можете играться как хотите в своей песочнице, но за рамки определенных и прописанных в ПРОТОКОЛАХ правил вы выйте не сможете. Таким образом организуется БАЗОВЫЙ ПОРЯДОК.
И вот вопрос. Вот вы встречаетесь на этих конференциях, опять-таки под эгидой многоуважаемых организаций, но где протоколы?
Вот поэтому это все и «фуфло» эти ваши конференции. Вы там решаете какие-то текущие проблемы, разрабатываете какие-то очередные костыли, вместо того чтобы заложить уже один раз твердый фундамент взаимодействия между вендорами ПО, ОС и железа.
PS: да я понимаю, что кое-кому или даже кое-каким организациям это выгодно — держать все в таком виде в каком оно есть. Ведь всегда можно использовать дыру заложенную в железке или в святом С (на котором написаны ОС), а те чудики что там парятся над всей этой протухшей надстройкой (конечные программисты ООП и ФП) — пусть они заботятся об уязвимостях нулевого дня, о побеге памяти и прочей лабуде. А хомяки что? Хомяки сожрут, подавятся и отрыгнут, им не привыкать (еще и заплатят за ПО, за ОС, и саму железку). Да для бизнеса все стараются, а то что я обычный пользователь все это терплю, теряю бабки, нервы и прочеее — по пофигу (плебс).
Сделайте уже на основе примера сетевой эталонной модели Восьмой уровень — где будут формализованы основные точки поведения вендоров.
PPS: И да ребята, я могу в чем-то заблуждаться, поэтому вы все вольные меня поправить, открыть глаза мне…
Ура, и доброго дня всем!
Запускайте контейнерные приложения в облаке с Evolution Container Apps 💭
❓ Что за сервис? Evolution Container Apps позволяет запускать контейнерные приложения в облаке, причем для этого не нужно разбираться в Kubernetes или развертывать виртуальные машины. Запуск проиcходит на базе Docker-образов.
🖥 Особенности и преимущества. Возможности сервиса применимы для любого стека — контейнеры могут использовать любую среду выполнения и любой язык программирования. В зависимости от нагрузки экземпляры контейнеров создаются или удаляются автоматически. Не нужно настраивать кластеры Kubernetes: достаточно загрузить Docker-образы в реестр и создать контейнеры в личном кабинете. А еще у Evolution Container Apps есть free tier: ежемесячный объем бесплатных ресурсов — 480 ГБ RAM и 120 vCPU, запускать небольшие приложения можно без оплаты.
👨💻 Кому будет полезно. Всем, кто использует Docker и хочет облегчить развертывание и масштабирование:
Разработчикам и DevOps-инженерам, чтобы быстро тестировать и запускать приложения.
Небольшим компаниям и стартапам, которые хотят сэкономить на инфраструктуре и попробовать бесплатные возможности Evolution Container Apps.
Большим проектам с микросервисной архитектурой, чтобы облегчить оркестрацию, развертывание сложных приложений за счет контейнеров sidecar и init.
Хотите узнать больше о сервисе? Смотрите запись доклада с GoCloud 2025, где мы рассказали, как сохранить данные в S3 при работе с Evolution Container Apps. А еще сохраняйте пошаговый туториал, как запустить облачное приложение с Evolution Container Apps, без Kubernetes и развертывания ВМ.
Хотите стать мастером регулярных выражений?
Тогда новый бесплатный курс — для вас!
Кто-то боится регулярных выражений, а потому избегает их. Кто-то пользуется этим инструментом и решает с его помощью сложные задачи. Мы подумали, что хорошо бы собрать полезные статьи по этой теме в одном месте и помочь читателям избавиться от «регекспофобии». Ну или, наоборот, усугубить ее — тут уж как получится.
В курсе разберем не только базовый синтаксис, но и осветим темы посложнее. Посмотрим даже, как можно комментировать регулярки в движках, которые не поддерживают такую функциональность. Уделим особое внимание работе с кириллицей. Все разбираем на примерах.
После изучения материалов вы сможете:
моментально извлекать данные из гигабайтов текста;
валидировать формы любой сложности;
правильно обрабатывать тексты на русском (никаких сломанных \b);
решать сложные задачи с помощью lookarounds и именованных групп;
повысить свой уровень в работе со скриптами и редакторами.
Все материалы бесплатные. Не требуется даже регистрация.
Совершенный assert() для всех языков программирования
...как ни смешно, но пострадали стоматологи: стало меньше зубовного скрежета!
Когда C/C++ разработчики переключаются на другие языки, им очень не хватает привычного механизма assert()/NDEBUG. Он, в некотором смысле, позволяет получить "идеальный" метод управления Debug/Release конфигурациями:
Как вы правильно поняли, в Release конфигурации строки кода между #ifndef NDEBUG и #endif полностью исчезают, и мы получаем идеальный билд. Но идентичного результата можно добиться и с помощью комментариев... (здесь должна была быть картинка, но вставить не получается)
Гмм.. Значит будет лишь краткий конспект статьи.
ОК, как ни странно, но это правда: я создал утилиту DebRel, полезную ВСЕМ языкам программирования! Комментарии специального вида (D0 - D9 и R0 - R9) позволяют минимальными усилиями добиться "идеального" управления Debug/Release конфигурациями:
Debug конфигурация дает нам всю необходимую диагностику! С различной глубиной.
В Release конфигурации нет никаких следов Debug-а! Ни байта.
А именно:
Конфигурация RN отменяет все остальные. Релиз -- эгоист!
Конфигурация DN оставляет лишь строки от D0 до DN. Вы задаете глубину отладки.
В общем, сразу читайте https://ders.by/arch/debrel/debrel.html Там есть подробности, исходники и сам debrel.exe.
Доступен репозиторий Project Ideas and Resources с десятками пет-проектов для реализации, где разработчики собрали огромное пошаговое руководство к наработке железных навыков программирования. Ресурс предоставляет бесплатный доступ к проектам разного уровня сложности: от простого шахматного приложения до полноценного клона Airbnb. Есть пошаговое руководство для реализации каждого проекта на самых популярных языках программирования: Java, Python, JS, C#, а также ссылки на теоретические выкладки, книги и видео по различным темам программирования.
🔺Пример MCP для Gemini CLI
Ковыряюсь с Gemini CLI, консольным кодовым агентом, который на днях вышел. Накидал пример, как расширить его функционал при помощи MCP сервера.
my_mcp.py
from openai import OpenAI
from mcp.server.fastmcp import FastMCP
import base64
import os
client = OpenAI(api_key=os.environ["OPENAI_API_KEY"])
mcp = FastMCP("openai-image-generator")
@mcp.tool(description="Generate an image with OpenAI Images API")
def generate_image(
prompt: str,
size: str = "1024x1024", # "1024x1536", "1536x1024", "1024x1024"
quality: str = "high", # 'low', 'medium', 'high'
background: str = "transparent"
) -> str:
"""Return a file path to the generated image."""
response = client.images.generate(
model="gpt-image-1",
prompt=prompt,
size=size,
quality=quality,
output_format="png",
user="test_user",
moderation="low",
background=background,
n=1)
image_base64 = response.data[0].b64_json
image_bytes = base64.b64decode(image_base64)
file_name = f"gen_image.png"
file_path = os.path.join(os.getcwd(), file_name)
with open(file_path, "wb") as f:
f.write(image_bytes)
return file_path
if __name__ == "__main__":
mcp.run()Тут вызывается API для генерации изображения, ключ берется из переменных окружения, картинка сохраняется на диск. И прописываем путь до файлика в settings.json Gemini:
{
"mcpServers": {
"openai-image-generator": {
"command": "python",
"args": [
"/path/to/my_mcp.py"
],
"env":
"OPENAI_API_KEY": "${OPENAI_API_KEY}"
}
}
}
}Если теперь просить сгенерить лого для своего репозитория, то Gemini составит релевантный промпт по репе, вызовает этот метод и по желанию обновит Readme проекта, добавив в него картинку.
Смысл тут в том, что так можно подключить любой вызов вашего внешнего инструмента.
В целом же есть куча готовых серверов, можно легко подключить GitHub для создания агентом пулл-реквеста или RAG на своих файлах. Хороший список есть в официальной репе разработчиков MCP протокола.
Вайб-кодинг это TDD в блестящей обёртке и с хорошим пиаром. Change my mind.
И в этом очень-очень много иронии. Давайте прямо: за дцать лет TDD не стал ни стандартом де факто, ни даже общепризнанной хорошей практикой. Если оценим комментарии к местным статьям про TDD, то они скорее всего будут негативными. Даже саму необходимость юнит-тестов постоянно подвергают критике.
Дцать лет апологеты пытаются продвинуть TDD под предлогом улучшения надежности систем и снижения количества дефектов. И дцать лет их полоскают.
Но тут приходит Андрей Карпатый (разработчик ИИ, научно-технический просветитель, ныне больше с креном в инфоцыганство) и говорит страшную вещь. А давайте детально опишем поведение юнита со всеми корнеркейсами и скормим нейронке. А когда нейронка выдаст не совсем то - уточним описание. И так по кругу, пока результат не станет идеальным.
И все такие: ВАУ!!!111 10 ИЗ 10, ГОСПОДИ, 10 ИЗ 10!1
Внезапно оказалось, что если продумать спецификацию, то кодинг - дело техники. А если еще обмазать тестами, то надежность будет железобетонная. И чем детальнее спека, тем лучше результат. Кто бы мог подумать! Хотя погодите-ка...
МойОфис Frontend&UX Talks уже начался!
Самое время смотреть и задавать вопросы спикерам в чате митапа!
Митап посвящен главным вызовам и проблемам в сложных интерфейсах. Спикеры расскажут о самых разных аспектах фротенда в 2025 году: от айтрекинга и других методов исследований до реактивного программирования и СSS-спецификаций.
Сам митап разделен на две категории: JavaScript и UX. В каждой из них, помимо наших специалистов, есть ребята и из других компаний: Лаборатория Касперского, Контур, Alpha Research Center. Всего на встрече будет семь докладов – их расписание можно посмотреть здесь.
Смотрите митап прямо здесь:
Также трансляцию можно смотреть на Youtube и ВК.
Заинтересовало? Тогда скорее переходите в чат митапа. Здесь можно задать вопросы спикерам, и получить раньше остальных доступ к записи выступлений :)
Глубокий спец vs Фулстек. Я наверное никогда не устану говорить об этой теме, потому что для меня фулстек это нормальное состояние разработчика, в смысле легко достижимое, а не история про то что это обязательно плохой спец во всем. Более того, для меня норма, когда разработчик:
- Может в бек в несколько языков
- Может во фронт
- Умеет и настраивает пайпланый от Docker Compose до Github Actions
- Может сетапить и настраивать облака
(дисклеймер: речь не о том, что таким должен быть каждый, а что это не рокет сайнс все это уметь на хорошем уровне, достаточным чтобы классно делать проекты)
Что обычно имеют ввиду под глубоким спецом? Что человек прямо досканально знает все, быстро дебажит, создает качественный и поддерживаемый код (это ведь подразумевается?).
Знает ли досконально все? Вообще не факт, а скорее всего нет. От того что человек занимается только чем-то одним, не означает что он сидит и как не в себя копает во внутрь по этой теме. Как правило я вижу другую картину, если делать долго и упорно одно и тоже, то в какой-то момент это все делается на автомате, а дальше человек просто останавливается в развитии (соседний фреймворк не считается) ну либо становится тем, о ком я пишу выше.
Быстро дебажит? Вполне, это правда, но не на каждую проблему, а на какие-то кейсы, где что-то стреляет. Но во-первых сейчас эту часть очень серьезно закрывает ИИ, а если он не справится, то в команде наверняка есть кто-то кто в этой теме сечет больше.
А качественный код? Вот тут вообще никакой корреляции. Да, мы все слышали, что приходят беки и пишут фронт, после которых надо все переписывать, но это не ситуация, которую я рассматриваю. Мы все таки говорим про фулстеков, то есть тех кто целенаправленно учит, а не пишет фронт, потому что попросили, а он не сечет и не планирует учиться писать правильно. Что касается в целом подходов, то люди с более широким кругозором и опытом пишут обычно лучше. Потому что качество кода проявляется не в мелких деталях, что вы например в курсе про более крутой хук. Это все локальные оптимизации. Качество оно про более высокий уровень.
На практике все чуть сложнее. Главный фактор, который вижу я, помимо “я не буду этого делать” - компания и команда в которой работает человек. Где-то это норма, где-то нет и в зависимости от этого и идет рост.
p.s. Больше про разработку я пишу в своем канале Организованное Программирование