WebMoney Transfer объявила о запуске принципиально нового и уникального продукта под брендом Keeper Embedded. Это бизнес-платформа для блогов, социальных сетей, онлайн-игр, сообществ, web 2.0 проектов.

Участники любого сообщества и социальной сети, будь то «Хабрахабр», Facebook или World of Warcraft, теперь могут одним нажатием мышки связать свой существующий WM-кошелек с аккаунтом в нужной им социальной сети.

После этого становится возможным проведение микроплатежей и взаиморасчётов внутри коммьюнити. Например, таким образом владельца «Хабрахабра» или Livejournal могут наладить автоматические платежи в пользу самых активных участников коммьюнити на сайте или организовать систему взаиморасчётов за карму. Весь биллинг берёт на себя WebMoney Transfer. Размер денежной комиссии и технические вопросы решаются в договорном порядке. По умолчанию владельцы сообщества получают процент от всех исходящих платежей своих юзеров.

В качества образца уже создан первый плагин Webmoney для социальной сети Facebook.

Обсуждая с участниками "Комедиады" заявленное ограничение на длину видео (3 минуты), я решил пойти и посчитать, а какова, собственно, средняя длительность роликов, попадающих к нам в чарт на VirusVideo.ru (там каждый день редакторы проходятся по топам видеохостингов, отбирают наиболее интересное и анонсируют — такой ежедневный чарт можно получать в рассылке). Посчитал за последние 8 дней, получилось, что средняя длительность — 1:47. А если брать не среднее, а медиану, что корректнее — 1:17. Получается красивая цифра 77 секунд.
Я спросил коллег из Rutube, какая статистика по топам у них. Если брать активные ролики, то медиана для верхних 10% по числу просмотров и оценкам — 71 секунда. Если брать топ 1% только по рейтингу — 60 секунд, только по просмотрам — 109 секунд.
Мораль: 3 минуты — слишком долго для вирусного ролика. Оптимальная длительность — от одной до полутора минут. Впрочем, наша цифра 77 мне нравится больше всего — она круглая. И у нас в рейтинге не только Rutube, но и Youtube (и западные ролики), и немного других хостингов. Теоретически для нас и американцев данные могут отличаться. Впрочем, 71 или 77 секунд — это уже в пределах погрешности.

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

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

1. Главная страница выглядит блекло и безлично
Что видит ваш посетитель, попадая на главную страницу магазина? Может ли со 100% уверенностью сказать, что это интернет-магазин? Может ли он узнать, чем торгует этот магазин? Типичной ошибкой является пренебрежение к законам коммерческого дизайна. Помимо мелкого шрифта и отсутствия должного описания, часто не всегда удается найти центр композиции. Все тексты и картинки выглядят или второстепенным или же каждый элемент пытается «перекричать» соседний. Вспомните, как выглядит газета бесплатных объявлений, заполненная массой пестрых рекламных блоков.

Пожалейте время и глаза своего посетителя — он задержится дольше на вашем сайте и, возможно, сделает заказ.

2. Видны ли способы связи с менеджерами?
Одним покупателям проще прийти в магазин и самим отыскать товар на полках, другим же удобнее прямо с порога спросить продавца о наличии и стоимости. Даже если ваш магазин создавал профессиональный дизайнер, проконтролируйте, чтобы тем, кому удобнее позвонить или написать вам, изложив свои вопросы, не пришлось долго искать, как это сделать. Идеальным вариантом будет номер телефона, который всегда навиду. Например, в верхней части страницы.

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

За хорошие манеры можно принять наличие пункта об оплате и доставке на видном месте.

4. Удобны ли способы оплаты и доставки для вашего потенциального клиента?
Даже если информация о том, как оплатить, куда и за сколько вы доставите, висит на самом видном месте, ваш посетитель может уйти разочарованным из-за

Рекомендации по html-коду, вёрстке и немного — по копирайтингу. Актуально для февраля-2009

Это не очередной список «101 совет, как достичь идеала в том-то», которых полно в интернете. Это «инсайдерская информация» SEO-компании, ведущей более 600 проектов. Перечислено то, на что мы обращаем внимание, начиная поисковую оптимизацию. Разумеется, не всё получается реализовать (например, движок сайта что-то не позволяет, а где-то пункты противоречат(!) друг другу). Ничего страшного. Если больше половины рекомендаций получается реализовать, то это уже очень хорошо!

Склейка домена обычно происходит при необходимости переехать с одного домена на другой, например, при покупке нового более красивого адреса или попадания в бан одной из поисковых систем старого. Иногда же клеят в корыстных целях чтобы получить чужой тИЦ/PR, но сейчас о первом случае.

Хотелось бы сразу оговориться, что склейка домена занятие не трудоёмкое само по себе, но довольно нервотрепательное и долгое. И, на мой взгляд, без особой надобности её не стоит делать, ибо будут потери посещаемости.

