@symfony_php
Vladislav21.02.2018
15:25:35
15:25:35
автолоадинг походу пропал
Gordon21.02.2018
15:28:14
15:28:14
ну секция автолоада у меня вот такая из composer.json:
"autoload": {
"psr-4": {
"": "app/",
"Entity\\": "app/Entity"
}
},
Google
Andy21.02.2018
15:59:32
15:59:32
Daniel21.02.2018
22:25:49
22:25:49
Ребята. Короче вместо псевдо-именованных конструкторов вроде фабрик методов для изначально валидного создания обьекта сущности коллега предлагает юзать сеттеры, но сеттерить через стратегии и собирать в них саму сущность.
Sergey21.02.2018
22:26:42
22:26:42
а где гарантии что эти сеттеры не вызовут вне этого билдера?
Daniel21.02.2018
22:26:55
22:26:55
+
Sergey21.02.2018
22:27:04
22:27:04
уж проще тогда просто делать обьект с публичными полями
Sergey21.02.2018
22:29:21
22:29:21
Ребята. Короче вместо псевдо-именованных конструкторов вроде фабрик методов для изначально валидного создания обьекта сущности коллега предлагает юзать сеттеры, но сеттерить через стратегии и собирать в них саму сущность.
ммм... оверинженерингом попахиваетили переизобретением шаблона "билдер"
Sergey21.02.2018
22:35:00
22:35:00
билдер бы хорошо зашел с внутренними классами)
Sergey21.02.2018
22:42:20
22:42:20
эх... да...
почему RFC по иннер классам небыло а RFC по френд классам была?
хотя... всеравно выйдет криво
без пакетов
Google
Bohdan22.02.2018
09:05:04
09:05:04
вот складывается чуть такое впечатление. что новые rfc - это попытки притянуть фичи из других языков без оглядки на реальную их применимость
Sergey22.02.2018
09:59:11
09:59:11
я бы сказал просто с высоты своего опыта.
Alan22.02.2018
10:33:07
10:33:07
юзали rethinkdb? норм ее взять например для персональных риалтайм уведомлений, сбора онлайн метрик и такого, без данных для бизнес логики - это все в постгре
Sergey22.02.2018
10:38:09
10:38:09
юзали rethinkdb? норм ее взять например для персональных риалтайм уведомлений, сбора онлайн метрик и такого, без данных для бизнес логики - это все в постгре
я тыкал, прикольная штука, юзал для сбора метрик по кодуBohdan22.02.2018
10:38:42
10:38:42
почитал про него - выглядит интересно
как я понимаю - для реалтайма реального нужно над ним подвесить еще что-то (центрифугу etc)
так?
Sergey22.02.2018
10:39:00
10:39:00
ну нет, ты можешь подписаться на изменения
Alan22.02.2018
10:39:05
10:39:05
я как раз вместо центрифуги думаю)
Alexey22.02.2018
10:39:06
10:39:06
вот у меня вообще не вяжется "realtime" и "web" :)
Sergey22.02.2018
10:39:21
10:39:21
это как firebase на минималках
Alexey22.02.2018
10:39:56
10:39:56
оно вебсокеты из коробки умеет, да?
Bohdan22.02.2018
10:40:54
10:40:54
вроде как нет
по крайенй мере - в доке этого не вижу
Sergey22.02.2018
10:40:59
10:40:59
там идея в том что бы твои клиенты коннектились напрямую к базе
Bohdan22.02.2018
10:41:01
10:41:01
хотя
Sergey22.02.2018
10:41:02
10:41:02
и с ней работали
GoogleAlexey22.02.2018
10:42:09
10:42:09
ну я так и понял. Просто вне браузерного контекста звучит как очередной велосипед. pub/sub нынче не редкость
а если WS, возможно, это неплохое решение, чтобы свой костыль не городить
Sergey22.02.2018
10:43:14
10:43:14
https://www.rethinkdb.com/blog/horizon-release/
ну то есть помиимо rethinkdb вроде как еще horizon нужен что бы было то что хочется
но я только на бэке ее юзал так что хз
а если WS, возможно, это неплохое решение, чтобы свой костыль не городить
для чисто ws есть центрифуга - а тут другая задумкану вот rethinkdb + horizon ~= firebase на минималках
то есть если тебе надо просто коллектить данные или чатики на коленке запилить какие - ты можешь вообще бэк не писать
например - тебе надо сделать трекинг местоположения. Разворачиваешь эту штуку и клиент туда пишет. Кто-то может подписаться и следить. Вжух и у нас ни одной строчки бэкэнда
ну или тупой crud (это то что я хэйчу, что если у тебя бэк это тупо записать данные и прочитать данные - то тебе бэк не нужен)
для прототипирования вообще ништяк
Alexey22.02.2018
10:47:50
10:47:50
backend vs devops
Alexey22.02.2018
10:48:29
10:48:29
конечно, про программирование на конфигах
Bohdan22.02.2018
10:48:31
10:48:31
ну data-centric приложения тоже имеют место
в которых реально бекенда особо не нужно
Alexey22.02.2018
10:48:53
10:48:53
как только возникнет необходимость поддерживать весь этот лес, сразу "devops помоги"
Bohdan22.02.2018
10:48:59
10:48:59
девопс это вообще не особо про программирование
GoogleSergey22.02.2018
10:49:00
10:49:00
ну data-centric приложения тоже имеют место
подумай шире, у тебя в твоем domain driven приложении найдется место тупому круду)который можно не делать)
Bohdan22.02.2018
10:49:05
10:49:05
Sergey22.02.2018
10:49:16
10:49:16
как только возникнет необходимость поддерживать весь этот лес, сразу "devops помоги"
ops помоги, devops это идея а не человекAlexey22.02.2018
10:49:28
10:49:28
да, я именно про это и говорю
Bohdan22.02.2018
10:49:36
10:49:36
но если я скажу "ребята, мне нужен тут девопс или еще 100500 часов на меинтейнить архитектуру" - меня пошлют
Sergey22.02.2018
10:49:55
10:49:55
да, я именно про это и говорю
ну вот смотри, если у тебя все на докерах и кубернетисах возможно поднять за 10 минут эту штуку будет дешевле чем тратить день на написание крудаBohdan22.02.2018
10:50:08
10:50:08
теоретически да, любое приложение можно построить как firebase + доп бекенд, который будет ворочать логику
Sergey22.02.2018
10:50:12
10:50:12
если нет - тогда надо думать
потому что если у тебя инфраструктура.... как у большинства... то да, профита может и не быть. Но тебя никто и не заставляет это юзать)
AdminERROR: S client not available
Sergey22.02.2018
10:51:04
10:51:04
теоретически да, любое приложение можно построить как firebase + доп бекенд, который будет ворочать логику
дальше вопрос связанности и кастылей. У меня был один проектик который начинался с firebase красиво а потом пришлось очень быстро пилить бэкBohdan22.02.2018
10:51:20
10:51:20
дальше вопрос связанности и кастылей. У меня был один проектик который начинался с firebase красиво а потом пришлось очень быстро пилить бэк
ну это само собой
везде возникает вопрос костылей со временемSergey22.02.2018
10:51:20
10:51:20
ну и были те где хорошо зашло
да, я именно про это и говорю
особенно если речь идет про "надо по быстрому запилить прототип ибо хуй пойми что они хотят"Alexey22.02.2018
10:52:42
10:52:42
ну вот смотри, если у тебя все на докерах и кубернетисах возможно поднять за 10 минут эту штуку будет дешевле чем тратить день на написание круда
это просто перетекание мозгов между отделами (зонами ответственности). Написать круд разработчикам не проще и не сложнее, чем поднять пачку ready-to-run сервисов в кластере.Sergey22.02.2018
10:53:06
10:53:06
это просто перетекание мозгов между отделами (зонами ответственности). Написать круд разработчикам не проще и не сложнее, чем поднять пачку ready-to-run сервисов в кластере.
ну вот если у тебя так - значит у тебя нет devop (идеи, а не "отдела")devops про то что у тебя нет этого разграничения
у тебя оно есть - значит тебе такое не катит)
> Написать круд разработчикам не проще и не сложнее, чем поднять пачку ready-to-run сервисов в кластере.
не проще и не сложнее - дольше
GoogleSergey22.02.2018
10:54:15
10:54:15
представь что тебе надо запилить круд для 10-ти табличек связанных, при этом тебе надо что бы клиенты в реалтайме апдейты получали + оффлайн суппорт
за сколько ты такой круд напишешь?
ну даже не 10-ти табличек, парочка типов документов
минимум день, + тестить
а так ты можешь поднять за час эту херню и фронтендеры начнут херачить
а еще есть cloud версии
если не можешь поднять за час - то да это перестает быть выгодным для тебя
но все еще модет быть профитно для кого-то другого
потому не надо так категорично заявлять, юзкейсы и обстоятельства у всех разные
Alexey22.02.2018
10:57:51
10:57:51
я согласен, что писать api (круд) для 100 объектов затратнее, чем развернуть schema-less решение. Но не согласен, что в комплексе работ это выйдет быстрее. Тебе так или иначе придется описывать схему (форматы, запросы и т.д.) либо на сервере, либо на клиенте.
это исключительно вопрос компетенций и разделения ответственности
Sergey22.02.2018
10:58:23
10:58:23
я согласен, что писать api (круд) для 100 объектов затратнее, чем развернуть schema-less решение. Но не согласен, что в комплексе работ это выйдет быстрее. Тебе так или иначе придется описывать схему (форматы, запросы и т.д.) либо на сервере, либо на клиенте.
причем тут schema less решения?а еще есть AWS dynamodb
если ты и так юзаешь AWS может быть оч профитно
Alexey22.02.2018
10:58:42
10:58:42
при том, что ты фронтам сказал "херачьте сюда", и они херачат что-то там
Sergey22.02.2018
10:59:01
10:59:01
короч главное - подключить воображение а не делать все одинаково из проекта в проетк и потом удивляться почему ничего не развивается
короч держи видосик а я пойду работать:
https://www.youtube.com/watch?v=w7X4gAQTk2E
вдруг интересно будет
Alan22.02.2018
11:00:27
11:00:27
в моем случае все схемы у меня уже описаны в постгре, но функционал который я хочу добавить к бизнес логике не имеет отношения а значит это не самое больное место проекта и больше касается фронта, че бы и не унести когда есть красивый инструмент
Sergey22.02.2018
11:01:44
11:01:44
в моем случае все схемы у меня уже описаны в постгре, но функционал который я хочу добавить к бизнес логике не имеет отношения а значит это не самое больное место проекта и больше касается фронта, че бы и не унести когда есть красивый инструмент
судя по всему ты не понимаешь о чем яя говорю о том что бы "клиент минуя бэк коннектился к базе и работал с ней"
а ты говоришь о других вещах
ты можешь и с постгрессом это провернуть)
Открыть в Telegram