четверг, 28 августа 2008 г.

Пишите 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, это желательно в документации тоже указать.

пятница, 22 августа 2008 г.

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

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

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

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

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

четверг, 21 августа 2008 г.

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

Из чата:

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

Полезное

вторник, 5 августа 2008 г.

iPhone: This accessory is not made to work with iphone

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

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

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

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

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

пятница, 25 июля 2008 г.

Сравнительный анализ современных .net ORM

Задача

Необходимо было аргументированно выбрать ORM для большого .Net проекта. Рассматриваемые (пока) ORM: Entity Framework, BLTooklit, SubSonic.

Результат

* Аналитический отчет
* Сводная таблица с баллами, набранными каждой из ORM

Ваша критика/пожелания приветствуется. Надеюсь продолжить этот опыт и рассмотреть еще и другие (не менее интересные ORM)

среда, 23 июля 2008 г.

"И снесла курочка дедушке яичко. Левое. Напрочь."

http://www.metasploit.com/users/hdm/tools/debian-openssl/
Это, извините за мат, пиздец.

Вкратце - в 2006 году народ, который поддерживает сборку библиотеки OpenSSL, вычищая потенциальные уязвимости из библиотеки, "вычистил" напрочь код, который генерировал начальное значение для генератора псевдослучайных чисел (Pseudo Random Number Generator, PRNG). Вместо случайной последовательности байт PRNG инициализировался ID текущего процесса (а в linux это число <32768)

Эффект одной ошибки
Как результат - все debian based операционки (такие, как Ubuntu) до последнего времени были подвержены атаке "man-in-the-middle". Все SSL/SSH сертификаты, выданные в это время, скомпрометированы. Любые утилиты, использующие библиотеку debian-овскую сборку OpenSSL, могут быть уязвимы.

В оригинале:

All SSL and SSH keys generated on Debian-based systems (Ubuntu, Kubuntu, etc) between September 2006 and May 13th, 2008 may be affected. In the case of SSL keys, all generated certificates will be need to recreated and sent off to the Certificate Authority to sign. Any Certificate Authority keys generated on a Debian-based system will need be regenerated and revoked. All system administrators that allow users to access their servers with SSH and public key authentication need to audit those keys to see if any of them were created on a vulnerabile system. Any tools that relied on OpenSSL's PRNG to secure the data they transferred may be vulnerable to an offline attack. Any SSH server that uses a host key generated by a flawed system is subject to traffic decryption and a man-in-the-middle attack would be invisible to the users. This flaw is ugly because even systems that do not use the Debian software need to be audited in case any key is being used that was created on a Debian system. The Debian and Ubuntu projects have released a set of tools for identifying vulnerable keys.

Инструменты для взлома SSH/SSL сессий существуют и доступны в Сети. Такая вот веселая история из мира опен соурс.


Ссылки по теме:

суббота, 5 июля 2008 г.