На первый взгляд ничего не предвещало “грозы”, в метро все также у впереди проходящего через турникеты человека осталось 0 поездок и я снова задумался о том, что Матрица вот уже 10 дней работает без сбоев. Или все же это совпадение и у всех кто прикладывает проездной это была последняя поездка? Вчера я уже был близок к разгадке. Специально пропустив пожилого мужчину вперед таким образом, чтобы между мной и турникетом было два человека, в предкушении я потирал руки:

у первого ноль поездок, у второго… Упс у него пенсионный. Да, я живу в отменной симуляции и мне не нужна метавселенная от Меты и Маска).

Зайдя в вагон метро привычно достал смартфон и проверил почту. В одном из писем пользователь хабра в ответ на мой опус Создаем приложение Art-pixel на Angular и Nest.js. Часть 1, писал, что в демоприложении ошибка и при щелчке в одном месте,точка появляется на 12 клеточек правее и все это в Firefox последней версии.

Ошибка крылась в этом куске кода:

this.rendererRef = this.renderer.listen(this.canvasRef.nativeElement, ‘click’, (event) => {
let cX = event.layerX;
let cY = event.layerY;
const offsetLeft = this.canvasRef.nativeElement.offsetLeft;
const offsetTop = this.canvasRef.nativeElement.offsetTop;
this.canvasX = cX – offsetLeft;
this.canvasY = cY – offsetTop;
this.matr.data.map(data => {
if (cX >= data.x && cX < data.x + this.numberOf && cY >= data.y && cY < data.y + this.numberOf) { this.ctx.fillStyle = this.colorRect; this.ctx.fillRect(data.x, data.y, this.numberOf, this.numberOf); data.color = this.colorRect; } }) localStorage.setItem('matr', JSON.stringify(this.matr)); const data = this.canvas?.toDataURL(); }) }

Решил я разобраться. Первое, что пришло в голову это сравнить значения window.innerHeight и window.innerWidth

Мои значения получились следующие Хром 948х1485 против  602, 1920 значений Мозилы. Разрешение экрана 1920х1080, масштаб 100%. Выставил масштаб 200%, цифры соответственно поменялись Хром 408х525, Мозила 62, 960

Я задумался, вспомнил, что физические свойства отличаются от свойств браузера и есть devicePixelRatio – свойство глобального объекта window, которое содержит отношение разрешения дисплея текущего устройства в физических пикселях к разрешению в логических (CSS) пикселях. Также это значение можно интерпретировать как отношение размера одного физического пикселя к размеру одного логического (CSS) пикселя. Что ж значение window.devicePixelRatio при 100% в обоих браузерах составило 1, при 200% значение равно 2. Я подумал о том, что возможно я недостаточно осведомлен и для вычисления координат я использую не те значения. Но все же согласно документации innerWidth возвращает внутреннюю ширину окна в пикселях, включая в себя ширину вертикальной полосы прокрутки, если она присутствует. innerHeight, в отличие от innerWidth предназначено соответственно для возвращения внутренней высоты окна в пикселях.

Думаю дай взгляну на значения window.outerWidth и window.outerHeight которые предназначены для получения соответственно ширины и высоты всего окна браузера (включая границы самого окна, панель закладок и т.д.). В дополнение также решил посмотреть на window.screenX, window.screenY которые предназначены для получения положения окна браузера (т.е. его x и y координат) относительно экрана. Ну и глянул также на scrollX и scrollY которые используются, когда нужно получить количество пикселей, на которые документ пролистали в данный момент соответственно по горизонтали и вертикали.  Если уж смотреть, то нужно и на screen.height и screen.width взглянуть которые возвращают высоту и ширину экрана в пикселях.

Результаты были следующие:

Хром 

window.devicePixelRatio: 1; window.innerHeight: 948; window.innerWidth: 1423; window.screenX: 0; window.screenY: 27; screen.height: 1080; screen.width: 1920; window.outerHeight: 1053; window.innerHeight: 948; window.scrollX: 0; window.scrollY: 0

