Мне кажется не стоит начинать, во всяком случае из-за денег. Реально, вряд ли можно догнать майнстрим, а если его не догнать о деньгах лучше забыть в этом деле. Можно конечно же для удовольствия (for fun) так сказать, а там глядишь попрет и можно будет уже подумать и о деньгах.
Мне самому за сорок, многие друзья кто со мной начинал программировать 20-25 лет назад просто уже «выпали из обоймы», нет ну сидят конечно где-то на Дельфи, а то и на Клипере. Но там зп уже не доставляют.
Так что вывод: Если основная цель деньги — забудьте об этом, если нет — удачи!
Правда, мне тоже кажется, что в продакшне такому коду не место.
Основное требование к продакшен коду, что бы когда вы уйдете на повышение или покинете компанию, другой человек разобрался бы с кодом в кратчайшие сроки и мог делать правки. А с кодом на этом языке, никто разбираться не будет, и я думаю даже пробовать не будут.
Статья обстоятельная и даже интересная, но по прочтению возникает вопрос: «А зачем?» Ведь кроме перла есть еще масса языков на которых можно писать врайтонли код)
Забавно, не замечал в последнее время проявления комплексов «большой брат», всем уже лет пять-десять как пофиг на это. А вот комплекс «младшего брата» у вас на лицо, извините.
А я кажется нашел компромисс между «громоздкостью» С/С++, «тормозами» Python и «дзен-буддизмом» Erlang для решения подобных задач. Это язык D, на второй день чтения книги Александреску у меня получилось на нем сделать асинхронный TCP эхосервер на libev, а на четвёртый выделить его в модуль и «свернуть колбеки» с помощью фидеров. В итоге получилось что-то типа:
void echo_handler(Stream stream)
{
stream.timeout = 5;
while (stream.active)
{
try
stream.write(stream.read());
catch (Stream.TimeoutException e) {
stream.close();
writeln("Connection closed by timeout.");
} catch (Stream.ClosedException e) {
writeln("Connection closed.");
}
}
}
auto loop = new Loop();
auto listener = new TCPListener(loop, &echo_handler);
Ну так если у вас все остальное на PHP, то зачем сразу усложнять задачу.
Примерно так же сказал мой коллега в начале одного проекта (который на тот момент действительно был только на PHP) и сделал парсер входящих по сокету данных на PHP. Да получилось, но он падал с разной периодичностью из-за меморилик, забирая с собой все что крутилось на том же сервере :)
Код был написан вполне себе хорошо, ревью делали все программисты группы, но ничего подозрительного с точки зрения PHP не находили. Вывод был печальный, утечка была при непонятых стечениях обстоятельств в С коде функций сокетов или ХМЛ парсера. Проблема решилась только с помощью Pythonа.
Так что, если в проекте реально понадобилась что-то типа асинхронной обработки запросов, а все программисты в группе исключительно пэхапешники, то у вас проблемы.
… даже на заточенном немного на другие задачи PHP написать аналогичный сервер — совсем просто
Но после этого возник: «А зачем? А зачем это делать на PHP» :) Не спешите минусовать, я свой, тоже кое что могу на PHP :) Но зачем делать такое на PHP? Этот язык не был заточен с самого начала на работу отличную от «обработать запрос, отдать ответ». Зачем делать на нем демонов и async networking? Что бы отгрести проблем?
Если статья чисто академического плана, то нет вопросов. А если это руководство к действию, то… :)
Ни в коем случае :) к тому же я не апологет майсиквела. Просто хочется получить инфу из первух рук мигрировавших. Из того что я знаю, так это только то что ждать повышения производительности не стоит (во всяком случае не затачиваясь на фишки постгреса). И как факт, перевод типичного, среднего веб приложение ничего не дает, кроме лишней мороки.
Но фишки у него интересные, аналогов некоторым (ex. postgis) фактически нет. Но многие не production-ready, во всяком случае их никто в этой связи еще не пробовал (ex. hstore) и нет историй успеха. Фишки NoSQL в классических SQL БД, честно говоря настораживают. MySQL в этом плане тоже кстати не отстает :). Тут непонятно только одно, что получат первые запилившие это в продакшен, головняк или плюшки :).
Жаль что вы только в начале процесса миграции.
Если есть уже прошедшие этот путь пожалуйста отпишитесь.
А что послужило причиной потребности перенести базу на с mysql на postgresql? Плохая производительность, отсутствие фич, другое? И оправдались ли ожидания от такого перехода?
Просто это частый предмет спора — mysql vs postgresql, и было бы интересно узнать такие подробности от тех, кто это уже прошел.
Тему статьи можно переформулировать так «Одна из причин почему в проекте надо использовать популярный|проверенный фреймворк». При использовании фреймворка, согласен на первом этапе может быть некоторый оверворк, но когда реально встанет вопрос с проблемами расширения|масштабирования, уже будет понятно есть ли на это деньги и мотивация.)
Мне самому за сорок, многие друзья кто со мной начинал программировать 20-25 лет назад просто уже «выпали из обоймы», нет ну сидят конечно где-то на Дельфи, а то и на Клипере. Но там зп уже не доставляют.
Так что вывод: Если основная цель деньги — забудьте об этом, если нет — удачи!
Основное требование к продакшен коду, что бы когда вы уйдете на повышение или покинете компанию, другой человек разобрался бы с кодом в кратчайшие сроки и мог делать правки. А с кодом на этом языке, никто разбираться не будет, и я думаю даже пробовать не будут.
Примерно так же сказал мой коллега в начале одного проекта (который на тот момент действительно был только на PHP) и сделал парсер входящих по сокету данных на PHP. Да получилось, но он падал с разной периодичностью из-за меморилик, забирая с собой все что крутилось на том же сервере :)
Код был написан вполне себе хорошо, ревью делали все программисты группы, но ничего подозрительного с точки зрения PHP не находили. Вывод был печальный, утечка была при непонятых стечениях обстоятельств в С коде функций сокетов или ХМЛ парсера. Проблема решилась только с помощью Pythonа.
Так что, если в проекте реально понадобилась что-то типа асинхронной обработки запросов, а все программисты в группе исключительно пэхапешники, то у вас проблемы.
Если статья чисто академического плана, то нет вопросов. А если это руководство к действию, то… :)
Ни в коем случае :) к тому же я не апологет майсиквела. Просто хочется получить инфу из первух рук мигрировавших. Из того что я знаю, так это только то что ждать повышения производительности не стоит (во всяком случае не затачиваясь на фишки постгреса). И как факт, перевод типичного, среднего веб приложение ничего не дает, кроме лишней мороки.
Но фишки у него интересные, аналогов некоторым (ex. postgis) фактически нет. Но многие не production-ready, во всяком случае их никто в этой связи еще не пробовал (ex. hstore) и нет историй успеха. Фишки NoSQL в классических SQL БД, честно говоря настораживают. MySQL в этом плане тоже кстати не отстает :). Тут непонятно только одно, что получат первые запилившие это в продакшен, головняк или плюшки :).
Жаль что вы только в начале процесса миграции.
Если есть уже прошедшие этот путь пожалуйста отпишитесь.
Просто это частый предмет спора — mysql vs postgresql, и было бы интересно узнать такие подробности от тех, кто это уже прошел.