Несколько комментариев в защиту WordPress и его разработчиков
нам очень хотелось получить сайт в зеленой зоне PageSpeed Insights
Буквально каждый кандидат категорически настаивал на разработке кастомизированной темы "с нуля".
Проблема в том, что большинство современных качественных тем для ВП — это громадные швейцарские ножи, с 100+ вариантами отображения, встроенными визуальными конструкторами, десятком вариантов слайдеров и так далее. Их цель — охватить как можно большую аудиторию и максимизировать продажи.
Но в случаях, когда у вас есть дизайн и вы не предполагаете кардинально его изменять каждую неделю все эти навороты вам не нужны. И намного проще сверстать тему с нуля, со всеми требованиями по дизайну, по доступности, по поддержке именно вашего стека браузера, чем пытаться переделать и выбросить лишнее из чужой темы (ведь PageSpeed Insights это не только про скорость загрузки, это всё больше о том, как сайт работает на клиенте).
Про "оптимизацию WordPress" тут речь не идёт.
мы решили добавить фильтры по множеству тегов.
А вот стандартных плагинов для Wordpress с такой функциональностью — нет
У ВП есть встроенная возможность выводить посты по нескольким тегам или категориям. У него есть мощный api для фильтрации постов практически как угодно.
Забавно, но несколько месяцев назад я прошел через это.
Запускал один проект и долго не мог выбрать стиль организации файлов. Спрашивал совета по форумам/чатикам, но ответа не получил. В итоге я выбрал, как его назвал автор, "стековый" стиль, но уже через несколько месяцев всё переделал и перешел на "смысловой".
Причина проста: с "стековым" стилем банально сложнее работать. Реальность такова, что нам очень редко нужен только один файл. Чаще всего редактируется несколько файлов паралельно. И зачастую редактируемые файлы как-то логически связаны, связаны по смыслу. Скажем, вы меняете одну страницу сайта, скорее всего вы правите html, css, js возможно поправляете какие-то тесты для этой страницы и так далее. И намного удобнее, когда в редакторе кода, всё что относится к этой странице находится под рукой. Иначе приходится постоянно скролить список файлов вверх и вниз.
Самый распространённый в моей практике случай: загрузка каких-либо данных (например постов блога) частями. Это СУПЕР удобно.
Пишешь асинхронный генератор, который хранит в себе данные для пагинации и загружает посты.
А дальше используешь
Руководство, хотело выпустить хит, который будет держать компанию на плаву ближайшие несколько лет не меньше. Отсюда и большое количество "хотелок" которые были показаны, которые хотели реализовать но отказались или отложили.
Разработка игры очень дорогостоящая. А кошелек компании, не резиновый. Очевидно что компания не могла позволить себе откладывать игру сколько угодно. И старались выпустить как можно раньше, чтобы пополнить денежный запас и продолжить разработку.
Предполагаю, что в какой-то момент стоял выбор: перенести игру и понести убытки или выпустить в сыром состоянии и понести убытки. Выбирали меньшую из зол.
Но вот что отличает CDPR, так это то, что их игры имеют статус LTS :) Я уверен в том, что близшайшие года игра будет развиваться и улучшаться.
Представим, я пишу какой-то инструмент. Утилитку для себя, но и выложил её бесплатно в публичный доступ и набрал небольшую аудиторию, скажем в 1000 пользователей.
В случае критической проблемы при очередном обновлении, я не потеряю ничего. Да, будут недовольные пользователи, но не больше. Никаких убытков. А вот затраты на написание и поддержку тестов есть, хоть и не материальные.
При таком сценарии наличие тестов — полезно, но не главное, на чем стоит сосредотачиваться.
Забавный случай: как-то в моём приложении был большущий баг — огромная неработающая кнопка. И он был актуальным долгое время, потому, что ни один пользователь его не заметил и не отправил репорт.
Всегда думайте своей головой. Не делайте чего-либо по инерции, просто потому, что все говорят так делать.
Это я написал скорее для случайного читателя :) Уверен любой опытный разработчик прекрасно разбирается в теме и умеет расставлять приоритеты в каждом отдельно взятом проекте.
Справедливости ради, добавлю, что я вот почти никогда не пишу тесты. А если и пишу, то это минимальное покрытие критичных частей приложения.
Всё дело в том, что я чаще всего работаю над каким-то проектом в одиночку. Писать тесты, поддерживать тесты, писать документацию, поддерживать её в актуальном состоянии — это очень большой кусок работы. Не всегда один человек может тянуть весь комплекс. И в этом можно увязнуть, когда 80% всего времени ты тратишь на изменение тестов, документации, и прочего, вслед за небольшой правкой фичи.
Тестирование — это полезно, но далеко не всегда оправданно. Всегда думайте своей головой. Не делайте чего-либо по инерции, просто потому, что все говорят так делать.
А ещё есть такие люди, которые просто не могут работать с кем либо удалённо. Вы все знаете такой тип людей: это те, которые записывают голосовое сообщение на 5 минут со всеми этими "еее", "еммм", "бэээ", "ну, в общем", "щас, дай подумаю", "как это сказать?", вместо того, чтобы потратить 2 минуты своего времени, сформулировать вопрос и отправить тебе текстовое сообщение. Как по вашему такие вот индивиды могут работать с кем либо удалённо? А если такой человек занимает должность менеджера? Он же будет первым, кто встанет перед руководством и будер расказывать, что его отдел не может работать удалённо. Что никакой слаженности. Что все задачи обсуждаются не голосом, а где-то там, в каких-то чатах, тасктерекерах и вообще, ему нужно смотреть человеку в глаза…
Добавлю сверху:
Да, бывают компании, которые пытаются сделать пребывания в офисе комфортным. Но что делать если у двух сотрудников разные понятия про комфорт? А в таких случаях, отдаётся предпочтение тому специалисту/отделу, который более важен для компании.
Вот нравится местному сеньёру температура +5°С и гробовая тишина и всё. Он — лучший специалист компании, а ты на его фоне никто. И в случае конфликта руководство будет на его стороне.
Резервные дизель-генераторы обеспечат питание ЧАЭС и его объектов в течение всего лишь 48 часов.
https://twitter.com/DmytroKuleba/status/1501531899914825731
Жду статью про infer
Несколько комментариев в защиту WordPress и его разработчиков
Проблема в том, что большинство современных качественных тем для ВП — это громадные швейцарские ножи, с 100+ вариантами отображения, встроенными визуальными конструкторами, десятком вариантов слайдеров и так далее. Их цель — охватить как можно большую аудиторию и максимизировать продажи.
Но в случаях, когда у вас есть дизайн и вы не предполагаете кардинально его изменять каждую неделю все эти навороты вам не нужны. И намного проще сверстать тему с нуля, со всеми требованиями по дизайну, по доступности, по поддержке именно вашего стека браузера, чем пытаться переделать и выбросить лишнее из чужой темы (ведь PageSpeed Insights это не только про скорость загрузки, это всё больше о том, как сайт работает на клиенте).
Про "оптимизацию WordPress" тут речь не идёт.
У ВП есть встроенная возможность выводить посты по нескольким тегам или категориям. У него есть мощный api для фильтрации постов практически как угодно.
Есть и плагины. Скажем Jetpack Search.
Так что решения есть. Другое дело, что они могут по подходить вам по каким-либо критериям. Тогда только самописный вариант с учетом всех требований.
Забавно, но несколько месяцев назад я прошел через это.
Запускал один проект и долго не мог выбрать стиль организации файлов. Спрашивал совета по форумам/чатикам, но ответа не получил. В итоге я выбрал, как его назвал автор, "стековый" стиль, но уже через несколько месяцев всё переделал и перешел на "смысловой".
Причина проста: с "стековым" стилем банально сложнее работать. Реальность такова, что нам очень редко нужен только один файл. Чаще всего редактируется несколько файлов паралельно. И зачастую редактируемые файлы как-то логически связаны, связаны по смыслу. Скажем, вы меняете одну страницу сайта, скорее всего вы правите html, css, js возможно поправляете какие-то тесты для этой страницы и так далее. И намного удобнее, когда в редакторе кода, всё что относится к этой странице находится под рукой. Иначе приходится постоянно скролить список файлов вверх и вниз.
Ну, такие себе "фундаментальные технологии". Больше похоже на "что сможем портируем, остальное выбросим".
Оно так и делается
https://github.com/cawa-93/anime-library/blob/11774e997be0f93b894f5c176f289931bdd23f98/packages/renderer/src/utils/videoProvider/providers/anime365-interfaces.ts#L1-L12
Ну, по идее же, точно так же можно изменить и
Map.prototypeТак то да, но вся суть же ж была именно в том, чтобы запустить проект с ES модулями как основными. А для этого type: "module" и нужен.
Вы не можете использовать в одном файле две системы модулей.
https://web.archive.org/web/20210225120529/https://nkrzi.gov.ua/index.php?r=site%2Findex&pg=99&id=2053
https://web.archive.org/web/20210225120529/https://nkrzi.gov.ua/index.php?r=site%2Findex&pg=99&id=2053
Может быть полезным
https://github.com/znck/vue-developer-experience/tree/main/packages%2Ftypecheck
Самый распространённый в моей практике случай: загрузка каких-либо данных (например постов блога) частями. Это СУПЕР удобно.
Пишешь асинхронный генератор, который хранит в себе данные для пагинации и загружает посты.
А дальше используешь
чтобы загрузить новую партию постов.
Как по мне то, тут всё логично и понятно:
Руководство, хотело выпустить хит, который будет держать компанию на плаву ближайшие несколько лет не меньше. Отсюда и большое количество "хотелок" которые были показаны, которые хотели реализовать но отказались или отложили.
Разработка игры очень дорогостоящая. А кошелек компании, не резиновый. Очевидно что компания не могла позволить себе откладывать игру сколько угодно. И старались выпустить как можно раньше, чтобы пополнить денежный запас и продолжить разработку.
Предполагаю, что в какой-то момент стоял выбор: перенести игру и понести убытки или выпустить в сыром состоянии и понести убытки. Выбирали меньшую из зол.
Но вот что отличает CDPR, так это то, что их игры имеют статус LTS :) Я уверен в том, что близшайшие года игра будет развиваться и улучшаться.
Новогоднее оливье подвезли
Представим, я пишу какой-то инструмент. Утилитку для себя, но и выложил её бесплатно в публичный доступ и набрал небольшую аудиторию, скажем в 1000 пользователей.
В случае критической проблемы при очередном обновлении, я не потеряю ничего. Да, будут недовольные пользователи, но не больше. Никаких убытков. А вот затраты на написание и поддержку тестов есть, хоть и не материальные.
При таком сценарии наличие тестов — полезно, но не главное, на чем стоит сосредотачиваться.
Забавный случай: как-то в моём приложении был большущий баг — огромная неработающая кнопка. И он был актуальным долгое время, потому, что ни один пользователь его не заметил и не отправил репорт.
Это я написал скорее для случайного читателя :) Уверен любой опытный разработчик прекрасно разбирается в теме и умеет расставлять приоритеты в каждом отдельно взятом проекте.
Справедливости ради, добавлю, что я вот почти никогда не пишу тесты. А если и пишу, то это минимальное покрытие критичных частей приложения.
Всё дело в том, что я чаще всего работаю над каким-то проектом в одиночку. Писать тесты, поддерживать тесты, писать документацию, поддерживать её в актуальном состоянии — это очень большой кусок работы. Не всегда один человек может тянуть весь комплекс. И в этом можно увязнуть, когда 80% всего времени ты тратишь на изменение тестов, документации, и прочего, вслед за небольшой правкой фичи.
Тестирование — это полезно, но далеко не всегда оправданно. Всегда думайте своей головой. Не делайте чего-либо по инерции, просто потому, что все говорят так делать.
А ещё есть такие люди, которые просто не могут работать с кем либо удалённо. Вы все знаете такой тип людей: это те, которые записывают голосовое сообщение на 5 минут со всеми этими "еее", "еммм", "бэээ", "ну, в общем", "щас, дай подумаю", "как это сказать?", вместо того, чтобы потратить 2 минуты своего времени, сформулировать вопрос и отправить тебе текстовое сообщение. Как по вашему такие вот индивиды могут работать с кем либо удалённо? А если такой человек занимает должность менеджера? Он же будет первым, кто встанет перед руководством и будер расказывать, что его отдел не может работать удалённо. Что никакой слаженности. Что все задачи обсуждаются не голосом, а где-то там, в каких-то чатах, тасктерекерах и вообще, ему нужно смотреть человеку в глаза…
Добавлю сверху:
Да, бывают компании, которые пытаются сделать пребывания в офисе комфортным. Но что делать если у двух сотрудников разные понятия про комфорт? А в таких случаях, отдаётся предпочтение тому специалисту/отделу, который более важен для компании.
Вот нравится местному сеньёру температура +5°С и гробовая тишина и всё. Он — лучший специалист компании, а ты на его фоне никто. И в случае конфликта руководство будет на его стороне.