Согласится с автором, в том что ЯЗЫКИ программирования и структуры данных не имеют революционных достижений, можно, и я соглашусь.
Но в статье пропущены революционные ТЕХНОЛОГИИ создания маленьких программ и больших программных комплексов, которые изменили IT-ландшафт в глобальных масштабах.
Во-первых: открытый код, следствием является сборочное (из библиотек) программирование на потоке. Во-вторых: гибкая философия разработки (agile в совокупности), итеративное программирование с постоянной обратной связью. В-третьих: конвейерное программирование (непрерывная разработка), фабрика программного продукта с технологическим контролем и выходной приёмкой.
Хотелось бы продолжить использованное автором в начале статьи утверждение:
Как на смену ручному производству пришло конвейерное, так на смену программисту-одиночке пришли команды. Современные программы создаются командами, а не одиночками.
Теперь же, когда конвейерное программирование постепенно заменяется сборочным, на сцену опять выходят программисты-одиночки. Современное программирование — это продукт из готовых модулей, собранных из готовых библиотек, размещённых в контейнерах по готовой технологии. И здесь есть место умелым мастерам от программирования, которые вместо конвейерного «пиления-допиливания» тщательно шлифуют код и не выкатывают в продакт, пока не доведут до ума.
Согласен, для простого МК много, при желании можно организовать внешний стек FIFO. Важнее другое, сложная математическая статистическая обработка, в статье заявленная, для МК также вещь малоподъёмная. Может быть посмотреть в сторону одноплатных компьютеров? Либо, развернуться в сторону классической цифровой обработки сигналов и искать совпадения по спектрограммам.
:) Опять согласен, но… Но использованный пример такого сочетания команды и продукта не является референсным. Я встречался с адекватными сочетаниями и видел другие варианты развития ситуации. Поэтому немного комментов.
Продукту нужно постоянное развитие, иначе клиенты уходят к вашим конкурентам.
Если код съедает себя сам, и команда барахтается в поверхностном допиле, то клиенты и так уходят к конкурентам.
Но в реальном мире у вас будет лишь референсная реализация — собственно, ваш работающий продукт. И при переписывании вы вынуждены будете повторить все его недостатки.
Если кто-то поставил вопрос «о переписывании», значит кто-то сформулировал недостатки. Если под «референсной реализацией» понимается интерефейс и логика, то вопрос внутренней реализации продукта вторичен. Интерфейс и логику можно натянуть на любой язык программирования, важнее архитектура продукта.
И просто утонуть в фидбеке о том, насколько новый продукт не соответствует ожиданиям.
В этом случае я делал оговорку про первопроходцев. Миграцию, я подразумевал, не одномоментную.
В реальности происходит миграция обратно.
И это нормально. Возможных причин много: команда слаба в разработке, функционал не тестили на юзерах, завышенные технические ожидания от нового стёка, новые фичи юзерам пофиг, им нужнее адекватная поддержка и пр. Главное вовремя принять решение об откате, а не вступить в новую платформу. Сделать выводы и «медленно и кусками двигать проект». А возможно, и продать продукт пока он имеет клиентскую базу и работоспособен.
Соглашаюсь повторно, и опять выскажу параллельную точку зрения. Если не привязываться к технологии переписывания (спринты — значит Agile), то можно переписать и целиком, и с миграцией клиентов.
Что мешает поступить следующим образом:
— Зафиксировать текущее состояние продукта в части фичеобразования.
— Сформулировать требования и новую архитектуру. Выбрать стек. Оценить затраты.
— Перевести законсервированный продукт в режим «только тех.поддержка и ничего более».
— Протестировать клиентуру на предмет наличия желающих выступить первопроходцами, пообещать пряников.
— Запустить разработку новой платформы на ограниченном контингенте. Здесь можно уже и Agile включать.
— В какой-то момент запустить миграцию клиентов.
— Вывести из работы старый продукт, полностью переключится на новую платформу.
Автор, по-сути, изложил в новой формулировке базовые мысли всех покровителей стартапов (бизнес-ангелов, венчурных инвесторов, наставников, сооснователей и др.) — «проверяйте свои идеи, прежде чем приступать к реализации». Но молодые, оптимистичные, честолюбивые, профессионально состоявшиеся в разработке, успешные и уверенные в развитии успеха (автор назвал это чувство собственного превосходства — азартом) команды и одиночки раз за разом наступают на одни и те же грабли.
Удивительно, что многие заядлые игроки, не считают себя азартными. И желание пройти следующий уровень в видеоигре они считают драйвом и средством приобретения нового жизненного опыта, либо закреплением существующего.
В чем-то согласен. Но существует какая-то несогласованность в исходных установках. Есть работающий сложный продукт, а есть коллектив, не справляющийся с энтропией в существующем коде. Что следствие, а что причина — не суть важно. Если не законсервировать продукт на текущей стадии, то по-любому «код погубит сам себя». Поэтому, решение начать заново, на основе имеющегося опыта и с учётом современных технологий, — вполне разумно.
Если кратко, то постановка задачи в статье такая: на небольших временных интервалах, сравнимых с периодом напряжения в сети, по графикам (наборам данных) тока и напряжения на вводе определить текущий состав потребителей.
Предлагаю изменить метод на следующий: «Измерять очень часто, на длительных интервалах». Что в основе?
1. Каждый потребитель имеет свой уникальный образ электрического потребления (как функция комплексного сопротивления от времени). Поэтому временной ряд по току будет характерным отпечатком конкретного потребителя.
2. Мгновенный ток на вводе есть суперпозиция от комплексного сопротивления потребителей.
Дополнение. Импульсные потребители при детальном рассмотрении (около 1 МГц) по току имеют уникальные различия между собой. Можно сказать имеют токовый портрет. И эти портреты при потреблении не сливаются в один всеобщий резонанс.
Если проводить измерения тока и напряжения с частотой в разы превращающей работу импульсных блоков питания, то можно использовать временной ряд токового потребления для выделения образов и идентификации потребителей.
В длинной статье, акцент на слабых качествах (управленческих, архитектурных, системных) коллектива. Мол, неразумные довели дела до невыносимого состояния, да так, что все согласны начать заново. И далее, так делать нельзя, нужно тщательно разобраться, возможно, всё не так уж и плохо. Интересно, откуда у этого никудышного коллектива такой сложный продукт взялся?
По мне, желание сделать по-новой — это нормально! Правильнее переклеить обои, чем тщательно устранять неизбежные дефекты при эксплуатации (потёртости у выключателей, задиры, царапины, следы животных, выбоины, выцветание).
А может дополнить идею до полной системы?
Тесты должна писать разработка.
Прод должно писать тестирование.
Конечно, всё в меру. В случае с тестами от разработчиков в этой статье кейс рассмотрен. В целом, профит есть. И как я думаю, прежде всего от плотной коммуникации между разработчиками и тестировщиками. Запросто, можно представить как тестировщик, глядя на результаты тестов, предлагает разработчикам решение фичи, с определённой степенью детализации. А для этого он должен погрузится в устройство прода поглубже с помощью/обучением от разработчиков.
Согласен, наигранность сразу видна. А как, Вам, такой честный ответ: «Меня устраивает ваша зарплата и думаю, что участвовать в разработке вашего продукта будет интересно».
Смысл этой и многих статьей «Рекомендации для собеседования» такой: необходимо понравиться рекрутёру/собеседователю в легкой и непринужденной форме. Заматерели сеньоры-собеседователи, поэтому скоро кандидатам потребуются курсы актёрского мастерства и стенд-ап практика перед собеседованием.
Например:
«Будьте честны, но не наглейте. Недавно я собеседовал кандидата из Бразилии, который на вопрос: «Почему ты хочешь у нас работать?» ответил: «В Европе платят больше, чем в Бразилии». Несмотря на то, что это максимально честный ответ, это показывает, что ему всё равно, где работать и чем заниматься.»
Здесь автор считает честность кандидата наглостью. Во многих странах культурный код подразумевает открытое, эмоциональное, без заискивания высказывание о своих мотивах. Так же, прямо высказываются о качествах собеседника, и это не считается наглостью. Контекст подсказывает, что автор рекомендует бразильскому кандидату скрыть истинные мотивы, показать знание продуктов конторы и выразить псевдо-готовность работать за интерес/идею/перспективу/статус.
«Хотели как лучше, получилось как всегда» — выбираем не самых лучших, а тех кто понравился.
Познавательно и интересно, о том как гранды строят собственные решения (велосипедом это не назовёшь). В целом логичная автоматизация. Не совсем понятно, про Market Kombat и тест на предпродакшн. Куда в этих случаях выкатывается релиз? На теневой кластер или существует дополнительное специальное железо?
Есть разница. Существуют и такие, и такие модели. В одних нагрев больше берёт, в других охлаждение. Примеры на картинках. И обратите внимание на стартовый ток у LG
К чему негативные коннотации в ответах. Зачем в течении беседы регулярно оскорблять собеседника? Зачем вам дикое желание самоутвердится унизив собеседника в финальной фразе.
Похоже, что вы просто надменный интеллектуальный острослов (не более того).
В первом комменте, я с улыбкой (смайлик в конце) вопрошал про сильные магниты, не давая никаких рекомендаций. Вы сами ввязались требуя каких-то обоснований. Ваш назидательный тон, конечно, раздражает. Не вам меня учить, тем более, что вы и не можете. И если вы, «в зуб ногой» в теме МРТ, то всем интересно почитать от компетентного спеца детальный расклад «на пальцах».
Ок, компетентный, вы наш. Ждем от вас статью без суеверий на пальцах раскрывающую процесс МРТ, и научно доказанную полную безопасность магнитных, электромагнитных и электрических полей для всего живого. А также компетентных рекомендаций на уровне нобелевских лауреатов для обывателей.
Устраивая селективность автоматов у себя дома, помимо информации в статье, нужно помнить ещё об одном моменте.
Суммарная продолжительная токовая нагрузка на автоматический выключатель.
Тут картина в следующем:
Тепловой расцепитель нагревается от протекающего тока, чем больше ток, тем ближе он к точке срабатывания. У вас в каскаде на вводе автомат 32А, по комнатам 16А. Одновременно работают сплит, СВЧ, стиралка, пылесос, комп, телек. Средний продолжительный ток через ввод 25А (около 5 кВт). Если случается КЗ в комнате с малым текущим потреблением, то селективный автомат 16А не сработает. Предварительно взведённый нагревом вводной автомат сработает быстрее и отключит всю квартиру. С этим приходится мирится. Если поставить на ввод 40А или 50А, то домовая сеть может и не обеспечить тока КЗ для срабатывания такого монстра. А если ставить по комнатам меньше 16А, то сплит + пылесос будут регулярно перегревать автомат.
Причем, многоуровневое селектирование (ввод-подъезд-этаж-квартира-комната) требует точного подбора номиналов по сечениям и ожидаемой длительной нагрузке. К примеру, самостоятельно поставили жители в подъездных щитах автоматы на повышенный ток, что бы сплит квартиру не выбивал. И в самую жару включаешь пылесос — хлоп, и весь подъезд без света.
Но в статье пропущены революционные ТЕХНОЛОГИИ создания маленьких программ и больших программных комплексов, которые изменили IT-ландшафт в глобальных масштабах.
Во-первых: открытый код, следствием является сборочное (из библиотек) программирование на потоке.
Во-вторых: гибкая философия разработки (agile в совокупности), итеративное программирование с постоянной обратной связью.
В-третьих: конвейерное программирование (непрерывная разработка), фабрика программного продукта с технологическим контролем и выходной приёмкой.
Теперь же, когда конвейерное программирование постепенно заменяется сборочным, на сцену опять выходят программисты-одиночки. Современное программирование — это продукт из готовых модулей, собранных из готовых библиотек, размещённых в контейнерах по готовой технологии. И здесь есть место умелым мастерам от программирования, которые вместо конвейерного «пиления-допиливания» тщательно шлифуют код и не выкатывают в продакт, пока не доведут до ума.
Если код съедает себя сам, и команда барахтается в поверхностном допиле, то клиенты и так уходят к конкурентам.
Если кто-то поставил вопрос «о переписывании», значит кто-то сформулировал недостатки. Если под «референсной реализацией» понимается интерефейс и логика, то вопрос внутренней реализации продукта вторичен. Интерфейс и логику можно натянуть на любой язык программирования, важнее архитектура продукта.
В этом случае я делал оговорку про первопроходцев. Миграцию, я подразумевал, не одномоментную.
И это нормально. Возможных причин много: команда слаба в разработке, функционал не тестили на юзерах, завышенные технические ожидания от нового стёка, новые фичи юзерам пофиг, им нужнее адекватная поддержка и пр. Главное вовремя принять решение об откате, а не вступить в новую платформу. Сделать выводы и «медленно и кусками двигать проект». А возможно, и продать продукт пока он имеет клиентскую базу и работоспособен.
Что мешает поступить следующим образом:
— Зафиксировать текущее состояние продукта в части фичеобразования.
— Сформулировать требования и новую архитектуру. Выбрать стек. Оценить затраты.
— Перевести законсервированный продукт в режим «только тех.поддержка и ничего более».
— Протестировать клиентуру на предмет наличия желающих выступить первопроходцами, пообещать пряников.
— Запустить разработку новой платформы на ограниченном контингенте. Здесь можно уже и Agile включать.
— В какой-то момент запустить миграцию клиентов.
— Вывести из работы старый продукт, полностью переключится на новую платформу.
Удивительно, что многие заядлые игроки, не считают себя азартными. И желание пройти следующий уровень в видеоигре они считают драйвом и средством приобретения нового жизненного опыта, либо закреплением существующего.
Предлагаю изменить метод на следующий: «Измерять очень часто, на длительных интервалах». Что в основе?
1. Каждый потребитель имеет свой уникальный образ электрического потребления (как функция комплексного сопротивления от времени). Поэтому временной ряд по току будет характерным отпечатком конкретного потребителя.
2. Мгновенный ток на вводе есть суперпозиция от комплексного сопротивления потребителей.
Дополнение. Импульсные потребители при детальном рассмотрении (около 1 МГц) по току имеют уникальные различия между собой. Можно сказать имеют токовый портрет. И эти портреты при потреблении не сливаются в один всеобщий резонанс.
Если проводить измерения тока и напряжения с частотой в разы превращающей работу импульсных блоков питания, то можно использовать временной ряд токового потребления для выделения образов и идентификации потребителей.
По мне, желание сделать по-новой — это нормально! Правильнее переклеить обои, чем тщательно устранять неизбежные дефекты при эксплуатации (потёртости у выключателей, задиры, царапины, следы животных, выбоины, выцветание).
Тесты должна писать разработка.
Прод должно писать тестирование.
Конечно, всё в меру. В случае с тестами от разработчиков в этой статье кейс рассмотрен. В целом, профит есть. И как я думаю, прежде всего от плотной коммуникации между разработчиками и тестировщиками. Запросто, можно представить как тестировщик, глядя на результаты тестов, предлагает разработчикам решение фичи, с определённой степенью детализации. А для этого он должен погрузится в устройство прода поглубже с помощью/обучением от разработчиков.
Например:
«Будьте честны, но не наглейте. Недавно я собеседовал кандидата из Бразилии, который на вопрос: «Почему ты хочешь у нас работать?» ответил: «В Европе платят больше, чем в Бразилии». Несмотря на то, что это максимально честный ответ, это показывает, что ему всё равно, где работать и чем заниматься.»
Здесь автор считает честность кандидата наглостью. Во многих странах культурный код подразумевает открытое, эмоциональное, без заискивания высказывание о своих мотивах. Так же, прямо высказываются о качествах собеседника, и это не считается наглостью. Контекст подсказывает, что автор рекомендует бразильскому кандидату скрыть истинные мотивы, показать знание продуктов конторы и выразить псевдо-готовность работать за интерес/идею/перспективу/статус.
«Хотели как лучше, получилось как всегда» — выбираем не самых лучших, а тех кто понравился.
Похоже, что вы просто надменный интеллектуальный острослов (не более того).
Суммарная продолжительная токовая нагрузка на автоматический выключатель.
Тут картина в следующем:
Тепловой расцепитель нагревается от протекающего тока, чем больше ток, тем ближе он к точке срабатывания. У вас в каскаде на вводе автомат 32А, по комнатам 16А. Одновременно работают сплит, СВЧ, стиралка, пылесос, комп, телек. Средний продолжительный ток через ввод 25А (около 5 кВт). Если случается КЗ в комнате с малым текущим потреблением, то селективный автомат 16А не сработает. Предварительно взведённый нагревом вводной автомат сработает быстрее и отключит всю квартиру. С этим приходится мирится. Если поставить на ввод 40А или 50А, то домовая сеть может и не обеспечить тока КЗ для срабатывания такого монстра. А если ставить по комнатам меньше 16А, то сплит + пылесос будут регулярно перегревать автомат.
Причем, многоуровневое селектирование (ввод-подъезд-этаж-квартира-комната) требует точного подбора номиналов по сечениям и ожидаемой длительной нагрузке. К примеру, самостоятельно поставили жители в подъездных щитах автоматы на повышенный ток, что бы сплит квартиру не выбивал. И в самую жару включаешь пылесос — хлоп, и весь подъезд без света.