ソフトウェア開発」カテゴリーアーカイブ

PlaywrightとARIA

今月のSoftwareDesignを読んでいて、Playwrightのところで出てきたARIA。
どういうものなのか勉強がてら調べてみた

ARIAとは何か

ARIAは、Webコンテンツをスクリーンリーダーなどの支援技術で正しく解釈できるようにするための仕様です。W3CのWAI(Web Accessibility Initiative)が策定しています。

なぜARIAが必要なのか

HTMLの標準要素には、ブラウザが自動的にアクセシビリティ情報を付与します。

<button>保存</button>
<!-- ブラウザは自動的に「ボタン、保存」と支援技術に伝える -->

しかし、リッチなUIを作ろうとすると<div><span>でカスタムコンポーネントを作ることがあります。

<div class="fancy-button" onclick="save()">保存</div>
<!-- 支援技術には単なるテキスト「保存」としか伝わらない -->

この<div>はボタンのように見えて動作しますが、スクリーンリーダーはそれがボタンであることを認識できません。ARIAはこのギャップを埋めるために生まれたそうです。

ARIAの3つの柱

ARIAは主に3つの概念で構成されています。

Role(役割) は、要素が何であるかを定義します。

<div role="button">保存</div>
<!-- 「これはボタンです」と支援技術に伝える -->

Property(プロパティ) は、要素の性質や関係性を定義します。

<input aria-label="検索キーワード">
<div aria-describedby="hint-text">...</div>

State(状態) は、要素の現在の状態を定義します。

<button aria-pressed="true">太字</button>
<div aria-expanded="false">メニュー</div>

PlaywrightがARIAを活用する理由

Playwrightでは、従来のCSSセレクタによる要素特定に代えて、ARIAのロールと名前による特定を推奨しています。

// CSSセレクタによる従来の方法
page.locator('button.submit-btn')

// ARIAロールと名前による方法
page.getByRole('button', { name: '送信' })

accessible nameとは

getByRoleの第2引数で指定する「name」は、accessible name(アクセシブルネーム) と呼ばれるものです。以下の優先順位で決定されます。

  1. aria-label属性(最優先)
  2. aria-labelledbyで参照された要素のテキスト
  3. 要素内のテキストコンテンツ
  4. title属性(フォールバック)
<!-- aria-labelが最優先 -->
<button aria-label="送信する">Submit</button>
<!-- accessible name: "送信する" -->

<!-- ボタン内のテキストも使われる -->
<button>送信</button>
<!-- accessible name: "送信" -->

inputの場合は関連付けられた<label>も考慮されます。

<label for="email">メールアドレス</label>
<input id="email" type="text">
<!-- このinputのaccessible name: "メールアドレス" -->

なぜこのアプローチが優れているのか

実装の変更に強い:クラス名やID変更の影響を受けにくくなります。CSSセレクタに依存したテストは、デザイン変更のたびに壊れがちです。

アクセシビリティの担保:テストが通るなら、スクリーンリーダーでも適切に認識されることが保証されます。

可読性が高い:テストコードが「何をしているか」が明確になります。button.submit-btnよりbutton { name: '送信' }の方が意図が伝わります。

同じ名前の要素が複数ある場合

実際のアプリケーションでは「削除」ボタンが複数行に存在する、といったケースがあります。

<tr><td>商品A</td><td><button>削除</button></td></tr>
<tr><td>商品B</td><td><button>削除</button></td></tr>

この場合、親要素で絞り込むことで対処できます。

// 親要素で絞り込んでからロケート
page.getByRole('row', { name: /商品A/ })
    .getByRole('button', { name: '削除' })

まとめ

こう見ると、ARIAベースのロケーターをやろうとすると、aria用のプロパティを使いたくなりそう。でも、そういうのを使わなくてできるだけ表現し、最終手段として使うようにとのこと。
しっかりアクセシビリティを意識したフロントエンド実装が必要という話なんだなと。

ARIAでテストが書きにくいと感じたら、それはそのUIのアクセシビリティに問題がある可能性を示唆していると。テスト自動化とアクセシビリティ改善を同時に進められる、この相乗効果こそがARIAベースのテスト戦略の本当の価値です。

