Спасибо за неравнодушный комментарий.
Согласен, все так и есть, но вот целью статьи как раз и является привлечение внимание к тому, как должны и могут обстоять дела в области информационной и функциональной безопасности АСУ ТП. Даже, несмотря на то, что не все идеально в настоящий момент, что-то может быть изменено в сторону улучшения. И начальство тоже можно воспитывать различными методами ))
Добрый день, а на практике какой-то беспилотник использовался?
По тексту: поле Component ID на рисунка названо COMP, а в тексте COM, может быть на рисунке лучше использовать поля, как названо в исходнике?
Спасибо за статью, Airbnb действительно серьезный сервис, который решительно «подвинул» классические отели на рынке услуг.
И все же, крайне важным является организация взаимодействия с пользователями.
Из интересных оргфишек Airbnb я бы отметил службу решения конфликтов между гостями и хозяевами: выявление проблемных персон, отслеживание проблемных ситуаций, поиск «внезапно исчезнувших» людей и вещей.
Из проблем можно отметить уже слишком большую комиссию (больше 20%) и всяческие «болезни роста», такие как: слишком частая и непродуктивная смена интерфейса с потерей уже существующих записей, частое и долгое модерирование, медленное внедрение типовых функций UI/UX (например, нельзя создать он-лайн репозиторий фото, повторяющиеся фото надо загружать каждый раз заново), «потеря» транзакций и их «ручное» восстановление
С точки зрения Java, подход во многом новаторский. Однако, есть ли смысл реализовывать на Java то, что хорошо ложится на языки функционального программирования?
Спасибо, мне статья понравилась.
В частности, статья позволяет констатировать тот факт, что существуют преподаватели, небезразличные к студентам и учебному процессу.
Спасибо за ссылку. Тогда, если доступны глобальные данные, может быть, есть смысл их использовать не только для борьбы с ожирением, а и с другими вредными привычками? Например, если кто-то увеличивает объем физических упражнений, то, скорее всего, он(она) меньше курит и употребляет алкоголь (если раньше, конечно, была такая привычка). То есть, по прямым или косвенным данным можно решать целый комплекс социальных и медицинских проблем, а не только какую-то одну
Отличная статья на социальную тему. Однако, хабр подразумевает ещё и определённую конкретику в технических решениях. А какое здесь техническое решение предлагается? Какие датчики, какие приложения? Только лишь EMC Integrated Patient Record? Но это ведь другой уровень IoT
Спасибо автору, по-моему это все потрясающе! В трех цифрах можно выразить все наши знания о пространстве — изящно и ненавязчиво.
А весь этот фестиваль геометрии, очевидно, как-то связан с Вашей профессиональной деятельностью или такое вот хобби?
А меня вот заставило задуматься то, что материалу уже 30 лет и актуальности он почти не потерял. Нам всем кажется, что мы вечные и гениальные… А много ли из того, что мы сегодня делаем и пишем будет иметь смысл, пусть даже не через 30 лет, а лет через 5?
В итоге имеем.
Статья на хабре по истории программирования и вычислительной техники опубликована не на основании интерпретации исторических материалов теми, кто по объективным причинам не может знать, как обстояло дело в 1970-80-е гг., а непосредственным участников событий.
Хорошо это или плохо? Из чьих рук мы можем получить более достоверные факты? Много ли остается людей «в строю», которые помнят, как выглядели СМ, ЕС и каково с ними было работать?
Можно еще на всякий случай взглянуть на «послужной список» Владимира Николаевича Орлова, чтобы объективно составить мнение о том, является данный материал фальсификацией или нашей общей историей.
Опять же интересный факт — тот, кто «поймал за руку», обратил внимание на шеврон военнослужащего, а не на то, что в 1987 году не существовало в природе подобных системных блоков, клавиатур, мониторов и принтеров.
Да, иллюстрация 1987 г. несколько неуклюже заменена на более современное (но опять же на сегодняшний день историческое) фото. Да, когда ты первый раз делаешь публикацию на социально-профессиональном ресурсе, сложно безупречно вести полемику, и это не зависит от возраста.
Я бы предложил участникам дискуссии на секунду задуматься о том, что для нас важнее: факты и история или эмоции и единоразовое «yes, я его сделал!»
Для ответа на подобный вопрос существует спецификация и контекст использования, так называемый «здравый смысл», хотя спецификация в спорных вопросах лучше.
В «спецификации на велосипед», например, может быть сказано (это, конечно, один из многих вариантов): «основная функция — транспортировка пассажира(ов) с использованием педального привода». Если так, то, для этой функции порванная цепь — это отказ.
Может быть и другая функция: «транспортировка груза при движении человека рядом (ведет велосипед за руль)». Для такой функции разрыв цепи не является отказом.
Об этом и многом другом на данную тему хорошо написано в старом ГОСТ ГОСТ 27.002-89 НАДЕЖНОСТЬ В ТЕХНИКЕ. ОСНОВНЫЕ ПОНЯТИЯ. ТЕРМИНЫ И ОПРЕДЕЛЕНИЯ, ну и в учебниках по теории надежности тоже.
Сейчас в области терминологии по надежности действует ГОСТ Р 53480-2009, который является переводом довольно старого словаря МЭК 60050 (191):1990-12. С одной стороны, классно, интегрируемся с мировым сообществом. С другой стороны, уж не знаю почему, но из стандартизации выброшены методические наработки, которые создавались десятилетиями и за последние 30 лет так и остались непревзойденными.
Спустило колесо — это отказ, поскольку основная функция (передвижение) выполнена быть не может.
Сбой — это, например, погнутый обод или потерянная спица. Велосипед функционирует, но с некоторой деградацией: ограниченная скорость езды.
В теории это относится к общей надежности
По этому поводу могу сразу ответить, что последние лет 5 существует внутренняя инструкция IEC, в которой определено, что в стандарте должны присутствовать Foreword, Introduction, а также 4 вводных раздела:
1 Scope
2 Normative references
3 Terms and definitions
4 Abbreviations
После этого идёт основная часть, которая строго не регламентирована
В более ранних стандартах эти вводные части несколько варьируются, но смысл тот же.
На мой взгляд, отдельной публикации это не заслуживает
Согласен, все так и есть, но вот целью статьи как раз и является привлечение внимание к тому, как должны и могут обстоять дела в области информационной и функциональной безопасности АСУ ТП. Даже, несмотря на то, что не все идеально в настоящий момент, что-то может быть изменено в сторону улучшения. И начальство тоже можно воспитывать различными методами ))
По тексту: поле Component ID на рисунка названо COMP, а в тексте COM, может быть на рисунке лучше использовать поля, как названо в исходнике?
И все же, крайне важным является организация взаимодействия с пользователями.
Из интересных оргфишек Airbnb я бы отметил службу решения конфликтов между гостями и хозяевами: выявление проблемных персон, отслеживание проблемных ситуаций, поиск «внезапно исчезнувших» людей и вещей.
Из проблем можно отметить уже слишком большую комиссию (больше 20%) и всяческие «болезни роста», такие как: слишком частая и непродуктивная смена интерфейса с потерей уже существующих записей, частое и долгое модерирование, медленное внедрение типовых функций UI/UX (например, нельзя создать он-лайн репозиторий фото, повторяющиеся фото надо загружать каждый раз заново), «потеря» транзакций и их «ручное» восстановление
В частности, статья позволяет констатировать тот факт, что существуют преподаватели, небезразличные к студентам и учебному процессу.
А весь этот фестиваль геометрии, очевидно, как-то связан с Вашей профессиональной деятельностью или такое вот хобби?
Статья на хабре по истории программирования и вычислительной техники опубликована не на основании интерпретации исторических материалов теми, кто по объективным причинам не может знать, как обстояло дело в 1970-80-е гг., а непосредственным участников событий.
Хорошо это или плохо? Из чьих рук мы можем получить более достоверные факты? Много ли остается людей «в строю», которые помнят, как выглядели СМ, ЕС и каково с ними было работать?
Можно еще на всякий случай взглянуть на «послужной список» Владимира Николаевича Орлова, чтобы объективно составить мнение о том, является данный материал фальсификацией или нашей общей историей.
Опять же интересный факт — тот, кто «поймал за руку», обратил внимание на шеврон военнослужащего, а не на то, что в 1987 году не существовало в природе подобных системных блоков, клавиатур, мониторов и принтеров.
Да, иллюстрация 1987 г. несколько неуклюже заменена на более современное (но опять же на сегодняшний день историческое) фото. Да, когда ты первый раз делаешь публикацию на социально-профессиональном ресурсе, сложно безупречно вести полемику, и это не зависит от возраста.
Я бы предложил участникам дискуссии на секунду задуматься о том, что для нас важнее: факты и история или эмоции и единоразовое «yes, я его сделал!»
А другие материалы этой серии из 'Техника и наука' сохранились?
В «спецификации на велосипед», например, может быть сказано (это, конечно, один из многих вариантов): «основная функция — транспортировка пассажира(ов) с использованием педального привода». Если так, то, для этой функции порванная цепь — это отказ.
Может быть и другая функция: «транспортировка груза при движении человека рядом (ведет велосипед за руль)». Для такой функции разрыв цепи не является отказом.
Об этом и многом другом на данную тему хорошо написано в старом ГОСТ ГОСТ 27.002-89 НАДЕЖНОСТЬ В ТЕХНИКЕ. ОСНОВНЫЕ ПОНЯТИЯ. ТЕРМИНЫ И ОПРЕДЕЛЕНИЯ, ну и в учебниках по теории надежности тоже.
Сейчас в области терминологии по надежности действует ГОСТ Р 53480-2009, который является переводом довольно старого словаря МЭК 60050 (191):1990-12. С одной стороны, классно, интегрируемся с мировым сообществом. С другой стороны, уж не знаю почему, но из стандартизации выброшены методические наработки, которые создавались десятилетиями и за последние 30 лет так и остались непревзойденными.
Сбой — это, например, погнутый обод или потерянная спица. Велосипед функционирует, но с некоторой деградацией: ограниченная скорость езды.
В теории это относится к общей надежности
1 Scope
2 Normative references
3 Terms and definitions
4 Abbreviations
После этого идёт основная часть, которая строго не регламентирована
В более ранних стандартах эти вводные части несколько варьируются, но смысл тот же.
На мой взгляд, отдельной публикации это не заслуживает