буду рад вас приветствовать на новом своем новом сайте http://willson.ru

поскольку сессия близится к концу, а у меня уже куча набросков – скоро будет просто шквал новых и интересных статей ;-) увидимся там!

Скажите, ведь многие привыкли отправлять сообщения по Ctrl+Enter в аське?

Ну почему бы не сделать в форумных движках отправку сообщений по Ctrl+Enter ведь это так легко!

<script type="text/javascript">
function ctrlEnter(event, formElem)
    {
    if((event.ctrlKey) && ((event.keyCode == 0xA)||(event.keyCode == 0xD)))
        {
        formElem.submit.click();
        }
    }
</script>
<form action="send.php" method="post" onkeypress="ctrlEnter(event, this);">...</form>

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

О каких факторах может идти речь? Что может помешать народу перебраться на веб-аналоги и эти программы будут основными? В поисках ответов на эти вопросы я провел 2 дня, и тут представлен результат размышлений. Почему то аналогия возникла с уровневой моделью OSI.

Без решения вопросов на каждом из уровней, достижение полного перехода на новый уровень веб, по моему мнению, невозможно. К сожалению, у меня не получилось абстрагировать каждый вопрос и привязать по конкретному уровню. Но все же это не докторская диссертация и не научная работа, а всего лишь мысли, которыми я делюсь с вами, дорогие читатели ;) Итак, представлю эту модель: она состоит из 6 уровней.

Физический уровень

До боли простые и понятные вопросы: канал передачи данных, хватит ли на полностью используемого канала витой пары? Массово переходить на оптоволокно пока что непозволительная роскошь. Возникают сложности в поддержке, в обслуживании. Этот вопрос в принципе должен будет найти решение в любом случае. Возникают в голове мысли по поподу передачи информации через электрические провода и черпать интернет из розетки. Честно говоря, я не слишком компетентен в вопросе предельных нагрузок на этом уровне, но понятно что объемы передаваемой информации постоянно возрастают.

Технический уровень

Вот это уже интереснее. К техническому уровню я отнес вопросы стандартизации. Для того чтобы программы работали одинаково в различных броузерах и различных операционных системах нужно придерживаться единых стандартов в используемых протоколах, используемых инструментах при разработке. Скажем, тот же W3C формирует стандарты «качества», но до сих пор не все броузеры поддерживают эти стандарты в полной мере, а некоторые игнорируют их. Поскольку полной стандартизации добиться вряд ли смогут, то разработчики и дальше будут иметь головную боль, создавая свои приложения 5in1 под разные броузеры.

Прикладной уровень

Ну конечно, броузеры – это программки которые мы открываем, чтоб просматривать интернет странички. Предполагается, что все программки будут доступны на некоторых сайтах, но тут возникает вопрос: является ли протокол http самым удачным при формировании нового поколения веб? Возможно, что нет. Гипертекстовая разметка статична. Без JavaScript не создать динамический сайт, не использующий перегрузки всей странички. Будем использовать Ajax.

Что же касается серверной части программ, то не смотря на растущие мощности процессоров, программы должны быть оптимизированны под сервер, иначе не достичь такой динамики как при использовании персональных программ. Почему при всех своих масштабах google выдает потрясающие скоростные характеристики? Потому что они написали свой веб-сервер, используют С при написании своих приложений, что не может не сказаться на быстродействии.

Социальный уровень

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

Политический уровень

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

Экономический уровень

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

Хм. А ведь это не так уж и плохо: хочешь сохранить людей – обновляй сервис, добавляй новые возможности; не хочешь – полно бесплатных сервисов ничуть не хуже. Вспоминается, что раньше (а может и сейчас есть такое?) были платные электронные почты.

Ну хорошо, пусть это вовсе не проблема, Но тогда у каждого человека не возникает особой необходимости апгрейдить компьютер. Ему нужно гигов 10 оперативы, средненький проц, клава и моник, геймерам добавим видеокарточку. Получаем типичный терминал. В чем смысл покупать новое железо?

Скажите, было интересно? Я вот перечитал все, что написал, и понял, что мои измышления надуманны. Ширина канал и так растет постоянно. Процессоры развиваются, приложения нетеряют свою скорость. Программисты и так пишут приложения под 3(минимально) разных броузера. Люди всё больше привыкают к электронным платежам (терминалы на каждом углу). Уровень безопасности никто никогда не гарантировал (кроме майкрософта конечно же).

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

Возможно придет смена http, какой-нибудь xmtp и будет удобнее строить интерфейсы, добавлять динамику программе. А более проблем и нету. Вот-так. ;)

«Как Microsoft проиграла войну API» – вот так громогласно кричало название статьи Джоэла (http://www.joelonsoftware.com/articles/APIWar.html) от 13го июня 2004 года. Эта почти 15 страничная статья довольно подробно разбирает тонкости и упущения мелкомягких.

В кратце: Джоэл делится своими мыслями по поводу новой объявленной MS версии API WinFX, заточенной под Longhorn с Avalon, которая по сути должна была зачеркнуть опыт работы с win32, и можно было бы забыть об обратной совместимости. Ну как мы знаем, проект Vista видимо претендовал на возведения себя в Longhorn, ведь он как раз таки «работает» с 3д, может даже на авалоновском двиге. Быть может я путаюсь в терминах, что впрочем не важно, ибо на лицо сырой продукт, к которому пока аудитория не совсем готова. А знаете почему? На то есть ряд объективных причин. Не думайте что я «виста»-ненавистник. Я рад что майкрософт выпускает новый продукт, они дают очень много для компьютерного мира, на них ориентируются. Просто жаль что этот продукт на 90% удачен со стороны маркетинга силиконовой долины, и только на 10% со стороны пользователей.

Итак, к чему же мы приходим? Либо мы радостно скупаем «крутые» компы, ставим на них висту, оборудуем систему новым софтом, либо сидим тихо смирно на XP и ждем, что произойдет. А происходит следующее, что из-за неразберихи с апи программисты замечают, что интернет приложения выполняющиеся на сервере вовсе не требовательны к платформе клиента. Они одинаково хорошо исполняются как на виндах так и на всевозможных линуксах, бзд, солярисах и маках. «Вот оно!» – потирая ладошки, обрадовались программисты и начали мигрировать на написание программ для веб. Появляется некто «веб.два.ноль», грозят новой эпохой интернетов!

Вот они «за и против», отмеченные Джоэлом, с точки зрения разработчиков.

Развертывать веб-приложения у пользователя проще, потому что отсутствует процедура инсталляции. Установка веб-приложения заключается в том, чтобы ввести URL в окне адреса броузера. Сегодня я установил новое почтовое приложение google, нажав Alt+D, gmail, ctrl+Enter. Также заначительно меньше проблем совместимости и совместного сущестования с другими приложениями. У всех пользователей вашего продукта оказывается одна и та же его версия, потому не приходится заботиться о поддержке букета прежних версий. Годится любая программная среда, потому что функционировать она должна только на сервере. Ваше приложение автоматически становится доступным практически для любого компьютера на всей планете. Данные ваших клиентов тоже автоматически становятся доступными практически на каждом компьютере.

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

1. Создать быструю программу рисования.

2. Организовать проверку орфографии в реальном времени с подчеркиванием красной волнистой линией.

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

4. Обновить малую часть экрана, модифицированную пользователем без полного цикла обращения к серверу.

5. Создать быстрый управляемый клавишами интерфейс, не требующий мыши.

6. Позволить продолжить работу в отсутствии соединения с интернетом.

«Ха! Ну это же смешно! Какие это проблемы» — скажете вы и будете правы. Все эти проблемы уже давно решены. Тогда почему же нету кучи сервисов, которые могли бы помочь рядовому пользователю работать откуда и где ему угодно, предостовляя полноценные аналоги персональных программ. И тут же мы спотыкаемся об ряд не столь заметных на первый взгляд факторов. (продолжение следует…)

Шлемиль устроился на работу маляром, и должен был наносить разметку посредине дорог. В первый день он взял бочку краски и разметил 300 метров дороги. «Неплохо! – сказал босс. Ты быстро работаешь!» и заплатил ему за день. На следующий день Шлемиль осилил только 150 метров. » Ну что ж, не так здорово, как вчера, но ты все равно быстро работаешь. 150 метров – это не мало», – сказал босс и заплатил ему денежку. Еще через день Шлемиль расчертил 30 метров дороги. «Всего 30 метров!» – рассвирепел босс. – Это никуда не годится. В первый день ты сделал в десять раз больше. Что случилось?»

«Ничего не могу поделать, – говорит Шлемиль. – С каждым днем приходится все дальше и дальше уходить от бочки с краской».

Красочный анекдот. Но вы даже не подозреваете, что ежедневно сталкиваетесь с таким кодом, и мало того такой код пишете! Не верите? А я докажу :-)

