Подготовить тестовые данные, дернуть API, посмотреть что там в БД записалось.

Это все ещё могут сделать интеграционные и системные тесты.

Если мануальный QA может читать код, то в чем проблема тогда его писать? Просто становится ещё одним разработчиком, а не мануальным тестировшиком.

Хотите сказать, что мануальный QA проверяет качество кода и тестов? Я имею ввиду качество именно написанного кода, а не только качество, как получился функционал этой фичи.

даже предложить, как можно улучшить разработанную функциональность.

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

Это учитывается ещё до написание кода через планинг покер командой

А с чего он один? Во первых пара. То есть пропустит один, тогда второй укажет. Ревью кода и тестов — тоже пара минимум. То есть потеря покрытием специфических кейсов должно пройти минимум 4 человек. Тем более есть типа тест-коверейдж системы , которые и так укажут, что покрытие кода тестами упало в процентном отношении

TDD, BDD, code review — таска уже покрыта тестами и проверена другими инженерами перед принятием в бранч. Зачем тут QA?

PostgreSQL вернет ничего на

2 <> NULL

и

3 NOT IN (1, 2, NULL)

, но не „ложь”

leo=# SELECT 2 <> NULL;
 ?column?
----------

(1 row)

SELECT 3 NOT IN (1, 2, NULL);
 ?column?
----------

(1 row)

# как выглядить "ложь"

leo=# SELECT 2 <> 2;
 ?column?
----------
 f
(1 row)

Из документации:

Some applications might expect that expression = NULL returns true if expression evaluates to the null value. It is highly recommended that these applications be modified to comply with the SQL standard.

«Диван Эксперта»

lurkmore.to/Диванные_эксперты — отличный троллинг получился у организаторов :)

Авторское право — право на воспроизведение — распространяется на результаты творческой деятельности людей в различных областях: песни, книги, фильмы, фотографии и т.д. Авторское право дает вам право запретить другим воспроизведение, распространение или создание производных произведений на основе вашей работы. Авторское право защищает «форму выражения» идей, но не сами идеи. (Если ваш продукт представляет собой программное обеспечение, авторское право распространяется и на него. Вы можете запретить другим использовать ваше ПО, продавая его в виде устройств или исходного кода.) Авторское право означает практически бессрочную защиту объекта.

То есть авторское право может быть на продукт, не на код. Так же как писали тут с книгами — право на само произведение, а не на «сочетание слов». Кому принадлежит продукт — тот и получает

ежемесячные проценты, дивиденды

Вас приковали к батарее и заставляют писать на ROR? Подайте сигнал :)

Потому что Ruby — «blood-red colored GEMstone» ?

В компании нет подхода «это специалист дороже или дешевле» (как мне известно)

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

Но я не собираюсь Вас уговаривать на какую либо модель — full-stack или узкоспециализированный инженер. Они отлично уживаются и работают.

Работает как и все — почасовой же рейтинг :)

Ну или гараздо более времени тратит на обучение.

Раз уж полез — пусть «мучается», человека никто не заставлял становится «full-stack developer» :)

И список может быть не полным :)

Вы правы — эксперт в области Х будет лучше, чем просто full-stack инженер, которые просто там работает. Но разница еще будет в том, что эксперт в области Х умеет решать задачу только данным инструментов («когда у тебя в руках молоток, все задачи кажутся гвоздями»), и рассмотреть/понять как решить эту задачу или ошибку ему уже никак, ведь он ограничен только своей специализацией. Пример, когда DBA решает все через базу данных, даже если это разумнее перенести в бекэнд/фронтенд сторону — он это сам не знает, он просто DBA.

Thus, a full-stack developer would be proficient, if not fluent, in:

— Server, network, and hosting environment
— Relational and nonrelational databases
— How to interact with APIs and the external world
— User interface and user experience
— Quality assurance
— Security concerns throughout the program
— Understanding customer and business needs

Как видите, в списке нет „знать Java 6” или „только jQuery”, поэтому не понятно, как новые технологии не возможны у Вас с full-stack инженером.

 — вот и обзор