Всем привет! Я потратил на ии кодинг 500 долларов за 10 дней работы с Девином, и в результате у меня получился онлайн редактор для АИ видео с открытым исходным кодом. Кто такой Девин, зачем я это делал и что в итоге получилось. Разбираемся ниже.
Теория — это прекрасно, но мое "расследование" не могло закончиться на простом понимании проблемы, ведь конечная цель любого инженера — построить работающую и надежную систему. К счастью, проверенные решения существуют.
Эти решения можно разделить на две большие группы: реактивные и превентивные.
За последние ~5 лет я много раз сталкивался с задачей собирать логи: обычно из маленьких или средних по размеру кодовой базы проектов. Отправлять логи из кода не проблема, у Java и Go для этого есть библиотеки практически из коробки. А вот разворачивать что-то для их сбора — головняк. Понятно, что решаемый (ещё до ChatGPT, а сейчас так тем более), но всё же. Все системы логов, прежде всего, ориентированы на большой-большой enterprise мир и его требования, а не на простых смертных с несколькими палками, клеем и дедлайном "вчера".
Запуск ELK для меня каждый раз испытание: куча настроек, нетривиальный деплой, а при заходе в UI разбегаются глаза от вкладок. С Loki и Graylog — немного проще, но всё равно функций сильно больше, чем мне нужно. При этом разделять логи между проектами, добавлять других пользователей в систему так, чтобы они не видели лишнего — тоже не самый очевидный процесс.
Поэтому примерно год назад я решил, что сделаю свою систему для сбора логов для себя: максимально простую в использовании и запуске. Чтобы разворачивалась на сервере одной командой, вообще без настроек и без лишних вкладок в интерфейсе. Собственно, так появился и теперь вышел в open source Log Bull: система для сбора логов для разработчиков с проектами middle-sized размера.
Решил попробовать вайб-кодинг и заодно сделать полезное дело — создать HR-сайт для компании, в которой я руковожу ИТ-департаментом. Рассказываю, что меня впечатлило, а с чем пришлось повозиться.
Привет, Хабр!
Давно я ничего не писал для джунов. А ведь HTML и CSS не стали проще для них. Всё так же есть сложности, и мне надо как-то помочь людям.
Я выделил несколько привычек, от которых лучше избавиться в самом начале карьеры фронтендера — главное, просто сделать это. Надеюсь, вам будет полезно.
Давайте посмотрим, что я вам подготовил.
В первой части я рассказывал об основах CSS-препроцессора LESS: переменных, миксинах, и некоторых полезных приёмах. Во второй — про автоматическую проверку файлов с картинками и генерацию CSS из них же прямо в процессе компиляции, про то, как сделать изображения адаптивными, про миксины в роли функций и про основы написания LESS-плагинов на Javascript'е (они сильно расширяют базовые возможности LESS).
Cегодня же мы погрузимся в тему плагинов достаточно глубоко и добавим в CSS… ни много ни мало — статическую типизацию с валидацией! Которая, как и полагается системе статических типов, позволит отлавливать семантические ошибки ещё на уровне компиляции, а значит — писать более безопасный CSS-код с меньшим количеством сюрпризов. Кроме того, мы попробуем сделать систему разрешения потенциальных конфликтов, связанных с глобальностью таких элементов CSS, как анимации. Полный код плагина ищите в конце статьи.
В процессе же поговорим о разных тонкостях написания миксинов, которые могут быть полезны.
Добро пожаловать под кат!
Предыдущая статья: Часть 3: А при чём здесь The Thundering Herd Problem?
Thundering Herd — это о бесполезной трате CPU на пробуждение “лишних” процессов, которые не смогут выполнить работу.
Dogpile Effect — это о бесполезной нагрузке на внешний ресурс (например, БД) из-за многократного выполнения одной и той же работы.
Всем привет. Недавно пришлось решать проблему идентификации пользователя по номеру телефона в маленьком стартапе, позволяющим оформлять и оплачивать заказы онлайн. Почему именно номер телефона, а не электронная почта, например, или авторизация через соц. сети? Телефон сейчас, как мне кажется, де-факто стандарт для таких кейсов - это во-первых, а во-вторых, используя телефонный номер, можно подключать разные варианты его подтверждения: от смс до звонков с дальнейшим вводом либо кода из смс, либо последних цифр звонившего номера. Думаю, тут всем знакомы подобные механики.
Изначально я сразу и предложил использовать механику с СМС-шлюзом, но так как я тут имею дело со стартапом без инвестиций, то меня попросили придумать как на первоначальном этапе можно сэкономить (в идеале обойтись на этом этапе совсем без затрат), так как основной целью запуска было тестирование бизнес-идеи.
По предварительным исследованиям целевая пользовательская аудитория продукта является пользователями мессенджера Telegram. Вот в эту сторону я и начал думать. “Коробочный” механизм авторизации через виджет Telegram не отдает номер телефона пользователя, а нам именно он и нужен. Городить велосипед по получению номера телефона по id пользователя идея не самая лучшая, поэтому я решил сделать своего ТГ-бота для механики авторизации. Я на паре сайтов уже видел подобные решения, быстрый поиск по примерам реализации этой механики не дал внятных результатов. При поиске “авторизация telegram” я наткнулся на сайт, который был первым в поисковой выдаче. Пошел смотреть как у них все устроено, рассмотрим по шагам:
Почему «метод персон» и JTBD — это неработающий инструмент, призванный лишь создавать документацию по пользовательским требованиям и оправдывать решения команд на «фактах»...
Часть 3: А при чём здесь Thundering Herd?
В конце второй части я оставил вас с интригой: почему мой AI-ассистент решил поправить лектора и предложил термин Thundering Herd (несущееся стадо бизонов)?
С нуля создаем Node.js-сервис для GitHub, который использует LLM (OpenRouter) для построчного код-ревью Pull Request. Разберем: верификацию вебхуков, борьбу с непредсказуемостью LLM и превращение хаоса в отказоустойчивый инструмент.
Часть 2: В поисках классических проявлений Dogpile Effect.
Мое "расследование" началось с самого очевидного — поиска информации по термину Dogpile Effect. Хотелось найти каноническое определение термина Dogpile Effect.
Этим постом хочу открыть серию постов по материалам курса Архитектор ПО.
Управление репликами - как избежать проблемы Dogpile при горизонтальном масштабировании и что вообще такое Dogpile.
Эта статья поможет вам создать приложение Express 5 с поддержкой TypeScript.
Вы настроите готовый к продакшну проект с помощью различных инструментов для линтинга, тестирования и проверки типов. В случае, если вы новичок в REST API, не волнуйтесь, эта статья также включает объяснения основных концепций, которые следует знать, таких как маршрутизация (роутинг) и аутентификация.
Настоятельно рекомендую писать код вместе со мной. Мы будем использовать подход "Разработка через тестирование" (test-driven development, TDD) для создания REST API, который может стать основой вашего следующего приложения Express.
Предупреждение: не сомневаюсь, что наверняка кто-то, прочитав данную статью, возжелает закидать меня тапками, но это его право, я не претендую на истину.
Я начал писать эту статью около двух месяцев назад. Писал по мере возможности и уже почти закончил, как буквально на днях было обсуждение именно этой темы с коллегами. По результатам услышанных там вопросов я добавил еще пару абзацев, чтобы постараться ответить на данные вопросы в комплексе. Эта статья лежала в черновиках с декабря 2021г, я совсем про нее забыл.
В наше время каждый слышал про Web-API и у многих это ассоциируется с REST. Однако этот многострадальный REST всегда какой-то не такой, с ним все время что-то не так.
Разработчики часто спорят и упрекают друг друга, что твой REST недостаточно REST-овый. Это стало чем-то вроде культа или даже религии. Я не планирую рассказывать о том, как правильно готовить REST, но весь материал именно вокруг этого многострадального RESTа.
Ещё в 2009 году Тим Бернерс-Ли написал веб-спецификацию под названием «Socially Aware Cloud Storage», ориентированную на защиту общественных интересов при реализации облачных хранилищ:
«Есть такая архитектура, в которой несколько сетевых или веб-протоколов собираются воедино для создания всемирной системы, где приложения (десктопные или веб) способны работать поверх уровня стандартного хранилища, предоставляющего возможность чтения/записи.
Ключевые моменты здесь в том, что главные участники (пользователи) и группы идентифицируются по URI, то есть получаются глобальными, и управление доступом к элементам хранилища выполняется с использованием этих глобальных идентификаторов. В итоге хранилище становится общедоступным ресурсом, независимым от использующих его приложений».
Несколько таких идей активно обсуждались в цифровой среде в конце 2000-х, вскоре после взрывного развития монолитных платформ эпохи Web 2.0 вроде Facebook*.
Ещё одну схожую по духу концепцию в то же время предлагали разработчики Opera, которые хотели «встроить в ваш браузер веб-сервер».
И если Opera Unite так и не обрела полноценную жизнь, на предложенную Тимом спецификацию обратили пристальное внимание через несколько лет, когда сменившие один другой кризисы конфиденциальности явно указали на необходимость повышения степени независимости и контроля со стороны пользователей в веб-среде.
Привет, Хабр! Я Катя Саяпина, менеджер продукта МТС Exolve. В прошлом посте я рассказывала, как подключить второй фактор аутентификации через звонок робота, который диктует код. А еще — как реализовать рабочее решение на Django с использованием API МТС Exolve на примере сайта бронирования.
Сегодня продолжим тему. Покажу, как это решение можно масштабировать и оптимизировать: уменьшить затраты за счет сохранения аудиокодов, повысить надежность доставки с помощью fallback-канала по SMS, автоматически подобрать голос и язык диктовки.
Как нас попытались «положить» при запуске: история одного DDoS
Всем привет Мы — команда разработки ии‑ассистента для поиска работы, это третья статья, посвященная нашему продукту.
Я уже писал о внутрянке продуктовой и технической части, поэтому сегодня решил поделиться кейсом нашего третьего запуска, когда нас атаковали хакеры..
Привет, Хабр!
В этой статье речь пойдет об интересной задаче на одном из моих проектов. Он был разработан на React для документооборота сотрудниками. Так уж вышло, что со времен старта проекта основным текстовым WYSIWYG-редактором был небезызвестный Jodit. За долгие годы было написано много кастомных плагинов, например, для работы с упоминаниями сотрудников, и нас устраивала его надежность, хоть его внешний вид был далек от идеала.
И вот однажды заказчик пришел с запросом:
Привет мир!
Сегодня поговорим о версионировании и его важности в разработке. 📚 Многие из нас используют библиотеки, фреймворки и пакеты — и одним из популярных способов отслеживания их изменений является семантическое версионирование, или SemVer! 🚀
🤔 Почему это важно?
Версии продуктов, которые мы делаем или используем, сигнализируют о состоянии изменений. Если обновление было в 2013 году, скорее всего, продукт больше не поддерживается. 📅Но даже если продукт обновляется каждую неделю, важно быть осторожным — ведь обновление может нести «breaking changes» и нарушить работу приложения 😱, что вызовет у ваших клиентов грустное лицо.
✨ Как SemVer решает проблему с «breaking changes»?
SemVer следует строго определенной структуре, которая делится на три основных части: major, minor, patch, и опциональные, дополнительные маркеры - pre-release и build.
Каждая часть представляет из себя число, и затем они соединяются через точку.
