Кто виноват?

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

Вот некоторые примеры таких ситуаций:

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

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

Предположим, что у нас есть 100 млн. долларов, которые нужно вложить в несколько возможных инвестиций. Каждое из этих вложений имеет различную стоимость и различный ожидаемый доход. Мы должны решить, как потратить деньги, чтобы получить максимальную прибыль.
Задачи такого типа называются задачами формирования портфеля. У нас есть несколько позиций (инвестиций), которые должны поместиться в портфель фиксированного размера (100 млн. долларов). Каждая позиция имеет свою прибыльность. Необходимо найти набор позиций, которые помещаются в портфель и дают максимальную прибыль.
Многие из вас скажут, что никакие эвристики тут не нужны, и что вполне можно обойтись полным перебором. Другие заявят, что и полный перебор не нужен, ведь существует метод ветвей и границ. Но как быть, если количество возможных инвестиций 65? Полное дерево решений содержит более 7*10^19 узлов. Предположим, что метод ветвей и границ перебирает десятую часть процента этих узлов, а компьютер проверяет миллион узлов в секунду. В этих условиях для решения задачи потребовалось бы более 2 млн. лет. Именно для таких сложных задач и используются эвристики. Если вам интересно, милости прошу под кат.

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

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

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

Если вы эксперт по разработке пользовательских интерфейсов и юзабилити, если количество разработанных вами лэндингов больше 10, если вы уже прочитали сотню статей по этой теме с рекомендациями профессионалов — наш пост не для вас. Он скорее для тех, кто только начинает…



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

Стили

User Agent

Один из способов включения стилей для мобильного устройства — это использование User Agent, которую получает сервер от клиента.
Этому может помочь набор скриптов: code.google.com/p/mobileesp, а также сервис от яндекса api.yandex.ru/detector
При работе с User Agent только одна проблема — это постоянно появляющиеся новые User Agent.

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

Эта история началась два долгих года назад, когда во время командировки в США я ВДРУГ остался без мобильной связи: с дуру перед поездкой поменял телефон, а он оказался «двух-диапазонником»… Да и роуминг не дешёвый…
Итогом стало открытие для себя SIP-телефонии.

И вот несколько месяцев назад, из статей на Хабре, выясняю, что чужим дядям можно и не платить за межгород, если надо позвонить откуда-то в родной город через Интернет! Достаточно поставить VoIP сервер и настроить его так, как надо именно тебе!

И вот, взяв в руки Asterisk, я приступил к операции по борьбе с излишней жадностью ОпСоСов…

Условия

