Все испытательные полёты Boing Starliner сопровождались какими-то техническими проблемами: то с программным обеспечением, то с работой систем. Не понимаю, как можно было на таком аппарате живых людей отправлять...
Скажем так, за десять лет я ни разу не видела PO и PM на одном проекте. Верхний человек проекта назывался по-разному, но его функции были примерно те же с поправкой на тип проекта. И это всегда был один человек. Любопытно, что где-то выделяют двух.
Например, в методологии Microsoft Solutions Framework (MSF), о которой наверняка рассказывают студентам «программистских» направлений в курсах инженерии программного обеспечения. Там эти роли называются Program Management и Product Management, и, если посмотреть матрицу совмещения ролей, их пересечение в одном лице категорически не рекомендуется из-за конфликта интересов.
Можно даже предположить, что этот аппарат называется «Starship»... Пока всё идёт к тому, что это название станет в космической отрасли нарицательным, как «джип» на Земле.
Вообще-то в Вашей статье присутствует винегрет из должностей, профессий и ролей, в котором непросто обнаружить структуру. Владелец Продукта, например, это не специальность, а роль в методологии Scrum. И можно ли его назвать там «верхним человеком» — открытый вопрос.
В разных компаниях менеджеров и владельцев по-разному определяют, ну и менеджеры разного уровня бывают. Можете уточнить, с чем в моём описании этих двоих вы не согласны? Интересно.
Менеджер проекта отвечает за то, чтобы продукт имел заданный уровень качества и был выполнен в срок без выхода за рамки бюджета. Владелец продукта отвечает за то, чтобы продукт решал нужды заказчика. В отношении продукта владелец сосредоточен на функциональных требованиях, а менеджер - на нефункциональных.
Менеджеры проектов обычно присутствуют в проектах заказной разработки или продуктах с чётко определёнными целевой аудиторией и направлением развития. Владельцы продукта отвечают за продуктовые проекты, у которых есть клиенты, но нет заказчиков извне компании.
Менеджеры проектов обычно присутствуют в любых проектах — при решении уникальных задач в заданные сроки.
Что ситуации бывают разные, это понятно. И в Арктике надо обеспечивать работу оборудования, и подводные кабели ремонтировать. Но сейчас не 19-й и даже не 20-й век, и можно обеспечить персоналу больший уровень комфорта. Если отбросить пионерский задор и расстояния, то аналогичные истории могут рассказать многие инженеры, например, обслуживающие банкоматы в 20-градусный мороз в какой-нибудь провинциальной глубинке (20 км или 2000 км через заснеженный лес — большой роли не играет). И можно, конечно, расшивать и опрессовывать витую пару отвёрткой, если начальство не позаботилось о минимальном наборе инструмента. Но, по-видимому, это плохой пример для подражания.
Как я понял из статьи, Ваш коллега был отправлен в командировку куда-то в район Крайнего Севера. Не уверен, что, учитывая все обстоятельства и требования ТБ, можно было отправлять его в одиночку (работы на трансформаторах и источниках питания должны выполнять не менее двух человек, но если в рассматриваемом случае только слаботочка, то не знаю). Интересно ещё, как были выполнены рекомендации по организации работ в условиях низких температур? Обеспечил ли его наниматель средствами индивидуальной защиты (например, жилетом с подогревом)?
Эти дефекты могут иметь форму похожих на оболочки компактных областей, где плотность материи намного выше. Выстраиваясь в концентрические кольца, эти дефекты ведут себя подобно гравитации, но не обладают массой.
А о плотности материи можно говорить, исключая массу? Или это такая аллегория?
... каждый час до вылета потратили на поиски и покупку в обычных магазинах комплектующих, маленького лабораторного блока питания, компактной паяльной станции и т.д. Коллеги из дома приносили переносной фен, походный рюкзак…с миру по нитке.
Многое из описанной романтической суеты производит впечатление просто низкого уровня организации.
Поэтому везде подключаем систему газового пожаротушения. Мы используем безопасный для людей и оборудования газ, который быстро распадается и не оставляет загрязнений.
В помещениях, оснащённых системой газового пожаротушения, ощущается некоторый дискомфорт. Пожары не так часто случаются, как ложные срабатывания. И оказаться в процессе обслуживания оборудования в газовой камере — неприятная перспектива. Но вот как-то не верится, что есть такой замечательный во всех отношениях газ. Всё-таки для прекращения горения он должен вытеснять собой кислород, который необходим также и для дыхания.
Возможно, мы смотрим на вопрос с двух разных точек зрения, поэтому не можем прийти к единому мнению. Попробую пояснить свою позицию. В контексте того примера, который я привёл, понятие параллельности относится исключительно к методу решения задачи. Есть 10 потоков, все они запущены и находятся в состоянии выполнения. Этого достаточно для того, чтобы говорить о параллелизме. То, как этот параллелелизм реализован на низком уровне - реальные ли вычислительные ядра будут выделяться каждому потоку, или потоки будут разделять время работы одного ядра на всех - с точки зрения метода не играет никакой роли. Этот вопрос находится на другом, более низком уровне абстракции, и пусть этот уровень сам решает свои проблемы. Тем более, что из PHP/GO мы никак не можем на это повлиять. Для нас (стороннего наблюдателя прикладного уровня) всё будет выглядеть так, как будто потоки выполняются одновременно.
Главное в приведенном примере то, что потоки могут работать и работают независимо друг от друга. Каждый поток обрабатывает свой набор данных, у них нет предмета для конфликта, а значит и о свойстве конкурентности в данном случае говорить не приходится.
Случаи, когда прикладному программисту надо спускаться на низкий уровень реализации параллелелизма, редки. Ему важно видеть параллелелизм в алгоритмах решения задач, а также находить участки, в которых одновременное выполнение может привести к разного рода конфликтам (взаимным блокировкам, разным результатам в зависимости от порядка выполнения и т. п.). На этом, прикладном, уровне параллелелизм является первичной сущностью, и только параллельное выполнение участков может приводить к ситуациям, которые называют конкурентностью. Мне нравится, как это в научно-популярной форме описано у Таненбаума.
Был случай, когда у на компьютере сотрудника переустановили операционную систему (по жизненным показаниям), а он закатил скандал, что теперь не может работать из-за того, что изменился порядок значков на рабочем столе и в папках (там действительно было много папок и ярлыков), которые он заботливо расставлял долгие годы. Поэтому на производстве лучше не полагаться на штатные средства операционной системы, а использовать какие-нибудь специализированные решения для хранения «интеллектуальной собственности».
Вот пример: рассчитать таблицу умножения для десятичной системы счисления, то есть заполнить матрицу 10 x 10 значениями, равными произведению номера строки на номер столбца (нумерация начинается с единицы). Для простоты решать будем десятью потоками. Каждому даём свой персональный столбец (или строку) — и вперёд. Параллельность есть? Есть. А где конкурентность?
Алгоритм работает для любого списка, в который элементы поступают по одному — как слова в речи, товары на конвейере или автомобили на шоссе.
Что-то мне кажется, что играет роль ещё и вид распределения поступающих элементов. Если оно будет не равномерным, то точность может серьёзно ухудшиться. Тогда область применимости этого метода ещё больше сужается.
Конкурентность — это способность системы управлять несколькими задачами практически одновременно. Задачи могут приостанавливаться и возобновляться, давая ощущение одновременного выполнения. Это достигается путем распределения времени процессора между задачами.
Что-то мне это определение не нравится. Может, оно для мира PHP/Backend? В моём понимании, конкурентность — это способность управлять доступом к ограниченным ресурсам. А то, что описано выше, — это (псевдо)многозадачность.
А почему бы не разрешить IT‑шникам просто писать дипломные работы по своим IT‑проектам? И если проекты действительно демонстрирует их знания, умения и навыки, то давать им за это официальный диплом.
Чтобы стать рыцарем, мало сходить к пещере и завалить дракона. Надо ещё научиться стихосложению и игре в шахматы или хотя бы в шашки.
На Perl можно было писать по-разному. Можно так "оптимизировать" программу, что она будет похожа на обфусцированный код. А можно выбрать такой стиль, что она будет выглядеть уж никак не хуже программы на Python.
Все испытательные полёты Boing Starliner сопровождались какими-то техническими проблемами: то с программным обеспечением, то с работой систем. Не понимаю, как можно было на таком аппарате живых людей отправлять...
Например, в методологии Microsoft Solutions Framework (MSF), о которой наверняка рассказывают студентам «программистских» направлений в курсах инженерии программного обеспечения. Там эти роли называются Program Management и Product Management, и, если посмотреть матрицу совмещения ролей, их пересечение в одном лице категорически не рекомендуется из-за конфликта интересов.
Можно даже предположить, что этот аппарат называется «Starship»... Пока всё идёт к тому, что это название станет в космической отрасли нарицательным, как «джип» на Земле.
Вообще-то в Вашей статье присутствует винегрет из должностей, профессий и ролей, в котором непросто обнаружить структуру. Владелец Продукта, например, это не специальность, а роль в методологии Scrum. И можно ли его назвать там «верхним человеком» — открытый вопрос.
Менеджер проекта отвечает за то, чтобы продукт имел заданный уровень качества и был выполнен в срок без выхода за рамки бюджета. Владелец продукта отвечает за то, чтобы продукт решал нужды заказчика. В отношении продукта владелец сосредоточен на функциональных требованиях, а менеджер - на нефункциональных.
Менеджеры проектов обычно присутствуют в любых проектах — при решении уникальных задач в заданные сроки.
Мне кажется, что вот этим категориям специалистов «отработка» совсем не обязательна:
И «Менеджер проекта» и «Владелец продукта» — это разные категории.
Что ситуации бывают разные, это понятно. И в Арктике надо обеспечивать работу оборудования, и подводные кабели ремонтировать. Но сейчас не 19-й и даже не 20-й век, и можно обеспечить персоналу больший уровень комфорта. Если отбросить пионерский задор и расстояния, то аналогичные истории могут рассказать многие инженеры, например, обслуживающие банкоматы в 20-градусный мороз в какой-нибудь провинциальной глубинке (20 км или 2000 км через заснеженный лес — большой роли не играет). И можно, конечно, расшивать и опрессовывать витую пару отвёрткой, если начальство не позаботилось о минимальном наборе инструмента. Но, по-видимому, это плохой пример для подражания.
Как я понял из статьи, Ваш коллега был отправлен в командировку куда-то в район Крайнего Севера. Не уверен, что, учитывая все обстоятельства и требования ТБ, можно было отправлять его в одиночку (работы на трансформаторах и источниках питания должны выполнять не менее двух человек, но если в рассматриваемом случае только слаботочка, то не знаю). Интересно ещё, как были выполнены рекомендации по организации работ в условиях низких температур? Обеспечил ли его наниматель средствами индивидуальной защиты (например, жилетом с подогревом)?
А о плотности материи можно говорить, исключая массу? Или это такая аллегория?
Многое из описанной романтической суеты производит впечатление просто низкого уровня организации.
В помещениях, оснащённых системой газового пожаротушения, ощущается некоторый дискомфорт. Пожары не так часто случаются, как ложные срабатывания. И оказаться в процессе обслуживания оборудования в газовой камере — неприятная перспектива. Но вот как-то не верится, что есть такой замечательный во всех отношениях газ. Всё-таки для прекращения горения он должен вытеснять собой кислород, который необходим также и для дыхания.
Будет ли этот приём работать как на LSB, так и на MSB архитектурах?
Возможно, мы смотрим на вопрос с двух разных точек зрения, поэтому не можем прийти к единому мнению. Попробую пояснить свою позицию. В контексте того примера, который я привёл, понятие параллельности относится исключительно к методу решения задачи. Есть 10 потоков, все они запущены и находятся в состоянии выполнения. Этого достаточно для того, чтобы говорить о параллелизме. То, как этот параллелелизм реализован на низком уровне - реальные ли вычислительные ядра будут выделяться каждому потоку, или потоки будут разделять время работы одного ядра на всех - с точки зрения метода не играет никакой роли. Этот вопрос находится на другом, более низком уровне абстракции, и пусть этот уровень сам решает свои проблемы. Тем более, что из PHP/GO мы никак не можем на это повлиять. Для нас (стороннего наблюдателя прикладного уровня) всё будет выглядеть так, как будто потоки выполняются одновременно.
Главное в приведенном примере то, что потоки могут работать и работают независимо друг от друга. Каждый поток обрабатывает свой набор данных, у них нет предмета для конфликта, а значит и о свойстве конкурентности в данном случае говорить не приходится.
Случаи, когда прикладному программисту надо спускаться на низкий уровень реализации параллелелизма, редки. Ему важно видеть параллелелизм в алгоритмах решения задач, а также находить участки, в которых одновременное выполнение может привести к разного рода конфликтам (взаимным блокировкам, разным результатам в зависимости от порядка выполнения и т. п.). На этом, прикладном, уровне параллелелизм является первичной сущностью, и только параллельное выполнение участков может приводить к ситуациям, которые называют конкурентностью. Мне нравится, как это в научно-популярной форме описано у Таненбаума.
«И как же это ты, Шарапов, папку на столе без присмотра оставил?!»
Был случай, когда у на компьютере сотрудника переустановили операционную систему (по жизненным показаниям), а он закатил скандал, что теперь не может работать из-за того, что изменился порядок значков на рабочем столе и в папках (там действительно было много папок и ярлыков), которые он заботливо расставлял долгие годы.
Поэтому на производстве лучше не полагаться на штатные средства операционной системы, а использовать какие-нибудь специализированные решения для хранения «интеллектуальной собственности».
Вот пример: рассчитать таблицу умножения для десятичной системы счисления, то есть заполнить матрицу 10 x 10 значениями, равными произведению номера строки на номер столбца (нумерация начинается с единицы). Для простоты решать будем десятью потоками. Каждому даём свой персональный столбец (или строку) — и вперёд. Параллельность есть? Есть. А где конкурентность?
Что-то мне кажется, что играет роль ещё и вид распределения поступающих элементов. Если оно будет не равномерным, то точность может серьёзно ухудшиться. Тогда область применимости этого метода ещё больше сужается.
Что-то мне это определение не нравится. Может, оно для мира PHP/Backend? В моём понимании, конкурентность — это способность управлять доступом к ограниченным ресурсам. А то, что описано выше, — это (псевдо)многозадачность.
Где-где? Естественно, в Китае!
Вот с дискетами действительно напряжённо.
Чтобы стать рыцарем, мало сходить к пещере и завалить дракона. Надо ещё научиться стихосложению и игре в шахматы или хотя бы в шашки.
На Perl можно было писать по-разному. Можно так "оптимизировать" программу, что она будет похожа на обфусцированный код. А можно выбрать такой стиль, что она будет выглядеть уж никак не хуже программы на Python.