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

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



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

Сегодня мне пришел заказ от весьма крупной компании. Они просят реализовать на одном из их сайтов вот такое решение (орфография оригинала, названия изменены):

Пользователь на сайте заходит в «Калькулятор стоимости решения „ЗАО Рога и Копыта“.
Там он отвечает на 11 вопросов для расчета стоимости решения. После этого пользователю должно быть предложено заполнить свои ФИО, должность, название организации и email.
На указанный email должно быть отправлено уведомление: „По указанному адресу в скором времени Вам будет выслана стоимости решения “ЗАО Рога и Копыта», на основе заполненной на сайте rogaiko.pyta анкеты".
На нашу почту должены прийти контакты пользователя и ответы на вопросы. В течении суток мы рассчитываем решение и высылаем на указанный адрес.
(прим.авт. — средняя стоимость решения более миллиона рублей).

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

1. «Калькулятор» означает устройство, которое выполняет расчет и выдает результат сразу.
Называя онлайн-сервис «калькулятором», мы как бы обещаем пользователю, что после того, как он потратит свое время и заполнит анкету, он сразу получит важный для него результат.
Если это не так, если над ответом будут трудиться живые люди, и придет он через пару дней, то мы не должны обманывать пользователя, называя этот сервис «калькулятором». Этот сервис правильнее назвать «запрос ценового предложения». Это операция совершенно иного характера, и заниматься такими запросами будут совсем иные люди с иной целью.
Особенно вызовет раздражение пользователя ситуация, когда о том, что это на самом деле не калькулятор, он узнает лишь после того, как заполнит и отправит анкету.

2. Большинство пользователей настоящих онлайн-калькуляторов подсчитывают на них что-то, в основном, ради любопытства, пусть и не праздного. Для них это быстрый способ узнать, стоит ли им тратить время на общение с этой компанией, или нет, а если да, то можно ли как-то сэкономить на том или ином решении. Для этого они могут пользоваться калькулятором несколько раз, вводя разные параметры и сравнивая результаты. Делается это, как правило, без особой предварительной подготовки, и некоторые параметры пользователь может ввести с изрядной погрешностью, что называется, «от фонаря». Заниматься этим будет, вероятно, сотрудник невысокой должности и квалификации, либо просто частное лицо.
Факт использования калькулятора совершенно не означает готовности пользователя пойти дальше и сделать заказ. Калькулятор лишь облегчает ему процесс принятия решения. И возможность быстро, навскидку, сравнить несколько результатов ему в этом сильно помогает.

В большинстве случаев стандартные методы, генерируемые доктриной на основе Yaml (XML или аннотаций), хватает только на получение каких то полей по какому-то простому фильтру. Для более сложного запроса приходиться пользоваться нативным QueryBuilder'ом и обращаться через dql запросы к нашей модели. Все это является следствием нагромождения больших кусков кода, которые имеют свойства дублироваться там где требуется применить идентичные запросы. А как хотелось бы обращаться с моделью просто и красиво через один единственный метод? Как? Напишем свой!

Эта тема не относится к IT напрямую, но все знают, что без нее никуда. К сожалению, далеко не у всех есть возможность изучать английский с преподавателями. Ну что ж, попробуем заняться этим дома и с максимальной отдачей!

Чуточку ликбеза. Навеяно предшествующими копипастами разной чепухи на данную тему. Уж простите, носинг персонал.

IP-адрес (v4) состоит из 32-бит. Любой уважающий себя админ, да и вообще айтишник (про сетевых инженеров молчу) должен уметь, будучи разбуженным среди ночи или находясь в состоянии сильного алкогольного опьянения, правильно отвечать на вопрос «из скольки бит состоит IP-адрес». Желательно вообще-то и про IPv6 тоже: 128 бит.

Обстоятельство первое. Всего теоретически IPv4-адресов может быть:
2³² = 2¹⁰*2¹⁰*2¹⁰*2² = 1024*1024*1024*4 ≈ 1000*1000*1000*4 = 4 млрд.
Ниже мы увидим, что довольно много из них «съедается» под всякую фигню.

Записывают IPv4-адрес, думаю, все знают, как. Четыре октета (то же, что байта, но если вы хотите блеснуть, то говорите «октет» — сразу сойдете за своего) в десятичном представлении без начальных нулей, разделенные точками: «192.168.11.10».

В заголовке IP-пакета есть поля source IP и destination IP: адреса источника (кто посылает) и назначения (кому). Как на почтовом конверте. Внутри пакетов у IP-адресов нет никаких масок. Разделителей между октетами тоже нет. Просто 32-бита на адрес назначения и еще 32 на адрес источника.

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

Все началось, когда, в один прекрасный день, один сайт перестал открываться. Оказалось, что из-за загруженности сервера хостер решил перенести аккаунт на другой сервер. При этом не было уведомления ни до переноса, ни в то время, когда перенос начался. Это, конечно, было крайне некрасиво со стороны хостера, но не в этом суть. После переноса стали происходить странные вещи. Несколько дней стала наблюдаться следующая картина: при попытке отрыть любую страницу с сайта, она могла либо открыться моментально (как обычно), либо могла не открыться вовсе. Шанс на успех был примерно 50%. Я написал по этому поводу хостеру и посмотрел загрузку процессора, она оказалась феноменальной. В среднем за день выходило около 500% от отведенной мощности, а в некоторые часы загрузка была выше 1000%. До переноса среднесуточная нагрузка была в районе 50-60%.