void strcat(char* dest, char* src)
{
     while(*dest) dest++;
     while(*dest++ = *src++);
}

Собственно этот код, код strcat, который можно легко найти в книге Кернигана и Ритчи «Язык программирования С», одобренный отцами С, имеет крайне досадную ошибку. При конкатенации двух строк эта функция проходится полностью по исходной строке в поисках ее окончания, а после уже копирует в свой конец вторую строку. Понимаете к чему клоню? Если мы будем соединять 10 строк по десять символов, то каждый раз функции придется пробегать на 10 символов больше. А если таких строк миллион? Невооруженным взглядом видно, что время выполнения функции возрастает. Умные и хитрые программисты сделали так:

char* mystrcat(char* dest, char* src)
{
      while(*dest) dest++;
      while(*dest++ = *src++);
      return --dest;
}

Таким образом функция возвращает обратно позицию последнего символа (не нуля) и с этого места будет продолжать соединение строк. Ура у нас получилось. Решение найдено и количество строк нас больше пугать не будет. Ну кто-то может возразить: «Погнал тут тему! Да С настолько низкоуровнев, что его часто с асмом сравнивают, да и в скомпилированном виде он будет работать в сотни раз быстрее чем любой из интерпретируемых скриптовых языков.» Это правда, но подобный код встречается на каждом шагу. Пусть имеется таблица данных в XML формате:

<?xml tic-tac>
<mylib>
     <book>
          <title>Язык программирования С.</title>
          <author>Керниган & Ритчи</author>
     </book>
     <book>
          <title>Искусство программирования для UNIX</title>
          <author>Рэймонд</author>
     </book>
</mylib>

Вопрос следующий: Как перемещаться от одной записи к другой? Собственно нужно быстренько воспользоваться функциями, которые предоставляет DOM, проанализировать xml файл, ссоздать дерево в памяти, с которым можно будет легко и быстро работать. С парой оговорок: во-первых, большие базы в xml держать не станешь, потому что предполагается. что памяти хватит на всю структуру; во-вторых, именно синтаксический и лексический анализ самого xml-файла будут составлять крайне медленную, если не самую медленную, часть при генерации страницы. Вообщем не задумываясь над «мелочами» мы ваяем свой код, который не есть оптимизированный.

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

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

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

1. Шаблон проектирования Singleton (одиночка).

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

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

<?php
class DataBase {
private function __construct($dsn = null) {
     this->conn = DB::connect($dsn);
}
static public function instance() {
     static $objDB;
     if(!isset($objDB)) {
         $objDB = new DataBase();
     }
     return $objDB;}
}
?>

В кратце поясню этот наглядный пример. Путем объявления функции __construct() – private, мы закрываем доступ к ней извне класса. Единственный способ которым можно создать объект этого класса является статический вызов функции DataBase::instance(), которая в свое время проверит, существует ли объект этого класса, и если несуществует, то создаст новый. Открыл для себя маленький хак :-)

2. Транзакции

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

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

А зачем использовать транзакции? Вижу в этом несколько плюсов:

1. Будем использовать тогда, когда нам крайне важно, чтобы нынешние изменения базы были успешно выполнены, иначе предыдущие изменения не имеют смысла или же даже опасны. Как пример: если в рамках одной функции вносятся изменения в несколько таблиц, то использование транзакции не позволит нарушиться целостности ссылок.
2. Удобно создавать этакие сэйвпоинты, а потом одним махом делать подтверждение или же откат до какой-либо из точек сохранения;
3. И конечно же важное: принцип невмешательства. Если вы все же намудрили при редактировании баз, то это никак не отразится на других пользователях системы, которые работают с этой базой данных, до тех пор пока вы не подтвердите свои ошибочные действия.

Современные версии популярных СУБД такие как MySQL, PostgreSQL, Oracle, MSSQL Server поддерживают транзакции.

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