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

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

МИФ №1: Использование HTTPS — гарантия безопасности сайта

Вроде бы все просто: все данные передаются между сервером и браузером в зашифрованном виде и украсть их «по пути» невозможно. На практике же запросто могут возникать нюансы…

Во-первых сам ключ: в большинстве компаний он просто лежит на жестком диске веб-сервера и доступен если не каждому сотруднику, то каждому системному администратору точно (причем вместе с паролем — перезапускать HTTP-сервера начальству же не положено). Про потенциальный ущерб от попавшего не в те руки SSL-сертификата более-менее серьезной интернет-компании, наверное, рассказывать не стоит — у всех и так хватит воображения.

Решением чаще всего становится использование аппаратных решений (так называемых HSM), соответствующих стандарту FIPS 140-2. Они предотвращают как несанкционированный доступ к ключам, так и любые формы его экспорта в незашифрованном виде (даже при резервном копировании и смене аппаратных модулей).

Вторым моментом, на который стоит обратить внимание, является тот факт, что шифрования трафика защищает только от перехвата данных: вирусы, фишинг и опасный для пользователей код остаются таковыми даже в зашифрованном виде. Если сайт генерирует вредоносные ответы через HTTPS они попадут в браузеры пользователей-жертв еще более безопасно для себя В такой ситуации маршрутизаторы с защитой от вторжения (IDS/IPS) и прочие системы безопасности, основанные на «глубоком анализе пакетов», становятся бессильными, если не настроить дешифрование и повторное шифрование.

Для избежания подобных казусов максимальное внимание стоит уделять работе отдела QA, грамотной настройке всех компонентов инфраструктуры и регулярным проверкам на предмет возможных эксплойтов на сайте.

МИФ №2: SSL сегодня не является значительной статьей расходов серверных вычислительных ресурсов

Если бы это было так, то F5, Juniper, Cisco и прочие не ставили бы такие ценники на свои решения. Да, вычислительные мощности среднестатистического сервера растут не по дням, а по часам, но эти же самые вычислительные ресурсы используются и для взлома сертификатов. Не смотря на то, что на взлом  1024-битного ключа по-прежнему требуются многие годы и неплохие финансовые вложения, NIST рекомендует переходить на более криптостойким решениям (от 2048 бит), так как теоретически подбор 1024-битного ключа сейчас вполне возможен.

Для разгрузки центрального процессора веб-серверов существует два основных пути:

• SSL-акселерация на уровне маршрутизатора (чаще всего от вышеупомянутых вендоров)
• Использование HSM с встроенным криптографическим процессором

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

МИФ №3: Расходы на управление сертификатами не растут с увеличением количества веб-серверов

Вполне очевидно, что чем больше веб-серверов используется, тем больше SSL-сертификатов должно быть установлено. Еще дополнительные SSL-сертификаты возникают и когда используется несколько виртуальных хостов на одном сервере. До до сих пор часто встречаются люди, которые не знают, что веб-сервер не может определить каким ключом расшифровывать запрос, если на одном IP-адресе расположены несколько доменов, использующих SSL.

Чтобы позволить спокойно масштабировать HTTP-уровень веб-приложения, необходимо рано прерывать HTTPS-соединение для определения сервера, где запрос будет собственно обработан. Такую архитектуру намного легче поддерживать, так как нет необходимости конфигурировать абсолютно каждый HTTP-сервер с отдельными IP-адресами для каждого шифруемого поддомена.

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

Заключение

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

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

По традиции напоминаю про подписку на обновления.

Piccolo — это система для распределенных вычислений, использующая новую ориентированную на данные модель программирования для разработки приложений по параллельным вычислениям в памяти в масштабах дата-центров. В отличии от существующих моделей, основывающихся на потоках данных, Piccolo позволяет вычислениям выполняться на различных машинах, при этом имея общее изменяющееся состояния через интерфейс таблиц пар «ключ-значение». Традиционные ориентированные на данные модели (такие как используются в Apache Hadoop) предоставляют пользователю для работы лишь единственный объект в определенный момент времени, когда в Piccolo используется глобальная таблица состояний, одновременно доступная для всех частей вычисления. Это позволяет пользователям указывать алгоритм вычисления в интуитивно-понятной манере, очень похожей на разработку программ для одного компьютера.

Использование хранилища, позволяющего хранить в памяти пары «ключ-значение», сильно отличается от канонического подхода map-reduce, который основан на распределенных файловых системах. Результаты впечатляют:

Эксперименты показали, что Piccolo очень быстр и отличные возможности по масштабируемости для многих прикладных задач. Производительность вычисления PageRank и k-средних выросла в 11 и 4 раза, соответственно, по сравнению с Hadoop. Вычисление PageRank для связанного графа из 1 миллиарда страниц заняло лишь 70 секунд на 100 машинах в Amazon EC2. Распределенная система по скачиванию веб-страниц легко может полностью загрузить 100Мбит интернет-канал при работе на 12 машинах.

Проект реализован в виде библиотеки для Python и C++. Более детально примеры использования и принципы работы системы разбираются в источниках информации (правда на английском), не поленитесь — загляните. Вместо заключения хотелось бы по традиции порекомендовать подписаться на RSS блога, если Вы еще этого не сделали.

Источники информации

• Russell Power — автор проекта Piccolo
• Piccolo: Building Fast, Distributed Programs with Partitioned Tables

• Проект был презентован на OSDI10: презентация и видео

Для начала хочу вкратце пересказать саму статью. Написана она по мотивам мнений различных экспертов в области разработки, в частности Objects Have Failed by Richard P. Gabriel, November 6, 2002 и holywar’а на конференции OOPSLA с участием именитых специалистов. Аргументы у обоих сторон «за и против»  были довольно странноватыми и по сути были подтверждениями и опровержениями различных мифов об ООП, например о том, что с использованием парадигмы ООП разработка идет быстрее/проще/понятнее/удобнее, что ОО языки программирования не соответствуют требованиям вычислительных процессов будущего и не адекватно отражают предметную область, что повторное использование кода есть в любом языке программирование — как минимум в виде библиотек. Сторонники ООП же в основном настаивают на справедливости мифов и твердо отстаивают три основных столпа их парадигмы. На вышеупомянутой конференции по мнению аудитории вверх взяла сторона «против ООП» из-за натиска сторонников языка Lisp и растерянности сторонников ООП касательно своей же теории.

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

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

Когда речь идет о разработке крупной корпоративной системы с большим количеством пользователей и разнородной информации, на первый план выходят чаще всего масштабируемость и сроки реализации, а вовсе не производительность и эффективность алгоритмов. В таких системах разработка выглядит скорее как склейка требуемого продукта из различных готовых компонентов, чем реализация собственных алгоритмов и оптимизация производительности. Для подобных проектов чаще более уместен объектно-ориентированный подход с использованием широкого спектра готовых классов, библиотек и системных компонентов. Да, в данном случае пострадает производительность, но купить несколько дополнительных серверов дешевле, чем изобретать велосипед и писать с нуля реализацию всех необходимых составных частей системы.

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

Плюс не стоит забывать и о том, какие люди участвуют в разработке: бывают разработчики, которые фанатеют от ООП, всю жизнь занимаются «сборкой» проектов из библиотек на Java или C#, являются ярыми поклонниками TDD и Agile-разработки, а бывают разработчики, которые предпочитают Assembler/C/Fortran/Cobol/Lisp/Haskell/Erlang (нужное подчеркнуть), любят реализовывать очень сложные  алгоритмы, оптимизировать их, добиваясь выиграша в несколько миллисекунд во времени или пару килобайт в использованной оперативной памяти. Естественно это лишь крайние или почти крайние случаи, большинство разработчиков скорее всего находятся где-то посередине (к сожалению, у меня нет такой статистики), предпочитая универсальные языки программирования, на которых можно писать код как объектно-ориентированно, так и нет (C++/Python/PHP/etc). Хочется порекомендовать руководителям не заставлять имеющихся в наличии людей заниматься тем, что им не по душе, просто так как Вам кто-то вчера рассказал, что «Ruby on Rails — это круто» или так как во-о-он тот известный проект реализован с использованием во-он тех технологий, языков программирования или парадигм разработки. Используемые технологии и подходы к написанию кода, должны соответствовать поставленным задачам, а команда должна быть готова реализовать проект именно так, как это необходимо, при этом очень большое значение имеет распределение ролей между разработчиками — чтобы каждый занимался своим любимым делом.

Коллеги, копайте ямы лопатами и забивайте гвозди молотками, а не наоборот

Хотя да, достаточно давно уже Google выпустили в свет платформу Google App Engine. Описание этого продукта меня заинтересовало еще до открытия публичного доступа к системе и я даже записался на полу-закрытое тестирование. Вскоре пришло подтверждение, что мол «мы рады сообщить, что Ваша учетная запись активирована и теперь у Вас есть возможность попробовать наш новый продукт, для этого нажмите ссылку такую-то». Но пришло оно как-то не очень удачно, когда ни лишнего свободного времени не было, да и идеи подходящей для создания чего-нибудь эдакого на новой платформе тоже на горизонте не наблюдалось. В общем зашел на их сайт, посмотрел админку, поставил демо-приложение, поигрался чуток и забросил. Но с тех пор руки так и не прекращали чесаться от желания попробовать GAE на каком-нибудь более приближенном к реальности приложении, что мне совсем недавно и довелось сделать. Спешу поделиться впечатлениями.

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

Если взглянуть издалека, то GAE представляет собой условно-бесплатный хостинг для веб-приложений, для разработчиков предоставляется все необходимое: начиная от минимально-необходимого SDK со встроенным веб-сервером, локально эмулирующим саму платформу, заканчивая неплохой документацией по самой системе и доступным из нее API от Google. Почему условно-бесплатный? Бесплатно приложениям выделяется лишь ограниченное количество вычислительных ресурсов, при превышении которых по выбору владельца приложения либо взимается вполне скромная плата, либо всем пользователям начинают показывать «извиняйте, заходите завтра» (в прямом смысле, счетчики потребления ресурсов сбрасываются ежедневно).

Но финансовый вопрос далеко не самый интересный, давайте взглянем на техническую сторону медали. Написанное с использованием SDK приложение загружается в production-окружение, которое физически размещается на тех самых известных кластерах Google, о которых у меня даже есть пост (конечно же под GAE используется только очень небольшая часть их вычислительных можностей). Причем все заботы о распределенной работе приложения на большом количестве машин платформа берет на себя: разработчику не нужно думать ни о балансировке нагрузки, ни о партиционировании данных, ни о других аспектах. Сразу же после окончания процессов загрузки и развертывания приложение готово становится готово к работе и доступно по домену третьего уровня на *.appspot.com, либо можно подключить свой отдельный домен.

Технические ограничения тоже имеют быть: для разработки под GAE можно использовать лишь небольшой набор языков программирования, в частности Python 2.5, а также Java и все остальные языки, компилируемые или интерпретируемые под JVM (JRuby, Scala, Rhino, etc.). Все приложения исполняются в песочнице, ограничивающей доступ к окружающему миру, то есть определенные подмножества языков становятся недоступны, например: доступ к файловым системам, встроенные средства обработки изображений, доступ к сторонним ресурсам по HTTP, отправка почты. Про реляционные базы данных, memcached и библиотеки, использующие нативный, платформозависимый код, также стоит забыть. Но не все так плохо, как кажется: для реализации всех «отобранных» у разработчиков функциональных компонент Google предоставляет собственные сервисы-заменители, доступные через хорошо документированный API или вовсе замаскированные под стандартные методы языка. В качестве дополнительных бонусов предоставляются и возможности по интеграции с другими продуктами Google, скажем можно легко сделать авторизацию пользователей в приложении по учетным записям от GMail или нотификацию пользователей по Jabber через GTalk.

