昇降デスクを買った

今月（2021年7月）から新しい会社で働きはじめたのですが、完全にリモートワークとなったので自宅の開発環境をより快適なものにしたくて昇降デスクを購入しました。

前の会社も、新型コロナのせいで緊急事態宣言が出てからリモート可能になったけど、コロナ落ち着いたらまた出社になるんかな？という感じだったので自宅をグレードアップするのに躊躇していました。

今の会社は今のところ出社するために申請がいるとのことで、出社するほうが難易度高いし一度はオフィス行ってみたいと思いつつ、電車乗るの好きじゃないし、フルリモートでいいやって感じです。

ってことで、これからずっとリモートするなら通勤がなくなる分、自転車で駅に行ったり、駅から歩いたりすることがなくなるので、一日中座りっぱなしだと腰とかヤバくなってくることが想定される（いまのところそこまで腰痛はひどくないが）

スタンディングデスクも検討したが、体調不良のときでも立ちっぱなしになるのはキツそうなので昇降デスクにすることにした。

で、今の環境はこんな感じです。

昇降デスク

昇降デスクの上に27インチの4kモニターとMBPを置いてHHKBとMagicTrackpad2を使用、足元にはエクサーのステッパーを置いて、これを踏み踏みしながら作業してます。
（入社オンボーディング中にバレないようにこれに乗ってけど、同期同士のオンライン懇親会で「なんか揺れてましたけどどしたんですか？」と聞かれてしまった）

昇降デスクは山善のこれです。

山善(YAMAZEN) 電動 昇降デスク 幅100 スタンディングデスク ELD-FS(MWH) 脚部_ホワイト天板_ナチュラル(木目調)

なんでもよかったけど家のキャパの関係で、横幅が100cmのものを探していたらこれがジャストだったのでこれにしました。 手動と電動と迷ったけど、電動にしました。
手動のほうが故障しにくいかなと思ったけど、立ったり座ったりこまめに高さを変えることが想定されたので、楽したいし電動にしました。

ステッパーはエクサーのやつ

（後ろの木箱にルーターとか収納）

Xiser Pro Trainer エクサー プロ ステッパー フロアマット付き stepper 日本語説明書付き 5年保証 ブラック [EXMO,Inc.] XISER-STEP-MATSET-BK

5月くらいからダイエットはじめてて、食事制限だけでなんとかなるかなと思ってたけど、そういえばずっとリモートワークで、ほとんど家から出ない生活になっていたので最初はウォーキングでも始めようかと思った。
けど雨とかあると嫌だし、ながら運動できるほうがいいなと思って、色々探してこれに行き着いた。
デスク付きのエアロバイクも検討したけど、置ける部屋にエアコンがないので夏は地獄だなと思ってステッパーにした。
１万円以下のやつもあるけど、30分くらいしか連続で使えないみたいだし、音もうるさく壊れやすいというレビューが多かったので、めちゃくちゃ高かったけど一生使えそうなのでエクサーにした。

ずっと立つのは辛い

やはり立ちっぱなしというのは辛い。ずっとやってると慣れるというブログもいくつか見たが、頑張りすぎるとよくないし適度に座るようにしている。

(椅子使用時の絵。中古で買ったセイルチェア)

午前中は基本立ち or ステッパー踏み踏みで、午後一は眠くなるので立ち、14〜15時くらいは座ったり立ったりして、夕方はずっと立つ、みたいな感じで運用している。

非常に腰の調子がよく、眠くなったら立てばいいし、運動不足も解消できるし、昇降デスクマンセーって感じです。

次の展望は、やはり曲面ディスプレイ。 MBPと27インチで充分なんだけど、やっぱ憧れますよね。

【Amazon.co.jp 限定】LG モニター ディスプレイ 34WL75C-B 34インチ/曲面ウルトラワイド(3440×1440)/IPS 非光沢/HDR対応/HDMI×2,DisplayPort×1/高さ調節

今回デスクとステッパーで散財してしまったので、ディスプレイはまだしばらくお預けです。

あとは最近興味しんしんの分離キーボード このあたりから入門したいなぁと思ってる

ergodox-ez.com

キーボード沼も深そうなので興味あるが、ハンダとかまではまだハードル高そうなので、まずは完成品買ってみて試してみたいと思ってます。

Rubyのsuperの呼び出しについて、モジュールをincludeしてる場合

Rubyで、superを使ってスーパークラスで定義されたメソッドにたどり着きたい場合、モジュールがインクルードされていると期待する動作をしない、というのを学んだ。

例)

module Foo
  def hoge
    puts "Foo!!"
  end
end

class SuperBar
  def hoge
    puts "SuperBar!!"
  end
end

class Bar < SuperBar
  include(Foo)

  def hoge
    super      # Fooのhogeが呼び出される
  end
end

superを使うと、継承元のメソッドを呼び出すもんだと思っていたが、モジュールに同名のメソッドがあると、そちらが使われる。 なので、superで意図しない動きをした場合、includeしているモジュールに同名のメソッドがある可能性も視野にいれる必要がある。

骨伝導イヤホンを買ってしばらくたった

半年くらい前に購入して、すごい買ってよかった思っているこの骨伝導イヤホン

2020 OpenMove AfterShokz オープンムーブ ワイヤレスヘッドホン 骨伝導イヤホン 防水 Bluetoothイヤホン Zoomなどリモート会議 テレワーク 在宅勤務に使用可能 Slate Grey

すごい便利なんだけど、この便利に慣れすぎて普通になってきたので、まだ感じてる良いところを書いておこうと思う。 （そのうちあたりまえになって便利さを忘れる前に）

僕が思う骨伝導イヤホンの一番いいところは、耳を塞がないことだと思う。（あたりまえなんだけど） うちは二人の子供がいるのだけれども、食事などを作っている時、子供がテレビを見ていると音楽やポッドキャストを聴くことができない。 かといってヘッドフォンをしながら料理はしたくないし、仮にやったとしても子供が何かやらかした時にすぐ気づけないことになりそう。

そんなとき、骨伝導イヤホンだと、軽いので料理やら洗濯物干してるときもつけてられるし、子供が何か不穏なことをしていても気づくことができる。 僕はそれほど音質についてよくわかってないので、「音質が〜」とか思うこともないし、主に英語のポッドキャストとか聴いていて、聴ければなんでもいいと思っているので、重宝している。

デメリットはもちろんある、バッテリーである。フル充電でだいたい6時間くらいで切れるので、これはちょっと気をつけないといけない。オンラインミーティングに使用するとき、バッテリーの残量に気をつけていないといきなり切れてしまうことになる。

そして寝ながらつかえない。これは構造上しかたないが、頭の後ろの輪っかのとこ（なんていうんだろう？バンド？）があるので、寝転ぶとイヤホンがずれる。 一番何もすることがなく、まれに恐ろしく時間がかかる子供の寝かしつけのときに使えないのは悔しい（そういう用途で作ってないので仕方ないが）。この時間に使えれば長時間の寝かしつけでイライラすることも減りそうなもんだけど。

まあ、そんな気になるデメリットはあるものの致命的ではないので、総じて買ってよかったと思ってる。 性能アップしてバッテリーが20時間くらいになったらまた買い直すと思う。

「THE MODELを読んだ」

Saas開発に携わるにあたって、マーケティングとか営業の知識も仕入れておく必要があるのかなぁと漠然と思っていたけど、社内の営業研修に参加したらこの本がおすすめされていたので読んでみた。

THE MODEL（MarkeZine BOOKS） マーケティング・インサイドセールス・営業・カスタマーサクセスの共業プロセス

既に動いているものを上手に動かす仕事と、一から何かを作り上げる仕事は天と地ほど違う。一から作り上げる過程に携わった人だけが、後にあの仕事を自分がやったと実感できる。 「再現性」とは？ 成功モデルを作り上げる過程で行われた意思決定のプロセスである。それを身につければ環境や条件が変化しても対応ができる。

