デフォルトだとこんな感じのバインドになってる
| 中クリック | 戻る |
|---|---|
| 左クリック | 右クリック |
左上を戻る、右上を中クリックにしたい
xinput listで接続しているデバイスの情報が取れる
$ xinput list
⎡ Virtual core pointer id=2 [master pointer (3)]
⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)]
⎜ ↳ Kensington Kensington Slimblade Trackball id=10 [slave pointer (2)]
⎣ Virtual core keyboard id=3 [master keyboard (2)]
↳ Virtual core XTEST keyboard id=5 [slave keyboard (3)]
↳ Power Button id=6 [slave keyboard (3)]
↳ Video Bus id=7 [slave keyboard (3)]
↳ Power Button id=8 [slave keyboard (3)]
↳ foostan Corne Keyboard Rev.1 (Split Common) id=9 [slave keyboard (3)]
Kensington Kensington Slimblade Trackball id=10 [slave pointer (2)]
こいつ
xinput get-button-map {device_id}で取れる
$ xinput get-button-map 10 1 2 3 4 5 6 7 8
とりあえずなんか1~8まであることがわかる
xevを起動して表示されるウィンドウ内でそれぞれのスイッチを押してみる
ButtonPress event, serial 37, synthetic NO, window 0x3c00001,
root 0x50f, subw 0x0, time 1223890, (154,31), root:(212,500),
state 0x0, button 1, same_screen YES
左下をスイッチを押した場合こんな感じで出力される
button 1 の数字の部分が先程確認した1~8のいずれかに対応している
自分の環境だとこんな感じだった
| 中クリック(2) | 戻る(8) |
|---|---|
| 左クリック(1) | 右クリック(3) |
xinput set-button-map 10 1 8 3 4 5 6 7 2
を実行する
xinput get-button-mapで取得した際の数値を並び替えて実行するだけ
before: 1 2 3 4 5 6 7 8
after : 1 8 3 4 5 6 7 2
これでバインドが変更される
設定ファイルがあると思うが面倒くさかったのでスクリプトを書いて対応
#!/bin/bash
DEVICE_ID=`xinput list | grep "Kensington" | awk '{print $7}' | cut -c 4-`
xinput set-button-map ${DEVICE_ID} 1 8 3 4 5 6 7 2
これを適当な場所に保存、実行権限を与えておいて自動起動するようにする
Ubuntu 21.10だと上手く行きませんでした(Waylandだから？)
なのでこれ使ってます。GUIってありがたいネ
$ lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 20.04.3 LTS Release: 20.04 Codename: focal
Mozc+自作キーボード(Corne Chocolate)を使用していて、F13にIMEオフ/F14にIMEオンを設定しているんですが
F13を押すとUbuntuの設定が起動してしまうのを何とかしたい
F13がXF86Toolsを送るようになっていているのが原因っぽい
$ sudo apt install dconf-editor $ dconf-editor
dconf-editorをインストールして起動、control-center-staticで検索し以下の設定にする
['']
やけに音がビビるなと思って島村楽器で見てもらったら、ボディ側の弦高が1.3mmしか無くてリペアマンがたまげてました
トップ板が膨らんでしまったのが原因とのこと。無念。
湿度気にしたり、弾かないときは弦を緩めたりしてたのにセール品とは言えまさか1年持たないとは…
修理するにしても2万以上かかるし、様々な調整が必要で今後また発症しないとも限らないとのこと
次の引越し先の防音性が今の家ぐらい良いとも限らないのでサイレントギター買いました
ボディない分の薄さやイヤホンから聴こえる音とか色々慣れないけど今の所悪くない感じ
こいつは5年ぐらい元気でいてくれると信じてます
ここ数年たくさんレビューする機会に恵まれ、より良いレビューとは何かを考えていたのでまとめてみた
大きく分けて以下3点
このあたりは必ずレビューする必要があり、基本的には機械的なチェックが行えず人力でチェックする必要がある
チェック項目の中でも以下のように分けることが出来て、必要な技量がそれぞれ異なる
技術力が高い=適切なレビュー指摘が出来るとはならないのが難しいところで、技術と業務知識が合わさって初めて適切なレビューが行えると考えている
だからと言って業務知識がまだ少ないからレビューは避けよう…というのは誤りで、むしろ知識が少ないうちにたくさんレビューは行ったほうが良い
業務知識があるメンバー同士だと暗黙知によるレビュー漏れや、潜在的な問題を後回しにするといった問題が起きる可能性もあるので
業務知識がない新規メンバーから見たフレッシュな観点でレビューするのがとても大切(レビュー指摘ではなく質問だけでも良い)
早いうちからレビューを行うことで以下のようなメリットが有る
レビュー経験自体が無く手も足も出ない場合は以下のような手法をとっても良い
キッカケさえあればその後は段々レビューが出来るようになるはずなので、まずは簡単なところから始めるのが良いはず
素敵なコードに対して:cool:とか:+1:とかつけるだけでも十分価値があるので、どんどんつけていくと良いと思う
→:cool:貰えた側も嬉しいし良い事尽くし。出来る人のコードって段々褒められなくなるし褒めていきたい
どんな開発手法でも大体は一人のメンバーに対してタスクがアサインされるので、その時点で属人性が高まってしまう
大きめのタスクであれば更に細分化し複数人で分担する事で属人性が減らせるが、それでも担当箇所はどうしても属人性が高まる
属人性が高いと急な事故や病気で担当者が作業できなくなった場合、引き継ぎが難しくなるという大きなリスクを抱えることになる
※無理に属人化を避けようとすると、個人がコードを書かないように自動生成ですべて行えるようにして…等、逆に開発効率が落ちるようなケースもあるので、必ずしも属人化が悪いというわけではない
属人性の排除において特に有効なのがコードレビューだと思う
実装内容自体はVCSで管理していたらコミット履歴やPRから把握することは出来るが、実装時の思想や意図を確認するのはレビューのタイミングしかない
レビューで思想や意図を把握しておくことで、今後その箇所を触るときに元の設計を壊さないようにしたり、もし問題があれば修正を行うことも容易になる
把握していないと修正して良いのかわからず、怖いから一旦そのままに…でどんどん技術的負債が溜まっていく事が多々ある
まず、これは人それぞれな部分ではあるが、目的もなくただ技術の勉強をするより目的を持って技術の勉強を行ったほうが効率よく学習が行えると考えている
(技術書読むだけで全部わかる人は考慮しない)
レビューは技術力の向上においてはベストな場所で、効率の良い学習が行える以下の条件が揃っている
単に勉強しろと言われてもまず何からやるべきか…と詰まってしまうが、レビューは上記条件があるのでまず詰まることはない(レビューの仕方がわからない等は除く)
マージするために必ず答えが導き出されるので終わりが無いということもない
レビュアーは質問を行ったりコードを読むことで技術力が向上し、レビュイーは質問に回答することで技術力の向上がする
特に問題なければ質問自体が生まれないが、コードを読むだけでも技術力が向上するので問題ない
色々考えを書いたが、ではレビューは誰が行うべきなのか？
個人的にはチームメンバー全員がすべきだと思っている
大体のプロジェクトだとレビューを行う人/行わない人は以下だと思う
当然コードを読める人がレビューしたほうが早いし、より適切なレビューを出来るので間違っていないと思う
しかし開発者だけがレビューすると、開発独自の目線でしか見ることが出来ず、コードのみの品質が向上しソフトウェアの品質は横ばい(最悪の場合低下)する可能性があると考えている
行わない人それぞれがレビューした場合に生まれるメリット
大体はタスク管理、進捗管理を行いユーザとのやり取りを行うのみ
仮にレビューを行った場合以下のメリットが考えられる
開発を滞りなく進め、ソフトウェアの完成が成果となる管理者ではつい進捗のみに目を向けがちだが
レビューを行うことでより詳細な進捗を把握できることになり、適切な納期提案やユーザとの相談が行える様になると思う
一部のエンジニアは「コードを書けない人は信用しない」と言う考えを持つエンジニアもいるため、その層に対しても
「書けない(時間がない)が、レビューで貢献して成長しようとしている」という姿を見せることで、リーダーの役割に対して理解を得られる可能性もあると思う
大体は実装自体は行わず、品質の向上のためにテストケースの作成やテストの実施するのみ
仮にレビューを行った場合以下のメリットが考えられる
責務的にレビューは行わないことがほとんどだと思うが、レビューすることでソフトウェア自体の品質向上に大きく効果があると思う
特にやり取りをスムーズに行える点がかなり有効で、おそらくこのあたりでしょうか？とコードベースで話すことでかなり修正が行いやすくなるはず
開発者としても実装仕様を理解しているテスターだとやりやすいので、開発とテスター間で信頼が生まれると思う
レビュー自体はコードを一行も生み出さないので開発スピードが低下するイメージもあるが、バグを防いだり技術力の向上が見込めたりで実装する以上のメリットがあるのでどんどん行うべきだと思う
みんな大好きt_wadaさんもテストコードを書かないと最初は開発スピード上がるけど、時間が経てば経つほど修正が難しくなって開発スピードが落ちていく、という話をしていたので似たような物だと考えている
レビュー自体が無いPJでも自分からレビューの基盤を整えてレビュー環境を作っていくのは誰でも出来るので、積極的にアプローチすると:cool:
🐊個人的な話🐊
レビューめっちゃ好きなんすけど、経験則でずっとレビューしてきたので体系的にレビューを学べる本とかあれば教えて下さい
考え方とかレビューの勘所とか何でも知りたいです。押忍。
Win+Shift+Sで起動する画面範囲キャプチャが時々機能しなくなる
前回起動したキャプチャのプロセスが生きているのが原因っぽいので、タスクマネージャーからプロセスをKillするとショートカットが機能するようになる
画面の領域の切り取り->ScreenClippingHost.exeをKill
ただこれだけだとプレビューが動かないケースがあるので、通知周りで何かあるかもしれない
ご存じの方助けてください
Controller -> Service -> ORMみたいなアプリケーションの場合
ServiceでORMとか依存するクラスをDIでモック出来るように作ると思うんだけど、前しょーもないミスをした
ORM
<?php class UserOrm { { // DBからUserデータとってくる public function fetchUser(int $user_id): User { DB::selectQuery->where('user_id' , $user_id)->fetch(); } }
Service
<?php class UserService { // DI出来るようにしてる private UserOrm $user_orm; public function __construct(UserOrm $user_orm) { $this->$user_orm = $user_orm; } public function fetchUserAge(int $user_id):int { $user = $user_orm->fetchUser($user_id); return $user->getAge(); } }
Controller
<?php class UserController { // 叩かれたらAgeをレスポンスとして返す public function userAgeApi(int $user_id): Response { // newしたりDIコンテナからとったり $user_orm = new UserOrm(); return (new UserService($user_orm))->fetchUserAge($user_id)->getAge(); } }
よくあるMVC
これのテストコード書くときにやらかした
<?php public function testFetchUser() { $age = 20; $user_id = 1; // Userを返すモック $user = new User($user_id); $user->setAge($age); $user_orm = Mockery::mock(UserOrm::class); $user_orm->shouldReceive('fetchUser') ->once() ->with($age) ->andReturn($user); // 期待するAgeが取得できる $actual = (new UserService($user_orm))->fetchUser($user_id); $this->assertSame($age, $actual->getAge()); }
これテストも通るし、パッと見問題ないんだけどControllerからモックを使用せずにテストケース書いた際に死ぬ(事に後々気づく)
ORM
<?php class UserOrm { { // DBからUserデータとってくる public function fetchUser(int $user_id): User { // ここでreturnしてない DB::selectQuery->where('user_id' , $user_id)->fetch(); } }
ORMから何も返してないので当然Ageが取れずに死ぬ
というかそもそも返り値型と一致してなくて死ぬ
みたいなこと考えたんだけど、節穴なのでIDEの警告は見落とすし
Service層で作り固めて最後にControllerの繋ぎこみするプログラミングしてるから検知が遅れてしまって完全にダメダメだった
なんかもう通っちゃいけないのに通すこのテスト、本当に必要か…？みたいな気持ちがあってイマイチ答えが出せずにいる
結局想定するデータ用意するんだし、データDBに突っ込んでモック使わずにControllerからテストしたほうがいいじゃないかと思い始めている
DBに突っ込むとIO増えるからテスト遅くなるんだけど、そこは現代的に並列化とかパワー上げるとかで対処出来るはず
もうテストわからなくて完全にこれになっています
