日付を文字列にするときのオススメ

日付を文字列にしたいと思うことはよくあると思うので、オススメを書いておこうと思います。

はじめに

日付を文字列にする場合は2種類の変換の仕方があります。それは、

  • 日付型に戻せる文字列
  • 日付型に戻せない文字列

です。この二つを混ぜて扱うとすぐに死に目を見ることになるので、くれぐれもきをつけましょう。

日付型に戻せる文字列

日付型に戻せる文字列は、主にファイルに書き出すときやAPIで通信するときに用います。どのプログラミング言語でも戻せる文字列で扱うのが良いです。具体的には、ISO8601 (例: 2004-04-01T12:00:00Z) や Unix time(例: 1713225605) です。これらは大抵のプログラミング言語で日付型に戻す機能が用意されているいます。 理由がなければISO8601、特にタイムゾーン付きのISO8601 (例: 2004-04-01T12:00:00Z) をオススメします。

日付型に戻せない文字列

日付型に戻せない文字列は、主に人間に見せるために用います。例えば、「今」「10分前」「2024年4月19日」「April 19, 2024.」「19th April 2024.」です。この記事を書き始めた時刻を表していますが、タイムゾーン付きのISO8601 に戻すことはできません。特に、日本語とアメリカ英語とイギリス英語の表記の差を正しくパースして戻すことは至難の業です。

使い分けをする

基本的には日付型か日付型に戻せる文字列で扱い、ユーザーに表示する直前にユーザーの設定に合わせて最適な文字列に変換してあげるのが好ましいです。少なくとのTimeZoneや言語は考慮して、できれば暦(グレゴリアンや和暦等)や文化を好著した表記に変換ましょう。

アプリでノートンの警告が表示されたときの解決方法

iOSでセキュリティソフトを使っている人はほとんどいないが、たまにいてクレームがあったのでその解決法です。

問題

クレームは「アプリを使っていると https://app-analytics-services-att.com が危険だと警告が表示される」というものだった。このURLはFirebaseAnalytics で用いられておりGoogleが持っているドメインなのではっきり言って怪しいドメインではないし、FirebaseAnaliticsくらい誰でも使っているとは思うのだが、弊社のアプリでしかなぜか警告が表示されない状態だった。

SDKにissueがあるし、Nortonのフォーラムでも問題提起されていた。 github.com https://community.norton.com/en/forums/unsafe-site-warning-app-analytics-servicescom443community.norton.com

ウィルスバスターでも同様の問題が発生していたが、割と早めに警告は出なくなった。

解決

Nortonはどうも対応しそうになかったので、アプリで対応することにした。URLに含まれているattの文字から察するに、Apple Transparency Tracking に関連したトラッキングを行っているからこのAPIが使われているのだと予想した。

幸い弊社ではATTはほとんど使われていなかったので、取得しない方針をとることにした。Swift Package Managerを使ってFirebaseAnalyticsをインポートしていたが、FirebaseAnalyticsWithoutAdIdSupportをインポートするように変更した。

Nortonで警告は出なくなった。

まとめ

Nortonを入れないことをオススメします。

■

プログラミングにおいて、文字列はソートをできることを説明します。

ソートとは

データを一定の基準に従って並べること。同じデータをバラバラな順番にして、ソートした場合に必ず同じ順番になる。

プログラミングにおいては、配列から昇順または降順の配列を作ることを指すことが多いです。昇順のソートをした配列のN個目の値は、それより前の値より大きいまたは同じで、それよりあとの値より小さいまたは同じになっている。

ソートの操作をするためには、配列の比較できる値が入っている必要があります。

整数は比較できる

整数は、0より1が大きく、1より2が大きい。全ての整数は大小関係があり、比較ができます。

比較できる値の配列は比較できる

配列を比較するときは、それそれの配列の一つ目の値を取り出して比較して、異なる値であれば大小関係が決定し、同じ値であれば次の値取り出して比較します。この操作を繰り返して、値が取り出せない配列は小さいとします。

例えば、[0] < [1], [1, 1] < [1, 2], [1] < [1, 0]となります。

文字は数字として扱える

文字列ではなく、1つの文字についてです。

コンピュータは0と1のビット列しか扱うことができないので文字を表現するにも、各文字を1つの数字に割り当てることで表現しています。この割り当て表を文字コードと言います。アスキーコード(ASCII) や UTF-8がよく使われます。

アスキーコードでは、'A'を65、'a' を 97として扱います。

アスキーコードの文字列は比較できる

これらから、文字列を数字の配列であり、比較できます。

例えば、"a"→[97] < "b"→[96]となる。

アスキーコード以外の文字列は比較できるがプログラミング言語によって結果が異なる(たぶん)

