Компания-создатель облачной IDE Cloud 9 на конференции NodeSummit, посвященной Node.js, планирует представить ряд новых улучшений в своем продукте, попутно представив сообществу англоязычный сборник документации по Node.js, который доступен по адресу nodemanual.org.

Весь сборник разделен на две части — Basic и Tutorials; при этом как таковых «HowTo» для новичков нет, поэтому можно сказать, что целевой аудиторией сайта являются все же профессионалы в Node.js. Авторами большинства статей называются разработчики Mozilla и Joyent, а примеры, представленные в документации, можно запустить в Cloud9, имея в ней аккаунт. GitHub сборника можно найти здесь.

Также Дениэлс намерен представить и блог nodebits.org, направленный на "… поддержание духа Node.js и инновационности". Сейчас блог не отличается большим числом статей (первая датируется только 30 декабря), но его обещают пополнять, называя среди авторов ведущих разработчиков Node.js-сообщества Тима Касвелла, Берта Белдера и Бена Нурдхаиса (Tim Caswell, Bert Belder, Ben Noordhuis).

[NodeManual]

Для просмотра разной внешней документации (man/perldoc/pydoc/etc.) в Vim есть множество плагинов и рецептов. Проблема в том, что одни не настраиваются на открытие окон с документацией удобным мне способом, другие не расширяются для поддержки новых источников документации, третьи глючат и написаны слишком криво чтобы их можно было относительно просто пофиксить и выслать патч автору. На днях меня эта ситуация окончательно достала, и я написал плагин viewdoc, решающий все эти проблемы.

Он прост внутри и удобен в использовании, предоставляет единый пользовательский интерфейс для работы с любой документацией (включая встренный :help), умеет определять требуемую документацию по контексту, гибко настраивается, и очень просто расширяется (внешними плагинами или прямо в ~/.vimrc) для добавления новых источников документации. Основной недостаток — тестировался только в linux, может работать в других *nix, точно не будет работать в винде.

Дыры в информационной безопасности бывают разные. Бывают дыры в софте, бывают в железе, бывают в головах людей. А еще бывают в документации. Вот, к примеру, прямо сейчас на сайте весьма известного в Украине банка лежит инструкция, призывающая пользователей корпоративного интернет-банкинга доверять любым фишинговым сайтам, выдающим себя за банк, забивая при этом на все предупреждения браузера о неверных сертификатах. А ведь хотели, наверное, сделать людям полезную доку. Но получилось как всегда.

Вместе с выходом второй версии фреймворка CakePHP обновилась и документация — book.cakephp.org/2.0/. А самое главное, появилась офлайновая дока. Скачать можно прям с первой страницы кукбука: CakePHPCookbook.epub. Можно скачть с гитхаба исходники или помочь с переводом и исправлением.

Мне было лень искать что-то, что читает формат .epub и я просто распаковал файлы и получил много html страничек. Такая документация выглядит примерно так. Zip с html страничками качаем отсюда

Все, кто может, помогайте с переводом туториалов. Координация на форуме pattr.ru
pattr.ru/forum/perevod-oficialnyh-tutorialov-maxmsp/spisok-otkrytyh-perevodov

Сегодня был интересный разговор с одним потенциальным клиентом. Думаю следует отнести его к разделу юмор, но я уже в середине разговора хотел послать клиента к чертям.

Upd: Для нетерпеливых: пошаговые инструкции по созданию переводов.

Русская документация PHP

Добрый день Хабрасообщество!
Как многим известно, вот уже долгое время на php.net нет русской версии документации PHP. Это не значит, что работа по переводу была прекращена, а результаты этой работы пропали.
Дело в том, что перевод документации — добровольное дело, и добровольцев, скажем так, не много. Один-два человека старались удержать перевод на плаву, но все равно в конце концов документация устарела и скорее вводила в заблуждение тех, кто ей пользовался, нежели помогала в освоении языка. Где-то в 2008 г. в команде переводчиков никого не осталось, потом документация устарела настолько, что процесс сборки (куда входит синхронизация с английской версией) сломался и русский мануал исчез с официального сайта до «лучших времен». Медленное и мучительное возрождение документации началось в октябре 2010 г., но с тех пор оно с каждым днем набирает обороты.

Сегодня мы поговорим об отечественных стандартах на проектную документацию. Как эти стандарты работают на практике, чем они плохи и чем хороши. При разработке документации для государственных и серьезных частных заказчиков у нас обычно нет выбора — в требования по документированию ТЗ вписано соблюдение стандартов. На практике мне приходилось сталкиваться с различными примерами недопонимания структуры стандартов, того, что должно быть в документах и зачем эти документы нужны. В итоге из-под пера техписателей, аналитиков и специалистов выходят порой такие перлы, что непонятно, в каком состоянии сознания они писались. А ведь на самом деле все достаточно просто. Поиск по Хабру не вернул ссылок на более-менее целостный материал на данную тему, потому предлагаю закрасить этот досадный пробел.

Что такое стандарты на документацию?

В серии 34, о которой идет речь, существует всего 3 основных стандарта по документированию:

ГОСТ 34.602-89 Техническое задание на создание автоматизированной системы

Самый любимый и популярный стандарт по разработке ТЗ. Единственное, не стоит забывать, что он крепко связан с другими стандартами серии и если вы получили ТЗ, выполненное по данному стандарту, крайне желательно придерживаться и других стандартов, даже если об этом нет прямых требований. Хотя бы в плане общей идеологии (о которой ниже)

ГОСТ 34.201-89 Виды, комплектность и обозначения документов при создании автоматизированных систем

Это базовый документ, в котором приводится полный перечень документации ГОСТ 34, рекомендации по кодированию документов, к каким стадиям проекта относятся документы (стадии описываются в ГОСТ 34.601-90), а также как их можно объединить между собой.

Фактически, этот стандарт представляет собой большую таблицу с комментариями. Ее можно загнать в Excel для удобства использования.

РД 50-34.698-90 Автоматизированные системы. Требования к содержанию документов

Объемистый стандарт, с различной степенью детальности описывающий содержание проектных документов. В качестве индекса используется упомянутый выше ГОСТ 34.201-89.

К стандарту РД 50-34.698-90 существует множество вопросов и трактовок его положений, которые ввиду их неконкретности, часто понимают по-разному заказчик и исполнитель или даже члены проектной команды. Но ничего более конкретного у нас, к сожалению, нет.

Рассмотрим теперь плюсы и минусы стандартов, начав традиционно с минусов.

Совсем скоро выйдет релиз Symfony 2. И хотелось бы читать документацию,
да и обсуждать вопросы, связанные с фреймворком, на родном языке.
Именно с этой целью был создан новый русскоязычный сайт о Symfony 2.
Но так как объем документации достаточно велик, в одиночку переводить становится трудно.
Это призыв к помощи, к коллективному переводу и обсуждению документации.
Для этого вы можете воспользоваться формой на сайте или же редактировать страницы
напрямую, через GitHub.
И да — это реклама, немного преждевременная, т.к. пока сделано совсем мало.
Проект не несет какой-либо прибыли, единственная цель —
сплотить русскоговорящих разработчиков, использующих Symfony 2.
Надеюсь, вам понравится!
PS на топик-ссылку не хватает кармы.