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

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

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

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

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

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

Глава 4. Куда сеем? В контент!

Многие спросили, как я набрал первоначальную массу пользователей, после набора которой сообщество, собственно, как-то задышало. Было дело так: когда я на одном из бесплатных LiveStreet'овском (CMS моего проекта) дизайне только-только открыл проект, сразу же встал вопрос о привлечении на него аудитории. Но на что придёт аудитория, не на голое же место?

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

Добрый день, %username%!
За последний год столкнулся с несколькими задачами по написанию SOAP/REST API к различным сервисам и вывел для себя боле-менее удобную модель. Я не претендую на фундаментальное исследование, просто хочу поделиться опытом наступания на грабли.

Для начала общие требования к default API:

• возможность расширения
• удобный стандартизированный формат запросов
• удобный стандартизированный формат ответов
• достаточный уровень безопасности
• возврат ошибок выполнения запроса

Вступление

Привет!

В последнее время, спустя вот уже полтора года, как я с нуля, практически в одиночку, создал и развил неплохое с точки зрения пользующихся им людей, а также с точки зрения материального профицита, интернет-сообщество — Автотуристу.Рф, меня стали часто спрашивать, как мне удалось этого добиться и какие шаги я предпринимал на пути к этому. Пусть это и покажется не скромным, но я действительно добился результата (это – состоявшийся факт), об этапах достижения которого теперь и хотел бы поведать интересующимся. И пусть я не запустил Хабр v2.0 и не получаю со своего стартапа баснословных доходов, но, всё же, средний (и даже немножечко выше) московский ай-ти’шный оклад я с него имею, а это и было моей целью. Соответственно, ниже повествование о том, как я поставил себе цель и её добился!

Итак, писанина ниже – это некое Know-How на тему создания с нуля человеком, далёким от web-разработческих дел, интернет-стартапа и его дельнейшего продвижения и развития. Сразу оговорюсь, что всё, что будет изложено ниже, основывается лишь на моём собственном опыте и не претендует на какую бы то ни было научность или официальность. Дело в том, что полтора года назад загоревшись (да что там «загоревшись» — став одержимым!) идеей создания тематического интернет-сообщества, я самостоятельно, от и до, её реализовал. Ещё прошу заметить, что все свои «трепыхания» при создании своего собственного стартапа предпринимались мной, так сказать, «по наитию», то бишь я не читал мудрых книжек и не ходил на семинары или мастер классы. Хотя, с другой стороны, если бы не два замечательных человека, моих друга, то, скорее всего, не было бы и никакого стартапа, но об этом по ходу пьессы.
Важно! Я буду писать много и обстоятельно, вдаваясь в разные, на первый взгляд, казалось бы, ненужные детали, но, поверьте, именно детали порой играют решающую роль, имхо, конечно же.

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

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

Поехали

MySQL стал собственностью Oracle, есть ли альтернативы и как быстро движение вперед?.. Вроде как обобщающего обзорчика «who is who?» еще не было. Итак, обзорчик для тех кто «не в теме»

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

1. Почему не mb_detect_encoding() ?

Если кратко — он не работает.

Привет всему хабросообществу.

Время не стоит на месте. После публикации моего справочника по Postgresql очень многое успело поменяться, а точнее добавиться в эту отличную СУБД. После выхода PostgreSQL 9 версии я понял, что потребуется добавить информацию о нововведениях для этой версии. Тем более, что 9 версия знаменуется выходом репликации из коробки.

О чем пойдет речь

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

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

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

Я, как человек, связанный университетом с Java, следил за развитием NetBeans практически с момента его становления изначально меня принудил ей пользоваться мне показал эту IDE мой учитель — Вадим Монахов (с гордостью обнаружил, что ссылка на него ведет с wikipedia, раздел литература). Сейчас часто сталкиваюсь с тем, что программисты PHP пишут говнокод ссылаясь на недоразвитость IDE не умеют делать Refactoring и многих из них останавливает отсутствие автоматизированных средств. Собственно, я решил отобрать у них этот аргумент: средства есть и сегодня я рассмотрю NetBeans как среду разработки для PHP и продемонстрирую заложенную в нее мощь.

