テーマは「情報収集について」

RSS

自分の場合、日常的なInputとして使っているのはRSS(Feedly)で大体以下のRSSかな

ほんとは他にもフォローしているブログがあったのだが、更新されなくなってしまった

まぁはてブの人気エントリは1ヶ月で2000ぐらいあったりするので大体それ見とけばいいとなっている 基本的にタイトルは全て追っていて、気になったり知らないことに関して書かれた記事は読むという感じ

Twitter

Twitterもソースとして当然使っているが、とはいえメジャーな技術の記事は上に含まれているような気もする。

なのでニッチな技術に関してはその第一人者をfollowしておくとかで有用、例えばNixなら Domen Kožar (@domenkozar) | Twitter とか

たまに海外記事のまとめをReplyで翻訳し始める人間もいるので、そう言った場合に有用。

AWS

他にはAWS ニュースレターとかもAWSのアップデートを追う上ではまぁまぁ有効、最近は新サービス開始時にTokyo regionもおま国されないのが嬉しい

nixpkgs

github.com

nixpkgsのcommit logとか適当に見ているだけでかなりの情報がある、これは流石に全部見れんが

GitHub

遭遇したIssueはとりあえずSubscribeしとくと便利、あまりfollow機能は使っていない

Web

あと、なんか普通に仕事してたりTwitter見ていたら、知らないことって結構出てくるので納得いくまで調べることが多い

shell.nixとdirenvでプロジェクトごとに補完をいい感じにする

概要

HERPでは shell.nix をgit repositoryのrootに置いて依存関係を解決しているが、PATH がprojectごとに設定されるだけなので 例えば kubectl の補完が有効になるわけではない。

その課題を解決するために shell.nixzshの補完もうまく済ませるワザップを今回は書く。

zsh completion について

zsh: 20 Completion System

zsh の completionの仕組みをざっくり書くと、 FPATHをいい感じにして compinit すれば FPATHから解決されるcompletion用のscriptが実行され補完される

手法

FPATH用のderivation

まず、completionを集めたderivationを作る。

buildEnv というderivationの特定のディレクトリの集合体を作る関数があるのでそれを使う

FPATH = "${nixpkgs.buildEnv {
     name = "zsh-comp";
     paths = buildInputs;
     pathsToLink = "/share/zsh";
   }}/share/zsh/site-functions";

FPATHの設定

上記で作った FPATH$HOME/.zshrc で追加された FPATH に足せばいいのだが

安易な方法として shell.nix にFPATHを足してしまうと、そのまま上書きされて既存の補完の全てを失ってしまう

なので、 project_FPATH のような環境変数に一時的に保存する。

このまま nix-shell --run zsh のように実行する場合は, ZDOTDIR をshell.nix中で上書きするなどのコードをを足せば問題ないのだが、 いちいち実行するのが面倒なので direnvを使っている場合は工夫が必要になる。

use nix
path_add FPATH $project_FPATH

以下の理由でこのコードは動きそうに見えて動かない(人によっては動く)

direnvは .envrc の評価をbash上で行っており、評価した結果の差分を既存のshellに足すような実装になっている。(コレは echo $0 してあげるとわかる)

実はzshFPATH は exportされていない変数なので (コレは echo ${(t)FPATH} でわかる、コレをlocal変数と言っていいのかはわからない) bash上で評価した際に存在していない変数として扱われFPATHが上書きされる

なので direnvの評価が始まる前、つまり ~/.zshrc などで export FPATH (typeset でも可) しておく必要がある

export FPATH してない人間向け対応

世の中には export FPATH していない人間もいるので、そう言った人が projectに入って direnv allow した瞬間に壊れて cd するのも困るのは不親切という考え方もあるので対応をする。(考え方によっては学習機会を奪っている。人間は困らないと進化しないので)

上記で書いたように 評価がbash上で行っているので export -p した中に FPATH が含まれていなければ export FPATH されていないことがわかる

よって以下のようになる

use nix

if export -p|grep "declare -x FPATH" ; then
  path_add FPATH $project_FPATH
