Flutterのバージョンアップでハマった

プログラム、環境構築投稿日:

Flutterのバージョンが古かったので最新にしようと作業したら思わぬ所でハマってしまった

flutterをupdateしたあとでflutter doctorを実行したところandroid-toolchainでエラーが発生
環境を変えた憶えがないのでエラーの原因が不明
同じようなエラーが出ている情報をネットを色々と調べるが出てくるのはcmdline-toolsをインストールしたら解決したという内容ばかり
当然、必要なものは全てインストールしているしバージョンも合わせている。謎

ふとエラーメッセージを見るとflutter doctorのオプションに -vをつけてみるよう書かれていた(Doctor summary (to see all details, run flutter doctor -v))
flutter doctor -v

そこで原因が判明しました
理由はわかりませんが、Android SDKが2箇所にインストールされていました
自分では1つしかインストールしていないつもりで、自分でインストールしたAndroid SDKの場所をAndroid Studioで指定していました
しかし、flutter doctorで参照していたのはもう１つのAndroid SDK(C:/Users/{user_name}/AppData/Local/Android/Sdk)でした
flutter doctorが参照している場所にはcmdline-toolsはインストールしていなかったので当然エラーになりますよね

Android SDKを１つにして参照先をまとめるとエラーが解消して無事にバージョンアップできました

解決に半日くらいかかってしまった・・・。いつのまに別のAndroid SDKが入ってしまったんだろうか。謎は残りますがひとまずこれで作業が進められます

システム開発のテストで気をつけたいこと

プログラム投稿日:

以前にとある案件で上流工程だけ参加するプロジェクトがありました
そのプロジェクトの関係でテストに関する情報を共有して頂いた際に「？？？」となることがあったので、そのことについて書きたいと思います

まず、前提としてシステム開発でのテストは色々なやり方があるので「これが正解！」というのは無いと思っています
今回書いている内容も「これじゃなきゃダメだ！」と言っている訳ではなく、「こういう考え方も必要かも」くらいで読んでください

テストに関する情報を共有して頂いたのには理由があります
それは進捗の遅れ
進捗の遅れに不安になった発注元の会社様から相談があり、私の方から「では、仕様の認識のズレとか過不足を確認する為にまず単体テストの仕様書」「結合テストの仕様書」を貰って確認してみてはいかがですか？
という提案をさせてもらいました
そうすると開発会社から「単体テストはUnitテストをしているので仕様書はありません」「結合テスト仕様書はまだ作成していません」と回答がありました

私はこの返答を聞いてさらに不安になりました
単体テストをUnitテストでするのは良いです。ただどの程度をUnitテストで網羅するのかの指標を出してくださいと聞いても回答がありませんでした
そして時が経ち（その間、何をいってもテストに関する情報が出てきませんでした）、「結合テスト仕様書」が届きました
その内容を見て少し驚きました

「パスワードの入力欄は伏せ字で表示されること」

といった感じの試験項目が「結合テスト仕様書」にはいっぱい書かれていたんです

これは「結合テスト仕様書」なのか？と疑問に思いました
内容はほぼ単体テストのフェーズでテストすべき項目じゃないのか？
単体テストの粒度が私の思っている単体テストと違うとしても、これではフェーズごとのテストすべき内容と目的から大きくズレているのではないか？
これでいいのか？と・・・。

前置きが長くなりましたが、ここからが本来書きたかった内容です

まず、重要なのが「何のためにテストをするのか！」です

それは「不具合を見つけるため！！」です
「正しく動くはず」という視点でテストをしてしまうとテストパターンも少なく不具合を見つけることができません
そのため、出来るだけプログラムを作る前に設計書を基に発生しそうな不具合のパターンを考えてテストの仕様書（もしくはテストのコード）を書きますこの時、「不具合が無いはずはない」「不具合を出してやる！」くらいの視点を持つことが大事です
「不具合を見つけるため！！」なんてあたりまえじゃないか！と感じると思いますが、その案件で実際にシステムが動く段階になって触らせて貰ったら驚くほど初歩的な不具合が多くてビックリしました。それが結合テストのフェーズということで更にビックリしました。これは単体テストで行ってるUnitテストの網羅度が低く、テストに対する視点が間違っているのだろうと感じた為です
特に自分で書いたプログラムのテストをする際はこの視点が大切です

また補足すると、Unitテストでは全ての処理のテストを網羅するのは現実的でがありません。だから手動でテストしたり、時には一部だけ次フェーズのテストで作成されるデータでテストする方が効率がよいといった場合もあります。そのような場合には次フェーズにテストを遅らせるのも良いと思います

次にフェーズごとのテストについてです
フェーズの分け方は組織によっても変わるでしょうから、単体テスト、結合テストの２つだけについて書きます

まず単体テスト
「単体」とは何か？というのは粒度の違いがありますし、作るシステムによっても違います
ここでは今回の案件がWebシステムだったのでWebシステム開発する場合について書きます
単体とは「関数やメソッドなどのひとつの機能ごととするのか」「画面ごととするのか」そこで単体テストが意味するものがかわります
私は画面ごとで単体テストをすることが多いです
そうでない場合は、画面ごとのテストをするフェーズをもう１段階設ける必要がでてきます。関数やメソッドなどはUnitテストで行い、それらを使った画面ごとに単体テストを行います。もちろん先に書いたようにUnitテストでは全ての処理のテストが網羅できていないことがあるので、その点も注意しながらテストします
この時、画面ごとのテストでは「詳細設計書どおりに作れているか」が試験のポイントです

次に結合テストです
結合テストは単体テストを繋いで１つのシステムとして動作させた時の試験です
ここでテストするのは「要件定義が網羅できているか、正しく動作するか」が試験のポイントです
この時、単体テストで行った画面ごとのテストはする必要がありません
ただし、各画面をへてデータが入力されたり、加工されたりしますので、その結果各画面が正しく動作するのかは試験する必要があります
特に特殊データや、日またぎ、月またぎ、年度またぎなど単体テストではやってない可能性のあるテストも実施する必要があります

他に書いていないテストとして以下のようなものがあります

  • 外部とのインターフェース試験
    • これは外部システムなど作っているシステム外からの入力や、システム外への出力が正しいかテストします
  • 性能試験
    • 高負荷や大量データなど性能に関するテストをします
  • 復旧試験
    • バックアップなどから正常に復旧ができるのかなどテストします

他にもあるような気がしますが・・・ひとまず以上としておきます

長々と書いてきましたが、まとめると以下のようなことが今回のブログで書きたかったポイントです

  • テストは「不具合を見つける！」という視点でやろう
  • どのうなテスト項目が必要か、それをいつテストするのかちゃんと計画しよう
  • フェーズごとに「何をもってシステムの動作が正しい」とするのかを把握しよう

ということです

ベテランの開発者にはあたりまえのことばかりを書いていますが、最初に書いた案件のように？？？となるような事があり、そんな開発会社もあるようなので、そんな方へ少しでも考えるきっかけになればと思い書いてみました

異論・反論はあると思います
最初に書いたようにやりかたは様々です
顧客の要望どおりに動いていればそれで正しいと思います
その上でメンテナンス性や拡張性が高ければベストです

そうありたいと日々仕事をしていますが、なかなか現実は難しい。。。

メールで気をつけたいこと

Note、雑談投稿日:

メールに限らず文章でのコミュニケーションでは気をつけておきたいポイントがいくつかありますよね
今日はその中のいくつかのポイントについて書きたいと思います

まず、今回の内容は2014年に購入して読んだ「メール文章力の基本　大切だけど、だれも教えてくれない77のルール」という藤田英時さんが書かれた本を参考に書いています
この本はどのようなきっかけで購入したのかは憶えていませんが仕事をする上で一度ちゃんと勉強しておこうと思って購入したんだと思います
本を読む前も文章を書く際は十分に気をつけていたつもりでした。しかし、この本を読んで私が書く文章には思慮が足りていないと感じる部分が多くあったのを憶えており以前にもブログ（過去に書いていた別のブログ）で本の紹介をしました

今回このブログを書くきっかけは、仕事では当たり前のようにメールやチャット、その他のツールでお客様とやり取りしていますが、たまに気になる内容のメールを頂くことがあり自分も知らないうちに学んだことを忘れているのではないか？と、思って本を再読してみてました。そこで改めて今日はメールを書く際に「気にしてみて欲しいポイント」を挙げてみました（本からの抜粋ですが、一部表現を変えて書いています）

「件名はひと目で内容が伝わるように」

メールの件名が「◯◯(名前)です」とか「打ち合わせの件について」といったひと目で内容が分からない件名のメールが届くことがあります
こういった件名のメールは本文まで見なければ内容がわからなくて困ります
「XXXX案件の打ち合わせについての議事録」など件名から内容が推測することができると良いですね

「１つのメールで複数の議題を（できるだけ）書かない」

これは最初の件名の話しと同じですが、件名と本文にずれた内容が含まれるためです
複数の内容があると返答が漏れたり、情報を探す時に件名からの内容が推測できずに困ることがあります
複数の内容を書く場合には件名も複数項目書くか、メールを分けましょう

「本文は結論→理由→詳細の順に書く」

メールでもチャットでも相手が読みやすい構成にしましょう。最初から長々と書くと「これ、何の話しなんだろう？」とか「で、結論はなんだったのだろう？」など伝えたいことが正しく伝わらないかもしれません
まず結論を書いてメールで一番伝えたいことを伝えて、その理由、必要であれば詳細を記載するとスッキリして読みやすく、まとまった文章になります

「書いたメールは送信トレイに置いて確認する」

一旦確認する癖をつけましょう。（私も読み返すまで忘れていました。ただ、メールを送信する際には読み返すようにしています。また重要な内容の場合には書いた翌日に読み直して送信するように気をつけています。。。できるだけ）
文章って書いてるときには合ってるつもりでも、あとで見返すと誤字脱字やもっといい言い回しなどが必ず１つは見つかるはずです

「文章ではなく箇条書きを原則とする」

読む人のことを考えて簡潔さとわかりやすさが大切です
文章にするとつなぎの言葉をいれたりして読みづらくなります
（私も文章が長くなることが多いので気をつけようと思いました）

「明日、来週などではなく日時を明記する」

明日や来週が示す日付は読むタイミングによって変わりますよね。だから思わぬ間違いを生むこともあります
日時を明記すると間違いが少なくなります。できれば曜日も記載すると良いですね
明日(3/22 金曜日)や3/22(金)の午前中
といった書き方なら相手も認識しやすいですよね

「事実と意見をはっきり分けて書く」

これも重要ですよね。それが事実なのか、単なる意見や推測なのか文章の信用度に関わります

その他にも本には沢山のポイントがあります。今回挙げたポイントは本の前半部分のほんの一部です
まだまだ書きたいポイントがいっぱいあったのですが、書いてるとすごく長くなりそうです
本の方には色々な例題やシーンでの使わけなど役に立つ情報がいっぱい書いてあります
古い本ではありますが、とても役に立つ内容なので一度読んでみることをオススメします

ChatGPTに簡単なインジケーターを作って貰った

プログラム投稿日:

これまでChatGPTは簡単な質問をするだけで、何かのプログラムを作るようなことはしていませんでした

これまでは

「●●●な機能をもったアプリを作ったんだけど、英語でどんな名前が良さそうか候補を5個くらい出して」
とか、
「●●●(日本語)をXXXXの場面で使う場合には、どんな英語にするといい？」
みたいな質問をしていました

今回は、MetaTrade4で動く簡単なインジケーターを作って貰いました
作って貰ったお題は以下の通り
「前日の最高値、最安値、始値、終値の水平線で書いて、線の上に価格も表示するMQL４のプログラムを作成してください
この時、最高値は青、最安値は赤、始値は緑、終値は水色で表現してください」

そうすると、あっというまにコードを書いてくれました
書いて貰ったコードをエディタにコピーしてコンパイルして動作させてみましたが、表示がおかしい
価格の表示位置が画面左上にまとまってる、水平線が引かれていないなど

「水平線が引かれていないので、水平線を引くように修正して」と追加依頼

そうすると「すみません。水平線がありませんでしたね。」と、新しいコードを書いてくれました
それを再びコンパイルして動作。線がひかれました
同じように価格の表示も変更
しかし、なにかおかしい・・・正しく前日の値になってない
そこで、

「日本時間で前日の最高値、最安値、始値、終値となるように修正して」
と、要求しましたが日付の処理はうまくコードを作ってくれませんでした
たぶん、要求の仕方がよくないのでしょう
その後、色々な表現でお願いをしてみましたが期待するコードが出来ることはなかったので、最終的には自分でコードを手直しして作り上げました

今回の試しで分かったこと

  • 結構、しっかりコードを書いてくれる。活用するのはあり
  • 作ってくれたコードを自分で読めないと正否が判断できない。最低限その言語のプログラムは読める必要ある
  • 要求の出し方、質問のしかたが適切でないと、適切な答えは帰ってこない。ときどき要求を忘れることもある
  • 作られたコードは参考を参考にして、最終的には自分でコードを書くのがベスト！（今のところは。）

ちなみに、今回のお試しはGPT3.5で動作。4の場合は少し結果が違ったかもしれません。
また今度、次は4で試してみたいと思います

タスク管理に悩む

プロジェクト管理投稿日:

これまではタスク管理をあまりしっかりやってきませんでした
過去にはタスク管理ツールを導入して運用していた事もあるのですが、管理ツールの入力が煩雑でGoogleカレンダーに予定を入れるだけのお手軽でやってました

しかし、それだと作業の進捗が管理しきれず記憶だけが頼りになってしまって、作業漏れが発生することもあり、なんとかしないとダメだと感じていました

そこで、今年(2024年)からNotionを使ったタスク管理を始めたのですが、進捗管理はできるけど時間管理ができない・・・
だから時間管理はこれまで通りGoogleカレンダーを使うようにしてましたが、やっぱり２つを使うのは辛い
そこで最近リリースされたNotionカレンダーを使ってタスク管理をしてみることにしました

１つの画面でタスクとカレンダーが同時に見れるのでこれまでより楽にはなりましたが、カレンダーからタスクの詳細にアクセスできないのが少し不便です
Notionカレンダーの画面右に「Notionで開く」というボタンがあるんですが、できればカレンダー上に表示されているタスクをクリックすると詳細を表示できると嬉しい

現在の最大の不満点は、AndroidのNotionカレンダーのアプリがまだリリースされていないこと
タスクの登録はPCから行うだけでなく、スマホからも登録する事が多いのでアプリは欲しい！
Android版のNotionカレンダーアプリが早くリリースされる事を願います

スマホからのタスク登録はNotionアプリにタスクとして追加するか、これまで通りGoogleカレンダーから予定をいれて、それを複製してNotionと連携するという手法を取るか、別のツール（Notion Automatons）を使って連携するしかないですね

ひとまず、簡単にタスク登録できるスマホアプリでも作ろうかな・・・

まだ運用しはじめたばかりなので、改善点は沢山あると思いますがNotion+Notionカレンダーのタスク管理をしばらくやって行こうと思います

WPのカスタマイズが難しい

Note、雑談投稿日:

この度、ホームページをリニューアルするにあたり、最も重要なポイントは”楽に情報更新をすること！”でした
これまでHugoを使ってホームページを作成・更新していたのですが、ビルド、ファイルアップロードをするのが手間で情報更新が滞っていました（作った時は手間だと思っておらず、表示速度が早くなる方がいいと思っていたんです）

今回はCMSを使う事として、仕事でも利用しているWordpressで作ることにしました
最初はデザインを作成し、それをHTMLに変換し、テーマを作って・・・としていたのですが「それでいいのか？」「ブロックエディター使わなくていいのか？」という疑問が出てきて、勉強も兼ねてブロックエディターでデザインできるように色々と調べて、色々と挑戦したのですが、これが難しい。可能な限りPHPを変更せずにデザインを変えられるように管理画面のメニューから選択できるように・・・などしてたのですが、時間がかかって仕方ない

仕事としてお金が貰える訳でもないのに時間をかけて自分のホームページ用のテーマをゼロから構築するのはコストに合わない！！

ということで、今回は他の方が作られたテーマをカスタマイズして利用することにしました

利用したテーマは「Inspiro」。そのテーマを少しカスタマイズして利用させて頂いています
（InspiroのLICENSEはプラグインのコード内に記載があり、GNU GENERAL PUBLIC LICENSE version 2)
カスタマイズする作業で色々と勉強になったので、時間が確保できたらオジリナルのテーマを作ってみたいと思っています