Во-первых то, что вы забыли о существовании нагрузочного тестирования говорит лишь о том, что вы забыли о существовании нагрузочного тестирования, а не о том, что «приложению нужен реальный трафик».
Пропускаете этапы разработки — получаете факап с разработкой. Всё логично.
Во-вторых, конечно, любой вменяемый разработчик начал бы проектирование архитектуры не с сущностей ORM, а с вопроса «А какие типовые сценарии выборки и манипуляции данными предполагаются?»
А вот уже из типовых запросов и стали бы рождаться схемы данных. А не наоборот, как у вас.
>> В пользу своей собственной орбитальной станции
>> В пользу обещания сделать свою собственную орбитальную станцию
>> В пользу макета обещанной своей собственной орбитальной станции
>> В пользу рисунка макета обещанной своей собственной орбитальной станции
>> В пользу обещания сделать рисунок макета обещанной своей собственной орбитальной станции
К слову, Python далеко не самый медленный язык по сравнению с конкурентами в «своей весовой категории», взять те же PHP
Ничего более смешного за последнее время я не читал. Сравнивать Python по скорости с современным PHP, который давно уже не «интерпретируемый», чья виртуальная машина по скорости уступает нативному коду максимум в 1.5 раза, в котором есть JIT-компиляция… Вы серьезно?
Совершенно корректный код в PHP.
Есть некие сомнения, что это можно сделать легко и дешево в языке со статической типизацией, но нет сомнений, что в принципе возможно.
Не очень понятно, а чему удивляется автор? Каков язык и его экосистема — таковы и «разработчики».
Вы (автор) еще и виноваты останетесь, что оскорбляете кандидатов слишком сложными и непрактическими вопросами.
Вы молодец, что пытаетесь. Но вряд ли на Хабре место для статей такого уровня. Учитесь, изучайте PHP, изучайте, как устроены другие фреймворки — и не прекращайте писать код, даже если его критикуют. Особенно, если его критикуют!
осталось устранить PHP, везде, в том числе в прокси-сервисе, и написать на C модуль для nginx
чтобы слал реквест в базу в JSON и отдавал от нее же респонс
Пропускаете этапы разработки — получаете факап с разработкой. Всё логично.
Во-вторых, конечно, любой вменяемый разработчик начал бы проектирование архитектуры не с сущностей ORM, а с вопроса «А какие типовые сценарии выборки и манипуляции данными предполагаются?»
А вот уже из типовых запросов и стали бы рождаться схемы данных. А не наоборот, как у вас.
Что-то вроде конечных автоматов?
Да не, шизофазия, разумеется...
>> В пользу обещания сделать свою собственную орбитальную станцию
>> В пользу макета обещанной своей собственной орбитальной станции
>> В пользу рисунка макета обещанной своей собственной орбитальной станции
>> В пользу обещания сделать рисунок макета обещанной своей собственной орбитальной станции
Ничего более смешного за последнее время я не читал. Сравнивать Python по скорости с современным PHP, который давно уже не «интерпретируемый», чья виртуальная машина по скорости уступает нативному коду максимум в 1.5 раза, в котором есть JIT-компиляция… Вы серьезно?
Дело за малым — отправить на packagist, рассказывать всем о ней и смотреть, как прибавляются звездочки.
Можете еще попробовать перевести это с помощью zephir-lang.com/ru-ru в расширение.
На RFC для включения в стандартную библиотеку языка это, разумеется, пока еще не тянет.
Совершенно корректный код в PHP.
Есть некие сомнения, что это можно сделать легко и дешево в языке со статической типизацией, но нет сомнений, что в принципе возможно.
99% сливаются с треском.
А что, есть кто-то, кто против ограничений в БД? Вот прямо всерьез, с аргументацией?
Жаль, что Тейлор не подозревает о существовании более «взрослых» БД, нежели MySQL.
Но, однако, спасибо, что вспомнили ))
Вы (автор) еще и виноваты останетесь, что оскорбляете кандидатов слишком сложными и непрактическими вопросами.
Статья неполна без похорон PHP. Это же хороший тон уже примерно лет 15 — его хоронить. Требую немедленно добавить PHP в статью!
</сарказм>
чтобы слал реквест в базу в JSON и отдавал от нее же респонс