アスキーコードは7bitで表現されており、それ以外の文字は複数バイトの文字として扱われる。プログラミング言語内部の文字列の扱いによって異なっている、そのため比較の結果も異なる。データベースでと、アプリケーションサーバー、Javascriptでソートした場合に結果が異なる場合がある。

アスキーコード以外意図しているソート順にはならないという前提で考えた方が良いので、ソート用の情報を別途持たせておくのが良いだろう。

意図した順番になるかはまた別の話

例えば"1", "2", "10"があった時に、大抵は"1", "10", "2"の順番に並んでしまう。意図したソート順に並べるのは一工夫必要です。

草津でワーケーションしてきた

妻「ちょっと一週間くらい実家帰ってきてくれない？」

話を聞くに、毎日一緒にいるのに飽きてきたらしい。確かに、うちの夫婦は2人ともリモートワークで、ほとんど出社もしない。習慣的に外に出るのも買い物か散歩程度で、1日23時間くらい同じ家の中で過ごしている。1日100歩程度のこともざらにある。私が出不精なため家にいるのは私の方になりがち。自分の家でゆっくりしたいらしい。

実家に行くのはなんとなく嫌だった。実家と仲が悪いというわけではないが、変わった理由で外に出るのだから、変わったことをしたいと思ったのだ。リモートワークをして、自分の家でないところから仕事をするのだから、どこで仕事をしても良いじゃないと考えた。そして、ちょうどいいサービスがあった(ステマではない)。

https://otell.app/otell-select-headerotell.app

Otellは長期宿泊できるホテルがまとまる。特にOtell Selectは最低限のWifiと机、いすがある。1週間どこかに行くのは便利そうということで予約することにした。Otellで予約する場合は、予約のリクエストという形で登録される。予約成立率があって、リクエストしたとしてもホテルが予約されたわけではない。失敗する場合があるようなにで注意が必要だ。

ワーケーションで5泊6日で予約したので荷物がかなり多い。仕事道具+6日分の旅行の荷物だからだ。できるだけ荷物を減らそうと思い、仕事道具は最低限にして、3日分の服を鞄に詰めてコインランドリーで一度洗うことにした。それでも重かったので準備が事前にできるのであれば、宅配で送るのをおすすめしたい。

草津の日々

夜のライトアップされた湯畑 毎日、朝起きて温泉に入り、仕事をして軽く町を散策しつつお昼を食べ、仕事を早めに切り上げて観光に行き、温泉に入る。朝起きて「とりあえず温泉に行こう」で始まり、熱々の温泉が常にあり、気が向いたら常に温泉に行ける。そんな日が4日も続く。東京はまだ35度を超えるような暑い日々が続いていたようだが、草津は肌寒い程度の気温だった。それもまた温泉を心地よくさせている。

ホテルは、町の端にある。シャトルバスは出ているが、歩きだとどこに行くにしても15分くらいかかる。坂も多い。それでも歩くほうが多かった。硫黄の香りが漂い、温泉の川が流れている町を散策していた。歩き疲れたら、休憩がてら足湯に入った。都会の喧騒とは違った、観光地を楽しむ人々の声が聞こえる。平日でも湯畑周辺では人が絶えない。

温泉が川になっている
西の河原
五重塔
草津熱帯圏
石灰をダバダバ入れているところ

些細な話

日曜日に明日から仕事のため、消耗品と軽く朝食を買おうと、買い出しをしに行った。

インスタントコーヒー等と、紅茶と信じられているクリープ

紅茶のつもりでクリープを買ったのだが、チャックが着いていないことに気がついて開けなかった。帰ってから写真を見ていた妻から「クリープ開けなかったんだね」と言われてやっと気がついた。しかも詰め替え用で詰め替え先は家にもない。

言ったら貸してくれたのかもしれないが、湯呑みでコーヒー飲んでいたので割れにくいタンブラーを持っていた方が良かった。

まとめ

  • 毎日温泉サイコー

C2カバレッジについて

カバレッジ基準のおもにC2カバレッジについて調べ直したのでまとめてみた。

カバレッジ基準とは

制御フローテストで着目する要素を「命令文」「分岐」「条件」のうち着目してカバレッジを計測する要素のことをカバレッジ基準と言います。

この要素で主なものは3つあります。

事実

 ステートメントカバレッジ

「命令文」に着目して全ての命令文を最低一度は通れるようにテストします。

ディシジョンカバレッジ

「分岐」に着目して全ての分岐を最低一度は通れるようにテストします。ステートメントカバレッジを包含しています。

コンディションカバレッジ

「条件」に着目して全ての条件を最低一度は通れるようにテストします。

単純条件カバレッジと複合条件カバレッジ

