на чем писать серверную часть мобильного приложения
Разработка сервера мобильных клиентов
Обратная сторона мобильных клиентов — сервер.
Введение
Не открою секрета, что разработка мобильных приложений в тренде – этому способствует стремительное техническое развитие: мобильные устройства с каждым годом улучшаются по всем характеристикам и становятся доступнее для широкого круга людей. Почти каждый, кто имеет на руках мобильный гаджет (будь то смартфон, коммуникатор или планшет) пользуется приложениями: браузером, клиентом электронной почты и мгновенных сообщений, играми, бизнес или финансовыми программами. И зачастую от пользователей скрыто то, что многие из приложений взаимодействуют с удаленным сервером: обмениваются с ним данными через Интернет.
По роду деятельности (Java разработчик серверных приложений) мне в команде приходится разрабатывать сервера для мобильных клиентов (за последние 2 года участвовал в реализации 3-х таких проектов для зарубежных компаний). Определился набор Java-технологий для решения задач такого рода, который варьируется в зависимости от требований и целесообразности (другими словами — желания), благо свобода при выборе технологий позволяет экспериментировать. Сформировавшейся точкой зрения и опытом хотел бы поделиться с сообществом.
Требования
Особенностью является то, что формируются требования и для серверного, и для клиентского приложения, которые в ряде случаев взаимосвязаны. Для начала опишу базовые требования в контексте механизма обмена данными:
• кроссплатформенность клиента: зачастую важно обеспечить поддержку разных платформ — Android, iOS, Windows Phone и пр. Редко заказчик довольствуется одним видом устройств.
• быстродействие: должна обеспечиваться достаточная для workflow скорость работы, комфортный отклик на графическом интерфейсе пользователя;
• простота: чем проще API протокола, тем меньше времени уходит на реализацию и поддержку кода, тем меньше может быть квалификация разработчика;
• эффективность: чем сложнее реализация протокола, тем больше потребляется ресурсов мобильного устройства, которые ограничены.
Дополнительные требования зависят от специфики приложения:
• масштабируемость сервера – для SaaS, социальных приложений, где в идеале ожидается большой поток посетителей, это условие обязательно. Для бизнес приложений, где есть ограничения по числу пользователей или численность прогнозируется, данное свойство не требуется;
• интерактивность: ряд приложений нужно обеспечить механизмом нотификаций – сообщить приложению (пользователю) о наступлении определенных событий, передать сообщение пользователю. Данным свойством должна обладать, например, биржевая система или автоматический диспетчер такси.
• открытое API: предполагается, что сторонние разработчики могут воспользоваться функционалом системы посредством документированного протокола. Ведь клиентом может быть как мобильное, так и внешнее серверное приложение.
• другие требования…
Команда
Состав проектной команды для разработки системы в идеале может быть следующим:
• менеджер проекта: управляет, контролирует проект, напрямую взаимодействует с заказчиком;
• разработчик серверного приложения: разрабатывает сервер бизнес логики, базу данных, сетевой протокол;
• разработчик приложения администратора: разрабатывает Web приложение, пользовательский интерфейс для настройки и управления серверным приложением;
• разработчик клиентского приложения для Android;
• разработчик клиентского приложения для iOS;
• разработчик клиентского приложения для …
• тестировщик: тестирует приложение администратора и клиентские приложения.
Внимательный читатель заметит, что в случае написания серверного приложения с графическим интерфейсом, например, на HTML5, можно сэкономить. В этом случае не требуется разработка клиентских приложений – интерфейс пользователя предоставляет браузер. Данная статья не рассматривает такой случай, идет речь о разработке ”родных” (native) приложений для мобильных устройств.
Мне доводилось работать в команде с полным составом, но будет реалистами – не всегда человеческие ресурсы и бюджет позволяет собрать такую команду. И иногда роли приходится совмещать: менеджер проекта + разработчик серверного приложения, разработчик клиентского приложения + тестировщик.
Технологии, инструменты, библиотеки
Для разработки сервера мобильных клиентов обычно использую следующий стек “свободных” технологий:
• Apache Tomcat – контейнер сервлетов;
• MySQL – СУБД;
• Subversion – система версионного контроля;
• Maven – фреймворк для автоматизации сборки проектов;
• JUnit – обеспечит эффективность автоматического тестирования приложений;
• Apache Log4j – библиотека логгирования;
• Jenkins – система непрерывной интеграции;
• Hibernate – ORM (настройки, конфигурация в properties, xml файлах и в аннотациях);
• hibernate-generic-dao – реализация DAO от Google, реализует основные методы для работы с данными базы данных, упрощает реализацию фильтрации и сортировки в методах;
• Spring – реализация аутентификации и авторизации (security), контейнер сервисов и бинов (конфигурация в xml файлах и в аннотациях), используем также при создании тестов.
В зависимости от специфики системы и требований к ней использую один из 2-ух вариантов реализации протокола обмена данными.
Когда требуются кроссплатформенность, быстродействие, простота, эффективность, масштабируемость, открытое API, то беру Jersey – реализацию Web-сервисов REST (RESTful Web services). Эта библиотека позволяет использовать сериализацию данных в формате JSON или(и) XML. Конфигурация REST ведется посредством аннотаций. Для обмена с мобильными устройствами взят формат JSON по причине того, что имеет более простую реализацию на стороне клиента (по этой причине не используем “классические” Web-сервисы), генерируется меньший объем трафика. Jersey позволяет настроиться на наиболее подходящий “вид” JSON.
В ином случае, если необходимы кроссплатформенность, высокое быстродействие, простота, эффективность, интерактивность, то беру
• Apache MINA – framework для создания сетевых приложений,
• Google protobuf – библиотека кодирования и декодирования структурированных данных. Структура данных определяется заголовочными файлами *.proto, компилятор генерирует из них Java классы (также есть возможность генерации для других языков программирования: C++, Objective-C и т. д., что обеспечивает свойство кроссплатформенности);
• java.util.concurrent – используем стандартный пакет.
Данный вариант может масшабироваться, но на это требуется закладываться на этапе проектирования на уровне архитектуры, учитывая бизнес логику.
Рассмотрим гипотетическую задачу на примере выбора технологий для реального SaaS сервиса – “Аукцион услуг “Аукнем”, который позволяет людям сформировать заказ на выполнение требуемых услуг или работ, а организациям в свою очередь оставить для них свои предложения. Берем все базовые требования по умолчанию. Ввиду того, что регистрация в этой системе свободная и бесплатная, то однозначно к ним требуется добавить масштабируемость. А что на счет интерактивности? Было бы здорово сообщать подрядчикам (исполнителям) о создании новых заказов, а заказчиков информировать о поступивших предложениях в тот же миг в приложении, а не только по электронной почте. На основания этого возьмем для реализации Apache MINA, Google protobuf. Смотрим следующее свойство — открытое API. Сервис общедоступный, потому предположим, что внешние разработчики могут проявить интерес к интеграции с ним. Постойте! Не все так просто. Протокол на базе Apache MINA достаточно сильно зависит от реализации и интеграция без знания нюансов отнюдь не прозрачна. В такой ситуации придется взвесить, какой фактор важнее и сделать выбор.
ASP.NET Core: Создание серверных служб для мобильных приложений
Представляем вторую часть из серии статей, посвящённых разработке на ASP.NET Core. В этом обучающем материале вы узнаете, как создавать серверные службы с помощью ASP.NET Core MVC для поддержки мобильных приложений.
Второй цикл статей по ASP.NET Core
Первый цикл статей можно найти здесь.
Образец мобильного приложения
Мобильные приложения могут без труда обмениваться данными с серверными службами ASP.NET Core. Здесь можно скачать образец кода серверных служб.
В данном материале в качестве клиента используется приложение Xamarin Forms ToDoRest. Оно включает отдельные клиенты для устройств под Android, iOS и Windows. По ссылке выше вы найдёте руководство, которое поможет создать приложение (и установить необходимые бесплатные инструменты Xamarin), а также сможете скачать образец решения Xamarin. В него входит проект двух служб ASP.NET веб-API, на замену которым приходит приложение ASP.NET Core из этой статьи (со стороны клиента изменения не понадобятся).
Функции
Приложение ToDoRest поддерживает составление списков, добавление, удаление и обновление элементов To-Do. Каждый элемент наделён своим идентификатором, названием, примечаниями и свойством, которое указывает, выполнен ли элемент.
В основном представлении элементов, как показано выше, имеется название каждого элемента, а наличие флажка указывает, был ли он выполнен.
Коснитесь значка +, чтобы открыть диалоговое окно для добавления элементов:
Коснитесь элемента в главном списке, чтобы открыть диалоговое окно для редактирования названия, примечания и статуса выполнения, либо чтобы удалить элемент:
Создание проекта ASP.NET Core
Создайте новое веб-приложение ASP.NET Core в Visual Studio. Выберите шаблон веб-API и отключите аутентификацию. Присвойте проекту имя ToDoApi.
Примечание: обязательно запустите приложение напрямую, а не через IIS Express, который по умолчанию игнорирует не локальные запросы. Выполните dotnet run из командной строки либо выберите название приложения из раскрывающегося меню Debug Target на панели инструментов Visual Studio.
Добавьте класс модели для представления элементов To-Do. Отметьте обязательные поля с помощью атрибута [Required] :
В этом примере при реализации используется частная коллекция элементов:
Настройте реализацию в Startup.cs:
Теперь можно перейти к созданию ToDoItemsController.
Создание контроллера
Для работы контроллера необходим параметр IToDoRepository; запросите экземпляр этого типа через конструктор контроллера. В среде выполнения этот экземпляр будет предоставлен благодаря поддержке платформы для внедрения зависимости.
Этот API поддерживает четыре команды HTTP для операций создания, чтения, обновления и удаления (CRUD) в источнике данных. Самая простая операция — Read (чтение), она соответствует запросу HTTP Get.
Чтение элементов
Метод List выдает код ответа 200 OK и список всех элементов ToDo, сериализованных как JSON.
Вы можете протестировать новый метод API с помощью ряда инструментов, например Postman, как показано ниже:
Создание элементов
Внутри метода проверяется, правильно ли составлен элемент и существовал ли он ранее в хранилище данных; если ошибок нет, он добавляется с помощью репозитория. ModelState.IsValid выполняет проверку модели; это следует сделать в каждом методе API, который принимает вводимые пользователем данные.
В образце используется перечисление кодов ошибок, передаваемых в мобильный клиент.
В ответе метод выдает только что созданный элемент.
Обновление элементов
Чтобы протестировать Postman, измените команду на PUT и добавьте ID обновляемой записи в URL. Укажите данные обновляемого объекта в теле запроса.
При успешном выполнении метод выдает ответ NoContent (204), обеспечивая тем самым согласованность с существующим API.
Удаление элементов
Помните, что при тестировании функции удаления в тело запроса добавлять ничего не нужно.
Простой клиент-сервер на Android (интернет-мессенджер)
Важно. Все написанное ниже не представляет собой какой либо ценности для профессионалов, но может служит полезным примером для начинающих Android разработчиков! В коде старался все действия комментировать и логировать.
Поехали. Многие мобильные приложения (и не только) используют архитектуру клиент-сервер. Общая схема, думаю, понятна.
Уделим внимание каждому элементу и отметим:
Клиент, установленный на устройстве А, посылает сообщение для клиента, установленного на устройстве Б. И наоборот. Сервер играет роль связующего звена между устройством А и Б… С, Д… и т.д. Также он играет роль «накопителя» сообщений, для их восстановления, на случай удаления на одном из клиентских устройств.
Для хранения сообщений используем SQL БД как на сервере, так и на устройствах-клиентах (в принципе, вся работа клиентов интернет-мессенджеров и сводится к постоянной синхронизации локальной и удаленной БД с сообщениями). Дополнительно, наш интернет-чат будет уметь стартовать вместе с запуском устройства и работать в фоне. Взаимодействие будет происходить путем HTTP запросов и JSON ответов.
Более логично, если синхронизация происходит через порт/сокет, это с одной стороны упрощает задачу (не нужно циклично слать HTTP запросы на проверку новых сообщений, достаточно проверять состояние прослушиваемого сокета), но с другой стороны, это усложняет создание серверной части приложения.
Делаем сервер
Для реализации «сервера», нам нужно зарегистрироваться на любом хостинге, который дает возможность работы с SQL и PHP.
Создаем пустую SQL БД, в ней создаем таблицу.
Структура запросов к api:
Клиентская часть
Теперь структура Android приложения:
В фоне работает FoneService.java, который, в отдельном потоке, каждые 15 секунд делает запрос на сервер. Если ответ сервера содержит новые сообщения, FoneService.java записывает их в локальную БД и отправляет сообщение ChatActivity.java о необходимости обновить ListView, с сообщениями. ChatActivity.java (если она в этот момент открыта) получает сообщение и обновляет содержимое ListView из локальной БД.
Отправка нового сообщения из ChatActivity.java происходит сразу на сервер, минуя FoneService.java. При этом наше сообщение НЕ записывается в локальную БД! Там оно появится только после получения его назад в виде ответа сервера. Такую реализацию я использовал в связи с важным нюансом работы любого интернет-чата — обязательной группировкой сообщений по времени. Если не использовать группировку по времени, будет нарушена последовательность сообщений. Учитывая, что клиентские приложения просто физически не могут быть синхронизированы с точностью до миллисекунд, а возможно будут работать даже в разных часовых поясах, логичнее всего будет использовать время сервера. Так мы и делаем.
Создавая новое сообщение, мы передаем запросом на сервер: имя автора сообщения, имя получателя сообщения, текст сообщения. Получая эту запись назад, в виде ответа сервера, мы получаем то, что отправляли + четвертый параметр: время получения сообщения сервером.
Какой серверный язык выбрать…мобильному разработчику
Вы скажете, какое вообще дело мобильному разработчику до того, на чем написан бэкенд. Главное, чтобы API туда был удобный, понятный, гибкий. А нам так не кажется.
Мы в AppsConf думаем, что всем нам необходимо иногда выходить за пределы мобильной разработки и прокачивать шляпку буквы T в модели T-shape. Вот, например, познакомиться с серверными языками чуть глубже, чем: «Я слышал, что Ruby умер». И чуть шире — то есть не только с популярными, но и из вторых рядов и даже андеграундными.
Чтобы и вы прониклись идеей Introductory-трека, записали интервью с Никитой Соболевым. Собирались говорить о языках программирования, а получилось о программистах. Заходите под кат, если считаете, что лучше быть просто хорошим разработчиком, а не Android- или iOS-разработчиком, а особенно, если не согласны с этим. Пятница — самое время поспорить.
— Как тебе идея целого трека обзорных докладов по разным технологиям от бэкенда до фронтенда на конференции по мобильной разработке, который мы назвали Introductory?
Никита Соболев CTO в wemake.services, автор методологии Repeatable Software Development Process, организатор ElixirLangMoscow, член программного комитета Moscow Python Conf++, частый спикер на IT-конференциях и борец за качество кода.
На мой взгляд, это лучший трек на мобильной конференции.
Мне вообще очень не нравится идея узких специалистов. Мне гораздо ближе идея T-shape person — то есть человека, хорошо разбирающегося в чем-то одном, но при этом с широким горизонтом понимания проблем в предметной области.
К сожалению, мне кажется, что мобильные разработчики в этом смысле сами по себе. Дело усугубляется еще тем, что они очень сильно зависят от вендора. Грубо говоря, закроется Apple — они уйдут на мороз.
Поэтому мне очень нравится идея Introductory-трека и то, что гостям конференции предлагают посмотреть вокруг, узнать, что есть у других, перенять их опыт и улучшить себя как специалиста в плане широты взглядов.
— Для каких еще конференций актуальна эта идея?
Для очень многих. У меня под рукой пример Python. В прошлый раз мы пригласили специалистов по Go, Elixir и Julia. В этом году я хочу пригласить фронтендера и хаскелиста (кстати, Call for Papers уже открыт). Потому что Python-разработчики тоже разные, многие из них работают как full-stack, им тоже полезно нагребать знания со стороны.
— Как думаешь, мобильные разработчики стали охотнее смотреть по сторонам, потому что это стало необходимо для профессионального развития, или так всегда и было, просто сообщество созрело?
Мне трудно точно судить, последний раз я писал мобильное приложение в 2010 году. Мой основной язык тогда был Java, я взял Objective-C и написал приложение для iOS. Был воодушевлен, думал, сейчас стану всем этим заниматься. Но нет: управления памятью не было, никаких библиотек не было, управления зависимостями не было, система сборки была отвратительная. С тех пор в эту сферу я внимательно не смотрел.
А сейчас я вижу несколько трендов, которые естественно привлекают мобильщиков к «серьезному программированию».
Раньше в данной сфере языки были сугубо специализированными. Objective-C был только для разработки под Apple. А сейчас, например, Swift пытаются вытащить на сервер и на нем что-то делать. Java для бэкенда и для Android — были двумя разными языками. А сейчас Kotlin более или менее похож и для того, и для другого. JavaScript появился в мире разработки мобильных приложений, а это какой-никакой серверный язык, и в это же время язык для фронтенда.
Появляется единая инфраструктура, которая начинает людей интересовать. Если раньше (в моем случае это 2010 год) мобильная разработка была совсем в отрыве, то сейчас все по-другому.
Причем сближение идет в обе стороны. Более плотная интеграция платформ дает людям возможность и необходимость за этой интеграцией следить.
— Но если интеграция сама идет к мобильному разработчику, зачем ему разбираться в языках для бэкенда?
У меня есть философский ответ на этот вопрос.
Если хочешь быть Android-разработчиком, то разбираться в бэкенде, наверное, не надо. А если хочешь быть просто разработчиком — конечно, надо.
Разработчик — это тот, кто решает проблемы из реального мира при помощи кода. Соответственно, решения могут возникнуть везде, в том числе в мобильном приложении, на сервере, на фронтенде. Хороший разработчик может решить в принципе любую проблему реального мира, с помощью инструментов разработки.
Понятно, что есть вход в каждый из этих инструментов, наработка практики и прочее, но жесткая фиксация на одной технологии, на мой взгляд, губительна для индивида, который этим занимается.
Как минимум технологии устаревают. Языки, которые были популярны 15 лет назад, сейчас практически не используются. Навык постоянно развиваться и учиться новому, смотреть на соседей, критично важен для любого разработчика. В частности, важно разбираться в бэкенде, потому что бэкенд фундаментален для всей разработки, сегодня все как-то да общается с сервером.
Кроме того, наверняка, мобильщикам бывает некомфортно с другими разработчиками, которые легче находят общий язык. Фронтендер и бэкендер все равно ближе, чем разработчик мобильных приложений к любому из них. Мой доклад поможет в некоторой степени закрыть проблему человеческого общения, помочь интегрироваться.
Насколько глубоко или поверхностно надо разобраться, другой вопрос. Особенно, если мы говорим о мобильном разработчике, которому, как ни крути, надо глубоко копать в свою область.
Я за то, что нужно активно смотреть по сторонам и в прошлое. Важно изучать историю программного обеспечения и программирования. Если не знаешь историю, то будешь заново изобретать очень многие вещи, которые уже придумали и от которых отказались по вполне объективным причинам. Я веду telegram-канал, где делюсь ссылками на классные open source проекты без привязки к языку, стараюсь выделить важные идеи.
— Разработчику мобильных приложений достаточно общих представлений или нет?
Зависит, прежде всего, от окружающей среды. Если у человека есть потребность напрямую влиять на бэкенд в своей компании: ставить им более правильные задачи, участвовать в процессе, возможно, управлять этими людьми, то придется разобраться глубоко.
Но если ты занимаешься только мобильной разработкой, то достаточно иметь поверхностное представление, что там вообще происходит, какие есть языки, проблемы, популярные решения. На таких людей и рассчитан мой доклад на Saint AppsConf. Естественно, за один доклад глубокое представление невозможно дать.
— Что еще нужно разработчику, чтобы быть классным разработчиком?
— То есть ты считаешь, что надо разбираться в предметной области?
Ограниченно, конечно, но надо. Например у нас одновременно есть 3-4 проекта, я, естественно, не разбираюсь в них всех идеально, но понимаю базовые концепции, с которыми работаю. Как они взаимосвязаны между собой, как они влияют на деньги, где расход, где приход, зачем все это надо бизнесу.
И другим разработчикам тоже советую. В нашей компании для них мы составляем документацию, как работает бизнес, какие проблемы мы решаем, почему это нельзя решить руками. Иногда нанять человека, чтобы он один раз, например, перебрал справочник товаров, дешевле. Если же мы автоматизируем процесс, нужно понимать, зачем.
— Давай разберем на примере. Если ты пишешь сервис доставки для пекарни, ты должен разбираться в том, как работает доставка, но не обязан разбираться в видах булочек, которые печет эта пекарня?
И в некоторых видах булочек тоже. Потому что некоторые булочки могут храниться час, а какие-то два дня. Соответственно их доставка будет отличаться.
— В своем докладе ты обещаешь рассмотреть сразу несколько популярных языков, несколько языков из вторых рядов и несколько языков из глубокого underground. Что это будут за языки?
Я не возьму те языки, которые слушатели конференции и так могут знать: Kotlin, Java, JavaScript. Бессмысленно о них рассказывать, если большая часть аудитории и так с ними знакома. Я решил рассказать о языках, которые люди гарантированно не знают, потому что мобильные приложения на них совсем не пишут. Выбирать и так есть из чего.
Я в принципе люблю языки программирования. Без конкретной задачи. Мне нравится язык программирования как идея. Какие-то люди подумали: «Есть вот такой набор проблем, их можно объединить и решить все разом. Сделаем для этого язык». Он будет решать определенный список проблем. А другой язык будет решать другие проблемы, потому что обычно все проблемы разом не решить.
Мне очень нравится смотреть за тем, какие проблемы каждый язык решает и зачем это может быть нужно на практике. Сам язык становится для меня объектом интеллектуального искусства. Большое количество людей работали, думали, проектировали, оптимизировали. Это очень интересно, поэтому я слежу за многими языками программирования.
Те языки, которые я выбрал для доклада, обладают несколькими интересными характеристиками. Во-первых, они спорные. Ни один из них это не язык, который ультимативно хорош во всем в сознании сообщества.
Все знают, что Python медленный, но это все равно самый популярный язык, он используется повсеместно. Я постараюсь объяснить, почему он используется.
А если говорить о Ruby, первое, что скажут люди, — Ruby умер. А на самом деле разработчики Ruby сейчас больше, чем в каком-либо другом языке, заморачиваются с архитектурой и внедряют огромное количество идей из других языков — функциональных, объектно-ориентированных и делают из этого что-то очень интересное.
Если говорить о Go, то у Go очень узкая сфера применимости, но на волне хайпа на нем начали писать вообще все.
Каждый из языков, которые я выбрал, для того чтобы представить во время выступления, обладает каким-то конфликтом.
Как персонаж хорошей истории. И суть конфликта в том, что какие-то вещи работают хорошо, а какие-то нет. Этот конфликт и будет во главе доклада.
— Ты считаешь, что нужно выбирать свой язык под каждую задачу, проект?
Это хорошая идея, но она не работает на практике. Ровно по тому, с чего мы начали. Есть Android-программисты, есть Python-программисты, которые, когда им показываешь код на Ruby, который ну то же самое, только в профиль, говорят: «Ой нет, все непонятно, не хочу разбираться».
Конечно, хотелось бы, чтобы люди были более универсальны и могли выбирать инструмент под задачу, но получается, что люди знают что-то одно и берут этот инструмент всегда.
Сюда же добавляется фактор найма. Например, в нашей компании мы могли бы не выбирать из TypeScript и Python. Но, если мне понадобится нанять Elixir-разработчика, я буду искать его всю жизнь. Я знаю таких разработчиков, но их не то чтобы много, и не то чтобы я смогу их быстро к себе переманить. Поэтому приходится умерить амбиции и подстраиваться под рынок и под заказчиков, которые тоже в соответствии с рынком имеют ограниченный стек.
— Ты обещаешь субъективный взгляд чуть ли не на 10 совсем разных языков. Ты правда с ними со всеми близко знаком, что-то писал на них всех?
С каждым по-разному, но, конечно, я всех их пробовал хоть в какой-то степени.
Например, на Rust я пишу open source, а на pony я написал 15 строчек кода, прочитал туториал, восхитился, и теперь хочу показать участникам конференции. Чтобы они тоже прониклись идеей.
— Очевидно, за один доклад ты не сможешь дать полной картины и понимания каждого языка. Почему людям стоит пойти на твой доклад, а не погуглить?
Причина в том, что когда тебе рассказывает живой человек, это совсем другое. Доклад в какой-то степени — это всегда шоу. Когда люди приходят на шоу они получают не только контент, но и эмоции. Когда гуглишь, получаешь только контент. Если он тебе интересен, ты и так погуглишь. А формат выступления живого человек позволяет популярно и легко получить интересные знания.
— Что будет главным элементов твоего «шоу»?
Языков много, они все классные, но писать не на чем.
Есть много популярных языков для решения своих бизнес-задач: найм, заказчики, библиотеки. Но все они стали популярными не просто так. Как правило, основная причина в том, что они очень простые. В их основе простые концепции, на которых легко начать, но тяжело продолжать.
Есть нишевые языки, и вот там уже появляются очень интересные сложные концепции, на которых можно построить что-то большое и надежное: Rust с его прекрасным компилятором, Elixir с его абсолютно бронебойной виртуальной машиной, Haskell с его системой типов и т.д. Но они не могут стать популярными как раз из-за высокого порога входа.
Большинство разработчиков, которые хотят чему-то научиться, берут популярные языки и на них пишут. И вопроса, зачем может быть нужно что-то еще, не возникает, потому что в тех проектах, с которыми они работают, и не требуется ничего более сложного.
Для разработчика очень важно понимать ограничение инструмента.
Чтобы понять ограничение, нужно упереться в него лбом, повоевать с проблемой, а потом отойти назад и на это большое посмотреть издалека. Только в докладах людей, которые очень много лет с чем-то работали, это и проявляется. А я хорошо знаком с этими людьми, накопил разные случаи и знаю, где во что можно упереться. И смогу обобщить свой опыт и опыт других людей.
— Написать «Hello world» на Haskell уже большой подвиг, но этого недостаточно?
Да, нужно повариться в сообществе функциональщиков. Послушать, какие проблемы они решают, какие доклады они делают — так можно понять срез.
Например, в сообществе хаскелистов очень остро стоит проблема входа. Они до сих пор не могут ее решить и сделать свой язык дружелюбнее к новичкам. Исторически сложилось, что в Haskell используется совсем другой синтаксис и совсем другие правила, просто чтобы хоть что-то написать. Даже опытному разработчику сначала будет совсем непонятно, что происходит в этом коде.
И дело не только в функциональном программировании. Если начинать знакомство с функциональщиной с Elixir, то будет гораздо проще. Elixir по синтаксису очень похож на Ruby. На первых порах будет не видно разницы, можно писать так же как и на Ruby. А только потом станет понятно, что это функциональный язык. Ты этого не замечаешь до какого-то момента, а потом открываешь для себя дополнительные возможности. Понимаешь, что на самом деле он строится на совершенно других принципах. Зная эту базу, становится легко перейти на менее дружелюбный функциональный язык.
— Кроме популярных языков и языков, как ты говоришь, вторых рядов, который хотя бы в какой-то степени на слуху, ты собираешься представить и совсем неизвестные. Например, что это за pony?
Pony is an open-source, object-oriented, actor-model, capabilities-secure, high-performance programming language. То есть строготипизированный, памятибезопасный (memory safe), акторный язык. Он очень молодой и очень интересный.
Его разработчики создают язык, где ты можешь создавать очень большое количество акторов, как в Elixir, но эти акторы гарантировано типобезопасные. Границы применимости этого языка еще совсем непонятны. Но я бы сказал, что он может ударить по Go, а я активно поддерживаю все, что может ударить по Go.
— Если все языки имеют недостатки и ограничения, как быть? Что с этим делать?
Страдать. И продолжать искать техническое совершенство. Это недостижимая мечта любого инженера, но процесс поиска этого совершенства — это отличная цель.
Saint AppsConf через 10 дней. Программный комитет отобрал 35 докладов и 12 митапов, среди которых каждый мобильный разработчик найдет идеи полезные для решения ежедневных задач и для своего профессионального и личного развития. Встретимся 21 и 22 октября в Санкт-Петербурге!
Бонусный вопрос для тех, кто хочет поделиться опытом, но почему-то еще не стал спикером. Ты часто выступаешь, зачем тебе это и что мотивирует?
У меня есть три цели: