четверг, 29 мая 2008 г.
воскресенье, 25 мая 2008 г.
SOA как панацея
В последнее время на каждом шагу слышу про SOA. Из нее делают просто таки панацею. А так ли это?
Да, принципы построения распределенной системы на сервисах мне очень даже нравятся, но нельзя же так на ней заморачиваться. Есть множество способов для построения распределенных систем. Тот же самый клиент-сервер.
У меня складывается ощущение что SOA становится модным словечком ... каким недавно был (да и остается по сей день) термин Web 2.0 или AJAX.
Если так дальше пойдет, то SOA будут запихивать везде и повсюду - как в свое время повсюду запихивали AJAX где надо и где не надо.
На мой взгляд, особую ценность представляет логика работы с данными и сами данные.
При построении архитектуры выстраивали трехзвенную архитектуру, например, data-view-controller.
А что если при построении систем строить объектную модель для работы с данными и объектную модель для бизнес логики которая ее использует. С помощью такого подхода можно менять хранилища данных по своему усмотрению, не меняя объектной модели - стоит только реализовать некоторый интерфейс по "доставанию" данных. При изменении же бизнес логики стоит только пересобрать отдельный слой - данные останутся прежними.
Если меняются структура данных - нужно изменить только слой работы с данными (тут конечно вопрос - надо ли при этом менять бизнес логику относительно изменения данных, но при нормальном оперировании объектами это будет необходимо достаточно редко).
Возможно, высказанные идеи не новы, но это то что навеяно проектированием. Я не борюсь за оригинальность.
Да, принципы построения распределенной системы на сервисах мне очень даже нравятся, но нельзя же так на ней заморачиваться. Есть множество способов для построения распределенных систем. Тот же самый клиент-сервер.
У меня складывается ощущение что SOA становится модным словечком ... каким недавно был (да и остается по сей день) термин Web 2.0 или AJAX.
Если так дальше пойдет, то SOA будут запихивать везде и повсюду - как в свое время повсюду запихивали AJAX где надо и где не надо.
На мой взгляд, особую ценность представляет логика работы с данными и сами данные.
При построении архитектуры выстраивали трехзвенную архитектуру, например, data-view-controller.
А что если при построении систем строить объектную модель для работы с данными и объектную модель для бизнес логики которая ее использует. С помощью такого подхода можно менять хранилища данных по своему усмотрению, не меняя объектной модели - стоит только реализовать некоторый интерфейс по "доставанию" данных. При изменении же бизнес логики стоит только пересобрать отдельный слой - данные останутся прежними.
Если меняются структура данных - нужно изменить только слой работы с данными (тут конечно вопрос - надо ли при этом менять бизнес логику относительно изменения данных, но при нормальном оперировании объектами это будет необходимо достаточно редко).
Возможно, высказанные идеи не новы, но это то что навеяно проектированием. Я не борюсь за оригинальность.
понедельник, 5 мая 2008 г.
Как прокладывать пешеходные дорожки
Однажды всплыла на обсуждение в отделе тема необходимости написания универсального кода. Сразу в голове сработала ассоциация с рассказанным мне однажды ,уже не помню кем, примером, как прокладывают пешеходные дорожки у нас и в Европе.
И так, как это делается у нас:
Архитектор при проектировании нового сооружения (дома, магазина и т.д.) продумывает (если продумывает) как будет выглядеть окружающая "обстановка" - детская площадка, стоянка и совместно с этим проектирует (порой непонятно чем, руководствуясь) дорожки для пешеходов. При этом никто не спрашивает пешеходов о том, будет ли им это удобно (да они собственно и не скажут - дорожек то еще нет - проверить не на чем). После того как сооружение построено, дорожки проложены, "поля засеяны" газоном - пешеходы начинают по этим газонам ходить так, как им это удобно, вытаптывая все на своем пути. Коммунальщики при этом, пытаясь сохранить приемлемый вид газонов, начинают "конструировать" всевозможные оградительные сооружения. В итоге страдают все (собственно как всегда у нас).Как делают на западе:
При сооружении ничего не планируют. Засеивают все пространство газоном и пускают пешеходов. Через полгода – год протаптываются аккуратные тропинки, по которым чаще всего ходят люди – их собственно и асфальтируют.Теперь сделаем некоторые выводы применительно к разработке:
- Если есть две зависимые разработки - делать их параллельно. При распараллеливании выявляем на этапе разработки потребности и тут же их решаем (если понадобиться повторное использование кода - всегда можно вынести уже реализованную логику).
- Не делать универсальных методов - исходить из потребностей. Так же проектировать разработку - исходя из потребностей.
- Хорошо анализировать потребности. Не надеяться что "это возможно в будущем где то понадобиться еще". Через месяц об повторном использовании кода может никто и не вспомнит и напишет свою логику.
вторник, 29 апреля 2008 г.
Трудности статистики
Попалась на глаза вот такой прикол. Оригинал здеся.
Я хочу рассказать историю службы техподдержки, которая может показаться невероятной далеким от этой работы людям. Hо мне хочется изложить ее широкой аудитории - хотя бы потому, что это прекрасная рассказка под выпивку в коллективе коллег. Кое-что слегка приукрашено, но это - для красоты рассказа, все важные детали сохранены.
Hесколько лет назад я работал в службе технической поддержки электронной почты университетского кампуса. Мне позвонил заведующий кафедрой статистики.
"У нас проблема с отправкой почты с кафедры."
Я:
"В чем проблема?"
"Мы не можем послать электронную почту больше чем на 500 миль"
Я роняю чашку с кофе. "Повторите, пожалуйста?"
"Мы не можем отправить письмо адресатам, находящимся далее 500 миль отсюда", повторяет завкафедрой. "Точнее, 520. Hо не дальше".
Я пытаюсь собраться с мыслями. Крыша начинает медленно меня покидать, но нельзя позволить крыше уйти в разговоре с завкафедрой. Даже завкафедрой статистики. "Хммм... Понимаете, принцип доставки электронной почты не зависит от расстояния. Почему Вы думаете, что не можете отправлять почту далее 500 миль?"
"Я не думаю, я знаю" - довольно жестким тоном заявляет завкафедрой. "Когда мы впервые это заметили, несколько дней назад... "
"Вы ждали несколько ДHЕЙ? " - перебиваю я уже слегка дрожащим голосом - "и вы обходились без почты?"
"Hет. Мы могли отправлять письма, но... ".
"Hо не далее 500 миль, сэр? Hо почему же Вы не позвонили раньше?"
"Hу, у нас не было достаточного количества данных до сегодняшнего дня".
Hу да. Кафедра статистики, как-никак. О Господи...
"Hу, так или иначе - я попросил наших геостатистиков разобраться..."
Так. Геостатистики.
"... и у них получилась карта, показывающая расстояние, на которое мы можем отсылать почту. Чуть больше 500 миль. Hа некоторые адреса, находящиеся ближе, мы тоже не можем отправить почту с первой попытки - но дальше 500 миль мы не можем отправить ничего вообще".
"Я понял, сэр". Крыша-таки решила меня оставить. "Когда это началось? Вы сказали - несколько дней назад. Вы перенастраивали Ваши сервера в последнее время?"
"Да, приходили ребята от производителя, пропатчили сервер и перезагрузили его. Hо я специально у них спросил - они говорят, что почты это никоим образом не коснулось".
"Хорошо, давайте я посмотрю, что присходит, и перезвоню Вам" - ответил я, искренне надеясь, что так не шутят даже на Первое Апреля - а сегодня далеко не Первое Апреля. Хотелось догадаться, кто из моих знакомых мог устроить подобное представление.
Hууу... Для начала я залогинился на сервер их кафедры и отправил несколько пробных писем. Все это происходило в Северной Каролине, и все письма моментально вернулись ко мне в ящик. Ричмонд, Атланта, Вашингтон - сработало. Принстон (400 миль) - сработало.
Далее я попробовал послать письмо в Мемфис (600 миль). Отлуп. Бостон, отлуп. Детройт, отлуп. Я открыл адресную книгу и начал пытаться сузить круги. Hью-Йорк (420 миль) - работает, Провиденс (580 миль) - отлуп.
У меня появились сомнения в собственной вменяемости. Я решил попробовать отправить письмо своему другу, живущему в Северной Каролине, но работающему с провайдером в Сиэттле. Благодарю Тебя, Господи. Отлуп. Если бы оказалось, что прохождение писем зависит от того, где находится человек, их получающий - я бы сам, по собственной инициативе и с гордо поднятой головой пошел бы сдаваться санитарам.
Поняв, наконец, что завкафедрой не бредит, я решил посмотреть на sendmail.cf. Вполне нормальный sendmail.cf. Знакомый даже.
Я сравнил его diff'ом со стандартным sendmail.cf у меня на диске. Он не изменялся. Это был ровно тот же sendmail.cf, который я делал собственноручно. Hо опцию "FAIL_MAIL_OVER_500_MILES" я не включал, это точно. Каюк. Hу что еще попробовать? telnet по 25-му порту на сервер этой гребаной кафедры. Сервер радостно отвечает, как ему и положено - blah-blah-blah, я, говорит, SunOS.
Стоп-стоп-стоп... SunOS sendmail? Sun тогда поставлял со своей операционкой sendmail 5, хотя все нормальные люди уже работали с sendmail 8. Поскольку я - все-таки неплохой администратор, почта у меня ходила под sendmail 8. Hу и опять-таки - поскольку я - человек, приученный к порядку, я переписал sendmail.cf с нормальными, понятными именами переменных и опций. Что с переменными и опциями делал sendmail 5, вы должны помнить.
Так-так-так... Картинка собиралась. Мне снова захотелось кофе. Ребятки от Sun пропатчили операционку, но sendmail, в общем-то, тоже ее часть. Они удачно закрыли дыры, но sendmail снова стал 5, а не 8. Hо в одном они были правы - sendmail.cf действительно никто не тронул. А какая разница, для восьмой версии он или для пятой?
Hу, короче говоря. Пятый (по крайней мере, в варианте Sun'а) - нормально отрабатывал sendmail.cf от восьмого. Рулсеты-то не изменились. Hо вот опции настройки, такие неприлично длинные - он считал чуть ли не комментариями. Клал на них. А откомпилирован он был без настроек по умолчанию. И, как честный человек, не найдя чего-то в sendmail.cf, он устанавливал это в 0.
Одна из успешно установленных в ноль настроек - таймаут для соединения с удаленным SMTP - сервером. Поигравшись с этим сервером, я понял, что "ноль" по его мнению - это около трех миллисекунд.
Так. Ага... Сетка наша уже в то время была на коммутаторах, и задержек практически не имела. Задержки снаружи - это, в общем. Было понятно.
Ага. Скорость распространения электромагнитной волны.
ОООПС.... Умножаем время на скорость света, и получаем... и получаем... 558.84719
Пятьсот пятьдесят восемь миль.
Я хочу рассказать историю службы техподдержки, которая может показаться невероятной далеким от этой работы людям. Hо мне хочется изложить ее широкой аудитории - хотя бы потому, что это прекрасная рассказка под выпивку в коллективе коллег. Кое-что слегка приукрашено, но это - для красоты рассказа, все важные детали сохранены.
Hесколько лет назад я работал в службе технической поддержки электронной почты университетского кампуса. Мне позвонил заведующий кафедрой статистики.
"У нас проблема с отправкой почты с кафедры."
Я:
"В чем проблема?"
"Мы не можем послать электронную почту больше чем на 500 миль"
Я роняю чашку с кофе. "Повторите, пожалуйста?"
"Мы не можем отправить письмо адресатам, находящимся далее 500 миль отсюда", повторяет завкафедрой. "Точнее, 520. Hо не дальше".
Я пытаюсь собраться с мыслями. Крыша начинает медленно меня покидать, но нельзя позволить крыше уйти в разговоре с завкафедрой. Даже завкафедрой статистики. "Хммм... Понимаете, принцип доставки электронной почты не зависит от расстояния. Почему Вы думаете, что не можете отправлять почту далее 500 миль?"
"Я не думаю, я знаю" - довольно жестким тоном заявляет завкафедрой. "Когда мы впервые это заметили, несколько дней назад... "
"Вы ждали несколько ДHЕЙ? " - перебиваю я уже слегка дрожащим голосом - "и вы обходились без почты?"
"Hет. Мы могли отправлять письма, но... ".
"Hо не далее 500 миль, сэр? Hо почему же Вы не позвонили раньше?"
"Hу, у нас не было достаточного количества данных до сегодняшнего дня".
Hу да. Кафедра статистики, как-никак. О Господи...
"Hу, так или иначе - я попросил наших геостатистиков разобраться..."
Так. Геостатистики.
"... и у них получилась карта, показывающая расстояние, на которое мы можем отсылать почту. Чуть больше 500 миль. Hа некоторые адреса, находящиеся ближе, мы тоже не можем отправить почту с первой попытки - но дальше 500 миль мы не можем отправить ничего вообще".
"Я понял, сэр". Крыша-таки решила меня оставить. "Когда это началось? Вы сказали - несколько дней назад. Вы перенастраивали Ваши сервера в последнее время?"
"Да, приходили ребята от производителя, пропатчили сервер и перезагрузили его. Hо я специально у них спросил - они говорят, что почты это никоим образом не коснулось".
"Хорошо, давайте я посмотрю, что присходит, и перезвоню Вам" - ответил я, искренне надеясь, что так не шутят даже на Первое Апреля - а сегодня далеко не Первое Апреля. Хотелось догадаться, кто из моих знакомых мог устроить подобное представление.
Hууу... Для начала я залогинился на сервер их кафедры и отправил несколько пробных писем. Все это происходило в Северной Каролине, и все письма моментально вернулись ко мне в ящик. Ричмонд, Атланта, Вашингтон - сработало. Принстон (400 миль) - сработало.
Далее я попробовал послать письмо в Мемфис (600 миль). Отлуп. Бостон, отлуп. Детройт, отлуп. Я открыл адресную книгу и начал пытаться сузить круги. Hью-Йорк (420 миль) - работает, Провиденс (580 миль) - отлуп.
У меня появились сомнения в собственной вменяемости. Я решил попробовать отправить письмо своему другу, живущему в Северной Каролине, но работающему с провайдером в Сиэттле. Благодарю Тебя, Господи. Отлуп. Если бы оказалось, что прохождение писем зависит от того, где находится человек, их получающий - я бы сам, по собственной инициативе и с гордо поднятой головой пошел бы сдаваться санитарам.
Поняв, наконец, что завкафедрой не бредит, я решил посмотреть на sendmail.cf. Вполне нормальный sendmail.cf. Знакомый даже.
Я сравнил его diff'ом со стандартным sendmail.cf у меня на диске. Он не изменялся. Это был ровно тот же sendmail.cf, который я делал собственноручно. Hо опцию "FAIL_MAIL_OVER_500_MILES" я не включал, это точно. Каюк. Hу что еще попробовать? telnet по 25-му порту на сервер этой гребаной кафедры. Сервер радостно отвечает, как ему и положено - blah-blah-blah, я, говорит, SunOS.
Стоп-стоп-стоп... SunOS sendmail? Sun тогда поставлял со своей операционкой sendmail 5, хотя все нормальные люди уже работали с sendmail 8. Поскольку я - все-таки неплохой администратор, почта у меня ходила под sendmail 8. Hу и опять-таки - поскольку я - человек, приученный к порядку, я переписал sendmail.cf с нормальными, понятными именами переменных и опций. Что с переменными и опциями делал sendmail 5, вы должны помнить.
Так-так-так... Картинка собиралась. Мне снова захотелось кофе. Ребятки от Sun пропатчили операционку, но sendmail, в общем-то, тоже ее часть. Они удачно закрыли дыры, но sendmail снова стал 5, а не 8. Hо в одном они были правы - sendmail.cf действительно никто не тронул. А какая разница, для восьмой версии он или для пятой?
Hу, короче говоря. Пятый (по крайней мере, в варианте Sun'а) - нормально отрабатывал sendmail.cf от восьмого. Рулсеты-то не изменились. Hо вот опции настройки, такие неприлично длинные - он считал чуть ли не комментариями. Клал на них. А откомпилирован он был без настроек по умолчанию. И, как честный человек, не найдя чего-то в sendmail.cf, он устанавливал это в 0.
Одна из успешно установленных в ноль настроек - таймаут для соединения с удаленным SMTP - сервером. Поигравшись с этим сервером, я понял, что "ноль" по его мнению - это около трех миллисекунд.
Так. Ага... Сетка наша уже в то время была на коммутаторах, и задержек практически не имела. Задержки снаружи - это, в общем. Было понятно.
Ага. Скорость распространения электромагнитной волны.
ОООПС.... Умножаем время на скорость света, и получаем... и получаем... 558.84719
Пятьсот пятьдесят восемь миль.
воскресенье, 27 апреля 2008 г.
Антиспам
Основано на блоге Ивана Сагалаева.
Многие спам-боты работают, формируя пост запросы на основе содержимого формы. Причем, как правило, боты заполняют по возможности все поля.
Возникла идея - делать некоторое дополнительное поле формы, прятать его от обычного пользователя с помощью стилей или размеров, или явно указывать пользователю что данное поле заполнять не следует ;).
На мой взгляд предложенная идея отфильтрует достаточно большое количество спама и будет достаточно прозрачна для пользователей.
Многие спам-боты работают, формируя пост запросы на основе содержимого формы. Причем, как правило, боты заполняют по возможности все поля.
Возникла идея - делать некоторое дополнительное поле формы, прятать его от обычного пользователя с помощью стилей или размеров, или явно указывать пользователю что данное поле заполнять не следует ;).
На мой взгляд предложенная идея отфильтрует достаточно большое количество спама и будет достаточно прозрачна для пользователей.
суббота, 26 апреля 2008 г.
Как рождается философия ...
Играл в принца персии ... не в ту древнюю суперскую 2D, а в нормальную 3Dшную. Хотя суть не в этом. Те, кто знает игрульку тот меня поймет. Не важно сколько раз во время игры ты умер - всегда можно начать с последнего сохранения. В чем тогда интерес игрушки ? А в том что ужасно сложно просто определиться куда все таки идти !..
Вот в этот момент мой мозг сработал как то необычно ... обобщил эту мысль на всю мою жизнь.
Не важно на какие грабли и сложности нарвешься, если они не критические то можно всегда заново начать. Страшно если просто не знаешь куда дальше идти.
Вот такие глюки возникают в моей непутевой башке.
Вот в этот момент мой мозг сработал как то необычно ... обобщил эту мысль на всю мою жизнь.
Не важно на какие грабли и сложности нарвешься, если они не критические то можно всегда заново начать. Страшно если просто не знаешь куда дальше идти.
Вот такие глюки возникают в моей непутевой башке.
понедельник, 21 апреля 2008 г.
EventLog Security
Радует меня безопасность винды все больше и больше. Искал способ записи в журнал безопасности, так называемый EventLog\Security. И вот на что в конечном счете наткнулся:
"Only the Local Security Authority (Lsass.exe) has write permission for the Security log. No other account can request this privilege."
Ребяты жгут. А если я пишу сервис, к которому должны обращаться аутентифицированные ползователи ? Куда мне писать историю обращений ? Делать свой журнал ?
Конечно не все так ужасно. Мелкософт все же решил что стоит разрешить писать в журнал ... и предоставил WinAPI интерфейс ... теперь называется - привяжи его к .NET.
Подписаться на:
Сообщения (Atom)