Quickerz

Вариант 1. Пишем свой middleware, который будет шарить сессию

var express = require("express");
var Server = require("http").Server;
var session = require("express-session");
var RedisStore = require("connect-redis")(session);

var app = express();
var server = Server(app);
var sio = require("socket.io")(server);

var sessionMiddleware = session({
    store: new RedisStore({}), 
    secret: "secret",
});

sio.use(function(socket, next) {
    sessionMiddleware(socket.request, socket.request.res, next);
});

app.use(sessionMiddleware);

app.get("/", function(req, res){
    req.session 
});

sio.sockets.on("connection", function(socket) {
  socket.request.session // Теперь сессия доступна через сокет
});


server.listen(8080);

Вариант 2. Используем https://github.com/techpines/express.io
Вариант рабочий, но есть нюансы с апи экспресса. Местами оно немного устаревшее.

Обычно для финальной сборки и подписи приложения используют ant. В папке platform/android выполняется ant release, а в файле ant.properties (имя может отличаться, его можно определить в файле конфига в той же папке) указывается путь к файлу ключа и название хранилища. При билде ant попросит пароль от файла ключей и положит готовое приложение в platform/android/bin под именем AppName-release.apk

Flask вполне подойдёт для ваших целей. Сразу скажу, что не имел дело с веб разработкой под Java, но мне кажется, что порог входа значительно выше, чем в питоне. Вам нужен ровно один файл и десяток строк, чтобы запустить своё первое приложение на Flask. Сомневаюсь, что с Play! можно сделать подобное. Но тут стоит выслушать людей, которые работают с ним. Я лучше опишу преимущества веб разработки на питоне.

Во-первых это сам питон. Язык прост, лаконичен, имеет множество библиотек, которые покрывают большую часть потребностей для веб разработки. Насчёт рекурсивных импортов я бы не беспокоился. За исключением очень уже редких случаев такие проблемы легко решаются переносом импорта в нужное место в файле либо правильным разнесением функционала по модулям.

Во-вторых Flask не имеет каких-либо требований к организации проекта, что даёт желаемую гибкость, хотя и требует дополнительного планирования архитектуры. Хотя я не уверен, что это минус для специфичного проекта, который в любом случае предполагает некоторое предварительное планирование. Вы можете сделать весь проект в одном файле (старайтесь этого избегать), можете использовать встроенный механизм блюпринтов, можете использовать стороннее решение для организации кода на основе классов либо сделать своё. Гибкость и прозрачность питона здесь отлично себя проявляет.

Ну и напоследок, если вы работаете над реально СПЕЦИФИЧНОЙ задачей, есть смысл поискать решения именно под эту задачу на языке-кандидате. Может оказаться так, что более удобный для общих задач фреймворк окажется менее пригодным для решения именно вашей задачи.

Я бы рекомендовал использовать SCSS, как тут уже посоветовали. Теперь по пунктам.

Нет необходимости ставить окружение на сервере. На локальной машине ставится ruby + gem sass, после этого в IDE (продукты JetBrains и Netbeans точно поддерживают такую возможность) настраивается watcher, который собирает все файлы при их изменении и выгружает их на виртуалку в локальной сети. При сдаче проекта возможно тем же модулем окончательно минифицировать файл, убрав все отступы и пробелы.

Одним из преимуществ scss является разбить стили по файлам, чтобы отделить, к примеру, стили для построения сетки от стилей, которые отвечают за типографику. Самым простым решением будет создать один индексный файл style.scss и в нём уже импортировать остальные файлы. При этом файлам которые импортируются следует давать имена, которые начинаются с нижнего подчёркивания. Это будет означать, что они не будут компилироваться в отдельные css файлы, что даст на выходе один файл.

Ну и главное преимущество: scss содержит многие элементы полноценного ЯП: переменные, функции, управляющие структуры, которые позволяют сделать код стилей более простым, понятным и гибким.

Вот этого краткого обзора возможностей SCSS должно хватить, чтобы оценить, насколько он удобнее чистого CSS. Я после использования SCSS не представляю, как можно верстать на чистом CSS, особенно учитывая, что для человека, который знает CSS и владеет любым языком программирования, порог входа в SCSS практически отсутствует.