tamtakoe

Есть костыль:

#define Class3 Class3_Unused
#include "module1.h"
#undef Class3

Таким побразом при включении module1.h вместо Class3 будет объявлятся какая-то хрень, которую нигде вы использовать не будете.

Правда, все ломается, если у вас этот module1.h включен по цепочке других инклудов. Надо аккуратно в каждом месте, где вы его включаете так же обарачивать в define.

Но по уму, это большой косяк авторов module1 и module2, что они не используют namespace. Их надо бы переписать.

Мне кажется с блокировками вы несколько путаетесь. В данном случае могут быть заблокированы 2 объекта на одной файловой операции:
1. поток, использующий синхронную операцию чтения/записи в файл
2. файл открытый для монопольного доступа

Думаю ваш вопрос не связан с п.1, т.к. это больше про параллельное программирование, а не про файлы и БД.
Файловые операции легко могут не блокировать поток - асинхронный ввод/вывод.
Файл можно открыть с монопольным доступом и с общим доступом. В общем доступе этот же файл может открыть и другое приложение одновременно с вашим.
При общем доступе вы можете блокировать какую-то область файла и работать с этой областью "монопольно".
БД открывают свои файлы в монопольном режиме.
В разных потоках одного приложения вы можете открыть файл один раз и работать с одним и тем же дескриптором файлов из разных потоков. Но это может создать кучу проблем с целостностью структуры файла, если много потоков будут не согласованно писать в файл.
Файловые операции ОЧЕНЬ медленные. Поэтому все нормальные базы данных работают через свой собственный кэш. Поэтому там, обычно нет кучи потоков, которые лопатят файл БД. Движок SQL берет данные из кэша, есть некий "менеджер кэша" - отдельный поток, которому движок дает запрос на данные, если данных в кэше прямо сейчас нет, то менеджер кэша читает данные из файла в кэш и отдает эти данные запрашиваемому потоку. Чтение файла наверняка то же идет не на прямую, а запросы на чтение ставятся в очередь и возможно какой-то другой поток (или тот же менджер кэша) по очереди читает необходимые данные. Аналогично и с записью - через кэш и последующую очередь на запись.
Если запустить MS Sql Server с настройками по умолчанию с достаточно большой по объему базой он довольно быстро отожрет в компе вообще всю свободную память (конечно, если БД меньше, чем объем ОЗУ, то всю память не отожрет). Не то что бы ему очень нужно прямо сейчас вот столько памяти (он может в это время вообще простаивать), просто он начитал данные в кэш.
Как-то так я это вижу.

как тогда работают БД?

Пускай Ораклисты меня поправят но по моему DBMS Oracle не использует потоки. По крайней мере
на уровне терминологии и документации все составные части Oracle - это процессы PMON, SMON, DBW...
И пользовательские сессии тоже представлены процессами. По крайней мере отстрел пользовательских
сессий через orakill / kill тоже привязан архитектуре процессов.

или у БД своя файловая система?

Да Oracle может использовать ФС ext3/4 например или работать поверх технологии ASM (это 2-в-1 и менеджер
томов и кластерная ФС) но мне кажется что к сути вопроса это не относится.

По старой памяти у меня в голове крутится параметр FILESYSTEMIO_OPTIONS, он отвечает за тип I/O
операций которые DBMS будет использовать. Там кажется ASYNC, DIRECT и их комбинации. Вобщем
почитай тоже по этому вопросу.

Посмотрите в сторону функции eval().
Описание: https://learn.javascript.ru/eval

Правда, eval() редко используется. Чаще, если необходимо выполнить какие-либо расчеты после, например, заполнения пользователем какого-то поля, описывается обработчик события (отлавливается клик пользователя на кнопку, отправка формы, наведение курсора куда-либо и т. д.).
Описание: https://learn.javascript.ru/introduction-browser-events

Если расчет достаточно сложный и требует связи с бэкендом - используют AJAX-запросы.

Не согласен с предыдущим оратором (@geeek), в частности с утверждением

В общем если хочешь быть в тренде - бери

- Meteor совсем не в тренде.

Если дать краткий и резкий ответ на вопрос "расцветает или чахнет?" - отвечу: интерес к Meteor чахнет, не смотря на все усилия команды разработки.

