а вы всё на суп

[juan_gandhi]

Sorry, something went wrong.

We're working on getting this fixed as soon as we can.

Go Back

Facebook © 2012 · Help

(и календарик прошлогодний)

А потому что скрипт-киддиз одни собрались, нет чтобы хаскельщиков нанять - но хаскельщиков они боятся!

Comments

[justy-tylor.livejournal.com]

Нет. У фейсбука ведь как: был гадюшник, стал highload-гадюшник. Качество работы сервиса не является ключевой составляющей их бизнеса. Иначе обезьян пришлось бы глобально заменять на специалистов, которые, как правило, выбирают более сильные технологии, а уж на скальщиков или "хаскелистов пишущих на C++" - без разницы. HipHop, в свою очередь, обычное снижение затрат на машинное время.

[dennisgorelik]

1) Я правильно понимаю вашу точку зрения, что в Фэйсбуке использование PHP залатанным HipHop-ом - вполне допустимо, но в большинстве проектов лучше всё же сразу же делать упор на высококвалифицированных специалистов и использовать соответствующие технологии?

2) Можете привести пример, как использование PHP снижает качество работы сервиса (в сравнении с использованием Scala/C++)?

3) Вот здесь пишут, что:
---
At the front end, their servers run a LAMP (Linux, Apache, MySQL, and PHP) stack with Memcache.
...
Facebook’s backend services are written in a variety of different programming languages including C++, Java, Python, and Erlang.
---
Из моего опыта работы над веб сайтом, большая часть кода пишется всё-таки на backend. Особенно по мере взросления веб сайта.
То есть PHP - скорее всего не основной язык программирования в Фэйсбуке.

[justy-tylor.livejournal.com]

1. Зависит от желаемого результата.

2. У специалистов есть выбор из многих языков и технологий. Более удобных в работе или более доходных по предложениям на рынке труда. На PHP застревают худшие. Именно это снижает качество работы сервиса.

3. Пользовательские характеристики, такие как воспринимаемая скорость и корректность работы UI, это фронтенд.

[dennisgorelik]

2) То есть если заменить трёх $100K/year программистов на PHP на двух $150K/year программистов на Scala, то качество сервиса улучшится при сохранении такого же объёма разработанной функциональности?

3) Если изменение на back-end увеличивает скорость работы UI - то это вы всё равно классифицируете как front-end программирование?

[justy-tylor.livejournal.com]

2. Вероятно.

3. Ускорение бэкенда (программными методами или увеличением количества серверов) позволяет улучшить пользовательские характеристики только в том случае, когда скорость работы UI уже обеспечена на фронтенде. Это не всегда так. Например, можно ядрёно ускорить запрос из базы и поставить обезьянам HipHop, но если архитектура фронтенда предусматривает слишком большое число запросов из браузера на рендеринг одной страницы, то ни один пользователь таких "улучшений" не заметит.

[dennisgorelik]

Если замена дешёвых программистов на меньшее количество дорогих программистов обычно ведёт к улучшению качества сервиса, то почему тогда менеджеры не склонны сделать такую замену по умолчанию?

Я предполагаю, что такая замена выгодна лишь в половине случаев, а в другой половине - не выгодна.
Хотелось бы научиться эти случаи отличать друг от друга.

[justy-tylor.livejournal.com]

Замена творческих работников это своя цена и свои риски.
Смогут они улучшить качество сервиса?
Сколько займёт процесс создания и миграции на новый тек?
Принесёт ли это новые деньги бизнесу? ... Не обязательно.

[dennisgorelik]

Архитектура (определяющая количество HTTP запросов) наиболее популярных страниц на Фэйсбуке наверняка определяется очень квалифицированными и дорогими архитекторами. Вне зависимости от того, используют они PHP или нет.
Почему при большом количестве запросов страница будет рендериться медленно?
Ведь запросы могут делаться паралельно, а страница может рендериться по мере получения данных.

[justy-tylor.livejournal.com]

У меня нет положительной информации о квалификации архитекторов фейсбука.

[dennisgorelik]

А отрицательная информация есть?

[justy-tylor.livejournal.com]

И отрицательной тоже нет. Любые архитектурные проблемы могут оказаться следствием указаний сверху.