На чем лучше программировать визуальные приложения?

Гугл -> visual studio c++ графический интерфейс
Неужели так сложно?

Чем плох ajax чат?

Ну да, менее надёжный, при этом более длинный и запутанный код (на обеих сторонах) - это мелочи.

Чем плох ajax чат?

Дмитрий: Ну это можно проверить. Вот пример простого java-класса, рассылающего сообщения. Да, ява довольно многословна, но кода там всего 5 строчек: 3 метода, в двух по 1-й строчке (добавление/удаление сессии), в одном один цикл и одно условие и отправка сообщения:

@ServerEndpoint("/ws")
class WSHandler {
    static final Set sessions = new HashSet<>();

    @OnOpen
    public void onOpen(Session session) {
        sessions.add(session);
    }

    @OnClose
    public void onClose(Session session) {
        sessions.remove(session);
    }

    @OnMessage
    public void onMessage(String message, Session session) {
        for (Session session : sessions) {
            if (!session.equals(session)) {
                session.getAsyncRemote().sendText(message);
            }
        }
    }
}

Сообщения отправляются асинхронно. Вероятность ошибки в логике нулевая, здесь и логики-то нет. Да и вообще, очень маловероятно, что что-то пойдёт не так.

Вот код на питоне + tornado. Он лаконичнее, но суть та же: добавление, удаление. цикл, условие и отправка:

class ChatWebSocket(websocket.WebSocketHandler):
    connections = set()

    def open(self):
        self.connections.add(self)

    def on_message(self, message):
        [c.write_message(message) for c in self.connections if c is not self]

    def on_close(self):
        self.connections.remove(self)

Можешь привести пример серверной части с таким же функционалом в случае AJAX? Будем считать, что в строке сообщения есть все данные: кто отправил, время, если надо, и т.д. (клиент, в моём случае, получает всегда 1 сообщение в ответе за 1 отправленное сообщение от другого пользователя).

Как передать массив методом post с помощью ajax?

Евгений Петров: в этом случае - нет. Просто ошибка автора не в том, что он забыл сериализовать данные, а в том, что он массив использует как объект.
Если же в $.ajax передать объект, то вручную его не надо сериализовать - jquery сам сделает это, вот я что имел ввиду.

Как передать массив методом post с помощью ajax?

jquery сам прекрасно сериализует, достаточно указать dataType: "json"

Каким образом у разных объектов оказывается общим один параметр?

Валерий Рябошапко: Ничего неожиданного, всё описано в доках. В явах/плюсах статические поля ведут себя очень похоже.

Веб-приложение написано. Что дальше?

Lord_Prizrak: Должен работать, но лучше почитать в доках.

Для каких проектов используется node js?

Александр Прозоров: Ну стандартные преимущества тредов перед процессами:
Создавать процессы и переключаться между ними дольше, чем между потоками.
Нет общих ресурсов, ведь запуск процесса происходит в новой, изолированной среде, в новом интерпретаторе.
Передача данных в ноде идёт только через отправку сообщений, и сама передача данных между процессами - более дорогостоящая операция, чем передача между потоками.
Нет балансировщиков, типа тредпулов.
Более слабый контроль выполнения кода.
И т.д.

Ну и в итоге, новый процесс опять однопоточный. Каждую задачу так не позапускаешь, только какие-то особо медлительные или блокирующие части.

Так что нода пока однопоточна, а это не очень хорошо (хотя что-то начинает появляться.

Для каких проектов используется node js?

Александр Прозоров: > Но что вам мешает выделять подзадачи в другие потоки в Node?
Как? Приведи пример пожалуйста. А то всё, что я нашёл - это запуск задачи в другом процессе, что далеко не одно и то же, что поток.

Для каких проектов используется node js?

Александр Прозоров: Нет, нода однопоточная. Там есть event loop, который позволяет выполнять код асинхронно, но это не полноценные потоки. Если вызвать что-то блокирующее в любой задаче, заблокируется всё.
Вот в erlang'е асинхронность реализована через легковесные потоки (волокна). Есть 1 главный поток, все функции (корутины) запускаются в своих потоках. Там своя реализация планировщика. Но суть в том, что вызвав что-то блокирующее в какой-нибудь корутине, ты не заблочишь всё приложение. И если корутина сломается, приложение будет целым.
В Java, например, полноценные потоки на уровне JVM (вроде системные). При этом, код можно выполнять как просто параллельно (new Thread(runnable).start()), так и используя асинхронный подход (Future). И тут тоже потоки независимы, т.е. если один поток вызывает что-то блокирующее (если конечно не блокировать ресурсы через семафоры, например) или ломается, то приложение продолжает работать.

Для каких проектов используется node js?

Александр Прозоров: Ну понятно, что надо обезопасить себя и сделать обработку возможных ошибок максимально устойчивой, и запускать сервер не просто через screen.
Проблема в том, что новички могут не предусмотреть некоторые неочевидные вещи. Да и если что-то пойдет не так и одна задача сломает приложение, то все выполняющиеся задачи будут прервыны. После перезапуска далеко не факт, что данные смогут восстановиться. Например, асинхронная задача забрала из очереди сообщений послание, начала выполнять какое-то действие и уронила приложуху. Все незавершённые задачи уже забрали свои сообщения, но результат их выполнения прервался и если он не был сохранён где-то извне, то данные всех задач пропадут.
В многопоточном приложении потеряются данные только одной задачи, все другие потоки будут продолжать работать, да и основное приложение сложнее уронить.

Как приготовить Java SE + MVC + SWING + DependencyInjection/IoC?

Кирилл Саксин: Ох, простыня щас будет...
0) В яве много минусов в плане ООП:
a) отсутствие параметризированных типов в runtime из-за type erasure генериков. Получить тип можно либо через костыли, либо передавая в каждый метод, зависящий от типа, этот тип напрямую, что добавляет кучу лишнего кода.
b) Только ad-hoc полиформизм, а было бы круто, если бы он был параметрический
c) Диспетчеризация только по одному типу (метод принадлежит объекту, из которого он вызван). В объектной системе лиспа CLOS есть мультиметоды. Их можно параметризовать как одним классом (тогда будет как в яве/питоне/других языках), так и несколькими (тогда будет множественная диспетчеризация). Почитай про него, полезно хотя бы для общего понимания, какое ООП вообще бывает.
d) Классы - не объекты. Это очень печалит. В том же питоне любой класс - это полноценный объект, его можно хранить в переменной, и т.д. В java есть только костыли вида Class.
e) Как следствие - отсутствие метаобъектов
f) Отсутствие множественного наследования (хотя бы в урезанном виде: mixins, traits, delegates). e и f частично решается в scala и groovy.
Вообще, любой прототипный язык (js, lua, io) намного ближе к классической парадигме. ООП в стиле java/c++/c# просто более популярное (потому что более простое для понимания).