Отдельного внимания заслуживает используемая в данной платформе система хранения данных, основанная на BigTable, о которой более подробно можно почитать в уже упомянутом посте об архитектуре Google. Если в двух словах, то она представляет собой распределенное нереляционное хранилище данных, автоматически обеспечивающее репликацию и кеширование данных, а также практически гарантирующее постоянную доступность данных вне зависимости от сбоев низлежащего оборудования. Для доступа к нему разработчикам предоставляется специальный API и язык доступа к данным GQL, слегка напоминающий упрощенный диалект SQL (лишь отдаленно). Продукт в обращении достаточно своеобразен, как оказалось самый простой способ привыкнуть к работе с ним — выкинуть из головы все знания о традиционных СУБД и взглянуть на процесс хранения данных с чистого листа. Разномастные JOIN’ы и прочие изыски лишь мешают думать в терминах подобных систем.

Закончив тему с рекламой GAE, позвольте перейти к моим личным впечатлениям. Попробовал я данную платформу на вполне конкретном примере (в конце поста дам ссылочку на частично-готовый результат, если кому интересно), надо же в конце-концов на что-то с пользой убивать внезапно появившееся свободное время. ОтJava и прочей компании языков, основанных на JVM, я невероятно устал на теперь уже «прошлой» работе, так что взор мой упал на Python и давно находящийся у меня на слуху (в основном благодаря Ивану Сагалаеву) фреймворк Django. Ни с тем, ни с другим я ранее почти не был знаком на практике, разве что когда-то пытался помогать своим очень хорошим подругам с прохождением Python в университете (пользуясь случаем, передаю привет Полине, Кате и Юле, очень по вам скучаю ). Стоит упомянуть, что существует несколько сборок Django, адаптированных под GAE, наиболее продуманным и готовым к эксплуатации мне показался проект под названием app engine patch, которым я и воспользовался для экспериментов.

Django, как известно, является вполне традиционным веб-фрейморком, пропагандирующим свою вариацию на тему MVC (именуемую MVT — Model-View-Template, но по сути абсолютно то же самое), а также целый ряд философских верований (вроде DRY, Don’t repeat yourself), которым даже отведена отдельная страница на официальном сайте. Адаптированная под GAE версия фреймворка отличается от стандартной по большому счету лишь замененной частью Model, в которую очень неплохо вписался предоставляемый API к уже упоминавшемуся хранилищу данных. По всем остальным компонентам системы официальная документация по Django практически полностью актуальна и сильно помогла понять всю картину разработки веб-приложений с использованием данных технологий.

Пересказывать функциональные возможности Django как-то не входило в мои планы, все кому интересно и так уже в курсе или знают где посмотреть. Хочу лишь сказать, что со своей задачей упрощения и ускорения процесса разработки веб-приложений он полностью справляется: все основные функциональные компоненты реализуются просто, легко и быстро, при этом особой необходимости (да и желания) вникать в то, как оно в итоге работает не возникает. Если же взглянуть на Django в совокупности с возможностями GAE — вопросы масштабируемости также по большей части с плеч разработчика снимаются (если не забыть прочитать документацию по хранилищу и не творить глупостей). В общем что-что, а количество человекочасов, требуемых на создание качественного масштабируемого веб-приложения, эта парочка способна сократить изрядно.

Предложение Google по использованию платформы GAE выглядит очень заманчиво, не смотря на все ограничения под нее можно как портировать существующие приложения, так и легко создавать новые. Бесплатное использование до превышения квот также не может не радовать (кстати квоты там рассчитаны на мировой рынок, превысить большинство из них в рамках рунета — надо постараться, мне кажется). Но закончить данное повествование мне всетаки хотелось парой недокументированных или вкратце официально упоминавшихся «ложек дегтя». Первая неприятная особенность: процессы, обрабатывающие пользовательские запросы приложений, умирают после очень небольшого времени простоя (таймаут судя по всему секунд 20-30). По истечении таймаута система освобождает использующиеся приложением ресурсы и когда после перерыва приходит очередной пользователь система вынуждена заново инициализироваться (чуть ли не заново компилировать байткод, хотя не уверен), что занимает около 5 секунд, а то и больше, во время которых пользователю ничего не остается кроме как терпеливо ждать. Сделали данный механизм видимо в связи с тем фактом, что подавляющее большинство развернутых приложений были сделаны просто чтобы побаловаться и были сразу же заброшены, что делает неэффективным постоянное держание в готовом состоянии даже одного процесса для каждого приложения. Таким образом использование GAE для тяжелых веб-приложений с небольшой целевой аудиторией не очень эффективно.  Минус второй: существуют некоторые жесткие ограничения, которые не разрешают увеличивать даже за деньги (по крайней мере расценок не видно). В их число входят максимальное время обработки одного запроса (30 секунд, правда не ясно распространяется ли это на выполнение задач в Task Queue и местном аналоге Cron’а), 30 активных процессов, обрабатывающих запросы приложения (что влечет за собой достаточно жесткое ограничение на количество запросов в секунду в районе нескольких сотен), максимальный размер HTTP запроса/ответа в 10 мегабайт и некоторые другие. В итоге «тяжелые» вычисления на GAE не погоняешь (хотя есть варианты с применением AJAX и, соответственно, большого количества запросов к GAE), от Digg-эффекта или DDOS’а есть шанс не уберечься, хостинг файлов не соорудить, но… разве это ограничения? Есть масса более интересных типов веб-приложений, способных прекрасно существовать в такой среде. Да и в крайнем случае всегда можно связаться с представителями Google с просьбой в виде исключение для Вашего приложения, судя по их заявлениям все ограничения носят искусственный характер и служат лишь для защиты от потребления неоправданно большого количества вычислительных ресурсов плохо спроектированных приложениями.

Этот пост написан по мотивам истории сайта CargoBook, который задумывался как сообщество для логистов, с плавным выходом на корпоративный рынок с продуктом в виде логистической информационной системы, предоставляемой по принципу SaaS. Сходив по ссылке можно заценить, что можно сделать средствами сладкой парочки Django+GAE и одного студента с почти гуманитарным образованием за часов эдак 20 работы в свободное время. Сейчас в задумке кроме меня участвует всего еще один человек: на правах автора идеи, но  если Вас заинтересовал данный проект и может быть Вы хотите присоединиться в каком-либо амплуа — пишите об этом в комментариях или по другим контактным данным.

Кстати в американской части Интернета о GAE ходят в основном негативные мнения, мол тормозит, большое время отклика, сплошные таймауты и ошибки. На практике пока не удалось столкнуться с чем-то подобным, но реально работающего приложения с активной пользовательской базой у меня пока нет для того, чтобы делать какие-то относительно объективные выводы. Может быть со временем что-нибудь изменится и более тонкие нюансы станут выползать на поверхность — время покажет. Как раз будет повод написать еще один пост на эту же тему

Итак, пара слов о предмете разговора. memcached — это распределенная система кэширования объектов в оперативной памяти. Разрабатывается фирмой Danga Interactive (кстати, они являются авторами не только memcached, но и других интересных проектов). Но о них, возможно, в следующий раз. Обычно memcached используется приложениями для временного хранения данных, которые надо часто читать. Приложения не взаимодействуют (обычно) напрямую с сервером memcached, а работают при помощи клиентских библиотек. На настоящее время созданы библиотеки для многих языков программирования (а для некоторых еще и по нескольку альтернативных)  — полный список клиентских библиотек доступен на wiki проекта. В целом, данная схема похожа на работу с БД, знакомую многим разработчикам.

Будем рассматривать установку и использование memcached для Linux. Так же при рассмотрении примеров на PHP и обзоре кэширования сессий потребуются PHP и Apache. Возможно, их придется установить, но мы не будем заострять внимание на вопросах установки.

Сервер memcached

Давайте приступим к установке memcached. Практически во всех дистрибутивах Linux memcached можно установить из репозитариев. Если есть желание собрать самую свежую версию, то можно заглянуть на сайт разработчика (на момент написания этих строк последняя версия — 1.4.0).
Также, возможно, понадобится установить libevent. Последняя стабильная версия — 1.4.11

Собираем, устанавливаем и запускаем memcached в режиме вывода сообщений. Интересно же посмотреть, что с ним происходит:

memcached -vv

Процесс запускается и ждет подключений (по умолчанию на порту 11211). Серверная часть готова обрабатывать подключения клиентов и кэшировать полученные данные.

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

Клиенты memcached

Из всего многообразия клиентских библиотек рассмотрим две:

• libmemcached (для Си);
• PECL extension для PHP (построенный на базе предыдущей библиотеки).

Си

Библиотека libmemcached на данный момент активно развивается и представляется наиболее подходящим выбором при работе с Си и PHP. Также, в комплекте с самой клиентской библиотекой поставляются дополнительные утилиты для работы с memcached, позволяющие просматривать, устанавливать, удалять значения в кэше memcached. Кстати, удивляет, что набор утилит идет не с серверной частью, а с клиентской библиотекой.

Итак, приступим к установке libmemcached. На момент написания этих строк текущая версия libmemcached — 0.31. Компилируем, устанавливаем. Для начала, наслаждаемся чтением страниц man:

man libmemcached
man libmemcached_examples

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

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

• memstat — выдает информацию о сервере memcached
• memcat — выдает значение по ключу
• memrm — удаляет значение по ключу
• memdump — выдает список ключей

Для начала посмотрим, что скажет сервер memcached, запущенный нами немного ранее в режиме выдачи сообщений. Запросим статистику сервера при помощи утилиты memstat:

memstat --servers localhost

 Listing 1 Server
 Server: localhost (11211)
 pid: 14534
  uptime: 1950
 time: 1247390264
 version: 1.4.0
 pointer_size: 32
 rusage_user: 0.0
 rusage_system: 0.0
 curr_items: 0
 total_items: 0
 bytes: 0
 curr_connections: 10
 total_connections: 11
 connection_structures: 11
 cmd_get: 0
 cmd_set: 0
 get_hits: 0
 get_misses: 0
 evictions: 0
 bytes_read: 0
 bytes_written: 0
 limit_maxbytes: 67108864
 threads: 5

Получили статистику — следовательно memcached функционирует и откликается на запросы.

Итак, на настоящий момент готовы к использованию сервер memcached и клиентская библиотека. Осталось дело за малым — внедрить использование memcached в разрабатываемое приложение. Что касается приложения — все в руках разработчиков, а мы рассмотрим небольшой пример работы с базовыми функциями.

memcached предоставляет следующий набор основных функций (их, конечно, больше, но здесь приведены основные):

• set - занести в кэш пару ключ-значение
• add - занести в кэш значение при условии, что значения с таким ключом в кэше еще нет
• replace — обновляет кэш при условии, что значение с таким ключом в кэше уже есть
• get — получает значение из кэша по указанному ключу

Пример программы на C

Файл mc.c

#include "stdio.h"
#include "string.h"
#include "memcached.h"

int main( void )
{
	char *key = "key";
	char *value = "value";
	uint32_t flags = 0;
	size_t length = 0;
	char *value2 = NULL;
	memcached_return rc;

	// 1. создать структуру для работы с кэшем
	memcached_st *memc = memcached_create(NULL);

	// 2. указать сервер с которым будем работать
	memcached_server_add(memc,"localhost",11211);

	// 3. занести пару ключ-значение в кэш
	rc = memcached_set(memc, key, strlen(key), value, strlen(value)+1, (time_t)0, flags);

	if (rc == MEMCACHED_SUCCESS) {
	} else {
		// обработать ошибку
	}

	// 4. получить значение
	value2 = memcached_get (memc, key, strlen(key),     & length, & flags, & rc);
	if (rc == MEMCACHED_SUCCESS) {
		printf("%s\n", value2);
		free(value2);
	} else {
		// обработать ошибку
	}

	// 5. высвободить структуру
	memcached_free(memc);
	return 0;
}

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

