Astrohas

Прежде всего хочу заметить, что настолько больших возможностей по расширению языка, как в Lisp'ах, никакой другой язык не предоставляет. Но в некоторых языках, в том числе в Python, можно немного поколдовать с кодом на этапе его разбора.

dumb_translator.py

import ast
import sys

class DumbLisp(ast.NodeTransformer):
    def fix(self, source, result):
        ast.copy_location(result, source)
        ast.fix_missing_locations(result)
        return result

    def visit_Expr(self, node):
        if isinstance(node.value, ast.Tuple):
            t = node.value
            if isinstance(t.elts[0], ast.Name):
                if t.elts[0].id == 'newif':
                    _else = [ast.Expr(value=t.elts[3])] if len(t.elts) == 4 else []
                    _if = ast.If(test=t.elts[1],
                                body=[ast.Expr(value=t.elts[2])],
                                orelse=_else)
                    self.generic_visit(_if)
                    return self.fix(node, _if)
                elif t.elts[0].id == 'define':
                    assign = ast.Assign(targets=[ast.Name(id=t.elts[1].id, ctx=ast.Store())],
                                        value=t.elts[2])
                    return self.fix(node, assign)
                else:
                    call = ast.Expr(value=ast.Call(func=t.elts[0], args=t.elts[1:], keywords=[]))
                    return self.fix(node, call)
        return node


with open(sys.argv[1]) as fh:
    tree = ast.parse(fh.read())
    DumbLisp().visit(tree)
    code = compile(tree, filename=sys.argv[1], mode="exec")
    exec(code)

test.dl

(define, a, 1)

(newif, a == 1, (print, 'Yes'), (print, 'No'))

Запускаем
python dumb_translator.py test.dl

Естественно, пример предельно простой, а потому в качестве s-форм приходится использовать кортежи. Но есть полноценный фронтенд компилятора Python, транслирующий в python-байткод диалект Lisp близкий к Clojure - Hy.

вполне оправданная, сотку тут все дают, и больше дают (и есть, где сильно больше) и не тяжело такую работу найти

но конторы разные:
- требуют пахать за 10
- требуют многое, а пилить Г в итоге дают
- готовы и давать деньги и условия и делиться знаниями
- готовы обещать, но не давать

рынок огромный, толковых разрабов тяжело найти... хорошие компании или проект -- аналогично тяжело,

ну и никто с джунами возиться не хочет :)

в питоне не существует понятия "констаты", их принято писать капсом, так понимается что это константа, но да, в любой момент есть возможность её перезаписать

1. Скачиваешь PyInstaller Extractor
   
2. Устанавливаешь uncompyle6
   
3. Распаковываешь extractor'ом exe'шник
   
4. Декомпилируешь интересующие pyc-файлы с помощью uncompyle6
   

Для подобных вещей очень удобно использовать make файлы

ls Makefile

angular:
    cd client && ng build --watch &
django:
    cd ../src && python manage.py runserver 
run_all:
    make angular
    make django

и потом вызываешь то что надо
плюс еще можно наделать обертки на все остальные рутинные задачи

1. С помощью navigator.mediaDevices.getUserMedia() получаешь MediaStream
   
2. Выводишь MediaStream в video
   
3. Создаёшь canvas и рисуешь на нём текущий кадр из video
   
4. Преобразуешь canvas в blob
   
5. Создаёшь FormData и добавляешь в него blob
   
6. Отправляешь FormData ajax-запросом на сервер
   
7. На сервере обрабатываешь запрос как обычную загрузку файла
   

P.S. Скриншотом называется снимок экрана. Снимок сделанный камерой - это не скриншот.

SVG + padding/margin в процентах

Для новичка в части быстрого выхода в практический ML я бы рекомендовал:

• Этот лонгрид для упорядочивания видов ML простым языком
  
• Условный роадмап из ответа на Quora
  
• После изучения основ программирования - достаточно легкий курс с Coursera (мой обзор на него)
  

Также изучение статистики было бы большим плюсом.

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

Полноценный CI/CD поднимать не вижу смысла ввиду размеров

вы ж все равно собираетесь какие-то скрипты мутить и чото выдумывать,
какая разница это будут крон скрипты на сервере или джоба в дженкинсе? по-скорости написания - одно и тоже будет. так что по-моему размер тут не имеет значение
единственное что имеет значение - насколько явно у вас описан процесс(алгоритм) билда/разворачивания приложений
с этой точки зрения мое видение примерно такое:

1) git не есть инструмент для развертывания по, git лишь для версионирования кода
и по-идее результатом вашей работы должен быть не код в гитхабе, а какой-то вменяемый артефакт, готовый к деплою (docker-image, pip пакет, npm пакет, deb пакет, jar, war, zip в крайнем случае, и тд и тп). Если производить артефакты то вопрос с тегами отпадет сам собой - у вас будет артефакт какой-то версии и все
сервер не должен знать ни про какие гиты и ни про какие-то теги в нем
Здесь я бы рекомендовал паковать все в докер-имеджи хотя бы только потому, что сервер в итоге не будет знать ничего о зависимостях приложения, нужных библиотеках, ниочем вообще, вам нужно установить только докер
Огромное преимущество использование докера - в Dockerfile вы вынуждены волей/неволей описать точно и явно все шаги требуемые для установки приложения. И что самое замечательное - это все будет храниться в том же репозитории, под контролем гит - шикарно.
Артефакты желательно хранить в каком-то артефактории,
но если реально все просто - то можно хранить несколько последних версий прямо на сервере в какой-нибудь папочке

2) как только вы получили артефакт - его можно деплоить
неплохо было б знать особенности вашего проекта, но грубо говоря допустим что достаточно его зааплоадить на сервер, положить в нужное место
опять же с этим дженкинс справится на ура и займет у вас это все дело 10 минут . Если вы опишете логику в Jenkinsfile вы выиграете еще раз потому что процесс развертывания(алгоритм) будет описан опять же ЯВНО. И будет тоже под контролем гита. (Jenkins должен знать только в каком репозитарии и в каком месте ему искать Jenkinsfile)
Если же вы будете крутить какой-то спрятанный cron скрипт на сервере - о нем никому ничего не будет известно. Поверьте уже через короткое время все это дело начнет усложнятся, что-то забудется, что-то измениться и это все вместе больно ударит вас по яйцам.

В чем еще преимущество такого подхода: если вам нужно сделать roll-back на предыдущую версию вам не нужно собирать проект заново выкачивая все с гита, ведь у вас есть предыдущие артефакты, ролбек в таком случае вообще не проблема - просто указываем предыдущую версию артефакта и деплоим еще раз и все

3) Env Variables
когда приложение стартует - считывает все что ему нужно из переменных окружения
деплой джоба может каждый раз эти переменные устанавливать перед тем как деплоить - это было бы тоже круто потому что вы сделали бы это знание так же явным

Итого имеем
- логика сборки проекта описана в Dockerfile и находится под гитом
- логика деплоя находится в Jenkinsfile и находится под гитом, и что самое главное является кодом (Jenkinsfile пишем на груви, для простых вещей вам понадобиться 30 минут изучения и все)
- на сервере мы ничего не устанавливали совершенно кроме самого докера
- мы храним несколько версий нашего приложения на всякий случай и можем быстро откатиться не прибегая к гиту вообще
- сервер не знает ничего о гитах
- на сервере нет НИКАКОЙ дополнительной логики по разворачиванию вашего приложения
- имея все это очень легко добавлять другие сервера для деплоя - что нам нужно - грубо говоря указать другой айпи и набор env variables к нему ( если они конечно отличаются)

1. Хорошая ли идея стягивать все исключительно по тегам т.е. поставил я на фронте и на беке тег v0.4 и скрипт на сервере стянул и то и другое
2. Самонаписанный скрипт постоянно чекающий теги гитлаба это вообще идея хорошая? В чем +\- деплоя по тегам?

Метки ставить можно. Даже полезно релизы метками отмечать. Всегда можно определить, на какой комит надо откатиться, чтобы локально восстановить версию кода как на сервере. И release notice писать по git log между метками, а не в памяти держать.

Постоянно чекать git не надо. Лишняя нагрузка на проц. Совершенно лишняя. Рекомендую веб-хуки или деплоить по SSH команде.

3. Как быть с адресами и портами.

Выносите в конфигурационные файлы или в параметры окружения

10+ вариантов на странице https://css-tricks.com/deployment/
Я для разного размера проектов пользовался
1. deployhq - как только обновляется ветка master - сервис обновляет сервер по SSH
2. веб-хуками из bitbacket + самописным веб-скриптом на PHP без таймлимита - как только приходит хук об обновлении ветки master, выполняется скрипт типа такого

cd /var/www/project
cp web/closed.bak web/closed.html # закрыть приложение
git pull
composer update && php yii migrate # как то код бэка обновить
npm run build # как то код фронта обновить
rm web/closed.html # открыть приложение

3. такой же командой, запускаемой через ssh, без веб-хуков. Это когда понадобилось сразу бэк и фронт пересобирать из разных репо и из разных веток. Ну типа демо из ветки develop, а релизы из ветки master на несколько серверов.
4. настраивали Jenkins для авто-установки

В принципе устраивает

Магии в джанге нет