Мозила

window.devicePixelRatio: 1; window.innerHeight: 589; window.innerWidth: 1920; window.screenX: 0; window.screenY: 27; screen.height: 1080; screen.width: 1920; window.outerHeight: 1053; window.innerHeight: 589; window.scrollX: 0; window.scrollY: 0 

 Ок, я убедился, что у браузеров разные размеры моего окна.

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

Напомню, что getBoundingClientRect() возвращает объект DOMRect, который содержит размеры элемента и его положение относительно видимой области просмотра где left и top возвращают координаты X и Y верхнего левого угла элемента, а свойства right и bottom возвращают координаты правого нижнего угла элемента, width и height соответствуют ширине и высоте элемента (включают границы элемента border и внутренние отступы элемента padding, за исключением внешних отступов margin), свойства x и y соответствуют координате левой (x) и правой (y) границы прямоугольника относительно видимой области.

Что ж заряжаю document.body.getBoundingClientRect() в console.log и

хром – bottom: 1394.90625; height: 1394.90625; left: 0; right: 1408; top: 0; width: 1408; x: 0;y: 0;

мозила – bottom: 1399.75; ​height: 1399.75; ​left: 0; ​right: 1908;​ top: 0;​ width: 1908;​ x: 0;​y: 0

На всякий пожарный, проверил значение this.canvasRef.nativeElement.getBoundingClientRect()

хром – bottom: 774.703125;height: 550;left: 659.65625;right: 1209.65625;top: 224.703125;width: 550; x: 659.65625; y: 224.703125

мозила – bottom: 779.75​; height: 550​; left: 909.63330078125​; right: 1459.63330078125​; top: 229.75​; width: 550​;x: 909.63330078125​; y: 229.75

Как видим это ничего не прояснило. При том что в хроме canvasRef.nativeElement.offsetLeft -660; canvasRef.nativeElement.offsetTop -225; у мозилы canvasRef.nativeElement.offsetLeft – 910; canvasRef.nativeElement.offsetTop – 230;

Решил поскролить координаты, думаю вдруг вложенность контейнеров, canvas или другое что влияет, соорудил такое

координаты курсора относительно текущего окна

координаты курсора относительно документа

Эксперимент показал, что координаты, относительно окна: clientX/clientY и координаты, относительно документа: pageX/pageY у браузеров одинаковые.

Я не скажу, что я прозрел, но в какой то момент мне показалось что я понял очень важную вещь – я протупил.

И это оказалось действительно так, я упустил из виду, что все дело в layerX/layerY которые я использовал.

Ведь LayerX и LayerY извлекает x, y координаты указателя мыши относительно верхнего левого угла ближайшего расположенного элемента предка элемента, который запускает событие. Рядом с ними существуют также OffsetX, OffsetY  которые извлекают x, y координаты указателя мыши по отношению к верхнему левому углу элемента offsetParent элемента, запускающего событие. Элемент Offset Parent возвращает ссылку на ближайший элемент-предшественник в иерархии DOM, из которой вычисляется позиция текущего элемента. Вот так вот, все оказалось относительно просто, ошибка в этих двух строчках:

let cX = event.layerX;
let cY = event.layerY;

Заменяю на:

let cX = event.offsetX;
let cY = event.offsetY;

И все работает.

P.S. На самом деле все было не так. Я все это придумал или почти все, но письмо все таки было. А квадратики в Хроме в art-pixel так криво и кликаются. Проснись Нео, проснись…

Картинка Vincent Pontier

.

Подборка свежих новостей, инструментов и материалов из мира PHP.

Приятного чтения!

Этот дайджест подготовлен совместно с Insolita. Если понравился выпуск, плюсаните пост, пожалуйста.

⚡️ Новости

• The PHP Foundation Update, January 2022
  Фонд PHP стартовал свою работу в конце ноября и уже есть первые результаты. Получены и обрабатываются заявки на спонсорство от core-разработчиков, идет подготовка необходимых документов.
  Обзоры по работе фонда будут публиковаться каждый месяц, можно подписаться на твиттер @thephpf, чтобы следить за новостями.
