CustisWiki - Новые страницы [ru]

Agile Learning: Программируем и тестируем. Людей.

2010-11-09T00:39:20Z

BenderBot: 1 версия

SECR-2010: Отчет Белобородова Дмитрия

2010-11-03T14:03:11Z

BenderBot: 1 версия

Agile Learning: Эффективные инструменты

2010-11-02T11:53:39Z

BenderBot: 1 версия

Все блюда для интранета из MediaWiki

2010-10-28T11:51:38Z

BenderBot: 1 версия

Slide Show

Warning: legacy <slide> parser hook used, change it to <slideshow> please

Заголовок: Все блюда для интранета из MediaWiki
Автор: Виталий Филиппов
Нижний колонтитул: Все блюда для интранета из MediaWiki
Дополнительный нижний колонтитул: Виталий Филиппов, 03:03, 29 октября 2010

UNTITLED

2010-10-25T15:38:58Z

81.19.66.77: Dummy article created for Simple Forms extension

Dummy article used by Extension:SimpleForms

Учет ценных бумаг - сделать сложное простым (Цепков на SECR-2010)

2010-10-19T12:23:57Z

VitaliyFilippov:

Доклад был сделан на банковской секции конференции SECR-2010

Презентация выложена на slideshare

Докладчик: Максим Цепков, главный архитектор компании CUSTIS (Заказные ИнформСистемы)

Название доклада: Учет ценных бумаг - сделать сложное простым (Securities Accounting - Make It Easy).

Вакансия ведущего разработчика .Net

2010-10-04T14:13:18Z

StasFomin:

В направлении «Торговые сети» компании CUSTIS открыта вакансия Ведущего разработчика C# в одну из проектных команд. Система (модуль «Модуль распределения товара») находится в стадии интенсивной разработки. Модуль будет представлять собой высоконагруженное трехзвенное line of business приложение, обеспечивающее движение товара в крупной розничной торговой сети в режиме 24х7. В решении применяются технологии Microsoft .NET (C# 3.0), СУБД ORACLE и ряд внутренних технологий компании.

Вакансия Team Lead (Java, Oracle)

2010-10-04T14:09:19Z

StasFomin:

В направлении «Финансовые Институты» компании CUSTIS открыта вакансия Team Lead в одну из проектных групп. Группа разрабатывает и развивает приложения, обеспечивающие бизнес-процессы в крупной финансовой организации. Приложения строятся в трехзвенной архитектуре с клиентскими интерфейсами в виде Web- или Swing-приложений. К приложениям предъявляются требования высокой надежности, эргономики и производительности.

Вакансия инженера-аналитика

2010-09-27T16:12:00Z

StasFomin:

Основные требования:

знание современных информационных технологий;
аккуратность и педантичность;
умение работать в команде;
опыт и желание общаться с клиентами компании и конечными пользователями;

желательны:
- опыт работы в IT-индустрии,
- знакомство с СУБД (SQL).

Предлагается участие в проекте разработки модуля направления «Торговые сети», включая:

тестирование;
техническую поддержку на этапе внедрения и сопровождения;
анализ требований заказчика;
написание постановок на доработку и развитие системы;
написание технической документации;
обучение конечных пользователей со стороны клиента (в зависимости от проекта).

Условия

Компенсация обсуждается индивидуально с каждым соискателем по результатам собеседования. Но в целом, наши зарплаты не ниже, и даже существенно выше рынка. Есть и медицинская страховка: поликлиники и стоматология. Уровень заработной платы адекватно отражает профессиональный и позиционный рост;
Работа в команде профессионалов: многие наши сотрудники являются признанными экспертами в индустрии, публикуются в СМИ, от бумажных до хабра, активно выступают практически на всех IT-конференциях, более того, мы сами организуем IT-конференции и открытые семинары. У нас давно выстроены Agile-процессы разработки (адаптированный SCRUM), сочетающие эффективность и гуманизм.
Комфортная работа: мы доверяем сотрудникам, и поэтому у нас нет жестких ограничений, таких как фиксации прихода-ухода, дресс-код, фильтрации интернет-трафика и т.п. Возможен гибкий график работы, и даже удаленная работа (по VPN). Мы не экономим на инструментах: компьютерах, софте, мебели и т.п. Например, стандарт по мониторам — качественный 24" (+ вспомогательный), по компьютерам — «Core i7 с SSD», и т.п.. Возможно совмещение работы с учебой на старших курсах.
Рост и развитие сотрудника: компания оплачивает участие сотрудников в конференциях и тренингах, поощряет профессиональную сертификацию. А внутри налажен процесс внутреннего обучения силами сотрудников.
Удобный офис в центре Москвы, в пятиминутной доступности от пяти станций метро: «Тургеневская», «Чистые пруды», «Сретенский бульвар», «Лубянка», «Китай-город». Для автовладельцев (и велосипедистов) есть охраняемая стоянка (платная), впрочем, можно бесплатно запарковаться в переулках.

Любые правки этой статьи будут перезаписаны при следующем сеансе репликации. Если у вас есть серьезное замечание по тексту статьи, запишите его в раздел «discussion».

Репликация: База Знаний «Заказных Информ Систем» → «Вакансия инженера-аналитика»

Вакансия ведущего разработчика Oracle

2010-09-27T16:09:03Z

StasFomin:

В подразделениях компании «Торговые сети» и «Финансовые институты» открыта вакансия ведущего разработчика Oracle.

Проектные команды «Торговых сетей» ведут разработку модулей ПО «Каталог товаров», «Финансовый», «Розничная торговля», «Общее квотирование», «Оптовые продажи» и других для ИС крупной торговой сети. Работа в рамках проектов включает в себя проектирование элементов системы, разработку базы данных, серверной бизнес-логики, пользовательских интерфейсов и механизмов межсистемной интеграции.

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

Проекты предусматривают применение технологической платформы на базе СУБД Oracle и ряда внутренних технологий компании.

Вакансия бизнес-аналитика

2010-09-27T16:04:45Z

StasFomin:

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

Работа над задачами потребует от Вас:

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

Ваша кандидатура особенно интересна нам, если Вы:

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

Вакансия ведущего разработчика Java

2010-09-27T15:59:49Z

StasFomin:

В направлении «Финансовые Институты» компании CUSTIS открыта вакансия ведущего разработчика Java в одну из проектных групп. Группа разрабатывает и развивает приложения, обеспечивающие бизнес-процессы в крупной финансовой организации. Приложения строятся в трехзвенной архитектуре с клиентскими интерфейсами в виде Web- или Swing-приложений. К приложениям предъявляются требования высокой надежности, эргономики и производительности.

Вакансия системного аналитика

2010-09-27T15:48:52Z

StasFomin:

В направлении «Финансовые Институты» компании CUSTIS открыта вакансия cистемного аналитика в одну из проектных групп. Группа разрабатывает и развивает приложения, обеспечивающие бизнес-процессы в крупной финансовой организации. Приложения разрабатываются с использованием Java и Oracle.

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

Презентация-трансформер: S5 на MediaWiki/Слайды

2010-09-22T14:53:48Z

VitaliyFilippov: /* Слайд GnuPlot */

Золотая середина: открытые системы поддержки разработки/Аннотация

2010-09-10T07:20:44Z

BenderBot: 1 версия

Наша тема — системы поддержки разработки. Коллективная разработка всегда сталкивается с одними и теми же проблемами групповой работы - над кодом, документацией, тестами, ошибками и требованиями, корпоративными знаниями, и каждый решает эти проблемы по-своему. Кто-то увлекается изобретением систем собственной разработки ("изобретают велосипед"), кто-то идёт к вендорам, кто-то покупает платные специализированные узконаправленные системы.

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

