Нет %username%, на этот раз речь будет не об уважаемом математике Рао Кальямпуди Радхакришна. Наш новый друг ПишиЧитай РАО — Российское Авторское Общество, некоммерческая общественная организация, созданная авторами для реализации и охраны авторских прав в сфере интеллектуальной деятельности.
«Э брат, это жулики», сказал бы Карлсон, просвистев в очередной раз футбольный гимн, и был бы осужден, на вагон и маленькую тележку денег. Какие предьявы? По какой причине?

а) Нарушение авторских прав.

Все знают, что произнесенная фраза принадлежит Автору, ну а РАО авторов всячески защищает.
РАО vs «Deep Purlpe» — где РАО оштрафовывает «исполнителей»(Deep Purlpe) в пользу «автора»(Deep Purlpe) :)
РАО vs Элтон Джон — аналогично.

Update статьи “Пиши резюме правильно или “умею улыбаться и пеку оладушки”.

Начну с того, что я IT рекрутер. В этом тексте выражено только мое мнение по вопросу составления резюме. Это вовсе не значит что мои коллеги по отрасли считают также. Возможно, с чем то-то они согласны, с чем-то нет.

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

1. Работая в IT кадровом агентстве, я общаюсь с кандидатами только по телефону и мне психологически комфортнее представлять себе человека визуально. Возможно вам тоже. Часто процесс трудоустройства растягивается на недели, а то и на месяцы. В этот период я веду с кандидатом переписку, общаюсь по телефону и в скайпе. Волнуюсь за него, особенно если процесс рассмотрения резюме почему-то затягивается, а человеку срочно нужна работа. Если история заканчивается хорошо, и кандидата приглашают в компанию — радуюсь. И так изо дня в день, и из месяца в месяц. Человек становится уже в чем-то близким для меня. И не представляя его визуально — чуть сложнее и как-то грустнее, что ли, работается.

Поэтому фото в резюме важно для меня, как для рекрутера.

2. Для руководителя, ищущего специалиста себе в команду — фото в резюме кандидата может быть важно по другой причине: с этим человеком он и его коллеги будут работать по 8 часов в день 5 дней в неделю. И хочется, чтобы человек вписался в команду. Конечно, понять, впишется специалист в команду, или нет, можно только на собеседовании, и то не всегда. Но всех на собеседование не пригласишь, у руководителя мало времени для этого. Фото в таком случае выступает для него одним из фильтров для экономии времени.

Отталкиваясь от этого, решать, размещать ли фотографию в резюме, и какую именно — вам. Я лишь попробовала объяснить, почему это может быть косвенно полезно при поиске работы.

И напоследок, перед тем как вы начнете, уже наконец, читать саму статью, хочу попросить вас — не стесняйтесь комментировать! Ваше мнение для меня очень важно, потому что вы — мои друзья, или коллеги по отрасли или те, кому я звоню каждый день, говоря: ”здравствуйте, я нашла ваше резюме..."

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

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

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

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

Andrey: у меня была точно такая же ситуация с банкротством конторы, сейчас я уже вижу, где поступил неправильно. Нас так же кормили «завтраками», или, как мы их называли, «микроплатежами», когда срок переносится на неделю, потом ещё на неделю. В итоге сказали, что банкротят. Также предложили написать заявление на отпуск без содержания на 3 месяца. Это основное условие получения текущей зп. Только нам выплачивали не всю зп. Остаток должны были выплатить по договору с головной американской конторой. Какая у меня была ошибка:

1) я написал заявление на увольнение по собственному желанию
2) я написал заявление на отпуск без сохранения зп
3) поверил, что головная контора выплатит долг

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

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

Как я и обещал – публикую вторую статью о некоторых моментах разработки игр в трех измерениях. Сегодня расскажу об одной технике, которая используется почти любом проекте ААА-класса. Имя ей — HDR Rendering. Если интересно — добро пожаловать под хабракат.

