которые в руби уже кончились

>Их применение крайне примитивное и крайне ограниченное. ну что за пипец?

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

а без него нет жизни

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

+1

Выполнение кода параллелится как раз таки

/stat@combot

combot.org/chat/-1001032697885

Другой вопрос что в нутрях, не но пофиг ли, Konstantin вы же не профессионал в параллельных вычислениях и многопоточности? Или профессионал?

Другой вопрос что в нутрях, не но пофиг ли, Konstantin вы же не профессионал в параллельных вычислениях и многопоточности? Или профессионал?

А что, есть какой-то уровень профессионализма, связанный с мнопоточностью? )) Если вопрос в том, пишу ли я в работе какой-то продакшен код, связанный с параллельностью/конкурентностью, то да, пишу. Нет, мне не пофиг, потому что текущая реализация потоков в MRI не позволяет столь же эффективно их использовать, нежели в том же JRuby, например. Хотя это и лучше, чем ничего. Я не знаю, это стоит вообще обсуждать? Разве это не очевидно или вы хотите доказать обратное?

это не очевидно

ок?

все что дают потоки в руби, это эффективная работа с блокирующими функциями.

какой-то тухлый наброс, понимать как работает интерпретатор никогда не будет лишним

А что, есть какой-то уровень профессионализма, связанный с мнопоточностью? )) Если вопрос в том, пишу ли я в работе какой-то продакшен код, связанный с параллельностью/конкурентностью, то да, пишу. Нет, мне не пофиг, потому что текущая реализация потоков в MRI не позволяет столь же эффективно их использовать, нежели в том же JRuby, например. Хотя это и лучше, чем ничего. Я не знаю, это стоит вообще обсуждать? Разве это не очевидно или вы хотите доказать обратное?

Если вы только занимаетесь параллельными вычислениями, то при всей любви к руби, вы не тот язык выбрали)

какой-то тухлый наброс, понимать как работает интерпретатор никогда не будет лишним

Это понятно

Паралелить только IO - вполне себе хороший подход. В том же NodeJS оно из коробки на каждый чих готово переключиться на другие вычисления чтобы не ждать завершения текущего кода из-за обращения к IO. И при этом всё вполне себе быстро и эффективно. GIL по сути делает тоже самое, только, в отличие от JS, тут ты сам руками всё делаешь, что дает и свои плюсы и минусы.

Есть ещё форк процесса, что увы теряет общий контекст ибо память дублируется и каждая по своему используется, но, в некоторых задачах, почему бы и нет

А так да - хочешь все ядра занять и иметь общую память - храни общее в редисе или чем-то подобном

И много инстансов руби

В целом то приложения обычно на самом то деле не часто и не много имеют общей памяти на поток. С другой стороны конечно сильно зависит от задачи. Но в том же веб обычно это получение запроса от клиента, какие-то вычисления, 1 или более запросов в базу и ответ. И всё это не требует иметь общей памяти за исключением базы данных. Вот туда может по разному ходиться, и транзакциями и просто простенькими запросами, но нет необходимости что-то прям динамически в памяти держать и сложное вычислять, достаточно сложное чтобы нагрузить ядро процессора на все 100%. Ибо если 1 запрос одного юзера не грузит на 100% - можно просто роутить на другие запущенные инстансы на входе, причем не только в рамках одной машины даже - а в рамках многих нод, балансировка нагрузки и прочее такое всё

Если же вычисление требует прям вот всё-всё нагрузить - возможно не тот язык выбран. Впрочем, вероятно, редис поможет в обмене данными между инстансами MRI по ядру на каждый

Тут столько бесед про многопоточность

Неужели это такая прямо проблема?

На самом деле многопоточность - действительно проблемы

Я просто не сталкивался с этим очень остро. Если что,выделял в воркер или микросервис

И вообще, каждой задаче свои инструменты. Многопоточность не самая сильная сторона руби

Неужели это такая прямо проблема?

просто у некоторых фетиш

если язык не занимает все ядра - гештальт не закрыт

Так он в принципе не самый быстрый

Так он в принципе не самый быстрый

Значит, "не нужен" ?

Нет) нужен.

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

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

С++ же

решает все задачи

С++ же

Много веб-проектов на нём видел? И фронт?

решает все задачи

Именно поэтому я написал "нормально"

Кое-как почти все задачи может решить и руби, и пхп, но иногда это тупо не выгодно

Много веб-проектов на нём видел? И фронт?

все веб-проекты на MRI - считай, на С++

не, все веб проекты на MRI а не C++

все веб-проекты на MRI - считай, на С++

Чё??

А почему не Java тогда уж с той же аргументацией? ?

А почему не Java тогда уж с той же аргументацией? ?

а я не помню, на чем оно написано

а я не помню, на чем оно написано

На коболе </sarcasm>

Короче, MRI написан на Си, а не плюсах, как минимум

На коболе </sarcasm>

может на ассемблере

может на ассемблере

Кобол на ассемблере, а ассемблер — на Фортране. Потому Фортран так и ценится. Всё на Фортране работает, весь веб в том числе

Кобол на ассемблере, а ассемблер — на Фортране. Потому Фортран так и ценится. Всё на Фортране работает, весь веб в том числе

Ассемблер на Фортране? Ого, не знал

Кобол на ассемблере, а ассемблер — на Фортране. Потому Фортран так и ценится. Всё на Фортране работает, весь веб в том числе

так вот оно чо

Ассемблер на Фортране? Ого, не знал

