700ghz

1. Личный блог, если вы его правильно оптимизируете, сможет давать вам лиды с поиска. Например, вы можете написать несколько статей на тему "Найти программиста и не прогадать", "Хороший программист - на все золота". Т.е. с вхождением в метатеги в тексте запросы, по которым могут искать такого специалиста. Да, это чисто коммерческая история но и вы ведь работаете за деньги, не так ли, и это всё не из-за любви к искусству, а чтобы найти клиентов.

2. Человек который пишет, всегда "выше на голову" того, кто не пишет. Конечно при условии, что они на примерно одном уровне и человек не пишет ерунды.

3. Чтобы не прослыть копипастом, напишите в блоге, что это ваши личные статьи, уникальный контент, и что если кто-то хочет его использовать, то ссылка обязательна. Гит и т.п. профильные сообщества никто не отменяет.

Успехов, направление верное. Лучше это делать, чем не делать. Я кстати себе нашел разработчика на один проект на битриксе именно через его блог, в поисковой выдаче.

Ну во первых стоит отказаться от использования слова "api" в названии папок, файлов, классов, функций, etc.

Я подобную задачу решал приблизительно так:

..shop
....users.js
....books.js
..buyer
....users.js
....books.js
..users.js
..books.js

При этом users.js и books.js, лежащие в папках shop и buyer, наследовались от users.js и books.js, лежавшие в корневой папке.

Пофиг, разраб все равно при сборке запроса обратится к свойству своего объекта.
И ид тут лучше, так как унифицирует код..

отрисовка интерфейса слишком неоднородная задача чтобы ее скидывать на GPU.
тыкну пальцем в небо и скажу процент использования GPU небольшой.
upd: подразумевается отрисовка немультимедийных элементов интерфейса - окошки, кнопочки, менюшки...

"внутри интерфейса" проги уже зависит от кода самого приложения.
в 3д-игрушках, видеоплеерах и подобных GPU используется очень активно.
upd: подразумевается, к примеру, поток видео, в котором надо произвести малое количество операций над большим количеством данных.

Какого уровня тесты?

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

3 пункт конечно не делать!

много идеологических вопросов, что именно и зачем тестируете.
несколько уровней тестирования, обычно при ТДД разработке требуется быстрая обратная связь с тестами, и тестируют исключительно ту функциональность которую разрабатывают, без тестирование зависимостей в виде баз данных и тд, для этого используют разного рода заглушки (в виде мокапа).
тоесть базу данных вообще не используют.
В конце разработки, все равно прогоняются "интеграционные" тесты, по всему сервису, чтоб посмотреть работу сервиса в целом, включая все его части, тогда используется максимально идентичное окружение, что и как на продакшене, по возможности даже используя примерно такую-же БД что и на продакшене. База данных в памяти уже не соответствует этому требованию, может случится так, что например разница в задержках между тем как отрабатывало в памяти и как отрабатывает в реальности будет сильно отличатся, и приведет к неожиданному поведению.
ну и да на каждый такой интеграционный тест базу заново перезаписывают и заполняют темеже самыми данными что и ранее (мы же обычно в тестах проверяем соответствие исходным данным, потом проверяем например изменение этих данных, поэтому без отката этих данных назад, повторить теже самые тесты не получится)

1. Значит ли это что мне нужно очищать базу данных после каждого теста?

да

2. Как лучше заполнять базу данных: вызывать функцию заполнитьБдТестовымиЗаписями() (функция заполняет сразу все таблицы какими-то текстовыми записями) перед каждым тестом? Или не заполнять сразу всю базу данных, а создавать только необходимые записи (например пару юзеров) прямо внутри теста?

создавать только необходимые записи (например пару юзеров) прямо внутри теста

3. Правда ли что тестовая БД должна храниться именно в memory? (не в файле, как обычная БД) (то есть использовать sqlite для тестов, вместо mysql)

желательно, но не обязательно.
"Финальные" тесты должны проходить на софте и окружении, который будет на продакшене.
Также желательно провести тесты еще раз не на пусстой базе, а на обезличенных данных с реального проекта

Разберитесь в различиях функциональных/приемочных тестов и юнит-тестов