Посмотрите еще thin, как новую альтернативу монгрелу. На продакшене сами мы еще не пробовали, но по отзывам он обгоняет монгрел везде и основан на стабильных компонентах.
В многопоточных приложения ferret действительно добавляет потенциальные баги. Недавно с этим столкнулся:
На продакшн серверах (разныех) феррет периодически начал отваливаться с такой ошибкой в логе: [FATAL] Segfault без какой-либо конкретики, что наводит на мысль что это где-то в дебрях руби кода происходит.
Со сфинксом работать гораздо менее приятно, особенно если нужно индексировать не БД, а поля сущностей, но то, что феррет нестабилен — это уже общее, устоявшееся мнение
Как реалити-шоу ваша идея конечно любопытна. Но ИМХО вы себе почти уничтожили challenge-элемент. Вашу идею можно сделать с помощью любой CMS-системы за пару дней. И сама концепция уже была ранее, как писал daeq3, отвергнута рынком. Возможно, потому что стартаппер стартапперу — не друг.
На маленьких скринах не видно, если ли эта фича, но:
Когда хитов больше 50 000 в день, было бы полезно иметь не просто сортировку но и средние значения по фильтрованным запросам (т.е. например средний CPU запросов по маске "/index/*"). Обычно ведь нужна как раз такая общая информация, а не по индивидуальным запросам.
Будет здорово, если автор к уже хорошей программе добавит такой функционал.
> Что касается Lead Generation — то не очень понятно, как оценивающие стоимость своей квартиры становятся желающими купить квартиру.
Банально: люди, которые продают свою квартиру, как правило, делают это, чтобы затем купить другую квартиру в той же стране или даже в том же городе.
Примерно прикинуть востребованность такого проекта можно узнав ежегодное количество сделок по купле-продаже non-luxury квартир по России.
Будущее проекта будет сильно зависеть от способности аггрегировать данные пользователей. Чисто на калькуляторе им будет тяжело сформировать хороший продукт.
Кстати, просто сам факт использования этого сайта кем-либо — ценная информация для риэлторов, по которой они смогли бы статистически оценивать количество/качество предложения на рынке в real-time режиме. Я думаю, что команда несомненно думала о том, как монетизировать такую информацию
Очевидно что стратегия МСа по подкупу учителей информатики в школах дала свои плоды :). Пипл обозлился на не-МС-продукты даже не разобравшись что к чему.
Если так дальше пойдет дети будут вырастать с built-in ненавистью к open-souce
AgentSmith, «Собрать все книги бы да сжечь», да? («Горе от ума», А. Грибоедов)
Как я понимаю, камень преткновения в php — функции-сироты внутри пространства имен. В руби или в джаве невозможно держать функцию в пространстве имен без класса (или хотя бы модуля, в руби).
Поэтому Foo::bar() там имеет только один смысл.
Нет времени читать их обсуждение, но они рассматривали возможность отказаться от бесхозных функций в неглобальном пространтстве имен? куча проблем бы отпала.
Для визиток — сильно выигрывает голый пхп. Если говорить о ZF vs Rails, то вряд ли у ZF будет однозначное преимущество: оба фреймворка достаточно массивные и требуют определенной конфигурации перед кик-стартом.
не усмотрел в своих словах такое :) но хочу обратить внимание что я действительно писал: все крупные пхп-проекты достаточно старые, и платформа была отягощена давлением со стороны большого коммьюнити, которое требовало и обратную совместимость и эволюцию одновременно.
на пхп есть серьезные проекты, и, я уверен, они еще долгое время будут оставаться на нем написанными.
Только, если честно, я слабо верю, что яху собирается переходить на 5.3. Их главные странички наверняка сидят на 3. х. В больших компаниях стабильность превыше всего — никто не рискнет должностью чтобы и без того работающий сервис переводить на новую платформу.
Ruby и PHP — могу спорить, т. к. многие пхпшники переходят на руби под давлением паблисити — и их стоимость не сильно меняется (по крайней, мере не доростает до Java)
Насчет стоимости — спорно. Если речь идет о рабочей силе, то из моего опыта: дешевые кодеры = больше времени + больше ошибок + больше претензий от пользователей и/или заказчика = больше затрат в итоге.
А первоклассным программистам на самом деле пофигу на каком языке/фреймворке писать, т. к. все 1) ООП фреймворки похоже 2) все ООП языки похожи 3) выбор платформы зависит от самой задачи.
Никто не сказал что она ущербная сама по себе. Просто *в сравнении* с более новыми языками (хотя на самом деле, исторически, руби более старый — с 93 г.) — пхп-шный подход к ООП выглядит устаревшим. Взять хотя бы рефлекшены PHP-Java-Ruby. Функционал везде почти одинаковый, но удобство использования в пхп явно уступает.
Кстати, по совету посмотрел роудмэп по ПХП 6, разработчики обещают что в Unicode режиме многие string-функции будут на 300% медленнее. Валидно, да? =)))
code.macournoyer.com/thin/
В моем комменте речь идет о squarespace.com
На продакшн серверах (разныех) феррет периодически начал отваливаться с такой ошибкой в логе: [FATAL] Segfault без какой-либо конкретики, что наводит на мысль что это где-то в дебрях руби кода происходит.
Со сфинксом работать гораздо менее приятно, особенно если нужно индексировать не БД, а поля сущностей, но то, что феррет нестабилен — это уже общее, устоявшееся мнение
Когда хитов больше 50 000 в день, было бы полезно иметь не просто сортировку но и средние значения по фильтрованным запросам (т.е. например средний CPU запросов по маске "/index/*"). Обычно ведь нужна как раз такая общая информация, а не по индивидуальным запросам.
Будет здорово, если автор к уже хорошей программе добавит такой функционал.
Банально: люди, которые продают свою квартиру, как правило, делают это, чтобы затем купить другую квартиру в той же стране или даже в том же городе.
Примерно прикинуть востребованность такого проекта можно узнав ежегодное количество сделок по купле-продаже non-luxury квартир по России.
Будущее проекта будет сильно зависеть от способности аггрегировать данные пользователей. Чисто на калькуляторе им будет тяжело сформировать хороший продукт.
Кстати, просто сам факт использования этого сайта кем-либо — ценная информация для риэлторов, по которой они смогли бы статистически оценивать количество/качество предложения на рынке в real-time режиме. Я думаю, что команда несомненно думала о том, как монетизировать такую информацию
Если так дальше пойдет дети будут вырастать с built-in ненавистью к open-souce
AgentSmith, «Собрать все книги бы да сжечь», да? («Горе от ума», А. Грибоедов)
Поэтому Foo::bar() там имеет только один смысл.
Нет времени читать их обсуждение, но они рассматривали возможность отказаться от бесхозных функций в неглобальном пространтстве имен? куча проблем бы отпала.
на пхп есть серьезные проекты, и, я уверен, они еще долгое время будут оставаться на нем написанными.
Только, если честно, я слабо верю, что яху собирается переходить на 5.3. Их главные странички наверняка сидят на 3. х. В больших компаниях стабильность превыше всего — никто не рискнет должностью чтобы и без того работающий сервис переводить на новую платформу.
Ruby и PHP — могу спорить, т. к. многие пхпшники переходят на руби под давлением паблисити — и их стоимость не сильно меняется (по крайней, мере не доростает до Java)
А первоклассным программистам на самом деле пофигу на каком языке/фреймворке писать, т. к. все 1) ООП фреймворки похоже 2) все ООП языки похожи 3) выбор платформы зависит от самой задачи.