Тут просто сделать make install быстрее. Он заменит сам nginx точно таким же + скопирует сам модули. Быстрее и проще. Если не хотите, чтобы ваш nginx менялся на только что скомпилированный — можете вручную копировать модули, само собой.
Это гораздо проще, т.к. не надо прописывать вручную пути, где будет лежать nginx, его конфиг и т.д.
Т.е. поставил nginx из репы, добавил модули и все. При этом по факту, версия остается та же, только добавляются модули.
Ну и конечно, по большей части эта инструкция для тех, у кого уже установлен nginx и надо добавить пару модулей, ничего не сломав.
До появления динамических модулей у меня бывали ситуации:
«ооо, какую крутая штука. Ммм, да она еще и это умеет, надо попробовать ее на своем sandbox-сервере. Черт! Там же nginx надо пересобирать для этого. Нее, тогда не охота.»
В том году было несколько интересных докладов на фронте и серверсайде. Было интересно послушать Александра Макарова, доклад про смену языка и еще несколько других…
В этом году что-то не нашел для себя интересных тем докладчиков.
Ну вот авторы решили записать это в минус, но по мне — это не плюс и не минус. Это особенность. На каких-то изображениях это выглядит лучше, на каких-то наоборот. Но в целом, лично мне больше нравится, когда границы объектов четко выделены, а не страдают от артефактов сжатия того же JPG.
Как-то выглядит странно их затея. Делать по сути новый фреймворк без обратной совместимости и это тогда, когда есть Symfony, Yii2, Laravel5.
Думаю, кто был на CI3 — либо его и используют, либо перешли на вышеобозначенные фреймворки. 4 версии никому не нужна. ИМХО.
По четвертому пункту, думаю, не совсем все так.
Есть прекрасный пример того, как русские парни маленькой командой создали интересную инди-игру и вполне себе прошли краудфандинг и GreenLight.
Я говорю про 12 is better than 6:
https://boomstarter.ru/projects/291276/12_is_better_than_6
https://www.kickstarter.com/projects/1926605606/12-is-better-than-6
https://steamcommunity.com/sharedfiles/filedetails/?l=russian&id=387892777
Есть даже отдельная статья (https://addyosmani.com/blog/backing-up-a-github-account/) о разном импорте с GitHub.
Там есть ссылка на проект (https://github.com/joeyh/github-backup), который позволяет сдампить всё, что у вас есть на гитхабе, включая репозитории, ветки, форки, pull-реквесты и остальное.
Есть, конечно, https://backhub.co, который вообще все оптимизирует и делает за вас по нажатию одной кнопки. Главный минус — файлы хранятся на их сервере в Германии, соответственно, это опять облако с неизвестной доступностью. Но что самое настораживающее — ваш код будет сохранен 3 лицом где-то на его стороне.
Как по мне, можно ведь просто использовать GitLab или аналоги на вашем сервере или на какой-нибудь виртуалке и создавать автоматический дамп сервера или каталога репозиториев по расписанию. Я бы предпочел такой способ, чем постоянно тягать данные через гит и отправлять их на другой сервер.
П.С. извиняюсь на текстовые ссылки, карма не дает вставить html.
Первый тест — вычислительная задача, чтобы количественно сравнить php/ruby/js+node.
Практического смысла, понятное дело, не имеет. Это показатель того, как языки (и нода) справляются с вычислениями.
Второй тест — более приближенный к жизни, хоть и показывающий простой и банальный use-case приложения.
В случае с SailsJS использовал генератор проекта от самого Sails. Он и создал такой файл, его я не менял.
И вообще, если в фреймворке есть средства генерации кода — я его использовал. Это касается всех приведенных в статье фреймворков.
Кэширование тоже бывает разным. Но интереса ради включу везде кэширование и проведу отдельный тест.
По поводу замера размера памяти — я, конечно же, понимаю, что так сравнивать не совсем корректно, но руби и нода стартуют сервером, в то время как встроенный сервер php — совсем не производительное решение.
Как вариант, конечно, перевести всё на один веб-сервер + подключить обработчики для языков. Хотя нода в любом случае будет запускать свой сервер, к которому нужно будет делать upstream.
Да, немного ошибся. После обновления до 5 версии ноды стали такие результаты. Жирность не поменял. Спасибо за замечание.
Можете в коммитах посмотреть, какие показатели были на 0.12.7 версии ноды.
Думаю, всем понятно, что я сравнивал инструменты в рамках веб-разработки. Соответственно, нода здесь — серверный «язык». Хотя с вами соглашусь, выразился не совсем корректно.
Пользуюсь feedly + gReader. Отличная связка для чтения новостей как на пк, так и на Android.
Собственно, скорее из-за gReader остался на feedly. Хотя он и сам по себе (веб-версия) весьма хорош.
30-40 программ в одном обзоре — это будет перебор, по-любому нужно будет поделить. + я сделаю сводные таблички к каждому обзору + одну общую, со всеми программами.
Т.е. поставил nginx из репы, добавил модули и все. При этом по факту, версия остается та же, только добавляются модули.
Ну и конечно, по большей части эта инструкция для тех, у кого уже установлен nginx и надо добавить пару модулей, ничего не сломав.
«ооо, какую крутая штука. Ммм, да она еще и это умеет, надо попробовать ее на своем sandbox-сервере. Черт! Там же nginx надо пересобирать для этого. Нее, тогда не охота.»
В этом году что-то не нашел для себя интересных тем докладчиков.
Думаю, кто был на CI3 — либо его и используют, либо перешли на вышеобозначенные фреймворки. 4 версии никому не нужна. ИМХО.
Есть прекрасный пример того, как русские парни маленькой командой создали интересную инди-игру и вполне себе прошли краудфандинг и GreenLight.
Я говорю про 12 is better than 6:
https://boomstarter.ru/projects/291276/12_is_better_than_6
https://www.kickstarter.com/projects/1926605606/12-is-better-than-6
https://steamcommunity.com/sharedfiles/filedetails/?l=russian&id=387892777
Там есть ссылка на проект (https://github.com/joeyh/github-backup), который позволяет сдампить всё, что у вас есть на гитхабе, включая репозитории, ветки, форки, pull-реквесты и остальное.
Есть, конечно, https://backhub.co, который вообще все оптимизирует и делает за вас по нажатию одной кнопки. Главный минус — файлы хранятся на их сервере в Германии, соответственно, это опять облако с неизвестной доступностью. Но что самое настораживающее — ваш код будет сохранен 3 лицом где-то на его стороне.
Как по мне, можно ведь просто использовать GitLab или аналоги на вашем сервере или на какой-нибудь виртуалке и создавать автоматический дамп сервера или каталога репозиториев по расписанию. Я бы предпочел такой способ, чем постоянно тягать данные через гит и отправлять их на другой сервер.
П.С. извиняюсь на текстовые ссылки, карма не дает вставить html.
Практического смысла, понятное дело, не имеет. Это показатель того, как языки (и нода) справляются с вычислениями.
Второй тест — более приближенный к жизни, хоть и показывающий простой и банальный use-case приложения.
И вообще, если в фреймворке есть средства генерации кода — я его использовал. Это касается всех приведенных в статье фреймворков.
По поводу замера размера памяти — я, конечно же, понимаю, что так сравнивать не совсем корректно, но руби и нода стартуют сервером, в то время как встроенный сервер php — совсем не производительное решение.
Как вариант, конечно, перевести всё на один веб-сервер + подключить обработчики для языков. Хотя нода в любом случае будет запускать свой сервер, к которому нужно будет делать upstream.
Можете в коммитах посмотреть, какие показатели были на 0.12.7 версии ноды.
Собственно, скорее из-за gReader остался на feedly. Хотя он и сам по себе (веб-версия) весьма хорош.