unclechu

Если речь именно об PR, - можете просто сделать новый коммит с удалением этих файлов (git rm somefile), а потом сделать squash (склеить ряд коммитов в один, про это можно почитать отдельно) для ветки с этим PR, сделать отдельную ветку, где всё слито в один коммит, где этих файлов уже не будет в истории, а старую ветку удалить и запушить её удаление (git push --delete origin some_branch_to_remove).

Покроет всё перечисленное - https://riot.im/
Это клиент к протоколу Matrix.

1. Открытый децентрализованный сервер (федеративный, т.е. возможно свободное общение между серверами)
   
2. Открытый клиент
   
3. Хранение истории на сервере
   
4. Обмен файлами
   
5. Групповые чаты
   
6. Аудио/видео звонки (в т.ч. групповые)
   
7. Демонстрация экрана (в Riot зажать Shift при клике на видеозвонок)
   
8. e2e шифрование
   
9. Поддержка Markdown для сообщений
   
10. Веб-версия клиента
    
11. Десктоп-версия клиента (gnu/linux, os x, windows)
    
12. Мобильные версии клиентов (anroid, iphone)
    
13. Есть русскоязычная локализация
    
14. etc.
    

Из недостатков можно отметить, что десктопная версия Riot сделана на Electron-е.

P.S. Можно задать интересующие вопросы тут: https://riot.im/app/#/room/#ru.matrix:matrix.org

Для начала нужно задаться вопросом: для чего вообще нужен SPA-фреймворк? Сокращённый ответ окажется краток: для декомпозиции больших сложных частей на более простые и понятные мылые (которые связываются между собой). В случае с лендингом, - едва ли вам нужен SPA ферймворк, только добавите боилерплейта (то-есть добавите сложности проекту, что противоречит изначальной цели фреймворка), да и jquery вам скорее всего тоже не нужен (разве что как обязательная зависимость для работы каких-то готовых интерактивных решений, слайдеров/галлерей).

Изучать какой-либо SPA-фреймворк или нет? Ну спросите себя, какого рода задачами вам хочется заниматься, хотите клепать лендинги? Или хотите работать в команде над созданием сервисов вроде того, на котором вы сейчас задали вопрос (т.к. тут уже применение парадигмы SPA будет уместно)?

В контексте сказанного попробуйте по пунктам ответить сами себе.

Вам нужно "мокать" данные от сервера, т.е. вам нужен некий временный http-сервер, который по указанным роутам просто отдаёт содержимое статических json-файлов. У вашего front-end приложения должен быть локальный конфиг, где указан путь до бекенда, туда, на момент разработки, вы подставляете свой псевдо-сервер, напр, http://localhost:9000/api, если вы используете webpack для сборки, то можно приспособить для этого webpack-dev-server, на своём опыте я так и делал, см. https://webpack.github.io/docs/webpack-dev-server.html, написав хэндлер определённого роута можете описать простую логику раздачи json-файлов или поищите готовые рецепты такого подхода. Можно описывать дополнительно в отдельном документе какой роут какого рода информацию должен отдавать для последующей передачи её бекендщикам для реализации в уже реальной серверной части.

Некоторые знакомые ребята пользуются некоей X Separate Screens, которая встроена в проприетарный драйвер NVidia. Вообще как-то задавался таким вопросом, в одном jabber-чате сказали, что если готов достаточно покрасноглазить, то руками и напильником можно такое сделать, я вобщем сам не углублялся. Возможно это ещё зависит не только от наличия двух дисплеев, а от наличия двух независимых видеокарт. А какие задачи планируется решать? Может посмотреть в сторону WM, которые умеют хорошо работать с независимыми воркспейсами? Например XMonad (набор воркспейсов к дисплеям только биндится, то-есть можно открыть на одном из дисплеев воркспейс, который до этого был открыт на другом)? Или dwm, у которого каждый из дисплеев имеет свой независимый набор воркспейсов (что при сноровке в общем-то можно реализовать и в XMonad).

Вообще можно провести эволюционную цеполчку:

1. Процедурное программирование
   
2. ООП
   
3. Функциональное программирование
   

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

Это если топорно и представлять мир как чёрное или белое.

Но вообще, судя по описанной картине — мужик начитался умных слов из книжек и клише, что мол вот тебе серебряная пуля, всё остальное — дно. Технологии уж точно слишком рано объявлять устаревшими, скорее мода на функциональщину новаторская (хоть и отнюдь не новая). Хоть идея на мой взгляд и хорошая, но с таким подходом к хорошему не приведёт, особенно без рвения и понимания с вашей стороны.

К тому же ФЯП не отменяет фреймворков.

Как-то писали «обычный сайт», в общем-то если собрать однажды гибкие и расширяемые «рельсы», то вполне можно делать и обычные сайты в том числе. В приведённом примере собрана достаточно гибкая и расширяемая админ-панель, можно юзать на условиях GNU/AGPL. Правда в качестве ORM для БД я бы порекомендовал взять что-нибудь аля монгус, т.к. в данном проекте главная боль в заднице — это были миграции для SQLAlchemy.

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

1. Всегда px;
2. По идее нужно использовать line-height, но когда столкнулся с багом фичей отрисовски шрифтов на яблооси (ни на одной другой ОСи это не повторялось, шрифт смещён относительно центра), то стал использовать box-sizing: border-box; и выравнивание через padding-top;
3. В фуррифоксе-то как раз со шрифтами всё хорошо, а вот хромоногий и его производные имеют с этим проблемы на шindows-ах, многие light-версии шрифтов в относительно небольшом кегле превращаются вообще не пойми во что, контуры частично исчезают. Делаю .otf, .woff, .svg (для старых IE .eot), вот пример с less миксином объявления шрифтов:
   
   @revision: 4;
   @tplPath: '/';
   @fontsPrefix: '@{tplPath}fonts/';
   
   .font-face(@fontname, @fontfile, @fontweight:normal, @fontstyle:normal) {
   font-family: "@{fontname}";
   src: url("@{fontsPrefix}@{fontfile}.eot?v=@{revision}");
   src: url("@{fontsPrefix}@{fontfile}.eot?v=@{revision}#iefix") format("embedded-opentype"),
   url("@{fontsPrefix}@{fontfile}.woff?v=@{revision}") format("woff"),
   url("@{fontsPrefix}@{fontfile}.otf?v=@{revision}") format("opentype"),
   url("@{fontsPrefix}@{fontfile}.svg?v=@{revision}#@{fontfile}") format("svg");
   font-weight: @fontweight;
   font-style: @fontstyle;
   }
   
   @font-face { .font-face('Roboto', 'Roboto-Regular'); }
   @font-face { .font-face('Roboto', 'Roboto-Bold', bold); }
   @font-face { .font-face('Roboto-Light', 'Roboto-Light'); }
   @font-face { .font-face('Roboto-Medium', 'Roboto-Medium'); }
   @font-face { .font-face('Roboto-Thin', 'Roboto-Thin'); }
   @font-face { .font-face('Roboto Condensed', 'RobotoCondensed-Regular'); }
   ;
4. Чтобы скролл не появлялся, — для родительского элемента ставится overflow: hidden;
5. Используйте Modernizr, делайте изначально бордюр через outline, а при наличии поддержки теней (html.boxshadow ...) убирайте outline и делайте нормальный box-shadow, а в Safari пусть правят баги, это не ваша проблема;
6. Возможно у вас JPEG, если дизайнер присылает рендеры не в PNG (или другом lossless), — бейте током;
7. От спрайтов отказался в пользу SVG файлов, все элементы сайта, как правило — векторные, в условиях торжества мобильных платформ, — использовать для этого растр — неразумно, в редких случаях PNG (когда это имеет какой-то смысл или безисходность), JPEG только для фотографий;

Я считаю, что начать стоит с освоения UMD (по ссылке также имеются примеры jQuery-плагинов), т.к. на сегодняшний день сколько-нибудь сложный фронт-енд как правило не обходится без AMD или CommonJS. Хорошим живым примером будет jQuery UI.

Хотел порекомендовать udev, вы хотябы в тегах конкретизируйте целевую ОС. А также ПО.

См. /usr/local, скорее всего установлено туда. А вообще конфигурируйте с ключом "--prefix /opt/temp_dir", собирайте и ставьте (тем же make install), а потом смотрите в /opt/temp_dir что где лежит и ищите в /usr или скорее в /usr/local, но имейте в виду, что вполне могли быть перезаписаны уже имеющиеся файлы, особенно если префиксом по умолчанию был /usr.

Если это серверный js: https://www.npmjs.org/package/deep-extend

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

Можно объявлять локальные переменные внутри конструктора и оперировать с ними через getter/setter, которые объявлены методами от this опять же в конструкторе. Но вообще общепринято выделять используя нижнее подчёркивание в начале имени свойства (аналогично Python, там тоже нет настоящих приватных свойств). Если нужна «защита от дураков», — то тут поможет кнут и маны по «правилам хорошего тона».

У меня появились подозрения на неоднозначность проблемы. Никакие способы не помогают. Это нормально что у меня запрашивается авторизация по HTTP-BA (с текстом: «Subdomain authorization»), а не через веб-интерфейс?

Может для начала CSS в студию? UPD: А лучше весь упрощённый пример на jsfiddle.net