PHP *

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

Большинство символов можно просто набрать с клавиатуры и использовать в коде PHP в их исходном виде. Например, $string = "php.watch" - это полностью допустимая строка в PHP, а $num = 42 - допустимое число. Также можно использовать многобайтные символы (для хранения которых требуется более одного байта), например, этот совершенно допустимый эмодзи: $emoji = "?".

PHP, наряду со многими другими языками программирования, поддерживает определенное количество escape-последовательностей для использования различных символов, которые не могут быть набраны с обычной клавиатуры, не могут быть представлены в текстовой форме (например, невидимые символы или различные управляющие символы) или иным образом не считываются. Эти символы используют escape-последовательности, которые распознает PHP.

Что касается чисел, PHP поддерживает стандартные десятичные числа, но также может использовать и другие нотиции, такие как двоичное, восьмеричное, шестнадцатеричное и даже научное (scientific) представление. Они могут сделать код более читаемым и понятным в зависимости от контекста.

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

Эта статья ориентирована скорее на новичков в программировании, но возможно кто-то сможет вдохновиться одним из описанных далее подходов.

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

Давайте отбросим эмоции. И посмотрим, что можно быстро предпринять, чтобы облегчить страдания.

В последнее время было достаточно много обсуждений производительности в PHP. И даже несмотря на то, что у нас есть PHP8, JIT и куча других улучшений, многие по-прежнему продолжают жаловаться на то, что PHP "недостаточно производительный". Что PHP - это язык, подходящий только для модели запрос-ответ. Что PHP слишком медленный и его не нужно использовать для высоконагруженных систем. С одной стороны от части всё это правда. Если мы строим какую-то систему, для которой вопрос производительности критичен, то использовать классический блокирующий PHP явно не стОит. Большая часть функций и библиотек PHP созданы для работы в традиционном блокирующем окружении, что уже подразумевает собой не самую высокую производительность. Однако PHP может работать быстро, более того, он может работать очень быстро. Как? Обычно у нас может быть две причины, из-за чего будет проседать производительность: мы либо совершаем какие-то сложные вычисления, либо у нас есть блокирующй ввод-вывод. Первое к сожалению (или к счастью) мы не можем решить в PHP. Но блокирующий ввод-вывод для PHP совсем не проблема. В PHP-сообществе есть люди, которые пишут асинхронный код уже на протяжении несколько лет. Конечно одновременно с этим бОльшая часть сообщества по-прежнему считает асинхронный PHP - дикостью. Я часто слышал: "Ты наверно совсем отчаянный, если собираешься писать что-то асинхронное на PHP". По правде говоря, у нас у всех есть это предубеждение, что PHP не подходит для подобного рода задач. И в большинстве случаев это предубеждение основано на неверных представлениях о самой "асинхронности". Неверные предубеждения в свою очередь ведут к неправильным ожиданиям, что в свою очередь приводит к разочарованию и обвинениям в том, что PHP "не по-настоящему асинхронный".

Хочу поделиться опытом автоматизации экспорта заказов из Aliexpress в несколько CRM. Приведенные примеры написаны на PHP, но библиотеки для работы с Aliexpress есть и для других языков. Структура запросов и ответов аналогична. Если перед вами стоит задача интеграции Aliexpress, надеюсь, эта статья будет вам полезна.

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

Меня зовут Alex Versus и сегодня с вами посмотрим шаблон Singleton, реализацию на языке Golang.

Какая суть?

Одиночка - относится к порождающим шаблонам. Гарантирует:

Привет! В эту субботу PHP-чат Нижнего Новгорода проведет свой четвертый офлайн-митап с интерактивной трансляцией. Доклады подготовят Валентин Удальцов из Москвы и Денис Юрьев из Новосибирска. Записаться на митап можно здесь, поставить колокольчик под трансляцией — здесь. Те, кто будут смотреть онлайн, смогут задать вопросы текстом или голосом прямо из браузера.

А под катом небольшое интервью с докладчиками про то, что не вошло в их выступления.

Какие уязвимости можно найти в типичном PHP-проекте? Удивительно, но любые — от слабых мест и уязвимостей в коде никто не застрахован. Чем быстрее мы их найдем, тем меньше риск для компании. Но чем лучше будем понимать, как можно атаковать наше приложение и как взаимодействуют друг с другом наши фичи, тем легче будет защитить код еще на уровне разработки. Тем более, что в PHP есть свои специфичные уязвимости — те же type juggling, insecure deserialization и local file include.

Чтобы повысить уровень безопасности кода, полезно думать как хакер и тестировщик одновременно, проверяя все возможные лазейки в коде. Сканеры уязвимостей, SSL-сертификаты, аудиты и прочие многочисленные инструменты защиты будут хорошим дополнением. О том, как всё это совместить, Антон Прохоров рассказал в нашем интервью. На конференции PHP Russia 2021 Антон представит в докладе уязвимости PHP-приложений и способы их эксплуатации.

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

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

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

При разработке фронтенд приложений (mobile/web), часто сталкиваешься с тем, что API на бэкенде еще не реализован. Приходится ждать разработчика на бэкенде, когда он предоставит нужные запросы, постоянно напоминая ему о себе. Не редкость и другая ситуация, когда нужные http запросы уже есть, но они реализованы очень плохо и криво.

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

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

Итак, начнем.

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

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

В тот момент я искал кнопочный телефон, чтобы заменить им смартфон, который отнимал уйму времени. Так ко мне попал matrix-фон Nokia 8110 с KaiOS на борту и именно с этого момента когда я клал трубку после очередного разговора, приятели шутили, что мне опять звонил тот самый бог сновидений Морфеус.

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

Важная информация для всех, кто стремится попасть на стажировку. Набор «антисоветов», которые можно «перевернуть» и применить на практике, чтобы повысить свои шансы на попадание в ту или иную компанию.

Всем привет. Меня зовут Сергей, я работаю в digital-агентстве Convergent лидером команды бэкэнд разработки. Одно из основных направлений работы агентства ⸺ это разработка под заказ веб-приложений. Такая деятельность подразумевает, что зачастую создается достаточно много однотипных проектов. Они могут отличаться механиками, но основные юзкейсы повторяются: регистрация, авторизация, личный кабинет, админка и т. д. В данной статье я хочу рассказать о том, как мы оптимизировали процессы переиспользования кода и пришли в итоге к модульному подходу, ну и затрону еще немного технической стороны вопроса. Основной язык программирования в компании — PHP, так что дальше я расскажу о работе с этим языком. В нашем случае он отлично подходит для создания сайтов различного уровня сложности, различных активаций и промо-кампаний.

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

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

Буквально через два уровня абстракций я оказался в коде, датированном 2016-2017 годами, то есть занялся software archeology. В какой-то момент меня возмутило, что вместо интерфейса репозитория в конструктор класса сервиса была передана реализация. Ещё одним уровнем абстракции ниже оказалось, что это всё-таки был интерфейс, но назывался он просто ContentRepository, а не ContentRepositoryInterface, как написал бы любой адепт ООП и принципов SOLID. Это уже не лезло ни в какие ворота, и я потребовал у архитектора оснований (кстати, рекомендую его статью о том, как мы вдвое ускорили построение лент подписок). Он в свою очередь невозмутимо показал пункт внутренних правил оформления кода, где была проставлена ссылка на статью 2013 года («А» — археология, как и было сказано).

Под катом — перевод этого материала.