Компилируем, возможно придется явно указать пути к библиотекам:

gcc -Wall -o mc mc.c -I/usr/local/include/libmemcached/ -lmemcached

Запускаем:

./mc
 value

Видим требуемое значение — должно быть, заработало!

Для уточнения деталей, смотрим сообщения на сервере memcached:

<32 new auto-negotiating client connection
32: Client using the ascii protocol
32 STORED
32 sending key key
>32 END
<32 quit
<32 connection closed.

В данном примере представлены следующие события: подключение клиента, установка пары ключ-значение, чтение данных по ключу и отключение клиента.

Посмотрим статистику на сервере:

memstat --servers localhost
 Listing 1 Server
 Server: localhost (11211)
 pid: 14534
 uptime: 4659
 time: 1247392973
 version: 1.4.0
 pointer_size: 32
 rusage_user: 0.0
 rusage_system: 0.0
 curr_items: 1
 total_items: 1
 bytes: 58
 curr_connections: 10
 total_connections: 13
 connection_structures: 11
 cmd_get: 1
 cmd_set: 1
 get_hits: 1
 get_misses: 0
 evictions: 0
 bytes_read: 58
 bytes_written: 58
 limit_maxbytes: 67108864
 threads: 5

Следующие две строчки показывают, что в кэше появилось значение:

curr_items: 1
total_items: 1

Посмотрим на данное значение:

memcat --servers localhost key
 value

Итак, приложение, использующее memcached — готово.

PHP

Для начала установим PECL extension для PHP — memcached

pecl install memcached

На этом этапе возможно появление сообщения об ошибке вида:

ERROR: 'phpize' failed

Это означает, что не установлен пакет php-dev или его аналог. Устанавливаем его и можно пробовать снова:

pecl install memcached
 install ok: channel://pecl.php.net/memcached-1.0.0
 You should add "extension=memcached.so" to php.ini

Как нам и советуют, дописываем extension=memcached.so в php.ini и перезапускаем Apache.

Смотрим информацию об используемом PHP:

memcached support  enabled
Version  1.0.0
libmemcached version    0.31
Session support    yes
igbinary support   no

Пример программы на PHP

Можно смело использовать обращения к memcached из PHP. Как обычно, рассмотрим пример:

<?php
$m = new Memcached();

$m->addServer('localhost', 11211);
$m->set('phpkey', 'phpvalue');
var_dump( $m->get('phpkey'));
?>

Результат работы данного скрипта:

string(8)  "phpvalue"

Итак, PHP-приложение, использующее memcached — готово.

Кэширование данных сессий

Memcached можно использовать и как хранилище данных сессий для PHP. Такой подход часто используется в реальных приложениях. Давайте рассмотрим, что для этого надо сделать.

Вносим изменения в php.ini

;session.save_handler = files
session.save_handler = memcached

;session.save_path = /var/lib/php5
session.save_path = localhost:11211

Параметр session.save_handler указывает, что теперь данные будут храниться в memcached. Второй параметр — session.save_path указывает сервер memcached (их может быть указано несколько, через запятую) на котором будут сохранятся данные.

Перезапускаем Apache — и готово!

Теперь надо проверить, что теперь данные сессии реально хранятся не на диске, а в memcached.

Рассмотрим работу несложного скрипта, заносящего что-нибудь в сессию:

<?php

session_start();
$_SESSION['intval'] = 123;
$_SESSION['strval'] = "qwe";
?>

Запускаем скрипт, он заносит данные в сессию, после чего смотрим на кэш

memdump --servers localhost
 key
 keyphp
 memc.sess.key.3ff8ccab14424082ff83a6dfbcf0941f

Итак — к нашим знакомым по предыдущим примерам ключам, добавился ключ с характерным именем memc.sess.key.3ff8ccab14424082ff83a6dfbcf0941f.

Хранение данных сессии перенесено в систему кэширования. Более подробную информацию по работе с memcached из PHP можно почитать на сайте PHP.

Заключение

Мы рассмотрели утановку и примеры использования memcached. Следует особо подчеркнуть, что memcached — это не система хранения данных, поэтому на практике memcached почти всегда используется в паре с БД. Также следовало бы уделить внимание своевременной инвалидации данных в кэше и вопросам безопасности. В общем, тема интересная, и еще далека от закрытия.

]]> http://www.insight-it.ru/programmirovanie/memcached-na-palcakh/feed/ 10 http://www.insight-it.ru/programmirovanie/java/interfejs/ http://www.insight-it.ru/programmirovanie/java/interfejs/#comments Sun, 04 May 2008 10:41:27 +0000 Иван Блинков http://www.insight-it.ru/?p=71
Наверняка у многих из вас слово «интерфейс» ассоциируется с внешним видом любой программы, то есть кнопочками, виджетами, иконками и прочим ее оформлением. Да, несомненно графический пользовательский интерфейс является одним из значений этого понятия, но существует и масса других!

Хотите узнать больше?

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

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

Уже догадались? Да, это я так неспеша плавно подводил разговор к объектно-ориентированному программированию. Термин интерфейс широко применяется и в нем. Как не трудно предположить, в роли объектов в этом случае выступают как сами классы, так и их экземпляры (которые, впрочем, тоже принято называть словом объект).

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

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

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

Самым наглядным языком программирования для демонстрации описания интерфейсов я считаю Java (хотя можно было бы выбрать и C#, PHP или практически любой другой по вкусу). В теории все просто:

• Ключевое слово interface обозначает описание интерфейса;
• За ним следует название конкретного интерфейса, которое впоследствии можно будет использовать в коде при его упоминании (некоторые программисты на правах традиции начинают названия интерфейсов с заглавной буквы I, мне в свое время даже пытались объяснить зачем так надо делать, но аргументы не показались мне достаточно весомыми);
• Далее идет тело интерфейса, в котором перечисляются все заголовки методов, которые должны быть в классе, реализующем данный интерфейс (никакой реализации!);
• Впоследствии приписав к заголовку любого класса ключевое слово implements с последующим указанием названия интерфейса, можно обязать этот класс реализовать указанные в описания интерфейса методы. Существует небольшое исключение для абстрактных классов (то есть классов,для которых не может быть создан объект, обозначаются ключевым словом abstract), они могут и не реализовать все методы интерфейса, но тогда эта обязанность будет переложена на их наследников.

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

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

На практике же это выглядит это примерно следующим образом:

// описание интерфейса
interface Renderable
{
    // обязуем реализовать метод draw
    public void draw();
}

// конкретная реализация интерфейса
class SomeText implements Renderable
{
   string text;
   public SomeText(string str)
   {
      this.text=str;
   }
   public void draw()
   {
       // вынуждены подчиниться и реализовать
       System.out.println(this.text);
   }
}

// класс-клиент
class Render
{
  public Render(Renderable obj)
  {
     // можно быть уверенным, что
     // метод draw реализован
     obj.draw();
     /*
         в качестве альтернативы можно было бы написать как-то так:
         if(obj instanceof Renderable)obj.draw();
         то есть проверить реализован ли интерфейс
         вместо использования его названия в роли типа данных
     */
  }

В данном примере ситуация тривиальна: класс-клиент Render умеет лишь визуализировать классы, которые он получает в конструктор, вызывая у них метод draw. Для обеспечения такой возможности описан интерфейс Renderable, который реализуется в классе SomeText. Хоть класс Render ничего и не знает о том, какой именно класс ему подсунут, благодаря интерфейсу он сможет вывести на экран любой объект, корректно реализующий наш интерфейс, в том числе и SomeText.

Как я уже упоминал: альтернативой такому подходу является использование полиморфизма и наследования. Такой подход более распространен в других языках программирования, например C++, но пример я приведу все равно на Java, основываясь на предыдущем примере, чтобы читателям было проще сравнивать.

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

// теперь используем абстрактный класс
abstract class Renderable
{
    // реализуем метод draw
    public void draw()
    {
       System.out.println("Вывод на экран недоступен!");
    }
}

// реализация интерфейса (на этот раз неформального)
class SomeText extends Renderable
{
   // на этот раз используем extends (наследование)
   // вместо implements
   string text;
   public SomeText(string str)
   {
      this.text=str;
   }
   public void draw()
   {
       // переопределяем метод draw
       // но могли этого и не делать, тогда
       // использовался бы метод из Renderable
       System.out.println(this.text);
   }
}

// класс-клиент
class Render
{
  public Render(Renderable obj)
  {
     // можно быть уверенным, что
     // метод draw реализован
     obj.draw();
     /*
        на этот раз так как в крайнем случае
        в крайнем случае вызовется хотябы
        метод из класса Renderable
     */
  }

Минимальные изменения — суть та же. Сразу хочу отметить, что этот процесс так прост только в Java, в других языках программирования понадобилось бы использование дополнительных модификаторов для метода draw (например в C#: virtual или abstract в классе-потомке и override в классе-наследнике, это необходимо для обеспечения возможности их переопределения).

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

]]> http://www.insight-it.ru/programmirovanie/java/interfejs/feed/ 9 http://www.insight-it.ru/programmirovanie/design-patterns/ http://www.insight-it.ru/programmirovanie/design-patterns/#comments Thu, 24 Apr 2008 10:03:09 +0000 Иван Блинков http://www.insight-it.ru/programming/design-patterns/ Как говорится, все новое — хорошо забытое старое. Когда я в вдруг вспомнил эту поговорку, мне пришла в голову мысль вернуться к незаслуженно забытой некоторое время назад теме объектно-ориентированного программирования. Возможно многим читателям уже поднадоели часто публикующиеся здесь статьи об устройстве уже существующих проектов, это конечно же не повод прекратить их публикацию, но, тем не менее, немного отвлечься все же стоит.

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

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

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

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

Основной вклад в этот процесс сделала знаменитая команда, известная как Gang of Four. Она состоит из четырех авторов не менее известной книги «Design Patterns — Elements of Reusable Object-Oriented Software»:

• Erich Gamma
• Richard Helm
• Ralph Jonson
• John Vlissides

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

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

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

]]> http://www.insight-it.ru/programmirovanie/design-patterns/feed/ 8 http://www.insight-it.ru/programmirovanie/javascript/comet/ http://www.insight-it.ru/programmirovanie/javascript/comet/#comments Wed, 26 Mar 2008 18:13:04 +0000 Иван Блинков http://www.insight-it.ru/programming/javascript/comet/ Уже приготовились мыть посуду? Что ж, придется Вас разочаровать, сегодня речь пойдет вовсе не о моющем средстве, а об одноименной технологии.

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

Реализация этой технологии, как не сложно догадаться, основывается на JavaScript. Основной идеей является поддержание долговременных HTTP-соединений с каждым клиентом приложения и отправка новых данных клиентам с их помощью как только произошло их обновление или возникновение на сервере. Этот принцип послужил основой для альтернативных названий этой технологии: Server-push, Reverse AJAX. В случае классического AJAX (о котором тоже стоило бы сначала написать статейку, потом может быть соберусь) клиент асинхронно отправляет серверу запрос на получение какой-либо конкретной информации. В Comet же клиент с сервером как бы меняются ролями: инициатором передачи информации является сервер, а не клиент. Что же это меняет? Самым наглядным примером послужит реализация постоянного обновления какой-либо информации в реальном времени:

• Классическая модель отправки запросов. Для решения задачи понадобится постоянно обновлять всю страницу целиком, вручную пользователем или альтернативными способами автоматически. Совсем не вариант, будет генерироваться огромное количество запросов к серверу, каждый из которых будет очень существеннен по объему. Большое количество одновременно работающих пользователей такое приложение явно не выдержит, да и доступность данных в реальном времени не обеспечит.
• AJAX. По сравнению с предыдущим вариантом AJAX предоставляет массу преимуществ: размер передаваемых данных существенно уменьшается, особенно если использовать в качестве формата данных не XML, а JSON. Но тем не менее необходимость регулярно отправлять запросы серверу для получения обновленной информации останется. С ростом количества пользователей будет расти и количество запросов, открытие и закрытие которых будет неуклонно генерировать нагрузку на сервер. Для снижения нагрузки можно попытаться увеличивать интервал между запросами, но это лишь временная мера, обладающая существенным недостатком — увеличение этого промежутка времени повлечет за собой рост задержек между обновлением информации на сервере и обновлением клиентской части приложения.
• Comet. С каждым клиентом поддерживается постоянное HTTP-соединение, как только данные на сервере обновились — сервер сразу же отправляет по уже открытому соединению уведомление о необходимости провести изменения в клиентской части, это позволяет существенно сократить нагрузку на сервер и практически избавиться от задержек между обновлением данных на сервере и клиенте.

Для написания серверной части приложения может использоваться практически любой язык программирования, наиболее распространенным решением, пожалуй, является Java Servlet, запущенный в каком-либо контейнере — Apache TomCat, Jetty или Sun GlassFish. Для реализации этого подхода к организации общения клиента с сервером написано достаточно большое количество framework’ов и библиотек, наиболее полный список, я думаю, можно найти в английской википедии.

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

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

• Создание масштабируемых Comet-приложений с использованием Jetty и Direct Web Remoting
• Asynchronous HTTP and Comet Architecture (eng.)

Я же надеюсь написать статью более практической на направленности по этой теме лишь в обозримом будущем, не пропустить этот момент Вам поможет абонемент.

]]> http://www.insight-it.ru/programmirovanie/javascript/comet/feed/ 19 http://www.insight-it.ru/programmirovanie/php/modifikaciya-algoritma-khehshirovaniya/ http://www.insight-it.ru/programmirovanie/php/modifikaciya-algoritma-khehshirovaniya/#comments Fri, 15 Feb 2008 10:17:20 +0000 Иван Блинков http://www.insight-it.ru/programming/php/modifikaciya-algoritma-khehshirovaniya/ Если Вы уже успели прочитать одну из моих предыдущих записей о хэшировании, то Вы уже имеете базовое представление о теме сегодняшнего разговора.
Одним из возможных способов применения хэшей является хранение аутентификационных данных пользователей интернет-приложения, об особенностях реализации формирования и проверки хэшей при регистрации и авторизации пользователей средствами PHP я и хотел бы с Вами поговорить.

Сомневаюсь, что Вы услышите что-то новое, если я скажу, что в PHP даже в «стандартной комплектации» реализована масса алгоритмов хэширования, начиная с широкораспространенных md5(); и sha1(); и заканчивая модулями hash и mhash, в которых реализована еще целая масса алгоритмов. Все они давно уже стандартизованы и доступны для изучения всем желающим получить о них какую-либо информацию.

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

• Первым делом он бы попытался определить, какой именно хэш перед ним находится — чаще всего это делается либо просто взглянув на длину хэша, либо если приложение широко распространено (популярная CMS скажем) — покопавшись в ее исходниках, еще есть вариант найти свой собственный аккаунт — и зная пароль попробовать на нем разные алгоритмы, способов можно придумать множество — все ограничивается лишь воображением. Узнав ответ на свой вопрос ему лишь останется набрать в Google фразу вроде «md5 decrypt», а дальше уже дело техники.
• Еще один вариант решения задачи — взглянуть на список хэшей на предмет наличия совпадений. С очень высокой степенью вероятности за значительной группой одинаковых хэшей будет скрываться какой-либо банальный пароль вроде 123456.

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

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

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

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

function generateHash($input,$salt = false)
{
  if(!$salt)$salt=randomString(2);
  $hash=md5($input.$salt);
  return $salt.substr($hash,2);
}

Как не трудно заметить — используется самодельная функция randomString();, которая возвращает случайную строку, состоящую из указанного количества шестнадцатеричных цифр (надеюсь Вы в состоянии написать ее своими силами). Именно этот момент и гарантирует элемент случайности при каждой новой генерации хэша. В том месте, где я прочитал про этот механизм (ссылку, к сожалению, привести не могу — в bookmark’ах не нашел), этот случайный компонент назывался словом salt, смысл его заключается в том, что он приписывается ко входным данным, передаваемым стандартной функции хэширования, а затем им же подменяется какая-либо фиксированная часть полученного хэша.
Наверняка у Вас возник вопрос: а как же потом понять, что пользователь ввел верные данные, ведь для тех же исходных данных получится другой хэш и возможности их сравнить не будет? Ответ достаточно прост, его можно было увидеть даже в коде: при повторной инициализации хэша из базы данных достается заранее известная часть хранящегося там хэша, соответствующего конкретному пользователю — тот самый salt, и передается нашей функции. В этом случае в механизме будет использоваться именно он, а не новое случайное значение, и, как следствие, в случае правильности введенных данных на выходе получатся совпадающие хэши. Вот такой вот простенький, но иногда достаточно полезный трюк.

Если Вам понравился этот пост — возможно Вам придутся по душе и остальные записи из этой серии статей, а не пропустить публикацию новых записей Вам может помочь RSS feed.

]]> http://www.insight-it.ru/programmirovanie/php/modifikaciya-algoritma-khehshirovaniya/feed/ 13 http://www.insight-it.ru/programmirovanie/php/na-puti-k-idealu/ http://www.insight-it.ru/programmirovanie/php/na-puti-k-idealu/#comments Thu, 07 Feb 2008 12:39:34 +0000 Иван Блинков http://www.insight-it.ru/programming/php/na-puti-k-idealu/ …или 15 привычек, которые помогут ускорить PHP-приложение

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

Прочитав достаточно солидный объем разного рода документации по PHP, я часто натыкался на статьи и тексты, так или иначе связанные с производительностью PHP-скриптов. Порой в такого рода источниках информации удавалось найти достаточно интересные и неочевидные факты об этом языке программирования, которые не смотря на свою простоту могли дать вполне заметный прирост к производительности итогового приложения. Я почему-то очень серьезно стал относиться к производительности написанных мной скриптов, и довольно часто стал испытывать на практике спорные моменты в реализации, о которых узнавал из Сети или каких-либо других источников, с помощью самописных или opensource benchmark’ов, хотя порой и просто внедряя в реальные приложения. Как ни странно, в большинстве случаев практика подтверждала теорию, и я стал постоянно пользоваться этими простыми правилами, о которых я и хочу Вам рассказать.

Повышения значения индекса с помощью ++$i;

Этот факт был наверное одним из самых удивительных для меня, когда я впервые о нем услышал, но действительно операция ++$i; выполняется несколько быстрее, чем $i++;. или другие вариации на ту же тему вроде $i+=1;. Привычка использовать в качестве индекса цикла переменную под названием i, казалось бы стара как Мир, мне она досталась в наследство от C, а в месте с ней «в комплекте» шла привычка писать выражение i++ в заголовках циклов. Разница в скорости обработки этих выражений, насколько мне известно, обусловлена разным количеством элементарных машинных операций, которые необходимо выполнить процессору (в точных цифрах не уверен, пишу по памяти, но ++$i; требует трех элементарных операций, а $i++; – четырех). В справедливости этого факта не трудно убедиться, достаточно написать простенький скрипт, состоящий из цикла с достаточно большим количеством итераций, и замерить любым способом точное время его выполнения при использовании разных способов инкрементации индекса цикла.

Вывод статического контента без помощи PHP

Сейчас тот факт, что использование интерпретатора PHP для вывода статического контента сильно замедляет этот процесс, кажется мне очевидным, но поначалу я использовал echo там, где он был необходим, ничуть не чаще, чем там, где он лишь замедляет работу скрипта. От использования еще менее эффективного способа — print, меня избавила моя лень: писать каждый раз на одну букву больше дико не хотелось (в отличии от echo, print возвращает информацию об успешности выполнения своей работы, что в большинстве случаев просто-напросто не нужно). Проверить опять же не трудно — нужен лишь объемистый текстовый файл, который достаточно вывести в browser разными способами и засечь уходящее на это время.

Вывод статического контента из отдельного файла

Частенько при желании выполнить указанное в заголовке действие по привычке используют include, require или их _once версии, что является далеко не самой лучшей идеей с точки зрения производительности. Самым быстрыми быстрыми и экономичными поотношению к оперативной памяти являются функции readfile и fpassthru. В качестве доказательства этого факта приведу таблицу, демонстрирующую статистику выполнения этой операции различными методами и позаимствованную с одного англоязычного сайта:

Функция	Время (сек.)		Оперативная память (байт)
	32Kb файл	1Mb файл	32Kb файл	1Mb файл
file_get_contents	0.00152	0.00564	52480	1067856
fpassthru	0.00117	0.00184	20016	20032
fgets	0.00195	0.07190	30760	30768
file	0.00157	0.06464	87344	2185624
require_once	0.00225	0.08065	67992	2067696
readfile	0.00117	0.00191	19192	19208

Вывод переменных

Наверняка вам известно, что переменные можно выводить с помощью конструкции вроде echo «$var text»;, что является одним из самых удобных вариантов решения этой задачи благодаря минимальному количеству символов, которые необходимо набрать, но с точки зрения быстродействия этот вариант далек от идеала, так как влечет за собой достаточно серьезные преобразования в памяти сервера, эффект которых порой бывает заметен невооруженным глазом. Частично ущерб производительности можно сгладить заменой этой конструкции на echo $var.» text»;, что приводит к несколькому усложнению внешнего вида кода и несколько поправляет ситуацию со скоростью выполнения. Но как известно знак . обозначает конкатенацию двух строк, что тоже требует некоторых вычислений и затрат памяти, но и от нее можно избавиться, заменив на запятую. Выражение echo $var,» text»; ничем по своему эффекту не отличается от предложенных ранее вариантов, за исключением максимального быстрого выполнения, обусловленного отсутствием дополнительных преобразований в процессе передачи просто последовательности из константы и переменной.

Избегайте выполнения лишних действий

Достаточно абстрактное утверждение, но тем не мение постоянное напоминание себе о нем может избавить Вас от совершения массы ошибок. Самой широкораспространенной является наверное вызов какой-либо функции (чаще всего count(); или strlen();) в проверке условия выхода из цикла. Когда-нибудь доводилось писать видеть в собственном или чужом коде выражение вида for($i = 0; $i < count($array); ++$i) { … }? А задумываться о последовательности выполнения действий при его обработке? Стоит только немного начать размышлять и ошибка становится очевидной: count(); выполняется при каждой итерации цикла, что приводит к подсчету количества элементов массива при каждой проверки условия выхода из цикла — почему бы не посчитать это значение заранее и сравнивать значения индекса с переменной, а не с результатом выполнения функции?

@

Использование этого оператора стоит избегать при каждой возможности. Казалось бы такое простое действие, как сокрытие вывода возможного сообщения об ошибке, влечет за собой достаточно трудоемкую последовательность действий: устанавливает значение параметра PHP-интерпретатора error_reporting = 0, выполняет указанное за этим оператором действие, возвращает значение error_reporting в исходное состояние.

Маленькие мелочи

Развивая тему предыдущего подраздела, хочется обратить внимания, что даже на еще более элементарных вещах можно сэкономить драгоценное процессорное время:

