Вчера случилось долгожданное для SourceTalk событие: наконец вышел полноценный релиз. Для тех кто о проекте слышит первый раз или уже успел забыть: SourceTalk — это сервис для обсуждения исходных кодов в реальном времени, по изначальной задумке — что-то вроде Campfire или HipChat для разработчиков, но возможно вы уже успели познакомиться с более близким аналогом, вышедшим в прошлом году — Gitter. О непростом пути, пройденном за два года развития от прототипа до релиза, можно прочитать в моей статье на Мегамозге. Здесь же я опишу только текущий функционал.

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

2 года жизни, $10k потраченных из собственного кармана, порядка тысячи человекочасов. И результат, который стоил всего этого: http://sourcetalk.net

История эта началась ровно два года назад на хакатоне HackDay в Нижнем Новгороде. Идея к этому моменту у меня уже была: сервис для обсуждения исходных кодов в реальном времени, интегрированный с различными IDE и GitHub, что-то вроде Campfire или HipChat для разработчиков. Команду из трёх человек удалось собрать довольно быстро, хакатон прошёл крайне продуктивно (кстати отдельное спасибо организаторам), и через два дня у нас был работающий прототип. Там же на наш проект обратила внимание Евгения Смородникова, человек в российском стартап-сообществе небезызвестный, и какое-то время побыла его ментором (за что я ей крайне признателен). Однако идиллия продолжалась недолго, довольно скоро первоначальная команда развалилась, как это часто бывает. Я остался один с незаконченным проектом на руках и огромным желанием довести дело до конца.

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

На нашем проекте мы используем Backbone.js в качестве основного JS-фреймворка. Почему выбор пал на него, я возможно ещё расскажу в одном из следующих постов, в этот раз речь о другом. Как известно, из коробки Backbone предлагает весьма скромные возможности, компенсируя это максимальной гибкостью. Поскольку Backbone существует достаточно давно и успел обзавестись серьёзным сообществом разработчиков, для решения многих типовых задач Backbone-приложений сегодня существуют плагины либо целые надстроенные над Backbone фреймворки (многим известен например Backbone.Marionette, очень многообещающе выглядит недавно вышедший Base — кстати советую приглядеться).
Тем не менее, есть одна достаточно распространённая задача, адекватное решения которой мне до сих пор не попадалось: речь идёт о создании типовых автономных элементов UI. Скажем, у вас в проекте используется элемент выбора даты, для его создания вы используете найденный вами на бескрайних просторах гитхаба плагин jQuery. С этим последним всё хорошо кроме того, что вам нужно вручную дёргать его каждый раз, когда на вашей странице появляется соответствующий input, а потом возможно ещё и подчищать созданную им разметку во избежание дальнейших конфликтов. В итоге вам приходится писать много повторяющегося кода. Вот здесь вам и пригодится Backbone.Component.

В последнее время тема удалённой работы стала особенно актуальной — достаточно вспомнить этот недавний пост на хабре, выход книги Remote от Джейсона Фрайда и приуроченный к запуску книги старт биржи поиска удалённых сотрудников от 37 Signals.
Сторонников у неё более чем достаточно, особенно среди работников, уставших изо дня в день добираться до офиса по сумасшедшим городским пробкам. Противников также немало и в первую очередь среди работодателей. Здесь я постараюсь объяснить, почему, несмотря на все минусы (многие из которых, к слову, либо временные, либо вымышленные), удалённая работа — это наше будущее, и будущее весьма близкое. Как человек из IT-индустрии, я конечно имею в виду в первую очередь её, но значительная часть этих наблюдений носит универсальный характер.
Сразу оговорюсь, я не хочу сказать, что работа в офисе уйдёт в небытие, она лишь превратится из единственного возможного способа в инструмент, решающий определённый спектр задач. Под катом список основных плюсов удалёнки для работника и работодателя, а в следующей части я постараюсь опровергнуть основные мифы, к которым часто апеллируют её противники.

Зачем?

Вообще, идея этого поста пришла мне в голову в тот самый момент, когда я, не имея до этого за плечами полноценного опыта фриланса, решил всерьез освоить oDesk. Да, если кто не знает, oDesk — это одна из крупнейших в мире фриланс-бирж. Итак, дело было в июле этого года. Официальной работы к тому времени у меня уже полгода как не было, все подработки закончились, новых серьезных заказов не предвиделось, и oDesk представлялся мне весьма перспективным вариантом. Аккаунт, как водится, был зарегистрирован «про запас» еще за год до того, но висел все это время без дела, поэтому начинать нужно было с нуля. При этом я был почти уверен, что руководство, хотя бы самое краткое, на тему, как и с чего начинать, я где-нибудь (уж на Хабре-то точно!) да найду.
Возможно, я плохо искал. Однако все, что мне попалось по теме, сводилось только к тому, что не нужно сразу загибать цены, лучше начинать с небольших. Примерная цитата: «начинайте с $10 в час, со временем, дорастете и до $15». Дорастать до $15, да еще и со временем, мне категорически не хотелось, я был уверен, что можно зарабатывать значительно больше. Да и кроме того, меня волновало огромное количество вопросов. Как заполнять профиль? На какие проекты откликаться? Как составлять cover letter? Как, черт побери, получить этот первый заказ, когда все тебе отказывают?
В тот момент я решил, что если все у меня получится, обязательно напишу то самое руководство для новичков, которого я не нашел.

Основатель самого известного бизнес-инкубатора Y-Combinator Пол Грэм высказал свои предостережения основателям стартапов. Все, кому интересны детали, могут прочитать исходный текст, для остальных вкратце изложу суть.