Just do IT

IDC оценила рынок OSS в $1.8 миллиардов

2007-06-04T21:20:00.000+04:00

По оценкам IDC в 2006 году рынок open source software достиг $1.8 миллиардов. И будет увеличиваться ежегодно на 26%, достигнув $5.8 миллиардов в 2011 году.

Among the key results presented in IDC's study are the following:

Worldwide revenue from standalone open source software reached $1.8 billion in 2006.
This revenue will reach $5.8 billion in 2011, representing a compound annual growth rate (CAGR) of 26% from 2006 to 2011.
Software vendors are advised to consider several factors when evaluating how best to leverage open source software as a business opportunity, including the most appropriate business model, the appropriate usage of partnerships and alliances, and the characteristics of the community supporting the open source software.

Вообще эти цифры было бы интересно сравнить с оценкой роста всего рынка на этот же период и, соответственно, посмотреть изменение доли OSS в общем рынке.

Microsoft снова против

2007-06-03T22:41:00.000+04:00

На этот раз Microsoft против TestDriven.Net. До суда дело, вроде, еще не дошло, но "личная" переписка по увещеванию разработчика (Jamie Cansdale) отказаться от продукта уже довольно объемна. TestDriven.Net - Add-In для MS VisualStudio (в том числе поддерживает и Express). Понять недовольство MS можно – в Express многое обрезано и она должна "подталкивать" разработчиков к переходу на платную полнофункциональную MSVS. Ясное дело, что TestDriven.Net "тормозит" подобные переходы.

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

Update. Еще обсуждения данной темы:
Microsoft борется с TestDriven.NET
Microsoft против TestDriven.NET

SVN for Distributed Development Teams

2007-05-29T05:14:00.000+04:00

Сегодня-завтра на CMcrossroads намечается пара интересных вебинаров, посвященных использованию Subversion для работы распределенных команд разработчиков:

Globally Distributed Development Using Subversion
Сегодня, 29 мая в 22:00 по Москве (поздновато).
Докладчики:
Blair Zajac, Principle, OrcaWare Technologies
Jim Campigli, Executive VP, Product Management & CTO, WANdisco
Patrick Egan, Editor-in-Chief, CM Journal
Subversion for Enterprise Distributed Teams: Why, When and How?
Завтра, 30 мая в 18:00 по Москве.
Докладчики:
Carey Schwaber, Senior Analyst, Forrester Research, Inc.
Auke Jilderda, Senior Collaboration Consultant, CollabNet, Inc.
Mark Phippard, Director, Subversion Engineering, CollabNet, Inc.

Вопрос Source Control Management для распределенных команд один из наиболее проблемных. Надеюсь будут интересные идеи не только по SVN, но и по SCM в целом.

И вообще, здесь довольно много интересных вебинаров. В частности еще ожидаемые по Distributed Development:

20 июня - Managing Software Production with Geographically Distributed Teams.
11 июля - The Art of Managing Geographically Distributed Development.

Прошедшие вебинары доступны в течении 6 месяцев on-demand.

Resume vs. CV

2007-05-04T23:11:00.000+04:00

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

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

Резюме

В Америке, в гораздо большей степени, чем в Европе, выражена узкая специализация сотрудников, конвейерный подход, набор сотрудников через агентства (которые ищут по четко заданным критериям). Каждое резюме прочитывается многими людьми на разных уровнях, прежде чем будет принято решение, что с соискателем можно и пообщаться (хотя бы по телефону). Отсюда требование к резюме – оно должно быть только по делу и очень кратким (максимум 1 лист A4 нормальным шрифтом). Одного быстрого взгляда должно хватать, чтобы понять – что именно этот человек нужен на конкретной должности.

Первым делом надо указать должность, на которую подается резюме и зарплату, на которую рассчитывает соискатель.

Далее самый важный блок - информация о навыках, причем только тех, которые непосредственно относятся к должности, на которую претендует соискатель. В зависимости от требований конкретной компании меняются приоритеты, т.е. вверх поднимаются навыки, которые требуются на конкретной должности в конкретной компании. Соответственно резюме одного и того же соискателя могут отличаться как при подаче на разные должности, так и при подаче на одну и ту же должность, но в компании с разной специализацией (пример см. в конце поста). Сколько лет или месяцев проработал соискатель в той или иной области не очень важно (можно указать, а можно и нет), но очень важны количественные и качественные показатели систем, с которыми приходилось работать (проектировал БД со 100 справочниками, 15 оперативными таблицами; участвовал в разработке системы с 20 рабочими местами), параметры лучше выбирать самые «впечатляющие».

Далее идет информация о местах работы, но, опять же, только тех, которые непосредственно относятся к должности. Здесь хорошо подробнее остановиться на месте работы (не обязательно последнем), которое считаете «достижением».

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

Контактная информация – Имя (или фамилия, на данном этапе полные данные не нужны), email, телефон и др. способы связи. Возраст и пол указываются только если к ним есть особые требования.

CV (curriculum vitae)

Европейский подход более «человечный» - главное чтоб человек был хороший, а навык появится. CV - это полная автобиография. В ней надо отразить весь жизненный бэкграунд.

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

И далее все очень хорошо описано здесь.

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

Навыки – в порядке заинтересованности соискателем. Этот блок логическое продолжение предыдущего блока. Он должен рассказать работодателю чем соискатель хочет продолжать заниматься исходя из своих возможностей.

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

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

Образование – тоже в обратном хронологическом порядке «официальное» образование, в конце дополнительные курсы.

Личностные характеристики – все что еще хочет сказать о себе соискатель работодателю.

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

Пример особенностей резюме для разных должностей

Возьмем соискателя программиста VB.NET + MS SQL Server, имеющего опыт работы как в крупной компании (работа по четко поставленному ТЗ), так и в небольшой (самому приходилось бегать и выяснять требования).

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

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

Послушать (eng) чем отличаются резюме и CV можно здесь (прямая ссылка на MP3 файл)

Aspect-oriented programming

2007-04-20T03:30:00.000+04:00

Если что-то появляется, значит, оно кому-то нужно.

И снова новая методология программирования и к ней новый подход к разработке ПО. Приглашаем любить и жаловать: Aspect-Oriented programming (AOP) и Aspect-Oriented software development (AOSD).

В отличии от предыдущей методологии (OOTD) (которая была только идеей и поводом немного задуматься, да и на устои привычной OOP серьезно не покушалась), эта методология вполне оформившаяся и претендует быть кардинально отличной от OOP.

История:

Aspect-Oriented подход разработан в Xerox PARC в 2001 году под руководством Gregor Kiczales. Этой же группой была разработана первая реализация – AspectJ, которая на текущий момент входит в Eclipse Foundation. Кроме AspectJ уже создано несколько десятков реализаций AOP парадигмы, практически для всех языков.

Идея AOP захватила сообщество - существует Aspect-Oriented Software Association (AOSA), проходят ежегодные конференции по AOSD, в которых в качестве спонсоров выступают Microsoft, Google и IBM.

Основная цель, которую себе поставил Gregor Kiczales, и в результате движения к которой появился AOP – уменьшение кол-ва ошибок и улучшение качества кода за счет борьбы с запутанностью кода и разбросанностью функционала.

Дисклэймер:

Я, человек привыкший думать объектно-ориентированно, не совсем поняла их претензии к OOP. Т.е., на мой взгляд, при правильном дизайне системы (в объектно-ориентированной парадигме) нижеизложенные проблемы не дают серьезного ухудшения качества кода. Описание же AOP, на мой взгляд, слишком похоже на патерны. Но то, что я не вижу преимуществ – это не значит что их нет. OOP тоже плохо приживался в процедурно мыслящей среде.

С чем боремся:

В объектно-ориентированном подходе как на уровне системы в целом, так и на уровне отдельных классов присутствует сквозная функциональность (т.е. та, которая реализована понемногу в разных модулях), а так же большое количество кода, который фактически не относится к функционалу системы. На уровне системы это идентификация, защита, логирование, репликации, сериализация/десериализация, сохранение настроек системы и т.д., т.е. или общий или «сервисный» функционал, зачастую реализованный в разных частях системы (примеры: сериализует один модуль - десериализует другой; каждый из модулей системы занимается идентификациеи и защитой), в связи с чем усложняется отладка и поддержка (со временем начинается «расползание»). То же самое на уровне классов – класс инкапсулирует в себя не только функциональную часть, но и внутренние «сервисы», обеспечивающие корректность работы – отлов ошибок, работа с памятью и т.д., которые загромождают код и усложняют чтение логики – в следствии чего, опять же сложности с отладкой и длительной поддержкой.

