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

Бизнесу нужно идти в ногу с пользователем. Сейчас потенциальному клиенту недостаточно только сайта, а теперь ему нужны еще и SMM-сообщества, E-mail и SMS-рассылки, мобильное приложение и, конечно же, общение в мессенджерах.

В связи с этим появились чат-боты.

Был тёплый, солнечный обед, все шло своим чередом.

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

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

Привет, друзья!

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

С чего все началось?

Прочитал статью Kent C. Dodds "Replace axios with a simple custom fetch wrapper", изучил несколько аналогичных утилит других разработчиков и решил, что могу сделать лучше. О том, насколько мне это удалось, судите сами.

Ссылки

Исходный код проекта находится здесь.

Обертка в виде npm-пакета — very-simple-fetch (хотел назвать пакет просто simple-fetch, но это название оказалось занято).

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

Что насчет Axios?

Наша обертка будет сильно похожа на axios. Это объясняется тем, что axios — лучший из известных мне инструментов для отправки HTTP-запросов. Он одинаково хорошо работает как в браузере, так и в Node.js. Безусловно, разработчики axios проделали большую работу. Однако в большинстве случаев нам для решения повседневных задач, связанных с разработкой веб-приложений, не требуется весь функционал, предоставляемый этим инструментом. Если в цифрах, то размер axios составляет 371 Кб, а размер very-simple-fetch — 9.33 Кб.

Конечно же, после смерти Flash веб не превратился в простую, скучную плоскость. К старту курса по фронтенду показываем, как при помощи Three.js и технологии WebGL создать магический шар с анимацией внутри объёма. Автор статьи не только опубликовал код на CodePen для удобной демонстрации, но и добавил на страницу ползунки, чтобы вы могли экспериментировать с шаром и сразу видеть результат. В конце вы найдёте ссылку на исходный код на Github и демонстрацию не на CodePen.

Это вторая часть статьи о применении комбинации технологий nest.js и NEXT.js. В первой части был создан и настроен проект, а также выбран способ отправки данных для SSR, в результате чего проект уже удовлетворял большинство потребностей при разработке простого сайта. В этой части можно узнать о том, как выжать максимум пользы из nest-next: Hot Module Replacement, CDN, удобный SSR и разворачивание "за слешом".

• Организационные
  　Культура разработки performance-first
  　Бюджет скорости
  　Performance mantras
• Те, что можно использовать независимо от языка и его реализации
  　Смена языка или фреймворка
  　Смена алгоритма
  　Оптимизация алгоритма
  　Вынос инвариантов на уровень выше
  　Boolean short circuit
  　Досрочный выход из цикла
  　Предвычисление
• Для языков/фреймворков, в которых нет ленивых вычислений и приёма copy-on-write
  　Shortcut fusion
  　Ленивое вычисление
  　Copy-on-write
  　Оверинжиниринг
• Зависящие от железа
  　Разворачивание мелких циклов
  　Предсказание ветвлений (Branch prediction)
  　Доступ к памяти: направление итерации
  　Доступ к памяти: [i][j] vs [j][i]
• Для языков со сборкой мусора
  　Мутабельность
  　Zero memory allocation или GC-free
• Специфичные для JavaScript
  　Антипаттерн: накопление строк в массиве
  　Антипаттерн: Lodash _.defaults
  　Idle Until Urgent
  　Даунгрейд кода: ES6 → ES5
• Примеры из код-ревью

Будущее веб архитектуры  программного обеспечения уже обретает формы и на этот раз server-side рендеринг (опять). Но есть кое-что новое,  а именно передача HTML по WebSocket.

Подход с использованием SPA(Single Page Appllication) и JSON API привел к тому, что многие команды разработки погрязли в бесконечных спорах о структуре данных и ошибках синхронизации между этими двумя слоями. Это увеличивает стоимость разработки, замедляет релизный цикл и сокращает время, которое можно было бы потратить на инновации.

Тут нет правильного варианта ответа, это вкусовщина. Единственная цель этой статьи – узнать ваше мнение по этому вопросу и окончательно сформировать своё, потому что сейчас я в сомнениях.

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

Независимо от того, каким фреймворком вы пользуетесь, и пользуетесь ли вообще, у нас есть HTML-шаблон и JavaScript-код. Код частично залезает в шаблон, и тут и появляется наша проблема. От чего отталкиваться при названии функций?

Разговоров о Docker очень много, а вот про LXC гораздо меньше шума. А ведь у LXC есть свои области применения, где он может оказаться удобнее.

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

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

Полноценная мультплатформенная (включая Мак, Линукс и т.д.) IDE с нормальным автокомплитом для Друпала, JavaScript и TypeScript.

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

Можно ли вообще не использовать регулярные выражения? А в каких случаях нельзя? Что делать, если использовать все-таки приходится? Предлагаю разобраться с этим. Определим ситуации, когда регулярные выражения можно не использовать, когда нужно использовать и как сделать так, чтобы не было мучительно больно к ним возвращаться.

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

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

Возможно, вы уже встречали термин «human factors design» в прошлом. Но что это такое?

Пост посвящён более подробному рассмотрению перечислений, добавленных в PHP 8.1.

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

Рассмотрим оба варианта:

Пример №1: ТЗ в виде неструктурированного потока сознания

Я хочу продать собственную книгу по кулинарии! В ней я собрал авторские рецепты со всего мира и добавил собственные фишки! Хочу, чтобы клиенты заходили на сайт и понимали, какие-же классные там рецепты - и что они обязательно должно её купить/заказать. Вот тут все картинки из книги, а тут тексты. Сделайте, чтобы прям было очень красиво и сочно. Желательно в тёмной гамме.

_____________

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

В этом случае, проект делается на наше усмотрение. А клиент должен находится на связи и отвечать на возникающие вопросы. Ничего плохого в этом нет. Но если после его презентации клиент говорит: А я вообще не так хотел! То, нужно быть готовым к тому, что переделывать его бесплатно никто не будет. Потому что, как именно вы хотели - никто не знает.