Вторая часть обзора посвящена среде Google AppEngine.
В отличии от GWT, который является просто средством разработки, одним из ряда аналогичных, на GAE нужно посмотреть и с другой стороны. GAE это не просто среда (платформа), где выполняются приложения (кстати, совсем не обязательно, написанные на GWT), но и хостинг. (далее…)
Данный обзор ставит целью помочь руководителям проектов и программистам, не знакомым с технологиями Google Web Toolkit и Google App Engine, принять правильное решение об использовании или неиспользовании их в новом проекте.
В предыдущей серии мы делали простенькое Grails-приложение с использованием jQuery, а также решили для себя, что использовать jQuery в Grails можно и даже нужно. Обсудим более серьезные вещи, которые можно сделать с такой связкой.
Нетрудно заметить, что все больше сайтов используют AJAX и частичные обновления страниц, причем в невероятном количестве. В частности, «начиненные» AJAX ссылки могут использоваться для внутренней навигации по странице, переключения каких-то вкладок. Это хорошо тем, что
А) меньше данных нужно перегонять от сервера — только нужный кусок страницы и
Б) веб-страницы часто загружают просто гигантские CSS и JavaScript-файлы, которые при AJAX-обновлении можно повторно не загружать.
Итак, очень распространено построение приложений по сценарию: одна большая «стартовая» страница, загружающая весь JavaScript-код и CSS и более мелкие «внутренние» функциональные блоки, загружаемые через AJAX. С этим есть ряд проблем:
Однако крупные сайты нашли некое «хакерское» решение, которое мы сейчас рассмотрим и напишем небольшой свой собственный аналог на Grails и jQuery. (далее…)
В данном посте хотелось бы просуммировать наш опыт работы над крупными интернет-проектами и рассмотреть характер и объем работ системной и инфраструкторной поддержки проектов.
Работы можно отсортировать по «уровням» (с какой-то погрешностью). Высоким уровнем будет считаться уровень приложения и данных, низким уровнем будет аппаратная часть.
Жизнь устроена так, что показывать и обрабатывать цифровое видео всегда сложнее, чем цифровые фото:
Несколько месяцев назад мы в первый раз опробовали Balsamiq Mockups. Это такая небольшая и очень удобная программа для построения макетов пользовательских интерфейсов. Чтобы представлять о чем идет речь, сразу прикладываю один из экранов, который мы в ней нарисовали.
С выпуском 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/nullreal 0m1.924s
user 0m1.606s
sys 0m0.307s
$
Gramant © 2007—2024.