Метод борьбы:

Выделение сквозной функциональности в отдельные модули, которые называются аспектам (aspects). Поведение аспекта в конкретном месте программы (точке подсоединения, join point) определяет advice (собственно программная реализация модуля). Все точки подсоединения конкретного аспекта описываются в наборе pointcut.

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

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

Ссылки по теме:

Gregor Kiczales о AOP (Google Video)

Aspect-Oriented programming на wiki

Книги:

Aspect-Oriented Analysis and Design: The Theme Approach. Siobhàn Clarke, Elisa Baniassad.

Aspect-Oriented Software Development. Robert E. Filman, Tzilla Elrad, Siobhan Clarke, Mehmet Aksit.

Aspect-Oriented Software Development with Use Cases. Ivar Jacobson, Pan-Wei Ng.

Aspect Oriented Refactoring. Ramnivas Laddad.

AspectJ in Action: Practical Aspect-Oriented Programming. Ramnivas Laddad.

Очень точно подмечено

2007-04-15T22:55:00.000+04:00

Ко всем существующим фобиям у современных людей добавилась еще одна - боязнь потерять флешку!

(автор где-то в ЖЖ)

Фильм про Дубну и Синхрофазотрон

2007-04-10T01:44:00.000+04:00

Тем, кого заинтересовала Дубна, а так же тем, кто любит физику, историю и, особенно, историю физики:

10 апреля на канале "Культура" в 20.35 (по мск) будет фильм "Властелины кольца", посвященный созданию дубненского синхрофазотрона.

И еще пара наблюдений по поводу защиты в Висте

2007-04-09T02:31:00.000+04:00

1. Инсталлятор можно запустить только под админскими правами. Т.е. любой инсталлятор может сделать с машиной что угодно. Ранее не вызывающие особого доверия инсталляторы пускались под пользователем с ограниченными правами, давая некоторую дополнительную защиту. Теперь для таких "сомнительных" инсталляторов, по-видимому, придется использовать виртуальные машины.
2. Появились предупреждающие сообщения (с затемнением экрана) что данное действие может быть очень опасно с точки зрения безопасности и что требуется подтверждение пользователя на продолжение действия. Идея хорошая т.к. довольно давно известно, что большинство пользователей не читают текст обычных сообщений, а сообщение с затемнением экрана действительно привлекает внимание пользователя к сообщению – выглядит, как будто машина сейчас уйдет в перезагрузку и вызывает ощущение, что действительно происходит что-то опасное. Только во всем нужна мера, а MS перебрали с такими сообщениями очень сильно. Сообщения выскакивают по любому поводу. Результат – когда за 2 минуты работы пользователь увидит 6 штук таких сообщений то уже 4-е он читать не будет, а 6-м его можно будет спросить "Вы уверены что хотите установить вирус на ваш компьютер?" и пользователь ответит Да.

NSIS & Vista

2007-04-08T14:14:00.000+04:00

Для того чтобы установить программу в “Program Files” пользователю нужны административные права. Это не новость. А вот новость, появившаяся в Висте – запустить инсталлятор можно только под пользователем уровня доступа администратора машины.

С версии 2.21 в NSIS-е появилась команда RequestExecutionLevel, которая указывает какими правами должен обладать пользователь для запуска NSIS инсталлятора. RequestExecutionLevel может указывать 3 уровня прав: user, admin, highest. Если программа по умолчанию устанавливается в “Program Files”, то должен быть указан уровень admin. Если Команда не используется, то NSIS инсталлятор автоматически определяется Вистой и при запуске требует административных прав, однако после завершения инсталляции выдает сообщение о том что возможно установка программы прошла некорректно.

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

Все глобальные переменные системы (%UserProfile%, %LocalAppData% и др.) определяются не для фактически залогиненного акаунта, а для администраторского, под которым запущен инсталлятор. Та же ситуация с переменными NSIS скриптов (например $SMPROGRAMS) и доступом к ветке реестра HKEY_CURRENT_USER.

Такая ситуация с переменными выливается в то, что для обычного пользователя через инсталлятор нельзя проставить даже элементарные линки на программу в “Start Programs”, на “Desktop” и в “Launch Menu”. Для того, чтобы пользователь сразу после инсталляции увидел иконку на рабочем столе ставить ее (и все остальные линки) надо для All Users (команда SetShellVarContext all). Это значит, что фактически программу надо ставить не для конкретного пользователя, а для всех существующих пользователей машины сразу.

И, не смотря на то что здесь в FAQ-е NSIS сказано, что для успешного добавления линков в “Start Programs” при инсталляции и для последующего успешного их удаления при анинсталляции надо указать или “RequestExecutionLevel admin” или “SetShellVarContext all”, на самом деле обе операции должны применяться одновременно:

OutFile vista.exe
Name Vista

RequestExecutionLevel admin

Section
  SetShellVarContext all
  CreateShortcut "$SMPROGRAMS\Vista Test\hello.lnk" $WINDIR\notepad.exe
  WriteUninstaller $EXEDIR\uninst.exe
SectionEnd

Section uninstall
  SetShellVarContext all
  Delete "$SMPROGRAMS\Vista Test\hello.lnk"
  RMDir "$SMPROGRAMS\Vista Test"
SectionEnd

Российский Центр Программирования в Дубне

2007-04-06T17:59:00.000+04:00

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

Основные вопросы к технопаркам

Вообще тема этих парков с самого ее появления для меня была очень загадочна. 2 основных вопроса к подобной модели развития IT (когда в одном месте государственными усилиями пытаются собрать IT компании):

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

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

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

Ответы на вопросы

Теперь, собственно, свежая информация, которая хоть и не официальная, но вполне похожа на правду и дает ответы на вопросы.

В Дубне сейчас параллельно развиваются 3 проекта.

1. Инкубатор IT компаний. Проект уже действует. Основан на предоставлении дешевых и совсем бесплатных оборудованных офисов (ремонт, мебель, интернет) для молодых IT компаний. Время пребывания компании в инкубаторе не более 3-х лет. 1-й год бесплатно, 2-й и 3-й платно с повышающимся коэффициентом.

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

2. Российский Центр Программирования (РЦП). В народе, как не трудно догадаться – Силиконовая Долина (должна быть Кремниевая, но это не важно :-) ). Здесь немного официальной информации, правда не обновлявшейся с 2004г.

Итак ответы на мои вопросы:

Откуда взять компании. Якорной компанией является Luxoft (и возможно не он один). Т.е. крупная и активно растущая офшорная компания, которая очень активно ищет себе сотрудников по всей стране. Ей нужны офисы и жилье для сотрудников. И с офисами и с жильем сейчас проблемы уже не только в Москве и Питере, но и во всех более-менее крупных городах. Т.ч. шаг Luxoft-а выглядит очень разумным.

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

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

По моему – красота! Причем вполне осуществимая и, что очень важно, материально обоснованная.

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

3. Технопарк (как правильно называется проект не знаю). Технопарк должен стать полигоном высокотехнологических разработок, в частности области энергетики (ну и, наверно, ядерной физики). К программному обеспечению он прямого отношения не имеет, но программисты явно потребуются и туда. Будет располагаться рядом с РЦП. Больше про него, к сожалению, ничего не знаю.

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

Итог: Очень порадовало то, что за словами о развитии IT в России стала видна материальная обоснованность для конкретных игроков, что, на мой взгляд, является основным для реализации проекта. Будет ли это в результате Бангалор или Кремниевая Долина на текущем этапе не так уж и важно.

Вы слышите меня, Бандерлоги?

2007-04-03T23:17:00.000+04:00

"История про Google AdSence" или "Вот так и сотрудничай с Гуглом...»

На одном из сайтов была вовремя неотмодерированная информация. Причем не особо страшная - не порнография (в моем понимании контента для взрослых там не было), не реклама таблеток непонятных, но вот в URL-е содержала "nude-girls". Гуглу информация не понравилась и реклама на сайте была заблокирована.

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

Неделю назад руки все-таки дошли известить Гугл о том, что все исправлено, более безобразие не повториться и с просьбой разблокировать рекламную кампанию на сайте. И вот пришел ответ:

Большое спасибо за Bаше письмо.

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

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

Пожалуйста, учтите, что мы не сможем изменить наше решение или ответить на дополнительные вопросы по данному случаю.

Спасибо за Ваше понимание.

И после этого можно серьезно говорить о базировании бизнеса на сервисах Гугла?

Объектно-ориентированному дизайну пора потесниться

2007-02-28T00:19:00.000+03:00

Явно пришло время изменений. Предыдущий пост был про идею новой методологи разработки, а сегодня пришло время пересмотреть основы программирования и дизайна – OOP и OOD.

Большинство изменений происходят постепенно. За текучкой мы эти изменения не замечаем.

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

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

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

Самое неприятное - когда красиво спроектированную архитектуру приходится портить ради тестов. Какой выход из этой ситуации?

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

Roy Osherove предлагает кардинально другое решение. Он предлагает поменять подход к дизайну и делать его не только объектно-ориентированным, но и тесто-ориентированным. Итак, на замену OOD идет OOTD (Object Oriented Testable Design).

На мой взгляд идея хорошая. Признание факта противоречия классических канонов OOD и тестирования – это хорошая причина уделить внимание проблемам тестирования еще на этапе проектирования.

Post-Agile

2007-02-03T00:45:00.000+03:00

Это должно было свершиться и это свершилось. В наше время быть "новой методологией" в течении 10 лет невозможно. 10 лет это слишком долго, чтобы называться "новым".

Итак, прощай Agile, здравствуй Post-Agile. Early adopters уже "наигрались" с Agile, перепробовали все предлагаемые практики и методологии в разных комбинациях, и теперь им стало скучно с Agile. На текущий момент определенной новой сформировавшейся методологии нет, но Google уже выдает более 10тыс. результатов по фразе "Post-Agile".

Flow – одна из методологий (или, скорее, идеологий), претендующих на звание Post-Agile.

Сейчас "на коне" web2.0 проекты и цикл их жизни очень сильно отличается от жизненного цикла локальных конечнопользовательских приложений и, еще больше, от жизненного цикла корпоративных систем. Основное отличие в том, что эти проекты не предлагают решения проблем или нужд пользователей, они развлекают, делают жизнь более приятной, красочной, интересной. Многие из них, безусловно, очень полезны, но не необходимы. А так как любая игрушка рано или поздно надоедает - надо пользователям постоянно давать что-то новое, чем-то их привлекать снова и снова, чтобы они не ушли на другой свежий ресурс. Именно на это нацелен Flow:

Картинка из поста "What comes after usability?"

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

ProgressBar и индикаторы выполнения процесса

2007-01-26T18:56:00.000+03:00

Любое приложение, содержащее длинные операции (в которых время выполнения может превышать 1 минуту), должно иметь ProgressBar. Причем не просто "бегунок" который показывает что процесс идет, но по которому не понятно сколько выполнилось и сколько еще осталось и вообще работает приложение или "подвисло", а хороший ProgressBar с индикатором % выполнения операции и, желательно, показом сколько времени осталось до окончания выполнения. Такие длинные операции содержатся в большинстве систем работающих с данными и в вычислительных задачах. И, я думаю, большинство разработчиков постоянно сталкивается с ProgressBar-ами.

Что должен содержать ProgressBar и индикаторы процесса выполнения (в логическом порядке, а не в порядке важности):

1. Количественный показатель (в штуках, в байтах и т.д.) общего объема данных, которые требуется обработать.
2. Количественный показатель обработанных данных.
3. Количественный показатель данных, которые осталось обработать.
4. Время, потраченное на обработку данных (из п.2).
5. Ориентировочное время обработки оставшихся данных.
6. Визуальное отображение % обработанных данных (собственно сам ProgressBar).
7. Скорость обработки данных.

В большинстве случаев, для операций, не превышающих нескольких минут, хватает одного ProgressBar-а - по нему пользователь может сам оценить, сколько времени осталось до окончания выполнения операции, плюс по нему наглядно видно, что процесс движется. Для очень длинных операций одного ProgressBar-а не достаточно т.к. процесс движется медленно и картинка процесса на долго "застывает" в одном состоянии, так что кажется что процесс "завис". Количество обработанных данных и данных, оставшихся для обработки, тут позволят показать, что процесс все-таки идет, а временные показатели покажут, насколько долго еще процесс будет длиться. Причем индикатор ориентировочного времени обработки оставшихся данных просто необходим (показательный жизненный пример: в метро пассажиру интересно, когда подойдет следующий поезд, а не когда ушел предыдущий).

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

1. Заранее не известно, сколько данных должно быть обработано. Эта проблема очень часто возникает при запросах к базе данных, когда заранее не известно, сколько данных должно быть возвращено базой. Так же не редка ситуация, когда в вычислительных задачах перебор элементов делается по большому набору критериев, в результате чего заранее точно не известно, сколько данных надо перебрать. В обоих случаях оценить общее количество данных все-таки можно выполнив предварительные вычисления или предварительный запрос к базе. Это, конечно, займет лишнее время, но в большинстве случаев это окупается, т.к. информированный пользователь - удовлетворенный пользователь, а неинформированный будет злиться на "глупую программу" которая повисла и не понятно чего там делает. Минус такого решения - оно не подходит для задач, критичных к общему времени выполнения. Второй минус - появляется дополнительный процесс предварительного подсчета, которому так же может потребоваться свой ProgressBar.
2. В процессе выполнения операции невозможно (или можно, но с серьезной дополнительной нагрузкой на систему) узнать процент выполнения операции. Тут все зависит от архитектуры системы и вопрос возвращения данных для показа прогресса надо закладывать еще в момент проектирования. Встраивание этого функционала в уже готовую систему может быть очень сложным и может потребовать "перекраивания" взаимодействия классов и модулей системы. Более-менее стандартные решения: при запросах к базе данных отдавать информацию постранично; в задачах, работающих в основном потоке поднимать события обрабатывающим классом; в задачах, работающих в отдельном потоке периодически опрашивать поток или посылать сообщения из потока.
3. Процесс состоит из набора подпроцессов. Здесь есть, где разгуляться фантазии.

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

4. Выполняется параллельно несколько процессов. Раньше эта проблема появлялась не часто и, в основном, при закачке данных. Для вычислительных задач распараллеливание процесса вычисления при одноядерном процессоре большого смысла не имела, т.к. одна задача занимала весь ресурс процессора (ну или столько, сколько ей отводилось системой) и запуск второй, параллельной, задачи пропорционально тормозил выполнение первой. Сейчас при появлении CoreDuo и Core2Duo (а в дальнейшем ядер, похоже, будет все больше и больше) можно и нужно пускать параллельные процессы в разных потоках, соответственно вопрос отображения в одном ProgressBar-е нескольких операций выполняющихся в разных потоках становится очень актуальным. Если единицы измерения количественных данных всех параллельных операций одинаковые и операции имеют единую логическую базу – можно показывать единый ProgressBar с суммарными данными. Что делать с операциями, логически не совместимыми, покажет будущий опыт, а пока у меня красивого решения для такой ситуации нет.

Развлекаемся...

2007-01-26T12:05:00.000+03:00

Развлекательные посты - замечательный способ продвижения даже для серьезных сообществ.

Richard Quick, freelance web designer, в своем блоге про дизайн написал забавный пост "How to fake a Web 2.0 logo", который читается именно как развлечение. Пост попал на головную страницу Digg.com, в результате рост посетителей за день с 555 до 47501 захода. Трафик, конечно, обеспечил Digg.com, а вот попадание поста на Digg.com обеспечили, скорее всего, название (тут сразу и Web2.0, и How to, и fake) и хороший развлекательный тон.

Сейчас на головной странице Digg.com 2 первых поста: "Porn-Infected PC Crazy Woman Faces 40 Years - True Story" (с pcworld.com между прочим) и "10 Amazing Things You Didn't Know about Animals".

