PHP 6 был изначально обречен. Как только появилась идея разделить строки на "строковые" и "бинарные", стало понятно, что это путь в никуда. Обеспечить обратную совместимость было бы невозможно, совместимость двух этих типов - еще более нереально.
Я считаю, что отказ от PHP 6 и закрепление понятия строки, как "последовательности байт" с передачей ответственности по интерпретации этих строк на конкретные библиотеки - это был шаг, который спас PHP от неминуемого конца.
Так что тут не "не осилили", а наоборот "нашли в себе смелость отказаться от заведомого бреда"
Так а что тут скрывать и зачем? BBB - прекрасный проект, я только рад буду, если у него будет больше пользователей и наши скромные несколько коммитов улучшат его.
Как автор https://meethub.ru (решение, превращающее BigBlueButton в "веб-коммуникатор") не могу не упомянуть о нем.
Мы взяли отличный Open Source продукт, немного его подпилили под себя, написали для него управляющее приложение и в данный момент приглашаем пользоваться в облаке бесплатно. И можно даже попробовать без регистрации. При установке на свои сервера - поможем за деньги, но весьма и весьма символические.
И меня лично весьма и весьма задевает утверждение автора статьи: "из-за использования открытого исходного кода у продукта может быть плохая масштабируемость, мало пользователей, сбои в работе и отсутствие постоянной технической поддержки". Что это за бред? Откуда такие выводы Вы серьезно считаете, что тот же jitsi плохо масштабируется? Ну, видимо, зря его Яндекс выбирал в своё время ))
P.S. Сразу отвечу на незаданный вопрос - да, все наработки по самому BBB отдадим сообществу. Как только перестанет быть стыдно за код, так сразу будут оформлены мерж-реквесты.
Разумеется, во всех случаях, когда реально требовалась работа двух приложений - я всегда делал буквально два приложения в двух изолированных контейнерах и роутинг между ними возлагал на третье приложение - роутер (к примеру на nginx и карту URL внутри него). Но ваш велосипед тоже интересен.
Я лично думаю, что тенденция вообще идет в сторону отказа от JS, как от языка программирования, предназначенного для людей.
Так уж повелось, что код на JS исполняется браузерами. Быстро и хорошо исполняется. Отлично. Эта ситуация останется еще на десятки лет доминирующей.
Но заставлять живых людей писать на JS и даже придумывать целые "фреймворки" (не являющиеся таковыми) для этого?
Нет, это не магистраль. Магистраль - это судьба JS, как языка промежуточного представления кода. Как нового ассемблера.
Посмотрите, к примеру, на Symfony Live Components, библиотеку, позволяющую бэкенд-разработчику создавать сложные и "живые" интерфейсы, не написав ни строчки кода на JS вручную.
Это - и есть следующий магистральный путь. Кода мы берем настоящий язык программирования, с настоящей системой типов, пишем на нем, а уж во что оно там транслируется - стараемся не задумываться.
Между прочим, так примерно и развивается IT последние лет 50. Ничего нового.
Как же тонко и аккуратно вы обходите момент, что PHP - прекрасный язык общего назначения, занимающий порядка 90% рынка веб-разработки (один человек это сказал, да), востребованный везде и всеми и что специалистов (настоящих) по PHP ждут везде и за любые деньги.
Это же просто переводы? Без каких-либо гарантий и обязательств?
Если это платежи - где авторизация, холд и собственно списание? Где возможность опротестовать платеж, да и вообще, хоть как-то пообщаться с платежной системой?
Поставил вам минус за низкий технический уровень материала, и готов объяснить, почему.
Стоило упомянуть, что для реализации DTO чаще всего используется паттерн Value Object и указать на разницу между этими двумя понятиями.
Неплохо бы объъяснить разницу между Value Object и Entity.
Стоило рассказать, что DTO по определению является иммутабельным объектом. А из этот следует применение модификатора readonly в свойствах и/или в классе.
Не упомянут тайп-хинтинг свойств - почему?
Если мы уж говорим о валидации, то стоит акцентировать внимание на том, что Value Object (и DTO, как подкласс) не могут находиться в невалидном состоянии, иначе это нарушает смысл паттерна.
Валидация может быть как при создании объекта (в конструкторе), так и условно "внешняя"
Второй вариант валидации - более гибкий. Он позволяет задать с помощью метаданных правила и сценарии валидации.
Метаданные в современном PHP задаются через атрибуты. Нужно было бы показать пример, например из Symfony.
Для преобразования в JSON в стандартной библиотеке PHP есть интерфейс. Почему его не использовали?
Я бы посоветовал вам взять примеры сериализации таких объектов опять же из Symfony. И рассказать про метаданные, две стадии сериализации (преобразование в массив, а затем в нужный формат) и про десериализацию.
PHP 6 был изначально обречен. Как только появилась идея разделить строки на "строковые" и "бинарные", стало понятно, что это путь в никуда. Обеспечить обратную совместимость было бы невозможно, совместимость двух этих типов - еще более нереально.
Я считаю, что отказ от PHP 6 и закрепление понятия строки, как "последовательности байт" с передачей ответственности по интерпретации этих строк на конкретные библиотеки - это был шаг, который спас PHP от неминуемого конца.
Так что тут не "не осилили", а наоборот "нашли в себе смелость отказаться от заведомого бреда"
Ну, честно говоря, самоподписанные сертификаты - это источник головной боли практически в любой ситуации внедрения любого софта.
Так а что тут скрывать и зачем? BBB - прекрасный проект, я только рад буду, если у него будет больше пользователей и наши скромные несколько коммитов улучшат его.
Как опираться? Да так и опираться - данные шарить между приложениями. База-то одна остается.
Обсуждение не то, что давно идет. У меня ощущение, что оно уже закончено и решение принято.
Там есть форма обратной связи. Ну или в личку пишите.
Назначили козла отпущения, на которого потом свалят принятие решение об уходе с Байконура.
Как автор https://meethub.ru (решение, превращающее BigBlueButton в "веб-коммуникатор") не могу не упомянуть о нем.
Мы взяли отличный Open Source продукт, немного его подпилили под себя, написали для него управляющее приложение и в данный момент приглашаем пользоваться в облаке бесплатно. И можно даже попробовать без регистрации. При установке на свои сервера - поможем за деньги, но весьма и весьма символические.
И меня лично весьма и весьма задевает утверждение автора статьи: "из-за использования открытого исходного кода у продукта может быть плохая масштабируемость, мало пользователей, сбои в работе и отсутствие постоянной технической поддержки". Что это за бред? Откуда такие выводы Вы серьезно считаете, что тот же jitsi плохо масштабируется? Ну, видимо, зря его Яндекс выбирал в своё время ))
P.S. Сразу отвечу на незаданный вопрос - да, все наработки по самому BBB отдадим сообществу. Как только перестанет быть стыдно за код, так сразу будут оформлены мерж-реквесты.
Весьма неплохо.
Разумеется, во всех случаях, когда реально требовалась работа двух приложений - я всегда делал буквально два приложения в двух изолированных контейнерах и роутинг между ними возлагал на третье приложение - роутер (к примеру на nginx и карту URL внутри него). Но ваш велосипед тоже интересен.
>> А что вы думаете об этой тенденции?
Я лично думаю, что тенденция вообще идет в сторону отказа от JS, как от языка программирования, предназначенного для людей.
Так уж повелось, что код на JS исполняется браузерами. Быстро и хорошо исполняется. Отлично. Эта ситуация останется еще на десятки лет доминирующей.
Но заставлять живых людей писать на JS и даже придумывать целые "фреймворки" (не являющиеся таковыми) для этого?
Нет, это не магистраль. Магистраль - это судьба JS, как языка промежуточного представления кода. Как нового ассемблера.
Посмотрите, к примеру, на Symfony Live Components, библиотеку, позволяющую бэкенд-разработчику создавать сложные и "живые" интерфейсы, не написав ни строчки кода на JS вручную.
Это - и есть следующий магистральный путь. Кода мы берем настоящий язык программирования, с настоящей системой типов, пишем на нем, а уж во что оно там транслируется - стараемся не задумываться.
Между прочим, так примерно и развивается IT последние лет 50. Ничего нового.
Придумайте уже себе вменяемый пакетный менеджер, как в других языках и экосистемах. Можно даже скопировать ))
Чем хорош PHP - на нем можно писать в таком стиле, за который уже 15 лет назад руки отрывали, а оно всё равно работает ))
Как же тонко и аккуратно вы обходите момент, что PHP - прекрасный язык общего назначения, занимающий порядка 90% рынка веб-разработки (один человек это сказал, да), востребованный везде и всеми и что специалистов (настоящих) по PHP ждут везде и за любые деньги.
Зато не забыли мертвый Руби упомянуть.
Что за комплексы у вас?
Если вы видите, что студент или выпускник использует MongoDB, то остановите его. Ему нужна помощь. Его ввели в заблуждение.Пожалуйста, ставьте плюсы статье и автору только за эту цитату, я вас прошу. Господи, наконец-то на хабре правда!
А где статья?
Но... это же не платежи, верно?
Это же просто переводы? Без каких-либо гарантий и обязательств?
Если это платежи - где авторизация, холд и собственно списание? Где возможность опротестовать платеж, да и вообще, хоть как-то пообщаться с платежной системой?
У этого - нет бесплатной. Многие по прошествии времени выкладываются бесплатно.
Даже "улучшив" публикацию, вы всё равно несете в ней какой-то малосвязный бред.
Поставил вам минус за низкий технический уровень материала, и готов объяснить, почему.
Стоило упомянуть, что для реализации DTO чаще всего используется паттерн Value Object и указать на разницу между этими двумя понятиями.
Неплохо бы объъяснить разницу между Value Object и Entity.
Стоило рассказать, что DTO по определению является иммутабельным объектом. А из этот следует применение модификатора readonly в свойствах и/или в классе.
Не упомянут тайп-хинтинг свойств - почему?
Если мы уж говорим о валидации, то стоит акцентировать внимание на том, что Value Object (и DTO, как подкласс) не могут находиться в невалидном состоянии, иначе это нарушает смысл паттерна.
Валидация может быть как при создании объекта (в конструкторе), так и условно "внешняя"
Второй вариант валидации - более гибкий. Он позволяет задать с помощью метаданных правила и сценарии валидации.
Метаданные в современном PHP задаются через атрибуты. Нужно было бы показать пример, например из Symfony.
Для преобразования в JSON в стандартной библиотеке PHP есть интерфейс. Почему его не использовали?
Я бы посоветовал вам взять примеры сериализации таких объектов опять же из Symfony. И рассказать про метаданные, две стадии сериализации (преобразование в массив, а затем в нужный формат) и про десериализацию.
и это только навскидку...
Спасибо.