среда, 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 г.
Игры в которые играют люди ...
суббота, 7 июня 2008 г.
Что нужно программисту ... и не только
Наткнулся на статью Сергея Архипенков "Антипаттерны руководства командами разработки ПО".
Достаточно подробный обзор типов руководителей. Поучительно. Вот что оттуда вычитал:
Программист устроен просто. Он состоит из четырех компонентов: тело, сердце, разум и душа.Предоставьте все это вашим сотрудникам, и эффективность их труда возрастет многократно. В противном случае профессионалы найдут все это в другой компании, а в вашей останутся только посредственности.
- Телу необходимы деньги и безопасность.
- Сердцу - любовь и признание.
- Разуму – развитие и самосовершенствование.
- Душе – самореализация.
Кроме того, применимо это по моему не только для программистов, но и для любой другой профессии.
среда, 4 июня 2008 г.
Ошибки важнее.
Кто обращает внимание на типы ошибок при проектировании ? Только честно ?
Лично я не обращал на них особого внимания. Перехват, обработка и запись в логи - это да, это всегда делал, но никогда почти не задумывался о том что туда пишется. До недавних пор.
А все началось с того, что у меня генерились ошибки в методах сервиса. Ну и что, скажете Вы.
А то что при падении любой необработанной ошибки вызывается FaultException и валится проксик в состояние Fault. И поднять его уже нереально - только пересоздавать и переоткрывать что просто нереально долго и жрет ненужные ресурсы.
При чем обрабатывать ошибки стало значительно удобнее - всегда знаешь когда свалилась прикладная логика, когда свалился скажем слой работы с данными, когда упал канал и т.д. Можно отследить практически любые ошибки на клиенте.
воскресенье, 1 июня 2008 г.
Творчество или просто работа.
В работе программиста есть два существенных момента: использование существующих технологий и архитектурный подход для построения структуры приложения.
Так что же первостепенно? Что представляет из себя профессия программиста? Это творчество или рутина?
Думаю что и то и то. Надо просто в рутине найти порядок и попробовать повернуть этот порядок в нужное русло. Не стоит ломать или переворачивать рутину. Это принесет кучу жертв, а должного эффекта не принесет (выстроенная на развалинах система скорее всего будет так же несовершенна как и предшественница, или даже иметь кучу новых недостатков). Не нужно сумасшедших идей, идеи нужны логичные и законченные.
Для меня работа начала становиться интересной только в тот момент когда мне наконец то дали воплощать в жизнь мои собственные решения. Это сейчас самая лучшая мотивация в работе.А каково ваше мнение о профессии? Кто такие программисты? Это свободные "художники" или все же работники, занимающиеся рутинным разгребанием кода?
четверг, 29 мая 2008 г.
воскресенье, 25 мая 2008 г.
SOA как панацея
Да, принципы построения распределенной системы на сервисах мне очень даже нравятся, но нельзя же так на ней заморачиваться. Есть множество способов для построения распределенных систем. Тот же самый клиент-сервер.
У меня складывается ощущение что 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
Пятьсот пятьдесят восемь миль.
воскресенье, 27 апреля 2008 г.
Антиспам
Многие спам-боты работают, формируя пост запросы на основе содержимого формы. Причем, как правило, боты заполняют по возможности все поля.
Возникла идея - делать некоторое дополнительное поле формы, прятать его от обычного пользователя с помощью стилей или размеров, или явно указывать пользователю что данное поле заполнять не следует ;).
На мой взгляд предложенная идея отфильтрует достаточно большое количество спама и будет достаточно прозрачна для пользователей.
суббота, 26 апреля 2008 г.
Как рождается философия ...
Вот в этот момент мой мозг сработал как то необычно ... обобщил эту мысль на всю мою жизнь.
Не важно на какие грабли и сложности нарвешься, если они не критические то можно всегда заново начать. Страшно если просто не знаешь куда дальше идти.
Вот такие глюки возникают в моей непутевой башке.
понедельник, 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 г.
Как офисный работник могу сказать что многое из сказанного - чистейшая правда. Особенно про перегрузки. IT компании как правило пытаются выжать из сотрудников максимум, но при этом теряют достаточно много.
среда, 16 апреля 2008 г.
вторник, 15 апреля 2008 г.
Аутентификаци & Персонализация
- Аутентификация. Пользователь подтверждает что это он заходит в систему, а не Дядя Вася Пупкин из села Простоквашино.
- Авторизация. Система выдает права пользователю. Говорит что Петя Иванов может получить доступ только к своим данным. Может быть назначает ему роль или явно определяет на основе битовой маски его права по вхождению в группы и личным правам.
- Имперсонация. Система берет привилегии юзера и использует доступные ему ресурсы.
- Персонализация. Система выбирает настройки для конкретного пользователя. Ширина и видимость столбцов таблиц, стили отображения, цвета, шрифты, значения по умолчанию и т.д.
А теперь представьте что нам необходимо создать независимое средство для хранения персональных данных пользователя и соотвественно для обращения к ним. Система авторизации и система персонализации - несколько разные вещи и их следует разделить. Отлично, разделили, а как теперь система персонализации узнает что пользователь прошел аутентификацию? Передавать ей некоторый уникальный код ?
четверг, 10 апреля 2008 г.
После того как я наткнулся на sqLite, на котором собственно сейчас работает и этот блог тоже, мне пришлось столкнуться с мелкосовтовской разработкой подобного типа.
MS SQL Server CE это субд для создания настольной компактной базы данных и управления ей. Выглядит она как inprocess библиотека, занимает 1-3 мб памяти. Для десктопных простых приложений незаменимая вещь.
База представляет из себя *.sdf файлик. Кто знаком с работой обычного MS SQL Server, тот знает что это second файл базы(second database file), поэтому достаточно просто его можно подвязать к нормальному серверу.
Для меня было достаточно приятно что появилось простое и доступное средство для работы сбазами. Функционал конечно достаточно нехило урезан, но для полноценной работы его вполне достаточно.
Где подобную базу можно использовать:
- Небольшие desktop приложения для которых нужно простое безопасное хранилище данных, со всеми "вкусностями" SQL запросов.
- Smart клиенты для которых нужно органиховать offline режим работы и репликацию данных.
- Разработки для Windows Mobile (не путать со smart клиентами) для которых нужна простая и легкая база.
- При разработке мобильных приложений когда базу нужно быстро перетащить (в этом случае базу можно просто скопировать с одной машины на другую без потери функциональности и работоспособности и без бэкапов).
Посмотрим что будет при реальном использовании, но думаю что неприятных неожиданностей не будет.
Кросс пост с моего сайта
суббота, 5 апреля 2008 г.
Вехи
Для web сейчас реально существует большая проблема с передачей данных. Если подробнее, то при каждом обращении к определенной страничке вы загружаете все, и сами данные и представление данных и логику. Даже если вы загружаете страницу по 40 раз в день.
А так хочется представление и логика получались только один раз (и при том только если это действительно нужно). А данные передавались в некотором универсальном формате(например, xml).
Эту проблему решали давно. Сначала пытались сделать кэширование страничек, рисунков, скриптов, стилей и т.д. Такой подход не позволяет отказаться полностью от передачи представления, так как заставляет браузер обновлять его, к тому де на самой страничке данные динамически меняются, а страничка содержит не только данные, но и представление, и мета информацию.
Следующим шагом была технология Ajax. Которая позволила передавать сами данные и относительно них менять представление. Но Ajax ориентирован на визуальное представление данных и имеет кучу проблем сам по себе.
Решать проблему передачи только данных теперь может SOA + Smart клиенты. При этом представление и логика уже будут находится у клиента.
четверг, 3 апреля 2008 г.
Логика в массы
not
:-) = not :-(
:-( = not :-)
or
:-) = :-) or :-)
:-( = :-( or :-(
:-) = :-( or :-)
:-) = :-) or :-(
and
:-) = :-) and :-)
:-( = :-( and :-(
:-( = :-( and :-)
:-( = :-) and :-(
xor
:-( = :-) xor :-)
:-( = :-( xor :-(
:-) = :-( xor :-)
:-) = :-) xor :-(
->
:-) = :-) -> :-)
:-) = :-( -> :-(
:-) = :-( -> :-)
:-( = :-) -> :-(
Проверяем знание HTML
Вот что у меня получилось:
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 г.
Вот как на самом деле называются цвета.
А я то дурак столько времени называл Ализариновый красный просто красным.
Как же я ошибался!!!
А вот HP взяли и опубликовали эксперементальную форму где каждый может дать свое название цвету.
вторник, 1 апреля 2008 г.
Мой маленький уголок в сети
Посмотреть и потестировать можно тут .
Теперь у меня есть реальная платформа для развития своих задумок. Будем надеятся что меня не выгонят с хостинга до того как я успею там что нить сломать :).
Если у кого то будут предложения по реализации какой нить функциональности - пишите буду только раз в реализации.
Ведь главное в любом проекте - идея. А технологии служат лишь для решения поставленных задач.
Так что с нетерпением жду предложений или в этом блоге или на сайте. ;)
понедельник, 31 марта 2008 г.
sqLite первые восторги
А нужны ли они в простеньком проектике? Даже интернет магазин может быть построен без громоздких баз данных.
Вот что пишут на официальном сайте sqLite буржуи: SQLite is a software library that implements a self-contained, serverless, zero-configuration, transactional SQL database engine.
Что мне понравилось:
- база лежит в одном файле там где вы сами хотите
- редактировать ее проще некуда (есть консольный интерпретатор, а можно и виндовым пользоваться - тут на любителя)
- в пхп5 встроена поддержка sqlite
- поддерживает pdo (!!! для prado просто оптимально ;) )
- поддерживает все основные возможности современных баз: вьюшки, триггеры, транзакции и т.д.
- можно работать с базой в несколько потоков
- ну и всякая межплатформенность и т.д. :)
- для редактирования базы нужно консольное приложение, которое весит 400 Kb (!!! это вам не гигабайтные SQL сервера)
- для более менее крупного проекта база будет занимать пространство на хостинге что при ограничении на размер существенный недостаток.
- задолбался устанавливать pdo под денвер (это может я <туплю> плохо соображаю
- смущает безопасность - обращение и все файловые операции происходят из потока сервака, поэтому могут быть проблемы с получением доступа и загрузки зловредного кода (не такой уж и большой минус)
Так что от sqLite я просто в восторге, хотя задолбался с ним не по детски.
воскресенье, 30 марта 2008 г.
PRADO недовольство
Написал свой сайт на основе демки которая идет в пакете фреймворка.
Сайт потрясно работает на денвере с php5 локально. Как только стал публиковать на хостинге - возникли проблемы. Оказалось что PRADO умеет работать с MySQL только через PDO.
Не нашел ни одного бесплатного хостинга, где было бы установлено pdo_mysql. Поэтому сайт не работает.
Есть конечно вариант - перевести сайт на sqlite. Для него PDO стоит на нескольких бесплатных хостингах. Да и подходит он мне больше - получается полностью локальная и переносимая версия сайта - базы лежат прямо на диске. Можно бэкапы делать быстро: слил файлы с хостинга и радуешься.
Однако от проблем хостинга к проблемам PRADO. По моему было слишком опрометчиво надеятся целиком на PDO. Надо было сделать модуль для подключения к MySQL через встроенные возможности PHP. Иначе прийдется все писать руками что мне очень не нравится. Так что теперь я перед большим выбором - искать хостинг или переписывать сайт.
суббота, 29 марта 2008 г.
Жизнь в 100 словах
Слово. Шаг. Простуда. Врач.
Беготня. Игрушки. Брат
Двор. Качели. Детский сад.
Школа. Двойка. Тройка.Пять.
Мяч. Подножка. Гипс. Кровать.
Драка. Кровь. Разбитый нос.
Двор.Друзья. Тусовка. Форс.
Институт. Весна. Кусты.
Лето. Сессия. Хвосты.
Пиво. Водка. Джин со льдом.
Кофе. Сессия. Диплом .
Романтизм. Любовь. Звезда.
Руки. Губы. Ночь без сна .
Свадьба. Теща. Тесть. Капкан.
Ссора. Клуб. Друзья. Стакан.
Дом. Работа. Дом. Семья.
Солнце. Лето. Снег. Зима.
Сын. Пеленки. Колыбель .
Стресс. Любовница. Постель.
Бизнес. Деньги. План. Аврал.
Телевизор. Сериал.
Дача. Вишни. Кабачки.
Седина. Мигрень. Очки.
Внук. Пеленки. Колыбель .
Стресс. Давление. Постель.
Сердце. Почки. Кости. Врач.
Речи. Гроб. Прощанье. Плач.
пятница, 28 марта 2008 г.
Обработка ссылок в системе
Как одно из решений - написание расширений для браузеров, которое будет отрезать обращение к серверу для ссылок определенного формата и обрабатывать их самостоятельно.
- 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
Менюшки потрясные, полупрозрачные png'шки очень неплохо смотрятся, но очень уж тяжело это все. Да и без картинок это будет выглядеть не совсем красиво.
ЗЫ: Кстати, на этом же блоге живет удивительный крысомамонт(замена RSS :) ). Улыбнуло.
Мониторинг состояния системы
Откуда вы обычно узнаете что ваша система не работает? От разгневаных клиентов? Или от неменее разгневаного руководства?
А как вы узнаете о причине неполадки? Используя собственный опыт и знание системы? Или долго и продолжительно изучаете логи, выискиваете ошибку, определяете причины?
А может не стоит дожидаться когда пользователь наткнется на отказ системы? Может этот процесс можно автоматизировать?
Только представьте, некоторая служба, регулярно проверяющая работоспособность системы(или нескольких систем). Она отслеживает работоспособность основных элементов системы (база, подключение, доступность, основной функционал), автоматически исправляет некоторые ошибки, и выдает подробный удобочитаемый сводный отчет о состоянии системы в целом и ее элементов.
И так, что требуется от службы мониторинга:
- Иметь базовый набор тестовых методов для проверки базового функционала системы(здесь очень пригодятся автоматические тесты, написанные на этапе разработки или тестирования)
- Уметь запускать мониторинг состояния системы в определенное время, проверять базовый функционал, логи и т.д.
- Уметь формировать сводный отчет и отправлять его ответственному(администратору или разработчику)
- Уметь устранять некоторые неисправности(например, перезапускать веб-сервер)
- Жестко связана с обследуемой системой.
- Низкая гибкость, малая универсальность. Для каждой новой функциональности нужно писать свой метод для его мониторинга.
- Большие накладные расходы на полный мониторинг(трафик, время, загрузка сервера).
- Использовать автоматические тесты, созданные на этапе разработки или тестирования.
- Проводить мониторинг эпизодически (по требованию) для устранения неполадок.
вторник, 4 марта 2008 г.
Веб-сервисы. Xml серелизация COM объектов.
Решение проблемы может быть одним из следующих:
- Выдирать из класса необходимые данные и записывать в свою структуру данных, которая уже будет серелизоваться. Достоинства: можно просто управлять серелизацией класса, можно также манипулировать полученными данными в классе, можно сделать свою систему хэширования данных на основе данных структур данных. Недостатки: необходим механизм преобразования COM класса в нашу структуру данных, причем такой механизм необходимо организовывать для каждого класса, сам же механизм представляет из себя лишь перенос данных из полей COM объекта в поля данных нашего класса.
- Организовать "универсальный" механизм серелизации необходимых нам COM классов в виде, скажем, фабрики. Достоинства: общий механизм для серелизации, нет накладных расходов на хранение "промежуточных" классов с данными - вся работа ведется непосредственно через COM. Недостатки: данные 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 настолько хорошо и логично построен что его необходимо копировать?
ЗЫ: Несколько многовато получилось для первого блога, однако прошу меня за это простить, видимо накопилось столько мыслей что высказать их просто необходимо.