Еще за одним примером далеко ходить не надо. На ITBlogs по посещениям с большим отрывом лидирует пост "Слухи...", несущий в своем названии явно развлекательную направленность. На втором месте пост "Чего громим? Кого мочим? (Читаем версии в обсуждении)" тоже с не особо серьезным названием.

Т.е. пост на серьезную тему прочтут не все, а те, кому тема интересна и в данный момент есть время на осмысление. Пост с развлекательным заголовком прочтут все (или, как минимум, откроют).

PS: Кстати в тему пост "Buzz titles" о том как составить привлекательное название для статьи или книги по IT, ну и для постов тоже.

Блого-зависимость

2007-01-22T08:51:00.000+03:00

10 дней практически без интернета явно продемонстрировали отрицательные стороны постоянной "включенности".

Желание что-нибудь почитать (блоги или новости) близко к наркотической зависимости. Рука тянется к иконке броузера, хотя мозг знает, что интернета нет.
В связи с тем, что броузер ничего не показывает, резко возросла производительность труда. Через дней 5 трудотерапия начала оказывать благотворное влияние и рука почти перестала тянуться к иконке броузера.
Появилось много идей по поводу решения тактических вопросов. Похоже, излишнее увлечение блогосферой стимулирует мысли стратегического направления (наверное из-за того, что обсуждается много тем не затрагивающих текущих задач, но рождающих новые идеи "на будущее"), и за этими думами "о высоком" решение текущих проблем становится "текучкой", что отражается на качестве принимаемых решений.
Одинаковые мысли приходят в голову разным людям практически одновременно. Может количество идей (а не ума) величина постоянная при постоянно растущем количестве людей? Окончательно убедилась в том, что если появилась мысль, о которой хочется написать – писать надо сразу же, иначе об этом напишет кто-то другой. При ежедневном прочтении лент это не так заметно, т.к. можно поучаствовать в обсуждении. Но если прошло уже несколько дней, то обсуждение уже закончилось, а поднимать заново тему смысла не имеет т.к. все желающие уже высказались.
Новые блоги, которые хочется почитать, появляются слишком часто. Старые при этом так же читаются. В результате за 10 дней более 200 непрочитанных постов! А ведь если бы интернет был, я бы их прочла. Причем действительно полезной информации в этом потоке очень мало.

Когда то "телевизор нам природу заменил", теперь, похоже, "интернет нам телевизор заменил".

Чуть больше года назад у нашего телевизора сломался пульт. Сразу же были выявлены симптомы нашей зависимости от телевизора – рука хватала пульт автоматически и начинала переключать каналы. Телевизор при этом не включался. Мозг останавливал руку только на 2-3-м нажатии. При этом до поломки пульта мы были уверены, что телевизор практически не смотрим. Оказалось это не так. После этого новый телевизор решили не покупать т.к. нервное щелканье пультом в поисках интересных программ – пустая трата времени. В результате мы уже год не смотрим телевизор.

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

Чем бы заняться стартапу

2007-01-07T14:52:00.000+03:00

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

На текущий момент основная идея успешного стартапа гласит: Делайте нужное, новое, уникальное и будет вам счастье (если повезет).

Пройдемся по пунктам.

1. Нужное

С первым постулатом про нужное все более-менее ясно. Хорошо бы только определиться кому нужное, но это уже детали, а сам по себе постулат вопросов не вызывает.

2. Новое

Второй постулат про новое сильно связан с третьим про уникальное, и тут начинаются вопросы.

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

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

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

2.1. Повторение - не уникальное и не новое

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

2.2. Новое, но не уникальное

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

3. Уникальное

А теперь самый экстремальный вариант – новый уникальный продукт. Создатели должны очень сильно верить в то, что то, что они делают хоть кому-то нужно. Но даже если это действительно очень нужный продукт, надо о нем сначала как-то известить потенциальных пользователей. Тут ситуации очень сильно отличаются в зависимости от рынка.

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

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

Бэта должна выглядеть как бэта, а не как готовый продукт

2006-12-31T14:00:00.000+03:00

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

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

Клиенты воспринимают степень готовность ПО по степени готовности интерфейса.

Картинка из поста "Don't make the Demo look Done"

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

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

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

Конечно, можно сказать: "А на что history list? Все изменения можно посмотреть там". Но нравится / не нравится - это эмоция, которая возникает не зависимо от того, что написано в history list. Да и сам history list даже профессионалы при использовании сторонних продуктов не всегда читают. Обычные пользователи практически никогда ничего не читают - все должно быть понятно из интерфейса.

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

Готовность интерфейса должна соответствовать функциональной готовности продукта.

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

Новых вам интересных и успешных проектов в наступающем 2007 году!

Автоматизатор, автоматизируй себя сам

2006-12-22T19:17:00.000+03:00

Среди более чем 400 примеров внедрения продуктов Microsoft исчезающе мало внедрений в сфере IT и среди них, в основном, телекоммуникационные компании.

Konstantin Starovoytov дал ссылку на Конкурс внедренческих проектов на iOne.ru. 39 компаний, в основном производственные, но нет ни одной IT компании-разработчика.

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

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

Мне очень нравится проект виртуального офиса компании СладКо (описание на microsoft.com, описание на iOne). Первый раз я о нем прочитала примерно года 2 назад. Первой мыслью было – звучит очень заманчиво и слишком красиво чтобы быть правдой. А второй мыслью было – почему это сделала кондитерская компания, а не IT? Т.е. возможно есть крупные IT компании, существующие без офиса, но я о них, к сожалению, не слышала.

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

Отсутствие офиса снимает не только финансовую нагрузку на его аренду, но и сложность поиска нужных специалистов в одном месте. Например, Sergey Rozovik написал что в Дубну начали стекаться IT компании в связи с чем там резко подскочили зарплаты, но проблема не в этом, а в том что квалифицированных специалистов там не много, а спрос растет и, как мне кажется, основной проблемой там скоро станут кадры. Компании, не привязанной к офису, искать специалиста можно не в каком-то конкретном месте, а по всему русскоговорящему сообществу (а если нет ограничений по языку – то вообще во всем мире).

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

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

Меняет ли Web2.0 модель формирования нашего мнения?

2006-12-20T10:12:00.000+03:00

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

Но как влияет Web2.0 на тех, кто все-таки постоянно "подключен" (на нас)?

Меняет ли быстрый доступ к информации и большому количеству мнений модель формирования и изменения нашего собственного мнения?

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

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

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

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

Web2.0 изменил способы генерации и доставки информации. Но потребитель остался таким же, каким и был.

Неудачные опыты с мобильным офисом

2006-12-15T17:29:00.000+03:00

Переезд в теплые края закончен.

В связи с переездом появилось новые мироощущения и отпали начавшие прорезаться надежды:

Надежда (это та, которая умирает последней). Засунуть все рабочие данные в интернет, не держать ничего на локальном компе и ноуте, не таскать за собой массу информации и дистрибутивов при переездах, не мучиться с синхронизацией данных между компом и ноутом, и, в конце концов, перестать бегать с ноутом по интернет-кафе. На текущий момент одни только сервисы гугла уже практически покрывают основные потребности: почта – Gmail; офисные документы - Google Docs & Spreadsheets; RSS Reader - Google Reader; изображения – PicasaWeb. Есть еще масса сервисов от закладок до построения диаграмм и бэкапов. Все это очень красиво звучит, и некоторые уже так живут. И даже можно отбросить паранойю по поводу утекания приватных данных. Но есть проблемы, которые в очередной раз были испытаны на собственном опыте:

Во первых, интернет есть не везде, даже если он "условно" есть в каком-то интернет-кафе он может быть такого ужасного качества, что даже gmail грузиться отказывается.

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

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

Ну и в четвертых, работать по 6 часов в интернет-кафе абсолютно не комфортно плюс никаких денег не напасешься.

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

