Pull to refresh
1
0
Send message
Подскажите, а какие промышленные изделия, выпускаемые большим тиражом, есть на ESP32? Видел только Sonoff и промышленный контроллер NORVII, что, по сути, тоже игрушки для самоделкиных.
Я только начинаю интересоваться этой темой и ищу расширяемые и программируемые датчики и реле для умного дома на открытых компонентах.
Всё, что находил, либо закрытое и малофункциональное, либо многофункциональное, но стоит, как крыло от самолёта.
94% (с частичной реализацией) — это в мире, а в России — всего 84,5%. Так что для большинства — это на будущее.
А зачем вы парсите магазины, которые сами размещают свои прайс-листы в CPA-сетях? Им ведь есть смысл отдавать только правильные и полные прайсы. А парсить xml-выгрузку можно хоть каждый час.
А можно ли выводить под заголовком список хабов или 2-3 строчки текста?
Я просматриваю все потоки, иногда можно найти интересную информацию по смежным областям. Но очень часто у статей «маркетинговый» заголовок, под которым может скрываться что угодно по любой тематике. И без захода на страницу не понять, о чём она, стоит ли читать её, либо это направление мне неинтересно. А интернет не всегда стабильный.
Поэтому я с телефона читаю только полную версию, где, позумив, можно быстро проглядеть весь список статей с превью текста.
Под «глобальным» я имею только их выполнение, а не способ подключения.
JSON — та же библиотека, только «вшитая» в ядро. Я не про неё конкретно. Есть достаточно много таких «вшитых» библиотек, некоторые из которых можно отключить при компиляции.
Так что в глобальном плане они не отличаются от сторонних. Только образование наименований функций отличается. И это порой создаёт путаницу.
Понимаю, что это из-за наследия формирования PHP, и что это не изменить. Но такая разнородность «не красит» язык.
Всё написанное прошу считать моими «мысли вслух». Это просто тезисы моего ЯП, который я создаю на основе PHP, существующий только в моей голове.
1. Нет, загрузка расширения (и его классов) идёт всего 1 раз во время поднятия PHP (или инстансов php-fpm), а не на каждый запрос.
2. На мой взгляд, код \JSON::encode выглядит гораздо гармоничней, чем \json_encode. Но это чисто моё мнение.

Плюс, как я думаю, поиск в локальных/глобальных классах будет будет идти быстрее, чем в функциях, т.к. их намного меньше. Но точно этого не знаю, т.к. надо измерять.
А чем в глобальном плане различаются «встроенные возможности» от сторонних библиотек? В самих встроенных библиотеках вообще можно найти разброд и ахтунг.
Например, встроенное расширение intl. Если зайти на страницу документации php.net/manual/ru/book.intl.php и почитать названия методов, то волосы встают дыбом — смесь CamelCase, слитное написание наименований без заглавных букв, «стандартное» наименование функций прописными буквами, разделённые нижним подчёркиванием. Плюс дублирование многих функций в процедурном стиле (функции вызываются из загруженного глобального пространства) и ООП.
В то время, как сторонние библиотеки (далеко не все, конечно) стараются держаться ООП либо вызова статических методов.
Т.к. это расширение, данный объект создаётся 1 раз при запуске php. Расходы на хранение не такие уж и большие.
Если сравнивать варианты выполнения функции:
1. json_encode: найти в локальном пространстве функцию json_encode, если в нём не найдём (что скорее всего и будет), ищем её в глобальном пространстве.
2. JSON::encode: найти класс JSON, затем в нём найти статический метод encode.

Мне кажется, что 2-ой способ будет выполняться быстрее. Могу ошибаться, не знаток внутренностей PHP.
На мой взгляд, json_encode -> Json::encode — очень хорошая замена, т.к. в стандартных библиотеках, коей является библиотека json, все функции, свойства константы идут с префиксом от наименования библиотеки, что иногда затрудняет чтение кода (не в случае json, конечно).
Зато все константы JSON_*, которые идут в этой библиотеке, можно будет вызывать не из глобального пространства, а как константы класса JSON
Вообще, как многие справедливо ругают, в PHP слишком много функций находится в глобальном пространстве. Кроме этого, данная замена позволит гибко управлять и переопределять эти функции.
Согласен со многими пунктами. Сам собираю список того, чтобы я изменил в PHP — с кучей новых возможностей, разделением и оптимизацией стандартной библиотеки, упрощением синтаксиса, с цепочками функций стандартных функций, без оглядки на историческое наследие.
Но это получается уже новый ЯП, несовместимый с PHP, но конвертируемый в/из него.
Может, как-нибудь оформлю свои заметки в статью
А можно по-подробнее про инструменты, которые используете для автоматизации сборки и тестовых сред?
Мы тоже к подобной автоматизации стремимся потихоньку, используем самописный скрипт для генерации шаблонов и gulp для сборки css/js
А насколько такой вариант кроссбраузный? Просто вариант с изменением ширины поддерживают все браузеры. Интересует практическое применение на мобильных устройствах

Information

Rating
Does not participate
Registered
Activity