Стремление уйти от ручного регрессионого тестирования — хороший повод внедрить автотесты. Вопрос, какие именно? Разработчики интерфейсов Наталья Стусь и Алексей Андросов вспомнили, как их команда прошла несколько итераций и построила тестирование фронтенда в Авто.ру на базе Jest и Puppeteer: юнит-тесты, тесты на отдельные React-компоненты, интеграционные тесты. Самое интересное из этого опыта — изолированное тестирование React-компонентов в браузере без Selenium Grid, Java и прочего.



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

Многие считают, что SMS — одна из причин того, что Твиттер так хорошо «выстрелил» на Западе. В США и ряде стран Европы твиты можно как публиковать, так и получать через SMS, при этом цена исходящего твита равна цене обыкновенной SMS, а входящие сообщения — бесплатны. Для пользователей без смартфонов (коих большинство) это значительно снижает порог на вход.

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

Некоторые проекты используют XSLT в качестве основного «движка» шаблонов. Помимо известных недостатков XSLT (например, его многословности, относительной медлительности и т.д.) у него есть и преимущества: «стандартность» языка, его идеология отсутствия «побочных эффектов» и pattern matching, возможность при необходимости вызывать методы helper-классов из шаблонов (через exslt-расширение). Какое-то время назад я выкладывал библиотеку ShortXSLT, позволяющую вместо громоздких <xsl:value-of select="/root/abc"/> и <xsl:choose>...</xsl:choose> писать просто {/root/abc} и {if...}...{elseif}...{/if} без потери производительности, так что проблема многословности отчасти решается.

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

Передаем данные в XSLT, минуя генерацию текстового представления XML

Представьте, что у нас есть контроллер, генерирующий некоторый вложенный PHP-список объектов для отображения на странице. Он должен этот массив преобразовать в XML, который потом пойдет на вход XSLT-шаблону. Хорошо бы, чтобы данное преобразование из структур PHP в XML выполнялось не вручную в каждом контроллере, а был некоторый промежуточный слой абстракции, который умеет применять XSLT-шаблон прямо к PHP-данным, минуя текстовое XML-представление. Так мы уменьшим вероятность ошибок, да и письмо сократится. Мы сможем работать с XSLT-шаблонами напрямую, минуя XML-представление данных.

Некоторое время назад я написал на Си PHP-расширение dom_varimport (также выложено на GitHub). Оно содержит одноименную функцию, на вход которой подается объект DOMDocument и PHP-массив любой вложенности. Функция заполняет переданный ей DOMDocument XML-представлением входного массива, и делает она это очень быстро — примерно в 20 раз быстрее, чем делал бы код, написанный на чистом PHP. Большой документ размером около 1 МБ с тысячами вложенных свойств и объектов формируется примерно за 1-2 миллисекунды.

Например, вызов:

Я получил это электронное письмо сегодня от Марка…

Привет Джо,
Во-первых я хотел бы поблагодарить вас за всю информацию, которую вы опубликовали на asp.net. Я почерпнул оттуда очень многое. Так же я слежу за вашими твиттами и меня заинтересовало, с чего вы начинали, как накапливали опыт для того, что бы стать Senior Program Manager в Microsoft. Если у вас будет возможность ответьте мне, я бы был очень благодарен.
Заранее спасибо,
Марк

Я получаю сообщения, подобные этому, один раз в несколько недель и вот наконец-то, я решил ответить всем, кому это интересно.

Честно говоря, у меня, давно сложилось впечатление, что если клиент (в данном случае броузер) что-то должен с сервера забирать без перезагрузки страницы, то это обязательно должен быть AJAX XMLHttpRequest. Ткнул куда-то пользователь, сработало событие, сгенерировался AJAX XMLHttpRequest-запрос, пришел с сервера ответ, коллбэк обработал его и пользователь что-то увидел.

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

Это перевод первых 10-ти советов статьи по оптимизации PHP кода. На хабре есть перевод более старой версии статьи — 40 советов по оптимизации вашего PHP-кода

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

Пишу по частям, иначе получится очень много материала сразу.

Это моя первая статья на хабре, надеюсь она получилась интересной.