fi

compinitの設定

あとは compinit するだけなのだが毎回 compinit していてはダルい(ダルい)

なので direnv がhookで評価した後にFPATHが書き変わっていれば compinit するようなhookを作ってあげれば良い

export COMPINIT_DIFF=""
_chpwd_compinit() {
  if [ -n "$IN_NIX_SHELL" -a "$COMPINIT_DIFF" != "$DIRENV_DIFF" ]; then
    compinit -u
    COMPINIT_DIFF="$DIRENV_DIFF"
    echo "compinited !"
  fi
}
if [[ -z ''${precmd_functions[(r)_chpwd_compinit]} ]]; then
  precmd_functions=( ''${precmd_functions[@]} _chpwd_compinit )
fi
if [[ -z ''${chpwd_functions[(r)_chpwd_compinit]} ]]; then
  chpwd_functions=( ''${chpwd_functions[@]} _chpwd_compinit )
fi

FPATH の diffを取ると言ったが色々考えた結果,nix-shell中でdirenv が実行されたときにcompinitされればいいので上記のようにした。(compinit以外のこともしたくなるかもしれない)

蛇足として一応書いておくが autoload compinit は他でするように

終わりに

nix-shelldirenv の組み合わせは環境を揃える手法として有名だが、実は補完まで揃えることができる。 各個人のzshrcに追記する必要はあるがオススメできる手法である。

余談

herp.careers

HERPのSREチームはnixを使って各種ツールの環境を揃えている。

KindleのアプリのUI悪い部分

概要

Kindleのアプリの体験が率直にいうと最悪なことはよく知られたことだが(ここで要出典と書こうとしたが「Kindle 使いにくい」をTwitterで検索するとたくさん出てくるのでここでは周知の事実として扱うものとする)

あまり言語化されていないようなので書く

一度読んだ本を最初のページから開くことができない

f:id:hiroqn:20220326231238j:plain

基本的に一度開いた本は読んだ途中のページから開かれる。それは当然いい機能だとは思うんだけど、ワンアクションで最初から開くことが何故できないのか疑問

読み終えた本、おそらく最終ページまで行った本は既読マーク(スクショで囲った部分)がつく

最後まで読んだという判定がありながら、本を開いた際に奥付けが表示されてユーザーが満足に思うと考えているのだろうか

ちなみに「未読にする」ボタンを押すと既読判定が消えるだけで開いた瞬間に既読になる、ジョークボタンか?

サマルとこれに関しては2点課題がある

  • ワンアクションで用意されていない
  • 最終ページまで行った本に対してのケアがない

しおり機能の誤判定が多い

f:id:hiroqn:20220326233113j:plain

スクショの赤線で囲ったあたりをタップすると、しおりを挟む機能がある

タップする、と簡単に言ったが再現性が非常に低く、おそらく画面とベゼルのぎりぎりのところをタップするとしおり機能が発動する、指が完全に画面内に入っていると駄目

f:id:hiroqn:20220326233101j:plain

ちなみに画面内をタップすると上のように「なんか色々できる画面」になる

実はしおり機能を使っていなんで、私の場合画面をタップする場合は100%2番目の画面になってほしいが結構な確率でこの「しおり」が発動する。

そしてしおりの解除がしたくてもう一度タップすると今度は2番目の画面になる

最悪だ...最悪ランキングの上位最悪体験である

別にしおり機能があることはいい、使う人もいるんだろう

この判定のピーキーさは本当にやばい、使ったら絶対わかる

絶対なんかあったはずで、しおり機能は例えば長押しするとか(現状長押しには何も割り当てられていない)、設定でしおり機能をオフにできるとか

表紙に戻るためのアクションが長い

f:id:hiroqn:20220326235522j:plain

「表紙に戻る」という行為はほんの一覧ページからできて然るべき、と言った内容は既に書いたが、実は本を開いている最中でさえ1アクションどころか3アクションかかる

スクショで示したように

  1. 画面の真ん中をタップする
  2. ハンバーガー亜種アイコンをタップする
  3. 表紙をタップする

