> Включая установку правильной версии libssl на хосте?
Подождите, но libssl — это внешняя относительно PHP сущность. Критика как бы не совсем по адресу.
>Но ладно, composer. Вот, скажите, как у нас с composer сочетается установка нескольких известных php-приложений, допустим: mediawiki, wordpress, phpbb. Они composer'ом устанавливаются в систему?
Почему бы и нет? К примеру:
https://www.mediawiki.org/wiki/Composer/ru
Смотрите, вы накидываете примеры из совершенно разных уровней управления.
Если вам нужно одноразово приложение — установите его файлами.
Если нужно поддерживать приложение up-to-date со всеми его внутренними зависимостями — используйте composer.
Если хочется также возможности фиксации внешних зависимостей — соберите образ или используйте docker.
Если нужна оркестрация всего этого счастья — используйте менеджер оркестрации.
Поймите, если чего-то «из коробки» нету в apt — это не значит, что нет красивого способа этим управлять ;)
>Как человек со стороны, я могу сказать, что существующие экосистемы PHP очень плохо интегрируются в взрослые (читай, не «shared hosting») системы. Мало библиотек, плохо проработанные практики для Ci/CD.
Кстати, если в магазине предусмотрены фильтрации по нескольким типам признаков я бы сразу порекомендовал обратить внимание на фасеты в Elastic — просто отличная штука!
Есть огромное количество примеров, как проекты посервисно, помодульно можно переводить на новые рельсы.
Это делается довольно просто, если только (не дай бог) данные не привязаны к логике приложения.
… в относительно новом продукте.
Поймите, я рассуждаю даже не с точки зрения программиста в стиле «Язык X — rulezz, язык Z — suxxx», а с точки зрения владельца технологического процесса.
Какой смысл мне (как техническому директору) начинать проект на языке, у которого нет вменяемых преимуществ перед аналогичными языками, но при этом количество разработчиков на нем — ниже на порядок, а то и на два порядка?
Причем, с учетом данного поста — про потенциальное качество тоже можно поспорить.
Автор пишет:
… большинство стартапов изначально сделаны на коленке. Только потом, в случае удачного выстреливания, при грамотном руководстве и понимании стратегических целей владельцы ресурса могут принять решение о рефакторинге существующего продукта.
Да, рефакторинг обычно требуется, но не такой! Чаще всего возникает ситуация, когда от монолита нужна перейти к сервисам, или реализовать возможности работы с репликами, если с начала про это забыли… но, простите, забыть про MVC даже для стартапа, даже «на коленке» — это уже слишком.
Я не буду спорить, что из коробки все это действительно взлетает, но есть большое НО: если требуется что-то немножко изменить в функциональности — начинаются пляски с бубном.
Я — разработчик с большим стажем, мне довелось поработать с большинством современных фреймворков и ORM, с Битриксом пришлось познакомится относительно недавно в рамках выполнения одной интеграционной задачи.
Что бы хотелось отметить особо:
— Жуткое месиво вместо структуры. Парадигма MVC не соблюдается абсолютно: в одном и том же файле на несколько тысяч строк идет объявление функций, классов, SQL-запросы, вывод HTML, XML, обработка бизнес-логики, а также всякие аспектные штуки вроде логирования и проверки прав. Естественно, что модификация и поддержка такого кода — реальный ад.
— Общая организация кода. Да, все мы знаем, что такое legacy, и как с ним порой трудно жить, но регулярные рефакторинги способны изменить ситуацию к лучшему.
— ООП. Больше всего меня поразило масштабное использование классов, как хранилищ статических методов. Это для того, чтобы гордо заявлять, что Битрикс — ООПшный? Соответственно, про использование паттернов (даже не GoF, а простых GRASP) речь не идёт.
Но на самом деле я благодарен Битриксу за то, что я четко стал понимать, что продажи программного продукта зависят на 98% от маркетинга и sales forces и на 2% — от собственно кода. Ради этого с ним стоило поработать :)
Вы на какую роль претендуете в данном проекте? Кодера или руководителя? Если руководителя — то вас должны интересовать бизнес-план и то, что в RUP называется Vision — видение проекта.
Грубо говоря, основные вопросы инвестора будут про:
1) Целевую аудиторию (с нормальным исследованием)
2) Какие потребности вы решаете своим продуктом
3) Risk Management
4) План разработки и развития (хотя бы драфт)
В общем, посмотрите первую из 4х фаз в RUP (http://ru.wikipedia.org/wiki/RUP)
От вас будут искать менеджерских качеств, а не умения собрать сервер на коленке ;)
Если это женский портал, да еще и с социальной компонентой — 95% бабла уйдут не на копеечный сервер, а на контент + дизайн + модерацию.
«Распределенный кластер серверов» — это вообще феерический… мммм… шедевр. Кто мешает виртуально разнести сервисы по одному серверу? Зачем для этого куча старого хлама? Основной смысл масштабирования — не связать коробки проводами, а построить такую архитектуру кода, структуры данных и подобрать такие сервисы, чтобы в идеале при вставке нового сервера в стойку не приходилось делать 1000 телодвижений.
К тому же маштабирование на картинке в пэйнте со стрелочками — это еще круче. Инвестор — дядя неглупый, он скорее всего придет со сторонним специалистом, который будет спрашивать не про то, как на двух пнях поднять сервак!
Подождите, но libssl — это внешняя относительно PHP сущность. Критика как бы не совсем по адресу.
>Но ладно, composer. Вот, скажите, как у нас с composer сочетается установка нескольких известных php-приложений, допустим: mediawiki, wordpress, phpbb. Они composer'ом устанавливаются в систему?
Почему бы и нет? К примеру:
https://www.mediawiki.org/wiki/Composer/ru
Смотрите, вы накидываете примеры из совершенно разных уровней управления.
Если вам нужно одноразово приложение — установите его файлами.
Если нужно поддерживать приложение up-to-date со всеми его внутренними зависимостями — используйте composer.
Если хочется также возможности фиксации внешних зависимостей — соберите образ или используйте docker.
Если нужна оркестрация всего этого счастья — используйте менеджер оркестрации.
Поймите, если чего-то «из коробки» нету в apt — это не значит, что нет красивого способа этим управлять ;)
Што. Какое отношение ЯП имеет к CI/CD?
No offense ;)
Это делается довольно просто, если только (не дай бог) данные не привязаны к логике приложения.
Поймите, я рассуждаю даже не с точки зрения программиста в стиле «Язык X — rulezz, язык Z — suxxx», а с точки зрения владельца технологического процесса.
Какой смысл мне (как техническому директору) начинать проект на языке, у которого нет вменяемых преимуществ перед аналогичными языками, но при этом количество разработчиков на нем — ниже на порядок, а то и на два порядка?
Причем, с учетом данного поста — про потенциальное качество тоже можно поспорить.
Автор пишет:
Да, рефакторинг обычно требуется, но не такой! Чаще всего возникает ситуация, когда от монолита нужна перейти к сервисам, или реализовать возможности работы с репликами, если с начала про это забыли… но, простите, забыть про MVC даже для стартапа, даже «на коленке» — это уже слишком.
Ко второму проекту уже можно будет освоить использование нормальных фреймворков, где MVC жестко разделено по дефолту.
Зато я узнал, что на ASP еще кто-то пишет.
PS: Но инфографика (особенно вторая) чуть не заставила меня вытащить экранную лупу.
Я — разработчик с большим стажем, мне довелось поработать с большинством современных фреймворков и ORM, с Битриксом пришлось познакомится относительно недавно в рамках выполнения одной интеграционной задачи.
Что бы хотелось отметить особо:
— Жуткое месиво вместо структуры. Парадигма MVC не соблюдается абсолютно: в одном и том же файле на несколько тысяч строк идет объявление функций, классов, SQL-запросы, вывод HTML, XML, обработка бизнес-логики, а также всякие аспектные штуки вроде логирования и проверки прав. Естественно, что модификация и поддержка такого кода — реальный ад.
— Общая организация кода. Да, все мы знаем, что такое legacy, и как с ним порой трудно жить, но регулярные рефакторинги способны изменить ситуацию к лучшему.
— ООП. Больше всего меня поразило масштабное использование классов, как хранилищ статических методов. Это для того, чтобы гордо заявлять, что Битрикс — ООПшный? Соответственно, про использование паттернов (даже не GoF, а простых GRASP) речь не идёт.
Но на самом деле я благодарен Битриксу за то, что я четко стал понимать, что продажи программного продукта зависят на 98% от маркетинга и sales forces и на 2% — от собственно кода. Ради этого с ним стоило поработать :)
Грубо говоря, основные вопросы инвестора будут про:
1) Целевую аудиторию (с нормальным исследованием)
2) Какие потребности вы решаете своим продуктом
3) Risk Management
4) План разработки и развития (хотя бы драфт)
В общем, посмотрите первую из 4х фаз в RUP (http://ru.wikipedia.org/wiki/RUP)
От вас будут искать менеджерских качеств, а не умения собрать сервер на коленке ;)
Если это женский портал, да еще и с социальной компонентой — 95% бабла уйдут не на копеечный сервер, а на контент + дизайн + модерацию.
«Распределенный кластер серверов» — это вообще феерический… мммм… шедевр. Кто мешает виртуально разнести сервисы по одному серверу? Зачем для этого куча старого хлама? Основной смысл масштабирования — не связать коробки проводами, а построить такую архитектуру кода, структуры данных и подобрать такие сервисы, чтобы в идеале при вставке нового сервера в стойку не приходилось делать 1000 телодвижений.
К тому же маштабирование на картинке в пэйнте со стрелочками — это еще круче. Инвестор — дядя неглупый, он скорее всего придет со сторонним специалистом, который будет спрашивать не про то, как на двух пнях поднять сервак!
Простите, а сколько человек живет в НН?
А фраза — по-моему, из какого-то затертого анекдота, мне она нравится :)
Просто среди тех, кто работал по специальности этот шанс выше :)