К сожалению, интегрированность закрытых инструментов обычно означает страшную негибкость и неудобства, если отклонится от магистральных сценариев. Плюс, конечно, дороговизна.

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

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

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

В нашем докладе мы не просто расскажем об опыте интеграции («Talk is cheap, show me the code» © Линус Торвальдс), мы идем на большее, — мы публикуем в open-source полностью все используемые нами системы, с доработками и расширениями. Мы предлагаем сообществу совершенно бесплатно установить все это у себя, и возможно, присоединиться к развитию этого инструментального фреймворка.

Золотая середина: открытые системы поддержки разработки

2010-09-02T12:57:50Z

BenderBot: 1 версия

Любая коллективная разработка программного обеспечения сталкивается с одними и теми же проблемами:

групповая работа над кодом, документами;
учет проблем, ошибок, требований;
документирование, накопление и циркуляция (поиск, трансляция, агрегация) знаний компании;
организация правильного тестирования.

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

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

Да, полно разных классификаций функциональности, которую должны обеспечивать эти системы asset management, requirements management/tracking, bug management, issue management, customer support/help desk, knowledge base, XXX management — очень легко запутаться, лично мы придерживаемся очень простой классификации, разделяя системы в случае учета — по основному объекту учета:

Исходный код/артефакты разработки: Системы управления версиями, вебинтерфейс к репозиториями, системы полнотекстового поиска.
Проблемы/ответственность: системы трекинга проблем, системы управления задачами, системы баг-трекинга.
Знания: вики-системы, блоги-форумы, коллаборативное документирование.
Интеграция информационных потоков: RSS-агрегаторы, почта.

Но почему же «тупое» сравнение систем «по функциональности» не работает? Почему разработчики с удовольствием используют на первый взгляд не очень функциональные, бесплатные системы, а если их заставлять использовать дорогие, «солидные» системы от именитых производителей — они яростно бунтуют?

Мы считаем, что при выборе систем, важно смотреть на классификацию по следующим двум осям:

Интегрированность: Снизу этой оси системы решающие частные задачи — управление версиями, вебинтерфейс к управлению версиями, поиск, совместное редактирование текстов, учет проблем и т. п. Сверху — интегрированные «комбайны», где все связано со всем (статьи-задачи-проблемы код), и центром интеграции обычно является IDE-разработчика.

Важно понимать, что это «неоднозначная ось» — интегрированней, не всегда значит лучше! Что-то приобретается (юзабилити стандартных сценариев, например), но что-то выплескивается вместе с водой! Теряется гибкость и некоторые возможности, которые разработчики (или, что хуже, маркетологи) посчитали ненужными! А иногда падает и юзабилити, когда куча лишней функциональности занимает интерфейс, но не используется разработчиком. Интегрированность иногда означает «интегрированность в рамках Одной Операционной Системы и Технологического Стека Одной Компании». Особенно это печально, в случае закрытой, платной системы, когда нет никакой возможности, что-то исправить, изменить, срезать углы… И уповать на платную поддержку бессмысленно — обычно платная поддержка это аутсорсинговый колл-центр, и повлиять на функциональность продукта «в свою сторону» — практически невозможно.

Закрытость-Открытость: Да, имеется в виду именно закрытость или открытость исходного кода — именно этот фактор определяет, как развивается продукт, силами сообщества (в случае открытого кода), или исходя из внутренних инженерно-технологически-маркетинговых соображений. Вообще, «закрытость-открытость» очень сильно коррелирует с «платностью-бесплатностью», хотя есть и исключения (например, можно купить исходники Jira), но в любом случае, даже если исходники открыты, но продукт платный, его развитие определяется не сообществом — мало кто будет контрибъютить свои доработки, развивая чужой, платный продукт.

Кстати, все больше распространяется мнение, что открытость софта позитивно коррелирует с качеством, надежностью и дешевизной техподдержки^[1].

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

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

В левом верхнем квадранте живут монструозные платные системы, обычно интегрирующие системы вокруг IDE (Visual Studio или Eclipse), или с вебинтерфейсом. Да, интеграция вокруг Visual Studio очень удобна для разработчика, работающего только в технологическом стеке Microsoft, и если в фирме вся разработка такая — выбор может быть вполне оправдан.

Если же часть компании работает с стеком J2EE, часть с LAMP, часть с Microsoft, часть — серверная логика на Oracle (и т. п.) — то все плюсы сразу становятся минусами.

Общая очевидная проблема — необходимость платить, причем эта проблема может стать достаточно существенной. Например, стоимость лицензий может быть больше стоимости добротного железа для разработчика. Плюс, как правило, такие систем закрыты, отсутствует возможность модификации системы и при этом, в систему жестко зашита интеграция с выбранным производителем (а не пользователем) стеком инструментов, закодированы какие-нибудь методологии и прочие «best practices», часто устаревшие на десяток лет, или слабоприменимые в ситуации пользователя, от которых никак нельзя избавиться. Несмотря на платность, в большинстве случаев нельзя повлиять на линию развития софта, уговорить производителя сделать нужные пользователю доработки, а платная «многоуровневая» поддержка, только изолирует разработчика системы от проблем пользователей, и зачастую неэффективна.

Так может рассмотреть открытые (бесплатные, и с открытым исходным кодом) интегрированные системы?

Такие есть, но их проблема — ограниченная функциональность, ибо в основном они ориентируются на удовлетворение основных потребностей небольших команд разработчиков, и как швейцарский нож — вроде бы умеет все, но слабо. То есть да, все интегрировано, но там — слабенький трекер, тут — слабая вики-система, где-то ещё — неразвитая система прав. (Например, у Pivotal Tracker ее вообще нет! Все имеют права на все!). Да, это удобно для небольших команд, где все друг-другу доверяют, но в коммерческой разработке, когда в компании больше 10 человек, это, вероятно, начнёт сильно жать.

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

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

Bugzilla: учет задач, ошибок, проблем, ведение журналов работ, учет оргфокуса.
Testopia: интегрированная с Bugzilla система управления тестами.
MediaWiki: документирование, постановки задач и требований, ведение базы знаний компании, и даже блогов сотрудников.
Subversion: вершина эволюции в централизованных системах контроля версий.

Также там находятся свободные системы, для которых нет свободных систем аналогов (и даже аналогов в мире платного софта):

ViewVC: веб-интерфейс к Subversion, важный «клей» между Subversion и остальными вебсистемами.
SVNSearch: полнотекстовый поиск по всей истории Subversion-репозитариев.
FeedOnFeeds: карманный «Google Reader», то есть корпоративный RSS-агрегатор с веб-интерфейсом.

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

Ещё пример: MediaWiki — отличная, можно сказать, ведущая вики-система, но из-за основной направленности — открытые энциклопедии, в ней не развита система прав. И более того — несмотря на то, что многие пользователи запрашивают хорошую поддержку прав в MediaWiki, её архитектура была и остаётся открытой. И более того — хорошо, если так и останется. Причина в огромном числе расширений, уже написанных, и ничего не подозревающих о системе прав, и открытом доступе к БД из любого расширения. Почему же это хорошо? Хорошо это потому, что если бы этого не было, не было бы и этого огромного числа расширений («глобально-надёжные» системы вроде неторопливой «энтерпрайз-лэвел» Java — не конёк огромных открытых сообществ разработчиков), а следовательно, и система не была бы так популярна, а следовательно, и развитие её было бы тоже замедлено.

И вообще, единая система прав и авторизации, — это самое важное, когда требуется «приручать диких животных» — то есть укрощать и интегрировать дикие вебсистемы.

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

Да, объем таких доработок будет относительно ничтожным, по сравнению с общим объемом системы (например, в MediaWiki больше 2 миллионов строчек кода и доработка/расширение в 100—200 строчек, будет меньше сотой доли процента).

