[life.sport.darts] Дротики Pure Darts Classics 90% 22g

Интернет-магазин puredarts.co.uk продает несколько моделей дротиков под своей собственной маркой. Одну из них, а именно Pure Darts Classics, я решил купить себе в поисках замены своих McCoy Stealth. Несколько дней назад они попали ко мне в руки. Если кому-то интересны подробности, то прошу под кат.

[life.sport.darts] Небольшой лытдыбр

На неделе сделал несколько интересных приобретений. Если кому-то интересно, то милости прошу под кат.

[work.thoughts] Поток сознания о планах проектов и задаче о рюкзаке

Так уж получилось, что я принципиальный противник подробного планирования работ над программным продуктом вообще и использования для этих целей инструментов вроде MS Project в частности. Уж очень часто приходится убеждаться в народной мудрости “Хочешь рассмешить Господа Бога – расскажи ему о своих планах”. Но, поскольку необходимость планирования – это одно из правил игры, то приходится ему следовать. В общем, если партия сказала надо – комсомол ответил на верху решили посмешить Господа, значит будем смешить.

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

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

Еще хуже, когда сроки проекта согласовываются на уровне самого высокого начальства из неведомых разработчику политических, экономических и еще хрен знает каких соображений. Проект изначально оказывается безнадежным, но ситуацию усугубляет еще и необходимость его “прозрачного” ведения. Чтобы максимум руководящих уровней (включая и заказчика) могли видеть его прогресс – вот такая-то задача уже исполнена на 90%, а вот эта всего на 10%, вот здесь работы завершились на 2 дня раньше, а здесь намечается запаздывание на неделю…

При этом, опять же из-за “прозрачности” план не может быть ни излишне детализированным, ни слишком гибким.

Например, задаче “Выпуск версии 2.2.1 протокола MbMsg с поддержкой поля ConfidentialMsg в сообщении SEND” с планируемым сроком реализации 30 минут не место в плане 4-х месячного проекта. Поскольку таких задач будет если пару сотен, то уж несколько десятков точно. А копаться в куче мелких деталей никому не хочется, да и времени это отнимает долго. Хотя, как это не парадоксально, именно такая мелкая задачка может стать настоящим show stopper-ом. И потребовать не 30 минут, а нескольких дней работы сразу нескольких разработчиков.

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

С другой стороны, начальство так же можно понять – они хотят иметь объективное впечатление о ходе проекта. А как они еще могут его получить? Не вызывать же к себе тим-лидов и не опрашивать каждого из них о том что, как и какие перспективы. Совсем другое дело открыть Project и увидеть какую-то циферку – 20% или 50%, или 97%. Совсем другое дело! Это же не “э-э-э, ну я надеюсь, что к 20-му… э-э-э, нет, к 22-му, у нас будут проходить большинство тестов…” Тут смотришь и видишь – 80% готовности, предположительное запаздывание 2.5 дня – все четко и понятно. Объективно.

Тут уж не могу отказать себе в удовольствии и не постебаться на тему процентов исполнения работ.

Во-первых, лично я признаю всего два показателя – 0% и 100%. Т.е. кусок работы либо сделан, либо нет. Все остальное от лукавого. Один разработчик может написать готовый модуль и объявить о 40% готовности потому, что он еще не проводил серьезных тестов и не закончил его документирование. А второй в такой же ситуации проставит 100%, поскольку он искренне считает, что его работа заключалась именно в написании кода, а тестирование и последующий баг-фиксинг – это уже совсем-совсем другая история.

Во-вторых, есть совершенно замечательный и на 100500% верный афоризм: первые 90% времени уходят на написание 90% кода, на оставшиеся 10% кода уходит еще 90% времени. Т.е., если по графику работ все было зашибись до 90% готовности проекта, то это вовсе не значит, что тоже самое будет и с оставшимися 10%. Как раз на этих 10% с проектом может случиться внезапный, полный, глубокий и окончательный приплыздец.

Поэтому я, как разработчик, который регулярно вляпывается в безнадежные проекты, считаю, что планы и Project-ы – это рюшечки и финтифлюшечки – глаз радуют и настроение создают, но нифига полезного не делают. В безнадежных проектах по крайней мере. (Мнение же менеджмента на данный счет идет в /dev/null – это мой блог и сейчас я говорю как разработчик)

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

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

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

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

1. Разработка TP.
2. Адаптация cp_service к особенностям проекта XYZ.
3. Адаптация AAG с особенностям проекта XYZ.
4. Разработка TLV_Gate для связи нескольких cp_service с одним TP.

Т.е. понятно, что в принципе нужно делать. Но еще не понятно, как именно. Хотя это не страшно. Главное в драку ввязаться, а там разберемся ;)

Когда работы начнутся, то ранее обозначенные куски начнут дробиться (заменяться) на блоки из все более и более четких, но мелких кусочков. В результате, на каком-то шаге работы первоначальный список из 4-х обобщенных пунктов преобразуется к чему-то вроде:

1. Библиотека ig_cp_service_iface-2.2.0 с поддержкой необязательного s_id (для исходящих и входящих сообщений).
2. Поддержка s_id для исходящих сообщений в cp_service.
3. Поддержка s_id для входящих сообщений в cp_service.
4. Первая версия TP, которая использует SOP/MBAPI для взаимодействия с cp_service. Без дозирования трафика и мониторинга.
5. Имитатор cp_service+AAG на основе SOP/MBAPI, который мог бы использоваться для нагрузочного тестирования TP.
6. Проверка первой версии TP без дозирования трафика на имитаторе cp_service+AAG.
7. Вторая версия TP, доработанная с учетом испытаний на имитаторе cp_service+AAG.
8. Доработка cp_service таким образом, чтобы он отсылал КП только финальные SR-ы, но не отсылал промежуточных.
9. Доработка cp_service таким образом, чтобы для некоторых приоритетов (возможно некоторых, а не всех КП) не проводилось динамического понижения приоритетов.
10. Библиотека ig_cp_service_iface-2.2.1 с поддержкой поля ConfidentialMsg.
11. Реализация в cp_service поддержки ConfidentialMsg.
12. Реализация в AAG поддержки ConfidentialMsg.
13. Библиотека TLV-представления протокола ig_cp_service_iface-2.2.
14. Прототип TLV_Gate который стоит перед cp_service+AAG.
15. Добавление в TP поддержки TLV-протокола.
16. …

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

По мне, такой список “незаконченных дел” намного нагляднее и объективнее диаграмм из Project-а. Чем меньше в нем незачеркнутых пунктов, тем ближе проект к завершению. Пункты не завязаны кучей зависимостей друг на друга, поэтому их проще изменять, удалять или добавлять новые.

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

Аналогия с задачей о рюкзаке здесь возникает потому, что по моему опыту, такие списки “незаконченных дел” никогда не оказываются полностью пустыми. Всегда в них остаются какие-то пункты, на которые не хватает ресурсов. Постоянно приходится этот список “ператрахивать”, повышая приоритет для тех пунктов, без которых совершенно нельзя обойтись и понижая приоритет (а то и вычеркивая) пункты, без которых можно обойтись или которыми приходится жертвовать из-за их трудоемкости или неочевидности. Практически как в академической задаче – выбор предметов исходя из их стоимости+объема+веса.

