Допустим мы имеем переменную 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 сложно.