• Вместо условия if($variableOne == $variableTwo) { … } можно написать if($variableOne === $variableTwo) { … }, что избавит от проверки на соответствие типов данных и приведения их друг к другу, в некоторых случаях эти действия эти случаях эти действия конечно же и бывают необходимы, но бывает это далеко не часто.
• Глядя на выражения вроде if($boolean == true) { … }, я чаще всего вспоминаю цитату из одного малоизвестного интернет-ресурса: if (b.ToString().length < 5) { … }. Хоть и не имет никакого отношения к PHP, но суть проблемы отражает очень ярко.
• Самым очевидным способом проверить попадает ли длина строки в какой-либо диапазон является использование функции strlen(); и сравнение полученного результата с фиксированными значениями, но зачем выполнять лишний вызов функции, если можно воспользоваться услугами конструкцией языка PHP isset(); для определения наличия в строке определенных символов. if(isset($str{5})) { … } приведет к абсолютно тем же результатам, что и if(strlen($str)>4){ … }
• Битовые операции выполняются намного быстрее относительно обычных арифметических действий. Об этом факте редко вспоминают, да и работать с ними умеет далеко не каждый, но порой они бывают очень актуальны, особенно при частой работе с числами кратными двойке.
• Угадайте, что делает интерпретатор при виде надписи 1/2? Правильно: делит 1 на 2. Зачем лишний раз утруждать его, когда можно написать просто половину — 0.5.
• При возвращении значения переменной из функции при помощи global выполняется на порядок больше действий, чем при классическом return.
• Конечно же фраза $array[text]; интерпритируется практически точно так же, как и $array['text'];, но зачем выполнять лишнее преобразование из необъявленной константы в строку, проверять, что такой константы все же не существует, выводить сообщение типа E_NOTICE, если можно всего этого не делать?
• По возможности не используйте require_once(); или include_once(); неоднократно по отношению к одному и тому же файлу. При отсутствии какого-либо эффекта, попусту тратится время на обработку повторного запроса.
• Даже «безобидных» ошибок стоит избегать, лишняя проаерка потратит не так много процессорного времени, как генерирование достаточно длинного сообщения об ошибке и вывод его в stdout, stderr или лог-файл, а также не стоит забывать, что даже «безобидные» ошибки могут стать потенциальной угрозой безопасности приложения вцелом.

В заключении…

…хотелось бы упомянуть одну из первых статей по оптимизации PHP, которые мне доводилось читать, до сих пор храню ссылку на нее в bookmark’ах, именно она и выступала в роли одного из основных источников информации для этого текста. В качестве возможных вариантов продолжения чтения про PHP хотелось бы предложить Вам соответствующие раздел сайта, серию статей, тэг и RSS-ленту.

]]> http://www.insight-it.ru/programmirovanie/php/na-puti-k-idealu/feed/ 32 http://www.insight-it.ru/programmirovanie/kriptografiya/obratnogo-puti-net/ http://www.insight-it.ru/programmirovanie/kriptografiya/obratnogo-puti-net/#comments Fri, 01 Feb 2008 12:43:17 +0000 Иван Блинков http://www.insight-it.ru/science/kriptografiya/obratnogo-puti-net/ …или введение в хэширование

Под таким неоднозначным заголовком я решил разместить всеголишь повествование о такой неотъемлимой части криптографии как hash-функции и алгоритмы.

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

Введение

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

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

Свойства

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

Устойчивость к коллизиям

Коллизия

– пара различных прообразов, для которых значение хэша совпадает.

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

Если взглянуть на это свойство с точки зрения обычного образованного человека, то нетрудно заметить, что возможных вариантов исходных данных практически бесконечное количество, а возможных хэшей — лишь 2 в степени фиксированной длины хэша. Из чего было бы логичным сделать вывод о том, что такие пары существуют. Но, как ни странно для всех криптографических алгоритмов, такие пары все еще кем-либо не найдены.

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

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

В научной литературе принята своеобразная классификация алгоритмов хэширования по устойчивости к обнаружению коллизий типов:

Первый тип

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

Второй тип

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

Однонаправленность

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

Кардинальное изменение хэша при незначительном изменении оригинала

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

Применение

На практике криптографические хэширующие функции имеет несколько вариантов применения, вот основные из них:

• Хранение аутентификационных данных пользователей сайтов или программных продуктов. В случае чисто теоретически возможной ошибки программистов или каких-либо других людей или просто имея доступ к базе данных на том или ином основании, потенциальный злоумышленник может получить доступ к закрытым компонентам того или иного проекта, в том числе и к базе данных пользователей. Если такого рода данные хранились бы в открытом виде, он получил бы полный доступ ко всем учетным записям пользователей. Для избежания возможности возникновения подобной ситуации принято хранить не сами логин и пароль пользователей, а их хэши. В этом случае для аутентификации введенные пользователем данные пропускаются через тот же алгоритм хэширования и полученный хэш сравнивается с хранящимся в БД.
• Проверка целостности копии данных. Чаще всего этот способ проверки соответствия копии оригиналу используется в отсутствии доступа к оригиналу. В качестве примера можно привести передачу больших объемов информации через ненадежное пространство (чаще всего Интернет), многие файловые серверы хранят рядом с большими файлами вычисленные от них хэши с использованием популярных алгоритмов, посетитель, скачав файл, может убедиться в его соответствии оригиналу, просто вычислив такой же хэш от копии и сравнив с доступным хэшем от оригинала. Но такой же принцип может использоваться и при доступном оригинале, например, многие программы для прожига образов на компакт-диски используют схожий принцип для проверки соответствия полученного диска образу.

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

Заключение

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

]]> http://www.insight-it.ru/programmirovanie/kriptografiya/obratnogo-puti-net/feed/ 9 http://www.insight-it.ru/programmirovanie/php/shablonizaciya/ http://www.insight-it.ru/programmirovanie/php/shablonizaciya/#comments Sat, 26 Jan 2008 12:25:36 +0000 Иван Блинков http://www.insight-it.ru/programming/php/shablonizaciya/ Наверняка Вы часто замечали, что в пределах одного сайта все (или покрайней мере большинство) страниц имеют много общего: структуру, расположение элементов, дизайн и так далее. Основным различием обычно является лишь содержание. Естественно, что делается это не спроста: именно общие компоненты сайта создают в голове посетителей тот самый образ, который производит общее подсознательное впечатление о сайте, а также позволяет посетителям отличать сайт А от сайта Б.

Продолжая разговор, начатый еще в одной из предыдущих статей, рассмотрим организацию интерфейса между двумя другими составляющими практически любого интернет-проекта: скриптов (все так же на примере PHP) и страницами, отправляемыми посетителям посредством http-сервера.

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

Наверняка у Вас уже возникло два вполне логичных вопроса:

1. Как можно разделить таким образом контент?
2. Как потом восстановить страницу в исходном виде?

Вариантов ответа на каждый из них можно придумать множество: начиная с банальных вариаций на тему применения echo, заканчивая применением достаточно серьезных готовых решений вроде широкораспространенного Smarty или существенно более эффективного Blitz. Каждый из них имеет свои сильные и слабые стороны, но в целом любой из них можно оценить по двум критериям: производительности и удобстве организации кода.

Какие-либо цифры оценки производительности приводить не буду, так как, во-первых, в Сети можно найти много benchmark’ов, посвященных этой теме, а, во-вторых, просто-напросто вовсе не о цифрах я хотел с Вами поговорить. Как известно самым производительным по крайней мере с теоретической точки зрения является метод под названием $php$ mess, заключается он в следующем: вся страница размещается в рамках одного файла, при этом статическая часть документа пишется просто "как есть" в соответствии с необходимым стандартом, а изменяемые части организуются размещенным в необходимых местах PHP-кодом, окруженным стандартной конструкцией <?php   ?>. Но огромнейший недостаток очевиден — огромное количество информации расположенной в одном файле, при отсутствии какого-либо более четкого разделения PHP-кода и остального содержимого, чем указанная выше конструкция, приводит к постоянной путанице в коде, а также существенным затратам времени программиста при попытках исправить ту или иную часть документа.

На противоположной стороне нашей шкалы удобство-производительность я бы расположил уже упомянутое выше решение под названием Smarty. Представляет оно собой целую систему, реализованную также на PHP, и предоставляющую огромное количество возможностей по решению нашей задачи. Шаблоны хранятся в отдельных файлах, для определения мест расположения динамического контента используется специальный синтаксис, который прост как три копейки, так как разрабатывался с расчетом не на программистов, а по принципу "чем проще, тем лучше". Именно этот факт сделал Smarty одним из самых (если не самым) распространенных движков шаблонизации (или как их принято правильно называть "Template Engine"). Но, к сожалению, за удобство приходится платить, в этом случае производительностью: вся система сама по себе громоздка и состоит из множества файлов, между которыми все данные так или иначе передаются, а так как написано она на PHP (который является далеко не самым производительным языком программирования, в основном в силу своей интерпритируемости и некоторых других особенностей), конкуренции в плане производительности многим другим вариантам решения нашей задачи Smarty составить не в состоянии.

Одним из лучших "компромиссных" вариантов, которые доступны на данный момент, могу назвать также упомянутый выше Blitz. Реализован он в виде модуля PHP, написанного на языке C, что является залогом его отличной производительности. При этом общая его концепция близка к Smarty: шаблоны также хранятся в отдельных файлах и подчинены незамысловатому синтаксису (который вообще можно понять и запомнить буквально за 15-20 минут, прочитав статью, ссылку на которую я уже приводил выше), а в PHP-скриптах после установки становится доступен специальный класс для управления модулем. Но основное достоинство этого решения является одновременно и его основным недостатком — редкий хостинг имеет этот модуль в списке предустановленных (видимо в силу своей не очень обширной известности, обусловленной ), а доступ к http-серверу и PHP-интерпретатору, который необходим для установки PHP-модулей, предоставляется чаще всего только на дорогих тарифах виртуального хостинга или на различных вариантах VPS или арендуемых серверов.

Помимо этого некоторые энтузиасты берутся на написание "собственных" Template Engine, базирующихся на различных вариантов использования PHP-функций вроде preg_replace. Если честно такие попытки редко заканчиваются успехом: в лучшем случае удается добиться удобства использования самим разработчиком, но чаще всего в ущерб производительности. Заниматься подобными экспериментами я Вам не советую, вместо этого я предлагаю написать "обертку" к приглянувшемуся распространенному Template Engine, что позволит не только сделать его использование более удобным конкретно для Вас, но и позволит заменить его на другой с минимальными затратами сил и времени (например в случае, если модуль Blitz недоступен).

Разрабатываем "обертку"

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

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

Начать стоит как обычно с пустой заготовки для класса:

engine=new Blitz('./template/'.$template.'.tpl');
  }
}
?>

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

В любом случае понадобится переменная для его хранения:

array=array();
    //можно сразу указать указать путь к папке с шаблонами
    $this->engine=new Blitz('./template/'.$template.'.tpl');
  }
}
?>

А также метод, переопределяющий стандартный set на метод, добавляющий новые значения к нашему массиву (хотя можно и любое другое понравившееся название использовать):

function set($caption,$value)
{
  $this->array[$caption]=$value;
}

После чего оригинальный set можно использовать уже непосредственно перед parse, с указанием уже собранного массива в качестве параметра. За компанию позволю произвести себе еще одну модификацию: в подавляющем большинстве случаев parse используется в совокупности с echo, чтобы не указывать каждый раз это слово — можно включить его прямо в наш класс:

function parse()
{
  if(count($this->array))$this->engine->set($this->array);
  echo $this->engine->parse();
}

Еще одним возможным вариантом модификации может стать обработка всех (или какой-то части, если есть необходимость) динамических данных с помощью какой-либо функции, например это актуально для htmlspecialchars:

