Таблица сравнений не актуальна для версии монги 3.2. относительно Ограничения данных или Объединения данных. Появились частичные индексы и LeftJoin.
Плюс я бы выпилил такие оценочные строки как «Мощный язык запросов» и т.д.
Так почему же он будет лидировать? В статье описано, что он УЖЕ по какой то причине набрал популярность, но я не понял причины этой популярности и почему они не изменяться в следующие 10 лет?
О да. И кстати, видел люки формы треугольника Рело, в Испании вроде.
Хотя, думаю, то что люк не проваливается — не главная причина. Я бы предположил, что при равной площади сечения проще лезть в круглую шахту.
Это просто картинка правильного пятиугольника с подписями к секущим, взятая в интернете.
В данном случае пятиугольник для каких то целей вписали в окружность. Не отвлекайтесь на мелочи )
Понятно, что люк и колодец одинакового сечения, где люк незначительно больше колодца. Вам нужно понять, можно ли плоский многоугольник, как-то развернув в пространстве, просунуть через отверстие, равное этому многоугольнику.
Теперь посмотрите на рисунок и на секущие KL и KD.
Ок, Вас понял, спасибо. По пятиугольнику: KL < KD. Пятиугольник можно повернуть так, что его высота = KL, тогда он сможет провалиться между двумя вершинами KD.
Это несложно доказать в общем случае отдельно для четных и нечетных правильных многоугольников, чуть сложнее для любого выпуклого многоугольника.
Интересный проект! Интересуюсь, есть ли еще кто то из видео-хостеров, кто так же использует одновременно несколько источников в плеере? Глянул на ютуб — очевидно, что они довольно умно динамически управляют подкачкой, но, видимо, все кусочки тянутся с одного сервера, выбранного при первоначальной загрузке страницы. Есть ли какие то технологические подводные камни такого склеивания?
Умеете ли динамически управлять качеством потока, снижать его при низких скоростях?
Кстати, неужели проблемы с битторрентом оказались не решаемые? Вроде бы протокол специально разработан для похожих задач и видел открытые проекты с его реализацией на клиенте.
Во, вот этот вопрос мы и решили, посчитав долгоживущие задачи антипатерном. Если есть большая задача, то в ней делаем подзадачи, а на саму задачу заводим ветку.
кстати, у вас к комментам задачи добавляется связь с коммитом репозитория?
В жире есть вкладка — коммиты по задаче. Про это? Коммит связываем просто с задачей, не с комментарием к ней. Может и было бы иногда удобно но в 99% случаев хватает номера задачи.
По условной компиляции: у нас бы завели задачу и сделали бы один коммит по одной задаче. Тогда у другого разработчика не возникло бы вопросов о том, зачем убрали одни атрибуты и добавили другие. Сейчас для этого требуется Ваше пояснение.
Впрочем, действительно, у нас тоже есть ИНОГДА коммиты с задачей и поясняющим текстом. И некоторые коммиты без задач: мердж, stylecop, мелкий рефакторинг для fxcop. Вопрос размера рефакторинга, который можно сделать без задачи — на усмотрение разработчика, до тех пор, пока не будет рецедива )
Отличия, видимо, лишь в описании коммита в дополнении к номеру задачи? Если так, то это Вам лишь кажется ) Одно из достоинств нашей команды (она же головная боль) — это отсутствие авторитетов в построении процесса разработки.
Каждое действие должно нести пользу и в этом еще нужно УБЕДИТЬ. Вот например, выше я интересовался преимуществом GitWorkFlow по сравнению с нашим именно потому, что когда то первоначально ввел именно его, а потом не смог найти его преимущества перед схемой ветка = версия.
Соответственно, чтобы начать писать кроме номера задачи комментарии, разработчиков нужно убедить, что это им полезно. А обязательность текста комментария мы убрали именно потому, что посчитали его в наших проектах бесполезным.
Переход на задачу — в один клик по номеру задачи. А комменты вроде:
«refactoring: убрать директивы условной компиляции Indep и AladdinSupport»
Как вы такое получаете?! Что мы делаем не так, что у нас такого нет?! )
Может действительно что то в Hg или отсутствии git workflow приводит к тому, что нет таких ситуаций?
По моему не раскрыта главная причина использования — LINQ. Новый оператор позволяет делать читаемые запросы к модели, в которой обоснованно используются null.
Меня не пугает, жить не мешает. В том редком случае, когда нужен именно аудит изменений — тот факт что история без правок только помогает разобраться. Такого не бывает. Послушав доводы и изучив за эти пару дней материалы лично мне кажется, что скрипач rebase — не нужен )
На 30 тыс коммитов примерно 11 тыс. задач в багтрекере. Т.е. примерно по 3 коммита на задачу, включая: мерджи, коммиты по тестам, по метрикам кода и stylecop. Много это или мало — смотрите сами.
А по истории трудно сказать. Процессов разработки, в которых мне бы нужно было полазить по графу мерджей больше одной итерации назад — действительно нет.
Типовые вопросы по истории: понять когда и кем была сделана фича по номеру задачи, с какой версии она появилась, история изменения участка кода, список изменений между поставками. Все эти вопросы решаются без графа. Т.е. у меня просто нет необходимости читать описания «забыл запятую». Значит ли это, что мне не нужна история?
Справедливости ради замечу, что вот у нас самый крупный непрерывный проект — 5 лет с 30 тыс коммитов. И у нас нет необходимости в красивой истории. Просто нет таких процессов в разработке, где нужно открыть дерево истории глубже чем на пару итераций и рассматривать его.
Хотя, допускаю, что если бы мы захотели красиво распечатать пятилетнее дерево коммитов в виде обоев на стену, то там бы ничего понятного бы не было.
Ок, понял. На всякий случай уточню: в git ведь не обязательно для актуализации с мастером (при длительной разработке) делать ребэйсы? Просто можно время от времени смерживать актуальные изменения?
Ок, идею понял. Красота, плюс если нужно откатить, то вот он — один коммит. С другой стороны, объединение коммитов и откат нескольких мне кажется задачей одной сложности. Почему бы тогда не проводить ее именно когда нужно откатить, а не каждый раз? Откатывают то 1 из 100. Получается, остается только красота и магическая «работа с историей»?
Кстати, мне тоже не совсем понятно, зачем нужна красивая история. Проблемы иногда добавляет а какие решает? Можете привести один-два примера?
Вот разработчик по одной задаче вместо одного коммита напихал десять штук, да еще отдавал их в три захода, между которыми успели вклиниться другие. В какой практической задаче у меня возникнет необходимость разбираться в этой лапше?
Поиск автора строки в коде — нет. История изменения файла — нет. Поиск плохого изменения — бисект.
Плюс я бы выпилил такие оценочные строки как «Мощный язык запросов» и т.д.
Хотя, думаю, то что люк не проваливается — не главная причина. Я бы предположил, что при равной площади сечения проще лезть в круглую шахту.
В данном случае пятиугольник для каких то целей вписали в окружность. Не отвлекайтесь на мелочи )
Понятно, что люк и колодец одинакового сечения, где люк незначительно больше колодца. Вам нужно понять, можно ли плоский многоугольник, как-то развернув в пространстве, просунуть через отверстие, равное этому многоугольнику.
Теперь посмотрите на рисунок и на секущие KL и KD.
Это несложно доказать в общем случае отдельно для четных и нечетных правильных многоугольников, чуть сложнее для любого выпуклого многоугольника.
Умеете ли динамически управлять качеством потока, снижать его при низких скоростях?
Кстати, неужели проблемы с битторрентом оказались не решаемые? Вроде бы протокол специально разработан для похожих задач и видел открытые проекты с его реализацией на клиенте.
Во, вот этот вопрос мы и решили, посчитав долгоживущие задачи антипатерном. Если есть большая задача, то в ней делаем подзадачи, а на саму задачу заводим ветку.
В жире есть вкладка — коммиты по задаче. Про это? Коммит связываем просто с задачей, не с комментарием к ней. Может и было бы иногда удобно но в 99% случаев хватает номера задачи.
По условной компиляции: у нас бы завели задачу и сделали бы один коммит по одной задаче. Тогда у другого разработчика не возникло бы вопросов о том, зачем убрали одни атрибуты и добавили другие. Сейчас для этого требуется Ваше пояснение.
Впрочем, действительно, у нас тоже есть ИНОГДА коммиты с задачей и поясняющим текстом. И некоторые коммиты без задач: мердж, stylecop, мелкий рефакторинг для fxcop. Вопрос размера рефакторинга, который можно сделать без задачи — на усмотрение разработчика, до тех пор, пока не будет рецедива )
Каждое действие должно нести пользу и в этом еще нужно УБЕДИТЬ. Вот например, выше я интересовался преимуществом GitWorkFlow по сравнению с нашим именно потому, что когда то первоначально ввел именно его, а потом не смог найти его преимущества перед схемой ветка = версия.
Соответственно, чтобы начать писать кроме номера задачи комментарии, разработчиков нужно убедить, что это им полезно. А обязательность текста комментария мы убрали именно потому, что посчитали его в наших проектах бесполезным.
Переход на задачу — в один клик по номеру задачи. А комменты вроде:
и так очевидны из диффа.
Может действительно что то в Hg или отсутствии git workflow приводит к тому, что нет таких ситуаций?
Бывает, видел у нас ну 7-8 веток. Но 33!
Меня не пугает, жить не мешает. В том редком случае, когда нужен именно аудит изменений — тот факт что история без правок только помогает разобраться. Такого не бывает. Послушав доводы и изучив за эти пару дней материалы лично мне кажется, что
скрипачrebase — не нужен )А по истории трудно сказать. Процессов разработки, в которых мне бы нужно было полазить по графу мерджей больше одной итерации назад — действительно нет.
Типовые вопросы по истории: понять когда и кем была сделана фича по номеру задачи, с какой версии она появилась, история изменения участка кода, список изменений между поставками. Все эти вопросы решаются без графа. Т.е. у меня просто нет необходимости читать описания «забыл запятую». Значит ли это, что мне не нужна история?
Хотя, допускаю, что если бы мы захотели красиво распечатать пятилетнее дерево коммитов в виде обоев на стену, то там бы ничего понятного бы не было.
Вот разработчик по одной задаче вместо одного коммита напихал десять штук, да еще отдавал их в три захода, между которыми успели вклиниться другие. В какой практической задаче у меня возникнет необходимость разбираться в этой лапше?
Поиск автора строки в коде — нет. История изменения файла — нет. Поиск плохого изменения — бисект.