Docker, Docker, Docker - последнее время слишком часто я слышу про эту технологию и тоже решил ее закинуть в свой список "изучаю WP, не изучая WP"
Для тех кто не в теме Docker - это программа для контейнеризации приложения. Приложение упаковывается в контейнер вместе со всем своим окружением и может переноситься на другие компьютеры без потребности настраивать это самое окружение - оно уже на месте
Я очень не люблю настраивать окружение что под WP, что под любой другой стэк. Когда наступает момент переноса кода на новую машину это немного "больно". И хотя ос, php и mysql под WP не особо трудно настаивать этот процесс хочется автоматизировать
На старом месте работы обычно один проект затягивался на пару месяцев, что позволяло не страдать от нужной первичной настройки. На новом месте проектов больше меняются чаще, и хочется упростить жизнь себе и другим разработчикам
Пока я далеко от желаемого результата, могу работать с чужими готовыми сборками, но не со своими. Планирую за выходные это исправить, материалов в открытом доступе достаточно, а на складе валяется курс, который я рекомендовал больше года назад. Тогда докер я не осилил, но и не особо в нём нуждался
Одной из итоговых точек для себя отметил создание стартового шаблона под WP тему или плагин на основе докера. А дальше уже мне точно будет хватать знаний, чтобы использовать готовые решения, которые создавало больше чем один человек, например Visible Wordpress Starter (655 звёзд), плюс туда можно будет залить Sage и будет вообще красота
Для тех кто не в теме Docker - это программа для контейнеризации приложения. Приложение упаковывается в контейнер вместе со всем своим окружением и может переноситься на другие компьютеры без потребности настраивать это самое окружение - оно уже на месте
Я очень не люблю настраивать окружение что под WP, что под любой другой стэк. Когда наступает момент переноса кода на новую машину это немного "больно". И хотя ос, php и mysql под WP не особо трудно настаивать этот процесс хочется автоматизировать
На старом месте работы обычно один проект затягивался на пару месяцев, что позволяло не страдать от нужной первичной настройки. На новом месте проектов больше меняются чаще, и хочется упростить жизнь себе и другим разработчикам
Пока я далеко от желаемого результата, могу работать с чужими готовыми сборками, но не со своими. Планирую за выходные это исправить, материалов в открытом доступе достаточно, а на складе валяется курс, который я рекомендовал больше года назад. Тогда докер я не осилил, но и не особо в нём нуждался
Одной из итоговых точек для себя отметил создание стартового шаблона под WP тему или плагин на основе докера. А дальше уже мне точно будет хватать знаний, чтобы использовать готовые решения, которые создавало больше чем один человек, например Visible Wordpress Starter (655 звёзд), плюс туда можно будет залить Sage и будет вообще красота
Первый купленный лицензионный софт:
Несмотря на четвертый год в разработке, я обходился бесплатным софтом всё это время - идеально для голодного школьника/студента. Но так как "голодать" я перестал, то можно начать вливать денюжку в повышение собственной эффективности через платный софт
GitKraken - стал моей первой покупкой, уж очень он мне понравился своим интерфейсом и возможностью объединить репозитории с кодом из разных мест. Да и по деньгам приемлемо - 60 вечнозеленых в год. Бесплатная версия есть и она включает в себя всю ту мощь, что есть и в платке, кроме возможности работать с приватными репозиториями, а это для меня критично
Это конечно не реклама, просто решил поделиться интересным моментом в прогерском пусти
P.S. Не реклама, но рекомендую
P.S. Осознал, что плохо знаком с гитом, еще один пункт в изучение WP, не изучая WP (об этом пути чуть позже)
Несмотря на четвертый год в разработке, я обходился бесплатным софтом всё это время - идеально для голодного школьника/студента. Но так как "голодать" я перестал, то можно начать вливать денюжку в повышение собственной эффективности через платный софт
GitKraken - стал моей первой покупкой, уж очень он мне понравился своим интерфейсом и возможностью объединить репозитории с кодом из разных мест. Да и по деньгам приемлемо - 60 вечнозеленых в год. Бесплатная версия есть и она включает в себя всю ту мощь, что есть и в платке, кроме возможности работать с приватными репозиториями, а это для меня критично
Это конечно не реклама, просто решил поделиться интересным моментом в прогерском пусти
P.S. Не реклама, но рекомендую
P.S. Осознал, что плохо знаком с гитом, еще один пункт в изучение WP, не изучая WP (об этом пути чуть позже)
Пора возрождать канал спустя год молчания. Вернулось время и желание писать, да и рассказать есть про что. Живые тут еще остались?
Да, жду контекта - 31
👍👍👍👍👍👍👍👍 79%
Я просто забыл отписаться - 3
👍👍 8%
Почему я подписан на этот канал? - 5
👍👍 13%
👥 39 человек уже проголосовало.
Да, жду контекта - 31
👍👍👍👍👍👍👍👍 79%
Я просто забыл отписаться - 3
👍👍 8%
Почему я подписан на этот канал? - 5
👍👍 13%
👥 39 человек уже проголосовало.
"Контекту" быть) Перечитал на днях devник и это уже 4 или 5 возвращение к каналу.
В моей прогерской жизни за прошедший год произошло мало существенных изменений.
Пошел второй год моей работы в onepix.net, продолжаю работать с WordPress, в основном на беке, иногда затрагивая интерфейсы на фронте. Темы, плагины, доработки-разработки, легаси и проекты с нуля - успел повидать много разных проектов.
Всё еще только планирую переход на PHP фреймворки, хотя успел изучить множество технологий, на которых они построены. ООП, MVC, routing, тесты. Напишу об этом подробнее позже
В универе уже на 4 курсе (канал был создан, когда я был в 11 классе), всё так же не вижу смысла в вышке для программиста, но надеюсь когда-нибудь узнать. С темой диплома определюсь за пару ночей до сдачи. Из полезных предметов на этом курсе есть "Функциональное программирование". Изучаем Haskell, я не знаю где применить этот язык, но для изучения "функциональщины" подходит идеально. Правда быстрее изучить его по книге, а не на парах. Об этом расскажу в следующем посте
В моей прогерской жизни за прошедший год произошло мало существенных изменений.
Пошел второй год моей работы в onepix.net, продолжаю работать с WordPress, в основном на беке, иногда затрагивая интерфейсы на фронте. Темы, плагины, доработки-разработки, легаси и проекты с нуля - успел повидать много разных проектов.
Всё еще только планирую переход на PHP фреймворки, хотя успел изучить множество технологий, на которых они построены. ООП, MVC, routing, тесты. Напишу об этом подробнее позже
В универе уже на 4 курсе (канал был создан, когда я был в 11 классе), всё так же не вижу смысла в вышке для программиста, но надеюсь когда-нибудь узнать. С темой диплома определюсь за пару ночей до сдачи. Из полезных предметов на этом курсе есть "Функциональное программирование". Изучаем Haskell, я не знаю где применить этот язык, но для изучения "функциональщины" подходит идеально. Правда быстрее изучить его по книге, а не на парах. Об этом расскажу в следующем посте
Пошел по классике программистской литературы. Возможно, у меня какая-то своя классика, но первой книгой в моем списке стоит "Паттерны проектирования" от Head First. В прошлом семестре именно по ней преподавались паттерны в вузе. Но если можно прочитать за неделю, зачем учиться семестр?
Книга рассказывает о всех основных паттернах в доступной форме: синглтон, фабрики, наблюдатель, декоратор и многие другие описаны в этой книге. Форма подачи материала стандартная для Head First. Простыми словами с кучей "смешнявок" и картинок можно узнать о важных вещях для современного ООП
Главное не перебарщивать с паттернами на проектах, всё таки они усложняют понимание кода, упрощая жизнь в будущем
Книга рассказывает о всех основных паттернах в доступной форме: синглтон, фабрики, наблюдатель, декоратор и многие другие описаны в этой книге. Форма подачи материала стандартная для Head First. Простыми словами с кучей "смешнявок" и картинок можно узнать о важных вещях для современного ООП
Главное не перебарщивать с паттернами на проектах, всё таки они усложняют понимание кода, упрощая жизнь в будущем
...166 дней спустя
Взялся за изучение Vue.js. Так совпало, что я захотел изучить что-нибудь новенькое для фронт-енд разработки, а vue понадобился для работы и учебы. В этот раз решил начал с чтения официальной документации. Она шикарна, содержит кучу информации и примеров (обычных и интерактивных).
Также взял из этой статьи план изучения vue. Он не очень подробный, но для начала сойдет. Такие есть по многим фреймворкам, когда-то использовал подобную для react.js и даже составлял свой план. Давние изучения реакта пригодилось, хотя я и плохо его уже помню, но знакомые концепции нахожу во вью
Попутно читаю пару книг по организации кода, но о них напишу позже, когда закончу
Взялся за изучение Vue.js. Так совпало, что я захотел изучить что-нибудь новенькое для фронт-енд разработки, а vue понадобился для работы и учебы. В этот раз решил начал с чтения официальной документации. Она шикарна, содержит кучу информации и примеров (обычных и интерактивных).
Также взял из этой статьи план изучения vue. Он не очень подробный, но для начала сойдет. Такие есть по многим фреймворкам, когда-то использовал подобную для react.js и даже составлял свой план. Давние изучения реакта пригодилось, хотя я и плохо его уже помню, но знакомые концепции нахожу во вью
Попутно читаю пару книг по организации кода, но о них напишу позже, когда закончу
Правильное форматирование кода не влияет на работоспособность программы, но вот на удобство разработки очень даже. Еще раздражает, когда работая на одном проекте с несколькими разработчиками, каждый пишет по своему. Для поддержания единообразия кода есть пара решений:
1) Настройка среды разработки и сохранение конфигурационного файла - это просто сделать и часто хорошо работает из коробки. Идеально подходит для одиночной разработки, когда не придется поддерживать единообразие кода между несколькими разработчиками
2) Использование линтеров - специальных программ для "причесывания" кода. Они автоматически приводят код в порядок и сообщают о тех местах где нужно поправить ручками. Конфиг лежит вместе с проектом, а скрипты линтера подтягиваются вместе с зависимостями. Удобно и автоматизированно.
К чему я это всё. Я уже давно знаком с линтерами для css и js, и только сейчас познакомился с линтером для php (phpcs) и в частности WordPress (wpcs). У WP есть официальный набор правил для кода и почти все из них мне нравятся, а те что не нравятся, я переопределил, но таких всего парочка. phpcs умеет самостоятельно править форматирование кода и указывать на проблемные места. В моем случае чаще всего это нехватка комментариев к методам и параметрам
Дефолтный скрипт phpcs требует много параметров для полного и красивого вывода, поэтому поверх дефолтного phpcs я написал bash скрипт на 20 строчек, который улучшает работу с линтером.
Пока обкатываю на паре проектов, после соберу пример, залью на гитхаб, а то там уже год только коммиты по работе
1) Настройка среды разработки и сохранение конфигурационного файла - это просто сделать и часто хорошо работает из коробки. Идеально подходит для одиночной разработки, когда не придется поддерживать единообразие кода между несколькими разработчиками
2) Использование линтеров - специальных программ для "причесывания" кода. Они автоматически приводят код в порядок и сообщают о тех местах где нужно поправить ручками. Конфиг лежит вместе с проектом, а скрипты линтера подтягиваются вместе с зависимостями. Удобно и автоматизированно.
К чему я это всё. Я уже давно знаком с линтерами для css и js, и только сейчас познакомился с линтером для php (phpcs) и в частности WordPress (wpcs). У WP есть официальный набор правил для кода и почти все из них мне нравятся, а те что не нравятся, я переопределил, но таких всего парочка. phpcs умеет самостоятельно править форматирование кода и указывать на проблемные места. В моем случае чаще всего это нехватка комментариев к методам и параметрам
Дефолтный скрипт phpcs требует много параметров для полного и красивого вывода, поэтому поверх дефолтного phpcs я написал bash скрипт на 20 строчек, который улучшает работу с линтером.
Пока обкатываю на паре проектов, после соберу пример, залью на гитхаб, а то там уже год только коммиты по работе
"Ретроспективное собрание" или просто "Ретро" - совещание, которое проводится в конце спринта для обсуждения решенных и не очень задач и постановки новых. Но это в идеальном мире
У меня на работе нет ретро по проектам, потому что проекты маленькие и часто команда состоит из двух человек, которым проще все обсудить в процессе. Зато есть ретро по отделам, где обсуждается общее видение развития направления (в моем случае backend направления) и оно должно проходить каждый месяц, но первое с начало года было несколько дней назад и так сложилось, что провел его я.
"Инициатива что-то делает с инициатором" - я очень хотел поучаствовать в ретро нашего отдела и несколько раз писал тимлиду "А когда?", на что в какой-то момент мне поступило предложение провести его самому, а я и не отказался.
Прошло всё отлично, собрал информацию с коллег об их настроении внутри компании еще до собрания: о плюсах, минусах и хотелках; убедился, что все знают кто есть кто, дал каждому высказаться на самом ретро (качаем софт скилы) и подвел итоги на основе всей информации.
Теперь самое интересное, надо же ставить задачи на ретро, и мы поставили, а я теперь слежу за их выполнением и часть выполняю сам. Если кратко, то бекенд отделу не хватает стандартов разработки, у нас каждый пишет так, как считает правильным, и это проблема, которую надо исправить. Подробнее расскажу, когда появятся результаты
У меня на работе нет ретро по проектам, потому что проекты маленькие и часто команда состоит из двух человек, которым проще все обсудить в процессе. Зато есть ретро по отделам, где обсуждается общее видение развития направления (в моем случае backend направления) и оно должно проходить каждый месяц, но первое с начало года было несколько дней назад и так сложилось, что провел его я.
"Инициатива что-то делает с инициатором" - я очень хотел поучаствовать в ретро нашего отдела и несколько раз писал тимлиду "А когда?", на что в какой-то момент мне поступило предложение провести его самому, а я и не отказался.
Прошло всё отлично, собрал информацию с коллег об их настроении внутри компании еще до собрания: о плюсах, минусах и хотелках; убедился, что все знают кто есть кто, дал каждому высказаться на самом ретро (качаем софт скилы) и подвел итоги на основе всей информации.
Теперь самое интересное, надо же ставить задачи на ретро, и мы поставили, а я теперь слежу за их выполнением и часть выполняю сам. Если кратко, то бекенд отделу не хватает стандартов разработки, у нас каждый пишет так, как считает правильным, и это проблема, которую надо исправить. Подробнее расскажу, когда появятся результаты
Github Actions - платформа на основе Github для автоматизации разработки. Позволяет автоматически запускать скрипты в проекте при наступлении определенных событий (например обновление кода в репозитории). Я давно поглядывал на эту технологию, теперь же она понадобилась на работе, и появилась возможность разобраться с ней получше
На рабочем проекте мне понадобилось автоматизировать три момента: проверку качества кода (wpcs рассказывал раньше), запуск тестов (phpunit расскажу позже) и сборку проекта.
Изначально скрипты для этих задач мог запустить каждый разработчик у себя на компьютере, но это было не обязательно, забывалось и качество кода не улучшалось. Теперь же перед выпуском каждого обновления обязательно запускаются проверки и не дают выпустить релиз, если код их проваливает. А после релиза код собирается в zip архив без лишних файлов (dev зависимости, тесты, конфиги на проде не нужны)
За время экспериментов с gh actions создал пару репозиториев у себя на гитхабе с запуском WordPress и с авторелизами. А все итоговые результаты в этом проекте Reepay - платежный шлюз для WooCommerce. Активно работаю над этим проектом, привожу его в порядок, пока не всё закончено
Последний аккорд с gh actions - это настройка кеширования. Сейчас проверки занимают несколько секунд, зато запуск окружения пару минут, а всё автоматическое должно запускаться быстро, чтобы было желание запускать. В actions есть возможность создавать кеш между запусками задач и это потенциально ускорит все проверки в десятки раз. Расскажу об этом в другой раз
На рабочем проекте мне понадобилось автоматизировать три момента: проверку качества кода (wpcs рассказывал раньше), запуск тестов (phpunit расскажу позже) и сборку проекта.
Изначально скрипты для этих задач мог запустить каждый разработчик у себя на компьютере, но это было не обязательно, забывалось и качество кода не улучшалось. Теперь же перед выпуском каждого обновления обязательно запускаются проверки и не дают выпустить релиз, если код их проваливает. А после релиза код собирается в zip архив без лишних файлов (dev зависимости, тесты, конфиги на проде не нужны)
За время экспериментов с gh actions создал пару репозиториев у себя на гитхабе с запуском WordPress и с авторелизами. А все итоговые результаты в этом проекте Reepay - платежный шлюз для WooCommerce. Активно работаю над этим проектом, привожу его в порядок, пока не всё закончено
Последний аккорд с gh actions - это настройка кеширования. Сейчас проверки занимают несколько секунд, зато запуск окружения пару минут, а всё автоматическое должно запускаться быстро, чтобы было желание запускать. В actions есть возможность создавать кеш между запусками задач и это потенциально ускорит все проверки в десятки раз. Расскажу об этом в другой раз
Сейчас в процессе изучения Unit тестирования. Его еще редко называют модульным или блочным. С его помощью можно проверить минимальные блоки кода. В идеале эти блоки кода должны представлять отдельные функции/методы
Самое трудное для меня сейчас - это покрыть unit тестами код, который вообще не предполагал тестирование. Тут и сильная связанность кода - невозможно запустить одну функцию без другой и огромные функции, тестирование которых превращается в интеграционное тестирование большОй части приложения, а не одного "юнита". Но я начал изучать тестирование ради этого проекта (всё тот же Reepay) и надо довести это дело до видимого результата.
Круто(а) помогла книжка "Принципы юнит-тестирования" от Владимира Хорикова. Правда я ее прочитал за два вечера, много чего не успел усвоить и теперь использую книгу как справочник. Еще рассчитывал покопаться в тестах ядра WP, их там дофига, но ничего для себя интересного не нашел. Скорее всего, как и с книгой, сделаю второй заход
Самое трудное для меня сейчас - это покрыть unit тестами код, который вообще не предполагал тестирование. Тут и сильная связанность кода - невозможно запустить одну функцию без другой и огромные функции, тестирование которых превращается в интеграционное тестирование большОй части приложения, а не одного "юнита". Но я начал изучать тестирование ради этого проекта (всё тот же Reepay) и надо довести это дело до видимого результата.
Круто(а) помогла книжка "Принципы юнит-тестирования" от Владимира Хорикова. Правда я ее прочитал за два вечера, много чего не успел усвоить и теперь использую книгу как справочник. Еще рассчитывал покопаться в тестах ядра WP, их там дофига, но ничего для себя интересного не нашел. Скорее всего, как и с книгой, сделаю второй заход
За последний месяц самым интересным в программировании для меня так и осталось юнит тестирование. На данный момент Reepay Checkout покрыт тестами на ~20%. С одной стороны медленно, с другой медленно не просто так:
Оказывается код надо готовить к тестированию и делать это лучше в процессе разработки. Но Reepay начал разрабатываться кучу лет назад и тогда о тестах точно никто не думал. Самое важное - это уменьшение связанности кода, и в этом помогло Внедрение Зависимостей (Dependency Injection) или просто DI
DI - это достаточно простой паттерн проектирования. Если один класс зависит от другого, не надо создавать экземпляр напрямую в классе, а стоит передать его через конструктор класса или сеттер.
Для чего это нужно в тестировании? Можно "внедрить" класс заглушку (Mock), который будет возвращать то что описано в тесте, и вместе с главным классом не будет тестироваться зависимость. А также убрать запросы к API и возвращать сразу то, что должно вернуться из запроса. Если есть запросы к API, то это уже не Юнит тесты, а интеграционные
И напоследок поделюсь великолепной статьей про создание DI контейнера на PHP с хабра - "Готовимся к собеседованию по PHP: Что такое «DI», «Container», «Auto-wiring» за семь простых шагов". Правда мне пришлось его доработать под свои нужны, выложу когда-нибудь отдельно на гитхаб
Оказывается код надо готовить к тестированию и делать это лучше в процессе разработки. Но 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
Для простого сайта это единая база данных, в которой находится вся информация для работы сайта. Если в БД понадобится использовать одну и туже информацию в нескольких местах, то ее надо сохранить в отдельную таблицу/ячейку и обращаться по ссылке (внешнему ключу)
В одном из проектов у меня было два "источника истины" - база данных сайта и API платежного сервиса. Работать с информацией можно было и на сайте и в кабинете платежной системы, после чего происходила синхронизация. Также клиент мог запустить глобальный импорт, если где-то не хватает большого количества данных (чаще всего на сайте при первом использовании API). Но это вызывало проблемы
Что если синхронизация не сработает? Или импортировать надо слишком много данных? Где-то появится устаревшая информация и для бизнеса это непозволительно. Поэтому было принято решения в локальную БД сохранять необходимый минимум для получения данных из API
Из минусов - выросла нагрузка на API, но клиента это никак не возмутило. Когда возмутит, можно будет настроить кеширование самых тяжелых запросов и дальше поддерживать концепцию SSOT
Сегодня снова провел ретроспективное собрание в бекенд отделе. В этот раз в более свободном формате, так как готовиться сильно заранее у коллег не было возможности из-за высокой занятости. Каждый рассказал о своих успехах за последний пару месяцев. Приятно видеть развитие в компании - почти каждый успел попробовать что-то новое из IT технологий.
Отдельно обсудили написание статей для блога компании. Привлечение клиентов через сгенерированные статьи провалилось, и мы переключились на авторский контент. Несколько человек, включая меня, вызвались перевести свой опыт в текстовый формат. Так что в течение лета здесь будут появляться ссылки на статьи от меня и моих коллег
Еще обсудили Github Copilot - инструмент с искусственным интеллектом для написания кода. Его использовало несколько человек в компании, и им понравилось. В итоге решили дать доступ к copilot всем желающим. Кому понравится, тому copilot будет оплачиваться. Я пока не попробовал, но надо добраться
Теперь осталось привести в порядок все комментарии от коллег, обсудить, запустить в работу... В общем есть чем заняться до следующего ретро
Отдельно обсудили написание статей для блога компании. Привлечение клиентов через сгенерированные статьи провалилось, и мы переключились на авторский контент. Несколько человек, включая меня, вызвались перевести свой опыт в текстовый формат. Так что в течение лета здесь будут появляться ссылки на статьи от меня и моих коллег
Еще обсудили Github Copilot - инструмент с искусственным интеллектом для написания кода. Его использовало несколько человек в компании, и им понравилось. В итоге решили дать доступ к copilot всем желающим. Кому понравится, тому copilot будет оплачиваться. Я пока не попробовал, но надо добраться
Теперь осталось привести в порядок все комментарии от коллег, обсудить, запустить в работу... В общем есть чем заняться до следующего ретро
Кэширование - временное сохранение какой-либо информации для быстрого повторного её получения. Используется во многих областях программирования для ускорения работы программ, включая разработку сайтов
Большинство сайтов генерируют контент динамически - происходит получение данных из базы данных, их передача в шаблоны и вывод посетителю. Можно ли здесь использовать кэширование? Да. Итоговый код перед выводом можно сохранить в простой .html файл и в следующий раз отдавать его вместо полноценной генерации. Но работает только если нужно отображать одинаковую страницу для всех посетителей.
Я же столкнулся с ситуацией, когда на сайте с уже давно и хорошо работающим с кэшированием, надо выводить каждом посетителю частично индивидуальный контент (индивидуальные скидки). В таком случае есть несколько решений
0) Отключить кэш вообще
1) Отключать кэш только для залогиненных пользователей, которым надо отображать скидки
2) Подгружать информацию о скидках асинхронно через AJAX
3) Разбить кэш на фрагменты и кэшировать только общие для всех элементы
Я выбрал первый способ - он не самый лучший, но простой в реализации, и не отпугнет новых пользователей, потому что для них страница все еще быстро будет грузиться из кэша. Подгрузка по AJAX - это очень хрупкое решение, при изменении шаблонов, придется и js менять, клиенты такое не любят. А про фрагментный кэш я вспомнил, когда всё уже было готово (и я не сталкивался с ним ни разу)
Теперь хочу попробовать фрагментное кеширование в WordPress. Есть уже готовые решения (к сожалению не подходящие к моему случаю), разберу пару из них, надеюсь, найдутся с не самым ужасным кодом
Большинство сайтов генерируют контент динамически - происходит получение данных из базы данных, их передача в шаблоны и вывод посетителю. Можно ли здесь использовать кэширование? Да. Итоговый код перед выводом можно сохранить в простой .html файл и в следующий раз отдавать его вместо полноценной генерации. Но работает только если нужно отображать одинаковую страницу для всех посетителей.
Я же столкнулся с ситуацией, когда на сайте с уже давно и хорошо работающим с кэшированием, надо выводить каждом посетителю частично индивидуальный контент (индивидуальные скидки). В таком случае есть несколько решений
0) Отключить кэш вообще
1) Отключать кэш только для залогиненных пользователей, которым надо отображать скидки
2) Подгружать информацию о скидках асинхронно через AJAX
3) Разбить кэш на фрагменты и кэшировать только общие для всех элементы
Я выбрал первый способ - он не самый лучший, но простой в реализации, и не отпугнет новых пользователей, потому что для них страница все еще быстро будет грузиться из кэша. Подгрузка по AJAX - это очень хрупкое решение, при изменении шаблонов, придется и js менять, клиенты такое не любят. А про фрагментный кэш я вспомнил, когда всё уже было готово (и я не сталкивался с ним ни разу)
Теперь хочу попробовать фрагментное кеширование в WordPress. Есть уже готовые решения (к сожалению не подходящие к моему случаю), разберу пару из них, надеюсь, найдутся с не самым ужасным кодом
Сегодня опубликовал первую статью от имени Onepix.
Разработка платежного шлюза для Magento 2. Правда она не моя, а моего коллеги Димы Сполохова, который и копался пару месяцев назад в Magento. Я же выступал в роли редактора и тестировщика, но тестировал не Magento, а редактор сайта onepix.ru
После публикации выяснили моменты, которые нужно доработать на сайте, чтобы он лучше подходил для публикации статей, в частности статей с кодом. Дорабатывать не мне, так что я просто составил тз для других разработчиков, через пару недель планируем ввести улучшения.
А моя статья выйдет уже через неделю. Расскажу про установку и запуск unit тестов в WordPress плагине. В разработке уже серия статей на тему unit тестирования в WP, по плану будет выходить по одной в две-три недели
Следить за выходом статей можно в новостном канале Onepix. В будущем там будут не только статьи
Разработка платежного шлюза для Magento 2. Правда она не моя, а моего коллеги Димы Сполохова, который и копался пару месяцев назад в Magento. Я же выступал в роли редактора и тестировщика, но тестировал не Magento, а редактор сайта onepix.ru
После публикации выяснили моменты, которые нужно доработать на сайте, чтобы он лучше подходил для публикации статей, в частности статей с кодом. Дорабатывать не мне, так что я просто составил тз для других разработчиков, через пару недель планируем ввести улучшения.
А моя статья выйдет уже через неделю. Расскажу про установку и запуск unit тестов в WordPress плагине. В разработке уже серия статей на тему unit тестирования в WP, по плану будет выходить по одной в две-три недели
Следить за выходом статей можно в новостном канале Onepix. В будущем там будут не только статьи
Похоже, я не умею вести собственный блог, но зато неплохо пишу в блог компании, поэтому просто оставлю ссылки на свои статьи здесь
PHPUnit для тестирования WordPress плагинов. Часть1: Установка
PHPUnit для тестирования WordPress плагинов. Часть 2: Как писать свои тесты
Публикация новой версии WordPress плагина с помощью Github Actions и SVN
PHPUnit для тестирования WordPress плагинов. Часть1: Установка
PHPUnit для тестирования WordPress плагинов. Часть 2: Как писать свои тесты
Публикация новой версии WordPress плагина с помощью Github Actions и SVN
OnePix RU
PHPUnit для тестирования в WordPress. Часть 1: Установка
PHPUnit в WordPress плагинах. PHPUnit — фреймворк для Unit тестирования приложений на PHP и его можно использовать с WordPress
Любопытно начал меняться вектор моей работы в компании. За две недели произошло много интересного:
1. Начал работать с новым стеком технологий.
Этот стек крутится вокруг PHP фреймворка Laravel и всего его окружения. У меня даже не было особо времени на изучение, поэтому изучаю сразу в бою. Да, код получился не самый лучший, но и проект на бекенде несложный — админка с созданием страниц, постов и получением информации из формы на сайте. Сейчас этот проект разворачиваю на сервере, так что еще понадобились знания nginx. И уже начался проект, где есть Docker. Пару лет назад я его даже изучал, о чем писал здесь, но тогда эти знания не пригодились
2. Теперь использую ChatGPT для помощи в написании кода.
Много раз слышал, что ChatGPT великолепен для разработчиков-джунов, и теперь я знаю об этом на практике. Так как на Laravel я джун, то мне иногда бывает трудно понять какую функциональность фреймворка где и как лучше применить. Но нейросетка даже по не самому точному и подробному описанию задачи выдаст рабочий код. К этому коду стоит относиться скептически, он часто не оптимальный, его можно улучшить, но жизнь все равно упрощает
3. Теперь я официально на должности Backend тимлид
Когда я начинал этот чат, даже подумать не мог, что меня кто-то будет называть тимлидом, и я смогу управлять проектами, но прошло 4.5 года и вот оно. Даже есть моя фоточка с должностью на сайте OnePix. При этом я остаюсь программистом и пишу код. Но я всё еще далек от своего идеала и программиста, и тимлида, еще многое предстоит изучить.
4. Провожу технические собеседования в компанию бекенд разрабов
Вообще случайно попал в эту часть жизни компании. Спасибо моему коллеге Владу, который взял меня с собой на проведение собеса, показал как оно должно быть. Теперь я провожу технические собеседования в соло. Сейчас мне доставляет удовольствие общаться с кандидатами, надеюсь, это не превратится в рутину
1. Начал работать с новым стеком технологий.
Этот стек крутится вокруг PHP фреймворка Laravel и всего его окружения. У меня даже не было особо времени на изучение, поэтому изучаю сразу в бою. Да, код получился не самый лучший, но и проект на бекенде несложный — админка с созданием страниц, постов и получением информации из формы на сайте. Сейчас этот проект разворачиваю на сервере, так что еще понадобились знания nginx. И уже начался проект, где есть Docker. Пару лет назад я его даже изучал, о чем писал здесь, но тогда эти знания не пригодились
2. Теперь использую ChatGPT для помощи в написании кода.
Много раз слышал, что ChatGPT великолепен для разработчиков-джунов, и теперь я знаю об этом на практике. Так как на Laravel я джун, то мне иногда бывает трудно понять какую функциональность фреймворка где и как лучше применить. Но нейросетка даже по не самому точному и подробному описанию задачи выдаст рабочий код. К этому коду стоит относиться скептически, он часто не оптимальный, его можно улучшить, но жизнь все равно упрощает
3. Теперь я официально на должности Backend тимлид
Когда я начинал этот чат, даже подумать не мог, что меня кто-то будет называть тимлидом, и я смогу управлять проектами, но прошло 4.5 года и вот оно. Даже есть моя фоточка с должностью на сайте OnePix. При этом я остаюсь программистом и пишу код. Но я всё еще далек от своего идеала и программиста, и тимлида, еще многое предстоит изучить.
4. Провожу технические собеседования в компанию бекенд разрабов
Вообще случайно попал в эту часть жизни компании. Спасибо моему коллеге Владу, который взял меня с собой на проведение собеса, показал как оно должно быть. Теперь я провожу технические собеседования в соло. Сейчас мне доставляет удовольствие общаться с кандидатами, надеюсь, это не превратится в рутину
👍5
В прошлом году мне нравилось писать статьи, выходило примерно по 1 статье в месяц и публиковались они на сайте onepix. Перед публикацией я несколько раз вычитывал статью, вносил кучу правок и в целом тратил на каждую много времени. Сейчас времени стало меньше и вместо статей я завел локальную базу знаний в obsidian
Obsidian — это блокнот на максималках. Каждая страница в нем представлена в markdown формате и очень удобна для редактирования и просмотра. Килерфичей в obsidian считается возможность ссылаться из одной записи на другую, получая в итоге собственную вики, которая хранится на локальном компьютере, а не где-то в интернете
Свою вики по проге я пишу уже пару месяцев по мере изучения нового и закрепления старого. И некоторые из заметок получаются достаточно качественными, чтобы ими можно было поделиться, только до звания статей они не дотягивают ни по объему, ни по формату. Поэтому я завел себе максимально простой блог, где вместо базы данных .md файлы из obsidian blog.ddaniel.ru, закинул туда пару заметок
Исходники блога и сами заметки опубликованы у меня на гитхабе, хоть немного подниму на нем активность. Сайт в целом еще сырой, собрал его за ночь и утром опубликовал, но изначальная идея реализована.
И реализована просто, на backend'е роутинг от
Obsidian — это блокнот на максималках. Каждая страница в нем представлена в markdown формате и очень удобна для редактирования и просмотра. Килерфичей в obsidian считается возможность ссылаться из одной записи на другую, получая в итоге собственную вики, которая хранится на локальном компьютере, а не где-то в интернете
Свою вики по проге я пишу уже пару месяцев по мере изучения нового и закрепления старого. И некоторые из заметок получаются достаточно качественными, чтобы ими можно было поделиться, только до звания статей они не дотягивают ни по объему, ни по формату. Поэтому я завел себе максимально простой блог, где вместо базы данных .md файлы из obsidian blog.ddaniel.ru, закинул туда пару заметок
Исходники блога и сами заметки опубликованы у меня на гитхабе, хоть немного подниму на нем активность. Сайт в целом еще сырой, собрал его за ночь и утром опубликовал, но изначальная идея реализована.
И реализована просто, на backend'е роутинг от
Symfony без всего лишнего, а на frontend'е bootstrap 5 для стилизации и markdown-it для рендера markdown в html. Расскажу о технологиях подробнее позже, когда доведу до ума их использование👍4
Сегодня засел рисовать логотип. Он для блога понадобился, и на канале захотелось обновиться. С графикой у меня плохо, и за всю жизнь рисовал только в paint, но меня выручила figma, в которой оказалось удобно работать с векторной графикой. Сначала вообще забыл про фигму и вспомнил только, когда поставил скачиваться adobe illustrator, с которым я бы просто разбирался пару дней
Логотип вдохновлен современными иконками нейросетей, на которых изображена рандомная фигура, например у chat gpt это цепь в форме шестиугольника. В моем случае это изначально был тупо "куб с окошками". Чтобы лого не устарело еще до своего появления добавил в него букву D. Вроде, Лебедев говорил, что лучшее имя бренда - это фамилия. В общем понабрал идей отовсюду и собрал что-то свое (в духе типичного программиста)
А главное в минималистичном логотипе - это возможность сохранить его в noscript и растягивать до любого размера. Хотя в тг этого и не увидеть, потому что здесь только png с jpeg можно поставить на фото канала.
Еще noscript анимировать можно. Но до этого доберусь через пару-тройку лет
Логотип вдохновлен современными иконками нейросетей, на которых изображена рандомная фигура, например у chat gpt это цепь в форме шестиугольника. В моем случае это изначально был тупо "куб с окошками". Чтобы лого не устарело еще до своего появления добавил в него букву D. Вроде, Лебедев говорил, что лучшее имя бренда - это фамилия. В общем понабрал идей отовсюду и собрал что-то свое (в духе типичного программиста)
А главное в минималистичном логотипе - это возможность сохранить его в noscript и растягивать до любого размера. Хотя в тг этого и не увидеть, потому что здесь только png с jpeg можно поставить на фото канала.
Еще noscript анимировать можно. Но до этого доберусь через пару-тройку лет
👍5
За несколько лет работы программистом, я не проходил курсы никакие it курсы, хотя манящей рекламы было и остается очень много. Тратил деньги только на доступы к закрытым статьям или тренажерам, но относительно стоимости тех же курсов потратил копейки
С понедельника это перестанет быть правдой. Я смог попасть на "Хардкорный курс PHP" от Валентина Удальцова, автора множества докладов и известного по каналам Пых и PHP Point. На курсе будет рассмотрена куча тем для middle PHP разработчиков, которые хотят стать senor'ами - мой случай
Круто что курс полностью построен вокруг фреймворка Symfony, но с которым я знаком очень поверхностно. Так что уже сейчас изучаю документацию и пробую практики Symfony в деле
С понедельника это перестанет быть правдой. Я смог попасть на "Хардкорный курс PHP" от Валентина Удальцова, автора множества докладов и известного по каналам Пых и PHP Point. На курсе будет рассмотрена куча тем для middle PHP разработчиков, которые хотят стать senor'ами - мой случай
Круто что курс полностью построен вокруг фреймворка Symfony, но с которым я знаком очень поверхностно. Так что уже сейчас изучаю документацию и пробую практики Symfony в деле
👍4
Идея блога на 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, поэтому знакомиться с ними я ними начал только сейчас. И пока писать блог, мне интереснее чем писать в него.
Новая версия блога еще в процессе, но я уже притащил в нее много новых для меня технологий:
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, поэтому знакомиться с ними я ними начал только сейчас. И пока писать блог, мне интереснее чем писать в него.
👍2