Мы используем MySQL для хранения любых данных FriendFeed. Наша база данных растёт вместе с числом пользователей. Сейчас у нас более 250 миллионов записей, это записи пользователей (post'ы), комментарии, оценки («likes»)

По мере того как росла база данных, мы время от времени имели дело с проблемами масштабируемости. Мы решали проблемы стандартными путями: slave-сервера, используемые только для чтения, memcache для увеличения пропускной способности чтения и секционирование для увеличения пропускной способности записи. Однако, по мере роста, использованные методы масштабируемости привели к затруднению добавлению новой функциональности.

В частности, изменение схемы базы данных или добавление индексов к существующим 10-20 миллионов записей приводили к полной блокировке сервера на несколько часов. Удаление старых индексов требовало времени, а не удаление ударяло по производительности, так как база данных продолжала использовать их на каждом INSERT. Существуют сложные процедуры с помощью которых можно обойти эти проблемы (например создание нового индекса на slave-сервере, и последующий обмен местами master'a и slave), однако эти процедуры настолько тяжелые и опасные, что они окончательно лишили нас желания добавлять что-то новое, требующее изменение схемы или индекса. А так как наши базы сильно распределены, реляционные вещи MySQL как например JOIN никогда не работали для нас. Тогда мы решили поискать решение проблем, лежащее вне реляционных баз данных.

Существует множество проектов, призванных решить проблему хранения данных с гибкой схемой и построением индексов на лету (например CouchDB). Однако, по-видимому ни один из них не используется крупными сайтами. В тестах о которых мы читали и прогоняли сами, ни один из проектов не показал себя стабильным, достаточно зрелым для наших целей (см. this somewhat outdated article on CouchDB, например). А все это время MySQL работал. Он не портил данные. Репликация работала. Мы уже в достаточной мере понимали все его узкие места. Нам нравился MySQL именно как хранилище, вне реляционных шаблонов.

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

Примечание: мини-статья написана для новичков

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

Знакомьтесь — Джон, владелец достаточно крупного сайта, маркетолог, считает себя умным, профессиональным, и к тому же уверен, что умеет четко излагать свои мысли. При всем этом, Джон не так уж много знает о веб-дизайне и разработке, поэтому ему нужна ваша помощь. Джон обращается к вам с целым набором четких маркетинговых целей и просит вас назвать цену своей работы.

Всегда объясняйте клиенту, зачем вы спрашиваете о бюджете

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

Джон, в свою очередь, с подозрением относится к вашему вопросу. Зачем вам знать о его бюджете? Единственная убедительная причина, которая приходит ему в голову – вы не хотите случайно назвать цену меньше той, которую он готов заплатить. Кроме того, он и сам не знает, какой у него бюджет. Откуда ему знать, сколько стоит сайт?


Клиент не должен думать, что вы выманиваете у него деньги.

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

Для вывода в лог (да и не только для этого, но это то, с чем я сам столкнулся) нужно конвертировать значение переменной в строку.

В C++ это обычно делается выводом в поток (как вариант — использование boost: lexical_cast<> — что в нашем случае практически одно и тоже).

Для встроенных типов это не проблема, а вот как быть, если нужно вывести скажем std: vector? Увы, но у std: vector нет оператора вывода в поток.

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

Абсолютные числа большого смысла не имеют, но как сравнение информация представляет некоторую ценность

Условия

Windows 7 x64 с обновлениями
AMD Athlon X2 4600+ (2.41ГГц)
DDR2 2Гб
.Net Framework 3.5, классы из FCL.
Два 64-битных процесса без дополнительных привилегий.
Антивирус Касперского выключен. С ним результаты сокетов существенно хуже.
Сокеты и именованные каналы в асинхронном режиме.
Размеры буферов подбирались оптимальные, эксперементально для каждого вида IPC.

С mod_rewrite есть одна проблема, об которую набиты уже наверное 15 миллионов шишек: он просматривает список правил снова и снова, пока URL удается хоть как-то изменить.

Очень часто получаеются и бесконечные циклы(например добавление расширения — оно добавляется снова и снова, если специально регэкспом не ограничить), над которыми с непривычки приходится поломать голову. Все надежды на модификатор [L] тщетны — он лишь сразу запускает следующую иттерацию обработки. Да и без бесконечного цикла лишние иттерации скорости работы не добавляют :-)

Хочу поделится достаточно простым и универсальным средством борьбы с такой особенностью, который обнаружил только-что :-)

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

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

1. Часть ЧПУ (человекопонятный URL)

По сути, слово с дефисами.

Паттерн: /^[a-z0-9-]+$/

Добрый день, коллеги!

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

Несколько позже, чем хотелось, но продолжаем наш разговор о получении текста из разных форматов данных. Мы с вами уже познакомились с тем, как работать с изначально XML-base файлами (docx и odt), прочитали текст из pdf, преобразовали содержимое rtf в plain-text. Теперь перейдём в вкусненькому да сладенькому — формату DOC.

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

Ниже предлагаются простые 5 шагов, с которых можно начать, на примере сайта WHOIS Digger.

Шаг 1. Аналог favicon.ico

Когда пользователь создает ссылку на ваш сайт в виде иконки в SpringBoard, iPhone автоматически формирует картинку из скриншота страницы. В результате почти всегда получается неразборчивая каша, которая на гордое звание «иконки для iPhone» никак не тянет. Пропишите этот тег в заголовке страницы:

<link rel="apple-touch-icon" href="res/iphone_icon.png" />

и добавьте соответствующую картинку res/iphone_icon.png размером 57х57 пикселов. iPhone сам добавит скругленные углы и полукруглый блик, сделав вашу иконку похожей на остальные.

Вот так выглядит исходная картинка и иконка на рабочем столе iPhone:

Email

• Swift Mailer
  Swift Mailer легко интегрируется в любое PHP-приложение. Это гибкий и элегантный ООП-подход к отправке писем с множеством функций: отправка эл.почты, используя SMTP, SendMail, Postfix, поддержка серверов и др.
  
• PHPMailer
  Лучший класс для работы с эл. почтой. Поддерживает сообщения в цифровой форме, S/MIME шифрование, текстовые и HTML-письма, изображения, поддерживает несколько Email’ов, SMTP-аутентификация.
  

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

Попробуйте быстро ответить на вопрос, чему равно следующее выражение:

foo = 'bar' and foo != 'bar'

Если ваш ответ — false, автор предлагает