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

Небольшой скриншотик для понимания

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

Это – пошаговое руководство для тех, кто хочет знать, каким боком из Яндекс Директ (на вполне законных, между прочим, основаниях) привлекать недорогой трафик по 0.01 у.е или 30 копеек за переход.

Хорошая новость для вебмастеров и владельцев сайтов. Наконец-то вышел релиз аналитики Piwik с многообещающей версией 1.0

Для тех, кто впервые услышал это название, стоит указать на основные фишки библиотеки:

• Полная и абсолютная бесплатность без подвохов
• Доступность всех исходных кодов по лицензии GPL
• Расширяемая за счет плагинов архитектура
• Обновление статистики в режиме реального времени
• Данные аналитики доступны только Вам и никому более (Гугл немножко нервничает)

О растущей популярности Piwik достаточно говорит этот график Google Trends:



Для работы Piwik на сервере должны крутиться PHP и MySQL — вряд ли это требование сейчас для кого-то представляет проблему.

На мой взгляд, существует три основных мотива для применения Piwik в своем проекте:

• Вы не желаете делиться данными о посещаемости сайта с Google, LiveInternet и прочими доступными счетчиками
• Вам нужны расширенные или особые отчеты, которые практически невозможно получить стандартными средствами
• Вам действительно нужна оперативная отчетность, а не данные, запоздавшие на пару-тройку часов

Если это так, welcome to the club!

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

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

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

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

Будут рассматриваться: Райффайзен, ВТБ24, Банк Санкт-Петербург, Банк Авангард, Промсвязьбанк.
Итак, поехали.

Пожалуй, начну с того, что если перегружаться 15 раз в год, то любой «тюнинг» процесса загрузки отнимает больше времени, чем будет выиграно на перезагрузках за все время жизни системы. Однако, спортивный интерес берет свое, тем более, что люди интересуется процессом оптимизации быстродействия. А загрузка оказалась самым очевидным кандидатом в примеры того, как на мой взгляд должен выглядеть этот самый процесс. Сразу скажу, что грузиться будем с 5400 rpm винта, грузиться будем в «рабочую» систему: помимо недобитой вендорской крапвари там стоит еще куча всякого типа вижуал студии, антивируса, скайпа, стима, гуглапдейтера и пр…

Про то, почему отключение pagefile-а скорее вредно, чем полезно — как нибудь в другой раз, а пока…

Двое на этой фотографии через месяц сменили работу на более крутую

Студент, который только учит Java, может получить в Москве больше, чем действующий разработчик. К примеру, в Российском центре разработки Deutsche Bank стипендия колеблется в районе 100 тыс.руб. в месяц — и вас за эти деньги ещё только учат, работа — потом.

Спрос на разработчиков каждый год растёт примерно на 10-15 процентов, а база для образования не справляется. И потребности растут, и текучка большая: ведь в какой-то момент выяснилось, что Java позволяет наиболее индустриально разрабатывать код.

Так вот, сейчас я расскажу, какие есть варианты карьеры в России и за рубежом есть у вас, если вы уже знаете Java или, по крайней мере, у вас есть пара месяцев, чтобы перейти на новый язык и новую среду разработки. За рубежом, кстати, Amazon, Facebook, Twitter и LinkedIn активно нанимают Java-инженеров, специализирующихся на бэкэндах. А у нас — Одноклассники, Deutsche Bank, Oracle, Luxoft, Сбербанк-Технологии, Azul и другие. Пошли, покажу, что и как.

В последнее время набирают популярность различные NoSQL базы данных. Эта статья начиналась как изучение особенностей графитовой графовой базы данных Neo4j. Но, в процессе подбора информации, мне захотелось систематизировать информацию о NoSQL решениях и о графовых базах данных, в частности.
В ходе этого небольшого исследования, были выбраны для подробного рассмотрения СУБД, успешно применяющиеся в области Web. И, поскольку в тегах присутствует «PHP», я выбирал СУБД, которые уже можно использовать с этим языком.

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

В качестве ОС я выбрал Ubuntu 12.04.

Адреса тестовых вебнод:
192.168.1.51 (loganalyzer-mysql.ip) — Rsyslog-сервер, на этом хосте также будет проинсталлирован LogAnalyzer
192.168.1.50 (loganalyzer-mongo.ip) — Rsyslog-клиент, который будет отсылать логи на сервер loganalyzer-mysql.ip

Настраиваем серверную часть, для чего добавим репозиторий от разработчика Rsyslog:

...
# Adiscon stable repository
deb http://ubuntu.adiscon.com/v7-stable precise/
deb-src http://ubuntu.adiscon.com/v7-stable precise/
...

# apt-key adv --recv-keys --keyserver keyserver.ubuntu.com AEF0CF8E
# gpg --export --armor AEF0CF8E | sudo apt-key add -

Введение:

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

Поскольку на моём сервере используется nginx, то был установлен модуль SSL
Гугл не выдал ни одного работоспособного howto, но информация в сети есть по частям.

Итак, пошаговое руководство по настройке nginx на авторизацию клиентов через SSL-сертификаты.

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

Представьте: Вы — веб-разработчик, который только недавно освоил Ruby on Rails. И тут Ваш первый проект подходит к стадии, когда его нужно выложить в интернет.
Вы, конечно, можете залить его на Heroku, но тамошние цены немного кусаются. Остается только купить VPS, настроить его и выложить проект туда.
«Что может быть проще? Найду какой-нибудь гайд, да следаю всё по нему» — подумаете Вы. Вот только гайдов, которые не просто выкладывают команды, но и объясняющие, что эти команды делают, — единицы, да и те используют уже устаревшую вторую версию Capistrano.

Поэтому я решил написать свой гайд, в котором постараюсь подробно рассмотреть:

• Первичную настройку сервера
• Установку и настройку nginx (с модулем PageSpeed), postgresql, redis
• Установку rvm, rails
• Настройку гема foreman для управления процессами Вашего приложения
• Настройку сервера Unicorn
• Настройку гема Capistrano (v3.1) для автоматизации деплоя

Я надеюсь, что этот гайд будет полезен не только новичкам, но и разработчикам со стажем.

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

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

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

1. Вычисления не должны блокировать взаимодействие с интерфейсом и его рендеринг — пользователь всегда должен иметь возможность указать на фокус своих интересов.
2. Страница объекта, к которому обратился пользователь, должна отображаться мгновенно, не дожидаясь загрузки данных, в которых нуждается объект.
3. Запросы в сеть не должны уходить одной большой группой, не должны отправляться сразу; должны откладываться на небольшое время, складываться и приоритезироваться в случае необходимости.

Изложенная в этой заметке информация — это мой практический опыт проектирования и разработки интерфейса моего приложения для поиска и прослушивания музыки seesu.me. Приложения, в котором гармонично комбинируются огромные пласты данных из разрозненных сервисов, таких как last.fm, вконтакте, ex.fm, hypem.com, soundcloud.com, discogs.com, youtube.com

Спустя три года (!) оно случилось: теперь для того, чтобы платить страховые взносы по сниженной ставке в 14%, нужно иметь 7 сотрудников в штате. Раньше минимальный порог равнялся 30. Пруфлинк на Минкомсвязь России.

Самая важная часть:

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

История

Три года назад, в 2010-м, Дума подготовила изменения в Федеральном законе «О страховых взносах в Пенсионный фонд Российской Федерации, Фонд социального страхования Российской Федерации, Федеральный фонд обязательного медицинского страхования». Суть изменений была прекрасна: для малых ИТ-компаний процент страховых отчислений снижался до 14% вместо стандартных 34%. Загвоздка была в самом определении малых ИТ-компаний, а именно:

• Количество сотрудников компании — не менее 50 (потом снизили до 30, но в корне это ничего не поменяло).
• Доля доходов от реализации ИТ-продуктов и оказания ИТ-услуг — не менее 90%

Со вторым у большинства веб-разработчиков проблем бы не возникло, а вот первое — фактически сводило на нет всю полезность закона. Мы решили пойти в наступление.

Часто возникает задача подсчета количества посещений той или иной страницы портала или подсчета кликов по какой-то ссылке. Например. может быть интересно подсчитать количество просмотров статьи или объявления, число кликов по «показать номер телефона» на странице объявления о продаже и т.д. и т.п.

Главное точно понимать, для чего вы планируете использовать эти счетчики и для чего они могут понадобиться в обозримом будущем. Нужно ли по ним выбирать/сортировать/группировать сущности или вам просто нужны редкие разовые отчеты (например раз в сутки)? А может, вы хотите показывать эти счетчики в админке или в личном кабинете пользователя? Хотите ли вы в реальном времени показывать эти числа или можно ограничиться часовой/суточной отсечкой? В зависимости от этих и, возможно, еще каких-то критериев будет зависеть выбор способа подсчета и хранения счетчиков.

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

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

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

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

Теперь давайте по порядку.

Привет! Меня зовут Денис Чернилевский. В Яндексе я руковожу группой автоматизации тестирования системы медийной рекламы. В процессе своей работы в Яндексе и на предыдущих местах мне довелось руководить командами 10+ человек, налаживать процессы и придумывать подходы автоматизации тестирования различных систем. И так уж вышло, что в каждом из этих проектов приходилось задумываться о подготовке тестовых данных. По итогам довольно долгой рефлексии был придуман подход, который позволяет в общем виде решить эту задачу и применять его в разных проектах. Помимо того, что я буду говорить о нём на Тестовой среде, решил рассказать подробности и здесь.

Кстати, если вы не можете приехать на наше мерпориятие для тестировщиков, можно будет посмотреть трансляцию, которая начнётся завтра, в субботу, 30 ноября в 11:00.



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

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

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

Docpad

«Нашумевший» проект в Twitter и GitHub. По заявлению разработчиков «Docpad снимает ограничения и убирает разрыв между профессионалами и новичками. Теперь дизайнеры и разработчики могут создавать веб-сайты быстрее, чем когда-либо прежде». Docpad — это статический генератор сайтов написанный на Node.js. Он позволяет с легкостью создавать шаблоны и блоки. Работает c PHP, Ruby, CoffeeScript и др. В нем есть file wathing, live reload и самое главное «amazing plugin system». Большим плюсом является обучающее видео (хоть и на английском).

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

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

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

Ключи

Redis — хранилище данных в формате «ключ-значение». Факты о ключах:

• Ключи в Redis — бинарно-безопасные (binary safe) строки.
• Слишком длинные ключи — плохая идея, не только из-за занимаемой памяти, но так же и в связи с увеличением времени поиска определенного ключа в множестве в связи с дорогостоящим сравнением.
• Хорошая идея — придерживаться схемы при построении ключей: «object-type:id:field».

Типы данных Redis

• Строки (strings). Базовый тип данных Redis. Строки в Redis бинарно-безопасны, могут использоваться так же как числа, ограничены размером 512 Мб.
• Списки (lists). Классические списки строк, упорядоченные в порядке вставки, которая возможна как со стороны головы, так и со стороны хвоста списка. Максимальное количество элементов — 2³² — 1.
• Множества (sets). Множества строк в математическом понимании: не упорядочены, поддерживают операции вставки, проверки вхождения элемента, пересечения и разницы множеств. Максимальное количество элементов — 2³² — 1.
• Хеш-таблицы (hashes). Классические хеш-таблицы или ассоциативные массивы. Максимальное количество пар «ключ-значение» — 2³² — 1.
• Упорядоченные множества (sorted sets). Упорядоченное множество отличается от обычного тем, что его элементы упорядочены по особому параметру «score».

Про типы данных Redis есть отдельная хорошая статья: «Структуры данных, используемые в Redis».