Наш флаг на вершинах Карпат

В феврале мы побывали в Карпатах и поднялись с флагом на самые высокие вершины нашей страны.

Говерла (2061 м) — самая высокая точка Украины. Единственная наша гора, зимним восхождениям на которую присвоена альпинистская категория (1Б).

Наш флаг на Говерле

Петрос (2020 м) — вторая по высоте гора в Украинских Карпатах.

Наш флаг на Петросе

Наш флаг на Петросе

Зимние Карпаты прекрасны!

Говерла зимой

Говерла зимой

Зимние Карпаты

Зимние Карпаты

Создание резюме на основе профиля пользователя в LinkedIn

Новая возможность на сайте «Работа в Харькове»: теперь пользователи могут создавать резюме на основе своего профиля в LinkedIn.

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

Сайт получает данные пользователя с помощью LinkedIn API.

Сайт «Работа в Харькове» — первый в Украине сервис поиска работы, который предоставляет соискателям возможность создать свое резюме на основе профиля в LinkedIn.

Сбор и хранение статистики для «Персии»

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

Задача

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

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

Поиск решения

Вариант А: ведение полной истории

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

Проведем оценку скорости роста таблицы статистики по одному пользователю. Предположим, что пользователь добавляет по одному резюме каждую минуту (что маловероятно, но наглядно для анализа). Другие действия пользователей, интересующие нас, требуют еще больше времени на выполнение. Итак, в год: 60×24×365 = 525600 действий. А значит столько же записей в таблицу статистики. А теперь умножаем на число пользователей в компании. Потом умножаем на число компаний… Многовато :) Какой выход? Разделить статистические данные по отдельным таблицам для каждой компании. Разделили. Для некоторых компаний этого будет уже достаточно: возможно у них 2-3 рекрутера и работа выполняется достаточно медленно. Но для крупных компаний таблица статистики все же будет слишком большой.

Вариант Б: хранение обобщенных данных

Посмотрим внимательней на собираемые данные и то, как мы их в итоге показываем пользователям. В данном случае, пользователя интересуют не столько записи о конкретных действиях, сколько их количество за определенный интервал времени. Значит, если выбрать минимальный интервал, то можно хранить количество (сумму) действий как одну запись. А это во много раз уменьшает таблицу статистики компании. Какой же выбрать минимальный интервал? Логично предположить, что в течение рабочего дня статистические данные могут меняться очень быстро и не имеет смысла за ними следить в режиме «реального времени». Скорее всего, руководителю интересно получить данные за неделю или месяц, и по ним принимать решения. Поэтому был выбран минимальный интервал в 1 сутки, что позволит нам получить информацию с вполне достаточной детализацией до одного дня.

При таком подходе получим таблицу, которая состоит из нескольких записей для каждого отдельного дня: одна строка для всей компании и по одной строке для каждого рекрутера этой компании. Например, если в компании 2 рекрутера, то в таблице будет: 2×3 х 365 = 2190 записей за год. В расчете на одного пользователя это в 480 раз меньше, чем в предыдущем варианте!

Решение

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

Сбор и обработка статистических данных

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

Видимый пользователям системы результат:

Общая статистика по компании
Общая статистика по компании

Статистика работы рекрутера
Статистика работы рекрутера

Выводы

Конечно, у такого подхода есть как преимущества, так и недостатки.

Недостатки:

  • теряются исходные данные по каждому отдельному действию пользователя;
  • невозможно повторно выполнить пересчет статистики;
  • пользователи не видят статистику за текущие сутки.

Преимущества:

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

По Северскому Донцу на катамаранах

22-24 июня 2013 г. мы сплавлялись на катамаранах по Северскому Донцу.

Три дня на веслах, две ночи в палатках. Купались, пели песни, готовили еду на костре, ловили рыбу. Отличная погода, прекрасная природа и веселая компания — отдых однозначно удался!

Теперь с новыми силами — работать, работать и работать :)