Дмитрий

Есть поговорка "Встречают по одежке, а провожают по уму".

На собеседовании вам по-любому надо будет показать свои знания. Но ведь надо еще сделать так, чтоб вас на него позвали! Любой сертификат это способ выделиться из массы других подобных специалистов. Не более. Более того качественная сертификация структурирует ваши знания. Возможно поможет посмотреть на себя со стороны. Повысит вашу уверенность в себе, а разве это плохо? Уверенный в себе и своих силах как правило большего добивается

Scrappy

Из минусов :
* Сложность установки на системе Windows. Поэтому один раз нужно будет поставить . Задокументировать процесс установки.
* У меня были проблемы с кодировками, но это возможно у меня что-то с руками было. Обратите на это свое внимание

Из плюсов:
* Многим известен
* Структурирован
* Много информации по нему

SICP учит думать по-программерски. Учит находить решения в программерском мире. Есть огромная разница между программистом знающим как использовать фреймворк1, фреймворк2, ..., фреймворкN и другим программистом, который может даже и не знать как использовать эти фреймворки, но сможет отличить что вон тот код очень похож на работу за O(n) , а вон тот вроде как за O(1) и сможет сделать более правильный выбор. Грубо говоря есть некий базис, который одному позволяет создавать решения более стабильные, более эффективные, а другому из-за не хватки приходится городить костыли.

К примеру общеизвестная задачка на программирование "банерокрутилка". Когда имеется банер1, банер2, ..., банерN и нужно вывести "псевдослучайно" каждый банер по одному разу. Один программер может применить массив и указвать в нем какие номера он уже выводил, а другой применит математику и при этом решение будет одно проходным и не потребует выделения массива. И таких задачек в программировании хватает!

Причин может быть достаточно много.
1. Что если сегодня поле расположено в виде закрытой переменной, а завтра будет доставаться из HTTP-ответа ?
2. Что если сегодня оно в виде хранимого значения, а завтра станет вычисляемым?
3. Что если сегодня оно в этом классе, а завтра решили перенести в другой, а чтобы не делать слишком большой рефакторинг пока решили оставить как есть?
4. Что если сегодня это свойство этого класса, а завтра родительского?

Причин множество! Геттеры и сеттеры спасают от головных болей.

Electron ? На С++ пишите NodeJS плагин , а на Html + JS + CSS фигачите GUI

Рекомендую посмотреть на aiohttp. Его пилит один из python core-девелоперов у которого руки в правильном месте. Идея использования на основе Flask. Только Flask хоть и адски удобный,но не асинхронный!

Если у вас такое желание возникло, значит вы пишите гуан-код в этом месте!

В случае появления желании использовать переменную, но уже чуть чуть в другом контексте это значит программист не улавливает, что он пишет ДВЕ задачи в одной функции!

Есть правило: Одна задача - ОДНА функция!

Спросите, а чем отличается текущее использование number после того как было "закрыта" область видимости при прошлом использовании? Именно ответ на этот вопрос даст вам более правильное название переменной!

Конкретно в этом случае я бы просто назвал: likes_in_vkpost().

Поясню:
1.
Если функция используется в правой части и присваивает значение в переменную в левой части, то что это если не геттер-функция? Зачем еще раз заострять читателю кода "Нет чувак, я тут 100 пудов достаю лайки из поста". Ему надо просто сказать "Лайки из поста". Не верит, пойдет в функциию и почитает ее код или заглянет в код юнит-тестов.

Если в коде гет-функии шлется http-запрос, потом получается http-ответ. Потом что-то считается. То это означает нарушение принципа "одно действие одна функция".
* Послать запрос одна функция
* Получить ответ другая
* Проанализировать еще одна
* А вот достать уже полученное из сети и хранящееся в объекте или каком-либо хранилище в памяти это и есть гет-функция. По этому ее делают read-only , чтобы она не разрушила объект и тогда она получается "свойством объекта" и по этой причине нет смысла использовать 'get' в имени функции

2. Глагол в функции имеет смысл использовать только тогда, когда вы хотите ЯВНО сказать, что тут нужна крайне внимательно присмотреться.

2.1. У вас есть сложный вычислительный процесс по подсчету лайков и этот код может "тупить", т.е. долго работать тогда и надо говорить compute_likes(). Читающий код задумается при глаголах: compute, analyze, etc

2.2. Обновление значений в объекте тоже может нести опасность и по этой причине нужно добавлять 'set' . Если у чувака объект рушится, то он задаст вопрос: "А кто изменяет объект?" и тогда он будет искать глаголы : set, update, push, pop, etc

3. Используйте грамматику английского языка

Возьмем предложения "Эта строка пустая?", "Эти данные зашифрованы?". Как бы вы спросили это по-английски?
'Is string Empty?" , 'Is data encrypted'?. Тогда в коде будем читать как:

if ( str1.empty() )
if ( data1.encrypted() )

Если вы будете использовать схему:

if ( str1.is_empty() )
if ( data1.is_encrypted() )

То вы нарушаете грамматику английского. Глагол 'to be' в вопросительных предложениях ставится ДО подлежащего! Возьмите к примеру документацию к C++ стандартной библиотеке и прочтите описание std::string.

Оговорка: Это не касается случая, когда вы пишите в процедурном стиле. Пример:

empty(driver_data_request)

тут сложно понять что имел ввиду автор и поэтому 'is_empty' вполне имеет смысл!

П..те в гугл и наберите "Максим Дорофеев". Этот дядька спасет вам жизнь. Его лекции есть на ютубе.

Кратко: Если вы ловите себя на мысле, что мечтаете о хз чем или думает опять над тем "А вот тогда-то надо было сказать ....", но не делаете что-то что важно делать именно сейчас. Это значит "обезьянка"(смотри\читай Дорофеева или Тима придумавшего рационального типа и обезьянку и др. личностей). Это значит что обезьянка нихера не втыкает что надо сделать!

Какую мозг берет задачу, сложную или важную? Ответ неверный! Он берет ПОНЯТНУЮ!

Обезьянка поняла? Понятно что делать? Это уже говорит о том, что вы можете продвинуться дальше, хотя бы раздробить на подзадачи. А это надо сделать. То если задача по субьективным оценкам больше 10\20 мин, значит дроби на более мелкие задачи

1.
>> Все эти медиа хранятся в одной таблице и различаются по полю Type
Вводя тип, различающий данные в таблице вы задаете условную логику. А это усложнение кода!

2.
Одна таблица одна сущность! Не экономьте на таблицах, если на это нет веских причин по performance.

3.
Есть объектно-ориентированные БД, которые позволяют вытащить общие части в аналог "базового класса". Посмотрите в эту сторону.

Это IMHO. Основано на том, как бы мне проще было понимать как все устроено.

1. Да, берут более молодых. Но почему?
По большей части у них есть больше энергии и сил.
Если возникает необходимость что-то сделать грандиозное: перейти на новый фрейморк, сидеть до поздна несолько дней лишь выдать продукт с правкой багов и др. То у молодых больше энергии

2. Но также берут и по-старше.
Но все люди разные. Кто-то уже "устал" и вообще ничего не хочет делать. А-ля "перегорел". А кто-то придет и запустив WinDbg напишет на коленке скрипт для pykd и найдет кучу уязвимостью. Потом их опишет и скажет "У Вас ребята руки из жопы. Так писать нельзя" и покажет как надо! Вот в таких случаях работодателю страшно уже по-другому поводу "А не слишком ли опытный? Ведь ЗП по-больше будет просить!" ;)

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

Так и в программировании. Любая измнененная\добавленная\удаленная строчка кода может сломать продукт. А чтобы об этом очень быстро узнать создают тесты такие, которые покрывают как можно больше функциональности в продукте. У них нет задачи локализовать причину поломки. У них другая задача: "хоть как-то работает или нет?"

1. "RESTful Web Services", shop.oreilly.com/product/9780596529260.do
2. "Thoughts on RESTful API Design", restful-api-design.readthedocs.io/en/latest
3. "REST API Design Rulebook", shop.oreilly.com/product/0636920021575.do

Найдите книгу Мигеля Гринберга про Flask. В этой книге этот вопрос раскрыт достаточно подробно

Попробуй поставить 5-6сек в time.sleep() между строчками:

driver.find_element_by_id("password").send_keys("Password123")
        driver.find_element_by_id("allow").submit()

У меня примерно так:

1. Пытаюсь понять суть решаемой проблемы
2. Пытаюсь вспомнить решал ли я подобную проблему?
3. Если не удалось вспомнить, пытаюсь придумать решение.
п.2. и п.3 - не более 15-20 мин на задачи кажующися очевидными. К примеру как отформатировать строку в python или как написать fixture в тесте на py.test
4. Если не удалось вспомнить лезу в документацию
5. Если в доке нету, то вбиваю вопрос в гугл
п.4. и п.5 не более 15 мин.
6. Если уж и там нет, то извещаю коллег в команде, что у меня затык и мне нужно время. Может мне кто-то придет на помощь или скажет отложить задачу и заняться другой не менее важной задачей
7. Если же продолжать надо, то задаю вопрос друзьям в skype или еще куда
8. Если и тогда нет помощи, то иду в Stackoverflow, toster, python.su, etc

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

Почитайте биографию Генри Форда.
Чувак работал в успешной компании на то время и в 40-летнем возрасте ушел "в космос", т.е. в никуда. Он четко знал что он хочет получить. В результате Форд сейчас одна из известных компаний. Если что именно ему приписывают авторство на слова "Если бы я слушал пользователей я бы сделал более удобную карету, но я дал им куда больше". Чувствуете? Этот человек ЗАРЯЖЕН настолько что хер его остановишь! Он пошел против системы и сумел убедить большинство что-то привычное старое средство карета это уже не айс. А идти против мнения большинства очень сложно! Оно возможно когда личность ясно представляет куда ей двигаться.

Нету у вас Мотивации! Когда появится, тогда и вопроса что и как делать не появится!

Тесты для кого? Для человека или для машины?
Я к тому, что тесты бывают разными: ручные и автоматические. Про это ничего не сказано в вашем вопросе!

Какие именно тесты нужны? Модульные? Интеграционные? Инсталяции? Нагрузочные? Про это тоже ни слова в вашем вопросе!

Тесты пишут так:
1. Выявляют сначала рабочие сценарии, т.е. когда все хорошо и появляется результат. Есть огромное кол-во ситуаций, когда пользователь готов заплатить забажный продукт, если он хотя 1 раз и 50 запусков сделает ему то, чтобы он делал 3 дня! Сценарии сортируются по:
1.1. компонентам
1.2. приоритету и важности.

После сортировки создают наборы тестов

2. Далее выясняют сценарии, когда что-то не хватает "насяльника сеть упала, что делать?". Другими словами проверить работу позитивных сценариях при возможных негативных случаях, которые быть, но не повине пользователя. Примеры: сеть упала, флешка перстала видеться, в БД вдруг доступ не пускают и др. Особенно смотрят на возможную порчу исходных данных. Был у моего знакомого случая, когда они подбирали пароль к базе данных и случайно затерли пару байтов. ;)

3. Только после этого проверяют "ошибку на дурака". Примеры: вместо текстового файла дали exe-файл. Или вместо числа ввели строку.

Предположу, что вы хотите писать модульные тесты. Скажу следующее что эти типы тестов не должны делать:
1. Проверять работу с БД, диском, сетью
2. Код зависящий от времени

Основной показатель модульного теста это скорость работы. Если тест такого типа работает пол-секунды, то значит вы написали что угодно, но это не модульный тест ;)