docs/ru/extra/hrs.md
# Рекрутерам
Февраль 2019-го года. Тебе 27 лет, самое время выбирать, чем ты будешь заниматься по жизни. Твоя хорошая знакомая Виктория (имя изменено, или нет, возможно, я настолько ленив, что даже не сменил ее имя) предлагает тебе пойти в веб-дизайн, потому что "Ты хорошо умеешь в фотошоп". Насколько здесь выстроена логическая цепь - не мне судить (плохо), но именно с этой фразы и начинается моя карьера в вебе
## Начало пути
Добрый день, меня зовут Игорь Алексеенко, и я не алкоголик
В феврале 2019-го посеянное Викторией зерно прорастает в нечто большее и я начинаю интересоваться структурой сайтов, пока только с точки зрения веб-дизайна - сетка, типографика, теория цвета, колонки. Создаются первые макеты, получаю первые отклики от своих знакомых по поводу работ, и наступает момент, когда я не понимаю, как это работает. Как именно я должен понять, что верстальщик **сможет** сделать то, что я нарисовал? Или же мы с ним вечно будем в контрах? Прежде чем осуждать верстальщика, я решил походить в его обуви - надел и не снял, так и хожу до сих пор
В марте, после месячной головокружительной карьеры веб-дизайнером я начал верстать
### HTML и CSS
Знать все на свете нереально, но я, мечту свою лелея, решил проблему гениально, я смотрю индусов на YouTube, эти ребята все знают и бесплатно. Часовой ролик об основах HTML меня не впечатлил, конечно, скучные див-чики, скучные таблицы, скучные ссылки, скучное абсолютно все, но все при этом такое необходимое... И все разом преобразилось благодаря часовому (конечно же) ролику об основах CSS. Вот где краски заиграли, и вот где меня понесло. Собственно говоря, это был период, когда я придумывал знакомым сайты, рисовал, верстал их и получал от них положительную оценку. Так я понял, что у меня слишком много льстецов в друзьях - ведь сайты были даже не адаптивны - но я был не против. Это был следующий урок, который мне только предстояло усвоить. Продолжая рыться в просторах YouTube, я наткнулся на Bootstrap и только тогда понял смысл 12-колоночной сетки в дизайне. Поначалу Bootstrap воспринимался, как то, что я **обязан** использовать, и довольно долгое время я его использовал как must-have. Что значит, что этот сайт не использует Bootstrap? Он не адаптивен? А нет, погодите-ка... И здесь начинается отказ от сетки бутстрап - зачем ее вообще использовать, если она больше мешает? Что тебе не позволяет написать свою сетку, свои дефолтные стили и переносить их из проекта в проект? Ничего? Так переноси. Жаль, конечно, что CSS нельзя разбить на маленькие подключаемые модули. Хотя, ПОГОДИТЕ-КА!
### CSS-препроцессоры и Gulp
> Можно
Так я узнаю про CSS-препроцессоры. На тот момент меня более всего привлек tab-индентный синтаксис SASS - долой скобки и лишние знаки препинания, да здравствует Tab!
> Со временем я отказался от tab-индентного синтаксиса, так как обычный CSS было намного проще интегрировать в `.scss` (Ctrl+C, Ctrl+V), в то время как с `.sass` пришлось бы проводить чистку или пользоваться онлайн-конвертерами. Такая задача требовала гораздо меньшего времени, а с переходом на TailwindCSS преимщества SASS и вовсе рассеялись.
SASS было очень просто изучать, и хотя я долгое время совершенно не понимал и не использовал его фишки (миксины, циклы, переменные), писать на нем было комфортнее. Собранный из крупиц в просторах интернета `gulpfile.js` помогал успешной сборке проекта, но теперь я хочу больше! Я хочу знать, как этот Gulp устроен, что такое таски и что такое вотчинг. Я начал его изучать подробнее, добился каких-то успехов, но главным тормозящим моментом было то, что это файл Javascript, а Javascript я тогда не знал. Потому gulp хоть и работал, но ощущения были не те. Долго так продолжаться не могло, на дворе май, а значит, самое время изучать Javascript
### Javascript и jQuery
Шучу, jQuery. До ванильного Javascript я по сути тогда так и не дошел. Достаточно было сравнить две записи
```js
// Vanilla JS
const btns = document.querySelectorAll('.btn');
btns?.forEach( btn => {
btn.addEventListener('click', e => {
// magic
});
});
// jQuery
$('.btn').click(e => {
// magic
});
```
чтобы определить своего фаворита, ведь так?
!> Спойлер - не так
Тогда выбор пал на jQuery. Именно из-за своей простоты, внутренней нативной понятности. Это дало мне ноль очков к изучению Javascript, но теперь можно было смело брать сайты с модалками, галереями и слайдерами, в общем, со всеми прелестями верстальщицкой жизни, выполнять какие-то простейшие задачи по скриптам, открыть, закрыть, вскрыть. Заказы росли, верстка поставлена на конвейер, я на пике кривой [Даннинга-Крюгера](https://ru.wikipedia.org/wiki/%D0%AD%D1%84%D1%84%D0%B5%D0%BA%D1%82_%D0%94%D0%B0%D0%BD%D0%BD%D0%B8%D0%BD%D0%B3%D0%B0_%E2%80%94_%D0%9A%D1%80%D1%8E%D0%B3%D0%B5%D1%80%D0%B0), но долго статичная жизнь продолжаться не могла
### WordPress
"Игорь, скажите, пожалуйста, я же смогу потом поменять текст?" - спросила меня клиентка добрым августовским утром 2019-го года. "Конечно" - ответил я ей, хотя без понятия, сможет ли она. Нужно было быстро найти какое-то решение и выбор пал на WordPress, благо ранее про него немного рассказывали мне. Не сказать, что я тогда все понял, как оно работает, но сложить 2 и 2 я смог. Но что это был за сайт! Ооооо! Да, она могла действительно менять текст, но как это было написано в коде... Мне до сих пор стыдно за его реализацию, хочется броситься к ее ногам, просить прощения, но я мужик, я не могу так поступить, с Вас 9 тысяч российских рублей, спасибо, обращайтесь еще
> Она, кстати, потом обратилась вновь. На этот раз сайт уже был произведен по канонам, без криворукостей и костылей, с кастомайзером. С Вас уже 15 тысяч, кстати. Да растем. Спасибо, обращайтесь еще
Но эта постыдная пощечина стала залогом того, что в августе-сентябре я довольно плотно засел за изучение WordPress. Основы его были поняты мной быстро, хотя хуки, как явление, долгое время оставались тайной за семью печатями. По сути, не приходило понимание, как с ними работать, но Stackoverflow спасал, копипаст выручал, сайт работал. Учение, зубрение, работа, и к концу сентября я уже вполне свободно владею WordPress, понимаю иерархию шаблонов, `WP_Query` и запросов в целом, работа с `$wpdb` и те же хуки дались. Вернее, как дались. Это же очень просто! Здесь все очень просто! В октябре начинается уже новая продуктивная работа, с качественно новыми знаниями ядра
До 2020-го года мне удалось еще сделать несколько сайтов, по 2-3 за месяц, как клиент ляжет, знания росли, крепли, и я начал задумываться, как интегрировать все вместе. Видите ли, обычный рабочий пайплайн тогда проходил так
1. Ты верстаешь сайт на Gulp, собираешь его
2. Переносишь верстку в WordPress, подключаешь стили и скрипты
3. Переписываешь верстку, стили и скрипты. Камон, ребята, ~Козловский~ WordPress
Я захотел избавиться от нудного второго пункта. Что, если сразу верстать в WordPress, прям в PHP-шных файлах, а сборщик выносил готовые стили и скрипты в отдельную папку, откуда бы они уже подключались? Разве так не было бы проще?
И так действительно было проще. Пару дней усердной работы, и вот я подключил Gulp к WordPress - включая HMR и Browsersync. Не сказать, что это прям победа, миллионы разработчиков делали это и до меня, но среди знакомых, кажется, я первый пришел к такому
Теперь обычный режим работы был таков:
1. Ты верстаешь сайт на Gulp, собираешь его
2. Ты красавчик
3. Ничего не переписываешь, потому что пункт 2
До марта 2020-го этот шаблон проектировки оставался основным. Почему оставался? Я его заменил. Нет, он работал исправно, более чем, но со временем хотелось чего-то большего, чего-то нового. Как насчет...
### Javascript. Опять
Оптимизации? Да, сжать скрипты и стили. Готово. Зачем такую картинку пихаешь в такое маленькое пространство? Обрезать, сжать, конвертировать. Это что, jQuery? Нет, серьезно, Игорь, ты подключаешь здоровенную библиотеку ради того, чтобы открывалось меню? Знаешь, как это делается на родном Javascript? Очень легко, оказывается. Оптимизация веб-сайтов заставила меня пересмотреть свои взгляды на jQuery
Действительно, тянуть тяжелую библиотеку извне, заставлять сайт ждать, пока она прогрузиться и все это еще **ДО** того, как этим могли воспользоваться пользователи? Представьте себе, что Вы заказываете такси и видите, что оно задерживается потому, что в машину ставят магнитолу. Представили? Так это только малая часть с jQuery, так как он Вам бы установил пять колонок по краям, да так, что X-Zibit (или как его?) бы закрыл "Тачку на прокачку" еще в далеком и лохматом году. Потому я снова перехожу на изучение JS, но на этот раз без всяких альтернатив - голая ванила, тащите мне сайт пентагона, буду взламывать! И вот уже сейчас изучение Javascript приносит свои плоды, приходит понимание, базовые вещи, фетч-запросы и промисы, даже немного ООП остается в голове, но есть одна большая проблема - кроссбраузерность. Тестовый Hello World отлично работает в Firefox, но в IE он попросту зависает. Ранее я привык, что не все браузеры поддерживают стили одинаково, хорошо, но то, что точно такая же история есть с ES6, повергло меня в шок. Что же делать? Снимать т, нет, рано еще, подключаем Babel. А как компилировать?
При помощи webpack. И babel туда же. И да, мы открываем новую качественную главу в разработке
### Webpack
Поначалу мне webpack жутко не понравился, но стоило лишь немного привыкнуть к его синтаксису, немного наловчиться, научиться отделять зерна от плевел и все, это твой друг, это твой **лучший** друг, прости, Виктория. Webpack может все. Если webpack что-то не может, то это не webpack что-то не может, это **ТЫ** его не можешь настроить. Наверное, если бы я еще порылся в документации webpack, я бы где-то и нашел плагин, который бы делал по утрам чашечку кофе, но я не искал. Потому основной поток моих поисковых запросов был направлен именно на это - КАК, а не ЧТО. На тот момент я писал все скрипты в одном месте и по итогу мой конфигурационный файл разросся до недопустимых размеров, 600+ строк кода, но по функциональности своей он был незаменим, как мне казалось.
> В дальнейшем я развил конфиг в двух направлениях - для голого HTML (или Pug), и для своего шаблона. Схожие моменты у обоих были, но, к сожалению, второй никак не хотел работать c dev-server и HMR - а вот первый пожалуйста. Первый гораздо кастомизируемее, а второму это было ни к чему. К тому же, оба эти конфига были разбиты на файлы по типу рабочего окружения и могли выполнять разные команды в зависимости от них - именно так я и оптимизировал свой "мега-файл"
Теперь же, после полноценной настройки, можно было полноценно разделять на части не только SASS-файлы, но и JS. Import, export, красота. Шаблон был успешно переписан под вебпаковские новые реалии. Что дальше?
### ООП
Как насчет того, чтобы полностью изменить подход к написанию кода? Давайте перейдем с процедурного на объектно-ориентированное программирование, классы, трейты, интерфейсы. Давайте подключим к проекту Composer и перепишем все-все-все. То есть, Игорь, у тебя есть шаблон, который исправно работает год, все минимально необходимое в нем есть, и ты хочешь его переписать полностью с нуля? ДА!
!> Таких радикальных ребилдов суммарно будет шесть. ШЕСТЬ, Карл!
И хотя первые шаблоны с применением ООП были кривоваты и вовсе не использовали Composer, они опять же работали. Во всяком случае, первый сайт, написанный на нем, отработал замечательно, если бы меня тогда не кинули с оплатой, то было бы вообще прям конфетка, но шаблон свое дело сделал, очередной сайт на WordPress готов. Дальнейшее изучение паттернов, рефакторинга, основ ООП и большее понимание его приведут к новым радикальным ребилдам (особенно после Dependency Injection Container), однако сейчас я подумываю о написании второго шаблона. А значит, август 2020-го, что это у нас такое впереди? It's Laravel time!
### Laravel и VueJS
Началось все с безобидного видео на YouTube, на этот раз не индуса, а канадца итальянского происхождения, которое я даже не смотрел, но его название меня очень привлекло. Laravel. Очень красивое название, и только из-за названия (я серьезно) я и решил изучать этот фреймворк. Структура папок после WordPress, конечно, была столь непривычна, но лишь со временем я понял, насколько она хороша. Ларавел же, как фреймворк, очаровал меня сразу. Это было самое большое потрясение из мира разработки за все время (и до сих пор остается), самый элегантный и простой синтаксис, как все красиво, какой у него ООП, мммм, да не увидит РосКомНадзор никакой пропаганды в этой фразе.
Параллельно с этим поднимается вопрос изучения какого-либо фронтенд-фреймворка, потому что "потому что" и выбор пал на VueJS - из-за низкого порога входа и как раз из-за того, что Ларавел неплохо работает с Vue.
С августа по октябрь полностью проходит в изучении обоих этих фреймворков, как повязанных. VueJS удивляет своей простотой и новым мышлением - после него стало гораздо проще понимать Javascript (а не наоборот, как должно было быть). Бэкенд Laravel полностью меняет мое представление о WordPress - из "Вполне хорош, мне очень нравится" он становится "Безобразной штукой без единого стиля, кодовинегрет, фу таким быть". Фронт Laravel также восхищает - какой элегантный blade, include, extend вместо обычного представления включения частей в шаблон, тут даже свой встроенный сборщик laravel-mix (пусть и на основе webpack, но у него свой конфиг) и он красивый, хм, приоритеты смещаются.
> В дальнейшем blade немного померк, хотя Laravel постоянно усовершенствует фронт, но я предпочитаю twig - гораздо удобнее и "безопаснее", как по мне
Однако реальность полна разочарований. Хотя мое стремление делать что-либо на Laravel/Vue была максимальной, спрос не совпадал с предложением и приходилось по-прежнему делать на WordPress, уже не любимом. Это породило желание переписать ядро WordPress под красоту Laravel, в частности, реализовать QueryBuilder, фасады, реорганизовать структуру под MVC и ввести консольные команды. Это была задача на будущее, а пока мой взгляд привлекла совершенно иная вещь из совершенно иной степи
### TailwindCSS
И это было второй раз, когда мне взорвало мозг. Не так, как с Ларавел, конечно, но довольно близко - Тейлвинд мог все!
> На самом деле, конечно, не все - даже сейчас Tailwind не может все, но благодаря системе конфигов и особенно JIT-mode он очень близок к этому. Если чего-то и не хватало, то это можно было вполне внести в конфиг самому, написать плагин, компонент - и теперь всего хватало
Забудьте прежний подход к CSS, да вообще забудьте, что такое CSS - Вам это больше не нужно.
Tailwind - это ЕДИНСТВЕННЫЙ CSS-фреймворк, с которым мне комфортно работать, и с которым я НЕ собираюсь расставаться.
По стилистике, конечно, приходилось выбирать, как лучше, БЭМ-овское написано, или utilities-first, оставлять ли мне `flex justify-center items-center` или выносить все в SASS в какой-то общий класс или что. Со временем второй подход победил именно из-за соображений оптимизации - лучше тянуть нужные стили к нудным страницам, чем общие стили всем. Выигрыш миллисекундный, но подход правильный, наверное.
Итак, с фронтом полностью определились (в будущем будет только изменение стака на фронте), что насчет бэка?
### Timber
Более подробное изучение ООП, опыт и теплые воспоминания о Laravel и поиск альтернативных решений по Github и иным сайтам привели к тому, что я нашел Timber - на тот момент плагин для WordPress, который отпочковался в самостоятельный фреймворк с элегантным twig-шаблонизатором и вполне удобными Query-запросами. Сверху этого я нашел структуру Bedrock для сайтов WordPress и даже Sage, которая использовала blade-шаблонизатор в темах WordPress. Однако пластмассовый мир победил и twig оказался сильней, а потому я остановился на Timber. Вместе со структурой Bedrock. Это подтолкнуло к написанию первого фреймворка на основе этих двух гигантов мысли, который трижды переписывался и все больше и больше становился похожим на Laravel. Успешно интегрировав Kirki Framework для создания опций сайта и Carbon Fields для метабоксов, я начал искать пути элегантизации шаблона и начал рыться в исходном коде Sage, Lumberjack и Laravel. И все это меня привело к одному выводу - мне нужен свой контейнер зависимостей
Ну как, свой, есть же готовая библиотечка PHP DI 6, тебе она по нраву? О, да! И шаблон заиграл новыми красками.
### Brocooly
Так и появился на свет Brocooly Framework, мой маленький фреймворчонок со своими методами маршрутизации, фасадами, удобным и отларавелленым по полной WP_Query, структурой MVC и сборщиком стилей. Все в одном, даже консольные команды были реализованы. Со временем я разделил тему и само ядро в отдельные репозитории, но это больше для пафоса. Шаблон разрастался новыми и новыми фишками, синтаксис становился все более и более элегантным, покрывалось все больше и больше фич WordPress.
У шаблона есть проблема с интеграцией с некоторыми плагинами из-за Bedrock-структуры, но он в первую очередь разрабатывался именно с учетом отхода от плагинов, только `must-use` или же необходимые технические плагины, по типу Yoast SEO или плагинов безопасности
### AlpineJS
Последним во фронт вмешался AlpineJS от создателей TailwindCSS. Умные ребята не стали все смешивать в одно, как все остальные (UIKit, Bootstrap, Materialize, Vuetify), а предоставили отдельно JS-фреймворк и CSS. Легкий и понятный синтаксис, ориентированный на VueJS, помог в его быстром изучении и интеграции с действующим шаблоном. Конечно, не все на нем можно сделать, нередко он миксуется с ванилой, однако он значительно ускоряет процесс разработки "банальных" вещей. А потому на данный момент Alpine вне конкуренции - легкий, простой, легко подключается, в отличие от VueJS. К тому же, Vue - слишком тяжеловесное решение для таких задач, как и jQuery.
### Верстка писем и MJML
Самым последним в моей истории (декабрь 2021) стала верстка писем. Я знал, какой это ужас, видел сверстанные шаблоны, какие-то простые вещи верстал и до этого, однако все меркло по сравнению с новой задачей - сверстать новогоднее письмо. Задача была простой, но у одной женщины, да хранят ее боги, письмо выглядело... Жутковато. Это не было неожиданностью, но нужно было решить, как же сверстать максимально корректно. И поиск решения привел меня к MJML - простому решению для верстки писем. Сверстанный шаблон корректно отразился у всех, задача решена успешно, еще одна галочка в моем багаже и новые перспективы по верстке писем. Что, письмо? Дайте десять
### Прочее, всякое, и (не)нужное
Помимо вебовского основного пути было всякого много, что в той или иной степени не являлось важным, вторичным, третичным и даже пятым в очереди задач верстальщика. Однако тем не менее, на некоторые задачи действительно приходилось тратить много времени и не сказать о них, как мне кажется, будет преступлением
Еще в январе 2020 я заинтересовался задачей деплоя проекта, безболезненного его переноса из локальной среды разработки непосредственно на хостинг/сервер. И я не имею ввиду перенос файлов вручную через FileZilla или WinSCP, а полноценный пайплайн с интеграцией с Github и/или Bitbucket. Опять же поиски, поиски, поиски, проба решения, и в конечном итоге я остановился на Buddy Apps и их `buddy.yml`, который на бесплатном тарифе позволял делать гораздо больше, нежели многие на платном. Осталось открытой только проблема деплоя баз данных - их приходится хранить в репозитории, и пусть он приватный, но это хранение базы в репозитории. Есть некоторые решения для миграции баз, но приходилось совершать две операции, в то время как с Buddy все подвешивалось на `git push` - пушишь файлы в репозиторий и он запускает пайплайн.
Также занялся линтингом - CSS, JS файлов, PHP, HTML с точки зрения WCGA и ARIA-атрибутов, подвесил к шаблону конфигурации со своими правилами. В целом, бесполезное занятие, но тренирует, вырабатывает привычки написания кода, дисциплинирует и раздражает, конечно. Че ты подчеркиваешь красным? Задолбал
> И еще много-много-много мелочей. Например, я выучил HTML-препроцессор Pug, но им практически никогда не пользуюсь. Я использую WP Cli, но так ли это важно? Если уйти в мелочи, эту секцию можно расширить раза в 4, а если еще упомянуть сторонние приложения, с которыми в той или иной степени использую и взаимодействовал (например, Mailhog, Insomnia, DBeaver), то и во все 6 раз.
Наверное, важно будет упомянуть, что осенью прошлого года перешел на Linux, где полностью приходилось поднимать локальный сервер, опробовал как голый Apache, так и Nginx, а в конце концов перешел на Valet. Удивительно, но эти знания пригодились, и приходилось поднимать сервера у клиентов и/или править их. Там же я впервые ознакомился с YandexCloud и поднял сервер на нем. Так что опыт, пусть и малый, есть. Хотя все равно, много пятен остается по работе с YandexCloud, были бы деньги, вопросов было бы меньше, но меня жаба душит. Где-то в сентябре поднял сайт на WordPress на Docker, были размышления по поводу его плюшек, но так как работал один и по большей степени с монолитами, то надобности в нем я не увидел. Потому знания о нем поверхностные и запылившиеся, вновь надо искать документацию, чтобы вспомнить, как поднять docker-compose.
### Подводя итоги
Подводя итоги, хотелось бы сказать, что я очень хорошо понимаю себя молодого, на заре, тогда еще дизайнера. Да, я действительно всегда буду конфликтовать с дизайнерами, потому что эти мудаки не могут даже понять, что так/сяк нельзя дешево будет реализовать, что как меня задолбали Ваши списки, переходящие в слайдеры на мобильном и что Ваша эта бесконечная линия или кружок между секциями по всему макету та еще боль с точки зрения оптимизации сайта. Все реализуемо, вопрос лишь в "правильности" реализации и ее цене
## Навыки
Здесь более сухо я подведу свои навыки, я не буду давать оценку, но оставлю комментарий к каждой категории, чтобы примерно понимать уровень
| Что | Как |
| ------ | ------ |
| HTML | Вообще глупо писать, что ты знаешь HTML. Достаточно часа, чтобы ты его знал. Другое дело, конечно, тонкости HTML, семантика и корректное использование атрибутов, особенно с точки зрения a11y (хотя серьезно, кому на просторах СНГ сдалась a11y? Это немного даже печально как-то. Даже у Вас на сайте нет поддержки, так что вопрос о ее реализации даже не первой очереди). И в конце, HTML можно разделить по уровню знаний, но по большей части это не нужно. Это больше для SEO, когда использовать `article`, а когда `div` |
| Pug | HTML-препроцессор, который я нашел во время заказа на просто верстку. Вернее, после него. Смысл был в том, что я устал верстать на HMTL, отсутствие циклов убивало, а копипаста карточек вводила в уныние. Здесь на помощь и пришел Pug. Использовав его в проектах ровно 0 раз, я положил его на полочку, однако это не значит, что он плох - просто я редко верстаю "вчистую" |
| MJML, Верстка писем | Несмотря на юный статус, MJML довольно прост - не надо быть гением, чтобы мгновенно понять 90% его документации, сверстать письмо и получить на выходе HTML, который согласно анализу Mailtrap поддерживается 88% процентами современных агентов. При практически нулевых затратах на верстку это невероятный КПД, и потому MJML я не собираюсь запускать и буду развивать навыки его. Конечно, при наличии необходимости в верстке писем |
| SASS, TailwindCSS | Я даже не буду писать CSS, так как давно не использую чистые CSS файлы, все идет либо через PostCSS, либо же SASS-препроцессор. Я не гений CSS, конечно, но всегда можно додуматься, как можно сделать ту или иную анимацию. Проблема лишь в том, что на подавляющем большинстве сайтов Вам не нужна анимация. Ну не нужна крутая анимация на сайте завода Пермских лакокрасок - так, только приятное глазу появление карточек с товаром, какой-то нерезкое переключение меню, ховеры, и все. В большинстве ситуаций знание продвинутой анимации GSAP/Three.js попросту излишне. Что касается Tailwind, то, наверное, я могу смело сказать, что разбираюсь в подавляющем большинстве его фишек, а с выходом третьей версии и обновлении документации под JIT-mode даже динамические плагины не должны стать проблемой |
| ES6, AlpineJS | Не знаю, насколько сильные, но знания Javascript есть, стараюсь использовать по максимум Alpine |
| VueJS, Nuxt | Есть базовые знания, однако практического использования (помимо чисто своих приложений) нет. Впрочем, если не идти вглубь, то использовать смело могу |
| ООП, PHP8.0, Composer | Есть довольно неплохие знания основ PHP (связанное с сайтами, но вот голый-голый PHP, конечно, нет, полностью я не знаю. Но гугл знает). Есть понимание ООП и его нюансов, активно использую во всех последних проектах. Из фишек PHP8.1 знаю только Enum, но я не смотрел их релизы, в общем, пусть он выйдет, освоится в окружающей среде, тогда и будем смотреть. Пока же я свыкаюсь с фишками 7.4/8.0, и в целом, именно на 8.0 и стараюсь писать. Это минимальные требование к клиентскому окружению - хостинг, сервер, контейнер - что угодно. И в целом - плотное сотрудничество с composer, что в WordPress, что в Laravel, и даже если приходится вдруг писать что-то извне - это всегда работа через Composer |
| WordPress, Timber | Я не люблю желать правки, так как я не ожидаю, что другие разработчики будут использовать тот же стиль написания, что и я, а пока у них разберешься, как это сделано, пройдет куча времени. Особенно в WordPress, где он позволяет столько вольностей в написании чего-угодно. Что касаемо создания новых сайтов, то это обязательно с использованием Timber и Bedrock. Да, наверное, можно не использовать мой шаблон, но вот без Timber уже будет сложно. Вместе с этим обязательно идут Kirki Framework для написания опций сайта и Carbon Fields для метабоксов, виджетов и блоков Gutenberg. Оба этих пакета подключаются через Composer и также идут, как must-have. Не хотелось бы работать с чем-то иным. Из минусов - я работал с WooCommerce, однако проектов на Timber нет. То есть, нет практики совмещения этих двух гигантов. Я в целом не люблю WooCommerce, он очень грузный, но то, что он построен на хуках, делает его проще в изучении. И я совершенно не работаю (и не желаю) работать с пейдж-билдерами - в топку ваши элементоры, пекарни и прочие элементы юзерабилити |
| Laravel | Laravel я не знаю на должном уровне, но безумно хотел бы знать, это именно та степь, в которую мне хотелось бы погрузиться и чем хотелось бы заниматься в приоритете |
| MySQL | Слабое звено. Понять синтаксис, конечно, могу, но написать самому надо будет изучать. В базах работаю через DBeaver, дампы делаю через wp-cli, да и в целом управление базой можно организовать через этот инструмент. Создать табличку можно, но на практике не сталкивался с такой необходимостью. Это больше для плагинов, конечно, а с ними проблема продумать то, что нужно |
| Линтинг и оптимизация | Знаю много по большей части ненужных линтеров, Eslint, Stylelint, Commitlint, Markdownlint, Prettier, PHPCS (WPCS), но практическую пользу из них несут только Eslint. Удобно использовать editorconfig в работе. К сожалению, я привык к tab-написанию в 4 пробела, что идет вразрез практически со всеми. Спасибо VSCode, что пытается сгладить углы, но какой-то процент работы я трачу просто на то, чтобы расставить табы, убрать пробелы, перенести на новую строку. И я помешан на оптимизации, кроссбраузерности решений, бэкапов. Помешан - громкое слово, но я изучал Modernizr не просто так. Знаю про сервисы CanIUseIt, Browserstack, Mobile Friendly, про генерацию спрайтмапов и иконочного шрифта вместо подгрузки целых библиотек, сжатие картинок, конвертацию в Webp, сервисы по типу TinyPNG - все это постарался вынести в webpack |
| Деплой, работа с сервером | Для деплой использую бесплатный аккаунт Buddy и очень доволен им, вряд ли я буду менять его. Что касается работы с сервером, то хоть и малый, но опыт работы с ним есть. Я не сис-админ, но подключиться по SSH и установить PHP-модуль смогу |