ABOMETP запуск диагностики пробовал, оно говорит, что всё в порядке. Для Target Display Mode у меня к сожалению нет thunderbolt кабеля, но я уже гуглил по этому поводу раньше, и везде в интернетах пишут, что 27" imac 2017 не поддерживает Target Display Mode
ABOMETP видео карта интегрированная. Серийник DGKVLJ9SJ1GQ. Принтер есть, но он выключен и не включался несколько месяцев. Есть беспроводные апловская клавиатура, трекпад, мышь, airpods pro (купил буквально за дни до того, как падения начались, даже думал, что в них причина может быть, но их отключение/полный вынос из квартиры ничего не поменял).
Вчера долго не было падений, сейчас включил посмотреть серийник, через минуту чёрный экран смерти.
Пробовал вообще отключать блютус/wifi. Никакой разницы. Но по-моему компьютер продолжает bluetooth использовать даже при выключении в настройках - беспроводная мышь и трекпад продолжают работают (не полностью, жесты не работает при выключенном bluetooth)
еще в копилку. сегодня примерно 6 часов проработал imac без сбоев (сначала с час гонял все cpu на 100% загрузке, потом включил видео с ютуба). стоило компьютеру перейти в режим сна, тут же (или сразу, или в течение пары минут - не уверен) выскочил чёрный экран смерти
ABOMETP памяти у меня две планки. пробовал вставлять по одной, вставлять в разные слоты. это ничего не меняло, всё равно ребуты в произвольные моменты происходили
> стресс-тест запустить yes > /dev/null &
нагрузил 8 ядер на 100%, вентилятор крутится, шумит, ребута не происходит. произойдёт вскоре через некоторе время по любому, но корреляции с нагрузкой cpu не вижу
на прошлой неделе я включил ютуб в сафари на свежей переустановленной osx для теста, и отработало больше 8 часов без падения. а пару дней назад умерло через пару минут после запуска видео. не вижу никаких закономерностей. умирает в случайны моменты
Заур Ашурбеков при сдвиге помимо изменения позиции самого элемента, он делает лишь один запрос, пример которого я написал выше. как именно он отработает на ваших данных, лучше смотреть на продакшен базе через explain analyze. в большинстве случаев сервер не заметит этого, если у вас не слишком большая таблица
плюс скорее всего вам сортировка нужна в контексте какого-то поля, чтобы сортировать десятки, максимум сотни элементов, в запрос в таком случае добавится where условие по этому полю, и обновляться индекс будет для совсем малого числа элементов. ручная же сортировка по position по всей таблице для десятков тысяч и более элементов в большинстве случаев бессмысленна и скорее всего означает неправильные требования к задаче
Diesel-nick: не особый синтаксис. Как правило чтобы выполнить тест, вы сначала создаёте какие-то объекты через before блок или через let
let(:site) { create :site }
соответственно, когда создаваемые объекты пишутся в базу, то работает это гораздо медленнее.
представьте, у вас для создания нужный условий к тесту создаётся десяток объектов.
а потом вы пишите тесты
it { ... }
it { ... }
it { ... }
it { ... }
it { ... }
на каждый it блок будет создаваться по десятку объекту. 10 * 5 = 50 штук. соответственно, если пять it заменить на один, то объектов создатся в пять раз меньше. один it в такой ситуации отработает гораздо быстрее, чем пять.
когда у вас наберётся несколько тысяч подобных тестов, то разница между один "it - один expect" и "один it - много expect" станет очень заметной. сильно зависит от тестов, но скорее всего "один it - много expect" будут выполняться в 2-4 раза быстрее
одна-две минуту на все спеки, или 4-5 минут - разница очень существенна
Diesel-nick: один expect в одном it/scenario лично мне кажутся гораздо эстетичнее и читабельнее. стараюсь использовать такой синтаксис в случаях, когда в тестах не делается запросов к базе/к серверу(как в feature спеках).
в остальных случаях группирую expect'ы в одном it/scenario. причина - при большом числе спеков группировка в разы ускоряет скорость прохождения тестов.
Александр Королев: увы, только теоретические размышления, т.к. делать не приходилось, лишь думал над этим.
В рельсах уже есть встроенный функционал - Rails::Engine edgeguides.rubyonrails.org/engines.html . В engine можно поместить полную структуру приложения: /app, /config, /db (модели, миграции, вьюшки, ассеты).
Соответственно выносим весь общий код в engine, кладём его в отдельный репозиторий подключаем в Gemfile для development и test через path (gem 'my_engine', path: '/path-to-repository') (чтобы не приходилось делать bundle update на каждое изменени в движке), а для production и staging подключаем как обычно.
Engine в роутах маунтим в корень проекта (mount MyEngine, at: '/') и затем переопределяем в каталоге проекта нужные нам /app/views, /app/controllers
В теории должен получиться движок, которой легко подключается, функционал которого можно переопределять своим кодом. Как будет на практике - не знаю, попробовать это мне так и не довелось. Наверняка выскочат какие-то подводные камни, о которые придётся хорошенько поспотыкаться.
> а как во втором случае оперировать .limit(15)?
не понял вопроса. отобразить ведь нужно 15 постов за вычетом постов, не подходящих по каким-то критериям?
соответственно выбираем 15 постов и их фильтруем
posts = Post.where(критерии_выборки).limit(15).select { |post| условия_фильтрации }
возможно, вас смущает метод select, т.к. select из Enumerable и select из ActiveRecord имеют одинаковое название? написанный мной select - это не select активрекорда, это фильтрация массива.
можно ещё вот так написать, код будет эквивалентен
posts = Post.where(критерии_выборки).limit(15).to_a
posts = posts.select { |post| условия_фильтрации }
> Поторопился чуток) сейчас попробую переделать, логика не та не много, .limit(15) нужен не фиксированный. То есть если в выбранных 15 есть 1 с post_block_id 2 то надо выводить на 1 меньше. А в данному случае если Post_block_id 2 то он его просто фильтрует, тоже самое с quote. А надо просто что бы к примеру есть в эти 15, 3 с Post_block_id 2 и 2 c quote не nil, то выводим не 15 а 10
тут как раз второй вариант подходит с фильтрацией в коде. сначала выбираем 15 постов, затем их фильтруем в руби. два варианта я написал, чтобы показать, как вообще можно делать.
> Единственно вот так выдавало ошибку
да, post_asset надо заменить на post_assets в where. там пишется не имя ассоциации, а имя таблицы
.where.not(id: Post.joins(:post_asset).where.not(post_assets: { quote: nil }))
> И если можно еще вопрос, что все таки лучше фильтровать сразу или после в коде?
> Как лучше по производительности чтоли? Мне кажется выгоднее последнее?
всё зависит от объёма данных. когда нужно всего 15 записей, и затем от них отрезать лишнее, то в руби отфильтровать и проще, и код понятнее. если бы, например, нужно было отфильтровать тысячи записей, и только затем выбрать 15, то это нужно было бы делать в базе.
@yucom ответил же на ваш вопрос в посте выше первым абзацем.
nodejs не лучше и не хуже, он другой, он работает как _асинхронный_неблокирующий_сервер_, и с рельсами сравнивать его некорректно.
асинхронность означает, что писать логику придётся на колбеках, на каждое блокирующее действие, задавая колбек на результат выполнения операции. это гораздо труднее, как написание самого кода, так и написание тестов к нему. преимуществом же будет возможность сервера держать на порядки больше открытых конекшенов.
так же v8 сам по себе быстрее руби, на сколько сказать затрудняюсь, на вскидку в 1.5-3 раза.
а недостатком, очень большим недостатком, будет отсутствие привычной экосистемы руби и скудный набор библиотек.
если вы хорошо знакомы с руби и рельсами и вам нужен именно асинхронный вебсервер, то выбирайте лучше eventmachine или производные от него более высокоуровневые сервера (goliath, celluloid), получите ту же асинхронность, но с кучей плюшек, сопуствующих языку ruby.
а если вам просто нужно поднять обычное апи, то асинхронность тут нафик не сдалась, рельсы будут лучшим выбором, на крайний случай можно взять синатру, либо её аналоги.
Написано
Войдите на сайт
Чтобы задать вопрос и получить на него квалифицированный ответ.
