Веб-разработка *

Coolify — это инструмент с открытым исходным кодом, который позволяет легко устанавливать на своём сервере разные приложения: сайты, базы данных, сервисы, скрипты, боты и остальное.

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

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

Два месяца назад я писал на Хабр о первом релизе Funxy — гибридного языка программирования. Тогда это был эксперимент по созданию своего языка с выводом типов, императивного, с функциональными возможностями.

С тех пор вышло несколько релизов. Мы исправили много ошибок, переписали рантайм и добавили недостающие инструменты. Хочу рассказать, что изменилось.

Стабильность: десятки багфиксов — падения на валидном коде, рекурсия, edge-кейсы VM

Рантайм: tree-walk интерпретатор → стековая VM (быстрее, легче по памяти)

Язык: const, return, лямбды (\x -> x + 1), list comprehensions, block syntax для DSL

Типы: strict mode, flow-sensitive typing

Тулинг: LSP и дебаггер

Embedding: встраивание Funxy в Go-приложения как скриптовый движок

Всем привет, меня зовут Алекс Гусев. Это третья публикация в линейке (раз, два), посвящённой тому, как меняется работа со знанием в условиях его избытка и почему внимание становится ключевым ограничивающим ресурсом.

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

Сервис‑воркеры сегодня — не экзотика, а рабочий инструмент: offline‑режим, агрессивное кэширование, «живые» обновления и всё такое. Под это уже давно есть отличный, проверенный Workbox, и я сам с ним работал.

Но по мере того, как я таскал SW из проекта в проект, у меня всё чаще возникало ощущение, что мне нужен инструмент с другим профилем: поменьше магии и слоёв абстракции, попроще вход в код и в «как тут всё устроено», конструктор из маленьких плагинов, которые легко прочитать глазами и отладить.

Поэтому я написал @budarin/pluggable-serviceworker — не вместо Workbox, а как более лёгкий, типизированный и прозрачный рантайм для тех случаев, когда хочется полной управляемости и минимально возможной когнитивной нагрузки.

Django Rest Framework (DRF) - чуть ли не единственный фреймворк для разработки REST на базисе Django. Мой нарратив о Django в прошлой статье заключался в том, что это неповоротливый монолит, который абсолютно не следует best practices и не стремится к ним. Если вдруг вы не задумывались о том, как связаны DRF и Django, то вас может быть немного это удивит - никак. Их делали совершенно разные люди, но каким-то образом они сошлись в общей концепции: игнор хороших практик, перегруженные классы и магия, превращающая разработчика в гадалку.

Бьюсь об заклад вы привыкли к инструментам разработчика в Chrome. Ежедневная проверка вёрстки, просмотр логов или анализ загрузку страницы делается на автопилоте. Но что если есть альтернатива, которая в некоторых моментах работает иначе и часто даже лучше?

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

В этой статье мы посмотрим на Firefox DevTools в деталях. Отойдем от банальных соревнований в стиле «у кого DevTools длиннее». Вместо этого разберем, в каких ситуациях панель Firefox может сэкономить вам время, а в каких всё же удобнее остаться в Chrome. Откроем для себя несколько приёмов, которые можно добавить в свою ежедневную работу, независимо от браузера.

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

Со временем я заметил: когда получаешь такое поздравление в Telegram, становится немного грустно, что человек хоть и поздравил, но не потратил время на то, чтобы обдумать и искренне пожелать чего-то хорошего и уникального только про тебя. Хотя понимаешь — это нормально. Поколение постарше привыкло обмениваться этими милыми, но безликими посланиями. Хотя не все делают это из-за нежелания — некоторым просто понравилась картинка, вот и скинули.

Привет, Хабр! Меня зовут Сергей, я фронтенд-инженер в Банки.ру.

В этой статье расскажу, как Zod помог нам перестать писать валидацию на уровне полей, подружился с React Hook Form и стал единым источником правды о структуре данных.

К Zod мы пришли не сразу. Долгое время типы и валидация у нас жили в разных слоях приложения: TypeScript определял структуру данных во время разработки, а отдельные функции или библиотеки (вроде Yup) проверяли входящие значения в рантайме.

