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

Я думаю, что вы не раз уже гуглили, заглядывали в статьи, манифесты IT-гигантов о лучших практиках проектирования API. Я тоже.

Но в большинстве из них всё ограничивается описанием URL ресурса, мотивацией использовать пагинацию, сложными словами про кэширование и SSL. Это, безусловно, необходимо для общего понимания технологий, но практически не помогает, когда ты сидишь перед пустой страницей и надо начать “проектировать контракт”.

Я работаю тимлидом направления системного анализа в X5Tech и за все время развития карьеры сталкивалась с большим количеством кейсов проектирования Web систем. IT продукты в большинстве очень динамичны: постоянно изменяются требования, появляются новые, итеративно улучшается пользовательский опыт (по принципу 20% усилий на 80% результата, а остальное доделаем потом).

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

В этой статье предлагаю спроектировать контракт по шагам, и на каждом из них я расскажу про общие рекомендации из копилочки “Полезное”, а также про личные правила и практики, полученные долгим опытом работы над постоянно меняющимися ИТ-продуктами, которые помогут для “дальновидного” проектирования GET REST API.

Чем больше у backend‑разработчика знаний в своей области, тем лучшим специалистом он является. Но опыт показывает: самые классные программисты подобны Сократу, который не стеснялся заявлять во всеуслышание «scio me nihil scire», что в переводе на общенародный — «я знаю, что ничего не знаю». Сомневаясь во всём и вся, вы никогда не упустите из виду то, что многие считают «банальным» и «общеизвестным», а потому легко избежите проблем, которые возникают у слишком уверенных себе. Рассказываю о вопросах которые, могут упустить из виду даже самые крутые backend‑программисты, и даю советы по защитите себя от нежелательных трудностей до того, как они станут критичными.

7 месяцев назад я стала тимлидом. От своих разработчиков я собираю обратную связь раз в пару месяцев. Поняла, что главный запрос от новичков — полезные и емкие инструкции по типовым задачам. Решила начать с таска, который наши программисты выполняют чуть ли не каждый день — ускорение сайтов. Если вы искали сборник лайфхаков, который можно спокойно отправить своим джунам — эта статья для вас. И для джунов, конечно. Инструменты проверки, оптимизация изображений, блокировка рендеринга — о всех этапах ускорения без воды с кодом и скринами. 

В начале — пару слов о себе. Меня зовут Полина и я работаю «Rocket Business» уже несколько лет. Свой путь от джуна до тимлида прошла именно здесь. Поэтому своим мини-пособием решила делиться в корпоративном блоге: оставляю в помощь потомкам и аудитории Хабра. 

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

В этой статье мы покажем:

• как в разных ситуациях манипулировать веб-сайтом таким образом, чтобы он передавал пользователям вредоносный JavaScript.
• как скомпрометировать администратора сайта, отправив ему личное сообщение;
• как атаковать разом всех пользователей при помощи комментария под статьей;
• как заставить пользователя отправить запрос на действия, которые он не собирается выполнять;
• как прослушивать WebSocket-соединения;
• и коротко объясним, как предотвратить все эти безобразия.

В общем, под катом вас ждет рассказ про распространенные уязвимости на стороне клиента и некоторые методы Client-Side защиты.

Здравствуй, дорогой читатель. Меня зовут Дмитрий. Я — системный инженер компании «Веб-сервер». На протяжении моего опыта оказания услуг технической поддержки сначала в компании Nginx, а теперь и в компании разработчика российского веб-сервера Angie, мы отвечаем на очень популярный вопрос: «Как организовать мониторинг состояния веб-сервера?». А вот так.

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

Приветствую всех читателей, меня зовут Вадим, я — бэкенд-разработчик в компании Домклик. В этой статье я хотел бы поделиться своим интересным опытом мажорного повышения зависимостей в проекте, который свыше пяти лет находится в проде под ежедневной нагрузкой более 2000 RPS. Мне пришлось обновить наш основной фреймворк сразу на несколько мажорных версий. Приглашаю прочесть как именно и зачем я это делал!

VS Code сам по себе не обладает большим количеством функций и возможностей. Но это можно легко исправить при помощи плагинов, которые доступны в магазине расширений VS Code. Под катом — несколько плагинов, которые могут пригодиться разработчикам. Здесь есть многое — от управления проектами до «нескучных обоев», т. е. изменений в дизайне. Что же, поехали!

История зарождения PHP

История PHP начинается не с полноценного языка программирования, а с набора CGI-скриптов на C, известного как PHP/FI 1. В этой статье мы возвращаемся к истокам PHP, рассматривая его первую версию, её компиляцию и функциональность.

О нашем девятимесячном пути к горизонтальному шардингу Postgres-стека Figma и о возможности обеспечения (почти) бесконечной масштабируемости.

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

С 2020 года стек баз данных Figma вырос почти в сотню раз. Это хорошая проблема, ведь она означает, что наш бизнес расширяется. Но в то же время она стала причиной технических сложностей. В течение последних четырёх лет мы усиленно старались не отставать от прогресса и избегать потенциальных проблем, связанных с ростом. В 2020 году у нас работала единственная база данных Postgres, которая хостилась на самом большом физическом инстансе AWS, но к концу 2022 года мы уже создали распределённую архитектуру с кэшированием, репликами для чтения и десятком вертикально разделённых баз данных. Мы разбили группы связанных таблиц (например, «Figma files» или «Organizations») на отдельные вертикальные разделы, что позволило нам обеспечить удобство инкрементального масштабирования и оставить достаточно пространства для дальнейшего роста.

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

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

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

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

Всем привет! Меня зовут Егор Молчанов, я разработчик в команде CRM для менеджеров ипотечного кредитования в компании Домклик. Хочу поделиться своим опытом создания VR‑тура с помощью фреймворка A‑Frame и библиотеки React. Для этого написал свой небольшой pet‑проект, который мы сейчас разберём.

Привет, Хабр! Так вышло, что на текущем я попал под сокращение, а значит путь к собеседованиям открыт. Как раз вчера случилось одно (видимо, из многих), на котором зашла речь про useCallback.

Всем привет!

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

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

Погнали!

Я потратил неделю, копаясь во внутренностях MySQL/MariaDB вместе с ещё примерно 80 разработчиками. Хотя MySQL и MariaDB — это, по большей части, одно и то же (я ещё к этому вернусь), я сосредоточился именно на MariaDB.

Раньше я никогда сам не собирал MySQL/MariaDB. В первый день «недели хакерства» я смог наладить локальную сборку MariaDB и твикнул код так, что запрос SELECT 23 возвращал 213. Сделал я и другой твик — такой, что запрос SELECT 80 + 20 возвращал 60. На второй день я смог заставить заработать простую UDF на C, благодаря которой запрос SELECT mysum(20, 30) давал 50.

Остаток недели я потратил, пытаясь разобраться с тем, как сделать минимальный движок для хранения данных в памяти. Именно о нём я и расскажу. Это — 218 строк кода на C++.

Привет! Меня зовут Артем Коньков, я frontend-разработчик в СберМаркете. А еще, я тот человек, который в фильмах ужасов спускается в темный подвал вопреки инстинкту самосохранения. Во-первых, потому что это интересно, а во-вторых — кто-то же должен это делать!

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