Disclaimer: эта статья имеет практический смысл только для мак-пользователей. Остальным — разве что ради иллюстрации возможностей MacOSX.

Один из очень частых use case для многих людей, пользующихся компьютером — создание и размещение скриншотов.

Как часто вам нужно показать кому-то часть вашего экрана, окно какого-приложения, «фотографию» ошибки или что-нибудь забавное? Правильный ответ — чаще, чем вы это делаете. Потому что обычно все это достаточно сложно и неудобно. И вправду, ведь что нужно сделать для этого:

1. Собственно, сделать скриншот.
2. Сохранить его в файл.
3. Разместить где-то в интернете.
4. Получить http-ссылку на него.
5. Передать ее кому нужно.

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

Я хочу рассказать о способе быстрого создания скриншотов, который пригодится, как мне кажется, многим.

Исходная задача заключается в том, что мы хотим связать комиты в SVN с тикетами JIRA, причем:
1. Не должны пропускаться комиты без реально существующих тикетов в Jira
2. Непосредственно в Jira должна быть возможность посмотреть что (кто, когда...) комителось в SVN к контексте конкретного тикета.

Как оказалось не так просто нагуглить инфу на эту тему. Есть куча решений jira pre-commit hooks, но только одно (может и есть другие?!, но я не нашел) позволяет решить задачу «реально существующих тикетов в Jira». И так решения…

Желание стать эффективнее и производительнее приводит многих дизайнеров к поиску методов улучшения рабочего процесса. Одно из распространённых решений — использование нескольких мониторов, способное дать значительные преимущества. В этой статье рассматриваются «за» и «против» такого решения.

«ЗА»

+1) Производительности труда растёт

Наибольшее преимущество — это, конечно, рост производительности труда.

Было проведено немало исследований, которые пытались подсчитать как именно меняется производительность труда от внедрения мульти-мониторной системы. В соответствии с исследованием Jon Peddie Research производительность вырастает на 42%.

В отчёте Pfeiffer 2005 года говорится что в результате повышения производительности, инвестиция во второй монитор (или увеличение диагонали первого) может дать годовой прибыли до нескольких тысяч американских долларов.

Цель поста

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

1 Вступление

В топике освещаются не столько подробности работы с git, сколько его отличия от схемы разработки других систем контроля версий, и общий подход (выработанный по большей части личным опытом и Git Community Book) к работе.

1 Введение

В своей прошлой заметке я постарался осветить в общих чертах стиль работы с
распределенной системой контроля версий git и указать на отличия по сравнению с
классическими централизованными СКВ. Целью было прежде всего обобщение опыта
работы с системой без упоминания тонкостей синтаксиса отдельных команд.

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

Когда в коде фигурирует пара вызовов BeginXxx()/EndXxx(), это приемлимо. Но что если алгоритм требует несколько таких вызовов подряд, то количество методов (или анонимных делегатов) преумножится и код станет менее читабельным. К счастью, эта проблема решена как в F# так и в C#.

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

Не буду вдаваться в «водяные» слова о системе, скажу лишь, что она полностью web-based, включая админку. Крутится на платформе Mozart, ранее выложенной (ом) тем же ADV как open-source framework, и в качестве основы для описания всех процессов имеет собственный несложный xml-язык (мета-описание), с помощью которого описываются совершенно произвольные (почти без ограничений) формы, включая их print-версии, которых у каждого типа документа может быть несколько.

Тут у ADV на сайте все описано и показано скришотами. Ну а вообще все можно пощупать и поломать воочию на демо-сайте http://workflow.evidentsolutions.org/

Привет! Вот и пришло время публикации моего первого проекта на Silverlight 4.

Подробную статью читайте по данной ссылке

Им стал сетевой морской бой. Почему-то хотелось сделать в качестве первого проекта что-то сетевое, универсальное, чтобы люди еще могли и поиграть с ним. Так вот, месяц стараний, и встречайте. Он уже готов! Сначала хотелось использовать хваленые Domain services, но как-то с ними сразу не срослось. Поэтому для связи я использовал Workflow services. Это удивительно удобное средство для коммуникаций. Вы пишите блоки логики — Activity (я писал code activity) с входными и выходными параметрами, а потом вставлял их в Workflow service. Причем, у меня был всего лишь один файл XAMLX. Он генерировал автоматически интерфейс взаимодействия (Service contract), в корне у меня была Pick activity, а внутри ветвей у меня уже были Receive activity, которые получали параметры и передавали их на дальнейшее исполнение. И вот поглядите, что получилось: Морской бой онлайн. Если кого интересуют подробности, то смело обращайтесь ко мне и я расскажу, что к чему.

А вот и скриншотик:

Добрый день! Этот текст является подробной статьей о том, как я делал морской бой на Silverlight 4. Вдохновили меня на написание статьи Ваши комментарии. Исходные коды можно взять здесь. Тестовый логин test@mail.ru, пароль 123456. Но есть ограничение на то, что игроки должны иметь разные логины. Поэтому кто-то один должен быть обязательно зарегистрирован, иначе возникнет ошибка, которая будет скоро устранена.

