Я пользовался немного btrfs 4 года назад. Активно использовал snapshots. В какой-то момент пошли глюки. Детали уже не помню, и данные не потерял, но глюки были довольно серьезными. Как-то разочаровался немного... Жду, когда исправят ошибки, но регулярно читаю о серьезных багах. Вот только недавно были обнаружены какие-то серьезные баги в реализации RAID. Ссылки не коплю, просто лично для меня это отодвинуло срок принятия btrfs еще на год или два... И вообще, ощущение, что ей как-то спустя рукава занимаются.
Я пофигист и считаю что все в жизни предусмотреть невозможно. Пытаться от всего застраховаться - верный способ к добавлению лишнего стресса в жизнь. Но это мой подход.
Зато если снимать деньги раз в квартиал, то $240 в год можно экономить на комиссиях Upwork. Немаленькая сумма.
Upwork существует более 10 лет и выжил всех своих конкурентов. Конечно, они очень странная контора, и чем дальше, тем хуже. Но вообще, да, особо не парюсь.
По поводу санкций: если под них попадет работа на Upwork, то по-любому будет очень хреново, а деньги вывести можно будет скорее всего. Вроде ведь крымчанам отдали деньги, хотя и заблокировали аккаунты.
Ну, в принципе, раз в месяц можно пережить, конечно. Но я всерьез задумываюсь о переходе на поквартальную оплату, потому что все равно напрягает немного это ожидание и необходимость пинать. Правда, не знаю, совместима ли поквартальная оплата с законодательством РФ (в частности, я плачу алименты, что еще сильнее все затрудняет).
Не пишу на PHP, но тут вроде приведение к типу int используется. Соответственно, SQL-инъекция сильно затрудняется. Это не отменяет того факта, что надо использовать prepared statements или ORM, конечно, особенно на уровне понимания автора, который, судя по вопросу, просто копи-пейстит случайно где-то найденный код (если было бы хоть малейшее понимание, то не было бы и такого вопроса).
Все равно затрудняюсь, потому что не использовал никогда serializers.serialize. Такие вещи по уму делаются через какую-либо реализацию REST типа DRF, tastypie.
Если нужно сделать один раз, то еще варианты:
1) посмотреть/показать значения переменных в месте, где происходит исключение. На странице с ошибками Django их можно увидеть под заголовком local variables. В частности, что присвоено переменной obj.
2) поставить точку отладки в этом месте и пройтись отладчиком
3) почитать документацию по serializers.serialize, хотя вряд ли он является частью публичного интерфейса Django
4) сериализовать вручную типа:
response = {
'work': work.name,
'images': [i.url for i in work.workimage_set.all()]
}
return json.dumps(repsonse)
Да, внешний вид заголовков и других элементов страницы. Страница ведь не может быть сделана из исключительно уникальных элементов (допустим, каждый заголовок на каждой странице имеет уникальное имя, уникальный шрифт и уникальный размер), это было бы слишком сложно и для понимания, и для разработки. Поэтому определяются основные строительные блоки и их внешний вид. Какими должны быть заголовки разных уровней, абзацы, списки, и т.д.
Alina94: Понимаете, любой тег - это в настоящее время просто набор букв и цифр (упрощенно). Но для общего удобства принято обозначать заголовки тегами h1-h6 по важности. Для удобства понимания кода всеми: от людей, которые разрабатывают сайт, до ботов и поисковых систем, парсящих его. Так-то вы можете использовать хоть теги zagolovok1-zagolovok6. Просто это будет непонятно всем.
Кроме того, существуют различные фреймворки, например, bootstrap. И если вы хотите, чтобы сайт отображался так, как задумано создателями фреймворка, тоже надо использовать правильные теги.
Грубо говоря, это как коробки с содержимым. Вы можете на коробке с носками написать: «Рубашки». Никто вас за это не накажет и нет никакого способа заставить вас писать правильно. Но всем будет удобнее, в первую очередь вам, если на коробке с носками писать «Носки», а на коробке с рубашками — «Рубашки».
Если вам сложно это понять, то используйте стандартные теги, потом со временем придет понимание что к чему.
Я путешествую и работаю. Поэтому в Крым заезжать боюсь. Потом доказывать, что не верблюд, с неизвестной вероятностью, что Upwork поверит или вообще станет слушать.
Ну и надо видеть, что выдает браузер в консоли ошибок при запросе статики, что при этом пишет Django и Apache в логах и консоли. Без этого отлаживать сложно. А если посмотреть на ошибки и логи, то 95% вопросов отпадут сами собой.
minaev007: Значит что-то не так с settings.py. В документации по staticfiles все разжевано. Как работает в development-режиме, как работает в production-режиме, даже по-моему, какие настройки веб-сервера должны быть.
Ни разу не было проблем с этим. Не видя всех настроек помочь невозможно, но уверен, что после прочтения документации вопросов больше не будет. Лучшей документации, чем у Django, нет ни у кого. Там все решения разжеваны простым понятным языком.
minaev007: Дык, если вы почитаете документацию по Django, то во время работы runserver, приложение staticfiles автоматически собирает статику из нужных каталогов. А вот в production-режиме, надо собирать вручную при помощи collectstatic в единое место, откуда уже будет раздавать веб-сервер (nginx или apache).
Вообще, смотрите в development-консоли, какие ошибки отдает веб-сервер, и в логах Apache, где он ищет статику, и почему не находит. Это ерундовая проблема.
Ну да, уже три года как. Если не через VPN работать. Да и через VPN, говорят, банят. Учитывая, что по отзывам суппорту Upwork практически наплевать на проблемы клиентов, проверять на своей шкуре не хочется. Бан-то пожизненный
В общем, правильно сначала разобраться в самых основах как Linux (кто такие пользователи, каталоги, файлы, как работают команды su и sudo), затем в основах PostgreSQL. Слепое копирование и комбинирование команд - это плохой способ изучать что-то и делать работу. Понимаю, что хочется побыстрее. Но если вы банальную операцию не можете сделать, которую опытный пользователь, разбуженный в 4 утра, не задумываясь сделает, то все же надо начинать с основ.
Вот именно, что вы не понимаете разницу:
1. между пользователями системы и пользователями базы данных
2. между именем базы postgresql и именем файла с базой
и т.д. и т.п.
Кроме того, sudo su - postgres - это какое-то масло масляное. Вам для начала надо понять, что вы вводите. Судя по этой команде, вы не понимаете, а просто копируете откуда-то. Правильно:
1. либо su - postgres
2. либо sudo -u postgres -i
Вместе это масло масляное. Кроме того, ваша команда изменила текущий каталог, поэтому вам надо привести полное имя для файла. Ну и кроме того, лучше psql запускать с тем пользователем (-U пользователь), кому должна принадлежать база и данные в ней. Пользователь postgresql - это как root в системе, только в PostgreSQL. Да, системные пользователи и пользователи PostgreSQL - это тоже разные сущности.