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

Теория простоты

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

понедельник, 30 июня 2008 г.

Определения

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

Опредление 1.
Назовем сложным то что кроме вас никто полностью(во всех мелочах) не понимает.

Следствие из Определения 1.
Явление или объект являются сложными если даже вы полностью(во всех мелочах) не понимаете его.

Определение 2.
Назовем простым то что кроме вас поймет любой балбес.

Следствие из Определения 2.
Если явление понятно каждому то оно гениально.

Теорема 1.
Систему или явление можно сделать простой если придумать простое тому объяснение.

Теорема 2.
Усложнить можно все что угодно.

ЗЫ: в каждой шутке только доля шутки :)

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

Отпуск ...

Что может быть лучше отпуска? Только два отпуска :) Но я собственно не о том.

Заметил такую интересную штуку, желание поработать во время отпуска возникает как то волнообразно. Первый "всплеск" как правило приходится на 3-4 день отпуска. Если нормально "пережить" этот период, то дальше работать не хочется уже с неделю точно - просто не тянет. Самое важное в этот период - не начать что нить делать. Это как правило приводит к плачевным результатам: потерянному времени (отпуска).

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

вторник, 17 июня 2008 г.

Ощущения от Firefox 3.0

Поставил третьего огненного лиса. Супер восхищения не ощутил поэтому сразу к делу.
Что не понравилось:
1. При установке на вторую версию обновились и встали нормально только два плагина. Работать без остальных конечно можно, но жутко неудобно.
2. Ребята из mozilla реально не рассчитали что после загрузки третьей версии все ломанутся грузить к ней плагины в связи с чем, видимо, этот ресурс стал недоступен.
3. Не появилось ничего "сногсшибательного". Обещали столько нового, а получилось что просто догоняют другие браузеры.

Что понравилось:
1. Как ни крути, но пиар-акция с "днем загрузки" классная штука.
2. Все встало достаточно быстро и шустро. Почти не было проблов при первом запуске (см недостаток №1).
3. Новая версия - новый интерфейс. Новые "фичи". Особенно классно - адресная строка начала реально экономить время.
4. Вроде стал пошустрее, но надо проверять.
5. Все смотрится пока немного "ненадежным".

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

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

И снова терминология

Возвращаясь к теме терминологии, почему большинство терминов сухие и безжизненные?
Вот пример: есть термин рециркуляция приложений (когда приложение восстанавливается после сбоя). Только что, роясь в блогах наткнулся на термин "сервер реинкарнации". По моему звучит просто отпадно! Вот так надо называть системы.

четверг, 12 июня 2008 г.

Терминология да и только

Сегодня услышал от брата новый термин (может он его сам придумал, может где слышал) - замкадовец (человек, живущий за МКАД). Звучит примерно как иностранец.
Кто еще знает новые термины?

понедельник, 9 июня 2008 г.

На волне Web 3.0.

Что вы ищете в интернете? Информацию! В каком виде? Как правило в виде текста.
А кому приходилось искать образы? Приведу простой пример из жизни.
Для продукта потребовались иконки. Прога была маленькая и покупать для нее набор иконок не было возможности, да и напрягать дизайнера не хотелось. Что делать? Искать в интернете или рисовать самому. Я бы и рад сам нарисовать иконки, но что именно рисовать? Вот вопрос. Нужен ассоциативный ряд образов и понятий, причем не как попало, а такой, чтобы воспринимали все пользователи.
Попробуйте найти в инете иконки или образы по какому нибудь неоднозначному понятию, например - образ для понятие "Обработка гиперссылки".
Появилась идея создания ресурса для поиска готовых образов. Как все это может работать:
1. В ресурс публикуется какой либо образ (в виде картинки например).
2. Образ рассылается нескольким пользователям (+ создатель образа публикует его название).
3. Пользователи ставят образу некоторое его описание.
4. Описания анализируются и записываются в регистр.
5. При обращении пользователя к некоторому образу ему предлагаются соответствующие образы, а также смежные с ними.
6. Из найденных образов выбирается один и ставиться в соответствие поисковой фразе дополняя описание.

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

На мысль навела Алена C++. За что ей огромное спасибо.

воскресенье, 8 июня 2008 г.

Игры в которые играют люди ...

