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

Привет! Я старший fullstack-разработчик в крупной b2b-команде, где мы активно развиваем IT турпродукты и сопровождаем легаси-проекты. Недавно мне довелось временно заменить тимлида — он ушёл в отпуск, оставив напоследок фразу: «Ты не будешь деплоить».

Спойлер: деплоил. И не просто деплоил, а чуть не похоронил релиз из-за одного неосторожного git reset --hard. К счастью, всё закончилось хорошо — но пришлось восстановливать ветки из GitLab’а, бороться с удалённой историей и вручную черри-пикать задачи.

Рассказываю, как всё было, какие выводы сделал и чего теперь точно делать не буду. Надеюсь, кому-то это сэкономит пару нервных клеток.

Несколько лет назад я начал добавлять Go в свой арсенал языков (будучи на тот момент Java разработчиком). Мне было очень непривычно. Более того, я принял язык не с первой попытки. Причём пришлось принять его больше из-за сложившихся обстоятельств, чем по собственному желанию.

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

Уточню: статья ориентирована больше на тех, кто планирует перейти в Go, чем для опытных разработчиков.

Привет, я собрал небольшой бортовой компьютер для авто, который умеет показывать температуру, время с момента включения и раздавать «Free Wi-Fi». В этой статье приведён код, список компонентов и всё остальное, чтобы собрать такой же. Назвал я его Kruk — от беларуского слова «Крук» (рус. «Крюк»).

Вот видео его работы на YouTube. Здесь его страница на GitHub.

Если вы уже посмотрели видео, то понимаете суть функции «Free Wi-Fi». Как только к Wi-Fi подключаются, система сразу переводит пользователя на captive portal, а сам компьютер начинает показывать, помимо температуры и времени, ещё два дополнительных окна с информацией о количестве пользователей, подключившихся к Wi-Fi, и о количестве пользователей, которые до сих пор к нему подключены (online).

Всем привет! Снова на связи Александр, автор проекта Peakline. Несколько дней назад я опубликовал здесь статью о своем «швейцарском ноже» для анализа тренировок, который я пилил в свободное время. Я ожидал пары конструктивных комментариев и, может быть, нескольких новых пользователей.

Я жестоко ошибался.

Всем привет! Я — разработчик и велосипедист, которому надоели ограничения Strava. Знакомы боли: GPS‑треки с «телепортами», платный анализ по зонам и неудобная загрузка сегментов на Garmin? Я решил исправить это и написал свой «швейцарский нож» для анализа тренировок.

Под катом — история создания pet‑проекта Peakline на Python, FastAPI и Vanilla JS. Расскажу, как устроен продвинутый FIT‑генератор для гонок с «призраком», как визуализировать исправление «сломанных» GPX‑треков и как заставить график и карту работать в связке. Поделюсь фрагментами кода, архитектурными решениями и подводными камнями при работе с API Strava.

Давным-давно, когда Joomla ещё была маленькой, в неё внедрили параметр $live_site. В ней хранился домен текущего сайта на случай, если Joomla не могла его определить из-за неверной настройки сервера. Нужно это было для разных SEO-компонентов, для использования редиректов и т.д.

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

Однако, параметр всё же остался в ядре Joomla. Зачем он нужен?

Или как я доставлял расписание студентам в новом формате решая несколько проблем, используя парсинг и PHP 7 в 2017-2021 годах.

Какие бывают схемы

В этой статье я расскажу, как всего за один вечер создал полноценный адаптивный SPA-сайт на Next.js без единой строчки кода — используя только AI и текстовые промпты.

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

Если вы думаете, что для создания SPA обязательно нужна кастомная разработка — эта история покажет, как современные AI-инструменты могут значительно упростить и ускорить процесс.

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

Иконки — это простой, но мощный инструмент, который помогает пользователю быстрее ориентироваться в интерфейсе.

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

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

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

В этот момент мы начинаем задаваться вопросом: «а как нужно писать и организовывать код на самом деле?». В поисках ответа мы читаем статьи, смотрим обучающие видео, доклады и неизбежно натыкаемся на Feature‑Sliced Design (FSD).

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

Наш фронтенд начинался как простой SPA на React, собранный с помощью Vite — типичный монолит с несколькими страницами. Со временем проект оброс новыми функциями и интеграциями и начал становиться всё сложнее в поддержке.

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

После изучения разных вариантов мы остановились на подходе микрофронтендов. Хотелось разграничить зоны ответственности между командами и ускорить разработку, не теряя гибкости. В качестве сборщика решили остаться на Vite — он быстро развивался, предлагал отличную DX и поддержку модульной федерации через плагин. Кроме того, важно было сохранить единый репозиторий, чтобы упростить CI/CD и управление зависимостями.

Привет, Хабр!