1) Нет, ты неправильно понимаешь MVC.
Model - это данные + бизнес-логика. Модель ничего не знает о том, как отображать их. Модель ничего не знает, кто, как и когда подписался на рассылку её оповещений. Однако, модель должна оповещать слушателей.
View - это то, как отображать данные. Без модели он бесполезен - нечего отображать. Соответственно, view должен быть связан с моделью напрямую (либо через посредника, но это не Controller).
Controller - это тонкая прослойка, связывающая пользователя с программой. Контроллер не должен связывать View и Model.

Model + View - это обычно паттерн Observer: модель (Observable) хранит в списке всех заинтересованных слушателей. Она имеет методы для добавления/удаления новых слушателей, ну и конечно - оповещение. Модели не важно, есть ли в списке ноль, один или сто слушателей. При изменении данных в модели она просто в цикле передаёт сообщение всем слушателям. View - это Observer. При поступившем событии от модели View обрабатывает полученное сообщение и что-то делает с данными.
View + Controller - это паттерн Strategy. При каком-то событии контроллер выбирает конкретную стратегию поведения, берёт данные из представления и выполняет выбранную стратегию в модели.

При этом, нет никакого противоречия в независимости компонент. Разрабатывать модель можно без знания о V и С. Модель лишь предоставляет интерфейс для обработки данных. При этом, не изменяя модель ты сможешь прикручивать к ней разные представления (которые могут быть написаны даже на разных языках).
View должен знать о модели, но не о контроллере. View должен уметь подписываться на события изменения данных из модели и обрабатывать приходящие изменения. При этом, не изменяя представление, ты можешь задавать ему разные стратегии поведения при действиях пользователя, достаточно просто изменить соответствующий контроллер. Опять же, контроллер может быть на другом языке, ничего не мешает это реализовать.

Вот пример: модель NumbersList хранит список чисел. Есть 3 view: одно отображает числа в виде круговой диаграммы, второе в виде столбчатой диаграммы, третье - в виде списка полей ввода. При старте программы все три подписываются на события модели NumbersList. В любой момент ты можешь отсоединить/присоединить представления по своему жеданию, естественно ничего не меняя в модели. При нажатии кнопки "отправить" контроллер соберёт числа из текстовых полей и отправит их в модель для обновления. Когда данные в модели изменяются, она в цикле высылает всем представлениям обновлённые данные. Все 3 view изменят свой внешний вид на соответствующий. Теперь, не трогая реализацию View, можно добавить контроллер, который при нажатии на столбец диаграммы передаст в модель значение соответствующего числа, но увеличенного на единицу. Можно повесить ещё один контроллер, который при нажатии на правую кнопку мыши будет высылать модели уменьшенное значение.

Вот это классическая реализация MVC, всё остальное - это не MVC.

