Как появилось программирование без программирования
Как создали программы для программирования без программ для программирования?
Если коротко, то новые языки программирования и другие инструменты создаются на основе уже существующих. Полная аналогия с другими областями техники, где новые станки и материалы позволяют создавать всё более совершенные станки и материалы. Как все станки начались с палки-копалки и кремниевого рубила, так и языки программирования начались с перфокарт и нечитаемого двоичного кода.
Центральный процессор вашего компьютера понимает только программы, написанные на языке ноликов и единичек. Например, команда «прибавить константу 5 к числу, записанному в регистре AL» записывается так:
0000 0100 0000 0101
Здесь 0000 0100 — код операции «прибавить число к регистру AL», а 0000 0101 — двоичное представление числа 5.
На заре индустрии для ввода программы в компьютер нужно было либо перещёлкнуть сотни тумблеров на специальной панели (тумблер ВЫКЛ — нолик, тумблер ВКЛ — единичка), либо пробить дырочки в специальной перфокарте. Ошиблись в одной ячейке из тысячи — программа будет работать неправильно, будьте добры сами найти ошибку методом пристального взгляда.
Ясно, что такой способ программирования жутко неудобен и подвержен ошибкам. Чтобы не тратить время на это занудство, ленивые программисты начали думать, как переложить неблагодарную работу на машину.
Можно один раз хорошенько помучиться и написать на языке ноликов и единичек вспомогательную программу, которая называется ассемблер («сборщик»). Этот волшебный ассемблер принимает на вход человеко-читаемый текст и преобразует его в нолики и единички. Например, та же самая команда «прибавить константу 5 к числу, записанному в регистре AL» записывается на языке ассемблера x86 так:
Думаю, вы согласитесь, что это всё-таки более читаемо, чем 0000 0100 0000 0101. Здесь хотя бы понятно, что речь идёт о сложении (ADD) и числе 5. Теперь уже дело ассемблера преобразовать эту строчку в 0000 0100 0000 0101. На языке ассемблера сложно писать большие программы, процессоры разных производителей могут требовать разных ассемблеров, но всё равно это был большой шаг вперёд.
Дальше инженерную мысль было не остановить. Нужно один раз помучиться, чтобы написать на ассемблере компилятор языка программирования, например Фортрана. Потом ещё немного помучиться, чтобы написать на Фортране компилятор Алгола. Затем передохнуть, помучиться и написать на Алголе компилятор языка CPL. Ещё немного мучений, и можно на основе CPL написать компилятор языка C. Дальше можно уже не мучиться и в свое удовольствие писать на C компиляторы C++, Java, C# и других современных языков. Впрочем, никто не запретит использовать Java чтобы написать ассемблер x86 и замкнуть рекурсию.
Запуск топ-приложения в одиночку, бесплатно и без кодинга (ну почти)
Как выучить неправильные глаголы английского, если ты продуктовый менеджер?
Очевидно, сделать продукт для их изучения.
Так я и поступил. Пилил приложение в одиночку, по вечерам, после основной работы. Путь от сырой идеи до релиза занял месяц. Еще месяц ушел на то, чтобы вывести приложение на первые места стора по всем ключевым запросам.
Как это было, с чем столкнулся и какие выводы сделал – читайте под катом.
Вообще-то мне хотелось просто подучить неправильные глаголы.
Но, установив десяток приложений из топа стора, я так и не нашел ничего подходящего. Приложения были перегружены рекламой, неудобными интерфейсами и мудреными механиками. Многие сразу требовали заплатить им денег.
Посмотрев на все это безобразие, я невольно задумался – а что мешает сделать простейшее приложение самому? Механика несложная, а популярных irregular verbs всего штук 100…
Поэтому я взялся за ручку-блокнот и сделал черновой набросок основных экранов приложения. Получалось симпатично.
Так приложение выглядело на бумаге
Ограничения
Я старый солдат и знаю, что когда придумал продукт мечты – важно отсечь лишнее и оставить только ключевой функционал. Иначе есть риск попросту не закончить проект. Особенно если делаешь его в одиночку.
Классика инди-проектов
Поэтому в первую версию я заложил всего 2 фичи:
список глаголов, чтобы познакомиться с ними;
тренировки глаголов, чтобы закрепить их в памяти.
Кроме того, я решил, что приложение будет:
только под Android;
без адаптации под планшеты;
без подстройки экрана под разворот телефона;
работать без сервера.
В дальнейшем я неоднократно сказал себе «спасибо» за эти ограничения. Впрочем, все мы грешны. Поэтому в финальной версии были уже и пуш-уведомления, и геймификация, и статистика обучения. Но давайте обо всем по порядку.
Варфреймы
Скетчи на бумажке — это хорошо, но нужно детально продумать путь пользователя в приложении. Какие у него будут задачи и как он их решит?
Например, список слов. Что там будет? Только 3 формы неправильных глаголов? Но люди, которые учат глаголы, наверняка не знают всех переводов. А нужна ли им транскрипция? А озвучка? А прогресс изучения каждого слова? А возможность скрывать изученные глаголы?
Тут легко нагородить лишних механик или, наоборот, упустить что-то необходимое. Поэтому важно иметь вижн продукта.
Мой вижн звучал примерно так:
Приложение ориентировано на начинашек и должно полностью закрывать их потребность в изучении неправильных глаголов. Но делать это предельно просто и без занудства.
Не вдаваясь в детали, расскажу про 2 инсайта, которые я поймал в процессе прототипирования:
1. Горизонтальная ориентация
Изначально я представлял вертикальное приложение.
Это же привычно, плюс можно держать телефон одной рукой. Но особенность неправильных глаголов в том, что нужно отображать три их формы. А еще перевод, прогресс, озвучка… В вертикальном формате получалась какая-то каша.
Зато в ширину всё помещалось без проблем. Поэтому пришлось переделать все варфреймы под горизонтальную ориентацию.
Варфрейм достаточно точно отображает будущий интерфейс
Я думаю, это хорошая практика – не делать слепо «как у всех» или «как принято». А, наоборот, учесть особенности своего продукта. Так список глаголов мог бы быть слабой частью моего приложения, но стал преимуществом.
2. Отказ от клавиатуры
Я планировал, что в одной из тренировок будет ввод с клавиатуры. Надо же студенту запомнить, как пишутся глаголы, верно?
Но клавиатура ломала пользовательский опыт:
остальные тренировки сводились просто к выбору варианта, а тут такое усложнение;
в клавиатуре слишком много отвлекающего: переключение языков, знаки, цифры;
при выезде клавиатуры нужно как-то смещать или перекрывать контент.
Конечно, можно было сделать собственную, сокращенную клавиатуру. Но мне хотелось предельной простоты управления. Поэтому клавиатурную тренировку я заменил другой, похожей: собрать глагол из букв, перемешанных в случайном порядке.
Тренировка «Собери глагол по буквам»
Реализация
Итак, у меня было 2 пакетика варфреймов, пинта чистого энтузиазма и персональная лицензия на Construct 2. Не то чтобы это был необходимый запас для создания приложения, но выбирать не приходилось – ведь я не разработчик и современным языкам программирования не обучен.
Вообще Construct – это конструктор игр, позволяющий делать игры условно «без программирования». Вся логика строится на интерактивных объектах и событиях «если …, то …». По итогу в моем проекте получилось 322 таких события (это около двух тысяч строчек кода).
Но главная фишка Construct – возможность экспортировать готовый проект на множество платформ, в том числе на Android и iOS.
Уточню, что я неплохо знаком с этим конструктором. Собственно, персональную лицензию я получил, заняв призовое место в конкурсе игровых разработчиков Construct 2.
Немного о конструкторе
Конечно, возможность делать игры «без программирования» – не более чем маркетинговая замануха. Ничего серьезного так сделать не получится.
Но если с алгоритмическим мышлением у вас все в порядке, то Construct дает комфортную среду разработки. Здесь и переменные, и функции, и циклы, и массивы, и всякое такое прочее. Думаю, ближе всего это к визуальному программированию.
Пример кода, который отвечает за переключатели на экране настроек
Если стандартных возможностей конструктора не хватает – можно использовать JS-вставки. Например, я так делал для определения дня года.
Функция Construct на основе JS-кода
Еще один момент, который сильно облегчил и ускорил разработку, – возможность в реальном времени проверять результат. Это происходит так: я запускаю проект на компьютере, захожу на локальный хост из мобильного браузера и сразу вижу полноценное рабочее приложение на экране смартфона. Очень удобно.
Организация проекта
Постараюсь не углубляться в специфику Construct, но расскажу вкратце, как устроен проект.
Он состоит из лейаутов и списков событий. Для каждого экрана приложения я использовал собственный лейаут и список событий. Плюс в отдельном списке событий вел документацию по массивам, чтобы не забыть – что где лежит.
Структура проекта
Базу данных с глаголами, переводами и транскрипциями хранил в обычной табличке Excel. Загружал ее как JSON при запуске приложения. В самом приложении были массивы, отвечающие за статистику обучения и пользовательские настройки. Все изменения массивов сохранял в Local Storage смартфона.
Интересно, что бэклог проекта я вел просто в текстовом файле. И то, занялся этим в самом конце разработки – просто чтобы ничего не упустить. Большую же часть приложения сделал вообще «из головы». Это один из примеров запуска продукта без ТЗ, о которых обещал рассказать в прошлой статье.
Уточню, что код я достаточно подробно комментировал, иначе сам бы в нем быстро запутался.
Дизайн
То есть продукт должен быть, прежде всего, удобным. А красоту можно и позже навести.
Но, конечно, мне хотелось, чтобы приложение выглядело более-менее прилично и современно. Поэтому начал я со стандартного варианта: минимализм, flat design, бледно-голубые оттенки, вот это всё. Учитывая, что сам я не дизайнер, – это беспроигрышный вариант.
Но, поработав над приложением какое-то время, я задумался: «Какого черта? Я же делаю некоммерческий продукт для души. Зачем мне очередной клон Facebook с гаммой хирургического кабинета?». И перекрасил все в теплые ламповые цвета. А войдя в кураж, добавил ещё и лиса в шляпе, чтобы у приложения было узнаваемое лицо.
Учитывая, что Construct – все-таки игровой движок, я не удержался и сделал в главном меню анимированный фон с эффектом параллакса. Это не типично для обучающих приложений, поэтому должно было вызвать небольшой вау-эффект.
Стартовый экран с эффектом параллакса
Дизайн готовил в Adobe Illustrator – где-то с нуля, где-то на основе бесплатных векторных стоков. Векторная графика удобна, когда не умеешь рисовать: можно тягать точки, пока результат тебя не устроит. Таким макаром, например, я сделал заглавную иллюстрацию для этой статьи.
Сборка билда
Сборка билда под стор – тот еще головняк. Конечно, потом привыкаешь и делаешь все на автомате. Но в первый раз хотелось всё бросить.
Вот обобщенный порядок действий:
экспортировать готовый проект из Construct в формат Cordova;
с помощью Adapter сбилдить проект Cordova в apk-файл;
сгенерировать уникальную подпись разработчика;
с помощью Apk-signer подписать apk-файл;
с помощью Apk-signer верифицировать и выровнять apk-файл (что бы это ни значило);
залить готовый билд в стор;
а в первый раз нужно ещё установить и настроить все эти программы и библиотеки.
Самое забавное, что это – простой способ. Он считается аморальным. Есть еще «правильная сборка», которая предполагает древние языческие ритуалы и компиляцию через консольные команды. Кому интересно – вот видеоинструкция.
Когда делаешь приложение в конструкторе игр
Конечно, для меня это всё – темный лес. Я же продакт, у меня лапки!
Как пользователь Construct я хотел бы, чтобы компиляция делалось одной кнопкой «Превратить проект в готовый apk-файл». Наверное, тут Construct сильно уступает «настоящим» средам разработки? Или там такая же морока? Кто в теме, напишите в комментариях, пожалуйста.
Тестирование
Проверялось приложение вручную. Для этого я:
собирал билд и прокликивал его на телефоне;
открывал проект в окне браузера на ПК и тестировал приложение на основных мобильных разрешениях;
сбрасывал тестовый билд друзьям для проверки на других устройствах;
добавил в настройках возможность полного сброса прогресса.
Релиз в Google Play
Должен признаться, Google, я разочарован.
Я привык, что продукты Google для широкой аудитории (почта, поиск, карты, переводчик, гуглдоки) – шикарны. Но когда речь заходит о профессиональных инструментах – все очень-очень плохо.
Достаточно сравнить Google Analytics и Amplitude, чтобы понять, насколько отстал Google.
Google уже не торт
Та же история и с Google Play Console для разработчиков. Кажется, ее делали с похмелья какие-то джуны. Я не понимаю, как компания с неограниченным бюджетом может делать настолько запутанные и нелогичные интерфейсы. А почитайте, что пишут в отзывах про их приложение. Жуть.
Не буду утомлять вас деталями, но благодаря «великолепно» спроектированной Google Play Console я зарелизил свое приложение… случайно! Причем Google не позволяет отменить релиз. Позже я выяснил, что многие столкнулись с такой же проблемой. Повезло, что мое приложение было в приличном виде на момент релиза.
Исторический момент
В общем, тут совет такой: будьте осторожны при заливке билда через Google Console, а лучше потренируйтесь сначала на тестовом приложении.
Проблемы
Как говорят в народе: «Скоро статья пишется, да не скоро билд эпрувится». И действительно, в процессе работы над приложением я столкнулся с рядом проблем. Вот самые неприятные из них:
1. Адаптивность дизайна
Чтобы приложение смотрелось адекватно на любых экранах, приходилось:
масштабировать интерфейс согласно разрешению;
закреплять элементы относительно края экрана;
рассчитывать позицию кнопок на основе ширины и высоты видимой области;
проверять все изменения адаптивности на десятке ключевых разрешений.
И это всё равно не решает вопрос на 100%.
Впрочем, результатом я горжусь – приложение смотрится адекватно даже на телефонах, которых ещё не существовало на момент релиза.
2. Работа без аналитики
Как продуктовому менеджеру, мне очень некомфортно работать без аналитики. Может и есть какой-то способ ее подключить к проекту Construct, но простого решения я не нашел. Поэтому пришлось делать приложение фактически вслепую, полагаясь только на свой вижн и экспертизу.
3. Отсутствие сервера
В принципе, Construct позволяет взаимодействовать с сервером. Но для этого нужен бэкенд-разработчик и хост. Так что решение делать игру без сервера было верным. Тем более, это позволило приложению запускаться локально на смартфоне и работать офлайн.
Но проблема в том, что без сервера нельзя организовать взаимодействие между пользователями или собрать общую статистику по ним. Ну и при чистке Local Storage весь прогресс обучения потеряется.
4. Неполный контроль
Конструктор упрощает разработку, это правда. Но обратная сторона этого решения – невозможность исправить низкоуровневую техническую проблему, если таковая возникнет.
Например, несколько пользователей пожаловались, что в приложении нет озвучки. Причем после перезагрузки она появилась. Я догадался, что звуки просто не успевают прогрузиться. И все, что я смог сделать, – это искусственно увеличить время загрузки приложения. Хорошо, что это помогло. Иначе у меня не осталось бы инструментов, чтобы исправить проблему.
5. Планшеты
Как у разработчика у меня может быть 100500 причин, почему я не хочу делать поддержку планшетов. Например:
моя целевая аудитория не использует планшеты;
мой продукт не подразумевает использование на планшете;
у меня маленькая команда и нет ресурса на планшетную версию;
я хочу обкатать продукт на мобайле, а потом уже делать версию для планшета.
Но Google не позволяет отсечь планшеты – ни при установке приложения, ни в рекламе.
Результат предсказуем – владельцы планшетов качают приложение, разочаровываются, ставят низкие оценки. Спасибо, Google.
Продвижение
Итак, спустя месяц разработки, я зарелизил приложение.
Жду день, жду второй… В выдаче стора оно не появляется. Почитал на форумах, что индексироваться может до недели. Ну что поделать, жду неделю. Ни-че-го.
Google, само собой, даже не пытается сделать этот процесс прозрачнее для разработчика.
Наконец, спустя 10 дней, приложение появляется в выдаче… на 143 позиции!
Первая реакция на появление приложения в выдаче
Делать нечего, пришлось заняться продвижением:
прошу друзей установить приложение и поставить ему 5 звезд;
полностью переписываю ASO-текст, включая туда максимум релевантных ключевых слов;
перерисовываю скриншоты для стора, делая их симпатичнее;
размещаю ссылку на приложение на нескольких ресурсах вроде 4PDA;
отвечаю на все комментарии пользователей, иногда использую ключевики в ответах;
делаю пробную закупку рекламы Google Ads (получилось недорого, порядка 5 центов за установку, всего потратил около 20$);
правлю баги и выкатываю новые версии – чтобы стор видел, что приложение живое и дорабатывается;
в самом приложении делаю страничку с просьбой оставлять оценки-отзывы.
Чтобы отслеживать позиции приложения по разным ключевикам – регистрируюсь в сервисах AppFollow и ASODesk. Первый дает больше бесплатных возможностей, второй шлет письма с отчетами о позициях приложения.
Итоги всей этой движухи спустя примерно месяц:
Отчет ASODesk
На самом деле, я вижу ряд причин, почему так получилось:
Ниша специфическая. Приложений, заточенных под изучение неправильных глаголов, не так много. То есть конкуренция не большая.
Я выбрал довольно удачное название – в него удалось впихнуть важные ключевые слова.
Первое время рейтинг приложения зашкаливал – там были сплошные пятерки, несколько четверок и ни одной оценки ниже.
Рекламная кампания была небольшой, зато своевременной – показала стору хорошую динамику скачиваний.
Приложение достаточно удобное, бесплатное, работает офлайн, в нем нет рекламы – думаю, это положительно сказалось на поведении пользователей и их оценках.
Удержание пользователей
Так как аналитики у меня не было – пришлось полагаться на свой опыт. Для удержания пользователей я решил использовать геймификацию и пуш-уведомления.
Геймификация
Проблема всех образовательных продуктов – мотивация студента. Поэтому нужно было дать студенту какую-то понятную ежедневную цель. А в идеале – еще и причину, чтобы вернуться завтра.
Каждый день генерировал «цель дня»: пройти Х упражнений, дать Х правильных ответов. Если брать все сочетания, то возможны 15 различных целей дня. Плюс в настройках можно выбрать их сложность.
Ввел понятие «ударный темп». Это количество дней подряд, когда цель дня выполнялась. Если пропустить день – ударный темп обнуляется.
В процессе выполнения упражнений отображается прогресс цели дня, а иногда выскакивает лис и дает мотивирующие комментарии.
Акцент на прогрессе цели дня
Уведомления
Изначально казалось, что подключить пуши не получится.
Но в результате, с помощью стороннего плагина Construct, сервиса OneSignal и такой-то матери – я их все же прикрутил.
Пуш-уведомления дают возможность вернуть студентов, которые пару дней не открывали приложение. А еще удобно уведомлять старых пользователей о выходе новой версии.
Из интересного – я не стал делать безликие триггерные пуши в духе «Пора заниматься!». Вместо этого рассылал уведомления вручную, каждый раз выбирая время и инфоповод.
Пуш на 14 февраля 
Пуш в начале пандемии
От 8 до 20% студентов, получавших такие уведомления, – тут же открывали приложение.
Оценки и отзывы
Когда делаешь коммерческое приложение в рамках работы – относишься к оценкам как к одной из многих метрик продукта. Но когда делаешь приложение «для души» – отзывы превращаются в значимый эмоциональный фактор. Они действительно могут мотивировать работать дальше.
Душевные отзывы
Ну или демотивировать.
Первая единица
Потому что даже одна единица сразу сбивает рейтинг приложения. И тогда думаешь: «Зачем мне это всё? Можно ведь вечер и лучше провести, а не возиться с вот этим всем».
Пару оценок удалось исправить, отвечая пользователям. Но в целом не стоит рассчитывать на объективность – люди могут пользоваться приложением и написать радостный отзыв, но при этом поставить тройку, потому что «могло бы быть и получше».
Выводы
В статье было много практичных мыслей, поэтому позвольте теперь поделиться общими впечатлениями.
В который раз я убедился, что лучший способ чему-то научиться – попробовать сделать это на практике. Пройти путь от начала до конца, пусть даже «на минималках».
К примеру, когда нужно объяснить правила настольной игры новичку – можно долго про них рассказывать, пока вообще не перехочется играть. Или просто начать играть, разбираясь по ходу дела.
С приложением (да и с жизнью в целом, наверное) – такая же история. Если выяснять все возможные проблемы и подводные камни, то начинать что-то делать страшно. Но если позволить себе чуть-чуть пофантазировать, немного изучить вопрос, сделать небольшой прототип… можно очнуться, когда все уже получилось.
Еще хочу сказать, что это большое удовольствие – делать что-то в одиночку. На работе мне достаточно написать задачу – и целая команада профессиональных разработчиков воплотит ее в лучшем виде: учтет все кейсы, архитектуру, адаптивность, секьюрность, нагрузку. Но когда работаешь в одиночку, то вообще не нужно писать задач, ждать конца спринта, что-то кому-то объяснять. Просто воплощаешь свой вижн – напрямую, непосредственно. Это увлекает. Думаю, что-то подобное чувствует художник, работая над картиной.
Спустя год
Прошло уже больше года с момента релиза приложения. Сейчас у него около 12 000 установок и средняя оценка «4,6». Какое-то время я еще занимался приложением: рассылал пуши, правил баги, добавил несколько фич по просьбе студентов.
Но потом забросил и только иногда отвечаю на отзывы.
В начале пандемии был пик скачиваний, но из-за отсутствия обновлений – приложение потихоньку теряет позиции, а с ними и количество ежемесячных установок.
Ежемесячные установки за весь период жизни приложения
В общем-то, можно было бы и дальше работать над ним, но без аналитики непонятно куда двигаться и как влияют доработки.
Конечно, есть и очевидные улучшения. Например, можно записать качественную озвучку с профессиональным диктором, носителем языка. Или нанять хорошего UI-дизайнера. Но и то, и другое будет стоить по несколько тысяч долларов. Не совсем понятно, зачем этим сейчас заниматься.
Поэтому я довольствуюсь тем, что получил ценный опыт и сделал что-то полезное для людей. Может быть, когда-нибудь появится вдохновение, и я продолжу эту историю.