deepblack

Переполнение стека.

screen

У вас, очевидно, selected_choice.votes - это строка, а вы пытаетесь применть оператор += с елым числом. Об этом вам и выдаётся ошибка. Нельзя к строке прибавить число.

Пожалуйста, впредь приводите полный код. В частности не хватает описания модели Choice.
А ещё нужно приводить целиком стек-трейс, чтобы не заставлять отвечающих читать ваш код целиком выискивая глазами причину ошибки.

В модели нужно votes сделать целочисленным,если вы хотите прибавлять к этому полю числа. Иногда тип поля меняют, но необходимые миграции не накатыают на БД и при десериализации инстанса модели у этого инстанса атрибут, обозначенный в модели как целочисленный. может оказаться строковым, как по-прежнему указано в схеме БД.

Делайте миграции или меняйте схему вручную для приведения в соответствие с моделью.

пишу GUI на android, хотелось бы снизить количество потребляемой оперативной памяти.

Не пишите на Python.

Есть Telegram bot API - это для ботов. А есть Telegram client API - это для приложений, вполняющих функции клиентской стороны. То есть если вы задумаете написать свой клиент для телеграмма, то будете пользоваться этим API. Некоторые злоупотребляют правилами и делают ботов с использованием этого API, чтобы боты ритворялись реальными аккаунтами. За это, по идее, должны банить.
Не надо делать таких ботов. Для чего вам?

docker log rotation

Импортировать нужные классы/функции и запустить их в отдельном потоке.

Ну, есть универсальный патч. Он особо подходит для тех, кто считает, что из всех дистрибов ему нужен почему-то Kali - ужасно узко специализированный дистриб для ИТ-безопасников, на нубов не рассчитанный от слова совсем.

a1=$(cat file1.txt |egrep -o '^a=[^\r\n]+$' |head -n1 |cut -d"=" -f2)
b1=$(cat file1.txt |egrep -o '^b=[^\r\n]+$' |head -n1 |cut -d"=" -f2)
if [ -n "${a1}" -a -n "${b1}" ]; then
    echo "${a1}-${b1}" >>out.txt
fi

А вот перебор по всем файлам в директории мне делать лень, поэтому пусть это будет вашим домашним заданием, сделайте ну хоть что-нибудь своими руками!

elif - это сокращение от else if, что в переводе значит "иначе если". Иначе если что в вашем случае? Условие-то где в условном выражении?

В принципе, сама по себе Android Studio - не сильно требовательная. В основном, вся боль начинается при сборке и запуске проекта на эмуляторе.
Начинал тоже, с древнего ПК, (там по моему даже 4 ГБ ОЗУ не было).

Решил проблему - запуском на реальном устройстве, девайсе, вместо эмулятора.

Довольно часто предлагают тестовое задание, на которое у меня нет времени.

В таких ситуациях правильнее будет сказать "Каковы условия оплаты данного задания?". Большинство неадекватов на этом этапе отсеиваются. Просто потому что не только вы что-то делаете для работодателя, но и он вам что-то дает. Если работодатель хочет получить какую-то работу еще до начала трудовых отношений - то следует задуматься, а нужен ли вам такой работодатель? Я просто из исследовательского интереса прошел несколько десятков тестовых заданий и я НИ РАЗУ не получил какого-либо фидбэка. По ощущениям - на результаты тестового никто не смотрит и всем тупо пофиг на него. Поэтому когда мне предлагают тестовое задание - всегда сразу спрашиваю оплату. Никто не хочет платить - это факт, тут ничего не сделать. Почти всегда сразу в отказ идут. Было несколько случаев, когда вроде согласились - но все равно ушли в закат. В целом же, в практике был лишь один случай, когда ко мне пришли и сказали - вот ты умеешь то-то и то, вот тебе тестовое задание, оцени, мы тебе денег сразу заплатим, а там если все пучком - будем работать дальше. И еще несколько случаев, когда работодатели сразу в описании вакансии писали, что тестовое задание оплачивается. Смотреть код тоже почти никому не интересно - такой случай тоже был лишь один, когда я предложил показать код, согласились посмотреть и поспрашивать про него. В абсолютном большинстве остальных случаев, адекватные работодатели сразу говорят: по результатам собеседования нас все устраивает, далее делаем так - вот тут у нас список задач, выбирай одну-две-три простых задачки, если все отлично - работаем дальше, если нет - ну что ж, выдадим зарплату за эти задачки и разбежимся миром. Все остальные, где там сложные и долгие интервью то с одним, то с другим, то задание такое, то сякое - больше на лотерею похоже, когда крутишь барабан и гадаешь - будет сектор приз или сектор ноль.

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

Специально - нет, не нужно. Разве что по результатам прохождения курса учебного какого - можно выложить. Ну и пет-проекты никто не отменял - вот их да, можно и нужно выкладывать на гитхаб и периодически подкармливать.

юнит - тестирование минимального модуля, обычно один класс.

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

Функциональный - тестируем полноценно какую-то функцию, например пользовательский юзеркейс, который для работы может использовать один юнит, а может и десять.

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

e2e - енд ту енд, тестирование от начала до конца какой-то функциональности. Оно не совсем в эту иерархию вписывается. Скорее как тест, который имитирует работу пользователя. Например юнит тест можно сделать внутренними инструментами, интеграционный тоже. А e2e должен ну как минимум имитировать реального пользователя или реальное окружение как продукт будет использоваться.

Потому что GitHub его выпилил уже полгода как.

Permanently disabled the unencrypted Git protocol