Русский
Русский
English
Статистика
Реклама

Модули

CS Cart или через терни к черной дыре костылей и оптимизаций

22.05.2021 18:12:52 | Автор: admin

Совсем недавно, я стал разработчиком модулей для CS Cart. Случилось это по воле случая: меня взяли на работу в Петербургскую сеть интернет магазинов, торгующих вейпами и всякими интересными штуками для удовлетворения потребностей физического характера страждущих пар и одиночек (кто не понял - еще не дорос ). Оба интернет магазина развернуты на двух витринах с разными доменами, но одной админкой и общей базой данных. Что же с ней не так? Думаю о CMS написано много, но я добавлю свою ложку дегтя в бочку с дегтем .

Путешествие в модуль через лес директорий

В процессе разработки первого модуля для этой платформы, я столкнулся со множеством проблем, которых, как я полагал, имея опыт работы с ООП, а также с CMS MODX Revo, быть не должно. Первое, что бросилось в глаза - это очень сложная и запутанная структура модуля:

root/ app/   addons/                                     <- Модули и расширения     [id_модуля]/                              <- Папка модуля        controllers/                          <- Расширение контроллеров          backend/                           <- Панель администратора            [ваш_контроллер].php            <- Новый контроллер            [контроллер].pre.php            <- Расширение перед контроллером            [контроллер].post.php           <- Расширение после контроллером          common/                            <- Общие контроллеры            [ваш_контроллер].php            [контроллер].pre.php            [контроллер].post.php          frontend/                          <- Контроллеры витрины             [ваш_контроллер].php             [контроллер].pre.php             [контроллер].post.php        database/                             <- MySQL файлы        schemas/                              <- Расширение PHP схем          [папка_схем]/                      <- Папка схемы (тип схемы)             [название_схемы].post.php       <- Расширение после схемы        Tygh/                                 <- Классы          Shippings/                         <- Доставки            Services/                       <- Службы доставки               [СлужбаДоставки].php         <- Ваша служба доставки          [ВашКласс].php                     <- Любой новый класс        addon.xml                             <- Главный файл модуля        config.php                            <- Константы        func.php                              <- Функции и расширения хуков        init.php                              <- Подключение хуков design/   backend/                                    <- Шаблоны панели администратора    css/                                      <- Стили панели администратора     addons/       [id_модуля]/                          <- Ваш модуль         styles.css                          <- Ваши стили         styles.less    mail/                                     <- Email и шаблоны счетов     templates/       addons/                               <- Модули и аддоны         [id_модуля]/                        <- Папка модуля           hooks/                            <- Подключение к хукам            [тип_хука]/                     <- Папка хука              [название_хука].pre.tpl       <- Код перед хуком              [название_хука].post.tpl      <- Код после хука              [название_хука].override.tpl  <- Переписать хук           [шаблон_письма]_subj.tpl/           [шаблон_письма].tpl/    media/                                    <- Статические данные     images/       addons/         [id_модуля]/                        <- Изображения вашего модуля           изображение_1.jpg/           изображение_2.png/    templates/                                <- Шаблоны      addons/        [id_модуля]/          hooks/                              <- Подключение к хукам           index/                            <- Папка хука            scripts.post.tpl                <- Хук подключения вашего скрипта            styles.post.tpl                 <- Хук подключения вашего стиля           [тип_хука]/             [название_хука].pre.tpl         <- Ваш код перед хуком             [название_хука].post.tpl        <- Ваш код после хука             [название_хука].override.tpl    <- Ваш код перепишет хук          views/                              <- Собственная страница           [ваш_контроллер]/                 <- Контроллер             [режим_контроллера].tpl         <- Режим (mode) контроллера          overrides/                          <- Переписать любой шаблон            ...                               <- Создайте нужную структуру     themes/                                     <- Дизайн витрины  темы     [название_темы]/                          <- Название темы       css/                                    <- Стили        addons/          [id_модуля]/            styles.css                        <- Ваш стиль CSS            styles.less                       <- Ваш стиль LESS       mail/                                   <- Шаблоны писем и счетов        templates/          addons/            [id_модуля]/              hooks/                          <- Раширение через хуки               [тип_хука]/                 [название_хука].pre.tpl                 [название_хука].post.tpl                 [название_хука].override.tpl              [шаблон_письма]_subj.tpl/       <- Шаблон темы письма              [шаблон_письма].tpl/            <- Шаблон письма       media/                                  <- Статические данные        images/          addons/                             <- Изображения модуля            [id_модуля]/              изображение_1.jpg/              изображение_2.png/       templates/                              <- Шаблоны         addons/           [id_модуля]/                        <- Ваш модуль             hooks/                            <- Расширение хуков              index/                          <- Папка хука               scripts.post.tpl              <- Хук подключения вашего скрипта               styles.post.tpl               <- Хук подключения вашего стиля              [тип_хука]/                     <- Папка хука                [название_хука].pre.tpl       <- Ваш код перед хуком                [название_хука].post.tpl      <- Ваш код после хука                [название_хука].override.tpl  <- Перезаписать хук целиком             views/                            <- Новая страница              [ваш_контроллер]/               <- Папка вашего контроллера                [режим_контроллера].tpl       <- Шаблон для режима контроллера             overrides/                        <- Переписать любой шаблон темы               ...                             <- Файл который нужно переписать js/                                            <- Скрипты модуля  addons/    [id_модуля]/      func.js/ var/                                           <- Хранилище шаблонов модуля   themes_repository/                           <- Используется при установке     [название_темы]/       ...

