5 роликов, все с одинаковым содержимым и одним репортажем. Орт такое орт. Показывают постоянно какое-то интернет кафе и эникейщиков, втентакле. У них это, похоже, такой дефолтный ролик фоновый для репортажей про энторнед.
Интересно, почему они вирусного аналитика сюда приплели.
Я лишь показываю вам примеры того, когда ваш стройный список грехов разваливается. Примерно половина «грехов» применима только к простому софту вроде блокнота. Когда речь заходит о сохранности данных, о безопасности, о защите от кривых рук — приходят ограничения и блокировки, устранение которых может стоить разработчиков больших денег и времени. А это в нашем изменяющемся динамичном мире, порой, равносильно смерти.
То есть надо ограничить параллельность браузером и текстовым редактором? И это нужно всем юзерам, потому что у вас так?
То есть я не смогу монтировать фильмы в Final Cut Pro?
Чем отличится работа за компьютером во время установки от работы при полностью установленной системе? В любой момент времени вы можете захотеть сделать что-то, что может не только усложнить жизнь программистам, но и усложнить жизнь самому себе.
Лучше почитайте книжку, как и во время кипячения воды ;)
Отрицаете, да. Final Cut это хорошо, но этой программой мир не заканчивается. Заниматься работой во время установки будет значительно дольше, чем установить и потом работать. Упираемся в тот же винт, в те же ограничения по оперативной памяти, в необходимость блокировки периферийных устройств (все та же защита от дурака — где гарантии, что юзер не прострелит себе ногу и не удалит папку в процессе инсталляции).
Даже MacOS не дает вам работать параллельно с установкой ОС.
Вопрос стоит в том, насколько опасно давать юзеру свободу. Параллелизм — это степень свободы, которую не всегда (и почти никогда) не нужно давать на откуп юзерам. Вы приводите в пример хром, который умеет обновлять себя сам. Возложите это на пользователей — и не будет хром наступать на рынок семимильными шагами, не будет роста поодержки новых фич, потому что у юзера «все итак работает»
Хорошо. Пусть вы будете правы.
Возражу только, что вы таки выдернули контекст как вам захотелось.
Юзер может быть и захочет параллелизма, но от этого задача быстрее не решится и ждать придется все равно. Пример? Форматирование диска C:\ перед установкой винды. Даже если я очень захочу, я не смогу начать установку сразу же, как почистилось достаточное количество секторов — головка диска от этого быстрее метаться не станет.
Не всегда стоит прогибаться под юзера, потому что, зачастую, юзер хочет совершенно противоположных вещей. Разработчик интерфейсов и программ должен в первую очередь решить задачу. Это потом появляется «желательно, побыстрее» и «и еще кнопку ПЫЩЬ».
Абсурдность примеров началась с примера про кипячение воды.
За сим, откланиваюсь. Желания вести беседу в пустоту нет.
Главную мысль я изложил выше. Вы же категорично встали в позу и всяко даете понять «Я все написал правильно, потому что я работаю юзабилистом и знаю, как правильно».
Думаю, на этом можно остановиться, аргументы вы, похоже, из принципа слушать не хотите. Дело ваше.
Мы так можем далеко зайти с примерами:)
Контраргумент «И что?» вообще интересный, против него ничего не скажешь, да.
Но, возвращаясь все таки к теме обсуждения: не все йогурты полезны. Параллелизм должен быть только там, где он возможен, и то, это исключительно по желанию разработчиков. Причислять это к грехам ко всем программам — имхо перебор
А если плита одноконфорочная походная?:) Я веду к тому, что программа, которая не дает юзеру делать что-то еще во время выполнения операции, делает это по одной простой причине — она не предполагает параллелизм на своей платформе. Примеров можно накидать хоть тысячу. Есть параллелизм процессов, если уж на то пошло.
Ваша статья уж слишком критичная и не учитывает, что некоторые ограничения налагают сами юзеры. Что параллелизм может быть просто не нужен, ибо ждать все равно придется.
Если язык реализации не принципиален — взгляните на code.google.com/p/libopcd/
Я в свое время на основе этой библиотеки делал OPC-шлюз, который выступал одновременно в роли OPC сервера и OPC клиента. Был источником данных для scada систем, брал данные из хозучета и другой скада системы по OPC, делал расчеты и суммарную инфу складывал уже в общезаводскую систему хозучета.
Серверная часть там сделана на очень хорошем уровне. Чтение тегов же я тестировал на тестовом сервере от dOPC — имхо, лучший тестовый стенд для проверки на совместимость стандартам (испробовал штук 20, все фигня).
Вот с документацией да, очень туго. Найти в сети практически нереально, если не платить консорциуму за членство. Я нарыл только спеки на 3 DA и частично на 2 версию, а потом все методом тыка
Судя по всему вы проделали огромный труд, респект. Тоже заканчивал институт по этой специальности и даже поработал на производстве. Правда, со скада системами работал в основном на прикладном уровне. OPC, да разного рода мелкие утилиты. Как у вас обстоит дело с поддержкой стандартов OPC? Помню, неистово бесило, что каждая скада система реализовывала его не до конца. 3.0 то держит? XML DA? Сама скада может выступать в качестве OPC сервера?
Интересно, почему они вирусного аналитика сюда приплели.
То есть я не смогу монтировать фильмы в Final Cut Pro?
Чем отличится работа за компьютером во время установки от работы при полностью установленной системе? В любой момент времени вы можете захотеть сделать что-то, что может не только усложнить жизнь программистам, но и усложнить жизнь самому себе.
Лучше почитайте книжку, как и во время кипячения воды ;)
Даже MacOS не дает вам работать параллельно с установкой ОС.
Вопрос стоит в том, насколько опасно давать юзеру свободу. Параллелизм — это степень свободы, которую не всегда (и почти никогда) не нужно давать на откуп юзерам. Вы приводите в пример хром, который умеет обновлять себя сам. Возложите это на пользователей — и не будет хром наступать на рынок семимильными шагами, не будет роста поодержки новых фич, потому что у юзера «все итак работает»
Возражу только, что вы таки выдернули контекст как вам захотелось.
Юзер может быть и захочет параллелизма, но от этого задача быстрее не решится и ждать придется все равно. Пример? Форматирование диска C:\ перед установкой винды. Даже если я очень захочу, я не смогу начать установку сразу же, как почистилось достаточное количество секторов — головка диска от этого быстрее метаться не станет.
Не всегда стоит прогибаться под юзера, потому что, зачастую, юзер хочет совершенно противоположных вещей. Разработчик интерфейсов и программ должен в первую очередь решить задачу. Это потом появляется «желательно, побыстрее» и «и еще кнопку ПЫЩЬ».
Абсурдность примеров началась с примера про кипячение воды.
За сим, откланиваюсь. Желания вести беседу в пустоту нет.
Думаю, на этом можно остановиться, аргументы вы, похоже, из принципа слушать не хотите. Дело ваше.
Контраргумент «И что?» вообще интересный, против него ничего не скажешь, да.
Но, возвращаясь все таки к теме обсуждения: не все йогурты полезны. Параллелизм должен быть только там, где он возможен, и то, это исключительно по желанию разработчиков. Причислять это к грехам ко всем программам — имхо перебор
Ваша статья уж слишком критичная и не учитывает, что некоторые ограничения налагают сами юзеры. Что параллелизм может быть просто не нужен, ибо ждать все равно придется.
Я в свое время на основе этой библиотеки делал OPC-шлюз, который выступал одновременно в роли OPC сервера и OPC клиента. Был источником данных для scada систем, брал данные из хозучета и другой скада системы по OPC, делал расчеты и суммарную инфу складывал уже в общезаводскую систему хозучета.
Серверная часть там сделана на очень хорошем уровне. Чтение тегов же я тестировал на тестовом сервере от dOPC — имхо, лучший тестовый стенд для проверки на совместимость стандартам (испробовал штук 20, все фигня).
Вот с документацией да, очень туго. Найти в сети практически нереально, если не платить консорциуму за членство. Я нарыл только спеки на 3 DA и частично на 2 версию, а потом все методом тыка