コード日進月歩

しんくうの技術的な小話、メモ、つれづれ、など

iOS17.4.1時点では、QRコードを読み取るアプリ「コードスキャナー」でURLを読み込むとWebViewで起動する。

タイトルどおりの話なのだが、なんの問題がおきるのかを整理する

対象となるOSバージョン

iOS 17.4.1

どういうことか

iOSにはQRコードを読み取るアプリが標準で2種類ある。一つはカメラ、一つはコードスキャナーである。

この2つのアプリでURLを指し示すQRコードを読み取ったときの挙動が異なる。

読み取るアプリ URLを読み込んだときの挙動
カメラ Safariでリンクを開く
コードスキャナー コードスキャナー内でWebViewが開く

この挙動のため、コードスキャナーでページを開くとSafariでのログインセッションなどは引き継がれないため、Safariでログインをしていても改めてログインを要求される。

下記の例ではSafariでログイン済みの状態だったときに、カメラで読み込むとつつがなくSafariが立ち上がりログイン済みだが、コードスキャナーの場合はWebViewがたちあがるのでログイン状態ではない事例

何がおきるのか

WebViewというものを認識していない利用ユーザーからすると「Safariでログインした直後にも関わらず再ログインを要求される」「QRコードからログイン限定領域を見ようとすると毎度ログインを要求される」などの事態がおきる。

気をつけるべきこと

要ログイン領域のページに遷移するQRコードを準備する場合にはこのような事態になることを勘案してオペレーションを設計する。また可能な限りコードスキャナーではなくカメラでのQRコードの読み取りを推奨すると懸念は減らせそう。

関連リンク

2024年7月時点のRFCの仕様を鑑みると、URLの文字数は8000文字まで対応されている

過去に書いた記事へのupdateの意味も込めて

出典

RFC 7230 - Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing

どのようなことが定義されているのか

RFC7230では以下のようなことが記載されている。

Various ad hoc limitations on request-line length are found in practice. It is RECOMMENDED that all HTTP senders and recipients support, at a minimum, request-line lengths of 8000 octets.(リクエストラインの長さに関するさまざまなアドホック制限が実際に見られます。すべてのHTTP送信者と受信者が、少なくとも8000オクテットのリクエストライン長をサポートすることが推奨されます。) - RFC 7230 - Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing 日本語訳

リクエストライン(リクエスト行)には8000文字程度扱えることが推奨されるということになっている。このリクエストラインとは何かというと、HTTPリクエストを送るときの一行目にあたる情報。

例としてcurlを使って https://example.com/index.html/ にアクセスするリクエストを送る場合は以下の内容がリクエストのテキストになる。

GET /index.html HTTP/2
Host: example.com
user-agent: curl/7.84.0
accept: */*

上記の GET /index.html HTTP/2 がリクエストラインにあたる。

このリクエストラインが8000文字程度のサポートを推奨しているので、ホスト部を覗く文字列の長さもその分だけ表現可能ため、8000文字前後はURLの文字列の長さとして許容できる、という見解になる。

関連リンク

『大吉祥寺.pm』に行ってきたよメモ

大吉祥寺.pm - connpass』に参加してきたのでそのメモです、

各発表の感想

ざっと見たものだけピックアップで… ※資料スライドは見つけたら貼ります。


大吉祥寺.pm 基調講演

感想

  • 出てくるフレーズが一つ一つ面白いご自身の歴史の発表
  • 前夜に行われた生存者バイアスナイトを地で言っている内容だった
  • 人に歴史あり、というのを感じる発表だった

関連リンク


多様性の時代を生き抜くキャリアプラニング

感想

  • キャリアプランニングの考え方の話
  • 日本では総合職に対してジョブローテーションをさせる考え方があるが、その根底は個々人の長所の発掘なのかもしれないなと改めて聞いて思うなど
  • ときにはインフラ、ときにはフロントエンドみたいにできると自分の長所を見出しやすいのかもしれない

関連リンク


開発部に不満を持っていたCSがエンジニアにジョブチェンしてわかった「勝手に諦めない」ことの大切さ

感想

  • カスタマーサクセスからWebエンジニアに変わって景色の見え方が変わった、という内容の話。
  • お互いのコミュニケーションの話で、何を大事にするといいかということを改めて感じる。
  • 異なるコミュニティ文化圏の人たちにうまく伝えることって大事
  • 個人的に強烈に違和感を感じる部分があったので、それに関してはどこかで書き留めたいなと思っている。 書いた。

関連リンク


君たちはどうコードレビューする(される)か

感想

  • コードレビューをどうするかという話
  • 個人的にこの手の話を見るたびに、目指すべきは「チームの共通見解の構築」が第一の目的になるんだろうなとは感じている。
    • どこまで行っても品質の「担保」にはならないので、その部分は品質を守るためにあるいくつかの防御壁の一つぐらいの感覚
  • 最近このコードレビューに至る前にADRなどで仕様の議論をして相互理解を図るのもテクニックの一つなのかなと思いつつある

関連リンク


組織のスケーリングと持続性

感想

  • エンジニアに求められることと、その先の事業貢献する話。
  • スケーリングしたのに売上が増えないと、逆回転して退職につながるというのはなるほどなと思う話だった。
  • 半自動的にプロダクトの未来や事業の未来を自分ごとに落とす仕組みがOKRなのではないかなと思い、この話と連動させると理にかなっている仕組みなのではないのか?とか思ったりなどした。

関連リンク


Linux コンテナの歴史を追うとコンテナの仕組みがわかる

感想

  • Linuxとコンテナの歴史の話。
  • 登壇自体は途中から聞き始めたので、資料ベースで読み返しをしたのですがコンテナ技術がLinuxの技術と地続きなっているのがスッと入る話でした
  • 「コンテナは仮想じゃないよ隔離だよ」というのは意識しておきたいなと思う一句でした。

関連リンク


デザインのこれまでとこれから

スライドはなさそう

感想

  • ここ10年のデザイン周りの話の振り返り
  • そういや色々使ってましたねというのと一斉を風靡したinVisionがサービス終了したのが驚き
  • みんな意外とAdobeFigmaの話を知らなそうな反応だった

関連リンク


僕のキャリアとワインと鍋

感想

  • 飲食店であるワインと鍋にまつわるいろいろな話とエンジニアリングの話
  • ゴーストレストランをやって手応えを掴むというところからしプロダクトマネジメント力高いのでは…?など思った
  • 現在のWeb開発のプラクティスってどこにでも転用可能なんだなと思ったし、そういう話もいろいろなところで聞くなと思いました。

関連リンク


ドメインモデリングの現在地点

感想

  • ドメインモデルというがこれは何を解決したいのかなどを掘り下げていった話
  • 複雑さに関して、本質的なものと偶有的なもの、ローカルなもの、グローバルなものと切り分けて行って考えを整理していく過程はただただ聞いてて面白かった。
  • また、最終的にビジネスロジックとバリデーションの話に着地したのも知見が多く、スライドを自分なりに噛み砕いて解釈したい

関連リンク


集中して作業する技術

感想

  • 健康と集中に関するエビデンスが詰まったスライド
  • 健康のためには睡眠と運動が大事…という話題以外にもちゃんと即実践できるものがあってよかった
  • 個人的にポモドーロ計測をやっていた身なので、7ポモが出せるのはすごいという印象
  • デスク環境を整える話はkawasimaさんの話に通ずるものがあった

関連リンク


ノート PC に Linux 入れてみたけど結構良かった

感想

  • elementary OSを入れた話
  • かなりMacライクに使えそうなので、軽くてMacっぽくトラックパッド使いたい!って人にはよさそう
  • ただ登壇のときにはワタワタしそうという事例を目の当たりにしました

関連リンク


コミュニケーションをパスと捉えている話

感想

  • サッカーのパスになぞらえたコミュニケーションの話
  • 一休さんの橋の端のような)パスのパスの話みたいにもなったがうなづけるところは多かった
  • 相手の状況を把握するというのと、前段の発表の「勝手に諦めない」という話に通ずるものがあるなと聞いていた。

関連リンク


エンジニアリングじゃないエンジニアのお仕事

スライドは見つけたら貼ります、forteeはこちら

感想

  • エンジニアから技術広報や教育のほうにまわった事に関する話
  • スカウト送ったり送られたりは大変だよね…とは思いながら聞いてました。
  • 時間切れで教育の話は聞けなかったのでスライドが公開されたらちょっと見てみたいなと思いました。

関連リンク


あらゆる重大な選択の際に使えるアーキテクチャ思考

スライドは見つけたら貼ります、forteeはこちら

感想

  • 物事を考えるときは感情だけでなく論理と一緒に洗い出して評価していくと良いよねという話
  • 「全部の非機能要件を拾うのは無理」というのはたしかにそう
  • 現状のコンテキストに合わせて相対する軸を出してあげる考え方は大事。

関連リンク


ぼっちを避けて楽しむためのアノテコノテ

感想

  • コロナ禍によって失われたオフライン勉強会知見をコンパクトにまとめてくれたスライド
  • アイコンしかわからない、とかはかなり多いはずなのでわかるものがあると便利なのはそれはそう
  • ちなみにこのブログはfaviconをアイコンにしたことにより、「なんかみたことある…」が増えた気がします(定性評価)

関連リンク


大人の社会科見学 ~ NTT 技術史料館に行ってみよう!

感想

  • NTT技術資料館の行ってみたレポ&推せるときに推せトーク
  • 子どもの頃は知らないことを知るみたいな側面で好きだったんですが、ある程度大人になるとベースの知識との差分埋めみたいなのができて楽しいよなと思います。
  • ガイドさんもいるみたいなので行ってみたくなりました

関連リンク


僕はまだ見ぬ誰かを動かすために登壇をする。

感想

  • 幸福と登壇について、哲学的なアプローチから入る話
  • いわゆる「何者」かになれば幸福を捕まえることができるんじゃないかというところから、そうではなかったんだという話に入るところがとてもキレイに語られていました。
  • 勇気とは何かというのも深い問いだなと思いました。

関連リンク


全体を通しての感想

  • 10年の振り返りもあり、技術的な話もあり、若い層の経験談もあり、抽象的な設計の話もあり、バラエティに富んだ会だなと改めて思いました。
  • 最後に「続けていくことが大事」という話をされていましたが、つくづく自分自身もこのブログを続けていてそう思いました。
    • 自分自身も様々な場所の勉強会で刺激をもらいつつ、自分の記録と周りへの議事録共有のぐらいの気持ちでブログにしたためていますが、たまに誰かの役になったお声はいただくので細々とやりたいなと思っています。
  • 登壇したいなという気概が一段と高まったので、とりあえずYAPC函館とKaigi on Railsかな…とか思っています。
  • もっと本当は The One Person Framework で雑にシュッとつくることもやりたいのでそこもやりたいぞという気持ちに

関連リンク

『アナタはなぜ チェックリストを使わないのか?』を読み終わったよメモ

読んだ本

読むきっかけ

明確にどなたかのツイートかは覚えてないのですが、Twitterなどでオススメされていたのを見たのがきっかけ

本について

この書籍の著者であるアトゥール・ガワンデ氏は外科医かつ公衆衛生学者である。このガワンデ氏は2008年頃に「Safe surgery saves lives checklist」(安全な手術は命を救うチェックリスト)を作り上げたのだが、このチェックリストができあがるまでのエピソードと「チェックリスト」という考え方が汎用的に使えることをまとめた本となっている。

ミスが許されない医療の現場でいかに成功率を上げるかということにおいて、チェックリストが有用であることを様々な角度で語られている。

また、書籍の最後には「チェックリスト作成ためのチェックリスト」があり、普段の生活のチェックリストを作る際にも役立つものとなっている。

読後の感想

チェックリストの本質を見つめ直させる

この書籍ではガワンデ氏が建築業界、航空業界で使われているチェックリストの考え方を取り入れて医療業界に取り入れていくエピソードも紹介されている。その過程を通して「チェックリストが持つ本来の力を発揮するものはどのようなものであるべきなのか」ということもわかる内容となっている。

本質がどのようなもであるか?というのは書籍の最後にある「チェックリスト作成のためのチェックリスト」を見ていただければと思うのだが、この中のチェックリストを開発する際のチェック項目に以下のようなものがある

「各項目は見逃される可能性が高く、必須である」 - アナタはなぜ チェックリストを使わないのか? チェックリスト作成のためのチェックリスト より抜粋

個人的にはこの部分が非常に重要だと感じた。こちらに関しては書籍内で書かれている航空機のチェックリストの事例の話を見ると非常にわかりやすいので、抜粋して紹介する。

単発のセスナ機での飛行中に、エンジンが停止したときのためのチェックリストだ。(中略)このチェックリストには、エンジン再始動の方法が六つの手順に凝縮されている。燃料バルブを開く、予備燃料ポンプのスイッチをいれる、などだ。だが、一つ目の手順が最も興味深い。そこには「飛行機を飛ばせ」とだけ書いてあるのだ。パイロットは、エンジンの再始動や原因の分析に一所懸命になり、最も基本的なことを忘れてしまうことがある。「飛行機を飛ばせ」硬直した思考を溶きほぐし、生存の確率を少しでも上げるためにそう書いてあるのだ。 - アナタはなぜ チェックリストを使わないのか? 第八章 P203-204より抜粋

事故が発生して頭が真っ白になったら普段できていたこともできなくなる、というエピソードはどこでも聞く話ではあるが、それを加味して事故時の対応のチェックリストに盛り込まれている。

チェックリストはマニュアルでも教科書でもない

普段チェックリストを作っているとただの「手順書」となってしまう場合がある、言い換えればマニュアルになってしまう。このことに関して書籍内で「チェックリストはマニュアルでも教科書でもない」と書かれている。

航空機のチェックリストの事例のとおり、良いチェックリストは要点が凝縮されており、それ自体がなにかの手順を説明するものにはなっていない。そうしてしまうと利用者が使いにくくなってしまうし、純粋に手術や航空機の操縦などで細かく書かれた手順をこなすというのは、紙に対してペンでチェックをいれるようなことができないので難しい。

また、マニュアルではないという側面が強く感じられるのは各項目が簡潔に書くべきというところで、マニュアルや教科書は「何もわかっていない」人向けに書かれるものだが、チェックリストは「ちゃんとわかっている人がヌケモレせずやる」というためのものになっている。そのためこの書籍では「プロフェッショナルこそチェックリストを有効活用すべきである」という旨のことがかかれている。こあたりもマニュアルとは異なるというところを表しているなと感じた。

予想外のミスはコミュニケーションで軽減させる。

不確実性が高い事象を取り扱うことが多ければ多いほど、トラブルやミスが起きやすい。それらをカバーするために「チェックリスト作成のためのチェックリスト」には下記のような項目がある。

「チームメンバーのコミュニケーションを向上をさせるような項目を加えること」 - アナタはなぜ チェックリストを使わないのか? チェックリスト作成のためのチェックリスト より抜粋

これは、コミュニケーション不全が多い場所ではミスが起きやすいという話から記載がされている。

著書の中の例だと手術の話がある。手術の実施前に自己紹介や取り組むことに関しての話がされていない状態で挑んだ場合、なにか予想外のトラブルが起きたときに誰にどう頼むべきかもわからず混乱する。ただ少しばかりの自己紹介と簡単な作業の概要に関して手術の前に言葉を交えるだけでトラブルが起きたときに対処しやすい。また事前に喋るタイミングがあれば、不安に思っていることや心配事もお互いに告げやすい。

また、建設現場のエピソードでは以下のように書かれている。

建設を任された専門家たちは個人の能力を過信せず、二種類のチェックリストを使う。単純な手順の間違いを防ぐチェックリストと、話し合いをさせることで予想外の困難も確実にすべて解決させるためのチェックリストだ。 - アナタはなぜ チェックリストを使わないのか? 第三章 P82より抜粋

チェックリストの力を最大限につかう

この書籍を読むと、チェックリストは平時の事前確認や有事のトラブル対応など様々な場面で使うことができることがわかる。また無意味なチェックリストに関して意味のあるものへの変え方も見えてくるので、普段チェックリストに辟易してしまっている人ほど、一読する価値があるような本なのではないかなと思いました。

関連リンク

非機能要件の検討に困ったときに参考にすると良い資料『非機能要求グレード2018』

観点として何をおさえておくといいんだっけ?というときに役に立つのでメモ

対象ページ

システム構築の上流工程強化(非機能要求グレード)紹介ページ | アーカイブ | IPA 独立行政法人 情報処理推進機構

みどころ

「非機能要件って何を見ればいいんだっけ?」と思ったときに自分自身に馴染のある部分に関してはすぐ検討できるが、馴染のない部分は忘れがちになる。そういうときに「一般的にはどういう要素があるんだ?」ということをざっと紹介してくれている。また自分自身が扱うシステムがどの程度のレベルまで担保すればいいのだろうというときに具体的な指標も示してくれる。

メインの資料自体はExcel形式になっており、項目ごとに気にするべき観点とそれに対する対応度合いがレベルで表現されている。例えばシステムが稼働素べき時間を5段階で表しており、レベル3は「1日のうち1時間の停止は許容する」レベル5は「24時間無停止」というような形で項目ごとに守るべき段階を例示してくれている。また、モデルケース別にどのレベルまで担保すべきか?という例示もセットで用意されている。

とりあつかうもの次第で気にするべき非機能要件の要素は変わるが、そこに関しても上からなぞっていくと頭に浮かべておいたほうがいいポイントが見ることができるので、普段非機能要件を整理しない人にはもちろん、普段からやってきていた人もヌケモレチェック用途として利活用できそうな資料でした。

関連リンク

RailsでActiveRecordからidがキーのHashを作りたいときはindex_by が便利

表題ですべてを語るシリーズです。

検証した環境

$ bin/rails -v
Rails 7.1.2

index_byとは

Railsガイドの説明が簡潔なので引用する。

index_byメソッドは、何らかのキーによってインデックス化されたenumerableの要素を持つハッシュを生成します。 - Active Support コア拡張機能 - Railsガイド- 9.1 index_by

今回の事例

レコードのidをKeyにして、Valueに実態のModelのレコードが入っているHashを用意したい場合。今回はBookモデルのすべての値を対象とする。

index_byを使わない場合

以下のような書き方になる

result_hash = Book.all.each_with_object({}) do |object, hash|
  hash[object.id] = object
end

index_byを使う場合

以下のように書ける

result_hash = Book.all.index_by(&:id)

関連リンク

『設計ナイト2024』に行ってきたよメモ

設計ナイト2024【オフライン】 - connpass』に参加してきたのでそのメモです。

各発表の感想

※資料スライドは見つけたら貼ります。


ロジックから状態を分離する技術

感想

  • 純粋関数の話を基軸にいかに容易にしていくのか、という話
  • 入力から必然的に出力が決まるロジック類をDomainとしておこうという発想はよかった
  • 純粋関数の構成デザインパターンの分け方すごくいいなぁと思ったのと、このあたりの話を提唱している人いないのがびっくり

関連リンク


コンポーネント設計ってなんだろう

感想

  • コンポーネント」がどういうものかを見つめて、そこからコンポーネントとそのコアとなる部分の整理に仕方の話に言及した話
  • 個人的には「メンタルモデルの写像をつくる、ではなくメンタルモデルと乖離の少ない設計モデルをつくるように動く」という考え方は持っていなかったので学びが多かったです。
  • 最終的なコンポーネント設計に関しても「アウトサイドインで抽象度を段階的に下げていって設計していく」というのは頭にいれておくとよさそうな考え方だなと感じた。

関連リンク


そのDDDは本当にDDDといえるのか?

www.slideshare.net

感想

  • いわゆる戦略的DDDをちゃんとやるためにはという具体的な話
  • ビジネスと一体になって動かないといけないよね、というところで気にかけるべきところに関しての話が色々でてきてこのレイヤーでの経験値が薄い身としては聞いてて気になるところがあったので資料が後日みれたら読み返したいなと思いました。

関連リンク


オブジェクト指向考古学: 人類は再び DCI の夢を見るか

感想

  • DCI(DataContextInteraction)に関しての話
  • ロール指向という考え方は馴染みやすい考え方だなと示唆が得られた。
  • Webにおけるシステムのオブジェクトは短命なので、状態が変化することよりもどう振る舞うかに強く着目して考えるほうがいいんではないか、というのはRailsActiveRecordとうまく噛み合わせることで巨大化の封じ込めの一助になるのではなどと思ったりした。

関連リンク


コミュニティ/カンファレンス運営を支援する社団法人を設立する話

感想

  • ストレートに法人を設立する話のLT
  • コミュニティも人も推せるうちに推せは本当にそう思いました…
  • ちなみに創設されるのは「一般社団法人日本テックコミュニティファシリテーター協会」とのことです!

関連リンク


Railsでクリーンアーキテクチャを考えてきた

感想

  • Railsでクリーンアーキテクチャをやる話
  • Railsで依存関係の逆転したいとかそういう考えにあまり至ったことがないので、改めてその視点で考えてもいいのかなと思いました。
  • 依存性のルール付けならPackwerkのgemを使うのもいいのではないかなど聞いていて思いました。

関連リンク


やらない事を決める設計

感想

  • やらないことを決めるにはどうすればいいかというお話
  • BtoB SaaSなどだとバーニングニーズどうするのみたいな話なので色々考えること多いですよねという気持ちになりました。
  • プロダクトの不確実性が多いうちは捨てやすく作るというのは改めて大事ですねと思いました。
    • いわゆる捨てやすさの話は前の発表にあったコンポーネントの考え方を活用すればできそうだなという気分にもなりました。

関連リンク


良い開発のためにまず組織を設計せい

感想

  • 組織に関しての設計のお話
  • 不要なコミュニケーションを減らして、頻度を適切に調整するのは確かに大事。
  • 政治力の教科書としてサンクチュアリが出てきたのですが、未読なので読んでみたくなりました

関連リンク


全体を通しての感想

  • 設計という点においては同じでしたが、具体的な実装、アプリケーションの構造としての設計、前段としてのモデリングなどの設計、組織設計などバラエティに富んだ話でした。
  • 抽象的な概念の話も多く、そのあたりは出てきたフレーズを拾って知識補強したいなというところが多かったです。
  • 日本語だとデザインという言葉に関連する設計の話はなかったので、そのあたりも含めるともっとバラエティに富んだ設計話ができそうだなと思いました。
  • 自分自身も思っていることがいくつか発表では出てきたので、何かしらの形で発表することで思考を整理できたりするのかもなと思いました。そのため自分も「設計」ってテーマでちょっと頭を整理したいなと考えています。