コード日進月歩

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

ユニバーサルデザインフォント(UDフォント)に関してざっくりまとめる

ユニバーサルデザインフォント(UDフォント)とは

フォントメーカーのイワタ社が提唱したもので定義としては以下のように書かれています。

UDフォントとは、ユニバーサルデザインの考えに基づいて作った文字(書体)をいいます。家電製品に表示する文字にも、年齢や障害の有無に関係なく、多くの人が少しでも見やすい文字を作ろうということで開発を始めました。 - UDフォント開発のきっかけと発売までの道のり(1/5):NICT

そのため何か仕様などがあるわけではなく、ユニバーサルデザインのコンセプトを汲んだフォント全般のことを指す。

イワタ社以外のUDフォント

2006年に「イワタUDフォント」がさきがけとなり、他の日本語書体を扱うフォントメーカーもUDのコンセプトに合わせたフォントをつくるようになり、2022年現在ではモリサワ社やモトヤ社、フォントワークス社などもUDフォントを作成している。

日本発祥の概念

もともと日本のイワタ社が提唱したものであるため、2022年時点では海外では認知が広くなく、日本国外ではまだ認知度の低い概念と思われる。(Googleトレンドで UD Font で比較しても検索ボリュームは日本のみある状況)

参考リンク

RubyのYARDにはRDocのような:nodoc:は存在しない

そもそもRDocの:nodoc:とは

Rubyに標準的に備わっているドキュメント生成のライブラリRDocには:nodoc:というオプションがある。これはどういうものかはドキュメントに記載がある。

指定した要素をドキュメントに含めません。 - library rdoc (Ruby 3.1 リファレンスマニュアル)

上記の通り「ドキュメントが存在しない」ということを示すものである。

YARDには対するものがない

YARDにはドキュメントの省略というものが存在しない、またデフォルトではYARDはpublicメソッドのみをドキュメント化する。

YARDにはなぜ:nodoc:が存在しないのか

互換性のある機能がありそうなものの、存在しないことに関してはYARDのReadmeに記載がある

YARD will by default only document code in your public visibility. You can document your protected and private code by adding --protected or --private to the option switches. In addition, you can add --no-private to also ignore any object that has the @private meta-tag. This is similar to RDoc's ":nodoc:" behaviour, though the distinction is important. RDoc implies that the object with :nodoc: would not be documented, whereas YARD still recommends documenting private objects for the private API (for maintainer/developer consumption). - GitHub - lsegal/yard: YARD is a Ruby Documentation tool. The Y stands for "Yay!"

上記の中にあるように

RDocは:nodoc:を持つオブジェクトはドキュメント化されないことを意味しますが、YARDはプライベートAPIのためのプライベートオブジェクトをドキュメント化することを推奨しています

という旨の一文があるので、原則としてドキュメントを書いてほしい意図から記述自体を用意していないということだと思われる。

参考サイト

RailsでRSpecを使う際にテストデータ用のファイルを置く場合はspec/fixtures/file配下が良さそう

CSVアップロード機能のテストなどをするときにテストデータを置きたいときのメモ

出典元

file fixture - RSpec Rails - RSpec - Relish

ドキュメントいわく

Rails 5 adds simple access to sample files called file fixtures.File fixtures are normal files stored in spec/fixtures/files by default.

ということで spec/fixtures/file というところに配置すれば file_fixture というメソッドから読み込みが可能なため、何か必要な場合は置くことを進めている。

file_fixtureとは

ActiveSupportでテスト用のメソッドが用意されており、そのうちの一つ。RSpecではその仕組みに乗ることを推奨している。そのためPureなRubyのコードでは使えない機能ではあるので気をつけること。

ActiveSupport::Testing::FileFixtures

参考サイト

キャパシティを超える要望に関して誠実に応えたいときに見たいスライド「Noを伝える技術」

ステークホルダーの要求をプロダクトバックログに載せたときの優先順位付けなどに悩んだときによみたいスライド

対象のスライド

speakerdeck.com

みどころ

タスクとしてやりたいことを積み上げて行っていく場合、やりたいことが無限に発生するときがある。さらにタスクは自分から湧き出るものではなく、他人から依頼されるものもある。往々にしてそういうものは受け付けるだけ受け付けてやらずにタスクとして残しっぱなしにし、やる側も依頼した側も不明瞭な状態になる…なんてことが起きる場合がある。そういう他人から依頼されたものに対していかに誠実に「できない」と告げるべきかを整理できる内容となっている。

仕事とは人対人のコミュニケーションなので、いかにして「できない」をお互い納得できる形でできるかを考えなおすきっかけにもなるので万人に気づきがある内容だと思います。

関連リンク

表データのエクスポートフォーマットはカンマ区切り(CSV)よりもタブ区切り(TSV)が使いやすい

何もしないとCSVだけど、TSVのほうがいいよねという話を言語化したものです。