Самым же неправильным методом переноса сайта на новый домен с минимальной потерей посетителей, на мой взгляд, будет следующий:

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

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

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

Итак, доступных для физических лиц систем оплаты в Украине ограниченное количество:

• Оплата картами Visa и MasterCard
• Предоплата банковским переводом
• Оплата наличными
• WebMoney
• Наложенным платежом

Инженеры из университета Осло создали эволюционный компьютер, который меняет свою конфигурацию с помощью генетических алгоритмов. Как и животным в настоящем мире, компьютеру требуется 20–30 тысяч поколений и мутаций, чтобы адаптировать дизайн к решению новой проблемы. Однако здесь процесс занимает не миллионы лет, а всего несколько секунд.

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

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

via Bits of News

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

Позитивным для блога являются:

• ссылки на блог в других блогроллах;
• ссылки на блог с других сайтов, которые не являются блогами;
• использование тегов для категоризации контента;
• PageRank;
• количество подписчиков на RSS блога;
• кол-во переходов со страниц результатов поиска и т.д.

Негативно влияют следующие факторы:

• публикация постов через короткие промежутки времени с чётким интервалом;
• контент блога отличается от содержания RSS;
• повышенное содержание ключевых слов, которые считаются «спамерскими»;
• большое количество дублирующегося контента;
• одинаковый или почти одинаковый размер постов;
• ссылки на один и тот же сайт во многих постах;
• большое количество рекламных блоков, баннеров и их расположение и т.д.

via

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

В заявке на подбор персонала в требованиях я указываю обычно весьма простые вещи:
– Хорошее знание SQL (MySQL, если быть точным).
– Знание Perl или PHP (с желанием перейти на Perl).
– Базовые знания всего остального, что может пригодиться разработчику — хотя бы отличать HTML от CSS, Java от JavaScript и веб-сервер от браузера.

Почему так просто? Всё банально — как правило, мне не нужны гуру.
Проекты, над которыми работает мой отдел, не такие сложные, чтобы не справиться человеку с 2–3 годами опыта активной веб-разработки. Все сложности, с которыми придётся столкнуться в первые месяцы работы, вполне себе могут быть решены или мной, или системными администраторами.

После того, как заявка заполнена, одобрена начальником департамента и генеральным директором, отдел кадров начинает поиск подходящего человека.

Как характеризуют сервис сами разработчики, Moqups — это «изящное HTML5-приложение для создания макетов, концептов пользовательского интерфейса, прототипов, в зависимости от того, как вы сами это называете».



Для Chrome есть отдельное приложение.

На данный момент доступно более 60 шаблонов элементов, экспорт в PDF и PNG, клавиатурные шорткаты, группировка объектов, привязка к сетке и проч.

Проект находится в стадии активной разработки и открыт для критики, помощи и предложений.

Дисклеймер: если после прочтения этого текста вы захотите внедрить KPI для программистов — сходите прочитать еще и это.

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

Итак, какие цели преследует аттестация.

Сегодня в продолжение наших рассказов о семантической разметке я хочу рассказать о её синтаксисе. То, почему он такой, а не иной, часто определяется историческими причинами, а иногда — ещё и комично. Поэтому мы попробовали здесь всё систематизировать и объяснить.

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

Словарь — это своеобразный «язык», набор классов и их свойств, с помощью которых указывается суть содержимого на странице. О них мы писали в предыдущей статье. Синтаксис — это способ использования словаря. Он определяет, с помощью каких тегов и как будут указываться сущности и их свойства, например, на веб-страницах.

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

• Microdata — Микроданные (словарь Schema.org чаще всего встречается именно в этом синтаксисе);
• Microformats.org — Микроформаты (напоминаем, что это объединенный стандарт синтаксиса и словаря);
• RDFa и RDFa Lite (в упрощенном виде RDFa рекомендуется создателями словаря Open Graph. Также встречается с другими словарями, например, со словарем Dublin Core или Data Vocabulary);
• JSON-LD — расширение JSON.

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

Once upon a time В 2004 году разработчики из W3C создали стандарт, который, по их мнению, подходил для «представления всего в мире». Так появился синтаксис RDFa (Resourse Description Framework in attributes), который позволяет однозначно транслировать HTML-разметку с семантическими данными в RDF.

Добрый день, уважаемое сообщество!

Существует большое количество малых и «маленьких, но гордых» организаций, которые при всей своей простоте вынуждены пользоваться определенной IT инфраструктурой. Хочу поделиться с вами некоторыми выводами по внедрению в них свободного ПО (СПО) и Линукса, которые я вынес для себя на базе многолетнего положительного опыта в этой области.

Слепок типичного заказчика

Обычно существовавшее изначально положение вещей характеризовалось следующим:

1. Организации с количеством компьютеров от 1 до 50 предпочитали использовать проприетарные решения для ОС одной хорошо всем известной заатлантической конторы.
2. Денег на покупку лицензий всегда не было. Предпочитали использовать «пиратчину».

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

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

