nashcft's blog

時々何か書く。

ErgoDox EZでも (もっと) 傾斜をつけたい!

先週こんな記事が公開された。

nippondanji.blogspot.jp

セパレート式のキーボードによって手から肩周辺にかけての姿勢を自然なものとすることができるが、より自然な姿勢を求める場合、上の記事で書かれているように、いわゆる「ろくろを回す姿勢」の手の角度であることが望ましい。
私が使用しているErgoDox EZはオプションでtilt / tilt kitがあり、これを用いてキーボードに傾斜を付けることができるが、これで最も傾斜のある状態にしたとしても「ろくろを回す姿勢」の角度には遠く及ばない。しかしFalbaTechで購入する場合のように部品単位で購入して適当パーツと組み合わせるというような、自分で工作して拡張するといったことは難しい、というか、やろうと思えばできるのかも知れないが私には工作への情熱やら何やらが絶望的に足りなかったので、別の方法で実現してみることにした。まあ大雑把に言うと内側のtilt kitの下に何か台になるものを敷くというものだ。
とりあえず今日の時点で大体いい感じになったのでそれまで何やっていたかまとめておく。

とりあえず下に何かを敷いてみる

最初はとりあえず良さげな高さのものを下に敷いて傾斜の具合を試してみようということで、職場にあった厚めの本を敷いてみた。

f:id:nashcft:20160930175527j:plain f:id:nashcft:20160930175548j:plain

この本の厚さが大体3.5cmくらいで、結論から言うとこの高さが写真のtilt kitの角度だと丁度良い塩梅になる。 せっかく空いたキーボード間のスペースが潰れてしまうが (トラックボールやタッチパッドを置いているなら問題ないかも知れない)、お手軽だし人によってはこれでも良いかも知れない。ただ、私にはこの書籍の幅では足りなくて若干肩周辺が詰まったような感覚を覚えたのでもうちょっと模索することにした。

左右のキーボードそれぞれに敷くものを用意する

何か下にものを敷きつつキーボード間の幅を持たせる場合、より大きなものを使用するか、敷くものもセパレートするかということになる。職場にはそんな大きさと厚さを兼ね備えたものはなかったので、とりあえず自分のメガネケースも使ってみることにした。

もともと傾斜は良い感じだったので、私がいつも使うときの幅でその傾斜を実現できて、そうそうこれこれという感じだった。 これを試してみて、このメガネケースのコンパクトさが丁度いいと感じ、あまりこれにあれこれ悩んでもしょうがないよなと思いつつ、同型のメガネケースがamazonで1個600円程度で買えることがわかったので、早速購入したのだった。

現在

購入したメガネケースが届いたのでそれと交換して写真のような状態で使用している。

現在の課題は、メガネケースを写真のように置いた場合の高さが4cmと最初に使用した本よりやや高く、それによって傾斜がつきすぎてErgoDox EZの外側手前部分の接点が滑り止めから外れてしまい、キーボードが滑りやすい状態になってしまっていることだ。
これについてはtilt kitの角度を調節するなり滑り止めになるものを買って接点につけるなりしようと思っている。

工作しなくてもこんな雑なやり方でもより良い環境は作れるものなので、各位適当にやっていきましょう。

番外

最初に紹介した記事のリンクにあったAxiosというキーボード、キー配列が気持ち悪いけど親指部分のキーに角度が付けられるの非常に良さそうなのでとても興味ある。
あと私はErgoDoxで親指部分のキーを叩くときは指ではなく手首を動かしていることが多い。押しにくいのは認める。

『再演 ~ 組織にテストを書く文化を根付かせる戦略と戦術 +α』メモ #t_wada

また過去に参加した勉強会のメモ。今回のは3/11ともはや半年以上前...
まあもう諦めても良かったのだけど、9月頭 (これも1ヶ月近く前...) にあったprivate methodの件だったり職場で最近あったお話だったりがこの講演で扱われた話題に関連している気がするなあと感じたので、折角だしと思って掘り出してまとめることにした。