На этой неделе пришлось столкнуться с Activiti — новым workflow движком для Java, и так как тема эта еще не обсуждалась на Хабре, решил поделиться впечатлениями. Сразу скажу — впечатления немного печальные, но об этом под катом

В данной статье я хочу рассмотреть пример создания простого приложения с использованием движка Activiti.

“Activiti” — это легковесная платформа (framework) для работы с бизнес-процессами (Business Process Managment), адаптированная для деловых людей, разработчиков и системных администраторов. Платформа основана на быстром и надёжном java-движке BPMN2-процессов. Проект OpenSource’ный и распространяется под лицензией Apache. Activiti может запускаться либо как часть вашего java-приложения, либо самостоятельно на сервере, кластере или облаке. Кроме того, она прекрасно интегрируется со Spring’ом.

Эта статья была опубликована еще в 2008 году на официальном сайте Adobe. В ней Nick Myers (ведущий визуальный дизайнер компании Cooper) рассказывает о преимуществах Fireworks в проектировании интерактивных продуктов.

Не бывает программного обеспечения без ошибок. Для учета ошибок в процессе разработки, как правило, используются баг-трекеры — программы, которые позволяют пользователям и тестировщикам сообщать о найденных ошибках, менеджерам — определять порядок исправления этих ошибок, а разработчикам — фиксировать факт исправления ошибок. Баг-трекер часто является основным средством взаимодействия команды разработки и пользователей, поэтому эффективность работы с ним так важна. В настоящее время выбор баг-трекеров достаточно велик. Среди них есть как бесплатные (Bugzilla, Mantis, Trac, Redmine), так и коммерческие системы (Jira, Fogbugz).

В нашей компании (JetBrains) долгое время использовалась Jira. Но в какой-то момент проблемы с производительностью и юзабилити этой системы заставили нас разработать свой собственный баг-трекер — YouTrack, ориентированный, как и другие продукты нашей компании, прежде всего на продуктивность команды. О системе YouTrack уже писали на Хабре два года назад, незадолго до выхода первой версии. С тех пор было уже три релиза, и теперь YouTrack для небольших команд стал бесплатным.

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

При попытке отредактировать этот старый пост слетело всё форматирование. Может быть я его когда-нибудь исправлю.

Я потратил несколько месяцев на борьбу с глюками Git-svn и обдумывание разных вариантов, прежде чем пришёл к этому методу организации рабочего процесса с сайтом — простому, гибкому и удобному в работе.

Основные преимущества:

• Делая push из удалённой копии мы автоматически обновляем live-копию сайта
• Правки файлов на сервере не будут разрушать историю коммитов
• Простота, не нужны особые правила выполнения коммитов
• Можно применить к уже запущенному сайту, без повторного деплоя или перемещения файлов

 

После поста про автоматизацию заявок некоторые коллеги попросили меня поподробнее рассказать о workflow-редакторе Nintex и о тех подводных камнях, на которые можно наткнуться при его использовании.

Я познакомилась с этим редактором ровно 2 года назад, когда ко мне подошел шеф и сказал: «Выучишь Nintex — поедешь в Казахстан». Для меня в тот период карьеры лучшей заманухи просто быть не могло. Надо сказать, что работа с этим редактором лично для меня все эти 3 года была скорее удовольствием и игрой, чем действительно работой.

Я не хочу подробно рассказывать о возможностях этого продукта, потому что, во-первых, не хочу pr-a, а, во-вторых, эта информация наверняка есть на каких-то специализированных сайтах. Я хочу рассказать о тех фактах, которые стали решающими в выборе Nintex и о тех подводных камнях, с которыми я сталкивалась.

Рабочие процессы — важная и почти обязательная составляющая портала на SharePoint, они являются основой документооборота и многих других бизнес-процессов. Неудивительно, что существуют такие системы как Nintex, пытающиеся расширить и дополнить возможности стандартных рабочих процессов.

По опыту работы с Nintex могу сказать, что данная система не лишена недостатков: дороговизна, периодически возникающие ошибки, общая неторопливость системы (хоть это свойственно всему SharePoint) — все это вынуждает меня использовать штатный механизм рабочих процессов. Однако, у Nintex есть важное преимущество — визуализация схемы и текущего состояния процесса. Благодаря этому создание рабочих процессов упрощается, и их могут создавать даже люди, достаточно далекие от программирования (контент-менеджеры, бизнес-аналитики и т.д.). В SharePoint 2010 есть аналогичная возможность создания рабочего процесса на основе визуальной схемы, используя Visio 2010 и SharePoint Designer 2010.

Продолжая тему двух предыдущих постов (первый и второй), в которых проводилось исследование на тему управления знаниями и были рассказаны основные результаты, хотелось бы углубиться в практическую составляющую данной проблемы. Вопросов для обсуждения здесь предостаточно, но основной — существуют ли инструменты, позволяющие удовлетворить все потребности бизнеса в части управления знаниями? Попробуем ответить на этот вопрос со своей «колокольни».

В данном видео демонстрируется технология Axxerion Workflow. Эта технология является ключевым компонентом SaaS системы Axxerion и применяется для автоматизации различных бизнес-процессов. В видео показано создание и исполнение workflow заявки на техническое обслуживание.