参考リンク

SCRUMのプランニングに時間かかりすぎ問題

なんだかんだ言ってスクラム開発よりウォーターフォールの開発経験のほうが長い経歴なのですが、かっちりとしたスクラムに今入り始めています。

過去にも一度経験はあり、異なるお客様・チームでの経験となるので、やっぱりそれぞれ進め方に微妙な違いがあるな、と嬉しく感じています。
むしろ同じだったら怖いな、と。

今の開発はまだ始まったばかりなのでこれからといったところなのですが、プロダクトバックログアイテムに対しての疑問がつきません。

前回のスクラム開発時にもあったのですが、PBIに対しての疑問を口に出していった結果、元々のPBIが再検討になったり、形を変えるという経験があります。
その中で、プランニングMTGで本当に見積もり。つまりプランニングポーカーなどのところまで行けるものなのかな?と思っていました。

すごい長尺のMTG時間を確保してプランニング自体を計画するしか無いのでは。。。

スプリントプランニングにとても時間がかかるのですが、どうしたらいいですか? | 株式会社アトラクタ

ぼんやり考えながらググってみたら、それっぽい答えが。

結局のところ、PBI自体を叩く時間が必要ということなのでは、と読んで思いました。
POが、目的ではなく方法論にまで足を踏み込みすぎてPBIを作ってしまっているからこそ、疑問が出てしまうということもあるのかもしれません。

このあたりは自社組織内でプロダクトをスクラム回しているわけではなく、お客様先プロジェクトに参画して進めていく以上、チームとしての経験が蓄積されるわけではないので難しいところ。

逆に言えば、このあたりのPOやスクラムマスターの支援が適切にできると、いい形のチームビルディング、教育になりそうだな、とぼんやりと思った。

AIにより加速していく世界の中でいつまでも似たような失敗繰り返しているわけには行きませんものね。
そのあたりをちゃんと紐解いて説明・導いていけるようなムーブが出来るようにがんばりますわー

Flutter・Dart勉強中

昨年末からFlutterの開発プロジェクトに参加・・・というか、立ち上げというか、関わることになりました。

これまでも何度となく新しいプロジェクトに参加するたびに、対象となる技術に関して勉強しようと本を買う。
そして、忙しさから本を読まないでプロジェクトを終える。。。という事になっています。

実際問題、私の役割としてコードを書くことはそれほど無いので、これってどこまで理解している必要あるんだっけ?といつも微妙な気分になりながら、メンバーに任せている。
任せざるを得ない感じになるんですよね。

世はAIコーディングまっしぐらな状態なので余計にその状況には拍車がかかると思います。
偉い人も呟いていました

ソフトウェア開発というものが「AIに対して正しく意図の定義を伝えること」と「結果を正しく検証すること」になっていくのかもしれません。

でもそうなると、AIに対して”正しく伝える”の範囲も結構広くなる可能性もありそうだな?と。
”コンテキストや仕様を正しく伝える”というのは当たり前の話ですが、”ソフトウェア構造に対する注文を正しく伝える”こともまだしばらく必要になるはず。
そうなると、より解像度を上げるためには言語やフレームワークの制約、選択肢などを正しく把握しておくのは良いことだと思いました。

むしろ、それらを抜かした形はいくらでも量産できてしまい、差別化出来ずに埋もれていくことになりそうだな、と。
何で差異を作っていくのかはもちろん様々な選択肢があるとは思いますが。

そんなことをぼんやりと考えながら、Qiitaに学習メモを書いていってます。
あくまで自分の気になった部分だけなので学習コンテンツとはならないですが。

Keychron K8バッテリー交換

メルカリで中古で購入した私にとって初めてのメカニカルキーボードであるKeychron K8。
最近は赤ランプがすぐに点灯したり、充電中に緑・黄で点滅したり、緑・赤で点滅したりとよくわからない状態になってました。

色々な色で点滅する理由はさっぱりですが、少なくとも赤ランプがすぐに点灯してしまうことに関してはバッテリー問題であろうと。
調べてみると、自力で交換ということも出来なくないようなのでやってみることにしました。

