mikemoix: Почитай доки по супервизору тогда. Там есть команды update, start, stop, restart, etc. И очевидно, что uwsgi надо запускать в супервизоре, чтобы им можно было через него управлять.
Ну фласк довольно серьёзная штука. Просто он требует больших познаний и в языке и в умении выстроить архитектуру приложения. В django не надо париться над структурой проекта, она довольно жёстко навязана самим фрейморком. Там есть куча готовых решений, но шаг в сторону - и начинаются проблемы.
Во фласке же ты сам из небольших кирпичиков строишь решение.
Чем .net перспективнее? Андроид куда более распространён, а это java. Кроссплатформенные десктопные приложения - это java (и Qt), .net только недавно пришёл на юниксы.
Энтерпрайз - это в большей степени java, т.к. стабильно и обратносовместимо.
А количество разных библиотек, фреймворков и серверов у явы куда больше. Причём, очень многие фреймворки разрабатываются крупными фирмами и проверены годами. А решений для .net крайне мало, по-сути, это то, что предлагает MS + пара сторонних проектов. Взять хотя бы разнообразие апп-серверов/контейнеров для явы (tomcat, jetty, netty, glassfish, wildfly, akka, undertow, WebLogic, WebSphere, etc).
Vlad Harbarchuk: Ты статью-то читал? Там сравнивается сервлет, запущенный на томкате (который блокирующий сервер) и приложение для ноды (который неблокирующий сервер).
Это сразу говорит о компетентности автора бенчмарка (впрочем, в комментах ему явно сказали, что он неправ). Да и вообще, там по-сути идёт сравнение скорости драйверов для CouchBD.
Т.е. по результатам бенчмарка можно сделать вывод, что даже не самый быстрый из блокирующих контейнеров сервлетов на Java с запущенным сервлетом (а это лишний оверхед по скорости) по скорости почти такой же быстрый, как нода. Надо ли говорить, что undertow или netty оставят ноду далеко позади. Причём, по-идее, надо было сравнивать именно нетти с нодой, так как они оба неблокирующие.
Да не драматизируй. JavaEE 7 - очень годная штука. А народ в большинстве предпочитает то, что легче выучить. На простых задачах рельсы с джангой удобнее, но вот сложные системы как раз подходят для EE. Кучу плюсов не перечислил.
Алексей Уколов: promise - 'это урезанная копия deffered, состояние которой нельзя изменить и которую можно и нужно передавать наружу (через return). сам deffered должен оставаться приватным, чтобы в нём ничего извне нельзя было изменить (т.е. изменить его состояние), иначе весь паттерн нарушится. habrahabr.ru/post/193598
abdullam5: Вроде как именно через filebrowser никак, но он позволяет грузить много файлов за раз в папку. Привязать к модели их можно вручную (например, для каждой модели выделять папку, в которую будут сохраняться изображения). Наверняка есть и готовые решения, посмотри по второй ссылке, что я привёл или посмотри тут stackoverflow.com/questions/537593/multiple-images...
abdullam5: Насколько я помню, надо создать папку "uploads" (это папка filebrowser'a по-умолчанию) внутри MEDIA_ROOT. Т.е., в твоём случае, это BASE_DIR/static/media/uploads
abdullam5: grappelli вроде исправили (судя по закрытому issue на гитхабе), но возможно ещё не зарелизили, просто пропиши в requirements.txt git-адрес. Про filebrowser не могу сказать, попробуй запустить и проверить.
Вадим Егоров: Так вроде ответил: читай статьи на вики/хабре и применяй эти знания на практике, вот и всё. Без реального опыта ты никогда не поймёшь что и как устроено. Желательно, конечно, познавать это всё не на пхп, но тут уж сам решай.
Да. в итоге такой файл и использую, только я генерю его сам через gulp-ng-config в зависимости от переданного аргумента командной строки. А потом всё инжектится при сборке.
Про генераторы и сборщики я знаю, использую generator-gulp-angular. Хранить настройки в соответствии с типом (prod/dev) я тоже думал, но может так случиться, что в процессе разработки разработчику A нужны будут свои настройки, а разработчику Б - другие. Т.е. есть общие дефолтные настройки, есть настройки для production, которые перезаписывают какие-то значения из общих настроек, есть настройки для dev, которые делают тоже самое, и есть локальные настройки, которые не хранятся в гите, но так же могут перезаписывать общие настройки (с наивысшим приоритетом), если будет существовать этот локальный файл. Как быть в этой ситуации?
Дмитрий: много кто: java/scala + netty, erlang, go, скорее всего даже питон с руби смогут, тут немаловажную роль играет железо.
В этом бенчмарке нода эпично сливает.
Alexander Litvinenko: Какие? Про ноду?
Мультипоточности всё ещё нет.
Да, es6 вышел, появились генераторы и yield, коллбеков стало меньше. Типизация всё та же. С SQL дела так себе, есть 1-2 фреймворка. Транкзакции ручные, ленивой загрузки вроде как нигде нет. Крупных веб-фреймворков с развитой инфраструктурой мало. Нет множества мелочей, которые есть в JavaEE. Производительность низкая.
Использование асинхронной модели в случае обычных веб-приложений. где соединение живёт недолго, не оправдывает себя. Если же брать чисто "асинхронные" задачи, то для Java есть netty, который намного производительнее, безопаснее и надёжнее ноды.
Просто дело в том, что Java как язык стремился к полной обратной совместимости и кроссплатформенности, а в вебе стремилась сделать платформу для построения очень крупных энтерпрайз-приложений, и это ей удалось.
А нода - это в первую очередь платформа, которая дала возможность писать на js на сервере с неблокирующим IO и событийностью. Но для веба это довольно узкоспециализированная вещь и подходит далеко не для всех задач. Java в этом плане более универсальная.
Node.js - это однопоточная асинхронность на коллбеках, платформа почти без веб- и ORM-фреймворков, язык с неявной типизацией и другими проблемами.
Java явно не этого пыталась добиться. Сейчас и для Java есть асинхронные сервера (netty, к примеру), которые быстрее той же ноды, но с поддержкой мультипоточности и с огромной инфраструктурой, проверенной годами. Есть и крутая акторная модель в виде Akka. А сам стандарт JavaEE включает столько всяких штук, что ноде и не снилось: ORM-фреймворк с автоматическими транзакциями, threadsafe-компоненты, сериализация с гибкой настройкой, вебсокеты, система событий, система сообщений, безопасность, возможность использования удалённого кода, масштабируемость и т.д. Плюс к этому, нормальная типизация и гарантия обратной совместимости. И это только одна ниша...
Nem0_o: Ну если для понимания, обычно прикладывается свой вариант с просьбой указать, где и что не так. А в таком виде это выглядит как "решите за меня нахаляву"
fundottz: Шаблонизаторов для явы много. Все они имеют разный синтаксис самих шаблонов, разные возможности, разную скорость рендера и т.д. Те же JSP с JSF тоже можно рассматривать как шаблонизаторы. Пишешь BackingBean на java, а на самих страницах используешь их. Много писать, тут легче тебе самому поискать статьи, тем более их очень много.
Другой вопрос, нужен ли тебе шаблонизатор? Ведь можно сделать так: написать сервис, REST, SOAP, другой какой, это ты уже сам решай. Я бы советовал REST, он более современный, да и на клиенте с ним работать легче. А схему можно взять json-schema (для неё я точно знаю, что есть библиотеки, генерирующие формы, а вот для xsd фиг знает, гуглить надо).
Сам же клиент - это тупо 1 html-страница. В качестве фреймворка на клиенте можно взять angular. В итоге, сервер отдаёт лендинг как статическую html-ку. Общение между клиентом и сервером происходит только через АПИ, сервер не рендерит шаблоны, на нём нет логики отображения. Вся логика отображения на клиенте. На ангуляре легко делать одностраничные приложения со сложной логикой. Работать с апи там тоже удобно, в принципе.
В любом случае, точно сказать не получится. Решение, что же конкретно выбрать, приходит с опытом. Нет опыта - делай как сможешь, потом на ошибках научишься.
Лично я бы делал REST сервис (это JAX-RS) + одностраничник на angular или jquery (используя json-schema).
Просто вызов метода toArray без параметров вернёт объект типа Object[], а если передать в него переменную, то он будет параметризирован её типом.
Фишка в том, что ты можешь в свой map запихивать любые значения, и компилятор не будет ругаться. А вот уже в рантайме при вызове вот этого метода будут проблемы, если вдруг не все элементы окажутся типа Player.
Поэтому надо использовать дженерики, и писать типобезопасный код. Текущее решение мягко говоря фиговое.
Правильно, Delphi не полумёртв, он умер окончательно. Кроме нескольких компаний, которые пишут на нём по старой памяти или которым delphi просто впарили, никто на нём не пишет. Да и цены сейчас на него какие-то совсем неадекватные.
Изобрёл паскаль небызезвестный Вирт. Теоретик он хороший, но практик из него никакой. Не умеет он нормальный код писать, увы. Достаточно посмотреть на код оберона.