複数の条件を組み合わせた条件分岐がある場合に、個々の条件の真偽のみの組み合わせを網羅することを単純条件カバレッジという。ディシジョンカバレッジを包含していないし、ステートメントカバレッジも包含していません。

複数の条件を組み合わせた条件分岐がある場合に、そのすべての組み合わせを網羅することを複合条件カバレッジという。ディシジョンカバレッジを包含しています。

C2カバレッジが単純条件カバレッジと複合条件カバレッジのどちらのことを差しているかわからなかった。
同じような疑問を持った人がいたようだが、調べてみることにした。 コードカバレッジについて、また考える - その1 - ソフトウェアの品質を学びまくる2.0

Webサイトでの説明

C2を単純条件カバレッジとするWebサイトと複合条件カバレッジとするWebサイトがある。

書籍による説明

持っている書籍のみを一通り調べた。

(追記) * ソフトウェアテストと導入・移行 * 複合条件カバレッジが書かれており、単純条件カバレッジについての記載はない。 * プログラミング現場の単体テスト * 珍しく単体条件カバレッジのみが書かれている。単体条件カバレッジがディシジョンカバレッジことも書かれている * ソフトウェアテスト入門 押さえておきたい<<要点・重点>> * ディシジョンカバレッジまでは書いてあったがコンディションカバレッジについての記載は見つけられなかった * 知識ゼロから学ぶソフトウェアテスト * ディシジョンカバレッジまでは書いてあったがコンディションカバレッジについての記載は見つけられなかった * ソフトウェア品質を高める開発者テスト * C0、C1までは書いてあったがコンディションカバレッジについての記載は見つけられなかった

C2が何かが書かれていなかった。

Google ブックスによる検索

いくつかをピックアップした。全文読めないので若干何とも言い難い。

所感

C2カバレッジは、単純条件カバレッジと複合条件カバレッジのどちらかをはっきりさせることはできなかった(諦めた)。 単純条件カバレッジと複合条件カバレッジを計測できるツールを私は知らないし、計測するつもりもない。他の人も同様に計測する気はないのだろう。つまり、定義がどっちでもいいのだ。

まとめ

仕様を読む技術

走り書き。根拠はない。

まだ小さな開発チームなので社内のプルリクエストを流し読み程度に全て見るようにしている。コードの品質は人によってさまざまあるのは当然だが、仕様の理解度に差があるように感じている。それは人によって異なっていて、常に理解度の高い人と低い人がいる。

仕様を読むためには、主に3つの要素があるのではないかと考えた。

  • 前提知識
  • 環境要因
  • 完成の定義

前提知識

システム開発だと0から作ることは少なく、多くの場合は追加開発になる。要求は何か、既存のシステムがどうなっているか、技術的に何が使われて何を使えばいいのか、がわかっている必要がある。

例えば、「ルービックキューブに黒い面を追加する」という追加開発があったとする。要求は「他の6面と同様な7面目を追加する」ということになり、既存のシステムは「3x3マス、立方体の組み合わせ、回転できる」等である。技術的な部分は「回転機構、各パーツの形」等がある。この例の要求は明らかに矛盾していることに気がつく。しかし、システムを作るときはよくあり、矛盾があることに気がつかない人がいる。これは前提知識がないために起こるのではないかと思われる。

前提知識は単に時間をかけて知っていくしかないように思う。

環境要因

仕様のできや、忙しくて読む暇がない、期日が迫っている、疲労等で仕様を読む能力が減少する。

読む能力が低下する要素を減らすようにすべきだろう。

完成の定義

仕様に完成の定義が書いてあれば良いのかもしれないが、書いていない場合は完成の定義を考えられると仕様を読んだときの質が変わってくる。完成の定義が曖昧なまま書かれたコードは曖昧な部分が透けて見えることがたまにある。

完成の定義は「仕様を満たしていることがわかるテストを作成し問題なく通ること」と考えている。テストは自動でも手動でもかまわない。

最後に

「他にこんな要素があるのではないか？」とかがあればコメントしてほしい。

事例: プルリクを誰も見てくれない

エンジニアが数名という時に、Androidアプリをレビューする人がいないという事態が度々発生した。作ったプルリクエストは滞留してなかなかマージされない。取った解決策は、Githubにプルリクが作られアサインが行われたら該当の人に通知を行うというものだった。通知はメールやSlackに配信された。

結果としては、効果はなかった。その時にプルリクを見れる人は1人しかおらず、その人は会議に出ずっぱりだった。実質的に、リアルタイムにプルリクを見れる人は誰もいなかったのだ。通知を送ってもレビューがされないのも当然だった、誰も見れないので。

Androidのレビューできる人を増やすということで解決した。専門でない人にわかるような内容のプルリクにしたり、基礎知識を教育した。

現実を直視しないと何も解決しない。