Не секрет, что в PHP 5.3 был введен ряд интересных новшеств. Разной степени полезности и скандальности. Возможно даже, что выпуск PHP 5.3 — хорошо спланированный PR-ход: самый большой список изменений за последние пять лет, оператор goto (sic!), пространства имен (namespaces) с синтаксисом «не как у всех», позднее статическое связывание (late static binding), более-менее честные анонимные (лямбда) функции (lambda functions), замыкания (closures).

Как разработчик, вы сидите на золотой жиле. Вы осознаете это?

Нет, серьезно, на @#$% золотой жиле! Никогда в истории не существовало возможностей так легко создать что-то с нуля, с маленьким или отсутствующим начальным капиталом и маркетинговой моделью, ограниченной только вашим воображением.

Подумайте о крупнейших сайтах, которые вы постоянно посещаете: Facebook, Twitter, Flickr, Foursquare, или даже Google — все они были созданы разработчиками, у которых была лишь идея. Было ли это легко? Черт, нет. Но это могло быть сделано только в наше время. Так, черт побери, почему вы просиживаете день за днем, работая на кого-то?

Написал небольшой мануал по настройке и масштабированию PostgreSQL. Сподвигло меня на это то, что материала по этой теме мало, он устарел или его просто нет.

Скачать можно здесь:
http://github.com/le0pard/postgresql_book/raw/master/postgresql.pdf
Исходники:
http://github.com/le0pard/postgresql_book/

Страница:
http://postgresql.leopard.in.ua/

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

Да-да, все «реальные пацаны» умеют строить веб-системы, способные выдержать монументальные нагрузки. Ну а для «непацанофф» всегда есть гугл и масса сайтов посвящёных данной тематике. Однако «проблема роста» включает в себя не только вопрос верной сервировки данных клиенту и их грамотной репликации/распределении на кластере. Зачастую проблемы возникают от того, что всё как раз-таки наоборот — слишком шустро работает. Рассмотрим пример из недавней практики:

Очень тяжело начать писать статью. Т.е очень тяжело придумать вступительное слово. Хочется рассказать обо всём и сразу :) Но нет. Будем последовательны.
Начну с того что совсем недавно проходил Highload++ 2008 на котором мне удалось побывать.
Скажу сразу — мероприятие было проведено по высшему клаcсу, докладов было много и все были очень интересными.
Одной из самых запомнившихся презентаций была лекция Аско Ойя об инфраструктуре серверов баз данных в Skype. Лекция в большей степени касалась различных средств с помощью которых достигается такая производительность серверов.
По словам Аско, база данных Skype выдержит даже если все жители Земли захотят подключится к скайп в один момент.

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

UPD: Как правильно заметил хабраюзер descentspb в статье присутствует досаднейшая ошибка. В следствие своей невнимательности я подумал что PgBouncer надо устанавливать между прокси и клиентом. Но, как оказалось, та проблема которую я решал с помощью PgBouncer не решится если установить его именно так. Правильнее надо устанавливать боунсер между нодами и прокси. Мало того, именно так и рекомендуется делать в оффициальном мануале на сайте PL/Proxy.
В любом случае использование PgBouncer так как указано на моей схеме также даст прирост производительности. (Разгрузит Proxy).

Многие задают мне один и тот же вопрос:
«Как дебажить этот $%*!%$! JavaScript?».

Так вот, во-первых JavaScript — не $%*!%$! А как я его дебажу — сейчас расскажу.

(Примечание: наверное эта статья больше для новичков. Так что не судите строго)

Может кому будет интересно как «по-быстрому» провести нагрузочное тестирование своего веб-приложения.
Подробности под катом