Может показаться, что модуль имеет логичную иерархию внутри своей структуры, но, иногда, следуя по документации, случаются баги, которые не должны были появиться. Например: был у меня кейс, когда обращаясь к контроллеру через AJAX функцию, встроенную в класс CMS JS упорно не хотела работать с моим контроллером, хотя сделано всё было четко по документации. Поискав информацию и обратившись к комьюнити, состоящем, в основном из 3-4 активных завсегдатаев-разработчиков, я понял, что даже сами разработчики этой платформы не могут ответить на вопрос о том, почему их функция ведет себя некорректно.

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

То что мертво - труп, но потыкать палкой нужно

Второй задачей, которую поставило руководство, являлась оптимизация сайтов этого магазина. Я взялся за нее без энтузиазма, понимая, что это мертворожденное существо, и мы с коллегой путем мучений и отключения всего того зоопарка модулей, что были установлены до моего появления со словами: "А че бы нет?!" - добились улучшенных показателей Google и в LightHouse, но прироста, в 20 единиц на одном сайте и 10 на другом, было не достаточно. Тогда я полез смотреть БД более детально. Поняв, что БД у данной CMS - набор несвязанных друг с другом таблиц, я понял, что все взаимодействия с базой и связки данных проходят через PHP, что, как я считаю, неправильно. Почему сделано именно так? - всё просто: CMS создавалась в 2003-2004 годах, и в качестве движка для СУБД использовался MyISAM.

MyISAM - сам по себе, довольно медленный движок и он не рассчитан на 50 000 (!) товаров (о количестве поговорим позже). Более того связывание таблиц этом движке реализовано не так хорошо как, скажем, в том же InnoDB. Из-за этого сервер начинает очень страдать при одновременном обращении 500 - 1000 пользователей.

Теперь поговорим о количестве товаров. Откуда 50 000 спросите вы? "Потому что" - отвечу я. Дело в том, что одну из витрин отдали на SEO какому то подозрительному фрилансеру из Беларуси. Странность его суждений заключается в разнообразных уловках и ухищрениях. Например: для улучшения видимости сайта он просил коллегу создать несуществующую номенклатуру и каждый день подгружать несуществующий товар. Аргументировал он это тем, что пользователи будут искать товары из этого несуществующего списка и попадать к нам на сайт, на этот товар. Понятно, что пользователь уйдет сразу же после этого, так как товара в наличии нет и никогда не было и не будет. Сайт ни капельки не продвигается, а руководство с упорством продолжает считать мнение данного "спеца" авторитетней мнения штатного программиста и контент-менеджера.

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

Нужна скрепка? Плати 100 баксов

Последняя проблема, которую я освещу в данной статье - это плата за любое мелкое допиливание этого "зомби". Хочешь стандартный функционал cron в панеле админа - плати. Подключить метрику не через утиную гуску, а так, чтобы она не нагружала клиент - плати. И другие малозначимые, но иногда важные изменения - стоят денег. Ценник, как правило, начинается от 100$ за модуль. Да, разработчикам, как и мне, хочется кушац, но у меня сложилось впечатление, что CMS и её стандартные модули специально не доведены до нормального состояния. А так как структуру всех классов и методов знают только создатели данной CMS, то они и являются, по сути, монополистами на рынке, так как любой фрилансер или штатный проггер, не сможет нормально сделать модуль с первого раза, используя недописанную и костыльную документацию, что предлагается на данный момент.

Заключение

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

Надеюсь, статья Вам была интересна. Я буду писать еще о своих изысканиях в этой CMS или о разработке модулей для неё.

