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

AgileDays-2011: Отчет Беспальчука И.А./Тимофей Евграшин. Культура лидерства в Agile

2011-05-07T15:52:39Z

StasFomin: Новая страница: «{{star}}{{star}}{{star}}{{star}}{{star}} К сожалению, я попал на [[Культура лидерства в Agile (Тимофей Евграшин, ...»

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

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

Лидер — это тот, у кого есть последователи (followers), лидер не может быть один в поле (в группе). Или он не лидер.
Харизме, которая обычно присуща лидеру, на самом деле можно научиться (Фрейд)
Лидер дает волю тому, что уже готово двигаться (Юнг)
Современная культура управления постепенно дрейфует в сторону управления через лидерство, и не только в наукоемких отраслях
Теоретические идеи такого управления заложены Херши и Бланшером (Hersey, Blanchard) в теории ситуационного лидерства
Ближе к Agile: классический Scrum-мастер должен быть лидером и коучем
Найти такого SM очень непросто. Всегда проще кого-то просто назначить ;)
Лидером может быть и Product owner, это тоже хорошо работает
Если яркий лидер есть в топ-менеджменте компании, то культура лидерства хорошо внедряется сверху.
Снизу внедрять значительно сложнее.

Далее говорили про ответственность и стили управления.

Ответственность может быть делегирована, но не может быть передана! Делегировав кому-то что-то, ты в то же время оставляешь ответственность на себе.
Делегирование = поручение + полномочия + доверие. Доверие не подразумевает передачу ответственности.
Личная ответственность также поддается воспитанию.

Давно всем известна картинка с четырьмя стилями руководства — от директивного к делегирующему. Но эти ступеньки слишком велики и иногда совсем неясно, как переходить от одного стиля к следующему. Тут докладчик ссылался на книжку «Management 3.0» за авторством Jurgen Apello, которая совсем недавно вышла на английском языке. Jurgen вводит более плавную, семиуровневую модель стилей управления:

Указания
Уговоры и убеждения (продажа идеи, объяснение)
Опрос мнений
Участие
Совет
Обратная связь
Делегирование в чистом виде

Утверждается, что по такой лесенке подниматься значительно проще, так как ее ступеньки пониже :) Книжку, вероятно, стоит посмотреть тем, кто интересуется данной темой.

И напоследок еще несколько разрозненных тезисов из доклада:

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

В общем, рекомендую посмотреть запись, мне понравилось.

AgileDays-2011: Отчет Беспальчука И.А./Борис Вольфсон. Масштабирование Scrum на большую распределенную команду

2011-05-07T15:49:16Z

StasFomin: Новая страница: «{{star}}{{star}}{{star}} * [[Масштабирование Scrum на большую распределенную команду (Борис Вольфсон, Agil...»

Масштабирование Scrum на большую распределенную команду (Борис Вольфсон, AgileDays-2011)

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

Организовано это все в достаточно однородную («фрактальную»?) иерархию SCRUM’ов. Есть группы разработчиков, в них — достаточно классические SM и PO. Причем, SM у них вполне похож на руководителя проекта. Тут все как обычно — scrum meeting каждый день.

На втором уровне иерархии (Scrum of Scrum или S2) раз в три дня собираются все SM и PO, и обсуждают вопросы более высокого уровня. Здесь выделяется свой «главный» SM, который называется Program Manager, и который отвечает, по сути, за процессы целого офиса разработки. А для PO появляется Chief product owner, который определяет межпродуктовые приоритеты.

И, наконец, есть третий уровень, S3 или Scrum of Scrum of Scrum, где две управляющие лестницы наконец сходятся в топ-менеджменте. Всех chief product owner’ов координирует CEO, а всех program manager’ов — CTO. Примечательно, что S3 meeting происходит стабильно раз в неделю (из-за распределенности используют Skype и т. п.).

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

Масштабирование Scrum на большую распределенную команду (Борис Вольфсон, AgileDays-2011)

2011-05-07T15:38:06Z

StasFomin:

AgileDays-2011: Отчет Беспальчука И.А./Семен Молотков, Евгений Кобзев. Экстремальный аджайл — танцуют все

2011-05-07T15:32:11Z

StasFomin: Новая страница: «{{star}}{{star}}{{star}} Докладчики из команды компании СКБ «Контур», разрабатывающей любопытный се...»

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

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

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

Что удивило:

Они сидят в одной комнате (18 человек!). Считают это за достижение и говорят, что это им сильно помогает, но я реально не понимаю, как это возможно — или они по большей части молча работают.
Если задачу оценили в N, а по ходу дела выясняется, что она скорее 3N, то вместо того, чтобы обозначить это, они начинают «списывать пропорционально». Мне кажется, это искажает раннюю информацию об «успеваемости».

Еще из любопытного:

Они стараются делать такие вещи, как «презентации аналитиков и продвиженцев» — людей, работу которых очень сложно померить и пощупать. Но, стараются, просто чтобы команда была в курсе того, как идут дела.
Вроде бы у них нет формального PM, хотя наверное, все-таки, кто-то такой есть.
Позже, на Jam Session девушка по-моему именно из этой команды спрашивала, то делать с нудными и скучными скрам-митингами. Честно говоря, не удивительно при таком разбросе ролей в одной команде!
Рисуют фичи (user stories) и таски на спринт в виде mind map’а. В любой момент его можно дорисовать, декомпозировав какую-то задачу, и разложив суммарную ожидаемую трудоемкость на части.
Иногда они проводят «день ретроспективы», выезжая на базу отдыха. Думается, это классная практика, и не слишком накладная, на самом деле.

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

Что касается доклада, то он, увы, был довольно занудный. Рассказывали двое, но от обоих хотелось спать.

AgileDays-2011: Отчет Беспальчука И.А./Николай Алименков, Алексей Солнцев. В погоне за качеством: Code Review

2011-05-07T15:29:09Z

StasFomin: Новая страница: «{{star}}{{star}}{{star}}{{star}}{{star}} Два бравых украинских хлопца [[В погоне за качеством. Code Review (AgileDays-201...»

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

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

Что хочется отметить из любопытного, что нам непривычно, но, возможно, стоит попробовать:

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

AgileDays-2011: Отчет Беспальчука И.А./Хенрик Книберг. Все любят изменения, но никто не любит, чтобы его меняли

2011-05-07T15:24:57Z

StasFomin:

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

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

Так вот, краткая инструкция от Книберга на такой случай звучит так:

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

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

График счастья: Ну и кто способен его адекватно вести? Погода на мое эмоциональное состояние может влиять гораздо более сильно, чем обстановка на работе.

Дети, уберите комнату: Ха-ха, так я и поверил, что удастся замотивировать ребенка рассказом о том, что «все будет так красиво» :) Как быть, если мотивы (и ценности!) ваши сильно различны, но все-таки это твой ребенок?

Сопротивление из-за перекрестных страхов типа «Они не захотят!»: Рецепт «собрать всех вместе и обсудить» может и сработает, если называемая причина является действительной причиной. А ведь запросто «Они не захотят!» может быть просто отговоркой, скрывающей истиные страхи и нежелания что-то менять, которые вам фиг раскроют. Ведь, как известно, все лгут©.

Вот такие вот сомнения возникали по ходу доклада (может, я еще не слишком agile?). Но, повторюсь, в целом доклад хороший, рекомендую посмотреть в записи.

AgileDays-2011: Отчет Гребнева Н.Ю./Lean Software Development

2011-05-07T15:20:33Z

StasFomin: Новая страница: «''Никита Филиппов'' Поскольку предыдущий докладчик уложился в 15 минут вместо 45, то Никита з...»

Никита Филиппов

Поскольку предыдущий докладчик уложился в 15 минут вместо 45, то Никита за время, оставшееся до своего доклада, успел прочитать введение в Lean. Основная идея Lean — это сделать путь элемента бэклога от начала работ до окончательного внедрения как можно меньше по времени. Это предлагается делать при помощи ограничения задач находящихся в работе (то есть тех работы, по которым уже начаты, но они еще прошли внедрение). Польза от подобных практик понятна в разработке ПО (чем раньше мы увидим результат, тем больше вероятность того, что мы делаем нужные вещи, а не какую-нибудь ерунду), но для меня далеко неочевидна на материальном производстве (основы идеи Lean взяты из производственной системы Toyota).

AgileDays-2011: Отчет Гребнева Н.Ю./Принципы Lean и развитие аутсорсинговой компании: теория и практика

2011-05-07T15:14:18Z

StasFomin: Новая страница: «''Михаил Плискин'' [[Принципы Lean и развитие аутсорсинговой компании (Михаил Плискин, AgileDays-20...»

Михаил Плискин

Доклад о том, как в компании Ланит-Терком от нечего делать внедрили приципы Lean. Причем рассказ об этих самых принципах докладчик счел излишним, о чем прямо и заявил. Доклад длился 15 минут.

AgileDays-2011: Отчет Гребнева Н.Ю./Domain Driven Design в условиях разработки распределенных приложений

2011-05-07T15:12:41Z

StasFomin: Новая страница: «''Николай Гребнев'' ''[http://www.slideshare.net/ngrebnev/domain-driven-design-6988494 Презентация]'' [[Domain Driven Design в услов...»

Николай Гребнев

Презентация

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

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

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

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

AgileDays-2011: Отчет Гребнева Н.Ю./Jam session

2011-05-07T15:06:53Z

StasFomin: Новая страница: «Поскольку Антон Бевзюк не смог приехать, то вместо его доклада была проведена [[Jam session (AgileDa...»

Поскольку Антон Бевзюк не смог приехать, то вместо его доклада была проведена джейм-сессия. Обсуждались следующие вопросы:

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

Обсуждались какие-то еще темы, но они мне не запомнились.

Jam session (AgileDays-2011)

2011-05-07T15:04:39Z

StasFomin:

AgileDays-2011: Отчет Гребнева Н.Ю./Архитектура в Agile: переосмысляя идею модульности и компонентности

2011-05-07T15:01:01Z

StasFomin: Новая страница: «''Андрей Бибичев'' Андрей [[Архитектура в Agile — переосмысляя идею модульности и компонентн...»

Андрей Бибичев

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

AgileDays-2011: Отчет Гребнева Н.Ю./Командный старт

2011-05-07T14:57:16Z

StasFomin: Новая страница: «''Сергей Дмитриев'' Фотографии флит-чартов с [[Командный старт (Сергей Дмитриев, AgileDays-2011)|ма...»

Сергей Дмитриев

Фотографии флит-чартов с мастер-класса: http://www.dropbox.com/gallery/3490871/4/Documentation/Conferences/AgileDays%20Msk%202011/Team%20startup?h=06ae92

Какие бывают игры…

Это был мастер-класс посвященный такому процессу как «командный старт». Сергей под командным стартом понимает специально выделенное время, когда собирается вся команда вместе, а также люди имеющие отношение к проекту (типа Product Owner `a и руководства заинтересованного в результате), с целью познакомиться друг с другом и проектом в целом, а также определить общие ценности и видение проекта.

Сергей рекомендует для командного старта отвести один день. Командный старт необходимо проводить когда:

Собирается новая команда для проекта
В команду приходят новые члены
Команда начинает новый проект
При внедрении agile.

Проведение командного старта позволяет:

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

Во время командного старта необходимо сделать:

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

Первый и пятый шаги должны занимать большую часть времени командного старта. Сергей придерживается концепции Брюса Такмана по развитию команды (Forming-Storming-Norming-Performing) и считает, что при изменении состава команда вновь оказывается в стадии Forming и из-за этого некоторые команды никогда не выходят на performing. Командный старт направлен именно на то, чтобы сократить стадии forming, storming, norming и выйти на performing. Это необходимо потому, что производительность хорошо сработанной команды может быть выше в несколько раз, чем просто у группы людей собравшихся для выполнения одной работы (по некоторым исследованиям прирост производительности составляет до 400 %).

В качестве инструмента для проведения командного старта докладчик рекомендует использовать игры (в выступлении были приведены в качестве примера, игры «35», «Мне интересно…», «спагетти» и т. д.). Игровая форма расслабляет людей и позволяет быть более открытыми и ускоряет процесс решения задач. Например, для знакомства членов команд друг с другом просить каждого рассказать о себе достаточно бесполезно, так как из рассказа вряд ли удаться понять какими навыками человек обладает и чем он увлекается. А при использовании игры типа «рынок навыков» это получиться сделать легко и непринужденно. Сергей также рекомендует в качестве пособия по играм обратиться к книге Innovation Games.

После мастер-класса была серия вопросов и ответов не всегда по теме, но достаточно интересных. Мне больше всего понравился вопрос про то, как команда должна принимать технические решения. Сергей считает, что команда должна принимать решения только единогласно и пока среди всех членов команды не будет достигнуто взаимопонимание, то должно продолжаться обсуждение. При этом уровень решений, которые принимает команда, должен быть ограничен итерацией. Решения, которые влияют на проект в целом, должны приниматься product owner`ор, причем возможно без учета мнения команды или вопреки ему. Более того команда для product owner`а не является единственным инструментов для выполнения проекта, у него также могут быть люди не входящие в команду, но при этом работающие на проекте. Например, таким человеком может быть системный архитектор, который также в своей работе может не принимать во внимание мнение команды, но при этом должен убедить product owner`а в правильности своего решения. Фактически PO и его люди отвечают на вопросы, что делать, а команда — как делать, причем именно в рамках итерации.

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

Командный старт (Сергей Дмитриев, AgileDays-2011)

2011-05-07T14:54:17Z

StasFomin:

AgileDays-2011: Отчет Гребнева Н.Ю./Шаблоны «Асинхронный фильтр» и «HasValue» в разработке desktop приложений

2011-05-07T14:47:32Z

StasFomin: Новая страница: «''Дмитрий Ермаков, Олег Клинчаев'' Олег [[Шаблоны «Асинхронный фильтр» и «HasValue» в разработ...»

Дмитрий Ермаков, Олег Клинчаев

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

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

AgileDays-2011: Отчет Гребнева Н.Ю./Иду по приборам! Практические советы по визуализации работ

2011-05-07T14:16:51Z

StasFomin:

Максим Гапонов

Название существенно лучше самого доклада. Рассказ ни о чем. В качестве средства визуализации предлагается использовать майндмапы и картонные интерфейсы.

AgileDays-2011: Отчет Гребнева Н.Ю./Kanban vs Scrum — чьё кунг-фу сильнее

2011-05-07T14:15:19Z

StasFomin:

Кирилл Климов

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

AgileDays-2011: Отчет Гребнева Н.Ю./Ретроспективы. Настраиваем наш процесс разработки

2011-05-07T11:06:37Z

StasFomin: Новая страница: «''Сергей Дмитриев'' Интересный [[Ретроспективы. Настраива...»

Сергей Дмитриев

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

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

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

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

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

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

AgileDays-2011: Отчет Гребнева Н.Ю./Стратегическое планирование через инновационные игры

2011-05-07T11:03:28Z

StasFomin: Новая страница: «''Дмитрий Лайер'' Очень интересная тема, но, к сожалению, очен...»

Дмитрий Лайер

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

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

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

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

В докладе утверждается, что такой способ принятия решений гораздо продуктивнее обычного. Для ознакомления с различными видами игр и темой инновационных игр вообще докладчик рекомендовал книгу Люка Хохмана Innovation Games.

AgileDays-2011: Отчет Гребнева Н.Ю./Everyone likes change, but nobody likes to be changed

2011-05-07T10:55:38Z

StasFomin: Новая страница: « Доклад на англий...»

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

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

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

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

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

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

Компаниям-лидерам необходимы кастомизированные ИТ-решения

2011-05-06T15:41:39Z

Галина Цатурян:

Сергей Тихомиров: Руководитель направления «Финансовые институты» CUSTIS

PC Week, март 2011. http://www.pcweek.ru/idea/article/detail.php?ID=129557

Интервью в обзоре PC Week Review: ИТ в финансовом секторе, март 2011

Функционал системы и ее стоимость чаще всего являются определяющими факторами при выборе программных продуктов. К организациям, работающим в финансовой сфере, это относится так же, как и к любым другим. Вместе с тем гибкость, производительность, масштабируемость — не только слова из рекламных буклетов поставщиков решений, но и требования самого бизнеса, среды, в которой он существует и развивается. Устаревшие технологии, на базе которых реализован программный продукт, на определенном этапе станут тормозить его развитие. Как этого избежать? Какие продукты сегодня востребованы участниками российского финансового рынка? Руководитель направления «Финансовые институты» компании CUSTIS Сергей Тихомиров побеседовал на эту тему с обозревателем PC Week/RE Алексеем Ворониным.

PC Week: Какие насущные задачи и, соответственно, программные продукты, на ваш взгляд, актуальны сегодня для банков и других участников финансового рынка?

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

PC Week: На какие решения в сфере интеграции будут ориентироваться крупные банки?

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

PC Week: Есть ли у заказчиков интерес к специализированным системам, поддерживающим работу на рынке ценных бумаг?

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

PC Week: Ядро информационной системы любого банка — АБС, или учетно-аналитическая система. Как вы оцениваете состояние данного сегмента российского рынка?

С. Т.: Рынок АБС сформировался давно, и на нем, казалось бы, не может быть особой динамики. Основное количество программных продуктов — российского производства. Однако многие АБС, давно работающие в российских банках, устарели в плане идеологии и архитектуры, заложенных в них еще в 90-х годах прошлого века. Поддерживать с их помощью современный, динамично развивающийся банковский бизнес сложно: эти системы все чаще и чаще достигают предела производительности и не справляются с задачами масштабирования бизнеса. То, что многие российские производители перешли на современные СУБД типа Oracle или Microsoft SQL и выпустили новые версии АБС, не решает всех проблем. Это, конечно, снижает операционные риски при эксплуатации АБС, делает систему более надежной, но не всегда улучшает ситуацию с поддержкой бизнеса. Динамично развивающийся бизнес требует современной и эффективной технологии и архитектуры информационных систем.

PC Week: Есть ли на финансовом рынке симптомы того, что банки осознают эту проблему и как-то пытаются решить ее?

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

PC Week: А на какой платформе вы строите свои учетно-аналитические системы для банков?

С. Т.: Для реализации проектов мы используем программную платформу собственной разработки «Учетная машина». Базовыми технологиями этой платформы являются СУБД Oracle и сервер приложений .Net. Возможны альтернативные реализации с использованием СУБД Microsoft SQL и сервера приложений J2EE.

«Учетная машина» позволяет разрабатывать учетно-аналитические системы промышленного масштаба в любой сфере экономики. Мы имеем обширный опыт создания и внедрения уникальных по структуре, функционалу и гибкости учетно-аналитических систем для крупных коммерческих структур с территориально распределенной сетью, причем в самых разнообразных отраслях экономики — финансовой (крупный многофилиальный банк всероссийского масштаба), торговой (ГК «Спортмастер», крупный ритейлер), ЖКХ (коммунальный биллинг).

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

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

PC Week: Как много у вас заказчиков среди предприятий финансовой сферы?

С. Т.: Их немного, но в их числе есть очень крупные, такие как Банк России и Газпромбанк. Мы отдаем себе отчет в том, что заказчиков у нас и не может быть много, в противном случае мы рискуем потерять в качестве обслуживания проектов, каждый из которых уникален и требует особого внимания. Нашими клиентами становятся отраслевые лидеры и компании, работающие на быстрорастущих рынках . Для автоматизации их жизненно важных бизнес-процессов, как правило, не существует готовых коробочных решений, способных полноценно поддерживать динамику их развития. Для этого как раз и необходимы заказные (или сильно кастомизированные) информационные системы.

PC Week: Расскажите об одном из проектов, который реализуется в Банке России. В чем его сложность, эксклюзивность?

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

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

PC Week: Спасибо за беседу.

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

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

Управление изменениями в прикладном ПО уровня предприятия

2011-05-06T15:20:05Z

Галина Цатурян:

Беспальчук Игорь: руководитель отдела технологического развития CUSTIS

Статья опубликована в журнале Intelligent Enterprise, № 4 (апрель) 2011, стр 48-51 ^[1]

↑ "Intelligent Enterprise , № 4 (апрель) 2011, стр.48-51. http://www.iemag.ru/numbers/index.php?YEAR_ID=1185&ID=22953

Наш клиент сам может сконструировать себе портал

2011-05-06T13:38:15Z

Галина Цатурян:

Сергей Тихомиров: Руководитель направления «Финансовые институты» CUSTIS

Андрей Гущин: Заместитель руководителя направления «Финансовые институты» CUSTIS

Национальный банковский журнал, № 4, апрель 2011. http://www.nbj.ru/publs/upgrade-modernizatsija-i-razvitie/2011/04/04/nash-klient-sam-mozhet-skonstruirovat-sebe-portal/index.html

О том, как с помощью портальных решений от компании CUSTIS заказчик может самостоятельно создавать приложения, НБЖ рассказали руководитель и заместитель руководителя направления «Финансовые институты» Сергей ТИХОМИРОВ и Андрей ГУЩИН.

НБЖ: Какие функции выполняет информационный портал и когда перед кредитными организациями возникает необходимость в его создании?

С. ТИХОМИРОВ: Портал является внутренним информационным ресурсом, который содержит оперативные и справочные информационные материалы. По нашему опыту, наиболее востребованные возможности порталов — это:

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

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

НБЖ: Известно, что компания CUSTIS разрабатывает системы под конкретных заказчиков. Придерживаетесь ли вы такого подхода при создании портальных решений?

А. ГУЩИН: Именно в индивидуальном подходе и заключается уникальность наших решений. Мы не рассматриваем портал как «коробку» с ограниченным набором функций, при внедрении которой проводится точечная доработка. Мы подходим к порталу как к полноценной системе, которая включает в себя широкий набор бизнес-приложений и в процессе эксплуатации которой функционал может расширяться.

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

НБЖ: Вы сказали, что система адаптируется под заказчика. Какие параметры организация может «заказать»?

С. ТИХОМИРОВ: Адаптация может затрагивать многие аспекты системы, начиная с внешнего вида и заканчивая набором функций. Так, на стадии проектирования портала мы выясняем, какая информация является для заказчика самой важной, какие данные должны быть в оперативном доступе, какие сведения относятся к категории приватных, как будет осуществляться взаимодействие с пользователями и т. д.

НБЖ: Может ли заказчик самостоятельно поддерживать портал в процессе эксплуатации?

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

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

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

НБЖ: Можете привести пример проекта, в котором были реализованы описанные возможности?

С. ТИХОМИРОВ: В 2004 году для Банка России нами был создан интранет-портал, предоставляющий необходимую для работы подразделений банка информацию. Он был построен на основе Oracle Portal, который специалисты нашей компании дополнили собственной технологией быстрого построения портлетов. Она решает проблемы публикации таблиц и графиков, автоматического обновления данных в браузере пользователя, персона-лизации отчетов под требования отдельных пользователей и переноса готовых отчетов между портальными серверами.

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

* * *

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

Поведенческая модель DISC в Agile проектах (Кирилл Климов, AgileDays-2011)

2011-05-05T17:05:42Z

StasFomin: /* Аннотация */

Экстремальный аджайл — танцуют все (AgileDays-2011)

2011-05-05T16:57:45Z

StasFomin:

Kanban vs Scrum – чьё кунг-фу сильнее (Кирилл Климов, AgileDays-2011)

2011-05-05T16:54:23Z

StasFomin:

Ретроспективы. Настраиваем наш процесс разработки (Сергей Дмитриев, AgileDays-2011)

2011-05-05T16:49:46Z

StasFomin:

Эволюция Wiki-Way командной разработки

2011-04-28T08:31:33Z

StasFomin:

Докладчик: Виталий Филиппов [vitalif * mail % ru].
Доклад рассказан на DevConf-2011.
Аннотация и слайды: http://wiki.4intra.net/Wikiway-devconf

Сравнительный анализ хранилищ данных (Олег Царев и Кирилл Коринский на ADD-2010)/Стенограмма

2011-04-25T11:01:39Z

StasFomin: /* Что такое распределенные хранилища */

Сравнительный анализ хранилищ данных (Олег Царев и Кирилл Коринский на ADD-2010)/Стенограмма/Андрей

2011-04-25T07:26:16Z

StasFomin: Новая страница: «64px Андрей Аксенов:»

Андрей Аксенов:

Сравнительный анализ хранилищ данных (Олег Царев и Кирилл Коринский на ADD-2010)/Стенограмма/Олег

2011-04-24T17:54:03Z

StasFomin: Новая страница: «---- 64px Олег Царев:»

Олег Царев:

Сравнительный анализ хранилищ данных (Олег Царев и Кирилл Коринский на ADD-2010)/Стенограмма/Кирилл

2011-04-24T17:51:01Z

StasFomin:

Кирилл Коринский:

Удобная кросс-доменная авторизация (Илья Кантор на ADD-2010)

2011-04-23T19:45:44Z

StasFomin: /* Примечания */

Сравнительный анализ хранилищ данных (Олег Царев и Кирилл Коринский на ADD-2010)

2011-04-23T19:25:32Z

StasFomin:

Как сервисному отделу не стать бутылочным горлышком (Юля Нечаева, AgileDays-2011)

2011-04-22T14:21:25Z

StasFomin:

В погоне за качеством. Code Review (AgileDays-2011)

2011-04-22T14:20:04Z

StasFomin:

Фантом-ОС (Дмитрий Завалишин на ADD-2010)/Стенограмма

2011-04-22T12:08:45Z

StasFomin:

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

Я вот пользуюсь компьютерами двадцать пять лет, вы знаете, они с тех пор, в тех с которых я начинал, в них было две дискетки по 160Кб, и 48Кб оперативной памяти. Так вот, вы знаете, оно загружалось быстрее, чем то, что у меня сейчас есть, а функционально я примерно тоже самое с ней и делаю, я программы пишу на ней, редактирую какие-то тексты, и электронную почту читаю. А при этом процессор и память изменились, господи боже… я даже подсчитать-то не могу… Пять порядков, шесть порядков — куда все это проваливается? Это проваливается ровно туда, весь софт, который сегодня сделан, он сделан по принципу исторического развития, чего-то такого старого, страшного и несчастного.

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

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

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

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

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

Появились библиотеки. Потом эти библиотеки превратились в ядро, которое уже запускает прикладную программу. Итак все постепенно, постепенно все и стало нарастать, в конце концов появился Юникс. Юникс, на сегодня — операционка, которая явно победила, даже Винды сделаны по образу и подобию Юникса, концепт, на котором он основан, явно является доминирующим.

Интересно, что когда Юникс появлялся, а я достаточно старый, чтобы помнить эти времена, Юникс, как операционная система, был очень странный, и сильно уступал всем существующим операционкам. Была там машина, на которой мы работали, которая называлается PDP-11 (СМ-1600), на ней была родная операционка, и был Юникс. Родная операционка работала в разы быстрей Юникса. И тем не менее, она сегодня сдохла, а Юникс существует!

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

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

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

В принципе, в основе Фантома лежала довольно банальная мысль, которая начала зарождаться в районе девяностых годов. Когда появился язык C++, который появился в 1987 что-ли году, все зафанатели с объектного программирования, и возникла мысль, типа «Ну а что? Язык-то объектный, почему операционка то планарная? Надо бы и ее сделать объектной». Причем, это вообще говоря, довольно такая практичная мысль, которая не из каких-то метаний или идеализма проистекает, она проистекает из того, что реально иметь объектный интерфейс это совсем удобно. Если посмотреть на сегодняшнюю ситуацию, это очевидно так. Тот же самый C#, та же самая Ява, вполне себе оборачивают операционные системы в объектные обертки, это удобно.

Хорошо. Следующий шаг. Довольно понятно, что мы хотим, чтобы программы коммуницировали. Причем вот интересно, что … вот что я забыл сказать на этом разговоре про яву и C#, про то, что в C#, ну и вообще в виндах есть OLE. Это реально… при всей, извините, ублюдочности этого инструмента, лучше пока к сожалению нет. И этот инструмент реально решает совершенно осмысленную задачу.

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

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

Здорово, да?

Я как-то вот, в один из первых разов, когда я рассказывал про Фантом, там был большой зал, там было человек двести программистов — «Кто знает, что такое OLE?». И рук тридцать поднялось. Я спрашиваю — «А сколько на нем программируют? Реально сделали OLEшный инструмент какой-нибудь?». И такие вот, неуверенные три человека вот, причем видно, что два из них компильнули «Hello World», примерно, а третий что-то реально прорубил и сделал^[1]

Почему? — Очень тяжело. Очень-очень-очень тяжело.

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

Причем — в чем еще беда? Нормальное, естественное представление своих потрохов для программы, это граф объектов. То есть программа обычно работает с графом связных объектов, а единственный способ, которые реально работает на interprocess communication, это pipe. То есть дырочка, в которую можно байтик просунуть. То есть граф документов не пролезает никак, его можно сериализовать, но в этом случает, он оторвется от того, что у вас было, то есть его можно будет только скопировать в ту сторону. А дать куда-то реально, такой вот инструмент, чтобы можно было поработать вместе над общими данными, … ну OLE это как-то позволяет, но опять очень сложно. Но при этом, достаточно очевидно, что это ценная возможность. Почему это сложно? Потому, что много лет назад, какой-то умный человек, сказал, что операционная система, это ядро, которое запускает процессы. Процессы эти работают в отдельных адресных пространствах. И с тех пор, за ним, эту гениальную мысль постоянно повторяют. В то время, как на самом деле для managed-языков, которыми и Ява и C# являются, и вообще, все, что сейчас делается, это managed-языки, … вообще говоря, отдельные адресные пространства не нужны, потому что сами по себе managed языки — они хорошо управляют памятью, у них нет сишных проблем с убежавшим указателем, с порчей чужих данных.

Поэтому если перейти, сделать шаг к managed языкам, можно отказаться, от адресных пространств на уровне операционной системы. А дальше мысль пошла таким образом — ну хорошо, мы с вами взяли, написали, … (смотрит на экран) это Фантом там работает …

Грузится?

Нет, он уже загрузился, это он трудится.

Мы с вами взяли две программы, запустили их, и они — подружились. Одна другой какой-то поинтер послала, поскольку у нас общее адресное пространство, очень просто коммуницировать. Поинтер кинул, поменялся, за него можно дернуть, что-то забрать, что-то передать, чужие данные становятся как свои, буквально. Очень дешевые IPC. Только одна беда, вот вы вот эту программу остановили, и Pointer куда смотрит? Вроде как в никуда. Перезапустили, и даже если у вас pointer смотрит на старые данные, эта программа у вас снова запущена, данные в другом месте, связь прервалась. Я вот каждый раз, когда это рассказываю, привожу один пример. Вы когда запускаете Фотошоп, все запускали Фотошоп, там такое окошечко вылезает, начинает там бежать такая строчка — вот он вот это грузит, потом вот сюда потянулся, потом здесь что-то нашел такое, … и он делает это каждый раз.

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

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

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

Недавно пришел в голову пример: есть такие программы, которыми пользуются музыканты, называются секвенсоры. Вот все эти программы работают с двумя типами файлов — один тип свой, личный, в котором они хранят свое состояние полностью, это обычно некоторый proprietary формат, который обычно никому не известен. А второй — это какой-нибудь там «.midi». Файл, в который можно что-то записать, чтобы потом куда-нибудь можно было передать, в другую программу — это exchange format. Так вот, первого формата, в этом случае можно вообще не делать. Программа запустилась, построила свое состояние в памяти. Машинку выключили, при выключении машинка, как какбы это делается в Hibernate все это сохранила, вы включили — програмки все очнулись, как будто ничего не происходило. То есть они спокойно могут оставаться в этом состоянии, вы свою работу не потеряете, вы можете эту программу как угодно связывать, связность эта получается очень дешевой и эффективной.

Еще некоторые смешные вещи вылезают. Ну например, жизнь всех программ в одном адресном пространстве означает, что тут довольно эффективный ввод-вывод, потому что нет переключения контекстов, как это происходит сейчас, в ядре операционной системы. Из-за того, что контексты переключаются, и память программы может быть paged out, в нее нельзя делать напрямую нельзя делать напрямую ввод-вывод, его можно делать в буфер отдельно. Ну короче, есть некоторые заморочки. В этом случае, можно этого избежать. Почему этого нельзя было сделать давно? Потому, что для того, чтобы делать такие вещи, нужно иметь машины с очень большим виртуальным адресным пространством, в 32 битах Фантом не имеет большого смысла, то есть имеет, но понятно, что 32 бита, это пространство, в которое должен вписываться весь диск, а это не очень много, это всего-лишь четыре гигабайта, а дальше не влезает. Поэтому собственно, по большому счету, Фантом, как идея, ориентирован на машины 64 битные, а если 32 бита, то это видимо, телефон, или что-то простенькое, небольшое.

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

Первый путь, это нативные правила. У системы Фантом существует свой собственный байт-код, интерпретатор, который строит обьектную модель, аналогично явской и C#, под нее есть компилятор собственного языка, и в нее пишутся трансляторы из байт-кода Явы и C#. То есть теория гласит, что там Явский и C#-ный код, а также весь код, которыый написан на языках, которые компилируются в JVM и CLR, можно будет в Фантом затащить. Причем среда для него будет очень естественная, натуральная и весь этот код может взаимодействовать дешевыми способами через вот такую вот схему обмена поинтерами.

Вторая среда, которая изначально не планировалась, однако походу возникла мысль, что наверное нужно, это среда, такой POSIX-compatible, типа UNIX внутри Фантома, который мы планируем сделать в двух вариациях, одна вариация простая и элементарная. Просто запуск юниксовых приложений, скомпилированных под Фантом. То есть POSIX-среда, обычная-обычная POSIX-среда.

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

Ну и естественно, какой-то interchange между ними, который планируется сделать тоже очень интересным способом. Понятно, что современная операционная система не может не быть микроядерной, естественно, что втаскивать все в ядро может быть несерьезно, понятно, что микроядерность это в первую очередь средство коммуникации между компонентами, в том числе, ядром, драйверами и приложениями. Для этого существуют механизмы ядерного message parsinga, и выяснилось, я поисследовал этот вопрос… Вот если кто знает, была такая система операционная, называлась она BeOS. Довольно давно, французы, ушедшие из компании Apple, сделали платформу, такую вот довольно интересную, сделали для нее операционную систему, она не очень пошла, хотя где-то применялась, компания развалилась, а операционка перешла в open-source, и ее с тех пор пару раз реализовали, и сейчас она существуюет под именем Haiku.

Вот в ней, довольно такой приличный механизм, message parsinga существует, и мы собственно посмотрели на его и в Фантом его перетащили. То есть он рассматривается, как инструмент для расширения ядра компонентами, во-вторых, для взаимодействия между Си-шным кодом, и объектным кодом, потому что понятно, что message parsing очень хорошо втыкается с любой стороны.

Вот. Я тут ничего не вижу, что там на экране, думаю, что вы тоже ничего не видите^[2]…

Все грузится?

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

Но некоторые вещи делаются существенно дольше, чем должны.

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

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

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

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

В автомобилях современных применяются компьютеры, и даже если это Линукс… если Винды, то это вообще конечно беда, очень долго поднимается. Даже если это Линукс, даже если он очень компактный, он все равно довольно долго запускается. Реально, потребность такая есть. Нужна система, которая, во-первых, быстро запускается, и которая не предъявляет претензий в плане shutdown-а. Вышел из машины, ключи так чик — зажигание выключил, положил в карман, ушел. Систему убили. Включили — система должна заработать там же, где была, потому что вы что-то с ней делали, карту там смотрели, что-то такое, какие-то операции происходили. Разумно, чтобы каждая операция была в том же состоянии, в котором вы ее и оставили. Если говорить там про какие-то серверные системы, для медицины например, вот мой любимый пример — системы искусственного дыхания — прошла уборщица, дернула за вилочку, включила обратно, а он говорит — «а я сейчас диски почекаю…, что-то там загружу, что-то еще поделаю». Человек глядишь, там уже и не дождался. Соответственно в эту область мы еще как-то стараемся попасть, я считаю, что это довольно хорошая задача для нас.

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

Какая виртуальная машина?

Это TPL. Понятно, это белое окно, это собственно Фантомовское приложение, оно очень простое, там три строки у меня, там примерно

i = i + 1
print i

Но смысл в том, что по его состоянию видно, насколько … какое состояние было поднято системой. После перезагрузок видно, что она свое состояние сохраняет, и восстанавливает, … Какая? А виртуальная машина — я ответил.

Вот. В каком состоянии проект примерно? Мы этим занимаемся около двух лет, ну я не считаю, там годы раздумий, и метаний, в течении которых писались куски кода экспериментальные, которые сегодня уже все либо переписаны, либо по другой причине выкинуты из проекта. Около двух лет. Примерно год заняла реализация proof of concept, в которой я очень активно использовал внешний код, ну грубо говоря, собрал из интернета все, что подходит из стандартного колла, типа управления процессором, managmenta памяти, то, что не является специфичным для Фантома, все было использовано стандартное. И поверх этого была написана операционная система, которая реализует основные идеи.

Когда мне стало понятно, что она написана, существует, работает, снепшоты отрабатывают и восстанавливаются, была поставлена задача очистить все этот от кода, который лицензии нашей не соответствует. На сегодня задача была выйти в LGPL, и примерно полгода потребовалось на то, чтобы весь чужой, GPLный и какой-то еще код со странными лицензиями, переписать, заменить на свой. И на сегодня, ядро, кроме стека TCP/IP, который взят целиком, из другой системы под нормальной лицензией, все остальные системы написаны с нуля. Сам стек TCP/IP доведен до какого-то внятного уровня, вот есть там графические драйверы, есть базовые драйверы для стандартных, наиболее популярных десять лет назад сетевых карт, типа там NE2000, или известные RTLки.

Тесты на снепшоты, разработка ядра, вообще-говоря, это все надо постоянно тестировать, мы сделали test-suite, который практически каждый build прогоняется, на предмет регресса.

Сделан компилятор собственного языка, по совпадению, тоже называется Фантом, и сейчас в работе такие вещи. Как-то долизывается ядро, хотя в целом, оно по большей части готово, и идет работа над транслятором из байт-кода Java в Фантом. Меня часто спрашивают, почему у Фантома свой байт-код, почему не взяли явский, есть масса причин, одна из них заключается в том, что фантомовский байт-код, как бы это правильно сказать, по-научному… но в Яве существуют нативные типы типа int, float, такие вот, контентные как бы типы, а в Фантоме их нет, там все объекты, совсем-совсем-совсем.

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

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

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

В Фантоме не так, в Фантоме каждая отдельная функция, создает под себя отдельный стек, и в нем она живет. Почему? Потому что вы можете позвать метод чужого класса, и если он ошибается, что-то напортит со стеком, то это он вам испортит. То есть это будет порча между разными юзерами. Вот этого мы не хотели допустить, поэтому там все очень-очень-очень жестко разграничено, и сам по себе этот код, в виртуальной машине, он менее эффективен, чем явский, зато он очень строгий. Кроме того, я не знаю, правильно ли было это решение или нет, может мы от этого откажемся, Явская виртуальная машина она же как сделана? У нее есть фаза верификации байт-кода и фаза исполнения. Байт код загружают, она его просматривает — «так можно, так можно, так можно… а так нельзя — не будут запускать». Или «можно-можно-можно-можно, все хорошо, запускать буду». В процессе работы это все не проверяется. В Фантоме сделано по другому, в нем нет верификации вообще, но в процессе работы байт-кода проверяется все. Попытка выйти за границы массива, попытка выйти за размеры стека, все-все-все, все это проверяется на ходу. Это очевидно влияет на эффективность, и довольно заметно. Впрочем, может не надо этим сейчас заниматься, потому что в любом случае мы будем делать shipment, он сейчас в работе, понятно, что многие верификации, которые сейчас делаются в run-time, в процессе JIT-компиляции они будут сделаны статически, наверное всем это не поможет, но вот, это одна из таких архитектурных проблем, которых надо еще продумывать.

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

Первые полгода или даже год система работала без garbage collection-а, тратилось-тратилось-тратилось, а потом все падало. А начав делать garbage collection, я осознал неприятную вещь.

Нормальный фантом, вот нормальный, который будет на 64 битных машинах, он будет оперировать адресным пространством, объектным, размером с диск. То есть на сегодня — терабайт, два терабайта, завтра — десять терабайт примерно. И garbage collection, который нужно провести, нужно провести на всем этом самом терабайте или десяти терабайтах.

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

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

Я стал прикидывать, ну может быть, я не знаю, ночью она будет это делать… в тихую там… Полные, жуткие страдания, я реально раздумывал, не убить ли проект, потому что непонятно, что делать. Две вещи меня спасли. Первое — я почитал про Azul, которое реально, эти ребята научились делать garbage collection на терабайте, on stock.

Даже три есть выхода из ситуации.

Второй выход из ситуации, мы его пока не приняли, потому что все эти алгоритмы они, как выяснилось, кем-то довольно злобно лицензированы, в чем тонкость? Есть очень старый, добрый, простой способ garbage collection-а. Называется он reference counting. Мы считаем число ссылок на объект, упало в ноль — объект выкинули. Твердый, дубовый, работает довольно просто, очень даже можно жить, но опять же всем известно, что он не спасает, если у вас есть циклы объектов. Сделали колечко, у всех ссылочка больше чем нолик, все они будут валятся где-то в углу, внешней ссылки на это нету, вечно потерянная память, не собирается. Есть алгоритмы, оказывается, которые называются loop-breakers. Они каким-то образом анализируют, потихонечку идут вдоль объектов в системе, и как-то приглядывают, не цикл ли это? Если цикл — то они его разрезают, а дальше обычный garbage collection добивает. Хорошая штука, но с лицензиями непонятно, поэтому тоже решили откинуть в сторону.

И третий вариант, собственно, который пришел в голову, когда я пошел искать в интернете все, что есть на тему garbage collectionа, это большая такая область, тяжелая, нашел статью, в которой автор размышлял на тему,… В чем есть самая большая проблема garbage collectionа? Если мы все можем остановить, спокойно програмку выключить, и спокойно все обойти, то очень легко сделать сборку мусора. А если программа продолжает работать, то сборка мусора может оказаться неверной, причем неверной в неправильную сторону. Ладно бы она не нашла какой-нибудь мусор, так она может еще счесть мусором какие-то правильные данные, там очень простая ситуация, которая может случится, система обходит все объекты, вот некоторые объекты, представьте себе, отсюда на него есть ссылка, система ходила-ходила-ходила, не дошла до него через, слева, пошла вправо, а это время его взяли и отдали левому объекту, который уже был обойден до этого. Она и здесь, пока ходила, его не увидела, его перекинули, она его вообще не выдала, а он при этом вполне нормальный, живой.

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

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

Отсюда возникло очевидное решение. В Фантоме два garbage collectора. Сейчас пока один, второй в разработке.

Первый garbage collectoр сделан на ref-countах, он очень тупой, у него есть два важных свойства: он всегда коротко работает, очень маленькое, предсказуемое время нужно на проверку того, что ссылка стала нулем. Она стала нулем — убил локальный объект. Причем тоже я про это говорил, статистика говорит нам, что большинство объектов в системе создаются на короткое время и имеют одну ссылку. Поэтому refcount garbage collector очень быстро убивает коротко живущие локальные объекты. Поэтому основной оборот памяти в системе, garbage collector-ом c refcount-ом вполне себе обрабатывается. А какое-то количество долго живущих объектов с циклами, они постепенно откладываются, то есть остаются, не собираются, этим сборщиком мусора, попадают в snapshot, и после того, как случился snapshot, запускается длинный garbage collectор, который уже собственно сделанную фотографию системы медленно-медленно, спокойно ее обходит, находит в ней мусор, и его уничтожает.

Почему собственно я этого не боюсь? Когда я описывал это людям, которые занимаются garbage collectoрами, они меня спросили — вот ты не боишься, что недособранных объектов станет очень много и они всю память заполнят? Нет, не боюсь. Потому, что они заполняют виртуальную память. Ну, во-первых, диска у нас и так до хрена, во-вторых, хорошо, ну положим мы на него еще ну мегабайт, ну два, ну сто мегабайт даже, вообще говоря, современному диску это совершенно незаметно. Вот, более-менее решенная проблема.

Еще есть некоторое количество проблем, которые возникают именно в такого типа системах, в линуксах их быть не может. Например, как устроен системный вызов в обычной операционной системе? Работает программа, ей хочется сделать fileopen, она делает прерывание, попадает в ядро, … плохой пример. Скажем — read из socket-а. Попадает в ядро, начинает читать из socketа, а в socketе ничего нет! Что происходит? Она блокируется! То есть программа ушла в системный вызов, и там заснула. Когда данные появляются, она пробуждается, мы возвращаемся обратно в код, поехали дальше.

Такого в Фантоме делать нельзя. Почему? Потому что, как устроена память Фантома? Это какое-то несвоппируемое ядро, и после него, дальше, сверху, начинается эта часть памяти, которая персистентна, в ней живет вся наша обьектная…

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

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

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

Что еще такого, нетривиального? Ну во общем, на самом-то деле, по большому счету, нетривиальности все находятся на той стороне, на стороне ядра. Для программиста, Фантом — это очень простая вещь, система, которая такая же, как все остальные, только программы в ней живут вечно. Тоже в общем, неправильно говорю, потому что вызывает неверные ассоциации. Данные живут вечно! Программу можно убить, перезапустить, это обычный thread, который так же себя ведет. Потому что меня постоянно спрашивают — если программа вечно живет, а она сломалась, как же ее убить? Ну просто убить. Берешь и убиваешь. Тем же самым killом и убивешь, или нажатием на какой-нибудь крестик, там, в уголку. В этом плане никаких отличий нет. Просто данные, которыми она пользуется, они остались. При остановке процесса, все это остается.

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

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

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

↑ Стенографист был один из тех, что поднял тогда руку (было это на РИТ-2010), а делал я и OLE-объекты, и OLE-объект, который позволял запускать VB-скрипты через AXHost, а те скрипты использовали другие OLE-объекты… впрочем, было это реально давно, в 1997 году где-то.
↑ cм. нашу видео-скринкасто-запись, там все видно.

На пороге дополненной реальности: к чему готовиться разработчикам (Андрей Бибичев на ADD-2010)/Стенограмма

2011-04-21T09:28:47Z

StasFomin: орфография/пунктуация

Непрерывная интеграция при разработке баз данных (Владимир Бахов, AgileDays-2011)

2011-04-17T14:31:53Z

StasFomin:

Тестирование встроенного ПО: альтернатива классическому TDD (Дмитрий Овечкин, AgileDays-2011)

2011-04-17T14:24:57Z

StasFomin:

Модель системы — архитектура для Agile-разработки (Максим Цепков, AgileDays-2011)

2011-04-17T14:18:46Z

MaksTsepkov:

Почему я не люблю огурцы и фитнес — плюсы и минусы BDD и ATDD (Алексей Баранцев, AgileDays-2011)

2011-04-17T14:11:24Z

StasFomin:

Гибкая теория ограничений (Борис Вольфсон, AgileDays-2011)

2011-04-17T14:02:19Z

StasFomin:

Культуры программных проектов (Энтони Лаудер)

2011-04-17T13:49:01Z

VitalyKozlovtsev:

Автор: Энтони Лаудер (Anthony Lauder), англичанин, в разработке ПО с 1987 года, поработал в куче контор — Англия, Штаты (включая Силиконовую Долину), и в конце концов, на удивление, осел в Праге (Чехословакия).

Что важно понимать об авторе — это не методолог, не писатель, не тренер, не маркетолог-продавец, не фантазер, а достаточно успешный практик (разработчик, project and product manager, консалтер,…) у которого, наконец-то, дошли руки, отрефлексировать свое понимание и написать книгу.

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

Почему наш начальник заставляет нас следовать методологии, которая очевидно нам не подходит?

Почему программисты не делают того, что им говорят?

Почему я не могу внедрить у нас в компании методологию АБВ?

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

Если это наша культура, то что нужно сделать, чтобы изменить её? См. предисловие

Software Project Cultures: Книга свежая, 2008 год, на бумаге вовсе не публиковалась, автор просто выложил ее в вебе http://sites.google.com/site/anthonylauder/SoftwareProjectCultures.pdf и она стала набирать популярность.

Путь очень схожий с книжкой Книберга — «SCRUM from Trenches» — свободная публикация привела к популярности, и к переводам добровольцев.

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

Использование Ruby on Rails 3 для быстрой разработки сложных веб-приложений (встреча ALT.NET, 2011-02-24)

2011-04-14T11:50:41Z

StasFomin:

Докладчик: Мигальников Андрей (Медиахолдинг «Эксперт»)

Обзор Ruby on Rails 3.

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

Использование хранилища Redis для увеличения производительности.

Сравнение Ruby on Rails с ASP.NET MVC.

Использование Ruby on Rails 3 для быстрой разработки сложных веб-приложений (встреча ALT.NET, 2011-02-24)/не делайте презентаций на черном фоне

2011-04-14T11:48:09Z

StasFomin: Новая страница: «Пояснения и советы потенциальным докладчикам * никогда не делайте презентацию на черном ф...»

Пояснения и советы потенциальным докладчикам

никогда не делайте презентацию на черном фоне
никогда-никогда не делайте презентацию с программным кодом на черном фоне

Да, яркий код на черном фоне очень стильно выглядит на экране монитора и желательно в темноте. Но это нереально показать в зале с проекторами, если только не перейти в «режим кинотеатра», и выключить весь свет.

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

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

2011-04-13T14:38:01Z

StasFomin:

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

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

2011-04-13T14:29:54Z

StasFomin:

В отделе Технологического развития компании CUSTIS открыта вакансия Ведущего разработчика .Net (C#). Цель этого отдела — обеспечивать прикладных разработчиков других подразделений компании наиболее подходящими для решения их задач технологиями, инструментами, шаблонами и практиками, разработанными как внутри компании, так и во внешнем мире.

Вакансия руководителя группы разработки

2011-04-13T14:24:39Z

StasFomin:

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

Вакансия руководителя отдела разработки

2011-04-12T14:59:18Z

StasFomin:

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

Вакансия ведущего администратора Unix/Linux Oracle

2011-04-12T14:57:32Z

StasFomin:

В компании CUSTIS ведется постоянная работа по модернизации и развитию IT-инфраструктуры, встречаются инфраструктурные проекты у заказчиков компании.