Обстоятельства заставили оформить мысль о том, как компания может изыскивать кадровые резервы для старта новых проектов.
Классическая модель такая: разработчики - есть ресурс. Разработчики работают над созданием и развитием продукта в рамках некоторого проекта. Проект - это нечто с некоторой целью и ограниченными сроками. В рамках этой модели, компания каждый раз решает, проект по развитию какого продукта ей выгоднее в каждый конкретный момент и запускает наиболее выгодные проекты.
У такого подхода всё хорошо, кроме одного.
( Read more... )
Есть желание докрутить NUnit для того, чтобы его было удобнее использовать для функционального тестирования (через GUI). Хочу, чтобы при падении теста, было собрано максимум информации: логи приложения, состояние базы данных, скриншот в момент падения теста, файлы настроек. В общем максимум для того, чтобы было удобнее расследовать падение теста.
( Внимание, задачка! )
Обычно во всяких статьях, типа 12 причин, почему нужно писать модульные тесты, одна из причин звучит "Тесты - это хорошая, живая документация".
Вопрос: а как часто вы читаете тесты, когда вам нужна документация?
Ещё вопрос: а много у вас модульных тестов, глядя на которые можно быстро сказать, какое поведение они документируют?
По-моему, сами собой тесты не начнут работать, как документация. Чтобы это произошло, нужно ( приложить усилия )
Программа жутко тормозила. Много думали и исследовали. Нашли бутылочное горлышко, сделали несколько правок, которые должны были дать офигеть-эффект. Время работы операции уменьшилось всего в 2 раза. "Эх... мало", - подумали мы.
В сосдней экспериментальной ветке внедрили новую библиотеку работы с Firebird. Время уменьшилось тоже в 2 раза. "Эх... будет прирост в 4 раза. Всё равно мало...", - подумали мы...
В релизную ветку аккуратно влили и то и другое. Операция стала выполняться раз в 100 быстрее. "Ой...", - подумали мы.
Разгадка:
"в два раза" - это "на 50%". Так вот надо было не разы перемножать, а проценты складывать! :)
Есть в трекере такое загадочное поле, как target milestone.
Milestones - это такие столбики, стоящие вдоль дороги с промежутком ровно километр (милю).
Target milestone - это один из таких столбиков на пути к светлому будущему, до которого мы должны успеть сделать некоторый список задаче, которые мы же сами себе и поставили.
Ниже описывается одна из практик применения target milestone. Она же - основная практика его применения :)
Оказывается, разработчики багзиллы признают, что сейчас больше всего развитие багзиллы тормозит то, что она написана на Perl'е.
Более того, они задумываются над тем, чтобы переписать её полностью на более современно языке программирования.
Правда этой "новости" уже как минимум год. :)
Ссылки по теме:
http://avatraxiom.livejournal.com/58084.h
http://wiki.mozilla.org/Bugzilla:Languag
Сегодня две очень специфические и не очень интересные практики, нацеленные на то, чтобы сделать из трекера действительно полноценный инструмент по наблюдению за проектом.
Считается, что в трекере уже фиксируются ошибки и новая функциональность. Но от всеобщего взора ускользают такие вещи, как внутренние переработки и изменения внесённые в код разработчиком самостоятельно: сам обнаружил недочёт - сам исправил.
Новая функциональность и переработка старой функциональности оформляются в виде задач в трекере. Таким образом, через трекер проходят почти все значительные изменения в продукте.
Менеджер или тим-лид распределяют задачи в трекере по разработчикам, либо разработчики делают это в автономном режиме самостоятельно.
Преимущества
Работающие над продуктом люди распределены и нуждаются в средстве систематического обмена информацией.
Если все, кто должен быть в курсе происходящего, поддерживаются в курсе каким-то другим достаточно эффективным образом, практика не очень осмыслена. В небольших командах все могут сидеть в одной комнате и участвовать в общих собраниях. Либо менеджер разработки может самостоятельно каким-то образом доводить важную информацию до всех заинтересованных людей.
Если в команде уже используется какое-то другое средство планирования разработки, со списком задач и возможностью распределять работу по разработчикам, то дублирование того же самого в трекере почти не даст плюсов. В этом случае, возможно, следует ограничить область применения трекера только ведением истории работы над ошибками.
Эта практика даёт много интересных бонусов, но при этом требует заметных затрат на поддержку актуальной полной информации в трекере. Скорее всего, эта практика не подойдёт тем, кто делает ставку на живое общение и минимум формальностей в команде. А для команд, ставших настолько большими, что живого общения уже не хватает, эта практика предлагает хороший способ борьбы с информационным голодом.
Начнём с банальностей. Зачем вообще нужно использовать трекер?
Решил начать описывать в ЖЖ набор практик использования трекера, до которого у меня получилось дойти своим умом в течении 3 лет его использования. Ценность будут представлять
Под трекером я тут подразумеваю приложение, которое позволяет коллективно работать с так называемыми issue. Чаще всего issue - это информация об ошибке в программе. Реже - запрос новой функциональности. Вообще говоря, issue может быть вообще чем угодно.
У меня богатый опыт работы с Bugzilla. Кроме того я представляю как выглядят mantis, JIRA и трекер в TFS, но никогда с ними плотно не работал.
Целей несколько. В первую очередь упорядочить свои собственные мысли. Во-вторую, поделиться своими выводами с народом, для которого они могут оказаться новыми и полезными. В третьих, попытаться инициировать дискуссию с заинтересованным народом, дабы дополнить мои знания чужими, а, возможно, и вовсе сгенерировать в процессе дискуссии новые знания.
В общем, обсуждения приветствуются!
У меня не получилось как-либо упорядочить и структурировать практики использования трекера, но я постарался расположить их в порядке, удобном для восприятия.
Описание каждой практики, как мне кажется, должно уложится в шаблон:
1. Описание практики.
2. Преимущества, которые она даёт.
3. Обсуждение применимости данной практики.
На момент заморозки таблицы результатов за час до конца в 10-ке было всего 2 не русскоговорящие команды - MIT (5 место) и Fudan State University (10 место). Из оставшихся восьми - всего две не российские команды - Львов (3 место) и Беларусь (7 место).
И это чемпионат мира!
СПб ИТМО жжот на первом месте.
Ижевск жжот на втором.
УрГУ - на 19-ом.
Внимание вопрос: Какого чёрта в этой стране все болеют за футбол?!? :)
Результаты тут: http://icpc.baylor.edu/dmt/v2/wf/scoreb
Окончательных не дождусь - пойду спать :)
Неплохо, кстати, поболели в "Малине" за наших. Нам там даже розетку для ноутбуков нашли!
В рамках оптимизации своей рабочей деятельности, решил составить список того, чем мне так или иначе приходится заниматься на работе.
Сегодня подсказали, что если ввести в яндексе загадочную фразу nhibernate vs linq, то первой в списке результатов будет ссылка на вот этот вот мой ЖЖ :-)
Решил, что Яндекс как то странно глючит. Поискал то же самое в гугле среди русских страниц - аналогично.
Странно всё это! :-)
Для френдов без мат-образования на всякий случай начну с disclaimer-а
Всё написанное ниже, не смотря на явный математический оттенок, не следует воспринимать как серьёзное математическое рассуждение - оно содержит кучу дыр и нестыковок незаметных пока не разберёшься в деталях. К этому стоит относится всего лишь как к забавной ассоциации :)
Есть такая строго доказанная теорема Гёделя, из которой в конце концов следует примерно следующее:
Во всякой более менее богатой теории (достаточно богатой, чтобы из неё выводились основные истины нашей арифметики), можно сформулировать утверждение, которое нельзя ни доказать, ни опровергнуть.
Такое утверждение можно, например, добавить к системе аксиом, оставив её непротиворечивой.
Сейчас родители смотрят какой-то фильм, в котором девушка - дочь ворожеи, начала готовить зелья и "привораживать" мужчин. Причём сама девушка совершенно не верит, что это всё работает - она просто так зарабатывает деньги (притом не без угрызений совести).
У меня с родителями на этой почве завязалось обсуждение и они в голос стали мне рассказывать про мега-бабулек в их деревнях, которые лечили от кучи болезней "пошептав" или поделав ещё какие-то простые действия. Я тоже вспомнил Ксюху Верхотурову (привет тебе! :), которая рассказывала про таких бабулек из своих экспедиций и не только. В общем тут-то меня и торкнуло! :)
Нормальный человек скажет "привораживание и прочее колдовство - это всё враньё, потому что это не объяснимо". Типа "Наука не признаёт", а значит шарлатаны.
Теперь, когда мы обозначили мнение обывателя, попробуем посмотреть на проблему с точки зрения самой Науки, которая "не признаёт".
Для начала "не признаёт" означает всего лишь "не умеет объяснять".
Далее, предположим, что наши физики узнали все аксиомы нашей вселенной (вах!).
В этом случае может случиться три вещи:
1. Будет показано, как из аксиом мироздания следует работоспособность колдовства, оно будет наконец-то признано, изучено (а-ля НИИ ЧАВО) и им начнут пользоваться на научный манер.
2. Будет показано, что из аксиом мироздания следует неработоспособность колдовства. Тем самым будет доказано, что все колдуны шарлатаны. В этом случае всех колдунов можно будет со спокойной совестью судить за шарлатанство.
3. Будет доказано, что из аксиом мироздания не возможно ни доказать, ни опровергнуть работоспособность колдовства. Согласно теореме Гёделя эту возможность никак нельзя исключить! И при том это самый интересный случай. Он означает, что работоспособность колдовства можно взять за аксиому! То есть если я верю в колдовство - оно работает. Если не верю - не работает.
Так позиция "Я верую на тот случай, если бог на самом деле существует" предстаёт перед нами совсем в другом свете :)
Часть вопросов про коллекции снята после прочтения этого блога и этого FAQ-а
Тем, кто считает, что ICollection<T> - это generics аналог ICollection посвещается :)
( Read more... )
В пятницу я впервые участвовал в собеседовании человека, которого мы сознательно не взяли, и я об этом слегка жалею. Это хорошо! Это значит, что мы уже достаточно сильны духом, чтобы поднять планку на правильный уровень. По этому поводу я решил написать немножко про собеседования.
( Read more... )
Жили были дядьки, которые придумали стандарт на устройство файлов с криптографическими сертификатами, подписями, зашифрованными данными и т.п.
( Read more... )
Мораль. Никогда не переоценивайте стандарты. ;)
Я сформулировал для себя такое правило:
Если A и B работают в соответствии с некоторым довольно сложным стандартом, но совершенно не знают друг про друга, то при их взаимодействии почти наверняка будут проблемы.
Помните такой афоризм?
Любую проблему можно решить введением дополнительного уровня абстракции кроме одной - слишком большого количества уровней абстракции.
Navigate: (Previous 20 Entries)