​​Github Actions - платформа на основе Github для автоматизации разработки. Позволяет автоматически запускать скрипты в проекте при наступлении определенных событий (например обновление кода в репозитории). Я давно поглядывал на эту технологию, теперь же она понадобилась на работе, и появилась возможность разобраться с ней получше

На рабочем проекте мне понадобилось автоматизировать три момента: проверку качества кода (wpcs рассказывал раньше), запуск тестов (phpunit расскажу позже) и сборку проекта.

Изначально скрипты для этих задач мог запустить каждый разработчик у себя на компьютере, но это было не обязательно, забывалось и качество кода не улучшалось. Теперь же перед выпуском каждого обновления обязательно запускаются проверки и не дают выпустить релиз, если код их проваливает. А после релиза код собирается в zip архив без лишних файлов (dev зависимости, тесты, конфиги на проде не нужны)

За время экспериментов с gh actions создал пару репозиториев у себя на гитхабе с запуском WordPress и с авторелизами. А все итоговые результаты в этом проекте Reepay - платежный шлюз для WooCommerce. Активно работаю над этим проектом, привожу его в порядок, пока не всё закончено

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

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

Самое трудное для меня сейчас - это покрыть unit тестами код, который вообще не предполагал тестирование. Тут и сильная связанность кода - невозможно запустить одну функцию без другой и огромные функции, тестирование которых превращается в интеграционное тестирование большОй части приложения, а не одного "юнита". Но я начал изучать тестирование ради этого проекта (всё тот же Reepay) и надо довести это дело до видимого результата.

Круто(а) помогла книжка "Принципы юнит-тестирования" от Владимира Хорикова. Правда я ее прочитал за два вечера, много чего не успел усвоить и теперь использую книгу как справочник. Еще рассчитывал покопаться в тестах ядра WP, их там дофига, но ничего для себя интересного не нашел. Скорее всего, как и с книгой, сделаю второй заход

​​За последний месяц самым интересным в программировании для меня так и осталось юнит тестирование. На данный момент Reepay Checkout покрыт тестами на ~20%. С одной стороны медленно, с другой медленно не просто так:

Оказывается код надо готовить к тестированию и делать это лучше в процессе разработки. Но Reepay начал разрабатываться кучу лет назад и тогда о тестах точно никто не думал. Самое важное - это уменьшение связанности кода, и в этом помогло Внедрение Зависимостей (Dependency Injection) или просто DI

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

Для чего это нужно в тестировании? Можно "внедрить" класс заглушку (Mock), который будет возвращать то что описано в тесте, и вместе с главным классом не будет тестироваться зависимость. А также убрать запросы к API и возвращать сразу то, что должно вернуться из запроса. Если есть запросы к API, то это уже не Юнит тесты, а интеграционные

И напоследок поделюсь великолепной статьей про создание DI контейнера на PHP с хабра - "Готовимся к собеседованию по PHP: Что такое «DI», «Container», «Auto-wiring» за семь простых шагов". Правда мне пришлось его доработать под свои нужны, выложу когда-нибудь отдельно на гитхаб

​​Single source of truth (SSOT) или Единый источник истины - концепция при которой в программе все данные можно создавать (получать, обновлять, удалять) только в одном месте.

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

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

Что если синхронизация не сработает? Или импортировать надо слишком много данных? Где-то появится устаревшая информация и для бизнеса это непозволительно. Поэтому было принято решения в локальную БД сохранять необходимый минимум для получения данных из API

Из минусов - выросла нагрузка на API, но клиента это никак не возмутило. Когда возмутит, можно будет настроить кеширование самых тяжелых запросов и дальше поддерживать концепцию SSOT

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

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

Еще обсудили Github Copilot - инструмент с искусственным интеллектом для написания кода. Его использовало несколько человек в компании, и им понравилось. В итоге решили дать доступ к copilot всем желающим. Кому понравится, тому copilot будет оплачиваться. Я пока не попробовал, но надо добраться

Теперь осталось привести в порядок все комментарии от коллег, обсудить, запустить в работу... В общем есть чем заняться до следующего ретро

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

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

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

0) Отключить кэш вообще
1) Отключать кэш только для залогиненных пользователей, которым надо отображать скидки
2) Подгружать информацию о скидках асинхронно через AJAX
3) Разбить кэш на фрагменты и кэшировать только общие для всех элементы

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

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

​​Сегодня опубликовал первую статью от имени Onepix.
Разработка платежного шлюза для Magento 2. Правда она не моя, а моего коллеги Димы Сполохова, который и копался пару месяцев назад в Magento. Я же выступал в роли редактора и тестировщика, но тестировал не Magento, а редактор сайта onepix.ru

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

А моя статья выйдет уже через неделю. Расскажу про установку и запуск unit тестов в WordPress плагине. В разработке уже серия статей на тему unit тестирования в WP, по плану будет выходить по одной в две-три недели

Следить за выходом статей можно в новостном канале Onepix. В будущем там будут не только статьи

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

PHPUnit для тестирования WordPress плагинов. Часть1: Установка

PHPUnit для тестирования WordPress плагинов. Часть 2: Как писать свои тесты

Публикация новой версии WordPress плагина с помощью Github Actions и SVN

​​Любопытно начал меняться вектор моей работы в компании. За две недели произошло много интересного:

1. Начал работать с новым стеком технологий.
Этот стек крутится вокруг PHP фреймворка Laravel и всего его окружения. У меня даже не было особо времени на изучение, поэтому изучаю сразу в бою. Да, код получился не самый лучший, но и проект на бекенде несложный — админка с созданием страниц, постов и получением информации из формы на сайте. Сейчас этот проект разворачиваю на сервере, так что еще понадобились знания nginx. И уже начался проект, где есть Docker. Пару лет назад я его даже изучал, о чем писал здесь, но тогда эти знания не пригодились

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