の3手順かかる

さらに最悪ケースとして、稀に目次が細かく別れている本があるのだが、その本の場合「表紙」が出てくるまでスクロールする必要がある

必要なアクション数が多いことは最悪さの権現であるが、実は上記のフローに隠れ最悪UIが潜んでいる

それは2と3の距離が遠いということである

それだけ?と思うかもしれないが、やったらわかる、やってみなはれ鳥井信治郎

画面のアスペ比からわかると思うがこれはiPadであり(厳密には10.9inch のAir)私の指は11inchもないので片手で支えてもう片方で操作する

つまり2をタップする際に左手の指を使っているのだが(私の左手は左についている)、右手はiPadを支える状態になっていて右手は操作できない(しにくい)

なので3をタップする際にはiPadを持ち替えて右手でタップすることになる。わからん人間は仰向けになって寝ながら漫画読んでいる時を想像してくれ

あと、片手で全て操作したらいいのでは?って人間、買え!iPadを、でかいから

コレ、本当に最悪なんでこのデザインに決定した人のマウスを逆の手でしかクリックできないようにしてほしいし、実はちょっと前まで3のボタンが実は左にあったんでデザイン戻してほしい、切実に

サマリ

どこら辺にボタンがあると快適なのかを考えられてないなぁと感じるアプリは多い

私もiPadポートレートモードで持つこともあるし最強のボタン配置はないと思う

ただ、一部のゲームはボタン配置をいじれるようになっていて流石に体験がいいなってなる

あと、Desktop Webも同じ課題に向き合わなければならない

ちょっとした操作をするたびにポインタを左右に振らされるとゲンナリするし、その操作を何回もしなければいけない時には鬱になる、FPSじゃないんですよ

考えた結果それでも操作の距離が遠くなる場合、視線とポインタの位置を一致させる人が多いように感じるので、視線誘導を意識しながら配置すると良いと考えている

GitHubでrepositoryごとに権限が割り当ててある人間を探す

abst

GitHubの権限を真面目に管理することを考えると、やはりrepositoryに対してUserを紐付けることをやめたい。 つまりRepositoryに対してTeamを紐づける権限管理をやりたい。

しかし、Repositoryを作ったUserがadminとして設定されてしまう仕様や過去に適当に割り当ててしまっていた経緯から、いまだにRepositoryに対して割り当てられているUserを探して削除する必要がある。

今回はGitHubのGraphQL APIを用いて上記のようなRepositoryを探す

実装手法

以下のようなQueryにした。ORG_NAMEを書き換えること

query FindRepo($node_id: String) {
  organization(login: "ORG_NAME") {
      repositories(first: 20, after: $node_id) {
          totalCount
          pageInfo {
              endCursor
              hasNextPage
          }
          nodes {
              id
              name
              nameWithOwner
              collaborators(affiliation: DIRECT) {
                  edges {
                      node {
                          login
                      }
                      permission
                      permissionSources {
                          source {
                              __typename
                              ... on Organization {
                                  login
                              }
                              ... on Repository {
                                  nameWithOwner
                              }
                              ... on Team {
                                  slug
                              }
                          }
                      }
                  }
              }
          }
      }
  }
}

依存関係として、jq,ghが必要

TMP_FILE="$PWD/tmp.json"
DEST="$PWD/repo_list"
QUERY="$PWD/repo.graphql"

set -ex

gh api graphql -f query="$(cat $QUERY)" > $TMP_FILE
jq -r '.data.organization.repositories.nodes[]|select(.collaborators.edges|length > 0)|.nameWithOwner' < $TMP_FILE > $DEST
cat $TMP_FILE
while [ "$(jq -r '.data.organization.repositories.pageInfo.hasNextPage' < $TMP_FILE )" == "true" ]; do
  sleep 1

  cursor=$(jq -r '.data.organization.repositories.pageInfo.endCursor' < $TMP_FILE )
  gh api graphql -F node_id="$cursor" -f query="$(cat $QUERY)" > $TMP_FILE
  jq -r '.data.organization.repositories.nodes[]|select(.collaborators.edges|length > 0)|.nameWithOwner' < $TMP_FILE >> $DEST
  cat  $TMP_FILE
