Как узнать — понятно. А как задавать это количество? Другими словами, количество реплик — это единая характеристика всего кластера или для каждого VDI можно указать своё значение?
Чтобы говорить по-английски, не спотыкаясь, мне кажется, надо в первую очередь понимать ключевое отличие английского языка от русского. А оно следующее.
В русском языке при построении предложения изменяются все его члены, т.е., чтобы правильно составить предложение на русском языке, нам необходимо подобрать правильные варианты всех слов в предложении.
В отличие от русского языка, в английском языке в предложении изменяется только глагол. Думать об остальных частях речи для построения предложения в английском языке фактически не требуется.
Другими словами, в согласовании слов в предложении в русском языке участвуют все члены предложения, неся смысловую нагрузку в равной степени, а в английском языке основную смысловую нагрузку (для согласования слов в предложении) несёт глагол.
Именно поэтому глаголы в английском языке, скажем так, более «продвинутые». Английские глаголы имеют дополнительную характеристику (отсутствующую у русских глаголов) по которой они могут изменяться.
Повторюсь ещё раз, эта характеристика нужна английским глаголам именно в силу того, что они единственные, кто несёт смысловую нагрузку для согласования слов в английском предложении.
Эта характеристика называется — характер действия.
Характер действия это не какой-то аспект времени, это — самая настоящая характеристика глагола в английском языке, по которой он может изменяться для согласования слов в английском предложении.
Именно в силу того, что у русских глаголов эта характеристика отсутствует, нам сложно представить что это такое, и в ближайшем приближении мы пытаемся трактовать это как какой-то аспект времени, т.е. в смысле построения русского предложения.
Так вот, чтобы говорить по-английски, не спотыкаясь, надо перестать мыслить категориями русского предложения, а начать мыслить так, как это делают носители языка.
При построении русского предложения эта дополнительная характеристика нам совершенно не нужна. Но при построении английского предложения мы должны обязательно определить характер действия глагола точно также как и другие его характеристики (например, время, залог, которые у русских глаголов есть). Просто надо помнить, что без характера действия нельзя правильно построить ни одно английское предложение.
2. Адаптивный вывод карточек.
Например, пользователь будет просматривать приложение на планшете да ещё в альбомном режиме. Как будут отображаться карточки с информацией в данном случае? Они растянутся на весь экран. Можно организовать вывод количества карточек в строке в зависимости от ширины экрана. Пример:
3. Перенести загрузку и работу с данными в выделенный сервис/сервисы, вместо того, чтобы работать с данными напрямую в компонентах. Например, сервис Репозиторий — для работы с данными (сортировка, фильтрация и т.п.) и сервис Источник данных — для загрузки данных. Компоненты запрашивают данные и их необходимую обработку у сервиса Репозитория, который в свою очередь получает данные из источника. Источники данных можно в дальнейшем, при необходимости, менять. При этом при смене источника данных как-то менять классы компонентов и класс сервиса Репозитория не потребуется. Потребуется всего лишь в модуле сервиса Репозитория сменить класс сервиса Источника данных. Т.е. будет что-то в таком виде:
Тут оба класса dataSource и prodDataSource должны определять одинаковые методы. При этом класс dataSource определяет просто интерфейс, т.е. набор пустых методов или методов, возвращающие пустой массив данных. В свою очередь каждый класс сервиса реального источника данных (например, prodDataSource) эти методы по-своему реализует.
4. Добавить классы-модели данных.
Отличная статья, спасибо!
Есть вопрос. Может быть поможете, подскажите, что делать. В Гугле ответа так и не нашёл.
Стоял Debian Jessie, в котором lvm version:
Так вот, проблема следующая:
Используется thin-пул (vg), в котором thin-разделы (lv). Снапшотов thin-разделов нет (не делались), т.е.
lvs
(и на Jessie, и на Stretch) показывает, что снапшотов нет. В тоже время на Jessie команда
lvs -o+data_percent,snap_percent
честно показывает, что snap_percent у thin-раздела отсутствует (снапшоты же не делались), а вот у Stretch ситуация становится интересной, команда
lvs -o+data_percent,snap_percent
показывает размер snap_percent у thin-раздела равный data_percent.
В итоге на Stretch получается, что если thin-разделы в общей массе занимают, например, 50% thin-пула, то создать еще один thin-раздел не представляется возможным, т.к. обновлённая lvm при определении свободного места в thin-пуле учитывает эти откуда-то взятые snap_percent, т.е. тупо увеличивает занятое место ровно в 2 раза.
Для не thin-разделов всё нормально, т.е. этих непонятных снапшотов нет.
Вопрос, можно ли безболезненно откатится на предыдущую версию lvm, учитывая, что система тоже установлена в lvm-раздел (другая vg, не thin) и если да, то как?
Да, согласен, написал не в тему, поспешил (людей насмешил).
Не разглядел mobx, т.к. с mobx не пересекался. Подумал, что в свойстве e.type хранится тип самого объекта e, т.е. update и splice — суть возможные типы объекта e. Соответственно, конструкции: (e as update). и (e as splice). помогут webstorm знать в точках (1) и (2) списки доступных свойств.
Можно для более строгой типизации ещё немного доработать:
mobx.observe(foo, e => {
if (e.type == "update") {
(e as update). // 1
// Либо
(<update>e). // 1
}
if (e.type == "splice") {
(e as splice). // 2
// Либо
(<splice>e). // 2
}
});
Понятно, что для JSX подходит только первый вариант, т.е. as-синтаксис.
Есть ли на Qt проработанная, законченная, известная архитектурная модель построения приложения под Android (и, возможно, iOS), при которой возможно было бы запускать приложение одновременно как с пользовательским интерфейсом (Активити), так без него (Сервис)?
Или, другими словами, чтобы одна часть приложения загружалась с пользовательским интерфейсом, которую можно будет, например, позже закрыть (или эта часть будет позже «прибита» системой), а другая часть приложения параллельно загружалась бы как сервис?
Понятно, что можно сделать приложение отдельно с пользовательским интерфейсом, а отдельно — как сервис. Т.е. два отдельных приложения. А, вот, чтобы это всё в одном приложении жило, есть ли какие методики под Android на Qt (и, возможно, iOS)?
Может, знаете какие-нибудь ссылки на открытые проекты с похожей архитектурой, или на описание её в блогах гуру Qt?
А про новый (российский) сервис Nabi (justnabi.ru) кто-нибудь слышал, пользовался? В Москве таксисты во всю про него рассказывают, а вот клиентов пока маловато — единицы. Рекламы нет. Раскручиваются на народной молве.
Почему до сих пор нет комментария о том, какое отношение expect имеет к bash, нет упоминания про POSIX, и никто по-доброму настоятельно не советует читать его ранее написанные единственно правильные комментарии?
Другими словами, почему до сих пор никто не приступил к спасению новичков и начинающих? Ребята, отметившиеся в комментариях разумной критикой, вам же потом придётся за ними уязвимости убирать! Пора, пора начинать критиковать и минусовать.
Есть такая логическая ошибка, называется «Мнимая логическая связь». Это когда ЖЕЛАЕМАЯ логическая связь выдаётся за истинную. Например, на КОРОТКИЙ вопрос должен быть только КОРОТКИЙ ответ. ;)
А как указать количество хранимых копий VDI?
А сами сколько трудитесь? Какая нагрузка?
Посмотрите на их сайте: https://support.plex.tv/articles/201373803-nas-compatibility-list/
В русском языке при построении предложения изменяются все его члены, т.е., чтобы правильно составить предложение на русском языке, нам необходимо подобрать правильные варианты всех слов в предложении.
В отличие от русского языка, в английском языке в предложении изменяется только глагол. Думать об остальных частях речи для построения предложения в английском языке фактически не требуется.
Другими словами, в согласовании слов в предложении в русском языке участвуют все члены предложения, неся смысловую нагрузку в равной степени, а в английском языке основную смысловую нагрузку (для согласования слов в предложении) несёт глагол.
Именно поэтому глаголы в английском языке, скажем так, более «продвинутые». Английские глаголы имеют дополнительную характеристику (отсутствующую у русских глаголов) по которой они могут изменяться.
Повторюсь ещё раз, эта характеристика нужна английским глаголам именно в силу того, что они единственные, кто несёт смысловую нагрузку для согласования слов в английском предложении.
Эта характеристика называется — характер действия.
Характер действия это не какой-то аспект времени, это — самая настоящая характеристика глагола в английском языке, по которой он может изменяться для согласования слов в английском предложении.
Именно в силу того, что у русских глаголов эта характеристика отсутствует, нам сложно представить что это такое, и в ближайшем приближении мы пытаемся трактовать это как какой-то аспект времени, т.е. в смысле построения русского предложения.
Так вот, чтобы говорить по-английски, не спотыкаясь, надо перестать мыслить категориями русского предложения, а начать мыслить так, как это делают носители языка.
При построении русского предложения эта дополнительная характеристика нам совершенно не нужна. Но при построении английского предложения мы должны обязательно определить характер действия глагола точно также как и другие его характеристики (например, время, залог, которые у русских глаголов есть). Просто надо помнить, что без характера действия нельзя правильно построить ни одно английское предложение.
1. Ленивая загрузка компонентов (как выше уже написали). Примеры:
2. Адаптивный вывод карточек.
Например, пользователь будет просматривать приложение на планшете да ещё в альбомном режиме. Как будут отображаться карточки с информацией в данном случае? Они растянутся на весь экран. Можно организовать вывод количества карточек в строке в зависимости от ширины экрана. Пример:
3. Перенести загрузку и работу с данными в выделенный сервис/сервисы, вместо того, чтобы работать с данными напрямую в компонентах. Например, сервис Репозиторий — для работы с данными (сортировка, фильтрация и т.п.) и сервис Источник данных — для загрузки данных. Компоненты запрашивают данные и их необходимую обработку у сервиса Репозитория, который в свою очередь получает данные из источника. Источники данных можно в дальнейшем, при необходимости, менять. При этом при смене источника данных как-то менять классы компонентов и класс сервиса Репозитория не потребуется. Потребуется всего лишь в модуле сервиса Репозитория сменить класс сервиса Источника данных. Т.е. будет что-то в таком виде:
Тут оба класса dataSource и prodDataSource должны определять одинаковые методы. При этом класс dataSource определяет просто интерфейс, т.е. набор пустых методов или методов, возвращающие пустой массив данных. В свою очередь каждый класс сервиса реального источника данных (например, prodDataSource) эти методы по-своему реализует.
4. Добавить классы-модели данных.
Есть вопрос. Может быть поможете, подскажите, что делать. В Гугле ответа так и не нашёл.
Стоял Debian Jessie, в котором lvm version:
Обновился до Stretch. Соответственно, lvm version:
Так вот, проблема следующая:
Используется thin-пул (vg), в котором thin-разделы (lv). Снапшотов thin-разделов нет (не делались), т.е. (и на Jessie, и на Stretch) показывает, что снапшотов нет. В тоже время на Jessie команда честно показывает, что snap_percent у thin-раздела отсутствует (снапшоты же не делались), а вот у Stretch ситуация становится интересной, команда показывает размер snap_percent у thin-раздела равный data_percent.
В итоге на Stretch получается, что если thin-разделы в общей массе занимают, например, 50% thin-пула, то создать еще один thin-раздел не представляется возможным, т.к. обновлённая lvm при определении свободного места в thin-пуле учитывает эти откуда-то взятые snap_percent, т.е. тупо увеличивает занятое место ровно в 2 раза.
Для не thin-разделов всё нормально, т.е. этих непонятных снапшотов нет.
Вопрос, можно ли безболезненно откатится на предыдущую версию lvm, учитывая, что система тоже установлена в lvm-раздел (другая vg, не thin) и если да, то как?
Не разглядел mobx, т.к. с mobx не пересекался. Подумал, что в свойстве e.type хранится тип самого объекта e, т.е. update и splice — суть возможные типы объекта e. Соответственно, конструкции: (e as update). и (e as splice). помогут webstorm знать в точках (1) и (2) списки доступных свойств.
Понятно, что для JSX подходит только первый вариант, т.е. as-синтаксис.
Такой вопрос.
Есть ли на Qt проработанная, законченная, известная архитектурная модель построения приложения под Android (и, возможно, iOS), при которой возможно было бы запускать приложение одновременно как с пользовательским интерфейсом (Активити), так без него (Сервис)?
Или, другими словами, чтобы одна часть приложения загружалась с пользовательским интерфейсом, которую можно будет, например, позже закрыть (или эта часть будет позже «прибита» системой), а другая часть приложения параллельно загружалась бы как сервис?
Понятно, что можно сделать приложение отдельно с пользовательским интерфейсом, а отдельно — как сервис. Т.е. два отдельных приложения. А, вот, чтобы это всё в одном приложении жило, есть ли какие методики под Android на Qt (и, возможно, iOS)?
Может, знаете какие-нибудь ссылки на открытые проекты с похожей архитектурой, или на описание её в блогах гуру Qt?
А про новый (российский) сервис Nabi (justnabi.ru) кто-нибудь слышал, пользовался? В Москве таксисты во всю про него рассказывают, а вот клиентов пока маловато — единицы. Рекламы нет. Раскручиваются на народной молве.
Почему до сих пор нет комментария о том, какое отношение expect имеет к bash, нет упоминания про POSIX, и никто по-доброму настоятельно не советует читать его ранее написанные единственно правильные комментарии?
Другими словами, почему до сих пор никто не приступил к спасению новичков и начинающих? Ребята, отметившиеся в комментариях разумной критикой, вам же потом придётся за ними уязвимости убирать! Пора, пора начинать критиковать и минусовать.
:)
А если серьёзно, спасибо за хороший цикл статей!
73