Здравствуйте! Меня зовут Елена Толмачева. В компании «ДоксВижн» я занимаюсь разработкой пользовательской документации.

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

Когда .NET разработчик слышит слова «В проект нужно добавить workflow», то первым приходит в голову идея взять Windows Workflow Foundation.

В 2010 году мы выбрали WF в качестве движка документооборота.

Аргументы просты:

• Бесплатно;
• Встроено в Visual Studio;
• В интернете много информации об использовании WF.

За полтора года (с августа 2010 по февраль 2012) использования WF мы столкнулись с массой разнообразных проблем при реализации требований клиента. В конечном итоге мы были вынуждены отказаться от Windows Workflow Foundation и сделать свою реализацию State Machine.

В этой статье я расскажу об основных проблемах, с которыми мы сталкивались, и как решали (или не решали).

В этой теме хотелось бы познакомить читателей с относительно новым подходом к контролю доступа под названием Attribute-based access control. Знакомство будет происходить на примере сравнения с популярным нынче Role-based access control.

Недавно мой друг, программист, рассказал, что он не читает требования, а вместо этого приглашает аналитика на чашку чая, они вместе садятся, и аналитик рассказывает, что должно быть реализовано. Мой друг — умный человек и хороший программист, и причина, почему он получает знания о требованиях именно так, не в том, что ему лень читать документацию, а в том, что, даже прочитав ее, он до конца не разберется, что же надо сделать. В данной статье я хочу рассказать, как можно написать требования к программному продукту так, что программисты не просто используют требования, но и участвуют в их написании; на основе собственно опыта я хочу показать, каким образом можно описать требования, чтобы эти описания были достаточными для реализации системы.

Целью нашей разработки было создание с нуля учетной системы для одной из крупных российских компаний. Система была призвана заменить текущую, написанную в конце 90-х. В результате были реализованы платформа и один из бизнес-модулей. В реализованной части было порядка 120 объектов, 180 таблиц, около 30 печатных форм.

Хочу оговориться, что подход, описанный ниже, не универсален для написания любого ПО. Он подходит для систем уровня предприятия, которые строятся на основе объектно-ориентированного подхода: учетных, CRM-, ERP-систем, систем документооборота и т.п.

Вся документация на наш программный продукт состояла из следующих разделов:

• Общая часть
  • Список терминов и определений
  • Описание бизнес-ролей
  
• Требования
  • Бизнес-требования
  
  • Общие сценарии
  • Сценарии использования
  • Алгоритмы и проверки
  • Системные требования
  • Нефункциональные требования
  • Требования к интеграции
  • Требования к пользовательскому интерфейсу
• Реализация
• Тестирование
• Руководства
• Управление

Содержание

• Введение
• Величины, типы и операторы
• Структура программ
• Функции
• Структуры данных: объекты и массивы
• Функции высшего порядка
• Тайная жизнь объектов
• Проект: электронная жизнь
• Поиск и обработка ошибок
• Регулярные выражения
• Модули
• Проект: язык программирования
• JavaScript и браузер
• Document Object Model
• Обработка событий
• Проект: игра-платформер
• Рисование на холсте
• HTTP
• Формы и поля форм
• Проект: Paint
• Node.js
• Проект: веб-сайт по обмену опытом
• Песочница для кода

Мечта, ради которой создавалась Сеть – это общее информационное пространство, в котором мы общаемся, делясь информацией. Его универсальность является его неотъемлемой частью: ссылка в гипертексте может вести куда угодно, будь то персональная, локальная или глобальная информация, черновик или выверенный текст.

Тим Бернес-Ли, Всемирная паутина: Очень короткая личная история

Пользуясь регулярно подходом ABC of ICT обнаружил что информации об этом крайне мало (сам познакомился благодаря ссылке где-то в комментариях). Под руки попалась неплохая статья по методике и решил ее перевести, возможно кто-то после захочет ближе познакомиться с этим подходом к развитию и управлению процессами в компаниях.



Оригинал опубликован на сайте GamingWorks (создатели наиболее популярных бизнес-симуляций для IT всего мира)

Много текста

Предлагаю вашему вниманию перевод и адаптацию статьи Сьюзан Вайншенк — «The Psychologist’s View of UX Design».
Предупреждаю, что статья может содержать много «банальных» утверждений. Однако, считаю, что это ничуть не умаляет её общеобразовательной ценности.

… Все вы, наверное, слышали притчу о слепцах и слоне:

Один мой товарищ недавно активно искал работу, и спрашивал меня, как себя подавать перед работодателем. Погуглив, мы пролистали с десяток статей о том, как надо и как не надо делать во время поиска, и одну из них я решил перевести для хабрасообщества, возможно кому-то это поможет избежать ошибок, которые в ней описаны. Манера статьи довольно провокационная, язык местами нецензурен, поэтому я постарался сгладить углы. Итак, поехали..

