А может мне кто нибудь пояснить необходимость rebase? Чисто для красоты дерева коммитов что ли?!
Под hg есть плагин, видимо, повторяющий функционал из git, но не могу понять, зачем бы мне захотелось переносить изменения вместо слияния?
Так и у нас схема аналогичная, крупные фичи — в ветках. Они отдельно тестируются, потом вливаются в нерелизную ветку (она ровно одна).
При этом, как мне кажется, мы избегаем кучи мерджей, связанных с процессом выпуска версии. Типа исправили баг и вмерджили его сперва исправление в альфу, потом в бету, потом в пререлиз.
Практически единственные мерджи, не связанные с параллельностью разработки — когда находим баги в старых но поддерживаемых ветках. 2-3% всех багов.
Коллеги, а есть кто в ветке, кто сможет мне объяснить, зачем все вообще носятся с этим Git Workflow? После svn последние 6 лет работаем на hg, выпускаем и поддерживаем версии модульного продукта по одной-две версии в год. Поддерживаем 2-3 последних версии.
Так вот, для нас, как мне кажется, гораздо удобней схема — ветка = версия продукта/модуля. Т.е. сперва ветка находится в состоянии разработки, потом в альфе, потом в бете и релизе.
Хотфиксы — внутри ветки. Новая версия — новая ветка. Не поддерживаемые версии — закрываем.
Вообще то да. Например, при массовом выпуске товара подавляющее большинство тестов — выборочные. И в результате вполне корректная статистическая оценка.
Альтернатива стохастическому подходу — 100% протестированный но не кому не нужный продукт в виду его высокой стоимости.
Троллинг чистой воды.
1. До разработки двух версий узнать оценку разницы производительности нельзя, имея на руках любые синтетические тесты.
2. Наличие синтетических тестов позволяет сделать хоть какую то оценку, а вопрос ее достаточности и достоверности каждый принимает сам.
Соответственно, Вы задаете вопрос: с чего 80%?
Вам отвечают: ну вот у меня тесты, я ОЦЕНИВАЮ что будет ПРИМЕРНО так же.
Вы: а что мне эти тесты, они вообще не про мою систему
Думаю, не более чем дань моде. Вкладки — обычный, общепринятый способ структурирования. В емайлах пока не принят, но и в браузерах его когда то не было. Представьте, я застал дискуссии: «нужны ли вкладки в браузере, когда это так неудобно».
У меня есть примеры (см. выше), где я был бы не против получать письма со вкладками.
Смотрите, пример:
СанПиН 2.1.4.1116-02 максимум кальция до 130мг на дм3, при этом чем меньше тем лучше. Т.е. при 3 литрах воды в день из воды со 130мг мы получим примерно 400 мг кальция. Что вроде бы как половина суточной нормы.
Но усваиваемость кальция с еды около 15%. С воды — меньше. Тогда как в молочных продуктах концентрация раз в 10 выше. При обычном питании мы и так получаем избыток кальция, и 60мг кальция из воды (а это — максимум) — ни какой погоды не делают.
Аналогично с натрием и другими солями. Получение с воды по сравнению с едой — микроскопическое. И наоборот, превышение нормы в воде солей вызывает проблемы.
Если есть исследования о том, что очищеная вода хотя бы СПОСОБСТВУЕТ деминерализации — приведите пожалуйста. Пока все данные, до которых я добрался, говорят о том, что модули минерализации — лишь дань фобиям.
Кстати, мощные осмотические (мембранной технологии) системы очистки воды могут существенно снизить содержание этих важных элементов в питьевой воде. Это надо просто учитывать в своём рационе, чтоб потом не случилось неприятностей типа частых переломов костей и быстрого разрушения зубов.
Изучите вопрос, как незаменимые минеральные соли попадают в организм. Доля попадания с водой — микроскопическая. Поэтому осмотическая очистка воды ни к какому разрушению зубов и костей не приводит.
Начал читать статью, сразу попал в место, которое хотел бы уточнить.
Суффиксное дерево для строки s – это минимальное по числу вершин дерево, каждое ребро которого помечено непустой подстрокой s таким образом, что каждый суффикс s[i..n-1] может быть прочитан на пути из корня до какого-нибудь листа и, наоборот, каждая строка, прочитанная на пути из корня до какого-нибудь листа, является суффиксом s.
Так понимаю, для абсолютно любой строки длины N, минимальное количество вершин в суффиксном дереве всегда будет равно N+1. Где все вершины кроме корня являются листьями с соответствующим суффиксом.
Но сразу же после этого определения приводится картинка дерева, где количество вершин явно больше минимального, т.к. есть еще узловые вершины. Где-то не точность: в определении, в иллюстрирующей картинке или в моем понимании.
Смотрите, проблемы в статье не в том, кому нужно или не нужно использовать Excel, а в том, что:
1. Статья не конкретная и не позволяет узнать ничего нового читателю. В основном состоит из фраз: без BI плохо, т.к. нельзя ничего понять, а с BI – хорошо.
Что за BI, чем хорошо, а чем раньше было плохо?
Если хотите прорекламировать какие то системы BI (Вам в корпоративном блоге — можно), так сделайте же это!
2. Хуже того, статья МАСКИРУЕТСЯ под техническую и имеет формат: проблема –> решение в общем виде –> пример из жизни.
Но проблема описана как «все плохо», решение вида «все хорошо», а пример выглядит как «есть компания где было все плохо, а стало все хорошо».
Это вызывает ощущение маркетинга и чувство, что автор не является специалистом (хотя это может быть и не так)
3. И главное, в статье повсюду куски слабоосмысленного текста. Примеры:
Тот же класс систем используется для очистки данных Big Data
Во-первых, никакой класс систем в статье так и не был описан, ни до, ни после. Кроме названия Класс систем BI, ничего сказано так и не было.
Во-вторых, что такое очистка данных Big Data?!!!
нарезание регулярных отчётов
Что такое «нарезание»?
Из примеров этого же класса задач
Вроде бы все ок, но никакой класс задач до этого не был описан
… розница в США любит дополнение клиентских профилей…
… метазадача BI...
А вот этот абзац мог бы быть сгенерирован Яндекс-Весной.
Далее данные загоняются в модель работы предприятия. Классическая методология — та же ССП — была создана ещё в 87-м году, и с тех пор не особо сильно менялась. В смысле, апдейты и форки в ассортименте, но принцип везде похожий. Если коротко, то деятельность компании можно разложить на 4 составляющие: финансовая часть, клиентская часть, кадры и резервы (то есть персонал) и стратегия развития. Даже госпредприятия оцениваются так же, только вместо прибыли там попадание в заданный бюджет.
И т.д. и т.д. и т.д.
Дайте пример хотя бы трех подряд идущих абзацев текста, где бы связанно раскрывалась какая мысль.
Серьезно. Мне кажется, это плохая статья и я не могу понять, откуда у нее 16 плюсов, кроме как от Ваших коллег. Про BI можно и нужно писать лучше.
Ба-а-лин. Маркитинговый текст, замаскированный под технический.
Простой пример: в регионах отчёт собирается руками и отправляется в виде экспорта 1С. Разобраться, что там — настоящий тёмный лес, можно только сказать, хорошо или плохо. А что хорошо и что плохо — надо ехать и копать. Теперь мы даём инструмент для руководителя, чтобы там была вся операционная карта. Он сразу видит по отчётам, где хорошо и где плохо — и где требуется его вмешательство, смотрит весь учётный уровень до самого низа, если пожелает.
Во-первых все такие тексты заменяются на: «были плохие отчеты а мы сделали хорошие.»
Во-вторых реквестую этого самого руководителя и что он скажет о том, на сколько все раньше было плохо и стало хорошо. Не ген.директора, а того самого, что ездил и разбирался в регион, а теперь больше нет.
Еще немного добавлю критического. Все эти неназванные, дорогие и фантастические инструменты бизнес-аналитики можно перечислить так:
1. Обычные отчеты из учетной системы + Excel — 99%.
2. Olap cube и производные с него отчеты и графики — 1% (на демонстрации)
Напомнило заметку в «Челябинском рабочем» от 6 октября 1957 года.
В прошлое воскресенье вечером… многие челябинцы наблюдали особое свечение звёздного неба. Это довольно редкое в наших широтах свечение имело все признаки полярного сияния. Интенсивное красное, временами переходящее в слабо-розовое и светло-голубое свечение вначале охватывало значительную часть юго-западной и северо-восточной поверхности небосклона. Около 11 часов его можно было наблюдать в северо-западном направлении… На фоне неба появлялись сравнительно большие окрашенные области и временами спокойные полосы, имевшие на последней стадии сияния меридиональное направление. Изучение природы полярных сияний, начатое ещё Ломоносовым, продолжается и в наши дни. В современной науке нашла подтверждение основная мысль Ломоносова, что полярное сияние возникает в верхних слоях атмосферы в результате электрических разрядов.… Полярные сияния… можно будет наблюдать и в дальнейшем на широтах Южного Урала
Мне кажется, есть четыре проблемы:
1. Есть коллективная ответственность с багами. Должно снижать мотивацию.
2. Есть личная ответственность с багами. Весь мой опыт говорит мне о том, что продуктивность падает в разы. Это как пройтись по бревну на земле и поднятым на высоту 100 метров. Как только возрастает ответственность за ошибку, то скорость РАДИКАЛЬНО падает. При этом, частота ошибок и стоимость их исправления — не так уж и значительна.
Т.е. код с учетом исправления багов можно писать значительно дешевле, если не штрафовать разработчиков за баги. А способ понизить стоимсть бага = автоматические тесты + кодревью + парное программирование + Разработчики тестирования + те самые тестировщики.
3. Ни кто не оплатит «Технический долг», т.е. не будет рефакторинга. Формальные правила CodeStyle будут выполняться но код будет ухудшаться.
4. Если уж идет попытка сделать справедливую стоимость оплаты, в зависимости от пользы компании, то к чему Грейды? Если я младший программист и делаю эту задачу так же хорошо как и старший программист — я должен получать столько же.
Встречаете ли Вы у себя эти проблемы? Если да, то как решаете. Если нет, то как избежали?
Под hg есть плагин, видимо, повторяющий функционал из git, но не могу понять, зачем бы мне захотелось переносить изменения вместо слияния?
При этом, как мне кажется, мы избегаем кучи мерджей, связанных с процессом выпуска версии. Типа исправили баг и вмерджили его сперва исправление в альфу, потом в бету, потом в пререлиз.
Практически единственные мерджи, не связанные с параллельностью разработки — когда находим баги в старых но поддерживаемых ветках. 2-3% всех багов.
Так вот, для нас, как мне кажется, гораздо удобней схема — ветка = версия продукта/модуля. Т.е. сперва ветка находится в состоянии разработки, потом в альфе, потом в бете и релизе.
Хотфиксы — внутри ветки. Новая версия — новая ветка. Не поддерживаемые версии — закрываем.
Что мы делаем не так? Какие возможности теряем?
Альтернатива стохастическому подходу — 100% протестированный но не кому не нужный продукт в виду его высокой стоимости.
1. До разработки двух версий узнать оценку разницы производительности нельзя, имея на руках любые синтетические тесты.
2. Наличие синтетических тестов позволяет сделать хоть какую то оценку, а вопрос ее достаточности и достоверности каждый принимает сам.
Соответственно, Вы задаете вопрос: с чего 80%?
Вам отвечают: ну вот у меня тесты, я ОЦЕНИВАЮ что будет ПРИМЕРНО так же.
Вы: а что мне эти тесты, они вообще не про мою систему
У меня есть примеры (см. выше), где я был бы не против получать письма со вкладками.
СанПиН 2.1.4.1116-02 максимум кальция до 130мг на дм3, при этом чем меньше тем лучше. Т.е. при 3 литрах воды в день из воды со 130мг мы получим примерно 400 мг кальция. Что вроде бы как половина суточной нормы.
Но усваиваемость кальция с еды около 15%. С воды — меньше. Тогда как в молочных продуктах концентрация раз в 10 выше. При обычном питании мы и так получаем избыток кальция, и 60мг кальция из воды (а это — максимум) — ни какой погоды не делают.
Аналогично с натрием и другими солями. Получение с воды по сравнению с едой — микроскопическое. И наоборот, превышение нормы в воде солей вызывает проблемы.
Если есть исследования о том, что очищеная вода хотя бы СПОСОБСТВУЕТ деминерализации — приведите пожалуйста. Пока все данные, до которых я добрался, говорят о том, что модули минерализации — лишь дань фобиям.
Изучите вопрос, как незаменимые минеральные соли попадают в организм. Доля попадания с водой — микроскопическая. Поэтому осмотическая очистка воды ни к какому разрушению зубов и костей не приводит.
Так понимаю, для абсолютно любой строки длины N, минимальное количество вершин в суффиксном дереве всегда будет равно N+1. Где все вершины кроме корня являются листьями с соответствующим суффиксом.
Но сразу же после этого определения приводится картинка дерева, где количество вершин явно больше минимального, т.к. есть еще узловые вершины. Где-то не точность: в определении, в иллюстрирующей картинке или в моем понимании.
1. Статья не конкретная и не позволяет узнать ничего нового читателю. В основном состоит из фраз: без BI плохо, т.к. нельзя ничего понять, а с BI – хорошо.
Что за BI, чем хорошо, а чем раньше было плохо?
Если хотите прорекламировать какие то системы BI (Вам в корпоративном блоге — можно), так сделайте же это!
2. Хуже того, статья МАСКИРУЕТСЯ под техническую и имеет формат: проблема –> решение в общем виде –> пример из жизни.
Но проблема описана как «все плохо», решение вида «все хорошо», а пример выглядит как «есть компания где было все плохо, а стало все хорошо».
Это вызывает ощущение маркетинга и чувство, что автор не является специалистом (хотя это может быть и не так)
3. И главное, в статье повсюду куски слабоосмысленного текста. Примеры:
Во-первых, никакой класс систем в статье так и не был описан, ни до, ни после. Кроме названия Класс систем BI, ничего сказано так и не было.
Во-вторых, что такое очистка данных Big Data?!!!
Что такое «нарезание»?
Вроде бы все ок, но никакой класс задач до этого не был описан
А вот этот абзац мог бы быть сгенерирован Яндекс-Весной.
И т.д. и т.д. и т.д.
Дайте пример хотя бы трех подряд идущих абзацев текста, где бы связанно раскрывалась какая мысль.
Серьезно. Мне кажется, это плохая статья и я не могу понять, откуда у нее 16 плюсов, кроме как от Ваших коллег. Про BI можно и нужно писать лучше.
Во-первых все такие тексты заменяются на: «были плохие отчеты а мы сделали хорошие.»
Во-вторых реквестую этого самого руководителя и что он скажет о том, на сколько все раньше было плохо и стало хорошо. Не ген.директора, а того самого, что ездил и разбирался в регион, а теперь больше нет.
Еще немного добавлю критического. Все эти неназванные, дорогие и фантастические инструменты бизнес-аналитики можно перечислить так:
1. Обычные отчеты из учетной системы + Excel — 99%.
2. Olap cube и производные с него отчеты и графики — 1% (на демонстрации)
Используйте любую бэгтрекинговую систему, чтобы ставить задачи тех.писателям. В таких системах есть встроенные функции учета трудозатрат.
Которая вышла… сразу после 29 сентября
1. Есть коллективная ответственность с багами. Должно снижать мотивацию.
2. Есть личная ответственность с багами. Весь мой опыт говорит мне о том, что продуктивность падает в разы. Это как пройтись по бревну на земле и поднятым на высоту 100 метров. Как только возрастает ответственность за ошибку, то скорость РАДИКАЛЬНО падает. При этом, частота ошибок и стоимость их исправления — не так уж и значительна.
Т.е. код с учетом исправления багов можно писать значительно дешевле, если не штрафовать разработчиков за баги. А способ понизить стоимсть бага = автоматические тесты + кодревью + парное программирование + Разработчики тестирования + те самые тестировщики.
3. Ни кто не оплатит «Технический долг», т.е. не будет рефакторинга. Формальные правила CodeStyle будут выполняться но код будет ухудшаться.
4. Если уж идет попытка сделать справедливую стоимость оплаты, в зависимости от пользы компании, то к чему Грейды? Если я младший программист и делаю эту задачу так же хорошо как и старший программист — я должен получать столько же.
Встречаете ли Вы у себя эти проблемы? Если да, то как решаете. Если нет, то как избежали?