Новое мироощущение же можно выразить так – прогресс sucks, оставьте все как было. Т.е. раньше у меня было устойчивое мнение, что если появляется что-то новое то оно приживается только если удобно потребителям. Покупка нового ноута и его дальнейшее использование опровергло это мнение напрочь. Ноут покупался с Core 2 Duo и в процессе выбора выяснилось что все свежие модели идут с зеркальной матрицей, исключение составляют (похоже временно) только дорогие Lenovo и HP. За ноутом с зеркальной матрицей работать невозможно – бликует и очень слепит. После часа работы глаза начинают болеть. Антибликовая пленка помогает несильно, плюс ее наклеить – это отдельная история. Но производители переходят на зеркальные мониторы т.к. они хорошо продаются. Они очень красивые, яркие, блестящие с сочными цветами и очень красиво выглядят на витринах. Производителю главное – продать, а то, что за таким ноутом работать невозможно его уже не интересует, это проблемы потребителя. Или, возможно еще не достаточно времени прошло и производители одумаются?

И снова о SOA

2006-12-06T06:21:00.000+03:00

Так что же такое SOA. Сервисно-ориентированная архитектура. Вроде бы очень говорящее словосочетание. Но большинство копий в обсуждениях на ITBlogs поломались, по моему, о слово архитектура (не то, чтобы слово архитектура встречалось часто, но смысл баталий именно вокруг этого).

Что имеется ввиду? Я вижу 2 варианта и они очень разные.

Архитектура как подход к проектированию системы
Архитектура как подход технической реализации.

С точки зрения SOA как технической реализации, система проектируется как раньше, и реализуется как набор отдельных компонентов (они же сервисы). В данном случае, как мне кажется, SOA – это buzzword. Раньше это называлось модулями и интеграцией отдельных систем. Т.е. и раньше можно было взять системы разных производителей (если это было оправдано) и интегрировать их у себя. Система при этом не становится наборной, она остается единой, но собранной из отдельных модулей. Сейчас такие системы называют SOA. Почему? Просто потому что модный термин?

С точки зрения SOA как подхода к проектированию, получается наборная, постоянно модифицирующаяся, система – т.е. выявляется проблема, для ее решения делается сервис, выявляется другая проблема, для ее решения еще сервис. Сервисы друг для друга – черные ящики. Это очень облегчает проектирование системы. Тут самое сложное заложить основу взаимодействия сервисов. Механизмы взаимодействия сервисов хорошо описал Влад Боркус (плюс к посту есть не менее ценные комментарии).

Подобный подход в проектировании системы удобен

Для сервисов, рассчитанных на конечного пользователя, когда каждый следующий сервис решает еще одну проблему пользователя и интегрирован с предыдущими сервисами. В основном это web сервисы, но могут быть и desktop приложения, дополняющие друг друга.
Для небольших мобильных компаний, сфера деятельности которых позволяет быстро подстраиваться под изменяющуюся ситуацию. Таким компаниям не нужны крупные ERP, им нужны сервисы, которые можно быстро ввести в строй и начать использовать и так же быстро от них отказаться. Эти компании, в первую очередь, сам же IT сектор, а далее практически весь непроизводственный бизнес (услуги, торговля). Но, в любом случае остается ограничение по размеру компании (по количеству людей). Каким бы простым сервис ни был нужно время на обучение сотрудников, а с внедрением, растянутым на длительное время, теряются вышеописанные плюсы.

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

Agile Testing

2006-12-03T09:23:00.000+03:00

Очень интересные доклады по Agile методологиям на Google Video. Их довольно много. Вот некоторые (ссылки на остальные видны справа при просмотре):

Agile Testing (Elisabeth Hendrickson)
Scrum et al. (Ken Schwaber)
Kent Beck: Ease At Work (В 7-и частях, к сожалению 1-ю не нашла, эта вторая. При просмотре рядом ссылки на остальные части)

Я пока осилила только Agile Testing. Очень зажигательная докладчица. Elisabeth Hendrickson является консультантом по software testing, основателем Quality Tree Software. На сайте Quality Tree Software есть документы с советами по тестированию продуктов и по набору тестировщиков. Ну и, конечно же, Элизабет ведет блог - Ruminations.

Разработка, идущая от тестирования, для меня, наверно, самая близкая из agile техник.

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

А разработка конечнопользовательских продуктов может идти от тестирования с самого начала. Здесь приложение решает проблему (или набор проблем) пользователя и нет четких рамок как это должно происходить – главное, что бы проблема решалась наиболее удобным для пользователя способом. Т.ч. проект сразу начинает жить подстраиваясь и видоизменяясь.

На текущий момент отдельные части кода, объекты и функциональные модули тестируются с помощью UnitTest-ов (которые встроены сейчас практически во все среды разработки). Практика эта довольно распространенная, хотя к порядку использования UnitTest-ов есть вопросы – кто и в какой последовательности должен писать тесты к коду? Должны ли сначала писаться по спецификациям тесты, а потом код? Должен ли сам программист писать тесты к своему коду? У меня пока нет универсального ответа, пробовались разные варианты и у всех есть свои недостатки.

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

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

technorati tags: Agile Testing

Хаос наступает

2006-11-30T02:35:00.000+03:00

IT стремится к хаосу. SOA – хаос в архитектуре систем. Agile (XP и, особенно, Scrum) – хаос в производстве систем.

Причем хаос - это не мое видение. SOA и Agile позиционируются как методологии жизни в хаосе.

Новые методологии отрицают планирование, никаких планов развития. Они все сиюминутны.

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

Чем методология разработки более гибкая тем больше ее сейчас любят. Каждая следующая методология оставляет все меньше места планированию и контролю. Roy Osherove, agile консультант, пишет что Scrum продается лучше чем XP в основном потому, что Scrum более настраиваемый, требует меньше управления и не содержит страшного слова "Extreme". Т.е. разработчик наслушавшись как все может быть хорошо с agile, где ему не надо ни за что отвечать ведется и хочет применить это на себя. Причем выбирает методологию – чем проще звучит тем лучше.

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

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

Disclamer: Не бейте меня сильно! Описание ситуации немного утрировано, но, иногда, карикатурная утрированность помогает взглянуть на ситуацию по новому.

technorati tags: SOA, Agile, Scrum, eXtreme Programming

Microsoft тоже хочет мой номер телефона

2006-11-29T02:42:00.000+03:00

Пару недель назад Google придумал как выманивать номера телефонов у пользователей.

Microsoft решил не отставать.

Кликните по картинке для увеличения

Но у Google была уловка, и для использования сервисов Google указание телефона не обязательно. Microsoft же теперь без указания номера телефона в Live ID не пускает к данным на их сервере. Хотела посмотреть презанташку на www.microsoft.com/rus, но с таким подходам мне эта презенташка не нужна.

Как то мне совсем не нравится такая тенденция.

technorati tags: Microsoft

Жизнеобеспечение проекта. Часть 3.

2006-11-26T01:10:00.000+03:00

Про обещанного аналитика, и еще про технолога.

Предыдущие части: Часть 1 (введение), Часть 2 (про службу поддержки).

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

Кликните по картинке для увеличения

Аналитик анализирует новый требующийся функционал (check function overview) и возможные технические проблемы проекта (check possible bug), выявленные пользователями и службой поддержки. Т.е. неформализованную информацию из Help Desk. На основе этого он составляет технические задания (technical project) для разработчиков. ТЗ, как и вся информация по проекту, складывается в Wiki. Задания разработчикам записываются в Bug Tracking со ссылками на источник задания в Help Desk и на ТЗ в Wiki.

В зависимости от принятой для проекта методологии разработки зависит уровень детализации ТЗ, которые аналитик отдает разработчикам.

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

один разработчик,
команда, возглавляемая ведущим разработчиком (который принимает решения по реализации функционала внутри модуля),
команда, сама принимающая решения (например Agile team).

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

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

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

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

Кликните по картинке для увеличения

Технолог – главный специалист в своей предметной области (subject area). Он работает на неформализованном уровне проекта. Всю информацию, которая требуется для решения конкретной задачи технолог кладет в Wiki и ставит на нее ссылку из Ticket-а Help Desk.

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

В следующей части - Project Manager.

В начало

technorati tags: Life Cycle, Development Team

Крамольный прогноз развития корпоративных IT систем

2006-11-22T11:23:00.000+03:00

В связи с высказанной разнее крамольной мыслью у меня появился крамольный прогноз: через несколько лет опять начнут набирать популярность самописные корпоративные IT системы.

Историческое обоснование:

Были самописные системы, разработка которых со временем дорожала из-за дорожания программистов, а адаптивность их падала т.к. системы становились слишком громоздкими.

На смену им пришли универсальные ERP, которые было гораздо быстрее внедрять и они проще адаптировались и масштабировались. Но со временем системы начали дорожать, а главное, сильно подорожала стоимость внедрения (консультантов). При этом жизнь сейчас меняется быстрее чем 10-15 лет назад и к моменту внедрения ERP системы она уже устаревает.

Теперь пришли SOA и SaaS. SaaS не рассматриваю т.к. он хотя и сервисный, но, скорее, метод распространения. А вот SOA является явной альтернативой крупным и дорогим ERP. Она выигрывает и по скорости и по стоимости внедрения. Но скоро всплывут все проблемы использования разномастных приложений. Плюс опять же начнет дорожать стоимость внедрения – модные специалисты всегда дорожают.

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

technorati tags: IT

Крамольная мысль

2006-11-22T05:03:00.000+03:00

У меня появилась крамольная мысль почему идея SOA так популярна в корпоративном сегменте и так активно пиарится.

Исхожу из 2-х посылок:

SOA (сервисно-ориентированная архитектура) - это набор небольших сервисов, которые, как предполагается, должны быть замечательно друг с другом интегрированы.
Какие плюсы корпоративной SOA рекламируются:
1. Сервисы небольшие они "лучше продуманы и реализованы оптимальнее чем соответствующие модули крупных ERP систем".
2. Если нужен новый сервис его просто встроить в "конструктор" SOA, чем в крупную ERP.
3. Если у вас уже есть много разных систем, то с помощью SOA они начнут работать слажено.
Корпоративные информационные системы продаются вендорами, которым надо сначала убедить что их система самая-самая, потом внедрить систему (своими силами или с помощью сторонней компании) и потом бороться с просачиванием негативной информации о системе и результатах ее внедрения (а у любой крупной системы будут негативные отзывы какая бы она ни была реально).

Итак крамольная мысль: Вся шумиха вокруг SOA в корпоративных системах очень выгодна вендорам.

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

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

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

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

P.S.: К идее SOA я отношусь хорошо, но, imho, она, в основном, полезна не для корпоративных систем, а для конечнопользовательских наборов сервисов и продуктовых линеек.

technorati tags: IT, SOA

Стандарт по проектированию UI для Vista

2006-11-22T02:42:00.000+03:00

Стандарт здесь.

Мне нравится подход Microsoft к проектированию приложений (правда далеко не все приложения MS соответствуют их же рекомендациям). Начинается все не с самого проектирования UI, а с моделирования поведения пользователя. Даны общие рекомендации, рекомендации как сделать UI более простым в использовании , описаны стандартные ошибки.

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

Т.к. стандарт для Vista то есть раздел с общими рекомендациями того, как по мнению разработчиков Vista должно быть спроектировано приложение, и, конечно же, есть отдельный раздел о Aero Aesthetics - как должно выглядеть приложение, соответствующее Aero Aesthetics.

Так же не забыты рекомендации по применению контролов . Например, советуют чтобы объектов в RadioGroup было от 2 до 7 (раньше, кажется, было до 5). И напоминают, что если в выпадающем списке есть пустое значение, то запись не надо оставлять пустой, а надо ее пометить специальным значением (например (none)).

А еще (спасибо Алексею Копылову) рекомендации по тому как должна вести себя иконка в трее.

И еще много всего разного.

technorati tags: Стандарты, GUI, Vista, Microsoft

Новые технологии и Модные термины

2006-11-21T07:26:00.000+03:00

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

Появляется что-то новое, и сразу же все начинают стараться применить это на себя или "впарить" потребителю.

Но технологии как таковые не важны. Они сами по себе не дают преимущества. Они всего лишь часть инструментов бизнеса.

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

Т.ч. идти надо не от технологии, а от нужд бизнеса.

А вообще по поводу места IT технологий в бизнесе хорошо написано у Джима Коллинза в книге "От хорошего к великому" (глава 7 «Технологии как акселераторы»).

technorati tags: IT, Jim+Collins

Жизнеобеспечение проекта. Часть 2.

2006-11-19T05:17:00.000+03:00

Начало здесь.

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

Кликните по картинке для увеличения

Одна из основных функций Help Desk – поддержка пользователей (user support). Если у пользователя возникает проблема, он обращается в службу поддержки (request for support). Служба поддержки отвечает на запрос пользователя (reply for request). Довольно часто пользователи обращаются с однотипными проблемами. Для оптимизации ответов службы поддержки на однотипные проблемы удобно использовать шаблоны ответов (templates for support), хранящиеся в Wiki.

Основное предназначение Wiki – база знаний (knowledge base) проекта. На данном этапе интересны 2 "части" базы знаний – Help и технические особенности реализации (technical specifications). Разделение на части условно т.к. все должно храниться вместе, но разграничиваться на уровне прав доступа к статьям и частям статей.

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

Разумно организованный, постоянно обновляющийся и дополняющийся online help поможет снизить количество обращений пользователей в службу поддержки. Организация Wiki очень удобна для хэлпа т.к. перекрестные ссылки позволяют избежать дублирования информации в разных разделах. Однако классическую организацию wiki удобно дополнить иерархической структурой меток (tags), соответствующей разделам хэлпа, и каждую статью помечать соответствующими метками. Это поможет пользователю быстрее находить нужную информацию в хэлпе.

Если пользователь хочет новый функционал, информацию об этом служба поддержки передает (inform about request for new function) управляющему проекта (его роль будет рассмотрена позднее).

Если служба поддержки выявляет проблемы в функционировании проектом, то она информирует о ней (inform about bug) аналитика. При этом, если проблема была выявлена при разборе запроса пользователя, должна быть связь между ticket-ом запроса пользователя и ticket-ом бага. Почему служба поддержки для информирования о проблеме использует Help Desk, а не добавляет новую задачу сразу в Bug Tracking? Делается это для четкого разделения работы с неформализованной и формализованной частями проекта. Help Desk содержит неформализованные задачи по проекту, Bug Tracking – формализованные. Связью между ними является аналитик. О роли аналитика в следующей части.

technorati tags: Life Cycle, Development Team

Это уже было в Симпсонах

2006-11-16T18:33:00.000+03:00

Офтоп.

Жизнь:
Недавно в Нью-Йорке у статуи Вашингтона украли голову.

"The Simpsons":
Барт украл голову у статуи основтеля города (The Telltale Head (1990) - Season 1, Episode 8)

Ну что тут еще можно сказать? Это уже было в Симпсонах! ("South Park" The Simpsons Already Did It (2002) - Season 6, Episode 7)

technorati tags: New York, The Simpsons, South Park

Жизнеобеспечение проекта. Часть 1.

2006-11-14T01:33:00.000+03:00

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

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

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

Help Desk
Bug Traking
Source Repository
Wiki
CRM

Реализаций этих приложений огромное множество. Но появляется сложная проблема выбора:

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

Для решения нужно точно понять, кто и как в команде будет использовать эти приложения.

Без диаграмм вариантов использования тут не обойтись :-) (для проектирования использовался бесплатный oss продукт StarUML)

Первое приближение. Определяем набор ролей в команде и взаимодействие между приложениями.

Кликните по картинке для увеличения

Итак.

Интеграция приложений:

Help Desk использует CRM для получения данных об обращающемся пользователе и продукте, который использует пользователь. (CRM ID - идентификатор записи в CRM)

Так же Help Desk использует Bug Tracking для отслеживания реализаций задач. (BT ID - идентификатор задачи в Bug Tracking)

Bug Tracking, в свою очередь, использует Help Desk для отслеживания источника задач. (HD ID - идентификатор Ticket-а в Help Desk. Извиняюсь, не могу подобрать хороший русский аналог к Ticket)

Еще Bug Tracking использует Source Repository для определения, в какой версии файла исходника хранится изменение, внесенное для решения конкретной задачи. (SR ID - ссылка на версию файла исходника в Source Repository)

Роли:

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

technorati tags: Life Cycle, Development Team

SaaS великий и могучий

2006-11-11T02:51:00.000+03:00

Написала коммент к посту Даниила Фейгина "Модель продаж SaaS" и получился он таким большим и довольно развернутым, что я решила его здесь перепостить.

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

Механизм "нравится -- берите, желательно у нас не спрашивая" это мечта любого разработчика!

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

SaaS, в подавляющем большинстве, это тонкий клиент. А в браузере работать неудобно. Особенно с текстом. Это подтверждается большим количеством толстых приложений по управлению контентов блогов (как Windows Live Writer, BlogJet).
Приложения, используемые для автоматизации предприятий, должны быть интегрированы друг с другом (частично в эту тему Intel выпускает SuiteTwo). При использовании различных сервисов интеграцию их обеспечить нельзя.
Далеко не все фирмы готовы размещать свои приватные данные практически неизвестно где и у кого (ведь вначале постулировалось "желательно у нас не спрашивая"). Причем не только данные клиентов, но и всей внутренней кухни - базы знаний, управление проектами (как текущими так и будущими), логистика, финансы (какая фирма без финансов, а финансы еще хорошо бы подружить с CRM и управлением проектами) и т.д.
Возвращаясь к данным клиентов... Мне тут видятся 2 основные проблемы:
1. Возможная утечка грозит фирме не только, собственно, потерей данных, но и исками от своих клиентов, т.к. именно фирма, использующая сервис гарантирует клиентам приватность данных, а не IT компания этот сервис предоставляющая.
2. С CRM должны дружить большинство остальных модулей, а CRM должна уметь делиться ID-ками, автоматически добавлять данные (парсить email-ы и xml).

Итог: если бы для автоматизации компаний можно было бы применять 100% унифицированные процессы, не нужно было бы толп консультантов внедрения ERP систем.

Tags: SaaS

Enterprise 2.0 Suite от Intel

2006-11-08T20:34:00.000+03:00

Intel выпускает новый продукт SuiteTwo, объединяющий wiki, блоги и rss агрегаторы и нацеленный на корпоративное использование.

Явный плюс SuiteTwo в том, что будет единая точка управления всеми продуктам.

Сайт продукта, к сожалению, очень аскетичный. Описание возможностей SuiteTwo очень скудное.

Обещают возможность вести отдельные блоги по каждому продукту и интеграцию email, mobile и rss ленты в wiki.

Нет никакой информации о разделении доступа к статьям и частям статей в wiki. Для корпоративного использования wiki это необходимо, т.к. основное предназначение wiki – это база знаний для обмена знаниями внутри команд, между отделами, а так же предоставление постоянно обновляемой информации пользователям. Т.е. требуется вести не только публичную информацию, и без разделения прав доступа информация «внутреннего использования» не будет попадать в wiki. Кроме того разделение прав должно быть многоуровневым, с возможностью раздела доступа по отделам и должностям. Без этого использование wiki становится однобоким (только публичным или только внутренним) и резко падает эффективность от использования.

Более подробную информацию по продукту обещают прислать после регистрации на сайте. Как продукт выглядит не понятно вообще – нет ни демо, ни скриншотов.

Цен на сайте так же нет, но на Terralab есть информация о 175-200 долларов в год или 15-17 долларов в месяц в расчёте на пользователя. С одной стороны 15-17 долларов в месяц не много, но, с другой стороны, доступ нужен большинству отделов (суппорт, разработчики, маркетинг и т.д.), соответственно большому количеству пользователей, а это уже может вылиться в довольно крупные суммы. При большом количестве бесплатных и недорогих платных движков wiki и блогов финансовая выгода SuiteTwo как единой точки доступа, на мой взгляд, не очевидна.

Будем следить за развитием.

Tags: Enterprise Solutions

Google хочет мой номер телефона

2006-11-06T06:18:00.000+03:00

Google придумывает все новые способы, как выманить у нас наши private данные.

При открытии нового акаунта в Gmail (по ссылке из Picasa) Google первым делом спрашивает... номер телефона. На который предлагает прислать invitation code.

Хотела сделать screenshot со страной Russia, но оказалось, что Google знает всего 9 стран :-)

Требование телефона, похоже, связано с активным продвижением Gmail и других сервисов для мобильных.

SOA в Amazon.com

2006-11-04T14:58:00.000+03:00

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

Как сделать так, чтобы большая компания оставалась мобильной и быстро реагировала на изменения запросов клиентов знает Werner Vogels - CTO в Amazon.com.

Успешный рост Amazon.com был обеспечен сервисно-ориентированной архитектурой (SOA). На текущий момент Amazon.com является набором разнообразных сервисов, разрабатываемых и поддерживаемых независимо друг от друга.

Компания не является монолитной, а состоит из большого количества маленьких agile команд (2 pizza teams), раскиданных по всему миру. Каждая команда занимает свое место в сервисно-ориентированной структуре. Подобная организация дает Amazon.com быстроту реакции маленьких компаний.

Процесс определения требований к продукту Werner Vogels описывает как работу "задом наперед" (working backwards). Для соответствования услуг нуждам пользователей, процесс определения требований к услугам ведется начиная с документации, которая потребуется при запуске (пресс-релизы и FAQ), затем переходя к документации, относящейся непосредственно к продукту (руководство пользователя и прототип поведения пользователей). В результате получается набор документация полностью описывающий продукт. Эти наборы документации позволяют легко передавать знания о продуктах между отдельными командами внутри Amazon.com.

Здесь можно посмотреть интервью Werner Vogels, данное для ACM Queue magazine.

Tags: Development Team, Agile, Werner Vogels

В чем искусство?

2006-11-04T07:47:00.000+03:00

Я очень люблю всяческие стандарты и шаблоны.

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

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

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

Порядок ведения проекта и взаимодействия команды определяется выбранной методологией разработки ПО (Agile, Waterfall, RUP, BDUF).

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

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

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

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

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

Полезные ссылки:
Martin Fowler - один из лучших авторов на тему методологий разработки ПО.
maxkir.com – сайт Кирилла и Саши Максимовых с замечательной подборкой переводов книг и статей на темы процессов, методологий, анализа, проектирования и т.д. от таких авторов как Мартин Фаулер , Рон Джеффриз, Алистэр Коуберн.
Стандарт кодирования на Delphi.
Главы книги "Наука отладки".

Tags: Software Engineering, Development Team, Стандарты

Windows Mobile коммуникатор vs. ноутбук

2006-11-02T21:22:00.000+03:00

Михаил Козлов дал ссылочку на статью о преимуществах использования коммуникаторв с Windows Mobile платформой.
Хорошо описаны возможности Windows Mobile. Но преимущества показаны так, как будто у компаний вообще еще нет информационных систем. "Устройства Windows Mobile позволяют повысить производительность персонала за счет автоматизации бумажного документооборота".
Не хватает важного компонента - в чем преимущество использования коммуникатора с Windows Mobile по сравнению с ноутбуком. Ноутбуки становятся все меньше и легче. А использовать их для того, чтобы "получать доступ к нужным данным, даже находясь за пределами офиса" все-таки удобней.
В предлагаемой связке пользователям придется именно работать на коммуникаторах. Но у коммуникаторов слишком маленький экран и клавиатура. Коммуникатор не эргономичен, значит будут потери по времени и, возможно, по качеству работы.
Если в день сваливается несколько сотен писем их удобней разбирать на ноутбуке и пакетно, а не на телефоне по мере поступления. "Писать заказы" и т.д. тоже удобней на ноутбуке.
Упоминание ноутбука встречается только в статье с мнением компании IDC и выглядит, скорее, как рекламный оборот: "Where laptops simply allowed workers to move the location from where they would do their work, handheld devices are changing how the work gets done".
Есть какая либо статистика о замене компаниями у разъездных сотрудников ноутбуков на коммуникаторы?

Tags: Enterprise Solutions, Windows Mobile

Новые ExplicitХ проперти в DFM

2006-10-31T17:38:00.000+03:00

В Turbo Delphi в DFM стали писаться 4 новыx проперти: ExplicitTop, ExplicitLeft, ExplicitHeight и ExplicitWidth.

Добавляются они сами. В Object Inspector-е их нет и менять их нельзя т.к. они public read only. Объявлены в TСontrol.

Эти новые проперти здорово раздувают файл формы. Но самое противное:

