kazmiruk

Так делать плохо https://github.com/angular/angular.js/wiki/Anti-Pa...
Можно сделать проще

$timeout(function() {
код
});

Эффект будет такой же. Ну и все это актуально для кода, который изменяет состояние извне.

Метрики для определения формата не всегда однозначны и трудно формализуются. Создать какие-то приближенные методы возможно, но они будут работать не со 100% результатом (хотя, возможно, и близким к ним). Работал над чем-то подобным для обработки наборов изображений поступающих роботу и ничего адекватного для С++, python, C# не нашел. По пхп не точно, но предполагаю, что ситуация аналогичная. Ну и подобную задачу решать на пхп не самый лучший вариант, так как для распознавания в любом случае потребуется разбор изображения, получение производных и т. п. в чем пхп явно не лучший игрок.

SELECT *
FROM Peoples
INNER JOIN peoples_to_region
ON Peoples_to_region.people_id = Peoples.id AND Peoples_to_region.region_id IN ({region_list})
INNER JOIN Peoples_to_metros.people_id = Peoples.id AND Peoples_to_metros.metro_id IN ({metro_list})

Ну и peoples - "народы" переводится, а не "люди"

Все реально, но изучить рельсы это должно быть не "прочитать книги и послушать скринкасты". Результатом изучения должны стать простенькие проектики (желательно не абстрактные, а полезные хотя бы Вам), которые доступны онлайн или на гитхабе. Вот со знанием руби + парой примеров на нем уже можно идти во фриланс. Без этого заказы возможно получить, но из-за отсутствия практики Вы будете неумолимо пропускать сроки и терять деньги, так как не сможете верно оценить трудозатраты.

Врут, можно решить )
var x = {}, y = 'asd';
x[y] = 123;
console.log(x);//выведет {asd: 123}

Если забить на термины и попытаться просто объяснить что происходит - первый вызов sum записывает переданное значение в переменную currentSum и создает функцию, которая сможет всегда достать эту переменную (это называется замыкание). Т. е. где бы и когда бы Вы не вызвали функцию f она всегда будет ссылаться на переменную currentSum (причем это не разные копии переменной, это именно одна и та же переменная). Затем созданная функция возвращается как результат sum. При вызове того, что вернулось из sum (т.е. вызове f) общение снова произойдет с currentSum. Т.е. примерно так:
sum(1)(2)(3) =>
sum(1) возвращает f и currentSum = 1
f(2) возвращает f и currentSum += 2 == 3
f(3) возвращает f и currentSum += 3 == 6
Ну и когда Вы захотите увидеть результат, то вступает в силу f.toString = function() { return currentSum; };, которая переопределяет метод, который вызывается при попытке отобразить функцию как строку. Так как f всегда возвращает f, то после последнего этапа currentSum будет равен 6 и вернется f. Делая alert(sum(1)(2)(3)) Вы по большому счету пытаетесь отобразить вернувшуюся функцию. Происходит обращение к toString, которая отображает именно currentSum, а не что-то другое. Это на пальцах. Но лучше почитать то, что Вам посоветовали.

Вы не говорите, что завершен ответ. Нужно вызвать response.end(); в конце, а у Вас response.end;

Странно, что работало раньше и "вдруг" перестало работать. Вообще судя по коду вы используете expressjs. В документации есть такое expressjs.com/4x/api.html#req.body:
"req.body
Contains key-value pairs of data submitted in the request body. By default, it is undefined, and is populated when you use body-parsing middleware such as body-parser and multer."
Т. е. body по умолчанию undefined и его надо заполнить чем-то вроде body-parser.

Переделайте
response.write(cities);
на
response.write(JSON.stringify(cities));
так как response.write принимает только строки и буфер. Т. е. данные необходимо сначала сериализовать.
Ну и Content-type в данном случае лучше поменять с application/x-javascript на application/json

В данном контексте самый правильный вариант. User с полем friends, у которого тип list. Только не обязательно на каждого юзера слать отдельный запрос. Можно управится 2мя запросами (выбрать текущего пользователя, а затем выбрать всех юзеров с идами в списке user.friends). Ну или даже одним через аггрегирование.

Да, можно. Создаем пустую миграцию, в которой пишем db.execute("что угодно")
Но так как эта операция не легкая и потенциально опасная, то лучше поменять старые миграции с учетом выставления нужного типа, а на текущей базе провести изменения руками. Таким образом текущие данные будут в InnoDB и новые инстансы проекта будут также в InnoDB

А что Вы хотите сделать этой строчкой res.json('response':req.body.response);?
Ошибка вполне справедлива: req.body undefined по умолчанию и наполнить его можно body-parser'ом (expressjs.com/4x/api.html#req.body). Но даже после наполнения он не должен содержать response (если Вы его туда сами не запихаете), response должен содержаться в response переменной (в Вашем случае res), передающейся в обработчик. Плюс у вас в res.json передается невалидный json, нужно res.json({ключ: значение}). И последнее - Ваш код не понятно что делает. Вы пытаетесь в response вывести response. Это как минимум нелогичное действие )

req.params содержит динамические параметры, которых у Вас судя по урл /users/login для данного запроса попросту нет. Если Вы хотите выводить там то, что после ? (/users/login?q=1), то для этого нужно использовать res.query

Потому что update ушел, но ваш текущий объект никто не обновлял. Судя по ответу от апдейта изменение произошло. Просто теперь Ваш текущий объект устарел и его надо снова запросить из базы, чтобы он стал актуальным.

Не совсем понятно что за "мобильный банк". Если именно банк как полный аналог аналогичного оффлайнового, то открывать свою конторку - затруднительно. Требуется получение лицензии от ЦБ РФ на осуществление финансовой деятельности (которую получить судя по требованиям не так просто) + разрешения различных бюрократов (количество и набор зависит от того какие виды услуг Вы собираетесь оказывать). И вроде Вам потребуется внушительная сумма для обеспечения деятельности в каждый момент времени (т. е. в самом начале, до получения первой прибыли Вам надо будет иметь N миллионов рублей). Ну и управлять всем этим программист не сможет, нужны аналитики, финансисты и т. п. Т. е. тут явно лучше выступать "прокси" к существующему банку добавляя свою маржу.

1. Для системных тулов, мат. вычисления, веб
2. Множество готовых батареек, качественные веб-фреймворки, живое и дружелюбное сообщество
3. Если мнение авторов питона - на сайте, мое - замечательный синтаксис, соотношение "скорость разработки - качество кода - скорость выполнения" одна из самых высоких
4. Сегодня - питон (много работы, высокие зарплаты). Завтра - скорее всего java (очень активно идет развитие стека typesafe и, мне кажется, что в будущем он займет свою довольно внушительную нишу в веб разработке. Но это завтра может настать очень не скоро, если вообще настанет. Ну и это все таки не для веб студий и не для сайтов-визиток вариант. Проекты сложности выше средней с долгосрочной поддержкой). RoR - работы меньше, оплата еще выше. Пхп - работы горы, зарплаты намного меньше. Но вообще трудно сказать. Есть еще nodejs (развивается гигантскими скачками), но не могу про него ничего сказать толкового. Работы под него довольно много, но как изнутри не знаю.
А вообще сейчас набегут Рубисты, Явисты, Пхпшники и начнется холивар, поэтому надо текать ) Изучив любой из php\python\ruby на достаточном уровне и выдавая качественный код Вы будете востребованы как специалист еще довольно долго.

Все запутано, но судя по всему Django ведет себя верно: Вы удалили все миграции и теперь джанго думает, что миграций нет (и мало того они не накачены, так как Вы почистили таблицу). Именно поэтому она создает миграцию с create table, а не alter table. Как вариант исправления - восстановить миграцию, которая создает таблицу без добавленных 3х полей: можно удалить 3 поля из модели, создать миграцию, затем добавить их и создать вторую миграцию, добавить информацию о первой маиграции в django_migrations (как будто она накачена) и затем накатить через migrate вторую миграциюю.