Компания MDG (Meteor Development Group) подняла $31M инвестиций (https://www.crunchbase.com/organization/meteor) и хотела всё сделать круто, стать мейнстримом, а потом зарабатывать на хостинге Meteor проектов - такой план монетизации. Хостинг они, кстати, сделали. И в какой-то момент было много хайпа вокруг Meteor, казалось, что всё идёт по плану. Полтора года назад вышел Meteor 1.0 (октябрь 2014), потом была пара хороших релизов, которые убрали всю "сырость": Meteor 1.1 и 1.2.

Но в середине 2015 стало понятно, что никаким мейнстримом они не стали, мейнстрим нынче React!
Не смотря на простоту старта и скорость разработки с Meteor, были очевидны следующие минусы:

1. Собственная система пакетов со своим центральным репозиторием https://atmospherejs.com - посмотрите на счётчики скачивания пакетов, это крохи по сравнению с npm. Посмотрите на активность разработки основных пакетов - всё очень тухленько.

2. Собственная система сборки. С одной стороны всё работает из коробки, с другой стороны в неё не вклинишься (это сложно). Плюс всякие странные условности, что всё в глобальном пространстве имён и ваши js файлы загружаются в алфавитном порядке. В Meteor 1.3 частично решили проблему, ходят слухи, что в будущем будут использовать webpack.

3. Собственный шаблонизатор blaze (похож на handlebars). В начале blaze выглядел хорошо, но теперь все внезапно пишут на React и многие потирают руки в ожидании Angular 2, в итоге blaze оказался ещё один велосипедом, с которым не понятно что делать.

4. На бекенде всё ещё Node 0.10. Даже с Node 0.12 Meteor уже не работает из-за некоторых бинарных зависимостей! Обещали в будущих версиях обновиться с поддержкой Node 4.

5. Метеор сильно завязан на MongoDb. Чтобы реактивно доставлять новые/изменившиеся данные от сервера в бразуер они парсят логи Mongo. Были попытки сделать аналогичное для SQL баз, но не увенчались успехом. В итоге встречайте их новый проект Apollo, который поверх GraphQL и не привязан к конкретной реализации бекенда www.apollostack.com А что теперь будет со старым добрым DDP?

6. Ваше Meteor приложение одной командой можно упаковать в мобильное приложение Cordova - выглядит круто, но сейчас время ReactNative и вот мы читаем обсуждения на форумах, что возможно, они таки интегрируются с ReactNative, но когда?

Подводя итог: ребята из MDG подняли кучу денег и хотели сделать всё сами: свои пакеты, свою сборку, свой шаблонизатор, свой реактивный протокол (DDP) и чтобы всё работало из коробки. И они сделали это!

Только это оказалось никому не нужно, т.к. для пакетов все сидят на npm, сборка должна быть гибкой (и поэтому у нас есть gulp и webpack), самый модный шаблонизатор нынче - это React, реактивный протокол GraphQL и базы на сервере люди любят разные, а не только MongoDb. А Meteor, по сути, остался на обочине всей экосистемы и движухи вокруг JavaScript. Поняв это, MDG начали двигаться в сторону JS комьюнити и первый шаг сделан: Meteor 1.3 поддерживает нормальные модули ES2015, npm пакеты, рендринг через React и Angular. Но Meteor 1.3 - это куча костылей поверх старого велосипедного Meteor. Почитайте их планы на будущее в официальном блоге, хотя бы в этом посте: info.meteor.com/blog/announcing-meteor-1.3 - им по сути предстоит переписать всё заново! И первые ласточки такого "переписывания" - это выделение проекта Apollo.

Возможно, со второй попытки они всё сделают правильно и Meteor 2.0 действительно выстрелит. Если только у них деньги не закончатся раньше.

Сейчас можно взять Meteor и эффективно зарабатывать на маленьких/средних фриланс проектах, когда нужно сделать быстро и не думать о долгосрочной поддержке.
Если же вы делаете большой продукт, то вас ждут большие потрясения и изменения в экосистеме Meteor.

Вот такая штука у меня в подвале, помимо синхронной загрузки скриптов из массива scripts, после загрузки вызываются функции из массива scripts_cb

var scripts = ['/style/jquery-1.7.1.min.js','/style/jquery.boxy.min.js','/style/smspilot.js?v2.3'];
var scripts_head = document.getElementsByTagName('head')[0] || document.documentElement;

var scripts_cb = [];
function scripts_ready( callback ) {
	scripts_cb[ scripts_cb.length ] = callback;
}
function scripts_loaded() {
	
	scripts.splice(0,1);
	
	if (scripts.length > 0) {
		scripts_load();
	} else {
		for( var i = 0; i<scripts_cb.length; i++) {
			scripts_cb[i]();
		}
	}
}
function scripts_load() {
	var script = document.createElement('script');
	script.type = 'text/javascript';
	script.async = true;
	script.src = scripts[0];
	script.onload = scripts_loaded;
//	script.onerror = onerror;
	script.onreadystatechange = function () {
		var state = this.readyState;
		if (state === 'loaded' || state === 'complete') {
			script.onreadystatechange = null;
			scripts_loaded();
		}
	};
    scripts_head.insertBefore(script, scripts_head.firstChild);
}
window.setTimeout('scripts_load()', 50);

Есть очень хорошая библиотека, он не большая (2kb), и может отслеживать загрузку как js так и css файлов
Fallback JS.

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

Если действительно хочется решения на чистом JS без использования каких-либо библиотек, то можно скачивать скрипты при помощи XMLHttpRequest и вставлять в DOM тело скрипта.
Пример::

function fetch(url,callback){
    var req = new XMLHttpRequest();
    req.open("GET",url);
    req.onload = function(){
      callback(req.responseText);
   }
   req.send();
}

function insertScript(scriptBody){
   var script = document.createElement('script');
   script.innerText = scriptBody;
   document.body.appendChild(script);
}

var scripts = ["/first.js","second.js"];
var bodies = new Array(scripts.length);

scripts.forEach(function(script,index){
    fetch(script,function(body){
        bodies[index]=body;
        if(bodies.every(function(el){return el})) {
             bodies.forEach(insertScript);
        }
    });
})

Скачайте putty
Подключитесь к серверу по ssh своей учетной записью
Затем в консоли наберите su и нажмите Enter. На запрос пароля - введите пароль рута. Все - вы рут!

Сама идея имеет много плюсов...

Вот именно, всё правильно описали. Чем модульнее, чем распределённее, и чем чище схема взаимодействия между модулями - тем лучше.

Минус в производительности

Зависит от архитектуры, может быть и плюс.

Может быть не http а что-то более быстрое использовать?

Попробуйте. Можно попробовать чистый TCP, почему бы и нет...

Можно.
1) Заходим https://itunesconnect.apple.com/
2) Переходим в Manage Users
3) Выбираем тип учётной записи itunes connect user
4) Нажимаем Add User
5) Для того чтобы пользователь мог видеть только отчёты достаточно выбрать права на "Sales"

Лучше воспользоваться специализированным сервисом, AppAnnie www.appannie.com или Distimo www.distimo.com
Они берут отчеты непосредственно у Apple под вашим аккаунтом и выводят все в удобном виде, с графиками, множеством фильтров, и показывают статистику положения в сторе разных стран. Можно шарить информацию другим пользователям через инвайты.

Если single контракт, то по моему нельзя. Если company контракт, то можно создавать отдельных пользователей для разных ролей.

Возможно www.fastpictureviewer.com

@require 'имя_модуля/**/*.styl'; //И эта тоже

По логике должна работать такая:
@require '*/*/*.styl';
А ещё тут написано, что паттерн "**" по умолчанию выключен.

Основа всего что касается продаж, маркетинга, исследования потребителей, Клод Хопкинс "Моя жизнь в рекламе, Научная реклама" www.koob.ru/hopkins/#books

Помним, что ВСЕ ветки в git равноправны и термин унаследована от той или от той не верен.
Еще стоит помнить, что гит оперирует состояниями проектов. И с одной стороны коммит - хранит дельту состояния, а с другой все состояние целиком.

Теперь же давайте задаим вопрос иначе?

1)Ветка experiment - это что? Побочная ветка, в которой работа идет над отдельной фичей?
Тогда смысла обновлять ветку experiment нету. А лучше использовать по окончании экспериментов слить ветку с мастером с помощью merge.

2)Эта ветка является ответвлением, где началась над новой версией продукта, а в мастере содержаться фиксы, которые должны быть перенесены в новую версию? Тогда логичным выглядит использование патчей.

3) В ветки experiment ведется паралелльная, альтернативная разработка? Тогда лучше использовать rebase, тогда все ваши коммиты окажутся сверху и ход вашей разработки не будет нарушен

Rebase как раз и сделает так что головой ветки experiment как раз и станет последний коммит m11 в master.

$ git init
$ echo 111 > 1.txt
$ git add .
$ git commit -m "m10"
$ git checkout -b server
$ echo ser >> 1.txt
$ git commit -am "s11"
$ echo ser1 >> 1.txt
$ git commit -am "s12"
$ echo ser2 >> 1.txt
$ git commit -am "s13"
$ echo ser3 >> 1.txt
$ git commit -am "s14"
$ echo ser4 >> 1.txt
$ git commit -am "s15"
$ git checkout -b experiment
$ echo exp1 >> 1.txt
$ git commit -am "e1"
$ git checkout server
$ echo ser5 >> 1.txt
$ git commit -am "s16"
$ git checkout master
$ git merge server
$ git checkout experiment
$ git rebase master
# будут конфликты, решаем их
$ git mergetool
$ git rebase --continue
$ gitk --all

CamelCase — ВерблюжьяНотация
locale — так же локализацция
mock, mock implementation — имитация, «заглушка»
deffered — так же отложенный
deep-linking — мне кажется глубокое связывание, возможно внутреннее свзывание
evaluate — вычисление, в разных контекстах еще и выполнение