Nurbol Suleimenov

Посоветовать действительно много чего:

• Kivy довольно простой инструмент для создания мобильного приложения. Насколько я читал, проблема больше в сборке бинарных пакетов для мобильные ОС. Для Android есть buildozer, с которым люди испытывают проблемы. В Хабре есть статья про его настройку
  
• Мобильное приложение для управления - не сложная задача. Логика очевидно будет на сервере, а клиент можно сделать и на современных Javascript фреймвоках. Не зацикливайтесь на языках и технологиях, самое важное в сроках и качестве исполнения.
  
• Не тратьте много времени на мелочи. Кроме минимального мобильного клиента и сервера, Вам не мало времени придется провести за проработкой протокола обмена, способе и виде хранения, оптимизации и отладке всего этого и т.д. Быстро создайте прототип, путь и не самый красивый, а позже украшательство можно внести.
  
• Из практических советов: В мобильном клиенте можете сильно "затормозится" на реализации хороших графиков. Можно значительно упростить, если воспользоваться готовыми html виджетами. Для python есть довольно популярный Dash. В мобильном клиенте можно показывать через html контейнер.
  
• При работе с железом хорошо бы использовать очередь в том или ином виде. Советую очень хорошую реализацию очереди на Python: dramatiq. Для крупного проекта RabbitMQ или NATS
  
• Для создания сервера на Python очень рекомендую molten. Проект хоть и молодой, но стабильный и очень продуманный и современный. P.S. есть интеграция с dramatiq с коробки.
  

Самому приходилось писать на Python решение для умного дома, так что знаю о чем пишу.

Хочеться "порочный" круг разорвать, чтобы билд и деплой были не на прямую связанны.

Не понятно, чем связаны сборка и деплой у Вас?
Я считаю, что связаны они тем, что оба являются стадиями или по другому этапами в непрерывной интеграции (CI).

И в чем порочность, которая требует разрыва?
На этапе сборки происходит к примеру компиляция, линковка, ... результатом является docker образ. Который на этом же этапе помещается в хранилище артефактов т.е. docker registry (docker push). На этапе деплоя, происходит подключение к серверу и доставка артифакта с хранилища (docker pull) и запуск (docker run) к примеру.

Почему я считаю, что эти этапы прямую не связанны?
Между сборкой и деплоем в непрерывной интеграции принято вставлять этап тестирования и даже профилирования (нагрузочного тестирования) иногда. И в зависимости от результатов тестирования цепочка этапов(pipline) может прерваться. Выполнения деплоя может и не быть. В чем собственно и цель непрерывной интеграции от старого подхода, когда собирали и доставляли на производство. Цель: доставлять жизнеспособный продукт потребителям непрерывно.

Судя по Вашему описанию, Вам и в правду не нужен кластер.

через файлы конфигурации, как в кубернетс ... перезапуск при падении как в кубернетс

Это называется инфраструктура как код. Для простых задач достаточно элементарный bash скрипт (srv-up.sh & srv-down.sh, make file, ...) или docker-compose.

обновление без простоя

Для этого посмотрите связку docker+nginx+consul+consul-template. В интернете много статьей, примеров и т.д.
Работает так:

• Есть сервис. nginx (srv-v.1 в конф.) -> srv-v.1
  
• Выходит вторая версия продукта и строится образ srv-v.2 и доставляется на сервер
  
• Запускаем образ srv-v.2 на сервере
  
• Состояние сервера: nginx (srv-v.1 в конф.) -> srv-v.1
  srv-v.2
  
• consul обнаружит srv-v.2 в докере, что в свою очередь обновит конфигурацию nginx и сделает nginx reload (не перезагрузка)
  
• Состояние сервера: nginx (srv-v.1, srv-v.2 в конф.) -> srv-v.1
  \ ->srv-v.2
  
• Останавливаем srv-v.1 или удаляем srv-v.1 со списка серверов в consul
  
• consul обнаружит остановку srv-v.1 в докере, что в свою очередь обновит конфигурацию nginx и сделает nginx reload (не перезагрузка)
  