Основные рекомендации и ввод данных

• Стремитесь к краткости.
• Убедитесь, что в форме используется один язык (обороты, термины).
• Если на странице находится только форма и ничего кроме нее, то при загрузке страницы стоит ставить фокус на первое поле формы, это позволит сэкономить немного времени (страница поиска, входа, регистрации).
• Поддерживайте ясный путь заполнения формы.
• Избегайте вторичных действий, если это возможно.
• В противном случае четко разделяйте основное и дополнительные действия.
• Выравнивайте основное действие так же как и поля формы, это упрощает восприятие формы.
• Цветная подложка у главной кнопки сделает её более видимой.
• Отключайте кнопку «Отправить» после того как пользователь на нее нажал, это позволит избежать двойной отправки данных.
• Еще лучше — показывайте индикатор отправки.

Надеюсь, что данный материал будет кому-нибудь полезен.

Siege – это утилита для нагрузочного тестирования веб-серверов. Она была создана для того чтоб дать разработчикам возможность проверить ресурсоёмкость своего кода в условиях, максимально приближенных к реальным. Так же Siege может имитировать обращения к сайту сразу нескольких пользователей. Это позволяет держать сервер как бы «под осадой» долгое время. Количество запросов, произведённых при «осаде», рассчитывается из общего количества пользователей и количества их обращений к серверу. Например 20 пользователей, обратившись по 50 раз, создают в общей сложности 1000 запросов. Результат, выводимый программой после тестирования, включает в себя время затраченное на проверку, общее количество переданной информации ( включая заголовки ), среднее время ответа сервера, его пропускную способность и число запросов на которые пришёл ответ с кодом 200. Эти данные формируются и выдаются при каждой проверке. Подробно они описываются ниже. Siege имеет 3 основных модели работы – режим регрессионного тестирования, режим имитации Интернета и режим грубой силы. Программа считывает порцию ссылок из конфигурационного файла и обращается к ним по очереди ( режим регрессионного тестирования ) или случайно ( имитация интернета ). Или же пользователь может указать один единственный адрес к которому будут производиться все обращения – режим грубой силы.

UPD: спасибо за плюсы, перенес в тематический блог.

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

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

Сразу хочу сказать, что все книги на английском. Часть из них можно найти на русском, но без английского на уровне чтения и прослушивания подкастов будет тяжко – на русский клевые вещи об управлении продуктами переводят медленно и нехотя. Второй момент – чтение книг из этого списка не сделает из вас менеджера продукта. Как и книжка С++ за 21 день не сделает из вас С++ разработчика. Просто уровень вхождения в окологуманитарные профессии пониже, и это иногда создает напрасные иллюзии.

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

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

Довольно часто на сайтах е-коммерса нас просят реализовать фильтры. Хороший фильтр — довольно дорогая игрушка. Вообще, они не всегда уместны — пользователю проще посмотреть глазами на список, чем разбираться в логике разработчика фильтра. Конечно, если в этом списке не так много элементов. Скажем, не больше 200 в каждом разделе. Ниже в виде проверочного списка для наших QA, я зафиксировал некоторые требования, которые мы настойчиво внедряем на своих проектах с этого года. Стандартизация, ептэ.

Эти требования разумны. Часть из них трудно реализуема. Часть — очевидна. Часть — зависит от контекста. Но в целом они довольно универсальны. Если будут какие-то вопросы по конкретным пунктам — велкам в комментарии.

В последнее время в рунете появляется статей про технологию аукциона в реальном времени – Real-time Bidding (RTB). Пока эта тема больше обсуждается на специализированных ресурсах, поэтому я буду одним из первых, кто расскажет о ней на Хабре. Это подлинная, в том числе и технологическая инновация на рынке интернет-рекламы, с которой пора знакомить с ней тех, на кого она собственно нацелена: рекламодателей, покупающих рекламу в интернете, и площадки, зарабатывающие на продаже медийной рекламы и трафика (Habrahabr.ru, например :).

По прогнозам, расценки на медийную рекламу в интернете в 2013 году вырастут на 14 процентов, в то время как в среднем реклама подорожает на 10 процентов. Медийная реклама обгонит и другие инструменты интернет-рекламы – к примеру, контекстная реклама вырастет всего на 13%. На мой взгляд, драйвером этого роста станет именно RTB.

О том, как мы пришли к идее издания книги, я рассказал в предыдущем посте. А тут я постараюсь рассказать про взаимоотношения с издательствами и почему в итоге мы сами выступили в качестве издательства; про то, как искали, где печатать книгу, и несколько курьезных моментов из этого; про подготовку макетов книги; про взаимоотношения с типографией и, наконец, как происходила непосредственно сама печать книги.

Вот основные стадии книги — от замысла, до выхода в свет: