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

Мне часто приходится сталкиваться с задачами организации A/B тестирования в различных интернет-проектах. В этой статье хочу поделиться необходимыми базовыми знаниями для проведения тестов и анализа результатов.

AngularJS молод и горяч, когда дело доходит до современной веб разработки. Его уникальный подход к компиляции HTML и двусторонней привязки данных делает его эффективным инструментом для создания клиентских веб приложений. Когда я узнал что Quick Left (студия в которой работает автор. прим. пер.) будет использовать его для создания приложения для одного из наших клиентов, я был взволнован и постарался узнать о angular столько сколько мог. Я обошел весь интернет, каждый урок и руководство, которые смог найти в Google. Они были реально полезны в понимании работы директив, шаблонов, компиляции и цикла обработки событий (digest), но когда дело дошло до тестирования, я обнаружил что эта тема была просто упущена.

Я обучался подходу TDD (Разработка через тестирование) и я чувствую себя не в своей тарелке без подхода «Красный-Зеленый-Рефакторинг». Так как мы все еще разбирались что к чему в тестировании в Angular, команде иногда приходилось полагаться на подход «тестирование-после». Это начало нервировать меня, поэтому я решил сосредоточится на тестировании. Я потратил на это недели, и в скором времени покрытие тестами поднялось с 40% до 86% (Кстати, если вы еще этого не делали, можете попробовать Istabul для проверки покрытия кода в вашем JS приложении).

В свете последних топиков, в том числе «Autodesk не будет продавать ПО попавшим под санкции компаниям», появляется ощущение, что маховик абсурда все сильнее раскручивается. Мы не будем осуждать в этом топике политические причины всего этого безобразия, а подумаем немного о том, что произойдет, если внезапно «выключат Google», причем неважно с какой стороны. Также предлагаю рассмотреть один из вариантов забрать себе накопленный контент, используя открытое ПО.

Для начала давайте подумаем, что является наиболее ценным для большинства пользователей сервисов Google? В первую очередь, это личный контент, который хранится в облаке, почта и другие материалы. Во вторую очередь, это сервисы, которым нужно найти замену в кратчайшие сроки. Мы не будем рассматривать нужды профессиональных разработчиков под Android и корпоративные нужды.

Перевод статьи «3 New JavaScript APIs You May Want to Follow», Aurelio De Rosa из портала SitePoint.

Если вы постоянный читатель SitePoint, и возможно, читаете мои заметки, то вы знаете, что я написал множество статей о новых HTML5 и JavaScript API. До сих пор я писал заметки об API, которые вы можете использовать прямо сейчас, в том числе с использованием полифилов.

Сегодня я решил нарушить это правило и описать вам несколько API на ранней стадии разработки. Эти технологии настолько свежи, что 2 из 3 были представлены всего несколько дней назад. Поэтому они пока не могут быть использованы. Однако, если вам интересно, что они позволят сделать, вы можете почитать спецификации и написать, что бы вы хотели в них улучшить.

Давайте же, без лишних церемоний, начнем!

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

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

Вот прямо сейчас кончаются времена, когда многие делали форменную туфту для получения лёгких денег по аналогу бума доткомов. И заявляли, что «начнём мы, когда найдем инвестора». Модель была простая: бралась идея с потолка, по ней ничего не делалось, но находился инвестор. По возможности — лох, не особо смыслящий в IT. Полученные деньги вкладывались в прототип и массу пиара, затем разыскивался инвестор второго раунда. Дальше стандартно: «когда водка выпита, выясняется, что джип разбит…». И проект заканчивался.

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

Предыстория:

Имя большой опыт в разработке веб-сайтов (около 15 лет) и являясь программистом, я очень не люблю рутинную работу, стараюсь ее либо избегать, либо каким-то образом оптимизировать. Другими словами, если мне в какой-то момент необходимо заниматься наполнением контентом сайта (да, знаю, не царское дело программисту наполнять сайт, но случаи разные бывают), то я предпочту потратить пару часов на написание парсера входящих данных, чем часа 4 вколачивать эти данные вручную. И давно меня терзала проблема отсутствия удобного редактора для создания карт изображения. Конечно, можно нарисовать карту в Corel Draw или подобном, выгрузить в SVG и по быстрому переконвертировать в нужный формат, но меня давно интересовала возможность создания некоего редактора, который позволит, не загружая сторонние программы, прямо на сайте, по-быстрому загрузить изображение и выделить на нем нужную карту. Например, есть некое изображение здания, на котором необходимо выделить контур этажа и привязать к нему какие-то JavaScript-события или просто ссылку, вот как здесь:

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

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

Так же документация модульного кода гораздо более эффективна.

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

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

Существуют хорошо зарекомендовавшие себя библиотеки способные решить большинство поставленных задач и избежать отрицательных моментов. Одной из наиболее популярных библиотек для написания модульных приложений на яваскрипт является RequireJS. RequireJS хорошо документирована и касаться разработки с ее использованием в этой статье мы не будем. Рассмотрим подробнее как интегрировать RequireJS в Symfony2 с последующей оптимизацией созданных нами модулей. Для подобной цели очень кстати может оказаться HearsayRequireJSBundle, так что, какая проблема, берем бандл инсталлируем через компоузер и все! Возможно у кого-то так и получилось, однако могли возникнуть и некоторые нюансы. Чтобы максимально сгладить процесс знакомства с подобной интеграцией предлагаю прочесть то, что изложено ниже.

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

Это устройство — беспроводный динамик Om One, который поставляется вместе с док-станцией.

В этой статье мы соберём вместе aiorest + jinja2 + angular.js + gulp.js + bower.js + nginx. В результате мы получим:

• авто-перезапуск сервера при изменении python-кода и jinja-шаблонов
• сборка, минификация и автоматическая пересборка при изменении клиентского js-кода

Начнём с главного — как пользоваться, а затем я подробнее опишу некоторые моменты реализации. Если вам легче читать код — вот ссылка на репу.

Обсуждение начну с весьма печального твита Криса Аллена (Chris Allen, @bitemyapp):

«Мне немного грустно от того, что некоторые организации твердят мантру „Вы сможете использовать haskell“, чтобы заполучить толковых инженеров подешевке».

— Untyped is unsane ( @bitemyapp) 3 июня 2014 г.

Для тех, кто не знает: Haskell — продуктивный и мощный язык, позволяющий программистам, по крайней мере талантливым, быстро писать правильный код. По сравнению с разработкой на Java скорость возрастает в 2–5 раз при сопоставимой производительности и меньшем количестве ошибок. Крис совершенно верно заметил, что разработчик, использующий Haskell, чаще всего не получает достойного вознаграждения. Если вы твердо решили использовать функциональное программирование, то будете зарабатывать меньше коллег, которые разгребают базы кода C++ в банках, накопленные за 30 лет. Как-то это все неправильно. Почему к программистам, применяющим более мощные инструменты, применяются экономические санкции? В отличие от управленцев, ставящих во главу угла выгоду, программисты действительно хотят сделать свою работу как можно лучше. Почему же вместо «пряника» за благие намерения они получают «кнут»?

Дом — это машина для жилья

_{Ле Корбюзье}

В этом посте я расскажу об opensource проекте домашней автоматизации openHAB.
openHAB переводится как "Open Home Automation Bus". Это значит, что он нацелен на создание универсальной платформы для объединения всей домашней «умной» техники в единую систему управления.

Что же это дает на практике? Под катом я расскажу о том, как с помощью этого решения можно создать настоящий интернет вещей в своем доме.

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

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

Наверное, каждый, кто использовал JavaScript, когда-либо сталкивался (или столкнётся в будущем) с асинхронными вызовами. Может быть, это будет обращение к базе на стороне сервера. Может быть — работа с таймером для создания анимации на сайте.

Для того, чтобы «побороть» асинхронность, используются разные инструменты от промисов до смены языка программирования. Но иногда очень хочется бросить всё и написать на чистом JS линейный код:

timeout(1000);
console.log('Hello, world!');

Можно ли реализовать нечто подобное? Разумеется, можно.
В данной статье мы рассмотрим один опасный, но действенный способ.

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

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

Так как работаю программистом и значительную часть работы выполняю дома — для себя создал два рабочих места, на втором их которых работаю до сих пор. Далее опишу их с подробностями и сделанными выводами. Полагаю, интересно будет людям, которые работают удалённо или фрилансерам.

В сентябре прошлого года компания Google выпустила Web Designer — бесплатную программу под Windows, Mac и Linux, с помощью которой можно разрабатывать интерактивные HTML5-приложения, сайты и баннеры. С тех пор программа несколько раз обновлялась, но вчерашний апдейт является самым значительным.

Эта статья появилась на свет после прочтения материала «Почему вы никогда не должны использовать MongoDB». Ниже — история о том, как мы постепенно отказались от MySQL и пришли к использованию MongoDB в качестве основного хранилища данных.



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

Первым делом были сформулированы:

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

На западе есть такой термин “портфель простака”, “портфель лежебоки”. Пусть я простак (это предположение недалеко от истины) и у меня нет экономического образования. Я выбираю, куда можно инвестировать. Какие рынки мне могут прийти в голову? Их не так-то много:

Вы знаете, что такое Selenium и/или PhantomJS? И с чем их едят? Тогда, возможно, вам будет интересен проект Dalek.js — кроссбраузерная утилита для тестирования веб-приложений.

Dalek.js позволяет писать тесты, которые ходят по веб-страничкам, щелкают ссылки, заполняют формы, отправляют данные и делают скриншоты. То же самое и даже больше делают тесты, написанные с использованием Selenium'а или Phantom.js, в чем подвох?

Дорогие Хабролюбители, всем привет! Не откроем Америку если скажем, что существуют сотни плагинов и библиотек, которые облегчают специализированные задачи, связанные с построением современных web интерфейсов. Angular один из них, про его производительность писалось много и в большинстве случаев даются рекомендации чего не нужно делать, чтобы все было хорошо.

Основной аргумент сторонников — медленно работают неправильные приложения, а вот правильные не должны содержать более 2000-3000 элементов. Если содержит больше значит что-то не так. См. например http://iantonov.me/page/angularjs-osnovy.

Аргумент в общем вполне здравый, но всегда есть ситуации, когда нужно написать «неправильное» web приложение потому, что такие требования. В этой статье мы решили рассказать как раз про такую задачу, и как мы ее решили. На наш взгляд статья будет полезна в большей степени профессиональным веб разработчикам. Итак, наша задача была сделать календарь для системы бронирования для одного спортивного клуба. Календарь отображает семь 12–часовых блоков, каждый день из которых разделен на 15 минутные интервалы. В блоке может быть от 2-х до 10 DOM элементов. Вроде ничего не предвещало беды, верхняя граница ~3000.

Доброго времени суток, уважаемые хабравчане!

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

Итак, к делу.

Задача и проблемы

Проблемы — те же что и в посте, который я привел выше:

• Невозможность использовать window.location для «приготовления» URL;
• Нельзя работать сразу с несколькими window.location в силу политики безопасности браузеров;
• Отсутствие известных готовых решений ( да и сейчас, уже апосля, я не нашел подобного кода )

Задачи которые я поставил перед собой:

• Удобный синтаксис
• Возможность как читать части URL так и изменять их
• Работа с GET-параметрами
• Кроссбраузерность и универсальность

Писал я на чистейшем JavaScript, причем без использования prototype.__defineGetter__ или prototype.__defineSetter__ в угоду кроссбраузерности ибо IE < 9 такого не умеет. Более подробно про getters/setters написано в этом посте.

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

Приступим! Раньше сядем — раньше выйдем.