Вот вы говорите "это не прописка". С одной стороны я согласен - в законе уточнений нет, просто "постоянно проживающий в РФ". С другой - реальность вроде как такова, что многие органы и него прописку (регистрацию по месту жительства) считают основным признаком. Возьмите временный ввоз авто на европейских номерах в РФ гражданином РФ - если вы по дурости или по незнанию покажете таможеннику ваш внутренний паспорт с действующей регистрацией, то есть подозрение, что без пошлины вас не впустят.
Внимание, вопрос - так что же это, если не прописка? В суд пойдете доказывать, что прописка ничего не значит, если вам будут штраф рисовать или пошлину требовать?
Так зачем? Ну если я свой образ использую для своего проекта, все крутится внутри и не торчит наружу, зачем мне самому себе вставлять палки в колеса в виде нерелевантного кода (обновление не относится к прямым зависимостям моего приложения), невоспроизводимых билдов (ну если версии в apt-get install ещё можно запинить, то системные то не особо), увеличения размера образа? А все ради какой-то сомнительной "безопасности"
А может, не стоит выделять "Автоматизатора" в принципе? В нашей компании мы нанимаем инженеров по тестированию. И инженер по тестированию отвечает за качество продукта, а руками он тестит или пишет фреймворки для автотестов — уже его дело. Любой тестировщик должен и руками уметь потестить, и прикидывать, как автоматизировать тот или иной кейс и вообще я стоит ли автоматизировать (ROI).
Не говоря уж про то, что разработчикам тоже неплохо бы про тесты знать, в итоге получаем, что собеседование на разработчика вообще не сильно отличается от собеседования тестировщика. Ну там отклонения туда-сюда, но в целом все перечисленное разработчик тоже должен как минимум представлять
Если бы вы не вставляли какие-то левые видео через строчку и добавили личный опыт, то могло бы быть интересно. А сейчас это просто наглая реклама какая-то.
К сожалению, как «та самая» Опера (на Presto, естественно) перестала развиваться и все больше и больше сайтов рендерила или криво или вообще никак, то в какой-то момент выбора просто не осталось. Ну ок, Огнелис или Хром, все равно не много. А на сегодняшний день ничего толком не поменялось — все равно или Хром[иум] или Огнелис.
Я как-то тыкал в калькулятор баллов для Express Entry, получалось, что если нет семьи, то без оффера или без прям топ-топ IELTS можно даже не пытаться. Наличие семьи же сразу чуть ли не удваивает количество баллов и можно как автор и описал «просто брать и ехать».
Аналогично, 50\50 это определенно многовато, я думаю, идеальным было бы что-то вроде 1-2 недель в квартал. Такой выделенный face-to-face, а в качестве бонуса на сэкономленные деньги от свободных от сотрудников офисов, такие фейс-ту-фейс недели могли бы проводиться в разных офисах (ну условно сегодня в США, в следующем квартале в Германии, осенью на Тайвани и зимой в Мексике, зависит от географии офисов компании). Я думаю, это покрыло бы нужны рабочего личного общения с головой.
У нас в компании (не FAANG, но десятки тысяч сотрудников по миру) сейчас удаленка до сентября (была до июля, но на днях прилетела новость, что продлили). Обещают в апреле провести опрос сотрудников на предмет желаемой модели работы в будущем, в теории упоминался вариант полной удаленки, но есть подозрение, что все-таки так категорично не рискнут и останемся с некой «гибридной» моделью. А вот насколько «гибрид» — это вопрос на миллион. На неделю в квартал я бы с радостью согласился, а какие-нибудь «3 дня в неделю в офисе» — это вообще принципиально ничем от «5 дней в офисе» не отличается имхо. Ибо это сразу глушит такие возможности удаленки\WFH как переезд куда-то, хоть в рамках своей страны, хоть дальше. И если офис условно в центре дорогого европейского или американского города, то ни одним гибридом вида «х дней в неделю в офисе» от необходимости жить довольно близко к офису не деться. А это значит, трата условной трети зп на аренду (если мы про Европу говорим). Принципиально ситуацию изменит лишь «х недель в квартал».
идем в помещение заправки. стоим очередь. говорим: 50 литров. оплачиваем. возвращаемся к машине.
Я тут не так давно проехал множество регионов в РФ и почти везде работает вариант «идем в помещение заправки, из двери обращаем внимание кассира на себя фразой 'Пятую дизель до полного поставьте пожалуйста!', идем заправляться». И только после этого уже стоим нормальную очередь на оплату.
За 5 месяцев и 10к километров попалось ну может две заправки, которые прямо уперто говорили «нет, платите сначала». Так что предоплата тоже бывает разная :)
Оказывается, что плохо работает не ваш код, а функция sample от другого разработчика, которую вы используете.
Так где ошибка-то была? А то вы привели какой-то прямо каноничный пример:
antoshkka:
— Пришел в файл фиксить багу
— (через 5 минут) Ой, кто это писал, что за ужас, поправим стиль.
— (через 15 минут) мда, одним стилем не обойтись, надо капитально рефакторить
— (через 30 минут) вот, теперь хорошо *горд собой и постит статью на хабр*
Тимлид: «antoshkka, как там с тем багом, нашел проблему?»
antoshkka: "*искренне удивлен* Каким багом? *мучительный мыслительный процесс* А, с тем багом! Ой...."
Понятно, что хороший код лучше плохого, но не надо забывать о главной цели-то. И если код не такой уж и плохой (собственно, в исходном коде были косячки, ну магические числа, но ничего серьезного, что бы требовало рефакторинга ASAP, на мой взгляд), то может стоит сначала там тестов к нему написать, например, найти баг и пофиксить, и только потом за рефакторинг браться? Как говорится, Red-Green-Refactor.
И это вы сейчас ведь из РФ такое пишете. Тогда как в РФ с банковской системой все на пару порядков лучше, чем в Европе (конкретно про Германию дальше речь будет, но вообще по всему ЕС, думаю, что-то похожее).
Например, в ЕС самый популярный метод оплаты периодических платежей (квартплата, контракты на домашний интернет и сотовую связь, налог на авто) — это т.н. Direct Debit (иногда рядом есть слово «SEPA»). Это вы «продавцу» выдаете даже не номер карты\CVV (ключ от сейфа), а просто описание и координаты сейфа (номер счета, IBAN). И этого достаточно, чтобы продавец «когда будет время, зайдёшь и сам возьмёшь оттуда сколько тебе надо, чтоб оплатить услугу». Да-да, вы не ослышались — для снятия денег достаточно *публичного*(!) номера счета(!!). Как бы, в теории там еще ваша подпись (ручкой на бумажке или чекбоксик в интернетах) нужна, но мы же все понимаем, что с технической стороны никакая подпись для осуществления транзакции не нужна. И при всей безумности происходящего, местные в этом не то чтобы проблем не видят, наоборот, ратуют «как удобно, не надо самому платить за телефон».
Вставил в блокнот, сохранил как .html — не работает. Если вы пишете/переводите статью о конкретном фреймворке, то, пожалуйста, потрудитесь упомянуть во введении, о каких фреймворках речь.
Окей, начнём с банального — раздача статических файлов. В какой контейнер их класть? В каком контейнере запустить «manage.py collectstatic» и как при этом не наплодить стопицот лишних докер-слоёв?
Вы намекаете, что мне тоже статью стоит написать? Честно говоря, я понимаю, потому что если гуглить «django docker», то во всех этих хипстерских seo-friendly бложиках ни один чел не идет дальше хелловорлда и тему статических файлов не затрагивает. Я сам довольно долго гуглил и спрашивал в чатиках насчет «правильного» способа.
На сегодняшний день я использую один из следующих вариантов:
— Shared volume лишь между контейнерами (но не с хостом, см. SO). Тогда collectstatic пишется в контейнере с джангой и nginx контейнер просто видит папку со статиками
— Если же volume не вариант (например, в Docker Swarm), то можно сделать multistage билд для nginx контейнера. Ну т.е. что-то подобное: FROM python:3.9 as builder
RUN pip install Django
COPY . /app
WORKDIR /app
RUN manage.py collectstatic --noinput
FROM nginx
COPY config/nginx.conf /etc/nginx/config
COPY --from=builder /static /static
— Ну и «плохой» вариант, но в общем-то вполне рабочий для небольших проектиков без сотен реквестов в секунду — используйте manage.py runserver. Тогда вам даже второй контейнер с nginx не нужен. Есть несколько библиотек типа whitenoise, которые в теории несколько улучшают ситуацию с «runserver не для продакшна».
Чуть менее банальное — почти любой Django-проект однажды дорастёт до необходимости использовать Celery, где и как запускать его воркеры?
Не могу ответить, поскольку ни в одном из проектов Celery не использовал, не было нужды. Но есть подозрение, что это может выглядеть как один контейнер, в котором воркеры сами скейлятся как надо (собственно, как uwsgi для того же джанго сам делает).
Ага, а контейнеры тут при чём? Пусть автор просто прогонит установку на чистой системе (да хоть в том же контейнере, лол) и в ридми допишет зависимости, да и всё. В плейбуке, кстати, зависимости тоже прописаны.
Понятно, что хороший автор опишет все, но Dockerfile (как и ваш плейбук, видимо) — это не просто текст, это реальные инструкции, которые должны работать, чтобы проект поднялся. И само средство вынуждает автора описать environment. Лишь один коммент — в каком проценте open source проектов вы видели плейбук (или, например, Vagrantfile?) в репозитории? Сравните с процентом репозиториев, имеющих Dockerfile.
Так изначально его не было, у меня знания тоже не из воздуха появились.
А я до сих пор продолжаю гуглить инфу про докер, но так и не могу собрать что-то пригодное для продакшена ¯\_(ツ)_/¯
Ну видите, мы в одинаковой ситуации, только с разными тулами :) Только в самом начале я пошел гуглить про довер и теперь знаю о докере и применяю его, а вы пошли гуглить про Ansible и применяете его. 1-1 :)
Я говорю о проекте уровня описанного в статье — простой веб-сервис с условным nginx+uwsgi/gunicorn/php+mysql/mariadb/postgre. Бложик или пет-прожект на джанге или обычный монолит на PHP. Какая еще «организация взаимодействия»? environment: {DB_HOST: db} и depends_on: db для зависимых контейнеров? Вот и все «взаимодействие». Ну да, простите великодушно, «тактично умолчал», потому что это три строчки, которые после первых пары раз пишутся на автомате и уже не думаешь даже. Секундное дело. Но зато после этого вы получаете docker-compose файл, который кто угодно может на своей машине запустить, имея из зависимостей лишь, собственно, докер и компоуз. Один клик — и весь сервис поднят. Да, естественно, если вам захочется больше плюшек, health-чеков, определенного порядка запуска контейнеров, дальше будет сложнее, но для описанного в посте уровня простенького проекта ничего этого не нужно.
Не говоря уж про то, что написание Dockerfile это как минимум «правило хорошего тона», по которому можно понять, какие у вашего проекта зависимости. Если мы говорим про питон, то каждая вторая нетривильная зависимость из requirements.txt будет требовать какой-нибудь нативной библиотеки, про которую, естественно, автор не упомянет в ридми. А если вы напишете в докерфайле «pip install -r requirements.txt», то это банальный тест — если оно билдится, значит побилдится и у всех остальных. Не раз и не два такое было, что на хосте вроде работает, а пишешь в докерфайл — опа, оказывается, еще десяток нативных зависимостей надо доставлять (которые на хосте были поставлены неизвестно когда и уж все забыли про них).
Кэп подсказывает, что Ansible playbook у вас написался без проблем, потому что у вас есть опыт в написании плэйбуков. А у меня наоборот — я подобные простые 2-3 сервиса быстро и без проблем оберну в Dockerfile+docker-compose, а вот если надо будет Ansible юзать, то я уйду гуглить на неопределенное время.
Алгоритмическая сложность, О-большое? Не, не слышали?
Вот вы говорите "это не прописка". С одной стороны я согласен - в законе уточнений нет, просто "постоянно проживающий в РФ". С другой - реальность вроде как такова, что многие органы и него прописку (регистрацию по месту жительства) считают основным признаком. Возьмите временный ввоз авто на европейских номерах в РФ гражданином РФ - если вы по дурости или по незнанию покажете таможеннику ваш внутренний паспорт с действующей регистрацией, то есть подозрение, что без пошлины вас не впустят.
Внимание, вопрос - так что же это, если не прописка? В суд пойдете доказывать, что прописка ничего не значит, если вам будут штраф рисовать или пошлину требовать?
После push, естественно, CI на данный PR прогоняется ещё раз.
Аргумент вида "все равно ничего нет, давайте ещё больше неопределенности внесём, какая разница".
Так зачем? Ну если я свой образ использую для своего проекта, все крутится внутри и не торчит наружу, зачем мне самому себе вставлять палки в колеса в виде нерелевантного кода (обновление не относится к прямым зависимостям моего приложения), невоспроизводимых билдов (ну если версии в apt-get install ещё можно запинить, то системные то не особо), увеличения размера образа? А все ради какой-то сомнительной "безопасности"
А может, не стоит выделять "Автоматизатора" в принципе? В нашей компании мы нанимаем инженеров по тестированию. И инженер по тестированию отвечает за качество продукта, а руками он тестит или пишет фреймворки для автотестов — уже его дело. Любой тестировщик должен и руками уметь потестить, и прикидывать, как автоматизировать тот или иной кейс и вообще я стоит ли автоматизировать (ROI).
Не говоря уж про то, что разработчикам тоже неплохо бы про тесты знать, в итоге получаем, что собеседование на разработчика вообще не сильно отличается от собеседования тестировщика. Ну там отклонения туда-сюда, но в целом все перечисленное разработчик тоже должен как минимум представлять
Ну мой коммент о том и был — что как правильная опера отдала концы, выбора не осталось :(
Аналогично, 50\50 это определенно многовато, я думаю, идеальным было бы что-то вроде 1-2 недель в квартал. Такой выделенный face-to-face, а в качестве бонуса на сэкономленные деньги от свободных от сотрудников офисов, такие фейс-ту-фейс недели могли бы проводиться в разных офисах (ну условно сегодня в США, в следующем квартале в Германии, осенью на Тайвани и зимой в Мексике, зависит от географии офисов компании). Я думаю, это покрыло бы нужны рабочего личного общения с головой.
У нас в компании (не FAANG, но десятки тысяч сотрудников по миру) сейчас удаленка до сентября (была до июля, но на днях прилетела новость, что продлили). Обещают в апреле провести опрос сотрудников на предмет желаемой модели работы в будущем, в теории упоминался вариант полной удаленки, но есть подозрение, что все-таки так категорично не рискнут и останемся с некой «гибридной» моделью. А вот насколько «гибрид» — это вопрос на миллион. На неделю в квартал я бы с радостью согласился, а какие-нибудь «3 дня в неделю в офисе» — это вообще принципиально ничем от «5 дней в офисе» не отличается имхо. Ибо это сразу глушит такие возможности удаленки\WFH как переезд куда-то, хоть в рамках своей страны, хоть дальше. И если офис условно в центре дорогого европейского или американского города, то ни одним гибридом вида «х дней в неделю в офисе» от необходимости жить довольно близко к офису не деться. А это значит, трата условной трети зп на аренду (если мы про Европу говорим). Принципиально ситуацию изменит лишь «х недель в квартал».
Я тут не так давно проехал множество регионов в РФ и почти везде работает вариант «идем в помещение заправки, из двери обращаем внимание кассира на себя фразой 'Пятую дизель до полного поставьте пожалуйста!', идем заправляться». И только после этого уже стоим нормальную очередь на оплату.
За 5 месяцев и 10к километров попалось ну может две заправки, которые прямо уперто говорили «нет, платите сначала». Так что предоплата тоже бывает разная :)
Так где ошибка-то была? А то вы привели какой-то прямо каноничный пример:
antoshkka:
— Пришел в файл фиксить багу
— (через 5 минут) Ой, кто это писал, что за ужас, поправим стиль.
— (через 15 минут) мда, одним стилем не обойтись, надо капитально рефакторить
— (через 30 минут) вот, теперь хорошо *горд собой и постит статью на хабр*
Тимлид: «antoshkka, как там с тем багом, нашел проблему?»
antoshkka: "*искренне удивлен* Каким багом? *мучительный мыслительный процесс* А, с тем багом! Ой...."
Понятно, что хороший код лучше плохого, но не надо забывать о главной цели-то. И если код не такой уж и плохой (собственно, в исходном коде были косячки, ну магические числа, но ничего серьезного, что бы требовало рефакторинга ASAP, на мой взгляд), то может стоит сначала там тестов к нему написать, например, найти баг и пофиксить, и только потом за рефакторинг браться? Как говорится, Red-Green-Refactor.
Глсн н нжн, вс и тк пнтн.
Например, в ЕС самый популярный метод оплаты периодических платежей (квартплата, контракты на домашний интернет и сотовую связь, налог на авто) — это т.н. Direct Debit (иногда рядом есть слово «SEPA»). Это вы «продавцу» выдаете даже не номер карты\CVV (ключ от сейфа), а просто описание и координаты сейфа (номер счета, IBAN). И этого достаточно, чтобы продавец «когда будет время, зайдёшь и сам возьмёшь оттуда сколько тебе надо, чтоб оплатить услугу». Да-да, вы не ослышались — для снятия денег достаточно *публичного*(!) номера счета(!!). Как бы, в теории там еще ваша подпись (ручкой на бумажке или чекбоксик в интернетах) нужна, но мы же все понимаем, что с технической стороны никакая подпись для осуществления транзакции не нужна. И при всей безумности происходящего, местные в этом не то чтобы проблем не видят, наоборот, ратуют «как удобно, не надо самому платить за телефон».
Вставил в блокнот, сохранил как .html — не работает. Если вы пишете/переводите статью о конкретном фреймворке, то, пожалуйста, потрудитесь упомянуть во введении, о каких фреймворках речь.
Вы намекаете, что мне тоже статью стоит написать? Честно говоря, я понимаю, потому что если гуглить «django docker», то во всех этих хипстерских seo-friendly бложиках ни один чел не идет дальше хелловорлда и тему статических файлов не затрагивает. Я сам довольно долго гуглил и спрашивал в чатиках насчет «правильного» способа.
На сегодняшний день я использую один из следующих вариантов:
— Shared volume лишь между контейнерами (но не с хостом, см. SO). Тогда collectstatic пишется в контейнере с джангой и nginx контейнер просто видит папку со статиками
— Если же volume не вариант (например, в Docker Swarm), то можно сделать multistage билд для nginx контейнера. Ну т.е. что-то подобное:
FROM python:3.9 as builder
RUN pip install Django
COPY . /app
WORKDIR /app
RUN manage.py collectstatic --noinput
FROM nginx
COPY config/nginx.conf /etc/nginx/config
COPY --from=builder /static /static
— Ну и «плохой» вариант, но в общем-то вполне рабочий для небольших проектиков без сотен реквестов в секунду — используйте
manage.py runserver. Тогда вам даже второй контейнер с nginx не нужен. Есть несколько библиотек типа whitenoise, которые в теории несколько улучшают ситуацию с «runserver не для продакшна».Не могу ответить, поскольку ни в одном из проектов Celery не использовал, не было нужды. Но есть подозрение, что это может выглядеть как один контейнер, в котором воркеры сами скейлятся как надо (собственно, как uwsgi для того же джанго сам делает).
Понятно, что хороший автор опишет все, но Dockerfile (как и ваш плейбук, видимо) — это не просто текст, это реальные инструкции, которые должны работать, чтобы проект поднялся. И само средство вынуждает автора описать environment. Лишь один коммент — в каком проценте open source проектов вы видели плейбук (или, например, Vagrantfile?) в репозитории? Сравните с процентом репозиториев, имеющих Dockerfile.
Ну видите, мы в одинаковой ситуации, только с разными тулами :) Только в самом начале я пошел гуглить про довер и теперь знаю о докере и применяю его, а вы пошли гуглить про Ansible и применяете его. 1-1 :)
environment: {DB_HOST: db}иdepends_on: dbдля зависимых контейнеров? Вот и все «взаимодействие». Ну да, простите великодушно, «тактично умолчал», потому что это три строчки, которые после первых пары раз пишутся на автомате и уже не думаешь даже. Секундное дело. Но зато после этого вы получаете docker-compose файл, который кто угодно может на своей машине запустить, имея из зависимостей лишь, собственно, докер и компоуз. Один клик — и весь сервис поднят. Да, естественно, если вам захочется больше плюшек, health-чеков, определенного порядка запуска контейнеров, дальше будет сложнее, но для описанного в посте уровня простенького проекта ничего этого не нужно.Не говоря уж про то, что написание Dockerfile это как минимум «правило хорошего тона», по которому можно понять, какие у вашего проекта зависимости. Если мы говорим про питон, то каждая вторая нетривильная зависимость из requirements.txt будет требовать какой-нибудь нативной библиотеки, про которую, естественно, автор не упомянет в ридми. А если вы напишете в докерфайле «pip install -r requirements.txt», то это банальный тест — если оно билдится, значит побилдится и у всех остальных. Не раз и не два такое было, что на хосте вроде работает, а пишешь в докерфайл — опа, оказывается, еще десяток нативных зависимостей надо доставлять (которые на хосте были поставлены неизвестно когда и уж все забыли про них).
Кэп подсказывает, что Ansible playbook у вас написался без проблем, потому что у вас есть опыт в написании плэйбуков. А у меня наоборот — я подобные простые 2-3 сервиса быстро и без проблем оберну в Dockerfile+docker-compose, а вот если надо будет Ansible юзать, то я уйду гуглить на неопределенное время.