Должен быть один руководитель
"Лидер проекта". Это титул, который легко ложится на плечи подобно хорошему пальто. Мы становимся чуть выше от ответственности и нагрузки, которую мы теперь несем. Да действительно мы можем всегда указать руководителя проекта - если даже нет других признаков, мы всегда можем его отличить по походке!
.. не столько человека с титулом, сколько человека, который твердо намерен осуществить проект. Он живет, ест и дышит проектом. Он намерен выполнить его или умереть. В любое время он держит руку на пульсе проекта и знает как он идет... Весьма неверна интерпретация его как человека, чей зад пришпилен к проекту и кого обязательно уволят, если проект не будет сделан.
Одна из вещей, которая может случится с вами как с руководителем проекта, состоит в том, что ваше лидерство может оспариваться другим членом команды. Это означает что кто-то еще пытается стать неформальным лидером проекта и отобрать у вас власть. Если это произойдет вы должны нейтрализовать вызов.
Фергус О'Коннэл "Как успешно руководить проектами. Серебрянная пуля"
Армия это не только красивое слово, но еще и быстрое дело
Прапорщик Казаков, х/ф "ДМБ"
Есть тут очень интересный момент - это объем усилий, затрачиваемых на руководство проектом. Как правило он составляет 6-8% общих усилий по проекту. Несложно посчитать, что для больших проектов, один человек физически не сможет справиться с руководством. Тогда и появляются иерархии.
Не помню точно какое количество человек является оптимальным для проекта, по Бруксу кажется не более 10.
Вообще мне не кажется однозначным это утверждение. Возьмем например совет по управлению изменениями. Т.е. дело вроде меньшее чем руководство проекта, но требуется совет!
Все-таки я думаю что это сказано про технического руководителя. Есть ведь еще рукводитель/консультант от бизнеса. Который участвует в определении приоритетов и помощи в спорных ситуациях. В общем мне кажется тема до конца не раскрыта ... возможно специально упрощена... Также руководство экстремальных методологиях хочется поднять.
Как закончу пересмотр книги попытаюсь сделать полномасштабный обзор. Смотрел внешние ссылки на блог - кто-то порекомендовал ознакомится с моим непредвзятым мнением. Спасибо! Попытаюсь радовать обзорами и дальше. Действительно есть некоторое количество книг, которые для айтишника прочесть крайне желательно. И сталкиваюсь что многие просто не слышали ни Брукса, ни Де-Марко и даже Боэма. Откровения приходят и в 30 лет и наверное даже позже... "Радости профессии" и "Метод БигБук" Брукса способны пробуждать чувства даже у взрослых айтишников 
Большинство книг повторяет одно и тоже и в общем случае, если читал одно - второе , третье .. десятое можно пропустить. Но есть некоторые с совсем противоположным вектором. Так например пока большинство бродит среди призраков сроков, бюджета и функциональности, Купер говорит, что хороший продукт рынок может и подождать.
Адаптивное планирование
Мартин Фаулер, Основы UML, третье издание
Эта школа поддерживает адаптивное планирование в соответствии с утверждением, что прогнозируемость это иллюзия. Вместо того, чтобы дурачить себя иллюзорной предсказуемостью, мы должны повернуться лицом к реальности постоянных изменений и использовать такой подход в планировании, при котором изменение в проекте является величиной постоянной. Это изменение контролируется таким образом, чтобы в результате выполнения проекта поставлялось как можно лучшее программное обеспечение; но хотя проект и контролируем, предсказать его нельзя.
Различие между прогнозирующим и адаптивными проектами проявляется разными путями, когда люди говорят о состоянии проекта. Когда утверждается, что выполнение проекта идет хорошо, поскольку работа ведется в соответствии с планом, то имеется ввиду метод прогназирования, При адаптивной разработке нельзя сказать "в соответствии с планом", поскольку план все время меняется. Это не означает, что адаптивные проекты не планируются; обычно планирование занимает значительное время, но план трактуется как основная линия поведения последовательных изменений, а не как предсказание будущего.
На основе прогнозирующего плана можно разработать контракт с фиксированной функциональностью по фиксированной цене. В таком контракте точно указывается, что должно быть создано, сколько это стоит и когда продукт будет поставлен. В адаптивном плане такое фиксирование невозможно. Вы можете обозначить бюджет и сроки поставки, но вы не можете точно зафиксировать функциональности поставляемого продукта.
Адаптивный контракт предполагает, что пользователи будут сотрудничать с командой разработчиков, чтобы регулярно пересматривать требуемую функциональность и прерывать проект, если прогресс слишком незначителен. Как таковой процесс адаптивного планирования может определять проект с переменными границами функциональности по фиксированной цене.
Естественно, адаптивный подход менее желателен, поскольку все предпочитают большую предсказуемость программных проектов. Однако предсказуемость зависит от точности, корректности и стабильности множества требований. Если вы не в состоянии стабилизировать свои требования, то прогнозирующий план базируется на песке, а изменения настолько значительны, что проект сбивается с курса. Отсюда вытекают два важных совета.
1. Не составляйте прогнозирующий план до тех пор, пока не получите точные и корректные требования и не будете уверены, что они не подвергнуться существующим изменениям.
2. Если вы не можете получить точные, корректные и стабильные требования, то используйте метод адаптивного планирования
Выбор правильных людей
Фергус О'Коннел. Как успешно руководить проектами. Серебрянная пуля.
Глава 17. Выбор правильных людей
Метод собеседования
Все компании говоря, что люди являются наиболее важным их ресурсом, но сколько же их видит процесс найма и проблемы, связанные с людьми, как дело отдела кадров или отдела людских ресурсов. Люди определяют, как мы сделаем наши проекты. Именно поэтому они наш наиболее важный ресурс.
Мы использовали двухэтапный подход в собеседованиях с людьми. На первой стадии я производил предварительный отбор всех резюме и проводит предварительные беседы.
Беседы были короткими (полчаса), и в них на самом деле задавалось толко три вопроса:
Что вы сделали?
Что вы хотите делать?
Что вам нравится?
На втором собеседовании, которое могло длится 3 или 4 часа, соискателю надо было встречаться с как можно большим числом людей из команды: коллегами, подчиненными, менеджерами. Мы поощряли соискателя походить и пообщаться с людьми, особенно с сотрудниками, делающими работу, аналогичную его будущей работе. Соискатель делал это безо всякой цензуры, то есть он мог заговорить с любым попавшимся ему сотрудником, а последний мог отвечать все, что взбредет ему в голову... Мы утвердили такую точку зрения, что нам нечего скрывать, что люди должны увидеть нас без прикрас. Мы хотели, чтобы люди почувствовали, как будет выглядеть работа в нашей команде, и именно поэтому интервью продолжалось столь долго, и кандидат видел так много людей: это было минимальное расстояние, с которого он мог разглядеть нас, прежде чем принять решение о работе здесь.
Что вы сделали?
Именно на этом этапе вы выясняете, какой опыт и квалификация есть у человека. Для любой высокотехнологичной области существуют определенные проф. навыки и умения, котрые важны. Мы ищем людей, которые описывают свою карьеру в терминах этапов или достижений и, собственно, являются проектно-ориентированными людьми. Типичные вопросы здесь:
Какой величайший момент в вашей жизни?
Три вещи, которые вам больше всего нравилось делать в вашей жизни?
Какая самая большая неудача?
Что вы хотите делать?
Ключевой вопрос - использование личных целей человека в интересах выполнения нашего проекта. Если человек не знает, что он хочет, то я почти никогда не возьму его. Если он не знает, что хочет, то как вы можете использовать его в вашем проекте - это ведь может оказаться не тем, что ему надо?
Понятно, что я не задаю вопрос в лоб, и, если человек не отвечает, выбрасываю его за дверь. Я готов к исследованию и провожу его по необходимости самым тщательным образом. Однако в конце дня вам все равно нужно извлечь из кандидата правильную информацию. Невероятно, но иногда это может быть первый раз, когда они поняли, что они хотят делать. Мы задаем вопросы типа:
Что вы определенно не хотите?
Если бы вы могли выбирать абсолютно любую работу, что бы это было?
Вас устраивает, как идет ваша карьера?
Что вами движет?
Вы считаете себя человеком, ориентирующимся на задачу или на людей?
Что вы делаете на досуге?
Что мог бы сказать о вас кто-то другой - прежний начальник, ваша подруга?
Насколько сильно вы хотите работать?
Вам надо знать, каков будет этот человек, когда он появится в вашей команде. Вы знаете, что вы хотите делать с вашим проектом и какую роль вы хотите поручить этому человеку. Вопрос состоит в том, что сам этот товарищь хочет делать.
Что вы любите?
Ну и наконец вы должны получить представление об индивидуальности человека. Вы чувствуете, что он будет соответствовать общему духу вашей группы?
Опишите вашу личность.
Вы тот тип человека, для которого, если я попрошу сделать какую-либо работу, то могу расценивать ее как выполненную?
Какие у вас сильные и слабые стороны?
Расскажите о себе что-нибудь отрицательное.
Что вы любите читать?
--
Первоапрельские приколы кодеров, программистский юмор, самые смешные подборки картинок и фото предлагает вашему вниманию развлекательный ресурс shodka.net.
Успешный проект
Разгребал внутреннюю документацию компании и натолкнулся на определение успешного проекта 2005 года:
Успешный проект - проект, который завершается с требуемым уровнем качества в установленный срок в рамках бюджета.
Спишем это на "древность" документа Совершенно понятно что должно быть в определении еще достижение цели проекта ...
Управление проектам для корпораций
На простой вопрос "когда проект считать успешным" часто можно услышать очевидный ответ. Проект успешный тогда, когда цели проекта достигнуты и при этом он выполнен в установленные сроки и не вышел за рамки бюджета. Однако не всегда можно дать простой ответ на простой вопрос.
Типы проектов
По мнению В. Либерзона, прежде всего нужно принимать во внимание то, что проекты могут иметь разные цели и критерии успеха. С этой точки зрения следует все проекты разделить на три типа.
Бизнес-проекты, ориентированные на получение максимальной прибыли (например, проект по контракту).
Организационные (инфраструктурные) проекты, нацеленные на улучшение бизнес-процессов и реализуемые за счет внутренних ресурсов организации (сюда относятся ИТ-проекты)
Социальные или политические проекты — они не имеют целью получение прибыли.
Проекты конкурируют между собой за ресурсы, и это важный аспект оценки их успешности.
Удача проекта лежит за его пределами
Правильная оценка успешности проекта - нетривиальная задача. Возникающая при этом проблема состоит в том, что прибыль бизнес-проекта возникает в результате использования продукта проекта, т.е. она возникает за пределами жизненного цикла собственно проекта. Это значит, что проект должен быть ориентирован на получение максимальной прибыли на протяжении всего жизненного цикла продукта. Но сам размер прибыли еще мало о чем говорит, следует ориентироваться на экономическую эффективность инвестиций в жизненный цикл продукта. При этом следует иметь в виду, что проект является всего лишь одним из первых этапов этого жизненного цикла.
Как связать успех команды и успех проекта
Наряду с вопросом об успешности проекта стоит и вопрос об успешности команды проекта. Совершенно очевидно, что команда в проекте может быть успешной, а сам проект — нет; возможно и обратное. В самом деле, команда уложилась в ограничения проекта, но оказалось, что проект убыточен - его цели были поставлены перед командой неправильно. Или напротив, команда достигла результата с опозданием и перерасходом бюджета, но при этом с точки зрения прибыли проект оказался успешным. Чтобы он таким стал, необходимо совместить интересы команды проекта и организации, исполняющей проект. Это определяется принятыми критериями и системой мотивации. Критерии должны быть такими, чтобы в точках принятия решения о продолжении работ (kill points) можно было оценить целесообразность управленческих решений.
Еще статья полезная ИТ не терпит риска
В период взлета доткомов в конце 1990-х многие критиковали Уоррена Баффета за отказ от инвестиций в Internet-компании. Его ответ акционерам был таков: «То, что толпа с вами не согласна, не может быть критерием ошибочности ваших суждений. Вашу правоту могут подтвердить только верные исходные данные и логичные рассуждения». Со временем правильность этих слов подтвердил рынок, а Internet-бум теперь чаще называют Internet-пузырем. Какой урок могут вынести из этого ИТ-менеджеры? Минимизировать риски при выборе ИТ-проектов можно только путем правильного подбора исходных данных и четких рассуждений и обоснований.
Джордж Хилмейр, бывший директор DARPA, финансировавшего разработку лежащих в основе Internet технологий, выдвинул набор критериев, называемых иногда катехизисом (наставлением) Хилмейра, по которым оценивались соискатели грантов DARPA. ИТ-менеджерам стоит воспользоваться этой методикой при сборе данных, анализе и обосновании предлагаемых проектов, а также для оценки проекта с точки зрения его эффективности для компании. Этот набор критериев поможет подготовить необходимые данные для защиты проекта перед высшим руководством. В данной статье катехизис Хилмейра представлен в виде восьми наборов вопросов. Ответы на эти вопросы помогут подготовить полноценное предложение проекта...
Peopleware от Ларри Константина
Решил сложить чужой опыт командной работы и взялся за перечитывание классиков. Странно, но толчком послужил пост Блеск и нищета специализации и обсуждение XML для систем ориентированных на данные и подборка постов Корпоративные паразиты.
Читая Ларри Константина сразу можно уловить некоторые моменты. Интересно обратить внимание на дату статьи - поистине ИТ это техническая профессия без памяти
... Согласно исследованиям, коллективные решения зачастую сводились к более рискованным вариантам по сравнению с теми, которые сотрудники группы могли бы принять самостоятельно... Однако другие исследования групповой динамики показали, что при выполнении задач и принятии решений в группах имеет место эффект нивелирования, который сводит результаты к своего рода наименьшему общему знаменателю индивидуальных способностей и вкладов. Казалось, что один человек принимает более верные решения...
Очевидно, что такие эффекты зависят главным образом от организации и методов управления в группе. В России, где я работал с консультантами и руководителями новых предприятий, "посредственность" доминировала благодаря старой советской системе. Для многих руководителей, учившихся еще при старом советском режиме, командная работа означала переход на уровень общей некомпетентности. В советской системе управления работа в команде часто позволяла избежать ответственности. Иногда коллективы умышленно занижали свою производительность. Отстаивание своей точки зрения или выдвижение новой, спорной идеи грозило не только недовольством коллег, но и возложением ответственности и ожиданием подобных инициатив в будущем. Зачем беспокоится, если производительность никак не вознаграждается, а потерять работу в типичном советском коллективе трудно даже при большом желании?
Социальный и организационный климат, в котором работает группа, - это как раз то, что в действительности определяет возможность раскрытия потенциала. Для достижения лучших результатов корпоративная культура и само руководство группы должно активно поощрять и поддерживать новаторство и сотрудничество. В известном смысле, команды советского периода работали действительно хорошо, удовлетворяя реальные ожидания начальников и политических руководителей, хотя их усилия больше сводились к прикрытию тылов, нежели к достижению результатов. Советские менеджеры говорили мне, что они научились "никогда не оказываться крайними".
... Совместная разработка и принятие решений дает наилучшие результаты, если решение рождается из талантов всех участников команды и отражает их опыт, творческие способности и умение мыслить критически. Речь идет не об отражении "в среднем", а об истинном синтезе, в котором соединяются лучшие качества каждого сотрудника. Какими бы талантливыми ни были лидеры группы, но если они начинают проталкивать собственные решения, качество работы всей команды снижается.
... Исследования показали, что если руководитель откладывает изложение собственных идей до тех пор, пока все участники группы или их большинство не представят свои, группа приходит к более совершенным решениям. Это означает, что лидер, который всего лишь высказывается слишком рано, возможно, снижает качество работы группы. Самоуверенные руководители, убежденные в том, что они всегда правы и знают все на свете, могут создать наибольшие трудности в работе.
... Большинство лидеров проектов и руководителей среднего звена в сфере разработки ПО являются довольно сильными специалистами. Почти каждый из них поднялся из отделов программирования, системного анализа и проектирования. Они достигли своего положения потому, что разбираются в вопросах разработки программ.
... Хороший лидер является другом для каждого и, в то же время, не является чьим-то адвокатом. Такой лидер стремится получить вклад от каждого, никого не выделяя... помогает прийти к техническому консенсусу, но не оказывает влияния на исход обсуждения и не навязывает свой вариант решения.
Computer Language Magazine, №3, март 1992
Команда и хороший командный игрок
Если каждый станет петь одну и туже ноту, вы не получите гармонии. Для достижения гармонии нужно чтобы люди пели разные ноты, которые сочетаются друг с другом.
Джошуа Якобсон, дирижер хора Zamir
Что касается людей, то они всегда намного более гибки, чем программы. По крайней мере, некотрые люди.
Лари Константин
Некоторое время назад задался вопросом определить, что же такое хорошая команда и хороший командный игрок в отношении производства ПО. Посмотрите объявления о работе - всем нужен "good team player", но кто и как определяет для себя этот термин?
Надо сказать, что дать однозначный ответ мне самому довольно трудно, собеседователи тоже часто ограничиваются просто распросами "где больше работал самостоятельно или в команде?"
Для затравки что-то типа определения "настоящая команда позволяет добиться большей производительности, чем если бы участники работали по отдельности". Стоит сразу упомянуть прямой антипод - толпу, где вся "команда" )или группа) оказывается на уровне самого невменяемого своего участника.
Первое что нужно сказать - всегда есть несколько измерений. Например, проекты бывают разные и , по хорошему, жизненный цикл выбирается под конкретный проект. В качестве отличного вводного материала здесь можно посоветовать известную статью Алистера Коберна Каждому проекту своя методология. Есть разные стили управления ...
Пока писал PS пропал почти весь задор с упором, так что идеальные команды оставлю наверное на следующий раз ... Если коротко
Тщательное исследование результатов показало, что ключевым фактором было разнообразие... Для наибольшей производительности руководство командой должно быть представлено в нескольких лицах. Обычно функции лидера распределяются между членами команды, а не аккумулируются в одном "супер-лидере", играющем все эти роли. Такая модель "совместного лидерства" является отличительным признаком успешных групп...
Одна из трудностей заключается в том, что почти каждый предпочитает работать с людьми, похожими на него, в то время как производительность команды повышается, когда ее составляют люди, непохожие друг на друга. Разнообразие навыков и стилей работы, в которых эти навыки проявляются, придает команде гибкость.
Хоть это сказано про команды разработки ПО, если посмотреть на те же команды по "Караоке-капитализм" и "Бизнес в стиле фанк" мы увидим абсолютно такие же выводы и для других бизнес-команд, занимающихся производством при помощи интеллекта.
Здесь можно сделать первый интересный вывод "в идеале каждый новый командный игрок должен отличаться от всех остальных участников команды". Т.е. хорошим он будет если не похож на всех остальных и в каждой конкретной команде это будет кто-то другой, хотя люди собираются для работы над общим делом Кстати тут сразу интересно посмотреть идеальные команды от Брукса, Белбина, Де-Марко, RUP, MSF, Scrum, XP, ...
Команды также в идеале должны подбираться под конкретные проекты.
Властная пирамида
Ответственность возлагается на кого-либо, кто может принимать решения и отдавать приказы (желательно, чтобы этот человек разбирался в деталях и тонкостях дела). Подразумевается, что решения принимаются строго сверху вниз... Не требуется никаких консультаций. Не нужны никакие обсуждения, ни дискуссии, ни исследования....
Когда речь идет о разработке ПО командной работе, традиционная модель лучше всего подходит для того, что называется тактической работой. В тактических проектах территория знакома, а параметры известны. Самое главное - это выполнить работу... вы знаете каждый свой шаг и сможете сделать их даже во сне.
Ясность имеет решающее значение для тактической командной работы - ясность требований, ясность инструкций, ясность ролей. В этом мире методы разработки становятся более эффективными, если они хорошо определены и опираются на ясные стандарты и нормативы. ... Тщательно продумать ЖЦ и последовательность этапов. В такой команде внимание группы акцентировано на текущей задаче. Точка. Члены команды больше всего нуждаются в ясных инструкциях от лидеров проекта и руководства. Каждому члену команды назначается конкретная часть хорошо понимаемой работы, и все выполняют то, что должны делать...
... независимые индивидуалисты и традиционная иерархия - это несовместимые понятия.
С вершины пирамиды или изнутри может показаться, что другого способа организации и управления не существует... Либо вы руководите, либо выполняете указания, либо уходите с дороги.
Методы хаоса
Суть состоит в том, чтобы извлечь все лучшее из изобретательной энергии вольнодумцев, поощряя дух свободных исследований и личной инициативы. Нужно поддерживать некоторый творческий беспорядок, граничащий с хаосом, - своего рода контролируемое безумие, которое позволяет отойти от шаблонов, ограничений и расширить представление о собственных возможностях. Все это противоречит закрытым шаблоном корпоративных пирамид, поскольку подрывает основы власти и выбрасывает традиционный подход на ветер... серьезно угрожает традиционным методам управления, однако это как раз то, что нужно для освоения новых земель.
Деятельность "команд прорыва" зависит от индивидуальной инициативы. Решения принимаются не централизованно, а самостоятельно, на рабочем месте - теми, кто обнаружил проблему и знает, как ее решить... общий интерес и любовь к игре, а также взаимное уважение игроков друг к другу удерживает их от того, чтобы разбежаться в разные стороны.
Необходимые элементы - (1) хорошие люди с хорошей подготовкой, владеющие хорошими приемами (2) достаточные или даже избыточные ресурсы. Процесс свободного создания и проверки новых идей имеет важнейшее значение.
Адаптивное сотрудничество
(мой коммент- средний случай, наверно именно этот тип команд подразумевают HR когда пытаются оценить ваш good team player level)
Члены команды тщательно согласовывают свои действия. Решения принимаются колективно в процессе обсуждений, переговоров и построения консенсуса. Это не значит, что все во всем соглашаются, однако они приходят к техническому консенсусу... все члены команды поддерживают действия и решения, выработанные группой по всем главным вопросам. Для этого требуется, чтобы каждый мог внести свой вклад в важные решения. Такой подход позволяет каждому сотруднику "вложиться" в совместное усилие и гордится своим личным участием в коллективном продукте.
Синхронное плавание. Эутопическая команда
Люди вокруг вас делают все, что должно быть сделано. Не нужно стоять над душой у каждого или разъяснять что-либо на пальцах. Все идет гладко потому, что люди, которые работают для вас или вместе с вами, разделяют ваши представления о работе команды - о том, что нужно делать и каким образом. Это люди, которые вам подходят; они думают так же, как и вы, и во многом смотрят на мир вашими глазами. Едва вы успеваете сказать слово, как они уже принимаются разрабатывать следующий набор модулей или кодировать расширения для графического пользовательского интерфейса, или делать еще что-нибудь нужное. Все - люди, программное обеспечение, программирование - подходит друг другу так точно, как будто вы все придумали сами, не прилагая к этому никаких усилий. В команде не существует конфликтов и не нарушается дисциплина. Подобно команде по синхронному плаванию, это само совершенство и гармония.
Лари Константин, Software Development Magazine №17, июль 1993
Надеюсь не утомил цитированием. Просто кто-то подумал уже за нас и это можно использовать. В общем командное разнообразие вносит еще больший сумбур в определение того, кто же он такой "хороший командный игрок". Очевидно что это будет зависеть от проекта и от стиля руководства. Иногда самый лучший - самый опытный, а в других моментах самый послушный.
ЗЫ.
Если взглянуть на мой опыт командной игры, то в играх в разработку он будет крайне скудный, в большинстве случаев это было два человека - я и заказчик. Иногда заказчиков было два, иногда мне кто-то помогал. Однако если посмотреть немного раньше, то картина более оптимистичная. Например я несколько лет подряд в школе ходил в походы, большие и маленькие, день, неделя, месяц. Разбить лагерь, подготовить дрова, приготовить еду. Вообще поход это отличнейшая аналогия проекта и размером и командой...
Не заню можно ли как-то к опыту командой работы приплести ВУЗ ...
Еще вспоминается стройка, как-то писал, что поработал некоторое время подсобником. Начав буквально без опыта работы, закончил лучшим подсобником за все шабашки для шести профессиональных строителей. Кстати интересна иллюстрация к тому, почему нужно брать новичков.
Я вырос индивидуалистом и по настоящему командной разработки не пробовал. Так просто получилось, что с самого начала я был немножко дальше чем все остальные. Так в институте я знал Turbo Pascal, лучше преподавателя и закончил курс программирования за 2 дня, успев еще объяснить преподавателю работу с оверлейными модулями... Потом я объяснял преподавателям тонкости проектировании UML, ER, SADT диграмм... Сам увлекался стандартами, методологиями, жизненными циклами, рисками, оценкой - сам вопросы задавал - сам искал ответы. После института доказывал руководителю выбор средств разработки и критиковал изначальный подход, далее критиковал стил ведения проекта ... В последнем проекте был просто предоставлен сам себе - делал проект и общался с заказчиком. В любом случае не думаю, что это испортило меня окончательно
Специалисты веб-студии «Rubix» возвели оперативность в стандарт – на создание сайта с несложной структурой они затрачивают не более 48 часов.
ftp-proxy в freebsd
Дело было ранней зимой. Требовалось обеспечить доступ из интернета к ftp-серверу в локальной сети. Сперва решил тупо перенаправить на него порт 21 и порты выше 1025, но выглядело это не очень красиво.
В результате было решено поднять на шлюзе прокси-сервер для протокола ftp (ftp-proxy - портированный из openbsd вместе с pf) и настроить его для работы в обратную сторону.
Что нужно сделать:
1. Добавить в файл /etc/inetd.conf строку:
ftp-proxy stream tcp nowait root /usr/libexec/ftp-proxy ftp-proxy -R <local-ftp-server> -S <local-net-if>
где
<local-ftp-server> - ip-адрес внутреннего ftp-сервера,
<local-net-if> - ip-адрес внутреннего интерфейса шлюза.
2. Настроить параметры запуска inetd в /etc/rc.conf:
inetd_enable="YES"
inetd_flags="-wW -c 60 -a 80.xx.yy.zz"
где 80.xx.yy.zz - внешний ip-адрес шлюза.
3. Настроить pf:
rdr on $ext_if proto tcp from any to $ext_ip port ftp tag TRAF_FTP -> 80.xx.yy.zz port 8021
< ... skip ... >
pass in on $ext_if reply-to proto tcp tagged TRAF_FTP flags S/SA keep state
pass out on $ext_if proto tcp from $ext_ip to any flags S/SA user proxy keep state
pass in on $ext_if proto tcp from any to $ext_ip flags S/SA user proxy keep state
pass out on $int_if proto tcp from $int_ip to any flags S/SA user proxy keep state
pass in on $int_if proto tcp from any to $int_ip flags S/SA user proxy keep state
где
$int_if - локальный интерфейс,
$int_ip - ip-адрес локального интерфейса,
$ext_if - внешний интерфейс,
$ext_ip - ip-адрес внешнего интерфейса,
proxy - имя пользователя ftp-proxy.
4. Запустить inetd.
# /etc/rc.d/inetd start
Прокси-сервер может работать в пассивном режиме. Работу в активном режиме не проверял.
Шаблонная виртуальность (Parameterized Virtuality)
Помимо использования С++ интересно использовать трюки, которые позволяет этот язык. Одним из таких трюков является Parameterized Virtuality(C++ Templates: The Complete Guide By David Vandevoorde, Nicolai M. Josuttis).
Параметризированная виртуальность позволяет указывать будет ли использоваться механизм виртуальных функций при работе с иерархией классов.
Для этого использутся два класса:
view plainprint?
struct not_virtual_type {};
struct virtual_type
{
virtual void method() {}
};
Далее, определяется базовый класс иерархии:
view plainprint?
template< class vbase >
struct base: private vbase
{
void method() {}
};
И класс наследник:
view plainprint?
template< class type >
struct derived: public base<type>
{
void method();
};
Теперь, при использовании класса derived мы можем указать, использовать ли виртуальность. Это делается следующим образом:
view plainprint?
template< class T >
void test(base< T >& t)
{
t.method();
}
view plainprint?
base< not_virtual_type >* ptr = new derived< not_virtual_type >;
test(*ptr); // здесь вызывается base::method()
delete ptr;
base< virtual_type >* vptr = new derived< virtual_type >;
test(*vptr); // здесь вызывается derived::method()
delete vptr;
Интересная штука- индексируемые свойства С# и Pascal(Delphi)
Прикольная штука Вопрос как в C# сделать код который может реализовать вот это
program IndexerTest;
{$APPTYPE CONSOLE}
{%TogetherDiagram 'ModelSupport_IndexerTest\default.txaPackage'}
{%TogetherDiagram 'ModelSupport_IndexerTest\IndexerTest\default.txaPackage'}
{%TogetherDiagram 'ModelSupport_IndexerTest\default.txvpck'}
{%TogetherDiagram 'ModelSupport_IndexerTest\IndexerTest\default.txvpck'}
uses
SysUtils;
type
TTestIndexer = class
strict private
procedure SetProperty1(i:integer;val : Integer);
function GetProperty1(i:integer) : Integer;
procedure SetProperty2(i:integer;val : Integer);
function GetProperty2(i:integer) : Integer;
private
ar: array of integer;
public
constructor Create;
property Property1 [i :integer]: Integer read GetProperty1 write SetProperty1;
property Property2 [i :integer]: Integer read GetProperty2 write SetProperty2;
end;
var
///<directed>True</directed>
IndTestArr: array[0..2] of TTestIndexer;
i,j:integer;
constructor TTestIndexer.Create;
var
i:integer;
begin
inherited;
SetLength(ar,3);
for i := 0 to 2 do
ar[i] := i;
end;
function TTestIndexer.GetProperty1(i:integer): Integer;
begin
result := ar[i];
end;
procedure TTestIndexer.SetProperty1(i:integer;val : Integer);
begin
ar[i]:= val;
end;
function TTestIndexer.GetProperty2(i:integer): Integer;
begin
result := ar[i];
end;
procedure TTestIndexer.SetProperty2(i:integer;val : Integer);
begin
ar[i]:= val;
end;
begin
{ TODO -oUser -cConsole Main : Insert code here }
for I := 0 to 2 do
begin
IndTestArr[i] := TTestIndexer.Create;
IndTestArr[i].Property1[2] := 2;
end;
for I := 0 to 2 do
begin
for j := 0 to 2 - 1 do
with IndTestArr[i] do
Write(Property1[j],' ',Property2[j]);
Writeln;
end;
readln;
end.
Что тут интересно так это то что на C# влоб задачу не решить.
Нужно исхитриться
Такой код не пройдет
class testind
{
int [] ar;
public testind ()
{
ar = new int[3];
ar[0] = 1;
ar[1] = 2;
ar[2] = 3;
}
void setP1( int i, int val)
{
ar[i] = val;
}
int getP1( int i)
{
return ar[i];
}
public int this[int i]
{
get{ return ar[i];}
set{ ar[i] = value;}
}
public int this[int i]
{
get{ return this.getP1(i);}
set{ return this.setP1(i,value);}
}
}
А такой пройдет
class testind: IMyProp1,IMyProp2
{
int IMyProp1.this[int i]
{
get{ return ar[i];}
set{ ar[i] = value;}
}
int IMyProp2.this[int i]
{
get{ return ar[i];}
set{ ar[i] = value;}
}
public IMyProp1 MyProp1{ get {return this;}}
public IMyProp2 MyProp2{ get {return this;}}
int [] ar;
public testind ()
{
ar = new int[3];
ar[0] = 1;
ar[1] = 2;
ar[2] = 3;
}
}
Только использовать придется таким способом – через указатель на интерфейс
MpTd.MyProp1[1] = 10;
MpTd.MyProp1[3] = 10;
------------
Престижный мобильный телефон от известного производителя – признак успеха любого делового человека. Купить самые прогрессивные модели вы всегда можете на сайте Esms.com.ua.
Узнать интересную информацию про бодибилдинг, программу тренировок и спортивную диету можно на сайте artbody.ru.
Свежие новости строительной России, последние технологии и материалы в отделке интерьера – все это сайт Pbloks.ru.
MSF на Intuit.ru
Прошел курс "Технологии программирования на базе Microsoft Solutions Framework" на Intuit.ru и даже получил диплом набрав 87 баллов.
Данный курс читается в 4-ом семестре и опирается на прочитанные ранее общие курсы CS101 "Введение в методы программирования", CS102 "Методы объектно-ориентированного программирования", в рамках которых студенты знакомятся с фундаментальными понятиями, принципами и методами программирования, изучают основные алгоритмы, простейшие структуры данных, языки программирования Object Pascal и C/C++. В 3-ем семестре студенты изучают первую часть курса CS103 "Алгоритмы и структуры данных", выполняют лабораторные работы согласно учебному плану. Таким образом, полученных к 4-му семестру знаний и навыков достаточно для того, чтобы приступить к ознакомлению с технологиями коллективной разработки программ.
Конечно, уровень студента 2 курса все еще не позволяет овладеть этой темой полностью, поэтому учебный план предполагает изучение нескольких последовательно расположенных курсов, первым из которых, вводным, является данный курс - "Технологии программирования. Курс на базе Microsoft Solutions Framework (MSF)".
Курс так себе - можно почитать для общего развития. Курс расчитан на 2 курс института. Присутствуют примеры и презентации. Что-то подкачало описание выше - внутри курса исходники проект на Java.
Читал несколько лет назад редакцию 3.0 на русском. Автор курса пишет, что изменений в версии 4.0 много, но особо на них не останавливается. Основное различие это разделение на два типа процессов - легкий и тяжелый.
Вот бы кто сделал MSF в Eclipse EPF ..
********
Обширная фотогалерея современных офисов бизнес центров, банков представлена на сайте "Архитектурной студии Кузьмина" по адресу k-studio.ru. Спешите видеть, как обставляются самые роскошные офисы в мире.
Не знаете, что такое андроидный коллайдер? Исчерпывающий ответ найдется в блоге Ивана Победы!