TL;DR

  • Excelなどの表データ書き出しでCSV(Comma Separated Value)を選択したくなったらTSV(Tab Separated Value)のほうがおすすめ
  • データの性質によるが、文字列においては , よりもタブ文字が含まれることのほうが稀なため、TSVを選択すると悩みごとが一つ減る。

今回考えるもの

Excelスプレッドシートなどで作られたデータをシステムにインポートするときに使われる形式として「CSVで書き出し」などがあるが、その選択肢として何がよいか整理するというのが今回のポイント。

今回扱うCSVとTSVの定義

CSV(Comma Separated Value)

文字通り、カンマで区切った値を指す。表の罫線に当たる部分をカンマで切り分ける形のデータ構造になっている。また、基本は1行を1つの独立したデータとして扱い、複数行つくることで表組みのようなデータの形式を提供する。

なお、こちらに関してはRFCで仕様が定義されている

RFC 4180 - Common Format and MIME Type for Comma-Separated Values (CSV) Files

TSV(Tab Separated Value)

Tab文字(正規表現などだと \t で表現されるもの)で区切った値を指す。前項のCSVと区切り文字が異なる以外はほぼ同じ概念となる。

TSVのほうが勝る点

一番大きいのは「実データにカンマが入ることはあるが、タブが入ることは稀」というところ。

数値だけを扱うデータの表の場合はそこまで考えるところは少ないが、データに文字列が入る場合にはデータの性質によってはカンマが入るためそれらを考慮してエスケープをかけるなどの必要性が出てくる。

また、TSVの場合はテキストエディタで開いた状態のものをコピペしてExcelなどの表計算ソフトに貼ると自動でセルごとに入れてくれるという特徴がある。

改行などがないデータを扱う場合はTSVをおすすめしたいです。

関連リンク

Google MeetはPWA版があり、単体アプリとして使える

Zoomはアプリがあるけど、Meetはアプリがないので迷子になりがち。という人向けのかんたんなメモ

インストール方法

Google MeetのTOPページからPWAとしてインストールできる。PWAなのでインストール方法は下記の方法を参照のこと。

プログレッシブ ウェブアプリを利用する - パソコン - Google Chrome ヘルプ

参考リンク

認証が必要なページにおける403/401と404の使い分けに関してざっくりまとめる

認証エラーだから401を返してあげるのがよいのか、悪いのかをざっくりまとめる

TL;DR

  • 順当に作る場合は認証を終えていないと見れないページはHTTPステータスコードは403(認可における不足の場合は401)のレスポンスコードを返す
  • ただし認証をした人だけ認識できるページの場合は認証できないときのエラーのHTTPステータスコードは404とする場合もある
    • ページとして存在することを認知されたくない場合がこれに該当する

そもそもHTTPステータスコードの403/401と404とは

ざっくり表現すると404はリソースが存在しないことを示し、403/401はリソースへのアクセスを行うことができない旨を示すものとなる。

404

404 は標準的なレスポンスコードの1つで、リクエストされたリソースがサーバー上で見つからなかったことを表します。 - 404 | MDN

403

HTTP の 403 Forbidden クライアントエラーレスポンスコードは、サーバーがリクエストを理解したものの、認証が拒否されたことを示します。 - 403 Forbidden - HTTP | MDN

401

HTTP 401 Unauthorized は、有効な認証資格が不足していることによりリクエストが適用されないことを示すクライアントエラーのレスポンスコードです - 401 Unauthorized - HTTP | MDN

ログインが必要なページに未ログインでアクセスしたときの処理

要ログインのページを作っている場合、そのページにアクセスする際にログイン情報がないと閲覧不能な場合は、前提となる説明のステータスコードを鑑みた場合だと「ログイン、すなわち認証を済ませていないユーザからのアクセスのため、認証が拒否されている状態なので403」と考えることができる。そのためログインが必要なページに未ログインでアクセスすると403ページを出す、というような作りをするケースがある。

認証している人だけに知らせたいページは存在を教えない

ただし、403や401は「このページは認証をしないといけないページです」というのを明示的に表現してしまう。例えば、以下のようなURLのパターンがあるとする。

このURLにおいて、https://example.com/secret/ 配下はログインが必要なページとなっており、この中で実際に存在するページは https://example.com/secret/page/xiqaapes/ とした場合、前2つは404、最後の1つは403でレスポンスが帰ってくるとする。

この場合に、最後の xiqaapes のページだけ副次的な効果で「存在をすること」を表現してしまう。

この副次的な効果で不都合が発生する場合がある、それは悪意を持ったユーザが権限内の情報を探し当てたいときに、情報があることのヒントとなってしまうことである。

些細な情報かもしれないが、少ないヒントを掛け合わせて悪意のあるユーザは攻撃などをしかけるので、「本当に認証している人以外には存在を秘匿したほうがよい」というケースの場合はレスポンスとしても存在しない体裁にして404を返す場合がよいケースもあるので、ページのコンテキストによっては検討したほうが良い。

なお、GitHubなどが404にする方向性を取っており、アクセスする権利があれば正常に表示されるページもログアウトすると404扱いになって見れない形になっている。

参考リンク