• PHP 8.0.15, PHP 8.1.2
  Багфиксы для актуальных веток PHP.
• Drupal покинули группу PHP-FIG
  Зато теперь используют PHPStan в ядре.
• ❌ User Defined Operator Overloads
  Предложение добавить перегрузку операторов в PHP ожидаемо не прошло голосование.
  Автор RFC опубликовал довольно интересную инструкцию Как сделать RFC для PHP с пачкой неочевидных советов.
• Trait expects interface
  Интересное обсуждение поднял SerafimArts с предложением добавить поддержку ключевого слова expects для трейтов, как указатель на то, что класс использующий трейт, должен имплементировать определенный интерфейс.
  Скрытый текст

  trait LoggerTrait expects LoggerInterface
  {
  // …
  }

  class MyService
  {
  use LoggerTrait; // Fatal Error: Class MyService expects LoggerInterface to be implemented
  }

  class MyService2 implements LoggerInterface
  {
  use LoggerTrait; // OK
  }

  Это уже было в симпсонах есть в Psalm.

🛠 Инструменты

• thephpleague/flysystem 3.0.0 – Мажорное обновление популярной библиотеки для работы с файловыми системами. Блогпост в поддержку
• spatie/ignition – Обновлена библиотека для отображения страниц ошибок для отладки, многим знакомая по Laravel, но теперь не зависит от фреймворка и может быть использована в любых приложениях. Блогпост с обзором изменений.
• chevere/xr – Отладочный сервер на ReactPHP, вдохновлённый идеей spatie/ray, но вместо десктопного приложения просто cli-команда для запуска. Видеодемо.
• marijnvanwezel/reflection-file — Небольшая библиотека позволяет получить рефлексию по пути файла, а не по классу. Но если нужно больше возможностей, стоит обратить внимание на Roave/BetterReflection
• Doctrine ORM 2.11 — С подержкой перечислений, виртуальных столбцов, read-only свойств, вложенных атрибутов и другого.
• viewi/viewi — Мощный инструмент для создания реактивных приложений используя только PHP и HTML. Теперь есть интеграция с Symfony.
• JustSteveKing/php-sdk, Sammyjo20/Saloon — Две похожих библиотеки с одинаковой идеей: упростить создание SDK для сервисов или организовать доступ к разным API в едином стиле.
• AliSaleem27/wordle-cl — CLI-версия популярной игры Wordle для отгадывания пятибуквенных слов.
• flow-php/etl — Реализация паттерна Extract Transform Load для PHP. Тред от автора.
• staabm/phpstan-dba — Расширение для PHPStan, которое проверяет валидность SQL-запросов в PDO, mysqli и doctrine/dbal. Демо.

Symfony
Laravel
📝 Статьи
📣 Сообщество

Подписывайтесь на Telegram-канал PHP Digest.

Этот дайджест подготовлен совместно с Insolita. Если вам понравился выпуск, подпишитесь на Юлию в твиттере и поставьте плюс в пост, пожалуйста.

Заметили ошибку или опечатку? Сообщите в личку хабра или телеграм.

Прислать ссылку можно через форму или просто напишите мне в телеграм.
Поиск ссылок по всем дайджестам
← Предыдущий выпуск: PHP-Дайджест № 219

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

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

Правила оригинальной игры Wordle довольны простые – нужно за 6 попыток отгадать загаданное слово. После каждой попытки буквы введенного слова подсвечиваются определенным цветом:

• желтым – если буква есть в загаданном слове, но стоит в неправильном месте

• зеленым – если буква есть в загаданном слове и вы правильно определили ее позицию

• серым – если такой буквы нет в загаданном слове.

За сутки можно отгадать одно слово. Это позволяет легко сравнивать свой результат с друзьями и знакомыми. Пример как это выглядит можно посмотреть ниже.

Оригинальная игра на английском.

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

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

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