И о таких подходах часто рассказывают на конференциях (как докладчики, так и участники) и в интернете.

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

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

Поэтому («Talk is cheap, show me the code» © Линус Торвальдс) мы идем на большее, — мы публикуем в open-source полностью все используемые нами системы, с доработками и расширениями. Кстати, еще одна проблема использования open-source — пользоваться им любят многие, но при этом не любят делиться своими доработками^[2].

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

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

↑ См. отчет Forrester: «ПО с открытым исходным кодом характеризуется лучшим качеством (76%), более высокой надёжностью (71%) и меньшими расходами на поддержку (71%)»
↑ См. «Open source's ardent admirers take but don't give» или перевод «Поклонники открытого ПО не склонны делиться. Логика автостопщиков»

Репликация: База Знаний «Заказных Информ Систем» → «Золотая середина: открытые системы поддержки разработки»

T

2010-08-27T16:32:51Z

VitaliyFilippov:

Ошибки (TemplatedPageList):

Неправильная опция )
Не задано ни одного ограничения. Полный список страниц не показывается.

РИТ-2010: Отчёт Виталия Филиппова

2010-08-19T11:46:14Z

BenderBot: 1 версия

Сайт конференции: http://www.ritconf.ru/
Даты проведения: 12-14 апреля 2010
Место проведения: Infospace (ИнфоПространство)

Организация нормальная. Затупов не было. Только Джонатан Вортингтон, разработчик Perl 6 / Rakudo, который очень любит beer/vodka и так далее, то ли не приехал, то ли приехал, но очень увлёкся beer/vodka и так далее, в первый день вместо него выступал Шитов. С едой всё в порядке, обед раздёлен на два — по часу с 45-минутным интервалом между ними, во время каждого «обеда» прекращает работу только один зал, а в остальных продолжаются доклады. Кофе-брейк вечером, очень мало плюшек, их сожрали в момент. В последний день было пиво и шашлык ~~из кролика~~. Кстати, о кролике: там был один товарищ, который умудрился купить билет на РИТ по тестовой цене в 50 рублей, которую после выкладки на боевой сервер не успели поменять. За скорость тестирования ему вручили приз — живого кролика, правда, карликового (то есть малопригодного для еды).

Была видеозапись и онлайн-трансляция (6 камер в каждом зале). Есть надежда, что видео с конференции не будет столь же бездарно пролюблено, как это было с Highload’ом.

«У меня сразу плохая новость — обед идёт сейчас и кончится где-то посередине доклада, так что … решайте …»

«Стас, ты сейчас либо оставишь людей без кофе-брейка, либо следующего докладчика — без аудитории»

Mindmaps: история и идеология

2010-08-19T00:32:59Z

StasFomin:

Видеозапись одного из регулярных внутренних семинаров.

Интеграция Open Source-систем для управления разработкой ПО (SECR-2007)

2010-08-19T00:24:51Z

StasFomin:

Выступление Стаса Фомина на конференции SECR-2007.

В некотором смысле сейчас устарело, вместо него рекомендуем посмотреть:

Но может представлять исторический интерес.

Введение в Subversion (Лекция 2009-03-31)

2010-08-19T00:07:22Z

StasFomin:

Лекция с курса «Разработчик СУБД», где мы готовили разработчиков информационных систем, владеющих всем инструментарием грамотного девелопера — системы контроля версий, управления конфигурациями и задачами, вики-системы и т.п.

Эта видеолекция «Введение в Subversion» — только введение, после были и практические занятия, и совместная командная работа над реальными проектами.

Есть и презентация (можно скачать и ее):

Да, в нашей компании основной системой контроля версий является именно Subversion, хотя есть несколько legacy проектов, до сих пор хранимых под CVS (мы не переносим их под SVN, т.к. все это имеет хитрую интеграцию с системами сборки и «проноса» версий). Местами у нас применяются и распределенные системы контроля (Mercurial и Bazaar), но в основном только для локальных операций конфигурационного управления, либо экспериментальных проектов. В целом, мы согласны с одним из идеологов Subversion, и мы рекомендуем прочитать серию его статей о Subversion в нашем переводе.

Репликация: База Знаний «Заказных Информ Систем» → «Введение в Subversion (Лекция 2009-03-31)»

РИТ:Высокие нагрузки-2008 (Отчет Стаса Фомина)

2010-08-18T18:48:24Z

StasFomin:

Замечания и предложения направлять автору.

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

Сразу замечу, хотя явно вроде не указано (в списке спонсоров-соорганизаторов десятки значков участников, даже «udaff.com»), что эту конференцию (highload.info, не путать с highload.ru) было бы правильней именовать «Яндекс:Нагрузки», ибо практически «контрольный пакет» всех докладов был от «Я», также было немало Я-участников в ~~узнаваемой униформе~~ креативных футболках. Похоже Яндекс тут был ключевым организатором, и ничего плохого в этом факте нет. Может стоило тогда так и назвать конференцию и провести ее на самой территории Яндекса, с экскурсиями по машинному залу и т. п. Когда-то (1999) я был в серверной Яндекса, но сейчас, думаю, там все сильно круче.

РИТ:Высокие нагрузки 2008 (Отчет Алексеева Алексея)

2010-08-18T16:37:49Z

BenderBot: 1 версия

Замечания и предложения высказывайте автору.

Отчет о посещении «РИТ: Высокие нагрузки 2008».

Макс: Application Developer Days 2010 - тезисы

2010-08-13T19:25:36Z

MaksTsepkov:

Автор: Максим Цепков, главный архитектор компании CUSTIS (Заказные ИнформСистемы).

Название доклада: Учетная машина — универсальная архитектура учетно-аналитических систем.

Запись доклада: Учетная машина (Максим Цепков на ADD-2010)

Хостинг для публикации наших проектов в open-source

2010-08-12T14:06:38Z

StasFomin:

Мы собираемся опубликовать большое количество наших внутренних доработок и расширений в open-source, и в связи с этим, нам интересно мнение наших потенциальных потребителей и контрибьютеров — какой хостинг кажется вам наиболее подходящим?

Голосуйте, каждый может выбрать три наиболее интересных варианта, вернее так — у вас есть три голоса, и вы можете распределить их среди представленных систем — можно три раза проголосовать за один вариант, можно по разу за три разных, можно … ну вы поняли.

Какой хостинг кажется вам наиболее подходящим?

Вы можете использовать 3 голоса.

Хостить на нашей площадке, с инфраструктурой Bugzilla, MediaWiki, Subversion, SVNSearch, ViewVC
SourceForge
github
Launchpad
Freepository
Google Code
Bitbucket
CodePlex
assembla
GNU Savannah
Tigris.org
Все равно

См. также сравнение свободных хостингов.

Why I prefer no tabs in source code (Так говорил Виталий)

2010-08-11T14:47:58Z

BenderBot: 1 версия

Документ Why I prefer no tabs in source code начинается с очень разумной строчки:

Многие программисты смешивают в исходниках пробелы с табами — символами табуляции с ASCII-кодом 09, вместо того, чтобы использовать несколько (обычно 8) пробелов вместо таба.

Но дальше, вместо того, чтобы эту мысль развить, автор зачем-то переходит к другим, не очень разумным аргументам. Поэтому и существует «контр-документ» http://derkarl.org/why_to_tabs.html, который с точки зрения чёткости аргументации мне нравится больше, несмотря на то, что сам я в своём коде всегда использую пробелы.

