でも、リリース手前の山を越えるのに数週間かかっています！

リリースの何に手間取るのか

審査がある

ひとつ段階を超えるごとに、審査に数日かかります。

まさか人力でやっているわけではないと思うのですが。

AndroidStudioからのabbファイル作成方法がわからない

アプリのアップロードには、abbファイルとkeyファイルが必要でした。

なにそれ？と調べた限りでは、keyファイルがPCローカル上のどこかにある必要があって、
abbファイルはkeyファイルで署名した、アプリの魚拓みたいなものなのかなと。

PlayConsoleには、この魚拓しかアップロードできない仕組みなんです。

以降は、ちょっと改変するごとにgradle.buildのバージョンを上げて、アップロードしなおし、審査やり直しになります。

微妙な変更に時間がかかるようになるわけです。

グラフィックを作るのが面倒

とりあえずはこれで良いんですけどね。こだわり始めるとキリがないです。

よーし終わったー！リリースしよう！

からの気力が削がれる感じがすごいです。

きっちり作り込まないと出せないのは、作る側にとってはちょっとつらいですね。

さいごに

リリースまでに

・内部テスト

・クローズドテスト

・オープンテスト

・公開

と、４段階あります。

テストをすっとばして公開しても、だめではないようですが
初心者だからいっこずつやろう、とするとなかなか時間がかかります。

各段階でいろいろ不具合起きたりしますし。

というわけで、ここからもまだ時間がかかります。

データベース構築に使えるO/R mapper

データベースを活用するの、ややこしいです！

Realmの使い方は習ったことがあるのですが、現在は非推奨。後継が出ていますが、有料になるのでRealm　から　Room　に移行しました。

そうすると、Roomの使い方がまたRealmとは違うのですよねー！なんだそれ！SQLわからない！

と思っていたら、記憶術の宮口公寿先生にO/R mapperというものを教えていただきました。宮口先生、プログラミングにも詳しいのです。

O/R mapperとは、オブジェクト指向プログラミングとデータベースの差分を埋めてくれる機能をもったもののようです。

Firebaseが良い

クロコメさんにも、FireBaseが良いよと教えていただきました。

FireBase？と思って調べてみると、Googleさんがやっているサービスなんですね！

まとめ

わからないところを「わからない！」と公言することって大事なんだな、と思いました。
教えていただいて、本当にありがとうございます。

弱みを見せると誰かが助けてくれる、素敵な世の中です♡

自分が書く側にまわってみるとその気持ちがわかりました。英語を使って書くので、そう書くのが１番楽で公式なので、そうとしか書けない。

アプリ制作中ですが、詰まっているところがたくさんあります。

Fragmentの表示

bindingを使ってみたところ、R.idが取得できなくて迷いました。findViewByIdも使えないのです。
結局、R.id.binding.コンテンツ名.idという遠回り＆力技で解決しました。

表示が重なってしまう

FragmentはFrameLayoutなので、外枠に引っ掛けて固定することができず、表示させたいコンテンツがバラバラと重なってしまいます。

そもそもFragmentを使わずにActivityを増設することでこの問題をスルーしました。

データベースを取得して表示

メインスレッドでgetAll()するとエラーが出ました。コルーチン（非同期処理）を使わないといけないらしいです。

ナイスな動画を貼っておきます。
https://www.youtube.com/watch?v=KLEq_sG15QE

まとめ

あれ、私のアプリ落ちすぎ・・・！？

起動させると、しょっちゅうアプリが落ちます。もうやだ。



データベースを追加編集するための画面（Fragment）を表示させるのに時間かかりましたが、結局Fragmentじたい使うのをやめました。

そしてデータベースの初期値を入れるのにDbeaberを入れてみましたが、そもそも接続が難しい！
頭をかきむしりながら進めています。

苦痛が多いのですが、知らないことばかりで楽しいんですよねぇ。

本当はこんな記録もQiitaに書いていったほうがアクセスされやすく、有益なんだろうとは思います。
でもきっと「これどうクラブ」もちゃんとアクセス数の稼げるブログになっていくと信じています！

おしたくボードをアプリで表示させたくて、個人開発してみることにしました。
子供にプログラミングを語るにしても、何か結果を残しておきたいからです。
うまくいけばポートフォリオにも加えたいなぁ。

作るのはAndroidアプリ。

プラットフォームはAndroid Studio、
使う言語はKotlin。JAVAの後継言語です。

なぜアプリ制作なのか

私のアプリ制作は、Udemyのみんプロ講座で、北川先生に習いました。
※2022年現状、販売されていません。


２年ぶりにアプリ作ろうとじたばたしてますが、当時習ったことが使えなくなっていて、時代の流れの速さにびっくりしています。
プログラミングの世界は勉強が不可欠なんだなと身をもってわかりました。
親戚の子供がもう中学生！？というの以上に移り変わりが早いですね。

行政書士の法律の勉強に戻ってくると、安定的で変わらなくて何故か安心感を覚えます。
相乗効果があって良い感じです。
時間と気力体力の配分でバランスをとりたい。

つくりたいもの

おしたくボード、ご存知でしょうか？

これをアプリでやりたいわけです。

ToDoリストがイラストになっていて、タップしたら変わる。
とりあえず、最低限の機能でリリースを目指します。

まとめ

久しぶりにプログラミングやってますが、自分の欲しいものを好き勝手に作るのは楽しいです。

北川先生、今はFlutterに注力されてます。
https://minpro.net/

出産する親友に、安産御守を贈りたい。
例年なら神社で安産御守をGETして郵送するところですが、コロナのご時世、それもなんだかなぁと思いました。

そこから感染が広がっても嫌です。
安産を願ったはずなのに、逆効果が過ぎます。

そこで、完全に人の手を介さない、画面上に表示されるだけの安産御守どうかなと思いつきました。

意外となかった

Amazonでは桐箱に入った安産御守を見つけました。

ところが、オンライン御守となると、意外と無いものです。
握りしめたりできないから需要がないんでしょうか。

誰かが持っている安産御守の写真、なんてちょっと嫌ですしね。

自分で作ることにした

探すのも面倒になってきたので、自作してしまうことにしました。

自分で作った御守を渡す、だなんて青春ラブコメみたいです。やったことないですけど。

幸いなことに、お絵かきの経験はあったので、楽しく描いてできあがりました。

幸福チャームの全部のせです。

OpenSea出品

MINT！

NFT安産御守は流通することに意義がある

腹帯や安産御守は、あえて出産を無事に終えた人のものをもらったりしますよね。
いわば、人の手を伝わってきたものほど価値があるわけです。

モノであれば劣化しますが、NFTなら劣化しようがありません。
常に綺麗なまま、人の手を渡っていけるわけです。
これがNFT安産御守の最大のメリットだと考えます。

しかも画面に表示するだけなので、限りなく衛生的です。

CMしておきます

この安産御守はOpenSeaで買えます。

流通の初期に持っておくと、出産時の気持ちの安定につながるだけでなく、金銭的な安定にもつながるかもしれません。
産まれてくる赤ちゃんに、一生収入が発生する銀のスプーン、贈ってみませんか？

ネタとしても面白いかと思います。

ブログ共同運営にあたり、契約書を作りました。

そもそも仲良いのに契約書必要？というところからですが、契約書は何かあったときに嫌な気持ちにならない、揉め事を事前に回避するオトナの技だと思います。

せっかく勉強中の、行政書士の仕事をちょっと体験してみたかった、というのもあります。

初仕事です！わーい！

複数人でブログ運営をする時の、契約書作成の注意点をお伝えします。

まず契約書の内容を検討する

まずは、なほさんが作ってくれたテンプレートを改造するところから始まりました。

サクッと作っておきました。

早い！

契約書作りましょう！から、原案がすぐに出てくるのがすごいです。脱帽。

甲・乙のところ、名前を色付きで記入してくれたの、とてもわかりやすかったです。

後から置換すれば良いだけなので、なおすのは簡単。さすが、これは良い工夫だなと思いました。

最初からガチガチに固めると後から辛くなるし、フレキシブル運用できる緩さを持たせたい。
毎月の記事数は定めず、運用構成と取り分の割合だけ定め、あとは話し合いで決める内容で合意しました。

主な条項は下記の通り。

1. 作業内容
2. 費用の扱い方の取り決め
3. 各自の取り分の割合
4. 秘密保持契約
5. 著作権の扱いと修正可否
6. 契約期間

契約書を成立させるまでにはいくつもの壁がある

小規模事業者に電子契約は難しい

ブロックチェーンの話をするくらいなので、電子契約をしてみたいなと思いました。

電子契約とは、契約書をクラウドにアップして、タイムスタンプを付与してもらう仕組みです。

ただ、どのタイムスタンプ業者も月額制です。

無料コースもあるのですが、保持期間が１年以内だったり、有料サービスに移行するのが前提のようでした。

月５件以上契約するのならペイするかもしれませんが、今回のような単発契約向きではないなと判断しました。残念。

収入印紙が必要

１万円以上の契約書には、収入印紙が必要になります。

契約書に書かれている金額に応じて、収入印紙の額が定められています。

国税庁のサイトにわかりやすい表があります。
契約金額が大きくなると、契約書にかかる税金も莫大ですねぇ。

金額が書かれていない場合は最低金額の200円でOKでした。
契約書が２枚あるので、200円の収入印紙をそれぞれに貼ります。

収入印紙が貼られていない場合はどうなるの？

収入印紙が貼られていない契約書は、契約としては有効ですが、印紙税法違反になります。
契約内容はさておき、課税文書であるにもかかわらず必要な税金を納めていない、ということです。

収入印紙が貼られていない場合のペナルティとしては、当初に納付すべき印紙税の額の3倍額の過怠税がかかったりします。

ちなみに電子契約の場合には、収入印紙は不要です。

契約期間の注意点

では、契約日付はどうすればよいのでしょうか。
「20XX年○月○日から20XX年△月△日まで」と記載しておかなければ、一生契約したままにもなりかねません。

契約書を検討している一方、ブログ制作の方はもう走り出してしまっています。
契約開始時点は、このブログ共同運営の話が持ち上がった時点からにするのが良さそうです。

開始日に過去の日付を書けばいいだけなのでは？

だめなんですってー！

契約書に過去の日付を書くのは「バックデイト」にあたります。

違法、ではないのですが、コンプライアンス的によろしくないので契約書の信頼度が下がります。

ではどうしろと・・・

そんな時は、この魔法の１文を入れるだけで万事解決です！

本契約は契約締結の日にちに関わらず、20XX年△月○日に遡って効力を生じることとする。

この１文があるだけで、バックデイトにあたらないんだそうです。不思議ですね。

印鑑の嵐

日本はハンコ文化なんだな、と改めて感じるとともに、もうこの面倒臭さなんとかしてくれーと思いました。

• 氏名の後の印
• 割印（契約書が２部以上の時に、書類にまたがって押す）
• 契印（契約書が２枚以上の時に、ページにまたがって押す）
• 消印（収入印紙にまたがって押す）
• 捨印（契約書の右上隅に押す）

もっと詳しく知りたい方は、こちらの「はんこ豆辞典」のページが詳しかったですよ。
抜け漏れにご注意ください。

郵送は普通郵便で送らない

さて、こうして完成した書類を２部、郵送でやり取りします。
スキャンしてメール
簡易書留やレターパックなど、追跡できるようにしておかなければなりません。

郵送途中で紛失したら、勝手に契約書に記名捺印した見知らぬ誰かと、知らないうちに契約が成立してしまう可能性だってあり得ます。

まとめ

• 契約書はあったほうが良い
• 契約書を成立させるには内容＆型の検討が必要
• 収入印紙を忘れずに
• 契約開始日が過去の場合は魔法の一文を入れること
• 印鑑の抜け漏れに注意

うーん、難しかったです！
契約書作成には慣れが必要なのかなと感じました。
いろいろ考えて作りましたが、これでも抜け漏れあるのかもしれません。