Изучив несколько, я выбрал версию на React, Next.js и Tailwind CSS, так как ее легче всего было изменить под себя + я был хорошо знаком с этими технологиями. Ссылку на этот репозиторий я оставить не смогу, автор по какой-то причине его закрыл. Но вы без труда можете найти подобный через Github поиск, с того времени их стало только больше.

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

От буквы Ё пришлось вообще отказаться, прости, буква Ё!

Рассчитывая на вирусное распространение игры, я много времени уделил механизму шеринга (кнопке поделиться) и даже улучшил его по сравнению с оригинальной игрой. В итоге поделиться результатами во все популярные соцсети и мессенджеры можно всего в один клик.

Оставалось только добавить словарь. На часах было около 2 ночи. К сожалению, готовых вариантов в удобном формате я быстро найти не смог, поэтому решил уже с утра написать небольший скрипт, который скачает с викисловаря 10 тысяч наиболее распространённых слов в русском языке и возьмёт из них все пятизначные слова (за исключением служебных частей речи).Всего в первую версию получилось добавить около 900 слов.

Как выглядит игра на русском

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

Продвижение

Вечером я опубликовал твит, в котором рассказал об игре и попросил знакомых и некоторых лидеров мнений ретвитнуть (большое спасибо @fillpackart, @TatarinFrontend, @usehex, @vas3k за ретвиты и лайки).

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

Уже на конец следующего дня посетителей было в 10 раз больше, более 4 тысяч человек. Благодаря тому, что люди активно делились результатами, приложение заняло первое место в трендах русскоязычного Твиттера.

После этого я написал нескольким журналистам в Твиттере, которые играли в оригинальный Wordle, что я сделал русскую версию. Это помогло получить первые ссылки в СМИ. На следующий день журналисты начали мне писать уже сами.

Наверное всего более 30 СМИ выпустили статьи с упоминанием моей версией игры в течение недели.

Некоторые сайты, которые написали о приложении. Скрин из Я.МетрикиРазвитие

Люди часто жаловались, что в словаре не хватает слов, поэтому в первые дни я в основном сосредоточился на добавлении новых слов. Спасибо также разработчикам @harris и @aednlaxer за то, что поделились своими базами и помогли расширить словарь. Сейчас в базе уже более 8000 слов на русском языке (в оригинале всего 2500). Хотя игроки до сих пор иногда жалуются на отсутствие некоторых слов.

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

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

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

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

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

В Вордли уже сыграли на всех континентах, практически в 80 странах, если верить счетчику Яндекс.Метрики. Более 3000 человек поделились результатами игры в социальных сетях. Больше можно посмотреть по хештегу #вордли

Еще из прикольного – начали появляться некоторое подобие теории заговора.

Планы

Реклама в веб-версии не планируется, на текущих объемах кричащие баннеры много не принесут, но сильно ухудшат интерфейс, что замедлит рост и испортит впечатление от игры.

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

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

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

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

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

Так что если у вас есть пожилые родственники, рекомендую отправить им ссылку на мою русскую версию Worlde и играть вместе, это будет не только весело, но и полезно для здоровья!

Выводы

Какие выводы можно сделать:

• Иногда скорость решает. Если я бы выпустил ее чуть позже, то скорей всего так раскрутиться не получилось. Лучше взять что-то готовое, чтобы запуститься быстрее и потратить больше времени на важное.

• Если тема горячая, то СМИ охотно идут на контакт. О появлении русской версии Wordle рассказали практически все популярные СМИ, что помогло получить еще больший охват.

• Нужно давать пользователям, то, что им нужно. Пользователь Твиттера Денис Пешехонов написал в реплаях Твиттера, что до моей версии видел еще минимум 3 похожих адаптации на русском, скорее всего их еще больше. Думаю моя версия взлетела, именно потому что больше всего была похожа на оригинал. Люди хотели играть именно в оригинальную игру на своем родном языке и у меня получилось дать им такую возможность.

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

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

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

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

Когда вы открываете любой сайт — например, google или facebook, вы видите конечный продукт. Но чтобы этот продукт увидеть, и пощупать, нужно:

1. Написать код приложения

2. Собрать проект

3. Поднять его на сервере приложения

Сегодня я расскажу про третий этап: что вообще такое сервер приложения и зачем он нужен.

Что это такое и зачем он нужен

Жила была Анечка. Она пекла вкусные кексики и тортики на заказ. Чтобы удобнее было делать заказ, решила Анечка сделать свой интернет-магазин. И обратилась за помощью к брату, разработчику Ване.

Ваня говорит:
— Да не вопрос!

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

А как сделать так, чтобы у нас в интернете появилась страничка? Для этого нужен сервер приложения. Ваня для магазинчика выбирает apache (Apache HTTP Server), как наиболее популярный.

Мои тестовые системы:

— Users
— Shop

Тоже подняты на Apache. И написаны на php, то есть не требуют сборки))

Сервер обеспечивает возможность обращаться с приложением по HTTP-протоколу. Вы, конечно, можете и сами написать такой код, но зачем? Когда для этого уже есть готовая система. Причем бесплатная и open-source.

Положили код PHP в сервер. Запустили — вуаля, оно работает! Теперь у Анечки есть свой интернет-магазин, доступный извне, с любого устройства.

Если бы код был не на PHP, а на Java, у нас добавился бы шаг «собрать проект» — из набора текстовых файликов получить приложение. Обычно это архив, например, test.war. И уже его мы подкладываем в сервер. Ну а PHP — интерпретируемый язык. Ему не нужен сборщик.

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

http://46.36.217.134:80/ → http://shop.cakes.ru/

Вот теперь точно все готово!

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

Преимущества серверов приложений

Готовый HTTP-сервер

Пожалуй, самая важная и популярная функция сервера приложений — поддержка HTTP-сервисов и текущих HTTP-стандартов. Зайдите на любой сайт в интернете — фактически вы отправляете HTTP-запрос в приложение:

Да, можно написать обработку запросов самостоятельно. И следить за стандартами, постоянно обновлять код… Но зачем, когда есть готовый сервер?

Для небольших проектов хватает HTTP-сервера, без дополнительных функций и плюшек. На текущий момент самый популярный сервер — Apache HTTP Server. Есть и более сложные сервера, например, Wildfly. Они имеют больше функций и используются в энтерпрайз системах.

Систему Users мне делал фриланс разработчик. Она написана на PHP и поднята на сервере Apache.

А на работе у меня на одном из проектов был enterprise продукт.. Написан на Java, поднимается на сервере Wildfly.

Поддержка горячего резерва

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

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

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

Каждая нода может обработать запрос независимо. Если приложение имеет какое-либо состояние, то оно может быть сохранено в общую БД. А также ноды могут оповещать другие ноды об изменении состояния через очереди/топики.

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

Но какой бы ни был резерв, фишка в том, что синхронизацией занимается сервер приложения, а не разработчик. У разработчика не болит голова о том, как бы данные на разных серверах не разъехались. Он может сосредоточиться на бизнес-логике системы.

Централизованная настройка и управление

В сервере приложений обычно есть админка. Заходишь по специальному URL — и у тебя есть доступ к настройкам приложения. Вот так выглядит приветственная страница админки wildfly:

Если у вас несколько серверов приложения, то изменение настроек может быть опасным занятием. Одну ноду (сервер) обновили, вторую забыли, а потом ловим баг.
Но так как сервер поддерживает работу в кластере, то все упрощается:

1. Мы меняем настройки в админке.

2. Они сами расползаются по всем нодам.

Безопасность

В больших бюрократических компаниях разделяют разных админов:

• админ физического сервера (железка, на которой установлено ПО)

• админ сервера приложений (например, wildfly)

Так вот, админу приложения дают доступ только в админку wildfly. Физически на сервер он зайти не может, или может, но на птичьих правах, логи почитать. А если нужно параметры системы изменить — извольте заводить заявку для админа железяки.

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

Поддержка транзакций

Сервер поддерживает поддержку XA транзакций — когда несколько транзакционных источников поддерживают распределенную спецификацию, и сервер ее координирует.

