Рома Зварич

Попробую угадать как работает этот TinyJPG:

1. Берется некоторое начальное значение уровня сжатия (не так важно какое).
   
2. Задается некоторый целевой порог допустимых потерь (эта константа предварительно обкатывается в A/B тестах).
   
3. На каждом шаге итерации высчитывается среднеквадратическое отклонение значений всех пикселов сжатого изображения (от оригинального), и сравнивается с пороговым знанием.
   
4. Бинарным поиском находится минимальное значение уровня сжатия при котором выполняется условие (3).
   
   

Те, кто не заметил разницы в A/B тестах, не заметят разницы и в любых изображениях, сжатых по этому алгоритму.

Если вы не используете пространственную БД то самое время на неё перейти.
Сравнивает две геометрии и проверяет находятся ли они ближе чем указанное число единиц - postgis.net/docs/ST_DWithin.html

mysql check if point is in polygon

У нас в компании 80% мониторов - 1280х1024

Это те кто не гамится и в основном работает с текстом, например я )

Если следовать вашей логике, то к 2020 году мониторы обязаны быть у всех во всю стену и сенсорные. Проблема с ожирением будет побеждена... попробуйте попрыгать у такого монитора целый день ))

На счёт другого - у Яндекса лучше документация как по мне.

Сформируйте список желаемых разделов и дайте задание реализовать для них вывод результатов по конкретным параметрам.

к мечте ближе друпал. к платному проекту - 1с

Wordpress c плагинами вполне себе подойдет. Отображение на карте решается с помощью google API или yandex API.

Обычно разделяю предметные области проекта на отдельные приложения. Если какая-то область слишком обширна, то в папке приложения создаю отдельные приложения для подобластей. Для каждого приложения - своя папка templates: это позволяет при большом количестве приложений не путаться в разросшейся иерархии директорий. Кроме того, отправляю всю обособленную статику в директории static каждого приложения: иногда для работы интерфейса пишу JavaScript приложения на Marionette - всегда знаю, где искать нужную кучу скриптов.
Для примера: пишем проект для дилерской сети по распространению и продаже автомобилей. Получается так:

./project_name/
./project_name/settings.py
./project_name/urls.py
./project_name/static/
./project_name/static/css/...
./project_name/static/js/...
./project_name/static/imgs/...
./dealer/
./dealer/admin.py
./dealer/models.py
./dealer/views.py
./dealer/urls.py
./dealer/templates/
./dealer/templates/dealer/
./dealer/templates/dealer/list.html
./vehicles/
./vehicles/admin.py
./vehicles/models.py
./vehicles/logistics/
./vehicles/logistics/models.py
./vehicles/logistics/admin.py
./vehicles/logistics/views.py
./vehicles/logistics/urls.py
./vehicles/logistics/templates/
./vehicles/logistics/templates/logistics/tracking.html
./vehicles/logistics/static/
./vehicles/logistics/static/js/app/tracking/
./vehicles/logistics/static/js/app/tracking/main.js
./vehicles/logistics/static/js/app/tracking/app.js
./vehicles/logistics/static/js/app/tracking/...
./vehicles/sales/
./vehicles/sales/models.py
./vehicles/sales/admin.py
./vehicles/sales/views.py
./vehicles/sales/urls.py
./vehicles/sales/templates/
./vehicles/sales/templates/sales/invoices.html
./vehicles/sales/static/
./vehicles/sales/static/js/app/invoices/
./vehicles/sales/static/js/app/invoices/main.js
./vehicles/sales/static/js/app/invoices/app.js
./vehicles/sales/static/js/app/invoices/...
./static/
./media/
./templates/
./templates/base.html
./templates/...

Далее по аналогии. Если нужна какая-то мелочь - отправляем ее в соответствующее "корневое" приложение; если мелочь становится более серьезным куском функционала в рамках той же предметной области - создаем ей отдельное приложение внутри уже существующего. Все, что выходит за рамки предметной области - новое "корневое" приложение.

Блин, да это же джанго, он сам явно подталкивает к одной структуре приложения.
Одно приложение на 1 логическую и независимую часть сайта. Например, интернет-магазин должен включать в себя каталог продукции и функционал для заявок. Потому что они взаимосвязаны. А вот новостную часть на этом сайте надо выносить в отдельное приложение, так как новости обычно почти не связаны с заказами и товарами как таковыми.
Ещё в каждом приложении можно создавать папку static, куда класть все статические файлы. Но так обычно поступают разрабы "плагинов" для джанги. В рамках сайта можно коласть в 1 папку static в корне проекта, но разделяя js и css файлы (чтобы вёрстка не было в 1-м суперогромном css файле, в котором хрен чо найдёшь). Потом сборщики должны всё собирать и минимизировать.
Шаблоны раскидывай по папкам, соблюдая иерархию. Т.е. если есть приложение shop, то в корневой папке templates создай layout.html, а все шаблоны магазина клади внутрь templates/shop, наследуя. Также можно хранить шаблоны внутри приложения, но опять же, это обычно используют разрабы "плагинов", хотя сам принцип хорош.