J Lang Fest Kansai Online #1 で登壇してきた

久しぶりに外の勉強会ではなしてきた。

kansai-jvm-langs-fest.connpass.com

毎年 1 回は機会を作ろうと思っていたのに、2019 年は社外で登壇しなかったので久しぶりになってしまった。。

Scala の好きなところ」をテーマにもらっていたので、大好き(?)な Akka をメインにしてみた。
コーディングとかたくさんある機能、簡単に実現できる並列・分散処理、リアクティブなどなど、Akka の良いところはたくさんある。その中でも特に推しておきたい処理を部品として分解することによる事業へのメリットを扱ってみてる。実は「それは Akka じゃなくても良いんじゃない?」という声があるだろうなーとは思ってる。ほんとそのとおり。でも同じように実現できる言語やフレームワークの中でも、その自由さであったり容易さがピカイチなのは Akka だと思ってる……。定量的に比較してなくて超定性しかも個人の。
そんなだから、もし「おいおいおいおいーこれも超いいんだけど!?忘れてない!?!?!?」みたいなのがあればぜひ教えてもらって知りたい!というモチベーションでも登壇したのでした……。

資料はこちら

speakerdeck.com

質問でもらっていた背圧制御については Actor ではなく Streams の方で実装されているのは訂正しておきます。
あとあんまりデメリット側のはなしができてなかったのだけれど、アクターやメッセージボックスの数の最適化や、割り当てるスレッドプールの数などアクターモデルにはアクターモデルのチューニングポイントというか難しさがある。これはどんな道具でもそういうところがあるので、道具にあわせて学んでうまく付き合っていきたいところ。

そういえば「良い道具は使い手を良く育てる」みたいなことを途中言いたかったんだけれど、なにかの格言なのかネットの言葉なのかネタ元が見つからなかったので見送った……。良い道具はそれ自体に作り手の思想やプラクティスが染み込んでいるので、ある程度はその道具の導くとおりに振る舞うことで良いおこないとなるみたいな云々カンヌン……。

ぜんぜん内容には関係ないけれど、タイトルや途中のスライドに出てくる山は
剣山(から見た次郎笈)→(次郎笈から見た)剣山 → 大膳原キャンプ場 → 大山から見た日本海 → 大山
の順番。この夏の山々。もっと山登りいきたいなー。

他の方の登壇内容もすごく興味深いのに、登壇が後の方だったので自分のことにいっぱいでちゃんと見聞きできていない。。また見ときます。

運営の方、素敵な機会をありがとうございました〜。良い経験になりましたー。

Windows Terminal 1.3 で変わったタブ切り替えの挙動をもどす

Windows Terminal が 1.3 になったころから Ctrl + Tab と Ctrl + Shift + Tab での次のタブ・前のタブのタブ切り替え挙動が変更となった。

Release Windows Terminal Preview v1.3.2382.0 · microsoft/terminal

We're trying out a new tab switching experience! (#6732), followups: (#7263) (#7280) (#7321) The nextTab and prevTab bindings will now display an ephemeral UI that can be navigated with the mouse or keyboard

↓ こんなかんじ

1.3からのタブ切り替え
1.3からのタブ切り替え

いろいろ変わっていくこと試してみることはとても良いことなんだけれど、自分にはあんまり合わなかった。。
というのもシェルの名前といまいるディレクトリを表示されても、そこでなにしてたか覚えてない。なんなら複数同じディレクトリを別タブで開いておいて Scala の sbt の対話型コンソールで作業しつつ別タブではコマンド実行してたりするので、同じ名前の同じディレクトリがいくつも並んでしまう。こういう使い方してると合わないのかも。

たくさん開いたタブを検索する機能も入ってるので、それとの挙動の共通感を出したかったのかも?

ということで元に戻した。
方法は同じリリースノートに書いてあった。

If you would like to fall back to the original tab-switching UI (or lack thereof), set new useTabSwitcher (global, boolean, default true) to false.

  "useTabSwitcher": false,

これを keybindings とか copyOnSelect とかと同じ階層に追加する。

戻った。しっくりきた。

We'd love feedback on why the new tab switcher didn't work for you!

ということなので、またフィードバックしだいでは変更あるかもしれないけどひとまずはこれで……。

RAW現像に手を出しています

いままでカメラと写真を撮るのは好きできたけれど、どうにも RAW 現像というのはやってこなかった。

f:id:nishikawasasaki:20200615120203j:image

