Правило 1. Руководитель проекта должен посетить каждого, кто занят в его проекте хотя бы один раз. Он должен знать всех менеджеров в своём проекте (как из государственных органов, так и у субподрядчиков), а также членов команды проекта. Людям нравится, когда руководитель проекта заинтересован в их работе, и лучше всего посетить их лично и увидеть самому, что они делают.
Правило 2. Руководитель проекта должен четко знать мотивацию участников проекта (то есть их систему премирования и штрафов, их регламенты и другие компоненты культуры этих компаний).
Правило 3. Принципы управления не изменяются. Меняются только средства. Вы попрежнему должны найти нужных для выполнения работы людей и найти путь, следуя которому они смогут выполнить задание.
Правило 4. С кем бы вы не имели дело, будьте честны и справедливы. Многие области бизнеса настолько специфичны, что все люди знают в них друг друга. Вы можете быть удивлены тем, насколько часто вам придётся работать с одними и теми же людьми. Пусть лучше они уважают вас, чем тащат за собой груз своего недовольства вами.
Правило 5. Руководители проектов могут быть порочными и совершенно неприятными людьми. Но они не могут быть бездушными, нерешительными, копушами или болтунами.
Правило 6. Подходящим руководителем проекта может быть тот, кто ждет следующего назначения или находится на грани неудачи. Полная безопасность не характерна для руководителя проекта.
Правило 7. Одной из проблем нового руководителя проекта является то, что все ждут от него решения своих проблем. Старым руководителям проектов старшее руководство обычно говорило «решите ваши собственные проблемы, мы вас нанимали именно для этого».
Правило 8. Текущая деятельность обычно не оставляет времени для того, чтобы вы могли думать. Вы должны выкроить время для того, чтобы «понюхать розы». При вашей работе вы должны иметь время, чтобы понять последствия ваших действий.
Правило 9. Руководитель может не знать, как должна выполняться работа, но он знает, чего он хочет. Он лучше определит, чего он ожидает, и хочет, даже если он не знает как. Слепой лидер имеет тенденцию к движению по кругу.
Правило 10. Не все успешные менеджеры компетентны и не все потерпевшие неудачу менеджеры некомпетентны. Удача играет существенную роль в успехе или неудаче, но удача предпочитает компетентных и трудолюбивых руководителей.
Tuesday, January 13, 2009
Tuesday, March 4, 2008
Конфуций... вот прав мужик
«Что можно сказать о человеке, если все в деревне его любят?» — «Это никчемный человек», — ответил Конфуций. «А что можно сказать о человеке, которого все в деревне ненавидят?» — «И это никчемный человек, — сказал Конфуций. — Лучше, когда хорошие люди из этой деревни его любят, а дурные — ненавидят».
Tuesday, February 26, 2008
Жикаренцев
Законы этой жизни таковы, что вы можете решать в ней любые проблемы, неважно, где находятся их корни и кто их породил. Действуйте, а помощь придёт всегда.
Saturday, February 23, 2008
О течениях
"Если вас внезапно подхватило течение ..... не пытайтесь бороться с течением и плыть против него. Вместо этого плывите перпендикулярно течению." учебник OWD стр 129.
Судя по всему это будет работать и в большинстве жизненных ситуаций....
Судя по всему это будет работать и в большинстве жизненных ситуаций....
Monday, February 11, 2008
Жаль что не я придумал.....
По настоящему счастлив лишь тот, кто зависит только сам от себя (Цицерон)
Friday, January 4, 2008
Введение в AspectJ
Введение в AspectJ
Этот раздел кратко познакомит Вас с основными возможностями AspectJ, которые встретятся далее в этой главе. Эти возможности – ядро языка, но тем не менее не полное его описание.
Особенности языка мы рассмотрим на примере простого графического редактора, где есть фигуры (Figure) состоящие из частей FigureElements, которые, в свою очередь, могут быть либо точками (Point) либо линиями (Line). Класс Figure предоставляет фабричные функции (имеется в виду GoF Abstract Factory, прим перев). Существует, также, класс Display. Большинство примеров данной главы базируются на данной системе.
UML для системы FigureEditor
Основным фактором, побуждающим использовать AspectJ (или использовать AOP в целом), является понимание того, что существуют проблемы, которые плохо решаемы при помощи традиционных методологий программирования. Рассмотрим, к примеру, проблему обеспечения безопасности некоторого приложения. По своей природе, безопасность пронизывает множество модулей системы. Более того, в силу постоянной эволюции системы, безопасность должна равномерно охватывать и все новые модули системы. Сама система безопасности тоже может эволюционировать. Путь использования традиционных подходов для решения таких проблем как политика безопасности является сложным и порождает множество ошибок.
Концепции, вроде безопасности, пронизывают элементарные части системы. В ООП языках, элементарная часть системы является классом. Но в ООП языках внедрение сквозных концепций является затруднительным, так как приходится изменять сами классы, что в свою очередь, делает повторное использование кода практически невозможным. Такие классы сложно улучшать, от них сложно наследоваться, потом такие классы неконтролируемо распространяются по всей системе… короче – не удобно и все тут.
Аспектно - ориентированное программирование – способ обобщения сквозного подхода, равно как ООП является способом обобщения общих концепций предметной области. AspectJ – реализация АОП для Java.
AspectJ добавляет в Java лишь одну новую концепцию – join point - в реальности, это лишь название для уже существующей в Java концепции. А также добавлены еще несколько новых конструкций – pointcut, advice, объявление inter-type и aspects. (я даже не буду пытаться перевести эти, всем понятные термины на русский язык, чтобы не быть оплеванным – прим переводчика ). Pointcuts и Advice влияют на выполнение программы динамически, определения inter-type на иерархию классов системы статически, а аспекты инкапсулируют эти новые конструкции.
Join point – явно определенная точка программы. Pointcut консолидирует набор join point и данных в них. Часть кода advice будет выполнена в том случае, когда будет достигнута join point. Это были динамические составляющие AspectJ.
AspectJ содержит различные виды inter-type определений, которые позволяют разработчику модифицировать статическую структуру программы, а именно – члены классов и зависимости между классами.
AspectJ's aspect является базовой сущностью сквозного подхода. Их поведение напоминает Java классы, но может содержать pointcuts, advice и определения inter-type.
(Далее по тексту будут использоваться слова джоинпоинт, поинткат, адвайс, аспект, интертайп – прим перев.)
В разделах, которые последуют прямо сейчас, мы собираемся рассмотреть джинпоинты и то, как их объединять в поинткаты. Потом мы рассмотрим адвайс: код, который запускается в момент достижения поинтката. Мы рассмотрим, как комбинировать поинткаты и адвайсы в аспекты – базовые сущности AspectJ, которые доступны для повторного использования и наследования. И, наконец, мы рассмотрим, как использовать интертайп определения для обеспечения сквозного подхода в контексте классов программы.
Этот раздел кратко познакомит Вас с основными возможностями AspectJ, которые встретятся далее в этой главе. Эти возможности – ядро языка, но тем не менее не полное его описание.
Особенности языка мы рассмотрим на примере простого графического редактора, где есть фигуры (Figure) состоящие из частей FigureElements, которые, в свою очередь, могут быть либо точками (Point) либо линиями (Line). Класс Figure предоставляет фабричные функции (имеется в виду GoF Abstract Factory, прим перев). Существует, также, класс Display. Большинство примеров данной главы базируются на данной системе.
UML для системы FigureEditor
Основным фактором, побуждающим использовать AspectJ (или использовать AOP в целом), является понимание того, что существуют проблемы, которые плохо решаемы при помощи традиционных методологий программирования. Рассмотрим, к примеру, проблему обеспечения безопасности некоторого приложения. По своей природе, безопасность пронизывает множество модулей системы. Более того, в силу постоянной эволюции системы, безопасность должна равномерно охватывать и все новые модули системы. Сама система безопасности тоже может эволюционировать. Путь использования традиционных подходов для решения таких проблем как политика безопасности является сложным и порождает множество ошибок.
Концепции, вроде безопасности, пронизывают элементарные части системы. В ООП языках, элементарная часть системы является классом. Но в ООП языках внедрение сквозных концепций является затруднительным, так как приходится изменять сами классы, что в свою очередь, делает повторное использование кода практически невозможным. Такие классы сложно улучшать, от них сложно наследоваться, потом такие классы неконтролируемо распространяются по всей системе… короче – не удобно и все тут.
Аспектно - ориентированное программирование – способ обобщения сквозного подхода, равно как ООП является способом обобщения общих концепций предметной области. AspectJ – реализация АОП для Java.
AspectJ добавляет в Java лишь одну новую концепцию – join point - в реальности, это лишь название для уже существующей в Java концепции. А также добавлены еще несколько новых конструкций – pointcut, advice, объявление inter-type и aspects. (я даже не буду пытаться перевести эти, всем понятные термины на русский язык, чтобы не быть оплеванным – прим переводчика ). Pointcuts и Advice влияют на выполнение программы динамически, определения inter-type на иерархию классов системы статически, а аспекты инкапсулируют эти новые конструкции.
Join point – явно определенная точка программы. Pointcut консолидирует набор join point и данных в них. Часть кода advice будет выполнена в том случае, когда будет достигнута join point. Это были динамические составляющие AspectJ.
AspectJ содержит различные виды inter-type определений, которые позволяют разработчику модифицировать статическую структуру программы, а именно – члены классов и зависимости между классами.
AspectJ's aspect является базовой сущностью сквозного подхода. Их поведение напоминает Java классы, но может содержать pointcuts, advice и определения inter-type.
(Далее по тексту будут использоваться слова джоинпоинт, поинткат, адвайс, аспект, интертайп – прим перев.)
В разделах, которые последуют прямо сейчас, мы собираемся рассмотреть джинпоинты и то, как их объединять в поинткаты. Потом мы рассмотрим адвайс: код, который запускается в момент достижения поинтката. Мы рассмотрим, как комбинировать поинткаты и адвайсы в аспекты – базовые сущности AspectJ, которые доступны для повторного использования и наследования. И, наконец, мы рассмотрим, как использовать интертайп определения для обеспечения сквозного подхода в контексте классов программы.
Friday, December 28, 2007
Жаль что не мной придумано....
«Я не должен бояться.
Страх — убийца разума.
Страх — это маленькая смерть, влекущая за собой полное уничтожение.
Я встречусь лицом к лицу со своим страхом.
Я позволю ему пройти сквозь меня.
И, когда он уйдет, я обращу свой внутренний взор на его путь.
Там, где был страх, не будет ничего.
Останусь лишь я».
(c)Френк Герберт "Дюна"
Страх — убийца разума.
Страх — это маленькая смерть, влекущая за собой полное уничтожение.
Я встречусь лицом к лицу со своим страхом.
Я позволю ему пройти сквозь меня.
И, когда он уйдет, я обращу свой внутренний взор на его путь.
Там, где был страх, не будет ничего.
Останусь лишь я».
(c)Френк Герберт "Дюна"
Subscribe to:
Posts (Atom)
