Прототипно-ориентированный язык программирования
До 2022 года я думал, что автоматизация — это удел только крупных компаний. Но в 2022 году я открыл для себя n8n, и всё изменилось. Теперь я автоматизирую рутинную работу, отчёты и даже целые бизнес-процессы — иногда менее чем за 30 минут. Вот как это работает, что меня удивило и что вы можете попробовать уже сегодня.
На старте проекта обычно встает вопрос о выборе готовой ui-библиотеки для решения шаблонных задач, таких как создание форм, инпутов, кнопок и других компонентов. Количество готовых ui-библиотек для React так стремительно растет, что уже сложно остановить свой выбор на какой либо из них. Зато в таком разнообразии каждый может найти библиотеку, подходящую под его задачи. В этой статье хочется рассказать о фреймворке Steroids, который разработан и поддерживается в нашей компании.
Изначально мы не планировали создавать фреймворк, а просто собирали удачные решения рутинных задач. Получился набор полезных утилит и мини-библиотек, который позволял нам работать быстрее. Мы постепенно добавляли в него новые элементы, он рос и видоизменялся, и в итоге вырос в полноценный фреймворк Steroids.
Недавно работал над хобби-проектом, который описал в другой своей статье. В процессе его реализации у меня возникло желание чиркануть пару абзацев о том, почему React — отстой, но в итоге я не смог удержаться и решил высказаться по полной…
Так что вот она полноценная статья, ещё больше той, из которой она родилась. Здесь я подробно опишу все проблемы React и поясню, почему это может не быть виной разработчиков.
Когда я начинал писать Node.js-сервис, который должен был интегрироваться с LLM-моделью, я уже понимал, что доступ к некоторым зарубежным API из России может быть проблемой. Именно поэтому моим первоначальным выбором была модель от Yandex Cloud — Yandex GPT.
Но после того как я и мои товарищи немного пообщались с ней, стало ясно, что Yandex GPT нам не подходит. Её ответы были слишком неестественными, «нечеловеческими» — особенно это было заметно в нашем конкретном кейсе. Поэтому пришлось искать альтернативу среди зарубежных моделей. Вариант обучать собственную модель отпал сразу — опыта у меня в этом не было, а искать кого-то, кто сможет это сделать, не было времени, так как хотелось быстро запустить. Так выбор пал на Gemini API от Google, о котором было много позитивных отзывов.
Однако это означало, что нужно было как-то решить проблему доступа из России, ведь мой сервис размещён именно в Yandex Cloud.
Кликбейтные заголовки, давайте признаемся, надоели всем. Сейчас они встречаются даже на Хабре. Программист Линус Ли, судя по всему, испытывал те же чувства и решил действовать по принципу «не можешь победить — доведи до крайности». В результате он создал Tabloid — полноценный язык программирования, где весь код пишется в стиле сенсационных заголовков.
Представьте язык, где вместо привычного function hello() вы пишете DISCOVER HOW TO HELLO WITH (англ. «узнайте, как сделать... с помощью»), а вместо return используете SHOCKING DEVELOPMENT! (англ. «шокирующее развитие событий»). А еще каждый листинг должен заканчиваться фразой PLEASE LIKE AND SUBSCRIBE.
Звучит как странная шутка? Да, но этот язык реально работает, имеет собственный интерпретатор и позволяет писать полноценные программы.
Привет, Хабр. Меня зовут Марат Исаев. В этой статье я кратко рассмотрю устройство самописного микрофреймворка и его применение для написания приложения-планировщика, чтобы вы могли написать свой фреймворк, для своих приложений. Подчеркну: статья образовательная и не охватывает enterprise-разработку.
Чтобы мой рассказ был более предметным, я сразу покажу код фреймворка и приложения. Можете скопировать его прямо в консоль, запустить и по мере чтения статьи тестировать, разбираться и исследовать.
Впервые про моделирование эволюции я прочитал в 13 лет в статье «Жить и умереть в компьютере» (Техника — Молодежи, №5 1993 год). Она произвела на меня столь неизгладимое впечатление, что я тут же загорелся идеей создать что-то подобное.
Однако никак не удавалось проработать законы мира. Как организмы будут «смотреть» на окружающий мир? Как общаться? Как атаковать? Как кушать друг друга? Наконец, как будет устроен их «мозг»? Реализовать виртуальную машину, как в статье из журнала, или использовать что-нибудь проще, типа конечного автомата или схемы из блоков И-НЕ?
Короче, муки творчества да и, что уж там греха таить, ограниченные технические навыки, не позволили довести идею до ума. Я вернулся к ней уже в зрелом возрасте, лишенный юношеского максимализма и перфекционизма. Решил: раз сделать навороченную модель не получается, стоит начать с чего-то более простого. А лень и остатки перфекционизма в организме прошептали: с чего-то максимально простого.
WebRTC - это технология, которая позволяет браузерам и мобильным приложениям обмениваться аудио и видео в реальном времени без необходимости использования промежуточных серверов. Это делает WebRTC идеальным выбором для приложений, которым необходим функционал видеозвонков, стриминга, и аудиовызовов.
Как говорил дядя Бен, большие продукты — это большая ответственность. И без сложных интерфейсов тут никуда: а с ними и исследования становятся труднее, и встречается больше препятствий на этапе кода — от нюансов реактивного программирования до риска утонуть в разнообразии CSS-спецификаций.
Для МойОфис как мультипродуктовой экосистемы со сквозными сценариями — все эти вопросы очень актуальны! Поэтому на прошлой неделе JS-еры, дизайнеры и UX-исследователи нашей и других компаний собрались на митапе под названием Frontend&UX Talks, чтобы обсудить эти и другие проблемы современного веба. Получилось интересно, драйвово и даже сказочно! (и я в прямом смысле этого слова :-))
Под катом расскажем в 7 тезисах, к каким выводам пришли и как именно: поехали!
О фронтенде в 2025-м году мы поняли, что...
Понятный и простой код — куда важнее, чем кажется
Примитивы это сказка! (причем буквально...)
Реактивное программирование актуальное и удобное! Но не для всех...
Следить за CSS обновлениями каждый квартал – базовый минимум
Темизация это нелегко, но есть лазейки!
В прошлой статье мы рассмотрели теоретическую основу такого понятия как полиморфизм. Теперь же перейдем к рассмотрению что там «под капотом».
Когда в одной из купленных для нашей ИТ-библиотеки книг начали попадаться забавные терминологические ляпы — вроде «жирных клиентов» и «микрослужб», — нам стало понятно: переводчик явно не из отрасли. Чтобы избежать таких «фейлов» и помочь сделать техническую литературу понятнее, в КРОК появился Read IT Club — команда рецензентов и экспертов, которые добровольно и безвозмездно правят и переводят книги по ИТ.
Все началось с небольшой инициативы внутри компании, но клуб быстро вырос до 40+ человек — специалистов из ведущих технологических компаний России. Вместе мы проверяем переводы для ведущих ИТ-издательств, таких как «Питер», «Бомбора» и «БХВ», чтобы книги были не только грамотными, но и действительно полезными. Ведь хорошая книга — это когда после нее не нужно ломать голову над тем, что же имел в виду автор, а можно спокойно работать.
В этой статье хотим поделиться нашей выборкой — изданиями по теме тестирования, которые мы внимательно проверили и с уверенностью рекомендуем: они помогают не путаться в терминологии и реально прокачивают понимание ИТ.
В конце — промокод на 25% скидку от наших друзей из издательства Питер.
Сегодня в нашем CI ежедневно запускается более 5 000 автотестов, которые проверяют всё: от корректности скриншотов панели до скорости отклика API. Это не просто тулза в пайплайне, а часть инженерной культуры команды, которая помогает нам выпускать изменения быстро и с уверенностью.
Привет! Меня зовут Михаил Шпаков, я руковожу разработкой Timeweb Cloud.
Мы вышли на рынок четыре года назад, в условиях, когда уже сформировалась сильная конкуренция, и облачные платформы были далеко не новинкой. Поэтому с самого начала для нас критичной стала скорость доставки изменений — чтобы не отставать, а опережать. Но когда твой продукт — чья-то продовая инфраструктура, нельзя позволить себе нестабильность.
Чтобы не выбирать между скоростью и стабильностью, мы сразу сделали ставку на автоматизацию и автотесты. Это позволило команде быстро выпускать новые фичи, не боясь сломать что-то важное, и при этом держать контроль над качеством на каждом уровне.
В этой статье расскажу, как устроена наша система, какие типы тестов мы используем, как выстроен процесс, и какие уроки мы из этого извлекли.
Привет, друзья!
В этой серии статей я делюсь с вами своим опытом решения различных задач из области веб-разработки и не только.
В этой статье мы изучим библиотеку react-force-graph-2d для рисования двумерных графов.
Демо приложения:
Локальный запуск приложения:
git clone https://github.com/harryheman/react-graph.git
cd react-graph
npm i
npm run devИнтересно? Тогда прошу под кат.
После переезда в США мой английский был на уровне A1. Вместо курсов и приложений я решил создать собственный языковой тренажёр и заодно прокачать себя как fullstack-разработчика. В статье рассказываю как я парсил словари, получил бан, внедрил геймификацию и достиг уровня B2 за год.
Всем привет. Меня зовут Виктор Степанов, я frontend chapter lead на платформе СберТеха GitVerse. Хочу рассказать про внутреннюю «механику» V8 и показать, как писать более быстрый код. Поехали!
Привет, Хабр! У каждого JS-разработчика есть своя история. История о том, как он впервые встретился с этим. Сидишь, пишешь код, всё логично, всё под контролем. И тут, чтобы проверить одну мелочь, открываешь консоль и из чистого любопытства пишешь:
[] + {} // Получаешь: "[object Object]"
// Хм, ладно, массив привел себя к строке, а объект стал... объектом. Логично.{} + [] // Получаешь... 0 ???
// ЧТО?!
Стоп. Как это вообще возможно? Мы только что поменяли местами два операнда и получили совершенно другой тип данных. Кажется, будто язык издевается над нами.
Всем привет! Сегодня я хочу поделиться историей одного странного и затянувшегося расследования, главным героем которого стал мой компьютер, а антагонистом — веб-версия Telegram. Эта история не только о поиске прожорливого процесса, но и о глубоких аномалиях в поведении современных веб-приложений, которые вызывают серьезные вопросы.
Кажется, мы окончательно запутались в терминах.
За последнюю неделю меня назвали вайб-кодером раз 20. Не то, чтобы меня это как-то оскорбляло, каюсь, пишу код в Cursor, но просто... Это ведь не так - просто по определению. Похожие чувства я испытывал, когда хакатонами стали называть любые мероприятия с кодингом, а их участников - хакерами. Но язык - штука живая, и писать душную статью о том, как мы все неправильно юзаем термины - точно не то, на что я хочу убить вечер воскресенья.
В этой статье я хочу рассказать кто такие вайб-кодеры, и не вайб-кодеры (а просто программисты, которые используют в работе ИИ-инструменты), и с какими проблемами сталкиваются и те и другие.