• Состояние сервера: nginx (srv-v.2 в конф.) ->srv-v.2
  

Можно обновить запуском к примеру через bash скрипт: upgrade-srv.sh srv-v.1 srv-v.2
или то же через CI

подскажите, в чем я неправ? Может быть, нужно это как-то иначе использовать?
Какие сейчас практики применяют?

Вы не совсем поняли. Ansible был когда docker и в помине не было. И отвечал задачам подготовки сервера к доставке(deploy) продукта (настройка окружения, установка зависимостей, ...) и непосредственно развертывания продукта. Так же некоторое применение было в обслуживании серверов (обновление сертификатов, установке патчей, ...).

Сейчас в пост докеровском веке, отпала необходимость в установке и настройке зависимостей на сервере, изоляции сервисов (chroot, ...), ... Зависимости и сам продукт доставляются на сервер в готовом виде, т.е. уже развернутом и настроенном. В этом идея контейнеров. Это не от того, что docker играет на том же поле что Ansible, а потому что подход контейнеризации избавил Ansible от некоторых функции.

Что не предоставляет docker? Это установка самого docker-а на сервере и запуск поверх него готовых контейнеров. Для этого, по прежнему необходим инструмент, можно тот же Ansible.

P.S. Относительно недавно недавно избавил себя от использования Ansible, в пользу Fabric. По причине тяжеловесности Ansible для простых задач. Хотя обновленный Fabric стал лучше, но по прежнему не идеален (описание в императивном стиле, ...). Условно идеальным средством могут служит инструменты для оркестрации docker: Swarm и Kubernites, но не для простых сайтов и маленьких проектов.

Человек Паук, для новичка программиста при обучении основ программирования в теории графов нет необходимости. Это я Вам говорю, как дипломированный математик прикладник с опытом работы в индустрии разработки ПО.

Дискретная математика с современному программированию имеет опосредованное отношение. Согласен, что для тех, кто претендует на звание среднего уровня или эксперта крайне желательно знать графы, алгоритмы сортировки, местами комбинаторику и т.д.

Для новичков, рекомендую "потреблять легкую пищу" при обучении. Основы алгоритмов, методологии программирования (хотя бы императивный подход и ООП), практические навыки работы с инструментами программистов (tooling: IDE, линтеры, VCS, инструменты для сборки и/или упаковщики), технологии (http, ajax, сериализация, ...), ...

Объясните, пожалуйста, новичку, зачем нужно изучать ее и как и где она применяется.

На практике, много где применяется:

1. Не понимая основ графов, можно запросто запутаться и испортить репозитории в git. Точно так же понадобится для анализа дерева зависимостей и разрешения проблем связанных с ним (смотри).
   
2. При отладке программ и профилировании зачастую приходится смотреть AST.
   
3. Нахождение путей, определение цикличностей и т.д. понадобятся, когда Ваши данные хорошо подходят для представления в качестве графов. К примеру социальные сети, GPS навигация, множество абстракции в компьютерных играх и т.д.
   

У Вас две проблемы, хоть они и связаны. Первым делом нужно устранить проблемы. Вопросом производительности заняться после устранения ошибок, т.к. без наличия проблем это будет исключительно оптимизация.

Проблемы бывают аппаратные и программные. Советы по диагностике аппаратных проблем:

• Проверьте температуру процессора, мат. платы, видеокарты и т.д. в штатном режиме. Проследите не происходит ли перегрева.
  
• Как советовал dollar, проверьте оперативную память. В компьютерах брендов утилита для проверки памяти зачастую встроена в BIOS. Или создайте загрузочный диск на USB носителе или CD/DVD с дистрибутивом LInux (Ununtu, ...). Практических во всех в меню загрузки есть Memtest
  
• Посмотрите отчет S.M.A.R.T. о своем диске, возможно происходит деградация диска. В интернете можно бесплатно скачать утилиты для просмотра информации о SMART
  

Программные проблемы:

• Посмотрите журнал ошибок WIndows (Панель управления > Администрирование > Просмотр событий). Службы Windows записывают туда отчет о своей работе. Красными кружочками обозначены проблемы и указывается код ошибки, это поможет найти способ его устранения
  
• В консоли (cmd) запустите проверку диска на ошибки. chkdsk c: /f /r Скорее всего потребуется перезагрузка для начала проверки
  
• Помимо своего штатного антивируса просканируйте бесплатными сканерами других производителей (cureit, ...). Любой хороший антивирус определяет к примеру 90-97% вирусов, но у разных производителей базы вирусов чуть отличается. Сомнительные файлы проверьте через сайт www.virustotal.com
  
• Не советую пользоваться утилитами для чистки и оптимизации проблем. Положительным в ним является то, что не требуется знания для их использования. Негативным фактором служит то, что помимо исправления проблем они вполне могут их и порождать. И еще устанавливает вместе с собой множество ненужных рекламных программ и даже вирусов
  

Абсолютно все невозможно предусмотреть и рассказать. Поможет поэтапная проверка и уменьшении области для проверок. Если будете действовать как надо, то будете знать чем проблема не связана.

Автору посоветовал бы использовать паттерн декоратор (decorator) и назвать его к примеру Timer для класса или timer (timeit, ...) для функции(если в Вашем языке функция это first class citizen) как предлагал Валерий Глуховцев.

Обоснование:
Причина по которой Вы хотели бы использовать подобный класс это профилирование. И мне лично, не хотелось бы отделять объект измерения от самого измерения. Введение декоратора для измерения позволит обеспечить хорошую сцепленность. Самостоятельные классы следует создавать для необходимых сущностей, а не плодить их, так пропагандируют современные эксперты. И это еще опуская тот факт, что настоящий ООП сейчас в опале. Помимо декоратора, в зависимости от языка, я могу придумать так же использование метаклассов, но декоратор удобнее.

Почему я считаю, что измерение времени не достойно полноценного существования как отдельного класса?

• Класс предполагает порождение экземпляров. Которые в свою очередь будут вызываться в методах, когда мы хотим что то измерить? Это уже сильная связанность, которую следует избегать. А так же, в какой то мере увеличит code complexity score
  
• Вы написали:

  В коде есть объект, единственное свойство которого это длительность его существования

  
  Сами слова говорят, что цель такого объекта слишком мало для отдельной сущности. Это, наверное, "Одержимость элементарными типами" в концепции Код с запашком
  
  

Советую запускать сервисы на Python через Supervisord (по старинке) или Circus, и предусмотреть в коде частные случаи.

Причина: В реальной жизни есть масса тонкостей, такие как наличие зависимых сервисов и порядок запуска, отсутствие доступа к сети, отсутствие прав к ФС, сети и т.д., ... Указанные продукты позволят настроить многие из указанных моментов, а так же как указал Pavel Denisov timeout для них и логирование.

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

megaPonshik, Stanislav Pugachev прав. Файл банально не сохранен. Нужно отметить, что ответ Stanislav Pugachev верен

По поводу Jython согласен.
А Illia Nezhyhai не прав. Cython != CPython. CPython действительно реализация языка, но Cython - это самостоятельный язык, синтаксисом напоминающим микс Python и C.

>>> Зачем они нужны?
Cython используют часто для написания компилируемых расширении для Python.
Преимущество в повышении производительности и понижении потреблении памяти.
Но может служить и для написания самостоятельных программ.
Подробнее: https://ru.wikipedia.org/wiki/Cython

Сначала банальности:
1. Проверить наличие nuxt в package.json.
Возможно на локальной машине устанавливали так:
npm install nuxt // без ключа --save
Зависимость не прописалась в package.json и не устанавливается на сервере
2. nuxt требует node >=6.11
Если не поможет:
3. Проверить не было ли ошибок при установке зависимостей npm install
Есть issue по поводу этого: https://github.com/nuxt/nuxt.js/issues/3039
Выход: переход на yarn