function set($caption,$value)
{
  $this->array[$caption]=$this->html($value);
}
function rawset($caption,$value)
{
  $this->array[$caption]=$value;
}
private function html($array)
{
  if(is_array($array))
  {
    foreach($array as $caption => $value)
    $value=$this->html($value);
    return $array;
  }
  else return htmlspecialchars($array,ENT_QUOTES);
}

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

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

]]> http://www.insight-it.ru/programmirovanie/php/shablonizaciya/feed/ 20 http://www.insight-it.ru/programmirovanie/php/obshhaemsya-s-bazojj-dannykh/ http://www.insight-it.ru/programmirovanie/php/obshhaemsya-s-bazojj-dannykh/#comments Wed, 16 Jan 2008 19:04:09 +0000 Иван Блинков http://www.insight-it.ru/programming/php/obshhaemsya-s-bazojj-dannykh/ На этот раз хочется обсудить такой одновременно важный и несложный момент в реализации работы любого интернет-проекта, как координации работы Ваших скриптов с СУБД.

Если подойти к этому вопросу "в лоб", то код станет очень неудобен как для понимания, так и для использования: код станет переполнен различными функциями соединения с БД, отправки запросов, преобразования результатов запросов в массивы PHP, подсчета строк, которые затронул запрос, а также многие и многие другие.

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

Этим способом будет являться написание класса, реализующего интерфейс между СУБД и PHP-скриптами. Для начала стоит определиться с ассортиментом функций, которые будет призван выполнять наш класс:

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

Вполне очевидным является тот факт, что методы этого класса будут использоваться практически повсеместно в большинстве проектов. Вследствии чего становится нецелесообразным создание объекта нашего класса и передача его по всем функциям и методам всех скриптов, в таких случае намного предпочтительнее делать владельцем методов и переменных сам класс, а не экземпляр класса, с помощью ключевого слова static. Это позволит пользоваться услугами нашего класса из любого места кода. Приступим-с собственно к кодингу, начать стоит с заготовки пустого класса:

В зависимости от предпочитаемой Вами СУБД набор конкретных функций, используемых в реализации нашего класса, будет вариироваться. В большинстве случаев предпочитаю пользоваться PostgreSQL, на это причин у меня несколько, но это тема для отдельного разговора. Благодаря этому факту приводимый в качестве примера код будет использовать функции для работы именно с этой СУБД. Для поклонников же других этот систем вопрос в подавляющем большинстве случаев заключается лишь в замене этих функций на аналогичные из других модулей PHP, например для популярной и широкораспространенной MySQL достаточно будет всеголишь пройтись автозаменой pg_ => mysql_ и слегка подредактировать параметры некоторых функций.

Перейдем к реализации установления соединения с СУБД, не стоит ожидать увидеть здесь ничего необычного:

static function connect()  // установка соединения
{
  self::$connection=pg_pconnect("host=localhost dbname=pgsql user=pgsql password=MyPassword");
  // не забываем менять указанные данные для авторизации на правильные
  if(!isset(self::$connection))
  {
    echo "Сайт не работает по техническим причинам.Просим прощения за доставленные неудобства.";
    exit;	// ни в коем случае не выводим более информативных сообщений об ошибке, чем это
  }
}

А вот с отправкой и обработкой результатов запросов ситуация далеко не так однозначна. Помимо простой передачи самого текста запроса в СУБД, необходимо правильно определить тип запроса и в соответствии с этим обработать результат. Можно конечно попытаться сделать это автоматически на основе вытаскивания первого слова из текста запроса, но мне всетаки кажется более предпочтительным определение "вручную" желаемого вида представление результата. Выполнение произвольных запросов может выглядеть, например, следующим образом:

static function query($str,$bool=false) // произвольный запрос
{
  //echo $str.""; // очень удобно на стадии разработки в процессе поиска ошибок
  $result=@pg_query(self::$connection,$str); // @ - для сокрытия теоретически возможных ошибок
  // or die('Query failed: '.pg_last_error());
  // не забываем убирать в комментарий в финальном варианте проекта
  // или совсем удалять
  if($result)  // Если получен результат, отличный от false
  {
    if($bool)  // Если выбран результат в виде boolean
    {
      return true;
    }
    else  // Если выбран результат в виде массива
    {
      $n=pg_num_rows($result);	// для создания универсального формата массива
      if($n==1)return pg_fetch_array($result,0,PGSQL_ASSOC);
      else  // даже когда результат содержит только одну строку
      {
        $j=pg_num_rows($result);
        $list=array();
        for($i=0;$i<$j;$i++)
        $list[]=pg_fetch_array($result,$i,PGSQL_ASSOC);
        return $list;
      }
    }
  }else return false;
}

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

static function selectAll($table)
{ // пример метода отправки чаcтоиспользуемых запросов
  return self::query("select * from ".$table.";");
}

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

Что ж, осталось лишь собрать весь код в единый листинг:

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

Эта статья является частью серии статей "Джентельменский набор PHP программиста", если Вам понравилась эта статья то очень вероятно, что Вам придутся по душе и остальные статьи.

Не забываем подписываться на RSS блога, а также на ленту комментариев.

]]> http://www.insight-it.ru/programmirovanie/php/obshhaemsya-s-bazojj-dannykh/feed/ 21 http://www.insight-it.ru/programmirovanie/php/zashhita-internet-resursov-v-kartinkax/ http://www.insight-it.ru/programmirovanie/php/zashhita-internet-resursov-v-kartinkax/#comments Sun, 13 Jan 2008 19:30:00 +0000 Иван Блинков http://www.insight-it.ru/programming/php/zashhita-internet-resursov-v-kartinkax/ Этой статьей мне хотелось бы открыть мою первую серию статей "Джентельменский набор PHP программиста". Как и во всей остальной серии здесь пойдет речь о программировании на PHP для интернет-проектов, но в каждой статье я буду выбирать один узкий аспект и на протяжении всей статьи буду стараться показать возможные варианты его реализации и применения.

Сегодня таким аспектом станет защита интернет-ресурса от возможного возникновения нежелательного контента со стороны пользователей с помощью технологии captcha (точнее о "графическом" варианте ее реализации), о которой уже неоднократно шла речь.

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

Подготовка

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

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

1. Описание класса, генерирующего изображение
2. Файл, который будет вызываться browser’ом. В нем будет подключено описание нашего класса, выбор настроек данного конкретного изображения и выполнено создание объекта класса, в соответствии с выбранными настройками.

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

Итак, создание объекта будем производить максимально простым способом, параметрами укажем белый и черный цвета.

(для удобного чтения таких вставок исходного кода достаточно нажать на нее один раз левой кнопкой мыши и использовать стрелки ← и → на клавиатуре)

Заготовка для самого класса будет выглядеть примерно следующим образом (предположим, что он хранится в файле captcha.class.php):

Задаем параметры

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

width=250;
	$this->height=80;
	$this->fgcol=$fgcol;
	$this->bgcol=$bgcol;
	$this->generateSymbols();
   }
   private function generateSymbols()   // генерация четырех цифр
   {
      $this->string=$this->leadingZero(rand()%10000,4);
   }
   private function leadingZero($num,$length) // дополнения числа num лидирующими нулями
   {						// до длины length
	$str=strrev($num);
	for($i=strlen($str);$i<$length;++$i)$str.="0";
	return strrev($str);
   }
}
?>

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

Генерируем изображение

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

private function generateImage()  // генерация изображения
{
   $im=@imagecreatetruecolor($this->width,$this->height);
   $bcol=imagecolorallocate($im,$this->bgcol[0],$this->bgcol[1],$this->bgcol[2]);
   $fcol=imagecolorallocate($im,$this->fgcol[0],$this->fgcol[1],$this->fgcol[2]);
   imagefill($im,0,0,$bcol);
   imagettftext($im,40,10,20,25,$fcol,"./font/font_name.ttf",$this->string));
   header('Content-Type: image/png');
   imagepng($im);
   imagedestroy($im);
}

В данном методе используются функции модуля PHP под названием GD, основывающегося на одноименной библиотеке, убедитесь, что на Вашем хостинге этот модуль установлен.

Реально же ей пользоваться не стоит — такое изображение с легкостью поддается OCR. Полученный текст необходимо тем или иным образом исказить. Для вывода изображения используется формат PNG, но никто не мешает воспользоваться JPEG или GIF, для этого достаточно заменить везде png на название соответствующего формата.

Искажаем текст

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

• использование нестандартных шрифтов — функция imagettftext позволяет использовать произвольный шрифт в формате Truetype, чем и необходимо воспользоваться. В Сети можно найти огромное количество бесплатных шрифтов в этом формате. По возможности стоит выбирать шрифты, максимально не похожие на любой стандартный, но при этом легко читающиеся.
• использование нескольких шрифтов — сделав подборку подходящих шрифтов, можно не останавливаться на каком-то одном, а сделать выбор текущего шрифта случайным из списка.
• случайный выбор цветов — усложняет работу OCR и в большинстве случаев не сильно мешает восприятию человеком.
• случайное расположение символов — еще один способ усложнить работу программам, пытающимся прочитать текст.
• неравномерный фон — изобразив на фоне какой-либо абстрактный набор любых фигур, можно заставить программу-посетителя подумать что какая-то часть из них является символом. Например, пересечение двух прямых линий часто распознается как буква T или L. Неплохим вариантом является написание на фоне других символов другим цветом, сильно отличающимся от основного и близким к цвету фона.

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

private function generateImage() // генерация изображения
{
   $im=@imagecreatetruecolor($this->width,$this->height);  // создаем пустое изображение
   $mcol=imagecolorallocate($im,$this->fgcol[0]+rand()%100+80,$this->fgcol[1]+rand()%30+150,$this->fgcol[2]-rand()%55); // выбираем случайным образом
   $kcol=imagecolorallocate($im,$this->fgcol[0]+rand()%100+80,$this->fgcol[1]+rand()%30+150,$this->fgcol[2]-rand()%20); // несколько цветов
   $lcol=imagecolorallocate($im,$this->bgcol[0]-rand()%20,$this->bgcol[1]-rand()%20,$this->bgcol[2]-rand()%20);
   $bcol=imagecolorallocate($im,$this->bgcol[0],$this->bgcol[1],$this->bgcol[2]);
   $fcol=imagecolorallocate($im,$this->fgcol[0],$this->fgcol[1],$this->fgcol[2]);
   imagefill($im,0,0,$bcol);  // заполняем изображение фоном
   $array=array(6,7,6,6,20,20,25,26,31,32,37,39,41); // список названий подходящих шрифтов
   $n=$array[rand()%count($array)];  // наугад выбираем из них один
   $m=rand()%50+1;
   $k=rand()%50+1;
   for($i=0;$i<$m;++$i)
   imageline($im,0,rand()%$this->height,$this->width,rand()%$this->height,$lcol); // создаем на фоне несколько линий
   for($i=0;$i<$k;++$i)
   imageline($im,rand()%$this->width,0,rand()%$this->width,$this->height,$lcol); // и еще несколько
   /*
   Генерируем текст: две строки на фон, а также интересующие нас символы по одному.
   */
   imagettftext($im,rand()%20+40,rand()%100-50,rand()%$this->height*0.8,rand()%50+25,$kcol,"./font/".$k.".ttf",$this->randomString(rand()%15));
   imagettftext($im,rand()%40+35,rand()%70-35,rand()%$this->height*0.8,rand()%25+25,$mcol,"./font/".$m.".ttf",$this->randomString(5+rand()%4));
   for($i=0;$istring);++$i)
   imagettftext($im,rand()%10+33,rand()%70-35,15+$i*$this->width/5*1.1+rand()%5,rand()%7+$this->height*0.73,$fcol,"./font/".$n.".ttf",$this->string[$i]);
   for($i=0;$i<$m/10;++$i)
   imageline($im,0,rand()%$this->height,$this->width,rand()%$this->height,$mcol); // еще линии
   for($i=0;$i<$k/4;++$i)
   imageline($im,rand()%$this->width,0,rand()%$this->width,$this->height,$mcol);  // и еще немного
   for($i=0;$i<$k/6;++$i)
   imageline($im,rand()%$this->width,0,rand()%$this->width,$this->height,$fcol);  // и еще чуть-чуть
   header('Content-Type: image/png');
   imagepng($im);
   imagedestroy($im);
}
private function randomString($length)  // генерируем случайный набор символов заданной длины
{
  $list="abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVXYZ!@#$%^&**()-=_+.,<>/\|;:";
  for($i=0,$str="";$i<$length;++$i)$str.=substr($list,mt_rand(0,strlen($list)-1),1);
  return $str;
}

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