Это классическая проблема: дублирование логики и рассинхрон. Типы в interface поменялись, а валидация осталась прежней (или наоборот). Мы пробовали Yup, но он казался громоздким в связке с TS: типы приходилось выводить вручную или мириться с тем, что схемы выглядят непрозрачно. В какой-то момент стало непонятно: зачем тащить отдельную библиотеку, если проще написать if (typeof x === 'string')?

С переходом на Zod всё стало значительно проще: одна схема одновременно является и валидатором, и источником типа данных.

Привет, Хаброжители! Node.js — это технология, которая изменила современный веб. Более 10 миллионов разработчиков по всему миру используют ее для создания быстрых и масштабируемых приложений.

Эта книга поможет вам присоединиться к их числу и превратить знания JavaScript в уверенные навыки бэкенд-разработки.

Вы научитесь создавать надежные, быстрые и масштабируемые приложения, востребованные в таких компаниях, как Amazon, Netfl ix, LinkedIn.

Недавно на Хабре вышла статья про создание RAG-системы для строительных ГОСТов. Команда Цифрового стандарта проделала титаническую работу — полгода вручную разбивали документы на смысловые чанки. Респект за настойчивость и результат.

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

Всем привет, меня зовут Дима, я делаю ИИ-функции в Gramax. Эта статья для тех, кто сейчас воюет с чанками вручную или пытается найти оптимальный подход. Делимся нашим путем от быстрого прототипа до продакшен-решения с метриками 90%+.

В прошлой статье "Ваш отчет никто не читает: Как мы научили разработчиков понимать падения тестов за 30 секунд?" мы разбирали, как слой Flows и декораторы позволяют разрабам не тратить время на дебаг отчетов. Статья вызвала большой отклик, и сегодня я хочу раскрыть «фундамент», на котором строится этот подход.

Многие годы нам продают BDD (Behavior-Driven Development) как "серебряную пулю" для коммуникации...

Давайте честно, это чушь. Никогда не понимал, зачем мы кормим этого монстра по имени Cucumber. Тратим до 50% времени на поддержку регулярок («клея»), возимся с хрупкими .feature файлами и боимся переименовать шаг, потому что все развалится. При этом ни один менеджер в здравом уме не заходит в ваш репозиторий читать эти файлы. Они все смотрят только отчеты.

Так зачем нам Gherkin на этапе написания кода? Представляю вам новую методологию BDR (Business-Driven Reporting).

Почему классический BDD (Gherkin) — это ошибка?

Gherkin заставляет инженера работать внутри IDE, как в текстовом блокноте. Это абсурд.

Всем привет, меня зовут Паша и я Head of QA. Ну… был им до недавнего времени. Мы оказались в банальной ситуации: проект пришлось приостановить по независящим от нас причинам — и я снова оказался «в поиске интересных возможностей».

И опять упёрся в саму парадигму найма. Бесконечная война соискателей и рекрутеров: одни не могут нормально рассказать, что умеют, вторые не знают, кого искать. В итоге ищут не человека, а функцию — и важно не то, как ты думаешь, а какие теги у тебя есть, чтобы пройти фильтры ATS. Эта парадигма ломает саму суть задачи найма.

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

Так появилась идея сделать собственный сайт. Не классическое резюме и не список технологий, а персональную визитку, более ориентированную на техлидов и C-level, чем на эйчаров и автоматические фильтры. Сам сайт я хотел сделать нескучным и изначально видел в голове в стилистике окна персонажа из Fallout 2 — с атрибутами, самооценкой скиллов, перками, и ироничным описанием.

И я осознаю: сам, без ИИ, я бы за это никогда не взялся. У меня поверхностное знание фронтенда, я не дизайнер и не веб-разработчик. Но у меня есть опыт производства IT-продуктов в целом — и мне стало интересно проверить вайбкодинг на практике.

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

Если хотите — вот сайт: pavel.rocks (для полного погружения лучше смотреть с десктопа, под мобилу я постарался адаптировать на современный лад).

А под катом — подробный рассказ о процессе: как я к этому подошёл, на какие грабли наступал, почему мобильный адаптив оказался сложнее, чем весь остальной сайт, и при чём здесь дихотомИИя. Ну или просто заходите, если вы любите Fallout 2 так же как я.

