Нету главного процесса. В любойм процессе есть минимум один поток (его Вы и назвали главным). При порождении других потоков в рамках этого процесса они все равноправны и независимы друг от друга (у них разный стек, у каждого свой). Вполне логично что выброшонное исключение сворачивает до верху стек потока и завершает поток. Выплыть в каком-то другом потоке исключение само никак не может, т.к. это отдельный поток, отдельный стек и все отдельное, кроме общей памяти.
По поводу термина «главный». Вобщем то он просто первый, ничем не главнее других. Все равноправно могут вызвать exit процесса, все могут не вызывать. Кстати, если обойти стандартный механизм завершения программы (с которым приедться столкнуться при попытке завершить «первый» поток), то процесс может легко существовать без «первого» потока. Важно наличие хотябы одного потока, любого.
SamDark верно ответил. composer имел море багов, большая часть которых росла из обратной совместимости, часть из раздолбайства сообщества поддерживающего репозитории доступные в нем. В итоге первая часть проблем решилась на текущий момент, вторую каждый решил сам и не юзает либы людей которые могут легко снести тег с релизом 1.0.0 и оставить только 1.4.x. А то есть всякие индусы которые пишут хорошие вещи под Yii2, пушат в гитхаб, а потом берут — и переделывают или удаляют теги, а ты как бы и не знал, пока не начал релизиться. Я для себя это решил путем клона реп к себе и использованием чисто своих форков. Чтобы никто удаленно ничего не сломал в либах которые я юзаю.
Вопрос не о замене, а о развитии. Другой который был — умер (pear).
Ну багов там было масса — https://github.com/composer/composer/issues?q=is%3Aissue+is%3Aclosed
Сейчас уже кончено сильно лучше, чем было, он развивается. Но все же — начиная использовать фреймворк — хочется чтобы и все инструменты вокруг были хороши.
У нас на Yii2 написано 6 проектов, да, хорошо, здорово — но вот делать ли на нем «все» — пока вопрос.
Вопрос не только к композеру, такая же история с кодсепшином и другими инструментами вокруг фреймворка — они мягко говоря недотягивают.
У меня есть вопрос на тему yii2 и composer.
Yii2 ныне стабильный и хороший фреймворк, готовый и цельный продукт, но почти гвоздями прибит к composer. Сам же composer до последнего времени имел довольно приличное количество багов (которые уже закрыли в стабильной версии, но написали новые). Собственно вопрос к SamDark:
Ввиду того, что использование yii2 без composer неудобно и почти невозможно — команда yii2 будет контрибьютить композер или это предоставится на волю и желание публики?
забыли описать важную фичу, описали что-то недостаточно ясно, да просто орфографические и пунктуационные ошибки.
вот эти проблемы и решает мой подход. это не идеальный кейс, а нормаьный и достаточный.
Вы начинаете путаться в показаниях.
Не начинаю. Вы снова не поняли. В задаче есть «документация» — да. но ее там никто кроме разработчика читать не будет. читать ее будут в хранилище документации. вы часто ставите задачи? в теле задачи пишите что нужно сделать и доку. ок. задача готова и идет в топку т.к. никому не нужна. документация идет в хранилище. все проще, чем вы представляете. не усложняйте ;-)
Документация к методу API — это же не только его название и набор параметров. Как минимум описание «что? зачем? когда нельзя использовать? когда нужно?». Ведь иначе новый человек пришедший в проект, через 3 года (когда старых людей уже нет в команде) — просто ничего не поймет из доки и придется читать код. Есть еще важный момент — аналитики и менеджеры тоже должны знать что там есть и понимать это человеческим языком — иначе каждая их задача в итоге превратится в ежедневную «допилку» API и они не смогут экономить время разработки.
Два источника — совсем не так. Задача на разработку API в jira/redmine — ну никак не источник документации ее вообще потом могут не найти, да и искать не нужно. Источник один — где там удобно в wiki, в конфлюенс или где то еще.
Проблема в том, что документацию часто приходится дополнять, поправлять.
Если так приходится делать — вы либо теряете обратную совместимость, либо делаете новую версию, либо изначально сделали не то что хотели — это совсем не вопрос ведения документации, скорее вопрос к тому что вы делаете и зачем.
Как минимум написать 3 буквы в разметке. Это тоже поддержка. И дело не в том сколько букв, а в том что работают Люди — и мы все время от времени забываем их поправить.
А решение с постановкой задачи в виде доки — исключает любые факторы и не завязано на инструменты.
В понятиях микросервисов и нашем подходе — минорная версия это багфикс. Он обязан быть обратносовместим и сохранять интерфейс.
После появления новой версии, старая снимается с поддержки даже с багфиксрв.
Обычно у нас версия 1 — это рабочий прототип на php, а 2ая это полноценная версия на C++. Далее изменения уже не требуются.
Ну и читайте статью — https://megamozg.ru/post/24718/, там все ответы
Совсем нет. Вы просто сходу представляете нерасширяему систему (MVC например).
Что такое добавить нового клиента в приложение? Идем с конца: нам нужна сущность клиента, нам нужна возможность его добавить (форма), нам нужны внешние ключи/связи.
Вспоминаем, что база это не то куда надо гадить, а мы понимаем ее как "микросервис для хранения данных". Окей.
Итого: 2 задачи, 2 фичи, 2 правки:
Добавить таблицу с юзерами в БД (правка в микросервисе "СУБД", CREATE TABLE, CRAETE VIEW)
Нужен интерфейс (список, форма добавления/редактирования, валидация, само сохранение) — чисто новый микросервис, ничем на прочее не завязанный. На запись в БД имеет права только в свою табличку clients. На чтение — только из готовых VIEW (чтоб связи выбрат — клиент-менеджер, клиент-партнер). VIEW как известно — это интерфейс (читаем wikipedia).
Как пускать туда манагеров в этот микросервис? Ну да, у нас же нормальная архитектура и композиция — авторизация у нас централизована по токену.
Как показать все в едином интерфейсе? Ну да, у нас же все по уму — мы ssi используем и proxy_pass. Внешне — все в одном UI, не внешне — хоть в разных ЦОД.
Вы просто начинаете с того, что у вас монолит на MVC — там да, проблема. Но не надо закладываться на то, что "мы сразу с нуля будем делать плохо"
Нету главного процесса. В любойм процессе есть минимум один поток (его Вы и назвали главным). При порождении других потоков в рамках этого процесса они все равноправны и независимы друг от друга (у них разный стек, у каждого свой). Вполне логично что выброшонное исключение сворачивает до верху стек потока и завершает поток. Выплыть в каком-то другом потоке исключение само никак не может, т.к. это отдельный поток, отдельный стек и все отдельное, кроме общей памяти.
По поводу термина «главный». Вобщем то он просто первый, ничем не главнее других. Все равноправно могут вызвать exit процесса, все могут не вызывать. Кстати, если обойти стандартный механизм завершения программы (с которым приедться столкнуться при попытке завершить «первый» поток), то процесс может легко существовать без «первого» потока. Важно наличие хотябы одного потока, любого.
Ну багов там было масса — https://github.com/composer/composer/issues?q=is%3Aissue+is%3Aclosed
Сейчас уже кончено сильно лучше, чем было, он развивается. Но все же — начиная использовать фреймворк — хочется чтобы и все инструменты вокруг были хороши.
У нас на Yii2 написано 6 проектов, да, хорошо, здорово — но вот делать ли на нем «все» — пока вопрос.
Вопрос не только к композеру, такая же история с кодсепшином и другими инструментами вокруг фреймворка — они мягко говоря недотягивают.
Yii2 ныне стабильный и хороший фреймворк, готовый и цельный продукт, но почти гвоздями прибит к composer. Сам же composer до последнего времени имел довольно приличное количество багов (которые уже закрыли в стабильной версии, но написали новые). Собственно вопрос к SamDark:
Ввиду того, что использование yii2 без composer неудобно и почти невозможно — команда yii2 будет контрибьютить композер или это предоставится на волю и желание публики?
P.S. может я чего-то не знаю — ткните носом плиз
вот эти проблемы и решает мой подход. это не идеальный кейс, а нормаьный и достаточный.
Не начинаю. Вы снова не поняли. В задаче есть «документация» — да. но ее там никто кроме разработчика читать не будет. читать ее будут в хранилище документации. вы часто ставите задачи? в теле задачи пишите что нужно сделать и доку. ок. задача готова и идет в топку т.к. никому не нужна. документация идет в хранилище. все проще, чем вы представляете. не усложняйте ;-)
Документация к методу API — это же не только его название и набор параметров. Как минимум описание «что? зачем? когда нельзя использовать? когда нужно?». Ведь иначе новый человек пришедший в проект, через 3 года (когда старых людей уже нет в команде) — просто ничего не поймет из доки и придется читать код. Есть еще важный момент — аналитики и менеджеры тоже должны знать что там есть и понимать это человеческим языком — иначе каждая их задача в итоге превратится в ежедневную «допилку» API и они не смогут экономить время разработки.
Два источника — совсем не так. Задача на разработку API в jira/redmine — ну никак не источник документации ее вообще потом могут не найти, да и искать не нужно. Источник один — где там удобно в wiki, в конфлюенс или где то еще.
Если так приходится делать — вы либо теряете обратную совместимость, либо делаете новую версию, либо изначально сделали не то что хотели — это совсем не вопрос ведения документации, скорее вопрос к тому что вы делаете и зачем.
А решение с постановкой задачи в виде доки — исключает любые факторы и не завязано на инструменты.
После появления новой версии, старая снимается с поддержки даже с багфиксрв.
Обычно у нас версия 1 — это рабочий прототип на php, а 2ая это полноценная версия на C++. Далее изменения уже не требуются.
Ну и читайте статью — https://megamozg.ru/post/24718/, там все ответы
"все" и "кто-то" один — я имею ввиду микросервисы.
Что такое добавить нового клиента в приложение? Идем с конца: нам нужна сущность клиента, нам нужна возможность его добавить (форма), нам нужны внешние ключи/связи.
Вспоминаем, что база это не то куда надо
гадить, а мы понимаем ее как "микросервис для хранения данных". Окей.Итого: 2 задачи, 2 фичи, 2 правки:
Как пускать туда манагеров в этот микросервис? Ну да, у нас же нормальная архитектура и композиция — авторизация у нас централизована по токену.
Как показать все в едином интерфейсе? Ну да, у нас же все по уму — мы ssi используем и proxy_pass. Внешне — все в одном UI, не внешне — хоть в разных ЦОД.
Вы просто начинаете с того, что у вас монолит на MVC — там да, проблема. Но не надо закладываться на то, что "мы сразу с нуля будем делать плохо"