Юрий Ярош

Зависит от конкретной версии PostgreSQL'я.
Если самый простейший - можно с коробки в 9.5 через postgres_fdw вот так . В <9.5 нельзя так как там внешние таблички (foreign tables) не могут наследоваться. Cам fdw afaik однопоточный по историческим причинам, по этому имеет смысл хранить сразу несколько шардов в пределе одного сервера.

Если нужна поддержка, и что-то попроще чем ванильный SQL, то лучше взять какое-то готовое расширение (extension) типа pg_shard, и потом докупить у них же их плюшки к PostgreSQL'ю по потребности. pg_shard умеет только операции равности (equality) хешей столбцов у шардов, эт значит что если выползти за границы таблички любым range query - оно начнёт бороздить все шарды, что порядком надоедает. Реализацию операций сравнения (больше/меньше) хешей пока не замечал, хотя давно его не ковырял. Т.е. хоть это и довольно таки простое решение, без понимания его ограничений чуть более чем наверняка можно напороться на квазилион граблей. Иногда складывается впечатление что разработчики специально затягивают feature list для того что бы клиенты переходили на их платный CitusDB.

Уууу.... CitusDB сегодня заопенсорсили.

PostgreSQL-XC нынче чуток морально устарел, и на его основе был разработан PostgreSQL-XL, про который уже упоминалось на хабре. Поддержки как таковой у него нет, но есть пару российских вендоров которые в нём перманентно ковыряются, так как это сугубо опенсорсятинка. Имхо, по функционалу оно на много превосходит pg_shard, и с ним нет таких дурацких проблем, хоть и разворачивается в разы сложнее, не без полуночного красноглазия.

У БЭМа есть ряд сугубо исторических причин существования:

• Когда-то в далёком 2008м был Firefox 3, в котором селекторы на классах работали быстрее чем на div'aх - потому что в префиксном дереве не выполнялся проход по фильтру Блума.
  
• Атомарный подход существовал ровно столько же сколько и XUL, но вместо изобретения индивидуального языка разметки, решили обойтись решением на основе стандартных CSS селекторов.
  
• Нужны были инструменты для автоматизации разметки по существующем иерархиям стилей - появился bemjson / bemhtml etc
  

Нужен ли БЭМ ?
Если вы понимаете приемущества атомарных подходов в верстке и активно их используете - он вам не нужен, и будет избыточен. В противном случае - берите и пользуйтесь.

Обычно оно бывает так.
Главным аргументом для внедрения БЭМа является возможность правки разметки с минимальными правками стилей, но и с хорошей семантикой старого-доброго html5 можно добиться тех же результатов, иногда, при правильной готовке, даже с приростом скорости рэндеринга.

В 18 прочитал "Шаблоны проектирования", и в 19 "Шаблоны проектирования корпоративных приложений" с "Зомбированные шаблонами и балдеющие от адреналина". Активно начал использовать в 19-21 год, когда начали появляться подходящие задачи. К самому GOF'у стоит относится скептически так как там описаны далеко не все существующие шаблоны, которые приходится использовать на практике, да и то максимум 3-4 шт на приложение.

Просто читать - бесполезно, нужно смотреть примеры реализации на различных языках, и реализовывать самостоятельно.

Если ставить OpenWrt, то да.
Но нужно уметь всякие JTAG'и, TFTP, и консольки по UART'у.
Совместимость вроде нормальная, но нужно смотреть ревизию конкретного экземпляра.

Учитывая количество каспа и знаков вопроса/восклицания, ответ будет - нет, не совместим.
И вообще не стоит надеятся что любой роутер можно использовать как NAS, без навыков прошивки и настройки linux'а.

Обычно для таких вещей люди учат вычислительную геометрию, и радуются жизни.
Конкретно в 3dMax есть MAXScript который имхо угъ, более целесообразно использовать для этих целей maya с питоном, можно вот так. Ну и блендером конечно такое можно тоже делать, но в maya пока имхо проще.

Да, вертексами двигать можно, да и вообще применять любые трансформации.

