Были у меня большие программы на питоне. Не помню ни разу, чтобы сложная проблема была последствием использования динамической типизации. Вот всякие race conditions, логические недоработки или просто ошибки в рассчетах — этого навалом, но что-то я не слышал, чтобы статически типизированные языки от подобного были защищены.
Про 3 месяца я загнул конечно, но если изначально был проект сделанный за неделю, то за 3 месяца уже могут что-нибудь да выкатить на прод. По опыту знакомых джавистов-аутсорсеров, где-то так все и происходит: приходят люди и просят переделать говнокод на питоне или еще чем-то во что-то приличное.
Такое происходит, когда методология тестирования нарушена.
Тут мы и приходим к тому, что чтобы проект выдерживал нагрузки сразу, разработчик должен быть опытным (дорогим) и чтобы просто проверить идею (которая скорее всего не взлетит по статистике), придется потратить много денег и скорее всего времнеи. Естественно я не говорю о проектах, где большая нагрузка точно будет.
Не согласен с вами. Поведение под нагрузкой предсказать всегда сложно, и оно может упираться не в RPS, или не в тот RPS, который вы задумали. Уже было очень много случаев, когда делали оптимизированный сервер на Java/C++/Go/etc. и в большинстве случаев все равно все заканчивалось тем, что под взрывом нагрузки сервис несколько дней лежал, так как упор был не в процессор, а например в базу. Почитайте для примеров истории разных io-игр или погуглите на хабре словосочетание «не выдержал хабраэффекта».
Еще мне кажется, что автор не имел в виду, что надо всегда оставаться на питоне в любой ситуации. Вы можете наговнокодить за неделю прототип на Django и размножить его на 100 серверов при необходимости, а убедившись что 100 серверов действительно нужны, нанять в это время высокооплачиваемую Java-команду, которая за три месяца перепишет проект и уместит все в один мощный сервер.
И тогда цена проекта получится полностью оправданной — и 100 серверов, и профессионалы покупаются только если они действительно нужны. А если сервис понадобится только 1.5 пользователям, все что вы потеряете — это деньги на микроинстанс и неделю времени.
Почему-то все считают, что их проект обязательно доберется до той точки, где ему понадобятся сотни и тысячи серверов и при этом будет использоваться тот же код, что и в начале. Таких больших проектов реально единицы и обычно они начинают с дешевого говнокода от фрилансеров, который все равно потом приходится переписывать.
Специально для таких ситуаций существует удаленная работа, когда работник не хочет/не может выехать из провинции, а работодатель хочет немного сэкономить. В последние годы таких вакансий стало очень много на русскоязычном рынке, а если потратить несколько месяцев на изучение английского, то вариантов становится еще больше.
Но проблема думаю не в доступности удаленной работы, а в том, что ваш знакомый скорее всего выучил лет десять-двадцать назад delphi / c++ / 1C и больше никуда развиваться не хочет, так как новые языки его в чем-то не устраивают, или на это банально нет времени.
Лично мне известно довольно много примеров, когда человек работает удаленно из провинции, постепенно находит «свою» компанию, которая платит ему уже даже больше, чем в крупных городах. При этом я говорю не о вчерашних студентах, а об опытных специалистах 30-50 лет, которые в нужный момент не побоялись переключиться в угоду рынку.
У меня опыта с MongoDB нет, но насколько я понял из статьи — его имеет смысл использовать для простых CRUD-приложений с перспективой быстрого роста, когда при этом не очень страшно, что часть данных будет неконсистентной. То есть действительно информация по онлайн-играм, сообщениям и прочей пользовательской активности.
С другой стороны, если у меня точные данные или нужна сложная аналитика, то тут уже придется брать *SQL базу на одной машине с репликами, и надеятся, что до шардинга дело дойдет нескоро.
Интересно что This War Of Mine — это по сути механика Dwarf Fortress (строим свою крепость с кроватями и мастерскими, варим еду и самогон, не даем персонажам скучать, торгуем) в сеттинге, похожем на реальный мир. Но в то же время FUN — это одно из самых употребляемых слов на форумах игроков DF, хотя в игре зачастую происходят гораздо более страшные вещи.
Отдавать тесты на публику, как по мне, не очень хороший вариант по многим причинам (безопасность, упрощение разработки конкурирующего продукта и т.п.). Компромиссом может стать появление независимых экспертов, которым разработчик может передать тесты под NDA, и которые будут выдавать свою оценку качеству продукта, понятную для конечных пользователей.
Также более мягкий вариант — выдавать только нагрузочные тесты, использующие внешние интерфейсы. Они позволят оценить продукт на близких к реальным условиях. При этом живые пользователи не пострадают, как это обычно происходит, плюс ничего скрытого никто не увидит.
Выглядит очень интересно, но в коммерческом проекте, который нужно поддерживать другим людям, я бы такое не применял, разве что для каких-то специфических задач, где ORM действительно будет палкой в колесах.
Python, точнее его самый известный представитель CPython, не очень предназначен для каких-либо быстрых расчетов.
Если решать задачи в лоб (с вложенными или просто огромными циклами, например), получается действительно довольно медленно. Если же пользоваться итераторами, корутинами, стандартными библиотеками itertools, functools или внешней scipy, выходит вполне приемлемая производительность, которой для большинства случаев хватает. Не зря же довольно много ученых выбирают python для своих исследований.
Плюс ко всему в CPython отлично реализована поддержка больших чисел (тип long), работает просто молниеносно.
Для Python есть CheckIO, там задач гораздо больше и они сгруппированы по тематике (математика, регулярные выражения и т.д). Есть некое подобие сюжета, хотя я, если честно, не совсем его понял.
Я ни разработал ни одной игры, но наблюдал довольно много интересных историй. Сейчас основная проблема у разработчиков — это то, что они по-старинке ломятся сразу на большой рынок, ничего там не получают и грустно уходят.
Другие, обычно более успешные разработчики, начинают с совсем малого, сначала ведут тему где-нибудь на tigsource, потом отправляют свои наработки блоггерам, участвуют в разных джамах (причем и тех и других сейчас, как и игр, развелось огромное множество и все имеют какой-то вес) и постепенно набирают популярность, которая обеспечивает много продаж или по крайней мере позволяет запустить успешную кампанию по сбору средств на разработку.
Тут мы и приходим к тому, что чтобы проект выдерживал нагрузки сразу, разработчик должен быть опытным (дорогим) и чтобы просто проверить идею (которая скорее всего не взлетит по статистике), придется потратить много денег и скорее всего времнеи. Естественно я не говорю о проектах, где большая нагрузка точно будет.
Еще мне кажется, что автор не имел в виду, что надо всегда оставаться на питоне в любой ситуации. Вы можете наговнокодить за неделю прототип на Django и размножить его на 100 серверов при необходимости, а убедившись что 100 серверов действительно нужны, нанять в это время высокооплачиваемую Java-команду, которая за три месяца перепишет проект и уместит все в один мощный сервер.
И тогда цена проекта получится полностью оправданной — и 100 серверов, и профессионалы покупаются только если они действительно нужны. А если сервис понадобится только 1.5 пользователям, все что вы потеряете — это деньги на микроинстанс и неделю времени.
Но проблема думаю не в доступности удаленной работы, а в том, что ваш знакомый скорее всего выучил лет десять-двадцать назад delphi / c++ / 1C и больше никуда развиваться не хочет, так как новые языки его в чем-то не устраивают, или на это банально нет времени.
Лично мне известно довольно много примеров, когда человек работает удаленно из провинции, постепенно находит «свою» компанию, которая платит ему уже даже больше, чем в крупных городах. При этом я говорю не о вчерашних студентах, а об опытных специалистах 30-50 лет, которые в нужный момент не побоялись переключиться в угоду рынку.
Специально для такого случая в питоне есть библиотека unittest.mock
С другой стороны, если у меня точные данные или нужна сложная аналитика, то тут уже придется брать *SQL базу на одной машине с репликами, и надеятся, что до шардинга дело дойдет нескоро.
Также более мягкий вариант — выдавать только нагрузочные тесты, использующие внешние интерфейсы. Они позволят оценить продукт на близких к реальным условиях. При этом живые пользователи не пострадают, как это обычно происходит, плюс ничего скрытого никто не увидит.
Читал очень давно, в книге рассказывается о разных аспектах робототехники на тот момент (конец семидесятых).
Если решать задачи в лоб (с вложенными или просто огромными циклами, например), получается действительно довольно медленно. Если же пользоваться итераторами, корутинами, стандартными библиотеками itertools, functools или внешней scipy, выходит вполне приемлемая производительность, которой для большинства случаев хватает. Не зря же довольно много ученых выбирают python для своих исследований.
Плюс ко всему в CPython отлично реализована поддержка больших чисел (тип long), работает просто молниеносно.
https://muut.com/riotjs/compare.html
Другие, обычно более успешные разработчики, начинают с совсем малого, сначала ведут тему где-нибудь на tigsource, потом отправляют свои наработки блоггерам, участвуют в разных джамах (причем и тех и других сейчас, как и игр, развелось огромное множество и все имеют какой-то вес) и постепенно набирают популярность, которая обеспечивает много продаж или по крайней мере позволяет запустить успешную кампанию по сбору средств на разработку.