Благодаря текстовым интерфейсам, каждая команда должна знать как форматировать и это увеличение опций умножается на количество команд.
В powershell, благодаря объектной модели, команды более ортогональны. Отформатировать можно одними и теми же способами выхлопы разных команд.
# вывести процессы отсортированные по ID в грид
ps | sort id | ogv
# вывести все сервисы в названии которых есть SQL сгруппированные по статусу и отформатировать как таблицу с автоматическим размером колонок
gsv *sql* | sort status | group status | ft -au
нам не нужно расшаривать состояние между двумя вкладками одного ии того же приложения.
Я бы уточнил — нужно, но мы обычно это делаем внутри процесса, а не по сети.
Ага, так понятно. А нельзя было как-то более удобно это сделать без всех этих текстовых констант и кейзов? Чтобы оно сраружи выглядело как 2 way binding а внутри была бы вся эта иммутабельность и прочее. Свитчи под капотом, редюсеры знают только про свою часть состояния и так далее.
А вот не может ли кто-нибудь мне, человеку далекому от веба, объяснить зачем нужны фреймворки управления состоянием и желательно дать концептуальный анализ почему они нужны в вебе и не нужны на десктопе, или менее распространены (например в каком-нибудь WPF).
С моей точки зрения вот это вот практически полностью не очень хорошо спроектированный бойлерплейт:
const LoginComponent = (state = initialState, action) => {
switch (action.type) {
// This reducer handles any action with type "LOGIN"
case "LOGIN":
return state.map(user => {
if (user.username !== action.username) {
return user;
}
if (user.password == action.password) {
return {
...user,
login_status: "LOGGED IN"
}
}
});
default:
return state;
}
};
И в высокоуровневом коде такое не желательно — хотелось бы как-то связать View с моделью, но при этом не думать об управлении состоянием, причем, в терминах текстовых констант. Типа как в WPF + MVVM.
Делать велосипед хорошо, если это учебный проект (цель — разобраться, как устроен велосипед) либо человек ознакомился с основными существующими конструкциями велосипедов и понимает, чем именно они его не устраивают. Желательно так же понять, были ли попытки построить именно такой велосипед, как он хочет, почему они провалились и почему у него должно получиться.
Во втором случае, правда, это не совсем велосипед.
Еще во втором случае надо, чтобы выгода он новых свойств перевесила недостатки от риска, стоимости создания, отсутствия поддержки и так далее.
С моей точки зрения размытые вопросы — это не хамство. Во-первых, не все всегда умеют внятно сформулировать, во-вторых, можно их задавать специально, чтобы выяснить умеет ли человек общаться. В работе довольно часто нужно достигать понимания и устранять неопределенность, например, можно уточнить что человек именно имеет ввиду.
type NonEmptyArray<T> = [T, ...T[]];
const okay: NonEmptyArray<number> = [1, 2];
const alsoOkay: NonEmptyArray<number> = [1];
const err: NonEmptyArray<number> = []; // error!
if (isNonEmptyArray(bar)) {
needNonEmpty(bar); // okay
} else {
needEmpty(bar); // error!! urgh, do you care?
}
контексте самого произвольного вектора без создания сторонних типов.
Как только вы описываете концепцию вектора с некоторым условием, воспринимаемую системой типов вы создаете новый тип на основе верктора, возможно, неименованный.
Мне думается еще чем опаснее, тем больше усилий тратится на борьбу (например, у симптомного бошльше шансов попасть на карантин) => тем меньше возможностей размножиться. Интересно, насколько это влияет на эволюцию вируса.
Обычно при кешировании время повторного запроса тех же данных меньше, соответственно, внешний наблюдатель с секундомером это может заметить. Я бы назвал это изменением поведения (причем намеренным).
Я не помню, чтобы кто-то из авторов книжек называл рефакторингом введения кеша. Так же стоит учитывать что оно находится в связи со словом factoring — декомпозиция, разбиение на кусочки.
Такое прочтение слова refactoring имеет ценность, так как рекомендуют отделять реструктуризацию кода от значимых изменений.
Возможно в разных прочтениях слова таится не понимание между pnovikov и marvin255 — если это так, то с точки зрения первого необходимость рефакторинга означает плохой факторинг кода, а с точки зрения второго, нет, так как рефакторинг это просто любое изменение кроме изменения связанного с функциональными требованиями. Хорошая декомпозиция (факторинг) на репозитории позволила просто добавить кеш.
"Рефа́кторинг (англ. refactoring), или перепроектирование кода, переработка кода, равносильное преобразование алгоритмов — процесс изменения внутренней структуры программы, не затрагивающий её внешнего поведения "
Обычно в книжках по рефакторингу я видел "extract method" а не "introduce cache".
А что, серологический тест уже есть? Кто проводит? В википедии вот что:
A number of laboratories and companies are developing serological tests, which detect antibodies.[413] As of 6 April 2020, none of these has been proved sufficiently accurate to be approved for widespread use.[414] In the US a serological test developed by Cellex has been approved for emergency use by certified laboratories only.[415]
Достаточно сделать адаптер. В powershell если в pipe встроить обычную программу, она будет потреблять текст. Т.е. количество костылей уменьшается.
Благодаря текстовым интерфейсам, каждая команда должна знать как форматировать и это увеличение опций умножается на количество команд.
В powershell, благодаря объектной модели, команды более ортогональны. Отформатировать можно одними и теми же способами выхлопы разных команд.
Я бы уточнил — нужно, но мы обычно это делаем внутри процесса, а не по сети.
Ага, так понятно. А нельзя было как-то более удобно это сделать без всех этих текстовых констант и кейзов? Чтобы оно сраружи выглядело как 2 way binding а внутри была бы вся эта иммутабельность и прочее. Свитчи под капотом, редюсеры знают только про свою часть состояния и так далее.
Или я чего-то не понимаю?
А вот не может ли кто-нибудь мне, человеку далекому от веба, объяснить зачем нужны фреймворки управления состоянием и желательно дать концептуальный анализ почему они нужны в вебе и не нужны на десктопе, или менее распространены (например в каком-нибудь WPF).
С моей точки зрения вот это вот практически полностью не очень хорошо спроектированный бойлерплейт:
И в высокоуровневом коде такое не желательно — хотелось бы как-то связать View с моделью, но при этом не думать об управлении состоянием, причем, в терминах текстовых констант. Типа как в WPF + MVVM.
Делать велосипед хорошо, если это учебный проект (цель — разобраться, как устроен велосипед) либо человек ознакомился с основными существующими конструкциями велосипедов и понимает, чем именно они его не устраивают. Желательно так же понять, были ли попытки построить именно такой велосипед, как он хочет, почему они провалились и почему у него должно получиться.
Во втором случае, правда, это не совсем велосипед.
Еще во втором случае надо, чтобы выгода он новых свойств перевесила недостатки от риска, стоимости создания, отсутствия поддержки и так далее.
С моей точки зрения размытые вопросы — это не хамство. Во-первых, не все всегда умеют внятно сформулировать, во-вторых, можно их задавать специально, чтобы выяснить умеет ли человек общаться. В работе довольно часто нужно достигать понимания и устранять неопределенность, например, можно уточнить что человек именно имеет ввиду.
Я просто пытался избавиться от древнегреческого заимствования в вашей фразе
Если нужен второй спец, а есть уже один со своей технологией то как искать?
Вы хотели сказать "подобия"?
Ой, это не также. [] — это стандартный литерал для массива в typescript а вам приходится делать что-то специальное. Часть с тайпгардом не реализована.
Подсказка: вот это — стандартный литерал для массива.
В TS вы можете стандартный массив попробовать привести этому типу.
И вот тут идет речь про стандартный массив:
Внутри If у переменной bar уточняется тип до NonEmpty а внутри else — стандартный массив
Создайте, только, чтобы вот это так же работало:
Как только вы описываете концепцию вектора с некоторым условием, воспринимаемую системой типов вы создаете новый тип на основе верктора, возможно, неименованный.
В тайпскрипт, оказывается, тоже можно
Мне думается еще чем опаснее, тем больше усилий тратится на борьбу (например, у симптомного бошльше шансов попасть на карантин) => тем меньше возможностей размножиться. Интересно, насколько это влияет на эволюцию вируса.
Обычно при кешировании время повторного запроса тех же данных меньше, соответственно, внешний наблюдатель с секундомером это может заметить. Я бы назвал это изменением поведения (причем намеренным).
Я не помню, чтобы кто-то из авторов книжек называл рефакторингом введения кеша. Так же стоит учитывать что оно находится в связи со словом factoring — декомпозиция, разбиение на кусочки.
Такое прочтение слова refactoring имеет ценность, так как рекомендуют отделять реструктуризацию кода от значимых изменений.
Возможно в разных прочтениях слова таится не понимание между pnovikov и marvin255 — если это так, то с точки зрения первого необходимость рефакторинга означает плохой факторинг кода, а с точки зрения второго, нет, так как рефакторинг это просто любое изменение кроме изменения связанного с функциональными требованиями. Хорошая декомпозиция (факторинг) на репозитории позволила просто добавить кеш.
Я был неточен в определении.
Да, мне надо было скопипастить из википедии:
Обычно в книжках по рефакторингу я видел "extract method" а не "introduce cache".
А что, серологический тест уже есть? Кто проводит? В википедии вот что:
Это не рефакторинг а добавление новой фичи. Рефакторинг — это изменение структуры кода без изменения функциональности.
Вот тут аргументы в пользу локдауна:
https://www.washingtonpost.com/graphics/2020/world/corona-simulator/
Начиная с
Whoops! As health experts would expect, it proved impossible to completely seal off the sick population from the healthy.