Архив от 2010

AJAX и все, все, все

В предыдущей серии мы делали простенькое Grails-приложение с использованием jQuery, а также решили для себя, что использовать jQuery в Grails можно и даже нужно. Обсудим более серьезные вещи, которые можно сделать с такой связкой.

Нетрудно заметить, что все больше сайтов используют AJAX и частичные обновления страниц, причем в невероятном количестве. В частности, «начиненные» AJAX ссылки могут использоваться для внутренней навигации по странице, переключения каких-то вкладок. Это хорошо тем, что
А) меньше данных нужно перегонять от сервера — только нужный кусок страницы и
Б) веб-страницы часто загружают просто гигантские CSS и JavaScript-файлы, которые при AJAX-обновлении можно повторно не загружать.

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

  1. В результате AJAX-действий внутреннее состояние страницы не отражено в адресной строке браузера.
  2. Как следствие, внутренние страницы не могут быть запомнены в закладки, нельзя «отправить ссылку другу».
  3. Не работает Back/Forward навигация в браузере, т.к. AJAX-ссылки не попадают в историю браузера.

Однако крупные сайты нашли некое «хакерское» решение, которое мы сейчас рассмотрим и напишем небольшой свой собственный аналог на Grails и jQuery. (далее…)

В данном посте хотелось бы просуммировать наш опыт работы над крупными интернет-проектами и рассмотреть характер и объем работ системной и инфраструкторной поддержки проектов.

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

Диаграмма объема инфраструктурных и системных работ

(далее…)

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

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

(далее…)

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

(далее…)

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

Весной я выступал на РИФе с докладом «Java как язык Веба: эволюция или ребрендинг?». Почему эта тема вообще возникла? Дело в том, что некоторые считают Java чисто академическим языком, для других — это язык корпоративных приложений, но никак не язык Веба. В России вообще для большинства Веб-разработчиков существует только один язык – PHP. Что касается Java, то есть мнение, что писать на нем непродуктивно, это сложный язык с высоким порогом входа, под любой проект нужно долго настраивать среду разработки, и вообще – язык слишком сложен для Веб-приложений, которые в большинстве своем достаточно просты.

В своем докладе я попытался реабилитировать Java как язык именно Веб-приложений. Аргументы следующие. (далее…)

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

(далее…)

Mike Haertel, автор GNU grep, написал в рассылку FreeBSD отличное письмо по поводу производительности grep-а.

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

Там же предлагалась идея использовать mmap для увеличения производительности, чтобы ядру не читать read-ом каждый байт, а передать контроль за этим в юзерспейс — самому grep-у.

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

Вторая причина в том, что каждая считанная страница памяти будет генерировать page fault. Это может быть даже дороже, чем системный вызов read().

Собственно, именно так и посчитали разработчики grep-а.

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

$ time grep groovy tmpfs/words > /dev/null

real 0m0.927s
user 0m0.600s
sys 0m0.311s
$ time grep -n groovy tmpfs/words > /dev/null

real 0m1.924s
user 0m1.606s
sys 0m0.307s
$

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

И в это лето мы решили не изменять традиций!

Изначально отдых  планировался  культурный, с бассейнами, футбольными площадками, сауной… Но  в результате поехали  мы на берег Москвы реки под Звенигород!

Что мы там делали? Да все делали! Купались, кормили комаров, ели шашлыки(ударение на втором слоге), варили плов(ну мы его потребляли в основном), играли в бадминтон. Вечером снимали стресс, глядя на огонь.. это сейчас так называется.  Играли мы в Контакт. В нашей компании из этого получается очень  высокоинтеллектуальная игра! Я в очередной раз почувствовала себя блондинкой и порадовалась, с какими умными людьми я работаю.

Ну а на следующий день – пошли по Святым местам! Савву Сторожевского посетили. Кстати, говорят,  что он в бизнесе помогает. Говорят, у кого какие проблемы – сразу к нему! Чтобы мы выгледели прилично, нам выдали юбки…даже мальчикам выдали. Не могу сказать, что выглядеть мы стали приличнее….но решили не лезть со своим уставом в чужой монастырь. Наверное Богу тоже иногда хочется посмеяться.

В общем, отдохнули хорошо, потом от отдыха еще долго отдыхали!

В Москве на Ходынке рабочие повредили кабель спецсвязи, из-за того, что он не был указан в документации в связи с высокой секретностью (http://lenta.ru/news/2010/08/16/liason/). Этот случай – очень хорошая иллюстрация опасности подхода «Security through obscurity» (безопасность путем сокрытия). Система, построенная на этом принципе может содержать уязвимости, но, разработчики или владельцы системы считают, что о них никто не узнает. Но на самом деле, об уязвимостях узнают, и в первую очередь отнюдь не разработчики этой системы.

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

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

Алгоритм шифрования A5/1 (http://en.wikipedia.org/wiki/A5/1), применяемый в GSM сетях, изначально держался в секрете, однако в 1994 году некоторые детали реализации алгоритма утекли в широкие массы, а в 1999 году он был полностью раскрыт реверс-инженирингом телефонного аппарата. Алгоритм оказался настолько некриптоустойчив, что на данный момент GSM передачи можно перехватывать при помощи оборудования за $1500 (http://www.securitylab.ru/news/396052.php).

Компания Cisco Systems скрывала детали реализации своих протоколов маршрутизации, пока в мае 2004 года не были украдены исходные коды операционной системы, которая работает на их маршрутизаторах. В результате анализа кода было выявлено множество уязвимостей в протоколе EIGRP, что подвергло риску множество владельцов оборудования Cisco. (http://www.securitylab.ru/vulnerability/source/243482.php)

Случается люди кладут свою секретную информацию на веб-сервер, не защищая ее паролем и беспечно полагая, что об этом сервере никто не узнает, если они о нем никому не скажут (не будут создавать DNS имя, создатут секретную папку с секретным именем, поднимут веб-сервер на нестандартном порте и проч.). Сетевые сканеры (cheops-ng, firewalk, nmap) довольно быстро находят такие заначки, и их секретная информация быстро становится достоянием общественности. Аналогично, «секретные» URL оседают в истории броузеров, оказываются в HTTP referer, и, довольно быстро, Google и другие поисковые машины их индексируют.

Открытость системы, как правило увеличивает уровень ее безопасности. Согласно Эрик Реймонд сформулировал «закон Линуса», который гласит «при достаточном количестве глаз баги выплывают на поверхность» (given enough eyeballs, all bugs are shallow). Если система открыта, довольно много экспертов захотят на нее посмотреть и если в ней есть уязвимости, об этом будет известно довольно быстро, как правило до того, как ей будут пользоваться миллионы клиентов.