Подобными списками (оформленными на бумаге или в каком-то электронном документе) я пользуюсь давно и регулярно. В принципе, на небольших проектах они работают успешно (в том числе и на безнадежных проектах). Но, к сожалению, поколебать страсть менеджмента к диаграммам Гантта и другим плюшкам Project-а они не смогут. Се ля ви :(

[life] Особенности слежения за EMS-посылками через belpost.by

Если вы в Белоруссии ждете посылку из-за границы и у посылки есть Tracking ID, то ее прохождение по территории Белоруссии можно отследить через сайт belpost.by (сейчас слежение доступно через URL: http://search.belpost.by). Но здесь есть некоторые тонкости. Вот, например, информация о посылке, которую я забрал вчера вечером:

Примечательный пункт там – это информация о поступлении посылки в 42-е отделение. По системе слежения доставка произошла в 17:14. Хотя реально доставка почты вечером в наше отделение происходит где-то в 18:30-18:45. Это уже проверено на практике и даже вчера вечером опломбированные мешки с посылками вскрывали прямо на моих глазах для того, чтобы достать мою посылку. А в некоторых отделениях вечерний обмен почты происходит вообще после 19:00, т.е. когда участок уже закрыт.

Т.е. информация в системе слежения как бы показывает желаемое состояние посылки, которое может сильно отличаться от актуального. Я сам уже несколько раз наступал на грабли – верил Интернету, шел на почту, а там посылки пока еще не было :(

В последний раз такие грабли попались мне вчера. Есть у нас в Гомеле центральный пункт доставки на Карбышева 2 (рядом с автовокзалом). По идее, все посылки ночью прибывают из Минска туда. И находятся там где-то до 11-12 часов. Что, теоретически, позволяет часов в 9 утра забрать посылку там не дожидаясь, пока ее доставят в “родное” почтовое отделение. Но это теоретически. На практике туда приходишь, а твою посылку не находят – нету ее говорят еще и не важно, что написано в Интернете, т.к. они Интернет не контролируют. А почему посылка не нашлась – действительно не была получена или ее просто не туда положили, или же ее уже упаковали для отправки в “родное” отделение – не узнаешь.

Интригует, однако, одна вещь: приходишь на Карбышева за посылкой, а у тебя спрашивают: “А вам звонили?” Видимо, на нашей почте есть неявная услуга – персональное уведомление о приходе посылки. Знать бы еще, как на эту услугу подписаться :)

[prog.bugs] Ключевой момент поиска чужой проблемы в минувшую субботу

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

В конце-концов, где-то в 23:00 ко мне дошли достаточного размера фрагменты логов софта клиента для того, чтобы найти причину проблем (кстати, что еще раз доказывает старую истину о том, что логов много не бывает). Оказалось, что при некотором стечении обстоятельств цикл разбора бинарного пакета в их ПО превращается в бесконечный. И, к несчастью, именно с ночи пятницы и всю субботу эти обстоятельства стекались в самом худшем направлении очень часто :(

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

У меня рабочий ноутбук – HP ProBook с влагонепронецаемой клавиатурой. Из-за чего зачастую клавиши не срабатывают – нажмешь какую-нибудь недостаточно сильно и никакого эффекта. Особенность неприятная (особенно при вводе паролей), но к ней я уже привык. Поэтому, если я что-то нажал, а ничего не произошло, то по привычке неосознанно повторяю комбинацию клавиш, подразумевая, что клавиатура опять не сработала.

Полученные от клиента логи я просматривал в FAR-е, в его стандартном FileViewer-е. Просматривал, просматривал, строчек там много, полезную информацию выискивать тяжело. Потом обнаружил, что интересующие меня строки начинаются с фразы “Получен пакет”. Ну, недолго думая, нажимаю в просмотрщике F7 (поиск подстроки), ввожу нужную фразу, жму OK, нахожу следующую нужную мне строку. А потом нажимаю Shift-F7 (продолжение того же поиска), потом еще и еще раз… И осознаю, что на экране-то ничего не меняется.

Ну, думаю, клавиатура опять глючит. Начинаю нажимать сильнее и аккуратнее. Опять ничего не меняется. Бля, думаю, только сломавшейся клавиатуры мне сейчас не хватает. В полном ахуе еще раз несколько раз Shift-F7 – опять ничего не изменилось! Уж не помню, какие матерные слова я тогда высказал в адрес всего света вообще и водонепроницаемых клавиатур HP в частности, но попытки “правильно” нажать Shift-F7 повторял. И вдруг краем глаза заметил, что на экране что-то изменилось. Что не понял, но что-то точно поменялось. Начал присматриваться повнимательнее, но ничего конкретного не замечал. Тем не менее Shift-F7 повторять продолжал. За что был вознагражден – внезапно сменилось время в строках лога на экране. До этого было, скажем, 14:23:18, а стало 14:23:19.

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

В первый раз что-то изменилось на экране когда просмотрщик указал новый процент – в правом верхнем углу 6% сменилось на 7% :) А уже после этого поменялось время в записях лога.

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

Но вот сколько времени мне пришлось бы потратить, чтобы понять, что фрагменты лога повторяются, если бы FAR не позиционировал найденные строки на одном и том же месте экрана – вот этого уже не узнать :)

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

Ну а сегодня и клиент окончательно подтвердил правильность наших догадок.

PS. Еще одна мораль сей басни – время в логах нужно писать, по крайней мере, с миллисекундами. А то при нынешней технике одна секунда работы – это очень и очень много :)