done

解説

Repository の affiliation: DIRECT にするとRepositoryに対してUserが紐づいた人が出てくる.

All collaborators with permissions to an organization-owned subject, regardless of organization membership status.

らしい

bashで雑にloopを回していく。

権限を取り除く

API経由でできなくもなさそうだが手で取り除いた。

正直、このコードはひどいな、と思いつつ...

for i in $(cat $DEST);do echo $i; sleep 2;done|xargs -n 1 -I @ open https://github.com/@/settings/access

ブログなどのコードはメンテされないので別のとこで面倒を見るためのリンク

scrapbox.io

財テク

このテーマ考えたの自分だけど、そんなに自分は資産運用に関してよく考えてないことに気づいた&そんなに資産がない

資産状況

NISA口座を開設した

この行動するまでに1年ぐらいかかった。しかしNISAは開設して終わりではない。入金して投資しなければいけない

今年中に終わることができるのだろうか

IDECO資料請求した

でも60歳まで引き落とせないのリスク高すぎるのでは?ってなって辞めた。

この制度、新卒で入った会社にずっといるタイプの人間じゃないと性格的に恩恵感じないのでは?それか個人事業主系の人

そもそも60歳って微妙すぎる。45歳ぐらいでFiredしたい人間には向いてない。制度として定年宣言をした段階で貰える&再加入不可でよくないか?

詳しくないので上のwazapもできるのかもしれない

Folio

folioやってる。130万ぐらい、そのうちロボアドが80万ぐらい。

NISAでやれって言われたらまぁそうってなる。

ふるさと納税

12月18日、ついにやった。

特に楽天経済圏にいる人間ではないが楽天を使った。

前はさとふるを使っていたが、ソフトバンク系のサービスは全て使わないようにしているんで辞めた。

生活費運用

私名義の共同の口座に定額入れる仕組みで運用している。家賃などはそこから落ちる。 あと B/43 | ラクして予算管理!家計簿プリカというサービスを使っている。共有のクレカが使える的なやつで、これはかなりベンチ

ついでに招待コード貼っておきます W4QDTL

もともと上記の共同の口座のキャッシュカードについているデビットカードで運用していたが不便だった。

B/43の不便点としては、スマホ決済対応してないのがある。

もともとKyashはQuickPayが使えて最近共有カードの概念を出してきたので、B/43も対応するんじゃないんですかね、知らんけど。

ちなみにKyashは初期使っていたけど、共有カードの概念がないのと資金決済法対応でサービスがガラッと変わったのでちょっと前に解約した。 まぁ色々察するところもあってしょうがないとは思うけど、便利な機能で客寄せしてコアバリューをガラッと変えてくる企業は私のポリシー的に使うことができない。

理想の働き方について

共著ブログ私信電信、今回のテーマは「理想の働き方」

理想の働き方と聞いて、働く上での姿勢と作業環境の2点が思い浮かんだ

働く上で大事にすること

¬ 友情・努力・勝利

これは解説すると「{信用,信頼} しない」「努力と感じることをしない」「終わりがない」と言う話

{信用,信頼} しない

一つ目は言葉通りだが、例えば

  • システムを組む上で人間を使う限りはミスや悪意を受容する。
  • 実績や過去の功績でコードやアーキテクチャに関する評価を決めない。
  • 自分が書いたコードはバグなく動くという誤った認知を持たない。

Trust But Verifyが言葉として近いかもしれない

ちなみに「信用と信頼は違ってTrustは信頼で〜」みたいなこと言うてる人間よくおるけど、日本にそんな文化存在せんから嘘やとおもてる。あるのは誰が腹を切るか決める文化だけ。まぁもっと最悪なのは腹切ることを責任と勘違いしている人間。

努力と感じることをしない

