Выглядит так, что большинство выполненных вручную действий как раз и должно быть реализовано в провайдере Selectel для TF. Надо его развивать. Действия в админке должны заканчиваться на генерации доступов к API, иначе это не IaC.
Использование провайдера HTTP вместе с API, не поддерживающим идемпотентность, может привести к проблемам.
Но есть Psalm и PHPStan, там даже дженерики сейчас можно описать с помощью аннотаций в PHPDoc, это уже нативно поддерживается IDE, устанавливается и настраивается локально и в CI за полчаса.
Я согласен с комментом выше про "автор слабак". Я в PHP почти 10 лет и это хороший инструмент, если его использовать правильно. Да, я также иногда пишу код на TypeScript и Go. Да, есть что-то в этих языках, что мне нравится больше, чем в PHP, но есть разные задачи, а ЯП — инструмент и его нужно использовать правильно.
Как писал товарищ @bombe, есть ещё и Temporal, например, где вы можете вдоволь попрограммировать на том же Go в своём PHP-приложении, если очень хочется или того требует задача.
Иногда нужно работать либо с большими числами, либо с числами с фиксированной точностью, либо с большой мантиссой. Для этого в PHP удобных нативных инструментов нет.
Для организации Decimal существует экстеншн: https://github.com/php-decimal/ext-decimal. Как раз там как бы реализована перегрузка операторов на уровне экстеншна, то есть:
$foo = new Decimal("0.1");
$bar = new Decimal("0.2");
$baz = $foo + $bar;
echo $baz->toString(); // "0.3"
Всё же, привычные арифметические операторы были бы удобны здесь. Но остаётся открытым вопрос сложения, например, нативного int с каким-то BigInteger.
Хотелось бы остановиться на том, что результатом операций с привычными бинарными операторами будут числа в том или ином представлении (тот же BigInteger или Decimal). Дальше уже вопросы типизации.
Я рассуждал с мыслью о платных коробках. Когда при продаже ПО клиенту можно не переживать, что через несколько месяцев он будет выложен на какой-нибудь warez-помойке в комплекте с парочкой троянов.
Иногда условия бизнеса не позволяют создать какое-то SAAS-решение, клиент борется за то, чтобы софт был на его сервере и под его контролем.
Ломают. И в нашем случае, скорее всего, научатся.
Тут вопрос в возможности использования такого декомпилированного кода и целесообразности таких действий.
Подождём, понаблюдаем. Но если появится нативный инструмент, который будет эту задачу решать и решать её хорошо, то пользы от этого будет точно больше, чем проблем. Всё же, в команде internals достаточно хороших и адекватных специалистов.
Да, возможно в опенсорсе подобные решения создадут проблемы, но для коммерческой разработки — большой плюс.
Будет намного проще отдать клиенту "код" без костылей в виде обфускации (всё равно можно развернуть обратно). Текущие решения вроде Ioncube не работают с современными версиями php (7.4 / 8.0).
Тем более, в мире C++ (и не только) и скомпилированных библиотек с этим нет никаких проблем: библиотека поставляется вместе с заголовочником, схема отлаженная. Возможно, в php появится похожая возможность.
во всякие вордпрессы юзеры будут сами себе ставить кучу малвари
Это происходит и сейчас, некоторые разработчики скачивают "крякнутые" плагины/темы и т.п. и устанавливают их, даже не открывая сорцы.
У меня аналогичная ситуация. Как-то женщина моя вошла в телеграм на моём телефоне, теперь ей всё время приходят уведомления, что какой-то контакт из моей телефонной книги зарегистрировался в телеграм.
Было очень тяжело читать. А автору стоит вспомнить о том, что PHP — это не только про сайты (сайты в том понимании, в котором они упоминаются в тексте статьи).
Блин, а я вот задумывался о покупке с GooglePlay и наткнулся на такие посты на Пикабу и сразу засомневался.
Очень жаль, что так вышло (ведь это, наверное, неплохо повлияло на количество заказов), надеюсь, правосудие восторжествует!
Для простых графиков лучше выбрать нечто вроде amcharts или highcharts. D3 для более серьёзных вещей, ИМХО.
И разобраться было проще, чем с D3.js. Но это сугубо субъективное мнение.
Иногда не следует принципам, да, это видно и порой очень грустно. Но на деле всё выглядит хорошо и упущения по своим же стайлгайдом либо чем-то оправданы, либо не имеют большого значения.
Заранее скажу — я не дизайнер.
В статье написано, что человек «пропитался концепцией». Но на деле, установив приложение, оказывается, что разработчик вовсе не знает что такое Material Design, об этом говорит всё.
1. Невнятные анимации выплывания при тапе на «настройки» (+ ещё и иконка отвратная);
2. Иконка наезжает на другую иконку при свайпе влево/вправо (перемещение между экранами);
3. Огромные ничем не оправданные отступы у Floating Button;
4. Про «Поиск контактов» написано выше;
5. Повсюду непонятные отступы у элементов форм;
6. Поле ввода текста с фразой «Я перезвоню попозже»: материальные кнопки с текстом должны быть в верхнем регистре, само поле ввода не материально. При открытии диалога редактирования этого текста дёргается экран (ошибка не дизайна, но было неприятно — пытается открыться клавиатура, но приложение её быстренько закрывает).
7. Страница оплаты. Непонятные прямоугольники с ценами, также хедер (верхняя полоска приложения) чуток больше, чем везде.
8. Помимо того, что некоторые иконки выглядят плохо, они не материальны (https://www.google.com/design/spec/style/icons.html)
Общее впечатление: разработчики пытались придумать что-то своё, похожее на Material Design. Моё мнение — не получилось.
Выглядит так, что большинство выполненных вручную действий как раз и должно быть реализовано в провайдере Selectel для TF. Надо его развивать. Действия в админке должны заканчиваться на генерации доступов к API, иначе это не IaC.
Использование провайдера HTTP вместе с API, не поддерживающим идемпотентность, может привести к проблемам.
Позвольте позанудничать.
А какое отношение статья имеет к Laravel? Если заменить название фрейморка на другое, ничего по большей части не изменится.
Средствами языка — да.
Но есть Psalm и PHPStan, там даже дженерики сейчас можно описать с помощью аннотаций в PHPDoc, это уже нативно поддерживается IDE, устанавливается и настраивается локально и в CI за полчаса.
Я согласен с комментом выше про "автор слабак".
Я в PHP почти 10 лет и это хороший инструмент, если его использовать правильно.
Да, я также иногда пишу код на TypeScript и Go. Да, есть что-то в этих языках, что мне нравится больше, чем в PHP, но есть разные задачи, а ЯП — инструмент и его нужно использовать правильно.
Как писал товарищ @bombe, есть ещё и Temporal, например, где вы можете вдоволь попрограммировать на том же Go в своём PHP-приложении, если очень хочется или того требует задача.
Ну вообще, все эти символы задействованы и парсеру известны. :)
@ — Error Control Operator
# — Комментарий
^ И ~ — Побитовые операции. XOR и отрицание соответственно.
Иногда нужно работать либо с большими числами, либо с числами с фиксированной точностью, либо с большой мантиссой. Для этого в PHP удобных нативных инструментов нет.
Для организации Decimal существует экстеншн: https://github.com/php-decimal/ext-decimal. Как раз там как бы реализована перегрузка операторов на уровне экстеншна, то есть:
Также небезвестное решение: https://github.com/brick/math. В этом случае используются методы вроде
sum(...)Всё же, привычные арифметические операторы были бы удобны здесь. Но остаётся открытым вопрос сложения, например, нативного
intс каким-тоBigInteger.Хотелось бы остановиться на том, что результатом операций с привычными бинарными операторами будут числа в том или ином представлении (тот же
BigIntegerилиDecimal). Дальше уже вопросы типизации.Круто! Думаю, данный инструмент будет очень полезен.
Спасибо за проделанную работу!
Всё верно.
Я рассуждал с мыслью о платных коробках. Когда при продаже ПО клиенту можно не переживать, что через несколько месяцев он будет выложен на какой-нибудь warez-помойке в комплекте с парочкой троянов.
Иногда условия бизнеса не позволяют создать какое-то SAAS-решение, клиент борется за то, чтобы софт был на его сервере и под его контролем.
Ломают. И в нашем случае, скорее всего, научатся.
Тут вопрос в возможности использования такого декомпилированного кода и целесообразности таких действий.
Подождём, понаблюдаем. Но если появится нативный инструмент, который будет эту задачу решать и решать её хорошо, то пользы от этого будет точно больше, чем проблем. Всё же, в команде internals достаточно хороших и адекватных специалистов.
Да, возможно в опенсорсе подобные решения создадут проблемы, но для коммерческой разработки — большой плюс.
Будет намного проще отдать клиенту "код" без костылей в виде обфускации (всё равно можно развернуть обратно). Текущие решения вроде Ioncube не работают с современными версиями php (7.4 / 8.0).
Тем более, в мире C++ (и не только) и скомпилированных библиотек с этим нет никаких проблем: библиотека поставляется вместе с заголовочником, схема отлаженная. Возможно, в php появится похожая возможность.
Спасибо!
Заказал комплектухи. Всё, кроме ESP32, их есть у меня.
Глядишь и прошивку опубликуете к моменту, как приедет, буду пользоваться.
Десктопный Slack, например, — тоже Electron.
И работает нормально.
Поддерживаю.
У меня аналогичная ситуация. Как-то женщина моя вошла в телеграм на моём телефоне, теперь ей всё время приходят уведомления, что какой-то контакт из моей телефонной книги зарегистрировался в телеграм.
Вроде бы и реализация несложная, но по сей день почему-то такого не было.
Установил, работает, нравится. Спасибо!
Также было бы удобно искать через клик по расширению (сейчас там пусто)
Очень жаль, что так вышло (ведь это, наверное, неплохо повлияло на количество заказов), надеюсь, правосудие восторжествует!
Это похоже на годный гайд. Спасибо! Буду пробовать.
И разобраться было проще, чем с D3.js. Но это сугубо субъективное мнение.
Заранее скажу — я не дизайнер.
В статье написано, что человек «пропитался концепцией». Но на деле, установив приложение, оказывается, что разработчик вовсе не знает что такое Material Design, об этом говорит всё.
1. Невнятные анимации выплывания при тапе на «настройки» (+ ещё и иконка отвратная);
2. Иконка наезжает на другую иконку при свайпе влево/вправо (перемещение между экранами);
3. Огромные ничем не оправданные отступы у Floating Button;
4. Про «Поиск контактов» написано выше;
5. Повсюду непонятные отступы у элементов форм;
6. Поле ввода текста с фразой «Я перезвоню попозже»: материальные кнопки с текстом должны быть в верхнем регистре, само поле ввода не материально. При открытии диалога редактирования этого текста дёргается экран (ошибка не дизайна, но было неприятно — пытается открыться клавиатура, но приложение её быстренько закрывает).
7. Страница оплаты. Непонятные прямоугольники с ценами, также хедер (верхняя полоска приложения) чуток больше, чем везде.
8. Помимо того, что некоторые иконки выглядят плохо, они не материальны (https://www.google.com/design/spec/style/icons.html)
Общее впечатление: разработчики пытались придумать что-то своё, похожее на Material Design. Моё мнение — не получилось.