Теперь знаешь. Выучишь Фортран — будешь получать сто тыщ баксов

Теперь знаешь. Выучишь Фортран — будешь получать сто тыщ баксов

Сомневаюсь

Теперь знаешь. Выучишь Фортран — будешь получать сто тыщ баксов

так говоришь как будто это много

так говоришь как будто это много

Это вроде цитата из тех времён, когда было много

Кобол на ассемблере, а ассемблер — на Фортране. Потому Фортран так и ценится. Всё на Фортране работает, весь веб в том числе

А это точная информация?

А это точная информация?

Нет ?

Тонковатая шутка получилась

https://bogdanvlviv.github.io/posts/ruby/new-aliases-append-to-push-and-prepend-to-unshift-since-ruby-2_5_0.html?utm_source=rubyweekly&utm_medium=email

ну у него и ник

ну у него и ник

да уж :/

ERROR: S client not available

А что нового обещают завезти?

Добрый день. Кто-нибудь занимался компрессией ассетов, лежащих на s3? Опишу ситуацию. Используем CloudFront. Ассеты улетают в бакет на s3 (юзаем гем asset_sync). В конфиге гема включил опцию, которая должна компрессить ассеты. Проверяю бакет - сейчас там лежат рядом .css и .css.gz файлы. На всякий случай проверил конфиг nginx - там всё ок с точки зрения дружбы с gzip. Но сайт по-прежнему продолжает ссылаться на простой .css файл. Гуглил, грыз матчасть - пока не очень помогло, я явно что-то упускаю. Кто-нибудь сталкивался с подобным?

могу ошибаться, но - сайт и должен ссылаться на простой css js. а gzip версию отправляет уже nginx, и разруливает все по этой версии браузер

могу ошибаться, но - сайт и должен ссылаться на простой css js. а gzip версию отправляет уже nginx, и разруливает все по этой версии браузер

вроде да. надо в DevTools ⇒ Network смотреть

Примерно так и должно работать, судя по гуглу, да - nginx отправляет гзипованную версию, браузер её разжимает и использует. Но пока не понял, как проверить и убедиться, что в этом плане всё ок. Изначально я на этот вопрос внимание обратил, когда смотрел в рекомендации гуглового PageSpeed Insights, после всех изменений он по-прежнему продолжает ругаться, что ассеты не сжаты =/

Примерно так и должно работать, судя по гуглу, да - nginx отправляет гзипованную версию, браузер её разжимает и использует. Но пока не понял, как проверить и убедиться, что в этом плане всё ок. Изначально я на этот вопрос внимание обратил, когда смотрел в рекомендации гуглового PageSpeed Insights, после всех изменений он по-прежнему продолжает ругаться, что ассеты не сжаты =/

написал выше, плюс сюда, например, можно вставить ссылку на ассет: https://checkgzipcompression.com/

Судя по нетворку - приходит полная css-ка, не сжатая. При этом чекер говорит, что всё ок. Хотя судя по всему, он просто проверяет нужный header: With this tool you can check if your web server is sending the correct GZIP enabled header.

Судя по нетворку - приходит полная css-ка, не сжатая. При этом чекер говорит, что всё ок. Хотя судя по всему, он просто проверяет нужный header: With this tool you can check if your web server is sending the correct GZIP enabled header.

в нетворке размер смотришь? там серым и чёрным разные размеры должны отображаться в одной колонке, насколько помню

Размер, урлу - всё смотрю :) Размер отображается один, и это размер оригинала, несжатого

там в хедере в контент encoding gzip должно быть

Есть в хедерах такое :) Content-Encoding: gzip

Вообще, по ощущениям, на стороне AWS и Nginx - всё так, как должно быть. Вопрос именно в том, чтобы рельса понимала, что ей нужно обращаться к .gz файлу

А зачем вообще заморачиваться по этому поводу, если cloudfront?

самое простое — сделать nginx'у gzip off; gzip_static on; и потом curl -H "Accept-Encoding: gzip,deflate" -I https://example.com/asset.css 2>&1 | grep Content-Encoding

но, опять же, непонятно зачем

Ещё disable cache включи

Тогда вроде сможешь увидеть разницу

Добрый день. Кто-нибудь занимался компрессией ассетов, лежащих на s3? Опишу ситуацию. Используем CloudFront. Ассеты улетают в бакет на s3 (юзаем гем asset_sync). В конфиге гема включил опцию, которая должна компрессить ассеты. Проверяю бакет - сейчас там лежат рядом .css и .css.gz файлы. На всякий случай проверил конфиг nginx - там всё ок с точки зрения дружбы с gzip. Но сайт по-прежнему продолжает ссылаться на простой .css файл. Гуглил, грыз матчасть - пока не очень помогло, я явно что-то упускаю. Кто-нибудь сталкивался с подобным?

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

http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/ServingCompressedFiles.html

Спасибо за ссылки/комменты Сейчас разбираюсь, как это всё работает, есть пробелы в матчасти, восстанавливаю

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

это если ты их не проксируешь.

это если ты их не проксируешь.

надо у вопрошающего спросить, одинаковы ли root URL для ассетов и для приложения

Не одинаковы

Не одинаковы

Тогда это явно не про проксирующий nginx

ребятки, подскажите как быстро изменить регистр имен множества файлов? CamelCase -> kebab-case

ребятки, подскажите как быстро изменить регистр имен множества файлов? CamelCase -> kebab-case

pry в помощь :)

pry в помощь :)

и как он поможет?

FileUtils#mv и String#dasherize, очевидно