Недавно я публиковал статью про HeadHunter. Судя по количеству комментариев, она взбудоражила сообщество и превратилась в настоящее поле для дискуссий.

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

Сегодня я хочу объяснить, почему считаю, что ложь часто становится вынужденной мерой.

Редизайн сайта Артемия Лебедева – каждый раз, когда я заходил на сайт tema.ru мне становилось интересно, а как можно его обновить. И вот однажды идея появилась, а потом проросла в моей голове. Сайты умираю, ИИ развивается и нам нужен принципиально новый формат. Шалость удалась — с радостью делюсь с вам получившимся результатом.

Задача. Сделать редизайн сайта.

Важно. Это не коммерческий заказ, a просто моё упражнение и развлечение для души и мозга.

Зачем изобретать свой Street View?

Все мы привыкли к Google Street View, но что, если нужно показать пространство, куда машина со 360-камерой не заедет? Интерьер офиса, музей, университетский холл. Коммерческие решения для виртуальных туров часто дороги или ограничены в кастомизации.

tl dr:

• итеративный constitution.md

• промтинг фич с помощью md-файлов

• модификация скриптов speckit

• ChatOps с уведомлениями в Telegram

• git-ветки для контроля урона

• вычитка документации вручную

• авто-кодинг с код-ревью финального mr.

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

Мой друг попросил помочь ему с экселем. Он пусконалаживает-чинит-сопровождает всякие станки на всяких заводах и его контора, хоть и ведет дела в 1С, но это чисто бюстгалтерский учет и какому клиенту какая запчасть едет и на каком этапе ремонт конкретного станка — бюстгалтерии неведомо. Поэтому друг мой ведет записи в экселе. Точнее вел, пока станков этих было немного. А вот как их перевалило за десяток — тут-то его познания в экселях уперлись в потолок, а сам эксель стал как-то не очень шустро поворачиваться.

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

Потому что у заказчиков так бывает: в ТЗ написали одно, думали при этом другое, а на самом деле проблема предприятия в третьем.

Оказалось что у друга моего проблема вовсе не в экселе.

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

Создание блоков с вырезами всегда было трудоёмким, даже для вырезов простейшей формы. Фронтендеры годами тренировались мысленно рассекать блоки на части: прямоугольничек для контента, прямоугольничек для выреза и ещё парочка рядом с ним. И вдруг парадигма поменялась...

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

В статье мы сверстаем карточку с круглым вырезом двумя способами: традиционно‑дедовским и современным. Затем сравним объём кода, простоту и гибкость получившихся реализаций. И порадуемся, что будущее уже наступило!

Я не React разработчик. Я прибыл к вам с далёкой планеты с одной целью: внедриться и изучить слабые места вашей архитектуры, ваших подходов, дабы доказать своему народу, что ваша цивилизация слишком хаотична, чтобы создать что-то по-настоящему долговечное.

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

Моя главная претензия к современному реактивному сообществу проста: вы потеряли фундамент. Вы строите небоскребы на болоте, игнорируя три фундаментальных правила игры, которые заложили авторы библиотеки.

Я не нашел на хабре достойного представления фрейморка Jaspr сообществу и решил представить сам. Flutter, безусловно, хорошая магия: один код для всех платформ, в том числе и Web. Но за магию приходится платить. Платить мегабайтами загрузки, муками с SEO и ощущением, что ты принёс на пляж боулинг — вроде и весело, но как-то не к месту. Команда Flutter и сама честно говорит: Flutter Web создан для веб-приложений, а не для веб-сайтов. Для сложных дашбордов, PWA, для всего, что живёт за логином — да. Для контентного сайта, блога, лендинга — увы.

Знакомьтесь, Jaspr. Веб-фреймворк на Dart, который осознанно отказывается от канваса и пиксельной магии Flutter в пользу старого доброго HTML и CSS. Он выглядит как Flutter, ощущается как Flutter, но на выходе даёт то, что поисковики и браузеры любят и понимают: обычный HTML-документ и DOM. А попробовать на вкус его можно здесь.