先月分
雑記
CASECを受けて英語力が伸びてないことが分かった
CASECという英語力を測るCBTを受けた。勉強時間が足りてないとはいえ、仕事の一部で英語を使い始めて半年ほど経っていた。流石に少しは英語力が改善されているであろうと見立てていた。
微々たる量ではあるが、語彙も増えたし、以前より聞き取る力もマシになっているはずだと。
見立ては甘かったようだった。TOEIC換算のスコアを出してくれるのだが、あろうことか約1年前に受けたTOEICのスコア以下だった。
ディクテーションは、正直スタサプENGLISHのTOEICコースの方がよっぽど難かしかった。そのため、解いている最中に余裕だなと思っていた。蓋を開けてみれば、ディクテーションが1番低かった。なんじゃそりゃ。
これからの時期はマネージャになって初の期末だ。更に新居の完成や引っ越しやらがある。今までのように朝の時間を英語に費やすのが難しくなるかもしれない。せめて英語力をキープできるように単語だけは続けておこう。
初めてのキャンピングカーでネコママウンテンに行ってきた
初めてキャンピングカーはとてもワクワクした。一種の夢…的な部分がある。あのテカテカした鉄のボディの中に居住空間が広がるアンマッチさが心をくすぐる。
ネコママウンテンは福島県にあるゲレンデである。旧猫魔スキー場と旧アルプ磐梯を連結して2023年に生まれ変わった。
越後湯沢のゲレンデの交通の便が良すぎるが故に(僕は)忘れがちだが、山なので基本的に車移動が最強である。車がないと中々行けないところも多い。ネコママウンテンもそんな場所の一つだ。
友達がキャンピングカーのレンタルとネコママウンテンのリフト券などがセットになった美味しいプランを見つけて誘ってくれた。本当にありがとう。 星野リゾート内にある温泉に入り放題だったのが大きい。
正直、行く直前はデカい車を運転する怖さが急に大きくなった。キャンピングカーのワクワクを上回る勢いだった。終わってみれば、他の2人があまりに頼もしくて運転はなんとかなった。
めちゃくちゃ楽しかったが、更に満足度を高めるために持っていくと良いものがあったので、ここに残しておく。
- スリッパ
- 床が冷たい
- クラフトビール
- 冷蔵庫が付いている
- WCBのFresh Powderとか買って飲んだら多分エモい
- ココアパウダー
- 冷蔵庫ある故に牛乳も買える
- 夜はココアが良いかも
- 美味しいコーヒー豆
- 途中でスーパーで買えることに期待するなかれ
- 自分の好きな豆を買って持っていこう
- 自前の暖かい寝袋
- レンタルの寝袋は寒かった
- キャンピングカー内の寝る場所によって温かさが異なる
- 軽油を使った暖房の有無と使い方
- 電力をもらえるのは2日目の夜からだったので1日目はかなり寒かった
理由あって動画編集に初チャレンジした
理由あって軽く動画編集をする必要が出てきた。
チャレンジ自体はとても楽しくて有意義だったが、成果物のクオリティは高くなかった。YouTubeやテレビの編集ってすごいんだなあと実感した。
こんなにも自分の結婚式のムービーを自分で編集しなかったことを悔やんだ日はなかった。まあ、それはそれでプロにやってもらったからこそのクオリティはあって良かったのだけれど。
最初は字幕をつけるだけのつもりだったので、iMovieだけでいけるやろ！と軽い気持ちで始めた。
作り始めてすぐに、字幕の位置を自由に変えられないことに気がついた。「もうちょい下に置きたいな…」と思ってマウスオーバーしてみるも1ミリたりとも動かない。
結局、一旦黒背景をバックにピクチャインピクチャで合成する。その状態で一度動画出力し、範囲を指定してクロップする。
また、そのまま素材を使うと制限時間オーバーすることに気づき、発言の中にあるつなぎのフレーズや沈黙を切っていく作業が必要になった。波形見つつ切って確認を繰り返した。
やっていくと徐々に凝りたくなってくる。
静止画を上に乗っけたいな…。keynoteで透過画像を作り、ピクチャインピクチャで乗っけようとすると…置けない。あれ…なんでだ？と思いつつ調べると、どうやらiMovieは2レイヤまでらしい。なるほど。
3つ以上のレイヤを重ねたいのであれば、一度動画出力して、それをインプットに新しいプロジェクトを作るしかなさそうである。
後は、ヨビノリが理系すぎる漫才をM-1後によく上げているが、あれと同じ構図を作ってみたくて、うっかり時間をかけてしまうなど。
同じ背景で立ち位置を別にして撮影して、iMovieのスプリットスクリーンで合成すればいけるやろと思っていたが、スプリットスクリーンは各動画の真ん中部分の切り取り固定らしい。ベースの動画の右半分とオーバーレイの動画左半分で合成するというようなことができず落胆。
結局、1枚のバーチャル背景を半分に分け、それぞれの半分の背景で撮影し、スプリットスクリーンで合成することで同じ空間にいるように見えるようにした。
ということで、これでいつでも SREすぎるウエストランド漫才 とか出来る(?)
Adobe Premiere Pro が必要な理由が分かった数日間のできごとだった。
読んだ本
2月は、新居に関する準備や英語の勉強中心にやっていて2冊しか読めていない
チームを動かすIT英語実践マニュアル
仕事において、主にインドネシアのメンバと英語で会話する機会がある。Slackはもちろんのこと、1on1などのミーティングもある。
リスニングも危うい部分があるが、Google Meetのcaption機能がいくばくかサポートしてくれるのでマシになっている。となるとスピーキングが問題だ。どうしても表現が出てこない瞬間があり、会話が少し止まってしまったり、自分の中からニュアンスが少し違う表現を引っ張ってきてしまうことがある。
この本は、ITの仕事をするうえで頻度の高いシチュエーションごとに、よく使う表現や会話例、瞬間英作文などが用意されている。即効性が高くて良い。
takeaways
- フィードバック
- I was concerned about ~ や I’ve noticed ~で気になる行動について説明し、Do you mind if I ask why? のように聞いてみる
- How about~? で対応策を提案し、I’d like to see you -ing (あなたに~して欲しい)と確認の意味を込めて伝える
- I understand that ~, but try to be aware of~ のように共感を交える
- 1on1
- How was your weekend? / Any plans for the weekend? のように聞く
- How’s the current project going? のように相手独自の視点や考えを聞くことが重要
- 相手の要望を聞いても即答できないことがあるので、そのときは Let me get back to you on that. と言って前向きに受け止めていることを伝える
- 便利なフレーズ
- on a side note: ちなみに
- hold off: 延期する
- hold off「より良い状況やタイミングを待つ」
- put off「やる気がない、回避したい、または面倒だから後回しにしている」
- it would be in one’s best interest to ~: ~するのが最善である
- Could you elaborate on that?: それについて詳しく説明してくれますか？
持ち帰りたいものはたくさんある。 読み終えた今もたまに開いて、良さそうなフレーズやコツを思い出している。
心理学的経営: 個をあるがままに生かす
今いる会社の創業メンバの1人である大沢武志さんという方が1993年に出版した本。会社の輪読会で取り上げられたので読んだ。今の会社のシステムのベースに活きている部分が多く、どういう背景から生まれてきたのか理解できたのが良かった。
心理学について全く知らなかったが、そんな自分でも分かるように書かれていた。 1993年時点での研究データだと思うので、現代において再実験した場合にどのような結果になるのかはすごく気になっている。
ちなみに、16Personalities testが MBTIとは別物であることに気がついたのは本書のおかげである。詳しくは、Q 06: MBTIと検索するとよく出てくる16Personalities testというのは、MBTIではないのですか？ を参照のこと。
takeaways
- 官僚性組織論に代表される合理的組織の考え方は、最も効率の良いシステムを志向する。ただし、これらは人間存在の重要な側面（無駄な情緒や感情を基底に持つ）を無視している。
- 力に拠って強制しない限り、人々が現実に従っている拠り所になっているのはルールではなく、暗黙のうちに作られたお互いの合意であり、そこから生まれる規範（norms）
- 集団で定められた規範が集団の生産性について事実上決定的な影響を持っている
- 凝集性（集団のメンバをその集団に留まらせうる求心力）の高い集団は仕事における不安や緊張感が少ない
- エンカウンター・グループによって、日常の職場で超えることが難しい心理的なバリアーをなくし、グループ内で感情や思考をさらけ出し自己受容につなげることができる
- ハーズバーグの研究に代表される様々な実証的研究から、人々に強い職務満足をもたらすものは外部報酬ではなく、内的な達成要求や成長動機に根ざした主体的な行動である
- 最も効果的な目標の水準は個人にとって成否の確率が五分五分のとき
- 目標を与えられたほうが高い成果につながる（「できるだけ沢山」では成果は上がらない）
- フィードバックにも似たようなことが言えて、最も効果的なのは中程度に遅い者に対して
- また集団でも目標を持つこともモチベーションに大きく影響を与える
- 組織活性化はカオスの想像、ゆらぎの創出が出発点である
- 組織の内部にあえて不均衡を創出し、既存の秩序・規範を自己否定させる。そうすることで人々は不安と葛藤を感じる。この心の不協和を維持し続けることができず、これを解消しようとする。
- カオスの演出でリクルートが使っていた方法は「採用」「人事異動」「教育」「小集団活動」「イベント」である
- うまくいっている組織は管理者がリーダーシップを発揮しているか否かの差に起因するところが大きい
- 日本でのリーダーシップ研究で４つの因子が発見された（要望性、共感性、通意性、信頼性）
- これは山本五十六の「やってみせて（信頼性）、言って聞かせて（通意性）、させてみせ（要望性）、褒めてやらねば（共感性）人は動かじ」と符合する
- パーソナリティテストのデータは、評価情報というより、本人の自己理解の促進や職場適応を援助する道具として位置づけられることが望ましい
気になった記事
AWS Introduces an Experimental Low Latency Runtime for Faster, More Efficient Serverless Apps
AWSがサーバーレス環境に最適化した、LLRTというJSランタイムをオープンソースで開発している。 Lambdaで動作させたときに、他のJSランタイムに比べて最大10倍以上速く、最大2倍安くなるらしい。
なんでそんなに速いのかというと、
- コードとdependenciesを一つのJSファイルにバンドルしているので、ファイルシステムのlookupが走らないようになっている
- AWS SDKをpre-package, precompile, preload しておくことで、アプリケーション開始時にファイルのロードと解釈をスキップする
LambdaをAWSサービス間のglueとして利用する場合に理想的なランタイムだそう。
カスタムランタイムとして提供されていたはず。 ただ、まだ安定はしていなさそうなのと、node.jsとcompatibilityがない部分があるので、現状使い所としては限られそう。 AWS内部ではこういったランタイムに対する大きな需要はありそう。
LLRTはRust製とのことで、AWSはFirecrackerといいすっかりRustの会社感がありますなあ。
Pinterest’s Transition to HTTP/3: A Boost in Performance and Reliability
HTTP/3の情報をあまり追えてなかったので、この記事でキャッチアップした。そもそも、HTTP/3ってQUICをトランスポート層に利用したプロトコルだって知らなかった。 QUICの利点と混ぜて語られるので、ついでにQUICの復習にもなったかなと思う。
QUICで受けられる恩恵の他にも、大きなペイロードを扱う通信や輻輳制御における改善が入っているらしい。 Pinterestは画像多く扱うので、確かにクライアントCDN間のHTTP/3移行は効果ありそうだなあ。
CloudFrontでやろうと思うと、明示的にhttp3を許可する必要があるはず（デフォルトはhttp2）。後はモバイルアプリ側でライブラリのサポートだったりが必要なのかな？
HTTP/3の特徴を引用&メモ
- No TCP head of line blocking problem in comparison to HTTP/2
- Connection migration across IP addresses, which is good for mobile use cases.
- Ability to change/tune Lost Detection and Congestion Control parameters.
- Reduced connection time (0-RTT, while HTTP/2 still requires TCP 3-way handshakes).
- More efficient for large payload use cases, such as image downloading, video streaming, etc.
Go 1.22リリース連載始まります & ループの変化とTinyGo 0.31
GoがリリースされたらFuture Tech Blogを読む。
テストコードでよく、ループ変数が内部のクロージャから参照されるときに、 i := i を書いていましたが、それを書かなくて良くなったのは、common pitfalls が減って良かったのではないか。
まだ experimentalで入っただけだけど、range over function は使い所あるんじゃないかという気がするし、コードの可読性が上がりそうだなと思って期待している。 HTTPルーティングの強化もテストなどで役に立ちそうな気がしますなあ。 ちなみに、chiとgorillaとの性能比較結果は面白くて、それなりに大きいwebサーバを立てようと思ったらやっぱりchiを使うなと思いました。
