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

Рассказывается о том, как мы нанимали офис-менеджера плюс некоторые размышления о найме персонала в офис.

upd Рассказ не является руководством к действию, а иллюстрирует типичный подход небольшой компании (до 100 человек), а так же рассказывает о том, на что при найме обращают внимание и как принимаются решения о приёме на работу.

Захотелось нанять тебе, скажем, офис-менеджера.

1. Идёшь к HR (к девочке) и говоришь — хочу, дескать, офис-менеджера. Чтоб девочка, чтоб внешность была приятная — у нас коллектив мужской, опять же тебе, как HR с офис-менеджером работать — подбери, чтоб не цапались, зарплатная вилка такая-то, график посещения — такой-то, помогать должна в том-то и в том-то, ну и, иногда, за бутербродами для коллектива сгонять.
   
   
2. HR оборачивает это всё в красивые требования вакансии типа наличие В.О., знание языков, владение компьютером, опыт работы, и т.д., и т.п., выкладывает, скажем, на hh.ru.
   
   
3. за следующий день на вакансию приходит 80 резюме, через день — 150, к концу недели количество кандидатов на вакансию стремится к 400 человек (цифры реальные, данные на декабрь 2009 года — всякие там юристы, бизнес-аналитики, офис-менеджеры, секретари, работники отделов кадров, логисты и младшие экономисты имеют схожие показатели людей на место, немногим лучше ситуация у дизайнеров и системных администраторов (не тех, кто серваки сетапит, а тех, кто мышки пользователям меняет))
   

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

Как показал опыт, в наше тяжелое, наполненное террабайтами информации время, пользователи стали ленивы и предвзяты. Статья больше, чем на пару страниц должна быть просто-таки открытием в своей области, чтобы ее дочитали до конца больше половины пользователей, а шутка должна быть действительно смешной, чтобы ее начали пересылать друг другу. Настал ад для контент-менеджеров и рай для сайтов типа news2.ru или digg.com, где ленивых пользователей уже ждет специально одобренный другими пользователями, а значит, заведомо интересный контент. (Даже если одобрили его не обычные пользователи, а SMO-оптимизаторы, нанятые для продвижения того или иного сайта в web 2.0 ресурсах). Информации все больше, а времени все меньше. <>

N способов...

Хороших продуктов не существует, до тех пор пока они не станут таковыми в головах потребителей. Известная истина формирует новое направление в маркетинге. Это направление призвано заставить потребителей воспринимать товар или услугу выдающимся из ряда подобных товаров и услуг, делать потребителей слепыми поклонниками бренда. В благодарность за ваше существование они обеспечат вас бесплатной рекламой (а конкурентов — анитирекламой), будет исправно покупать каждый новый продукт за любые деньги. Это — не брендинг. Это — «изустный» маркетинг, верх маркетингового искусства.

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

И удачи вашему бренду, даже если единственный бренд, который у вас есть — это вы сами.

Добрый день, хабражители! Обнаружил, что на сайте нет статьи о том, как можно организовать процесс создания документации для Ruby on Rails проектов. Исправим эту проблему.

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

В начале 2013 я решил основать компанию.

В предыдущие 4 года я разработал и запустил несколько программных продуктов завязанных вокруг популярного сервиса. Я начал в 2008 году с сайта-хостинга изображений, который быстро вырос до 2-х миллионов уникальных пользователей в месяц. Продолжил в 2011 году андройд-приложением, которое было скачано и установлено более 200 тысяч раз. Но пользовательское соглашение популярного сервиса положило этому конец.

Долгое время мне приходилось работать в одиночестве. Я был системным администратором, PHP, Perl и Android разработчиком одновременно, проектировал и управлял базами данных. Я занимался маркетингом, поддержкой пользователей и решал юридические вопросы. Делал все, начиная от удаления фотографий эротического содержания вручную, заканчивая настройкой Bind серверов.

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

Кто здесь?

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

11:24:21 PM Michael: ну хз, надо пробовать
11:24:24 PM Michael: наверное так лучше
11:24:27 PM Michael: даже я думаю наверняка
11:24:36 PM Michael: но пока меня че-то останавливает
11:24:38 PM Michael: лень наверное :)

Знакомо? «Не хочется разбираться? Нет времени?» Тогда читаем дальше. В статье расскажу, как настроить свое любимое рельсовое окружении на разработку с подходом BDD и начать новую жизнь (опционально).

Обойдусь без копипастов и даже ссылок о том, что Ruby за зверь такой, ибо написано было уже сполна. В данном посте просто хочу рассказать о пути изучения Ruby (и, впоследствии фреймворка Ruby on Rails) человека далекого от программирования.

1. Любопытство

«Насколько далекого?», спросите вы, а я отвечу — «Чуть менее, чем полностью», так как в десятом классе в школе у меня были уроки программирования, парочка из которых были уделены Паскалю. Признаюсь, впоследствии о html узнал, и даже мог в Dreamweaver-e сверстать страничку или поставить готовый движок, да по инструкции налепить плагинов, но не более.
Хотя компьютеры мне нравились, пошел я учиться на экономиста* — бакалавриат, магистратура по бух. учету и аудиту, аспирантура по финансам, работа в банке, преподавание, страхование. Но не жилось мне спокойно в финансах, — финансовый калькулятор удовлетворял необходимости решения тривиальных задач, но не удовлетворял мой мозг. А ему хотелось посчитать не только будущую и приведенную стоимость актива, но и создать массив данных из исторических стоимостей этого актива за n лет, высчитать среднюю доходность, дисперсию и, в конце-концов построить красивый график!

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

При мне менялись технологии и концепции. Тачскрины, голосовое управление, сенсоры движения, тачпэды, не говоря о всяких мышах — все это органично вписывалось в мой мир взаимодействия с приборами, и на этом пути не было ни особых потрясений, ни революций. Я спокойно и естественно считал себя типичным early adopter. Я был в сетях Fido и Compuserve, писал электронные письма до Эпохи интернета, общался в чатах и конференциях годы до появления ICQ, хранил файлы в «облаке» чуть ли не до рождения некоторых нынешних стартаперов в модной области Cloud. У меня даже несколько лет был собственный блог задолго до сегодняшнего блог-сумасшествия и десятков доступных платформ для блоггинга.

И так далее, и тому подобное.

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

Хочу поделиться опытом разработки и продаж своего iOS-приложения из категории «Производительность» (Productivity). О приложении рассказывать не буду, чтобы не сочли за рекламу. Просто графики и выводы, которые я сделал.

Привет, Хабрахабр!

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



Кому интересно, добро пожаловать под кат.

Введение

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

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

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

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

Итак, что мы представляем из себя на данный момент? В Stack Exchange сейчас работают 75 человек, примерно половина занимается продажами (маркетинг и реклама), остальные же — созданием продуктов (разработка, дизайн, управление сообществами). БОльшая часть удалённо работающих сотрудников занимаются разработкой: 16 удалённых и 18 офисных разработчиков, сисадминов, дизайнеров. У нас команда-гибрид, которая, как мне кажется, лучшая в мире. Я руковожу отделом проектирования, так что буду говорить в основном о разработчиках, но это применимо ко всем должностям.

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

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

<a href="http://myapp.com/catalog/#action1">Сделать что-то полезное</a>

или даже

<a href="http://myapp.com/catalog/#action1/42">Сделать что-то полезное с параметром</a>

и всё прекрасно работало. Пользователь, в свою очередь, мог сохранить каждую из этих ссылок, и, в последствии, перейти по ним, сразу же активировав нужную функциональность. Единственный негативный момент во всём этом великолепии — наличие символа "#" (решетка). Не то, чтобы она была плоха сама по себе, но читабельность и «красивость» (с задних рядов мне ещё кто-то про RESTful что-то подсказывает) URL она портила.

Приветствую!

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

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

Facebook. FaceTime. Страницы в Google+. Хэш-теги в Твиттер и Инстаграм. Эти технологии кажутся такими новыми, не так ли?

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

До Facebook и Facetime, до Google+ и Twitter были Plato и Bell Picturephone, Dynabook и Xerox LiveBoard. В социальных медиа нет ничего нового. Сейчас у них просто лучшая упаковка – и лучший маркетинг.

Название LiveBoard ни о чем тебе не говорит? Никогда не слышал о Plato? Тогда настало время для небольшого исторического экскурса. И прежде чем браться за свой iPad и Tumblr удели немножко времени социальным медиа прошлых десятилетий. Ведь твоего iPad не было бы без DynaBook Алана Кейа. Без них ты бы остался ни с чем, кроме праздничного шампанского – и последующего похмелья.

Если и есть что-то неизменное с того дня, когда я начал писать код и по сегодняшний день (а я пишу уже дней 500). Так это то, что незнание с чего начать — невероятно пугает. Я остро помню панику изучения HTML, когда я понятия не имел, как заставить мои div-ы располагаться там, где я хотел. Я понимал концепцию сетки, но реализация никак мне не давалась в течение нескольких дней.

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

Hayaku это сборник полезных скриптов, помогающих при быстрой веб-разработке.

Hayaku предоставляет способ быстрого способ написания и поддержки CSS кода в редакторе. К сожалению, он пока доступен лишь для Sublime Text 2, поддержка других редакторов ожидается позднее.

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

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

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

Тот дизайнер, который ценит своё время, любит порядок в работе, разукрашивает папки и обзывает слои вменяемыми именами, а иногда даже оставляет «сноски в фотошопе в трудных для понимания местах» мгновенно переходит на следующий уровень с соответствующим ценником. И даже если финансы позволяют вам воспользоваться их услугами – их очень не просто найти, так-как соотношение между «дизайнерами-новичками» и «дизайнерами-со-скиллом-именования-слоёв» стремится к 80% — 20% или даже 90% — 10%.

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