Валидность данных не должна зависеть от какого-то там условного ларавеля. Сегодня это только ларавел, завтра к нему добавились дотнет и питон. А послезавтра автор запушил релиз с багом в валидаторе и как наташины котики уронил вообще всё.
Уникальные и внешние ключи, NOT NULL и прочее — они не только про валидацию, они ещё и про построение модели данных, которой очень охотно пользуется оптимизатор.
Так что я на 100% согласен с предыдущем комментарием — советы очень вредные, особенно для использования в больших системах. Сначала автор не описал в СУБД модель данных, через полгода появилась необходимость создать парочку реплик базы, потому что всё тормозит, через год у вас в штате уже есть табунчик девопсов. Зато DDD и феншуй.1)
1) Феншуй в понимании его автором статьи с вредными советами.
Почему? Меня лично раздражает выискивать глазами восклицательный знак и в уме инвертировать условие. Особенно, если надо в одном IF'е проверить пару условий.
Другое дело, если условия с отрицанием поддерживаются в самом языке:
Да понятно, про то и речь. Автор сравнивает совершенно разные вещи и делает из этого выводы. Где-то показал сферическое преимущество, где-то умолчал о нетривиальности реализации...
При 10.000.000 заказов в месяц это 1000 «обманутых» клиентов.
Если каждый из них позвонит в техподдержку и проматерится всего лишь 3 минуты, нагрузка на колл-центр будет 1000*3/60 = 50 часов.
Процентов 20 из этих клиентов рано или поздно оставит в интернетах комментарий в стиле «вот уроды», процентов 5 не поленится поставить приложению минимальную отметку. Счастливчики, попавшие на этот баг второй раз, 100% уйдут к конкурентам.
В разделе «Упражнения» — не эльфийский. Это язык Эллочки-людоедки.
Посыл статьи "Каждая кухарка Каждый программист должен быть и программистом и CFO одновременно" непонятен. Зачем это надо? Просто из-за того, что руководству жалко денег на бизнес-аналитика?
Тоже начал вести учёт в гуглотаблицах, правда, разбил всё на три отдельные книги: справочники, сырые данные (расходы) и планирование+аналитика. Расходы вводятся через гуглоформу — это вообще маст-хев, без неё вся затея давно бы умерла. Справочники вынесены в отдельную книгу, т.к. на них навешан триггер, который апдейтит форму при редактировании категорий затрат. Форма сохраняет значения в книгу "сырые данные".
В последней книге помесячно ведутся предполагаемые доходы и обязательные расходы (план/факт). Аналитика считается запросами в книгу с сырыми данными с помощью функций importrange и query. Вот, например, подсчёт трат по категориям:
=query(
IMPORTRANGE("https://docs.google.com/spreadsheets/d/xxxxxxxxxxxxxxxxxxxx"; "B:E");
"select Col2,sum(Col3) where year(Col1) = "&B1&" and month(Col1) + 1 = "&B2&" group by Col2 order by sum(Col3) desc label sum(Col3) 'Сумма'";
1)
Картинки
С красивостями и графиками не заморачивался — пока и так всё устраивает.
Это замечательно работает, если вы просто предоставляете публичное АПИ.
Но представьте, что у вас в проекте есть пять команд: бэкенд, фронтэнд, виндоус-десктоп, андроид-мобайл и эппл-мобайл. Через два месяца вам надо синхронно обновить версию приложения для всех платформ. В этой ситуации бэкенд уже не может что-то там писать-писать у себя внутри, а потом выкатить всё скопом. Или выкладывать потихоньку, постоянно что-то изменяя и добавляя. Их за это просто будут бить.
В таких случаях гораздо лучше работает подход documentation first. Все заинтересованные стороны сообща разрабатывают спецификацию API в понятном всем формате (swagger, openAPI), утверждают её и только потом приступают к разработке.
Я почти сразу после этой публикации резко сменил сферу деятельности, поэтому доделать остальные части не успел. Недавно наткнулся на черновики, перечитал и, вздохнув, стёр их: отсутствие информации лучше, чем устаревшая информация.
Ну невозможно такое читать. Сходу совершенно непонятно, где «А» — это союз, а где — сокращение от «Ардуино». С «В» то же самое. Выделение «А» и «В» очень помогло бы восприятию текста:
А вот тут поспорю, на А, которые я смотрел
А вот тут поспорю, на (А), которые я смотрел
Потому что автор слишком уж узко мыслит.
Валидность данных не должна зависеть от какого-то там условного ларавеля. Сегодня это только ларавел, завтра к нему добавились дотнет и питон. А послезавтра автор запушил релиз с багом в валидаторе и как наташины котики уронил вообще всё.
Уникальные и внешние ключи, NOT NULL и прочее — они не только про валидацию, они ещё и про построение модели данных, которой очень охотно пользуется оптимизатор.
Так что я на 100% согласен с предыдущем комментарием — советы очень вредные, особенно для использования в больших системах. Сначала автор не описал в СУБД модель данных, через полгода появилась необходимость создать парочку реплик базы, потому что всё тормозит, через год у вас в штате уже есть табунчик девопсов. Зато DDD и феншуй.1)
1) Феншуй в понимании его автором статьи с вредными советами.
Другое дело, если условия с отрицанием поддерживаются в самом языке:
тогда да, правило становится полезным.
Функция складывания пока что на стадии разработки.
Шестого декабря я напишу здесь очень важный комментарий. Не пропустите! Подписывайтесь на мой комментарий, ставьте лайки!
Да понятно, про то и речь. Автор сравнивает совершенно разные вещи и делает из этого выводы. Где-то показал сферическое преимущество, где-то умолчал о нетривиальности реализации...
Ps: в целом статья очень даже хорошая.
Какой ужас. Давно же придумали лаконичный и однозначный синтаксис:
2PhpRussia: Мне мало интересны видеоматериалы, но я бы их купил, чтобы просто поддержать проект. К сожалению, это оказалось слишком сложно.
Можно, я буду пересылать вам вакансии своих конкурентов? Вдруг какая понравится...
Если каждый из них позвонит в техподдержку и проматерится всего лишь 3 минуты, нагрузка на колл-центр будет 1000*3/60 = 50 часов.
Процентов 20 из этих клиентов рано или поздно оставит в интернетах комментарий в стиле «вот уроды», процентов 5 не поленится поставить приложению минимальную отметку. Счастливчики, попавшие на этот баг второй раз, 100% уйдут к конкурентам.
Посыл статьи "
Каждая кухаркаКаждый программист должен быть и программистом и CFO одновременно" непонятен. Зачем это надо? Просто из-за того, что руководству жалко денег на бизнес-аналитика?Тоже начал вести учёт в гуглотаблицах, правда, разбил всё на три отдельные книги: справочники, сырые данные (расходы) и планирование+аналитика. Расходы вводятся через гуглоформу — это вообще маст-хев, без неё вся затея давно бы умерла. Справочники вынесены в отдельную книгу, т.к. на них навешан триггер, который апдейтит форму при редактировании категорий затрат. Форма сохраняет значения в книгу "сырые данные".
В последней книге помесячно ведутся предполагаемые доходы и обязательные расходы (план/факт). Аналитика считается запросами в книгу с сырыми данными с помощью функций importrange и query. Вот, например, подсчёт трат по категориям:
С красивостями и графиками не заморачивался — пока и так всё устраивает.
Но представьте, что у вас в проекте есть пять команд: бэкенд, фронтэнд, виндоус-десктоп, андроид-мобайл и эппл-мобайл. Через два месяца вам надо синхронно обновить версию приложения для всех платформ. В этой ситуации бэкенд уже не может что-то там писать-писать у себя внутри, а потом выкатить всё скопом. Или выкладывать потихоньку, постоянно что-то изменяя и добавляя. Их за это просто будут бить.
В таких случаях гораздо лучше работает подход documentation first. Все заинтересованные стороны сообща разрабатывают спецификацию API в понятном всем формате (swagger, openAPI), утверждают её и только потом приступают к разработке.
У меня в квартире много окон и довольно высокий этаж, часто мыть окна снаружи (да и внутри) никакого желания нет.
Ну невозможно такое читать. Сходу совершенно непонятно, где «А» — это союз, а где — сокращение от «Ардуино». С «В» то же самое. Выделение «А» и «В» очень помогло бы восприятию текста:
А вот тут поспорю, на А, которые я смотрел
А вот тут поспорю, на (А), которые я смотрел