Об установке и базовой настройке rtorrent на хабре хватает статей, как и споров о том, стоит ли вообще связываться с хардкорным rtorrent или лучше обойтись чем-нибудь более дружественным к пользователю. Лично я много лет назад пересмотрел все качалки и в результате rtorrent оказался самым стабильным и эффективным. Интерфейс у него не самый удобный, но достаточно понятный и юзабельный чтобы это не стало серьёзной проблемой. Альтернативные интерфейсы вроде rutorrent у меня как-то не прижились - ставить php только ради rutorrent неохота, а остальные варианты выглядят совсем слабо (и ни одного кроме rutorrent даже нет в портаж Gentoo).

  

Одно из основных преимуществ rtorrent — очень гибкие возможности по его настройке и автоматизации. К сожалению, синтаксис ~/.rtorrent.rc достаточно нестандартный, нормальная документация отсутствует, поэтому обычно настройка сводится к поиску и копированию (попытка что-то в них изменить кроме констант/путей к каталогам обычно проваливается) готовых рецептов или вообще ограничивается редактированием констант в базовой конфигурации.

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

Я провел весь вчерашний день, напряженно работая, чтобы закрыть долгую и порядком надоевшую задачу. Было достаточно поздно, когда я закомитил изменения и отправил на пуш. Гит привычно ругнулся что не может, потому что есть свежие правки. Окей, pull, push. Теперь вроде нормально, можно идти спать.

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

На следующий день я еще раз сделал деплой на тестовый сервер, но он упорно показывал старую версию. Решил свериться с логом Гита… мой коммит… ЕГО ПРОСТО НЕ БЫЛО! Его не было нигде, ни в локальной копии, ни в удаленной. Его не было даже в исходниках на диске. Файлы, оставленные открытыми в редакторе, были пусты. Единственный фактом, связывающим меня в тот момент с реальностью, был скомпилированный js-файл проекта, оставшийся после сборки исходников. Он работал именно так, как я оставил его вчера.

В продолжение первой части. Сегодня будем рассматривать ресурсы о Java в интернете, которые подразделим на 4 части: вендоры, JUG, форумы, новости. А заодно подведём итоги.

Вендоры

Sun Microsystems

Основной сайт компании Sun содержит чисто рекламную информацию, поэтому рассматривать мы будем Сеть Разработчиков. Итак, что же здесь есть:

• JavaFX — хит сезона. В рамках продвижения Sun проводит конкурсы по этой технологии, ещё вы можете найти документацию на русском языке и даже Wiki.
• Академические программы — информация об образовательных программах. В основном это курсы для преподавателей и учебные материалы — лекции, написанные в рамках грантов.
• Java SE, Java EE, Java ME, JavaCard за 2009 год не содержат практически никаких обновлений, а за предыдущие года есть разве что переводы некоторых статей.
• Форум довольно мёртвый, за исключением раздела о JavaFX.
• Ещё есть переводы англоязычных блогов The Aquarium и The Planetarium, посвящённых новостям о Java EE и Java для всех других платформ(SE, ME, FX, etc...) соответственно.

Салют коллеги!
20-21 февраля 2015г. в Москве в ивент-холле «Инфопространство» пройдет 4-я международная конференция, посвященная управлению ИТ проектами и продуктами — Software Project Management Conference (SPM Conf).


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

Ну а пока о конференции словами участников.

Почему надо участвовать в конференции

О пользе и ценности участия

Одним из методов сбора информации о процессе является проведение интервью с владельцем или участниками этого бизнес-процесса. Такой традиционный подход встречается очень часто, особенно у начинающих бизнес-аналитиков и матерых консультантов из Big4. Казалось бы очень разумно выслушать человека, формализовать его монолог и согласовать результат с ним же — это быстро и не затратно. Одно плохо — на этапе анализа адекватности результата моделирования деятельности (если такое предусмотрено) происходит отбраковка собранных данных по причине их несогласованности и противоречивости, процедуру сбора данных о ходе процесса надо повторять сначала, «на радость» всем участникам проекта. Почему такое происходит? Как видно из заголовка, дело в респондентах. Ниже на конкретных примерах из личного опыта я покажу, почему был сделан такой вывод и как с этим бороться.

Летят в самолете Петька и
Василий Иванович, Василий Иванович кричит:
— Петька, приборы!
Петька отвечает:
— Двести!
Василий Иванович:
— А что «двести»?
Петька:
— А что «приборы»?

Сегодня выходит из беты наш новый сервис — Яндекс.Город. Он появился как логичное продолжение Яндекс.Справочника, который был единым источником знаний об организациях для всех наших сервисов. Его данные используются собственно в приложении Я.Город, на Яндекс.Картах, в сниппетах на странице результатов поиска, для построения маршрутов в Картах и Навигаторе, определения номера в Яндекс.Ките, выбора мест отправления и прибытия в Такси. Найти места и организации можно было на многих наших площадках, а вот выбирать там не очень удобно.

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

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


У сервиса поиска мест на Яндексе многолетняя история, и к его созданию приложили руку несколько команд. Растёт он из проекта adresa.yandex.ru. Потом Яндекс интегрировал в него бизнес «Жёлтых страниц» — так появился Справочник. Около года назад очень сильно обновилась команда сервиса. И он начал превращаться в Яндекс.Город. Я в этой команде руковожу службой производства данных и сегодня расскажу вам о том, какие у нас метрики и как они помогают нам делать лучшую базу организаций в России.

Низкая скорость поисковых запросов

Работая над поисковым движком по социальной информации (ark.com), мы остановили свой выбор на Elasticsearch, так как по отзывам он был очень легок в настройке и использовании, имел отличные поисковые возможности и, в целом, выглядел как манна небесная. Так оно и было до тех пор, пока наш индекс не вырос до более-менее приличных размером ~ 1 миллиарда документов, размер с учетом реплик уже перевалил за 1,5 ТБ.

Даже банальный Term query мог занять десятки секунд. Документации по ES не так много, как хотелось бы, а гуглинг данного вопроса выдавал результаты 2х-летней давности по совсем не актуальным версиям нашего поискового движка (мы работаем с 0.90.13 — что тоже не достаточно старая вещь, но мы не можем позволить себе опустить весь кластер, обновить его, и запустить заново на текущий момент — только роллинг рестарты).

Низкая скорость индексации

Вторая проблема — мы индексируем больше документов в секунду (порядка 100к), чем Elasticsearch может обрабатывать. Тайм-ауты, огромная нагрузка на Write IO, очереди из процессов в 400 единиц. Все выглядит очень страшно, когда смотришь на это в Marvel.

Как решать эти проблемы — под катом

Австралийский дизайнер Уилл Дэйбл предлагает интересную метафору, помогающую разрабатывать простые и удобные интерфейсы. Разработчику, который знает свою систему вдоль и поперек, и отдаёт работе над ней значительную часть своей жизни, очень трудно представить, как будет работать с ней обычный пользователь, чья голова забита другими вещами. Особенно, если он пробует его продукт первый раз в жизни и ещё не уверен в его полезности. Чтобы представить, что творится в голове у пользователя, Уилл Дэйбл предлагает вообразить, что пользователь пьян. Его внимание рассеянно, он легко выходит из себя, он не слишком отчётливо видит и не очень уверенно двигается — если постоянно помнить об этом, интерфейс получится чище и проще. Суть метода Дэйбл рассказывает в этом пятиминутном ролике:

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



Дамы и господа, леди и джентльмены! Настало время расчехлить свои смартфоны для нового приложения.

После нашей удачной первоапрельской шутки нас регулярно спрашивают, когда же мы выпустим C++ IDE. Понятно, что все, кто пишет под Linux, давно ждут такую среду разработки, да и альтернатива имеющимся в Windows и Mac OS никому не помешает.

C++ IDE — это отдельный продукт, она основана на платформе IntelliJ, как и прочие наши IDE. Поддержка C++ в ReSharper — это совершенно другая тема, и про нее мы отдельно напишем (не сегодня).

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

Жизнь — игра, в которую играют буквально все. Эта статья — ваше руководство.

Основы

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

В понедельник утром за неделю до Нового Года этот вопрос, думаю, актуален для многих.

Есть куча статей на эту тему. Вот основные советы:

• Начинайте с самой сложной задачи
• Сделайте первый шаг — продолжать будет уже легче
• Составьте план и неукоснительно ему следуйте
• Занимайтесь любимым делом
• Не отвлекайтесь

Всё просто. Закройте Хабр и приступайте к работе!

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

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

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