@kyanny's blog

My thoughts, my life. Views/opinions are my own.

Twitter のスペースについ肩入れしたくなってしまうのは、Clubhouse にみじめな想いをさせられた恨みからくるんだろうな、という自覚はある。

別に直接辱めをうけたわけではない。ただ、これだけ SNS が浸透して「実際に繋がりが発生している友達関係」が見える化された世界において、Clubhouse がとった「招待制」という手法は、一部の人たちにとってはあまりに残酷すぎたと思う。

招待制といえば mixi もそうだったし、やはり「まだ招待されてないの?」というプレッシャーは存在したが、「招待されてないことを自覚している自分」と「mixi を楽しんでいる奴ら」は隔離されていた。いまは「Clubhouse に招待されてない人」と「Clubhouse を楽しんでいる人たち」を第三者が同時に観測でき、その非観測可能性こそが恥辱の源泉となってしまう。

むかしプリクラが流行ったとき、「プリクラを撮ったことがない」ことはすなわち「一緒に撮る相手がいない」ことを表し、ゲーセンでプリクラのブースの近くを通るたびにみじめな気持ちにさせられたのと似ている。

スペースも「フォロワー何人以上のアカウントのみホストになれる」という縛りが(まだ)あるのはいただけないが、いずれ撤廃されて「誰も聞いてないツイキャス」みたいなスペースが乱立する日がくるのを期待している(どうせそういうのはアルゴリズムで非常に目立たなくなるのだろうけど、それはまた別の話)。

gh-pr-draft v2.2.0 をリリース

Release v2.2.0: Merge pull request #2 from kyanny/fix-missing-pr-number-in-output · kyanny/gh-pr-draft · GitHub

gh pr-draft と PR 番号を指定せずに実行したとき、メッセージに PR 番号が含まれず # だけになるバグがあった。数日前に報告されていて、修正コードも提供されていたのですぐ直せた。

GitHub CLI の extension って更新はどうするんだろう。remove してから install し直しなのか、install をもう一回やるだけでいいのか。


GitHub の Releases を作るときリリースノート(本文)で誰かをメンションすると Contributor として名前とアイコンが出ることを知った。

Bizmates Program: Level 2 Rank B Lesson 13: Recommending an idea

初めての女性トレーナーと。途中でこちらの回線が悪化して音声や映像が途切れ(チャットはずっと繋がってた)、こちらが MyStage に再ログインして治るということがあった。

今日のレッスンは進みが悪かった。次のレッスンに突入するだろうと思ってそちらの予習に時間を使ったら、このレッスンの準備にかける時間が少なくなってしまって、Try パートの 2 はちゃんと内容を考えておけたけど 3 は中途半端になってグダグダになり、Act パートに至っては Try の 3 の不出来を引きずったこともありシナリオが全然思いつかず、久しぶりに頭真っ白みたいな感じになって、残り 3 分くらいをずっと唸って過ごす羽目になった。完全に予習不足。反省。

今日のトレーナーは新しいフレーズとかをチャットに詳細な説明や例文付きで書いてくれる丁寧な感じだった。レッスン終了時には、途中で書き溜めておいたであろうこれまた詳細なフィードバックと改善ポイントなどをまとめて書いてくれた。アクセントなどは普通なフィリピン人講師という感じだった。話のつなぎで other than that, みたいなのを挟む癖があるっぽいが、ナザァとか言ってるように聞こえて実際なんて言ってるのか最後まではっきりわからなかった(ただ、話の本題ではないことは、何度も同じパターンの音が出てくることからわかった)。

  • How's your day at work?
  • Were there lots of patients in the hospital?
  • Lighten up – get more relaxed and less serious
    • ex. Just relax and enjoy yourself. Lighten up!
  • Are you going to be busy tomorrow?
  • A lot on one’s plate
    • =It shows that you have lot of work to do.
    • Example: Today, there are a lot of things in my plate as I am supposed to do an extra work of my colleague who is on leave.
  • Level 2 - Rank B - Lesson 13:Try Part #2
  • How do you suggest ideas at work?
  • I METICULOUSLY PROOF-READ the CONTENT of document / meticulous 最新の注意を払って
  • We have lots of newly hired employees.
  • We can move to a larger office
    • =instead of: more larger office
  • We can encourage the majority of employees to work from home with the exception of those who need to perform their tasks using company facilities.
  • It won't be possible to ACCOMMODATE all the employees in the office.
  • colleague =kol-eeg / 間違えて college って言ってしまったため(自分で気づいてすぐ言い直した)
  • Good points:
    1. You are very friendly and cheerful for tonight's lesson.
    2. You were able to concentrate on our main topic as well as provide concrete/specific examples for this lesson.
    3. You are careful with your thoughts and opinions as well as with your words.
    4. You were able to use expressions and vocabulary words accurately for your sentences.
  • Suggestions:
    1. Try reading aloud. ( English Articles) = It will enhance your articulation
    2. Try to talk with a colleague in English =at work, you can do this everyday
    3. Listen to English music or movie clips with subtitles.
    4. If you encountered an unfamiliar word, you can write it down in a notebook and you can search for its meaning during your free time.