2) Примеры, зачем нужно использовать внедрение зависимостей в JavaEE:
a) Выбор реализации EntityManager. Ты настроил в xml свои источники данных. В сервисе ты инъектишь через аннотацию эту зависимость. Сервер приложений сам парсит xml-файлы, выбирает нужный persistence unit (их может быть много, по-сути один юнит на одну БД в СУБД), смотрит, какие реализации JPA API он может использовать (а реализация может быть как встроенной в сервер, так и быть в виде jar-ки, которая входит в проект). При этом, сервер сам сможет следить за транкзакциями и обеспечивать безопасность. В JavaSE это не нужно, так как ты при запуске приложения сам создаёшь соединение (только из приложения, больше неоткуда) и подрубаешь нужный EntityManager в нужный бин через фабрику. Внедрение зависимостей только усложнит дело, а не упростит.
b) Управление временем жизни бина. Хороший пример - JSF. Можно сделать бин живущим, только для одного запроса (@RequestScope). Тогда для каждого запроса (вне зависимости от пользователя) этот бин будет жить только от поступления request до отдачи response. Можно сделать бин для сессии - @SessionScope. Когда заходит пользователь, для которого сессия не найдена, создаётся этот бин. Все данные он хранит до тех пор, пока сессия не протухнет. Таким образом, можно, например, изменять данные на странице без её перезагрузки (например как в админке GlassFish). Можно сделать бин @ApplicationScope. Он будет доступен всем вне зависимости от сессии и других сетевых параметров пока живёт само приложение. В свинге просто не предусмотрен многопользовательский режим: единственный пользователь - это тот, который запустил это приложение. И время жизни там только от запуска приложения до его завершения. Тут просто нет смысла управлять бинами.
c) Обеспечение транкзакций, передачи сообщений и безопасности. Для бинов, аннотированных через @EJB, сервер предоставляет гарантию транкзакций и безопасности (если сама реализация бина аннотированна всякими @Transactional, @ManagedBean и т.д.) Плюс, бин можно сделать удалённым и управлять им через JMS. Доставку собщений так же гарантирует сервер. В свинг-приожениях это просто не нужно.

В общем, ты только запутаешь свою систему с DI. Ведь тебе надо будет самому реализовывать многие вещи. Выбор нужной реализации конечно будет выполнять DI framework (если подходящая реализация только одна), однако при созданий множества реализаций одного интерфейса нужно уже вручную указывать, какую реализацию использовать. Серверы приложений - это огромное количество человекочасов, в одиночку сложно будет реализовать всё это.
Ну и самая простая причина не использовать DI состоит в том, что свинг-прилолжения простые: они не многопользовательские, они не предполагают управление временем жизни и контекстом приложения (ведь приложение запускается напрямую, а не в контейнере), они не предполагают выбора из множества реализаций API, всё идёт в compile-scope.
Самое простое и очевидное - просто использовать фабрики, а в каждом бине хранить его настройки в виде констант. Либо использовать аннотации при создании объектов/объявления классов, но без DI. Либо хранить настройки в файлах конфигов, если хочется гибкости. Этого хватит с головой.

А вот приложений на свинге не могу порекомендовать, поищи на гитхабах.

Почему textarea отличается по ширине от input в браузерах на движке Webkit?

kisonic: пропиши width, зачем создавать самому себе такие проблемы?
Как вариант, используй table или display: table, если нужна сетка. Если старые браузеры не нужны, то используй flexbox.
Какие-то странные у тебя проблемы на ровном месте.
И код скинь, а то непонятно, что ты там понаписал.

Есть ли подобный jquery-плагин для галереи?

мне не нужна одна над другой, таких много.
нужна просто горизонтальная прокрутка всех картинок (но не в 1 строку, как многие слайдеры делают, а в 2). а при нажатии всплывающая картинка, а не одна большая.
demo.tutorialzine.com/2013/05/diagonal-fade-gallery
вот пример, но там подгрузка аяксом, что мне не надо и он не оформлен как плагин, придётся много под себя кастомизировать, на что нет времени, к сожалению.

Как отключить кусок скрипта, если ширина экрана меньше указанного?

Сергей Озеранский: модернизр можно кастомизировать, т.е. возможно включить в итоговый js только нужный функционал, так что кода там будет по минимуму.. Да и сам модернизр довольно полезная вещь.
Хотя я сам за чистоту кода и не люблю подключать тот же jquery там, где он не нужен. А то очень многие используют от силы 5% его возможностей и тащат в любое место. А потом сайты тормозят.

Как понять суть программирования (подробнее в содержании)?

Ну и зачем человеку начинать изучение программированию с UML и ООП? Классы и ООП надо выбирать лишь там, где оно хорошо применимо. ООП - лишь одна из концепций, причём далеко не самая удачная и уж точно не универсальная. А то наслушаются таких советов, а потом спрашивают Что делает эта строка a[j] = i;, потому что у него нет нужного класса, а код он может только мышкой рисовать в виде UML.

Какую выбрать книгу по программированию для ребенка?

А от чего там отворачиваться? Там отлично показано, как имея в наличии совершенно простой язык создавать сложные вещи. По-моему, просто замечательно. При этом, там (в отличие от Кнутов, Виртов и других) сразу идёт практика.
В виде бонуса, в DrRacket есть всякие разные интересные учебные языки (с поддержкой графики, например).

Как создать свою модель пользователя в django?

maxclax: Статья в документации и так очень простая и наглядная. Изучи ты уж этот английский.

Как это называется?

TostMaria: Ну я перешёл. Это интернет, тут и послать могут, знаешь ли.

Как шрифт влияет на верстку страницы?

Выложи нормально. Твой рар никто не захочет качать. А по твоему описанию не очень понятно что за проблема.