А в чем сложность? Камера статична? фиксируете фон, разделяете область, снимаемую камерой на 2 области. Подбираете размер, после которого объект становится автомобилем. Получаем следующий алгоритм: вычитаем фон, бинаризируем получившийся результат (до этого возможно фильтруем с применение пространственно-временного фильтра, т.е. не только по текущему кадру усредняем, но и по соседним. Это позволит избавится от шума, дождя, снега, летающих насекомых), находим объекты, который больше определенного порога (чтобы отделить машин от собак и людей), смотрим как меняется положение объекта. Если из области 1 в область 2, то въехал, наоборот - выехал. Проблемы начинаются, если камера фиксирует сразу несколько автомобилей, которые могут перекрывать друг друга при движении и т.п. Тут уже необходим трекинг движения автомобиля + метод отделения одного автомобиля от другого. Ну а после реализации начинаем подбирать параметры: может ли автомобиль проехать весь кадр за 1 секунду. если не может, то все что это осуществит находится явно ближе к камере (птицы, насекомые) и нас не интересует.

Вы задаете более-менее правильные вопросы, но на них нет правильных ответов. Каждый случай очень индивидуальный и кратким ответом тут не обойтись, тут нужны лекции с тоннами теории. Я в свое время писал игры: php (api) + flash (клиент) + C++ (сервер) + mysql (база данных) + memcache (кеш), php (api) + python gevent (сервер) + mongodb (база данных) + redis (кеш) + html5 (клиент), nodejs (сервер) + html5 (клиент) + redis (кеш) + postgresql (база данных). Все они были довольно проивзодительными. Такое разнообразие технологий отчасти обуславливалось моим любопытством (проект на nodejs писал для себя).
В целом пытаясь ответить на Ваши вопросы:
1. Не совсем понятно что Вы имеете ввиду. Уточните вопрос.
2. Лучше всего передавать на сервер все действия клиента и обсчет производить на сервере для невозможности подделывания результатов действий, но это приводит к возрастанию нагрузки на сервер. Протокол - мне нравится bson с готовыми библиотеками, понятным форматом и небольшим размером. Но опять же его я использовал только во втором проекте, в остальных местах я создавал свои велосипеды, которые для конкретных случаев были наиболее эффективны (в моем представлении)
3. В базе хранить все, что не должно пропадать между играми (условно говоря после выключения сервера ;)), в оперативной памяти дублировать все в идеале (для избавления от операций чтения с диска).
4. Зависит от потребностей. Postgresql\mysql - более традиционны. Mongodb - модная ) Если Вы понимаете, что в Вашей игре вы можете пережить ограничения mongodb (к примеру отсутствие транзакций) - юзайте его, очень удобен для хранения игровых состояний. Если не уверены - используйте традиционные реляционки.
5. Кеширование по сути и есть перемещение данных из БД в оперативную память. Причем перемещается таким образом, что скорость выборки из оперативной памяти не зависит от количества данных. Это так называемые хэш-таблицы.

В общем, без обид, но судя по Вашим вопросам Вам надо очень серьезно подтянуть теорию, прежде чем браться за серьезную игру. Писать серверную часть на С++ - круто, если Вы его знаете на отлично. В целом большого профита Вы не получите, так как скорость С++ проявляется в числодробилках. А игровой сервер - в основном операции чтения\записи, которые будут одинаково выполняться на практически любом современном языке и их скорость больше зависит от построенной архитектуры.
Мои рекомендации: читать про блокирующие\неблокирующие сокеты, многопточность, структуры данных, паттерны проектирования, оптимизация запросов (включая нормализацию и денормализацию данных), кеширование. Параллельно с этим можно делать простенький чатик постепенно улучшая и оптимизируя его. Таким образом Вы приобретете и теорию, и практику. После этого можно сделать какую-нибудь простенькую игру.

В настройках подключения к СУБД в джанге укажите 'ATOMIC_REQUESTS': True и все Ваши запросы будут оборачиваться в транзакции