connpass.com

togetter.com

www.slideshare.net

転送サーバおけるテストの自動化 · GitHub

メモは最後に貼るとして、講演の内容の内2点について、この記事を書いている時点までにあったことも含めて思っていることをまとめる。これらを書いていて、半年以上前の講演で、それもスライドに残されていることではなくその場で話されていたようなことやそれについてその時感じたことなのに、今でもこうやって覚えていてそれなりな量の文章を書けるのは、自分にとってこの講演がそれほど感銘を受けるもので、その後の自分の考えや行動の指針となっているのだなあとしみじみ思ったのであった。

リファクタリングとビジネス価値、日々の開発の関係

スライドにおける「リファクタリングのジレンマ」の部分。スライドにはこれだけしか書かれていないがこの会ではここを掘り下げた話があった。

リファクタリングを独立タスクにすると、そのタスクは着手されない

どういうことかというと、リファクタリングそれ自体はプロダクトに新たにビジネス価値を付与するものではなく、振る舞いを変えることなく内部を改善する「だけ」なので、「〇〇のリファクタリングを行う」とタスクとして独立してしまうと、他の新機能開発や機能追加・改修といったタスクに対して短期的な視点からエンジニアの自己満足とみなされたり早く顧客に新たな価値を提供したいというビジネス判断をされたりして後回しにされ続けてしまい、ついぞ着手されることなくTODOリストの奥底に沈み込んでしまう、ということだそうだ。
ではリファクタリングのビジネス的価値とは何かというと、中長期的に見て同様のタスクをこなすのにかかる時間を一定以内に保ち続けられるようにすることであるとのことで、つまりビジネスの進行に対するブレーキをプロダクト内に作らないようにすることと言える。

リファクタリングされないまま開発を進めてしまった場合どういうところに行き着くのか、というのは、最近だと以下の記事の「コードの乱れが生むもの」がイメージしやすく書かれていると感じた。

d.hatena.ne.jp

この記事によれば、行き着く先とは最早リファクタリングどころではなくなってまた一から同じシステムを作り直すという、開発にもビジネスにも多大なコストを支払わざるを得ない状況となる。計画された再構築でなければ実施しようとする頃にはそれをするにも心許ない、最悪実施すらできないような状況に陥ってしまっているというのは恐ろしい話である。

短期的には後回しにされがちだが、かと言ってしないままだとその内まずいことになるのでやらねばならないリファクタリングを、じゃあどうやって実施したらいいのかと言うと、日々の開発タスクの中に小さなリファクタリングをまぶして、日々の業務に改善を組み込んでいきましょう、とのことだった。

これは言われてみればなるほどその通りで、規模の小さい内に問題を潰せることができればその後起こりうる大きな問題 (大規模なリファクタリング) を未然に防げるだろうし*1、結局開発もリファクタリングもソフトウェアエンジニアとしてはどちらもコーディングタスクと見做すことができるので、あえて別タスクに分離して実施しなくても一緒にやってしまえばいいよな、と思う。
とは言うものの中々実行はされないもので、今の職場では割とカジュアルにリファクタリングを独立タスクにしていく傾向があり、見かねて一度「そういうのは良くないよ、こういう風に日々の開発タスクの中で少しずつリファクタリングしていきましょう」ということをプルリクエストで実例を紹介しつつ訴えかけたことがあった。その時はあまり注目されてないなーと思ったのだけど、2, 3人ほどそれ以降実践してくれているのを観測したので、文化を作るきっかけにはなったのかなと考えている。

この講演でも話されていたことなのだけど、本当は上記のように大勢に呼びかけるような方法というのは戦術的には筋が良くなくて、一人ずつ伝授していくようにできる人を増やしていくという方法が紹介されていた。確かに、考え方や実践のためのスキルなど習得すべきことの性質や量を考えると個別にみっちり指導していく方がよく定着するだろうなと思う。とはいえ現実問題としてはそんな気長に構えていられないような状況もあるだろうし、まだ小さくリファクタリングする習慣を会得していない人のタスクに対してもどうにか改善を適用したいという思いがないこともない。
これに関してはプルリクエストによるコードレビューを行うとそれなりにカバーできるのかなあと考えている。講演でも戦術としてコードレビューが挙げられていて、人に見られるコードを書いているという意識を植え付けることで、コードの品質を向上させられるというような話があった。そのためには、単に実施するだけではダメで、レビュイーに自分の書いたコードやどのような変更を行ったかが見られ、その内容が評価*2されるということを認識させるように、レビュアーはきちんと見なければならないし、見ているという姿を表さないといけないが。

それで、どうやってコードレビューで日々の改善をカバーしていくかと言うと、レビューの際に改善ポイントをがあったら、普段からこういうのを見つけたらこういう風に直していきましょうねー、というのを指摘・解説しつつ、改善を適用して (してもらって) からmergeするようにする感じ。はじめの内はレビュアーのコストがかかるのは仕方ない。いわゆる投資というものである。人によってはこれでレビュアーが見つけてくれるからと完全に甘えてしまって改善を行わない人も出てくるかも知れないが、そうしたら素直に張っ倒して (比喩表現)、自らやるように導いていくなりする必要がある。
これも全体に〜という話だとレビューするプルリクエストの量が多くなって大変になってしまうが、改善活動を日々の開発に取り入れるならば、それの啓蒙や教育も日々の活動の中にまぶしていくのが良いのではなかろうか。

「設計の可動域を確保した」テストについて

前半の方で品質を上げるのはテストではなく設計とプログラミングという話があって、品質改善のために再設計を、それによって実装の変更を行うとして、その際にテストが実装に寄り添ったもの (= 実装をテストしているテスト) になっていると、これらの活動の足を引っ張るようになってしまう。なので、設計や実装の変更を後押しするような、実装と距離を持ったカバー範囲に遊びのあるようなものにして、カバー範囲内で変更を行う分には落ちないようなテストを作りましょう、という話だった。

それから時間が経って9月になって、private methodのテストと設計についての話が以下の記事を発端として話題になった。

su-kun1899.hatenablog.com

private methodにまつわる設計の是非は置いておくとして、この記事に対してt_wadaさんが紹介したQ&A記事において、質問者がprivate methodも実装した瞬間に実装のテストがしたいという発想のもとテストを書いてしまいたいな、と述べており、それに対してt_wadaさんは「プライベートなメソッドのテストを書く必要は 無い と考えています」と先に結論した上で、以下のように説明している。

繰り返すと、プライベートなメソッドや関数をテストする必要は無いと考えています。プライベートなメソッドは、実装の詳細であるからです。 (中略) プライベートメソッドに対するテストは内部の実装に対するテストになってしまうことが多く、そして内部の実装に対するテストはリファクタリングの妨げになりがちです。自動テストの助けを借りて積極的にリファクタリングを行いたいのに、その自動テストがリファクタリングの妨げになる。これはとても皮肉な状況です。避けられれば避けたいものです。
テスト「できる」ことと「するべきである」ことは異なります。リフレクションを使えばプライベートなメソッドのテストは「できる」のですが、そのテストはやがて実装改善の邪魔になりかねません。

Q&Aの記事がちょうどこの講演 (再演) の3年前くらいで、その頃からリファクタリングを後押しするための実装に対して距離を保ったテストという考えがあって今日まで一貫してきてるんだなあという感動があったのはさておき、実装のテストを書いてしまうと実装を変更するたびにテストも改修しなければならないためリファクタリングのコストを無闇に上げてしまうことや、リファクタリングが振る舞いを変えずに実装を改善することだというところから、リファクタリングによって継続的にコードを改善できるようにするために実装に対して遊びのあるテストを書きましょうということについては私も同意したのだが、「実装のテストを書くべきではない」というのはちょっと違うのでは、という考えを話を聞いた当時に持った。
それについて、講演後に呟いた以下の一連のtweetが上記の話を受けての実装のテストに対する考え方を表している。

まとめると、この講演では書くべきでないとされた「実装のテスト」について、私は実装をしているまさにその時はそれぞれの部品が正常に動くことを確認するための一時的な、目的を達成したら (部品が期待通りに動くことが確認できたら) 捨ててしまう「寿命の短いテスト」としてであれば別に書いても良いと思っていて、実装後も再設計やリファクタリングできるように残すテストは設計・実装に関してカバー範囲に遊びのある「寿命の長いテスト」にする、というように使い分ければ良いのではということである。

ここでいう「寿命の短いテスト」= 「実装のテスト」は役割的には補助輪のようなものだし、書くべきではないというより書かなくてよい、言い方としては「後に残すべきではない」の方が適切かな? というのが私の意見となる。

まあ時間軸の視点を持ったところで、結局「寿命の短いテスト」は書かずに済むに越したことはないし、「寿命の長いテスト」だけ書きながら書き上げられるようなプログラムがいわゆる良い設計のプログラムと言えるのかも知れない。


以下当日のメモ (当日若干遅刻したので途中から)

*1:根本的な設計そのものみたいな問題はこの方法では対処できなさそう...?

*2:コードの評価であって、人事評価ではない。念のため

Read more

第3回 マイクロサービス アーキテクチャ 読書会 メモ

書くだけ書いて投稿し忘れていた当日書いたメモ。もう第4回も終わってるんだけど...

architect-club.doorkeeper.jp

スライド: 前半

www.slideshare.net

後半

www.slideshare.net

統合

  • 数ある選択肢
  • 統合から何を得たいのか?
    • 破壊的変更を回避する
    • APIを技術日依存に
      • サービス間の通信に使うAPIを特定技術に依存させない
    • コンシューマにとって単純なサービスに
      • 利用コストが高いと価値がない
      • クライアントライブラリ: 結合度が高まる
    • 内部の実装詳細を隠蔽
      • 変更コスト、破壊リスク、技術的負債
      • ECサイトに対する会員登録API,メール送信APIを公開するべきではない -> ドメインモデル貧血症

顧客とのinterface

  • 単純なCRUD: 登録、削除とか

共有データベース

サービス間でDBを共有しても良いか否か

  • 大規模な共有APIの場合
    • スキーマ変更によりコンシューマを破壊してしまう
    • データモデル、プロダクトの変更がむずい (ドライバの問題とかあるね)
    • ロジックが分散する: 凝集性の喪失
  • いかなる代償を払ってもDB統合を避けるべき

共有しない場合の手段

  • 特に言及なし?

REST vs RPC (Remote Procedure Call): Trade-off?

RPC

  • finagle, gRPC
  • ひどくはない
  • プロダクトを選ぶ

REST

  • HATEOAS
    • リチャードソンの成熟モデル level 3
      • level 0: the swamp of POX - URI と HTTPが 1to1
      • level 1: Resources - リソースが紐付いている
      • level 2: HTTP Verbs - methodを活用している
      • level 3: Hypermedia controls - RESTful、状態と振る舞いを表している
        • 次の振る舞いを返却してくれたりする

JSON or XML?

  • JSONにはlink controlがない -> HAL e.g. Spring HATEOAS
  • SIREN
  • JSON API
  • JSON-LD (linked data)
  • de fact standard はなさそう

コレオグラフィ

Coreography

the art or job of deciding how dancers will move in a performance; also : the movements that are done by dancers in a performance

マイクロサービスアーキテクチャにおけるオーケストレーションとコレオグラフィ

  • クライアントが直接サービスを呼び出すのではなく、イベントを間に挟んで、イベントが必要な各サービスを呼び出す
    • pub/sub
  • Zabbix, Zipkin

orchestration vs coreography どちらを採用するべき?

  • coreographyはバッチみたいな大量の処理をするときに向いてそう
  • クライアントサービスはorchestrationでも良い?
  • 弊社サービスの構成はAPI gatewayというらしい
    • BFFかも?

req/res vs event-based

  • 同期モデルか非同期モデルか
  • SOAPとかRMIみたいな重いのよりJSONみたいな軽量のものを使いたいよね
  • level 3の採用は難しそうですねえ
  • まあ両方使うよね
    • ms間はevent-based
    • frontからはreq/res

色々なサービスを呼び出して結果的に1枚のHTMLに収めたい時

↓はアジェンダに当てはめるとここ?

UI

API合成

  • UIとサービス作成者の違い
    • 歩調を合わせるのは難しい
  • レスポンスの調整ができない

UI部品合成

  • SSRとか
  • wigetとか

API GatewayとかBFFとか

レガシーシステムやパッケージ製品ともやりとりする時の方法

↓はアジェンダに当てはめるとここ?

versioning

  • 最大限の見送り
    • フィールドの場所を曖昧にしておく (XPath)
      • 耐性のあるリーダー by Martin Fowler
    • ポステルの法則
  • 破壊的変更の早期把握
    • Consumer Driven Contract
      • 回避
      • 受け入れてコンシューマと相談
  • semverの利用
  • 異なるエンドポイントの共存
    • v1, v2がエンドポイントとして存在するけどロジックは1つ
    • テストの負担がやばいので3つ以上はやめとけ
  • 複数バージョンを同時に使う
    • 短時間ならまあいいかも
    • 「慎重に」

会の後

『自閉症の脳を読み解く: どのように考え、感じているのか』を読んだ

自閉症の脳を読み解く―どのように考え、感じているのか

自閉症の脳を読み解く―どのように考え、感じているのか

いつだったかTLでプログラマに向いてる人向いてない人の思考パターンについて会話しているのを見かけて、その中でこの本が紹介されていたので読んでみた。自閉症、というよりは人間の思考パターンに対する興味の方が強かった。
今月頭に購入してから時間を見つけてはちまちま読んでいて、今日の外出中に電車の中で読み終わった。

※ちょうどこの後目的地に着いて、昼だったので外食屋に入って以下をメモってた

思考パターンについて

本書によると人間の思考パターンには3つのタイプがあって「視覚的画像で考えるタイプ」「言語や事実で考えるタイプ」「パターンで考えるタイプ」があるのだそうだ。

8章「活躍の場を切り開く」の "対人関係のスキルを身につける" の項について

Ergodox EZを買った

最近色々なところで購入報告を見るようになったErgodox (EZ) を私も購入した。

f:id:nashcft:20160503161131j:plain

Read more

Gitを学ぶ

前の記事で勤め先のVCSをhgからgitに移行する機運があると書いたが、そちらの向きが強くなってきたのでgitについて少し真面目に勉強し始めていて、その中で良さげに感じた資料を一旦まとめることにする。

www.slideshare.net

このスライドはκeenさんのブログ記事で紹介されているのを見て読んだ。
gitで管理される情報の構造やユーザが操作するコマンドの裏側でどのようなことが行われているかをイメージしやすく、これを読んでおけば大体のことはこなせるようになるはず。
操作周りのスライドを読んでいて、hgを使っているのにrebaseやmqをガシガシ使っている人の多い弊社に本当に必要だったのはgitなのでは... と思った。

www.slideshare.net

最初のスライドに次に読むスライドとして勧められていた。所謂git-flow?
resetの部分だけ面倒だなと思ったので、これのresetしない版を普段やっているような気がする。
github-flow, gitlab-flowと他にもあるようだし、比較しながらブランチ戦略的なものを検討しよう。

Remove all ads

#CROSS2016 メモ

有給をとって朝からいた勢です
遅ればせながらのメモまとめ

togetter.com

Read more