Они постоянно меняются и при добавлении в VSS приходится тратить много времени на их вычитку.
Теряется обратная совместимость формы. Для открытия DFM в ранних версиях надо вычистить все ExplicitX проперти.

Описание этих странных пропертей в хэлпе нет.

Зачем же они нужны?

Внятного ответа от Borland мной не найдено (если кто-то нашел – поделитесь, плиз). В единственном объяснении сказано что в ExplicitX проперти запоминаются значения соответствующих пропертей размеров и расположения, которые были до изменения пропертей Align или Anchor из их дефолтных значений.

Проверяем:

В центр формы кладется панель. Форма сохраняется. В DFM ExplicitX пропертей нет.
Align панели ставится в alBottom. Форма сохраняется. В DFM у панели появились ExplicitX проперти со значениями, равными ее Top, Left, Height и Width, когда она была в центре.
Align панели ставится обратно alNone и… панель сама "прыгает" в середину формы. Форма сохраняется. В DFM ExplicitX пропертей нет.

Мне кажется этот эффект "прыганья" не стоит вышеописанных проблем.

И еще приведенное объяснение явно не полное, т.к. не объясняет эффект появления и исчезания ExplicitX пропертей в TabSheet-ах.

Tags: Turbo Delphi

Анкета от Borland для разработчиков

2006-10-30T23:42:00.000+03:00

Борланд в очередной раз выступил в репертуаре "хотели как лучше, получилось как всегда"

Анкета для разработчиков на тему "Как вам нравится Delphi и что бы вам хотелось видеть в дальнейшем":

http://infopoll.net/live/surveys/s30110.htm

Содержит более 200 вопросов! Они хотят знать наше мнение или в очередной раз решили испытать наше терпение?

Генерация XML документации в Turbo Delphi.

2006-10-30T00:35:00.000+03:00

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

Сопровождение компонентов, передаваемых сторонним разработчикам. В основном это коммерческие компоненты.
Как внутренняя документация для команды разработчиков.

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

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

Меня интересует второй случай. На текущий момент у нас используются обычные комментарии в объявлении классов, переменных, констант и т.д., и для ознакомления с функционалом юнита достаточно просмотреть его interface. Для упрощения взаимодействия между разработчиками и избавления от лишней информации (например вспомогательных переменных) хочется иметь возможность выгружать в отдельный файл объявления классов, всех public и protected членов класса с комментариями к ним и из protected членов класса только те, у которых есть комментарии. Это в идеале. С другой стороны задача, для нас, стоит не очень остро и дополнительных сил на написание своего парсера тратить не имеет смысла. Использование сторонних автоматических документаторов требует изменения формата комментариев и, соответственно, дополнительного контроля за правильностью их написания, что так же не имеет смысла.

Поэтому на генерацию XML документации в Turbo Delphi возлагались некоторые надежды. Были ожидания что с минимальными изменениями к требованиям к коментариям можно будет выгружать интерфейсы в читабельный вид. С другой стороны были опасения что или генератор будет глючить, или реализован будет так, что использовать его будет неудобно. К сожалению сбылись опасения.

В Turbo Delphi есть 2 варианта генерации XML документации:

При компиляции приложения создается XML файл для каждго юнита и файла проекта. Для этого должна быть включена опция "Generate XML Documentation" на закладке "Compiler" в "Project Options".
Можно создать единую документацию по всем исходникам приложения. Для этого должен быть включен "Together Support", а сама документация создается из "Model View".

В документацию идет вся информация по объектам + пользовательские комментарии (перед XML комментариями в коде должно быть ///). Вроде бы все хорошо, но…

Документация, создаваемая через "Model View" слишком "тяжелая". Ее, наверно, можно было бы использовать в качестве хэлпа для сопровождения компонентов, но там слишком много внутренней информации, которая в данном случае не нужна. Выбрать же уровень детализации (какие объекты выгружать в документ) нельзя. Насколько корректно работает данный генератор не проверялось т.к. стало ясно, что этот вариант генерации использоваться не будет.

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

Начинаем экспериментировать с генерацией XML документации при компиляции:

1. Создаем простенький класс с одной функцией. XML комментарии сделаны перед объявлением класса, объявлением функции и в теле функции (последний был добавлен чтоб проверить не добавляет ли генератор комментарии из тела функции к комментариям к самой функции).

...

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

2. Добавляем процедуру с комментарием перед объявлением, тело процедуры без комментариев.

Получаем XML с перепутанными комментариями. Вместо комментария к процедуре вставился комментарий из тела функции

3. Ну если не нравятся генератору комментарии в implementation уберем комментарий из тела функции, но добавим один после всех объявлений.

...

И опять получаем XML с перепутанными комментариями.

Нет ребята, такой документатор использовать нельзя. А жаль, такая идея хорошая...

Обживаемся в Turbo Delphi

2006-10-28T15:29:00.000+04:00

Не смотря на то, что Turbo Delphi, похоже, последняя реинкарнация среды, деваться некуда.

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

10 лет на Delphi5! Были, конечно, и 6, и 7 и далее по списку, но они в лучшем случае не давали существенных преимуществ, в худшем нещадно глючили :-( Т.ч. отдавать за них денег Борланду категорически не хотелось.

Ну, собственно, о самой Turbo Delphi.

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

Борланд решил совсем отказаться от старого варианта среды. Новая похожа на Майкрософтовские IDE. Основные изменения: работа с формой в design time и перенос палеты компонентов в docking window.

Сначала, конечно, пришлось среду "обживать". Раскладка desktop-а идущая по умолчанию (Default Layout) не понравилась т.к. мало места для кода (смотришь как через бойницу дзота).

Сделана стандартная настройка под себя (все вспомогательные окна убраны влево, настроены шаблоны, перенастроена подсветка).

Приятные новшества среды:

Более умные шаблоны автодополнения - возможность задавать в шаблоне несколько полей для ввода, переход между полями, автоматическая генерация переменных (например счетчик в for), разворот перечислимых типов (в case). Шаблоны теперь задаются в XML формате.
Автоматическая проверка синтаксиса "на лету".
Рефакторинг.
Автодокументация (правда возможность ее использования под сомнением).
Сворачивание отдельных кусков кода (директива {$REGION}).
Опция Surround.
Возможность закомментировать выделенный фрагмент кода (Ctrl+/).
Отдельная раскладка desktop-а во время исполнения (Debug Layout).
Поиск компонента в палете по первым символам.

Кое-что из вышеперечисленного появилось еще в BDS2005, но, т.к. BDS2005 была пропущена, считаю их новшествами BDS2006/Turbo. Работается быстрей и приятней.

Минусы:

Хотя шаблоны и более умные они, почему то, не вызываются при вводе параметров функции.
При установке требует поставить массу всего, что не понятно зачем нужно (зачем компилятору нэйтивного кода на Pascal нужен .netJ# ?).
Хэлп ставится при инсталляции по всем продуктам BDS 2006. При контекстном поиске вываливаются громадные списки среди которых приходится отыскивать записи, которые относятся к Delphi.
Хэлп написан неаккуратно. После нахождения пары ошибок/неточностей доверие вообще перестал вызывать,
Подглючивает Object Inspector. При переключении из Object Inspector в Project Manager и обратно Object Inspector теряет данные текущего контрола и обновляется только после повторного выбора контрола.
Debug Layout может быть только один. Т.е. может их быть много, но во время исполнения показывается тот, что с именем "Debug Layout".
Не работает User override для Enviroment Variables (была попытка изменить BDSPROJECTSDIR).
Попытка работать с Model View вызвала ощущение что его лучше не открывать вообще! Здесь тронешь - там посыпалось. Все изменения в моделе сразу же автоматом меняют код юнита, причем обычно криво.
Изменены некоторые ShortCut-ы. Например шаблоны автодополнения вызываются теперь по Ctrl+J. Здесь приведен список основных ShortCut-ов.

После более ближайшего рассмотрения какие то плюсы могут уйти в минусы. А минусы перестанут замечаться или просто выяснится что проблемы из за того что я еще "не умею их готовить".

А вот какие сюрпризы нам преподнесет компилятор будем выяснять в процессе работы.

Hello World!

2006-10-28T08:32:00.000+04:00

Ну с чего же еще начинать ;-)