Да, все верно, на ООП можно реализовать смыслы, которые я писал в статье. Но можно и не реализовать (если написать плохо по ООП). Т.е. тут я говорю в одной плоскости, а ООП в параллельной плоскости, одно не исключает другого.
Если прям дотошно придираться к слову "парадигма", то я могу предложить выделить минимальные "свойства" в различных языках программирования, скомбинировать их и написать свой язык программирования со своей уникальной комбинацией этих минимальных "свойств", и тогда это уже будет язык программирования своей парадигмы.
И вот выделение этих "минимальных" свойств (элементарных частиц) (и их комбинация) и есть мое предложение парадигмы.
"Свойство" - это то, что можно русским языком расскзать об объекте/сущности.
Например, когда мы описываем функции, обычно мы говорим: "функция имеет имя". Вот то, что "функция имеет имя" - это и есть "свойство" такого объекта как функция.
Т.е, относитесь к свойствам - как к предложениям на русском языке, которыми можно описать функцию. Вот сколько предложений о функции вы сможете сказать - столько свойств и есть у функции.
А затем начинается экспресиионизм - мы говорим несколько предложений о функции и несколько предложений о json строке. И затем комбинируем эти предложения между собой (1-е предложение описывающее функцию, 2-е предложеие описывающее функцию и 3-е предложение описывающее json строку), и пытамеся создать новый объект, обладающий данной комбинацией предложений.
И если бы мы могли внедрить в свой язык программирования новые ключевые слова или любые новые объекты (функции, трейты, интерфейсы, миксины и все что хотим), то мы бы добавили новое ключевое слово и наш язык программирования стал бы описываться нашей парадигмой (нашей комбинацией предложений на русском языке). И это было бы истинно парадигмой программирования.
Но мы не пишем свой язык программирования, по-этому мы не можем добавить новые ключевые слова или новые "объекты" (функции, трейты, интерфейсы, миксины) в свой язык. По-этому мы используем стандартные, данные в нашем языке программирования сущности, и поверх них создаем "метапрограммирование" - поверх функций, трейтов, интерфейсов, миксинов создаем новую сущность, которую если описывать на русском языке, то она будет описана теми предложенями, которые мы решили объединить.
Например в ООП языке программирования новая сущность будет скорее всего классом, реализующим определенное поведение. Например если мы комбинируем 2 свойства - имеет имя и может выполняться, то у нашего класса будет поле name и будет реализован интерфейс типа Invokable, чтобы наш объект можно было вызвать через obj(); Если захотим добавить совйство "может сериализоваться в простую строку", то реализуем интерфейс Stringable.
Т.е. новая сущность - это класс, имеющий поля и реализующий интерфейсы. А в функциональном языке программирования - набор функций.
И тут мы получаем уже не парадигму программирования, а некий "подход к построению метаобъектов (мета - потому что объект поверх стандартных объектов - функции, класса и т.д.) и из этих объектов состоит наша программа, которая выполняет полезное действие". Не парадигма программирования, но некий подход к программированию.
Это по поводу JSON. Ну 1) малое количество символов: скобки {}, кавычки ", запятая , и вроде все. 2) простая (по сравнению с xml) структура документа, нет аттрибутов, namespace'ов из xml и т.д. 3) маленькое количество типов данных 4) и в целом когда смотришь на JSON обычно сразу понимаешь что там написано.
Спасибо за интересные статьи. А что вы собираете делать дальше? 1) Вы станете евангелистом алгоритм собеседований Российских компаний? Т.е. всегда будете знать актуальные алгоритмические собеседования в Российские компании и публиковать их и разбирать их? 2) Или вы будете вести тренинги по алгоритмам в Российские компании?
Так они всего лишь держатели акций. Т.е. они теперь не могут продать свои акции по хорошей цене, по-этому требуют компенсацию разницы в цене от компании.
Да, согласен надо искать инструменты, которые дают серьезные преимущества, т.е. прорывные инструменты, а не побеждать проблемы.
Статья - инфоповод. Попытка что-то "пережевачить" (от слова жевачка для мозгов) идею - мысль, посмотреть ее с разных сторон еще раз что-то обсудить. Если бы на хабре не минусили, тут были бы такие интересные дискуссии в комментариях.
Статья про то, что - все проблемы PHP можно победить - имея хороший инструмент (стек) и код. Но например у меня опыта в стеке, который победит все проблемы PHP - нету.
Для сравнения Golang и PHP вы взяли дополнительное расширение для PHP - Swoole.
Подскажите, это расширение 100% совместимо с популярными PHP фреймворками, на которых пишут современные веб приложения - Symfony (особенно интересно, т.к. люблю этот фреймворк), Laravel, Yii. Имеется ввиду, что приходится расширять код фреймворков, где расширение кода не предусмотрено, или перегружать функции из стандартной библиотеки PHP, т.е. "черные" хаки.
Когда я сталкиваюсь с тем, что моя работа не может уложиться в какую-то методологию, и меня спрашивают, смогу ли я селать работу по методологии, я объясняю какую работу я должен сделать (написать код) и спрашиваю менеджера (обычно методолгист - менеджер)
- я рассказал, какую работу я должен сделать, как мастер методологии расскажите мне пожалуйста как мне уложить мою работу в эту методологию?
Я просто перестал считать себя супер профессионалом Скрама (в частности), и что я все понимаю и все в нем знаю. Профессионал Скрама - менеджер, я, как профессионал написания кода пробую найти с ним, как со специалистом в другой области контакт.
У нас особого стейта нету. Пара примеров: количество непрочитанных уведомлений в нотификациях, пара восклицательных знаков в меню на разделах, на которые пользователю надо обратить внимание (документы просрачиваются например, надо загрузить новые).
Эти стейты загружаются отдельными API запросами. Т.е. при переходе на новый фронт полностью перезагружается весь фронт (полное обновление страницы), и делаются API запросы на получение всех необходимых "восклицательных знаков (стейтов), которые надо показать пользователю", и потом пока пользователь ходит по новому фронту стейты не загружаются, потом при переходе на старый фронт снова все загружается через API.
Данные страниц не кешируются. Т.е. если пользователь зашел в таблицу каких-то данных, то при очередном переходе на эту страницу данные загрузятся заново.
Имеем 2 отдельных проекта. Отдельные URL обслуживаются старым проектом, отдельные URL обслуживаются новым проектом. Редиректы сделаны на стороне nginx + kubernetes. Т.е. у нас базовая единица разделения - отдельный URL.
Проблемы следующие: первый шаг очень большой, потому что нужно сделать один и тот же layout в старом и новом фронте, меню, модалки, панели, каркас и т.д.
Сложно мигрировать большие навороченные страницы со сложной логикой. Бывают такие страницы, которые мега навороченные по функционалу. Таких страниц у нас немного, остальные страницы в основном несложные мигрируются просто.
Изначально суд признал неправоту банка, но последующие инстанции встали на его сторону.
Непонятно почему последующие инстанции всатли на сторону банка, хотя верховный суд привел весьма логичные доказательства правоты пользователя, а адвокат вроде приводит нелогичные доказательства, например:
Наконец, как отметил судья, банк может заблокировать деньги на счёте только по решению суда либо по постановлению органов предварительного следствия при наличии судебного решения.
Получается суды разрешают блокировать деньги на счетах пользователей?
В классе User вызов функции AddDomainEvent(new UserWasCreated(Id, Email)); // детали реализации скрыты Откуда эта функция, т.е. какой класс хранит ее реализацию, прям сам класс User?
Да, все верно, на ООП можно реализовать смыслы, которые я писал в статье. Но можно и не реализовать (если написать плохо по ООП). Т.е. тут я говорю в одной плоскости, а ООП в параллельной плоскости, одно не исключает другого.
Если прям дотошно придираться к слову "парадигма", то я могу предложить выделить минимальные "свойства" в различных языках программирования, скомбинировать их и написать свой язык программирования со своей уникальной комбинацией этих минимальных "свойств", и тогда это уже будет язык программирования своей парадигмы.
И вот выделение этих "минимальных" свойств (элементарных частиц) (и их комбинация) и есть мое предложение парадигмы.
"Свойство" - это то, что можно русским языком расскзать об объекте/сущности.
Например, когда мы описываем функции, обычно мы говорим: "функция имеет имя". Вот то, что "функция имеет имя" - это и есть "свойство" такого объекта как функция.
Т.е, относитесь к свойствам - как к предложениям на русском языке, которыми можно описать функцию. Вот сколько предложений о функции вы сможете сказать - столько свойств и есть у функции.
А затем начинается экспресиионизм - мы говорим несколько предложений о функции и несколько предложений о json строке. И затем комбинируем эти предложения между собой (1-е предложение описывающее функцию, 2-е предложеие описывающее функцию и 3-е предложение описывающее json строку), и пытамеся создать новый объект, обладающий данной комбинацией предложений.
И если бы мы могли внедрить в свой язык программирования новые ключевые слова или любые новые объекты (функции, трейты, интерфейсы, миксины и все что хотим), то мы бы добавили новое ключевое слово и наш язык программирования стал бы описываться нашей парадигмой (нашей комбинацией предложений на русском языке). И это было бы истинно парадигмой программирования.
Но мы не пишем свой язык программирования, по-этому мы не можем добавить новые ключевые слова или новые "объекты" (функции, трейты, интерфейсы, миксины) в свой язык. По-этому мы используем стандартные, данные в нашем языке программирования сущности, и поверх них создаем "метапрограммирование" - поверх функций, трейтов, интерфейсов, миксинов создаем новую сущность, которую если описывать на русском языке, то она будет описана теми предложенями, которые мы решили объединить.
Например в ООП языке программирования новая сущность будет скорее всего классом, реализующим определенное поведение. Например если мы комбинируем 2 свойства - имеет имя и может выполняться, то у нашего класса будет поле name и будет реализован интерфейс типа Invokable, чтобы наш объект можно было вызвать через obj(); Если захотим добавить совйство "может сериализоваться в простую строку", то реализуем интерфейс Stringable.
Т.е. новая сущность - это класс, имеющий поля и реализующий интерфейсы. А в функциональном языке программирования - набор функций.
И тут мы получаем уже не парадигму программирования, а некий "подход к построению метаобъектов (мета - потому что объект поверх стандартных объектов - функции, класса и т.д.) и из этих объектов состоит наша программа, которая выполняет полезное действие". Не парадигма программирования, но некий подход к программированию.
Это по поводу JSON. Ну 1) малое количество символов: скобки {}, кавычки ", запятая , и вроде все. 2) простая (по сравнению с xml) структура документа, нет аттрибутов, namespace'ов из xml и т.д. 3) маленькое количество типов данных 4) и в целом когда смотришь на JSON обычно сразу понимаешь что там написано.
Вполне возможно это ваше видение ООП и оно совпадает с видением описанной в статье парадигмы.
Разбить выражение на несколько выражений и после каждого проверять таймаут вышел или нет. Таймаут задать в параметрах командной строки.
Спасибо за интересные статьи. А что вы собираете делать дальше? 1) Вы станете евангелистом алгоритм собеседований Российских компаний? Т.е. всегда будете знать актуальные алгоритмические собеседования в Российские компании и публиковать их и разбирать их? 2) Или вы будете вести тренинги по алгоритмам в Российские компании?
Так они всего лишь держатели акций. Т.е. они теперь не могут продать свои акции по хорошей цене, по-этому требуют компенсацию разницы в цене от компании.
10 тыс. подписчиков на Twitch это примерно 100 онлайн зрителей.
Да, согласен надо искать инструменты, которые дают серьезные преимущества, т.е. прорывные инструменты, а не побеждать проблемы.
Статья - инфоповод. Попытка что-то "пережевачить" (от слова жевачка для мозгов) идею - мысль, посмотреть ее с разных сторон еще раз что-то обсудить. Если бы на хабре не минусили, тут были бы такие интересные дискуссии в комментариях.
Статья про то, что - все проблемы PHP можно победить - имея хороший инструмент (стек) и код. Но например у меня опыта в стеке, который победит все проблемы PHP - нету.
Для сравнения Golang и PHP вы взяли дополнительное расширение для PHP - Swoole.
Подскажите, это расширение 100% совместимо с популярными PHP фреймворками, на которых пишут современные веб приложения - Symfony (особенно интересно, т.к. люблю этот фреймворк), Laravel, Yii. Имеется ввиду, что приходится расширять код фреймворков, где расширение кода не предусмотрено, или перегружать функции из стандартной библиотеки PHP, т.е. "черные" хаки.
Спасибо.
Когда я сталкиваюсь с тем, что моя работа не может уложиться в какую-то методологию, и меня спрашивают, смогу ли я селать работу по методологии, я объясняю какую работу я должен сделать (написать код) и спрашиваю менеджера (обычно методолгист - менеджер)
- я рассказал, какую работу я должен сделать, как мастер методологии расскажите мне пожалуйста как мне уложить мою работу в эту методологию?
Я просто перестал считать себя супер профессионалом Скрама (в частности), и что я все понимаю и все в нем знаю. Профессионал Скрама - менеджер, я, как профессионал написания кода пробую найти с ним, как со специалистом в другой области контакт.
У нас особого стейта нету. Пара примеров: количество непрочитанных уведомлений в нотификациях, пара восклицательных знаков в меню на разделах, на которые пользователю надо обратить внимание (документы просрачиваются например, надо загрузить новые).
Эти стейты загружаются отдельными API запросами. Т.е. при переходе на новый фронт полностью перезагружается весь фронт (полное обновление страницы), и делаются API запросы на получение всех необходимых "восклицательных знаков (стейтов), которые надо показать пользователю", и потом пока пользователь ходит по новому фронту стейты не загружаются, потом при переходе на старый фронт снова все загружается через API.
Данные страниц не кешируются. Т.е. если пользователь зашел в таблицу каких-то данных, то при очередном переходе на эту страницу данные загрузятся заново.
Имеем 2 отдельных проекта. Отдельные URL обслуживаются старым проектом, отдельные URL обслуживаются новым проектом. Редиректы сделаны на стороне nginx + kubernetes. Т.е. у нас базовая единица разделения - отдельный URL.
Проблемы следующие: первый шаг очень большой, потому что нужно сделать один и тот же layout в старом и новом фронте, меню, модалки, панели, каркас и т.д.
Сложно мигрировать большие навороченные страницы со сложной логикой. Бывают такие страницы, которые мега навороченные по функционалу. Таких страниц у нас немного, остальные страницы в основном несложные мигрируются просто.
Мы уже год переезжаем на Vue 3. Постранично, постепенно. Зато продуктовые задачи не останавливаем, просто берем по страничке в релиз.
Hidden text
Если вам кажется, что вы понимаете квантовую теорию, значит вы не понимаете квантовую теорию.
Ричард Фейман.
Пользоваться приложениями сможете, а обновления будут приходить еще 1 месяц.
Непонятно почему последующие инстанции всатли на сторону банка, хотя верховный суд привел весьма логичные доказательства правоты пользователя, а адвокат вроде приводит нелогичные доказательства, например:
Получается суды разрешают блокировать деньги на счетах пользователей?
В классе User вызов функции
AddDomainEvent(new UserWasCreated(Id, Email)); // детали реализации скрыты
Откуда эта функция, т.е. какой класс хранит ее реализацию, прям сам класс User?
В Windows есть Shadow Copy, можно посмотреть историю файла. Но надо включать и настраивать. В Mac OS - Time Machine (но может уже убрали).