カテゴリー: 開発

以下の説明は、PhpStorm に限らず、JetBrains の IDE なら同様のはずです。

PhpStorm で Git プロジェクトを扱っていると、リモートの変更を取得するために、Update Project ボタンを押しますよね。以下のように、Merge incoming changes into the current branch と Rebase the current branch on top of incoming changes のどちらかを選択しなければなりませんが、意味を知った上で選んでいますか？

CLI から Git を使わず、IDE からのみ Git を操作していると、Rebase を知らない人もいるかもしれません。そういった初心者向けに説明します。

前提

コミットログが以下のような状態になっているとします。

ローカル master で一つコミット（一番上）したタイミングです。origin/master からはコミット一つ分進んでいます。

変更を Push する前に、Update Project したい。しかし実は、別の開発者が一つコミットをリモートに Push 済みだったとします。

Update Project 時に Merge ... を選んだ場合

Update Project 時に Merge ... を選んで OK を押しました。コミットツリーは以下のようになります。

別開発者が行ったリモートのコミットが最後にマージされ、マージコミットが作成されています。

Update Project 時に Rebase ... を選んだ場合

Update Project 時に Rebase ... を選んで OK を押しました。コミットツリーは以下のようになります。

自分が最後に行ったコミットが一番後ろに付け足される形になりました。この時、マージコミットは作成されません。Rebase の方がコミットログがシンプルになることが分かると思います。

Merge と Rebase どちらを選ぶか？

コミットログのシンプルさが保たれるのは Rebase です。基本的に Rebase を選んでいいと思っています。

ただ、上記で説明した違いについては知っておくべきです。何か起こった時に対処するには、コミットログから過去を正確に知る必要があります。また、Git 自体の理解も重要です。全ての Git 操作を PhpStorm 上から行うことはできません。特にこの記事に書いてあることを知らなかった方は git rebase コマンドについて知らないことが多いかと思われます。よく使うことになるはずですので、是非調べてみてください。

こんにちは。福岡です。

ファイルをアップロードする時、制限されているファイルをアップロードしようとするのはシステムとして負荷もかかるので、できる限り「正しく」使って欲しいところです。一方で、「正しい」とはどんな条件をいうのかユーザが必ずしも認識できていないことはあり得るし、細かく注意書きを書けば書くほど読まれなくなります。そこで、Javascriptを使ってアップロードする前にファイルを検査する方法を探っています。

これは、今日では Javascript から Fie API を使って簡単にできるようになっています。制限サイズを超えていないか、拡張子のレベルで形式が合っているか、くらいはすぐにできます。

例えば以下の資料があります。
https://developer.mozilla.org/ja/docs/Web/API/File/Using_files_from_web_applications

WebClassでも、レポートファイルのアップロードでこれらを使ったチェックをやろうと思ったのがv11.8.2でした。が、問題が見つかって急遽キャンセルしたのがv11.8.2−2でした。

ほとんどの環境で動作していたのですが、Chrome + Android の環境で、Google Drive のファイルを指定してアップロードしようとする際に問題がありました。なぜか、アップロード前にJavascriptでファイルのチェックをすると、アップロードができなくなってしまいます。最近は学生もクラウドドライブ経由でレポート提出することも多いので、余計な混乱の元になりそうだったために元に戻してあります。

この問題は Chromium に報告してあり、現在、再現可能な問題として認識され、より詳細な調査をしよう、というステータスです。

https://bugs.chromium.org/p/chromium/issues/detail?id=1102021

早く治るといいなぁ。

今のWebClassの画面、人によってはボタンや注意書きを認識しづらいことがあるかもしれません。例えば色覚の認識が難しい人が見たらどんな感じでしょうか。「誰でも扱いやすいように」とは考えて作っていますが、このようなアクセシビリティに対して具体的な配慮まではできていませんでしたので、調べています。

総務省 みんなの公共サイト運用ガイドライン

アクセシビリティを取り扱うにあたって、１つの参考資料となるのがこちらのページです。

http://www.soumu.go.jp/main_sosiki/joho_tsusin/b_free/guideline.html

こちらは日本の公共機関向けにWebサイトのバリアフリー化を目指すべくまとめられたサイトになっています。具体的なガイドラインとしては「JIS X 8341-3:2016」を参照していますが、その中身は WCAG 2.0 とほぼ同じです（後述）。

国や地方の公共団体等に向けて調査報告や講習会の案内などがありますが、私たちとして興味を持ったのはそれを飛び越して最後の方、「障害者のウェブページ利用方法の紹介ビデオ」です。

どんな人を想定して作るか、とても重要なことではありますが、視覚・色覚は自分の感覚にどうしてもイメージが引きずられてしまいます。OSについているアクセシビリティ支援ツールも使ったことはなかったので、実際に使われている様子をイメージするのに助けになりました。

Web Content Accessibility Guideline

先ほどの総務省のページにもリンクがありますが、「Webアクセシビリティ基盤委員会」(https://waic.jp )というWebサイトで「JIS X 8341-3:2016」の情報がまとめられています。10月17日にはセミナーも開催されていたようですね。

こちらには JIS X 8341-3:2016 に加えて、元になっている WCAG 2.0 の翻訳も掲載されています。

• クイックリファレンス
  • https://waic.jp/docs/WCAG20/quickref/
• クイックリファレンスの各項目の解説
  • https://waic.jp/docs/UNDERSTANDING-WCAG20/Overview.html
• 実装と検証方法の事例集
  • https://waic.jp/docs/WCAG-TECHS/Overview.html#abstract

クイックリファレンスを見ると、対応項目に加えて、それぞれレベル、詳細な解説などが対応づけられています。例えば「1.4.3 コントラスト (最低限) レベル AA」を見ると、「テキスト及び文字画像の視覚的提示に、少なくとも 4.5:1 のコントラスト比がある。」と、具体的な基準値も示されています。

具体的な観点と基準があることは、実装して検査する上で重要と思います。

カラーユニバーサルデザイン

色に関しては、NPO 法人 カラーユニバーサルデザイン機構（https://www2.cudo.jp/wp/ ）で「カラーユニバーサルデザイン推奨配色セット」というのが公開されています（http://www2.cudo.jp/wp/?page_id=1565）

これは、色のみ分けにくい人であってもある程度見分けやすい色の組み合わせをまとめたカラーパレットです。カラーパレットは塗装用、印刷用、画面用の３パターンに対応していて、利用のためのガイドブックもPDFで公開されています。

ガイドブックのFAQによると、色の識別が難しい人と一口にいっても、それぞれ見分けにくい色、もしくは同じ色に見えてしまう色はそれぞれ異なるそうです。したがって、このカラーパレットは完全なパターンというわけではなく、できるだけ多くの人にとって比較的見分けやすい色なのだそうです。

このカラーパレットを使うかどうかはともかく、カラーパレットの作成経緯を少しでも知れたのは、私たちの今後の検査でも参考になるかと思いました。

チェックツール

先ほどれにあげた、WCAG 2.0 の「テキスト及び文字画像の視覚的提示に、少なくとも 4.5:1 のコントラスト比がある。」という項目を満たしたか確認するには、どうしたらいいのでしょうか。コントラスト比については、こちらの Web ページで WCAG 2.0 の基準も踏まえて色の選び方が適切か確認できるようです。

https://lab.syncer.jp/Tool/Color-Contrast-Checker/

また、総務省のページにリンクがありますが、総務省は「みんなのアクセシビリティ評価ツール：miChecker」というのを提供しているようです。

http://www.soumu.go.jp/main_sosiki/joho_tsusin/b_free/michecker.html

Firefox にも、開発者ツールにアクセシビリティチェックツールが搭載されています。開発者ツールを開き、「Accessibility」のタブを開いて有効にすると動きます。Datapacific のホームページで試しにコントラストチェックをしてみましたが、NGが出ていました。

さらには、視力や色覚が弱い人の視界を再現させてみることができるブラウザエクステンションも Chrome にあります。

https://chrome.google.com/webstore/detail/chromelens/idikgljglpfilbhaboonnpnnincjhjkd

今後

いきなり WCAG2.0完全対応！とはいかないので、まずは最初に対応させる項目をピックアップした後、チェック＝＞対応の具体的なノウハウを確立して開発サイクルに組み込みたいと思います。

こんにちは。福岡です。

この夏のアップデートパッチは７月３１日のリリースを予定していましたが、テストのやり直しが発生したため、少し送れて８月のお盆前を予定しています。

WebClassの年2回のリリースでは機能全体の検査をしています。だいたい１ヶ月くらいの期間をつかっていますが、その間に見つかったバグの修正などを反映したバージョンに差し替えるため、期間中には検査対象のバージョンや環境を変えて複数回テストをします。

今回はテストターゲットとして、拡張機能の開発途中のブランチで自動生成されたパッチを誤って選んでしまいました。そのままテストを開始してしまっていたため、テストターゲットを選び直してやり直しとなってしまいました。

リリーススケジュールは社内のいくつかのスケジュールとも関係していたため、遅れが出るのは私たちとしても痛いのですが、その中でも幸いと思っているのは「STOP」ができたことです。

投入した何かがあると、どうしても取り返したくなります。そのために、続行したり、ちょっとした調整で済ませようとします。それで済むこともあるとは思いますが、「どうも進み方がおかしいぞ？」と思った時は、手を止めて仕切り直しをする勇気が必要と思います。スタッフも受け入れて、テストのやり直しも進めてくれています。