Навеяно этим постом от юзера case. Пост не новый, и на главную он не попал.
Но я вот наткнулся на него сегодня и решил написать кое-что о сне. Уверен, что это будет полезно многим хабравчанам, да и случайным читателям тоже.

В программировании занято гораздо больше мужчин, чем женщин. С этим фактом не поспоришь, поэтому любому руководителю необходимо учитывать психологию мужчин в программировании.

Обратимся к древним временам, когда мужчина охотился на мамонтов, а женщины сидели дома, рожали детей и готовили еду. Чтобы охотиться, мужчина очень долго готовился, точил топор, готовил стрелы и лук. Потом он долго сидел в засаде и наконец делал выстрел или наносил удар. Эта особенность поведения трансформировалась и дожила до наших дней. Мужчину отличает способность к повышенной концентрации на выполняемой работе. Это большой плюс и большой минус. В отличие от женщины мужчина не может выполнять несколько дел одновременно.

Продуктивность у одного и того же человека может отличаться в зависимости от времени суток, настроения, коллектива, фазы луны, а иногда и от политической ситуации в Гондурасе. Понятно, что на некоторые факторы вы не в силах повлиять, но сделать жизнь программиста проще, а как следствие — продуктивнее, вам вполне по силам. Итак, что же для этого нужно?

Не устанавливайте рамки

Вроде бы эта тема многократно обсуждалась, но, тем не менее, многие компании заставляют приходить программистов в 9 утра, забывая, что работа разработчика – это творческий процесс (спросите своих сотрудников, как часто решение насущной проблемы приходит во время прогулки, в метро, во время секса), который трудно сочетается со стандартным офисным расписанием. А если еще учесть, что большинство проектов идут из обеих Америк (смещение времени до -8:00), то обязательный приход в 9:00 тем более выглядит странным решением.

Сегодня в рынке потихоньку-полегоньку приживается идея проектирования для интернет-ресурсов, но идея исследования аудитории в рамках проектирования приживается хуже. На Хабре была опубликована пара статей на эту тему:

• Как самостоятельно провести исследование перед проектированием сайта
• Обработка результатов предпроектного исследования

Мы любим «затачивать пилу» и улучшать наши навыки, поэтому мы пригласили в гости Александра Туника (altunik), автора этих статей и руководителя проектной студии «Тектоника», провести у нас в компании курс лекций, посвящённых именно исследованию контекста и аудитории, необходимому для проектирования сайтов.

В результате получился очень интересный и объёмный набор обучающих материалов, которыми мы, по договорённости с Александром, открыто делимся. Под катом — тезисы, видеозаписи и слайды с трёх семинаров.

Стартап Bountify — это нечто среднее между StackOverflow и фриланс-биржей. Принцип работы очень прост — заказчик публикует задачу или вопрос и вносит предоплату от 1 до 250 долларов. В течение недели любой желающий может предложить решение. Вознаграждение достаётся тому, кого выберет заказчик. Если предложено несколько примерно равноценных вариантов, или кто-то сделал ценные замечания и дополнения к решению-победителю, заказчик может дополнительно вознаградить тех, кто внёс свой вклад. Если решения нет, деньги уходят на благотворительность.

Ключевой гарантией качества является открытость — в отличие от фриланс-сервисов, обсуждение вариантов проходит публично, любой может указать на ошибку или улучшить решение. Открытость работает и в обратную сторону: в профиле заказчика можно посмотреть, насколько щедро он раздаёт дополнительные вознаграждения участникам дискуссии.

Предисловие

Изменение .NET метода MSIL кода во время выполнения приложения – это очень круто. Это настолько круто, что можно перехватывать вызовы функций (hooking), сделать защиту своего ПО и другие удивительные вещи. Именно поэтому мне уже давно хотелось это осуществить, но была одна проблема – MSIL код компилируется в машинный код с помощью JIT перед тем, как мы сможем что-либо с этим кодом сделать. А так как .NET CLR не документирована и изменяется от версии к версии, то мы и будем искать стабильный и надёжный путь, независимый от точного расположения адресов в памяти.

Хорошие новости! В электронной библиотеке TechNet (E-Book Gallery for Microsoft Technologies) опубликованы переведенные на русский язык электронные книги (EPUB, MOBI, PDF) по технологиям Windows Azure.

Миграция приложений в Windows Azure

Миграция приложений в Windows Azure, 2-й выпуск
Справочник\руководство Patterns & Practices