というのも、撮って出し(と呼ばれているらしい)撮影したときのカメラでの見た目そのままの JPEG で残しておくのが楽だったし、あとから見た目を変えてしまうことになんとなく抵抗感があったからかもしれない。別に写っているものに手を加えて変えてしまうわけでもないので、「撮ってそのまま」みたいなことに勝手な鮮度みたいなものを感じているのかも。

f:id:nishikawasasaki:20200615120140j:image

カメラを SIGMA fp にしてからというもの、プロダクトの魅力か魔力かカメラをとにかく触りたくなる。そこでメニューで見つけたのが「現像」機能だった。機能があるからには使いたい。でもいつ使うんだろう?

f:id:nishikawasasaki:20200615120249j:image

カラーモードは、SIGMA の売りでもある「T&O」か「風景」を好きでよく使うのだけれど、山で緑がきれいな写真を撮ったつもりが「T&O」になっていて元気のない枯れた絵になっていることがあった。うーんなんだか記憶の色でもないし、見せたい色でもない。ああそうか、こういうときに RAW(fp では DNG)で撮っておけば後から自分が見ていた景色を再現できるのかと、ようやく気がついたのでした。

f:id:nishikawasasaki:20200615120402j:image

修正をしているのではなくて、自分の見ていたものを再現する。そう考えると、変な抵抗感は無くなっていました。

f:id:nishikawasasaki:20200615120315j:image

スマートフォンにカメラを繋いで写真を取り込めば、その場でアプリを使って現像できる手軽さも良くて、これはなかなか楽しいことになりそうだなー。

2ヶ月ぶりの山登り

先週の日曜日に約 2 ヶ月ぶりの山登りに行った。
こんなご時世なので山行中もできる限りマスク。
すれ違うときのあいさつもあいさつも控えめか黙礼に。
変に声を張り上げてこれみよがしなのよりも、
「わかってますよ」とスッと会釈してすれ違うのもなかなか粋。

↓ は YAMAP さんがブログへの埋め込みに対応したそうなので

切り取られてしまっているので元の写真もいっしょに

f:id:nishikawasasaki:20200607123233j:plain
睡蓮

写真アップ用のサイト(Tumblr)を用意した

ここでやっても良かったんだけれど、
貼り付けての見やすさとかまとめなことを考えて
いつからぶりかの Tumblr を開始した。

https://nishisasa-photo.tumblr.com/post/617349801143566336
nishisasa-photo.tumblr.com

飽きるまではちょこちょこアップしていこう📷

はてなブログTumblr へアップした写真を表示する、
ブログパーツとかウィジェット探したけど
すぐに見つからなかったのでまたいつか。

デスクトップ(物理)を整えた

4月から基本的にテレワークな状態になったので、自分はあまりつかっていなかった机の上をカッコいい感じにしたいと思い始めていました。
そこでよく見ていたのが ↓

note.com

配置や配線は当たり前に、天板のオーダーから塗装、はては線を塗ったりとただならぬこだわり!こういうこだわり大好きです。

しかしながらさて自分も、とはなかなか行かない領域。
いろいろ考えて少し手を入れてみました。

まずはモニタアーム。
つい先日、長年の夢だったモニタアームを購入したのですが、なんと使っている机の張り出した部分が短すぎてがっちり固定できない問題が判明。どうしたものかと思っていたのですが、妙案を思いつきました。
……妙案というか引き出しを犠牲にする案です。
机を 180 度回転させ、本来正面となる向きを壁側に向けるのです。そして引き出した引き出しの中でモニタアームを固定し、さらにケーブル類やコンセント、電源系を引き出しの中に全部しまってしまう作戦。
こんな感じになりました。

ケーブル類がまとまるとそれだけでスッキリ見えていい感じに(個人の感想です)

あとはブックスタンドに PC を載せて、HHKB など機器類をもとに戻せば完成。

地味にブックスタンドに角度をつけるためにボール紙を挟んでいて、HHKB のケンブルはこの隙間から通しています。

これ以上は Magic Trackpad 2 に買い替えたり、モニタをベゼルレスな 4K に買い替えたり(そして 4K 対応として PC のスペックを上げたくなったり)、机を DIY して超気に入るものに替えたりとどうやってもお金がかかりまくってしまうのでひとまずここまで……。
机の上にマットを敷くのはやりたいかも。

