Как стать автором
Обновить
26
0

Пользователь

Отправить сообщение

Потому что автор слишком уж узко мыслит.


Валидность данных не должна зависеть от какого-то там условного ларавеля. Сегодня это только ларавел, завтра к нему добавились дотнет и питон. А послезавтра автор запушил релиз с багом в валидаторе и как наташины котики уронил вообще всё.


Уникальные и внешние ключи, NOT NULL и прочее — они не только про валидацию, они ещё и про построение модели данных, которой очень охотно пользуется оптимизатор.


Так что я на 100% согласен с предыдущем комментарием — советы очень вредные, особенно для использования в больших системах. Сначала автор не описал в СУБД модель данных, через полгода появилась необходимость создать парочку реплик базы, потому что всё тормозит, через год у вас в штате уже есть табунчик девопсов. Зато DDD и феншуй.1)


1) Феншуй в понимании его автором статьи с вредными советами.

Запрещены отрицательные логические названия
Почему? Меня лично раздражает выискивать глазами восклицательный знак и в уме инвертировать условие. Особенно, если надо в одном IF'е проверить пару условий.

Другое дело, если условия с отрицанием поддерживаются в самом языке:
if ($component->enabled()) { 
    print "OK"; 
}

unless ($component->enabled()) {
    print "Whoops";
}
тогда да, правило становится полезным.

Функция складывания пока что на стадии разработки.

Шестого декабря я напишу здесь очень важный комментарий. Не пропустите! Подписывайтесь на мой комментарий, ставьте лайки!

Да понятно, про то и речь. Автор сравнивает совершенно разные вещи и делает из этого выводы. Где-то показал сферическое преимущество, где-то умолчал о нетривиальности реализации...


Ps: в целом статья очень даже хорошая.

И всё-таки, если можно, опишите в двух словах: как веб-кеш на балансировщике узнает, что данные в БД изменились?
class Post {
    private $title;
    fn getTitle() => $this->title;
}

Какой ужас. Давно же придумали лаконичный и однозначный синтаксис:

class Post {
    private $title { get; protected set; }
}
О, другое дело. Большое спасибо за информацию о цене.
Записи обещают выложить через 6 месяцев. Сейчас их можно купить, но сколько это стоит — неизвестно. Стратегия ценообразования — «написала в личку».

2PhpRussia: Мне мало интересны видеоматериалы, но я бы их купил, чтобы просто поддержать проект. К сожалению, это оказалось слишком сложно.
На сколько я помню из своих тестов, вариант с биндингом примерно в три раза быстрее рефлексии.

Можно, я буду пересылать вам вакансии своих конкурентов? Вдруг какая понравится...

При 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), утверждают её и только потом приступают к разработке.
А кто-нибудь пользовался мойщиками окон? Вот, например, первый попавшийся экземпляр: www.dns-shop.ru/product/63706e1565b83330/robot-mojsik-okon-hobot-188-belyj
У меня в квартире много окон и довольно высокий этаж, часто мыть окна снаружи (да и внутри) никакого желания нет.
Я почти сразу после этой публикации резко сменил сферу деятельности, поэтому доделать остальные части не успел. Недавно наткнулся на черновики, перечитал и, вздохнув, стёр их: отсутствие информации лучше, чем устаревшая информация.
А вот тут поспорю, на А, которые я смотрел

Ну невозможно такое читать. Сходу совершенно непонятно, где «А» — это союз, а где — сокращение от «Ардуино». С «В» то же самое. Выделение «А» и «В» очень помогло бы восприятию текста:

А вот тут поспорю, на А, которые я смотрел
А вот тут поспорю, на (А), которые я смотрел
Если 16 это про RGB, то в гимпе надо делать Цвет → Максимум RGB

Информация

В рейтинге
Не участвует
Откуда
Новокузнецк, Кемеровская обл., Россия
Дата рождения
Зарегистрирован
Активность