Подглядел у Алены C++ прикольную мысль. Представьте что вам нужно чтобы множество человек выполнили некоторую работу, причем за мизерную плату. Можно конечно нанять кучу китайцев... Но есть выход проще - представить все в виде игры. Помните, в рекламах есть лотереи типа "Собери 25 крышечек и 15 этикеточек и еще одну крышечку получи бесплатно". Ведь при этом нам в качестве игры предлагают выполнить некоторую работу (да еще и потратить ресурсы). Почему бы не заставить людей делать что нибудь полезное. например Алена С++ предлагает создавать так базу для распознавания образов.

суббота, 7 июня 2008 г.

Что нужно программисту ... и не только

Наткнулся на статью Сергея Архипенков "Антипаттерны руководства командами разработки ПО".
Достаточно подробный обзор типов руководителей. Поучительно. Вот что оттуда вычитал:

Программист устроен просто. Он состоит из четырех компонентов: тело, сердце, разум и душа.
  1. Телу необходимы деньги и безопасность.
  2. Сердцу - любовь и признание.
  3. Разуму – развитие и самосовершенствование.
  4. Душе – самореализация.
Предоставьте все это вашим сотрудникам, и эффективность их труда возрастет многократно. В противном случае профессионалы найдут все это в другой компании, а в вашей останутся только посредственности.

Кроме того, применимо это по моему не только для программистов, но и для любой другой профессии.

среда, 4 июня 2008 г.

Ошибки важнее.

Кто обращает внимание на типы ошибок при проектировании ? Только честно ?
Лично я не обращал на них особого внимания. Перехват, обработка и запись в логи - это да, это всегда делал, но никогда почти не задумывался о том что туда пишется. До недавних пор.

А все началось с того, что у меня генерились ошибки в методах сервиса. Ну и что, скажете Вы.

А то что при падении любой необработанной ошибки вызывается FaultException и валится проксик в состояние Fault. И поднять его уже нереально - только пересоздавать и переоткрывать что просто нереально долго и жрет ненужные ресурсы.

К счастью решение все же нашлось. Проксики не падают в случае, если Вы пропишете контракт ошибок для сервиса. Александр Межов в своей статье как раз описывает как обрабатывать ошибки сервисов (интересны кстати еще и калбэки ошибок).

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


воскресенье, 1 июня 2008 г.

Творчество или просто работа.

В работе программиста есть два существенных момента: использование существующих технологий и архитектурный подход для построения структуры приложения.
Так что же первостепенно? Что представляет из себя профессия программиста? Это творчество или рутина?

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

Для меня работа начала становиться интересной только в тот момент когда мне наконец то дали воплощать в жизнь мои собственные решения. Это сейчас самая лучшая мотивация в работе.

А каково ваше мнение о профессии? Кто такие программисты? Это свободные "художники" или все же работники, занимающиеся рутинным разгребанием кода?

воскресенье, 25 мая 2008 г.

SOA как панацея

В последнее время на каждом шагу слышу про SOA. Из нее делают просто таки панацею. А так ли это?
Да, принципы построения распределенной системы на сервисах мне очень даже нравятся, но нельзя же так на ней заморачиваться. Есть множество способов для построения распределенных систем. Тот же самый клиент-сервер.
У меня складывается ощущение что SOA становится модным словечком ... каким недавно был (да и остается по сей день) термин Web 2.0 или AJAX.
Если так дальше пойдет, то SOA будут запихивать везде и повсюду - как в свое время повсюду запихивали AJAX где надо и где не надо.
На мой взгляд, особую ценность представляет логика работы с данными и сами данные.
При построении архитектуры выстраивали трехзвенную архитектуру, например, data-view-controller.
А что если при построении систем строить объектную модель для работы с данными и объектную модель для бизнес логики которая ее использует. С помощью такого подхода можно менять хранилища данных по своему усмотрению, не меняя объектной модели - стоит только реализовать некоторый интерфейс по "доставанию" данных. При изменении же бизнес логики стоит только пересобрать отдельный слой - данные останутся прежними.
Если меняются структура данных - нужно изменить только слой работы с данными (тут конечно вопрос - надо ли при этом менять бизнес логику относительно изменения данных, но при нормальном оперировании объектами это будет необходимо достаточно редко).

Возможно, высказанные идеи не новы, но это то что навеяно проектированием. Я не борюсь за оригинальность.

понедельник, 5 мая 2008 г.

Как прокладывать пешеходные дорожки

Однажды всплыла на обсуждение в отделе тема необходимости написания универсального кода. Сразу в голове сработала ассоциация с рассказанным мне однажды ,уже не помню кем, примером, как прокладывают пешеходные дорожки у нас и в Европе.

