Прим. перев.: эту статью написал автор Open Source-утилиты HTTP Toolkit, предназначенной для исследования и модификации HTTP(S)-трафика для нужд отладки и тестирования. В материале собраны примечательные особенности стандарта HTTP, которые долгие годы живут вместе с нами, однако не каждый догадывается об их существовании.

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

Часть из этих скелетов — малоизвестные, но вполне полезные функции, другие — странности, унаследованные от прошлых реализаций (на них ежедневно полагаются миллиарды соединений), а некоторые вообще не должны существовать. Что ж, давайте заглянем за занавеску…

Каждый год Оксфордский словарь английского языка выбирает «Слово года». Но в 2020-м что-то пошло не так. Издательство Оксфордского университета описало 2020-й как «год, который лишил нас дара речи», и сказало, что к нему невозможно подобрать правильное слово.

Но на наш взгляд, такое слово всё-таки есть. С прошлого марта в мире резко возросло использование слова «удаленно». Большинство предприятий отошли от традиционной модели офисной работы и стали пытаться организовать труд сотрудников из дома. Для разработчиков из СНГ это прекрасная возможность начать работу в лучших мировых компаниях. Зарплаты за рубежом выше, а возможностей сейчас стало больше, чем когда-либо прежде.

Мы постоянно исследуем рынок. Публикуем сотни вакансий ежедневно. И сейчас 40% выручки получаем от иностранных компаний, которые в основном нанимают программистов для удаленной работы.

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

Clone Wars

70 с лишним open-source-клонов или альтернатив популярных сайтов наподобие Airbnb, Amazon, Instagram, Netflix, Tiktok и т.д. В списке содержится исходный код, ссылки на демо, технологический стек и количество звёзд в GitHub.

Ссылка на проект

Ссылка на Github

Когда приходит новый разработчик, то перед ним встает задача запустить окружение для разработки. И до недавнего времени - это часто становилось похожим на танцы с бубном. Поставь 10 разных пакетов определенных версий, а еще окажется что твой собственный pet-проект требует другие версии или это даже может быть другой проект в рамках той же работы. Каждый раз из этой ситуации специалист выходил по своему, но основной проблемой помимо временных затрат на эту конфигурацию - оставалось, то что работоспособность от разработчика к разработчику или runner не гарантировалась.

К счастью - эта проблема решена в современном мире разработки, если не полностью, то в большей мере. Нам на выручку пришел Docker.

Помню первое впечатление от React hooks. Можно не писать классы. Не нужно описывать тип состояния, инициализировать состояния в конструкторе, теснить всё состояние в одном объекте, помнить о том, как setState сливает новое состояние со старым. Не придется больше насиловать методы componentDidMount и componentWillUnmount запутанной логикой инициализации и освобождения ресурсов.

Главная сложность в разработке приложения – накодить его функционал. Например, сделать редактирование текста для приложения-блокнота. Так я полагал, когда был моложе и наивнее.

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

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

Остров Пхукет в Таиланде — настоящий тропический рай с вечным летом, теплым морем и фруктами круглый год. Фрилансеры и удаленщики часто уезжают сюда на зимовку, но это не единственный доступный сценарий. Мы поговорили с Олегом — человеком, который профессионально помогает иностранцам переехать на Пхукет. Он сам приехал сюда в 2013 году, открыл бизнес и не просто зимует, а живет постоянно. Он расскажет, как вообще живется на Пхукете, что тут делать IT-специалисту, насколько легко остаться на ПМЖ и что ждет постоянных жителей и тех, кто хочет приехать на зимовку.

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

В рамках статьи я постараюсь просто рассмотреть и дать ответы на следующие темы:

• что такое архитектура и почему она должна быть чистая;

• как написать архитектуру, которая основана на сервисах;

• пример построения архитектуры для приложения заметок;

• интеграция архитектуры с реактом.

Эта документация поможет найти компромиссы между различными шаблонами (patterns) React, а также определить, когда использование каждого из них будет наиболее целесообразным. Нижеприведенные шаблоны позволят получить более практичный и многократно используемый код, придерживаясь принципов проектирования, таких как разделение ответственности, DRY (Don’t repeat yourself — не повторяй себя) и повторное использование кода. Некоторые из этих шаблонов помогут решить проблемы, которые возникают в больших React приложениях, таких как пробрасывание (prop drilling) или управление состоянием. Каждый основной шаблон включает пример, размещенный на CodeSandBox.

Приведенные ниже примеры не являются сложными, чтобы не смущать читателя деталями имплементации, которые не относятся к концепциям каждого шаблона компонентов.

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

Нормализация. От нее мы или страдаем или пишем собственное решение с множеством проверок на существование сущности в общем хранилище. Попробуем разобраться и решить эту проблему!

Учитывая насколько hype-driven является разработка софта в наше время, можно быть уверенным в том что через несколько лет будут существовать новые модные фреймворки для фронтенд разработки. В момент когда фреймворк на базе которого построено приложение выходит из моды — вы вынуждены либо поддерживать устаревшую (legacy) кодовую базу либо стартовать процесс перевода приложения на новый фреймворк.

Оба варианта сопряжены с ущербом для бизнеса. Поддержка устаревшей кодовой базы означает проблемы с наймом новых и мотивацией текущих разработчиков. Перевод приложения на новый фреймворк стоит времени (следственно — денег) но не несет никакой пользы для бизнеса.

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

Какие характеристики должны быть у web-приложения, чтобы соответствовать критерию "прогрессивное"? Понятно, что, как и обычные web-приложения, прогрессивные строятся на базе "большой тройки" web-технологий - HTML/CSS/JS. Но что именно делает web-приложения прогрессивными?

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

Рассказываю о небольшом цветовом фреймворке, который используется в нашей ДС. Сначала, как обычно, небольшой обзор бест-практисов, а затем мой велосипед.

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

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

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

Я много раз читал, как кто-то попробовал MobX, у него код получился запутанным с не контролируемыми изменениями, после чего он продолжил писать на Redux. Для MobX нет рекомендованной архитектуры. Но при использовании и соблюдении в MobX строгой и однообразной (имеется ввиду одинаковой в различных участках проекта) архитектуры, можно получить понятный код с контролируемыми изменениями в сколь угодно большом проекте. Я опишу один из вариантов, как этого добиться.

Эта часть статьи будет об осмыслении составляющих Redux. Так ли они необходимы, что является их аналогом. Также будет предложена более удобная альтернатива хука useReducer.

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

В этой части статьи я хочу показать, что:

— редьюсеры - это аналог обычных чистых функции для получения нового состояния.

— селекторы - это аналоги обычных функций с мемоизацией, которые возвращают данные.

— dispatch + action + action creators - это аналог обычных вызовов функций, и разбиение на dispatch, action, action creators является зачастую ненужным и используются не к месту.

Реактивность