blog.8-p.info

ソフトウェア開発者の仕事をしていた頃よりシェルスクリプトに触れる機会が増えた。ソフトウェア開発が職務ではなくなったのだからプログラミング言語を扱う時間が減ったのは当然だし、サーバサイドの技術サポートという仕事柄シェルスクリプトや込み入ったワンライナーを駆使してログを調査したりする機会も多い。シェルスクリプトは苦手なので、しばしば Ruby のワンライナーのお世話になっている(逃げている、ともいう)。

自分が仕事で扱う環境には Ruby がインストールされているので、込み入ったスクリプトを Ruby で書けて助かっているけど、一般的なサーバには Ruby がインストールされていないことも多い。そういう環境でも Perl と Python はだいたいインストールされているのでどちらかを使えばいいわけだけど、その三つの選択肢でジレンマを感じることがある。

Perl はワンライナーで正規表現置換をするとき $_ を書かなくていい*1のがエレガントだし、正規表現の /e (eval) オプションのように Perl ならではの強力な機能もあるが、JSON モジュールが標準添付されていないのが致命的だ。個人的に、二大「頻出だがシェルスクリプトで書くべきではない処理」は正規表現による文字列置換*2・抽出と JSON の扱い*3で、そのうち一方の用途を満たせないのは痛い。

Ruby はシンプルな正規表現置換でも $_.gsub() を書かなくてはいけないのが玉に瑕だが、機能面で不満はないので Ruby が使える環境なら Ruby 一択だ。正規表現の /e (eval) オプションはないが、String#gsub にブロックを渡すとだいたい何でもできるので、ワンライナーとしてはちょっと長くなることもあるがだいたい何とかなる。インストールされていない環境が多い点のみが困りどころだ。

Python は「どこにでもあって JSON を扱える処理系」として便利なのだが、ワンライナーを書きづらいのが難点だ。リスト内包表記を駆使すれば書けないこともないが、向いてないことは否めない。逆に、ワンライナーではないちょっとしたスクリプトを書く場合は、昨今の人気ぶりを考えると、読み書きできる見込み人口の多さという点で Ruby よりも好ましい選択肢なのかもしれない。Ruby を書いてると不思議と「もうちょっと短く・綺麗に書きたい」という欲が出てしまって余計な時間を使ってしまうことも多いので、トータルで考えると一番生産性が高い選択肢である可能性もある。

と、シェルスクリプトの代用品として考えたとき、三種類のメジャーなスクリプト言語にはそれぞれメリットとデメリットがある。問題は、どんな場合にも最善手といえる選択肢はないので、一つの作業のために Perl と Ruby のワンライナーをパイプでつないで使ったりしていると、「いっそシェルスクリプトで全部書いた方が潔いのでは」みたいな気の迷いが生まれることだ。言及先の記事の主張にあるように、awk だの sed だの jq だのを使っていたらそれこそ Perl と Ruby のちゃんぽんどころの話ではないのだが(理屈で考えればスクリプト言語を二つ使う方がずっとマシなのにシェルスクリプトにこだわりたくなってしまうのが「気の迷い」だ、ということ)。

2021/09/18 追記:

件の記事のはてブコメントで、これはと思ったものがいくつかあった。はてブコメントを読みふけるのも随分久しぶりだ。

シェルスクリプトを書くのをやめる - blog.8-p.info

bashでforを書きたくなったら、perlを使うことにしてる。bashでがんばってもいいことがないので。そしてperlはモジュールをインストールしたくなったら止めてpythonにしてる。

2021/09/16 11:53
b.hatena.ne.jp

これは良い指標だと思った。ちょうどいい塩梅の線引きに思える。自分に置き換えると、Ruby が使える環境では Ruby 一択でよく、Perl と Python しかない環境では「外部ライブラリが必要か」で使い分けると良さそう。実際、Ruby のワンライナーで -r xxx オプションを使うことはよくあるが、Perl のワンライナーで -MXxx オプションを使うことは滅多にない。

余談だが、新しめの Ruby なら bundler が、Python3 以降なら pyvenv がだいたい標準添付されてるので、一時的な用途で外部ライブラリをインストールする手段も確立されているのが便利だ。

シェルスクリプトを書くのをやめる - blog.8-p.info

Shell scriptで書いてたけど、リーダブルじゃないからRubyに変えて、Python嫌いだけどPythonに変えて、今はDenoで書いてる。シェル操作程度で、gemもpipもnpmもいらんかったんや。GoやRustはコードだけ紛失しちゃうから却下

2021/09/16 15:41
b.hatena.ne.jp

Deno に触れている人は他にもいた。Node.js の Ryan Dahl が新しく作った TypeScript の何かだっけ、という程度の理解だったが調べてみたら、コンパイルが不要なスクリプト言語なのに外部ライブラリの参照方法がいい感じにビルトインされていて単一ファイルで動くらしい。単一ファイルで動くパワフルなスクリプトは昔からの夢だった。しかも TypeScript をネイティブサポートしつつ JavaScript も使えるという。TypeScript を全然書き慣れないままなのにはちょっと危機感があったのだが(Node.js や Docker がブームになって普及したときよりも、乗り遅れが後々致命的になりそうな気がしている、Web の仕事を続けていく上では)、かといって Web フロントエンドで使うのは色々設定とか覚えることが多すぎて個人的に細々とやるには難しくて手をこまねいていたところだったので、TypeScript を書く機会を増やすのにもちょうど良さそう。Rust で描かれてるのもモダンでいいし、Deno 自体もワンバイナリで動くのでインストールも簡単と、いいことづくめに思える。


このエントリは、言及先の記事の主張に呼応した内容だし、著者が知人でもあるので、「Re: シェルスクリプトを書くのをやめる」というタイトルでもいいかなと思ったけど、まぁそこまで prominent にしなくても・・・という気持ちが勝って、結局また無題にした。

*1:sed と同様に

*2:BSD sed と GNU sed の違いで悩んだ経験のある人は同意してくれると思う

*3:jq -n で JSON を作った経験のある人は同意してくれると思う

note.com

出世してみたら大変過ぎて身体を壊したのでもうあんまり出世する気はないのだけど*1、強気な値段設定に興味をそそられたので買って読んだ。

有料記事なのでネタバレは避けるが、記事中で「出世のためのテクニック」として紹介されていた手順のうちのいくつかは、これまで出世を意識せずにやってきたことだったりしたので、「なるほど、『なんか物事がちゃんと回ってなくて気になる』みたいな理由で良かれと思って始めた活動が、周囲からは点数稼ぎに見えて反感を買うこともあるのか」という嫌な気づきがあった。


関係ないけど、こういうエントリに「Re: XXXX」というタイトルをつけたくなりがちだけど(トラックバック世代なので)、2020 年代のインターネットにおける言及の構図はもはや全然対等な関係性ではないのだから Re: はふさわしくない、かといっていちいち「XXXX を読んだ」みたいなタイトルをつけるのも勿体ぶっている感じがして億劫、ということで「無題」とすら書かない本当の無題が一番無難、という結論に落ち着いた。

*1:むしろ、どうすれば出世しなくても問題ないキャリアを手に入れられるか?を考えている。現時点では、「平社員のままでも人並み以上に稼げる仕事に就く」ために「平均給与の高い海外(アメリカ)の会社で職を得る」ことに成功し、今後の展望を見据えて「英語コミュニケーション力を磨く」ための自己投資をしている。