И так, как это делается у нас:

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

Как делают на западе:

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

Теперь сделаем некоторые выводы применительно к разработке:

  1. Если есть две зависимые разработки - делать их параллельно. При распараллеливании выявляем на этапе разработки потребности и тут же их решаем (если понадобиться повторное использование кода - всегда можно вынести уже реализованную логику).
  2. Не делать универсальных методов - исходить из потребностей. Так же проектировать разработку - исходя из потребностей.
  3. Хорошо анализировать потребности. Не надеяться что "это возможно в будущем где то понадобиться еще". Через месяц об повторном использовании кода может никто и не вспомнит и напишет свою логику.
ЗЫ: Все вышесказанное личное мнение автора и применимо не ко всем разработкам.

вторник, 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

Пятьсот пятьдесят восемь миль.

воскресенье, 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.

воскресенье, 20 апреля 2008 г.

Пингвины рулят


Точнее мочат... и по большому счету MS.
Сегодня наткнулся на статью Истеричный менеджмент - виновник низкой производительности труда.
Как офисный работник могу сказать что многое из сказанного - чистейшая правда. Особенно про перегрузки. IT компании как правило пытаются выжать из сотрудников максимум, но при этом теряют достаточно много.

вторник, 15 апреля 2008 г.

Аутентификаци & Персонализация

Давайте рассмотрим какие вещи могут происходить в системе при входе пользователя.
  1. Аутентификация. Пользователь подтверждает что это он заходит в систему, а не Дядя Вася Пупкин из села Простоквашино.
  2. Авторизация. Система выдает права пользователю. Говорит что Петя Иванов может получить доступ только к своим данным. Может быть назначает ему роль или явно определяет на основе битовой маски его права по вхождению в группы и личным правам.
  3. Имперсонация. Система берет привилегии юзера и использует доступные ему ресурсы.
  4. Персонализация. Система выбирает настройки для конкретного пользователя. Ширина и видимость столбцов таблиц, стили отображения, цвета, шрифты, значения по умолчанию и т.д.
При этом, прежде чем происходят 2,3,4 пользователь должен авторизоваться.
А теперь представьте что нам необходимо создать независимое средство для хранения персональных данных пользователя и соотвественно для обращения к ним. Система авторизации и система персонализации - несколько разные вещи и их следует разделить. Отлично, разделили, а как теперь система персонализации узнает что пользователь прошел аутентификацию? Передавать ей некоторый уникальный код ?

четверг, 10 апреля 2008 г.

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

MS SQL Server CE это субд для создания настольной компактной базы данных и управления ей. Выглядит она как inprocess библиотека, занимает 1-3 мб памяти. Для десктопных простых приложений незаменимая вещь.

База представляет из себя *.sdf файлик. Кто знаком с работой обычного MS SQL Server, тот знает что это second файл базы(second database file), поэтому достаточно просто его можно подвязать к нормальному серверу.

Для меня было достаточно приятно что появилось простое и доступное средство для работы сбазами. Функционал конечно достаточно нехило урезан, но для полноценной работы его вполне достаточно.

Где подобную базу можно использовать:

  1. Небольшие desktop приложения для которых нужно простое безопасное хранилище данных, со всеми "вкусностями" SQL запросов.
  2. Smart клиенты для которых нужно органиховать offline режим работы и репликацию данных.
  3. Разработки для Windows Mobile (не путать со smart клиентами) для которых нужна простая и легкая база.
  4. При разработке мобильных приложений когда базу нужно быстро перетащить (в этом случае базу можно просто скопировать с одной машины на другую без потери функциональности и работоспособности и без бэкапов).

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

Кросс пост с моего сайта

суббота, 5 апреля 2008 г.

Вехи

Недавно задумался над тем, почему таким образом развивается web и в частности , почему мне приходится заниматься тем, чем я занимаюсь.
Для web сейчас реально существует большая проблема с передачей данных. Если подробнее, то при каждом обращении к определенной страничке вы загружаете все, и сами данные и представление данных и логику. Даже если вы загружаете страницу по 40 раз в день.
А так хочется представление и логика получались только один раз (и при том только если это действительно нужно). А данные передавались в некотором универсальном формате(например, xml).
Эту проблему решали давно. Сначала пытались сделать кэширование страничек, рисунков, скриптов, стилей и т.д. Такой подход не позволяет отказаться полностью от передачи представления, так как заставляет браузер обновлять его, к тому де на самой страничке данные динамически меняются, а страничка содержит не только данные, но и представление, и мета информацию.
Следующим шагом была технология Ajax. Которая позволила передавать сами данные и относительно них менять представление. Но Ajax ориентирован на визуальное представление данных и имеет кучу проблем сам по себе.
Решать проблему передачи только данных теперь может SOA + Smart клиенты. При этом представление и логика уже будут находится у клиента.