Подробнее..
Категории: Javascript , Php , Cms , Магазин , Mysql , Модули , Cscart

Перевод Интригующие возможности С 20 для разработчиков встраиваемых систем

07.01.2021 08:23:49 | Автор: admin

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

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

С++20 это седьмая итерация С++, которой предшествовали, например, С++17, С++14 и С++11. Каждая итерация добавляла новые функциональные возможности и при этом влияла на пару функций, добавленных ранее. Например, ключевое слово auto С++14.

Прим. перев.:

В С++14 были введены новые правила для ключевого слова auto. Ранее выражения auto a{1, 2, 3}, b{1};были разрешены и обе переменные имели тип initializer_list<int>. В С++14 auto a{1, 2, 3}; приводит к ошибке компиляции, а auto b{1};успешно компилируется, но тип переменной будет int а не initializer_list<int>. Эти правила не распространяются на выражения auto a = {1, 2, 3}, b = {1};, в которых переменные по-прежнему имеют тип initializer_list<int>.

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

Так уж получилось, что в С++20 было добавлено довольно много новых функциональных возможностей. Новые итераторы и поддержка форматирования строк будут полезны с новой библиотекой синхронизации. У всех на слуху оператор трехстороннего сравнения, он же оператор космический корабль. Как и большинство функциональных возможностей, описание этого оператора выходит за рамки данной статьи, но если кратко, то сравнение типа x < 20, сначала будет преобразовано в x.operator<=>(20) < 0. Таким образом, поддержка сравнения, для обработки операторов типа <, <=, >= и >, может быть реализована с помощью одной или двух операторных функций, а не дюжины. Выражение типа x == yпреобразуется в operator<=>(x, y) == 0.

Прим. перев.:

Более подробную информацию об операторе космический корабль смотрите в статье @Viistomin Новый оператор spaceship (космический корабль) в C++20

Но прейдём к более интересным вещам и рассмотрим функциональные возможности С++20 которые будут интересны разработчикам встраиваемых систем, а именно:

Константы этапа компиляции

Разработчикам встраиваемых систем нравится возможность делать что-то на этапе компиляции программы, а не на этапе её выполнения. С++11 добавил ключевое слово constexpr позволяющее определять функции, которые вычисляются на этапе компиляции. С++20 расширил эту функциональность, теперь она распространяется и на виртуальные функции. Более того, её можно применять с конструкциями try/catch. Конечно есть ряд исключений.

Новое ключевое слово consteval тесно связано с constexpr что, по сути, делает его альтернативой макросам, которые наряду с константами, определенными через директиву #define, являются проклятием Си и С++.

Сопрограммы

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

Прим. перев.:

Более подробную информацию о сопрограммах и о том для чего они нужны, смотрите в статье @PkXwmpgN C++20. Coroutines и в ответе на вопрос, заданный на stackoverflow.

С++20 поддерживает функционал сопрограмм с помощью coroutine_traits и coroutine_handle. Сопрограммы являются стеконезависимыми и сохраняют свое состояние в куче. Могут передавать управление и при необходимости предоставлять результат своей работы себе же, когда выполнение сопрограммы возобновляется.

Концепты и ограничения

Концепты и ограничения были экспериментальной функциональной возможностью С++17, а теперь являются стандартной. Поэтому можно предположить, что эксперимент прошел успешно. Если вы надеялись на контракты Ada и SPARK, то это не тот случай, но концепты и ограничения C++20 являются ценными дополнениями.

Плюсом ограничений является то, что они позволяют обнаруживать ошибки на этапе компиляции программы. Ограничения могут накладываться на шаблоны классов, шаблоны функций и обычные функции. Ограничение это предикат (прим. перев.: утверждение), который проверяется на этапе компиляции программы. Именованный набор таких определений называется концептом. Пример кода, взятый с cppreference.com, показывает синтаксис и семантику этой функциональной возможности:

#include <string>#include <cstddef>#include <concepts>using namespace std::literals; // Объявляем концепт "Hashable", которому удовлетворяет// любой тип 'T' такой, что для значения 'a' типа 'T',// компилируется выражение std::hash{}(a) и его результат преобразуется в std::size_ttemplate <typename T>concept Hashable = requires(T a) {    { std::hash{}(a) } -> std::convertible_to<std::size_t>;}; struct meow {}; template <Hashable T>void f(T); // Ограниченный шаблон функции С++20 // Другие способы применения того же самого ограничение:// template<typename T>//    requires Hashable<T>// void f(T); // // template <typename T>// void f(T) requires Hashable<T>;  int main() {  f("abc"s); // OK, std::string удовлетворяет Hashable  f(meow{}); // Ошибка: meow не удовлетворяет Hashable}

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

Модули

Повсеместный #include заменяется модулями. Ключевые слова import и export находятся там, где когда-то находился #include.

Директива #include упростила написание компиляторов. Когда компилятор её встречает он просто выполняет чтение файла, указанного в ней. По сути получается, что включаемый файл как бы является частью оригинального файла. Такой подход зависит от порядка, в котором объединяются файлы. В целом это работает, однако такое решение плохо масштабируется при работе с большими и сложными системами, особенно с учетом всех взаимосвязей, которые могут принести шаблоны и классы С++.

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

Существующие стандартные библиотеки теперь будут поддерживать включение в виде модулей, но для обеспечения обратной совместимости поддержка директивы #include остается. Модули хорошо работают с существующей поддержкой пространства имен.

Я по-прежнему склонен программировать на Ada и SPARK, но новые изменения в C++20 делают его лучшей платформой C++ для разработки безопасного и надежного программного обеспечения. На самом деле мне нужно поработать с новыми функциями C++20, чтобы увидеть, как они влияют на мой стиль программирования. Я старался избегать сопрограмм, поскольку они были нестандартными. Хотя концепты и ограничения будут немного сложнее, они будут более полезны в долгосрочной перспективе.

Положительным моментом является то, что компиляторы с открытым исходным кодом поддерживают C++20, а также то, что в сети интернет появляется всё больше коммерческих версий компиляторов, поддерживающих С++20.

Подробнее..

Псс, парень, не хочешь сделать модуль для Flipper Zero?

19.10.2020 16:12:07 | Автор: admin


У Flipper Zero на боку есть отверстия GPIO под стандартную гребенку 2.54 мм, к которым выведены ноги микроконтроллера. Там есть аппаратный SPI, I2C, UART и много другой периферии, доступной в нашем чипе STM32. Эти контакты можно использовать для подключения к сторонним устройствам по промышленным протоколам. На GPIO выведено питание 3.3V и 5V, чтобы можно было питать подключенное устройство сразу от Флиппера.

Подобно Arduino, для Флиппера можно изготовить железные модули расширения с разными интересными функциями. Но в отличие от Arduino, где модули (шилды) это просто голые платы, модули для Флиппера можно сразу сделать продолжением корпуса.

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


Схема распиновки GPIO



Сейчас, пока Флиппер активно разрабатывается, распиновка гребенки GPIO может незначительно меняться. На момент написания статьи она выглядит так:


Кликабельно

Цифровые пины имеют логические уровни 3.3V, но толерантны к входящему сигналу 5V, поэтому можно использовать уже существующие модули от других платформ, например Arduino.

Пока схема устроена достаточно просто, все пины подключены через токоограничивающий резистор 51 Ом. Позже будет добавлена ESD защита.


Кликабельно





3D-модели


Чтобы разработчики могли сделать правильный корпус для своего модуля, мы публикуем 3D-модели внешних поверхностей Флиппера. Эти модели постоянно изменяются, но мы можем гарантировать, что разработчики будут получать актуальные версии моделей и точно будут знать финальный вариант задолго до массового производства. Актуальные модели находятся в репозитории github.com/Flipper-Zero/flipperzero-3d-models



Важно помнить, что 3D-модели будут меняться и нельзя опираться на эти модели как на финальные. В момент, когда модели будут финализированы, мы объявим об этом отдельно в рассылке.

Как начать разработку модуля





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

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

1. Обсудите с аудиторией


Сперва нужно проверить интерес пользователей. Для этого у нас есть отдельный раздел на форуме и специальный канал в Discord hw-3rd-party. Почитайте чужие идеи для вдохновения и предложите свою. В ноябре мы опубликуем самые интересные идеи и предложим пользователям проголосовать за них.

2. Посчитайте стоимость и оцените свои силы


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

3. Согласуйте с нами


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

4. Приступайте к разработке


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

Где деньги?


image
Запуск производства крупной партии электронных устройств требует ощутимых вложений. Мы готовы проконсультировать вас и помочь с построением производственной цепочки. Мы прямо не заявляем, что будем инвестировать в ваш продукт, но, если он ОЧЕНЬ хороший и вы нас убедите, такой вариант не исключается.



Следите за процессом разработки и новостями о Flipper Zero в:
Instagram
Facebook
Англоязычном блоге

Все характеристики Flipper Zero на официальном сайте.
Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru