Как сделать полноценную программу

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

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

Сначала, несколько комментариев и предостережений:

• Я буду описывать только один сценарий, а не всё приложение. Надеюсь, будет очевидно как расширить код при необходимости.
• Это намеренно очень простая инструкция без особых ухищрений и продвинутой техники, ориентированная на поточную обработку данных. Но если вы начинающий, я думаю, вам будет полезно иметь последовательность простых шагов, которые вы сможете повторить и получить ожидаемый результат. Я не утверждаю, что это единственный верный способ. Различные сценарии будут требовать различных подходов, и конечно с ростом собственной экспертизы вы можете обнаружить, что эта инструкция слишком простая и ограниченная.
• Чтобы облегчить переход с объектно-ориентированного проектирования, я постараюсь использовать знакомые концепции такие как «шаблоны», «сервисы», «внедрение зависимости» и т.д., а также объяснять как они соотносятся с функциональным подходом.
• Инструкция также намеренно сделана в некоторой степени императивной, т.е. используется явный пошаговый процесс. Я надеюсь, этот подход облегчит переход от ООП к ФП.
• Для простоты (и возможности использовать F# script) я установлю заглушку на всю инфраструктуру и уклонюсь от взаимодействия с UI напрямую.

Обзор

Обзор того, что я планирую описать в этой серии статей:

СДЕЛАЛ ПОЛНОЦЕННУЮ ИГРУ В 12 ЛЕТ

• Преобразование сценария в функцию. В первой статье мы рассмотрим простой сценарий и увидим как он может быть реализован с помощью функционального подхода.
• Объединение небольших функций. В следующей статье, мы обсудим простую метафору об объединении небольших функций в более крупные.
• Проектирование с помощью типов и типы ошибки. В третьей статье мы создадим необходимые для сценария типы и обсудим специальные типы для обработки ошибок.
• Настройка и управление зависимостями. В этой статье мы поговорим о том, как связать все функции.
• Валидация. В этой статье мы обсудим различные пути реализации проверок и преобразование из опасного внешнего мира в теплый пушистый мир типобезопасности.
• Инфраструктура. В этой статье мы обсудим различные компоненты инфраструктуры, такие как журналирование, работа с внешним кодом и т.д.
• Предметный уровень. В этой статье мы обсудим, как предметно-ориентированное проектирование работает в функциональном мире.
• Уровень представления. В этой статье мы обсудим, как вывести в UI результаты и ошибки.
• Работа с изменяющимися требованиями. В этой статье мы обсудим, что делать с изменяющимися требованиями и как они влияют на код.

Приступим

Давайте возьмем очень простой пример, а именно обновление некоторой информации о клиенте через веб-сервис.

Приложение за пару секунд на Java

И так, наши основные требования:

• Пользователь отправляет некоторые данные (идентификатор пользователя, имя и адрес почтового ящика).
• Мы проверяем корректность имени и адреса ящика.
• В базе данных в соответствующей пользовательской записи обновляются имя и адрес почтового ящика.
• Если адрес почтового ящика изменен, отправляем на этот адрес проверочное письмо.
• Выводим пользователю результат операции.

Это обычный сценарий обработки данных. Здесь присутствует определенный запрос, который запускает сценарий, после чего данные из запроса «протекают» через систему, подвергаясь обработке на каждом шаге. Я использую этот сценарий в качестве примера, потому что он распространен в корпоративном ПО.

Вот диаграмма составных частей процесса:

Но это описание только успешного варианта событий. Реальность никогда не бывает столь простой! Что произойдёт, если идентификатор пользователя не найдется в базе данных, или почтовый адрес будет некорректный, или в базе данных есть ошибка?

Давайте изменим диаграмму и отметим всё, что может пойти не так.

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

Функциональное мышление

Теперь, когда мы разобрались с этапами нашего сценария, как его реализовать с помощью функционального подхода?

Сначала обратимся к различиям между исходным сценарием и функциональным мышлением.

В сценарии мы обычно подразумеваем модель запрос-ответ. Отправляется запрос, обратно приходит ответ. Если что-то пошло не так, то поток действий завершается и ответ приходит «досрочно» (прим. переводчика: Речь исключительно о процессе, не о затраченном времени.).

Что я имею ввиду, можно увидеть на диаграмме упрощенной версии сценария.

Но в функциональной модели, функция — это черный ящик с входом и выходом, как здесь:

Как мы можем приспособить наш сценарий к такой модели?

Однонаправленный поток

Во-первых, вы должны осознать, что функциональный поток данных распространяется только вперед. Вы не можете вернуться «досрочно».

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

Как только мы это сделаем, у нас появится возможность превратить весь поток в единственную функцию — чёрный ящик:

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

Управление ошибками

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

Что мы можем с этим сделать?

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

Вот пример возможного определения типа для вывода результата:

type UseCaseResult = | Success | ValidationError | UpdateError | SmtpError

И вот переделанная диаграмма, на которой изображён единственный выход с четырьмя различными вариантами, включёнными в него:

Упрощение управления ошибками

Это решает проблему, но наличие ошибки для каждого шага — это хрупкая и мало пригодная для повторного использования конструкция. Можем ли мы сделать лучше?

Да! Нам в действительности нужны только два метода. Один для успешного случая и другой для всех ошибочных:

type UseCaseResult = | Success | Failure

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

Ещё один момент — в результате, который возвращает функция, совсем нет данных, только статус успех/неудача. Нам потребуется кое-что поправить, чтобы результат функции содержал фактический успешный или сбойный объект. Мы объявим успешный и сбойный типы как универсальные (с помощью параметров типов).

Наконец, наша итоговая, универсальная версия:

type Result = | Success of ‘TSuccess | Failure of ‘TFailure

На самом деле, в библиотеке F# уже есть подобный тип. Он называется Choice. Для ясности я всё же продолжу использовать в этой и последующих статьях созданный ранее тип Result. Мы вернемся к этому вопросу, когда подойдём к более серьезным задачам.

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

Как это сделать — тема следующей статьи.

Итог и методические указания

Итак, у нас есть следующие положения к инструкции:

• Каждый сценарий равносилен элементарной функции.
• Возвращаемый тип сценарной функции — объединение с двумя вариантами: Success и Failure.
• Сценарная функция строится из ряда небольших функций, которые представляют отдельные шаги в потоке данных.
• Ошибки всех этапов объединяются в единый путь ошибок.

Источник: savepearlharbor.com

Развертывание WPF-приложений

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

Запуск в браузере

Если создано WPF-приложение, состоящее из веб-страниц, его можно запускать прямо в браузере. Ничего устанавливать не понадобится. Однако приложение должно быть готово к тому, чтобы функционировать с очень небольшим набором привилегий. (Например, нельзя получать доступ к произвольным файлам, работать с системным реестром Windows, отображать всплывающие окна и т.д.)

Развертывание через браузер

WPF-приложения тесно интегрированы со средством установки ClickOnce («однократный щелчок»), которое позволяет пользователю запустить программу установки со страницы браузера. Лучше всего то, что приложения, установленные с помощью ClickOnce, могут быть сконфигурированы так, чтобы автоматически проверять наличие обновлений. Отрицательной стороной является то, что возможности по настройке установки ограничены, и нет никакого способа выполнить задачи конфигурирования системы (вроде модификации системного реестра Windows, создания базы данных и т.п.).

Развертывание с помощью традиционной программы установки

Этот подход все еще существует в мире WPF. В случае выбора такого варианта придется решить, нужно ли создавать полноценный установочный пакет Microsoft Installer (MSI) или же обратиться к более простой (но и ограниченной) установке ClickOnce. Готовый установочный пакет можно распространять на CD-диске, во вложении сообщения электронной почты, через общедоступный сетевой ресурс и т.д.

Хотя ClickOnce была разработана как легковесная технология развертывания, которая не заменит полноценные программы установки, каждая новая версия добавляет к ней ряд новых возможностей. В .NET 4 установка ClickOnce может создавать значки рабочего стола и регистрировать типы файлов. Вдобавок .NET теперь устанавливает дополнение Firefox под названием Microsoft .NET Framework Assistant, которое позволяет пользователям запускать установки ClickOnce из браузеров Firefox и Internet Explorer (естественно, если это дополнение включено).

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

Существует много вариантов создания программ установки. Можно воспользоваться коммерчески распространяемым продуктом типа InstallShield, либо создать установочный файл MSI с помощью шаблона Setup Project (Проект установки) в Visual Studio.

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

Другой вариант — применение системы развертывания ClickOnce, тесно интегрированной с WPF. Система ClickOnce обладает рядом ограничений (большинство из них связано с положенным в основу ClickOnce проектным решением), но обеспечивает два существенных преимущества:

• поддержка установки со страницы браузера (которая может размещаться как во внутренней сети, так и в Интернете);
• поддержка обновлений автоматической загрузки и установки обновлений.

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

Модель ClickOnce и частичное доверие

Обычные приложения WPF требуют полного доверия (full trust), потому что им нужны права доступа к неуправляемому коду для создания окна WPF. Это означает, что установка автономного приложения WPF посредством ClickOnce вызовет такое же препятствие со стороны системы безопасности, как и установка любого другого типа приложения из Интернета — в частности, браузер выдаст предупреждение безопасности. Если пользователь соглашается, устанавливаемое приложение получает возможность делать все, что разрешено делать в системе текущему пользователю.

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

Может показаться, что подход Windows Forms лучше, но WPF предусматривает возможность комбинировать частично доверенное программирование и технологию установки ClickOnce. Фокус заключается в использовании модели ХВАР. В такой ситуации приложение запускается в браузере, поэтому ему не нужно создавать каких-либо окон, и не нужны права доступа к неуправляемому коду. Более того, поскольку приложение доступно через URL (и затем кэшируется локально), пользователь всегда запускает последнюю, самую свежую версию.

При проектировании ClickOnce предполагалось иметь дело с простыми, прямолинейными приложениями. Развертывание ClickOnce, в частности, подходит для производственных приложений и внутреннего программного обеспечения компании. Обычно такие приложения выполняют свою работу, опираясь на данные и службы, предоставляемые серверами приложений среднего уровня. Как следствие, им не требуется привилегированный доступ к локальному компьютеру.

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

Модель ClickOnce также может иметь смысл для прикладных приложений, которые распространяются через Интернет, в частности, если эти приложения требуют частого обновления и не предъявляют строгих требований к установке. Однако ограничения ClickOnce (такие как недостаток гибкости в настройке мастера установки) делают эту модель непрактичной для сложных прикладных приложений, которые выдвигают детализированные требования к установке или нуждаются во взаимодействии с пользователем при выполнении ряда тонких конфигурационных шагов. В таких случаях понадобится создавать специальное приложение установки.

Чтобы установить приложение WPF с помощью ClickOnce, на компьютере уже должна быть установлена исполняющая среда .NET Framework. Это требование проверяется при первом запуске установки ClickOnce. Если исполняющая среда .NET Framework не установлена, отображается окно сообщения, которое поясняет суть проблемы и предлагает установить .NET с веб-сайта Microsoft.

Источник: professorweb.ru

Собрать мобильное приложение из таблицы за 5 минут — обзор Glide

Glide произносится как «глайд». Это платформа для создания мобильных приложений без написания кода и это один из флагманов современного No-code. На Glide можно собрать приложение с базовыми функциями за 2 минуты — и оно будет выглядеть красиво, быстро работать без интернета и выполнять возложенные на него функции.

И Glide — крутейший инструмент для создания приложения под себя, для тренировки в No-code разработке, для создания приложений для небольших бизнесов или внутреннего использования компаниями — и идеален для проверки гипотез. Glide развивается семимильными шагами. На момент написания этого текста — июль 2022 года — в Glide даже с начала года появилось много нововведений. В этом обзоре — про устройство и работу Glide, его возможности, тарифы, тонкости и актуальные функции.

Пользователю открывается рабочий кабинет. Слева — рубрикатор-меню, где открывается раздел с проектами (Projects), с шаблонами (темплейтами, Templates), с членами команды разработки (Members), с данными по использованию (Usage), с данными по оплате (Billing).

В основной рубрике «Проекты» откроется рабочая область, где собираются все проекты, которые есть в работе, предложенные темплейты, идеи для будущих приложений (это новая функция).

По клику на кнопку с плюсом «Новый проект» (New project) откроется окно, где можно дать название проекту, выбрать тип — мобильное приложение Glide App или веб-сайт Glide Page. После этого надо выбрать базу данных будущего приложения. Всё, можно начинать создавать.

Как создаются приложения в Glide

На первой странице сайта Glide говорят, что создать приложение на платформе можно в три шага:

1 шаг. Подсоединить базу данных.

База данных в Glide — это таблицы. Данные для неё собираются и вносятся заранее — без них платформа подставит данные по умолчанию, и приложение сформируется из них. Это наглядно, но логично заняться собственной базой данной сначала и работать уже со своими данными. Так что первый шаг в первом шаге — сбор данных. Второй шаг — приведение данных к единообразию.

Третий шаг — установка связей внутри базы данных.

2 шаг. Навести порядок и настроить под себя (кастомизировать) отображение данных

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

3 шаг. Опубликовать приложение

На этом этапе надо настроить способы доступа в приложение — по регистрации или нет — и по клику на одну кнопку сделать приложение публичным.

Внутри Glide строится работа над взаимосвязями в таблицах — именно тут создаётся реляционная база данных (узнать, что это такое, можно тут), которая обеспечивают работу приложения, сделанного на No-code. Тут же можно редактировать содержимое ячеек и вносить новые данные. Новые данные не отобразятся в первоисточнике — но, наоборот, если данные поменять в первоисточнике, они поменяются и в Glide.

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

Внутри таблиц базы данных Glide есть таблицы под сущности. Они отображаются на панели слева — к примеру, здесь отобразятся разные вкладки одной гугл-таблицы. По клику на «+» можно добавить новую таблицу-вкладку. Далее привычное построение базы данных — типы данных прописываются в столбцах, атрибуты прописываются в строках. По клику на заголовок столбца можно менять тип данных, редактировать название и отображение, устанавливать связи.

Интерфейс Glide — где и что расположено

Создание рабочего приложения в Glide происходит во вкладке с иконкой телефона на верхней панели. Здесь открывается рабочая область, которая состоит из боковых левой и правой панелей и центральной части, где отображён экран смартфона с приложением.

• Слева панель с вкладками или таб-бар. Эти вкладки называются табы (Tabs). Здесь настраиваются рубрики меню, которое может отображаться на экране приложения снизу либо слева сверху, в бургер-меню.

• Ниже слева находится раздел экраны (Screens). Здесь доступна настройка самого экрана и добавление компонентов: заголовки, сепараторы и прочее, текстовые блоки, кнопки, картинки и прочее; функциональные элементы как карта, таблицы, внешние ссылки и прочее. Компонентов в Glide более 40 штук. Добавлять их можно кликом или перетаскиванием.

• Справа панель с настройками отображения информации из базы данных. Тут есть панель со стилями. В Glide 8 стилей — 8 вариантов отображения данных. Это:

1. Список
2. Плитка
3. Календарь
4. Карта
5. Чек-лист
6. Карточки
7. Свайп
8. Детали

• Выбор стиля отображения — это ещё и выбор функциональности будущего приложения. В каждый стиль «зашиты» функции отображения и взаимодействия с приложением. И самый ноукодерский стиль — «Детали». Здесь доступна тонкая настройка экрана, при которой сам экран можно сформировать из компонентов. В других стилях кастомизация минимальная.

• Справа настраивается источник данных в разделе Source; присваивается название и иконка табов.

• Тут же справа можно настроить отображение семи предзаданных стилей через кнопку редактирования (Edit). Например, выбрать формат отображения изображений, отображение по фильтру или количество элементов на экране.

• Верхняя панель — это три кнопки, ведущие к базам данных, к настройкам режима отображения экрана, к настройкам самого приложения.

• Снизу справа на рабочей области есть две кнопки. Первая со значком play означает просмотр приложения в режиме пользователя. Вторая со значком курсора — это работа в режиме разработчика. В разработке вам пригодятся оба режима.

Сколько стоит Glide

У Glide четыре тарифа: бесплатный (с ограничениями для публикаций и использования, но идеален для начинающих), Starter (для нескольких индивидуальных проектов), Pro (для большого количества приложений и пользователей), Business (увеличенное количество приложений и пользователей). Расценки соответственно: $0, $25, $99, $249.

Для тренировок в разработке и даже для первого теста вполне подойдёт бесплатный тариф. После последних обновлений неограниченными стало использование источников данных, иконок внутри приложения. На бесплатном тарифе можно собрать любое количество приложений, но опубликовать дадут только три. Наиболее значимые ограничения — нет своего домена и ограничение в количестве строк и загружаемых данных.

Сильные стороны и ограничения Glide

Сильные стороны Glide делают его идеальным инструментом для тех, кто только начинает в No-code.

• Легко учиться. Поверхностно изучить Glide, чтобы понять, куда нажимать и что произойдёт, можно за вечер. Это низкий порог входа очень вдохновляет — и позволяет оттолкнуться и двинуться дальше, к глубокому изучению платформы. Плюс есть много обучающего материала в открытом доступе.
• Быстрый путь от идеи к запуску приложения. Когда вы разберётесь в работе Glide, то с готовой базой данных приложение будет собираться за несколько часов.
• Доступность работы на платформе на бесплатном тарифе. Ограничения есть в объёмах данных, но доступность Glide позволяет свободно чувствовать себя в обучении.
• Подходит для тестирования идей и проверки гипотез — минимальные затраты времени и денег, а на выходе полноценный продукт, который не стыдно показать людям.
• Идеален для маленького бизнеса. Когда клиентская база несколько сотен или даже тысяч человек, когда нет лишних денег на разработку, когда нет возможности изучать программирование — Glide просто находка.
• Идеален для создания внутреннего сервиса.
• Развивается семимильным шагами. Например, ещё в начале года в Glide нельзя было подключать Airtable и Excel. В апреле эта опция появилась. Так что ещё через полгода у платформы вполне могут появиться новые фичи, которые раньше были недоступны.

• Ограничено количество строк в базах данных и объёмах информации. Крупное приложение тут не построить.
• Нельзя создавать нативное приложение. Это и плюс, но и в некоторых случаях минус. За нативками — к Adalo.
• Весьма скудная кастомизация по цвету, шрифтам, внешнему виду приложения.
• На Glide — как и на любом ноукодерском инструменте — нельзя создать сложные продукты с большим количеством функций и данных.
• Зависимость от облачной платформы.

Что можно сделать на Glide и примеры проектов

Чтобы прикинуть, что можно собрать на Glide, можно изучить библиотеку шаблонов-темплейтов. Здесь 14 рубрик — образование, финансы, здоровье, персонал, планирование, личное, удалённая работа и другие. В каждой по паре десятков темплейтов приложений. Вот что можно там встретить:

• Приложения для личного использования: личный финансовый трекер, таск-трекер, планировщики, план питания, дневник, приложение с тренировками и подобное.
• Приложения для стартапов и малого бизнеса: приложение для бронирования столика в ресторане, услуги у мастера, заказа еды; небольшой онлайн-магазин; каталоги товаров и другое.
• Приложения для внутреннего использования: чаты, директории с персоналом, мини-приложение под событие (например, под конференцию).

Источник: codebreakers.tech