Вы же понимаете, что вам не нужно рыскать в списке созданных кем-то лицензий пытаясь подыскать подходящую именно вам и вы можете описать любые собственные условия и назвать эту лицензию любым набором букв, какой взбредет вам в голову?
Тут есть небольшая проблема. Как показала практика СССР, КНР и прочих помельче — плановая экономика хороша для выведения страны из состояния коллапса, но не очень способствует ее развитию в долгосрочной перспективе. Рынок программных продуктов (да и не только программных) так устроен, что потребитель, зачастую, понятия не имеет о том, что ему нужен какой-то продукт пока не начнет его использовать сам или не увидит примеров его использования. Таким образом, продукт общественного заказа к моменту его (заказа) исполнения может уже не быть актуальным, не соответствовать духу времени — так сказать. Успешны же те продукты, которые актуальны в момент их появления. А это значит, что производитель, чтобы выпустить успешный продукт, должен предвосхищать желания потребителя, а не просто следовать им.
Ну вот например четвертый пункт вполне себе обязывает потребителя исполнить лицензионное соглашение (купить продукт, например, если подразумевается коммерческое его использование) несмотря на то, что исходники открыты.
А пятый предлагает потребителю купить расширенный функционал.
Или вы как-то хотите заработать на opensource ничего не продавая? Хм… Я вам так скажу: один человек может получить от другого человека деньги в личное пользование только тремя способами:
1. Торговля
2. Дарение
3. Грабёж
Нельзя получить деньги избежав все три способа.
Так что либо вы что-то продаёте с opensource, либо вы просите милостыню с opensoruce, либо вы кого-то грабите с opensoure.
Ну и самое главное:
Оpen source — это не free source. Открывая (или не открывая) исходники своей интеллектуальной собственности, вы вольны монетизировать (или не монетизировать) ее так, как вам вздумается (ну или как минимум — так, как получится).
Все знают, что на open source невозможно заработать, верно?
Не верно. Кто вообще вложил автору в голову, такую странную мысль. Все прекрасно знают, что можно заработать на open source. Но не у всех получается. Вот что я могу придумать прямо сходу:
Сопровождение
Консалтинг
Облачные решения
Несвободная (внезапно) лицензия на открытый продукт
Premium source,
Продвижение основного проприетарного продукта.
Донат в конце концов.
И это только то, что мне удалось вспомнить или выдумать за 30 секугнд.
Всё верно, но бывает, что он даже не попадает в первый экран выдачи. А когда ты добавляешь заветное I, то оказывается прямо под рукой. Я например, для перехода к CacheInterface забиваю CaI, и шторм махом понимает что именно я хочу. В то время, как если бы это был просто Cache, то я бы собрал всю папку vendor и все, что там называется Cache, и не факт что интерфейс оказался бы в первом экране выдачи.
Хм… а я последнее предложение понял буквально. Я почему-то подумал, что «сложноподдерживаемые решения» — это именно репозитории с AR, а не репозитории вообще.
Я уж к холивару приготовился. А тут просто недопонимание )
Если так сильно хочется использовать репозитории, то переходите на Symfony.
Это не я сказал. Репозитории можно использовать в том фреймворке, в котром вам вкусно их использовать. Но не с любой ORM.
P.S. я не понимаю в чем вы хотите меня уличить.
P.P.S Можно использовать репозтории даже с Eloquent, если считать, что модели Eloquent это не модели предметной области, а их маппинг на базу данных.
В этом случае, у вас полчится забавный каламбур с DM работающим поверх AR.
Оратор выше, видимо, имеет ввиду, что репозитории с Data Mapper работают прекрасно, в отличии от репозиториев с Active Record.
Doctrine — единственная более менее съедобная имплементация Data Mapper на PHP.
Я же указываю на то, что Doctrine является самостоятельным проектом, разработка которого напрямую никак не связана с Symfony (косвенно может и связана — они там все общаются же).
В общем, переходить на Symfony, просто потому что там Doctrine — глупо (у вас должны быть более веские основания чтобы сменить фреймворк, в котором уже наработан опыт), потому как Doctrine точно также подключается и в Laravel. Я даже знаю человека, который наоборот цеплял Eloquent (illuminate/database) в проект на symfony. Ума не приложу, зачем это ему, но речь не об этом. Я всего лишь хотел сказать, что эти конкретные ORM не завязаны на фреймворк, как таковые. И, при желании, они легко запиливаются/выпиливаются (хотя, с выпиливанеим Eloquent из Laravel, все несколько сложнее, но не безнадежно).
Всегда добавляю суффикс Interface (за исключением тех случаев, когда название интерфейса является прилагательным). Но PSR Naming Conventions тут вообще не причем. Просто в глобальном поиске IDE (PHP Storm в моем случае) легче отличать интерфейс от имплементации. Вот такой вот я плохиш )
Начал за здравие, кончил за упокой. Я тоже полностью согласен с автором, но при чем тут Symfony? Это проблема модели взаимодействия с бд AR а не фреймворка.
Ну это странно. Нам на протяжении шести экранов объясняют, что такое дизайн ролевой игры, и за весь текст даже не вводится понятие роли. Всё про какие-то механики, контент, случайность, нелинейность. Все это прекрасно может жить и в «неролевых» играх. RPG тут как бы с боку.
Все таки, ролевая игра — это про роли. Даже не про расы-классы, а именно про РОЛИ. Если люди не могут отыгрывать в эту игру за различные роли (хотябы и не по ограничивающей механике игры, а допустим просто взяв на себя эту роль), то тут ни горы контента, ни продвинутые механики, ни даже убернелинейность, и полная свобода действий не сделают игру ролевой. Хотя… конечно же, и в cs:go можно пьесу разыграть — кто же спорит?
Очевидно же, что тип данных был выбран для эпатажа и привлечения внимания к данному материалу — никого не интересует их подлинность и репрезентативность. А оценить предлагают не результаты исследования, а возможности аналитических платформ.
Однако, все эти решения лежат в области ответственности разработчиков модулей. Я что-то так и не смог придумать ни одного варианта с исправлением браузерного api так чтобы стало хорошо.
import { Button as ButtonA } from 'lib-a'
import { Button as ButtonB } from 'lib-b'
customElements.define('button-a', ButtonA)
customElements.define('button-b', ButtonB)
Это не троллинг, я просто пытаюсь понять, почему вас так беспокоит коллизия имен.
Конечно, от этого можно защититься конвенцией именования с использованием префиксов, но такой подход сильно похож на проблемы с именами CSS-классов, избавление от которых нам обещали веб-компоненты.
Гораздо важнее, что проблема с коллизией имен больше не лежит на разработчике компонентов. А разработчик, монтирующий компоненты в свое приложение, сам волен назвать любой компонент — так, как ему удобно его называть. Это так же относится не только к стандарту веб-компонентов, но и к любому фреймворку оперирующему понятием "компоненты" в том же смысле. Как то: React, Vue, Angular, и т.п.
Так… давайте-ка сначала переведем эти слова на православный.
Junior Developer — Младший Разработчик Middle Developer — Разработчик
Senior Developer — Ведущий разработчик
И вот тут всё становится понятно. Здесь нигде нет упоминания про уровень крутости.
Нет слов типа "дипломированный", или "сертифицированный".
Это вообще не про личную квалификацию, а про то, какую позицию занимает (занимал/будет занимать) конкретный разработчик в конкретной конторе. Вот вы допустим несофтверная компания по катанию валенков, и взяли на работу (делать сайт-магазин) сына бухгалтера, который (сын) даже не окончил институт, но чего-то он там умеет в этих вордпресах. И (ВНЕЗАПНО!) оказывается, что чувак-то — ведущий разработчик. А почему? А потому, что он один и вести проект больше некому.
Ну вот никто же не станет спорить, что сениор из Google и сениор из WebDevStudio512 — вообще ни разу не одно и то же. Сениор из последней, даже на джуна в Google не вытянет.
Так почему нужно пытаться, уравнять понятие Senior для всех? Это же бред. Фактически, человек можешь проработать 10 лет на должности "обычного мидла" (ну просто потому, что он не амбициозен) — и это вообще не значит, что он не квалифицирован, так ведь? Просто ему нравится решать задачи, а не проблемы.
Итого:
Не понятия смешивайте "роль в команде" и "квалификация". Эти вещи иногда коррелируют, а иногда и нет.
ентрерпрайз решения полностью обкатываются на опен сорс :)
А пятый предлагает потребителю купить расширенный функционал.
Или вы как-то хотите заработать на opensource ничего не продавая? Хм… Я вам так скажу: один человек может получить от другого человека деньги в личное пользование только тремя способами:
1. Торговля
2. Дарение
3. Грабёж
Нельзя получить деньги избежав все три способа.
Так что либо вы что-то продаёте с opensource, либо вы просите милостыню с opensoruce, либо вы кого-то грабите с opensoure.
Ну и самое главное:
Оpen source — это не free source. Открывая (или не открывая) исходники своей интеллектуальной собственности, вы вольны монетизировать (или не монетизировать) ее так, как вам вздумается (ну или как минимум — так, как получится).
Не верно. Кто вообще вложил автору в голову, такую странную мысль. Все прекрасно знают, что можно заработать на open source. Но не у всех получается. Вот что я могу придумать прямо сходу:
И это только то, что мне удалось вспомнить или выдумать за 30 секугнд.
Всё верно, но бывает, что он даже не попадает в первый экран выдачи. А когда ты добавляешь заветное
I, то оказывается прямо под рукой. Я например, для перехода кCacheInterfaceзабиваюCaI, и шторм махом понимает что именно я хочу. В то время, как если бы это был простоCache, то я бы собрал всю папку vendor и все, что там называется Cache, и не факт что интерфейс оказался бы в первом экране выдачи.Я уж к холивару приготовился. А тут просто недопонимание )
Это не я сказал. Репозитории можно использовать в том фреймворке, в котром вам вкусно их использовать. Но не с любой ORM.
P.S. я не понимаю в чем вы хотите меня уличить.
P.P.S Можно использовать репозтории даже с Eloquent, если считать, что модели Eloquent это не модели предметной области, а их маппинг на базу данных.
В этом случае, у вас полчится забавный каламбур с DM работающим поверх AR.
Оратор выше, видимо, имеет ввиду, что репозитории с Data Mapper работают прекрасно, в отличии от репозиториев с Active Record.
Doctrine — единственная более менее съедобная имплементация Data Mapper на PHP.
Я же указываю на то, что Doctrine является самостоятельным проектом, разработка которого напрямую никак не связана с Symfony (косвенно может и связана — они там все общаются же).
В общем, переходить на Symfony, просто потому что там Doctrine — глупо (у вас должны быть более веские основания чтобы сменить фреймворк, в котором уже наработан опыт), потому как Doctrine точно также подключается и в Laravel. Я даже знаю человека, который наоборот цеплял Eloquent (illuminate/database) в проект на symfony. Ума не приложу, зачем это ему, но речь не об этом. Я всего лишь хотел сказать, что эти конкретные ORM не завязаны на фреймворк, как таковые. И, при желании, они легко запиливаются/выпиливаются (хотя, с выпиливанеим Eloquent из Laravel, все несколько сложнее, но не безнадежно).
Все таки, ролевая игра — это про роли. Даже не про расы-классы, а именно про РОЛИ. Если люди не могут отыгрывать в эту игру за различные роли (хотябы и не по ограничивающей механике игры, а допустим просто взяв на себя эту роль), то тут ни горы контента, ни продвинутые механики, ни даже убернелинейность, и полная свобода действий не сделают игру ролевой. Хотя… конечно же, и в cs:go можно пьесу разыграть — кто же спорит?
Разводилово. Срубили бабок и разбежались )
Странно, что вообще сайт остался
да вот мало смешного-то
О, теперь понимаю. А как вы бы решили эту проблему?
Сходу я вижу три возможных варианта:
Введение своей области видимости компонентов
Вендор-префикс. Это очевидно и это отлично работает в мире PHP (правда не все авторы пакетов соблюдают это правило, но большинство).
Алиасы (это скорее развитие первого варианта)
Однако, все эти решения лежат в области ответственности разработчиков модулей. Я что-то так и не смог придумать ни одного варианта с исправлением браузерного api так чтобы стало хорошо.
Я просто не понимаю, почему нельзя сделать так:
Это не троллинг, я просто пытаюсь понять, почему вас так беспокоит коллизия имен.
Гораздо важнее, что проблема с коллизией имен больше не лежит на разработчике компонентов. А разработчик, монтирующий компоненты в свое приложение, сам волен назвать любой компонент — так, как ему удобно его называть. Это так же относится не только к стандарту веб-компонентов, но и к любому фреймворку оперирующему понятием "компоненты" в том же смысле. Как то: React, Vue, Angular, и т.п.
Так… давайте-ка сначала переведем эти слова на православный.
Junior Developer — Младший Разработчик
MiddleDeveloper — РазработчикSenior Developer — Ведущий разработчик
И вот тут всё становится понятно. Здесь нигде нет упоминания про уровень крутости.
Нет слов типа "дипломированный", или "сертифицированный".
Это вообще не про личную квалификацию, а про то, какую позицию занимает (занимал/будет занимать) конкретный разработчик в конкретной конторе. Вот вы допустим несофтверная компания по катанию валенков, и взяли на работу (делать сайт-магазин) сына бухгалтера, который (сын) даже не окончил институт, но чего-то он там умеет в этих вордпресах. И (ВНЕЗАПНО!) оказывается, что чувак-то — ведущий разработчик. А почему? А потому, что он один и вести проект больше некому.
Ну вот никто же не станет спорить, что сениор из Google и сениор из WebDevStudio512 — вообще ни разу не одно и то же. Сениор из последней, даже на джуна в Google не вытянет.
Так почему нужно пытаться, уравнять понятие Senior для всех? Это же бред. Фактически, человек можешь проработать 10 лет на должности "обычного мидла" (ну просто потому, что он не амбициозен) — и это вообще не значит, что он не квалифицирован, так ведь? Просто ему нравится решать задачи, а не проблемы.
Итого:
Не понятия смешивайте "роль в команде" и "квалификация". Эти вещи иногда коррелируют, а иногда и нет.