Например? Какие боли у PHP по Вашему мнению? Нет асинхронности и корутин из коробки? Но в целом же есть (и асинхронность, и файберы, и множество библиотек добавляющих функционал). Я не пробовал го, мне нечего сказать о его плюсах/минусах. Я только знаю, что там нет нормальной обработки ошибок/исключений, и это для меня огромный dealbreaker.
Да, я и дальше так считаю. Вы взяли инструмент, но не знаете как ним пользоваться. Но уже считаете, что статьями на хабре можете учить других. Повторю еще раз - то что Вы "изобрели" в статье - полнейший бред, Вы не понимаете зачем Вам ООП. ООП это не только про объекты с методами и классами, хоть и объект является ключевым понятием.
Тем не менее Вы считаете, что основы надо читать мне. Хорошо, я не спорю, спасибо =) Я хоть и читал уже множество раз в разных источниках, но уверен, что в любом случае прочитаю как-то еще раз. Учиться и обновлять знания, знаете ли, приходится постоянно.
Паттерны не зависят от языка. Если Вы будете делать условный наблюдатель или фабрику - то это совсем не про язык. То же можно сказать и про SOLID, GRASP, DDD, и прочие модные словечки. Вот к примеру, инверсия зависимостей. Если программист понимает, зачем оно, то ему не составит проблем использовать этот паттерн а большинстве языков. А если нет - то на любом языке будет костылить, пока не поймёт.
Лично я PHP программист. Мое мнение - человек просто сдался. Не язык помойка, а автор слабак =)
Ну, во-первых, раз уж на то пошло, то Вы мне не друг =) А во-вторых, лично я Вам минусов не ставил, делать мне нечего =)
Но Вы и дальше продолжаете. Хорошо, удачи в познании разных архитектур приложений =) Моё мнение (не должно являться правильным для всех) - Вы совсем не понимаете, зачем Вам ООП.
Да ладно?! Разве не это Вам пытались вчера вталдычить, а Вы упорно продолжали спорить, что изобрели что-то новое и удобное. А оказывается, нужен сервис отправки сообщений. Эвоно как, неожиданно =)
но я отвечу, что разница между контроллером и моделью лишь функциональная (в контексте MVC)
да что Вы не говорите? С точки зрения MVC, модель - это бизнес логика, а в контроллер инжектятся зависимости, обрабатываются входящие параметры и с помощью команд модели ей передается управление. С точки зрения чистой архитектуры бизнес логика должна быть изолирована от инфраструктурного слоя, который Вы предлагаете пробросить в модель. Думаю, критики прекрасно понимают, что именно Вы пытаетесь сделать.
Согласен, в статье просто часто мелькает неймспейс models, и то, что абстрактный класс сообщения - расширенная Model. Именно термин не упоминается, разве что вскользь.
По поводу преимуществ. Все преимущества сойдут на нет, когда Ваш god-object надо будет изменять. К примеру, перед отправкой сообщения (или после) нужна какая-то логика. А потом надо будет добавить дополнительный аргумент в конструктор. И т.д.
Сообщение ничего не должно знать, каким образом оно будет отправляться. И будет ли отправляться вообще. И тем более не должно отправлять себя само, содержа в себе инстанс реализации отправки сообщений, для этих целей лучше создать сервис, который будет заниматься отправкой ЛЮБОГО сообщения. Он ничего не должен знать о том, каким образом формируется отправляемое сообщение. Его задача - просто отправить. У него должен быть метод отправки с аргументом - интерфейс сообщения. Именно интерфейс, а не конкретная реализация.
Но Вы вправе делать, как Вам угодно. Если оно работает - то почему бы и нет? =)
разве это проблема языка? В PHP есть строгая типизация, есть PHAR*. Допустим, если Вам в руки попадётся инструмент, написанный на PHP8, с включенным strict_types, и в CI выполняются проверки статическим анализатором (к примеру, phpstan с уровнем 9), и тестами (в идеале может даже мутационное) - количественно проблем будет около нуля.
The phar extension provides a way to put entire PHP applications into a single file called a "phar" (PHP Archive) for easy distribution and installation
Начните с того, что термин "Модель" (используемый в статье, и Вами в предыдущем комментарии) с точки зрения любой архитектуры - это не про объект письма, который больше похож на ValueObject. И ООП - это не про то, что данный объект письма может сам себя выслать (чего?) и с помощью DI втянуть в себя зависимости (?!). Автор может и про ООП, но конкретно своё видение, как "ООП - это когда объект с проперти и методами. А еще можно расширить клас. И наследовать, ага.". Инверсия зависимостей, единственная ответственность, паттерны - не, не слышал.
У Вас довольно странное понимание ответственности за нарушение авторских прав и нелегальное использование чужой интеллектуальной собственности. Судя по Вашей логике в РФ и РБ можно скомуниздить чужое и выдать за своё. Хотя, постойте...
скорее всего потолок будет в тысячу-две кубитов на нынешней технологии.
У меня еще вопрос возник. Вот Вы говорите о "нынешней технологии" в 1-2к кубитов, и упоминали, что лет через 10 предположительно будет 50-100к. Я так понимаю, это будет новая технология? Какие принципиальные отличия от той технологии, что есть сейчас? Новые материалы сверхпроводников или другая физическая реализация кубитов?
И как Вы считаете, что-то подобное закону Мура применимо к развитию КК?
Можете назвать пример реального практического применения, на что сейчас способны КК? И есть ли вообще применения, или пока что всё на стадии активной разработки? Насколько мне известно, сейчас 51 честный кубит (не считая машины для квантового отжига DWave) - потолок, так? Квантовое превосходство Гугл - пока что совсем не превосходство? Вот Вы, к примеру, какую задачу/алгоритм пробовали выполнить? И, допустим, Вы в 2035-ом и имеете КК. Какую текущую задачу для решения выберете в первую очередь? =)
И посоветуйте, пожалуйста, вводную книгу для совершенного новичка в квантовом программировании.
Проект был феноменально успешен, они достигли чувствительности больше, чем ожидали, почти на порядок.
Ого, круто! Будем ждать громких открытий, как от LIGO и Virgo 5 лет назад =)
Иметь личный ЦОД. Задач которые он будет выполнять - достаточно. Например, использовать как локальный демо-стейдж чего-либо (иногда бывает необходимость, решаемая с помощью ngrok) Так же я бы переместил записи видеонаблюдения туда (сейчас в облаке) и всё равно имел бы доступ из внешнего мира (добавив простую вебморду за авторизацией). Ну и еще в планах умный дом с API наружу.
Да, я понимаю, что проще, наверное купить хостинг для таких целей, но интересует именно процесс.
Не совсем конкретно в тему, но смежный вопрос. Как "построить" и обезопасить свой домашний хостинг для личных нужд? Для примера, некоторые вводные данные:
Я смогу поднять виртуальные хосты и установить всё нужное, что бы оно работало локально.
Панели управления как на хостингах не нужны.
Чего не хватает, и каковы мои дальнейшие действия и на что особенно обратить внимание? Можно просто списком, детали я постараюсь найти в интернете =) Спасибо
А я наоборот стараюсь не захламлять пул людей, с которыми считаю нужным поддерживать какую-либо социальную связь. Есть такое число Данбара, которое говорит о том, что человеку, как социальному существу, будет сложно поддерживать в среднем более 150 связей. Вот эти все "коллекции" друзей и контактов в социальных сетях и мессенджерах, по моему мнению, никак не отображают реальное положение дел. Их группировка - это не "A", "B", "C", а "семья", "друзья", "работа" (ну и другие группы, при чём один человек может входить в разные одновременно). И все остальные - тоже люди, с нейтральным отношением к ним, любой из которых может в будущем обрасти связью.
За свою жизнь я сталкивался с огромным множеством людей, научился "удалять" из друзей, пересматривать своё отношение к ним, ожидать, что список может как пополняться, так и убавляться. Важнее, что бы именно хотелось иметь связь с конкретным человеком в конкретный период времени, а не ожидать, что когда-то он станет полезен.
В целом, Вы полностью правы и я согласен, что в данном конкретном случае нарушается то, о чём я говорю =)
Но давайте снимем розовые очки и представим ситуацию из реального мира. Во-первых, стоит проверить, а нужно ли вообще вызывать cv2.resize? Возможен вариант, что frameSize[0] и frameSize[1] идентичны входящему размеру, следовательно, нужна проверка использующая frameSize. При чём, в случае идентичности размеров нужна единожды, а сам вызов ресайза в цикле будет вредным (если Вам, конечно же, важно быстродействие и не всё равно на лишние такты и память). Хотя тут тоже можно возразить, что совсем ничего не мешает использовать дополнительные переменные, которые, в целом не нужны.
Я к чему. Я согласен, что магические числа - плохо. Но я не согласен, что в данном конкретном случае использование frameSize не оправдано. Просто всунуть tuple вместо переменной в ресайз - как раз таки будет "магическими числами". И комментарий совсем не поможет.
Например? Какие боли у PHP по Вашему мнению? Нет асинхронности и корутин из коробки? Но в целом же есть (и асинхронность, и файберы, и множество библиотек добавляющих функционал). Я не пробовал го, мне нечего сказать о его плюсах/минусах. Я только знаю, что там нет нормальной обработки ошибок/исключений, и это для меня огромный dealbreaker.
Да, я и дальше так считаю. Вы взяли инструмент, но не знаете как ним пользоваться. Но уже считаете, что статьями на хабре можете учить других. Повторю еще раз - то что Вы "изобрели" в статье - полнейший бред, Вы не понимаете зачем Вам ООП. ООП это не только про объекты с методами и классами, хоть и объект является ключевым понятием.
Тем не менее Вы считаете, что основы надо читать мне. Хорошо, я не спорю, спасибо =) Я хоть и читал уже множество раз в разных источниках, но уверен, что в любом случае прочитаю как-то еще раз. Учиться и обновлять знания, знаете ли, приходится постоянно.
Паттерны не зависят от языка. Если Вы будете делать условный наблюдатель или фабрику - то это совсем не про язык. То же можно сказать и про SOLID, GRASP, DDD, и прочие модные словечки. Вот к примеру, инверсия зависимостей. Если программист понимает, зачем оно, то ему не составит проблем использовать этот паттерн а большинстве языков. А если нет - то на любом языке будет костылить, пока не поймёт.
Лично я PHP программист. Мое мнение - человек просто сдался. Не язык помойка, а автор слабак =)
Вы предлагаете мне освоить основы из статьи на хабре? Спасибо, занятно =)
Если серьезно, я прочитал не одну книгу Фаулера, Эванса, Вон Вернона и многих других. И минусую Вас не я, хватит на этом заострять внимание.
Ну, во-первых, раз уж на то пошло, то Вы мне не друг =) А во-вторых, лично я Вам минусов не ставил, делать мне нечего =)
Но Вы и дальше продолжаете. Хорошо, удачи в познании разных архитектур приложений =) Моё мнение (не должно являться правильным для всех) - Вы совсем не понимаете, зачем Вам ООП.
Да ладно?! Разве не это Вам пытались вчера вталдычить, а Вы упорно продолжали спорить, что изобрели что-то новое и удобное. А оказывается, нужен сервис отправки сообщений. Эвоно как, неожиданно =)
да что Вы не говорите? С точки зрения MVC, модель - это бизнес логика, а в контроллер инжектятся зависимости, обрабатываются входящие параметры и с помощью команд модели ей передается управление. С точки зрения чистой архитектуры бизнес логика должна быть изолирована от инфраструктурного слоя, который Вы предлагаете пробросить в модель. Думаю, критики прекрасно понимают, что именно Вы пытаетесь сделать.
Согласен, в статье просто часто мелькает неймспейс models, и то, что абстрактный класс сообщения - расширенная Model. Именно термин не упоминается, разве что вскользь.
По поводу преимуществ. Все преимущества сойдут на нет, когда Ваш god-object надо будет изменять. К примеру, перед отправкой сообщения (или после) нужна какая-то логика. А потом надо будет добавить дополнительный аргумент в конструктор. И т.д.
Сообщение ничего не должно знать, каким образом оно будет отправляться. И будет ли отправляться вообще. И тем более не должно отправлять себя само, содержа в себе инстанс реализации отправки сообщений, для этих целей лучше создать сервис, который будет заниматься отправкой ЛЮБОГО сообщения. Он ничего не должен знать о том, каким образом формируется отправляемое сообщение. Его задача - просто отправить. У него должен быть метод отправки с аргументом - интерфейс сообщения. Именно интерфейс, а не конкретная реализация.
Но Вы вправе делать, как Вам угодно. Если оно работает - то почему бы и нет? =)
В целом, я согласен с тем, о чём Вы говорите, но
разве это проблема языка? В PHP есть строгая типизация, есть PHAR*. Допустим, если Вам в руки попадётся инструмент, написанный на PHP8, с включенным strict_types, и в CI выполняются проверки статическим анализатором (к примеру, phpstan с уровнем 9), и тестами (в идеале может даже мутационное) - количественно проблем будет около нуля.
Начните с того, что термин "Модель" (используемый в статье, и Вами в предыдущем комментарии) с точки зрения любой архитектуры - это не про объект письма, который больше похож на ValueObject. И ООП - это не про то, что данный объект письма может сам себя выслать (чего?) и с помощью DI втянуть в себя зависимости (?!). Автор может и про ООП, но конкретно своё видение, как "ООП - это когда объект с проперти и методами. А еще можно расширить клас. И наследовать, ага.". Инверсия зависимостей, единственная ответственность, паттерны - не, не слышал.
Ничего не имею против
SonataAdminBundle. Но вEasyAdmin3вся статья поместится в одну строку в методеProductCrudController::configureFields:У Вас довольно странное понимание ответственности за нарушение авторских прав и нелегальное использование чужой интеллектуальной собственности. Судя по Вашей логике в РФ и РБ можно скомуниздить чужое и выдать за своё. Хотя, постойте...
У меня еще вопрос возник. Вот Вы говорите о "нынешней технологии" в 1-2к кубитов, и упоминали, что лет через 10 предположительно будет 50-100к. Я так понимаю, это будет новая технология? Какие принципиальные отличия от той технологии, что есть сейчас? Новые материалы сверхпроводников или другая физическая реализация кубитов?
И как Вы считаете, что-то подобное закону Мура применимо к развитию КК?
Спасибо огромное за ответы! Очень интересная и полезная информация!
Можете назвать пример реального практического применения, на что сейчас способны КК? И есть ли вообще применения, или пока что всё на стадии активной разработки? Насколько мне известно, сейчас 51 честный кубит (не считая машины для квантового отжига DWave) - потолок, так? Квантовое превосходство Гугл - пока что совсем не превосходство? Вот Вы, к примеру, какую задачу/алгоритм пробовали выполнить? И, допустим, Вы в 2035-ом и имеете КК. Какую текущую задачу для решения выберете в первую очередь? =)
И посоветуйте, пожалуйста, вводную книгу для совершенного новичка в квантовом программировании.
Ого, круто! Будем ждать громких открытий, как от LIGO и Virgo 5 лет назад =)
Что можете сказать о будущем квантовых компьютеров в ближайшие 5-10 лет? Доводилось ли Вам работать с реальными образцами?
И еще один вопрос: как в целом сейчас обстоят дела у LISA. Есть достижения в этой области?
Иметь личный ЦОД. Задач которые он будет выполнять - достаточно. Например, использовать как локальный демо-стейдж чего-либо (иногда бывает необходимость, решаемая с помощью ngrok) Так же я бы переместил записи видеонаблюдения туда (сейчас в облаке) и всё равно имел бы доступ из внешнего мира (добавив простую вебморду за авторизацией). Ну и еще в планах умный дом с API наружу.
Да, я понимаю, что проще, наверное купить хостинг для таких целей, но интересует именно процесс.
Не совсем конкретно в тему, но смежный вопрос. Как "построить" и обезопасить свой домашний хостинг для личных нужд? Для примера, некоторые вводные данные:
У меня есть железо и выделенный IP-адрес.
Трафик ожидается маленьким (личное использование).
Я смогу поднять виртуальные хосты и установить всё нужное, что бы оно работало локально.
Панели управления как на хостингах не нужны.
Чего не хватает, и каковы мои дальнейшие действия и на что особенно обратить внимание? Можно просто списком, детали я постараюсь найти в интернете =) Спасибо
А я наоборот стараюсь не захламлять пул людей, с которыми считаю нужным поддерживать какую-либо социальную связь. Есть такое число Данбара, которое говорит о том, что человеку, как социальному существу, будет сложно поддерживать в среднем более 150 связей. Вот эти все "коллекции" друзей и контактов в социальных сетях и мессенджерах, по моему мнению, никак не отображают реальное положение дел. Их группировка - это не "A", "B", "C", а "семья", "друзья", "работа" (ну и другие группы, при чём один человек может входить в разные одновременно). И все остальные - тоже люди, с нейтральным отношением к ним, любой из которых может в будущем обрасти связью.
За свою жизнь я сталкивался с огромным множеством людей, научился "удалять" из друзей, пересматривать своё отношение к ним, ожидать, что список может как пополняться, так и убавляться. Важнее, что бы именно хотелось иметь связь с конкретным человеком в конкретный период времени, а не ожидать, что когда-то он станет полезен.
В целом, Вы полностью правы и я согласен, что в данном конкретном случае нарушается то, о чём я говорю =)
Но давайте снимем розовые очки и представим ситуацию из реального мира. Во-первых, стоит проверить, а нужно ли вообще вызывать
cv2.resize? Возможен вариант, чтоframeSize[0]иframeSize[1]идентичны входящему размеру, следовательно, нужна проверка использующаяframeSize. При чём, в случае идентичности размеров нужна единожды, а сам вызов ресайза в цикле будет вредным (если Вам, конечно же, важно быстродействие и не всё равно на лишние такты и память). Хотя тут тоже можно возразить, что совсем ничего не мешает использовать дополнительные переменные, которые, в целом не нужны.Я к чему. Я согласен, что магические числа - плохо. Но я не согласен, что в данном конкретном случае использование frameSize не оправдано. Просто всунуть tuple вместо переменной в ресайз - как раз таки будет "магическими числами". И комментарий совсем не поможет.