Pull to refresh
13
0
Send message
имхо, ники можно заменять на 1: 2: 3:
в инфиуме еще и кнопки на тулбаре есть для доставания тегов ;) в 2010 они только в меню внизу
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 сервера?
невесту придется связать
IRC для инфиума давно есть
даже не знаю, что выбрать, все так заманчиво звучит

Information

Rating
Does not participate
Registered
Activity