С появлением новых проектов в сети иногда кажется, что задача эффективной организации пользовательских поддоменов (bob.someblog.com) кому-то представляется непростой. На самом деле, этот вопрос решается за одну минуту.
 

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

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

Тем, кто занимается бизнесом, в частности веб-разработкой, не надо рассказывать о «вредных» клиентах. Мой комментарий на эту тему в одном из топиков вызвал положительные отклики, поэтому расскажу, что я думаю по этому поводу. А именно: как дифференцировать клиентов по «вредности»; как (и стоит ли) работать с «вредными клиентами».

Несколько статей и переводов по оптимизации (gzip для Apache, gzip для CSS- и JS-файлов, CSS-сжатие, JS-сжатие) уже затрагивали тему применения архивирования для уменьшения размера файлов, и, тем самым, увеличения скорости их передачи конечному пользователю. В данном исследовании я задался вопросом: а как динамическое gzip-сжатие влияет на быстродействие сервера? Рентабельно ли включать mod_gzip / mod_deflate для высоконагруженных проектов? И в каких случаях архивирование вообще лучше не использовать?

Отдельно хочется сказать спасибо одному из читателей Хабра, который в личной переписке (к сожалению, исходное письмо безвозвратно потерялось, поэтому буду признателен, если он о себе напомнит) настойчиво пытался прояснить этот вопрос, что послужило отличным стимулом для написания данной статьи.

читать дальше на webo.in →

Суть проблемы

Возможность пользователя ввести оооочень длинное слово без пробелов, и тем самым «взорвать» layout — это старая проблема. Вот так она решается на Хабре.

Три наших персонажа: программист, дизайнер и клиент.

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

Одной из основных моих активностей на работе является оценка проектов. И в данной статье я постараюсь поделиться своим опытом в данной области.

Большинство дизайнов ориентировано на использование фиксированных значений при верстке: ширина и высота блоков, размер шрифта. Это позволяет сверстанному шаблону «не разваливаться» при изменении масштабов просмотра и сохранять свойство кроссбраузерности. Однако в этом есть один большой минус – при большом разрешении экрана маленькие фиксированные блоки теряются на большой площади и остаются незамеченными. Тут даже не спасет «резиновая» верстка, т.к. сайт будет выглядеть еще более нечитабельным, например на 19'' мониторах при разрешении большем 1280 по ширине. Для меня это актуально, т.к. на ноутбуке 17'' с разрешением 1400х800 просматривать «резиновый» сайт очень неудобно. И желание оставаться на таком сайте отпадает быстро. Существует ли способ, позволяющий управлять масштабами не только текста, но и всего сайта?

Существует прелестная библиотека для Python — libGmail. Используя эту библиотеку очень просто получать и отправлять письма с GMail. А еще можно сделать из своего аккаунта POP или SMTP сервер.

LibGmail можно использовать как с Питоном так и в связке с любым популярным фреймворком. Например, с Django.

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

import libgmail
…

def activation(request):
    to_email = request.user.email
    activation_link = dontbeevil.com/activate/%s % request.COOKIES[«sessionid»]
    ga = libgmail.GmailAccount(dontbeevil@gmail.com, «ourpassword»)
    ga.login()
    subject = «Администрация сервиса»
    msg = «Дорогой пользователь! Для активации аккаунта воспользуйтесь этой ссылкой: %s» % activation_link
    gmsg = libgmail.GmailComposedMessage(to_email, subject, msg)
    ga.sendMessage(gmsg)
…

Использование LibGmail избавило меня от необходимости использовать встроенный SMTP сервер моего хостера. Плюс отсутствие спама на служебный почтовый ящик :) Весь спам попадает в GMail.

Кросс-пост с моего блога.

Ниже перевод статьи «Optimizing Page Load Time», в которой автор математически рассчитывает оптимальный размер файлов для эффективной передачи при веб-запросах, рассматривает некоторые прикладные вопросы оптимизации загрузки страницы с учетом особенностей браузеров, а также дает несколько развернутых и ценных советов. Мои комментарии далее курсивом.

Существует распространенное мнение, что быстро загружающая страница положительно влияет на впечатление пользователя (improve the user experience). В последние годы многие сайты начали использовать для этой цели технологию AJAX, чтобы уменьшить время ожидания (при загрузке данных). Вместо того, что запрашивать с сервера новую страницу полностью при каждом клике, браузер часто можно либо поменять вид самой страницы (отобразив или скрыв какие-либо блоки), либо подгрузить небольшую порцию HTML-, XML- или JavaScript-кода и внести изменения на существующую страницу. В любом случае, это значительно уменьшает время, проходящее между кликом пользователя и окончанием визуализации браузером нового содержания.

Что влияет на загрузку страницы?

Однако, для большинства сайтов, загрузка страницы затрагивает десятки внешних объектов, основное время загрузки тратится на различные HTTP-запросы картинок, JavaScript-файлов и файлов стилей. AJAX, возможно, поможет в данной ситуации, но ускорение или удаление этих HTTP-запросов может принести гораздо больше пользы, хотя на данный момент нет единого мнения (a common body of knowledge), как именно это следует делать.

читать дальше на webo.in →

FreeBSD, сетевая Intel fxp, порт 100Мбит, polling, http accept-filter
в sysctl:

sysctl kern.maxfiles=90000
sysctl kern.maxfilesperproc=80000
sysctl net.inet.tcp.blackhole=2
sysctl net.inet.udp.blackhole=1
sysctl kern.polling.burst_max=1000
sysctl kern.polling.each_burst=50
sysctl kern.ipc.somaxconn=32768
sysctl net.inet.tcp.msl=3000
sysctl net.inet.tcp.maxtcptw=40960
sysctl net.inet.tcp.nolocaltimewait=1
sysctl net.inet.ip.portrange.first=1024
sysctl net.inet.ip.portrange.last=65535
sysctl net.inet.ip.portrange.randomized=0


Jared Kuolt создал небольшой скрипт кэширования для Django. Всем замечателен: и простотой и размером.

Но у скрипта StaticGenerator и nginx-конфига, приведенного Jared-ом, есть недостатки:
1) актуально только для сайтов без регистрации;
2) работа с ссылками только простого вида;
3) генерация только при изменении/добавлении контента и/или комментариев.

Я исправил эти недочеты, добавил кое-что интересное в скрипт, и получился StaticGenerator Pro.