Алексей Уколов

Дисклеймер: я не системный архитектор, и даже не знаю, кто конкретно должен так называться, наверное это что-то вроде технического директора.

Или у меня чрезмерно идеалистические представления о роли архитекторов в разработке?

Да, чрезмерно. Архитекторы (как вы их называете) не боги и даже не "вторые после бога".

включая "подводные камни", которые, как правило, доступны только прилично поработавшим с технологией специалистам?

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

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

А надо уметь главное выделять. Ну к примеру, вот позавчера анонсировали докер на винде на нативных контейнерах. Что нужно знать хорошему техническому директору? Что в 2016-й винде есть контейнеры (причём двух видов, настоящие и поверх hyper-v), что докер теперь будет их использовать со всеми вытекающими. Само собой нужно представлять что такое контейнер и чем от отличается от ВМ. Вот и всё что нужно знать, ну и посматривать за отзывами первых, кто осмелится опробовать технологию в деле.

Ну или вот возьмём TypeScript. Не обязательно писать на нём или знать его досконально. Достаточно понимать, что такое статическая типизация в языке, и уже можно будет представить разницу между использованием в большом проекте ES5/ES6 и TypeScript. Достаточно принять решение опробовать его у себя (как сейчас делаем мы) на небольшом куске проекта, и сделать вывод о дальнейшем использовании.

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

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

• для каких задач подходят функциональные языки, а для каких - ОО;
  
• что графовая СУБД как правило быстрее обрабатывает запросы на поиск с большой длиной цепочки;
  
• что утверждение из предыдущего пункта неплохо бы проверить на практике с конкретными СУБД;
  
• что веб-фреймворки бывают толстые и тонкие;
  
• какие сегодня есть вариации паттерна MVC;
  
• что сборка мусора это всегда накладные расходы и иногда не вполне предсказуемое поведение;
  
• что данные от пользователя нужно фильтровать, иначе в вашей системе найдут машину Тьюринга не там, где надо;
  
• что в информационной системе есть компоненты с разным уровнем доверия, равно как и сотрудники;
  
• что транзакции в СУБД придумали не для того, чтобы учебники стали толще.
  

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

Один последовательный участок памяти — это значит «последовательные адреса памяти». Таковыми будут массив простой и динамический, строка традиционного устройства, и все структуры памяти, что на них основаны. В том числе простейший стек и кольцевая очередь.

Для чего это нужно?
1. Это ближе к железу: проще код, лучше работает кэш, а значит, быстрее.
2. Некоторые функции, особенно нешаблонные, для своей работы требуют именно последовательных ячеек памяти.

Но если я реализую стек через список, разве это не будет противоречить сказанному?

Совершенно верно, будет. Отсюда и знаменитая ошибка «переполнение стека» — непонятно, как наладить стек вызовов бесконечной ёмкости и относительно простого устройства. Потому, если нужна очень глубокая рекурсия (например, при обходе сетей), стек вызовов приходится эмулировать.

Судя по контексту, у Вас ths - HTML DOM Input Text Object, оберните его jQuery
var self = $(ths);

При этом "узким горлышком" производительности веб приложений как правило является именно БД.

Логично, ведь большинство веб-приложений это выборка с некоторой простой обработкой. А БД не все умеют хорошо спроектировать.

Имеет ли смысл сортировать и группировать результаты выборки с помощью ЯП, чтобы убрать сортировку и группировку из запросов?

Это имеет смысл только если у вас вообще нет индексов, и по каким-то непостижимым причинам вы не можете их добавить. Чтобы отсортировать быстрее СУБД, нужно построить индекс самому, а вы вряд ли сделаете это лучше СУБД, еще и так, чтобы покрыть расходы на передачу данных. Группировку имеет смысл только если агрегирующая функция вычислительно очень сложная, но такое вы скорее всего в SQL запросе писать и не будете.

Даже если у вас sort и group действительно занимают основной процент времени, перенос этих операций в код приложения врядли вам поможет. Иначе говоря, пока вы добьетесь приемлемого результата от такого решения, вы добрую часть алгоритмов СУБД перепишите заново (сначала вы напишите индексы для поиска или сортировку слиянием, потом, как заметил Сергей Савостин у вас всё равно данные не будут влезать в ОЗУ и вы захотите писать их на диск, тут же вашу копию данных в приложении нужно будет синхронизировать и вы начнёте писать примитивную репликацию и так далее..)

У обычного объекта - нет. Но вы можете использовать Map.

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

Что из себя функция resolve представляет? Пробовали написать не 1, а 2, 3, 4 - результат меняется?

#include <iostream>

class Cam;

class OutputBuffer {
public:
    OutputBuffer() { std::cout << "OutputBuffer " << this << " initialized\n"; }

    void receive(Cam &cam) { std::cout << "OutputBuffer " << this << " receiving data from camera " << &cam << "\n"; }
};

class Cam {
    static OutputBuffer buffer;
public:
    Cam() { buffer.receive(*this); }
};

OutputBuffer Cam::buffer = OutputBuffer();

int main() {
    Cam cam1, cam2;
};

OutputBuffer 0x6013d1 initialized
OutputBuffer 0x6013d1 receiving data from camera 0x7fff7742970e
OutputBuffer 0x6013d1 receiving data from camera 0x7fff7742970f

Согласен, через greasemonkey - оптимальнее всего.
Ну берёте js-либу которая играет звук и по окончанию загрузки DocumentReady - парсите весь DOM: document.innerHTML (вроде так..)

IE=edge при заходе через IE указывает браузеру включать поддержку максимально доступной версии.
chrome=1 в IE при установленом плагине Google Chrome Frame включает рендер страницы через движок WebKit

Гуглится в 3 клика.
htmlbook.ru/html/meta

charset - Задает кодировку документа.
content - Устанавливает значение атрибута, заданного с помощью name или http-equiv.
http-equiv - Предназначен для конвертирования метатега в заголовок HTTP.
name - Имя метатега, также косвенно устанавливает его предназначение.