Менее переносимо. Вопрос — как понимать «переносимость». Противник табов рассматривает «личную» переносимость — то есть, он сам взял и перенесся за другой компьютер или другой редактор, настройки табов там другие, а код всё равно выглядит так, как должен. Защитник табов же наоборот, рассматривает «гуманистическую» переносимость — если код перенёсся к другому человеку, у которого маленький монитор — или большой, 24", но повёрнутый вертикально :-) — или же у которого личные предпочтения в 8 пробелов — этому человеку не придётся прикладывать дополнительных усилий для переформатирования.
Сложно смотреть diff’ы — вообще полный бред. Первый символ в unified diff’е это " ", «+» или «-» вне зависимости от того, табы там или пробелы. Однако с аргументами защитника табов я здесь тоже не согласен — понятно, что при изменении стиля отступов меняются почти все строки файла. Понятно, что стилей отступов пробелами много, а стиль отступов табами один, и внутри стиля изменения целого файла не будет.
Становится сложно двигать блоки кода влево-вправо, например на 2 колонки — а нахрена блок кода двигать на 2 колонки?!! (по-видимому, не равные полному уровню отступа) Блоки хорошего кода должны быть выровнены на целое (а не дробное) число уровней отступа! Если же речь о выравнивании комментариев и прочей мутоты вроде многострочных прототипов и вызовов функций — это задача, отличная от выравнивания блоков кода, и нефиг использовать табы и для выравнивания блоков кода, и для выравнивания комментариев. Короче говоря, снова побеждает защитник табов… Правда, привнося в жизнь своих соратников некоторый геморрой в виде необходимости постоянно следить за тем, где ставить табы, а где ставить пробелы.
…какой-то код был написан на emacs с табами по восемь пробелов, но со стилем отступов «Kernighan & Ritchie», где отступы в 5 пробелов… — это не проблема табов, это проблема людей, смешивающих в отступах блоков кода табы с пробелами.

Смешивание пробелов с табами — это как раз то самое ужасное, что может быть в форматировании кода! Например, в UNIX’е многие (похоже, стандартно) считают, что размер таба — 8 символов, но отступ при этом — 4 символа. Получается, что 1 уровень — это 4 символа, 2 уровень — 1 таб, 3 уровень — 1 таб и 4 символа, и т. п. А потом прихожу я со своим нормальным размером таба в 4 символа и несмотря на то, что с авторами софтины, которую я правлю, мы сходимся во мнении насчёт размера отступа, его код выглядит у меня совсем не так, как планировалось — нечётные и чётные уровни будут попарно равны, потому что 1 таб = 4 символа.

Кстати, в защиту табов есть ещё один аргумент — когда код выравнивается табами, нигде в середине файла не может случайно попасться строка, выровненная «нецелым» отступом в, например, 7 пробелов. Пример: строка-конец многострочного массива (PHP). То есть на строке скобка и точка с запятой «);». В том же файле перед закрывающимися скобками — пробелы. Пришёл человек и решил автоматически переформатировать код — заменить « )» на «)», то есть, убрать пробелы перед закрывающимися скобками. Итог — строка со скобкой выровнена на (n*4-1) символ.

А вышеописанные плюсы пробелов вовсе не в том, что выравнивание пробелами корректнее. Плюс пробелов в том, что с ними тупо проще:

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

Why I prefer no tabs in source code

2010-08-10T17:32:42Z

BenderBot: 1 версия

Adam Spiers «Почему в коде я предпочел бы обойтись без табов»

Перевод статьи Why I prefer no tabs in source code

Я заметил, что несколько человек зашло на мою статью с статьи Why I love having tabs in source code, где автор пытается оппонировать моим аргументам против использования табов. (Замечу также, что автор весьма невежливо не поставил меня в известность о своей заметке, и, тем самым, не дал мне удобной возможности ответить). Он поднял интересные вопросы, правда проигнорировал некоторые мои. Хотя возможно он просто их не понял, тогда это моя вина, что я сформулировал их более ясно. Если выдастся время, я попробую это исправить и ответить на его заметку с более конкретными, проясняющими мою позицию, примерами.

Итак, вернемся к моей статье.

Многие программисты смешивают в исходниках пробелы с табами — символами табуляции с ASCII-кодом 09, вместо того, чтобы использовать несколько (обычно 8) пробелов вместо таба. Да, это считается малозначительной вкусовщиной, но я считаю, что, как правило, это не шибко удачная идея, и ниже я поясню почему.

«Как правило» — это потому, что в любом правиле есть исключения, которые подтверждают все правила без исключения. Ниженаписанное относится в основном к свободному софту, потому что из-за «базарной»^[1] модели разработки высока публичность кода. Однако если вам не повезло, и вы работаете в компании не оставляющей никому выбора ни для правил отступов, ни текстового редактора, то, что поделать — эта статья вам все равно не пригодится.

Итак, это:

Менее переносимо, ибо разные редакторы/броузеры/просмотрщики отображают символ табуляции используя разное число пробелов, более того, большинство текстовых редакторов считают это пользовательской настройкой. Если вы используете пробелы без табов, вы никак и никогда не зависите от особенностей и настроек редакторов и просмотрщиков, вам не нужно выставлять им правильную ширину таба. Даже если вы готовы настраивать каждый редактор/просмотрщик под каждую используемую вами платформу, разве вы не усложняете жизнь остальным, кому надо читать и править ваш код?

Становится очень сложно читать diff-результаты, как контекстные, так и в формате unified diff, так как там первый столбец означает тип изменения строчки. Для многих разработчиков сейчас это очень важно. И даже если вы разрабатываете ваш код в одиночку, насколько вы уверены, что никому и никогда не взглянет на ваш код, не будет его править и уж совсем никогда не пошлет вам патчи?

Вообще у diff есть пара решений для этого — опции --expand-tabs и --initial-tab, но ни оба из них недостаточны.

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

Конечно, можно сказать все это не нужно, если у вас вменяемый редактор, делающий автоматический отступ, но автоматика не всегда срабатывает верно, особенно для Perl-а, когда даже GNU emacs не в силах разобраться с синтаксисом.

И опять таки, вы уверены, что никто кроме вас не захочет переформатировать ваш код? Точно уверены? Сто пудов? Уверены что вы никогда не будете копипейстить фрагменты кода в почте? Ну, представьте, что будет с этим кодом, кто-то ответить на такое письмо.

Аргумент «табы хороши, потому, что каждый может выбрать удобную для себя ширину отступов» не работает, потому что:

Табы используются не только в начале строк. Может многострочный комментарий, с левым выравниванием текста, но размещенный справа от кода, в общем, вглянем на реальный пример из /usr/include/gmp.h, найденный на FreeBSD-системе:

typedef struct
{
  int _mp_alloc;                /* Number of *limbs* allocated and pointed
                                   to by the D field.  */
  int _mp_size;                 /* abs(SIZE) is the number of limbs
                                   the last field points to.  If SIZE
                                   is negative this is a negative
                                   number.  */
  mp_limb_t *_mp_d;             /* Pointer to the limbs.  */
} __mpz_struct;

И теперь представим бедолагу сидящего за терминалом 80x25, и решившего просмотреть форматированный табами код, но, не с жирными 8 пробелами на таб, ведь было бы ужасно читать из-за переносов строк или выходов за границы экрана, а задав 2 или 3 пробела на таб. Итак, он печатает

 less -x2 foo.c

и бах — внезапно прямоугольные блоки комментария справа перестают быть выровненными по левому краю — что за фигня!

Проблемы могут быть даже если табы только в началах строк. Допустим, какой-то код был написан на emacs с табами по восемь пробелов, но со стилем отступов «Kernighan & Ritchie», где отступы в 5 пробелов. Если emacs настроен на использование табов, строчки с одним отступом будут отбиты пятью пробелами, строчки с двумя отступами будут отбиты табом и двумя пробелами (8 + 2 == 10).

Если кто-то еще захочет просмотреть этот код в редакторе/листальщике с табами по 4 пробела, то в строчках с единичной глубиной будет отступ на 5 колонок, следующий уровень — 6 колонок, третий уровень — 11 колонок… Упс!

