seosova: нормальная практика - брать несколько операционок и разбираться как работают различные тулчейны под различные платформы и архитектуры. Ещё раз повторюсь, в данном случае cmake используется лишь как генератор проектных файлов для VS или make / nmake, а компилятор можно использовать любой, и непосредственно к cmake это не имеет никакого отношения - у каждого компилятора могут быть свои глюки, которые обычно сводятся к наличию/отсутствию различных #pragma и поддержке всякой posix совместимой всякости.
Для параноидальных форточников, конечно, такая практика может быть и непривычна, но потом никто не мешает собирать те же dll'ки под линуксом, или макосью без какой-либо существенной разницы.
На самом деле сборка DLL библиотеки в cmake сводится к двум строчкам
CMAKE_MINIMUM_REQUIRED (VERSION 2.6)
ADD_LIBRARY(randomLibName SHARED one.c two.c three.c)
sim3x: кстати да... а я уже совсем забыл что он на golang тоже уполз.
В любом случае я сяду летом штопать порт golang'а под JVM, возможно даже сагитирую Дмитрия Вьюкова... так что будет ещё веселье в нашем детсаду.
nepster09: не мне решать зачем это нужно делать. Ничего не мешает координаты и названия которые определило geoip ложить в сессию пользователя и не дёргать каждый раз geoip и/или геокодинг/геолокацию гуглокарт.
В геолокации google используется банальный W3C Geolocation стандарт: GPS есть - жизнь удалась, GPS'a нет - получаем позицию ближайшего пограничного маршрутизатора вообще в другом городе.
Нет, правильно записывать IP пользовательского запроса и по нему получать координаты город/улицу, потом можно использовать эти координаты в рамках гуглокарты и по потребности получать прочую информацию геокодинга.
sim3x: потому что в JVM время компиляции на много больше и соответственно период повторного прогона тестов выше, в том же Goconvey можно гонять тесты каждые 1-3 секунды. В gradle с демоном на тот же самый объём тестов и исходников уходит в среднем 7-15 секунд, не учитывая времени выполнения самых тестов которое обычно происходит довольно медленно.
OpenGL - это не библиотека !
Сама библиотека в которой реализован интерфейс OpenGL поставляется с драйверами под вашу видеокарту.
И тут вряд ли кто-то сможет заванговать как и почему у вас оно где-то не определяется.
Да, в принципе можно взять тот же Phalcon, нормально кэшировать запросы в БД и не заморачиваться. Если у вас модель БД "черезодноместо", а так оно бывает у 80% людей которые задают подобные вопросы, то тут никакой фреймворк/язык/законы вселенской магии не помогут вам сделать ваш сервис быстрее - нужно было нормально организовывать работу и проводить QA.
Виктор Ablebeam: если в двух словах - проблемы будут.
Я понял - речь была о вертикальном масштабировании со стороны Ruby.
Нет простым vfork'ом и тонной воркеров тут проблему не решить.
1 запрос <=> 1 воркер/поток в одном процессе - путь в ад. Просто адовые накладные расходы на создание воркеров/потоков и довольно большой overhead по блокировке и переключению контекстов - обычно люди забывают что и в ОС тоже есть свой шедуллер, и он влияет :).
Много запросов <=> (количество ядер * 2) воркеров/потоков в рамках одного процесса- обычно оно так и делается, желательно в рамках какой-то producer-consumer модели типа disruptor или модели актёров аля akka, erlang, golang, greanlet'ы и т.п. Самопальные disruptor'ы проще контролировать и оптимизировать расходы памяти.
Есть ещё такие вещи как pfRing и netmap, и offheap кэширование - ну вот банальный redis vs terracota это 50 к 1 по скорости обработки fetch'a с хэш-таблицы. Когда микросервисные архитектуры делают через "одноместо", то подобные оптимизации абсолютно бесполезны и часто просто напрочь убивается вертикальное масштабирование... но тут уже речь идёт о трафике формата одноклассников или stackoverflow.
Виктор Ablebeam: я всегда считал в ноде должен быть какой-то встроенный disruptor, или хотя бы подобие планировщика, сам не ковырялся, но если там действительно такого нет - это просто прискорбно. Hail To the Golang.
Виктор Ablebeam: на 17К запросов вэбсерверы типа nginx помирают только если их неправильно готовить, да и на 17К запросах они бывают вовсе ненужны. Ну не зря же сейчас достаточно много проектов на рельсах слезли на golang и уменьшили количество своих серверов в 4-5 раз, а в случае с typesafe stack и Amazon'ом получилось в 8, хотя там это напрочь убило RAD.
Для параноидальных форточников, конечно, такая практика может быть и непривычна, но потом никто не мешает собирать те же dll'ки под линуксом, или макосью без какой-либо существенной разницы.