Например, что-то записали в БД и послали сообщение по JMS, всё в одной транзакции, вот сервер приложений предоставляет в том числе менеджера распределенных транзакций.

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

И наверняка есть что-то еще

Я честно пыталась выведать у знакомых разработчиков, зачем вообще сервер приложения нужен.

Оказалось, что он, в общем-то, и не особо нужен. Ну разве что как HTTP-сервер, хотя и для этого уже есть готовые библиотеки, можно в коде это все делать и запускать условный Main.java, без всякого дополнительного сервера.

На работе в одном из проектов мы использовали wildfly. Он дает кучу возможностей, но по факту мы использовали:

• HTTP-сервер — а куда же без него?
• Datasource — файл, где прописывается соединение с БД
• MQ-очереди — для горячего резерва, синхронизация нод между собой. Один сервер уведомляет другой об изменениях. Если другой сервер пока занят, то это сообщение встает в очередь.

Вот и всё!

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

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

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

Можно обойтись и без сервера. Да. Но с ним удобнее =)

Другие определения сервера

Когда вы разговариваете с коллегами, очень важно, чтобы вы говорили на одном языке!

Поэтому учтите, что под сервером приложений могут понимать разные вещи:

1. Сервер приложения как ПО — Apache, Wildfly, и другие. Та программа, которая запускает ваше приложение.

2. Физический сервер — компьютер, на котором установлен wildfly

Вот, например, одно из определений:

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

Тут сервером называется именно программа. А вот другое определение:

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

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

Так что если сомневаетесь, что вы с собеседником говорите об одном и том же, лучше уточнить, что он имеет в виду!

Дополнительные материалы

List of application servers — https://en.wikipedia.org/wiki/List_of_application_servers

Top 10 Open Source Java and JavaEE Application Servers — https://blog.idrsolutions.com/2015/04/top-10-open-source-java-and-javaee-application-servers/

Итого

Сервер приложения — это ПО, которое запускает ваше приложение. Сначала разработчик пишет код, потом собирает билд сборщиком… Но это просто некий архив с кодом. А вот чтобы это стало доступной в интернете ссылочкой, и нужен сервер приложения.

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

Кажется, мы стоим на пороге монополии одного браузерного движка. Вроде бы браузеров много: Chrome, Firefox, Edge, Safari, Brave, Opera, Vivaldi, Tor и десятки других… Но если присмотреться, картина вовсе не такая разнообразная. Большинство из них сделано на одном движке — Chromium. Даже Microsoft убила Internet Explorer и перешла на Chromium. Это значит, что мы возвращаемся к монополии, как в начале 2000-х годов. Только тогда это была монополия Microsoft, а сейчас — Google. Возможно, единственная сохранившаяся альтернатива — это Mozilla Firefox.

Почему Firefox?

Потому что это единственный альтернативный браузер с открытым кодом. Все остальные или на движке Chromium, или представляют собой проприетарные корпоративные инструменты, как Apple Safari.

К тому же Safari работает на движке рендеринга WebKit, что и Blink в Chromium. Так что здесь единственная реальная альтернатива — это Gecko/Quantum в Firefox.

Firefox потерял 40 миллионов пользователей с 2019 года

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

Несмотря на все свои преимущества, Firefox всё равно теряет пользователей. Это видно даже среди самых преданных поклонников Mozilla и тех, кто двадцать лет назад использовал Netscape Navigator и платную Opera — даже среди них многие сдались и перешли на Chromium или другие браузеры на этом движке. Или даже на Google Chrome, мол, а что делать? И в чем причина?

Согласно официальной статистике, на 31 декабря 2018 года активная месячная аудитория Firefox составила 244 248 100 человек.

К 3 января 2022 года аудитория сократилась до 205 929 800. Это означает, что за три последних года Лисичка потеряла около 38,3 миллиона пользователей! Это грустно, ведь Firefox до сих пор применяет инновационные решения. И он первым стремится внедрять технологии по защите безопасности и приватности. Например, в августе прошлого года Firefox первым среди всех браузеров реализовал поддержку Enhanced Cookie Clearing как часть общей защиты Total Cookie Protection.

