Как выбрать нишу для бизнеса

Дерек Сиверс в недавнем интервью любопытно ответил на вопрос о том, как выбрать нишу, в которой начинать бизнес. Он сказал, что нужно выбрать такую нишу, в которой у вас будет несправедливое преимущество (unfair advantage).

Несправедливым преимуществом Дерек называет ваш уникальный опыт: такой, какого нет у конкурентов в той же нише. Он приводит в пример CD Baby, музыкальный онлайн-магазин, который он основал в 1997 и продал несколько лет назад за много миллионов денег: его несправедливое преимущество состояло в том, что он 13 лет был профессиональным музыкантом и понимал, в отличие от других многочисленных музыкальных стартапов, что именно нужно музыкантам.

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

Джэйсон Коэн, основатель Smart Bear Software, дал такое определение:

Несправедливое преимущество – это такое преимущество, которое нельзя легко скопировать или купить.

Мне не очень нравится термин, но смысл хороший.

Добавлено (2014-02-21): У Макса Крайнова в блоге написано немного подробнее про несправедливое преимущество.

Три черновика

Только что посмотрел видео, в котором Тим Феррисс и Нил Страусс, авторы бестселлеров, обсуждают написание книг, и вот что нашел полезным.

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

Первый черновик – для вас

В первый черновик вы записываете все, что пишется. Когда вы закончите работу над ним, перед вами будет лежать большая куча страниц (образно говоря; скорее большой файл) и на этих страницах будет написано все, что вы хотели сказать. Текст больше не сидит у вас в голове, а перенесен “на бумагу”.

Второй черновик – для читателя

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

Третий черновик – для ненавистников

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

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

Кстати, если вы читаете и пишете по-английски, подпишитесь на рассылку I Write Like: Become a better writer, где я ежемесячно делюсь советами экспертов про то, как лучше писать. Скоро выйдет февральский выпуск.

О переусложнении проектов

Переусложненный гамбургер (но, наверное, вкусный)

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

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

Линус Торвальдс

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

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

Препятствия, какие-то недодумки и недоделки не должны возвращать наши мысли в первую стадию (стоит ли делать проект), если, конечно, это не какое-нибудь фатальное препятствие (типа теоремы CAP, если планировали сделать систему со всеми тремя свойствами, или период полураспада ДНК, если хотели клонировать динозавров и сделать Парк Юрского периода).

Помните первый iPhone? Там не было даже копирования и вставки текста! Не знаю, были ли у Apple какие-то задумки о том, как реализовать копирование, но факт в том, что отсутствие этой фичи не отложило и не отменило проект.

Не зря стартаперы говорят про MVP, minimum viable product: просто если не сделать минимально пригодный продукт, можно вообще никакого не сделать. Это же относится и к проектированию, не только к непосредственно исполнению: не усложняйте задачу, придумывая препятствия, которых пока нет, и которых может и не будет никогда.

Sellme.ru умер, да здравствует Sellme.biz!

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

Sellme.ru меняет домен на Sellme.biz. Теперь бандиты не смогут отобрать у меня этот блог, они смогут только закрыть к нему доступ на захваченной ими территории.

Исходники сайта, включая все статьи и картинки, теперь можно скачать с Гитхаба.

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

У Sellme.biz появился твиттер, где будут анонсироваться новые посты — @sellmebiz. Зафолловьте его.

Старый домен будет продолжать работать в качестве редиректа на новый пока это возможно. Но, пожалуйста, обновите закладки. Новый адрес: https://sellme.biz.

Mémoires 4

Выпустил новую версию Mémoires, моей программы для ведения персонального дневника на Маке.

Скриншот Мемуарс 4

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

Скачать можно с официального сайта: http://www.codingrobots.com/memoires/ (сайт тоже полностью обновился).

Кстати, я веду тумблер о разработке (на английском): http://codingrobots.tumblr.com.

С наступающим!

Sellme.biz по почте

Так как Google Reader закрывается, а большинство читателей этого блога пользуется именно им для чтения Sellme.biz, хотел напомнить, что можно подписаться на получение новых заметок по электронной почте:

Введите свой email:

(если форма не работает, кликните по этой ссылке).

Я нынче в блог пишу не часто, но не хотелось бы с вами потеряться. Тем более, скоро будет несколько интересных анонсов.

Немножко нового кода

Написал на Go BLAKE-512 (в дополнение к BLAKE-256) и Skein (Threefish тоже). Обе хэш-функции не выиграли SHA-3, выиграл Keccak. Плохо, Keccak в софте медленный.

SipHash! Я рассказывал про SipHash? Это криптографическая функция (MAC): даете ей 128-битный ключ и текст любой длины, она считает 64-битный хэш. Очень быстро работает (> 1 гигабайта в секунду на компе 2009 года), но самое главное, быстро считает хэш очень коротких текстов (8 байт, например). Ее придумали Jean-Philippe Aumasson и Dan Bernstein для того, чтобы победить HashDoS. Ruby на нее недавно перешел и Rust тоже. Если будете писать хэш-таблицу, обязательно используйте SipHash – она почти так же быстра, как MurMurHash или CityHash, но в отличие от них, безопасна (повторяю – криптографическая функция). Люди-то думали, что достаточно впихнуть любое рэндомное число куда-нибудь в функцию, и тогда коллизии невозможно угадать; а Жан-Филиппе с Бернштейном показали, что это не так: коллизии, например, для MurMur можно сделать такие, что они вообще не будут зависеть от seed будь он хоть трижды рэндомным. Так вот, я, конечно же, написал пакет для Go.

А еще я перевел на Go Бернштейновскую криптобиблиотеку NaCl, а потом оказалось, что Adam Langley работал над тем же. Мы объединили мои версии на Go, его ассемблерные версии, он написал новый интерфейс (лучше), и теперь все это дело живет в официальном репозитории go.crypto (документация тут). Если вам надо что-то зашифровать в своей программе, обязательно используйте NaCl. Она в несколько раз быстрее какой бы то ни было нехардварной комбинации MAC с AES, а самое главное, интерфейс – проще некуда.

В go.crypto, кстати, теперь еще живет scrypt, которую я написал в апреле. Scrypt придумал Colin Percival. Если вам нужен хэш пароля, или надо пароль преобразовать в ключ для шифрования, используете scrypt и будете счастливы. А не как LinkedIn, у которого утекли пароли, или Bitrix24, который хвастается тем, что хэширует пароли “двойным MD5”. Интересно, как они пришли к тому, что двойной MD5 лучше, чем, например, пятерной? Хе-хе.

Richard Hipp придумал для прототипа SQLite4 хорошую кодировку для беззнаковых целых чисел. Опять же, я написал пакетик для Go. Смысл кодировки в том, что маленькие числа кодируются в маленькое количество байт, а большие числа – в большее количество байт, но не равномерно, как, например, у гугловского varint используемого в компрессоре Snappy, а оптимизированно под маленькие числа. Если Snappy кодирует число 200 в два байта, то эта кодировка – в один. Кроме того, по первому байту можно определить сколько еще байт в числе, а у Snappy для этого нужно читать байты до финального.

WebP. Помните еще такой формат картинок? Google придумал, Opera использует в “Turbo”. Так вот они теперь поддерживают альфа-канал в lossy картинках и добавили lossless, который сжимает лучше PNG. Я обновил свой QuickLook плагин (это который показывает картинки, если нажать пробел в Finder) – теперь он поддерживает все нововведения.

Еще я написал кучу строк кода для всяких секретных проектов, но пока рассказать о них не могу, потому что секретные проекты часто не релизятся.

Вроде все.

PS. За моим кодом можно следить на GitHub.

Исправленная уязвимость в Fossil

Fossil хранит все данные – коммиты, тикеты, странички вики, аттачменты, и т.д. – в виде артефактов, к которым он адресуется по SHA1 хэшу содержимого.

Например, вот так выглядит описание коммита (манифест) 30fbf3723ed00679c6 0006217c5d996b20cb5aa6:

C Add\stest.txt.
D 2012-08-12T11:40:52.146
F test.txt e2db724da21fa19b21835946bcf8359a598ef67c
P 337fd550fc7257170d25a6b22622c20d137d1b56
R 6e7be55bd50eabe58814c006fd8a25a6
U dchest
Z aa72952b1d3914bc6502058f0e66239a

Этот манифест говорит, что пользователем dchest был сделан коммит 8 августа 2012 года с комментарием “Add test.txt”, и что теперь в проекте 1 файл, test.txt.

Сами файлы хранятся аналогично: как видно из манифеста, файл test.txt адресуется по хэшу содержимого, e2db724da21fa19b2 1835946bcf8359a598ef67c.

This is test.

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

Fossil deconstructed repository

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

Как Fossil отличает простое содержимое файлов от манифестов? А никак – любой текст, который можно пропарсить как манифест, будет манифестом. В этом ничего страшного нет, потому что случайно сделать содержимое файла, который будет парсится как правильный манифест, сложно. А если неслучайно?

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

Вот как можно было делать коммиты в любой репозиторий Fossil без прав на коммиты, только с правами на аттачменты:

  1. Склонировать репозиторий.
  2. Понаделать нужных коммитов (например, встроить куда-нибудь бэкдор).
  3. Запустить fossil deconstruct и найти коммиты и новые файлы для этих коммитов.
  4. Создать тикет и прикрепить к нему, один по одному, содержимое файлов из пункта 3.
  5. Готово – теперь репозиторий содержит ваши коммиты!

Что еще хуже, в оригинальном репозитории в timeline новые коммиты не покажутся пока администратор репозитория не запустит fossil rebuild или не синхронизируется с другой копией репозитория, а те, кто склонирует оригинальный репозиторий получат и наши злые коммиты.

Я сообщил об этой уязвимости автору. Он закрыл уязвимость 4 апреля: теперь любой аттачмент, который парсится как манифест, просто сжимается gzip’ом, то есть, если вы приаттачили malicious_commit.txt, он окажется в репозитории сжатым в malicious_commit.txt.gz. Вот только новая версия Fossil (1.23) вышла 8 августа, и в release notes про уязвимость ни слова, поэтому если у ваших проектов была всем открыта возможность добавлять аттачменты, сделайте fossil rebuild и проверьте историю коммитов, убедившись, что в репозитории нет лишних (или отсутствующих) коммитов. Ну и, естественно, если вы еще сидите на старых версиях Fossil, срочно обновитесь или хотя бы запретите аттачменты.

Как сгенерировать случайный пароль

Совсем случайный. Компьютер такого не сможет! Этот метод так же можно использовать вместо занятий физкультурой.

  1. Открываем текстовый редактор (или бумажный блокнот).

  2. Берем монетку.

  3. Бросаем монетку и запоминаем результат.

  4. Бросаем монетку еще раз. Если результат такой же как в прошлый раз (орел-орел или решка-решка), оба результата игнорируются (можно записать прочерк “-”, чтобы потом посмотреть сколько всего бросков было). Если результат другой (решка-орел или орел-решка), записываем первый результат (1 - решка, 0 - орел) и забываем второй.

  5. Повторяем с шага 3 до получения нужного количества битов. Для 16-символьного пароля нам понадобится 96 битов, то есть 96 ноликов или единиц. В результате у нас получится что-то вроде этого: –1-0—-0-111–0-0–1110–011-00–1–00-1-1-1-1—00000011-1——-011… и т.д.

  6. Убираем прочерки и группируем получившиеся единички и нолики в столбик по шесть штук:

    100111
    001110
    011001
    001111
    000000
    111011
    ...
    
  7. Смотрим в эту табличку, ищем комбинацию из цифр и записываем соответствующую ей буковку.

    000000  A      100000  g
    000001  B      100001  h
    000010  C      100010  i
    000011  D      100011  j
    000100  E      100100  k
    000101  F      100101  l
    000110  G      100110  m
    000111  H      100111  n
    001000  I      101000  o
    001001  J      101001  p
    001010  K      101010  q
    001011  L      101011  r
    001100  M      101100  s
    001101  N      101101  t
    001110  O      101110  u
    001111  P      101111  v
    010000  Q      110000  w
    010001  R      110001  x
    010010  S      110010  y
    010011  T      110011  z
    010100  U      110100  0
    010101  V      110101  1
    010110  W      110110  2
    010111  X      110111  3
    011000  Y      111000  4
    011001  Z      111001  5
    011010  a      111010  6
    011011  b      111011  7
    011100  c      111100  8
    011101  d      111101  9
    011110  e      111110  +
    011111  f      111111  /
    

Таким образом у нас получится:

100111 n
001110 O
011001 Z
001111 P
000000 A
111011 7
...

Случайно сгенерированный пароль: nOZPA7…

* * *

Такие пароли не очень подходят для систем, где регистр букв не важен (например, n и N – одно и то же). Для них можно взять табличку ascii85 вместо base64, которую я тут привел (или придумать свою), и сделать пароль длиннее.

Почему нужно кидать монетку по два раза и игнорировать одинаковый результат? Чтобы превратить “biased coin” в “fair coin”.

Бросайте монетки на здоровье!

Порция ссылок

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

Программирование:

*) Как сказали на HN, “I sometimes wonder whether Russ Cox is actually human or is in fact a collective pen name for a group of very talented hackers”. См. количество коммитов в Go, например.

Исторического интереса ссылки: