А ну что делаем?

А ну что делаем?

Снимаем штаны и бегаем

Кто работает удаленно, ваш экспириенс?

ПолуJun, даже 0.23

tags = ListFilter(name='tags__id') Типа такого в классе фильтра

Thanks

Если кто-то пишет DRF + SPA, вы вместе или в отдельных репозиториях держите front-end и back-end? И почему?

Если кто-то пишет DRF + SPA, вы вместе или в отдельных репозиториях держите front-end и back-end? И почему?

Разные разработчики, языки, задачи. Зачем в одном?

Я в разные вынес, но вот что подумал. У меня frontend может убежать вперед по развитию. Например, на backend не реализована какая-то функционалльность, а на frontent уже все для этого готово. Вот не пойму, как синхронизировать это все? Когда были джанго шаблоны, тут было проще с этим

или просто делать по версиям в обоих репозиториях и выкатывать на прод, когда и на фронденде и на бекенде все для текущей версии готово7

Разные разработчики, языки, задачи. Зачем в одном?

+

А если в соло пишешь все и вся, то удобнее в одном наверное

А если в соло пишешь все и вся, то удобнее в одном наверное

тоже в разных, ибо человек пишет на реакте и паблишит в свою репку

Ох уж эти SPA

хз, мне вот наприер пишу на "фронтэнд" и сразу вдруг надо поправить код на бэкэнде, ладно.

бросать надо это дело.. и пилить только под мобилки

я на обоих фронтах буду участвовать, но вообще там будут разные люди. Мне не до конца понятно, как выкатывать на прод, чтобы задача была выполнена и на бекенде и на фронтенде. И не получилось так, что на фронденте уже есть допустим новая вкладка, а на бекенде ничего не готово. На прод можно по версиям. А вот если staging, у нас например до разделения была непрерывная интеграция. Как щас ее настроить, хз

А что мешает в одном репе вести и пуллить туда могут и бекенд и фронтэнд разрабы

и у себя смогут дев сервак поднять, _

фронтенд разработчик будет тянуть и каждый раз мержить код с бекенда получается

и бекенд будет тянуть SPA каждый раз

Ну и ладно есть крупные проекты с десятками разрабов и люди мергят постоянно

хотя, можно игнорить наверное обоим сторонам не интересующую чатсь

Вы можете ветки делать, а потом сливать, чтобы не мергить каждый адейт в 1 строчку

developer_branch > master > release

developer_branch > master > release

ну у меня именно так процесс и устроен

Не знаю лично я склоняюсь к тому что 1 проект - 1 реп, в котором все части и бек и морда

ну и тестами покрыть не забыть)

у всех лицуха дэ?

ты не так спрашиваешь)) спроси "Кого из вас зовут lan yu?"

во фри версии есть возможность remote host? Чёт не вижу.

Всё хуйня, давай научу ломать

Про

Всё хуйня, давай научу ломать

это значит нет?

это значит нет?

Да

Да ломать то и сам умеею)

Я правильно понял, что единственный способ не палить важные данные из settings.py это просто не заливать settings.py?

Я правильно понял, что единственный способ не палить важные данные из settings.py это просто не заливать settings.py?

.gitignore?

Ну да

Я тоже так это понимаю. Интересно услышать лучшие практики на этот счет

Без settings.py твой проект бесполезен в git

а лучше 16гб

ну хз-хз, мне пока 8 гигов хватает, на ide, хром, винду в виртуалке ич чего нить еще

local_settings

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

или .env юзать

важные настройки лучше выносить в переменные окружения

важные настройки лучше выносить в переменные окружения

а почему?

https://github.com/hellpirat/django-cookiecutter-boilerplate/blob/master/%7B%7Bcookiecutter.project_slug%7D%7D/env.example вот например:)

если используете докер, то docker run ..... -e DATABASE_PORT=5432

а почему?

надежнее

и гибче

это не очевидно, переменные окружения всем видны ведь

и под разные окружения легко запилить

а на файл я могу права навесить

на файл в любом случае надо

а вот запускать что то менять удобнее

просто указываешь другие при запуске контейнера

А если проект большой и личных настроек куча. Проще их хранить в файле. Вообщем должны быть просто отдельный файл с использованием которого прод запускается, не важно докер или не докер Просто``env = DJANGO_SETTINGS_MODULE=application.settings.production`` в uwsgi например

А в этом файле просто делаешь from settings import * + свои личные настройки

Ну и естественно его в gitignore

Ну и естественно его в gitignore

а зачем? казалось бы этот файл должен ток на прод сервах создаваться

на серверах разработки тоже могут быть локальные настройки как это не странно

на серверах разработки тоже могут быть локальные настройки как это не странно

но там ведь тоже можно создать файлик с настройками и договориться что низя делать пуши с дев сервера

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

Вообщем-то это стандартная практика

ERROR: S client not available

Я правильно понял, что единственный способ не палить важные данные из settings.py это просто не заливать settings.py?

не гоните. сенситивку просто выносите в settings_local.py, который импортируется из основного и не коммитится

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

я как раз за это топлю, но не понимаю, почему надо что-то добавлять в gitignore

чтобы случайно не закоммитить

ну так локал сеттинг все равно пихать в gitignore, нет?

падажжжите

локал пихать

вот у меня есть дев настройки, почему я не могу их хранить в stettings.py а потом переопределять в production_settings?

а settings.py запомитить

закомитить*

храни дев настройки в сеттингсах, у разраба проект должен работать из репы сразу, а дополнительные настройки переопределяй в локал сеттингс

я как раз за это топлю, но не понимаю, почему надо что-то добавлять в gitignore

я вообщем-то наоборот сказал, ну да ладно)

огонь, теперь понятно стало

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

У вопросу о том как хранить логины пароли и тд. В чем минусы отдельного py файла который вынесен в гитигнор, взамен лежит семпл этого файла

семпл пусть лежит, чтобы новичок мог понять, что сетить

У вопросу о том как хранить логины пароли и тд. В чем минусы отдельного py файла который вынесен в гитигнор, взамен лежит семпл этого файла

Если взломать юзера www-data, например, то можно этот файл прочитать. Если передать пароли через env, то нужны права на конфиги uwsgi или systemd или что там, а их, этих прав, может не быть

смотри за руками, веб сервер с твоим проектом работает от www-data, так какая разница?

Интересно как ты взломаешь юзера www-data без возможности заходить в консоль и даже без пароля)

т.е. если ты ломанул, то окружение ты точно видишь

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

т.е. если ты ломанул, то окружение ты точно видишь

Кейс: ты можешь прочитать любой файл от юзера ввв-дата. Не запускать, а только прочиьать

Через какую-нибудь уязвимость в обработке картинок, например.

Что-то там было с ffmpeg пару лет назад

Возможность подпихнуть имя файла куда-то, не помню.

Черт, телефон умирает

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

Гайс, чет не получается postgresql подрубить. Вроде все по гайду делаю https://www.digitalocean.com/community/tutorials/how-to-use-postgresql-with-your-django-application-on-ubuntu-14-04 Но при миграции получаю FATAL: password authentication failed for user

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

Сисьемд юнит может принадлежать руту и с правами 600

Это очень все сомнительно

Это очень все сомнительно

Это не панацея, а защита ото некоторого вектора атаки.

Гайс, чет не получается postgresql подрубить. Вроде все по гайду делаю https://www.digitalocean.com/community/tutorials/how-to-use-postgresql-with-your-django-application-on-ubuntu-14-04 Но при миграции получаю FATAL: password authentication failed for user

ну тебе говорит что неверный пароль