Сергей Еремин

по индексу...
state[len(state)-1] = something
Конечно, если state не пустой массив...

Если данные не за одни сутки и нужно получить данные за весь период, то как-то так:

SELECT
  DATE(table.dattim) AS DD,
  HOUR(table.dattim) AS HH,
  AVG(table.value) AS AVG_VALUE
FROM table
GROUP BY DD, HH
ORDER BY DD, HH

Последние версии MySQL и MariaDB не дают подключать клиентов под root. Зайти под root можно только из клиента запущенного от sudo. Следовательно:

1. или запустить Workbench из под sudo (не вариант);
   
2. или создать в пользователя с правами на всё (эквивалентные админским, вход делаем sudo mysql -u root) и уже после коннектиться из workbench от имени этого пользователя.
   

Гуглится, что не хватает:

EMAIL_USE_SSL = False
DEFAULT_FROM_EMAIL = EMAIL_HOST_USER

или даже:

EMAIL_USE_SSL = False
SERVER_EMAIL = DEFAULT_FROM_EMAIL = EMAIL_HOST_USER

И еще, возможно у тебя двухфакторная аутентификация, и тогда твое приложение не авторизовано... читать тут: https://support.google.com/accounts/answer/6010255 ... тогда нужно или отключить двухфакторую авторизацию, или приложение следует подписать и указать в сетингах ключи EMAIL_SSL_CERTFILE и EMAIL_SSL_KEYFILE ... или использовать не gmail, а еще что-то...

Кроме того, чтобы не падало по таймауту -- поставить исключение на это событие, и/или использовать в сетингах EMAIL_TIMEOUT

P.S. Оправка почты из приложения -- медленная штука. Даже если ничего не падает -- пользователь замечает подтормаживание (2-3 секунды и больше). Так что почту лучше отправлять асинхронно или в параллельном потоке. Например, с помощью модуля django_background_tasks ...

Судя по принтскрину, в таблице для разных столбцов используются разные кодировки. Проблема может быть в этом. Не знаю, поможет это в твоем случае, но стоит попробовать:

Сделай дамп базы. Открой его в текстовом редакторе. Глазками посмотри что у тебя в тех полях которые идут умляутами и прочими квадратиками и вопросиками. Попробуй разобраться где какая кодировка образовалась и совпадает ли она с тем, что указано при создании таблиц и полей (вполне подходящий инструмент FAR Manager, в нем можно менять кодировки при просмотре и редактировании. Напиши скрипт, который унифицирует кодировки при создании таблиц и полей, а так же сделает перекодировки значений полей при их заполнении данными. Если данных в табличках не много -- все можно даже руками сделать в текстовом редакторе.

После залей этот исправленный дамп на сервер.

Придумать себе мини-проекты, сделать суперски и выложить в паблик. Никого не интересует, что за проекты. Можно сделать лендинг по продаже зонтиков для рыб, одностраничник пятых ног для собак или агрегатор по аренде и сдаче слонов для свадеб в стиле Болливуда... В таких безумных проектах даже больше креатива можно показать и работодатель/наниматель уж точно обратит на них внимание...

Тут посоветовали django-cleanup -- это действительно хорошее решение, но когда в каких-то моделях нужно удалять, а в других не нужно, или даже разное поведение с файлами в разных местах (где-то удалять файлы, а где-то оставлять), то есть другое решение:

Допустим есть модель:

class tb_icons(models.Model):
    image = models.ImageField(max_length=128, verbose_name=u"картинка")
    # ...
    # ...

Если хочешь удалить запись из таблицы tb_icons и сопутствующий файл из image делаешь так (например, для удаления первой записи):

tb_icons.objects.get(id=1).image.delete(save=True)
tb_icons.objects.get(id=1).delete()

Соответственно если save=False файл удаляться не будет.

Есть батаерйка django-background-tasks для работы с фоновыми задачами. Очереди хранятся в основной базе, можно через стандартную django-админку управлять фоновыми задачами и пр. У меня в продакшене почти уже год. Порядка 10 млн. задач выполнено. Полет нормальный...

вот отличный слайдер с очень гибкими настройками:
https://github.com/kenwheeler/slick
Много раз использовал. может всё!

Надо посмотреть как часто игроки сморят на рейтинг и попробовать организационно решить. Например отвязать рейтинг от очков в игре и ввести "магический" прогресс-параметр (темп набора очков) . Тогда, по сути, точно ли ты посчитал место в рейтинге или нет -- пользователю проверить уже невозможно. Кроме того, можно предположить, что те кто с 1-го по 1000-ое место, интересуются своим рейтингом более серьезно, чем те что с 100000-го по 500000-е... И тогда простор и раздолье, как все можно реорганизовать. Например, раздели пользователей на группы -- Гуру, Профи, Салаги, Микроорганизмы (причем поделить можно по частоте обращений к рейтингу) -- для каждой группы своя таблица (можно даже в БД на отдельной ноде), а в таблицу пользователей добавь указатель к какой группе он принадлежит... Соответственно очки пиши в обе таблицы (это быстро), но индекс будет только на той таблице, что поменьше... При запросе рейтинга показывать пользователю, место в рейтинге только в его группе, а делать "большую сортировку" и раскидывать по группам -- раз в день во время низкой активности...

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

Такой как на картинке DVI -- х.з. А вот если вокруг плоского штыря слева есть еще четыре шпырёчка -- значит в DVI есть и аналоговое дублирование сигнала. Ее и используют.

Проверь, что присваивается в STATIC_ROOT . Часто на хостинге статика хранится совсем в другом месте и приходится задавать STATIC_ROOT руками. И даже больше, если статика хитро разбросана по разным серверам, еще и web-сервер настраивать чтобы он по нужным правилам проксировал запросы в нужные места.

Это никак не влияет на СЕО. Поисковики давно научились отличать контент от навигации. А уже если сайт на каком-то стандартной CMS, то и подавно.

На счет разных шапок сайта для постов и страниц пейджинатора -- нужно знать какая CMS и нужно ли эту шапку подбирать под контент (или теги) или просто случайную шапку из набора выбирать. Если второе -- совсем просто, если первое -- нужно хорошо разбираться в структуре CMS и движка сайта и писать.

Для хранения справятся log-файлы... Ровно как и MySql, mariadb или postgresql ... или KV ../ да как угодно хранить можно.

Вопрос: что после с этими сохраненными данными делать и как их обрабатывать. И в зависимости от хателок будет вырисовываться архитектура и можно выбирать подходящую под задачу базу.

вот так у меня работает:

server {
    ...
    ...
    ...
    ...
    location / {
        root        /web/sites/internal.onclinic.local/www;
        try_files   $uri $uri/ /index.php;
        }
}