Петр

Интерфейсы определяют "Общедоступные" свойства и методы и не имеют смысла от модификатора доступа типа protected или privat

Можете сделать что-то вроде:

interface IModuleMenuItem {
     getName(): string;
}

class ModuleMenuItem implements IModuleMenuItem {
    private name;

    public getName() {
        return name;    
    }

    protected setName(newName : string) {
        name = newName;
    }
}

Взято отсюда

www.daterangepicker.com
longbill.github.io/jquery-date-range-picker
demos.krajee.com/date-range

Ну и классика

Немного не понятно это:

DataPicker - НЕ подходит

По сути Вы говорите "помогите выбрать автомобиль, но автомобиль не предлагать". DataPicker - это не имя собственное, это тип плагинов их множество, в том числе есть тип dateRangePicker - это как раз выбор диапазона дат.

try_files $uri $uri/ @php;
nginx.org/ru/docs/http/ngx_http_core_module.html#t...

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

Правильно ли я понимаю что для хранение файлов их нужно разбивать по папкам,

Неправильно.
Для того, чтобы файлы загружались и благополучно отдавались, сегментировать (разбивать по папкам) их совсем не обязательно.

Проблемы, про которые Вы могли слышать, связаны лишь с получением полного списка файлов в директории. Да, это долго и тормознуто, но никак не влияет на скорость чтения конкретного файла.

А на боевых серверах использование хранилища в локальной файловой системе и вовсе нонсенс. Там эта проблема не стоит в принципе.

Сегментацию можно сделать для, скажем так, красоты. Или чтобы было понятно, кому принадлежит тот или иной файл. Но практическая польза от неё сомнительна. Вреда, впрочем, тоже нет :)

допустим на сервер пользователь с Ником username заливает файл file.mp4, и я сохраняю этот файл по пути u/us/use/user/usern/file.mp4 и такой путь формируется для каждого пользователя

Опять неправильно.

Во-первых, никогда, НИКОГДА не доверяйте данным, пришедшим от пользователя. Сохраняете загруженный файл – сгенерируйте имя сами. А оригинальное имя не возбраняется сохранить и в другом месте. Если понадобится дать возможность пользователю сохранить файл под оригинальным именем, это делается в несколько строк.

Во-вторых, Ваша сегментация слишком агрессивная. Если представить, что юзернейм может состоять только из строчных латинских букв и цифр (итого алфавит 26+10=36 символов), то такое хранилище сможет вместить 36 ^ (1 + 2 + 3 + 4 + 5) = 36^15 = 2.21 * 10^23 файлов без повторений. А что если юзернейм короче 5 символов? А что если он переименуется?

Помните "во-первых"? Так как нам нужно самим придумать имя файла, почему бы не воспользоваться либо UUID и сгенерировать уникальное (с высокой достоверностью) значение вида 28c5a6d8-f7b5-440f-aeaa-150e4fd0bebc, а его уже сегментировать? Например, два сегмента по два символа датут прикольные ссылки вида 28/c5/28c5a6d8-f7b5-440f-aeaa-150e4fd0bebc и возможность разместить 65 тысяч файлов так, чтобы они были по одной штуке в директории :)

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

если будет 2 одинаковых названия файла у одного пользователя то просто добавляю к новому файлу номер (file1.mp4)

Если речь идёт о Джанге, то она сама так делает, это штатная функция хранилища.

Блог нужен человеку, которому есть что сказать и чем поделиться.
Судя вопросу, вам пока не нужен.

это потому, что комментирующие не знают предмета

да, Питон интерпретируемый, и он медленнее компилируемого Го, и тем более С++

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

в программировании есть два потока:
1) борьба со сложностью задачи
2) борьба со сложностью языка

и то и то с Питоном куда легче чем с любым другим языком

конечно, там где HighEnd - там только Си ( Го очень хорошо идет для веба), ну так "там" и curl с nginx ом, бывает, пересобирают

Ардуино подключается по USB и в системе оно видно как COM-порт. Соответственно, самый логичный способ связи между программой и железкой - COM

Придумайте себе интересный проект. Таким способом, по мере реализации вы столкнетесь с проблемами, какие успешно решите с помощью гугла, хабра, тотстера, или stack overflow, и это поможет вам набить руку

Приснилось.

Можно сделать только так, но это, по понятным причинам, не очень практично:

<div>1</div>
<div style="border:1px solid navy;float:left;background:green;">2</div>

div[style*="float:left"] {
  color: red;
}