ТыжСисАдмин

Лучше всего просто поставить два диска SSD и HDD.
На SSD система, файл подкачки, и все файлы с которыми вы активно работаете.
На HDD - хранилище файлов, т.е те файлы которые вы больше храните чем работаете с ними.
Это самый быстрый и оптимальный вариант.

Можно конечно устроить совместную работу используя SSD в качестве кэша, но это будет не так быстро.
Сейчас это не очень актуально. Раньше когда SSD были очень маленькими такая схема использовалась как компромисс между ценой и производительностью.

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

Вопрос исключительно общий. Начните с изучения самых основ, со способов представления информации и с систем счисления.

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

В широком смысле любой файл бинарный, так как записан на носителе с помощью всего двух возможных символов. В более узком смысле бинарные файлы — это противопоставление текстовым файлам. Но в любом случае выбор остаётся очень большим: исполняемые файлы приложений, музыка, видео, изображения, архивы, многие документы, базы данных и др.

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

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

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

Разные версии руби? В ruby 2 оптимизировали float

# Ruby 1.9
4.2.object_id == 4.2.object_id # => false

# Ruby 2.0
warn "Optimization only on 64 bit systems" unless 42.size * 8 == 64
4.2.object_id == 4.2.object_id # => true (4.2 is immediate)
4.2e100.object_id == 4.2e100.object_id # => false (4.2e100 isn't)

без разницы, они все справляются с тестированием.
ну и Ruby on Rails - вообще не язык.

Гуглится же все на 5 секунд.

5 вольтовый USART там, к ардуйне прицепится без проблем. Параметры передачи стандартные - 9600, 8 бит, без бита четности. Протокол бинарный, но в бложике все разобрано.

Если вам надо, чтобы за вас написали такой функционал это вам сюда freelance.ru или сюда fl.ru, можно сюда upwork.com или сюда freelancer.com

Если у вас сложились какие то проблемы то сформулируйте вопрос. Где проблемы, вам подскажут какой код надо выкладывать и где ошибки.
Если вы не можете сформулировать как надо сделать обмен сообщениями, сформулируйте вопрос "Как сделать обмен сообщениями как на фб" и вам предложат вариант аля вебсокет плюс аякс или фреймы. А писать за вас код и разбираться что вам нужно никто не будет).

P.S такие решения не гуглить надо, а разбираться как их писать.

Ибо все скатывается к гуглению,

Рекомендую ознакомиться: skillkit.ru/post-258-top-5-oshibok-nachinayuschih-...

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

UPDATE:

list = {'first' => 'BMW', 'second' => 'BMW', 'third' = 'MERCEDES'; }
А нужно мне:
list = {'first' => 'BMW', 'third' = 'MERCEDES'; }

Если пофиг какой ключ будет выбран, то

list.invert.invert => {"second"=>"BMW", "third"=>"MERCEDES"}

Если не пофиг, то

Hash[list.to_a.uniq{ |v| v.last}] => {"first"=>"BMW", "third"=>"MERCEDES"}

list['first'] = 'BMW';
list['second'] = 'BMW';
list['third'] = 'MERCEDES';

Как сортировать этот хэш по уникальности???

Хэш - это ассоциативный массив. У него нет сортировки.
Я правильно понял, что вам нужно выбрать только те пары ключ, значение, у которых значение уникально во всем хэше? Если да, то так:

h = { a: 'bmw', b: 'bmw', c: 'lada kalina' }
count = h.values.group_by(&:to_s)
h.select{ |_, v| count[v].size == 1 }  => {:c=>"lada kalina"}

Сортировать тоже можно, но получится массив:

h.sort_by{ |_, v| count[v].size } =>  [[:c, "lada kalina"], [:b, "bmw"], [:a, "bmw"]]

не вращайте вокруг них эту отвертку со скоростью выше 1500 оборотов секунду и проблем не будет.

Нужно использовать тег noindex в моем случае?

Нет.

Скажите, имеет ли смысл обернуть блок в тег noindex, чтоб он не индексировался?

Смысла не имеет.

Будет результат, как вы думааете?

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

obj.model_name.human

И локализацию положить в ru.activerecord.models

Отлаживать код умеете?
Сделать ap на original_filename. Если все-равно не понятна суть бага, то binding.pry и в дебагере поиграть с переменной.

С точки зрения оптимизационных моментов стоит завести отдельное поле file_name. У меня в одном из проектов работает это так:

def filename
    model.file_name = Russian.translit(original_filename) || model.file_name
end