Сборка

Не стоит забывать, что помимо генерации самого изображения, необходимо передать написанный текст другому скрипту, который будет сверять данные. Удобнее всего это делать через глобальный массив $_SESSION.

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

class Captcha
{
   private $string;	// генерируемый текст
   private $bgcol;	// основной цвет фона
   private $fgcol;	// основной цвет текста
   private $height;	// высота изображения
   private $width;	// ширина изображения
   function __construct($bgcol,$fgcol)  // конструктор, вызывается при создании экземпляра класса
   {
      $this->width=250;
      $this->height=80;
      $this->fgcol=$fgcol;
      $this->bgcol=$bgcol;
      $this->generateSymbols();
      $this->generateImage();
   }
   private function generateImage() // генерация изображения
   {
      $im=@imagecreatetruecolor($this->width,$this->height);  // создаем пустое изображение
      $mcol=imagecolorallocate($im,$this->fgcol[0]+rand()%100+80,$this->fgcol[1]+rand()%30+150,$this->fgcol[2]-rand()%55); // выбираем случайным образом
      $kcol=imagecolorallocate($im,$this->fgcol[0]+rand()%100+80,$this->fgcol[1]+rand()%30+150,$this->fgcol[2]-rand()%20); // несколько цветов
      $lcol=imagecolorallocate($im,$this->bgcol[0]-rand()%20,$this->bgcol[1]-rand()%20,$this->bgcol[2]-rand()%20);
      $bcol=imagecolorallocate($im,$this->bgcol[0],$this->bgcol[1],$this->bgcol[2]);
      $fcol=imagecolorallocate($im,$this->fgcol[0],$this->fgcol[1],$this->fgcol[2]);
      imagefill($im,0,0,$bcol);  // заполняем изображение фоном
      $array=array(6,7,6,6,20,20,25,26,31,32,37,39,41); // список названий подходящих шрифтов
      $n=$array[rand()%count($array)];  // наугад выбираем из них один
      $m=rand()%50+1;
      $k=rand()%50+1;
      for($i=0;$i<$m;++$i)
      imageline($im,0,rand()%$this->height,$this->width,rand()%$this->height,$lcol); // создаем на фоне несколько линий
      for($i=0;$i<$k;++$i)
      imageline($im,rand()%$this->width,0,rand()%$this->width,$this->height,$lcol); // и еще несколько
      /*
      Генерируем текст: две строки на фон, а также интересующие нас символы по одному.
      */
      imagettftext($im,rand()%20+40,rand()%100-50,rand()%$this->height*0.8,rand()%50+25,$kcol,"./font/".$k.".ttf",$this->randomString(rand()%15));
      imagettftext($im,rand()%40+35,rand()%70-35,rand()%$this->height*0.8,rand()%25+25,$mcol,"./font/".$m.".ttf",$this->randomString(5+rand()%4));
      for($i=0;$istring);++$i)
      imagettftext($im,rand()%10+33,rand()%70-35,15+$i*$this->width/5*1.1+rand()%5,rand()%7+$this->height*0.73,$fcol,"./font/".$n.".ttf",$this->string[$i]);
      for($i=0;$i<$m/10;++$i)
      imageline($im,0,rand()%$this->height,$this->width,rand()%$this->height,$mcol); // еще линии
      for($i=0;$i<$k/4;++$i)
      imageline($im,rand()%$this->width,0,rand()%$this->width,$this->height,$mcol);  // и еще немного
      for($i=0;$i<$k/6;++$i)
      imageline($im,rand()%$this->width,0,rand()%$this->width,$this->height,$fcol);  // и еще чуть-чуть
      header('Content-Type: image/png');
      imagepng($im);
      imagedestroy($im);
   }
   private function generateSymbols()   // генерация четырех цифр
   {
      $this->string=$this->leadingZero(rand()%10000,4);
   }
   private function leadingZero($num,$length) // дополнения числа num лидирующими нулями
   {						// до длины length
      $str=strrev($num);
      for($i=strlen($str);$i<$length;++$i)$str.="0";
      return strrev($str);
   }
   private function randomString($length)  // генерируем случайный набор символов заданной длины
   {
      $list="abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVXYZ!@#$%^&**()-=_+.,<>/\|;:";
      for($i=0,$str="";$i<$length;++$i)$str.=substr($list,mt_rand(0,strlen($list)-1),1);
      return $str;
   }
}

Слегка доработав его и приведя в более подходящий вид, можно добиться генерации изображений, выглядящих например вот так:



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

Для Вашего удобства предлагаю скачать используемые в примере код класса и код вызываемого browser'ом файла.

]]> http://www.insight-it.ru/programmirovanie/php/zashhita-internet-resursov-v-kartinkax/feed/ 8 http://www.insight-it.ru/programmirovanie/kriptografiya/bezopasnoe-obshhenie/ http://www.insight-it.ru/programmirovanie/kriptografiya/bezopasnoe-obshhenie/#comments Wed, 09 Jan 2008 14:34:33 +0000 Иван Блинков http://www.insight-it.ru/science/kriptografiya/bezopasnoe-obshhenie/ …или введение в криптографию

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

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

Как известно, наукой, посвященной теории и практике сокрытия данных, является криптография (из греческого: κρυπτός — скрытый и γράφω — писать). Несмотря на свою историю, насчитывающую не одну тысячу лет, эта наука и в современном мире нашла множество применений.  С применением этой науки возможно решение самых разнообразных проблем, но основной задачей, с которой призвана справляться современная криптография является как раз относительно безопасная передача данных через ненадежное пространство.

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

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

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

Залогом уверенности в том, что передача данных безопасна, является наличие чего-либо что знает или может сделать получатель, но не знает или не может сделать. Использование этой формы асимметрии и является основой для большинства современных методов шифрования информации. Этот объект, обуславливающий возникновение асимметрии, принято называть словом ключ. Формально говоря ключ является одним из параметров шифрования, определяющим каким именно образом были преобразованы данные заранее известным алгоритмом. Основная классификация алгоритмов шифрования основывается на том, кто изначально владеет ключом, принято разделять их на алгоритмы с симметричным (т.е. секретным) и асимметричным (т.е. публичным) ключами.

Алгоритмы с симметричным ключом

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

Сам процесс передачи достаточно прост: с помощью первого предоставленного протоколом алгоритма и имеющегося ключа, отправитель шифрует (encrypt) сообщение, и получает на выходе зашифрованное сообщение, которое и будет отправлено получателю через ненадежный канал. Получатель же в свою очередь, применив второй алгоритм и все тот же ключ, расшифровывает (decrypt) полученное сообщение и в идеале получает исходное сообщение.

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

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

Алгоритмы с асимметричным ключом

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

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

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

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

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

В качестве заключения…

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

]]> http://www.insight-it.ru/programmirovanie/kriptografiya/bezopasnoe-obshhenie/feed/ 1 http://www.insight-it.ru/unix-way/unix-way/ http://www.insight-it.ru/unix-way/unix-way/#comments Sun, 06 Jan 2008 16:30:16 +0000 Иван Блинков http://www.insight-it.ru/programming/unix-way/ На эту тему в Сети можно найти несметное количество статей и обсуждений, не удивлюсь если Вам уже доводилось читать что-либо подобное в прошлом или может быть работать в одной из множества операционных систем, разработанных с использованием этой идеологии. За этим словосочетанием скрывается целая философия разработки программного обеспечения, начавшая свое развитие в середине 90-х годов прошлого века и воплощенная в огромном количестве операционных систем и в еще большем количестве opensource проектов. В этом тексте я хочу поведать Вам свой взгляд на эту философию с двух точек зрения: программиста и пользователя.

Наиболее точно охарактеризовать то, о чем пойдет речь можно лишь процитировав одного из основателей традиций Unix и разработчика технологии под названием "Unix pipes" — Douglas’а Mcllroy’а:

"This is the Unix philosophy:

Write programs that do one thing and do it well.

Write programs to work together.

Write programs to handle text streams, because that is a universal interface."

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

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

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

Закончив лирическое отступление, хочется взглянуть на нашу философию с точки зрения программиста.

Взгляд с точки зрения программиста

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

Как же это выглядит?

Одна задача — одна программа

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

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

Unix pipes

Этот механизм является основным способом реализации столько раз упоминавшегося выше интерфейса между элементарными программами. Реализация его поддержки является как раз второй задачей, которая ставится перед программистом, идущим по пути Unix. С использованием большинства языков программирования она является тривиальной, особенно это справедливо для C.

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

Взгляд с точки зрения пользователя

Слово pipes можно переводить по-разному, мне больше нравится вариант потоки, но также часто используется и дословный перевод — трубы. Также имеет смысл сразу сказать, что его реализация полностью основывается на командной строке и командах различных ее оболочек, а также тесно интегрирована с устройствами компьютера и файловой системой.

У каждой элементарной программы, соответствующей этой идеологии, должен быть входной и выходной стандартные текстовые потоки — stdin и stdout соответственно. Механизм unix pipes позволяет перенаправлять эти потоки любой программы произвольным образом с помощью трех простых операторов: |, > и <. Первый из них — | перенаправляет stdout команды слева от него в stdin команды справа, а > и < предназначены для перенаправление потоков в/из файлы по схожему принципу.

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

• cat — вывод содержимого указанного первым параметром файла в stdout (по умолчанию stdout в большинстве программ направляется в консоль)
• less — постраничный вывод текста, полученного в stdin в stdout (переключение страниц и некоторые другие функции производятся с клавиатуры, возможны и другие варианты использования, но они нам не нужны)
• grep — построчная фильтрация текста, полученного в stdin, вывод только строк, содержащих текст, указанный первым аргументом, и вывод результата в stdout.

Начнем с примера, позволяющего прочитать постранично любой файл:

cat readme.txt | less

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

cat readme.txt | grep unix > readme.txt

Этот пример должен был бы удалить из файла все строки, где нет слова "unix". Маленькое замечание: при использовании такого перенаправления, перед началом передачи данных файл обнуляется. В этом и заключается ошибка данного примера: файл очищается до того, как поток данных успел пройти через фильтрацию grep, что приводит к просто очистке файла. Если же Вам все же нужен отфильтрованный список строк — стоит разместить в другом файле (которым можно было бы подменить исходный при необходимости), просто поменяв его название:

cat readme.txt | grep unix > meread.txt

Если же Вы хотите избежать очищения файла, в который производится запись, необходимо написать символ > дважды, тогда новые данные припишутся в конец:

cat readme.txt | grep unix >> readme.txt

В unix-like системах есть еще одна интересная особенность, косвенно связанная с этим механизмом: все устройства являются файлами и соответственно, прикреплены к файловой системе, для них выделена отдельная директория, по традиции называемая /dev. Работа с ними также ведется на тех же правах что и с обычными файлами, например набрав в консоли:

cat readme.txt > /dev/dsp

в ответ от компьютера Вы услышите некоторый звук, издаваемый из колонок или наушников.