Если в двух словах, механизм Enhanced Cookie Clearing гарантирует полную изоляцию и блокировку куков с определённого сайта. Идея в том, что каждому сайту выделяется отдельный файл jar (горшочек) для куков (печенек), см. техническую документацию по разбиению хранилища данных на разделы в Firefox. И в этом «горшочке» хранятся куки любых доменов, которые установились с этого сайта, и не только одного домена.

Таким образом, при очистке «горшочка» (раздела) условного comfypants.com удаляются в том числе куки facebook.com и весь остальной мусор, который проник в систему конкретно через этот домен. Это и есть Total Cookie Protection.

Вообще, по возможностям управления куками Firefox, кажется предпочтительней остальных браузеров (но это неточно). Когда смотришь на некоторые функции типа Total Cookie Protection с удалением всех куков раздела, то возникает вопрос: а почему так не делают все браузеры, ведь это единственно правильный алгоритм очистки куков!

Интересно, что даже сравнение с Brave по функциональности, производительности и другим параметрам показывает преимущество Firefox, хотя Brave вроде как специально создавался для гиков. О приватности и безопасности нечего и говорить: достаточно посмотреть на Tor (по сути, одна из версий Firefox).

Почему люди переходят на Chrome?

Наверное, у каждого свои причины. Но сразу приходят в голову такие:

• Некоторые расширения лучше работают на Chrome.
• Некоторые веб-сайты наилучшим образом оптимизированы под движок Chromium или вообще работают только на нём.
• Chrome — дефолтный браузер под Android. А если уже стал пользоваться каким-то браузером на смартфоне, то удобно запускать его и на десктопе, для синхронизации истории.
• Крупнейший поисковик в интернете рекомендует пользователям устанавливать Chrome (странно, да).

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

Firefox — единственная альтернатива?

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

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

Таким образом, кажется, что Firefox, пожалуй, единственная популярная альтернатива Chromium-браузерам. Если она исчезнет, у пользователей просто не останется вариантов.
Уже сейчас некоторые разработчики оптимизируют веб-сайты под Chromium, а если так продолжится и дальше, то все пользователи просто вынуждены будут перейти на него.

Монополии, обычно, это не очень хорошо. Все мы помним времена Internet Explorer, ставшего рассадником проприетарных стандартов. На пике в 2002–2004 годы доля Internet Explorer составляла примерно 95%, и это было действительно непросто. Теперь Microsoft уже совсем другая компания и поддерживает движение Open Source.

Но что сегодня? Доля Firefox на настольных компьютерах упала с 32% в 2009–2010 годах до 8% сегодня, а на смартфонах вообще близка к нулю. А все мы помним, что складывать яйца в одну корзину — плохая примета. Или вы думаете иначе?

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

Наполнением сайта занимается сообщество, а редакция Доки активно в этом помогает. Но в вебе важно не только грамотно рассказать о каком-нибудь свойстве или параметре, но и показать, как они работают.

Мы поговорили с Валей Броницкой, которая отвечает за визуальный контент в Доке, а также с дизайнером интерактивных примеров Светой Коробцевой и иллюстратором Кирой Кустовой. Они рассказали, как рисуют обложки, иллюстрируют статьи с помощью демок, схем и анимаций и как идут к тому, чтобы каждый автор мог создать визуал к своей статье и не переживать за собственные дизайнерские навыки.

В чём особенности контентной графики для Доки

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

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

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

Сейчас у нас есть три вида визуального материала:

• инфографика: схемы процессов и анимации,
• интерактивные демки с примерами кода,
• иллюстрации-обложки.

Схемы и инфографика

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

Схема в статье о структуре DOM — показываем, как выглядит HTML-код

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

Так выглядит наш конструктор схем

Со схемами сейчас работают редакторы разделов Доки. Мы собираем от них обратную связь и докручиваем конструктор, чтобы всем было удобно.

