2016-05-29

Об MKS

Я был на MKS. Нет, это не международная космическая станция. Туда я вряд ли хоть когда-нибудь попаду. Это Magic Kick [for] Startup — волшебный пинок для стартапа. Милое интенсивное мероприятие для упоротых айтишников и начинающих бизнесменов.
МКС
Я туда пошёл со своей давней болью. Еще в конце 2011 я родил небольшое Android приложение, где реализовал своё видение того, как должна выглядеть нормальная реализация GTD. Судя по отзывам, идея понравилась. На практике оказалось, что GTD — это лишь частный случай. Очень удобно использовать приложение для хранения кучи заметок. Вполне возможно выразить в приложении и джедайскую методологию от Максима Дорофеева. Да и любую другую методологию.
Очень не хватало ещё одной важной фичи: синхронизации. Во-первых, задачи-заметки должны синхронизироваться между несколькими устройствами одного пользователя. Во-вторых, наборы задач-заметок должны синхронизироваться между разными пользователями, чтобы работать над ними совместно. Вот это я в одиночку не осилил, не нашёл пары-тройки человекомесяцев свободного времени.
Поэтому в прошлом году, на внутренней стажировке 7bits я поиграл роль заказчика. Заказал разработку библиотеки для синхронизации. По ходу дела и из-за специфики стажировки за два месяца получился некий неполный аналог Google Keep. Стажёрам помогло, мне — не очень.
В этом году стажировка тоже будет. А вот проекты на неё должны были обязательно пройти MKS. Ну чтобы убить нескольких зайцев. И формат нового стартапного мероприятия проверить. И стартапы прокачать. И на стажировку взять прокачанные и реальные проекты, с ощутимой перспективой.
Telenote logo
День первый. Воскресенье.
Собрались. Еле-еле, абы как, за минутку с лишним попытались рассказать про свои идеи. Пошло тяжело. Но пошло.
Станислав Триерс из ФРИИ рассказал, что такое ФРИИ. Фонд развития интернет-инициатив. Как они акселерируют, как вкладывают деньги, какие проекты берут. Похоже, Станислав способен рассказывать истории фриишных проектов бесконечно. А я начал догадываться, что мне их деньги не нужны. А им не нужен мой проект, ибо он не смасштабируется до миллиардов рублей через пару-тройку лет.
Андрей Брежнев из «Делфи» рассказал про ценностное предложение и как найти свою целевую аудиторию.
Домашним заданием выдали провести проблемные интервью. Штук пятьдесят. Опросить посторонних людей, есть ли у них проблемы, которые вы своим стартапом пытаетесь решить.
Первые интервью провели тут же на месте, друг с другом. Выяснилось, что те, кто уже пользуются каким-то приложением для ведения списков и заметок, вполне им довольны. Но есть боль в том, что ты-то пользуешься крутым приложением, а тот, кому тебе нужно ставить задачи, не пользуется и не хочет пользоваться. Ещё нашёлся ещё один конкурент, о существовании которого я не знал.
Я решил смухлевать, и тут же вечером запостил вконтактиках длинный опросник, в качестве онлайн интервью. Несколько человек ответило.
День второй. Понедельник.
Днём я, пользуясь служебным положением, опрашивал бедных студентов, которых мы собеседовали на стажировку.
Обнаружилось, что куча народу вообще не испытывает каких-либо проблем с заметками и задачами. Всегда можно кому-то позвонить и всё объяснить, или СМС отправить. А вопросы личной эффективности вообще мало кого волнуют. Конкурировать придётся даже не с другими приложениями, а с записками на холодильнике.
Внезапно нашлась дополнительная целевая аудитория. В онлайновых играх (которые MMORPG), оказывается, существуют кланы. И главари этих кланов должны раздавать задачи. За пределами самой игры. Что-то простое и мобильное сильно помогло бы.
Вечером собрались снова. Снова Андрей Брежнев прочитал скучную лекцию про бизнес-модели. Немного поделились о своих открытиях на целевых интервью.
Домашнее задание: продолжать делать интервью.
День третий. Вторник.
Опять интервьюировал итервьюируемых студентов. Всё плохо. Конкурировать нужно не только с холодильниками, но и с бумажными блокнотами.
Вечером Валентина Трухан из того же «Делфи» рассказала лекцию про то, как считать ёмкость рынка. Сколько и кому получится продать. Интересно.
Потом были рассказы про свои проекты. И Анна Тарасенко пытала всех, чтобы родилось целевое предложение. Это одной фразой, максимум парой предложений сказать, что делает продукт и какую боль решает.
У меня не получилось. Слишком много задач можно решать моим продуктом, слишком размазана аудитория, тяжело выдать, чем моё будет лучше.
Пока выступали другие, сидел и думал. И придумал фразу «коллективная эффективность». Это как личная эффективность, её тоже нужно повышать, но для маленького коллектива вроде семьи или игрового клана.
Домашнее задание жуткое. Окончательно сформулировать целевое предложение. Провести продажи: взять с кого-то денег или обещание дать денег за продукт. Подсчитать объём рынка.
Я опять воспользовался вконтактиками и спросил, кто готов хоть сколько-нибудь заплатить за инструмент повышения коллективной эффективности. Ответило несколько человек, на удивление были готовы дать аж $5, если штука получится клёвая.
День четвёртый. Среда.
Считал деньги. Посмотрел, сколько пользователей мобильных устройств есть в мире. Для справки: Гугль хвастается, что имеет один миллиард четыреста миллионов активных Андроид устройств, а Эпл хвастается, что имеет миллиард активных иОС устройств, включая часы и телевизоры. Прикинул по количеству установок самых матёрых конкурентов, сколько юзеров пользуются какой-нибудь программкой для списков и задачек: четыреста миллионов. Помечтал, что уж пяток миллионов юзеров я своим приложением привлеку. Посмотрел, сколько юзеров у конкурентов поставили им пять звезд, типа лояльная аудитория. Получилось где-то полпроцента. Прикинул, что если у меня будет такой же процент лояльных, и каждый даст по $5, то можно поднять $150 000. Вдохновляюще.
Вечером поделились своими расчётами. Валентина предложила мне подсчитать нелояльных пользователей конкурентов, вдруг они захотят переметнуться.
А потом хитрая Алёна Борзунова устроила длинный сюрприз. Мы взялись делать прототипы приземляющей страницы, то бишь лендинга. Подробнейше разрисовали личность потенциального пользователя. Придумали, в какой стрессовой ситуации ему потребуется наша услуга. Выписали, какие вопросы он будет задавать, зайдя на наш сайт. Начиная от «Что это?» и «Какого фига?». Нарисовали на бумажке, как должен выглядеть сайт, чтобы отвечать на эти вопросы. Повторили это упражнение дважды: сначала для выдуманного сайта, потом по некоторым нашим проектам.
Было очень шумно и весело. Но вот домой я попал лишь в полночь.
Домашним заданием было сделать настоящий лендинг.
День пятый. Четверг.
Подсчитал нелояльных пользователей конкурентов. Тех, кто влепил одну звезду. Получилось ну очень мало. Потом я вспомнил свой опыт, что одну звезду лепят либо те, кто не понял, либо те, у кого не заработало, либо всякие неадекваты. И подумал, что мне такая аудитория не нужна. Не стал менять расчёты.
Делегировал домен, купленный ещё почти год назад на стажировке. Придумал тексты. Вспомнил HTML. Наверстал простенький лендинг.
В качестве целевого действия думал взять сбор денег ради хорошей идеи на будущую разработку. Типа маленький карманный краудфандинг. Но постеснялся. Всё же приложение должно быть бесплатным, негоже всех сразу пугать «дай денег». Поэтому завёл группы вконтактиках и попросил зарегистрироваться в них.
Вечером Сергей Райкинен из «Фермы» рассказывал про продвижение лендинга, на примере Яндекс.Директ. Потом коллеги показывали свои лендинги.
Домой пришёл за полчаса до полуночи.
Домашка: разрекламировать лендинг, нагнать на него трафик. И, о ужас, подготовить финальную презентацию.
День шестой. Пятница.
Навёл простенькую красоту на лендинге. Навесил виджетов вконтактиков, чтобы было понятнее, что я хочу от посетителей.
Ввиду международности аудитории потыкал AdWords. Настроил рекламную кампанию. В отличие от Директа, AdWords сканирует целевую страницу и сам выдаёт наиболее релевантные запросы. Пульнул 150 рублей банковским переводом.
Чудом умудрился успеть набросать презентацию.
Вечером Анна Тарасенко рассказывала про MVP.
Кто смог, показал презентации. Моя более менее получилась, записал тройку замечаний.
Потом мы хорошо потренировались в прототипировании этого самого MVP на нескольких наших проектах. Заодно и надавали друг другу отзывов.
Я задумался, что три ключевых момента моего продукта: гибкость, оперативность и удобство, которые требуют, соответственно, работ над моделью данных, синхронизацией и юзабилити, будет тяжко урезать до MVP.
Домой добрался в одиннадцать. Поправил презентацию.
День седьмой. Суббота.
Журили.
Я вызвался выступить первым. Нормуль. Как я и ожидал, жюри не поняли проблемы. Но хоть согласились с формулировками. На самом деле, офигенский прогресс по сравнению с тем, что было неделю назад.
Выступали долго. Напоследок Анна Тарасенко, внезапно, выступила со стартапом под названием Magic Kick Startup. Рекурсия.
Жюрили долго.
Три проекта выиграли набор персональных пинков от членов жюри в течение месяца. Ивану Кудыку, с его идеей засевать поля лучше и роботами, досталась романтическая поездка на посевную на тракторе MTЗ-82 вместе с министром экономики Омской области Оксаной Николаевной.
Четыре проекта заполучили тот самый сертификат на два месяца разработки силами стажёров.
Все желающие могут податься в преакселератор ФРИИ.
Напоследок случилась обратная связь от жюри в лице Дмитрия Кисленко о том, что все проекты были скучны, непонятны и унылы. Что бедному жюри пришлось отсеивать худших, а не выбирать лучших.
Я выиграл ничего.
День восьмой. Воскресенье.
Полдня пишу этот пост.
Банковский перевод до AdWords ещё не дошёл, так что непонятно, что там с раскруткой лендинга.
Очень хочется прорисовать прототип MVP на бумажках и стикерах, и кому-нибудь показать. На бумажках я это уже делал. Но тут важно именно показать.
Думаю, что нафиг нужны эти аудитории-шмадитории, бизнесы-шмизнесы. Если есть идея, её нужно просто делать. И смотреть, что получится. Что-то подобное Влад Коробов кричал со своего места в жюри. Вопрос только в том, готов ли я всё бросить, пожить несколько месяцев на накоплениях и сделать свой продукт. Похоже, это — способ доказать, что я прав.
Ах да. Нужен инструмент повышения коллективной эффективности? Добро пожаловать на telenote.me. Оставляйте отзывы, будем думать, что делать дальше.

