@Kaaboeld проектов больше чем на python, на последнем больше web-сервисов (rest), на ruby больше сайты/web-приложения (spa). Статистика по ruby лучше, инструменты для разработки там не хуже чем у python сообщества а в чем-то даже лучше. Если выбирать сейчас язык именно под web я бы выбрал ruby и оставил python для утилит и ресерчей (у меня сейчас он именно такое место занимает, так как для этих целей удобнее языка я пока не встретил).
Никак. Обычно ставят сервера с балансировщиками между клиентом и серверами. Опять же, можно на уровне DNS разруливать, просто что бы DNS сервер был вкурсе нагрузки на сервер когда принимал решение куда отправить пользователя. Согласитесь, если на сервер показывал признаки жизни три минуты назад и говорил что он еще может принять клиентов, верояность падения не такая уж и значительная.
@keslo лояльны, вот только наглеть уж не нужно. Если на каждый чих задавать вопрос тоже особо ничему не научишься. Спрашивать у гугла, разбираться, если не вышло (и не за 10 минут а нормально так поискать да попробовать) то можно уже спрашивать.
К слову об оплате работой... Вот предположим у меня в голове куча идей что можно было бы сделать. Поскольку идеи сомнительные (то есть я не уверен в профите) нужно делать proof-of-concept. Опять же упираемся в нехватку времени, и тут джуниор какой который бы согласился делать за "ревью", был бы к стати. Тут как бы и говнокод сойдет (proof-of-concept же, потом всеравно переписывать) и для разработчика профит - ревью и рекомендации + практика.
Правда совсем нулевые не смогут, а не нулевые бесплатно что-то делать за идею уже не захотят, им видите ли денежку надо платить. Словом это так, мысли в слух.
ай гивап... вы не думали просто забить на MVC? Просто влепить контроллер (MVC появилось как развитие паттерна контроллер) и все. Если очень хочется - можно потом логику по компонентам/сервисам разносить, но ни вьюв ни модели там нет.
Попробуйте сделать сначала так а потом уже можно будет весть размышения на тему правильно это или нет.
Есть абстрактное понятие "модель" взятое из контекста MVC и трактующееся каждым по разному. А есть еще domain-model. Модель предметной области. Если опять же упрощать - просто класс. Он может быть связан с другими классами... но они ни с кем особо не общаются. Общение должен делать контроллер или (желательно) компонент, работающий с данной моделью. Никаких сложностей, просто классы которые должны делать только то, что должны. Есть класс/объект File, он ничего не знает по сути о файловой системе, он просто данные хранит. А уже сервис FileManager умеет что-то делать с файлами и переносить эту работу на файловую систему. Это делается для того что бы развязать систему, мол у вас может в какой-то момент файловая система смениться на какую-нибудь навароченную распределенную с другим API, или вообще файловой системы не будет а фаайлы храниться будут где-то и дергаться по scp или любому другому протоколу...
@vasIvas но как по мне вы забили себя голову всеми этими MVC и слишком много паритесь по пустякам. Расскажите может что плагин делает хоть приблизительно. Я не могу придумать такой вариант при котором нужен еще и view.
А сервис - это любой класс, который используется контроллером для обработки данных. По сути в сервисе заключается бизнес логика. Модели - элементы на которых работает бизнес логика. Представление - как это не странно - слой представления. Он нужен только для конвертации из формата приложения (модель) в формат нужный на выходе.
@vasIvas у вас нету view. У вас есть данные на выходе и на выходе. Никакого MVC. Только контроллер. Ни модели, ни представления. Контроллер принимает пользовательский ввод и должен дать овтет. Наличие модели/представления не обязательно. Хотя зависит от плагина.
@Urukhayy работать будут они одинаково. Если хотите что бы все работало синхронно - я в своем ответе указал вам ссылку на доку по jquery и название опции. Тогда и ваш вариант будет работать.
@Urukhayy запереть значение в замыкание - да. Вариант @hell0w0rd чище. Только сделайте отдолжение - разберитесь что там происходит и почему. В будущем массу вопросов устранит.
@grafika вопрос уж точно не об этом. Посему я этот момент опускаю, ибо ну зачем вообще думать и гадать? Может описка, может действительно хотел. А вот предмет вопроса мне ясен, его я и обрисовал.
