Kris

С компиляцией питоновского кода в exe файл могут помочь утилиты: pyinstaller, cx_freeze, py2exe, py2app, или же тык

Каждая из утилит имеет свои плюсы и минусы. Например, в pyinstaller можно скомпилировать весь код в один файл и весить он будет намного больше. В cx_freeze же нужно тащить с собой папку необходимых библиотек, помимо ехешника, но сама папка, включая исполняющий файл, весят в разы меньше.

Используйте программы для автозамены текста, вроде TextExpander или Punto Switcher (автозамена есть только в Win версии).

Если сидите на Маке, то у Alfred есть Snippets для этих целей.

В поддержке использую подобный софт с 2009 года. Незаменимая вещь.

Помогают быстро писать часто используемые слова/фразы и вставлять готовый ответ. Например: сокращение «Зд» превращается в «Здравствуйте,», «пож» — в «пожалуйста,», а «демоо» — в ссылку на страницу для запланирования демонстрации сервиса.

В последнем сокращении специально указаны две буквы «о». Слово «демо» можно использовать в тексте как самостоятельное. Поэтому добавляется еще одна буква «о», чтобы программа не срабатывала после написания «демо». Такой вариант сокращения я использую сам, вы, скорее всего, остановитесь на другом.

Представьте: последний id был 100, вы начали транзакцию и добавили строку в таблицу. Должен MySQL зарезервировать ID для этой строки? Очевидно, да. Какой? Видимо, 101.
В этот момент проходит ещё одна команда на вставку строки, в другом потоке. Она тоже хочет получить следующий id. Какой ей выдать? Видимо, 102. Строка записана.
Теперь вы отменяете (или не подтверждаете) первую транзакцию. Куда деть значение 101? Да просто выбросить.
AUTO_INCREMENT гарантирует уникальность и монотонное возрастание, но не непрерывность значений, так что пропуск значений (лакуны) вполне допустимы.

Насколько я понимаю - connection.commit() завершает транзакцию, но если вы сделали инсерт, а затем не сделали комит, то транзакция автоматически откатится, однако так как инсерт "уже был", внутренний курсор автоинкремента сместится на количество (не)добавленных строк.

Почему так происходит и как этого можно избежать?

- Доктор, я когда вот здесь нажимаю - больно!
- Не нажимайте здесь.

https://www.codewars.com

Вы про code style?

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

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

Интеграционное тестирование означает проверку совместной работы компонентов системы. Например проверка того, что вызов метода контроллера создает запись в базе с определенной структурой. В данном случае проверяется интеграция контроллера с моделью. Более высокоуровневое интеграционное тестирование может быть проведено на уровне клиента, когда сервис возвращает нужный объект.

Функциональное тестирование проверяет соотвествие требованиям проекта. Например, при нажатии кнопки Удалить появляется окно подтверждение с текстом "Вы уверены", затем при нажатии кнопки "Да", запись удаляется из БД и пользователю выводится сообщение "Запись успешно удалена!".

Тест на регрессию - это повторная проверка работы конкретного участка кода. Как правило это участок кода, который не был покрыт тестами ранее.

PHPUnit изначально предназначен для юнит-тестирования, однако это не мешает вам использовать его для других видов тестирования. Есть даже коннекторы к WebDriver.

Тестирование контроллеров и моделей по отдельности - это юнит-тесты.
Тестирование связки контроллер-модель - это интеграционное тестирование.
Тестрование работы сайта целиком с помощью того же Selenium и т.п. - это функциональное тестирование.

потому что найдя 1ый файл она вываливается из функции на return. Вам надо аккумулировать все файлы и вернуть список

def my_list(path):
    result = []
    for dirname, dirnames, filenames in os.walk(path):
        filenames = filter(lambda x: x.endswith('.html'), filenames)
        for filename in filenames:
            file = os.path.join(dirname, filename)
            result.append(file)
    return result

допустим так

return прерывает выполнение функции, а print нет. Поэтому нужно сначала, вместо return, складывать все нужные значения в массив, а затем уже возвращать сам массив.
Что то вроде этого:

def my_list(path):
    filePaths = []
    for dirname, dirnames, filenames in os.walk(path):
        filenames = filter(lambda x: x.endswith('.html'), filenames)
        for filename in filenames:
            file = os.path.join(dirname, filename)
            filePaths.append(file)
    return filePaths

Побыстрее начать != начать хорошо! Насчет опыта работы все тоже очень относительно, я встречал разработчиков с опытом от 5 лет которые считают себя Senior'ами но которых по уровню знаний и умений обойдет хороший Junior. Все они также как и вы хотели побыстрее начать карьеру и получать опыт. В итоге работа в конторе по разработке сайтов -> верстка -> CMS -> фреймворки(если повезет)->перегорание (на этом этапе пропадает интерес и желание учится, от начального энтузиазма не осталось ничего, человек понимает что программистом так и не стал но сил начать все сначала нет). Путь в никуда!
Насчет front-end vs back-end смотрите что больше нравится. Выучить html,css,js,jquery придется в любом случае, для back-end советую еще познакомится с Python и тогда выбрать что-то одно Ruby/Ror или Python/Django.
Вам только 18 лет, не стоит убивать в себе программиста ради побыстрей

Понятие еnd-to-end обозначает всего-навсего классификацию тестов по уровню, на котором тестируется система, и, само по себе, ничего не говорит ни о том, какие конкретно должны быть эти тесты, ни о том, какую роль они играют в общей стратегии обеспечения/проверки качества и, также, не является методикой тестирования. (Методика - это совсем другое понятие.)

Для понимания сути этого понятия хорошо сравнить его с модульным ("нижний" уровень) и интеграционным ("средний") тестированием на каком-нибудь конкретном примере. Давайте рассмотрим некий сферический webshop в вакууме. Предположим, в нем есть 50 классов и для большинства из них написаны модульные тесты. Они проверяют исключительно функционал конкретного модуля (чаще всего, класса), т.е. тот, что зависит только от самого модуля и ни от чего чего более. Потом есть интеграционные тесты. Они проверяют корректность работы отдельных "модулей", если их собрать вместе согласно архитектурe. Например, работает ли правильно "Корзина", состоящая, в свою очередь, из 10 классов (предварительно проверенных модульными тестами), или "Корзина", подключенная к "Вебморде" и т.д. Где-то повыше в этой иерархии есть такие интеграционные тесты, которые проверяют конкретный функционал всей системы. Например, отправляется ли юзеру мейлом копия оплаченного заказа...

И вот тут начинается самое интересное для понимания того, что такое end-to-end тестирование! Можно представить себе тест, проверяющий, что соответствующий мейл генерируется и сбрасывается SMTP серверу. Если SMTP сервер не рассматривать, как часть разрабатываемой системы, то этот тест вполне можно назвать end-to-end тестом (послали кучку HTTP запросов через "Вебморду" и проверили сброс мыла на SMTP - все зашибись!). Однако, если настройки и эксплуатация SMTP сервера - часть проекта (например, заказана разработка webshop "под ключ"), может оказаться, что это мыло будет отфильтровано каким-нибудь спам-фильтром, превысит лимит почтового ящика пользователя... короче, не дойдет до него. Тогда этот же самый тест уже нельзя считать end-to-end, а нужно бы было написать тест, проверяющий приход мыла в POP3/IMAP ящик. (Опять же, если это действительно нужно! Ибо, в зависимости от конкретных функциональных и нефункциональных требований, архитектор и QA инженер вполне могут найти возможность обеспечить адекватный контроль качества и без такого теста.)

Таким образом, end-to-end тесты, это такие интеграционные тесты, которые воздействуют на систему через ее самые внешние интерфейсы и проверяют ожидаемую реакцию системы через эти же интерфейсы. Почему именно интеграционные? Потому, что это единственное, что можно о них сказать наверняка: они по определению не могут быть модульными тестами. А все остальное: являются ли они одновременно приемочными, нагрузочными или еще какими - зависит только от общих плана/стратегии тестирования и той роли, которые эти тесты в них играют.

1. Что такое миграция, для чего конкретно нужна и как это связанно с сохранением данных?

переход от одной структуры БД к другой без потери косистентности

2. Чем миграция отличается от db_upgrade or db_downgrade?

миграция подразумевает как прямое изменение апгрейд, так и обратное изменение - даунгрейд

3. Что будет, если миграции не производить?

миграции можно не делать,
если данные не важны и их можно просто удалить из БД,
если приложение не развивается и/или не меняет структуру хранения