Сообщение Re[31]: Элита! от 25.08.2018 11:02
Изменено 25.08.2018 11:04 vdimas
Re[31]: Элита!
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Continuous Delivery/Deployment, слыхал про такое?
Ага, еще Continuos Integration забыл упомянуть.
И еще кучу аббревиатур.
Опять вопрос поставлен так, что ты уникальный, а собеседник даже не слышал.
Мне опять приходится "оправдываться".
ОК.
Бывали ситуации, когда по какому-то продукту и каждый день шли релизы, бывали и два раза в день.
Из-за просьб клиентов, ес-но.
Протокол любой биржи — это бесконечной толщины талмуд (талмудов много разных, речь о сугубо протокольном), можно подписываться на разные сигналы, пользоваться разными наборами транзакций, по каждому направлению доступна разная степень глубины подробности получаемой информации.
Сам протокол сложный, на этом и живём.
От нас клиент получает уже удобную либу с простыми "connect", "subscribe" и т.д.
Всё это не на пустом месте — есть мощный сетевой фреймворк, дающий лучшие или практически лучшие показатели по отрасли (1-2-е места в мире в разных дисциплинах).
Клиент, по классике, не всегда заранее достоверно знает, что ему нужно, т.е. сам это обнаруживает только в процессе окучивания конкретной биржи.
Ну и, начинается классическое "а это можете?", "еще такое-то сделаете?".
Изначально-то ему выгоднее заказать как можно меньшую конфигурацию, чтобы банально меньше платить.
Настолько частые релизы это скорее исключение, чем правило, но показывает саму способность работать в том числе в таком режиме.
Степень требуемой надёжности даваемого клиенту кода можешь себе представить.
Еще не софт по управлению ядерным реактором, но уже ближе туда, чем к классическим "формочкам".
На любую не окученную ранее биржу вот так с наскока не выскочишь, ес-но, должна быть некая стадия подготовки к такому этапу, разумеется.
Стадия сама по себе комплексная и подозрительно напоминающая класические стадии процессов проектирования.
Я опять "оправдываюсь", вместо того, чтобы заниматься чем-то полезным, например — отделить мух от котлет, например отделить от схемы процесса его динамику — выравнивание нагрузки: "не пинать балду и не аврал" (С). Это вопросы точности оценки трудоёмкости работ и соответствующего планирования ресурсов.
Тема тоже отдельная и тоже, кстате, хорошо отличает кустарщину от некустарщины. Бо именно для целей улучшения оценок трудоёмкости классические "процессы", включая гостовские, содержат кое-какие важные этапы. И если контора делает/развивает сразу более одного проекта, где проекты могут быть на разных этапах или если речь о разных частях одного большого мега-проекта, то всегда есть возможность управлять ресурсами относительно гибко.
НС>А теперь расскажи нам, как студент на практике может познакомится с CD и всем что для этого нужно?
Когда совмещаешь разные части комплексной системы, то получается как с тем клиентом.
Только "релизы" могут идти не два раза в сутки, а малость чаще.
И опять, это скорее исключение, чем правило, но должна быть и такая способность.
Т.е. разработчик знакомится с самим фактом непрерывного уточнения/расширения требований, которые всегда происходят в сложной разработке.
Собсно, разработка чего-то сложнее GUI калькулятора ведётся именно так.
Итерации всегда всегда привязаны к срокам, ес-но, для всех уровней задействованных, от руководителей разных мастей до всех разработчиков.
Но при этом требуется в том числе гибкость/оперативность, умение быстро "проехать" некоторый затык.
Я же писал — разница лишь в том, кто является источником требований и что из себя представляет контроллирующий орган.
Этот орган не обязан быть одушевлённым для некоторого уровня итераций.
Чем сложнее проект, тем больше вложенность итераций.
НС>Или нафига был бы CD в ваших экзерсисах с датчиками, кораблями и коробкой пиков?
Если ты заметил, в последние лет 15 цикл выпуска железок заметно сократился от того, что было ранее и продолжает сокращаться.
Минимальный объем окупаемых партий тоже заметно сокращается.
Уже десяток тех же платок заказать — они по себестоимости получаются меньше, чем когда-то заказывал партию из десяток тысяч их.
Из-за чего, как сам думаешь?
Датчиков уже было третье поколение, если что.
Про транкинговую связь — это вообще были сплошные итерации.
Ну и уже тогда классика жанра, когда чуть ли не половина железа уехала в пики, т.е. в софт, т.е. обновляли клиентам лишь прошивки (не на месте, ес-но, просто заменяли на идентичне перепрошитые).
конструктивно отдельным модулем шел лишь радиоканал, но там степень связности, как сам понимаешь, минимальная во всём проекте.
Для рекламные бегущие огней был разработан полный эмулятор на PC, где можно было "играть" с алгоритмами, на выходе готовая таблица для прошивки в пик.
Для чего, как сам думаешь?
Почему бы просто "не сесть и сразу не начать писать код прямо на пик"?
Ну мы же, типа, неопытные студенты, должны были поступать как положено неопытным студентам как минимум год после ВУЗ-а!
И ни дня меньше!
(вот реально ваши аргументы — сплошной какой-то сюррр)
НС>И это лишь один из маленьких кирпичиков, и их таких много.
Ну, не так уж самих аспектов много, порядка десятка.
Просто сами они составные, например, описание общей схемы процесса или методики оценки трудоёмкости.
Но я уже говорил — для записи в кустарщину достаточно отсутствие буквально единиц этих кирпичиков или превращение кирпичиков в неполноценные.
НС>Чтобы понять всю специфику эволюции коммерческих продуктов, надо непосредственно и достаточно длительный срок во всем этом поварится, не просто тупо зазубрить модные слова, но на своей жопе прочувствовать нафига оно вообще нужно и почему без этого хуже.
Т.е. у меня нет шансов увести происходящие здесь рассуждения от вопроса уникальности и степени чувствительности жоп?
Коллеги, возьмите уже себя в руки. ))
Если бы человечество отказалось от передачи знаний друг другу и каждый человек позавал мир самостоятельно, мы бы до сих пор жили в каменном веке.
В той самой кустарщине.
НС>Еще раз — дело не в том что вы не из того мяса сделаны, а в том что перед вами просто цели другие.
Цель — это тоже важный аспект.
Как думаешь, что есть проектирование как таковое?
Ну вот давай, своими словами.
Тем более, что подсказка "цель" уже прозвучала.
НС>Разработка под одного заказчика — да ради бога, я сам в таком участвовал.
1. Откуда ты взял "одного заказчика"?
2. Cформулированое таким образом опять выдаёт непонимание роли источника требований.
НС>Но это никак не гарантирует, что та же команда умеет выпускать коробку или SaaS-продукт.
Это зависит не от самих девелоперов, а как раз от руководителей команды.
Я уже говорил — каждый разработчик, может и работает "почти промышленно", но сама организация процесса — "на ощупь", кустарная.
То бишь виноваты ответственные люди, организующие такую разработку, которые НЕ знают, что им надо делать.
Просто берут чьи-то удачные практики и используют их у себя.
Или раньше брали и получали более-менее удачное "попадание" в свою специфику (а специфик дофига, ес-но).
Мода на различные такие практики — тоже девка капризная.
А откуда эти практики появились, почему именно так — сплошное ХЗ.
Вместо того, чтобы разобраться с вопросом, смотрю, строишь у себя в голове некоторые "модели" на основе ж-пы, объясняющие "вот тут много заказчиков, а вот тут continuos" и т.д.
Вопрос на миллиард:
а как вообще умудряются жить такие конторы, которые выпускают и коробочный продукт и регулярно его же обновляют по требованиям, в том числе "самых важных заказчиков"?
Пока что всё, что ты говорил, сводится к тому, что это противоречивые кейзы, т.е. одни и те же люди НЕ МОГУТ этим заниматься, бо это РАЗНЫЕ НАВЫКИ.
Более того, согласно заветам IB, разработчикам и вовсе КАЖДЫЙ РАЗ требуется переучиваться для СМЕНЫ характера работы.
Ты хорошо понимаешь, куда ведут ваши рассуждения? ))
V>>Я говорил лишь, что конкретно ты не системотехник по образованию.
НС>Ну а конкретно у меня в дипломе тот самый инженер-системотехник написан.
Я тебе этого и не писал, бо хоть я с вами лично еще и не общался (чем, по твоей версии, перед вами виновен), но не вчера ж родился и по переписке тут не первый год.
Конкретно у тебя я вижу заметный перекос твоих интересов.
Вряд ли ошибусь, если предположу, что такой "перекос" был всегда, еще с ВУЗ-а.
Т.е. когда одни предметы гораздо интереснее других.
Не прими за наезд, я ведь достоверно знать не могу, но такие студенты обычно склонны к забиванию на малоинтересные им предметы.
(отвечать не обязательно, можешь у себя там где-то просто "галочку" поставить про сумасшедшего vdimas-а, хы-хы)
НС>Continuous Delivery/Deployment, слыхал про такое?
Ага, еще Continuos Integration забыл упомянуть.
И еще кучу аббревиатур.
Опять вопрос поставлен так, что ты уникальный, а собеседник даже не слышал.
Мне опять приходится "оправдываться".
ОК.
Бывали ситуации, когда по какому-то продукту и каждый день шли релизы, бывали и два раза в день.
Из-за просьб клиентов, ес-но.
Протокол любой биржи — это бесконечной толщины талмуд (талмудов много разных, речь о сугубо протокольном), можно подписываться на разные сигналы, пользоваться разными наборами транзакций, по каждому направлению доступна разная степень глубины подробности получаемой информации.
Сам протокол сложный, на этом и живём.
От нас клиент получает уже удобную либу с простыми "connect", "subscribe" и т.д.
Всё это не на пустом месте — есть мощный сетевой фреймворк, дающий лучшие или практически лучшие показатели по отрасли (1-2-е места в мире в разных дисциплинах).
Клиент, по классике, не всегда заранее достоверно знает, что ему нужно, т.е. сам это обнаруживает только в процессе окучивания конкретной биржи.
Ну и, начинается классическое "а это можете?", "еще такое-то сделаете?".
Изначально-то ему выгоднее заказать как можно меньшую конфигурацию, чтобы банально меньше платить.
Настолько частые релизы это скорее исключение, чем правило, но показывает саму способность работать в том числе в таком режиме.
Степень требуемой надёжности даваемого клиенту кода можешь себе представить.
Еще не софт по управлению ядерным реактором, но уже ближе туда, чем к классическим "формочкам".
На любую не окученную ранее биржу вот так с наскока не выскочишь, ес-но, должна быть некая стадия подготовки к такому этапу, разумеется.
Стадия сама по себе комплексная и подозрительно напоминающая класические стадии процессов проектирования.
Я опять "оправдываюсь", вместо того, чтобы заниматься чем-то полезным, например — отделить мух от котлет, например отделить от схемы процесса его динамику — выравнивание нагрузки: "не пинать балду и не аврал" (С). Это вопросы точности оценки трудоёмкости работ и соответствующего планирования ресурсов.
Тема тоже отдельная и тоже, кстате, хорошо отличает кустарщину от некустарщины. Бо именно для целей улучшения оценок трудоёмкости классические "процессы", включая гостовские, содержат кое-какие важные этапы. И если контора делает/развивает сразу более одного проекта, где проекты могут быть на разных этапах или если речь о разных частях одного большого мега-проекта, то всегда есть возможность управлять ресурсами относительно гибко.
НС>А теперь расскажи нам, как студент на практике может познакомится с CD и всем что для этого нужно?
Когда совмещаешь разные части комплексной системы, то получается как с тем клиентом.
Только "релизы" могут идти не два раза в сутки, а малость чаще.
И опять, это скорее исключение, чем правило, но должна быть и такая способность.
Т.е. разработчик знакомится с самим фактом непрерывного уточнения/расширения требований, которые всегда происходят в сложной разработке.
Собсно, разработка чего-то сложнее GUI калькулятора ведётся именно так.
Итерации всегда всегда привязаны к срокам, ес-но, для всех уровней задействованных, от руководителей разных мастей до всех разработчиков.
Но при этом требуется в том числе гибкость/оперативность, умение быстро "проехать" некоторый затык.
Я же писал — разница лишь в том, кто является источником требований и что из себя представляет контроллирующий орган.
Этот орган не обязан быть одушевлённым для некоторого уровня итераций.
Чем сложнее проект, тем больше вложенность итераций.
НС>Или нафига был бы CD в ваших экзерсисах с датчиками, кораблями и коробкой пиков?
Если ты заметил, в последние лет 15 цикл выпуска железок заметно сократился от того, что было ранее и продолжает сокращаться.
Минимальный объем окупаемых партий тоже заметно сокращается.
Уже десяток тех же платок заказать — они по себестоимости получаются меньше, чем когда-то заказывал партию из десяток тысяч их.
Из-за чего, как сам думаешь?
Датчиков уже было третье поколение, если что.
Про транкинговую связь — это вообще были сплошные итерации.
Ну и уже тогда классика жанра, когда чуть ли не половина железа уехала в пики, т.е. в софт, т.е. обновляли клиентам лишь прошивки (не на месте, ес-но, просто заменяли на идентичне перепрошитые).
конструктивно отдельным модулем шел лишь радиоканал, но там степень связности, как сам понимаешь, минимальная во всём проекте.
Для рекламные бегущие огней был разработан полный эмулятор на PC, где можно было "играть" с алгоритмами, на выходе готовая таблица для прошивки в пик.
Для чего, как сам думаешь?
Почему бы просто "не сесть и сразу не начать писать код прямо на пик"?
Ну мы же, типа, неопытные студенты, должны были поступать как положено неопытным студентам как минимум год после ВУЗ-а!
И ни дня меньше!
(вот реально ваши аргументы — сплошной какой-то сюррр)
НС>И это лишь один из маленьких кирпичиков, и их таких много.
Ну, не так уж самих аспектов много, порядка десятка.
Просто сами они составные, например, описание общей схемы процесса или методики оценки трудоёмкости.
Но я уже говорил — для записи в кустарщину достаточно отсутствие буквально единиц этих кирпичиков или превращение кирпичиков в неполноценные.
НС>Чтобы понять всю специфику эволюции коммерческих продуктов, надо непосредственно и достаточно длительный срок во всем этом поварится, не просто тупо зазубрить модные слова, но на своей жопе прочувствовать нафига оно вообще нужно и почему без этого хуже.
Т.е. у меня нет шансов увести происходящие здесь рассуждения от вопроса уникальности и степени чувствительности жоп?
Коллеги, возьмите уже себя в руки. ))
Если бы человечество отказалось от передачи знаний друг другу и каждый человек позавал мир самостоятельно, мы бы до сих пор жили в каменном веке.
В той самой кустарщине.
НС>Еще раз — дело не в том что вы не из того мяса сделаны, а в том что перед вами просто цели другие.
Цель — это тоже важный аспект.
Как думаешь, что есть проектирование как таковое?
Ну вот давай, своими словами.
Тем более, что подсказка "цель" уже прозвучала.
НС>Разработка под одного заказчика — да ради бога, я сам в таком участвовал.
1. Откуда ты взял "одного заказчика"?
2. Cформулированое таким образом опять выдаёт непонимание роли источника требований.
НС>Но это никак не гарантирует, что та же команда умеет выпускать коробку или SaaS-продукт.
Это зависит не от самих девелоперов, а как раз от руководителей команды.
Я уже говорил — каждый разработчик, может и работает "почти промышленно", но сама организация процесса — "на ощупь", кустарная.
То бишь виноваты ответственные люди, организующие такую разработку, которые НЕ знают, что им надо делать.
Просто берут чьи-то удачные практики и используют их у себя.
Или раньше брали и получали более-менее удачное "попадание" в свою специфику (а специфик дофига, ес-но).
Мода на различные такие практики — тоже девка капризная.
А откуда эти практики появились, почему именно так — сплошное ХЗ.
Вместо того, чтобы разобраться с вопросом, смотрю, строишь у себя в голове некоторые "модели" на основе ж-пы, объясняющие "вот тут много заказчиков, а вот тут continuos" и т.д.
Вопрос на миллиард:
а как вообще умудряются жить такие конторы, которые выпускают и коробочный продукт и регулярно его же обновляют по требованиям, в том числе "самых важных заказчиков"?
Пока что всё, что ты говорил, сводится к тому, что это противоречивые кейзы, т.е. одни и те же люди НЕ МОГУТ этим заниматься, бо это РАЗНЫЕ НАВЫКИ.
Более того, согласно заветам IB, разработчикам и вовсе КАЖДЫЙ РАЗ требуется переучиваться для СМЕНЫ характера работы.
Ты хорошо понимаешь, куда ведут ваши рассуждения? ))
V>>Я говорил лишь, что конкретно ты не системотехник по образованию.
НС>Ну а конкретно у меня в дипломе тот самый инженер-системотехник написан.
Я тебе этого и не писал, бо хоть я с вами лично еще и не общался (чем, по твоей версии, перед вами виновен), но не вчера ж родился и по переписке тут не первый год.
Конкретно у тебя я вижу заметный перекос твоих интересов.
Вряд ли ошибусь, если предположу, что такой "перекос" был всегда, еще с ВУЗ-а.
Т.е. когда одни предметы гораздо интереснее других.
Не прими за наезд, я ведь достоверно знать не могу, но такие студенты обычно склонны к забиванию на малоинтересные им предметы.
(отвечать не обязательно, можешь у себя там где-то просто "галочку" поставить про сумасшедшего vdimas-а, хы-хы)
Re[31]: Элита!
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Continuous Delivery/Deployment, слыхал про такое?
Ага, еще Continuos Integration забыл упомянуть.
И еще кучу аббревиатур.
Опять вопрос поставлен так, что ты уникальный, а собеседник даже не слышал.
Мне опять приходится "оправдываться".
ОК.
Бывали ситуации, когда по какому-то продукту и каждый день шли релизы, бывали и два раза в день.
Из-за просьб клиентов, ес-но.
Протокол любой биржи — это бесконечной толщины талмуд (талмудов много разных, речь о сугубо протокольном), можно подписываться на разные сигналы, пользоваться разными наборами транзакций, по каждому направлению доступна разная степень глубины подробности получаемой информации.
Сам протокол сложный, на этом и живём.
От нас клиент получает уже удобную либу с простыми "connect", "subscribe" и т.д.
Всё это не на пустом месте — есть мощный сетевой фреймворк, дающий лучшие или практически лучшие показатели по отрасли (1-2-е места в мире в разных дисциплинах).
Клиент, по классике, не всегда заранее достоверно знает, что ему нужно, т.е. сам это обнаруживает только в процессе окучивания конкретной биржи.
Ну и, начинается классическое "а это можете?", "еще такое-то сделаете?".
Изначально-то ему выгоднее заказать как можно меньшую конфигурацию, чтобы банально меньше платить.
Настолько частые релизы это скорее исключение, чем правило, но показывает саму способность работать в том числе в таком режиме.
Степень требуемой надёжности даваемого клиенту кода можешь себе представить.
Еще не софт по управлению ядерным реактором, но уже ближе туда, чем к классическим "формочкам".
На любую не окученную ранее биржу вот так с наскока не выскочишь, ес-но, должна быть некая стадия подготовки к такому этапу, разумеется.
Стадия сама по себе комплексная и подозрительно напоминающая класические стадии процессов проектирования.
А я опять "оправдываюсь", вместо того, чтобы заниматься чем-то полезным, например — отделить мух от котлет, например отделить от схемы процесса его динамику — выравнивание нагрузки: "не пинать балду и не аврал" (С). Это вопросы точности оценки трудоёмкости работ и соответствующего планирования ресурсов.
Тема отдельная и тоже, кстате, хорошо отличает кустарщину от некустарщины. Бо именно для целей улучшения оценок трудоёмкости классические "процессы", включая гостовские, содержат кое-какие важные этапы. И если контора делает/развивает сразу более одного проекта, где проекты могут быть на разных этапах или если речь о разных частях одного большого мега-проекта, то всегда есть возможность управлять ресурсами относительно гибко.
НС>А теперь расскажи нам, как студент на практике может познакомится с CD и всем что для этого нужно?
Когда совмещаешь разные части комплексной системы, то получается как с тем клиентом.
Только "релизы" могут идти не два раза в сутки, а малость чаще.
И опять, это скорее исключение, чем правило, но должна быть и такая способность.
Т.е. разработчик знакомится с самим фактом непрерывного уточнения/расширения требований, которые всегда происходят в сложной разработке.
Собсно, разработка чего-то сложнее GUI калькулятора ведётся именно так.
Итерации всегда всегда привязаны к срокам, ес-но, для всех уровней задействованных, от руководителей разных мастей до всех разработчиков.
Но при этом требуется в том числе гибкость/оперативность, умение быстро "проехать" некоторый затык.
Я же писал — разница лишь в том, кто является источником требований и что из себя представляет контроллирующий орган.
Этот орган не обязан быть одушевлённым для некоторого уровня итераций.
Чем сложнее проект, тем больше вложенность итераций.
НС>Или нафига был бы CD в ваших экзерсисах с датчиками, кораблями и коробкой пиков?
Если ты заметил, в последние лет 15 цикл выпуска железок заметно сократился от того, что было ранее и продолжает сокращаться.
Минимальный объем окупаемых партий тоже заметно сокращается.
Уже десяток тех же платок заказать — они по себестоимости получаются меньше, чем когда-то заказывал партию из десяток тысяч их.
Из-за чего, как сам думаешь?
Датчиков уже было третье поколение, если что.
Про транкинговую связь — это вообще были сплошные итерации.
Ну и уже тогда классика жанра, когда чуть ли не половина железа уехала в пики, т.е. в софт, т.е. обновляли клиентам лишь прошивки (не на месте, ес-но, просто заменяли на идентичне перепрошитые).
конструктивно отдельным модулем шел лишь радиоканал, но там степень связности, как сам понимаешь, минимальная во всём проекте.
Для рекламные бегущие огней был разработан полный эмулятор на PC, где можно было "играть" с алгоритмами, на выходе готовая таблица для прошивки в пик.
Для чего, как сам думаешь?
Почему бы просто "не сесть и сразу не начать писать код прямо на пик"?
Ну мы же, типа, неопытные студенты, должны были поступать как положено неопытным студентам как минимум год после ВУЗ-а!
И ни дня меньше!
(вот реально ваши аргументы — сплошной какой-то сюррр)
НС>И это лишь один из маленьких кирпичиков, и их таких много.
Ну, не так уж самих аспектов много, порядка десятка.
Просто сами они составные, например, описание общей схемы процесса или методики оценки трудоёмкости.
Но я уже говорил — для записи в кустарщину достаточно отсутствие буквально единиц этих кирпичиков или превращение кирпичиков в неполноценные.
НС>Чтобы понять всю специфику эволюции коммерческих продуктов, надо непосредственно и достаточно длительный срок во всем этом поварится, не просто тупо зазубрить модные слова, но на своей жопе прочувствовать нафига оно вообще нужно и почему без этого хуже.
Т.е. у меня нет шансов увести происходящие здесь рассуждения от вопроса уникальности и степени чувствительности жоп?
Коллеги, возьмите уже себя в руки. ))
Если бы человечество отказалось от передачи знаний друг другу и каждый человек позавал мир самостоятельно, мы бы до сих пор жили в каменном веке.
В той самой кустарщине.
НС>Еще раз — дело не в том что вы не из того мяса сделаны, а в том что перед вами просто цели другие.
Цель — это тоже важный аспект.
Как думаешь, что есть проектирование как таковое?
Ну вот давай, своими словами.
Тем более, что подсказка "цель" уже прозвучала.
НС>Разработка под одного заказчика — да ради бога, я сам в таком участвовал.
1. Откуда ты взял "одного заказчика"?
2. Cформулированое таким образом опять выдаёт непонимание роли источника требований.
НС>Но это никак не гарантирует, что та же команда умеет выпускать коробку или SaaS-продукт.
Это зависит не от самих девелоперов, а как раз от руководителей команды.
Я уже говорил — каждый разработчик, может и работает "почти промышленно", но сама организация процесса — "на ощупь", кустарная.
То бишь виноваты ответственные люди, организующие такую разработку, которые НЕ знают, что им надо делать.
Просто берут чьи-то удачные практики и используют их у себя.
Или раньше брали и получали более-менее удачное "попадание" в свою специфику (а специфик дофига, ес-но).
Мода на различные такие практики — тоже девка капризная.
А откуда эти практики появились, почему именно так — сплошное ХЗ.
Вместо того, чтобы разобраться с вопросом, смотрю, строишь у себя в голове некоторые "модели" на основе ж-пы, объясняющие "вот тут много заказчиков, а вот тут continuos" и т.д.
Вопрос на миллиард:
а как вообще умудряются жить такие конторы, которые выпускают и коробочный продукт и регулярно его же обновляют по требованиям, в том числе "самых важных заказчиков"?
Пока что всё, что ты говорил, сводится к тому, что это противоречивые кейзы, т.е. одни и те же люди НЕ МОГУТ этим заниматься, бо это РАЗНЫЕ НАВЫКИ.
Более того, согласно заветам IB, разработчикам и вовсе КАЖДЫЙ РАЗ требуется переучиваться для СМЕНЫ характера работы.
Ты хорошо понимаешь, куда ведут ваши рассуждения? ))
V>>Я говорил лишь, что конкретно ты не системотехник по образованию.
НС>Ну а конкретно у меня в дипломе тот самый инженер-системотехник написан.
Я тебе этого и не писал, бо хоть я с вами лично еще и не общался (чем, по твоей версии, перед вами виновен), но не вчера ж родился и по переписке тут не первый год.
Конкретно у тебя я вижу заметный перекос твоих интересов.
Вряд ли ошибусь, если предположу, что такой "перекос" был всегда, еще с ВУЗ-а.
Т.е. когда одни предметы гораздо интереснее других.
Не прими за наезд, я ведь достоверно знать не могу, но такие студенты обычно склонны к забиванию на малоинтересные им предметы.
(отвечать не обязательно, можешь у себя там где-то просто "галочку" поставить про сумасшедшего vdimas-а, хы-хы)
НС>Continuous Delivery/Deployment, слыхал про такое?
Ага, еще Continuos Integration забыл упомянуть.
И еще кучу аббревиатур.
Опять вопрос поставлен так, что ты уникальный, а собеседник даже не слышал.
Мне опять приходится "оправдываться".
ОК.
Бывали ситуации, когда по какому-то продукту и каждый день шли релизы, бывали и два раза в день.
Из-за просьб клиентов, ес-но.
Протокол любой биржи — это бесконечной толщины талмуд (талмудов много разных, речь о сугубо протокольном), можно подписываться на разные сигналы, пользоваться разными наборами транзакций, по каждому направлению доступна разная степень глубины подробности получаемой информации.
Сам протокол сложный, на этом и живём.
От нас клиент получает уже удобную либу с простыми "connect", "subscribe" и т.д.
Всё это не на пустом месте — есть мощный сетевой фреймворк, дающий лучшие или практически лучшие показатели по отрасли (1-2-е места в мире в разных дисциплинах).
Клиент, по классике, не всегда заранее достоверно знает, что ему нужно, т.е. сам это обнаруживает только в процессе окучивания конкретной биржи.
Ну и, начинается классическое "а это можете?", "еще такое-то сделаете?".
Изначально-то ему выгоднее заказать как можно меньшую конфигурацию, чтобы банально меньше платить.
Настолько частые релизы это скорее исключение, чем правило, но показывает саму способность работать в том числе в таком режиме.
Степень требуемой надёжности даваемого клиенту кода можешь себе представить.
Еще не софт по управлению ядерным реактором, но уже ближе туда, чем к классическим "формочкам".
На любую не окученную ранее биржу вот так с наскока не выскочишь, ес-но, должна быть некая стадия подготовки к такому этапу, разумеется.
Стадия сама по себе комплексная и подозрительно напоминающая класические стадии процессов проектирования.
А я опять "оправдываюсь", вместо того, чтобы заниматься чем-то полезным, например — отделить мух от котлет, например отделить от схемы процесса его динамику — выравнивание нагрузки: "не пинать балду и не аврал" (С). Это вопросы точности оценки трудоёмкости работ и соответствующего планирования ресурсов.
Тема отдельная и тоже, кстате, хорошо отличает кустарщину от некустарщины. Бо именно для целей улучшения оценок трудоёмкости классические "процессы", включая гостовские, содержат кое-какие важные этапы. И если контора делает/развивает сразу более одного проекта, где проекты могут быть на разных этапах или если речь о разных частях одного большого мега-проекта, то всегда есть возможность управлять ресурсами относительно гибко.
НС>А теперь расскажи нам, как студент на практике может познакомится с CD и всем что для этого нужно?
Когда совмещаешь разные части комплексной системы, то получается как с тем клиентом.
Только "релизы" могут идти не два раза в сутки, а малость чаще.
И опять, это скорее исключение, чем правило, но должна быть и такая способность.
Т.е. разработчик знакомится с самим фактом непрерывного уточнения/расширения требований, которые всегда происходят в сложной разработке.
Собсно, разработка чего-то сложнее GUI калькулятора ведётся именно так.
Итерации всегда всегда привязаны к срокам, ес-но, для всех уровней задействованных, от руководителей разных мастей до всех разработчиков.
Но при этом требуется в том числе гибкость/оперативность, умение быстро "проехать" некоторый затык.
Я же писал — разница лишь в том, кто является источником требований и что из себя представляет контроллирующий орган.
Этот орган не обязан быть одушевлённым для некоторого уровня итераций.
Чем сложнее проект, тем больше вложенность итераций.
НС>Или нафига был бы CD в ваших экзерсисах с датчиками, кораблями и коробкой пиков?
Если ты заметил, в последние лет 15 цикл выпуска железок заметно сократился от того, что было ранее и продолжает сокращаться.
Минимальный объем окупаемых партий тоже заметно сокращается.
Уже десяток тех же платок заказать — они по себестоимости получаются меньше, чем когда-то заказывал партию из десяток тысяч их.
Из-за чего, как сам думаешь?
Датчиков уже было третье поколение, если что.
Про транкинговую связь — это вообще были сплошные итерации.
Ну и уже тогда классика жанра, когда чуть ли не половина железа уехала в пики, т.е. в софт, т.е. обновляли клиентам лишь прошивки (не на месте, ес-но, просто заменяли на идентичне перепрошитые).
конструктивно отдельным модулем шел лишь радиоканал, но там степень связности, как сам понимаешь, минимальная во всём проекте.
Для рекламные бегущие огней был разработан полный эмулятор на PC, где можно было "играть" с алгоритмами, на выходе готовая таблица для прошивки в пик.
Для чего, как сам думаешь?
Почему бы просто "не сесть и сразу не начать писать код прямо на пик"?
Ну мы же, типа, неопытные студенты, должны были поступать как положено неопытным студентам как минимум год после ВУЗ-а!
И ни дня меньше!
(вот реально ваши аргументы — сплошной какой-то сюррр)
НС>И это лишь один из маленьких кирпичиков, и их таких много.
Ну, не так уж самих аспектов много, порядка десятка.
Просто сами они составные, например, описание общей схемы процесса или методики оценки трудоёмкости.
Но я уже говорил — для записи в кустарщину достаточно отсутствие буквально единиц этих кирпичиков или превращение кирпичиков в неполноценные.
НС>Чтобы понять всю специфику эволюции коммерческих продуктов, надо непосредственно и достаточно длительный срок во всем этом поварится, не просто тупо зазубрить модные слова, но на своей жопе прочувствовать нафига оно вообще нужно и почему без этого хуже.
Т.е. у меня нет шансов увести происходящие здесь рассуждения от вопроса уникальности и степени чувствительности жоп?
Коллеги, возьмите уже себя в руки. ))
Если бы человечество отказалось от передачи знаний друг другу и каждый человек позавал мир самостоятельно, мы бы до сих пор жили в каменном веке.
В той самой кустарщине.
НС>Еще раз — дело не в том что вы не из того мяса сделаны, а в том что перед вами просто цели другие.
Цель — это тоже важный аспект.
Как думаешь, что есть проектирование как таковое?
Ну вот давай, своими словами.
Тем более, что подсказка "цель" уже прозвучала.
НС>Разработка под одного заказчика — да ради бога, я сам в таком участвовал.
1. Откуда ты взял "одного заказчика"?
2. Cформулированое таким образом опять выдаёт непонимание роли источника требований.
НС>Но это никак не гарантирует, что та же команда умеет выпускать коробку или SaaS-продукт.
Это зависит не от самих девелоперов, а как раз от руководителей команды.
Я уже говорил — каждый разработчик, может и работает "почти промышленно", но сама организация процесса — "на ощупь", кустарная.
То бишь виноваты ответственные люди, организующие такую разработку, которые НЕ знают, что им надо делать.
Просто берут чьи-то удачные практики и используют их у себя.
Или раньше брали и получали более-менее удачное "попадание" в свою специфику (а специфик дофига, ес-но).
Мода на различные такие практики — тоже девка капризная.
А откуда эти практики появились, почему именно так — сплошное ХЗ.
Вместо того, чтобы разобраться с вопросом, смотрю, строишь у себя в голове некоторые "модели" на основе ж-пы, объясняющие "вот тут много заказчиков, а вот тут continuos" и т.д.
Вопрос на миллиард:
а как вообще умудряются жить такие конторы, которые выпускают и коробочный продукт и регулярно его же обновляют по требованиям, в том числе "самых важных заказчиков"?
Пока что всё, что ты говорил, сводится к тому, что это противоречивые кейзы, т.е. одни и те же люди НЕ МОГУТ этим заниматься, бо это РАЗНЫЕ НАВЫКИ.
Более того, согласно заветам IB, разработчикам и вовсе КАЖДЫЙ РАЗ требуется переучиваться для СМЕНЫ характера работы.
Ты хорошо понимаешь, куда ведут ваши рассуждения? ))
V>>Я говорил лишь, что конкретно ты не системотехник по образованию.
НС>Ну а конкретно у меня в дипломе тот самый инженер-системотехник написан.
Я тебе этого и не писал, бо хоть я с вами лично еще и не общался (чем, по твоей версии, перед вами виновен), но не вчера ж родился и по переписке тут не первый год.
Конкретно у тебя я вижу заметный перекос твоих интересов.
Вряд ли ошибусь, если предположу, что такой "перекос" был всегда, еще с ВУЗ-а.
Т.е. когда одни предметы гораздо интереснее других.
Не прими за наезд, я ведь достоверно знать не могу, но такие студенты обычно склонны к забиванию на малоинтересные им предметы.
(отвечать не обязательно, можешь у себя там где-то просто "галочку" поставить про сумасшедшего vdimas-а, хы-хы)