Например физический (реальный) самолет сделан так, что он имеет неровности, шероховатости и неоптимальную форму. Теоретический самолет сделан так, что он не имеет недостатков. Я могу «представить» себе идеальный самолет. Или идеальный стол или стул. Они существуют, но лишь в моем уме. Теоретический самолет (или машину например или еще что-то) можно лишь вообразить в уме. Так и эти архитектурные шаблоны. Глупо/неправильно представлять в уме программу, в которой существует entity и она в невалидном состоянии. Это как представлять некрасивый стол или стул. Фантазии всегда идеальны. Если бы мы программировали «мозгом», то наверное мы смогли бы написать такой код. Но поскольку как и физический самолет мы ограничены технологиями, то реализовать «чистый код» — трудно (например можно реализовать в очень маленьких программах).
Допустим мы имеем переменную isPresent. Мы можем упростить ее до present. Но если у нас есть несколько объектов (products и filters), то уже становится непонятно, что конкретно «present» — товар или фильтр. По-этому человеку придется держать в голове к чему относится переменная: products или filters. А человек может держать одновременно в голове не более 7 вещей. По-этому название переменной present придется расширить до productsPresent (а англичане может быть добавят туда еще «are», т.к. у них так принято). Теперь держать контекст переменной present в голове не нужно.
Для появления любой новой вещи или явления необходимо взаимодействие двух или более частей. Чай появляется из взаимодействия горячей воды и листьев, а атом водорода из взаимодействия протона и электрона.
Я пока лишь додумался, что абсолютно все состоит из каких-то «опорных точек» (физики сейчас докопались вроде до кварков, а в информатике это — «бит»). Все процессы (например взаимодействие электронов осуществляется переносчиками — фотонами), все предметы — всё. Многое из статьи мне близко. Спасибо за необычную и хорошо написанную статью.
"[T]hese ads should never have been allowed to run on our service," said Twitch. «We have removed these ads and are evaluating our review processes to ensure that similar content does not run in the future.»
Не знаю, какую-то политику Twitch'а нарушают.
Действительно на Twitch крутились видео, где работники рассказывали, что им не нужны профсоюзы. Это было в рекламных вставках, и Twitch удалял такие рекламы в конце концов. Twitch принадлежит Amazon. Демократия.
А можно засунуть все группы правил в статичные методы:
class ValidationRules
{
public static function getEmailRules(){
return ['required', 'email'];
}
public static function getNameRules(){
return ['required', 'alpha'];
}
}
ну понятно, что ваш подход дает больше возможностей.
Мне было бы интересно еще решить проблему комбинаций, например где-то требуется email, name, age; где-то email, name, phone; где-то email, name, address, не получается ли дублирования, и можно ли как-то его уменьшить/избежать?
Мы гарантируем аптайм 99,98%. Допустимое суммарное время недоступности в месяц ㅡ 8 минут 38 секунд.
Разве SLA не сделан для того чтобы стараться его соблюдать? Если компания считает, что ей проще заплатить штрафы, чем работать по SLA, то пусть ждет что это вскроется.
SQL с одной стороны не дает выбрать оптимальный план запроса (даже если вы переписали свой SQL запрос чтобы он работал быстрее, не факт, что это — оптимальное решение для конкретной СУБД, может она может и лучше) — недостаточно низкоуровневости.
А с другой стороны — слишком низкоуровневый язык, чтобы запросы выглядели легко и в них можно было легко и быстро разобраться (сложные запросы).
и тестировать SQL сложно.
per layer:
import{ fetchMostPopularComment } from '@/api/comment';
import { dispatchSetMostPopularComment } from '@/state/comment';
per feature:
import { fetchMostPopularComment } from '@/comment/api';
import { dispatchSetMostPopularComment } from '@/comment/state';
вроде разница не очень заметная (а она и не должна быть заметной в том коде, что я привел). Можете пояснить по подробнее пожалуйста.
Я пока лишь додумался, что абсолютно все состоит из каких-то «опорных точек» (физики сейчас докопались вроде до кварков, а в информатике это — «бит»). Все процессы (например взаимодействие электронов осуществляется переносчиками — фотонами), все предметы — всё. Многое из статьи мне близко. Спасибо за необычную и хорошо написанную статью.
я так полагаю, что абсолютно любое изменение от бизнеса требует ровно O(1) трудозатрат изменений в коде
Может сеньер это тот человек, который знает что возможно сделать, а что — нет?
Не знаю, какую-то политику Twitch'а нарушают.
А можно засунуть все группы правил в статичные методы:
ну понятно, что ваш подход дает больше возможностей.
Мне было бы интересно еще решить проблему комбинаций, например где-то требуется email, name, age; где-то email, name, phone; где-то email, name, address, не получается ли дублирования, и можно ли как-то его уменьшить/избежать?
Разве SLA не сделан для того чтобы стараться его соблюдать? Если компания считает, что ей проще заплатить штрафы, чем работать по SLA, то пусть ждет что это вскроется.
docs.oracle.com/cd/B13789_01/server.101/b10752/hintsref.htm
Все это для достижения максимальной эффективности.
А с другой стороны — слишком низкоуровневый язык, чтобы запросы выглядели легко и в них можно было легко и быстро разобраться (сложные запросы).
и тестировать SQL сложно.