山道具がおいてあったり鳥谷のポスターがあったり(写ってないところにカープグッズも多数)懐かしの CD が並んでいたりと、なかなかの雑然とした空間ができあがりました。満足。

API Gateway の HTTP API と Lambda を開発用・本番用のバージョン違いで接続する

めずらしく AWS ネタ。
けっこうどうやるんだ?ってなったので自分用のメモ。
要は API Gateway のステージとステージ変数を使って Lambda ファンクションのエイリアスを呼び分ける話。
「動的統合」というやつらしく IAM ロールは自分で用意・指定する必要があったところが(自分には)肝でした。

Lambda 側の準備

本番用と開発用とは Lambda の「バージョン」と「エイリアス」で表現する。なにも設定を変更してない状態だとバージョンは $LATEST だけ存在している。これを本番用の prod と開発用の dev に分ける。
現在の $LATEST バージョンをひとまず仮に本番用とするためバージョンを発行(作成)する。
f:id:nishikawasasaki:20200326195247p:plain
まだ一度もバージョンを作成していないと、バージョン 1 が作られる。

次にエイリアスを作成する。
本番用は固定されたバージョンの 1 を利用して、開発用は常に最新の $LATEST を使うとした場合。
f:id:nishikawasasaki:20200326195509p:plain
開発用なので dev としたエイリアスを、バージョンは $LATEST を見るように作成する。
f:id:nishikawasasaki:20200326195610p:plain 同様に本番用として prod エイリアスをバージョン 1 を見るように作成する。

これで Lambda 側の準備は完了。

API Gateway 側の準備

用意した Lambda のエイリアスに対応する形で API Gatewaydev ステージを用意する。

f:id:nishikawasasaki:20200326195915p:plain

ステージの名前は自由に。
ステージ変数の名前として「キー」に好きなものをつける。ここでは LambdaAlias
ステージ変数の値には Lambda で作った開発用のエイリアスを同じ dev をつける。
(この「値」が API Gateway の呼び出す Lambda ファンクションのエイリアスとして使われることとなる。)

同じことをデフォルトのステージ $default でもおこない、「値」は prod にしておく。
(本番用にちゃんと区別したい場合はデフォルトのステージを使わず prod ステージを用意すると良いはず。)

あとは統合する Lambda ファンクションを arn で指定するときに、エイリアス:エイリアス名 までつけて指定すれば OK。
arn + :エイリアス名 とするとそのエイリアスで Lambda ファンクションを指定できるそう。
arn:aws:lambda:ap-northeast-1:xxxxxxxxxxxxxx:function:hogehoge:${stageVariables.LambdaAlias} こんな雰囲気。
f:id:nishikawasasaki:20200326200440p:plain
「一致する Lambda 関数がありません」と出てくるけどちゃんと保存できます。

これで動くかなと思ったらそうではなくて、いまやっている「動的統合」の場合は「アクセス許可を呼び出す」のところを自動ではなく明示的に指定しないといけないそう。
自分はここから IAM 力の低さにつまづいてしまった……。
以下のページにもあるのだけれど、

動的統合を構築する場合、それに応じて権限を更新することも重要です。統合が単一のLambda関数を指す場合、HTTP APIは呼び出し権限を自動的に追加します。ただし、複数の関数を使用する場合は、ロールを手動で作成および管理する必要があります。これを行うには、Lambda関数オプションを呼び出すための[Grant API Gateway permission to invoke your Lambda function]をオフにし、適切な権限を持つカスタムロールを入力します。

高速、低コストで、より良いAPIの構築 – HTTP APIが利用可能(GA)になりました | Amazon Web Services ブログ

とのこと。
具体的にどんなロールを用意したらいいの?ってなったけど チュートリアル: 2 つの AWS のサービス統合と 1 つの Lambda 非プロキシ統合を使用して Calc REST API を作成する - Amazon API Gateway の内容に沿ってロール作成したものを使えばうまくいきました。

最終的にこういう状態に。

f:id:nishikawasasaki:20200326200903p:plain

試す

ここまできたら API Gateway に本番用と開発用の 2 つのステージで URL が得られているはず。

上が本番用で下が開発用。
あとは API Gateway のルートに作成したパスをつなげれば本番用・開発用の使い分けができる。

もし API 実行して Internal Server error が帰ってきており、Lambda の実行ログが Cloud Watch にも無いようなら、API Gateway から Lambda を呼び出せていないので IAM まわりを確認する。 そうでなく Lambda の中でこけているなら通常どおり Cloud Watch でログを見て修正する。

