В п.3.3. "Дублирование в «нарисованном»" вы пишете о возможностях текстовых IDE по поиску повторов кода, противопоставляя их визуальному поиску на картинке. Прошу пояснить, в каком виде утверждается ТЗ на подобные бизнес-системы?
Предлагается сразу писать код без согласования логики с "не-программистами"?
Я всегда был максимально прагматичным человеком ... потому что наверное только такие относятся к потраченному времени очень внимательно и не стараются его тратить на всякую чепуху.
Маша работала инженером в Роскосмосе, а сейчас работает в Кремниевой Долине, разработчиком в компании Applied Materials - одного из лидеров в оборудовании для производства микросхем.
а это другое:
... если набрать винегрет инженеров и ученых на разные темы, которых объединяет лишь желание получить много денег от россиян, то они через пару лет разъедутся обратно и каши за это время не сварят.
кстати, что там насчет Т-платформ? Помнится, на одном из заседаний АРПЭ Иван Покровский предлагал коллективное письмо подписать с просьбой освободить генерального директора из-под стражи.
собственно, МИФИ - хорошая иллюстрация: автоматчики есть, а реактор Маша вряд ли видела
На мой взгляд, почти все перечисленные в статье типы программистов вполне могут вписаться в нормальный коллектив и приносить ощутимую пользу бизнесу - кто-то любит уникальные фреймворки проектировать, кто-то сложные реалтайм задачи отлаживать, кто-то типовые конфигурации быстро клепать, а некоторые - предыдущее легаси сопровождать.
На мой взгляд, результаты инструментального контроля и повторный проход дяди Васи вообще-то должны быть прописаны в технологическом маршруте.
во-первых, для анализа качества
во-вторых, для учета трудозатрат и машиночасов на деталь
понятно, что дядя Вася будет избегать ввода значений, потому что ему платят за детали, а не за вводы, кроме того, как и все люди, он хочет поменьше надзора.
Поэтому желательно, чтобы ввод значений был как можно более автоматизирован и реально экономить дяде Васе время. Например, сменой измерительного щупа по автоматизированной программе. Как вариант, чтобы новый код нельзя было загрузить без выполнения операций контроля.
И главное: никогда нельзя на усмотрение исполнителя изменять операции.
Кстати, буквально вчера разбирались по браку с подрядчиком - выяснили, что технолог, обнаружив отклонение в техпроцессе (как позже выяснилось - по причине деградации оборудования), внес изменения, которые ему показались корректирующими. Результат немного предсказуем.
Если у вас постоянно новая номенклатура можно ввести обобщенную операцию со всеми возможными шагами и пропускать их - это гораздо проще контролировать.
Вывод: за потраченные средства, GM могла просто купить Toyota и Nissan:
Since 1980 GM has spent $45 billion on the automotive business. Capital spending appears to be almost inversely related to our levels of operating profit. And GM's forward capital spending plans are projected to be $34.7 billion over the period from 1986 through 1989. For $34.7 billion, given recent market valuations, GM could have purchased Toyota and Nissan.
Очень интересная и полезная статья, спасибо.
В п.3.3. "Дублирование в «нарисованном»" вы пишете о возможностях текстовых IDE по поиску повторов кода, противопоставляя их визуальному поиску на картинке. Прошу пояснить, в каком виде утверждается ТЗ на подобные бизнес-системы?
Предлагается сразу писать код без согласования логики с "не-программистами"?
Зачем так экономить на бытовых условиях?
В чем профит?
На мой взгляд, статья - классическая ошибка проектирования.
Преждевременная оптимизация.
ну а реактор-то? Реактор-то видели?
Основатель Group-IB дал совет из СИЗО, как вернуть уехавших из РФ айтишников
насколько я понимаю, это история успеха:
а это другое:
кстати, что там насчет Т-платформ? Помнится, на одном из заседаний АРПЭ Иван Покровский предлагал коллективное письмо подписать с просьбой освободить генерального директора из-под стражи.
собственно, МИФИ - хорошая иллюстрация: автоматчики есть, а реактор Маша вряд ли видела
Автор с энтузиазмом неофита начал огораживание и разграничение.
Пока на уровне джуна.
На мой взгляд, почти все перечисленные в статье типы программистов вполне могут вписаться в нормальный коллектив и приносить ощутимую пользу бизнесу - кто-то любит уникальные фреймворки проектировать, кто-то сложные реалтайм задачи отлаживать, кто-то типовые конфигурации быстро клепать, а некоторые - предыдущее легаси сопровождать.
Сомневаюсь, что в таком виде это можно продать председателю кооператива.
Продукты (цели) описаны очень обобщенно - непонятно, какие конкретно задачи решаются.
Хотя, для минсельхоза, возможно, зайдёт...
можно поподробнее?
за счет чего такая экономия денег и времени?
Ну зачем вы сразу так... Возможно, это хорошо продаётся...
ну не знаю, судя по фото и без мяча есть на что посмотреть
На мой взгляд, результаты инструментального контроля и повторный проход дяди Васи вообще-то должны быть прописаны в технологическом маршруте.
во-первых, для анализа качества
во-вторых, для учета трудозатрат и машиночасов на деталь
понятно, что дядя Вася будет избегать ввода значений, потому что ему платят за детали, а не за вводы, кроме того, как и все люди, он хочет поменьше надзора.
Поэтому желательно, чтобы ввод значений был как можно более автоматизирован и реально экономить дяде Васе время. Например, сменой измерительного щупа по автоматизированной программе. Как вариант, чтобы новый код нельзя было загрузить без выполнения операций контроля.
И главное: никогда нельзя на усмотрение исполнителя изменять операции.
Кстати, буквально вчера разбирались по браку с подрядчиком - выяснили, что технолог, обнаружив отклонение в техпроцессе (как позже выяснилось - по причине деградации оборудования), внес изменения, которые ему показались корректирующими. Результат немного предсказуем.
Если у вас постоянно новая номенклатура можно ввести обобщенную операцию со всеми возможными шагами и пропускать их - это гораздо проще контролировать.
в целом подход с распределенным управлением интересный.
какие средства есть для изменения технологических маршрутов и изменения типа и количества данных при операциях?
Прошу прощения, поясню, я думаю, эту историю должны держать в уме все, кто занимается робототехникой:
40 лет назад для борьбы с наступлением японских производителей GM открыла полностью роботизированную "Factory of Future": https://www.nytimes.com/1984/10/20/business/gm-factory-of-future-will-run-with-robots.html
через 10 лет закрыла: https://apnews.com/article/3e78974c3c94990405ce607326d29223
Вывод: за потраченные средства, GM могла просто купить Toyota и Nissan:
здесь можно почитать: Case Study: GM and the Great Automation Solution https://mba.tuck.dartmouth.edu/pages/faculty/syd.finkelstein/case_studies/01.html
Спасибо за познавательную статью, подход выглядит перспективно, практически "Factory Of Future"...
Стек выбранных технологий тоже произвел впечатление
переносимый язык позволяет кроссплатформенную отладку
я не фанат Форта, просто ваши комментарии противоречат целям заявленным в статье
Вы абсолютно правы.
Продолжу: в статье предложено свести оптимизированные к архитектуре синтаксисы ассемблеров к некоему обобщенному.
Как вы считаете, этот подход позволит использовать "преимущества современных процессоров с кучей регистров"?
...потом появится желание обеспечить повторное использование программ для различных ядер, чтобы по два раза не переписывать
...для этого понадобится привести архитектуры к одному общему виду
...называется это Форт