Pligg - большой noname сомнительного качества реализации и содержания.
Если хотите PHP - идите в сторону Symfony2 + Sonata и прочие бандлы, пилите по своим потребностям.
"Проще" - почти всё одинаково "сложно", и сложнее MVC + 5ая или 6ая нормальная форма БД ничего нет.
Я не люблю Django по причине довольно большего количества сомнительных поделок, чаще смотрю в сторону Pyramid + SQLAlchemy.

"Быстрее" - я бы сказал что ни пых ни питон особо "умом и сообразительностью" не отличается, хотя имхо РНР 5.6 работает шустрее CPython и чуток медленнее PyPy.

Если нужно "быстрее", в десятки раз, - лучше уходить в Java + Netty типа Vert.x или Play2, можно golang.

Бегать за производительностью платформы без острой надобности не стоит.
Если не планируется какая-то реактивность с богатыми фронтендами и всякими Flux/CQRS-ES etc для обновления контента по Websocket/SSE/longpolling etc - в большинстве случаев достаточно реализовать нормальное второуровневое кэширование, с учетом реляционной модели. Вот с РНР / Python / Ruby для подобных задач push-нотификаций надо крутить gearmand / celery / sidekiq - потому что нет нормальной многопоточности с коробки.

У скайпа было своё API, но его планировали прикрыть и/или сделать платным.
Раньше (лет 5 тому назад) для доступа использовался DBUS, так как скайп сначала был написан на дельфях и переписан на Qt.

В принципе ничего не мешает запустить иксы под виртуальным фреймбуфером xvfb и радоваться жизни.

На худой конец у скайпа есть вэб-интерефейс по которому можно щёлкать Selenium'ом.

google не ?

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

Высоконагруз начинается c 50К rps и 1GBit живого http трафика без статики.
Заканчивается где-то на 10M rps и 40GBit трафика. На одну ноду.

А вот выступления на HL++ в стиле: "Мы взяли, смасштабировали наше РНР 14K rps/node на 32 машины, 20 из которых простаивают на 50%", вызывает у меня ухмылку. Наверное, по этому и не развит, что у людей как-то профилирование и вертикальное масштабирование (эффективная утилизация аппаратных мощностей) в мозгу не приелось.

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

По поводу вариантов:
1. Гос. закупки сулят бумажными проблемами и сертификацией.
2. У "стартаперов" нет в мозгу должного QA и понимания долгосрочных перспектив, особенностей поддержки. Конкурсы и подобное обычно создаются с целью "вот мы вам дадим N рублей с расчётом, что через 5 лет вы сможете нам вернуть N * 10 рублей"
3. Читаем пункт 2.

Проекты на node.js/golang в 14K RPS и 1GBit, с фронтендами на React/Meteor, сложными или высоконагруженными называть не стоит, они сейчас скорее "стандартные" и "обоюдные".

Можно использовать WinRun4j или подобное.
К netbeans не имеет отношения, можно интегрировать с maven / gradle etc.

Все элементы DOM дерева с объявленным id автоматически становятся атрибутами глобального объекта window. console.log(box); и console.log(window.box); - одно и тоже. Это стандартное поведение для cовременных браузеров (ES5+ afaik) и одна из причин по которой секторы на основе id выполняются медленее чем уникальные селекторы на основе сlass атрибута, привет БЭМ.

На примере этой же страницы можно вбить console.log(window.adriver_banner_403766071); в консоль браузера.

В качестве самого хорошего примера сереализации советую рассмотреть ffjson. Обычно, рефлексией читают поля структуры и их аннотации и опосля кэширует их, ffjson напротив идёт путём кодогенерации. В некоторых случаях (с использованием интерфейсов в структурах) этот подход может быть ещё медленнее чем родной Marshal(), а для большей части прикладных задач, ещё и с использованием SIMD инструкций с SSE4 или SSE2 при работе со строками, получается сравнительно быстро. Ещё стоит глянуть исходники gob энкодера и декодера и почитать статью.

У Gulp'a есть родной фрактальний плагин к js-beautify.

А он умеет html / js / css бьютифицировать.

Я частенько пользуюсь atom-beautify на право и на лево.

Нет, бесплатных не существует.
Для хранения больших файлов стоит смотреть в сторону Amazon Glacier.

Вообще не вижу проблемы делать chunked file upload через какую нить JS file api обёртку.