Главная страница. Абонентское обслуживание компьютеров в СПб. ИТ аутсорсинг. ИТ аутсорсинг, абонентское обслуживание компьютеров в спб Полезные статьи посвященные компьютерам и интернету Проектирование и монтаж компьютерных сетей Разработка ПО (программного обеспечения) Продажа лицензионного программного обеспечения Поставка компьютерного оборудования, серверов, комплектующих Контакты. Время работы. Схема проезда
 

Обзор ИТ аудита, консалтинга

Методы ИТ аудита

Полезные статьи

Оставить отзыв

Отзывы клиентов

<< Предыдущая

106

107

108

109

110

111

112

113

Следующая >>

Полезные статьи | Будущее веб-приложений: Джошуа Шахтер

Будущее веб-приложений: Джошуа Шахтер

Будущее веб-приложений: Джошуа Шахтер


Это первая из серии статей по материалам конференции "Будущее веб-приложений" (The Future of Web Apps summit), прошедшей в 2005 году. В этой статье собраны и обработаны выдержки из выступления ведущего разработчика del.icio.us Джошуа Шахтера (Joshua Schachter). Скачать и прослушать выступление на английском языке в формате mp3 можно отсюда.

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


Веб-браузеры

Огромное количество времени у вас отнимет отладка работы вашего приложения в разных браузерах. JavaScript и CSS работают по-разному, отображение страниц отличается. Обязательно найдется какой-нибудь пользователь «Оперы», который будет ныть и портить вам жизнь. Вам придется разобраться с реализацией кеширования страниц у Microsoft Internet Explorer. В общем, готовьтесь к сложностям в этой области.

Масштабирование

Не тратьте время, пытаясь угадать будущие проблемы. Решайте настоящие

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

Почитайте статьи Кала Хендерсона (Cal Henderson) из Flickr и Fitzpatrick из LiveJournal о тех проблемах, с которыми они сталкивались, и о том, как они их решали. Подумайте о том, как разнести ваше приложение на несколько серверов. Например, вы можете отдавать основной контент, RSS*-каналы и изображения с разных машин. Поставьте кеширующий прокси-сервер между вашим веб-сервером и пользователями. И вообще используйте кеширование везде, где только можно.

Помните о том, что многие проблемы сегодняшних веб-приложений плохо решаются с помощью SQL*. Проверяйте скорость выполнения каждого SQL-запроса. Старайтесь уменьшить размеры индексов. Будьте хитрее — помните, что никто никогда не будет просматривать результаты на страницах 100, 101, 102 и т. д. А тот, кто туда доберется, может и подождать.

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

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

API

Чем раньше вы сделаете API, тем лучше

Постарайтесь реализовать API* как можно раньше. И вам будет проще, и вашим пользователям. Наличие API помогает популяризировать ваше приложение. Сделайте API как можно более простым. Такие технологии, как SOAP* и XML RPC*, замечательны, но гораздо больше народу знает, как использовать обычные GET- и POST-запросы вкупе с HTML*.

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

Безопасность

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

Прячьте детали реализации

При разработке приложения позаботьтесь о том, чтобы серийные и легко угадываемые ключи (index.php?id=10) не выставлялись наружу. Обязательно найдется какой-нибудь умник, который решит перебрать все ключи, для того чтобы стащить ваши данные. И это несмотря на присутствие API. Прячьте детали реализации проекта от посторонних глаз. Например, в del.icio.us вместо серийных цифровых ключей используются MD5-хеши. Это помогает.

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

Мониторинг

Установите и постоянно подстраивайте системы мониторинга (Nagios, MRTG). Наведите цифры и графики на все, что можно. Системы мониторинга помогут вам в двух вещах.

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

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

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

Функциональность

Аккуратно выбирайте функциональность

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

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

В любом случае, что бы вы ни сделали, пользователи будут просить вас добавить ту или иную функциональность. Пытайтесь разобраться в причинах. Поймите, почему пользователи просят эту функциональность, какая проблема стоит перед ними. И решайте эту проблему.
Ссылки по теме Проект mod_throttle на FreshMeat Проект mod_bandwidth на FreshMeat Прокси- и веб-сервер Perlbal Механизм кеширования memcached

Статья получена: hostinfo.ru

Новые статьи:
SEO-копирайтинг в вопросах и ответах
Механизмы безопасности GPRS

<< Предыдущая

106

107

108

109

110

111

112

113

Следующая >>