petitviolet_blog

@petitviolet blog

トラックボール変遷

トラックボールの話。 Macは大学時代に研究室配属されて以来使っているが、当初はあまりトラックパッドに馴染めずマウスを使っていた。 ある時トラックボールの存在を知って机の上を整理整頓できない自分にとっては最高のデバイスになるのではないかと思って試してみたところ、非常に体験が良かった。

名器といえる。

数年間は楽しく使っていたのだが、どうしてもUSB無線接続という性質上、USBの穴が埋まることも不満だったしプライベートPCと仕事PCの切り替えが面倒に感じていた。
その辺りで購入したのがこれ

Bluetoothで接続できる!親指で操作できるタイプ!ってことで良かった、良かったのだがいかんせんコンパクトすぎる。 手が大きいのでこのトラックボールでは少し無理した姿勢(?)で操作することになって窮屈さを感じ、そしてこの頃からトラックパッドにようやく慣れてきたので徐々にトラックボールに頼る頻度が下がってきていた。

そしてCOVID-19。 Work From Home期間が長くなりいつ終わりが見えるかわからない状況において、例によって例のごとくデスク環境を整えることにした結果、それまでは目の前にMacを置いてトラックパッドで操作していたが物理的に少し離れたところにMacを設置することにしたためトラックパッドを用いることが難しくなった。 ↑のトラックボールを持ち出してしばらく使っていたがどうしてもしんどいので奮発してこれを買った。

やや高い。でも非常に体験が良い。 名前の通りエルゴノミクス的なアレコレによって手首の角度も無理せず使えるし、何よりほどほどに大きいので手に馴染む。 何かと不満だった横スクロールが標準でサポートされているし、Logi Optionsという設定ソフトによって物理ボタンに多様な機能を持たせることも可能。

感動したのでどこかに書いておきたかったというだけの日記。

2019年度振り返り

社会人5年目の振り返り。
昨年度の。

転職した

大きなイベントとしてはまずこれ。 4年ちょっと在籍したFringe81株式会社からトレジャーデータ株式会社に。

現状、何とか死なずに済んでいるという状態。 入社してしばらくは無力感に打ちひしがれていたものの9月にはバンクーバーに出張に行き、何やかやで少しずつ理解が進んできたので冬の間はお金になりそうな機能を作っていた。 やっていることもそうだし、働き方とか仕事の進め方が前職と前提から異なっている感じで、新鮮で楽しいには楽しい。 ここ最近はCOVID-19の影響でしばらくオフィスには通っていない。オフィスランチが恋しい...。

そして英語は相変わらずボトルネックだが実際どれくらいなんだろうと思ってTOEFL受けてみたら73点だったのでわりとアカンことが判明してしまった。 というか大学院入試の頃(TOEIC760くらい?)と英語力的にはほぼ変わってなさそうでもうダメだしそんな状態で面接とかするとまあ大変だった。

エンジニアとして

環境が大きく変わったけどわかりやすいところだとScala -> Ruby(Rails)。 大学院の演習でRuby勉強してRailsアプリ作ったけど、それ以来でRubyを書いている。
最初は大変だったけど少し慣れてきたかなというところではある。結局難しいのはRubyとかRailsとかじゃないし。
せっかく仕事で使っているし勉強しようということで、Rubyで習作Gemをいくつかrubygems.orgに公開したりしてみている。https://rubygems.org/profiles/petitviolet

関係ないところだと夏頃はTypeScriptとかReact.jsのhookを触って遊んでた。

そしてGatsby使ってblog.petitviolet.netを作ったり。 今後は技術的なものはあっちに移すかもしれない。

登壇ScalaMatsuri2019だけだったらしい。

技術的には全体的に底上げされている感覚はあるもののこれといった強みを持てていないという悩みは相変わらずなのでどうしようかな。

プライベート

引っ越しをした、そして色々あったが子どもは相変わらずとにかくはちゃめちゃに可愛い。

来年度に向けて

ばーんとお金を稼ぐぞ!

RstructuralにOptionとEitherを追加した

前にRstructuralというGemを作ったという記事を書いた。

それの続編としてOptionEitherを実装した、というだけの話。

Option

Scalaやってる人にはOptionHaskellとかならMaybeで伝わるはず。 「要素があるかも知れないし無いかも知れない」を表現するための型で、Rubyだとすぐにnilが出てきてあらゆるオブジェクトがnilの可能性もあり大変なのでもう少し安全に扱いたいなということで実装した。 しかしそうなるとすべての要素をOptionにする必要があり大変だが、名前の通りオプショナルな値をOptionで包んでおくと便利に扱えるのではないかなと。

Option.ofがファクトリになっていて、mapとかflat_mapが生えている。

x = Option.of(100).flat_map do |v| 
  Option.of(v * 2)
end 
#=> Option::Some(value: 200)
x.get_or_else { 100 }
#=> 200

get_or_elseの引数はデフォルト値でも良いけどブロックを渡せるようにもなっていてOption::Someの時には無駄に評価されないようになっていたりして便利。 Scalaのcall-by-nameの仕組みは便利だったなほんと。

とはいえnilを安全に扱うための言語的なサポートが無いので、Optionがあっても気を付けないと何も変わらないので面倒だしあんまり使わない気もする。

Either

値がLeftかRightのどちらかであることを表現する型。 Rubyだと失敗がnilか例外になることが多いような気がしていてもう少し明示的に扱いたいと思ったので実装した。 Either.try(&block)がファクトリになっていて例外が起きたらEither::Leftになる。

Either.try { 100 } #=> Either::Right(value: 100)
Either.try { raise "this is error" } #=> Either::Left(value: this is error)

明示的にLeftかRightかを指定してnewしたければEither.leftEither.rightが生えている。

Either.right(100)
    .flat_map { |v| Either.left(v * 2) } #=> Either::Left(value: 200)
    .right_or_else { 0 } #=> 0

Either.left(100)
    .map_left { |v| v * 2 } #=> Either::Left(value: 200)
    .left_or_else { 0 } #=> 200

やはりmapflat_mapが生えていて、さらにright-biasedになっていて便利! さらにパターンマッチと組み合わせるとこういう雰囲気

case Either.try { do_something() }
in Either::Right[value]
    value * 2
in Either::Left[error]
    logger.error("error: #{error}")
    0
end

結果の成功失敗をラップする型があるとわりと便利かなと思うこともあり、Optionよりは使い勝手良さそうな気もする。

感想

こういうのがあるとなるべくifとかtryを使わずにパターンマッチだけで実装できて気持ちが良い。