Или добавьте эти команды в pdm/poetry. Будет `pdm run makemigrations` - он сам подгрузит из .env переменные окружения и запустит django команду. Причём мне больше нравится именно pdm, т.к. он умеет выполнять не только python скрипты.
Пользуюсь 5+ типами диаграмм в plantuml для разных случаев. В некоторых сильно выручают (pet-проект, к которому я возвращаюсь раз в несколько месяцев), в других помогают быть на одной волне с коллегами.
И даже тот самый изначальный UML иногда пригождается, чтобы лучше разобраться в наследовании и связях всех важных объектов.
Насколько я понял, автор в итоге деплоит в контейнер, а там по 12factor должен быть только один процесс. Да и в целом, при прочих равных я предпочту масштабироваться контейнерами, а не воркерами. По большей части из-за троттлинга cgroups.
Я как-то переводил на Хабре цикл статей Гвидо про реализацию нового парсера взамен ll(1). Вот там он моржа использовал очень часто. И код там получался с ним действительно лаконичнее без потери читаемости.
У меня была подобная задача ровно 10 лет назад. Выкрутился тем, что написал хранимку на pl/v8 (pl/upython на AWS нельзя использовать, т.к. он untrusted). Причём сборка json была выполнена с помощью склейки частей. Результат был порядка 50Mb.
Но у этой байки счастливый финал. За три месяца мы отрефакторили архитектуру и выбросили этот костыль.
Вам дают некоторый кусок кода, и надо его отревьювить: понять смысл, найти логические ошибки, проверить на следование лучшим практикам... Такой формат наиболее приближен к реальным задачам на высоких грейдах.
Внимательнее прочитайте начало треда. Там было "сам правивший и контрибьютивший в него", а вы набрасываете "Человек может прекрасно уметь говорить, но не уметь писать код." Противоречие же?
Если у кандидата есть активный github, то по нему вполне можно оценить как он кодит. Если у кандидата есть видео выступлений, то по нему понятно как он разговаривает.
Не специалист в ruby и gitlab, но часть недостающего функционала реализовал с помощью браузерного tampermonkey. Скрипт, правда, пришлось всем участникам поставить вручную, но на команду из 10 человек это было ок.
Как пример - двойной аппрув, доступный только в платной версии, сделал на эмодзи и кастомной кнопке.
А я ведь всегда говорил, что Django не монстр, а всего 3 файла! А при желании, оказывается, и в один упаковать можно.
Мне не хватило описания практической задачи, когда такой подход может быть востребован. Рефакторинг монолита, кончно, зачёт, но очень специфичен. Вангую, что какие-нибудь лямбды в AWS с таким подходом можно писать.
У них схожие значения (оба помогают кому-то), но разная конотация. Ментор обычно стоит выше и обучает кого-то. Т.е. знания передаются по вертикали. Бадди как правило находится на одном грейде с обучаемым, т.е. знания передаются по горизонтали.
Если синьор приходит в команду, то вряд ли его будет менторить мидл по процессам, репозиториям, доступом. Скорей он будет выступать бадди - как сопровождающий и помогающий.
Ньютон
А это точно тот кроссворд? Не совпадают номера и вертикаль-горизонталь. Например, 35Г нет вопроса.
калоши
Скройте тогда из таблицы человека с 77 баллами. Смущает, что у меня 80 баллов, а в таблице не вижу своего ника.
Или добавьте эти команды в pdm/poetry. Будет `pdm run makemigrations` - он сам подгрузит из .env переменные окружения и запустит django команду. Причём мне больше нравится именно pdm, т.к. он умеет выполнять не только python скрипты.
Пользуюсь 5+ типами диаграмм в plantuml для разных случаев. В некоторых сильно выручают (pet-проект, к которому я возвращаюсь раз в несколько месяцев), в других помогают быть на одной волне с коллегами.
И даже тот самый изначальный UML иногда пригождается, чтобы лучше разобраться в наследовании и связях всех важных объектов.
Насколько я понял, автор в итоге деплоит в контейнер, а там по 12factor должен быть только один процесс. Да и в целом, при прочих равных я предпочту масштабироваться контейнерами, а не воркерами. По большей части из-за троттлинга cgroups.
Я как-то переводил на Хабре цикл статей Гвидо про реализацию нового парсера взамен ll(1). Вот там он моржа использовал очень часто. И код там получался с ним действительно лаконичнее без потери читаемости.
У меня была подобная задача ровно 10 лет назад. Выкрутился тем, что написал хранимку на pl/v8 (pl/upython на AWS нельзя использовать, т.к. он untrusted). Причём сборка json была выполнена с помощью склейки частей. Результат был порядка 50Mb.
Но у этой байки счастливый финал. За три месяца мы отрефакторили архитектуру и выбросили этот костыль.
Вам дают некоторый кусок кода, и надо его отревьювить: понять смысл, найти логические ошибки, проверить на следование лучшим практикам... Такой формат наиболее приближен к реальным задачам на высоких грейдах.
А может и не надо туда? Я успешно прошёл 7 интервью на 2 разные позиции, но мне сказали, что мест нет.
Внимательнее прочитайте начало треда. Там было "сам правивший и контрибьютивший в него", а вы набрасываете "Человек может прекрасно уметь говорить, но не уметь писать код." Противоречие же?
Если у кандидата есть активный github, то по нему вполне можно оценить как он кодит. Если у кандидата есть видео выступлений, то по нему понятно как он разговаривает.
Ну с ретинированным клыком звучит несложно. А если он ещё анкелозирован? Есть ли средства узнать об этом до операции? Или будет сюрприз?
О, это то издательство с самыми корявыми переводами!
Если честно, то не понимаю как их вообще можно сравнивать. Инструменты ж для разного.
Не специалист в ruby и gitlab, но часть недостающего функционала реализовал с помощью браузерного tampermonkey. Скрипт, правда, пришлось всем участникам поставить вручную, но на команду из 10 человек это было ок.
Как пример - двойной аппрув, доступный только в платной версии, сделал на эмодзи и кастомной кнопке.
А я ведь всегда говорил, что Django не монстр, а всего 3 файла! А при желании, оказывается, и в один упаковать можно.
Мне не хватило описания практической задачи, когда такой подход может быть востребован. Рефакторинг монолита, кончно, зачёт, но очень специфичен. Вангую, что какие-нибудь лямбды в AWS с таким подходом можно писать.
Спасибо за перевод статьи, но вся её суть в анимациях в оригинале.
Тем более, что даже Atlassian признаёт gitflow устаревшим:
У них схожие значения (оба помогают кому-то), но разная конотация. Ментор обычно стоит выше и обучает кого-то. Т.е. знания передаются по вертикали. Бадди как правило находится на одном грейде с обучаемым, т.е. знания передаются по горизонтали.
Если синьор приходит в команду, то вряд ли его будет менторить мидл по процессам, репозиториям, доступом. Скорей он будет выступать бадди - как сопровождающий и помогающий.