Microsoftアカウントでログインするとユーザー名を雑に決められてしまう。よく見る対処法は↓のような感じだったので後者をやった。
もちろんユーザーディレクトリ名を気にしない限りはどうでもいい
随時追記
プライベートでいろいろする余裕ができそうだったのに個人開発他で使ってたMac miniが逝った
↩長いこと使ってなかったMac mini、HDMIポートがあかんかもしれん pic.twitter.com/280KFGOluF
— wifeofvillon (@wifeofvillon) 2021年5月28日
現在ブラウザ上で開いているTrelloボードの、特定カラム上にあるカードのタイトルとURLを取得するJavaScriptコード。Consoleで使う。
パフォーマンスとか難しいことをできるだけ考えない。
以前似たようなことをしたときのコード↓
現在の職場のミーティングは9割がGoogle Hangoutsで残りがZoomって感じなんだけど、家のMac miniにはカメラがついていないので3Dの美少女に口パクしてもらいたいなと思って試した。
結論から言うと、以下のことが確認できた/できていない。
まずかぶりたい美少女・美少年を用意する。Androidアプリのカスタムキャストはゲストモードでも(実際に配信しなくても)自分の声に合わせて口パクしてくれる。
キャラクターを作成したら[配信]>[キャラクター選択]>[背景選択]>[リップシンク設定]>[フリック設定]……で3Dキャラ+背景の状態にできる。
MacとAndroid端末にそれぞれApowerMirrorのアプリをインストールする。
Android端末をUSBでMacに接続してそれぞれでApowerMirrorを起動する。
Google Hangoutsには画面共有機能があるので「画面を共有」とか「Presentation」みたいなメニューからApowerMirrorのウィンドウを選ぶ。
自分が資料を共有したいときは共有するウィンドウを切り替える。他の人が資料を共有しているときはそのプレゼンテーションにピンを打てばいいと思う(未確認)。
1対1の場合はこれで良さそう。3人に増えた状態を確認したかったけどできてない。
ミラーリング画面をいい感じに切り取るにはOBS Studioを使うのが主流っぽい気がした。
これをGoogle Hangoutsのカメラとして認識させられれば最高なんだけどできてない。
OBS VirtualCamというプラグインでできそうなんだけどOBSのフォーラムにあるのはWindows版だけっぽい。
ApowerMirrorはAndroid端末の画面をそのままミラーリングしている(PC上で操作もできる)。そのため通知がくると普通に表示されてしまう。事故を絶対に避けたいなら通知領域が見えないように切り取ったりした方がいいと思う。
あとUSB接続の場合は↓こういうケーブルを繋いだまま立てておけるスタンドがあると便利そう。
VUIに対応しているアプリケーションで、自分が発音できない言語で動作確認をするとき、方法はいろいろあるんだけどGoogle翻訳は間違いなく便利。
スクショで言うと右ペインのスピーカーアイコンをクリックすると「こんにちは」って読み上げてくれる。
このページはGETパラメータを直で入力すればそれに応じた文言・言語で表示してくれる。「フランス語とドイツ語とマンダリンとヒンディー語でそれぞれ"Hello"に相当する言葉を発音して欲しい」みたいなシチュエーションに陥ったときに便利だったのでメモする。
上のスクショは下のURLで再現できる。
https://translate.google.com/?hl=ja#view=home&op=translate&sl=en&tl=ja&text=Hello
| key | value | sample |
|---|---|---|
| sl | 翻訳元の言語 | en |
| tl | 翻訳する言語 | ja |
| text | 翻訳する文字列 | Hello |
ブラウザで一言二言発音が聞きたいみたいな用途ならこれで十分だと思う。
このエントリは次の項目の個人的なまとめ
新しい端末を使い始めるときは最低限のデータしか引き継ぎたくないマンなので白紙から始める前提
$ cd ~
$ mkdir GitHub
$ cd GitHub
$ git version
# agree to the Xcode license
$ sudo xcodebuild -license
[Password:
agree
$ git version
# Settings
$ git config --list
$ git config --global user.name "${ユーザー名}"
$ git config --global user.email "${メールアドレス}"
# create `.netrc`
$ vim ~/.netrc
.netrcの内容machine github.com
login ${ユーザー名}
password ${personal_access_token}
protocol https
Touch Barの指紋認証便利だけどESCをッターン！できないのが悲しい
今週のお題「2019年買ってよかったもの」
NOTE: 商品紹介にAmazonアソシエイトを使っています
この前のサイバーマンデーでAmazon Echo Show 5を買ってリビングと自室の家電操作系統を変更したらよかったのでメモする。
サイバーマンデー以前は以下の通り
| 機器 | 役割 |
|---|---|
| Amazon Echo Dot 1 | 音声操作 |
| Nature Remo | 赤外線リモコンハブ・温湿度照度計 |
| エアコン(富士通) | 一般的な家庭用エアコン |
シーリングライトが2箇所あって片方はリモコン操作できるようになっていたんだけどLED電球に変えたらリモコン操作を受け付けなくなった。
Echo Dot (エコードット)第3世代 - スマートスピーカー with Alexa、ヘザーグレー
Nature スマートリモコン Nature Remo Remo-1W2（2nd Generation）
MEMO: 生活時間が3〜4時間ずれているので夫婦別室です
| 機器 | 役割 |
|---|---|
| SwitchBot Hub | 赤外線リモコンハブ |
| SwitchBot | 壁スイッチ物理操作 |
| SwitchBot 温湿度計 | 温湿度計 |
| エアコン(Panasonic) | 一般的な家庭用エアコン |
SwitchBot スイッチボット スマートホーム 学習リモコン グーグルホーム Alexa -IFTTT イフト Siriに対応 SwitchBot Hub Plus
部屋の中央にシーリングライトがあるんだけど引っ張って点灯・消灯するための紐がないのでSwitchBotでスマホで壁スイッチを操作するようにしたら色々と増えた。
別に全部スマホ(Android)か古いKindleの画面でも操作できるんだけどそのためにアプリを切り替えるの面倒だな〜と思ったり真っ暗な中で機器操作するのにスマホのスクリーンロック解除してSwitchBot/Hubの疎通待って……っていうのがVUIに慣れるとすごくだるい(し目が痛い)ので音声操作にしたいな〜と思ったりしていた。
ニュースが普通に映像も流れるのがいい。画質はいいけど音質はちょっと微妙。
ランダムで使い方を提案してくるので(例: 「〜と言ってみてください」)文字が読めるようになったお子様は楽しいと思う。
スキル開発者目線で言うと画面がついていると音声コマンド入力のどこで失敗したのかわかるのがいい。
Echo Show 5 (エコーショー5) スクリーン付きスマートスピーカー with Alexa、チャコール
リビングにEcho Showを置いて自室にEcho Dotを移動した。
Echo Showが届いたので自分の部屋とリビングが音声操作可能になった 夫の部屋は知らん pic.twitter.com/2xnFINbCrL
— wifeofvillon (@wifeofvillon) 2019年12月7日
| 機器 | 役割 |
|---|---|
| Amazon Echo Show 5 | 音声操作 |
| Nature Remo | 赤外線リモコンハブ・温湿度照度計 |
| エアコン(富士通) | 一般的な家庭用エアコン |
自室2.0 pic.twitter.com/yPWzF2VFWg
— wifeofvillon (@wifeofvillon) 2019年12月13日
| 機器 | 役割 |
|---|---|
| Amazon Echo Dot | 音声操作 |
| SwitchBot Hub | 赤外線リモコンハブ |
| SwitchBot | 壁スイッチ物理操作 |
| SwitchBot 温湿度計 | 温湿度計 |
| エアコン(Panasonic) | 一般的な家庭用エアコン |
もともとベッドがヘッドボードにコンセント2口とLEDライトがついているやつだったんだけど、Echo Dotのためにベッド後ろに余っていた延長コードを引いたので快適になった。
あとちょっと前にスマホ・タブレット用のアームをヘッドボードに設置していたので充電しながらゲームしながらアプリを切り替えることなくエアコンと壁スイッチを操作できるようになった。超便利だけど人間としてあかん気がする1。
リビングと自室のエアコンは同じAmazonアカウントでコントロールされるけど、「エアコン消して」だとリビングのエアコンが消える。これを避けるために「<室名><機器名>」が推奨されるけどうちは寝室がふたつある。
「なまくびのエアコン消して」に設定していたらAlexaは音声を「生首」と解釈するので期待通りの動作をしない。かといって「生首のエアコン」とアプリ上で表示されるのは可愛くないので今のところ「寝室エアコン」にしている。
が、夫がSwitchBot Hub miniを買うつもりらしいのでさらなる混乱が見込まれる。
SwitchBot スイッチボット スマートホーム 学習リモコン Alexa - Google Home IFTTT イフト Siriに対応 SwitchBot Hub Mini
テレビ・エアコン・照明全部赤外線リモコンで操作できるご家庭ならNature Remo1台でいいんじゃないかなと思う。アプリはこっちのほうが見やすいしわかりやすい。
物理スイッチが多くて配線を自分の意思で変更しにくい古めの賃貸の場合、SwitchBotは結構いいんじゃないかと思う。タイマーのついていないコーヒーメーカーも立派なスマート家電になる。
ただSwitchBotは物理スイッチをアームと強力両面テープで押したり引っ張ったりする仕様上スイッチカバーが外れる事故はあるので多分あまり軽い機器には向いていない。
個人的にはSwitchBotの加湿器とカーテンユニットもほしい。
SwitchBot Wi-Fi スマート加湿器 3.5L 大容量 除菌 アロマディフューザー 超音波式 アレクサ、Google Home、HomePod、IFTTT に対応
これはソフトウェアテスト Advent Calendar 2019 - Qiita 4日目のエントリです。
@wifeofvillonです。Drivemodeという会社で自社プロダクトのE2Eテストを主業務としており、最近はいい感じのテストマネジメントを模索しています。 このエントリでは現在進行形で体験・実行している「開発タスクマネジメントにQAチームとして便乗するための取り組み」について書きます。
現在Drivemodeとは別のアプリの開発プロジェクトが走っています1。
ほとんど総力戦のような状態になっているため、既に開発に組み込まれていたメンバーとは別にCertified Scrum Professional®を取得しているメンバーが開発タスクのマネジメントをしてくれる体制になりました。とはいえ要件が決まりきらない箇所が多く、きっちりスプリント計画を立てるのが難しいため、小規模なウォーターフォール開発にアジャイル開発のプラクティスを持ち込んだような変則的な運用になっています。
この体制の中にQAチームもまぎれ込んで、同時にマネジメントしてもらうための取り組みを行いました。今回はその泥臭い取り組みの内容を撮って出し2で書きます。
前提として、今回の開発タスク管理フローは以下のようになっています。
カンバンのカラムは以下のようになっています。
各Issueは開発状況に応じたカラムに開発者によって移動されますが、デザイナーの作業が必要であったり、コンポーネントテストのダブルチェックが必要であったりする場合にはそれぞれ「needs UX design」「ready for QA」のラベルを付けます。
基本的にコンポーネント開発のIssueはダブルチェックを経て完了扱いになります3。
また、カンバン上のカードタイトル＝Issueタイトル内に(相対)作業見積が記載されています。開発者同士のプランニングポーカーで算出されたもので、これを元にGoogleスプレッドシートでリリースまでのバーンダウンチャートを作成しています4。
前項をふまえQA側は、QAのタスクを開発タスクと同じカンバン上で管理できるようにしました。
タスク分解はまず「要件把握」「テスト仕様書作成」「コンポーネントテスト実行」「統合テスト実行」に分け、そこから機能単位で子Issueを切り出しました。(コンポーネントテスト実行は開発Issueのダブルチェックがそれに当たるので自分では切り出していません。)
作業見積も開発者がプランニングポーカーを用いた相対見積をしていることに合わせてフィボナッチ数の相対見積にしました。自分で切り出したIssueに関しては開発Issue同様タイトル部分に、開発Issueに関してはテスト仕様書・報告書へのリンクの横に記載しました。
今回開発者と一緒に管理されたかった理由の一部として
という気持ちがあったので、開発者がデザイナー・QAに対してそうしているように、開発者のレビューが必要だと感じたIssueに「needs Developers eyes」のラベルをつけるようにしました。
作業見積を元にGoogleスプレッドシートでバーンダウンチャートを作成するところは開発タスクと同じですが、現状では別シートに分けています。
本来は作業見積は開発者と一緒にやれることが理想ですし、実際プランニングポーカーの場にも呼んでもらいました。しかし、開発IssueがQAの作業単位より細かく切り出されていたこと、その時点ではプロジェクトの概要把握もおぼつかず基準として提示されたIssueについて作業量をイメージできていなかったこと5から、作業見積はひととおりのQAタスクをIssueに切り出してからひとりで行いました。
開発IssueがQAの作業単位より細かく切り出されていたというのは、例えば電話の待ち受けモードを変更する機能があったとすると、開発は「電話の着信を無視する」「着信を知らせる」という粒度まで分解されています。これについては別に何もおかしくはないのですが、統合テストで使えるテスト仕様書を作る(そしてテストを実施する)ことをゴールとしているQAの場合、電話の待ち受けモード全体をひとつのタスクにしたほうが条件組み合わせによる結果の違いがわかりやすく、テスト仕様書が書きやすくなると感じました。
バーンダウンチャートも開発・QAをまとめてプロジェクト全体で1枚にできると美しいと思うのですが、今回は作業見積自体別々に行ったのでそれぞれ別シートで管理しています。
プロジェクト運用に口と手を出したことによって、既存プロジェクトではTrelloでやっていたこととほぼ同じことをGitHub Projectsでもやれるようになったので、私の作業負担が大きくなったとは感じません。
むしろ私が何をどんなペースでやっているかが他のメンバーから見えやすくなったことにより、安心感が得られ、進捗を出していくぞ！という緊張感が生まれてよかったと思います。
あと、これはいいことだとは言い切れないのですが、作業負担が大きくならなかった理由として、テスト仕様書を書くのもダブルチェックを実行するのも全部自分なので作業見積やIssueの書き方に迷いがないというものがあります。
ここで例えば新しくメンバーを追加してテスト仕様書作成を分担したり、テスト実行を任せたりする場合は別途QAチーム内で作業見積をする必要がある6でしょうし、GitHub Actionsというかカンバン系式に慣れていない人と一緒に作業する場合はそのサポートも作業のうちに入ってくるのでこれこの短期間に限ってはひとりでよかったなと思います7。
次のリリースでは理想にもう少し近づけるといいですね……
今回の取り組みはあくまで開発者主体のプロジェクトで自分も心理的に楽になるためのものなので、どこのチーム・どこのプロジェクトにも普遍的にあるであろう
という問題が解決されるわけではないです。
この運用にしてから最初のリリースはまだ終わっていません(12/4現在)。なので、実際にどうなったか知りたい人は飲み会とかで訊いてください。
ソフトウェアテストの小ネタ Advent Calendar 2019ではもっと気楽なことを書くと思います
新規アプリの開発は私がチームに加わってからも、手堅いものからチャレンジングなものまで何度かありました。その度に副産物として開発・QA体制がブラッシュアップされてきたように思います。↩
まさか本当に撮って出しになるとは先月の時点では想定していなかった……↩
余談ですが、Pull RequestがmergeされるとGitHub ActionsでCIが実行され、Firebase App Distributionで新しいリビジョンが各試験端末に配布されるようになっており、これを用いてダブルチェックを行います。↩
どうしてこういう体制になったかを書き始めると脱線するのでここでは書きません。このタスクマネジメントの話は@KAKKA_Blogがいつか書いてくれるかもしれません。知らんけど。↩
これは完全に私の落ち度↩
そして作業見積についても学習してもらう必要がある可能性がある↩
今後についてはその限りではない。私よりつよいQAエンジニアがハンドリングしてくれないかな〜とはずっと思っている↩
