Интересно написано. Я начинал серьёзно программировать ещё на asm i8080 (вернее КР580ВМ80А), нравилось байтики и даже битики считать. А потом покатился по С->С++->Perl->PHP с периодическими шарпами-джавами-нодами и т. п… На хлеб с маслом хватает, но часто скучать начал по тем временам. Вот чаще появляться стала мысль в качестве хобби какую-то экзотику изучить, чтоб было интересно. Начал Irdis, но не очень зашло — оторванно как-то от жизни. На rust имеет смысл писать что-то что обычно пишут на PHP/Java/C# веба с основной целью перехода — радоваться циферкам в htop? Или это на порядки больше времени?
Наблюдается. При всём моём скептицизме к облачным сервисам, основанном прежде всего на их ценах, технических возможностей получить такие вычислительные ресурсы на короткий срок чуть ли не милисекундах, таких не было
Рынок в целом появился в конце 80-х, те же любители или программисты в НИИ стали открывать кооперативы и прочие ИТД, но импортный софт шёл по нереальному для простых людей курсу, а на контрафакт все закрывали глаза, включая тех кто с ним типа должен был бороться.
С эластиком интересно: вроде пострадать должны только облачные провайдеры эти, паразиты типа, а тот кто поднимает его для сам — нет. Но есь же третья категория пользователей — клиенты этих провайдеров, которые покупают у них эластик как сервис. В теории вообще могут остаться внезапно без сервиса, когда какие-то "маски-шоу" придут с решением суда в гуглу, амазону и кому там ещё
Бывает же. Первый раз вчера за 8 месяцев работы прилетела задачка оценить разработку почти стороннего для основной системы демо-сайт, даже без технической интеграции любой, чисто брендовость общая. Прочитал ваш комент в 2 часа ночи и до 7 утра экспериментировал со Swoole. Поднял в докере http/ws сервер. чатик в памяти — вроде работает. Впечатление двойственное: давно такое низкоуровневое и, я бы сказал, процедурное чуть ли не PHP3, и без поддержки в IDE нормальной не писал (ide-helper помогает, но не сильно — они сами признают, что он минимальный, но развивать нет ресурсов особо). И документация какая-то специфичная для таких проектов.
А с другой стороны работает, правда нагрузки не делал пока. В любом случае спасибо, что так вовремя "заставили" попробовать.
Мне это нужно, чтобы упростить ежедневную работу, а не усложнить ) Коробочным решением с удовольствием бы пользовался — в гоу понравилось когда его немного пробовал, а что-то костылять плохо стандартизированное… Лучше уж докер-контейнерами доставлять — стандарт де-факто уже можно сказать. Если админы-девопсы есть, то им даже специфика ПХП особо не нужна
линии в буквах в 1 пиксел толщиной с с физической высотой буквы м 2 мм.
Такого никто в здравом смысле не сделает. Я вот за последний час читал Хабр на трёх экранах:
6" телефон (476 ppi) с сантиметров 30
15.6" ноутбук (141 ppi) с сантиметров 50
27" монитор (163 ppi) с сантиметров 80
И вы хотите, чтобы линии в буквах были разной толщины физически (размер пикселя разный), а высоты визуально (расстояние до экрана разное)? Я вообще не уверен, что разгляжу линию на телефоне и букву на мониторе.
Когда из мелкого сервиса оно превращается в большой — возможностей sqlite уже не хватает и народ переезжает на полноценное ПО, которое предоставляет больше возможностей — pgsql/mssql/etc, так?
В мире PHP обычно всё же по умолчанию mysql, за сотни собеседований от трейни до лида второй команды только пару человек вообще пробовали с ним работать.
Так и с остальным, наверное. Раньше apache+modphp стандартом де-факто для самого простого хелловорда были, потом nginx+php-fpm, сейчас — они же в докере (с кмпозом в качестве оркестратор), хорошо если не кубер поднимают для бложика на вордпресе. При этом вопрос масштабирования/отказоустойчивости если и поднимается при выборе этой части инфраструктуры, то только горизонтального и бэкапов. В крайнем случае в уме держат реплику мускула для отчётов и тех же бэкапов.
Думаю, популярность этого связана с простой, если не самих средств, то их разворачивания и минимального конфигурирования путем копипасты нескольких готовых конфигов. Да даже ещё раньше, со времён массовой популярности апачи виртхостингов, где вообще свой софт установить или свой cli php процесс запустить нельзя было. Это всё досатточно простое чтобы стать, скорее всего, самым массовым способом создать работающее веб-приложение. При этом с большим запасом "прочности" когда задачи становятся сложнее. Тепрь туда добавился докер и идёт кубер. И, не дай бог, сделают лямбды на авс нативные )
Swoole (на С написан скорее всего) и ко для тех, кто вырос на LAMP и продолжателях, сложнее по факту. Скорее рассматривается как "вот понадобится масштабироваться, работать асинхронно и т. п. — у нас есть такие варианты в запасе чтоб не переписывать всю кодовую базу на Go/Kotlin"
Лично мне она нужна для удобства инхаус разработки и эксплуатации )Это если говорить именно об исполнимом бинаринике/ Ещё хотелось бы аналог .pyc файлов в python
Типичный (для меня и вообще на просторах мануалов и туториалов) сетап сервера для нескольких пхп приложений (на примере убунту по памяти)
nginx c конфигами для статики и fastcgi_pass в /etc/nginx/sites-enabled/* для каждого приложения
php-fpm c конфигами в /etc/php/7.4/fpm/pool.d/* для каждого приложения со своим портом/файл-сокетом
всё это systemd держит
На докере обычно получается, что приложение — это два контейнера в связке с конфигами для выделенного nginx и php-fpm. Или запихнуты в один плюс, обычно, supervisor. Плюс общесистемный nginx или haproxy (trаefik вроде тоже) как http reverse proxy в качестве чисто http роутера/"ингресса"
Хотелось бы чтобы php приложение было в одном процессе, слушало http, эффективно раздавало статику из публичного каталога приложени, ну и обслуживало динамику. И всё это гибко, очень гибко, настраиваемо на уровне билда или старта контейнера/ Как рабочий функционирующий пример: apache2+libphp или вон в комментах узнал про nGinx Unit.
Нормально один nginx на N php-fpm пулов или даже процессов (разные версии пхп например) на одном сервере под управлением системного systemd. С докером же это не очень нормально получается — выходит 1+N процессов nginx чтоб более-менее удобно деплоить отдельные приложения/сервисы
Я знаю эту философию, поэтому и вопрос вечно этот возникает, каждый раз когда в контейнер пытаешься пхп-фпм положить — в расшаривание файлов между контейнерами много нюансов.
P.S. Облачные сервисы не рассматриваем по ряду причин, кроме как базу для подъёма виртуалок и сетей между ними. И то, обычные хостеры предпочтительней, особенно если АПИ дают по цене обычного ВДС хостинга. А так на текущем проекте обычные дедики
Ну хаскель-код для меня как китайский текст почти ( А экосистема и есть приближенность к жизни.
Они-то как раз может и есть, просто практично подходят — тут на 100 долларов больше платят — быстрее выплачу ипотеку, семье больше достанется и т. п.
Интересно написано. Я начинал серьёзно программировать ещё на asm i8080 (вернее КР580ВМ80А), нравилось байтики и даже битики считать. А потом покатился по С->С++->Perl->PHP с периодическими шарпами-джавами-нодами и т. п… На хлеб с маслом хватает, но часто скучать начал по тем временам. Вот чаще появляться стала мысль в качестве хобби какую-то экзотику изучить, чтоб было интересно. Начал Irdis, но не очень зашло — оторванно как-то от жизни. На rust имеет смысл писать что-то что обычно пишут на PHP/Java/C# веба с основной целью перехода — радоваться циферкам в htop? Или это на порядки больше времени?
Наблюдается. При всём моём скептицизме к облачным сервисам, основанном прежде всего на их ценах, технических возможностей получить такие вычислительные ресурсы на короткий срок чуть ли не милисекундах, таких не было
Рынок в целом появился в конце 80-х, те же любители или программисты в НИИ стали открывать кооперативы и прочие ИТД, но импортный софт шёл по нереальному для простых людей курсу, а на контрафакт все закрывали глаза, включая тех кто с ним типа должен был бороться.
С эластиком интересно: вроде пострадать должны только облачные провайдеры эти, паразиты типа, а тот кто поднимает его для сам — нет. Но есь же третья категория пользователей — клиенты этих провайдеров, которые покупают у них эластик как сервис. В теории вообще могут остаться внезапно без сервиса, когда какие-то "маски-шоу" придут с решением суда в гуглу, амазону и кому там ещё
Бывает же. Первый раз вчера за 8 месяцев работы прилетела задачка оценить разработку почти стороннего для основной системы демо-сайт, даже без технической интеграции любой, чисто брендовость общая. Прочитал ваш комент в 2 часа ночи и до 7 утра экспериментировал со Swoole. Поднял в докере http/ws сервер. чатик в памяти — вроде работает. Впечатление двойственное: давно такое низкоуровневое и, я бы сказал, процедурное чуть ли не PHP3, и без поддержки в IDE нормальной не писал (ide-helper помогает, но не сильно — они сами признают, что он минимальный, но развивать нет ресурсов особо). И документация какая-то специфичная для таких проектов.
А с другой стороны работает, правда нагрузки не делал пока. В любом случае спасибо, что так вовремя "заставили" попробовать.
Мне это нужно, чтобы упростить ежедневную работу, а не усложнить ) Коробочным решением с удовольствием бы пользовался — в гоу понравилось когда его немного пробовал, а что-то костылять плохо стандартизированное… Лучше уж докер-контейнерами доставлять — стандарт де-факто уже можно сказать. Если админы-девопсы есть, то им даже специфика ПХП особо не нужна
Такого никто в здравом смысле не сделает. Я вот за последний час читал Хабр на трёх экранах:
И вы хотите, чтобы линии в буквах были разной толщины физически (размер пикселя разный), а высоты визуально (расстояние до экрана разное)? Я вообще не уверен, что разгляжу линию на телефоне и букву на мониторе.
Неа. Он содержит только php код. Если бы ещё, например, расширения вкладывались то частично бы подошёл
Диаграммами могут некоторые...
В мире PHP обычно всё же по умолчанию mysql, за сотни собеседований от трейни до лида второй команды только пару человек вообще пробовали с ним работать.
Так и с остальным, наверное. Раньше apache+modphp стандартом де-факто для самого простого хелловорда были, потом nginx+php-fpm, сейчас — они же в докере (с кмпозом в качестве оркестратор), хорошо если не кубер поднимают для бложика на вордпресе. При этом вопрос масштабирования/отказоустойчивости если и поднимается при выборе этой части инфраструктуры, то только горизонтального и бэкапов. В крайнем случае в уме держат реплику мускула для отчётов и тех же бэкапов.
Думаю, популярность этого связана с простой, если не самих средств, то их разворачивания и минимального конфигурирования путем копипасты нескольких готовых конфигов. Да даже ещё раньше, со времён массовой популярности апачи виртхостингов, где вообще свой софт установить или свой cli php процесс запустить нельзя было. Это всё досатточно простое чтобы стать, скорее всего, самым массовым способом создать работающее веб-приложение. При этом с большим запасом "прочности" когда задачи становятся сложнее. Тепрь туда добавился докер и идёт кубер. И, не дай бог, сделают лямбды на авс нативные )
Swoole (на С написан скорее всего) и ко для тех, кто вырос на LAMP и продолжателях, сложнее по факту. Скорее рассматривается как "вот понадобится масштабироваться, работать асинхронно и т. п. — у нас есть такие варианты в запасе чтоб не переписывать всю кодовую базу на Go/Kotlin"
P.S. плюсиков добавил — интересный диалог
Лично мне она нужна для удобства инхаус разработки и эксплуатации )Это если говорить именно об исполнимом бинаринике/ Ещё хотелось бы аналог .pyc файлов в python
Типичный (для меня и вообще на просторах мануалов и туториалов) сетап сервера для нескольких пхп приложений (на примере убунту по памяти)
На докере обычно получается, что приложение — это два контейнера в связке с конфигами для выделенного nginx и php-fpm. Или запихнуты в один плюс, обычно, supervisor. Плюс общесистемный nginx или haproxy (trаefik вроде тоже) как http reverse proxy в качестве чисто http роутера/"ингресса"
Хотелось бы чтобы php приложение было в одном процессе, слушало http, эффективно раздавало статику из публичного каталога приложени, ну и обслуживало динамику. И всё это гибко, очень гибко, настраиваемо на уровне билда или старта контейнера/ Как рабочий функционирующий пример: apache2+libphp или вон в комментах узнал про nGinx Unit.
Так понятнее? )
Выглядит очень интересно. А то уже думал может апачем пхп запускать для одного процессаю Спасибо за наводку. В проде пробовали?
Нормально один nginx на N php-fpm пулов или даже процессов (разные версии пхп например) на одном сервере под управлением системного systemd. С докером же это не очень нормально получается — выходит 1+N процессов nginx чтоб более-менее удобно деплоить отдельные приложения/сервисы
тут надо разделять просто упаковку в бинарник как замену
php program.pharилиphp -Sи всякие извращения с GUI типа завернутого хромиумаМотивация создания бинарников не понята, наверное. А потому ответ может быть не на ТОТ вопрос.
Я знаю эту философию, поэтому и вопрос вечно этот возникает, каждый раз когда в контейнер пытаешься пхп-фпм положить — в расшаривание файлов между контейнерами много нюансов.
P.S. Облачные сервисы не рассматриваем по ряду причин, кроме как базу для подъёма виртуалок и сетей между ними. И то, обычные хостеры предпочтительней, особенно если АПИ дают по цене обычного ВДС хостинга. А так на текущем проекте обычные дедики
По памяти он именно "вроде", просто биндинги