Этот же аргумент можно адресовать и к пробелам. Хотите взглянуть на исходники, чтобы двухколоночные отступы показывались как четырехколоночные? Без проблем:

$ perl -pe 's/^((  )+)/$1$1/' foo.c | less

Хотите переформатировать 8-колоночные отступы в трехколоночные? Легко:

$ perl -pi -e 's/^( +)\1{7}/$1 x 3/e' foo.c

Очевидно, можно написать простой Perl-скрипт или макрос для редактора, чтобы сделать эти операции еще более простыми.

А вы что думаете?

Я всегда интересуюсь чужой точкой зрения на этот вопрос. Может я что-то упустил? Или даже вы попробуете доказать мне что, я ошибаюсь?!

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

Будь любезен, сделай всем одолжение! Напиши в свое ~/.emacs:

(setq-default indent-tabs-mode nil)

или в своей ~/.vimrc:

:set expandtab

Пишите, пожалуйста, мне, как это сделать в других текстовых редакторах.

↑ Метафора отсылает к известному эссе «Собор и Базар» о конкурирующих парадигмах разработки корпоративного и свободного программного обеспечения.

Why I love having tabs in source code

2010-08-10T17:21:49Z

BenderBot: 1 версия

Перевод статьи http://derkarl.org/why_to_tabs.html

Многие делают отступы пробелами. Но в целом, это плохая идея. Если бы табы использовали для отступов, а пробелы — для остального форматирования, проблемы бы не было. По крайней мере современные редакторы, такие как VIM и KWrite, нормально обращаются с табами.

Мои контраргументы к утверждениям статьи «Why I prefer no tabs in source code», агитирующей за пробелы:

Табы менее переносимы, ибо разные редакторы/броузеры/просмотрщики отображают символ табуляции используя разное число пробелов, более того, большинство текстовых редакторов считают это пользовательской настройкой.
Если вы используете пробелы без табов, вы никак и никогда не зависите от особенностей и настроек редакторов и просмотрщиков, вам не нужно выставлять им правильную ширину таба. Даже если вы готовы настраивать каждый редактор/просмотрщик под каждую используемую вами платформу, разве вы не усложняете жизнь остальным, кому надо читать и править ваш код?

На самом деле это более переносимо. Я не знаю никого, кто делает отступы пробелами, восемь раз нажимая на пробел, просто они обычно настраивают их текстовый редактор, что таб это восемь пробелов. И неважно, насколько «глубоки» и «широки» ваши табы, читатель просто настроит глубину табов как ему удобно, без необходимости переформатировать файл, ведь переформатирование файла (даже с одним отступом) делает сравнение полностью невозможным, ибо изменяется все! Табы решают эту проблему, можно интерпретировать их как 4-пробельные или 8-пробельные отступы, без изменения файла.

Становится очень сложно читать diff-результаты, как контекстные, так и в формате unified diff, так как там первый столбец означает тип изменения строчки. Для многих разработчиков сейчас это очень важно. И даже если вы разрабатываете ваш код в одиночку, насколько вы уверены, что никому и никогда не взглянет на ваш код, не будет его править и уж совсем никогда не пошлет вам патчи?

Это совершенная неправда, на самом деле, как я выше уже утверждал, отступы с табуляциями упрощают чтение diff-ов.

Становится сложно двигать блоки кода влево-вправо. Например, вы пытаетесь сдвинуть блок на две колонки вправо — и это не действует на строчки начинающиеся с табов.
Конечно, можно сказать все это не потребуется для вменяемые редакторов, которые делают автоматические отступы, но автоматика не всегда может сработать правильно, особенно для Perl-а, когда даже GNU emacs не в силах разобраться с синтаксисом.
И опять таки, вы уверены, что никто кроме вас не захочет переформатировать ваш код?

Автоматическое переформатирование ваших файлов с использованием sed или perl на самом деле гораздо легче, если используются табы, так как каждый уровень задается в точности одним символом, и не надо подсчитывать пробелы, пытаясь определить ширину таба — 8, 4 или сколько там еще пробелов. А редакторы, которые не справляются с табами, — это вовсе не редакторы, а недоразумение (вспоминается emacs).

Аргумент «табы хороши, потому, что каждый может выбрать удобную для себя ширину отступов» не работает, потому что:

Табы используются не только в начале строк. Может многострочный комментарий, с левым выравниванием текста, но размещенный справа от кода, в общем, вглянем на реальный пример из /usr/include/gmp.h, найденный на FreeBSD-системе:
typedef struct
{
  int _mp_alloc;                /* Number of *limbs* allocated and pointed
                                   to by the D field.  */
  int _mp_size;                 /* abs(SIZE) is the number of limbs
                                   the last field points to.  If SIZE
                                   is negative this is a negative
                                   number.  */
  mp_limb_t *_mp_d;             /* Pointer to the limbs.  */
} __mpz_struct;
И теперь представим бедолагу сидящего за терминалом 80x25, и решившего просмотреть форматированный табами код не из расчета 8 пробелов на таб, ведь это было бы ужасно читать из-за переносов строк или выходу за границы экрана, а задав 2 или 3 пробела на таб. Итак, он печатает less -x2 foo.c и бах — внезапно прямоугольные блоки комментарие справа перестают быть выровненными по левому краю — что за фигня!

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

Проблемы могут быть даже если табы только в началах строк. Допустим, какой-то код был написан на emacs с табами по восемь пробелов, но со стилем отступов «Kernighan & Ritchie», где отступы в 5 пробелов. Если emacs настроен на использование табов, строчки с одним отступом будут отбиты пятью пробелами, строчки с двумя отступами будут отбиты табом и двумя пробелами (8 + 2 == 10). Если кто-то еще захочет просмотреть этот код в редакторе/листальщике с табами по 4 пробела, то в строчках с единичной глубиной будет отступ на 5 колонок, следующий уровень — 6 колонок, третий уровень — 11 колонок… Упс!

Во-первых, K&R-стиль давно устарел. Ничего страшного, если вы смените K&R-стиль на табы, где табы ровно X пробелов, и где каждый столбец будет на уровне кратном X.

На самом деле, преимущество табов можно увидеть на примере CVS-репозитория kde.

В основном код там допускает отступы пробелами и большая его часть непоследовательно содержит пробелы и табы вперемешку.

И только малая часть модулей (aRts, Noatun) на 100% последовательна — та, где код форматируется табами.

Лучше делать форматировать так (обозначим табы подчеркиваниями, а пробелы — точками):

_____if.(true)....//This should be replaced
_____{............//with a proper boolean
__________func();
_____}

На любом уровне, все будет выравнено:

SomeClass::SomeClass()
_____.:.InheritingClass(false, false
_____...................5, 10, true,
_____...................bleh, blah)
{
// ....
};

// vim: ts=4 noet

Репликация: База Знаний «Заказных Информ Систем» → «Why I love having tabs in source code»

Test/Keepalive

2010-08-04T12:34:07Z

TestBot: Automatic test: 2012-10-25 14:19:44

Страница для автоматических тестов MediaWiki.

Automatic test: 2012-10-25 14:19:44.

Python x64 для Windows 7

2010-08-03T18:04:28Z

BenderBot: 1 версия

Под 64 битной Windows 7 есть желание и Python поставить 64 битный, чтобы щедро кормить его памятью, ну и вообще.

Однако те, кто расслабился и привык инсталлировать все расширения через easy_install ждет разочарование — нет готовых бинарников, увы (на лето 2010).

Что делать? Ну, совсем быстрое решение — воспользоваться благотворительностью добрых людей и поставить таки собранные бинарники под 64 бита, и опубликованные тут http://www.lfd.uci.edu/~gohlke/pythonlibs/

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

