Как увидел картинку «Подключение умной розетки через переходник» не смог не поделиться мыслями.
При использовании готовых умных домов, например xiaomi — как раз получается такая картинка, но как показывает практика, мало кто задумывается, что переходники эти часто совсем не очень, а иногда очень не очень.
Вот как-то была ситуация, что потребителем выступал обогреватель, причем не особо то и мощный. Все в целом нормально работало, и работало долгое время, но в какой-то момент переходник внезапно расплавился и судя по всему собирался натурально загореться. Осторожнее вообщем.
Как мне кажется тут речь идет о сильно раздутых api, в которых придуман чуть ли не свой специальный язык запросов, хотя под такой функционал вполне подошел бы обычный sql.
Ну как бы DSL, особенно в виде ОРМ под которым SQL, это как бы нифига не NoSQL, на сколько мне кажется. Каким определением понятия NoSQL вы руководствуетесь?
Имхо тут дело даже не в тех, кто не знает и не хочет знать SQL, пытаясь что-то сделать через ОРМ, с такими и так все понятно. Имхо есть другая проблема — ряд людей, которые пытаются в реляционную базу пихать все подряд, старательно не замечая другие подходящие инструменты. Вот там да, без ОРМ все становится еще печальнее, однако ОРМ имхо в таком случае является костылем, прикрывающи основную проблему.
Имхо главная проблема попыток обучения ООП в излишней академичности и оторванности от практики. ООП это лишь инструмент, причем один из. Вот как молоток например. Можно провести лекцию по технике безопасности, однако как забивать гвозди проще и понятнее уяснить на практике.
А тут опять, ну не кошечки собачки, не машинки наследуемые, а самолеты. Опять какая-то хрень. Читаешь всякое такое, мучительно стараешься понять, даже код пытаешься такой писать, может быть.
А потом доходит, что стоит пойти посмотреть как другие люди код пишут, как устроены успешные большие проекты и тд. И собственно нет там ни кошечек ни самолетиков, а есть много другого всякого непонятного, а всякое это прочитанное, временами очень очень длинное из полезного дало пару абзатцев — ну типа основ синтаксиса.
Статья это типа такой странный троллинг что ли? Или так по приколу написали, чтобы написать?
Плюсы и и минусы странно сомнительные какие-то.
Так то у вас судя по всему есть некие проекты, ну так можно же написать, вот было Н серверов стало М на похожем функционале.
Раньше кодили нечто эдакое А дней, теперь Б.
Объемы переведенного опять же непонятны, а то вдруг некий не сильно большой сайт переписали, а потом придет вдруг осознание, что асинхронщина это вообщем-то больно, печально и не для всех в большом проекте. И намного дешевле было сервак добавить, чем адекватных джаваскриптеров найти, например.
>Случился фатально невнимательный merge ветки, в которой переделывали один из внутренних интерфейсов.
>Эти четыре минуты показали, что нам нужно усовершенствовать процесс деплоя, чтобы минимизировать риск ошибки.
Вейпинг вредный совет, если есть желание полностью избавиться от никотиновой зависимости, то он только растянет мучения. На самом деле, где-то через неделю после первой недели главная проблема — она в голове, и тут очень сильно помогает всякое, что повышает мотивацию, т.е. читать к чему приводит курение, картинки там всякие смотреть, общаться с людьми которые бросили. Лучше не искать какую-то замену, какую-то новую зависимость, а понять, что избавился от очен очень фиговой зависимости и найти в этом позитив.
В целом то преимущество не в возможности запускать там где Mysql нету, плюс в том, что его, например, можно тупо копированием перенести. Как показывает практика, для людей далеких от всякого технического без базы жить проще, да хотя бы из бекапа того же восстановиться.
Типа стройные логичные рассуждения, но которые исходят из
«появление на обломках былого раздолья государственного провайдера, который будет освобождён от выполнения предписаний по хранению трафика»
С чего вы так уверены, что такой провайдер будет освобожден от предписаний?
Тут сразу большой вопрос, а зачем так делать?
Нужны гетеры — средства современных IDE позволяют их сгенерить нажатием пары кнопок. Ваш же пример, как и многие другие с ипользованием $$ открывает простор для багов. Ошиблись где-то: либо в названии переменной или названии метода и сходу баг уже не обнаружить, а при другом подходе сама IDE нам бы об этом сказала.
Вообщем-то если подумать, например, когда мы генерим json,
то написание что-то вроде
echo('{var:"'.$var.'"}')
или
{var:"<?=$var?>"}
выглядит довольно странно и обычно так все-таки не делают.
Опять же при генерации XML, обычно стараются делать это на основе каких-то структур.
Однако в Html для браузера мы привыкли делать как-то так:
<input type="text" value="<?=$var?>">
Собственно все проблемы типа безопасности, необходимости экранирования и тд, как мне кажется, они именно из-за этого подхода. Т.е., по-моему, суть в том, что такой подход не органичен.
>А некоторые не шутят и действительно считают, что без «долларов» лучше
Ну если быть совсем честным, то их мнение имеет право на жизнь, вот на ваши примеры можно вот так посмотреть:
>1) Позволяет визуально отличать декларации переменных от структур, например:
>$a; // переменная
>a; // константа
Обычно константы все-таки заглавными выделяют, типа define («CONST1», "")
>2) Добавляет грандиозные и консистентные возможности метапрограммирования, >например:
А часто ли в реальном коде такое оправдано используется? Почти все случаи, которые я встречал были либо с проблемами в безопасности, либо слабо читаемыми, либо бажными. При этом ктож мешает бакс оставить именно для этого. т.е.
someVar // Вывод значения переменной some
$someVar // Вывод значения переменной, имя которой содержится внутри переменной some
>3) Позволяет делать интерполяцию без спец.символов (сомнительно очень), например:
Опять же как раз в этом случае бакс можно и оставить, так например сделано в Scala:
В чем проблема для вас определить функцию и делать <?= p()?>? Забыть не сложнее чем <?#=, лишние пара символов играют роль разве? При этом экранирование оно как бы разное бывает, не везде хватит htmlspecialchars, а кое-где его будет много. Собтсвенно c помощью PHP не только html генерят.
При использовании готовых умных домов, например xiaomi — как раз получается такая картинка, но как показывает практика, мало кто задумывается, что переходники эти часто совсем не очень, а иногда очень не очень.
Вот как-то была ситуация, что потребителем выступал обогреватель, причем не особо то и мощный. Все в целом нормально работало, и работало долгое время, но в какой-то момент переходник внезапно расплавился и судя по всему собирался натурально загореться. Осторожнее вообщем.
А тут опять, ну не кошечки собачки, не машинки наследуемые, а самолеты. Опять какая-то хрень. Читаешь всякое такое, мучительно стараешься понять, даже код пытаешься такой писать, может быть.
А потом доходит, что стоит пойти посмотреть как другие люди код пишут, как устроены успешные большие проекты и тд. И собственно нет там ни кошечек ни самолетиков, а есть много другого всякого непонятного, а всякое это прочитанное, временами очень очень длинное из полезного дало пару абзатцев — ну типа основ синтаксиса.
Плюсы и и минусы странно сомнительные какие-то.
Так то у вас судя по всему есть некие проекты, ну так можно же написать, вот было Н серверов стало М на похожем функционале.
Раньше кодили нечто эдакое А дней, теперь Б.
Объемы переведенного опять же непонятны, а то вдруг некий не сильно большой сайт переписали, а потом придет вдруг осознание, что асинхронщина это вообщем-то больно, печально и не для всех в большом проекте. И намного дешевле было сервак добавить, чем адекватных джаваскриптеров найти, например.
>Эти четыре минуты показали, что нам нужно усовершенствовать процесс деплоя, чтобы минимизировать риск ошибки.
А почему не отделить физически админку?
«появление на обломках былого раздолья государственного провайдера, который будет освобождён от выполнения предписаний по хранению трафика»
С чего вы так уверены, что такой провайдер будет освобожден от предписаний?
Нужны гетеры — средства современных IDE позволяют их сгенерить нажатием пары кнопок. Ваш же пример, как и многие другие с ипользованием $$ открывает простор для багов. Ошиблись где-то: либо в названии переменной или названии метода и сходу баг уже не обнаружить, а при другом подходе сама IDE нам бы об этом сказала.
Вообщем-то если подумать, например, когда мы генерим json,
то написание что-то вроде
или
выглядит довольно странно и обычно так все-таки не делают.
Опять же при генерации XML, обычно стараются делать это на основе каких-то структур.
Однако в Html для браузера мы привыкли делать как-то так:
Собственно все проблемы типа безопасности, необходимости экранирования и тд, как мне кажется, они именно из-за этого подхода. Т.е., по-моему, суть в том, что такой подход не органичен.
Ну если быть совсем честным, то их мнение имеет право на жизнь, вот на ваши примеры можно вот так посмотреть:
>1) Позволяет визуально отличать декларации переменных от структур, например:
>$a; // переменная
>a; // константа
Обычно константы все-таки заглавными выделяют, типа define («CONST1», "")
>2) Добавляет грандиозные и консистентные возможности метапрограммирования, >например:
А часто ли в реальном коде такое оправдано используется? Почти все случаи, которые я встречал были либо с проблемами в безопасности, либо слабо читаемыми, либо бажными. При этом ктож мешает бакс оставить именно для этого. т.е.
someVar // Вывод значения переменной some
$someVar // Вывод значения переменной, имя которой содержится внутри переменной some
>3) Позволяет делать интерполяцию без спец.символов (сомнительно очень), например:
Опять же как раз в этом случае бакс можно и оставить, так например сделано в Scala:
println(s"${msg}\n\n")
Да пошутил же я ))
Просто одно время был холивар, ну типа лишний шифт нажимать))
Очередной виток спирали,
улыбаемся и машем, в ряде задач вполне себе прикольно.