2016-05-15

О джедайской технике

Прошёл год жизни по джедайской технике. Может, конечно, я не такой уж и ярый последователь джедаизма от Макса Дорофеева, но задачки рисую и просматриваю.
Продолжаю пользоваться Микромильками, которые за этот год успели переименоваться в Maxdone. Типа, Макс сказал — Макс сделал.
Maxdone
В Микромильках и в концепции Макса под задачки предусмотрено три папочки: «Сегодня», «На неделе» и «Потом». У меня же сложилось их использование как: «В ближайшие дни», «В ближайшие недели» и «Потом». Да, такой я неспешный.
В первой папочке стабильно находится порядка пятнадцати задач. Во второй и третьей — под тридцать задач. Почему-то эти числа стабилизировались и почти не меняются. В день обычно делается от нуля до пяти-семи задач :)
Раз у меня нет папочки «Сегодня», у меня нет и ежедневного обзора задач. Как правило, я всегда точно знаю, что будет завтра, потому что в течение дня неоднократно заглядывал в задачки и календарь, и нет нужды это планировать. Либо я знаю, что то, что я буду делать завтра, выяснится только завтра утром, а значит, нет смысла что-то планировать.
А вот еженедельный обзор задач прижился. Я его делаю. Хотя по-прежнему не люблю и откладываю до последнего. Обзор нужен именно для того, чтобы обозреть все задачи. Секунд десять подумать над каждой: что она тут делает, нужна ли ещё, почему ещё не сделана, надо ли переформулировать, надо ли перенести в другую папочку. Весь обзор занимает не более пятнадцати минут. Зато ты восстанавливаешь в голове своё местоположение в ворохе собственных дел и планов.
Забавно, что в долгие праздники, когда конец недели расплывается на половину следующей недели, лень берёт верх, и задачи не пересматриваются до окончания празников. Смена ритма не идёт на пользу.
Микромильки хороши для записывания задач. Это действительно помогает. Когда тебя словили и говорят: вот тут так-то и так-то, сделай, пожалуйста, вот это и это. Без записывания ты просто киваешь головой, и забываешь. Теперь же ты киваешь головой, достаёшь телефон, и записываешь, что нужно сделать, в задачки (я записываю в «Сегодня»), и забываешь. В результате нет постоянного мельтешения мыслей: «а вот этого бы не забыть», «я же что-то там обещал». Просто, когда появляется возможность прерваться, берешь список задач, и видишь, что обещал сделать. Либо сразу делаешь, либо перекладываешь на потом.
Также очень прижилось обратное планирование в календаре. Это когда куда-нибудь едешь. Известно, когда отправляется поезд или вылетает самолёт. Это, время в пути, — событие в календарь. Но ведь на вокзале надо быть за полчаса до отправления, а в аэропорту регистрация заканчивается за сорок минут. Добавляем в календарь «Быть на вокзале/в аэропорту», прям событие такое. Но ведь туда ещё ехать где-то час. Добавляем событие «Ехать на вокзал/в аэропорт». Стоит один раз продумать всю эту суматоху с поездкой, а потом не нужно каждую минуту смотреть на часы: «ой пора уже ехать, или не пора?». Спокойствие повышается.
Инбоксы в почте у меня пустые. Ну почти. Всегда есть пара-тройка писем, на которые сегодня-завтра надо ответить. Или не надо, но надо хотя бы понять, надо ответить или нет. В общем, которые надо ещё обработать. Обработал — в Архив (в Gmail). За выходные, правда, накапливается десяток рабочих писем, которые надо разгрести в понедельник.
Стараюсь жёстко разделять работу и всё остальное. Задачи по работе — в Redmine, и смотрю я туда только когда на работе. Личные задачи — в Микромильках. Правда, когда ловят в коридоре, записать задачку удобно только в Микромильки, приходится потом переносить Редмайн.
Google Keep
Ещё я использую Google Keep. Для справочной информации, которой нужно поделиться. Типичный пример: список покупок. Покупки в конкретном магазине — это контекстная задача. Она не должна быть сделана ни сегодня, ни на неделе. Она должна быть сделана, когда в холодильнике становится пусто, и тогда приходится ехать в магазин, чтобы холодильник наполнить. В Микромильках неудобно держать такие задачи, ибо они связаны только с контекстом (в GTDшном смысле), а не со сроками. И в Микромильках нельзя редактировать задачу совместно. Вот тут Keep и пригождается. Там можно составить список покупок, расшарить его с женой, и совместно его забить нужными пунктами. Когда в магазине, вытаскиваешь эту заметку и идёшь по списку. А потом задвигаешь эту заметку подальше, чтобы перед глазами не маячила.
У меня сложилось впечатление, что полностью разделять справочную информацию и задачи — неверно. Понятно, что какой-нибудь длиннющий текст лучше засунуть в Google Drive, например. Но если этот текст связан с задачей, должен быть очень быстрый способ перейти от задачи к тексту. А всякие чеклисты вообще должны быть частью задачи. Но должны быть удобными.
Вообще, вырисовывается сложный многопользовательский кейс, который плохо ложится в Микромильки, и почти неосуществим в Keep. Хочется планировать, т.е. составлять целый набор задач на будущее, объединённые общей целью, — проект. Хочется назначать задачки на других людей (членов семьи, коллег, участников общего дела) и следить за их выполнением.
Да, это уже функционал того же Redmine или Trello. Но вот хочется не отделять это сильно от списка своих задач. А то возникает ситуация, аналогичная с нашими соцсетями или мессенджерами. Где я видел этот смешной пост с котиками: в Твиттере, Вконтакте? В каком тут чатике писали что-то важное: в Слаке, в Телеграме? Куда я засунул эту задачу: в Микромильки, в Keep, в Trello? «Инбокс должен быть один!»©™
Продолжаю считать, что я могу сделать заметочник/задачник, который будет гибче, универсальнее и удобнее, чем Micromiles и Keep. Посмотрим...
Впрочем, я сильно отвлёкся на инструмент. Концепция-то не изменилась. Записывать всё, чтобы не беспокоиться. Просматривать записи, чтобы не забыть и наводить порядок. Всё работает. Спасибо Максу.
Calm Jedi

2016-05-02

О gzip

Издавна файлы упаковывались и сжимались. Часто для экономии дискового пространства. Или же для передачи по сети. И как-то повелось, что сжимать нужно было сразу целые кучки файлов. Так родились такие милые форматы архивов, как Zip или Rar. Они выполняют сразу две задачи: засунуть кучу файлов в один файл и сжать всё это дело.
В мире Unix принято поступать своим путём. И эти две задачи разделены. За то, чтобы поместить кучу файлов в один большой файл, отвечает tar. Вообще-то, это — tape archiver, т.е. архиватор на ленту. Давным давно файлы нужно было засовывать в один непрерывный файл-поток для записи на магнитную ленту. Так и получался архив.
А вот сжатие архива делается отдельно. Формально, внешними утилитами. Такими, как gzip, bzip2, а в последнее время, ещё и lzma и xz. gzip использует тот же алгоритм сжатия Deflate, что и классический Zip. А lzma и xz реализуют алгорим LZMA (и LZMA2), те же, что в 7-zip.
Получается, что .tar.gz — это куча файлов в одном tar архиве, сжатое с помощью gzip. Это в некотором смысле противоположно zip архиву, где сначала сжимается каждый файл, а потом они помещаются в один архив. С другой стороны, у Rar и 7-zip есть возможность создания непрерывных (solid) архивов, когда всё происходит как в .tar.gz: сначала соединяем файлы, а потом всё жмём.
tar.gz
Юниксовые компрессоры gzip, bzip2, xz могут работать и без tar, сжимая один единственный файл. Как-то так:
% gzip big_long.log 
gzip жмёт похуже, bzip2 — получше, xz — ещё лучше. Но gzip жмёт всё же вполне прилично.
Допустим, у нас есть какой-то дурацкий лог-файл. Аж на 10 гигабайт.
% ls -s *.log
11002376 big_long.log
Этот файлик можно, конечно, засунуть в 7z архив.
% time 7z a big_long.7z big_long.log 

7-Zip [64] 9.20  Copyright (c) 1999-2010 Igor Pavlov  2010-11-18
p7zip Version 9.20 (locale=en_US.UTF-8,Utf16=on,HugeFiles=on,4 CPUs)
Scanning

Creating archive big_long.7z

Compressing  big_long.log      

Everything is Ok
7z a big_long.7z big_long.log  1955.19s user 33.48s system 118% cpu 28:03.36 total
Почти полчаса на то, чтобы сжать. Зато сжалось хорошо.
% ls -s1 *.log *.7z
  281720 big_long.7z
11002376 big_long.log
Сжалось аж почти в сорок раз.
Что с этим архивом можно сделать? Ну, распаковать.
% time 7z x big_long.7z                                 

7-Zip [64] 9.20  Copyright (c) 1999-2010 Igor Pavlov  2010-11-18
p7zip Version 9.20 (locale=en_US.UTF-8,Utf16=on,HugeFiles=on,4 CPUs)

Processing archive: big_long.7z

Extracting  big_long.log

Everything is Ok

Size:       11266426416
Compressed: 288475059
7z x big_long.7z  39.95s user 8.17s system 33% cpu 2:22.03 total
За две с половиной минуты мы можем получить наши десять гигабайт обратно.
Попробуем gzip.
% time gzip big_long.log 
gzip big_long.log  125.82s user 4.13s system 87% cpu 2:29.06 total    
Ухты. Две с половиной минуты на упаковку. Вместо получаса у 7z.
А что с размером?
% ls -s1 *.log *.gz
11002376 big_long.log
  456112 big_long.log.gz
Сжалось в два раза хуже. Но всё равно, четыреста пятьдесять мегабайт — это сильно транспортабельнее, чем десять гигабайт.
Что можно сделать с этим архивом? Можно распаковать.
% time gunzip big_long.log.gz 
gunzip big_long.log.gz  39.73s user 7.69s system 29% cpu 2:38.33 total
За те же две с половиной минуты.
Но можно и не распаковывать. Да.
Зачем нам этот лог? Файлик в десять гигабайт невозможно открыть ни в одном текстовом редакторе, памяти не хватит. Даже less не поможет, он тоже грузит файл в память. Его долго и проблематично грузить во всякие логстэши, в любом случае потребуется больше десяти гигов для хранения этой прелести. А я не хочу хранить, мне нужно найти пару десятков или сотен строк, относящихся к определённому моменту. Нам нужен grep.
Погрепаем десятигиговый файл.
% time grep "12:43:58" < big_long.log > big_long.grep_12_43_58.log
grep "12:43:58" < big_long.log > big_long.grep_12_43_58.log  9.32s user 7.55s system 13% cpu 2:07.35 total
Чуть больше двух минут на то, чтобы прочесть и профильтровать десять гигов, и получить сто семь строчек в двадцати семи килобайтах того, что нужно, и что можно открыть в редакторе.
Но gzip архивы можно грепать без распаковки.
% time zgrep "12:43:58" < big_long.log.gz > big_long.zgrep_12_43_58.log
zgrep "12:43:58" < big_long.log.gz > big_long.zgrep_12_43_58.log  48.25s user 3.80s system 116% cpu 44.796 total
Сорок пять секунд, и абсолютно тот же результат.
Как это работает? gzip — это поток, именно потому его используют веб-серверы для сжатия контента. Можно читать сжатые данные, разжимать их поблочно, сравнивать и грепать. Именно так и работает zgrep. Нет необходимости загружать все десять гигов в память, всё будет распаковываться маленькими кусочками по мере необходимости. А с диска читать нужно только сжатые данные, которых в двадцать раз меньше.
Есть куча других утилит, которые могут работать с файлами, сжатыми gzip, без явной распаковки. Собственно, zgrep — это, по сути, комбинация zcat и обычного grep. А есть ещё zdiff, zmore и zless.
gzip
Кстати, есть и bzgrep, и xzgrep.
Попробуем bzip2.
% time bzip2 big_long.log 
bzip2 big_long.log  2173.18s user 5.57s system 95% cpu 37:59.61 total
Доолго.
% ls -s *.bz2
250208 big_long.log.bz2
Сжал даже лучше, чем 7z.
Погрепаем.
% time bzgrep "12:43:58" < big_long.log.bz2 > big_long.bzgrep_12_43_58.log
bzgrep "12:43:58" < big_long.log.bz2 > big_long.bzgrep_12_43_58.log  249.57s user 11.47s system 106% cpu 4:05.09 total
Тоже долго. Дольше, чем читать несжатый файл.
Попробуем xz.
% time xz big_long.log
xz big_long.log  2326.37s user 6.65s system 98% cpu 39:18.39 total
Тоже долго.
% ls -s *.xz
253300 big_long.log.xz
Так же компактно.
Грепаем.
% time xzgrep "12:43:58" < big_long.log.xz > big_long.xzgrep_12_43_58.log
xzgrep "12:43:58" < big_long.log.xz > big_long.xzgrep_12_43_58.log  46.81s user 6.83s system 127% cpu 42.044 total
А вот тут быстро, почти как с gzip.
Выводы. Не засовывайте логи в архивы типа Zip, 7-zip, Rar. Сжимайте их в .gz. Тогда можно будет их обрабатывать без полной распаковки. Згрепать можно даже очень большие файлы. Если хочется сэкономить ещё немного места, можно взять bzip2 или xz вместо gzip, но помните, что gzip пакует значительно быстрее.

размер (в блоках)
время сжатия
время грепа
исходный файл, grep 11002376 02:07
gzip, zgrep 456112 02:29 00:44
bzip2, bzgrep 250208 37:59 04:05
xz, xzgrep 253300 39:18 00:42
7z 281720 28:03