必要となる資材

肝心のバッテリーはAliExpressで購入しました

3.7V 4000mAh 14.8Wh 606090 リチウムポリマーリチウムリポバッテリー JST-PH 2.0 ミリメートル 2Pin コネクタ GPS Bluetooth スピーカー電源銀行タブレット PC – AliExpress 44

それ以外は、バッテリーを固定させるための両面テープと、ネジを外すためのドライバーくらいです。

作業するよ

まずはキーキャップを外します。
購入後、一度もキーキャップを外したことがなかったのでひどいホコリやゴミが。。
ちょっと写真で映すわけには行かないレベルでした

キーボードの基盤を固定しているネジを外していきます

ネジを外したら、基盤を台座から外します。
この外し方がわからずにちょっと苦労しましたが、冷凍庫の製氷器から氷を取り出すように少し台座を歪めるような形にすると外れました。

バッテリーのプラグを基盤から外して、粘着テープでガッツリと固定されたバッテリーを台座から外します。
かなりしっかりと固定されているので結構力が必要でした。

右が古いバッテリー。
パンパンに膨らんでいるわけではないですが、新しいものと比べると膨らんでいるのがわかります。
パンパンになっていないことを考えると、以前の持ち主はそこまで利用せずに、バッテリーが逆に使っていないことで悪くなってしまった。。とかなのでしょうか。
ちょっと不調子な原因はわかりませんね

新しいバッテリーを両面テープで固定して組み上げていきます

無事に使えるようになりました。

まだ1日くらいしか経っていませんが、特に問題なく使えていますしバッテリーの持ちとしても改善されたと思います。

そして何よりも、きれいになりました!
どうしてもホコリやゴミが見えていたのが気になっていたのですが、すごいきれいになったので気持ちいいです。

たまには掃除するものですね
良かった良かった

codespacesに繋がらない

AIエージェント開発のハンズオンをやっていたのですが、細切れで作業をしているもので毎回コードスペースが停止してしまいます。

毎度のことなので、Restartして使っているのですが・・・

ずっとStarting codespaceのままで動かない

そして最終的には停止してしまい、接続できなくなってしまいました。

その時のステータスとしてはActiveになっているので起動はちゃんと出来ていると思うのです。
直前にプラグインをインストールしたのが気になるところです

codespacesには、ブラウザ上で動かすだけでなくVSCodeで動かすオプションもあるので、試しにそちらで呼び出してみたのですが・・・

エラー。
409が出ており、リソースの競合がおきている??そんな複数のウィンドウでつなげるようなことはしていないのですが。。。
何でしょう。

結局原因がわからず、ハンズオンの環境に時間をかけてもしょうがないので新規にスペースを立ち上げて接続ができることを確認。
つまりはネットワーク的には問題ないということまでは確定だと思うのですよね。

codespaces側で何かしらエラーがおきていないかを確認することができればもう少し原因究明できそうなものですが。
ハンズオンの内容的に、すべての内容をGithubへコミットしていなかっただけにちょっと残念な気分ではありましたが、まぁハンズオンですしね。

もやもやはしますが、気を取り直して進めたいと思います。

microCMSを触ってみよう

Qiitaのアドベントカレンダーを眺めていて、microCMSというものの存在を知った。
日本製のヘッドレスCMSということで、これまであまりヘッドレスCMSに触ってみてこなかったのでちょっといじってみることに

microCMS|APIベースの日本製ヘッドレスCMS

無料で利用ができるのはいいところ。登録にクレジットカードも一旦不要だ。

始めの選択肢としては、テンプレートからの作成か、1からか。

”1から”を選択すると、サービス名とサービスIDの入力が始まる
あとから変更可能ということなので、適当に入力する

まさかのサービスができてしまった

ここからはサービス内のAPIを作っていく形のようだ。

ここで料金プランをチェックしてみる。

料金プラン|microCMS|APIベースの日本製ヘッドレスCMS

無料プラン名としては”Hobby”で、ここではAPIの呼び出しはなんと無料でOK。ただし、APIの数は5個という制限が生じてしまう。

このあたりは何を作るのか次第なのだけれど、APIをあまり細かい単位で作ってしまうとすぐに制限に引っかかってしまうので注意が必要そう。

それ以外にもプランによる制限はいくつかあって、コンテンツ数あたりがネックになりそうな気はする。
ただ、ちょっとしたAPIを作る分には1万件あれば足りるのではないかと思う。
作りたいもの次第ですね。ここは。

APIの作成

APIを試しに作ってみる

ランニングのデータを想定して、一旦アクティビティを管理するAPIを作ってみることに。

JSON配列にするかオブジェクトにするか。
アクティビティにラップのような子要素を追加するのであればオブジェクト形式一択。
ただ、先の1万件制限がどういう単位でカウントされるのかが正直わからない。

一旦、Garminのデータを取り込むことを考えてオブジェクト形式としてみる

続いてAPIスキーマの定義。
このあたりは、OpenAPIのフォーマットを取り込めたりしないのだろうか?
ファイルインポートで指定しようとしたけれどうまく行かなかった。
後でフォーマットを確認する必要がありそう

手入力で進めると、データ入力画面になった。
サンプルデータを入力しておく

無事に取得することができた。

ひとまず、なんとなくサービスの土台を作ることができそうな雰囲気は感じることができた。
どうしてもこれまでCMSというとブログ作成ツールのイメージがあったけれど、その名の通りコンテンツを管理するシステムなわけで、ヘッドレスの場合はなおさらその意味合いが強く出てくる形なんだろう。

軽く触った程度だけど、もう少し手作業による構築をなくしたいところ。
API構築をファイルインポートによって行う手順はこのあと確認することにしよう。

面白いおもちゃを作ることができないだろうか

管理職が技術を学習する意義はあるか

予感というか、確定事項というか。。。仕事が忙しくなりそうな気配がしてきています。

どこまで自分が関わるかはわからないですが、Flutterを使うことになりそうなので慌ててdartを少し触り始めています。
メインの開発者になることはないので、触ったからと行って何が変わるというものではないのですが、こういうときに最初に触ろうとしてしまうんですよね。

何かしらやったことがない技術に関連した案件に携わるときに、自分の立場でいうとどうしても管理面で少し関わるようなレベル。
実際のプロジェクトにどっぷりと。しかもコーディングをする立場で関わるということから離れて随分と経ってしまいました。

ここ数年でも、ありがたいことにそういう機会にいくつか巡り合ったのですが、最初に少しチュートリアル的に触っただけであとは設計書周りと格闘したり、プロジェクト進行や管理周りで関わる程度が続いてしまっており、技術に対しての習得というレベルにいずれも達していません。

そもそも、そういう立場なので習得すること自体が本当に意味のある行為なのかどうか。
管理であるなら管理方面の手法などに時間を割いたほうがより生産的なのではないだろうか?は常につきまとう問題です。

このあたりが管理職になりきれてない面なのかもしれないと思いつつ、やっぱり抗いたい部分でもあるのですよね。
ただ、悲しいことに。残念なことに私はそちら方面の才は持っておらず、抗ったところでという結末を迎えやすいのが実情。
中途半端ではあります。

とはいえ、やはり抗いたい。
抗いたいのです。

これまでがだめだったからと言って、諦めるほどだめにはなっていないはずと信じながら。
抗うのです。

keychronの調子が悪い

自宅ではメルカリで仕入れたKeychronのK8をキーボードとしては使っているのですが、最近バッテリー充電していると、赤と緑ランプが交互に点滅します。

その後使っていると、すぐに赤ランプが点滅してバッテリー残量が少ないことを伝えてくるのでおそらくバッテリーがだめになっている可能性がありそうです。
ちなみに、工場出荷時に戻すという方法を取ってみたけれど効果はありませんでした。

さて、このバッテリー。
どうしたものかと調べてみたら、一応自分でもできそうでした

Keychronキーボードのバッテリー交換ガイド|NORILOG(ノリログ)