Общаясь с коллегами, я заметил, что они незнакомы с последними возможностями CSS. Как обычно, у всех свои причины. У кого-то много повседневной рутины. Кому-то в принципе неинтересно, что нового происходит в CSS. А кто-то по привычке использует подходы десятилетней давности и ему норм.

Как фанату CSS, мне грустно. Сколько же прикольных вещей проходит мимо них. Да и их код может быть меньше, надёжнее и проще для понимания. В общем, я собрал несколько фрагментов кода, которые были популярны давным-давно, и переписал их с помощью новых возможностей CSS.

Давайте посмотрим, что я вам подготовил.

Вместе с Самиром, Flutter-разработчиком в Surf, мы разберём, что за зверь этот Flutter Web. Посмотрим, что происходит у него «под капотом», какие трудности возникают в проде, как адаптировать UX под веб и какие виджеты помогут сделать интерфейс удобным.

Всем привет! Меня зовут Андрей Симагин, я автор программы для технического аудита сайтов SiteAnalyzer, и сегодня мы рассмотрим новую версию браузерного расширения SiteAnalyzer SEO Tools, в котором добавлена возможность отображения поисковой выдачи Яндекса и Google без сопутствующей рекламы путем скрытия соответствующих блоков из контента страницы. Расскажем обо всем подробнее.

Сначала я недооценил document.currentScript, но оказалось, что он отлично подходит для передачи параметров конфигурации прямо в теги <script> — и это далеко не все.

Порой я натыкаюсь на давно существующие браузерные API в JavaScript, о которых, по идее, я должен был узнать гораздо раньше. Например, window.screen или метод CSS.supports(). К счастью, я понял, что не один такой. Помню, как однажды упомянул window.screen в посте и получил неожиданно много комментариев от людей, которые тоже впервые о нем слышали. Это меня немного приободрило — я почувствовал себя не таким уж глупым.

Видимо, дело не в том, как давно существует API, а в том, насколько он полезен в реальных задачах. Если window.screen почти нигде не используется, о нем легко забыть.

Но иногда все же появляется неожиданный шанс применить одну из этих малоизвестных возможностей. Похоже, я как раз нашел такой случай для document.currentScript — и намерен использовать его по максимуму.

Работа должна приносить удовольствие — этой мой девиз. Если удовольствия от процесса или результата нет или его недостаточно, то надо что‑то поменять (может, и работу, но об этом как‑нибудь в другой раз). Сегодня хочу поговорить об окружающих нас, программистов, инструментах и как они нам могут пригодиться не только с точки зрения оптимизации скорости работы, но и с точки зрения некого мотиватора.

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

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

Еще давно я определил для себя, что мне нужно разнообразие в повседневной деятельности, иначе я очень быстро начинаю скучать и страдать от приступов кризиса среднего возраста. Также я понял, что меня вдохновляют инструменты («когда в руках молоток — все вокруг кажется гвоздями» — это про меня). Далее я расскажу мой путь, по которому я постепенно шел, ища подходящие инструменты для вдохновения и куда я в конечном итоге пришел и нахожусь в этом состоянии уже 3 года и пока мне все нравится.

Доброго времени суток!

Для начала представлюсь: я бэкенд-разработчик с опытом более 8 лет. Участвовал в разнообразных проектах: в стартапах, в галерах, в крупных корпорациях и в среднем бизнесе. К сожалению, найти идеальную статистику по данной теме не представляется возможным, однако из общения с бывшими коллегами я понимаю, что то, что будет описано ниже, — не только мой личный опыт, но и то, что регулярно происходит в других компаниях.

Если вы проджект-менеджер и не поймёте содержание этой статьи, это только подтверждает, что вы не способны контролировать данный процесс, и вас практически наверняка водят за нос. Хотя текст по написанию планировался максимально понятным и наглядным с учётом специфики проблематики.

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

Прежде чем мы приступим к разбору, хочу уточнить, что я прямой апологет бритвы Оккама, и важным правилом в моём подходе является не плодить сущности без необходимости. Если возможно написать сервис в 100 строк — лучше написать так. Потом, если потребуется, его будет несложно переработать под более удачную архитектуру.

Сообщество разработчиков всегда вдохновляло меня своей открытостью и культурой обмена знаниями. В мире дизайна всё иначе — чаще показывают только финальные работы, а процесс и инструменты остаются за кадром. Хотя open-source — это не только про код, а про культуру: делиться, улучшать, переосмысливать и переиспользовать.

В этой статье делюсь опытом создания инструментов для дизайнеров, которые можно не просто посмотреть, а сразу использовать в своей работе. Рассказываю о запуске Collected — бесплатного конструктора портфолио, Swarm — платформы для онлайн-выставок, и Everywhere.tools — коллекции open-source ресурсов для дизайнеров.