Ринат Закирьянов: Мой опыт работы с PHP в два раза больше вашего и он говорит мне совсем противоположное. Как вы можете утверждать, что открытое ПО не стоит использовать и при этом предлагать Yii? Он ведь тоже open source. Или Linux тоже плохого качества (я говорю про кастомные дистрибутивы, а про ядро)?
Есть очень много pen source решений прекрассного качества. Надо просто выбирать не приблуду, которую пишет неизвестный студент, а продукт с большим комьюнити и активным репозиторием.
По поводу "дорабатывать в разы сложнее" отчасти соглашусь. Если требуются сильные изменения, а исходный код не покрыт тестами (в таком случае использовать его глупо), то себе дороже выйдет. Но изначально я говорил не про переделать под себя, а интегрировать в свой проект. Поставить из коробки и через API создавать нужные темы для товара.
Ринат Закирьянов: Согласитесь, иметь механизм кеширования и продумать и реализовать логику вариативности и коректной инвалидации - это разные задачи по трудозатратам. Так же RBAC в Yii есть, но я говорю о бизнесправилах для них. Здесь проблема не в отсутствии инструментов, а в проектировании.
Мы занимались разработкой форумногшо движка для внутренних нужд компании. Три разработчика потратили на это почти три месяца, а опыта у нас достаточно (и в php и в Yii).
Я тогда на себе испытал правило 80/20. Костяк системы мы накидали довольно быстро, как вы и описываете. Но потом пошли разные тонкости и неочевидные на первый взгляд моменты. И это заняло времени больше, чем мы потратили до этого.
Если мы говорим об элемнтарной системе, которую можно самому на месяц написать, то может свой велосипед и будет хорошим вариантом. Но если это система посложнее, то намного дешевле выйдет допилить готовое решение.
Самый главный плюс готоых решений (качественных) - это отсутствие багов. Они оттестированы на протяжении долгово времени большим количеством пользователей. А своя велосипед - это новые баги, часть из которых обязательно вылезет в продакшене.
Отчасти я с вами соглашусь: иногда стоит сделать самому. Но на это должны быть очень веские причины.
Ага, а потом надо добавить кеширование, не будем же мы все дерево каждый раз вытаскивать. А кешировать надо для каждого пользователя свое, в зависимости от прав. Ах да, нам же еще и разделение прав надо будет добавить для форума. Где тоже не все так просто. А еще нужен инструмент для модерации. А еще надо ... (большой список).
Не вводите человека в заблуждение. Форму - это не плагин для коментирование. Это сложно и долго. И намного проще и эффективней взять готовое решение и допились его.
Сергей Протько: Я писал, что использую slick. Сам проект на Scala, и Hibernate вроде как по идеалогии не подходит, да и коллекции разные. Но, hibernate посмотрю. Мне сейчас не важно какая именно ORM это будет. Мне важно принцип понять.
Получается, я работаю с простыми объектами. В каждом я сам должен описать методы для сохранение/загрузки в бд, через domain objects.
Например есть модель User - простой класс. Я для нее создаю некий репозиторий UserRepository, в котором метод save() принимает модель и на основании ее полей делает запрос в бд. И метод findById(), который ищет нужную запись, создает объект и возвращает его.
Я верно понял?
Java JPA - это то, в чем мне надо разбираться?
Цитата из вопроса: >>Логика меняется очень часто и для каждого изменениея городить миграцию не вариант.<<
Я знаю, что такое миграция и конечно же использую их. Но для изменения схемы бд. А если для каждого изменения процедуры буду городить миграцию, у меня будут тысячи файлов храниться.
Я считаю, что код процедур - это такой же код приложения и история должна храниться в VCS. Но вот как это удобно организовать не знаю.
Никита
Вот тут я с вами согласен. Во всех учебниках, что я видел, материал преподносился так, как будто бы читатель уже пишет на java. Для новичнов я книг не встречал.
Но опять таки, знание библиотек - это не обязательно знание java
>>утверждение, что jmv общая тоже не совсем корректно.
Может я чего не знаю? Объясните, пожалуйста, в чем разница? Как я понимаю внутри и java и scala используют один и тот же байткод. И байткод, собраный из scala можно перевести в java.
Нет, к сожалению это - не то, что надо. Грубо говоря, нужно, что бы вторая колонка пополам делилась. Но я уже понял, что просто так это сделать не получится.
@lookid Во-первых: не надо хамить. Во-вторых: где вы нытье увидели? Я конкретно спрашиваю, где можно купить статьи на специфичные темы. Это не нытье. Я пытаюсь найти ответ на конкретный вопрос.
Под "сделать с умом" я подразумеваю сопутствующий статьям функционал, такой как интерактивные учебники и онлайн-интерпретаторы.
Есть очень много pen source решений прекрассного качества. Надо просто выбирать не приблуду, которую пишет неизвестный студент, а продукт с большим комьюнити и активным репозиторием.
По поводу "дорабатывать в разы сложнее" отчасти соглашусь. Если требуются сильные изменения, а исходный код не покрыт тестами (в таком случае использовать его глупо), то себе дороже выйдет. Но изначально я говорил не про переделать под себя, а интегрировать в свой проект. Поставить из коробки и через API создавать нужные темы для товара.