Виталий Ф.

api яндекс карты тебе в помощь..

Необходимо устроиться на работу.

django-cacheops

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

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

Не надо верстать таблицу дивами. Таблицы верстаются таблицами.

Максимально приближенный вариант получится, если использовать табличные значения свойства display. И в итоге разметка будет только более громоздкой, ибо вместо соответствующего тега придется использовать див с соответствующим классом. И троллейбус из буханки на фоне этого будет выглядеть куда более полезным изобретением.

Можно накидать и на JS, но все равно выйдет ад и содомия.

Выкиньте. Нахер. EX60.
Это адовое старьё с убитыми тормознутыми дисками класса SATA-2.

Можно попробовать заменить запись на url рабочей картинки. Если заработает, то проблема в картинке или не верном url

Go

Зависит от кучи параметров (плюшки, график, количество самой работы, проект, само собой - скиллы).
Вообще в Москве джангисту получать 100 получать вообще не проблема на полную ставку. Тот же островок предлагает от 120 до 170. В регионах - поделите на 2, что ли.
Ну и плюс учтите, что в IT зарплаты рублевые сейчас будут расти (в противном случае вся толковая разработка уйдет туда, где баксы зарабатывают и индексируют по курсу).

Как и везде от 25 000 до 100 000 тысяч рублей в месяц, в зависимости от навыков, производительности и уровня ответственности.

1) У Вас в search.period_start и search.period_end всегда текущая дата_время "new Date().toISOString()", поэтому ничего и не "ищет" ("new Date().toISOString(req.query.period_start);" - так не работает).
Проще с клиента тогда присылать преобразованные даты (.toISOString) и на сервере подставлять как есть.
2) В базе даты лучше хранить в Date-формате, а не в текстовом.

Обычно удобнее что-б ключи были фиксированные - не нужно гадать/перебирать, что-б получить значение.
Проблема может возникнуть если вы в будущем добавите ещё по стране в каждый элемент или т.п.
Памяти это (почти) не сэкономит. Проблем с хранением не возникнет.

Если расширять не планируется и хорошо подходит под текущие запросы, то никаких проблем.

Оукей. давайте возьмем ваш пример с fl.ru + чаты.

mongodb - хипстерская база данных. Для проекта типа fl.ru я бы пожалуй не использовал оную (не потому что монга отстой а потому что я лично не вижу в использовании оной смысла в контексте проекта типа fl.ru. Нам не нужен шардинг, реплекация реализуется нормально на любой нормальной RDBS, документоориентированность не нужна, хотя при грамотном подходе можно было бы реализовать неплохие агрегированные коллекции и оптипизировать селекты... Для себя не нашел у монги ни одного плюса перед RDBS типа PostgreSQL). В любом случае если вы не оставляете выбор - тут у нас будут храниться все данные. Придется потратить время на то что бы избавиться от желания что-то заджойнить и реализовать map/reduc-ы для обновления связанных коллекций. Но зато это будет так по хипстерски!

То есть если у вас есть куча однотипных запросов с кучей джойнов данные для которых обновляются редко а выборки происходят часто, то тогда можно вооружиться монгой а делать коллекции как агрегации этих выборок. Если вы вставляете референсы и пытаетесь эмитировать джойны в монге то значит вы сделали не правильный выбор основного хранилища данных). Правда денормализовать данные можно и с RDBS....

sphinx - поисковой индекс. То есть если мы должны реализовать вменяемый поиск (например по описанию вакансии) - то стоит его заюзать. Сфинкс не самый дружелюбный зато один из самых быстрых поисковых индексов. Хорошо интегрируется с MySQL и подобными и если сравнивать с ElasticSearch из коробки чуть лучше дружит с русским языком. Но опять же у эластики свои плюшки. Некоторые оной заменяют монгу так как по большинству фич в плане хранилища данных они совпадают.

redis - мы там вроде чатик делали. Помимо того что redis это хорошее key-value in-memory хранилище, которое к тому же может обеспечить нам надежность хранения данных (мэпится на файловую систему еще), оно так же поддерживает pub/sub. То есть чисто теоритически мы можем не добавлять в стэк штуки типа ZeroMQ и прочие *MQ для реализации авторизации и связи приложения чатика и основного приложения (вдруг у нас чатик будет написан на go/node.js/erlang).

memcache - вот тут стоит подумать нужен ли он если у нас есть редиска. Раньше для жирного кеша выбор был очевиден - memcached, так как reddis в те времена не поддерживал кластеризацию. Сейчас же по возможностям редиска далеко впереди. Так что даже то что memcached чуточку быстрее (но жрет больше памяти и не поддерживает авторизацию к примеру из коробки) не должно стать поводом для использования оного. Но я если честно redis в кластерах не использовал и ничего говорить не могу, а memcached испытан годами.

Хранить в отдельной коллекции. Если вы будете хранить в одном объекте то вам нужно следить за размером записи, в монго размер одной записи не может превышать 16 mb.