二つ目は、個人と仕事の話があって意味が若干違う。

個人の話は学習順序かな

たいして興味ないことに対して義務感で勉強するのはやめたほうが良い。精神に悪いし身につかない。 当然なんでも知っているに越したことはないが、興味が湧かない理由の一つに学習する上での前提として必要な経験や知識がまだ自分に足りていないんだな、と思っている。 そもそもその分野に興味がないなら時間は有限なので辞める。

仕事の話は、姿勢というか心掛けで

単に業務上必要な学習はコードを書く時間と比べてなんら変わらないただの"仕事"なので、いちいち努力と分けて考えない。

そもそも努力っていう言葉自体が僕自身の中で「行動の意図を理解しないまま頑張る」みたいな意味になってるかもしれん。

終わりがない

これはソフトウェア開発サイクルに終わりはないのでExitしようが開発は続く。"終わり"を前提としたソフトウェア開発は"終わり"より早く破綻する。

「これ、ちょっとの間しか使わないんで適当で」って作られたJobはそれが災厄を引き起こすまで動き続けるし、仮説検証のためのプロトタイプは大体書き直されることはない。

「だからちゃんと設計しよう」ではなくて「後悔しない意思決定にしとこう」みたいな話、終わりはないので。

「他に得意な言語はあるけど、聞いた感じ開発早そうなんでRailsで!これが適材適所!」

正気か?

作業の環境

音楽がかかっていると良い。「アトモスフィア;かかっている」が大事で自分でセレクトした曲が流れるのは好きじゃない。 音楽がかかっていないと?なんか気が散る感じがする。他人の気配とか話し声とか。 そもそも気は散るものなので散る対象が音楽に限定されるのが良いんかもしれない

歩き回れる方が良い。 癖かもしれないし慣れかもしれないが、思考と体の動きが動きが相関している気がする。

椅子はいい方がいい。今年に入ってherman millerのエンボディを買ったがかなり良かった。 ただ自宅がカフェとかに比べてひらけてない(=オープンでない=Not 鴨吻)ので、そこは不満

猫。 猫はストレスを極めて減らしてくれるが、仕事中に構って欲しがってくるので集中できない。危険

f:id:hiroqn:20211027192039j:plain

安易なSaaSのユーザー数課金は体験が最悪

サマリ

  • ユーザー数が増加しても、顧客の感じる価値が線形に増えない。
  • Entityに対して情報が公開されている範囲の制限できる場合、一部のユーザーはほとんど価値を感じていないが課金されている状態になる。
  • 全体のリソースはユーザー数に対して時間で積分した量になるので、ユーザー数が増えれば増えるほど価値を感じていない人間が増える。

ユーザー数課金をしているいい例

Slack

馬鹿みたいにprivate channelを作る会社でなければ、一人のユーザーに対して情報が制約されている状態にはほぼならない。 そもそも、一人の人間のとりうるコミュニケーション量は上限がある(と思われる)ので、でかい企業と小さい企業で一人のユーザーが体験する価値は(多分)変わらない。 また、guest などの機能はまともに使っていると実質無料でついてくる。

KING OF TIME

理由:(略)

これは労務管理している側と勤怠つけるだけ側に分かれるので、admin側ユーザ課金+一般ユーザー課金でもいいと思ったがユーザ課金だけらしい。

微妙な例

Google Worksapce

機能が多いのはいいことだが、会社全体でHardUseしていない場合、例えばインターン生のメールアドレスだけ発行したい場合などに高いなと感じる。

Entityに対して情報が公開されている範囲の制限できる場合、一部のユーザーはほとんど価値を感じていないが課金されている状態になる。

悪い例

読者(およびサービスプロバイダ)の課題とする

後書き

ビジネスの話はしていない。課金に対する体験の話をしている。 金を払うという行為は納得していないと体験として悪いと考えている。 例えば、時価で提供している飲食店もそうで注文した際に金額がわかっていればその時点でまずかろうが金を払うことに納得はしているが、後から金額がわかることは微妙と考える(特に美味しくなかった場合)。