Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Continuous Delivery/Deployment, слыхал про такое?
Ага, еще Continuos Integration забыл упомянуть.
И еще кучу аббревиатур.
Опять вопрос поставлен так, что ты уникальный, а собеседник даже не слышал.
Мне опять приходится "оправдываться".
ОК.
Бывали ситуации, когда по какому-то продукту и каждый день шли релизы, бывали и два раза в день.
Из-за просьб клиентов, ес-но.
Протокол любой биржи — это бесконечной толщины талмуд (талмудов много разных, речь о сугубо протокольном), можно подписываться на разные сигналы, пользоваться разными наборами транзакций, по каждому направлению доступна разная степень глубины подробности получаемой информации.
Сам протокол сложный, на этом и живём.
От нас клиент получает уже удобную либу с простыми "connect", "subscribe" и т.д.
Всё это не на пустом месте — есть мощный сетевой фреймворк, дающий лучшие или практически лучшие показатели по отрасли (1-2-е места в мире в разных дисциплинах).
Клиент, по классике, не всегда заранее достоверно знает, что ему нужно, т.е. сам это обнаруживает только в процессе окучивания конкретной биржи.
Ну и, начинается классическое "а это можете?", "еще такое-то сделаете?".
Изначально-то ему выгоднее заказать как можно меньшую конфигурацию, чтобы банально меньше платить.
Настолько частые релизы это скорее исключение, чем правило, но показывает саму способность работать в том числе в таком режиме.
Степень требуемой надёжности даваемого клиенту кода можешь себе представить.
Еще не софт по управлению ядерным реактором, но уже ближе туда, чем к классическим "формочкам".
На любую не окученную ранее биржу вот так с наскока не выскочишь, ес-но, должна быть некая стадия подготовки к такому этапу, разумеется.
Стадия сама по себе комплексная и подозрительно напоминающая класические стадии процессов проектирования.
А я опять "оправдываюсь", вместо того, чтобы заниматься чем-то полезным, например — отделить мух от котлет, например отделить от схемы процесса его динамику — выравнивание нагрузки: "не пинать балду и не аврал" (С). Это вопросы точности оценки трудоёмкости работ и соответствующего планирования ресурсов.
Тема отдельная и тоже, кстате, хорошо отличает кустарщину от некустарщины. Бо именно для целей улучшения оценок трудоёмкости классические "процессы", включая гостовские, содержат кое-какие важные этапы. И если контора делает/развивает сразу более одного проекта, где проекты могут быть на разных этапах или если речь о разных частях одного большого мега-проекта, то всегда есть возможность управлять ресурсами относительно гибко.
НС>А теперь расскажи нам, как студент на практике может познакомится с CD и всем что для этого нужно?
Когда совмещаешь разные части комплексной системы, то получается как с тем клиентом.
Только "релизы" могут идти не два раза в сутки, а малость чаще.
И опять, это скорее исключение, чем правило, но должна быть и такая способность.
Т.е. разработчик знакомится с самим фактом непрерывного уточнения/расширения требований, которые всегда происходят в сложной разработке.
Собсно, разработка чего-то сложнее GUI калькулятора ведётся именно так.
Итерации всегда всегда привязаны к срокам, ес-но, для всех уровней задействованных, от руководителей разных мастей до всех разработчиков.
Но при этом требуется в том числе гибкость/оперативность, умение быстро "проехать" некоторый затык.
Я же писал — разница лишь в том, кто является источником требований и что из себя представляет контроллирующий орган.
Этот орган не обязан быть одушевлённым для некоторого уровня итераций.
Чем сложнее проект, тем больше вложенность итераций.
НС>Или нафига был бы CD в ваших экзерсисах с датчиками, кораблями и коробкой пиков?
Если ты заметил, в последние лет 15 цикл выпуска железок заметно сократился от того, что было ранее и продолжает сокращаться.
Минимальный объем окупаемых партий тоже заметно сокращается.
Уже десяток тех же платок заказать — они по себестоимости получаются меньше, чем когда-то заказывал партию из десяток тысяч их.
Из-за чего, как сам думаешь?
Датчиков уже было третье поколение, если что.
Про транкинговую связь — это вообще были сплошные итерации.
Ну и уже тогда классика жанра, когда чуть ли не половина железа уехала в пики, т.е. в софт, т.е. обновляли клиентам лишь прошивки (не на месте, ес-но, просто заменяли коробки на идентичне перепрошитые).
конструктивно отдельным модулем шел лишь радиоканал, но там степень связности, как сам понимаешь, минимальная во всём проекте.
Для рекламных бегущие огней был разработан полный эмулятор на PC, где можно было "играть" с алгоритмами, на выходе готовая таблица для прошивки в пик.
Для чего, как сам думаешь?
Почему бы просто "не сесть и сразу не начать писать код прямо на пик"?
Ну мы же, типа, неопытные студенты, должны были поступать как положено неопытным студентам как минимум год после ВУЗ-а!
И ни дня меньше!
(вот реально ваши аргументы — сплошной какой-то сюррр)
НС>И это лишь один из маленьких кирпичиков, и их таких много.
Ну, не так уж самих аспектов много, порядка десятка.
Просто сами они составные, например, описание общей схемы процесса или методики оценки трудоёмкости.
Но я уже говорил — для записи в кустарщину достаточно отсутствие буквально единиц этих кирпичиков или превращение кирпичиков в неполноценные.
НС>Чтобы понять всю специфику эволюции коммерческих продуктов, надо непосредственно и достаточно длительный срок во всем этом поварится, не просто тупо зазубрить модные слова, но на своей жопе прочувствовать нафига оно вообще нужно и почему без этого хуже.
Т.е. у меня нет шансов увести происходящие здесь рассуждения от вопроса уникальности и степени чувствительности жоп?
Коллеги, возьмите уже себя в руки. ))
Если бы человечество отказалось от передачи знаний друг другу и каждый человек познавал мир самостоятельно, мы бы до сих пор жили в каменном веке.
В той самой кустарщине.
НС>Еще раз — дело не в том что вы не из того мяса сделаны, а в том что перед вами просто цели другие.
Цель — это тоже важный аспект.
Как думаешь, что есть проектирование как таковое?
Ну вот давай, своими словами.
Тем более, что подсказка "цель" уже прозвучала.
НС>Разработка под одного заказчика — да ради бога, я сам в таком участвовал.
1. Откуда ты взял "одного заказчика"?
2. Cформулированое таким образом опять выдаёт непонимание роли источника требований.
НС>Но это никак не гарантирует, что та же команда умеет выпускать коробку или SaaS-продукт.
Это зависит не от самих девелоперов, а как раз от руководителей команды.
Я уже говорил — каждый разработчик, может и работает "почти промышленно", но сама организация процесса — "на ощупь", кустарная.
То бишь виноваты ответственные люди, организующие такую разработку, которые НЕ знают, что им надо делать.
Просто берут чьи-то удачные практики и используют их у себя.
Или раньше брали и получали более-менее удачное "попадание" в свою специфику (а специфик дофига, ес-но).
Мода на различные такие практики — тоже девка капризная.
А откуда эти практики появились, почему именно так — сплошное ХЗ.
Вместо того, чтобы разобраться с вопросом, смотрю, строишь у себя в голове некоторые "модели" на основе ж-пы, объясняющие "вот тут много заказчиков, а вот тут continuos" и т.д.
Вопрос на миллиард:
а как вообще умудряются жить такие конторы, которые выпускают и коробочный продукт и регулярно его же обновляют по требованиям, в том числе "самых важных заказчиков"?
Пока что всё, что ты говорил, сводится к тому, что это противоречивые кейзы, т.е. одни и те же люди НЕ МОГУТ этим заниматься, бо это РАЗНЫЕ НАВЫКИ.
Более того, согласно заветам IB, разработчикам и вовсе КАЖДЫЙ РАЗ требуется переучиваться для СМЕНЫ характера работы.
Ты хорошо понимаешь, куда ведут ваши рассуждения? ))
V>>Я говорил лишь, что конкретно ты не системотехник по образованию. НС>Ну а конкретно у меня в дипломе тот самый инженер-системотехник написан.
Я тебе этого и не писал, бо хоть я с вами лично еще и не общался (чем, по твоей версии, перед вами виновен), но не вчера ж родился и по переписке тут не первый год.
Конкретно у тебя я вижу заметный перекос твоих интересов.
Вряд ли ошибусь, если предположу, что такой "перекос" был всегда, еще с ВУЗ-а.
Т.е. когда одни предметы гораздо интереснее других.
Не прими за наезд, я ведь достоверно знать не могу, но такие студенты обычно склонны к забиванию на малоинтересные им предметы.
(отвечать не обязательно, можешь у себя там где-то просто "галочку" поставить про сумасшедшего vdimas-а, хы-хы)
Один маленький пример.
У моих киевских друзей сын учится в Европе примерно на нашу специальность.
3-й курс, по весне обратился ко мне за помощью.
У них там самостоятельная на ардуино, ему по варианту задача игра-угадайка.
5 кнопок, графический индикатор и несколько цветных светодиодов-индикаторов.
Игра выводит приглашение, по спецификации по нажатию отдельной кнопки начинает игру, загадывает число.
Играющий должен отгадывать это число, через нажатия кнопок прокручивает соотв. разряды числа, отображаемые на индикаторе.
После каждого шага игра показывает, сколько всего правильных цифр и сколько стоят на своих местах.
Он собсрал макет, уже несколько дней потратил, но не может отладить программу.
Там простой С.
Говорит, потратил 50 евро, а всё зря. ))
Как думаешь, в чём заключалась моя помощь?
Я ему предложил написать консольный эмулятор его стенда.
Кнопки F1-F5, область на экране для индикатора, область для цветных квадратиков-"светодиодов".
Это всё.
За ~3 часа он написал такой эмулятор.
Я у себя тоже накатал такой эмулятор буквально за 20 мин и тоже привёл его алгоритм к работающему виду, но об этом не упоминал, ес-но.
Просто хотел оценить, насколько там всё плохо или наоборот.
Выдал ему пару рекомендаций, как разбить его код на составляющие — семейство независимых ф-ий со своими спецификациями, каждую из которых легко отладить.
Потом примерно за час (после написания эмулятора) парень справился со всем остальным — отрефакторил целевой код согласно моим советам, отладил тело "игры".
После этого оно сходу заработало на ардуинке.
Парень был в натуральном обалдении и счастлив, на радостях слал фоты и видео работающего макета, сплошной поток эмоций.
Это была первая "железка" в его жизни. ))
В общем, работа в коллективе — это, в том числе, передача опыта от более опытных к менее.
Это знакомство с тем, как решаются те или иные задачи, как преодолеваются всякие "затыки".
Всего на одной такой ерунде у него случилось два важных урока.
Увы, в его ВУЗ-е работающих, т.е. ведущих реальные разработки, железно-софтовых лабораторий нет.
Это к качеству европейского образования.
Здравствуйте, vdimas, Вы писали:
НС>>Continuous Delivery/Deployment, слыхал про такое? V>Ага, еще Continuos Integration забыл упомянуть.
CI, слава богу, добрался и до полукустарных команд, благо бесплатных сервисов в сети навалом.
V>И еще кучу аббревиатур.
По делу есть что сказать?
V>Опять вопрос поставлен так, что ты уникальный
Прекращай разговаривать с голосами в своей голове.
V>Бывали ситуации, когда по какому-то продукту и каждый день шли релизы, бывали и два раза в день.
Сходи в википедию, почитай про CD. У меня не получилось.
V>Еще не софт по управлению ядерным реактором
О, программисты АЭС живы, да.
V>А я опять "оправдываюсь", вместо того, чтобы заниматься чем-то полезным, например — отделить мух от котлет, например отделить от схемы процесса его динамику — выравнивание нагрузки: "не пинать балду и не аврал" (С). Это вопросы точности оценки трудоёмкости работ и соответствующего планирования ресурсов.
Это просто вопросы. Точнее те самые задачи, которые не всегда имеют место быть. А речь про то как эти задачи решаются.
V>Тема отдельная и тоже, кстате, хорошо отличает кустарщину от некустарщины.
И с чем ты споришь тогда?
НС>>А теперь расскажи нам, как студент на практике может познакомится с CD и всем что для этого нужно? V>Когда совмещаешь разные части комплексной системы, то получается как с тем клиентом. V>Только "релизы" могут идти не два раза в сутки, а малость чаще.
Еще раз, CD это не когда ты заплатки два раза в сутки втыкаешь после сырого релиза, это способность к релизам в любой момент времени без потери качества. А то что после выпуска релиза приходится хотфиксы два раза в день делать, это скорее признак отсутствия CD.
НС>>Или нафига был бы CD в ваших экзерсисах с датчиками, кораблями и коробкой пиков? V>Если ты заметил, в последние лет 15 цикл выпуска железок заметно сократился от того, что было ранее и продолжает сокращаться.
Мы сейчас не про железки вообще.
V>(вот реально ваши аргументы — сплошной какой-то сюррр)
Поэтому я и говорю, что ты даже не понимаешь о чем речь.
НС>>Но это никак не гарантирует, что та же команда умеет выпускать коробку или SaaS-продукт. V>Это зависит не от самих девелоперов, а как раз от руководителей команды.
От самих девелоперов зависит умение в такой команде эффективно работать. Свежие студенты — не умеют, просто в силу отсутствия соотв. опыта.
V>Я уже говорил — каждый разработчик, может и работает "почти промышленно"
Нет, не работает. Не потому что он плохой, а потому что для этого нужна соотв. потребность. Если ее нет, неважно почему, из-за размера команды, вида задачи или рукожопого менеджмента, то и никакой промышленной разработки не будет.
V>Вопрос на миллиард: V>а как вообще умудряются жить такие конторы, которые выпускают и коробочный продукт и регулярно его же обновляют по требованиям, в том числе "самых важных заказчиков"?
Нормально умудряются.
V>Пока что всё, что ты говорил, сводится к тому, что это противоречивые кейзы, т.е. одни и те же люди НЕ МОГУТ этим заниматься, бо это РАЗНЫЕ НАВЫКИ.
Ты опять говоришь с голосами в своей голове. Ловля рыбы и написание софта это тоже разные навыки, что не означает что человек не может заниматься и тем и другим.
V>Более того, согласно заветам IB, разработчикам и вовсе КАЖДЫЙ РАЗ требуется переучиваться для СМЕНЫ характера работы.
Он такого не говорил. Он говорил что если у человека нет определенного опыта, то его нужно учить.
Здравствуйте, elmal, Вы писали:
F>>на мой взгляд, там вопросы были сильно из разных сфер. например, поиск пути из lines я плохо представляю, где ещё можно применить, если рядом есть гиперболический синус и выборки из БД. E>Про гиперболический косинус речь заходит чтобы выяснить есть ли у кандидата хоть какие остаточные знания. И не подойдет ли он на вакансию математика, который еще и может программировать. То есть здесь речь идет не о том чтоб завалить, а чтоб нащупать чем кандитат может усилить команду.
так вам кто нужен?
или вакансий много, подбираете место под человека?
E>А их не нужно помнить и не нужно к собеседованиям готовиться. Лично я смотрю только остаточные знания. То есть если будет проблема, мне интересно, вспомнит ли кандидат ключевые слова, по которым он будет гуглить. Время на собеседование то крайне ограничено, нужно как то за час управиться и без тестовых заданий, рабочего кода на бумажке и всей любимой многими фигни. Если в институте учился, хоть что то должно остаться.
ха-ха. не остаётся ничего, кроме, именно что, ключевых слов.
а как вопрос про плотность распределения вероятностей тут помогает? ты же спрашиваешь именно определение, хотя говоришь про возможность нагуглить.
Здравствуйте, Ночной Смотрящий, Вы писали:
V>>Бывали ситуации, когда по какому-то продукту и каждый день шли релизы, бывали и два раза в день. НС>Сходи в википедию, почитай про CD.
Таки уникальность.
НС>У меня не получилось.
Значит и не надо было (это лучший вариант).
Т.е. навыков таких нет в любом случае.
Зато мы умеем реагировать на срочные "просьбы" клиента, если они технически осуществимы.
За что регулярно получаем благодарственные письма и отзывы в интернетах.
Потому что технологически к этому готовы, ес-но.
V>>Еще не софт по управлению ядерным реактором НС>О, программисты АЭС живы, да.
Я помню этот твой конёк, потому и упомянул.
Еще не АЭС, но уже близко.
V>>А я опять "оправдываюсь", вместо того, чтобы заниматься чем-то полезным, например — отделить мух от котлет, например отделить от схемы процесса его динамику — выравнивание нагрузки: "не пинать балду и не аврал" (С). Это вопросы точности оценки трудоёмкости работ и соответствующего планирования ресурсов. НС>Это просто вопросы. Точнее те самые задачи, которые не всегда имеют место быть. А речь про то как эти задачи решаются.
Как они решаются — это часто пенисометрия из разряда "пойди почитай".
Часто вопрос в том — решаются ли такие задачи вообще всерьёз, или просто навскидку таймлайн расставляется и трекается.
Ну и, по моему опыту, коллеги чаще всего советуют "ознакомиться" ровно с той инфой, с которой сами недавно ознакомились.
Прям напасть, какая-то...
Ну так-то понятно, ес-но, не будет же человек в своём уме предлагать кому-то пройтись по банальностям, это же самоподстава.
V>>Тема отдельная и тоже, кстате, хорошо отличает кустарщину от некустарщины. НС>И с чем ты споришь тогда?
Я не спорю, я пытаюсь превратить твои намёки в нормальные формулировки.
Пытался, вернее.
Надоело.
Когда человек так тщательно бегает, он явно беспокоится за своё реноме.
Такое ощущение, что есть за что беспокоиться, типа можно ненароком уронить.
Скучно...
НС>Еще раз, CD это не когда ты заплатки два раза в сутки втыкаешь после сырого релиза, это способность к релизам в любой момент времени без потери качества.
"Любой момент" — опять слишком обще, не видишь разве оставленного тобой простора для спекуляций?
Вычитку надо делать, прежде чем постить.
Если в данный конкретный момент еще ни одно изменение со времени прошлого релиза не дошло до нужной кондиции и не оказалось в соотв. "линейке" исходника, то этот новый релиз будет копией предыдущего, т.е. бессмысленен.
(и только попытайся включить свою шарманку, мол "ты не понимаешь, что значит в любой момент времени" — прокляну, бо наиболее серьёзно об этом говорили еще во второй половине 90-х, когда стали популярны системы контроля версий, а сейчас "это" само собой подразумеваемое правило хорошего тона, особенно у буржуев)
Поэтому, рассуждать об оперативности, т.е. о конкретных единицах измерения такого "времени", можно и нужно.
Это тоже показатель.
Конкретно мне рассуждать легко, бо на одну мою строку целевого кода будут десятки строк из нескольких тысяч тестов всего, относящихся к "платформе".
Угу, не ядерный реактор, но близко. ))
Надеюсь, ты еще помнишь определение "качества ПО"? ))
Ладно, картина примерно ясна, не смотря на всю беготню.
Пока что светишь кусочно-гладкими представлениями о процессе разработки.
Методологию разработки IT-систем прогуливал.
Выглядит так, что там что-то подсмотрел, тут что-то полезное почитал, здесь какая-то прошлая практика хорошо зашла и т.д.
По твоим репликам, опять же, примерно понятна стадия работ, она тебе и кажется важной, что понятно, потому что такова для нынешней твоей специфики.
Допилить свои представления до процесса, обладающего полнотой, тебе банально облом или вообще кажется разновидностью глупости.
На крайний случай, если надо будет, ты ж подсмотришь, подтянешь, справишься, верно?
Но только если надо будет!
Самое печальное демонстрируемое тобой с IB, почему я собсно зацепился и пытался раскрутить на прямую речь, — это непонимание идентичности процесса, обладающего полнотой, для произвольной вложенности циклов итераций разработки.
Т.е. в том числе для разработки не самого большого модуля в составе более большого, а тот в составе еще более большого и т.д.
Да пофик.
Всё одинаково.
Распределение акцентов и трудоёмкости разное, а схема непременно общая.
V>>Пока что всё, что ты говорил, сводится к тому, что это противоречивые кейзы, т.е. одни и те же люди НЕ МОГУТ этим заниматься, бо это РАЗНЫЕ НАВЫКИ. НС>Ты опять говоришь с голосами в своей голове.
Я отвечаю на прямые тезисы Ивана, которому ты плюсовал в этом споре.
Т.е. ты с ним в целом согласен.
НС>Ловля рыбы и написание софта это тоже разные навыки, что не означает что человек не может заниматься и тем и другим.
И даже это с натяжкой, бо если уж ударяться в аналогии, то ловля рыбы ручной сетью и рыбацкой шхуной — немного разные навыки, казалось бы.
Однако, пласт знаний конкретно о ловле сетью фактически идентичный.
А если еще и рыба такая же, т.е. когда св-ва и повадки её хорошо известны — тем более. ))
А вот удочкой, типа кустарщина...
Ан нет! ))
Есть такие области, где подходит ловля одновременно сотнями удочек, как ловля тунца, например.
Просто надо подготовить свою шхуну под наиболее эффективную лювлю именно удочками.
Помнишь про "цель"?
Цель управления разработкой — это достижение максимально эффективного использования ресурсов при решении задач с сохранением их кач-ва.
(что такое кач-во ПО?)
Процессы, обладающие полнотой, способны покрыть произвольный масштаб разработки и произвольные условия (есть деньги на дорогой Xilink или нет — не принципиально).
Принципиальны навыки, помогающие в любых конкретных условиях добиться максимальной такой эффективности.
Кустарщина в итоге ведёт к неэффективности при прочих равных, вот, собсно, основная разница.
Было еще желание разобрать процессы на составляющие, но это в другой компании, похоже.
(Я уже понял, что здесь до сути не дойду)
V>>Более того, согласно заветам IB, разработчикам и вовсе КАЖДЫЙ РАЗ требуется переучиваться для СМЕНЫ характера работы. НС>Он такого не говорил. Он говорил что если у человека нет определенного опыта, то его нужно учить.
В моих представлениях я бы еще согласился на "доучивать", ну типа как залить соляру в движок шхуны, завести мотор и рулить. ))
Если не прогуливал в ВУЗ-е, то и вовсе "немного набраться практики", бо вся теория о мореходстве и даже кое-какая практика обязательно была, как и практика ловли ручной сетью.
Но иваново "переучивать" хорошо натягивается на его позицию насчёт принципиальной неполноценности ВУЗ-а.
Ведь конкретно к ВУЗ-у прицепиться сложно, особенно если на нём кафедры ведут реальные разработки.
Должно было быть "что-то еще".
И вот, не успел я заподозрить и озвучить это "что-то" (мне же недолго, ты ж в курсе, я за "реноме" не трясусь), т.е. о том, что просто его общие представления таковы (вопиющие, положа руку на), как он и сам признался.
В этом месте будь я Иваном, я мог бы включить такого профессора над нерадивым студентом... у-у-у. ))
Но так-то опять скучно, на деле просто элемент раздражения за напрасно потерянное время, бо начинали вы за здравие, как грится, что даже малость заинтриговали...
Здравствуйте, vdimas, Вы писали:
V>>>Бывали ситуации, когда по какому-то продукту и каждый день шли релизы, бывали и два раза в день. НС>>Сходи в википедию, почитай про CD. V>Таки уникальность.
Продолжаешь перевирать мои слова? Ну ну.
НС>>У меня не получилось. V>Значит и не надо было (это лучший вариант). V>Т.е. навыков таких нет в любом случае.
У меня не получилось объяснить тебе что это. И, сдается мне, причина не во мне, потому что ты не первый кому я это объяснял, но ты первый, кто не понял. Ну или сделал вид.
V>Я помню этот твой конёк, потому и упомянул.
Это не мой конек, это такая разновидность закона Годвина в программистских тредах.
НС>>Еще раз, CD это не когда ты заплатки два раза в сутки втыкаешь после сырого релиза, это способность к релизам в любой момент времени без потери качества. V>"Любой момент" — опять слишком обще
Ничего общего, все вполне конкретно. Просто ты меня не слышишь и не понимаешь.
V>Если в данный конкретный момент еще ни одно изменение со времени прошлого релиза не дошло до нужной кондиции и не оказалось в соотв. "линейке" исходника, то этот новый релиз будет копией предыдущего, т.е. бессмысленен.
Решил довести до абсурда? CD это готовность конкретное изменение выпустить ровно в тот момент, когда оно будет готово. А ты по прежнему сидишь с вбитым в голову гвоздем про то, что CD это про скорость написания хотфикса, и собеседника не слышишь. От того и кажется все, что не попадает в твой неверный шаблон, непонятным и неправильным.
V>>>Пока что всё, что ты говорил, сводится к тому, что это противоречивые кейзы, т.е. одни и те же люди НЕ МОГУТ этим заниматься, бо это РАЗНЫЕ НАВЫКИ. НС>>Ты опять говоришь с голосами в своей голове. V>Я отвечаю на прямые тезисы Ивана, которому ты плюсовал в этом споре.
Ты сейчас прямо врешь. Перечитай собственную цитату.
Здравствуйте, Ночной Смотрящий, Вы писали:
V>>Если в данный конкретный момент еще ни одно изменение со времени прошлого релиза не дошло до нужной кондиции и не оказалось в соотв. "линейке" исходника, то этот новый релиз будет копией предыдущего, т.е. бессмысленен. НС>Решил довести до абсурда? CD это готовность конкретное изменение выпустить ровно в тот момент, когда оно будет готово.
Подаваемое тобой в исключительной манере — это и есть абсурд.
Мне сложно представить, что должно происходить у человека в голове, чтобы преполагать отсутствие даже хотя бы вот этих банальностей в той области, про которую я уже сказал.
НС>А ты по прежнему сидишь с вбитым в голову гвоздем про то, что CD это про скорость написания хотфикса, и собеседника не слышишь.
Это про возможность выпустить хотфикс относительно сразу.
Я слышу и даже обращал твоё внимание, что сама такая возможность без предварительной подготовки всей инфраструктуры принципиально не возможна.
Похоже, ты не видишь себя со стороны, хотя я уже прохаживался в этом направлении — подавая всю эту тему в таком специфическом ракурсе оно смотрится так, будто всю свою карьеру до последнего места работы был от такой специфики далёк. А потом тебя "торкнуло" на этом последнем месте работы и конкретно этот аспект тебе кажется самым важным.
НС>От того и кажется все, что не попадает в твой неверный шаблон, непонятным и неправильным.
Ты пока слишком далёк от понимания моего "шаблона", чтобы пытаться начать его обсуждать.
Причём, это ваша инициатива — рубить на корню попытки прямого обмена опытом.
Похоже, задача была в чём-то другом.
Вы отнимаете у собеседников время.
V>>>>Пока что всё, что ты говорил, сводится к тому, что это противоречивые кейзы, т.е. одни и те же люди НЕ МОГУТ этим заниматься, бо это РАЗНЫЕ НАВЫКИ. НС>>>Ты опять говоришь с голосами в своей голове. V>>Я отвечаю на прямые тезисы Ивана, которому ты плюсовал в этом споре. НС>Ты сейчас прямо врешь. Перечитай собственную цитату.
Поднимись чуть выше и обрати внимание, что ты отвечаешь здесь в подветке моего общения с Иваном, где именно это и говорилось.
Так шта, если ты не согласен с оставленным тобой процитированным, то это следовало писать ему, а не мне.
Но да, я помню, у вас "личные отношения", поэтому объективность спора будет страдать.
Ваше дело...
