Юрий Ярош

Сначала происходит загрузка boot.js или node_boot.js - там в window или global пишутся все методы jasmine интерфейса. Типа вот так

'use strict';

var jasmineRequire = require('jasmine-core/lib/jasmine-core/jasmine');

var jasmine = jasmineRequire.core(jasmineRequire);
window.jasmine = jasmine;

jasmine.DEFAULT_TIMEOUT_INTERVAL = 1000;

var env = jasmine.getEnv();
var jasmineInterface = jasmineRequire.interface(jasmine, env);

function extend(destination, source) {
  for (var property in source) {
      destination[property] = source[property];
  }

  return destination;
}

extend(window, jasmineInterface);

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

Инициализация под node.js отличается лишь ConsoleReporter'ом, в браузерной используется HtmlReporter.

После инициализации в window / global уже есть все it describe expect барахло, и можно писать спеки,
для их запуска просто делается
jasmine.getEnv().execute();

Там для ноды отдельно есть "удобная" обёртка для ленивых...
Если глянуть исходники, то в принципе должно быть понятно по основным методам

showColors - отображать ли разноцветные сообщения, форточки не умеют
addSpecFile - добавить файлик спеки
addReporter - добавить репортер
configureDefaultReporter, он же ConsoleReporter
addMatchers не помню
loadSpecs - просто require спеков
loadHelpers - просто require хэлперов
loadConfigFile - загрузка конфига
loadConfig - загрузка конфига с объекта
addSpecFiles - добавить кучу файлов спек
onComplete - вызвать callback по завершению
stopSpecOnExpectationFailure - прервать выполнение тестов если возникает исключение

В принципе

var Jasmine = require('jasmine');
var jasmine = new Jasmine();

jasmine.loadConfig({
    spec_dir: 'tests',
    spec_files: [
        'requests/**/*.js'
    ],
});

// или jasmine.loadConfigFile('spec/support/jasmine.json');

jasmine.configureDefaultReporter({
    showColors: false // если это форточки
});

jasmine.execute();

Для запуска тестов в node.js будет достаточно.

Эмм... для начала нужно выучить мат часть и разобраться что такое B-tree и R-tree и как они фигурируют в современных СУБД, разобраться что такое "6ая нормальная форма" (второй курс универа).

Если это мускуль у которого "бесконечная длинна" таблички - от 200Гб и до 1Тб, то достаточно просто использовать ENGINE ARCHIVE c R-tree индексом. В противном случае (если меньше 200Гб) нужно (учить мат часть и вправлять мозги) рефакторить базу. Лучше слезть с MySQL на PostgreSQL, а вот c MongoDB - куча проблем. Стандартные СУБД на основе B-tree для баз от 200Гб+ не подходят. MySQL исключение из-за модульности системы хранения, имеется ввиду ENGINE ARCHIVE, но так как там нет T-tree - нужен нормальный кэш. PostgreSQL даже похуже будет - нужно ковырять различные расширения типа cstore_fdw и т.п.

uint64 ID'шник в виде хэша - очень спорное решение, даже если и предположить что в какой-то вселенной нет коллизий, то точно не в этой, и дополнительно нужно прогонять фильтр Блума. Хотя, лучше всего, просто использовать композитные ключи и не заморачиваться.

Можно ещё попробовать HBase в Apache Phoenix обернуть, там уже есть всё готовое - и фильтр Блума и индексация, можно даже X-tree оформить. HBase, кстати, хорошо масштабируется на запись, а Cassandra, наоборот, - на чтение.

Шардинг (партицирование) и репликацию нужно оформлять когда схема хорошо нормализирована, и когда более-менее ясно какие таблички нужно масштабировать на запись, а какие на чтение - где-то нужен CA, где-то CP, а где-то AP... (CAP теорема)

Очень весело в PostgeSQL писать сишные функции для агрегации в материализованные представления, особенно весело с GPGPU.

Если читатать доки - становится понятно что есть опция exclude,
которая принимает строки и регулярки.

var wiredep = require('wiredep').stream;

gulp.task('wiredepWIthoutJquery', function() {
  return gulp.src('index.html')
    .pipe(wiredep({
      exclude: [ /jquery/],
    }))
    .pipe(gulp.dest('./dest'));
});

Входит общий чистый доход, с учётом вычитания налогов и сборов.
Можно пробовать CoronaSDK, правда там и по графике и по функционалу всё на много беднее.
Я бы ушёл в Unreal только в случае нормальных навыков С++'a и желания полезть в их Trello / Github issues в случае возникновения проблем, а багов там до сих пор хватает. По функционалу "c коробки" у UE сейчас большое преимущество.

Unity - более стабильный, менее производительный, на много проще, и обходится немного дешевле в долгосрочной перспективе (более 2 лет жизни проекта).

Нужно проверить определение существующих Maven/Ivy репозиториев в build.gradle нужного модуля.
И вот что там можно сделать:

repositories {
    ivy {
        url "http://mycompany.com/repo" // нужно проверить доступность
        // или
        url "../local-ivy-repo" // для локальной папки с Ivy репозиторием
        
        // В Ivy можно указать структуру каталогов для поиска и путь к ivy.xml явно
        // Таким образом можно описать путь для любых зависимостей по http/https'у 
        layout 'pattern' , { 
            artifact '[module]/[revision]/[artifact](.[ext])'
            ivy '[module]/[revision]/ivy.xml'
        }
    }

    // Тоже самое можно и для Maven'a
    maven {
        url "http://repo.mycompany.com/maven2"
        // или
        url "../local-maven-repo"

        // В MavenArtifactRepository нет возможности прописать Layout, по понятным причинам

        // А ещё и в Ivy и в Maven'e можно указать пароль к AWS'у или http auth, правда это нестабильная фича
        credentials { // или credentials(AwsCredentials) {
            accessKey "myAccessKey"
            secretKey "mySecret"
        }
    }
}

Maven и Ivy используют разные структуры папок, так что, при внесении изменений вручную, это нужно иметь ввиду. Хотя для Ivy можно явно указать layout 'pattern' для самопальной структуры, а вот в Maven'e afaik так нельзя.

Если совсем-совсем не заморачиваться, можно положить все jar'ки в папочку libs и добавить их в зависимости, вот так

dependencies {
    runtime files('libs/a.jar', 'libs/b.jar')
    // ну, или так
    runtime fileTree(dir: 'libs', include: '*.jar')
}

Пишите если нужно будет что-то уточнить.

Из интересных и перспективных структур пока откопал Fusion-tree и AF-heap.
Было бы неплохо оформить cache oblivious версии.