というわけで、早速精密ドライバーとバッテリーをぽちっと。

届くのは少し先になりそうですが楽しみです

Snowflake World Tour Tokyo に行ってきた

9/11, 12の日程で行われたSnowflake World Tour Tokyoに行ってきた。
本当は2日とも参加するつもりではあったけれど、業務の都合で初日だけ。。。

Snowflakeはだいぶ知名度が上がってきたけれど、最初に私が知ったのは3年ほど前。
案件で使う話があって、話を聞いたり調べたりもした。

ただ、最終的に紆余曲折の末、案件自体を離れることになったので実際に使うところまでいかなかったんですよね。
今回、また機会あってSnowflakeを使った案件に首突っ込むことになって、カンファレンスがあるということでせっかくなので参加してみた形です。

データウェアハウスやデータレイクの領域は、アプリケーションに携わっていることがメインの今の立ち位置だとなかなか馴染みが薄く、話を聞く中で知らない単語や新しい知識が多く色々と刺激をいただきました。

純粋に楽しかった。

ただ、これこの先どうだろうな~と思うと、正直どうなんだろう?と思ってしまうのも事実なんですよね。

streamlitを用いることで手軽に社内に対して情報を展開することができるというのはわかるのだけれど、自社でそういうことをやるのはわかれど、案件でとなるとDWHの導入プロジェクトとかそういうものになりそうな気がしてならない。

それか、やはりこれらデータを用いたAIか。

いずれにしても、せっかく参加したこの機会を利用して、色々と聞いてきた話をまとめて振り返っていかないとな、と思った次第です。

甦れ!アンパンマン

上の子が小さい頃に買ったアンパンマンのおもちゃがずっとしまってあったのですが、次女が最近アンパンマンを好きになっているので取り出してみました。

セガフェイブ(SEGA FAVE) アンパンマン かまどでぷく~ ジャムおじさんのやきたてパン工場
https://amzn.to/4gfe6cK

今はすでに販売中止になっていて、後継のおもちゃが出ているようですね。

喋らない

電源をONにしてみても、なんの反応もありません。
電池を見てみると。。。

やはり緑錆にやられてしまっていました。。。

うーん、遊んでなかったおもちゃあるあるですね。。。
これどうしたものなんだろう?と調べてみると、緑錆にはKURE5-56ではなくKURE2-26なるものがあると!

KURE(呉工業) 2-26 180ml 電気装置用防錆・接点復活剤 1020

買いました

緑錆に効くというよりは、電源などの接点を復活させることができるとのことで、綿棒使ってお掃除してみました。

続・喋らない

それでも音は鳴りませんでした。

うーん、接点がだめだったのか、それとも接点以外の問題があるのか・・・
とりあえず、中を開けてみることにします

ちょっと画像からは分かりづらいですが、下部の電源から伸びている金属が緑錆でやられていて。。。あれ、右下何もつながっていない??

そして、一本、配線がプラプラしている。。。

つまり、緑錆などで傷んでしまって配線が切れてしまったということなんですかね?
これを接合してあげれば復活しそうな気がしてきます。

接合といえばはんだごてですよ

はんだごて

買いました。

Lesimoll はんだごて ハンダゴテ 14-in-1はんだごてセット 溶接工具 精密半田ごて 電気ハンダゴテ 60W/110V 温度調節可能(200~480℃) 5つ無酸素銅こて先 50g高純度はんだ ON/OFFスイッチ付き 半田吸取器 日本語取扱説明書付き...

比較的お値段が手頃なものを。。。
なんか色々と付いてきていますが、例のごとく使いこなせる気はしません。
シンプルに接合できればよいと。

復活!!

「焼き立て!かまどでパン屋さん!」とアンパンマンが喋ってくれました!

喜びのあまり妻に経緯を説明したら、「買ったほうが安く上がったのでは・・・?」など冷たい言葉を浴びせかけられましたが、それでは面白くないじゃないですか。

一体、ハンダゴテなんていつ以来だろう。。。もはや思い出すことができませんね。
大学時代に溶接ならガスもアークもやりましたが。。。

いやー、楽しかったです