Но все же, большинство расширений скомпилируются и встанут, только нужно им правильно настроить C-компилятор.

Правильный компилятор — родной для питона 2.6 и 2.7 с python.org это Microsoft Visual C++ 2008.

Если вы счастливчик, и у вас он стоит и настроен, то скорее все будет ОК.

Но что делать тем, кто не собирается его покупать? Тут требуется пройти небольшой квест.

Установите Microsoft Visual C++ 2008 Express Edition (именно 2008, не 2010).
Пропишите путь C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC в переменную PATH.

Ни в коем случае не добавляйте этот путь в кавычках! Без кавычек!

Установите Microsoft Windows SDK for Windows 7 and .NET Framework 4 в пути по умолчанию. Ничего не меняйте!
Создайте файл

C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\bin\amd64\vcvarsamd64.bat

с содержимым

call "C:\Program Files\Microsoft SDKs\Windows\v7.1\Bin\SetEnv.cmd" /x64 /Release

Поправьте файл C:\Python27\Lib\distutils\msvc9compiler.py

в районе 648 строчки, после строк

            temp_manifest = os.path.join(
                    build_temp,
                    os.path.basename(output_filename) + ".manifest")
            ld_args.append('/MANIFESTFILE:' + temp_manifest)

добавьте строчку

            ld_args.append('/MANIFEST')

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

Сравнение DVCS - несколько задач

2010-08-02T15:02:34Z

BenderBot: 1 версия

Данная статья является очередным сравнением популярных DVCS — Mercurial, Git и Bazaar, с точки зрения нескольких нетривиальных задач.

Хотите лаконичный ответ в стиле «ИМХО» на вопрос — кого выбрать из трёх? Ну пожалуйста. Выбирайте Mercurial. А не Git (безумный конгломерат) и не Bazaar (пионерское поделие, унаследованное от Arch’а).

Интервью Стаса Фомина для ADD-2010

2010-08-02T08:03:04Z

BenderBot: 1 версия

Чтобы прояснить, какие люди замешаны в организации конференции Application Developer Days 2010, главный организатор конференции, Андрей Майоров взял интервью у председателя Программного Комитета Стаса Фомина.

Разработка систем на базе адаптивных моделей

2010-07-16T16:00:18Z

BenderBot: 1 версия

Большие проекты в Agile (AgileDays-Екатеринбург-2010)

2010-07-04T16:13:17Z

StasFomin:

Докладчик: Михаил Заборов

Креативное программирование 2.0

2010-06-16T12:45:18Z

VitaliyFilippov: Массовая правка: замена Категория:Рецензии на Категория:Рецензии на книги, замена Category:Рецензии на Category:Рецензии на книги

Автор(ы): Гласс Р.
Страница книги на сайте издательства: http://www.symbol.ru/alphabet/666333.html

Продуктивный программист. Как сделать сложное простым, а невозможное – возможным

2010-06-16T09:56:37Z

VitalyKozlovtsev:

Автор(ы): Нил Форд
Страница книги на сайте издательства: http://www.symbol.ru/alphabet/645323.html

FreeMind

2010-06-16T09:50:56Z

BenderBot: 1 версия

FreeMind — редактор «карт памяти». Инструмент для планирования и мозгового штурма, а также для иллюстрации текста красивыми «картами».

Инструменты в Agile (встреча AgileRussia.ru 2010-05-12)

2010-06-15T23:46:22Z

StasFomin: /* Дмитрий Лобасев */

12 мая в нашей компании прошла очередная миниконференция/встреча сообщества AgileRussia.ru.

Тема была заявлена достаточно широкая, «Инструменты в Agile», но в основном это были рассказы об используемых трекерах и процессах построенных вокруг них (планирование/коммуникация/мониторинг). Т.е. системы контроля версий, вики-системы, скайп и мессенджеры упоминались, но центром обсуждения оказались трекеры — TrackStudio, Redmine, Jira+GreenHopper, DevProm (ну и упоминались OTRS, Mantis, Bugzilla и даже Excel).

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

На возможный вопрос — а почему мы сами не рассказали об используемых у нас инструментах, ответим, что

Во-первых, мы только что рассказывали о них на двух конференциях подряд, и оба эти доклада опубликованы:
- Свободные системы, спасающие разработчиков (РИТ-2010)
- Knowledge Management: От Склада к Потоку (Software People-2010)
Во-вторых, мы бы не хотели злоупотреблять положением принимающей стороны, поэтому приоритет мы всегда отдаем нашим гостям.

Как обычно, мы опубликовали все возможные материалы — слайды, видео для вебпросмотра, видео в лучшем качестве для скачивания и сопроводили выступления нашей краткой рецензией.

Быстрое создание статей по шаблону

2010-05-25T12:56:10Z

VitaliyFilippov: Массовая правка: замена PCRE \n+\[\[Категория:Справка\]\] на <noinclude>Category:Справка</noinclude>

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

Можно больше — заполнить создаваемую статью не только «инструкцией о категории» но и любым произвольным блоком текста (шаблоном отчета, тест-кейса и т.п.). Для этого, для категории «XXX» нужно завести статью «Шаблон:Категория:XXX», и тогда ее содержимое будет подставляться при действии

«Создать статью в данной категории».

См. например, Категория:Тест-кейсы_(Bugzilla).

Репликация: База Знаний «Заказных Информ Систем» → «Быстрое создание статей по шаблону»

Софт - отстой! И что с этим делать?

2010-05-24T09:58:06Z

VitaliyFilippov:

Автор(ы): Платт Д.
Страница книги на сайте издательства: http://www.symbol.ru/alphabet/539043.html

Avisynth and Incorrect frame rate

2010-05-24T06:22:04Z

StasFomin: Новая страница: «I frequently encounter situations, when avisynth in VirtualDub preview showed all OK, but on saving video it doubles frame rate! Please, consider small sample: ...»

I frequently encounter situations, when avisynth in VirtualDub preview showed all OK, but on saving video it doubles frame rate!

Please, consider small sample:

clock.avi: AVI file, 32496 frames, 57:30.90, record for system clock, from 16:32 to 17:30
clock.avs: Dummy AVISYNTH script (DirectShowSource("clock.avi"))
Download example archive (≈200Kb): Файл:Clock.zip

If we open clock.avs in VirtualDub, and jump to frame at time 10:00, we see 16:42.

If we save the video (by VirtualDub, the codec does not matter) open saved video and jump to frame at time 10:00, we see 16:53.

What is going on? Is it bug or some feature?

SoftwarePeople-2010:Отчет Заборова М.А.

2010-05-20T17:47:42Z

MikhailZaborov: /* Питер Хрущка */

Моя страница на Круге

Software People 2010: отчет Игоря Беспальчука

2010-05-20T17:15:13Z

BenderBot: 1 версия

Моя страница на Круге

Сайт мероприятия: http://softwarepeople.ru/sp2010/; там все написано…

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

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

После заполнения анкеты подарили лицензию на Norton Antivirus и специальное («не для продажи») бумажное издание книжки про архитектуру от Microsoft, о которой я как раз недавно писал в блоге.

Народу на конференции было довольно много (если не сравнивать с РИТ’ом, конечно), большинство — молодые люди, 20-30 лет. Впрочем, сама конференция тоже молодая, проводится всего во второй раз.

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

Стас Фомин 16:16, 20 мая 2010 (UTC): Будет видео из всех залов

А какой у вас Agile: свежевыжатый или порошковый? (AgileEE-2009)

2010-05-07T07:43:56Z

StasFomin:

Андрей Бибичев, наш ведущий специалист по Agile и SCRUM, выступил на конференции Agile Eastern Europe с докладом «А какой у вас Agile: свежевыжатый или порошковый?»