これはアプリ開発でも当てはまることで、最初にその機能を作った人と、あとから来て修正した人との違いみたいなもの。 作る途中で直面した問題や解決した方法、調べたことなどは自分の中に蓄積されるが、出来上がった後に触る場合は、これが当たり前と思ってしまう。

営業プロセスの管理

マーケティング、インサイドセールス、フィールドセールスの分業体制。営業プロセスを分業化する。 分業することで、同じリズムの仕事に集中することができるため、効率が上がる。 また役割を固定することで１つのことに集中でき、徹底的に仕事を覚えることができる、そして次の役割に移ってまた新しい仕事を覚える。 １つの役割に集中させて数多く経験させて、スキルをあげるアカデミーのような側面もある。 これによって未経験から入っても効率よくスキルを向上させることができる。

また分業することで、どの部門がボトルネックになるのかを発見しやすく、対策を打ちやすくなる。 単一責任のクラス設計みたいだな。責務を１つだけにすることで、問題がある箇所を特定しやすいし、変更や改善しやすくなる。 一人ですべての業務をすると、各プロセスのどこかに問題があっても発見しにくい。

ザ・モデルのその先へ

インサイドセールスを当時の日本で行おうとすると、「日本のお客様だったらまず会いに来いと言われる」、、、 これはいまでもありそうで怖い、新型コロナの影響でだいぶ減ったがと思われる。

新規リードが永遠に増え続けることはない

当たり前のようで絶望できな言葉。 しかい放置顧客や商談に至らなかったリード、失注などを再び商談化のプロセルへとリサイクルできれば効果が見込める。

まとめ

（中盤から後半にかけては結構読み飛ばしたが、、、） マーケティング、インサイドセールス、フィールドセールス、カスタマーサクセスの職種別の業務プロセス、マネジメントや評価指標についてのことが書いてある。僕はエンジニアなので、そのあたりはサラッと読んだが、自分の会社の営業、マーケもこの本のやり方を参考にしていると思われるので、営業の業務内容や社内会議で使われてる用語などわからないことが理解できるようになったと思う。 ビジョン、ミッション、バリューなど、最近ではどの企業でも掲げてるものがなぜ必要なのか、組織づくりのためのベストプラクティスは何かなど、営業以外の組織の核となるものについても書いてあるので、読み物としても面白かった。

リファクタリング：Rubyエディション 7章 オブジェクト間でのメンバの移動

リファクタリング:Rubyエディション

引き続き7章読んでいく。

7章

メソッドやフィールドをどのオブジェクトに管理させるかは、オブジェクトの設計でもっとも重要な判断の一つである。

この問題に対応するためのテクニックについて学んだ。

メソッドの移動（Move Method）

メソッドが、自分のクラスの機能より他のクラスの機能を利用している場合は、そのメソッドがもっともよく使うクラスに新しいメソッドを作る。

クラスの機能が増え、２つのメソッドが密結合になりすぎたときは、メソッドの移動を行うことを考える。

フィールドの移動（Move Field）

メソッドの移動と同じような観点でフィールドが、自分のクラスより他のクラスからよく使われている場合は、そのクラスに新しいフィールドを作る。

クラスの抽出（Move Field）

クラスの仕事が１つではない場合は、新しいクラスを作って仕事を移す。

クラスは凝縮された抽象として少数の明確な任務を果たすべき

ちょっとした機能だと、既存クラスに追加してしまいがちだけど、本当にそのクラスで仕事させるべき機能なのかを考え、必要に応じて新しいクラスを作る必要がある。

クラスのインライン化（Inline Class）

クラスが大した仕事をしていない場合は、全ての機能を他のクラスに移してから消す。

クラスの抽出の逆 （サンプルのコード、結局戻すんかい）

移譲の隠蔽（Hide Delegate）

クライアントがオブジェクト内の委譲クラスを呼び出している場合、委譲を隠すためのメソッドを作りカプセル化する。 カプセル化とは、オブジェクトがシステムの他の部分についてあまり知識がないということ。

forwardableを使うことで、処理を移譲した機能を提供することができる。

横流しブローカーの除去（Remove Middle Man）

移譲の隠蔽でデメリットが出る場合に実施する。 移譲オブジェクトに追加するメンバが増えてくると苦痛になってくる。 その場合、クライアントが直接呼び出したほうがよい。

所感

6章は戦術的なリファクタで、各コードを読みやすく、保守しやすくするテクニックに対して7章はクラス設計に関わる部分。 これらを後から行うの結構きつそう。こういった手法は予め知っておくことで綺麗な設計を心がけることができそう。 また一つのテクニックを説明したあと、次でそれの逆を説明してくれている（「移譲の隠蔽」と「横流しブローカーの除去」など）ので、盲目的にカプセル化だ！とか思わず、こういうパターンもあるし、どっちにするか？と思考できるのがよい。

リファクタリング：Rubyエディション 6章

引き続き読んでいく

リファクタリング:Rubyエディション

3章〜5章は座学的な感じなのでざっと読んだ。 6章から、サンプルコードの改良するための手法の説明になる。

6章 メソッドの構成方法

メソッドの抽出（Extract Method）

コードの断片をメソッドにして、その目的を説明する名前をつける

メソッドの粒度が細かく出来ていれば、他のメソッドからそのメソッドを使える可能性が高くなる。 メソッドを抽出することによってコードがわかりやすくなるなら、抽出されるコードよりも名前のほうが長くてもメソッドを抽出すべき。

ソースコードのコメントはメソッドを見分けるのに使える。 コメント自体が抽出するメソッドの名前の候補になる。

メソッド抽出する対象のコードに、「ローカル変数なし」、「ローカル変数使用」、「ローカル変数への再代入」でそれぞれのケースを考慮する。 - 「ローカル変数なし」簡単 - 「ローカル変数使用」引数を渡す - 「ローカル変数への再代入」変数が抽出したコードより後で使われている場合は戻り値として返す。

メソッドのインライン化（Inline Method）

メソッドの中身が、メソッド名と同じくらいわかりやすい場合は、いちいちメソッド化しなくてよい。

一時変数のインライン化（Inline Temp）

一度だけ代入されてる一時変数は取り除いて式に直す。

一時変数から問い合わせメソッドへ（Replace Temp with Query）

式をメソッドにする。一時変数のすべての参照箇所を式に置き換える。

一時変数は、使われているメソッドのコンテキストの中でしか参照できない、一時変数にアクセスするにはメソッドを長くするしかないので、メソッドの長大化を助長してしまう。

一時変数からチェインへ（Replace Temp with Chain）

チェイニングをサポートするようにメソッドを書き換えて、一時変数を不要にする。 １つのオブジェクトの表現力を高める。

説明用変数の導入（Introduce Explaining Variable）

処理の目的を説明するような名前を持つ一時変数に式、または式の一部の結果を代入する。

確かに処理がわかりやすくなるがReplace Temp with Queryとぶつかりそう？？？ と思ったらちゃんと書いてた。 「説明変数の導入なら、メソッドの抽出を選ぶ」

一時変数の分割（Split Temporary Variable）

一時変数を使い回さない。代入ごとに別々の一時変数を用意する。 使い回すと変数は複数の仕事をかかえている兆候になる。

引数への代入の除去（Remove Assignments to Parameters）

引数に代入を行っている場合は一時変数にいれる。

メソッドからメソッドオブジェクトへ（Replace Method with Method Object）

ローカル変数の使い方によっては「メソッドの抽出」が適用できない場合、メソッドを独自のオブジェクトに変更し、すべてのローカル変数がそのオブジェクトのインスタンス変数になるようにする。

アルゴリズム変更（Substitute Algorithm）

メソッド本体を新しいアルゴリズムで書き換える

# 変更前
def use_programing_language(langs)
  language_list = []
  langs.each do |lnag|
    if(lang == "Ruby")
      language_list <<lang 
    end
    if(lang == "Java")
      language_list <<lang 
    end
    if(lang == "Javascript")
      language_list <<lang 
    end
  end
  return language_list
end

# 変更後
def use_programing_language(langs)
  langs.select {|lang| %w(Ruby Java Javascript).include? lang }
end

ループからコレクションクロージャメソッドへ（Replace Loop with Collection Closure Method）

ループではなくコレクションクロージャメソッドを使う。

# 変更前
zoo = []
animals.each{ |a| zoo << a.name }


# 変更後
zoo = animals.map(&:name)

サンドウィッチメソッドの抽出（Extract Surrounding Method）

同じようなコードの２つのメソッドで中頃に違いがある場合、重複部分を抽出してブロック付きのメソッドにする。

重複がメソッドの先頭や末尾なら重複を取り除くのはそれほど難しいことではない。 真ん中にある場合はそうもいかないが、Rubyのブロックを使えばうまい具合に重複部分を抽出してメソッドにまとめることができる。

クラスアノテーションの導入（Introduce Class Annotation）

クラス定義からクラスメソッドを呼び出して振る舞いを宣言する。

initializeを隠蔽する？あまり理解できてない。

名前付き引数の導入（Introudce Named Parameter）

引数リストをハッシュに変換して、ハッシュキーを引数の名前として使う。

# 変更前
Class Person
  attr_reader :first_name, :last_name
  
  def initialize(first_name, last_name)
    @first_name = first_name
    @last_name = last_name
  end
end

Person.new("yamada", "taro")


# 変更後
Class Person
  attr_reader :first_name, :last_name
  
  def initialize(params)
    @first_name = params[:first_name]
    @last_name = params[:last_name]
  end
end

Person.new(first_name: "yamada", last_name: "taro")

呼び出し元は綺麗になるが、クラス定義の方はメソッドの必須引数をしるためにメソッド定義を読む必要がある。 ここで「クラスアノテーションの導入」を使う。

そしたら

Class Person
  attr_reader :first_name, :last_name

  hash_initializer :first_name, :last_name

(どのみちメソッド定義読まなあかんのか？)

所感

サンプルコードを用いて、各テーマに沿ってリファクタリングを学べる。 なぜそれが必要なのかという理由と手順が書いてあり、ありがたい。

とにかく一時変数はさけて、小さいメソッドにしていくことが綺麗なコードにできる。 ただ何がなんでも一時変数がだめではなく、引数に代入をさせないようにするときなどは有用。 6章後半はちょっと理解が難しかったが、ここに書いてあると覚えておけば折を見て見返すことができる。

リファクタリング：Rubyエディションを手に入れた

高かったけど買いました。リファクタリングRubyエディション

リファクタリング:Rubyエディション

リファクタリングとは何か？

リファクタリングは、コードの外から見た振る舞いを変えずに、内部構造を改良するようにして、ソフトウェアシステムを変えていくプロセスである

第１章

ビデオレンタルのコードのリファクタリング リファクタするにはまずテストコードが必要なので、minitestで雑にテストコードを作って、本の通りにリファクタリングしてみる。（サンプルコード、いくつか誤記があったので修正したもの）

github.com

リファクタ後

https://github.com/terachan3700/refactoringRubyEdition/compare/main...refactor-complete

要約

1つのメソッドが長いく多くのことをやりすぎているときは注意が必要。 インタープリタはコードのきれい、汚いを気にしないが、システムに変更を加えるのは人間が関わってくるし、人間はコードがクリーンかどうかに左右される。 新しい機能を追加する場合に、まずリファクタリングして作業しやすくしてから追加するのが望ましい。

リファクタリングの第一歩としてテストコードが必要。 メソッドを小さく分解するたびにテストを実行する。

第２章

リファクタリングの歴史、定義、利点、いつすべきか、問題点など

• リファクタリングの定義
  リファクタリングはソフトウェアの振る舞いを変えずに、わかりやすく直しやすいものに変更すること。 パフォーマンスの改善のための変更は、最適化と呼ぶ。

• リファクタリングはソフトウェアをわかりやすくする
  他のプログラマや自分が将来、ソフトウェアに変更を加えるときのために、わかりやすくしておく必要がある。 自分の書いたコードも、ずっとは覚えていられないので、ごちゃごちゃしてるコードだと、読み解くだけで非常に時間がかかる。

などなど。 随時更新していく