nirvimel

Из асинхронной функции невозможно вернуть значение, потому что на момент выхода из неё оно ещё не определено.
Вы можете:

1. Вернуть промис, который будет возвращать значение
   
2. Принимать в асинхронную функцию другую функцию и вызывать её при получении результата, передавая его в качестве аргумента.
   
3. Сделать запрос синхронным и писать результат в глобальную переменную.
   
4. Использовать синтаксис async/await, если у вас свежая версия Node.
   

Первый вариант более современный и гибкий, второй более простой для понимания. По обоим вариантам есть масса информации, документации и уроков (подобный вопрос задаётся здесь ежедневно не по разу, поэтому не расписываю подробнее).
Третий вариант - кривой костыль и приведён только для полноты картины, не стоит так делать.
Чётвертый - это промисы для хипстеров, лучше использовать его тогда, когда вы хорошо умеете работать с промисами, чтобы случайно ничего себе не отстрелить.

Spine C runtime.
https://github.com/EsotericSoftware/spine-runtimes...
Это не серебряная пуля и не идеальные практики. Пожалуй, в плане кода это пример наоборот, как код писать точно не надо.
Но вот в плане реализации анимаций эта репка тебе очень поможет.

Суть такова. Есть модель, она статична. Есть отрезок времени (таймлайн), на этом отрезке есть точки - ключевые кадры. Ключевой кадр несет в себе информацию о том, какую часть модели и как сместить. Чем проще инструкция в ключевом кадре, тем удобнее. Масштаб, поворот и смещение многие любят разделять по разным таймлайнам.
OGL в этом деле не нужен, до поры.

С помощью SRT таймлайнов можно анимировать объекты в пространстве целиком, но если тебе захочется точно так же анимировать части меша модели, то впереди тебя будут ждать трудности.
Анимацию меша лучше реализовать на основе скелета. Это дело в двух словах уже не описать, тут лучше читать статьи.
www.gamedev.ru/code/terms/SkeletalAnim
www.gamedev.ru/code/articles/skeletal_animation
https://habrahabr.ru/post/219509/
https://habrahabr.ru/post/304042/
www.gamedev.ru/code/articles/?id=4182

Самое зерно скелетной анимации в том, что модель остается моделью, анимируются только кости скелета. И именно анимация кости приводит к перемещению фрагмента меша.

Только на одной скелетной анимации далеко все равно не уедешь. Когда требуется на одной модели одновременно задействовать сразу несколько скелетных анимаций, если сделать в лоб, то меш поплывет во все стороны.
Для смешивания различных скелетных анимаций применяют так называемые Blend Trees (ссылок под рукой нету, так что сорри).

В общем, как то так анимация выглядит. Анимируем в цикле обновления, вершины трансформируем в момент формирования кадра. OGL нам нужен, собственно, чтобы нарисовать раскоряченый анимацией меш.
OGL для непосредственного анимирования мешей тебе понадобится только тогда, когда ты достаточно глубоко нырнешь в анимации, в тот же момент ты уже полностью поймешь что от OGL понадобится для этого.

Я бы посоветовал завести себе какой-нибудь сервис для Continous Integration, например Jenkins.
Он позволит несколько усложнить задачу (кто бы мог подумать, что усложнить - это что-то хорошее!), например:
* Мониторит git / svn / hg / что угодно на предмет новой версии
* Забирает новую версию
* Прогоняет тесты
* В случае невыполнения тестов отправляет провинившемуся разработчику push / email
* В случае выполнения тестов выполняет деплой, и/или например отправляет артефакт в репозитарий, или образ докера в репозитарий.

Для маленького проекта на 5 файлов, конечно, Jenkins это из пушки по воробьям, и тут наверняка лучше будет rsync (если применимо). Но чем больше проект и чем больше тестов и вариантов сборки, тем полезнее может быть Jenkins.

У нас как только не используется: и собирает докер образы (в случае успешной сборки и тестов - в репозитарий), и собирает java-артефакты (аналогично, собрался - пошёл в maven). Собирает приложения на spring-boot, копирует их на целевой сервер, делает из них сервис и сам его перезапускает.

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

