суббота, 30 октября 2010 г.
Silverlight мёртв?
Основные причины верить в это описаны в данном посте. ... вместе с тем если обратить внимание на вторую часть, то сообщение скорее: мёртв для создания просто сайтов, что было очевидно уже давно. Мёртв ли он для создания сложных приложений с много уровневым интерфейсом пользователя, вот в чём вопрос!
пятница, 29 октября 2010 г.
Тема для диплома: стратегии тестирования производительности
Ещё одна интересная тема для бакалавра или магистра: performance testing strategies - "стратегии тестирования производительности" ... а кому этого мало может описать и подходы к увеличению производительности каких то определённых систем - например с теми которые вы работаете .. и включить туда подтему тестирования производительности.
В любом случае - для начала прослушайте данную презентацию.
Затем
1. Следуйте ей в написании своей работы - знания, предложенные стратегии, шаги итд
2. Задумайтесь какие вопросы поднимает или оставляет данная презентация. Например что важнее - тестирования производительности в стабильной среде и соответственно отделить ветку кода или тестирования производительности на самом новом коде? Когда необходимо применять одну и когда другую стратегию?
В любом случае - для начала прослушайте данную презентацию.
Затем
1. Следуйте ей в написании своей работы - знания, предложенные стратегии, шаги итд
2. Задумайтесь какие вопросы поднимает или оставляет данная презентация. Например что важнее - тестирования производительности в стабильной среде и соответственно отделить ветку кода или тестирования производительности на самом новом коде? Когда необходимо применять одну и когда другую стратегию?
четверг, 28 октября 2010 г.
Новый офис
Официально переехали. В понедельник. На практике переселились через коридор. Если раньше был вид на озеро Ülemiste с редким самолётопадом, то теперь вид на старый город и оба залива.
2010-10-27. Tallinn. DDT
Upd: DDT кстати очень хорошо играет джаз. И трубач с тромбонистом у них просто супер!
суббота, 23 октября 2010 г.
При чём тут Атлантида
По следам моста поста о "Эстонских Геркулесах"
Нет, конечно Hercules слово конечно используется в русском языке, но он отнюдь не означает античного героя. Хотя последнее тоже того ... не того... ну какие античные герои для современного человека - многие о таких и не слыхали небось. А Геракла знают исклячительно из-за фонтана в Петергофе - "Геракл разрываящий пасть ... кому то там" который наповерку оказывается Самсоном :) (вполне кстати допускаю, что на самом деле речь об одном и том же историческом персонаже), да и то последняя фраза приходит сразу после "Пасть порву, моргала выколю". Кроме того многие путают Геракла, Антея (а самолёт, знаю, знаю), Атланта (а.. это Атлантида? ... не ну тогда тот сильный чувак, на котором небо и балконы, тот явно Геракл - ну подумай сам, при чём тут Атлантида?)
пятница, 22 октября 2010 г.
Ещё одна интересная статья поднимающая важные вопросы из области агильного программирования: "Bad attitudes of Agile".
Во первых это всеобщая уверенность в всесильность самоорганизации которая ведёт нас часто к убеждению что менеджеры нас абсолютно больше не нужны. Безусловно, самоорганизация является неотъемлимой частью практики и условием для её применения, но это не даёт нам право говорить о том, что менеджер является абсолютно не нужным балластом в организации который получает бонусы от работы нас, несчастных практиков, разработчиков програмного обеспечения. Пусть даже в агильном проекте у нас будет кто-то без официального названия менеджер, все равно следующие роли просто необходимо выполнять:
1. Роль лидера проекта. Кто то должен прочетить в общих чертах проект, что мы делаем, как мы делаем, помогать приходить к общему знаменателю в споре и поддерживать команду в трудные времена.
2. Административная роль. Все мы хотим буть самоорганизующимися, но через мгновения мы говорим, "Эй, я программист, и именно этим я хочу заниматься. Почему я должен заказывать воду, организовывать собрания или делать заметки в течении собрания?" или "Бюджет? Да за кого вы меня принимаете? Что, доходность.... ?"
Во вторых. Итеративный принцип разработки программного беспечения часто ведёт к убеждённости, что в проекте нет сроков выпуска - "Ну, мы сдадим проект сразу же после того как всё допишем. Когда? Ну откуда мы знаем как вы будете устанавливать приоритеты или какая обратная связь будет приходить. Сорри - no comments". Всё это мы делаем не смотря на то, что очевидно проект имеет определённый бюджет, определённых клиентов которые заинтересованы узнать предпологаемую функциональность, а так же сроки сдачи проекта, чтобы составить свои планы и так далее. Тот факт, что начальные итерации как правило являются не готовыми к выпуску легко позволяют нам забыть, что общее правило по прежнему гласить, что в конце каждой итерации мы должны иметь продукт готовый к выпуску, и мы говорим "сроков нет" вместо того, что бы сказать "срок примерно такой то, но содержание может варьироваться в опеределённых рамках"
И наконец лозунги "все равны в проекте" и "никаких документов" на сегодняшний момент явно переоценены. В силу особенностей разработки, мы не можем получить готовое описание продукта в начале работы, так как мы не знаем как будут меняться приоритеты в ходе работы и каковы будут отзывы от руководства и клиентов которые принудят нас что-то менять в планах. Но это совсем не значит, что мы не должны фиксировать наши решения сделанные в процессе планирование каждой итерации и разработки. В противном случае ни тестеры, ни мы сами через определённое время не будем знать - как работают те или иные функции и, главное, почему именно так (кто и в силу чего решил). Не говоря уже о клиентах которых многие оставляют просто один на один с продуктом без описания функциональности.
Что касается всеобщной равности в проекте - это уже было и называется социализмом или ... На практике всё это трансформируется в лозунг "все равны, но некоторые равнее". А именно есть более и менее востребованные ресурсы. В нашем плане умения разработчика проекта как правило встречается на порядок реже нежели тестера, а поэтому такие ресурсы просто не рационально иногда использовать не по назначению, хотя безусловно и как тестеры они тоже приобретают полезный опыт. Всё таки нам нужна группа людей, которая будет заниматься тестированием как текущей итерации, так и уже выпущенных с целью гарантирования качества конечного продукта.
Во первых это всеобщая уверенность в всесильность самоорганизации которая ведёт нас часто к убеждению что менеджеры нас абсолютно больше не нужны. Безусловно, самоорганизация является неотъемлимой частью практики и условием для её применения, но это не даёт нам право говорить о том, что менеджер является абсолютно не нужным балластом в организации который получает бонусы от работы нас, несчастных практиков, разработчиков програмного обеспечения. Пусть даже в агильном проекте у нас будет кто-то без официального названия менеджер, все равно следующие роли просто необходимо выполнять:
1. Роль лидера проекта. Кто то должен прочетить в общих чертах проект, что мы делаем, как мы делаем, помогать приходить к общему знаменателю в споре и поддерживать команду в трудные времена.
2. Административная роль. Все мы хотим буть самоорганизующимися, но через мгновения мы говорим, "Эй, я программист, и именно этим я хочу заниматься. Почему я должен заказывать воду, организовывать собрания или делать заметки в течении собрания?" или "Бюджет? Да за кого вы меня принимаете? Что, доходность.... ?"
Во вторых. Итеративный принцип разработки программного беспечения часто ведёт к убеждённости, что в проекте нет сроков выпуска - "Ну, мы сдадим проект сразу же после того как всё допишем. Когда? Ну откуда мы знаем как вы будете устанавливать приоритеты или какая обратная связь будет приходить. Сорри - no comments". Всё это мы делаем не смотря на то, что очевидно проект имеет определённый бюджет, определённых клиентов которые заинтересованы узнать предпологаемую функциональность, а так же сроки сдачи проекта, чтобы составить свои планы и так далее. Тот факт, что начальные итерации как правило являются не готовыми к выпуску легко позволяют нам забыть, что общее правило по прежнему гласить, что в конце каждой итерации мы должны иметь продукт готовый к выпуску, и мы говорим "сроков нет" вместо того, что бы сказать "срок примерно такой то, но содержание может варьироваться в опеределённых рамках"
И наконец лозунги "все равны в проекте" и "никаких документов" на сегодняшний момент явно переоценены. В силу особенностей разработки, мы не можем получить готовое описание продукта в начале работы, так как мы не знаем как будут меняться приоритеты в ходе работы и каковы будут отзывы от руководства и клиентов которые принудят нас что-то менять в планах. Но это совсем не значит, что мы не должны фиксировать наши решения сделанные в процессе планирование каждой итерации и разработки. В противном случае ни тестеры, ни мы сами через определённое время не будем знать - как работают те или иные функции и, главное, почему именно так (кто и в силу чего решил). Не говоря уже о клиентах которых многие оставляют просто один на один с продуктом без описания функциональности.
Что касается всеобщной равности в проекте - это уже было и называется социализмом или ... На практике всё это трансформируется в лозунг "все равны, но некоторые равнее". А именно есть более и менее востребованные ресурсы. В нашем плане умения разработчика проекта как правило встречается на порядок реже нежели тестера, а поэтому такие ресурсы просто не рационально иногда использовать не по назначению, хотя безусловно и как тестеры они тоже приобретают полезный опыт. Всё таки нам нужна группа людей, которая будет заниматься тестированием как текущей итерации, так и уже выпущенных с целью гарантирования качества конечного продукта.
Подписаться на:
Сообщения (Atom)