Подводим итоги

С точки зрения простого пользователя использование opensource решений, построенных на базе философии unix, является как минимум нетривиальной задачей — ведь от него требуется как минимум понимание насколько мощная и гибкая система попала ему/ей в руки. Отсутствие единственного верного способа решения той или иной задачи ставит большинство людей попросту в тупик, у них начинают разбегаться глаза от десятков тысяч программ, доступа к которым есть у всех пользователей unix-like операционных систем, с помощью набора простой волшебной команды в консоли, состоящей не более чем из трех-четырех слов.

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

]]> http://www.insight-it.ru/unix-way/unix-way/feed/ 16 http://www.insight-it.ru/programmirovanie/java/tri-osnovnyx-komponenta-paradigmy-obektno-orientirovannogo-programmirovaniya/ http://www.insight-it.ru/programmirovanie/java/tri-osnovnyx-komponenta-paradigmy-obektno-orientirovannogo-programmirovaniya/#comments Sat, 05 Jan 2008 19:28:51 +0000 Иван Блинков http://www.insight-it.ru/programming/tri-osnovnyx-komponenta-paradigmy-obektno-orientirovannogo-programmirovaniya/ Представьте: Россия, солнце только-только начинает свой путь по бескрайним просторам неба, Вы находитесь на одной из самых оживленных улиц своего города и вокруг Вас нетрудно заметить множество людей, спешащих по своим делам. И вот, Вы видите как один человек зашел в большое офисное здание.

Вы спросите у меня: как это все может быть связано с темой этой записи? — об этом я и собираюсь Вам поведать.




---

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


---



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

• наследование
• инкапсуляция
• полиморфизм

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

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

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

class Human
{
   public int height; // рост
   public int age; // возраст
   public String gender; // пол
   public String eyesColor; // цвет глаз
   public String hairColor; // цвет волос
}

Помимо этого мы говорили о его навыках, которые тоже необходимо здесь же упомянуть, для простоты не будем ничего сложного придумывать в плане реализации:

class Human
{
   public int height; // рост
   public int age; // возраст
   public String gender; // пол
   public String eyesColor; // цвет глаз
   public String hairColor; // цвет волос
   public void walk()
   {
      System.out.println("Я иду!");
   }
   public void work()
   {
      System.out.println("Я работаю в большом офисном здании");
   }
}

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

Наследование

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

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

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

class Director
{
   public int height; // рост
   public int age; // возраст
   public String gender; // пол
   public String eyesColor; // цвет глаз
   public String hairColor; // цвет глаз
   public void walk()
   {
      System.out.println("Я иду!");
   }
   public void work()
   {
      System.out.println("Я работаю в большом офисном здании");
   }
   public void idle()
   {
      System.out.println("Я ничего не делаю!");
   }
}

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

class Director extends Human
{
   public void idle()
   {
      System.out.println("Я ничего не делаю!");
   }
}

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

Полиморфизм

Это слово пришло к нам из греческого языка, понимания этого термина легко достичь, просто переведя его на русский язык: πολύμορφος — многоформенность. То есть в наиболее простом случае подразумевается использование одной и той же переменной (или массива) для хранения информации об объектах, описываемых разными классами. Представим, что нам необходим стандартизованный способ узнать кем же работает тот или иной человек, естественно для этого необходимо описание соответствующего метода для выполнения этой функции в каждом классе, причем он должен одинаково называться в каждом из них. Для реализации этого примера на языке Java нет необходимости использовать дополнительных ключевых слов (в отличие от, например, C#, где необходимо использование слова virtual в заголовке метода в базовом классе и override — в производных). Продолжая приводить примеры на Java имеем три производных класса (для упрощения опустим дополнительные методы, которые могли бы присутствовать):

class Director extends Human
{
   public void work()
   {
      System.out.println("Я работаю директором!");
   }
}

class Programmer extends Human
{
   public void work()
   {
      System.out.println("Я работаю программистом!");
   }
}

class Manager extends Human
{
   public void work()
   {
      System.out.println("Я работаю менеджером!");
   }
}

Для того, чтобы воспользоваться механизмом полиморфизма достаточно лишь написать функцию, которая будет создавать экземпляры наших классов и "спрашивать" к них кем они работают, выглядит это ничуть не сложнее, чем и описания классов, хочу лишь обратить Ваще внимание на то, что полиморфная переменная должна иметь тип базового класса:

class AskHuman
{
   public static void main(String[] args)
   {
      public Human person;
      person = new Director();
      person.work();
      person = new Manager();
      person.work();
      person = new Programmer();
      person.work();
}

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

Я работаю директором! Я работаю менеджером! Я работаю программистом!

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

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

interface Worker
{
   public void work();
}

class Director extends Human implements Worker
{
   public void work()
   {
      System.out.println("Я работаю директором!");
   }
}

class Programmer extends Human implements Worker
{
   public void work()
   {
      System.out.println("Я работаю программистом!");
   }
}

class Manager extends Human implements Worker
{
   public void work()
   {
      System.out.println("Я работаю менеджером!");
   }
}

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

Инкапсуляция

Наверняка Вы уже задавались вопросом о том, что же значит слово public во всех предыдущих примерах. Это ключевое слово является частью реализации механизма инкапсуляции в языке Java, суть его состоит в том, чтобы дать возможность определить область видимости для составных частей класса, это очень актуально при написании ПО, использующего библиотеки, plug-in’ы или при написании программы группой людей. Ведь если Ваш класс подразумевает какие-либо ограничения для переменных или методов (например — возраст не может быть отрицательным), то их легко обойти воспользовавшись прямым доступом к ним из-за пределов класса или просто выполнив наследование.

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

• public — назначается по-умолчанию — полностью свободный доступ
• private — доступ предоставляется только другим компонентам класса
• protected — доступ предоставляется остальным компонентам класса, а также всем наследникам данного класса

Данный механизм является незаменимым помощником разработчиков любых более-менее крупных проектов, следующих принципам ООП.

Вместо заключения

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

]]> http://www.insight-it.ru/programmirovanie/java/tri-osnovnyx-komponenta-paradigmy-obektno-orientirovannogo-programmirovaniya/feed/ 15 http://www.insight-it.ru/programmirovanie/obektno-orientirovannoe-programmirovanie-a-chto-zhe-eto/ http://www.insight-it.ru/programmirovanie/obektno-orientirovannoe-programmirovanie-a-chto-zhe-eto/#comments Fri, 04 Jan 2008 18:39:53 +0000 Иван Блинков http://www.insight-it.ru/programming/obektno-orientirovannoe-programmirovanie-a-chto-zhe-eto/ Находишься в поисках способов облегчить свой труд в процессе написания программного обеспечения? — об одном из них мы сегодня и поговорим.

Сама концепция этого подхода к программированию достаточно проста для понимания, и заключается она в…

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

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

Для начала напомню тот факт, что в языках высокого уровня простейшими элементами, доступными программисту, являются:

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

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

Класс

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

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

Объект

Для простоты понимания это слово можно воспринимать буквально — как некую сущность, находящуюся в каком-либо состоянии и имеющую возможность совершать некий набор действий. Также как и реальные объекты, объекты «компьютерные» живут своей жизнью: рождением считается создание объекта (выделение памяти), а смертью — уничтожение (освобождение памяти). Промежуток между этими двумя событиями принято называть временем жизни объекта.

Если же есть желание взглянуть на объект с технической точки зрения, то он представляет собой экземпляр какого-либо класса, то есть как раз указатель на область оперативной памяти, данные по которому подчиняются «правилам», установленными в соответствующем классе. То есть для него могут выполняться заранее определенные функции, что будет приводить к определенным изменениям в его состоянии (то есть совокупности переменных).

Все написанное выше можно считать лишь неким подобием введения в ООП, дающим поверхностное представление о том, что же понимают под этой странновато звучащей фразой, и на какие же ««объекты» нужно «ориентироваться». Сама же теория является намного более обширной, и я собираюсь еще не раз вернуться к ее обсуждению в теории и с более практической точки. Например, возможно для многих остался не ясным вопрос: какие же преимущества предоставляет использование ООП перед более традиционным функциональным программированием? Ответить на него я и собираюсь в одном из следующих постов, не пропустить публикацию которого можно с помощью RSS.

]]> http://www.insight-it.ru/programmirovanie/obektno-orientirovannoe-programmirovanie-a-chto-zhe-eto/feed/ 4 http://www.insight-it.ru/programmirovanie/para-prostyx-sposobov-povysit-effektivnost-napisaniya-koda/ http://www.insight-it.ru/programmirovanie/para-prostyx-sposobov-povysit-effektivnost-napisaniya-koda/#comments Thu, 03 Jan 2008 17:52:05 +0000 Иван Блинков http://www.insight-it.ru/programming/paru-prostyx-sposobov-povysit-effektivnost-napisaniya-koda/ Начнем, пожалуй, издалека: если рассматривать процесс программирования чуть более глобально, чем просто как дальний синоним слова coding, то нетрудно прийти к выводу, что реализация хоть сколько-нибудь большого проекта невозможна просто с помощью следования банальному алгоритму: сесть за компьютер, бросить взгляд на ТЗ, открыть любимый текстовый редактор, взять в зубы клавиатуру и написать. Если говорить о проектах уровня "Hello, world!" такой алгоритм вполне пригоден для реального использования, но как только речь заходит о чем-либо более серьезном и полномасштабным, такой подход сразу начинает порождать несметное количество проблем.

Основными причинами этого явления я бы назвал ограниченность ресурсов одного человека и отсутствие какой-либо стандартизации. Количество строк кода, которые кодер в состоянии писать в единицу времени ограниченно не только скоростью набора символов на клавиатуре, но и аналитическими способностями: начиная с какого-то момента человек тупо начинает забывать где у него находилась, например, та или иная функция или что значит та или иная переменная / константа.

Временным спасением от подобного рода проблем может послужить привычка грамотно оформлять код:

• Размещение строго по одному выражению на строке в комбинации с поддающимся хоть какой-либо логике расставления отступов в начале строки позволяет избежать потерянных выражений и четко понимать: а где же заканчивает вон то-о-от цикл?
• Осмысленные названия переменных резко сокращают время, необходимое для осознавания ответа на вопрос "а что же она значила?" Мне доводилось не раз сталкивался с кодом, написанным с использованием в качестве абсолютно всех переменных разнообразных букв латинского алфавита — мало того что изменить их на что-либо другое как автозаменой, так и RegExp’ами проблематично, так и на разобраться что к чему ушло очень продолжительный период времени. Существует большое количество более адекватных способов названия переменных и функций, перечислять их все смысла не вижу, по-этому кратенько расскажу о том, которым предпочитаю пользоваться сам: алгоритм прост как три копейки — название соответствует переведенному на английский смыслу (переменную, содержащую чье-либо имя называем name), в случае если слов требуется более одного слова — пишем их слитно, начиная все кроме первого с заглавной буквы (например: veryLongName), и по старинной традиции делаем исключение для индексов циклов, которые называем буквами латинского алфавита начиная с i и далее по списку. Вот собственно говоря банальный способ, позволяющий в очень сжатые сроки вспомнить как называлась переменная, содержащее имя
• Подавляющее большинство языков программирования поддерживает разбавление кода комментариями, что существенно упрощает ориентирование в объемистых листингах как самим автором, так и всеми остальными персонами, которым по тем или иным причинам доведется в последствии читать произведение. Особенно этот способ актуален для низкоуровневых языков программирования, так как с первого взгляда на код даже его автору порой проблематично определить его значение.

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

]]> http://www.insight-it.ru/programmirovanie/para-prostyx-sposobov-povysit-effektivnost-napisaniya-koda/feed/ 9