3. Теперь я официально на должности Backend тимлид
Когда я начинал этот чат, даже подумать не мог, что меня кто-то будет называть тимлидом, и я смогу управлять проектами, но прошло 4.5 года и вот оно. Даже есть моя фоточка с должностью на сайте OnePix. При этом я остаюсь программистом и пишу код. Но я всё еще далек от своего идеала и программиста, и тимлида, еще многое предстоит изучить.

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

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

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

Свою вики по проге я пишу уже пару месяцев по мере изучения нового и закрепления старого. И некоторые из заметок получаются достаточно качественными, чтобы ими можно было поделиться, только до звания статей они не дотягивают ни по объему, ни по формату. Поэтому я завел себе максимально простой блог, где вместо базы данных .md файлы из obsidian blog.ddaniel.ru, закинул туда пару заметок

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

И реализована просто, на backend'е роутинг от Symfony без всего лишнего, а на frontend'е bootstrap 5 для стилизации и markdown-it для рендера markdown в html. Расскажу о технологиях подробнее позже, когда доведу до ума их использование

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

Логотип вдохновлен современными иконками нейросетей, на которых изображена рандомная фигура, например у chat gpt это цепь в форме шестиугольника. В моем случае это изначально был тупо "куб с окошками". Чтобы лого не устарело еще до своего появления добавил в него букву D. Вроде, Лебедев говорил, что лучшее имя бренда - это фамилия. В общем понабрал идей отовсюду и собрал что-то свое (в духе типичного программиста)

А главное в минималистичном логотипе - это возможность сохранить его в noscript и растягивать до любого размера. Хотя в тг этого и не увидеть, потому что здесь только png с jpeg можно поставить на фото канала.

Еще noscript анимировать можно. Но до этого доберусь через пару-тройку лет

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

С понедельника это перестанет быть правдой. Я смог попасть на "Хардкорный курс PHP" от Валентина Удальцова, автора множества докладов и известного по каналам Пых и PHP Point. На курсе будет рассмотрена куча тем для middle PHP разработчиков, которые хотят стать senor'ами - мой случай

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

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

Новая версия блога еще в процессе, но я уже притащил в нее много новых для меня технологий:

Postgres — база данных, которая становится все популярнее и лучше, и в какой-то момент должна обойти MySQL по популярности. Я ее выбрал, потому что никогда раньше с ней не сталкивался, хотя на моем небольшом объеме данных нет разницы какую БД использовать

Doctrine ORM — абстракция над базой данных в PHP. Позволяет работать с базой данной не через SQL запросы, а как с PHP объектами и особо не думать, какая база спрятана за абстракцией. Плюс решает проблемы безопасности и настройки связей между сущностями. Документация только не особо для новичков сделана, много инфы даже по базовым принципам искал по гайдам и статьям

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

Docker — первый проект, который я успешно поместил в докер контейнеры для одинакового запуска на разных машинах. Первая попытка была примерно 4 года назад, но тогда и ручки были кривые и поддержка винды у докера была гораздо хуже. В этот раз все завелось удивительно быстро и без особых проблем. Так что новая версия сайта будет работать на связке из 4 контейнеров - php:8.3, nginx:1.24, postgres:16.2 и pgadmin4:8.5.

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

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

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

А на сервере хочу настроить обход через хуёкер.io, чисто из-за названия. На прод такое тянуть не стоит, но кто меня остановит в собственном проекте

​​Переезд блога с markdown файлов на полноценную админку я разделил на три этапа, которые условно названы 1) Требуемое 2) Нужное и 3) Желательное. Далее каждый этап разбит на спринты, чтобы примерно понимать, когда я смогу довести сайт до личного идеала. В итоге получилось, что сайт будет готов к концу лета

А сейчас закончен первый этап "Требуемое". Требуемым была возможность публикации постов и объединение их по тегам. Еще была идея добавить категории, но они бы просто дублировали теги - так что вычеркнуто. Также добавлены хлебные крошки для более удобной навигации и подсветка кода в постах

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

Пока тестировал новую версию сайта, дописал и релизнул пару своих заметок: Принципы SOLID
и PHP стандарты форматирования кода. Хотя посты можно писать прямо в админке с предпросмотром, я продолжаю использовать Obsidian, копируя из него контент на сайт

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

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

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

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

Еще меня интересует тестирование интерфейса в браузере. Для этого есть множество конкурирующих js фреймворков. Меня привлекли jest и cypress и пока не сделал выбор в пользу какого-то одного, потому что при начальном использовании они по сути одинаковы.

После того как написаны первые тесты, важно организовать их автоматический запуск перед внесением изменений в репозиторий с кодом, обычно это делается в CI процессах. Если этого не сделать, то есть вероятность, что тесты случайно или намерено не будут запускаться . А если тест не запускается, то зачем его было вообще писать? На работе автоматизация настроена с помощью GitLab CI, а для собственных я предпочитаю GitHub CI, но в обоих вариантах невозможно внести изменения в код, пока все тесты не пройдены успешно

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

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

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

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

Кажется началось)

Реально началось)
https://habr.com/ru/articles/831388/

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

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

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

У PHP вроде бы и есть встроенные возможности для работы с отдельными процессами, а вроде они и устарели, а потом опять появились, а потом deprecated статус. А кто-то сделал свою библиотеку для этого, но она работает только с определенными версиями PHP

Так что сейчас закопался в этот материал. Планирую подготовить статью, если кнч наберется интересный материал, который заминусуют на хабре не с первой минуты. Потому что всегда же "можно уйти на Go, Node, Python - зачем тебе пыха?"

Красивое
https://onepix.ru/about-us