シネスコレイアウト写真の3段重ね

人がしてるのをみてシネマスコープ(風?)に切り抜いたり撮ったりしてる写真たち、Instagramにアップすると16:9くらいに横が切れるなーと思ってた。

そんなところにこれまで使ってなかったInstagramの「レイアウト」で、縦か横に3段重ねにするとちょうど収まることに気がついた!

こんな感じ。  

f:id:nishikawasasaki:20200220095845j:image

f:id:nishikawasasaki:20200220095848j:image

f:id:nishikawasasaki:20200220095852j:image

見やすいかというと……?だけどたまには奇をてらった感じで良いかも📸

 

ネコ写真(荒地山)

荒地山を登ったときに見たネコたち。
しましまと茶色とふさふさの 3 匹いたみたい。

ずっとついてきてなにかをねだるネコ

ついてくる

ねだり鳴き

うらめしい

ロッククライミングネコ

しなやか

「理想」「現実」「方法」「実行」に分けてみた

スクラムで出てくる振り返りとプロセス改善について考えていると、「理想」と「現実」のどっちも認識してそのギャップを埋める「方法」を適切に見つけ出した上に「実行」できることを自然と求められていて、それは大変に困難なことなのではないだろうか……と思って書き始めた。そもそも「理想」「現実」「方法」「実行」に分けてどれだけ考えているだろうかなーと。

勉強会に行ったり本を読むことは「方法」を学ぶことなんだけれど、実はその「方法」を適用することで達成される「理想」の状態についても知ることができる。自分はこれがとても大切だと思っている。どんなことをするにも最善の状態を認識できていないと、いまできることに引っ張られてしまってどうしても妥協が強く出たアウトプットしか出なくなるから。「現実」からの積み上げだけだと最終的な結果が必要なものに届きにくいと感じているのもある。ゴールに「理想」をおいて、ゴールまでの道のりまでを一定の粒度や単位に分解して進めていく方が、最も短くブレなくゴールに着けるんじゃないかなーと。
一方で「現実」の方もきちんと理解しないといけないと思っている。状況が見えていないのに「理想」だけ追い求めてもそれは無謀というものになってしまう。できないことをいきなりやろうとしてもうまくいかないし、結果が求めていたものじゃないかもしれない。より効果的でより効率的な「方法」を選び取るには「現実」を理解しておかないといけないと思うから。

「理想」と「現実」のどちらも「方法」選択に重要な要素なんだけれども、ここがあいまいなまま「方法」を選択してしまうからうまくいかなかったり、手段が目的になっているなんて言われたりしてしまうのかもしれない。 ケースがたくさん出てきそう。

  • アウトプットは出てもアウトカムじゃないってときなのかもしれない
  • なにかを複数人で進めていると他人に対してどうしてそんなことしたの?と疑問に思うこともあるけど、きっと見ていた「理想」の程度や方向性が違っていたのかもしれないし、もしかするとそもそも「理想」像が見えていないのに無理をしていた・させていたのかもしれない。
  • 視座の高さとか視野の広さっていうのは「理想」をどれだけ見れているのかってことなのかもしれない
  • エンジニアなら勉強会に参加しよう、みたいなのは社外の大きな世界で高い「理想」に触れてほしいという思いからなのかもしれない
  • キャリアパスってどう考えてる?なんて面談で聞かれるのは「理想」と「現実」をどう捉えていますか?という質問なのかもしれない

しれないしれない問答。思い当たるところがたくさん?

「実行」について……どんなに「理想」と「現実」から良い「方法」を見つけても「実行」されないと意味がないはず。なんだけれど、個人的にはコツコツやらないといけないここが難しい。どれだけ早く理解できてもやらなきゃなにもはじまらない。結果が見えた気になってるだけだとダメ……そう思って、意識してこれを書き始めたのかも。

はじめに戻ると、

「理想」と「現実」のどっちも認識してそのギャップを埋める「方法」を適切に見つけ出した上に「実行」できること。それは大変に困難なことなのではないだろうか

だから、きっと工夫の仕方や考え方のフレームワークという形で「方法」がたくさん別の名前で存在しているのだろう。けれどもそれはやはり「方法」でしかないので気をつけないといけないのかなって。

「理想」のところを目的とか 5W1H でいう Why のところに置き換えるとまた違ったことが考えられるかも?時間切れなのでまた考えてみようー