Hiro Fukami's Blog - 深海寛信のブログ

長沼公園 - お気に入りの場所

Thu, 26 Oct 2023 01:00:00 +0000

今まで開発したサービスや出来事について書いてきたけど、あまり自分自身のことについて公開していなかった気がしている。今後は自分ごとを中心にしていこうと思うので、まずは軽い感じでお気に入りの場所を紹介してみる。

自分なりの秘境というか、自分にとっての宝物のような場所は誰にでもひとつはあるかもしれない。

私のお気に入りの場所はいくつもないけれども、長沼公園は、そのような特別な場所のひとつ。

この公園は、京王線沿いに位置しており、終点の高尾山とは一味違う魅力を持っています。

何がこの場所を特別にするかと言うと、まずその静けさ。

長沼公園はマイナーな場所なので、通常、他の訪れる人とすれ違うことはほとんどない。全く他の人に会わないことすらある。この静かな環境が、自宅とは違う、都会とは違う、特別な癒やしを与えてくれる。

京王線の長沼駅から徒歩5分。自宅から気軽に訪れることができるのも良い。高尾山ほどのしっかりした登山ではなく、軽い運動にもなる。

長沼公園は小さな山のような形状で、森の中に入り込むような感覚になる。

鳥のさえずり、風にそよぐ木々の音、自然が包み込んでくれる。豊かな自然が心と体を浄化してくれる。まさに自然に浸ることができる。

入口から進むとすぐに木々が空まで覆い、自然に浸った感覚になります。気温も少し下がったような印象。貴重な自然との意思疎通。

場所によっては桜が並ぶように植えてあり、開花の時期に訪れるもの良い。

登りきった後の眺めは、なにか特別な感覚になれる。

考え事をしたり、煮詰まった時に自分をリセットするために訪れる。

この場所では、自然の大きさを実感でき、都会や家の中にいると感じることのできない、何か見失ってしまったものを取り戻せるような感覚になる。

なにか癒やしがほしいなと思っている方には、ひとりで訪れることをおすすめします。

長沼公園東京都公園協会

Flutter in_app_purchase で定期購入を実現する方法 2023年版

Mon, 16 Oct 2023 00:00:00 +0000

Flutter にて in_app_purchase を使って定期課金を実現するための方法をまとめました。

構成は単純なデバイス + DB 以外にも購入データを証明するバックエンドも加わり割りと複雑で、 in_app_purchase が行っている処理への理解も必要の上、Apple, Google 上で行うべき作業もある。

実際実現してみて事前にある程度情報を入れておかないと、実現するのは難しいと思ったのでまとめておく。

定期課金を導入したアプリ

フットサルSNSアプリ「フットサルメット」

広告なしで使える無料アプリだが機能制限があり、より便利な機能を利用するための定期課金を提供している。

参考にしたサイト

理解をするのに助けてもらったサイト。2023年9月においては古い情報もあり、完全に網羅しているサイトはかなった。これを読めば大丈夫。というものがなく、複数のサイトからの情報とトライアンドエラーが必要だったので、今回まとめようと思ったモチベーションになっている。

Flutter + FirebaseでiOSとAndroidの定期購入(サブスク)を実装する

必要な処理ごとにフローとサンプルコードを示しているので、どんな処理が必要なのか理解できる。示しているソースコードは実際の処理としては足りないので、鵜呑みにしない方が良い。

【Flutter】もう怖くない！アプリ内課金・定期購入機能を実装する方法を丁寧に説明してみた。

大まかに必要な要素をカバーしている。全体の流れを網羅するには良い。示しているソースコードは現状にはない関数があったり、かなり省略されているので実際のコードとしてはあまり参考にならない。

【Flutter + Firebase】アプリ内課金(IAP)のステップバイステップ実装ガイド【レシート検証】

購入した際に発行されるレシートの検証処理についてまとめている。検証するための構成や検証処理への理解を深められる。示しているソースコードはどんな処理をすればよいのか理解はできるが、サーバ側の検証部分が一部省略されているので、鵜呑みにしない方が良い。

環境

Flutter 3.13.4
Dart 3.1.2
in_app_purchase 3.1.8

構成

Flutter : アプリUIの提供。バックエンドとの通信
in_app_purchase : アプリ内課金を実現する。iOS, Android アイテム情報の取得、購入処理を行う
Firebase Firestore Database : DB として利用するバックエンド
Firebase Functions : Node.js で動かすバックエンド。今回は購入後のレシート情報の検証と firestore への書き込みを行う

準備

Flutter 側のセットアップ in_app_purchase 導入
iOS, Android へのアイテム登録

Flutter 側セットアップ

in_app_purchase の README の Getting started にも示されている通り、 codelab に沿うのが一番良いと思う。ただし、すべてのスッテップを行うのではなく「6. Set up Firebase」まででOK。その後の実装はバックエンドに dart で書いたサーバを立てる想定なので、今回の構成とマッチしなくなるので、参考にしない。

アイテム登録

codelab の「Set up the App Store」、「Set up the Play Store」の通りにする。

今回は、有料サービスの内容は1つだけど、月額、年額と2つの購入方法を用意する。

ここでは product id は以下のようにする。

月額 : com.example.monthly.standard
年額 : com.example.yearly.standard

flutter in_app_purchase 上の product id は、以下に対応する。

iOS : サブスクリプションの製品ID
Android : 定期課金のアイテムID

iOS

App Store Connect の該当アプリ上の「サブスクリプション」で入力する。

「サブスクリプション」が実際のユーザーに提示する課金アイテム。それらをまとめるための「サブスクリプショングループ」がある。今回のように、同じサービス内容で複数の支払方法に対応したい場合は、1つのサブスクリプショングループでまとめることができる。

サブスクリプショングループを1つ作り、その配下にサブスクリプションを追加した。

graph LR
    A[サブスクリプショングループ : default]
    A --- B[サブスクリプション 月額 : com.example.monthly.standard]
    A --- C[サブスクリプション 年額 : com.example.yearly.standard]

サブスクリプションには製品IDを付与して、これが flutter 上で持っておく product id になる。

注意点

App Store Connect で各サブスクリプションを入力する際に、最下部にある「審査に関する情報」でスクリーンショットと審査メモを必ず登録すること。この情報がなくても保存して審査へ提出ができるが、審査でリジェクトされる。

スクリーンショットは、そのサブスクリプションを購入する画面にした。審査メモは、その画面に行き着くフローを示した。結果的に承認されたので、この内容で良いと思う。

実際には以下のようにした。

Android

Google Play Console の該当アプリ上の「収益化」-「定期購入」にて入力する。

「定期購入」がアイテムIDを持ち、支払いサイクルなどを設定できる「特典」を配下に紐付ける。 queryProductDetails した時の product id は特典ではなく定期購入のアイテムIDになるので、定期購入を複数作成するようにする。特典を指定する方法は分からなかった。

graph LR
    A[定期購入 月額 : com.example.monthly.standard]
    B[定期購入 年額 : com.example.yearly.standard]
    A --- A1[特典 月額]
    B --- B1[特典 年額]

注意点

注意点1 : 定期課金と特典は削除できないので不要なものが残ってしまう。

また、queryProductDetails する時に不要なものを配列に入れなかったら notFoundIDs が返ってくる。 不要なアイテムIDも含めたすべての定期課金のアイテムIDの配列にする必要がある。

注意点2 : 定期購入をテストで使いたい場合は事前にビルドしたアプリをアップロードする必要がある。

この時点では課金の実装はできていないが、紐付ける App Bundle が必要なので、現状のアプリをとりあえずビルドしてアップロードすれば良い。 App Bundle エクスプローラに表示されサブスクリプションの画面にて紐付けられればOK。くれぐれも公開しないこと。

実装

基本的な処理の流れ

ユースケースごとに示す。

新規購入

デバイス(flutter)にて購入処理、Apple, Google へ問い合わせて購入処理をして localVerificationData を受け取る
firebase functions にて localVerificationData を使って Apple, Google へ検証する。最近のレシートを受け取る
firebase functions にて最近のレシート情報を firestore に保存する
flutter にて購入完了処理(購入ボタンの widget を閉じるなど)

定期課金更新チェック (firebase functions のみで実行)

firebase functions を cron 的に毎日スケジュールで実行
firebase firestore に存在するレシート情報から有効期限が切れているものを検索
該当レシートの verificationData を使って Apple, Google へ検証する。最新のレシートを受け取る
最新のレシートの有効期限が今よりも後ならば、最近のレシート情報を firestore に保存する

ユーザーが有料ユーザーかどうか判別 (flutter アプリにて)

firebase auth ユーザー情報より、該当ユーザーの firebase firestore 上のレシート情報のドキュメントを検索
該当ドキュメントの有効期限が現在時刻よりも後ならば有料ユーザー true, 前なら false

リストア (flutter アプリにて)

flutter 上は有料ユーザーではないと判別(firestore 上に有効期限内のレシート情報がない)
ユーザーがリストアボタンを押す
firebase functions にて localVerificationData を使って Apple, Google へ検証する。最近のレシートを受け取る
firebase functions にて最近のレシート情報を firestore に保存する

検証 verify とは

お金に絡むことなので、誤ったデータを使って購入させたり不正を防止するために Apple, Google が設けている購入したレシート情報の検証を行う処理。 1回毎の支払い情報のことをレシートと呼ぶ。

Apple, Google ともにレシート情報を返す Web Endpoint を設けている。

Apple : verifyReceipt
Google : purchases.subscriptions.get

クライアント(今回はflutter)にて Apple(App Store), Google(Google Play) を使って購入処理をすると verificationData が発行される。そのデータを Apple, Google の検証用 endpoint へ問い合わせて検証結果がOKなら、最新のレシート情報(last receipt) が返ってくる。

このデータが有料ユーザーの判別に使えるので firestore に保存している。

Apple の verifyReceipt endpoint は非推奨(Deprecated)になったので推奨方法での切り替えが必要。 App Store Server API を使うようにとのこと

仕様

有料ユーザーかどうかのチェックは1日1回とする
レシート情報の有効期限内なら有料ユーザーと判別する
flutter(クライアント側)では定期的に狙ったタイミングではチェックできないので、firebase functions にて行う
最新のレシート情報は firebase firestore に保存し、有料ユーザーの判別に使う

firebase functions

主に参考にさせてもらったサイト特に返り値の部分とか踏襲している。

Flutter + FirebaseでiOSとAndroidの定期購入(サブスク)を実装する

3種類の関数を設けた。

verify : flutter からの verify チェックのリクエストの窓口用
verifyReceipt : Apple, Google にアクセスし、レシートデータを検証して、latest_receipt(最新のレシート)情報を返し、firestore に保存する
verifySubscription : 定期購入の更新をチェックし、latest_receipt(最新レシート)を firestore に保存する

検証にアクセスする Apple, Google のURLやレスポンが異なっているので、 iOS, Android 用に2種類ずつ必要。計6つの関数を設けている。

verify
1. verifyIos
2. verifyAndroid
verifyReceipt
1. verifyReceiptIos
2. verifyReceiptAndroid
verifySubscription
1. verifySubscriptionIos
2. verifySubscriptionAndroid

関数ごとに分けて解説する。 functions にデプロイするファイル(今回は purchase.js)の先頭には以下のようにしている。

const functions = require('firebase-functions');
const admin = require('firebase-admin');
const axios = require('axios');
const { google } = require('googleapis');
const { Firestore } = require("firebase-admin/firestore");

各関数の返り値は以下のようにファイル内で定義している。flutter 側でも同じ用に解釈できるようにしている。

const SUCCESS = 0; // 成功
const EXPIRED = 1; // 期限切れ
const DOCUMENT_NOT_FOUND = 2; // Firestoreにドキュメントなし
const NO_AUTH = 3; // 認証情報なし
const INVALID_RECEIPT = 4; // レシート情報が不正です
const ALREADY_EXIST = 5; // 同じトランザクションが存在している
const UNEXPECTED_ERROR = 99; // 不明なエラー

verify

verifyIos を例に解説する。

verifyAndroid の gist はこちら

http.onCall で HTTP で受け付ける。context.auth で認証ユーザーであることが必須。

flutter 側から data["data"] に入っている verificationData を受け取る。

後述する verifyReceipt に verificationData を渡して最新のレシート latestReceipt を受け取る。

latestReceipt の transaction_id は支払処理ごとに割り当てられるユニークなIDなので、すでに firestore に保存されていないか確認する。 firebase auth のユーザーが異なっていている場合もあるので、collectionGroup で検索している。

なければ firestore に保存する。検証に利用するだけならカラムはもっと減らせるが、問い合わせなどがあった場合に運営側として把握しておきたい情報も含めている。実際保存しているカラムの意味は以下。

iOSの場合

receipt_data : verificationData をそのまま格納、verificationData は課金が続く限り認証情報として利用される
product_id : 購入した製品ID,アイテムID
transaction_id : 購入処理ごとに割り当てられたユニークなID
purchase_date_ms : 購入日時の unix time のミリセカンド
purchase_date : 購入日時
expires_date_ms : この購入の期限日時の unix time のミリセカンド
expires_date : この購入の期限日時

verifyAndroid のAndroidの場合は以下。 transaction_id の代わりに orderId になる。

receipt_data : verificationData をそのまま格納、verificationData は課金が続く限り認証情報として利用される
product_id : 購入した製品ID,アイテムID
orderId : 購入処理ごとに割り当てられたユニークなID
purchase_date_ms : 購入日時の unix time のミリセカンド
purchase_date : 購入日時
expires_date_ms : この購入の期限日時の unix time のミリセカンド
expires_date : この購入の期限日時

最後に期限日時が現在時刻と比較して期限が切れていないかどうかチェック。その結果を返す。

verifySubscription

verifySubscriptionIos を例に解説する。

verifySubscriptionAndroid の gist はこちら

pubsub.schedule にて定期実行させる。1日1回夜中に実行。

レシート情報から有効期限が切れているものを見つける。実行間隔は24時間なので、その間隔で検索する。

レシート情報の receipt_data を使って、verifyReceiptIos へ検証してもらう。

latestReceipt があり、有効期限が現在以降ならレシート情報を firestore に保存する。

Android 版の verifySubscriptionAndroid はfirestore の保存カラムが異なるだけで、処理内容は同じ。

verifyReceipt

verifyReceiptAndroid の gist はこちら

verificationData を使って、Apple の verifyReceipt にある Latest_receipt_info にアクスする。

レスポンスを見て、最終購入のレシート情報 latest_receipt を返す。

latest_receipt のレスポンスの各プロパティーの意味はドキュメントを参照

Apple : App Store Receipts responseBody.Latest_receipt_info
Google : Google Play Developer API SubscriptionPurchase

Apple, Google にアクセスするためには認証情報が必要。

Apple : RECEIPT_VERIFICATION_PASSWORD_FOR_IOS
Google
- SERVICE_CLIENT_EMAIL_FOR_ANDROID
- SERVICE_PRIVATE_KEY_FOR_ANDROID

RECEIPT_VERIFICATION_PASSWORD_FOR_IOS は、 App Store Connect で確認できる。

App Store Connect > ユーザーとアクセス > 共有シークレット

ない場合は生成する。

生成した共有シークレットの値をコード内の RECEIPT_VERIFICATION_PASSWORD_FOR_IOS の値に定義する。

SERVICE_CLIENT_EMAIL_FOR_ANDROID, SERVICE_PRIVATE_KEY_FOR_ANDROID は Google Cloud でアプリのプロジェクトにリンクしたサービスアカウントを作成する必要がある。

やり方は、 Google Play Developer API にありますが、執筆時点で Google Play Console の APIアクセスページが廃止されている。

Google Cloud のコンソール画面から行う必要がありそう。

Google Cloud > IAM と管理 > サービスアカウント でたどれる。

設定方法は、以下のサイトが参考になる。

Google Play Store向けサービスアカウントの作り方

このドキュメントの「秘密鍵の作成とJSONダウンロード」で、JSON を保存しますが、このJSONファイルに記載されている、 client_email, private_key をそれぞれ、コード内の SERVICE_CLIENT_EMAIL_FOR_ANDROID, SERVICE_PRIVATE_KEY_FOR_ANDROID の値に定義する。

in_app_purchase

flutter 公式の in app purchase するためのパッケージ。

実装の構成としては、以下の3つ。

利用可能かどうか確認する : isAvailable()
販売する product の提示 : queryProductDetails を使って情報を widget に表示
購入状況を把握する : purchaseStream 公式のように listener として状態を監視する

購入処理の流れとしては、

有料サービス説明と購入ボタンを含む widget を表示 queryProductDetails の情報を提示
購入ボタンをユーザーが押す
listener が動き出す
ユーザーが in app purchase 画面で購入処理をする
listener が status == purchased を検出
有料サービスの widget を閉じて、有料サービスを提供する

注意点

in app purchase で購入せずキャンセルして画面を閉じた場合は、処理が完了せずに purchaseDetails.pendingCompletePurchase == ture となる。この状態で再び購入ボタンを押すと、すでに listener 上であるのでエラーになる。そのため、この状態になったら listener 上で completePurchase して残らないようにしている。

Sample Code

購入するための widget。購入ボタンを押した後のレシートの検証も含めた1つのファイルにまとめている。

StatefulWidget にしている。

initState() で _getProducts() してアイテム情報を取得し、listener の設定をする。

購入アイテムの表示

_getProducts() では queryProductDetails して、返り値を ProductDetails の配列 _products に入れる。

_products の情報より widget を表示させる。 ProductDetails は、以下の情報を使って購入ボタンを表示している。

id : ex. com.example.monthly.standard
price : 通貨表示を含めた国ごとの価格
description : アイテム登録時に入力した説明文

購入処理

購入ボタンを押して buyNonConsumable を走らせると、 listener _listenToPurchaseUpdated が動き出す。

listener の status の状況によって処理を分ける。status が purchased,restored になったら _verifyPurchase で検証を走らせる。

_verifyPurchase では FirebaseFunctions.instance.httpsCallable('verifyIos') のように firebase functions へ http アクセスをして返り値を得て、そのまま値を返す。

返ってきた値によって _listenToPurchaseUpdated が処理を分ける。

BillingConst.SUCCESS だった場合 deliverProduct して、購入画面の widget を閉じて購入処理が完了する。

リストア restore

リストは iOS の審査には必須。ないとリジェクトされる。

リストが発生するのは、以下のような状態。

ユーザーは定期課金契約中、支払いは継続している、解約していない
ユーザー情報からは支払い履歴が確認できない

処理としては、verify で確認して、OKなら firestore に書き込む。

コードとしては、リストアするボタンを以下のようにすれば動作する。

CupertinoButton.filled(
  child: Text('リストアする'),
  onPressed: () {
    try {
      await inAppPurchase.restorePurchases();
    } catch(error) {
      print('inAppPurchase.restorePurchase: $error');
    }
  },
);

listener などはそのまま利用する必要があるため、上記の Sample Code に bool isRestore のような判別を加えて、

isRestore
 ? CupertinoButton.filled(
    child: Text('リストアする'),
    onPressed: () {
      try {
        await inAppPurchase.restorePurchases();
      } catch(error) {
        print('inAppPurchase.restorePurchase: $error');
      }
    },
  )
  : CupertinoButton.filled(
      child: Text(_buttonView), 
      //
  ),
  //

のようにしている。

テスト

デバイス

iOS

購入テストを行うには実機が必要。iOS Simulator では購入できない。

購入テストにはテストアカウントを使う。テストアカウントの作成は、App Store Connect のユーザーとアクセスのSandboxテスターで行う。

テストアカウントを実機に設定する方法は、 codelab の「Set up the App Store」にあるように、 Setting > App Store > Sandbox-account にて設定する。これで、TestFlight でアプリを配布、インストールして、テストアカウントにて購入処理ができる。

Android

Android Emulator で購入処理ができる。ただし Play Store に対応しているデバイスであること。

購入処理を進めた際にログインが求められた時は、自身の Google アカウントを使えば良い。

定期課金処理

定期課金処理は Apple, Google 共に数分間隔で実行される。(実際に1ヶ月や1年待つ訳に行かないので)

iOS : 特に通知なし、一定回数になると課金処理が停止されるが、定期課金の解約処理はされない
Android : 課金されるたびに都度メールが来る。このメール内に解約処理など manage できるページへのリンクが表示されている

定期課金の解約

実際はテストで新規購入のケースを何度も行いたい場合に定期課金の解約を行いたい時がある。テスト環境での定期課金の解約方法を知っておく必要がある。

iOS

テストアカウントの作成は、App Store Connect のユーザーとアクセスのSandboxテスターで行う。

Sandboxテスターのページで、テストアカウントが表示されれていることを確認して、「編集」ボタンを押す
該当のテストアカウントのチェックボックスにチェックを付ける
すると、「購入履歴を消去」ボタンが押せるようになるので、押す

解約処理の完了は通知されない。ボタンを押してから数十分後に反映されているようなので、すぐには新規購入はできない。

Android

ログインしたユーザーの Google Play の定期課金にて行える。また、定期課金の最初の購入処理がされるとメールを受け取るので、その本文に記載されている「Manage your subscriptions」リンクからもたどれる。

定期購入の解約が完了したらメールで通知されるので、それを待って新規購入のテストが行える。

メール本文は以下。

Your フットサルメット subscription from Players1st, inc. on Google Play has been canceled.

Order number: GPA.3340-2542-4611-83848
Order date: Sep 19, 2023 8:44:06 AM GMT+9

審査

iOS

上記のアイテム登録の注意点で示した、スクリーンショットと審査メモが実質必須なことを押さえれば、つまずきそうなポイントはないと思う。

今回1回リジェクトされて、App Store Connect 上の設定だけで対応できる対応内容だったが、コード上は何も変更がないのに、新しくビルド・アップロードして新しいビルドを審査に出すバージョンに紐付けなおす必要があった。

App Store Connect 上の設定だけで対応できる場合も 必ず新しいビルドを紐付ける必要がある。

多分これは、Apple の内部の都合で、一度リジェクトなどのステータスが決定されたビルドはステータス変更できないようにしているのだと思う。だから、再レビューするにはコードの変更がなくても新しいビルドが必要ということだろう。

あと審査は人間がアメリカのタイムゾーンで行っているようなので、日本時間のだいたい夕方から明け方に稼働してレスポンスが来る。だから、朝イチでレビュー依頼しても夕方以降までは何も起きない。変更を行ってから寝ている間に対応さしてくれるくらい時間がかかるものだと認識しておくと良い。

Android

製品版で新しいリリースを作成してあらかじめ作成していた定期購入を紐付ければ、特に気をつけるポイントはない。

審査は、システムが自動的に行なっているようで、数時間で結果が出る。 Google Play で公開されると、 Your update is live という題名のシンプルなメールが届く。

まとめ

in app purchase で定期課金を実現するには、複数の要素や多方面の知識が必要になるため、このドキュメントも膨大な情報量になってしまいました。

ひとつずつ解消していけば確実に実現するので、時間はかかると思うが、ぜひチャレンジしていただければと思います。

このドキュメントが誰かの役に立てば幸いです。

内容に関する、修正点の指摘、やってみたけど動かなかったなどの指摘はコメントにていただければです。

また、flutter x firebase で作るサーバーレスなアプリ開発や今回のような in app purchase の定額課金導入に対する有料のサポートも行っています。コンタクトフォームからお問い合わせください。

ペップのビルドアップ UEFA Champions League Final

Wed, 14 Jun 2023 01:00:00 +0000

ペップが2016年に ManCity の監督になってから6シーズンが経過した。

ついに最後の砦であった UEFA Champions League で優勝した。しかも、Premier League 優勝, FA Cup 獲得しての3冠達成だった。

ペップのフットボールの特徴として、個人的に最も重要視しているのが、ビルドアップ。

今シーズンのビルドアップは、今までのシーズンを踏襲しつつ改善し、より安定性が高まった印象。完成形に近いのではないか。

ペップのビルドアップの原則

6年見続けたペップのビルドアップは、いくつかの原則によって設計・運用されている。

5人で攻めて5人で守る

ビルドアップと攻撃で明確に役割を分けている。

ビルドアップは最終ラインとボランチの計5名で行う。残りの5名は攻撃に専念する。基本的にビルドアップに加わることはない。

他のチームで見られるように、トップ下の選手が中盤より低い位置まで下がってボールを受けて前線につなぐようなことはしない。

ビルドアップは、5名でボールを繋ぎながら全員で前進して、相手を敵陣に押し込む。そこからフリーの状態の攻撃の5名に良い状態でボールを渡す。あとは攻撃の5名に任せる。

最終ライン3名、次のライン2名の2ラインで組み立てる

今までは、いわゆる偽SBを使っての 3-2 の構成でビルドアップする。

左右どちらかの SB をピボーテと同じ高さで、中央に位置して、3-2 の構成を作っていた。この際、残った SB はサイド近くに位置するので、逆サイドに大きなスペースが生まれる歪な構成となっていた。

今シーズンは最終ラインを完全な3バックとして、3人を横幅に対して均等に配置した。その3人の前に次のラインの2名がボランチとしてポジションする。

きれいな 3-2 のポジションとなり、歪さがなくなり、これが安定感が増した。

実際、GK がビルドアップ時にボールを触ることがほとんどなくなった。

三角形を複数作る

3-2 の形がきれいに配置されると、均等な複数の三角形が形成できる。

三角形はパスコースが常に2つある状態なので、選択肢が担保され安定感が生まれる。

4-1 では三角形が歪になり、ピボーテが狙われやすく、リスクの高い状態になる。なので、3-2 の構成を作るために偽SBという発想が生まれている。

今シーズンは更に発展させて、SBをCBにして 「4人のCB + ピボーテ」 で 3-2 を作るようにした。

今シーズンの理想の立ち位置

前シーズンから変化はビルドアップの形が明確な3バックになった点。

3-2 のブロックでビルドアップする。全体のポジションとしては、3-2-2-3 という感じ。

ビルドアップ時

   Rodrigo  Stones

 Ake   Dias   Akanji

今シーズンのトップトピックとしては、「Stones のボランチ化」だろう。

今まで Rodrigo の隣には偽SBして、SBの選手を起用していたが、今シーズンの途中からCBの Stones をこのポジションへ起用した。

今まで CB としては見えなかった Stones のボールの受け方、動かし方、判断がとてもクレバーで、格段にビルドアップの質が向上した。

守りの時

守備の時は、4-4-2 になる。

攻撃の時の 3 バックが変形して4バックを形成する。

きれいな3ラインのブロックをしっかり構成することを重視している。

シーズン序盤

   Gundogan  Rodrigo

Ake  Dias  Akanji  Stones

攻撃時にボランチの位置にいた Stones が右SBの位置に入る。

終盤

   Gundogan  Rodrigo

Ake  Dias  Stones Akanji

終盤は、Stones がまっすぐ下がって最終ラインの右CBに入る。

Akanji は攻守にわたり右サイドをケアすることが引き続きできるし、Stones の横移動がなくなったことで、よりスムーズな守備構成への移動ができるようになった。

Ake がいない時の立ち位置

Ake が怪我をして離脱しているときは Waker が入った。

   Rodrigo  Stones

 Akanji  Dias  Waker

Akanji が右も左もできるのが大きかった。

Laporte は左ができるが、Ake の代わりに入ることはなく、Akanji を左に回すことで対応した。 SB的な役割も求められるこのポジションの序列としては、 Akanji の方が Laporte より上となっていた。

UCL ファイナル前半の立ち位置

Ake が復帰できたことで、今までの Waker に代えて Ake を先発で使った。

最終ラインは理想形と同じメンバーできた。

 Ake  Dias  Akanji

最終ラインは理想形だが、次のラインがいつもと違った

DeBruyne    Stones
      Rodrigo

 Ake  Dias  Akanji

Stones の立ち位置が Rodrigo と同じ高さではなく、もう一段前になっていた。いつもの「5人で行う」のではなくこの時は DeBruyne を左サイドにまわして「6人」になっていた。代わりに、いつもは左サイドのハーフスペースの前線近くに位置する Gundogan が右サイドに位置していた。

原則を崩して対策をしていた。

いつもなら DeBruyne は右サイドに入って、「攻め」のメンバーとしてハーフスペースを攻略する。ビルドアップには関わらない。

分析の結果やインテルのプレッシングへの対策からか、いつものビルドアップではない形だった。

左に張った DeBruyne は Ake から受けたボールを前線の Haaland めがけて長めのクロスを上げるようなことを何度か試みていた。

狙いとしては、なるべく DeBruyne をフリーにして、精度の高いキックを活かしたかったかもしれない。決められた狙い、戦術だったと思うが、原則を崩してしまったこととインテルの早いプレッシングに苦しみ、効果的なビルドアップは実現できていなかった。

ビルドアップからいつものように敵陣に押し込めたシーンはほとんどなかった。

UCL ファイナル後半の立ち位置

後半は前半のビルドアップの改善を行うために、メンバー交代はなかったが立ち位置をいつもの構成に戻した。

   Rodrigo  Stones

 Ake  Dias  Akanji

Stones が Rodrigo と同じ高さでより内側に位置するようになり、 DeBruyne はいつもの右サイドの攻撃側に入るようになった。

ボール回しも1タッチ、2タッチで積極的にパスを回すようになった。プレスがかかっていても後ろ向きに受けて、奪われないようにしながら、ボールを繋ぐようにした。

立ち位置のバランスが良くなったことや、インテルの守備のプレスが疲れから弱まったこともあり、よりボールがつながるようになった。

DeBruyne はいつものポジションでやりやすい感じで、右サイドで効果的な崩しが展開できるようになった。

ゴールシーンも、敵陣に押し込んだ状態で、数分間ポゼッションし、右サイドからの崩しの結果こぼれ球に Rodrigo が反応した見事なミドルシュートだった。

あの時間帯はいつもの ManCity の攻撃が再現できた時間帯だった。

今後も 3バックは踏襲するだろう

完璧な結果のシーズンだったが、おそらくペップにとって ManCity での最後のシーズンとなる 23/24 はどうなるか。

今シーズンの完全な3バックは安定感の効果が抜群なので、このまま踏襲するだろう。

Stones が引き続き使えるなら Rodrigo, Stones の組み合わせでビルドアップ時のボランチを形成するだろう。

Rodrigo, Stones のどちらかが怪我などで使えない時の代替えをどうするかが課題になりそう。 Phillips がSBもできれば、そろそろ実働させたい意図からも、代わりにでることも有り得そう。

常に改善点を見つけて的確に修正する

振り返ると、ペップは今あるものに満足することなく、常に改善点を見つけて的確に修正してきた歴史だったと思う。

偽SBでピボーテの負担を下げ、今回完全な3バック、CBのボランチ化でさらに修正してきた。

この修正が、シーズン最初だけでなく、シーズン中も行われるのが、見る側としてはとても楽しい。 Stones のボランチ起用はシーズン序盤にはない代表的な策だった。

いずれにせよ、今シーズンの課題をどこに見出して、どうバージョンアップさせる。それを見つけるのが楽しみだ。

テクニカルアドバイザー仕事が終わったのでまとめ

Tue, 07 Mar 2023 23:20:00 +0000

2月末でテクニカルアドバイザーの案件が終了したので、個人的な振り返りも含めてまとめておく。

UI は動的なものが当たり前に求められる時代に

Web UI は動的な見せ方が当たり前になったなぁと思う。スマホが普及したことの影響もあるだろう。

ボタンを押した時のちょっとしたアニメーションも当たり前。ページ遷移なくデータが更新されるのも当たり前。ユーザー側も開発側もそれが標準的なUIと思うようになった。

そうすると必然的に Javascript のフロントエンド開発が必須になる。結局、 UI 作る = Javascript でフロントエンド開発みたいな感じになる。

Web が覆い尽くす

UI としては Web 以外の手法もあるけれど、結局 Web に集約されそうな気配。

昔なら Windows 上でアプリを動かすことをしていた。 (みずほ銀行のATMにあるディスプレイで、エラーが起きてWindowsのデスクトップが見えている時があるのがそれ)

今なら Android, iOS 上でアプリを動かすのもありだけど、まだまだ開発の敷居が高いだろうな。 OS への依存度が高いのでロックオンされて、バージョンが上がるとエラーが出るようなことが Web に比べてると比較的多い印象。

Web なら今ある知識がそのまま活かせるし、デザインや機能含めすべての面で豊富オープンソースの恩恵を受けることができる。 Web のオープン性が生きている感じ。

構成は Javascript フロントエンド + API で

API サーバーを自前で建てるか、外部を使うかはあれど、構成は

Javascript フロント + API

これで良い。

個人的には、API は Firebase の Firestore Database にして、フレキシブルなカラム変更、ノーメンテナンスにして、バックエンド開発なし、サーバーレスのおまかせ運用にする。

Google 検索で得られる以上の情報を提供する

フィードバックで、欲しい情報は十分いただけたけど、もうちょっと優しい内容もあると。。という内容があったけど、結構それはわざとで、自分が提供する情報は Google 検索で得られる以上のものであるべき。というのがある。

概要の概要みたいな部分は Google 検索すれば、豊富なサイトにアクセスして読むことができる。読めば「何となく分かった」感じにななれる。

でも、システムを開発する場合、その程度の理解度では全然足りなくて、もっと実践的な理解が必要になってくる。

何となく分かるレベルの情報は知っているけど、更にその先に進めないから依頼(お金を払ってでも解消したい価値)があると思っている。

だから、基礎の基礎みたいな部分は追ってでも補完してもらって、もっと実現するために必要な大事な情報を提供するために時間を使っている。

なるべく動いているものを見せる

アドバイザーなので、コードを書かない、システム設計開発しない。ことは伝えていたのだけど、結局、簡易デモ環境を作って見せてしまった。

実施動くものを見るほうが何十倍も理解が進むので、あったほうが良いよなと思って、ちょっと作ってしまった。

アドバイザーは、適当なことを喋って時間を消費させることもできるし、そういう振る舞いの人も見かけるけど、個人的には物足りないと言うか、仕事に対してはもっと誠実でありたいと思う。

なので、理解をもっと深めてもらうためには何が必要かなと考えて、自分から提案して作った。

紹介会社が課題

それまでの反応やフィードバックを聞くに、多分エンドユーザーの課題は解消できたようなので、満足度は高かっただろう。

ただ、人材紹介会社が間に入る形式だったけど、やっぱりというか、相変わらず課題があったなぁ。

多分お金払う側から意見があって改善策を打ったのだろうけど、専門家側からすると契約内容以外の無駄な工数を強いられているだけになった。以前より悪手を打って状況を悪くしている。

単純にマッチングだけならもっと簡易的にできるはずだし、それで良いのだけど。

紹介会社の取り分程の価値が提供できないから意見を言われちゃっているだけなので、マージンの取り方を工夫すれば良さそうだけど、目の前のうまみがあるからそこは変えられないんだろうなぁ。

人材紹介会社の強みは大企業へのリーチ力と思っているし、マッチングだけしかしないのはそういう会社と思っているので、それで結構。業務に関わろうとしても、そもそも関わるような立場も提供できるスキルもありませんになちゃう。

ネットでマッチングできるサービスがあれば正直それで良いけど、今のところ見当たらないところを見ると、大企業は使ってくれないのかな、専門家側のエントリーがないのかな。

何れにせよ、課題は大きいのであまりこの状態が続くなら、自分でマッチングのためのサービス作っちゃうかも。

ということでお仕事募集中です

ということで、アドバイザーはこんな感じでやってきました。

お仕事の相談あればコンタクトフォームからいつでもご連絡ください。

コンタクトフォーム

Amazon で Kindle とペーパーバックを作るやり方

Tue, 07 Mar 2023 01:15:00 +0000

ひとりスタートアップで Kindle とペーパーバックを作った。

ちょっと手順や工夫が必要だったので、今後のためにメモっておく。

Kindle の作り方

基本的には Pages で書いて、epub にしてアップロードするだけ。

流れ

Pages で書く
Pages で epub 形式でエクスポート
表紙をデザインして png or jpeg 形式で保存
kdp にアップロード

epub について

Pages から epub にした時に、

維持されるもの

目次
改ページ
図表の位置
中央、左、右揃い
文字の大きさ

維持されないもの

フォントの種類
ページ数

表紙の作成

画像サイズは、1600px x 2560px にする。

Canva を使った。

ペーパーバックの作り方

流れ

Pages で書く
Pages で pdf 形式でエクスポート
表紙のテンプレートをダウンロード
テンプレートを元に表紙を作成
表紙と原稿を kdp にアップロード

奇数偶数で異なるヘッダー、フッター設定

ページ数の位置はページの外側にしたかったので、奇数ページと偶数ページで異なるヘッダー・フッターの設定にしたかった。

右ドキュメントパネルにて、「Section」タブの「Headers & Footers」の「Left and right pages are different」のチェックボックスを付ける。

ひとりスタートアップで設定したマージンは以下。

表紙作り

表紙は、表紙、背、裏表紙を1つの PDF ファイルで指定する。

ページ数によって、このファイルの縦横のサイズが変わるので、Amazon の表紙作成ツールでテンプレートを生成する必要がある。

ペーパーバックの表紙の作成を開く
表紙計算ツールとテンプレート生成ツールを開く
パラメーターを入力する (原稿のページ数の指定が必要なので、表紙作成の前に原稿作成が終わっていること)
サイズの計算ボタンを押す
表示された各サイズの「全表紙」の幅と高さをメモっておく
テンプレートをダウンロードボタンを押す
ダウンロードしたファルを解凍する

実際の表紙ファイルのデザインは Canva を使った。

Canva にログイン
新規作成する、キャンバスのサイズはメモっていた全表紙の幅、高さを入力する
テンプレートの png ファイルを追加して、キャンバスめいいっぱいまで広げる
テンプレートのガイドに従ってデザインする
表表紙をデザインする (kindle 表紙で作った画像をそのまま挿入)
背表紙に本タイトルと筆者名を入力する
裏表紙に ISBN 番号を入力する
出来上がったら、PDF ファイル形式でエクスポート、ダウンロードする
kdp の表紙としてアップロードする

校正用の印刷

「校正刷りを依頼」で世に出す前にチェックしたほうが良い。

余白のとり方、読みやすさなどをチェックした。

1冊 115ページで 757円ほどかかった。

[思考]老いへの許容

Mon, 06 Mar 2023 01:20:00 +0000

日常の出来事から思ったこと・考えたことをメモっておく。

つらつら書いたら長くなったし、自分用の読み返す用のメモなので、他の人があまり真剣に読むものでないです(汗

とある日のできごと

平日午後にジムに行った。土日は混むので、空いているから良い。

器具を使っている人数は10人行かないくらいか。値上げしてからだいぶ減ったかもなぁなどと思う。

今日使う器具は決まっているので、いつものように1器具15分 x 4種類のルーティーンをこなす予定。

レッグエクステンションを始めて、1セット10回が終わった時に話しかけられた。基本的にみんな一人で来て黙々とやるので、話しかけられるのは珍しい。

話しかけてきた相手は、年齢は70代後半から80代前半くらいだろうか。見た目、高齢者、おじいちゃんという印象。このジムに平日に来る人は年齢層高めだけど、その中でも高めな印象。

最初聞き取れなかったけど、聞き直すと「まだ、かかりますか？」とのこと。

あー、この器具がやりたいのか。時間を見ると残り7分くらいはあるな。「もう少しで終わりますよ。」と一応答える。

こちらが使っている最中に器具を使わせてほしいと言われるのは、2回目でかなり珍しい。言われるとやっぱり、「早く終わらせないと」という思いと、「自分のペースでやればいい」という思いが葛藤する。

「ちょっと早めに進めるか」と決めて再開する。

話しかけてきた相手は、隣の器具に座って、こちらをじっと見て何もしていない。単に待っているという姿勢。「やりにくいなぁ」と思う。

レッグエクステンションはもう一台、奥のスペースにあるはずだよなと思い、目を向けると、誰も使っていない。

「なんだよ」と思い、じっとこちらを見つめる高齢者に向かって、「あっち空いていますよ。」と伝える。「えっ？」と聞き返されたので、「あっちに同じ器具があって、空いていますよ。」と大きめに言う。相手は指差したほうも見ずに変化なし。こっちを見続けて待っているだけ。

「おいおい、わざとかよ」と思い怒りがこみ上げてくる。空いている器具があるのに、わざわざ人が使ってるのを邪魔したいだけか？結局、早めに切り上げて「どうぞ」と譲った。

その高齢者は「あい」とだけ言った。「ありがとう」ではなかった。それでさらに怒りが増したが、口には出さずに、空いているもう一台のレッグエクステンションに移動して続けた。

この時は「なんで人のじゃまをするのだろう」とか「高齢者だから言えば当然やってくれると思っているのだろうか」とか、色々考えてしまった。

その後悶々とする

結構大きな怒りが残ってしまったので、家に帰ってからも考えてしまった。

「単に意地悪のためにやっていた訳ではないよな」「もう一台あることを知らなかったのかな」「いや、あの人は結構前から見かけたことがあるから、もう一台あることは知っているだろう」

とかとか、答えのない問みたいな感じでくるくる考えていたら、ふと新しい考えが出てくる。

「もしかして、もう一台あることがわからなかった・認知できなかったのかな？」

見えなかったとか、目の前を通ったことはあるけど、忘れちゃっていたとか。高齢だとありえるのかな。と思った。

妻に確認してみる

妻は仕事上、高齢者を相手にしていた経験があるので聞いてみようと思い、夕飯時に今日の出来事や思ったことを話してみる。

すると、「多分、わからなかっただけだと思う」「単に目の前をものをやりたい、だから待っていただけ」「歳を取るとだんだん認知ができなくなるから、子どもと同じようになる」とのこと。

やっぱりそうか。気づけなかった・わからなかっただけか。

その場で怒らなくてよかったと思う。

老いを許容できるか

今まで、祖父や祖母の様子から高齢者の振る舞いはわかっていたつもりだったけど、実際わかってなかったのだなぁと思った。

自分はその場で腹を立ててしまって、その後、考え直すことができたけど、その場の感情で怒ってしまったら、あの人がもし認知できていなかったら、きっと怒られたことに困惑して傷つくだろう。

気づくはず・わかるはずという前提で対応したり、考えてしまうと外れてしまうのだな。

今後、高齢者の振る舞いを許容できる自分でいられるか。自分に問われた気がした。

未来は老いを許容してくれるか

今回は自分が高齢者に対しての把握不足があっての出来事だったけど、自分が逆の立場、高齢者になった時に確実に訪れることだなと思った。急に不安がこみ上げる。

自分が老いた時に、逆に、社会は許容してくれるだろうか。世の中は許してくれるだろうか。

批判されるだろうか。批判された時に自分はおそらく憤れないだろう・反論できないだろう。謝るしか無いのかもしれない。よく謝っているおばあちゃんの姿を見かける。

許してくれない世の中を批判することはできないだろう。自分の能力のなさを差し置いて、批判するのは単なるおごりだから。

能力はなくもうできないのに、できるように努力するだろうか。努力できたとしても、能力は上がらないだろう。

効率化はもう成り立たないかもしれない

日常を見ると、コンビニ、スーパーでの支払で時間がかかるのは、だいたい高齢の方が多い。スーパーやダイソーは、セルフレジが導入されている。もたつくのはほとんど高齢者。

それ自体は全然悪いことでもなんでも無い。それを攻めるような理由はない。それは単なる傾向だから。ただ、それを許せないとか困るとか思う人も出てきて、事件やニュースになるかもしれないなとも思う。

昔テレビで、マクドナルドのアルバイト同士のミーティングで、直近の目標を「一人あたりの対応時間の短縮」をあげていた。それは高齢社会では無理だろうと思う。もう単なる効率化は、成り立たないだろう。

しょうがないが成り立つか

「しょうがないこと」としてどれだけ社会は許容できるだろうか。今後許容できるようになっていくだろうか。

個人の思いとしては、許容できる世の中であってほしいと思うが、貧困率が高まり、今のような状態が続けば、難しいだろうとも思う。

ひとりひとりに余裕がない。経済的貧困は必ず心理的貧困につながるので、先々の方が難しいと思う。「心に余裕がない」時代。

思えば、高齢社会になることは年代別人口分布を見れば、何十年も前から容易に想像できた。高齢者に負担を強いる仕組みは作られたが、社会が高齢者を許容する視点での対応策はない。

自分があの方の年になるにはあと25年から30年後くらいか。

その時社会はどうなっているだろう。

社会はその時、色々できなくなっている自分を受け入れてくれるだろうか、許してくれるだろうか。

「ひとりスタートアップ」が本の形になりました

Fri, 17 Feb 2023 00:20:00 +0000

2022年12月に出した、「ひとりスタートアップ」。おかげさまで、ちょいちょい読まれております。

今までKindleのみで提供していましたが、紙の本の形態でも購入できるように作りました。

Amazon上では「ペーパーバック」と呼ばれています。

「ひとりスタートアップ無理せず確実に成長するための実践ガイドブックペーパーバック」

ペーパーバックって何？

Amazonが印刷、製本、郵送する、本です。

従来の出版社が出版する新書や文庫などの形態と分けて、「ペーパーバック」とAmazon上では呼ばれています。

注文してから印刷、製本すると思うのですが、翌日に届く地域もあるようで、さすがAmazonといった感じです。

今まで出版社におまかせしていた、レイアウト、表紙デザイン、原稿以外の文章の作成は自分でやることになるので、手間はありますが、PDFファイルをアップロードすれば、本になってしまう手軽さは、出版界の破壊的イノベーションだなぁ、などと感心したりします。

レイアウトの試行錯誤

文章の内容はKindleものと同じですが、読みやすい余白のとり方を見つけるのに、かなり時間がかかってしまった。

結果、5回も試し刷りしてしまった。。。

主に余白の幅の調整なのですが、余白の長さが本にすると1mm増えたりするので、製本される時の特徴みたいなのを把握するのに手間がかかりました。

結果的に背側の余白を多めに、小口側を少なめに、エディター側で設定できて、ちょうど良い余白の長さが見つけることができたので、納得の行くモノにできました。

中身はこんな感じ。

Apple Pagesで作りましたが、Appleの美しいフォントが活かせて、良い感じです😊

Amazonアプリから直接買える

ペーパーバックを出したことで、Amazonアプリから直接購入できるようになりました。

Kindleは、デジタルコンテンツ扱いになるので、アプリ内課金手数料30％適用の対象になってしまうんですよね。なので、手数料を払いたくないAmazonは、Amazonアプリから購入できないようにしています。

ということで、Kindleの形態だとAmazonアプリから直接買えない状態でした。

スマホで、AmazonのURLを開こうとすると、Amazonアプリがインストールされていると、アプリに遷移するようにしている方が多いと思うので、結構最悪なUXになってしまうんですよね。

スマホで商品のURLを開く
Amazonアプリが立ち上がる
商品情報が表示される
Kindleには「このアプリではこのコンテンツを購入できません」と表示されて買えない
では、どうしたら？となって購入できずにフローが終わってしまう

こんな感じで、せっかく商品情報まで遷移したのに買えないで終わる。という悲しいことになる。

アイテムのページにペーパーバックも表示されれば、終わらずに購入に繋がる可能性が作れます。

やはり本は手元に置いておきたい

個人的にもそうなのですが、何度も読み返したり、部分的に確認したりする場合は、本は物理媒体で置いておきたいと思う方は多いんじゃないかと思います。

気になる箇所にインデックスを張ったり、パソコン作業の傍らちょいちょい見返したりという事ができるのは、紙の本の良い点だと思います。

紙の本が手元に置けたので、今後新しく開発するサービスにも「ひとりスタートアップ」本を読みながら進めてみようと思います😊📖

自分で自分を客観的にアドバイスするみたいなことになりますが、結構ありがたいです。 (ひとりだとどうしても客観視点が足りなくなりがちなので)

ということで、「ひとりスタートアップ」本、よろしくお願いします

ひとりスタートアップ無理せず確実に成長するための実践ガイドブックペーパーバック

また、本のフォームを設けていますので、ご意見・ご感想、誤植の申告があればご連絡ください。

https://hirofukami.com/books

2022年を振り返る

Sat, 31 Dec 2022 01:20:00 +0000

本を出した

今までソフトウエアを作ることでサービスを提供して来た。創造物はソフトウエアだった。

これからは、時間売りでなく、創造物で稼ぎたいと思った。ソフトウエア以外の創造物でも出してみたかった。

創造物をあげてみると、ソフトウエア、本、画像、映像あたりだった。

本は今まで出した経験もあり、Kindleの環境も整っているので、取り組むには最適だった。

城ヶ崎海岸へ執筆のために泊まりに行った。結局、1ヶ月ちょっとで出版できた。

仕事

時間売をやめた

受託開発は完全にやらなくなった。フルタイムに近いプロジェクトにも参加しない。

アドバイザーやコンサルは引き続きしている。契約内容的には工数換算なので時間売りになるけど、どちらかと言うと、課題を解決するスキルに対する対価という料金算出にしている。

買収話があったり

結果的に収益が全然ダメな状態だったのと、向こうの提案内容が乗りたいものではなかったので、お断りした。

集中的に時間を使ったので、3週間くらいロスしたが、客観的にどう思われれているのか分かったので、収穫はあった。

運動

フットサル

怪我との付き合いが多かった。やっぱり年齢はあると思う。ちょっと負荷の高いことをすると怪我につながる。

左ふくらはぎの肉離れ 2回、違和感からの1ヶ月ちょっとお休み 1回。

今は over40とかover30とかの、強度の低い個サルに行くようにして、週1から2回楽しんでいる。

こんな感じで50歳くらいまではできるといいかなぁ。

ジム

週3回通うのは定着した。

最初は手術した左膝の筋肉を増やすためだったけど、全身も筋トレするようになって筋力が増えた。

今はジム通う前のプラス3キロくらい、体脂肪率12〜14%をキープしている。

これ以上筋肉つけると、妻と娘に嫌がられるので(笑)やめておく。

ライフイベント

イニエスタを見に行った

神戸まで行ってヴィッセル神戸のホームゲームを見に行った。

メインスタンド側の前から2列目だったので、ピッチが近かった。イニエスタ、大迫、槙野も間近で見れてよかった。槙野と大迫の太ももの太さすごかった。

やっぱりサッカー専用スタジアムはいいなぁ。味スタ近いんだけど、、、

神戸の街も少し楽しめたし、良い旅行だった。

家族旅行

石垣島に行った。とても良かった。

自然が多くて、人は自然と共存しながら生活できるのがいいんだろうなぁと思うようになった。

娘の大学が終わったら、石垣島へ移住もいいなぁなどと考えるくらい良かった。

でも、移住者が増えているようで(特に若い人)、空き物件も少なく、全般的に高め。

成人式

娘の成人式があった。親としての達成感が大きい。

ここまで来たかという感じ。大学卒業まで行けば、経済的にも独立して行くんだろう。

卒業まで順調に行けばあと1年ちょっと、もう少しだなと思う。

etc

博士取得検討

修士は持っているけど、ふと思い立って博士号取得まで行けるといいかなぁと思った。

2つ程の大学の説明会大学に出てみたけど、あまり魅力的に思わず。

大学に入るということはその大学の枠組み(ブランドイメージや訴求力など)が上限になるので、それならその枠組を超える取り組みを試みたほうが良いと思ったのでやめた。

セルフカット定着

コロナが流行りだしてから、完全に自宅で過ごすようになって、唯一外出する必要があったのが、散髪。

色々床屋を変えてみたけど、ここぞというところに出会えず、であれば自分でやろうということで、バリカンとハサミを買って自分でやるようになった。

セルフカットも回数を重ねるごとに慣れてきて、いい感じにできるので、3週間サイクルで、フェードカットを楽しんでいる。

まとめ

終わってみると、いい年だったなぁという感じ。

激動と言うよりかは、「やりたいことに対してしっかりアプローチして実現する」ことが出来ていたような気がする。

年齢を重ねるにつれ、激しく攻めたり焦ったりということが減ってきて、淡々と冷静にアプローチするようになった気がする。心情的には「静」で、でも何もしないことではなくて、新しく生み出すことは続ける。

そんな感じで2023年も行ければいいかな。

ハードウエアのWeb化

Wed, 14 Dec 2022 01:40:00 +0000

Web周りのテクニカルアドバイザーの仕事で、ハードウエア開発にちょこっとだけ絡んでいる。

ハードウエアの世界は縁遠いと思っていて、「IoTの時代だ」と言われても、積極的にアプローチしようとは思わなかったが、どうも最近のハードウエアはLinuxで動いているようで、「ほー、興味深いな」と一気に親近感を持った。

ちょっと調べてみると、「組み込みLinux」という単語もあるようで、ハードウエアのLinux化はすでに進んでいるみたい。

組み込みLinux

IoTに最適化されたLinuxも出ているようだし、組み込みLinuxの実践的な記事も出ている。

すでにハードウエアのLinux化は当然のアプローチみたい。

確かに、IPアドレスベースでの通信が可能だし、セキュリティ、ユーザー管理などもLinuxにおまかせできる。

IoTな機器だと、IPv6割り当てて、インターネットに繋がって、HTTPでWebAPIサーバーとの通信をすることもありだし、Linuxで動かすメリットは大きそう。

Linux化するってことはUIはWeb化するのでは？

そうするとUIはブラウザーベースでも可能になる。

なんとなくだけど、ハードウエアのUIってスタティックで、決まったレイアウトのViewしか出せないイメージがある。

LinuxならWebサーバーを立てて、UIをWebブラウザーにしてし locahost 内でHTTP通信させれば、パソコン・スマホの世界と同じアプローチで行ける。 SPAで動的に見せることも可能。

構成は、

Javascript
Web Browser
    |
    | HTTP
    |
Web Server (API)
Docker Container
    |
    | HTTP?
    |
Data (from sensors)

みたいな感じで行けそう。

Docker にしておけば、手元での開発環境との整合性も担保できるし、Docker部分は開発ベンダーが担当みたいに、責任分界点もきれいに分けられる。

懸念は表示のスムーズさかな

懸念は、ブラウザーベースにするので、今までのスタティックなViewよりかは、マシンスペックが低ければ、アニメーションがカクカクしてしまうかもしれない。

やっぱり、ブラウザーの描画処理って重いし、基本的に表示内容がリッチになればそれだけ負荷が大きくなる。

IoTな機器はコスト削減のために、マシンスペックをなるべく低くしたいだろうから、ブラウザーで動的ページを常にゴリゴリ動かすようなことには耐えられないかもしれない。

まぁ、この懸念はハードウエアのスペックが上がってくれば払拭されるけど。

楽観的に、ムーアの法則へ期待して、物理で殴れば懸念も引っ込む感じで。

競合は Android, iOSあたりか

組み込みLinuxの競合になりそうなのは、Android, iOSあたりになるんだろう。

実際Android搭載のハードウエアは増えているようだし、iOS CarPlay もiPhone以外のハードへのアプローチの1つとも言える。

オープン性で言えば Web > Android > > > iOS で、Webには有利。

Webのオープンさ、実績の豊富さ、スマホファーストな時代でも廃れないメインツールとしての有利なポジショニングがかなり強みになると思う。

UIをWebにするのは新しいアプローチだけど、WebがハードウエアのUIのメインになる可能性は高いと思う。

Web系エンジニアには新しいフィールドの誕生

実はIoT・ハードウエアは、これからWeb系エンジニアの新しい活躍のフィールドになってくるのでは？

UIがWeb化すると、フロントエンジニアだったり、フロントと通信するAPIをつくるWebアプリエンジニアも活躍の場が広がる。

Linuxそのものの設定になれば、インフラエンジニアも登場する。

ハードウエアを扱うメーカーのエンジニアは、今までのスキルセットで行くと、Webとは縁遠いと思われる。なので、今いるWeb系エンジニアへの需要がハードウエア業界から来る。ということが、これから起きそう。

ハードウエアは縁遠い、独特の世界と思っていたけど、向こうから近づいてきてくれた印象。

意外にもハードウエア業界は、Web系エンジニアの新しい活躍の場になってくれるのでは？

本を書きました「ひとりスタートアップ」

Mon, 12 Dec 2022 08:40:00 +0000

実は、本を出しました。

Kindleで販売中です。

ひとりスタートアップ無理せず確実に成長するための実践ガイドブック

タイトルは「ひとりスタートアップ」、サブタイトルは「無理せず確実に成長するための実践ガイドブック」です。

Kindle Unlimited な方は無料で読めます。

今まで本は2冊ほど共著で出したことはあるのですが、自分で企画、執筆、出版した初の本となります。

どんな本？

端的に言ってしまうと、「ひとり」で「スタートアップ」をするため本です。

本書内の「はじめに」には、

これから、「ひとり」で「スタートアップ」するための、考え方やうまくいくためのポイントをおさえながら、実践するためのコツや具体的な方法を説明します。

(中略)

「ひとりスタートアップ」は、あなたひとりしかいませんので、無茶はせずに、なるべく確実に進めます。

あなたのチャレンジを、大事に、大失敗を避けながら、まずは身の丈にあったやり方で成長を確実に作っていけるような方法です。

こんなことを書きました。

ひとりで、自己資金のみで、投資・借金せずに、サービスを成長させるための実践ガイドブックにしています。

ひとりスタートアップの考え方から準備、サービス作り、リリース後の集客、運用と、一通りのサービス作りのフェーズをカバーしています。

「自分でサービスを立ち上げたい」とか「独立しようかな」とか考えている方が、始める前にまず読んでもらって、実際に進めながらもう一度読み進めてもらえると良いなぁと思っています。

読者対象はIT系のサービスを立ち上げたいと思う見込み創業者ですが、新規事業の立ち上げをミッションにされている方でも「リスクを最小限にして確実に成長させる」アプローチは参考になるかと思います。

読者を励まし、応援し、常に並走し、アドバイスを送るための本を目指しました。

なぜ書いたの？

独立して13年、最初のスタートアップをチャレンジしてから12年が経っていました。

リーン・スタートアップに出会ってからは、その実践を重ねて来ましたが、うまく行ったこと・行かなかったことがあり、実践ノウハウや知見のようなものがある程度得られたと思っています。

今回、それを世に出してみようと思いました。

いまだに起業や新規事業には成功パターンはないと思われていますが、ある程度実践的な知見が集まれば「大きな失敗を避けて、成長させるためのやり方」はテンプレート化できると思っていて、そのチャレンジでもあります。

また、スタートアップに対しては、あまり創業者視点の本がなく、どうしても投資家、VC、インキュベーションなど周辺のものが多い印象で、これから創業者になる・なろうかと悩んでいる人たちに対して実践的にサポートできるような情報を提供したかったというのもあります。

この「実践的にサポートしたい」という思いは、年齢を重ねるにつれて徐々に意識するようになった「育成・教育・人を育てる」の具体的アプローチにつながっています。

イメージ的には「日本版 RUNNING LEAN」

リーン・スタートアップの実践本として「RUNNING LEAN」は、具体的にやり方を示してリーン・スタートアップの実践を解説した本としては、個人的にはとても参考になり、世に出た価値が高かったと思っています。

私も実際に本の通りにやってみて、「なるほど、こういうことか」と実感しながらサービスを作れました。

ただ、やってみたけどうまく行かなかったことや、日本的な特性には合わない方法だったり、出版されたのが2012年で時代の変化にマッチしなくなっている部分もあるかと思いました。

また、ちまたには起業系の本は多いのですが、アフィリエイト、広告収入、ECあたりを個人の範囲で小さなビジネス起こすこと想定したもので、大きな成長可能性を秘めた、いわゆるスタートアップに関連した本はほとんどありません。

そこで、日本に適したスタートアップ実践本、「日本版 RUNNING LEAN」をイメージして書きました。

ということで、「ひとりスタートアップ」よろしくお願いします

また、この本のページを作っています。

フォームを設けていますので、ご意見・ご感想、誤植の申告があればご連絡ください。

https://hirofukami.com/books

Amazon Kindleで読めますので、読んでみていただければです。

ひとりスタートアップ無理せず確実に成長するための実践ガイドブック

Hiro Fukami's Blog - 深海寛信のブログ

長沼公園 - お気に入りの場所

Flutter in_app_purchase で定期購入を実現する方法 2023年版

定期課金を導入したアプリ

参考にしたサイト

目次

環境

構成

準備

Flutter 側セットアップ

アイテム登録

iOS

注意点

Android

注意点

実装

基本的な処理の流れ

検証 verify とは

仕様

firebase functions

verify

verifySubscription

verifyReceipt

in_app_purchase

注意点

Sample Code

リストア restore

テスト

デバイス

iOS

Android

定期課金処理

定期課金の解約

iOS

Android

審査

iOS

Android

まとめ

ペップのビルドアップ UEFA Champions League Final

ペップのビルドアップの原則

5人で攻めて5人で守る

最終ライン3名、次のライン2名の2ラインで組み立てる

三角形を複数作る

今シーズンの理想の立ち位置

ビルドアップ時

守りの時

シーズン序盤

終盤

Ake がいない時の立ち位置

UCL ファイナル前半の立ち位置

UCL ファイナル後半の立ち位置

今後も 3バック は踏襲するだろう

常に改善点を見つけて的確に修正する

テクニカルアドバイザー仕事が終わったのでまとめ

UI は動的なものが当たり前に求められる時代に

Web が覆い尽くす

構成は Javascript フロントエンド + API で

Google 検索で得られる以上の情報を提供する

なるべく動いているものを見せる

紹介会社が課題

ということでお仕事募集中です

Amazon で Kindle とペーパーバックを作るやり方

Kindle の作り方

流れ

epub について

Pages

図表の挿入

目次の挿入

表紙の作成

ペーパーバックの作り方

流れ

Pages

マージン設定

奇数偶数で異なるヘッダー、フッター設定

表紙作り

校正用の印刷

[思考]老いへの許容

とある日のできごと

その後悶々とする

今後も 3バックは踏襲するだろう