Пишите usage для ваших веб-страниц

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

///

/// usage:
EditDistributionEmail.aspx?iid=INSTANCE_ID[&back=ENCODED_BACK_URL]
///

public partial class EditDistributionEmail :
System.Web.UI.Page
{
...

С точки зрения программиста, веб-страница ничем не отличается от статической функции - принимает некоторый набор параметров (HTTP Request) и возвращает некоторые значения (HTTP Response).

А следовательно, и документировать ее надо как функциою - описывать параметры и return value (последнее для фанатов, конечно :). Хотя, если страница может менять какие-то глобальные cookies, это желательно в документации тоже указать.

Техсаппорт для аналитиков

Волею случая я сейчас выполняю обязанности саппортера 1 уровня саппорта для приложения, которое же сам спроектировал и к которому писал спецификацию.

Так вот - это неприятно :). Пользователи используют систему не так, как ты придумал, хотя ты со всеми общался и требования вроде собирал. Все делают по другому. Наступают на глупые какие-то грабли, которые тебе граблями не кажутся. Тратят на это кучу своего и твоего времени.

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

Отсюда вывод - или аналитиков (product manager-ов) иногда нужно ссылать на поддержку продукта, который они создали, причем на самую неблагодарную ее часть - решение мелких бытовых вопросов пользователя, либо аналитики должны сами органиовывать получение feedback информации от саппортеров. Обязательно. Иначе так и будут витать в облаках ;)

Рабочее - вылизываем код до совершенства

Из чата:

1: главное чтоб там была сноска что это workaround for bug ### - а то потом будут люди будущего голову ломать, что ж за хуйню предки понаписали )))
2:
//This method added for bug0012852 workaround!!!
[Obsolete("This method added for bug0012852 workaround only!!! We strongly needs refactor here.")] поймут?
1: ага. только It is strongly needed to refactor, или "We strongly recommend to refactor this. -- Your predecessors"
1: Или так - Shall you to refactor this, shall not you to leave this unchanged
1: тьфу, модальные без "to"
1: shall you refactor this, shall not leave this unchanged
2: To refactor or not to refactor?
1: а вот этой неопрделенности нам не надо )

КЛАДР as a Service

Чудесно, что нашелся человек, который сделал REST версию справочника КЛАДР

http://gazdovsky.blogspot.com/2008/08/blog-post.html

Полезное

iPhone: This accessory is not made to work with iphone

Однажды, совершенно неожиданно, мой iPhone начал в случайные моменты времени выдавать вот такое сообщение:

"This accessory is not made to work with iphone."

и начал просить перевести его в Airplane mode. Перестал играться звук из iPod и YouTube через встроенный динамик.

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

Мораль: иногда надо работать руками ;)