Архив категории ‘Без категории’

Вторая часть обзора посвящена среде Google AppEngine.

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

Данный обзор ставит целью помочь руководителям проектов и программистам, не знакомым с технологиями Google Web Toolkit и Google App Engine, принять правильное решение об использовании или неиспользовании их в новом проекте.

(далее…)

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
$