четверг, 3 апреля 2008 г.

404

Поздравляю всех с днем антивэба (4.04) !!! :)

Логика в массы

Вот как надо учить логические операции :)

not
:-) = not :-(
:-( = not :-)
or
:-) = :-) or :-)
:-( = :-( or :-(
:-) = :-( or :-)
:-) = :-) or :-(
and
:-) = :-) and :-)
:-( = :-( and :-(
:-( = :-( and :-)
:-( = :-) and :-(
xor
:-( = :-) xor :-)
:-( = :-( xor :-(
:-) = :-( xor :-)
:-) = :-) xor :-(
->
:-) = :-) -> :-)
:-) = :-( -> :-(
:-) = :-( -> :-)
:-( = :-) -> :-(

Проверяем знание HTML

А ты сколько знаешь HTML тэгов??? Проверь себя!!!

Вот что у меня получилось:

You forgot:
ABBR, ACRONYM, APPLET, AREA, BASE, BASEFONT, BDO, BIG, BLOCKQUOTE, BUTTON, CAPTION, CITE, CODE, COLGROUP, DD, DEL, DFN, DIR, DL, DT, FIELDSET, FRAME, FRAMESET, IFRAME, INS, ISINDEX, KBD, LEGEND, MAP, MENU, NOFRAMES, NOSCRIPT, OPTGROUP, PARAM, PRE, SAMP, SELECT, SMALL, STRIKE, STRONG, STYLE, TBODY, TFOOT, THEAD, TITLE, TT, VAR

Так что я не знаю HTML настолько чтобы этим хвастаться. Но с другой стороны его не нужно знать - любой тэг можно получить стилями.

среда, 2 апреля 2008 г.

Вот как на самом деле называются цвета.

А я то дурак столько времени называл Ализариновый красный просто красным.

Как же я ошибался!!! Laughing

А вот HP взяли и опубликовали эксперементальную форму где каждый может дать свое название цвету.

вторник, 1 апреля 2008 г.

Исходники висты ;)


Исходный код Windows Vista. Есть интересные моменты использования некоторых системных функций. :-D

Мой маленький уголок в сети

Наконец то сбылось то о чем я долго и продолжительно мечтал - я сделал и успешно опубликовал свой динамический сайт с которым было столько проблем.
Посмотреть и потестировать можно тут .
Теперь у меня есть реальная платформа для развития своих задумок. Будем надеятся что меня не выгонят с хостинга до того как я успею там что нить сломать :).
Если у кого то будут предложения по реализации какой нить функциональности - пишите буду только раз в реализации.
Ведь главное в любом проекте - идея. А технологии служат лишь для решения поставленных задач.
Так что с нетерпением жду предложений или в этом блоге или на сайте. ;)

понедельник, 31 марта 2008 г.

sqLite первые восторги

И зачем мне нужны были все эти громоздкие базы данных ? MySQL, MSSQL ... для маленького проекта их возможности ужасно избыточны. Но традиция заставляет их использовать. Как говорится "так исторически сложилось" что клиент-серверные базы превалируют.
А нужны ли они в простеньком проектике? Даже интернет магазин может быть построен без громоздких баз данных.
Вот что пишут на официальном сайте sqLite буржуи: SQLite is a software library that implements a self-contained, serverless, zero-configuration, transactional SQL database engine.
Что мне понравилось:
  1. база лежит в одном файле там где вы сами хотите
  2. редактировать ее проще некуда (есть консольный интерпретатор, а можно и виндовым пользоваться - тут на любителя)
  3. в пхп5 встроена поддержка sqlite
  4. поддерживает pdo (!!! для prado просто оптимально ;) )
  5. поддерживает все основные возможности современных баз: вьюшки, триггеры, транзакции и т.д.
  6. можно работать с базой в несколько потоков
  7. ну и всякая межплатформенность и т.д. :)
  8. для редактирования базы нужно консольное приложение, которое весит 400 Kb (!!! это вам не гигабайтные SQL сервера)