Это первая книга в серии patterns & practices, посвященной платформе Windows Azure. В книге рассматривают различные аспекты (изменения в архитектуре, вопрос стоимости, мониторинг и диагностика системы и т.п.) миграции локального приложения на облачную платформу Microsoft – Windows Azure. В книге описана миграция на примере приложения aExpense, это ASP.NET приложение согласования авансовых отчетов. Во-первых, книга поможет получить хорошее представление о тех вопросах, которые необходимо учесть при миграции приложения в облако, а, во-вторых, в книге даются ответы на ряд практических задач, которые являются актуальными не только при миграции приложения, но и просто при разработке любого облачного приложения.

EPUB | MOBI | PDF

Привет!

О плагине JsTree на хабре упоминалось лишь в далеком 2009 году. С тех времен все довольно сильно поменялось. Плагин активно развивается. Страница проекта на гитхабе.

Учитывая специфику проекта, над которым сейчас работаю(справочная система), этот плагин оказался просто незаменимым, и я использую 90% его функционала с превеликим удовольствием. И я до сих пор не видел такой же мощной альтернативы.



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

Что мы имеем?

• Построение дерева на основе html разметки, json и xml формата
• Drag & drop с тонкой настройкой возможности перемещения нодов по дереву
• Динамическое добавление/удаление/изменение нодов
• Возможность построения нескольких деревьев на одной странице и манипуляция нодами между этими деревьями
• Возможность присвоения нодам произвольных типов (file, folder, drive, да какой угодно), и указать отдельное поведения для каждого
• Поддержка тем оформления (на скрине в начале статьи пример того, как это реализовал я)
• Управление с клавиатуры
• Использование нативных и кастомных чекбоксов
• AJAX подгрузка нодов, запоминание состояния дерева
• Плагин красиво и читабельно написан, позволяет писать дополнительные плагины к нему и без проблем кастомизировать.
• Удобная система байндингов для обработки событий
• Мультиязычность
• Управление анимацией раскрытия
• Поиск по дереву
• Кастомное контекстное меню
• Поддержка браузеров: IE 6+, Firefox 2+, Safari 3+, Opera 9+, Chrome
• Мини-фича, которая меня особенно порадовала — плагин wholerow — выделения нода во всю ширину. А-ля mac style

В далёком 2005 году я менял стек технологий с Java на .NET и поначалу в Visual Studio мне очень не хватало возможностей, которыми располагала IntelliJ IDEA. Пробуя различные плагины к студии, я остановился на ReSharper'е и по сей день его использую. Недавно стало интересно, есть ли похожие продукты для работы с SQL Server, а точнее с T-SQL кодом хранимых процедур. Собственно про один такой продукт я и хочу рассказать в этой статье.

Итак, SqlCodeGuard – это бесплатный addin для SQL Server Management Studio для статического анализа T-SQL кода. Ну и плюс пара-тройка других возможностей.

Хочу поделиться с обществом собственным плагином, который упрощает работу с динамическими формами и называется jqDynaForm. Под динамическими формами я подразумеваю формы, в которые при заполнении пользователь может добавлять по необходимости дополнительные поля или блоки полей. Разумеется, в каждом месте разрешено добавлять только заранее разрешенные виды блоков. Вот примеры подобных простейших форм:

1. Контактная форма, в которой есть поле «телефон». Пользователь может добавить еще несколько дополнительных полей для телефонов, если возникнет желание.

2. Счет на оплату. Есть фиксированный набор полей, таких как «имя плательщика» и «номер счета». Кроме того, есть таблица с позициями. Каждая позиция состоит следующих полей: «наименование», «количество», «цена». Пользователь может добавлять произвольное количество дополнительных позиций.

Давайте рассмотрим работу с jqDynaForm на примере такого счета. Вот пример такой формы:

Добрый день. Наша команда (без ссылок, это не важно) решила попробовать новый инструмент-компилятор Saltarelle в разработке своего проекта и, так как Хабр часто нам помогал полезной информацией, решили внести и свой скромный вклад в его копилку знаний и перевести запись в блоге разработчика.

На хабре уже было много статей о распределенных системах управления версиями (DVCS), их сравнений, а также сравнений GUI-клиентов для них. Также были обсуждения плагинов к IDE для работы с git и mercurial. Но практически не было информации об инструментах визуального сравнения и разрешения конфликтов слияния.


Недавно я «перескочил» с mercurial (который до сих пор считаю более удобным и логичным) на git, потому что, подавляющее большинство проектов, которые мне интересны, используют git и хостятся на github. В связи с этим, встал вопрос о пересмотре арсенала инструментов, в частности вопрос выбора инструмента визуального сравнения и слияния (diff and merge). Дабы восполнить недостаток информации на хабре, я решил написать этот мини-обзор. Как говориться — по горячим следам.

Под катом Вы также найдете примеры настроек Git для использования с DiffMerge и WinMerge под Windows. Думаю многим сэкономит время.