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

Как мы стали Дедом Морозом. Новогодние грабли. Часть 1

2013-11-26 17:38:17 (читать в оригинале)



Приветствую вас, мои дорогие мальчики и девочки! Хорошо ли вы себя вели в этом году?..

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

Начало

Все началось в прошлом году, месяца за 4 до Нового года. Нам очень захотелось получить плюс в карму сделать что-то хорошее. И так как у нас уже была заготовка для похожего проекта, было принято решение разработать и запустить ресурс, позволяющий отправить «письмо от Деда Мороза».
Читать дальше →

---

Продающий дизайн интернет-магазина. Часть 3. Дизайн элементов

2013-11-26 15:19:16 (читать в оригинале)

Третья часть статьи из цикла «Продающий дизайн интернет-магазина». Для тех, кто пропустил первую и вторую, их можно прочитать тут: «Продающий дизайн интернет-магазина. Часть 1. Аналитика» и «Продающий дизайн интернет-магазина. Часть 2. Элементы интерфейса».

Страница товара

Попав на страницу товара, человек должен получить максимум информации о нем. Здесь не работает правило «краткость – сестра таланта». Так как мы имеем дело с онлайн магазином, то наш покупатель лишён возможности увидеть товар вживую, поэтому мы и должны предоставить ему максимум имеющейся у нас информации: детальное описание, технические характеристики, качественные фотографии, отзывы, видео или 3D-обзор. Отзывы для товаров, кстати, изобрел Амазон, внес социальность на сайт, сильно увеличив тем самым конверсию и продажи.

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


Читать дальше →

---

Создание игрового калькулятора на примере игры Aion

2013-11-25 21:03:15 (читать в оригинале)

Введение

Любой кто увлекается программированием играя в игру всегда хочет прикрутить туда что-то своё или сделать что-то полезное. Кто-то делает модификации игры, кто-то трейнеры или читы, кто-то вики или фансайты. Не обошло это увлечение стороной и меня.
Играю в настоящий момент в ММО Aion: Tower of Eternety (далее для простоты “Аион”) от корейского разработчика NCSOFT. Именно про неё и пойдёт разговор.

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

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

Третье — различного рода “читерские” приспособления. К чести разработчиков чего-то действительно стоящего простой модификацией ресурсов игры получить нельзя, всё перепроверяется сервером и на клиенте циферки скорее для справки пользователю и синхронизации действий на экране с расчётами на сервере. Можно побаловаться увеличением размеров каких либо неприметных объектов в игре, например сундуки сокровищ или именных монстров. Но это чревато глюками и опять же нарушает ПС как и п.2.

Остаётся творить вне игры, но на её тему, но нас, конечно же, интересует то, что можно закодить, а не фанарты или статейки. Баз разной степени актуальности и паршивости по аиону в интернете предостаточно. А вот чего действительно не было до меня — так это калькулятора экипировки персонажа, по крайней мере, онлайн версии мне не попадалось. С вводом новых классов в игре стали также неактуальны существующие калькуляторы умений (стигм). Калькулятор экипировки достаточно сложный чтобы с него начать разбор, поэтому поговорим сначала про умения.
Основные шаги, рекомендации и комментарии

---

Идеальный сайт – ТЗ как основа работы сайта, построенного на базе грамотных программных решений

2013-11-25 18:53:03 (читать в оригинале)

Идеальный сайт – ТЗ как основа работы сайта, построенного на базе грамотных программных решений

Представьте себе, что Вы как владелец некой компании заказываете сайт компании у студии разработчика. Ситуация вполне стандартная и развивающаяся по стандартному сценарию. Читать дальше →

---

[Из песочницы] Pointer события

2013-11-25 14:09:30 (читать в оригинале)

В каждой избушке — свои игрушки

До некоторого момента front-end разработчик при написании javascript кода, рассчитанного на взаимодействие с пользователем, ориентировался лишь на «мышиные» события. Затем появились различные устройства, которые использовали другие формы взаимодействия пользователя с приложением — сенсоры или перо. Типы событий для каждого устройства были предложены индивидуальные. Так, кроме mousedown, mousemove итд., появились touchstart, touchmove и другие события.

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

• События мыши возникают только после сенсорных;
• Наведение мышью (mouseover) и другие аналогичные события не сработают без прикосновения к устройству. Обработчики таких событий должны быть запущены по умолчанию или их нужно заменить на событие 'click' по элементу;
• События по щелчку не будут запущены при изменении DOM дерева документа;
• События по щелчку срабатывают не сразу, а, приблизительно, через 300 мс;
• Touch и mouse события, в некоторых случаях, конфликтуют между собой.

В результате, front-end разработчику при написании приложения приходится обрабатывать несколько видов событий, события мыши на десктопных ПК и touch события для сенсорных устройств. Код становится громоздким, процесс разработки — трудоемким… Читать дальше →