Хабрахабр: Web-разработка / Блог / Захабренные Голосов: 1 Адрес блога: http://habrahabr.ru/blog/webdev/ Добавлен: 2008-06-12 19:52:21 блограйдером ZaiSL

Веб-разработка / Защищаем веб-формы от спама без CAPTCHA — 2: Ботобор

2012-02-28 20:14:49 (читать в оригинале)

Три года назад на Хабре была опубликована статья «Form Spam Bot Blocker: Защищаем Web-формы без CAPTCHA!», рассказывающая о принципиально отличном от CAPTCHA решении для PHP по защите форм от спам-ботов. Это решение основано на идеях, изложенных в своих статьях Филом Хааком (Phil Haack) — Honeypot Captcha и Недом Батчелдером (Ned Batchelder) — Stopping spambots with hashes and honeypots. К сожалению, предложенный в статье класс, написан для PHP4 и не развивается с 2007-го года. Хочу предложить вашему вниманию его аналог на PHP5.

---

Техническое задание на сайт

2012-02-28 17:23:36 (читать в оригинале)

Хабы: Веб-разработка

Не так давно на хабре были две статьи (Согласно техническому заданию и А зачем мне ТЗ? Я и так знаю!) посвященные техническим заданиям. У меня обе статьи вызвали, мягко говоря, недоумение, в особенности статья «Согласно техническому заданию». На мой взгляд, это вообще вредная статья, которая приводит к неверному понимаю сути ТЗ. В связи с этим хочу выразить свой взгляд на этот вопрос. Не буду говорить обо всех тех. заданиях, слишком широка тема, но думаю смогу рассказать о ТЗ на сайт.

То описание технического задания, о котором речь пойдет ниже, не является пересказом ГОСТа, но скорее является его творческой переработкой, хорошо сдобренной горьким опытом. Описанный ниже подход к ТЗ не охватывает все аспекты сайтостроения, но задает общее направление.

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

1. Обоснование необходимости ТЗ

А зачем вообще нужно ТЗ на сайт? Заказчик говорит: «Нужен следующий сайт: каталог товаров, корзина, форма заказа, доставка, мы на карте, о нас, обратная связь». Что не ясно? Ничего необычного, всё обыденно и рутинно.

Разработчик отчетливо представляет, что нужно сделать, а сделать, в его понимании нужно вот так:



Далее много букв

---

Веб-разработка / Техническое задание на сайт

2012-02-28 17:23:36 (читать в оригинале)

Не так давно на хабре были две статьи (Согласно техническому заданию и А зачем мне ТЗ? Я и так знаю!) посвященные техническим заданиям. У меня обе статьи вызвали, мягко говоря, недоумение, в особенности статья «Согласно техническому заданию». На мой взгляд, это вообще вредная статья, которая приводит к неверному понимаю сути ТЗ. В связи с этим хочу выразить свой взгляд на этот вопрос. Не буду говорить обо всех тех. заданиях, слишком широка тема, но думаю смогу рассказать о ТЗ на сайт.

То описание технического задания, о котором речь пойдет ниже, не является пересказом ГОСТа, но скорее является его творческой переработкой, хорошо сдобренной горьким опытом. Описанный ниже подход к ТЗ не охватывает все аспекты сайтостроения, но задает общее направление.

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

1. Обоснование необходимости ТЗ

А зачем вообще нужно ТЗ на сайт? Заказчик говорит: «Нужен следующий сайт: каталог товаров, корзина, форма заказа, доставка, мы на карте, о нас, обратная связь». Что не ясно? Ничего необычного, всё обыденно и рутинно.

Разработчик отчетливо представляет, что нужно сделать, а сделать, в его понимании нужно вот так:

---

Веб-разработка / [Из песочницы] Начала отладки и профилирования веб-приложений

2012-02-28 12:23:00 (читать в оригинале)

Вступление

Много существует статей на Хабре, описывающих интересные и сложные аспекты веб-разработки, но много существует читателей, которые, находясь в начале своей карьеры веб-разработчика, хотели бы видеть материал, который позволил бы сделать первый шаг от «PHP за 24 часа» до разработки на серьезном уровне, и я хотел бы поделиться своим опытом в этом деле.

Особенности веб-приложения делают его разделенным на две части: клиентскую и серверную. На стороне клиента работает код на JavaScript (может быть, где-то можно найти и VBScript, но мы, пожалуй, не будем рассматривать этот случай), на серверной же — много что, в принципе, но мы рассмотрим PHP, наиболее популярный язык для серверной части веб-приложений. Так же интересно было бы поговорить об отладке и профилировании Flash-приложений на клиентской стороне, но затронутая тема и так обширна, так что пока оставим это.

Так же можно отнести к задачам отладки клиентского кода анализ и валидацию HTML кода. Это, вроде бы, задача не совсем из области программирования, но также немаловажная.

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

---

Веб-разработка / Решение проблемы с появлением 8080 порта в ISP manager (настройка редиректа на 80 порт)

2012-02-28 11:01:35 (читать в оригинале)

Сегодня столкнулся с проблемой — обнаружилось, что по ошибке старого системного администратора, в одном очень редком случае у нас происходил редирект с обычного 80 порта на порт 8080.

Из-за этого в индекс яндекса попала целая куча страниц, имеющих адрес example.com:8080, потому что проблема существовала уже 3 года, а заметили ее только сейчас.

Проблема усугублялась тем, что сервер конфигурировался автоматически с помощью ISP manager, что привело к тому, что сайты были доступны как по адресу example.com, так и по example.com:8080, и с учетом того, что к серверу было привязано 5 ip-адресов и на нем крутилось около 20 сайтов, переконфигурировать все вручную чтобы сконфигурировать правильным способом апач и nginx (сделать, чтобы апач слушал только 127.0.0.1 и чтобы они висели на одном порту с nginx, а внешние адреса слушал только nginx) не представлялось возможным. Проблеме потенциально подвержены все сайты, которые пользуются ISP manager, поэтому я считаю ее достаточно актуальной, и решил опубликовтаь свое решение, чтобы все тоже проверили и исправили, если надо.

Соответственно стояла задача — «малой кровью» сделать:
1. чтобы сайт example.com корректно работал, но не открывался по адресу example.com:8080
2. чтобы с порта 8080 для одного определенного сайта шел редирект на 80 порт, чтобы сохранить работоспособность страниц, попавших в выдачу яндекса.