Что не понравилось:
  1. для более менее крупного проекта база будет занимать пространство на хостинге что при ограничении на размер существенный недостаток.
  2. задолбался устанавливать pdo под денвер (это может я <туплю> плохо соображаю
  3. смущает безопасность - обращение и все файловые операции происходят из потока сервака, поэтому могут быть проблемы с получением доступа и загрузки зловредного кода (не такой уж и большой минус)

Так что от sqLite я просто в восторге, хотя задолбался с ним не по детски.

воскресенье, 30 марта 2008 г.

PRADO недовольство

Вот и настал час разочарования. PRADO меня разочаровало, причем не на шутку.
Написал свой сайт на основе демки которая идет в пакете фреймворка.
Сайт потрясно работает на денвере с php5 локально. Как только стал публиковать на хостинге - возникли проблемы. Оказалось что PRADO умеет работать с MySQL только через PDO.
Не нашел ни одного бесплатного хостинга, где было бы установлено pdo_mysql. Поэтому сайт не работает.
Есть конечно вариант - перевести сайт на sqlite. Для него PDO стоит на нескольких бесплатных хостингах. Да и подходит он мне больше - получается полностью локальная и переносимая версия сайта - базы лежат прямо на диске. Можно бэкапы делать быстро: слил файлы с хостинга и радуешься.
Однако от проблем хостинга к проблемам PRADO. По моему было слишком опрометчиво надеятся целиком на PDO. Надо было сделать модуль для подключения к MySQL через встроенные возможности PHP. Иначе прийдется все писать руками что мне очень не нравится. Так что теперь я перед большим выбором - искать хостинг или переписывать сайт.

суббота, 29 марта 2008 г.

Жизнь в 100 словах

Колыбель. Пеленки. Плач.
Слово. Шаг. Простуда. Врач.
Беготня. Игрушки. Брат
Двор. Качели. Детский сад.
Школа. Двойка. Тройка.Пять.
Мяч. Подножка. Гипс. Кровать.
Драка. Кровь. Разбитый нос.
Двор.Друзья. Тусовка. Форс.
Институт. Весна. Кусты.
Лето. Сессия. Хвосты.
Пиво. Водка. Джин со льдом.
Кофе. Сессия. Диплом .
Романтизм. Любовь. Звезда.
Руки. Губы. Ночь без сна .
Свадьба. Теща. Тесть. Капкан.
Ссора. Клуб. Друзья. Стакан.
Дом. Работа. Дом. Семья.
Солнце. Лето. Снег. Зима.
Сын. Пеленки. Колыбель .
Стресс. Любовница. Постель.
Бизнес. Деньги. План. Аврал.
Телевизор. Сериал.
Дача. Вишни. Кабачки.
Седина. Мигрень. Очки.
Внук. Пеленки. Колыбель .
Стресс. Давление. Постель.
Сердце. Почки. Кости. Врач.
Речи. Гроб. Прощанье. Плач.

пятница, 28 марта 2008 г.

Обработка ссылок в системе

Проблема: есть программа, которая генерирует ссылки на свои объекты в некотором формате (например http://sample.ru/object.aspx?sys=sys_code&id=object_id ) при этом происходит обращение к веб-серверу, который возвращает файл с некоторым MIME типом, открываемый на клиенте зарегистрированной для этого типа программой (например, некоторым обработчиком объектов данной программы). Изменить формат ссылок нельзя, но вся необходимая для открытия объекта информация содержится непосредственно в ссылке.
Как одно из решений - написание расширений для браузеров, которое будет отрезать обращение к серверу для ссылок определенного формата и обрабатывать их самостоятельно.
  • IE: решением для IE было бы создание Asynchronus Pluggable Protocol, но такое решение сталкивается с несколькими проблемами. Такое решение будет работать только если браузером по умолчанию стоит IE. Сложно писать (все таки ActiveX). Проблемы при установке. Проблемы при открытии ссылок из сторонних приложений.
  • Firefox: для firefox все несколько проще. можно навеситься на событие ввода адреса в строку адреса и на событие загрузки браузера. А с помощью XUL можно запустить произвольное прилоджение
  • Opera: Для этого браузера сделать подобный перехват не удастся. браузер конечно поддерживает пользовательские скрипты и плагины, но навеситься на перехват перехода по ссылке я не смог, кроме того, я не смог из пользовательского скрипта запустить внешнее приложение или обратиться к COM классам.
Однако, писать плагины под каждый браузер - несколько нелепо. Ведь обработка гиперссылок может по разному обрабатываться внутри приложений, а при передаче гиперссылок должны отрабатывать одни и те же системные механизмы. Универсальным решением все таки стала бы обработка имено таких событий.
Как я понял, в Windows обработкой гиперссылок занимается модуль urlmon.dll. Он же вызывает методы интерфейса IInternetProtocol и IInternetProtocolSink для Asynchronus Pluggable Protocol.
Универсального решения проблемы я так и не нашел. Если кто нибудь знаешь в какую сторону копать - подскажите плз.

вторник, 25 марта 2008 г.

Подписка на события

Уже давно слышал о идее службы подписки на различные события: приход почты, возникновения ошибки, входа пользователя и т.д. Как правило простые события достаточно просто отслеживаются и необходимости в подписке не возникает.
Однако, порой нужно уметь подписываться на нестандартные события. Например недавно встретился с задачей: при записи в лог файл десятого сообщения, соответствующего определенному формату нужно отправлять письмо администратору.
Для такой задачи очень бы пригодилась система, способная генерировать сообщения, в зависимости от происходящих событий.
Что такая система должна делать:
  • Уметь определять момент возникновения события системы(как ОС, так и прикладной системы, причем во втором случае может возникнуть необходимость или в периодическом опросе или в жесткой интеграции)
  • Генерировать события подписки (рассылать почту, вызывать внешние методы, обращаться к веб-сервисам, издавать звук и т.д.)
В принципе, функциональности такая система несет немного, и ее реализация достаточно проста если прикладная система открыта и позволяет отловить возникающие в ней события.

Vista Aero и Web

Наткнулся на вот такой блог и задумался о том, действительно ли красота темы Aero Glass адекватна вэбу. Прозрачный интерфейс хорош, но стоит ли он того, чтобы переносить его в веб?
Менюшки потрясные, полупрозрачные png'шки очень неплохо смотрятся, но очень уж тяжело это все. Да и без картинок это будет выглядеть не совсем красиво.

ЗЫ: Кстати, на этом же блоге живет удивительный крысомамонт(замена RSS :) ). Улыбнуло.

Мониторинг состояния системы

Откуда вы обычно узнаете что ваша система не работает? От разгневаных клиентов? Или от неменее разгневаного руководства?

А как вы узнаете о причине неполадки? Используя собственный опыт и знание системы? Или долго и продолжительно изучаете логи, выискиваете ошибку, определяете причины?

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

И так, что требуется от службы мониторинга:

  1. Иметь базовый набор тестовых методов для проверки базового функционала системы(здесь очень пригодятся автоматические тесты, написанные на этапе разработки или тестирования)
  2. Уметь запускать мониторинг состояния системы в определенное время, проверять базовый функционал, логи и т.д.
  3. Уметь формировать сводный отчет и отправлять его ответственному(администратору или разработчику)
  4. Уметь устранять некоторые неисправности(например, перезапускать веб-сервер)
Недостатки такой системы:
  1. Жестко связана с обследуемой системой.
  2. Низкая гибкость, малая универсальность. Для каждой новой функциональности нужно писать свой метод для его мониторинга.
  3. Большие накладные расходы на полный мониторинг(трафик, время, загрузка сервера).
Для устранения этих недостатков можно
  1. Использовать автоматические тесты, созданные на этапе разработки или тестирования.
  2. Проводить мониторинг эпизодически (по требованию) для устранения неполадок.
Однако, разработка такой системы в большинстве случаев не оправдывает себя. Слишком большие накладные расходы на создание и поддержку системы. Однако, идея может быть реализована в сети как предоставляемый платный сервис, тогда решится проблема с разработкой своей системы, нужно будет лишь написать функционал(если его нет в стандартной, предоставляемой сервисом) для мониторинга специфической логики.

вторник, 4 марта 2008 г.

Веб-сервисы. Xml серелизация COM объектов.

Сегодня столкнулся со следующей проблемой. Веб-сервис должен обмениваться данными, которые получаются посредством некоторого COM класса. Данные хранятся в полях данного класса. При этом .NET не умеет серелизовать COM классы, да ему это и не нужно .
Решение проблемы может быть одним из следующих:
  1. Выдирать из класса необходимые данные и записывать в свою структуру данных, которая уже будет серелизоваться. Достоинства: можно просто управлять серелизацией класса, можно также манипулировать полученными данными в классе, можно сделать свою систему хэширования данных на основе данных структур данных. Недостатки: необходим механизм преобразования COM класса в нашу структуру данных, причем такой механизм необходимо организовывать для каждого класса, сам же механизм представляет из себя лишь перенос данных из полей COM объекта в поля данных нашего класса.
  2. Организовать "универсальный" механизм серелизации необходимых нам COM классов в виде, скажем, фабрики. Достоинства: общий механизм для серелизации, нет накладных расходов на хранение "промежуточных" классов с данными - вся работа ведется непосредственно через COM. Недостатки: данные COM объектов могут быть в спецефическом формате, и общий механизм серелизации его некорректно обработает.
  3. Организовать "обертку" для COM, свойства которой серелизуются. Достоинства: Нет накладных расходов на хранение данных COM объектов, обертка просто серелизуется. Недостатки: Для каждого COM класса нужна своя обертка.
Вообще передача самого COM объекта для веб-сервисов не актуальна - необходимо передавать только данные, которые хранятся в их полях. Но для удобства разработки необходим универсальный подход. Удобно бывает не задумываться о том, как серелизуется и десерелизуется объект, для разработчика важны только данные, переданные методами сервиса.
Возможно для этих целей уже есть стандартное решение и я на него пока(!) не натолкнулся.

четверг, 28 февраля 2008 г.

На старт ... или первый взгляд на PRADO.

Не буду утомлять своим нытьем по поводу того, что я создал свой блог - это и так понятно. Сразу к делу.

Уже как год я "вынужден" программировать на .NET, и скажу я вам что мне это нравиться. Однако судьба так распорядилась что столкнулся я с PHP и несколько оробел сперва. Мало того что к скритовым языкам я не очень то привычный (jsvascript еще более менее понятен и очевиден), так он оказался несколько ниже по уровню, нежели .net. Почти сразу у меня возникла идея ... неужели нельзя написать на php полноценный framework и уже с ним работать. Встроенные средства аутентификации, персонализации, работы с xml и тому подобные прелести облегчили бы построение приложений на пхп в разы.

Идея вызревала в моей голове до тех пор, пока я не наткнулся на уже готовый framework и собственно был не просто удивлен, а поражен.

И так ... PARDO.

Как заявляется на официальном сайте http://www.pradosoft.com/
PRADO is a component-based and event-driven programming framework for developing Web applications in PHP5. PRADO stands for PHP Rapid Application Development Object-oriented.
В общем то - framework, основанный на построении визуальный компонентов.

Как только я кинул первый взгляд на платформу меня тут же постигло ощущение что я это где то уже видел. Я попал в привычную среду .NET, только на PHP. Те же конфигурационные xml'ки, те же пространства имен, те же компонент-ориентированные принципы построения контролей. Одним словом, практически все "слизано" с ASP.NET.

Хорошо или плохо ?

Разберу все с чем успел столкнуться подробнее.

Действительно, работать c xml данными в .net на много проще, нежели на php. И удобный интерфейс для работы с xml на hpp лично мне очень был нужен. Но стоит ли при этом полностью копировать пространство имен System.Xml ? Может быть стоило проработать нечто свое?

Потопали дальше. Библиотека встроенных веб-контролей. Здесь я был просто в восторге. При той скупости которую дает сам пхп, библиотека визуальных контролей выглядит просто откровением. Кроме того, отделение кода от представления странички тоже неплохо выглядит. Еще одно приемущество - уже готовые AJAX контроли(выстроены на основе prototype.js), неплохая коллекция валидаторов. Писать свои компоненты конечно достаточно непросто, но оно того стоит.

Встроенная система аутентификации пользователей по конфигурированию ужасно напоминает ASP.NET. Вот для примера кусок конфигурационного файла, отвечающего за авторизацию
<authorization>
<allow pages="Login" users="?" />
<allow roles="normal" />
<deny users="*" />
</authorization>
Не правда ли, напоминает ASP ?

Настойчивое ощущение "слизанности" PRADO с ASP.NET не покидало меня ни на секунду. Однако когда что то происходит один раз это случайность, когда два - уже закономерность. Неужели .net framework настолько хорошо и логично построен что его необходимо копировать?

ЗЫ: Несколько многовато получилось для первого блога, однако прошу меня за это простить, видимо накопилось столько мыслей что высказать их просто необходимо.