«Презентации по-уму» — основные правила

2010-05-07T07:26:25Z

StasFomin:

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

Конечно, многие советы кажутся весьма простыми, в духе Старого Кэпа, но увы, судя по нашему опыту, 90% выступающих совершенно не рефлексируют над подачей материала. Мы сами не исключение — и на этом семинаре активно критиковались предыдущие, и даже он сам (Чтобы понять рекурсию, нужно сначала понять рекурсию…).

Смерть от PowerPointa выглядит наверное как-то так:

Ну мы то не являемся специалистами, нам можно и ошибаться, и все же, всем (даже если вам стало лень смотреть видео), рекомендуем хотя бы за 5 минут полистать великолепную Смерть через PowerPoint.

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

Из лично прочитанных книг, я (Стас Фомин) рекомендовал бы Slide:ology (я читал бумажную версию, но теперь эту книгу уже можно найти в электронном виде).

Если нравиться «Mac-way», усиленно дизайнерский подход ко всему, то рекомендую Prezentation Zen — это блог и одноименная книга, Apploвского эксперта по презентациям. (…есть в электронном виде…).

Если нужно «прокачать» не слайды, а само искусство выступления — смотрите конференции серии TED: Technology, Entertainment, Design.

Ну а если ваша основная цель — манипуляция аудиторией, для достижения своих целей — читайте «Presenting to Win: The Art of Telling Your Story» (тоже есть в электронном виде).

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

Репликация: База Знаний «Заказных Информ Систем» → ««Презентации по-уму» — основные правила»

Avisynth and frame drops

2010-05-06T20:14:35Z

StasFomin: Новая страница: «I frequently encounter situation, when avisynth drops frames, that leads to desynchronization of overlays. Please, consider small sample: ;100frames-src.avi: Sour...»

I frequently encounter situation, when avisynth drops frames, that leads to desynchronization of overlays.

Please, consider small sample:

100frames-src.avi: Source AVI file, 100 frames
bug-frames-skipped.avs: Dummy AVISYNTH script

Compressing src-avisynth-vdub.avi

О текстовом вводе замолвите слово (WUD-2009)

2010-05-06T08:53:54Z

StasFomin:

Выступление Андрея Бибичева, на конференции WUD-2009.

Современные системы до сих пор грешат излишней жесткостью и строгостью к пользователю в таком базовом и важном элементе, как текстовый (символьный, алфавитно-цифровой) ввод. Я расскажу про современный устойчивость к распространенным ошибкам ввода; про удобный поиск в одной строке; о силе интерфейсов, основанных на текстовой строке и на простых примерах покажу, что такое «ad hoc» анализ строк.

Проектируем время. Психология восприятия времени в программном обеспечении

2010-05-06T08:16:42Z

VitalyKozlovtsev:

Автор: Стивен Сеов
Страница издательства: http://www.symbol.ru/alphabet/638480.html
Рецензия

Репликация: База Знаний «Заказных Информ Систем» → «Проектируем время. Психология восприятия времени в программном обеспечении»

РИТ-2008 (Отчет Стас Фомина)

2010-05-05T19:30:16Z

BenderBot: 1 версия

Software People 2010: Отчет Стаса Фомина

2010-05-05T15:39:38Z

StasFomin: /* Риски управления рисками */

Отчет Стаса Фомина, все замечания, претензии и прочие комментарии welcomed (можно письмами, можно комментировать в блоге).

Несколько лет назад, озлобленный безумной организацией очередной IT-конференции я разродился длинным и ~~злобным~~ конструктивным постом на тему очевидных правил правильной организации IT-конференций. И эту запись читали многие организаторы конференций (были подтверждающие отзывы), но вот только эта конференция стала близкой к идеалу по организационным вопросам^[1].

Настолько близкой, что я позволил себе полностью переключится из режима «участника» в режим «докладчика».

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

Но это никак не снобизм! Я беру на себя кармическое обязательство просмотреть все опубликованные записи всех выступлений с Software People-2010, и опубликовать ниже отзывы-обзоры и о них. А пока можно почитать отзывы коллег, честно посещавших доклады.

Возможно эту фишку «просекли» и многие другие участники — и залы «Инфопространства» не были так забиты, как на Highload или РИТ. Ну и плюс апрель-месяц был дико перенасыщен конференциями — за неделю до SWP2010 был трехдневный РИТ-2010, а за пару дней до этого, в выходные был TrainingLabs-2010 (звали кстати, но никак не мог пойти, ибо overkill).

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

Более того, докладчиков стимулировали «работать» и на обеде — оказалось, каждому докладчику был выдан персональный стол с табличкой, чтобы жаждущие ответов могли к нему подсесть и получить интеллектуальный или моральный satisfaction.

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

Так вот, не сказать, что мой стол ломился от желающих общения, но таковые были. К тому же, обедал я только второй день, первый день нафиг пропустил. Ибо.

↑ Впрочем, идея «конференций на курорте» мне по-прежнему нравится сильно больше

В этой мутной воде деньги теряют и граждане, и предприятия

2010-04-30T14:04:14Z

BenderBot: 1 версия

Андрей Борейко, заместитель директора по развитию бизнеса CUSTIS (Заказные ИнформСистемы).

Интервью в обзоре «ИТ в национальных проектах 2006 — ЖКХ» на сайте CNews^[1]

Рост тарифов на услуги ЖКХ заставляет граждан все более внимательно относиться к тому, каким образом рассчитываются затраты на коммунальные услуги. К сожалению, отсутствие современных биллинговых систем не позволяет сделать прозрачной систему начислений. О том, как решить эту проблему, рассказал в интервью CNews Андрей Борейко, заместитель директора по развитию бизнеса компании CUSTIS (ООО «Заказные ИнформСистемы»)

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

Андрей Борейко: В целом ответ будет неутешительный. Когда мы начинаем работать в новом городе, то довольно часто выясняется, что начисления выполняются с нарушением законодательства. Иногда это может быть связано с низким качеством программного обеспечения, иногда — с фантазиями персонала, ответственного за расчеты, иногда — по обеим этим причинам.

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

Рост цен на жилищные и коммунальные услуги связан с ростом тарифов. Тарифная политика не относится непосредственно к процессу расчетов. Но рядовому плательщику до этого, понятно, дела нет. И если уж нельзя сдержать рост тарифов, то он требует справедливых расчетов, и это его неоспоримое право. Право на справедливые расчеты может нарушаться, например, при учете недопоставки услуг. Довольно типична ситуация, когда в городе не хотят или не могут учесть в квитанции недопоставку отопления или горячей воды.

Справедливости ради надо сказать, что случаются и злоупотребления со стороны населения. Сплошь и рядом имеют место ситуации, когда плательщик может «договориться» с персоналом расчетного центра о сумме платежа или задолженности. Знаете, прямо как с кондуктором в автобусе. Так что в этой мутной воде деньги теряют и граждане, и предприятия. Поэтому ответственные градоначальники и руководители ЖКХ ищут способы улучшения ситуации, ищут решения. И чем дальше, тем больше людей понимает, что при растущих объемах расчетов только современные информационные технологии могут гарантировать надежность и прозрачность.

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

CNews: Вы много говорите и пишете про «биллинг полного цикла». Что это — отраслевой стандарт? Что включает в себя это понятие?

Андрей Борейко: Коммунальные расчеты очень слабо регулируются. Стандартов, по сути, нет. Ни в отношении правил расчета, ни в отношении автоматизации. В этом плане ситуация сильно отличается, к примеру, от телекоммуникационной сферы. Возможно, причина в том, что в ЖКХ, в отличие от телекома, еще не созданы мощные операторы федерального уровня, способные «продавить» нужные нормы. Реальная деятельность, по большей части, привязана к муниципальному, реже к региональному уровню.

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

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

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