Видел всякие разные конфигурации, даже такую, когда для сборки проекта покупалась виртуалка на amazon, делала сборку и уничтожалась :) Вопрос лишь в извращённости сознания администратора Jenkins. Ну и, конечно, максимально хорошо он интегрирован с Java. JetBrains TeamCity, Atlassian Bamboo - в общем-то тоже.

Никак.
Потребление памяти определяется самой программой, способ запуска на это никак не влияет.

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

Это как раз способ уменьшить объем доступной памяти.

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

Конкретно мое мнение: влиять на технический рост IT-специалистов нужно осторожно. Инженеры - это очень пунктуальная и ревностная(в проф. плане) категория людей. Сотрудники уже в компании, а значит имеют достаточный(по-вашему мнению) скилл. Уважающие себя программисты читают книги, ведут home-проекты, где оттачивают навыки(я, надеюсь, у Вас именно такие:)).

Идти нужно от простого: что есть отрицательного в работе => подавляет энергию => не хочется творить => не развиваешься. Недопонимание между операционной и технической командами? Потому что первые постоянно закидывают мозговыносящими задачами, а вторые, исправляя баги, добавляют новые. Ты в "ынтерпрайзе" и ограничен в своих действиях, ибо никто не хочет внедрять "по свистку" новый фреймворк(надежность в угоду моде)? Менеджер снова завалил какими-то непонятными задачами и т.д., сделав которые, понимаешь, что их можно было по-другому сгруппировать? Можно продолжать... Часть этих проблем можно решить нормальной, здоровой коммуникацией(иногда стоит пойти на жертвы среди сотрудников - было у меня и такое).

Я не менеджер. Расскажу о 3-х летнем опыте(со старших курсов универа), который был стартом мой карьеры. Определенно, многому научился тогда. Исходные данные, чтобы было понятнее: организация(иностранная, если это будет важно) с представительством в РФ, Отдел внедрения IT.

Эту фразу нужно будет поместить на место трех точек в каждом пункте("..."):
Не каждому сотруднику это нужно, но обязательно найдутся те, кому будет полезнее именно так.

Что мне со стороны сотрудника показалось важным для роста:
0. Толковые тимлиды/архитекторы, готовые делиться знаниями - таких нужно выискивать и направлять их на менее опытных. Я в свое время с бешеной скоростью впитывал знания от старших товарищей. Команда сильна насколько силен самый слабый(и прочие бла-бла). Во-всяком случае, меня их уровень подстегивал. Это важный фактор, как ни крути. Должны быть лидеры(кстати, не только технические).
...
1. Прозрачная система ведения бизнеса. Это значит, что информация о том, что происходит в компании на поле битвы(бизнеса) доступна и понятна каждому сотруднику безотносительно его должности. Хочет программист/тестировщик знать как дела обстоят с новыми клиентами, в каких тендерах участвуем - пожалуйста. Но без фанатизма и раннего открытия информации. Какие настроения у текущих клиентов? Какие внутриорганизационные моменты происходят?...
...
2. Каждый сотрудник может спокойно организовать one-to-one с менеджером. Поговорить о выполняемых задачах, подвести итоги, обсудить какие-то планы на будущее(по бизнесу, по своему привлечению к будущим проектам, по возможному росту, по текущим задачам коллег). Сотруднику становится проще понимать прикладную составляющую своего труда и выдвигать свои идеи и предложения(разумно). Менеджер знаком с настроением каждого члена команды => распределяет задачи более оптимально, ну и в целом легче ему становится "дергать" нити управления.
...
3. Как можно более индивидуальный подход в "конвейерных" тренингах. К примеру, занятия English: вот походили мы с ребятами на корпоративные уроки - но это было больше похоже на курс для галочки(большинство "учащихся" на абы как, учителю как ни старайся...). А время шло, и я в N-ый раз уже слышал менеджера "на колле" с иностранцами. Тут родилась идея объединиться в группу с тему, кому действительно ХОЧЕТСЯ и найти себе преподавателя из школы. Сказано - сделано. Больше года занимались с отдельным преподом, который к нам приезжал в офис. Потом даже выбили себе немного бюджета на это c помощью менеджера(не 100% покрыли конечно). И в итоге все довольны - мы знаем английский(главное, что потом и применять стали), у компании, соотв., тоже одни плюсы.
...
4. Давать сотрудникам иногда чуть более важные задачи, чем они привыкли делать. Давать вистов иным образом. Здесь конкретные примеры сложно привести. Допустим, взять программиста в командировку на локацию на этапе оценки инфраструктуры и знакомства с клиентом. Хотя он там не особо-то еще нужен. Или в конференцию его подключить по важному вопросу. Нужным людям это даст больше уверенности и мотивации, и они сами будут готовы генерировать идеи во благо, без палки даже.
...

P.S. Я уже не там, да и вообще круто(от слова "резко") поменял стек технологий. Но ценю тот опыт, который смог там получить.

Часть первая, добрая

1. Идете к юристу и оформляете правильную лицензию, в которой вы предоставляете право на использование вашего продукта. Жестко запретите модификацию кода CMS всеми, кроме вас. Оставьте за собой право модификации кода удаленно, в любое время без предварительных уведомлений. Оставьте за собой право отзыва или изменения лицензий без уведомлений и объяснений. Запретите перепродажу. В лицензии добавьте оговорку насчет статьи 273, что действия по модификации кода сайта являются санкционированными и неотъемлемой частью продукта.
2. Реализуете и обкатываете механизм автоматического лицензирования через интернет. Вешаете лицензионное соглашение на официальный сайт продукта.
3. Рассылаете всем нелицензионным пользователям "письмо счастья", в котором доходчиво объясняете, что их копия не лицензирована и т.д. Рекомендую вам разрешить использование своей CMS для некоммерческих организаций и домашних страничек без рекламы при наличии ссылки на сайт продукта. Предложите бесплатное обновление для некоммерческих пользователей.

Часть вторая, злая

1. После введения новой лицензии, но до уведомления всех письмами счастья, удаленно зашиваете код, который будет выводить html-комментарий о том, что данная копия не имеет лицензии т.д. и т.п. Там же должна быть ссылка на ваш сайт, где можно лицензировать продукт. Данный шаг не будет препятствовать работе с сайтом.
2. Рассылаете письма счастья.
3. Ждете, пока пройдет срок, в течение которого компании должны лицензировать свои версии.
4. Вместе с юристом выбираете компанию, на которую вы подадите в суд за нелицензионное использование своей CMS и у которой точно выиграете дело. Судитесь. Выигрываете. Далее на сайте проекта вешаете официальную информацию о судебном разбирательстве и решении в пользу истца. Делаете огласку истории, публикуете ее на всяких Спарках/Хабрах/Цукербергах и прочих ресурсах.
5. Через месяцок рассылаете новые письма счастья с уведомлением о том, что бывает с теми, кто отказался. Ссылку на результаты разбирательства приводите.
Плюс, можете вывесить список сайтов у себя, где нелегально используется ваша CMS.

Работайте и разговаривайте исключительно с компаниями, которые непосредственно зарабатывают деньги через вашу CMS и для которых сайт действительно важен. На школьников, геймеров и мусор не тратье время. Шкурка выделки не стоит.

Часть третья, плохая

Для всяких нехороших людей, ничего из себя не представляющих и пишущих маты вам в ответ, включайте 404-ю для поисковых роботов. Они очень громко будут вас ругать на форумах. Не обращайте внимания.

Это называется фрагментация памяти. Некоторые «мусорщики» (как в Java или C#) способны сдвинуть объекты и получить большой непрерывный отрезок.
Менеджер памяти C++ дефрагментировать память не способен и выдаст нехватку памяти.
В любом случае, массив — что в Java, что в C++ — будет занимать непрерывный отрезок памяти.

Чтобы совмещать мусорные языки с системными интерфейсами, есть способы пометить структуру как неперемещаемую. Но это уже на стыке виртуальной машины Java/C# и системного кода, который пишется на Си(++).

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

location.href = 'javascript:alert(1)';