Строго говоря, этого и не было написано. Было написано, что Дейкстра применяется для частного случая графов. Графов, а не алгоритмов. Перечитайте еще раз исходный комментарий.
Согласен, отстой. Повсеместно наблюдается путаница между тем, что относится к SQL вообще (обычно это базовые вещи, да и то не всегда), и фичами конкретных СУБД, и только их.
Ну например, описание ON CONFLICT - пойдите и попробуйте найти это скажем для оракла или для MS SQL? Не найдете, потому что там это называется по-другому. Нигде не указано, для какой СУБД это работает, что универсально (в рамках стандарта SQL), а что специфично. И такого навалом. Я почитал последние пункты - примерно половина из них на самом деле относится к PostgreSQL. А например MERGE - это фича MS SQL, при этом нигде это не указано.
Да не похоже, а точно. Впрочем, возможно я видел этот же текст у этого же автора прямо тут. А сейчас это его исправленный вид. И что-то правда даже исправлено, но при этом все равно местами б-р-р.
Я вам больше скажу - еще во времена S/360 между кодом на ассемблере и железом уже существовал слой микрокода. В котором понимали только разработчики машины из IBM, и который был разным для каждой модели. И так что, с тех пор только они тру программисты? Да нет конечно, это полная фигня.
Как по мне, вы по сути подтвердили мои сомнения. 1-3 много, 4 в самый раз, а 2 это плохо. И? Выходит этот параметр вообще не важен (на самом деле важен конечно, потому что у 1 человека конфликты при слиянии веток очевидно очень редки (хотя я не просто могу их представить, а лично видел). В итоге просто число человек в команде без других показателей вообще не говорит ни о чем.
Ну и потом - если у вас большое число конфликтов у двух людей, значит они почему-то правят одни и те же куски кода? Это наводит на мысли, что на самом деле этот код просто обладает излишней связностью, и его бы надо порефакторить, разбив на более независимые куски. Т.е. качество кода, что бы мы под этим не понимали, чуть ли не более важно при выборе методов работы с ветками в репозитории.
Команда 1-3 человека и расширение не планируется. Для такого размера команды TBD довольно сложный инструмент.
И прямо тут же практически написано, что всего было 5 команд общей численностью 20 человек (т.е. в среднем - четыре). То есть, 3 это слишком мало, а 4 в самый раз? Ну хм.
А вы удивлены? Я нет. Это вполне типично - внедрять скажем метрику скорости закрывания задач, потому что это мы можем померять. Главное при этом что? Правильно, внедрить ее надо даже там, где скорость не нужна (а такие проекты, поверьте, существуют).
Понимаете, вот скажем в моей компании (отделе) процентов 90% девопса - это Jenkins, Nexus, Git и Ansible. У вас очевидно не так. Поэтому надо было бы описать, что у вас за проект, которому нужен девопс, и почему вы выбираете те инструменты, которые выбираете. Сначала цели. Потом анализ существующих решений и выбор своего. Потом описание, чем свое решение лучше других. Для вашего проекта. Такой вполне обычный план, который у вас не очень наблюдается.
Я бы больше сказал - то в чем смысл должно быть в первом абзаце. Девопс это про развертывание чего-то, что делает работу. Написать достаточно длинный текст, и при этом умудриться ни слова не сказать о том, что же за проект мы развертываем - это надо было постараться.
Честно говоря, не думаю что это что-то да значит. Я вот никогда не видел java разработчиков, пользующихся VS Code. Это конечно не значит, что их нет, но когда лет за 10 (ну или сколько там лет VS Code) не видел ни одного - наводит на мысли. Eclipse видел, NetBeans видел (не часто), VS Code - никогда.
Ну я не ставлю под сомнение, что они влияют, я скорее про всеобщность. Вот я прямо щас искал себе шлифовальную машинку, где конкурентом маркетплейсов является все тот же ВсеИнструменты (и есть еще куча сайтов только тех, что я знаю и помню). И что я вам скажу - одна и та же модель на ВсеИнструменты стоит 15 тыс примерно, а на маркетплейсе - от 18 до бесконечности, в зависимости от жадности. И у меня есть полное впечатление, что все те 20 продавцов, которые ее предлагают на маркетплейсе, все берут ее в одном месте. У того же специализированного сайта.
Ой, да не за что. Как мы видим, у вас правда написано не очень внятно, похоже какое-то слово было опущено.
Вот тут явно напрашивается "обрабатывает частный случай графа с"...
Согласен, тут я нечетко выразился тоже. Не понимаю, откуда у меня такое отложилось.
Ну я вот про что:
Возможно тут коряво написано, соглашусь, но тут же нет утверждения, что алгоритм Дейкстры частный случай алгоритма Форда - Беллмана?
Строго говоря, этого и не было написано. Было написано, что Дейкстра применяется для частного случая графов. Графов, а не алгоритмов. Перечитайте еще раз исходный комментарий.
Согласен, отстой. Повсеместно наблюдается путаница между тем, что относится к SQL вообще (обычно это базовые вещи, да и то не всегда), и фичами конкретных СУБД, и только их.
Ну например, описание ON CONFLICT - пойдите и попробуйте найти это скажем для оракла или для MS SQL? Не найдете, потому что там это называется по-другому. Нигде не указано, для какой СУБД это работает, что универсально (в рамках стандарта SQL), а что специфично. И такого навалом. Я почитал последние пункты - примерно половина из них на самом деле относится к PostgreSQL. А например MERGE - это фича MS SQL, при этом нигде это не указано.
Да не похоже, а точно. Впрочем, возможно я видел этот же текст у этого же автора прямо тут. А сейчас это его исправленный вид. И что-то правда даже исправлено, но при этом все равно местами б-р-р.
Я вам больше скажу - еще во времена S/360 между кодом на ассемблере и железом уже существовал слой микрокода. В котором понимали только разработчики машины из IBM, и который был разным для каждой модели. И так что, с тех пор только они тру программисты? Да нет конечно, это полная фигня.
Ну да, я примерно это и имел в виду. Ни один из параметров. не является полностью определяющим сам по себе. Нужно смотреть в совокупности.
Как по мне, вы по сути подтвердили мои сомнения. 1-3 много, 4 в самый раз, а 2 это плохо. И? Выходит этот параметр вообще не важен (на самом деле важен конечно, потому что у 1 человека конфликты при слиянии веток очевидно очень редки (хотя я не просто могу их представить, а лично видел). В итоге просто число человек в команде без других показателей вообще не говорит ни о чем.
Ну и потом - если у вас большое число конфликтов у двух людей, значит они почему-то правят одни и те же куски кода? Это наводит на мысли, что на самом деле этот код просто обладает излишней связностью, и его бы надо порефакторить, разбив на более независимые куски. Т.е. качество кода, что бы мы под этим не понимали, чуть ли не более важно при выборе методов работы с ветками в репозитории.
И прямо тут же практически написано, что всего было 5 команд общей численностью 20 человек (т.е. в среднем - четыре). То есть, 3 это слишком мало, а 4 в самый раз? Ну хм.
А вы удивлены? Я нет. Это вполне типично - внедрять скажем метрику скорости закрывания задач, потому что это мы можем померять. Главное при этом что? Правильно, внедрить ее надо даже там, где скорость не нужна (а такие проекты, поверьте, существуют).
Понимаете, вот скажем в моей компании (отделе) процентов 90% девопса - это Jenkins, Nexus, Git и Ansible. У вас очевидно не так. Поэтому надо было бы описать, что у вас за проект, которому нужен девопс, и почему вы выбираете те инструменты, которые выбираете. Сначала цели. Потом анализ существующих решений и выбор своего. Потом описание, чем свое решение лучше других. Для вашего проекта. Такой вполне обычный план, который у вас не очень наблюдается.
Я бы больше сказал - то в чем смысл должно быть в первом абзаце. Девопс это про развертывание чего-то, что делает работу. Написать достаточно длинный текст, и при этом умудриться ни слова не сказать о том, что же за проект мы развертываем - это надо было постараться.
как вы угадали? )
ну в общем да. До вкусвила в этом смысле не дотягивает.
Ну уж не знаю точно. Но 274 магазина в Москве о чем-то да говорят.
Понятно. Просто деталь из примера без особых изысков, сразу возникает вопрос, а что бы ее не отпечатать.
Я правильно вас понял, что 3D печать не дает вам нужной производительности, и детали требуют после нее доработки? Поэтому литье?
Честно говоря, не думаю что это что-то да значит. Я вот никогда не видел java разработчиков, пользующихся VS Code. Это конечно не значит, что их нет, но когда лет за 10 (ну или сколько там лет VS Code) не видел ни одного - наводит на мысли. Eclipse видел, NetBeans видел (не часто), VS Code - никогда.
Ну я не ставлю под сомнение, что они влияют, я скорее про всеобщность. Вот я прямо щас искал себе шлифовальную машинку, где конкурентом маркетплейсов является все тот же ВсеИнструменты (и есть еще куча сайтов только тех, что я знаю и помню). И что я вам скажу - одна и та же модель на ВсеИнструменты стоит 15 тыс примерно, а на маркетплейсе - от 18 до бесконечности, в зависимости от жадности. И у меня есть полное впечатление, что все те 20 продавцов, которые ее предлагают на маркетплейсе, все берут ее в одном месте. У того же специализированного сайта.