Что такое биллинговая система «полного цикла»? В нашем понимании это система, которая, как минимум, объединяет в себе функции расчетной и платежной системы. То есть обеспечивает поддержку единой базы данных населения, жилищного фонда, услуг, тарифов и льгот, выполняет начисления, позволяет выставлять счета на оплату, производить сбор, обработку и диспетчеризацию платежей, выпускать отчеты.

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

CNews: Вы хотите сказать, что платежные системы не относятся к системам «полного цикла»?

Андрей Борейко: Как правило, в платежных системах отсутствует или слабо развит механизм начислений, то есть расчет суммы, предъявляемой к оплате. Это не то чтобы какой-то недостаток. Специализация по-своему полезна. В каких-то технических аспектах платежная система может быть более «продвинута», чем система полного цикла. Ведь это общий принцип, отличающий универсальные решения от специальных.

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

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

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

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

CNews: Почему поставщики жилищных и коммунальных услуг не могут обеспечить собственный биллинг?

Андрей Борейко: Отчего же не могут, могут. Но это сопряжено с определенными трудностями. Я бы обозначил здесь три наиболее важных аспекта.

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

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

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

Поэтому остается объективная потребность в такой структуре, которая будет «равноудалена» от всех участников расчетов и при этом сможет обеспечить качественную статистку для администрации, насколько это допускает законодательство и договорные отношения с поставщиками ЖКУ.

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

Андрей Борейко: Вы совершенно правы. Одна из основных целей реформирования ЖКХ — создание конкурентного рынка услуг управляющих организаций. Но жизнь складывается так, что сроки достижения этой цели неясны. Сама возможность демонополизации обслуживания жилья у многих вызывает сомнения.

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

Практика показывает, что товарищества и кооперативы за редкими исключениями не способны на реальное управление жильем. В подготовленном Минрегионразвития комплексе мероприятий по развитию ЖКХ в 2006—2009 гг. предполагается, что все ТСЖ с 1 января 2007 г. должны будут выбрать управляющую компанию. Фактически это означает признание того факта, что жилищная революция, целью которой было быстренько переложить весь груз ответственности за жилье на собственников, не удалась. Отрасли предстоит развиваться эволюционным путем.

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

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

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

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

Еще один ключевой фактор — позиция поставщиков ЖКУ. Они, как правило, не очень доверяют управляющим организациям в финансовом плане, если только эта организация не создана самим поставщиком. При определенных условиях ЕИРЦ может выступать гарантом сохранности денег поставщика, и это будет устраивать все стороны.

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

CNews: Речь идет о готовых программных решениях, или требуется адаптация? Если ситуация так различается в разных городах, то, наверное, не так просто обеспечить единое решение. Вы только поставляете программное обеспечение или оказываете и услуги внедрения?

Андрей Борейко: Еще с 90-х годов на рынке присутствуют «коробочные» решения для коммунального биллинга. Как правило, они внедряются силами заказчика. До недавнего времени такая ситуация устраивала большинство клиентов. Но в последние год-два, в связи с изменениями в законодательстве и с приходом частного капитала, темпы изменений в отрасли ускорились, а специфика отдельных городов стала проявляться более отчетливо.

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

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

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

CNews: От поставщика бизнес-приложений нечасто приходится слышать про внедрение «под ключ». Это же не строительство. Обычно поставщики информационных систем стремятся четко зафиксировать объем своих обязательств и переложить существенную часть работ на клиента. В вашем случае внедрение «под ключ» чем-то отличается от общепринятого подхода?

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

У нас же обычным делом является создание «с нуля» нового биллингового центра или коренная модернизация существующего. Одна из основных особенностей создаваемого производственного комплекса — мощный человеческий фактор и большая потребность в обучении. Причем обучать нужно практически всех — от кассира и оператора абонентского пункта до директора. Для рядового персонала и менеджеров среднего звена существуют апробированные программы обучения.

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

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

CNews: Не удивительно. Насколько мне известно, ваша система разработана на Oracle, а в регионах, наверное, не так уж много готовых специалистов по Oracle, тем более — в коммунальной сфере?

Андрей Борейко: Дело не только в недостатке квалифицированных программистов. Тут мы как раз создали достаточно эффективную модель обучения и развития партнерской сети.

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

Что касается СУБД Oracle, то несмотря на дефицит кадров в регионах, мы ни разу не пожалели о выборе платформы. С точки зрения надежности, безопасности и производительности Oracle остается лидером. Кроме того, мы сознательно сделали ставку на доступные для муниципалитетов условия лицензирования базового ПО.

Наше партнерство с компанией VDEL и операционной системой Linux Red Hat также обусловлено не только техническими преимуществами этого ПО, но и его доступностью для заказчика.

CNews: А можно поподробнее рассказать про партнерскую сеть и обучение ИТ-специалистов?

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

Это предприятие комплектуется полностью из местных профессионалов. Затем они проходят обучение в нашей московской штаб-квартире и подключаются к внедрению еще до окончания курсов и аттестации. Объем их полномочий и возможностей в дальнейшем определяется тем, насколько успешно показала себя команда во время внедрения, насколько активно она вливается в экспертное сообщество системы. Технология создания партнерской сети предусматривает как минимум две модели технического центра — с разным объемом функций.

Для площадок, расположенных недалеко от Москвы, а также для тех случаев, когда создание местного техцентра по каким-либо причинам затруднено, мы не так давно создали федеральный сервисный центр. Этот сервисный центр может обеспечить весь комплекс технической поддержки — от лицензионного сопровождения до обучения новых пользователей.

CNews: Раз коммунальный биллинг находится в фокусе процессов реформирования отрасли, то вам, наверное, должны быть заметны основные тенденции информатизации ЖКХ. Чего можно ожидать в ближайшие годы?

Андрей Борейко: Ну, понятно, что раз мы занимаемся биллингом, то верим, что он будет развиваться и дальше. Причем как в варианте полного цикла, так и тонкий биллинг, платежные системы. Хотя, для последних конкуренция будет выше и насыщение произойдет раньше.

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

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

Большой потенциал имеется у таких смежных направлений как социальные и транспортные карты. Хотя здесь присутствует элемент моды. Далеко не всегда появление социальных карт сопровождается внедрением полезных приложений. Большой потенциал карточных технологий используется лишь в незначительной степени. Понимая это мы заключили партнерское соглашение между нами и лидером в области производства и обслуживания пластиковых карт — компанией «Розан». Они — профессионалы в части создания инфраструктуры для пластика, мы — в области расчетных приложений.

В коммунальном хозяйстве еще практически не задействованы центры обработки вызовов абонентов (call center). А между тем, ЖКХ — один из самых массовых потребительских рынков, где применение центров обработки звонков способно значительно улучшить взаимодействие с массовым клиентом. На сегодня лишь очень немногие информационно-расчетные центры используют подобные решения. И здесь у нас тоже есть сильный партнер — компания NAUMEN.

Наконец, довольно перспективное направление — процессинг и аутсорсинг приложений. На сегодня он активно развивается в сфере приема платежей. Например, мы сотрудничаем с компанией «Дельта Телеком», которая может оперативно предоставлять ЕИРЦ возможность принимать платежи за мобильную связь, что безусловно дает дополнительный биллинговый эффект.

Как видите, ставка на партнерские цепочки, о которой мы с вами говорили в апреле 2005 года, оказалась вполне оправданной.

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

CNews: Спасибо.

↑ "В этой мутной воде деньги теряют и граждане, и предприятия", Интервью на сайте CNews, октябрь 2006

Репликация: База Знаний «Заказных Информ Систем» → «В этой мутной воде деньги теряют и граждане, и предприятия»