На всякий случай уточню — это сарказм, связанный с тем, что expect — традиционно юниксовый инструмент автоматизации, ваш трукрипт живёт под сервером 2003, а упоминание AutoIt вы решили не заметить?
А чего бы не сделать так, чтобы ноутбук всё сам делал с утра пораньше — при помощи средств типа AutoIt или expect, уверен, это будет гораздо прикольнее, чем всякие там обеликсы с астериксами. И пароль надёжнее хранится. Самое сложное — это объяснить ноуту, что надо утром проснуться раньше вас, а потом заснуть обратно, когда всё сделает.
Строго говоря, меня WiFi как канал для HD тоже не впечатлил ни разу. Поэтому тоже кабельное подключение делал в аналогичной ситуации (Synology + роутер + выигрыватель медиафайлов).
Думаю, последнее можно обобщить — документация по любому стандарту может появляться вместе с системой.
Популярная книжка, конечно, требует какой-то живой экосистемы продукта, но хочется подчеркнуть, что дефолтная документация не должна быть убогой. Как раз наоборот.
Попробую в двух словах дать выжимку своих ощущений от этой темы.
(В идеале) должно быть удобно и понятно пользователю продукта. Иначе говоря, тут две переменных — продукт и его целевая аудитория.
Неказистый (недостаточно хорошо спроектированный) продукт порождает сложную документацию. Не в последнюю очередь потому, что разработчики и сами не понимают, что представляет из себя этот продукт (к примеру, в вашем случае это может быть из-за недостаточно узкого определения продукта и недостаточно проработанных требований к нему; далее отсылаю к Алану Куперу).
Клёвый продукт документировать легко, потому что целевая аудитория чётко определена. Автору тогда не нужно писать все возможные варианты документации, потому что он не представляет, чего захочется людям.
Простейший пример: *никсовые маны. Информационная плотность манов очень велика, воды там минимум, потому что они ориентированы на очень узкую ЦА, системных администраторов и внимательных энтузиастов. Никому не придёт в голову писать для утилиты wc набор (five minute intro, ten minute intro, fifteen minute intro, faq, api reference, developer's manual).
С другой стороны, если совокупная сложность продукта превышает определённый порог, иногда полезнее написать книгу, чем стописят манов, факов и экзамплов. Примеры из жизни: sendmail, bind. Книгами по подобным инструментам люди пользуются с куда как большим удовольствием, чем «родной» документацией. Почему так? И почему, скажем, разработчикам байнда было сразу не написать увлекательную книжку, как поступили Крикет и Ли?
Отдельный разговор — внутренняя документация для разработчиков. Для них иногда самая клёвая документация — это UML-диаграммы. И больше не надо ничего.
И вот как на это всё можно натянуть ГОСТ? На мой взгляд, никак. Польза ГОСТа, равно как и прочих стандартов, в, простите, стандартизации. То есть когда число продуктов начинает превышать какой-то обозримый минимум, возникает идея, что всё должно быть единообразно — для упрощения и ускорения процессинга этих самых продуктов. Если для академической среды это хорошо, не факт, что это будет хорошо для конечного потребителя.
Другой момент — если люди не хотят напрягать мозг насчёт документации, они могут применить стандарты, и сэкономить на этом. Если формат продукта такой, что это допустимо, ничего страшного нет. Если продукт клёвый (см. выше), возможно, есть смысл задуматься, как применение стандартов отразится на конечных пользователях. (Хотя мне кажется, у авторов клёвых продуктов вообще изначально забота о пользователях выше.)
Какие-то схемы, примеры и списки я приводить, пожалуй, не буду — кажется, особого смысла нет. Могу сказать, что для текущего продукта выбрал неформальный формат для руководства пользователя — почти полностью отказался от безличных оборотов, формальных конструкций языка, и вообще ориентируюсь на то, чтобы развлекать читателя. Насколько это оправданно — покажет время.
А почему это хороший техписатель будет стоить разумных средствов? :) Типа, слова писать — наука не точная, не то что девелопмент, потому и стоит дешевле?
А потом окажется, что заказчик «имел в виду» полный комплект, который при сертификации обязательно нужен. :-) Вся потребность в документации по ГОСТу, на мой взгляд, и сводится к сертификации или иным подобным мероприятиям. В противном случае выгоднее писать так, чтобы пользователю было удобно и понятно, а не по ГОСТу.
Если перефразировать Догму, — У создателей ГОСТов прекрасное чувство юмора. Взять хотя бы бумажную документацию на 1С.
Интерактивность типа откручивания головы кабану уже есть в других играх, вышедших раньше DNF. Из недавно игранного — Vanquish на PS3. Мастурбацией джойстика достигаются различные эффекты в рукопашной с роботами.
Что-то вспомнилось, как лет шестнадцать (?) назад Intel разыгрывала на выставках процессор Pentium 60. (Бэкграундом — очень зелёная трава и очень высокие деревья.)
Популярная книжка, конечно, требует какой-то живой экосистемы продукта, но хочется подчеркнуть, что дефолтная документация не должна быть убогой. Как раз наоборот.
Потому что хороший разработчик стоит дорого. И хороший автор — тоже. А разумные деньги — это вообще миф.
(В идеале) должно быть удобно и понятно пользователю продукта. Иначе говоря, тут две переменных — продукт и его целевая аудитория.
Неказистый (недостаточно хорошо спроектированный) продукт порождает сложную документацию. Не в последнюю очередь потому, что разработчики и сами не понимают, что представляет из себя этот продукт (к примеру, в вашем случае это может быть из-за недостаточно узкого определения продукта и недостаточно проработанных требований к нему; далее отсылаю к Алану Куперу).
Клёвый продукт документировать легко, потому что целевая аудитория чётко определена. Автору тогда не нужно писать все возможные варианты документации, потому что он не представляет, чего захочется людям.
Простейший пример: *никсовые маны. Информационная плотность манов очень велика, воды там минимум, потому что они ориентированы на очень узкую ЦА, системных администраторов и внимательных энтузиастов. Никому не придёт в голову писать для утилиты wc набор (five minute intro, ten minute intro, fifteen minute intro, faq, api reference, developer's manual).
С другой стороны, если совокупная сложность продукта превышает определённый порог, иногда полезнее написать книгу, чем стописят манов, факов и экзамплов. Примеры из жизни: sendmail, bind. Книгами по подобным инструментам люди пользуются с куда как большим удовольствием, чем «родной» документацией. Почему так? И почему, скажем, разработчикам байнда было сразу не написать увлекательную книжку, как поступили Крикет и Ли?
Отдельный разговор — внутренняя документация для разработчиков. Для них иногда самая клёвая документация — это UML-диаграммы. И больше не надо ничего.
И вот как на это всё можно натянуть ГОСТ? На мой взгляд, никак. Польза ГОСТа, равно как и прочих стандартов, в, простите, стандартизации. То есть когда число продуктов начинает превышать какой-то обозримый минимум, возникает идея, что всё должно быть единообразно — для упрощения и ускорения процессинга этих самых продуктов. Если для академической среды это хорошо, не факт, что это будет хорошо для конечного потребителя.
Другой момент — если люди не хотят напрягать мозг насчёт документации, они могут применить стандарты, и сэкономить на этом. Если формат продукта такой, что это допустимо, ничего страшного нет. Если продукт клёвый (см. выше), возможно, есть смысл задуматься, как применение стандартов отразится на конечных пользователях. (Хотя мне кажется, у авторов клёвых продуктов вообще изначально забота о пользователях выше.)
Какие-то схемы, примеры и списки я приводить, пожалуй, не буду — кажется, особого смысла нет. Могу сказать, что для текущего продукта выбрал неформальный формат для руководства пользователя — почти полностью отказался от безличных оборотов, формальных конструкций языка, и вообще ориентируюсь на то, чтобы развлекать читателя. Насколько это оправданно — покажет время.
Если перефразировать Догму, — У создателей ГОСТов прекрасное чувство юмора. Взять хотя бы бумажную документацию на 1С.
www.razgovorchiki-v-stroyu.ru/?p=58
Внимание на «Например».
Если кто делает такие мышки на продажу, заходите в личку, пообщаемся.