Мы добавили в конструктор новые элементы и вариативность, описали базовые шаги

Система демок

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

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

А в этой статье демка иллюстрирует событие keydown — нужно просто начать печатать любое слово

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

Первые демки авторы статей собирали самостоятельно на CodePen. Тогда у Доки ещё не было сайта, а статьи писали в Notion. Чтобы встроить интерактивный пример кода, его нужно было собрать во внешней песочнице — на codepen.io, repl.it или им подобных сервисах.

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

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

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

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

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

Пример демки в CodePen, которую собрал Николай Лопин. Изначально пример был рассчитан только на эту платформу: здесь нужно удалить код из вкладки CSS, а это возможно только в песочнице

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

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

Конструктор обложек статей

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

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

Наши первые иллюстрации

Мы начали разрабатывать новый стиль иллюстраций. Решили, что хотим уйти больше в «компьютерность» и грузить на сайт SVG, чтобы рассматривать картинки как код. Это удобно в плане поддержки быстрых изменений. Например, за счёт того, что мы загружаем все иллюстрации в SVG, мы можем что-нибудь перекрасить пакетно.

До — плавные линии и мягкие формы, а после — больше геометрии и узнаваемости

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

Везде хорошо — и в светлой теме, и в тёмной

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

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

Вариативность элементов для иллюстраций к статьям

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

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

Но наша главная цель — наращивать степень включения авторов не только в производство текста, но и контентной графики. Если вам есть что рассказать о веб-разработке, то приходите к нам.

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

С использованием Joomla довольно легко настроить cURL и все необходимые резервные варианты подключений в одной строчке кода.

use JoomlaCMSHttpHttpFactory;
$http = HttpFactory::getHttp(null, );

Этот код вызывает драйвер Joomla Http, позволяющий делать исходящие запросы на внешние URL. Этот драйвер использует драйверы транспорта в указанном порядке, то есть в данном случае в начале cURL (если доступен), а затем stream.

В Joomla 3 “из коробки” доступны 3 драйвера транспорта:

Создание вызова

HttpFactory в Joomla 3 поддерживает следующие типы HTTP-запросов:

• delete

• get

• head

• options

• patch

• post

• put

• trace

Все эти методы используют одинаковые аргументы:

1. URL – url вызова, end-point.

2. Data – массив данных, отправляемых в запросе.

3. Headers – заголовки http-запроса. Могут использоваться, например, для авторизации.

4. Timeout – установка специфичного таймаута для запроса.

Пример POST-запроса

$answer = $http->post($url);

POST-запрос с данными

$answer = $http->post($url, );Добавление опций запроса

HttpFactory может добавлять опции настроек для драйвера транспорта. Для этого нужно создать массив, где ключ – это опция, а значение – значение опции соответственно. Ниже примеры опций для cURL. Полный список в документации PHP.

$curlOptions = array();
$curlOptions = false;

Далее добавляем массив с опциями с помощью метода setOption().

$http->setOption(‘transport.curl’, $curlOptions);Токены аутентификации в заголовках запроса

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

Добавить нужные заголовки весьма просто. Создаем массив с нужными заголовками, а затем указываем его при создании Http-запроса.

if(!empty($access_token) && !empty($user_key)){
$headers = array(
‘Authorization’ => ‘AccessToken ‘.$access_token,
‘Content-Type’ => ‘application/json’,
‘charset’ => ‘UTF-8’,
‘X-User-Authorization’=> ‘Basic ‘.$user_key
);

if(!is_null($data)){
$headers = strlen($data);
}
$http->post($url,$data,$headers);
}

Далее уже оборачиваем запрос в try-catch и обрабатываем ошибки.

Обработка ответа

Ответом всегда является объект класса HttpResponse. Он имеет 3 свойства:

• code – код ответа сервера (200, 400, 301 и т.д.)

• headers – заголовки ответа сервера

• body – собственно тело ответа сервера

Заключение

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

От читателей приветствую пожелания и уточнения по терминологии.

Список источников: