Мы долго, тщательно и педантично выбираем телефон, ноутбук, автомобиль, часы. А как иначе — это дорогой, технически сложный продукт для довольно долгого пользования. Эти вещи обеспечивают наш комфорт, экономию времени, даже хорошее настроение. Но всё меняется, когда человек выбирает софт для своего бизнеса: он начинает на удивление положительно реагировать на красивые речи, яркие презентации и типичные приёмчики продажников. Странно было бы думать, что это происходит от безразличия к судьбе своей компании — нет, причина в том, что мы стесняемся признаться в том, что в чём-то ничего не понимаем и просто рассчитываем на профессионалов. Которые на поверку могут оказаться, например… владельцами студии растяжки, подрабатывающими наудачу на партнёрской сети. А между тем, секрет начала успешного внедрения прост и доступен: разговаривайте. Спрашивайте, уточняйте, не стесняйтесь простых вопросов и мыслей — иногда именно за ними скрывается самый нужный и единственно важный ответ. 

Привет, друзья!

В данном туториале мы разработаем простой сервер на NestJS, взаимодействующий с SQLite с помощью Prisma, с административной панелью, автоматически генерируемой с помощью AdminJS, и описанием интерфейса, автоматически генерируемым с помощью Swagger. Все это будет приготовлено под соусом TypeScript.

Репозиторий с кодом проекта.

Если вам это интересно, прошу под кат.

Это первая часть истории (вперемешку с рассказом о моих ошибках и их решениях) о том, как я (где-то два года в свободное время) разрабатывал мобильное приложение под iOS и Android, которое бы мотивировало мою дочь решать примеры по математике, чтобы она достигла автоматизма в основах арифметики (склад числа 10 или табличка умножения). В итоге, получилось приложение, позволяющее ребёнку зарабатывать деньги своим умом.

Использовал я движок Unity и язык C#, а также дополнительный набор софта вроде обязательного Photohsop или Audacity (для создания звуков).

План рассказа (часть первая)

• Предыстория
• О монетизации
• Почему Unity
• О Scriptable Objects
• О плагине Anima2D
• О Lean Localization
• Об iTween
• О Unity Analitics
• О Visual Studio
• Ссылки

Предыстория и колорадские жуки

Мой предыдущий опыт — это несколько лет в 3D и, с недавних пор, разработка нескольких инди-игр на пару с программистом, где я выступал в основном только в роли дизайнера и художника (очень редко пописывая какие-то элементарные скрипты на C#). Хотя, с программированием знаком не понаслышке (колупал Basic в школе и баловался с C/C++ в универе).

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

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

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

upd — немного дополнил текст до ката.

Давайте представим, что вы управляете продуктом, который помогает малому бизнесу осуществлять техническую поддержку своих клиентов. Вы ищете способы увеличить степень вовлечённости (engagement) и возвращаемости (retention) своих клиентов. У вас есть две идеи:

• Дашборд, который позволит владельцам бизнеса мониторить статистику вовлечённости.
• Чат-бот, который поможет владельцам бизнеса автоматизировать коммуникацию с потребителями.

Дашборд – это фича, которая уже несколько раз обсуждалась с пользователями и вы чувствуете, что у неё есть большой потенциал, но также осознаёте риск того, что только один крупный пользователь будет пользоваться дашбордами. Чат-бот – это то, что нравится всем сотрудникам вашей компании и продавливается руководством – это похоже на очень нужную вещь для клиентов, это классный проект. И да, чат-боты сейчас в моде.

Что вы выберете?

4

5. Открывая новые измерения

Предыдущие главы показали вам, что такое XBRL, и что с его помощью можно сделать. Как вы уже знаете, он является расширяемым стандартом. В этой главе мы рассмотрим один из расширяющих стандартную спецификацию модулей – XBRL Dimensions (Измерения).

Глава основывается на спецификации XBRL Dimensions версии 1.0 CR от 19.06.2006. На момент написания книги спецификация находится в статусе Candidate Recommendation, но ожидается, что окончательный вариант не принесет никаких значительных сюрпризов.

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

5.1. Введение

Обычно, факты в отчетах некоторым образом классифицируются, например:

• Продажи в разных периодах;
• Продажи по продуктовым линиям;
• Продажи по регионам;
• Продажи по отделам;
• Количество сотрудников по возрасту;
• Количество сотрудников по полу;
• ...

4. Отчет XBRL

В этой главе мы рассмотрим отчеты XBRL. Как и прежде, основное внимание уделяем тому, что можно сделать, а не как это делается.

Отчет (instance document) содержит факты и ссылается на таксономию для придания фактам смысла:

Факты могут быть простыми (item) или составными (кортеж, tuple). Все простые факты в отчете имеют контекст, напр. финансовый год или начало отчетного периода. Все используемые контексты содержатся в самом отчете.

Схематически состав отчета можно изобразить следующим образом:

В следующих разделах мы более подробно рассмотрим составные части отчета.

2. Что такое XBRL?

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

2.1. Что такое таксономия?

Помните пример отчетной формы, которую я показал в первой главе? Вот она снова:

3. Анатомия таксономии

Эта глава с названием как у песни рок-группы 60-х годов описывает структуру таксономии XBRL. Больше внимания уделяется тому, что можно сделать с помощью таксономий, и меньше − тому, как это делается с технической точки зрения. Мы оставим этот уровень детализации для другой главы.

Начнем вот с чего: то, что мы называем таксономией, на самом деле представляет собой, как правило, целый набор связанных документов, называемых Связанным комплексом таксономий (Discoverable Taxonomy Set), для краткости − DTS.

Отправной точкой DTS является Схема таксономии. Это документ, на который ссылается отчет XBRL. Эта схема таксономии может ссылаться на другие документы, которые в свою очередь могут также ссылаться на другие документы и т.д.

Чтение DTS подразумевает переход по всем ссылкам до тех пор, пока не будут прочитаны все из связанных документов.

Таксономия может ссылаться на два типа документов:

• Таксономия − это тот случай, когда одна таксономия (Extended Taxonomy) расширяет другую таксономию (Base Taxonomy)
• База ссылок (Linkbase) − она используется для предоставления дополнительных сведений об определенных в таксономии концептах. Базы ссылок описывают связи между разными концептами, а также между концептом и дополнительной информацией к нему. Всего существует пять основных видов баз ссылок (каждый из которых будет подробно рассматриваться далее):
  
  • Определения (Definition)
  • Вычисления (Calculation)
  • Презентация (Presentation)
  • Ярлыки (Label)
  • Ресурсы (Reference)

Схематически это можно изобразить следующим образом: