Пользователь когда-то подписался на рассылку, но уже забыл когда, и главное зачем. Теперь ежедневно к нему падает спам, а по собственному опыту он знает, для того чтобы отписаться нужно зайти по ссылке свой профиль, найти и снять там какую-то галку а главное, помнить свой логин и пароль на давно забытом им сайте.
Его действия? «В спам!»

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

И вот, с десяток таких «отписок» и гугл будет удобно отсортировывать ваши рассылки в папочку Спам (584), у ВСЕХ ваших подписчиков.

Однако многие из нас уже успели заметить: некоторые письма в Gmail при попытке отметить их «В спам!» САМИ предлагают отписаться от рассылки в один клик.

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

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

Что такое спам? Это 80% почтового трафика в интернете и 20% эффективности. Обычная, грамотно сделанная email рассылка, будет в разы эффективнее. Но даже с самыми благими намерениями всегда есть риск попасть в чистилище папки «Нежелательная почта». Чтобы этого избежать, нужно учитывать ряд нюансов.

Как обычно, саммари в начале статьи и дальше — подробные пояснения. Итак, 9 простых правил:

1. Не занимайтесь спамом
2. Спрашивайте у адресатов согласия на рассылку
3. Обновляйте ваши базы адресов
4. Не используйте покупные базы
5. Храните подтверждения о законности вашей базы
6. Давайте возможность отписаться прямо из рассылки
7. Не повторяйтесь
8. Красиво и грамотно составляйте письма
9. Учитывайте требования спам-фильтров

Обычно, если вам требуется сделать блок с ползунком или даже что покруче — с выбором диапазона, то используем готовый плагин из набора jQuery UI — slider().



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

JavaScript может быть кошмаром при отладке: некоторые ошибки, которые он выдает, могут быть очень трудны для понимания с первого взгляда, и выдаваемые номера строк также не всегда полезны. Разве не было бы полезно иметь список, глядя на который, можно понять смысл ошибок и как исправить их? Вот он!

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

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



— А, что ж так темно-то, Господи? © День радио.

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

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

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

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

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



Декларируют техподдержку многие. Делать системно и рентабельно умеют единицы. Этот текст скорее для студий (чтобы они могли улучшить свои процессы или сказать, как улучшить наши). Но будет полезен и тем, кому действительно интересно разобраться, есть ли жизнь после релиза. Мы потратили десятки часов на обсуждения и споры внутри студии, чтобы решить, что наш процесс должен выглядеть как-то так. И хотя мы довольно гибко можем настроить некоторые аспекты технической поддержки (например, вести работу в любимом таск-трекере заказчика), каркас, к которому мы пришли, мне кажется, довольно хорош.

Пытаясь разобраться с библиотекой от Facebook ReactJS и продвигаемой той же компанией архитектурой «Flux», наткнулся на просторах интернета на две занимательные статьи: «ReactJS For Stupid People» и «Flux For Stupid People». Решил поделиться с хабравчанами переводом первой (а чуть позже и второй) статьи. Итак, поехали.

ReactJS для глупых людей

TL;DR В течении долгого времени я пытался понять, что такое React и как он вписывается в структуру приложения. Это статья, которой мне в свое время не хватало.

Что такое React?

Чем отличается React от Angular, Ember, Backbone и других? Как управлять данными? Как взаимодействовать с сервером? Что, черт возьми, такое JSX? Что такое «component»?

СТОП.

Остановитесь прямо сейчас.

React — это ТОЛЬКО УРОВЕНЬ ПРЕДСТАВЛЕНИЯ.

Бывает, сайты падают из-за отказа площадки хостера, каналов и так далее. Я 7 лет работаю в хостинге, и часто вижу такие проблемы.

Пару лет назад я понял, что услуга резервной площадки (без доработки их сайта или сервиса) очень важна клиентам. Теоретически тут всё просто:
1. Иметь копию всех данных в другом дата-центре.
2. При сбое переключать работу на резервный ДЦ.

На практике система пережила 2 полные технические реорганизации (сохранение основных идей со сменой значительной части инструментария), 3 переезда на новое оборудование, 1 переезд между поставщиками услуг (переезд из немецкого дата-центра в два российских). На исследование поведения разных систем в реальных условиях под клиентской нагрузкой ушло 2 года.

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

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

У популярного веб-сервиса для создания и хранения заметок Evernote скоро появится свободная альтернатива — Paperwork. Благодаря открытым исходникам каждый может установить Paperwork на своём сервере и предоставить доступ пользователям по локальной сети или через интернет.

Демонстрационный доступ открыт по адресу demo.paperwork.rocks. После регистрации создаётся демо-аккаунт для создания и редактирования заметок. Базу данных удаляют ежедневно в 3:00 (CET). Для регистрации можно использовать произвольный email, он не проверяется.

Перевод статьи Vincent Driessen: A successful Git branching model

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



В качестве инструмента управления версиями всего исходного кода она использует Git.

Доброго времени суток.

Пускай уже несколько дней v 5.0.0.9 BETA лежит в открытом доступе, но из названия понятно, что скачивать и вести свой проект на ней еще рановато, поэтому в этой статье я распишу достопримечательности UI в 4.6. Сразу замечу: все, что написано ниже, сугубо имхо, так что не нужно придумывать остроумные комментарии, поскольку я не претендую с этой статьей на ЦА Хабра, а просто хочу, чтобы такая статья на Хабре была, ведь если бы я наткнулся на подобную статью, как только скачал UNITY 4.6, то осваивать новый UI было бы легче и интереснее. Вот. Поехали.

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

1. В ходе исследовательской программы ВВС было установлено, что «если смотреть программы, в которых проверяют эрудицию участников, играть в интеллектуальные настольные игры и принимать душ с закрытыми глазами, то уже через неделю можно поумнеть примерно на 40%».
2. Когда для одной из ТВ-викторин обычных прохожих попросили назвать самую умную профессию, в списке оказались: сапожник, портной, учитель, учёный, профессор, дворник (да, меня тоже удивило), врач и – вот оно, народное признание! – программист. Ну и еще парочка стереотипов: кто работает в ИТ-компании? Ясное дело, программисты (есть еще вариант «компьютерщики»). А что они делают в свободное время? Играют в компьютерные игры, конечно!

Разрушать стереотипы – отличное занятие. Относительно самой умной профессии, впрочем, этого можно и не делать, а наоборот – попробовать посоревноваться с другими интеллектуалами, да не в компьютерной игре, а лицом к лицу, так сказать, голова к голове. Вдруг удастся победить учёных профессоров или даже самих дворников? Ну а кому не хочется получить звание самого умного среди коллег? Поумнеть – пусть даже не на 40% (не каждый готов принимать душ с закрытыми глазами), а хотя бы на 10-15 — тоже неплохо, хоть и не очень-то я верю этим британским ученым… В общем, мотиваторов для участия в битвах интеллектов оказалось предостаточно, и Veeam Software решила организовать команду знатоков «Что-Где-Когда».

Под катом – рассказ о том, что из этого получилось.

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

В публикации затронуты следующие моменты:

1. Отображение иконки и текста над объектом в сцене;
2. Отображение текста или иконки в окне Project;
3. Шаблоны создаваемых скриптов;
4. Открытие и создание проекта через контекстное меню проводника;
5. Добавление подписчиков на событие в инспекторе.

Персональные рекомендации позволяют познакомить пользователя с объектами, о которых он, возможно, никогда не знал (и не узнал бы), но которые могут ему понравиться с учетом его интересов, предпочтений и поведенческих свойств. Однако, часто пользователь ищет не новый объект, а, к примеру, объект A похожий на объект B («Форсаж 2» похож на «Форсаж»), или объект A, который приобретается/потребляется с объектом B (сыр с вином, пиво с детским питанием, гречка с тушенкой и т.д.). Построить такие рекомендации позволяют неперсонализированные рекомендательные системы (НРС).


Рекомендовать похожие/сопутствующие объекты можно, ориентируясь на знания об объектах (свойства, теги, параметры) или на знания о действиях, связанных с объектами (покупки, просмотры, клики). Преимуществом первого способа является то, что он позволяет достаточно точно определить похожие по свойствам объекты («Форсаж 2» и «Форсаж» — похожие актеры, похожий жанр, похожие теги, ...). Однако данный способ не сможет порекомендовать сопутствующие объекты: сыр и вино. Еще одним недостатком этого способа является тот факт, что для разметки всех объектов, доступных на сервисе, требуется не мало усилий.

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

Под катом описан метод ассоциаций, позволяющий построить неперсонализированные рекомендации, основываясь лишь на данных о действиях над объектами. Там же код на Python, позволяющий применить метод для большого объема данных.

В виду отсутствия хорошего материала по парсингу с помощью скриптового браузера SlimerJS и наличия свободного времени решил написать небольшую статью.

Первым звуковым редактором, который я увидел в своей жизни — был Фонограф (sndrec32.exe) в Windows 98. Недолго я игрался с ним, записывал до 1 минуты звука с микрофона (потом запись прерывалась) и прослушивал полученное. А еще переконвертировал звуки из одного качества в другое.

Вторым звуковым редактором, который я увидел — был Cool Edit Pro 2000 (который теперь называется Adobe Audition). Но когда я порылся в нем достаточно — я был расстроен, эту штуку называют «звуковой редактор», но она только редактирует звук. В ней нельзя написать музыку с нуля. В ее наследнике — Adobe Audition, правда, позже добавили систему дорожек, в которые можно понапихать loop-ов и наделать музыки из них.

Потом я еще увидел Cakewalk Pro Audio (Cakewalk Sonar), Fruity Loops, Sound Forge и т.д.

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

И год с лишним назад, в декабре 2013 года я начал делать этот редактор.

«Галоп пикселя», часть I — базовые понятия, этапы взросления, прикладные упражнения (линк)
«Галоп пикселя», часть II — перспектива, цвет, анатомия и прикладные упражнения (линк)
«Галоп пикселя», часть III — Анимация (линк)
«Галоп пикселя», часть IV — Анимация света и тени (линк)
«Галоп пикселя», часть V — Анимация персонажей. Ходьба (линк)
«Галоп пикселя», часть VI — Анимация персонажей. Бег (линк)

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

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

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