portal shit!

Memolist.vim の保存先を Dropbox にする運用を長年続けてきたが、 iOS の Markdown エディターの iA Writer で編集時にファイルが無限複製されるという問題があることや、最近のポリシー変更で Dropbox を無料で使い続けるのは難しそうかつお金を払うにしてもプランが高め（最安でも ¥1,500 / 月で 2TB まで使えるプランしかない）で個人では使いづらそうなので iCloud Drive を代わりに使ってみることにした。 iCloud は今のところ無料で使ってるが 50GB 使えるプランでも月額 ¥130 なので個人で使いやすい。 iCloud Drive は Windows や Linux からは使えないが、 Linux デスクトップはもう何年も使ってないし、 Mac と iPhone にロックインされた生活に不満はないので無問題。

移行の手始めにまずは iCloud Drive にターミナルでアクセスしようとするが、 cd ~/iCloud\ Drive などではたどり着けない。以下の記事を読んで調べた。

ターミナルからiCloud driveに移動する方法 - Qiita

#iCloudを使う理由 職場でDropBoxを使っていて、クラウドで保存するのに慣れていた。 私用ファイルの保存場所としてiCloudを使ってみる。 #iCloud Driveはどこにあるのか やりたかったことは、 `pwd i...

qiita.com

パスは ~/Library/Mobile\ Documents/com~apple~CloudDocs で良いみたい。

~/Dropbox/memolist ディレクトリを ~/Library/Mobile\ Documents/com~apple~CloudDocs/Documents/ ディレクトリに移し、 .vimrc を以下のように書き換えた。

diff --git .vimrc .vimrc
index 6c4987e..56882b2 100644
--- .vimrc
+++ .vimrc
@@ -568,7 +568,7 @@

     " memolist.vim {{{

-      let g:memolist_path = "~/Dropbox/memolist"
+      let g:memolist_path = "~/Library/Mobile Documents/com~apple~CloudDocs/Documents/memolist"
       let g:memolist_unite = 1
       let g:memolist_unite_source = "file"
       let g:memolist_unite_option = "-auto-preview -start-insert"

これで Memolist.vim の Markdown ファイル保存先を iCloud Drive に移行できた。

ソフトウェアエンジニアからプロダクトマネージャーにジョブチェンジするにあたり、社内説明するために作った資料を公開します。プロダクトマネージャーという職種はプロダクトマネジメントについて書いてある本（シリコンバレーの PM が書いたもの）でも「定義は会社や組織によって異なる」とあるので、自分の会社でも役割を明確にしておく方がやりやすいだろうと思って作りました。プログラマー/エンジニアは How にフォーカスするけど、プロダクトマネージャーは What にフォーカスする職業だなぁと最近は思っています。

以下は HTML バージョン

プロダクトマネージャーの役割

ソフトウェアを継続的に企画・製造してユーザーのニーズを満たし、ビジネス上の成功を実現する

ビジネス上の成功とは何か？

Product/Market Fit

※図は Dan Olsen のスライドから引用

Product/Market Fit とは何か？

良い市場を見つけ、市場の要求を満たすプロダクトを作る

なぜ Product/Market Fit が重要か？

すでにある製品を買ってくれる相手を探すより、市場に存在する問題を解決する製品を作る方が簡単だから

なぜプロダクトマネージャーが必要か？

• Market Driven な製品開発
  Market Driven でプロダクトを作っている会社の方が 31% 儲かりやすい
• 組織のゴールが明確になり、プロダクトのリリースと収益化が迅速化される

（良い） プロダクトマネージャーは何をするのか

• 何が作る価値があるものか、何がそうでないかを明らかにする
• すでに市場（ユーザー）で価値の検証が済んでいるものだけを作る

エンジニア・デザイナーとどう違うのか

• エンジニア・デザイナーは解決空間を担当
• プロダクトマネージャーは問題空間を担当する

具体的な役割

• ユーザーヒアリング
• 解決すべき課題の定義
  すでに存在する問題だけではなく、ユーザー自身も気づいていない問題も定義する
• 作るものの定義
  機能要件、スコープ
• 成功の定義とメトリクスの計測

※図は Making It Right から引用

プロダクトマネージャーが扱うデータについて

• データ分析チームとは異なり、ありのままの現実を調べる
  線形解析とか難しい統計とか機械学習などは担当しません

まとめ

• Product/Market Fit がミッション（ Objective ）です
• どうやったら Product/Market Fit したかを含め、成功そのものを定義します
• 成功するプロダクトを作ることに注力します（ Engineering からは身を引きます）

参考ページ

• Amazon.co.jp: Making It Right: Product Management For A Startup World (English Edition)
• Mastering the Problem Space for Product/Market Fit by Dan Olsen at Mind the Product San Francisco 2018 on Vimeo

ヒトデさんの以下のツイートを目にして便利そうだと思ったので fish + peco + vim でやってみることにした。

VSCodeの下にくっついてるターミナルで git ls-files | peco | xargs code とかやってファイルを開くと快適にファイルを探せて便利

— 趣味はマリンスポーツです (@hitode909) June 20, 2018

以下のような fish 関数を追加した上でショートカットキーを bind しておいた。

function peco_gitlsfiles_vim
  git ls-files | peco --query "$LBUFFER" | read selected
  if [ $selected ]
    vim $selected
  end
end

function fish_user_key_bindings
  fish_vi_key_bindings
  bind \cg\cv peco_gitlsfiles_vim
  bind -M insert \cg\cv peco_gitlsfiles_vim
end

これまで一旦 vim を閉じてしまうとファイルを開きたいときには vim . して Unite で調べててたけど、いきなり git ls-files して peco して絞り込めるようになってとても便利になった。

302 Found

blog.craftz.dog

↑の記事を読んで tmux でウィンドウを上下分割して、上でコード書いて下でテスト実行したりするの便利そうだなと思ってまねしてみてる。とてもよい。

ただ分割比を調整するために毎回何度かキー入力が発生するのがいまいちだなと思っていた。 tmux のセッションを開始するときにしかこのコマンドを実行することがないので面倒だなと思いながら都度手動で調整していた。

しかし tmux には select-layout という機能があって、 Control
+b + Alt+1 とか入力するといい感じに pane を配置し直してくれることを思い出した。上下分割は C-b + M-3 に main-horizontal というスタイルが割り当てられており、上の pane をメインにして上下分割してくれる。このとき main-pane-height という設定項目に任意の値を設定しておくと分割した pane の高さを指定できるようだった。デフォルトだとメインの pane の高さは小さめなので自分は set-window-option -g main-pane-height 60 にしておいた。これで tmux を起動してウィンドウを水平分割したあと C-b + M-3 とやるだけで 8:2 くらいで二つの pane に水平分割されるようになった。ちなみに左右で分割したときの値を調整したい場合は set-window-option -g main-pane-width 230 などとしておけばよい。便利。

fish-shell に移行 してこれで .zshrc のお守り業から解放されたと思ってたが、最近異常にシェルの新規セッションの開始が遅くて死にそうになってた。特にやばいのが git mergetool したときで、これは内部的には沢山の fish のプロセスが起動して diff を調べて最終的に vimdiff で表示しているように見えた（僕は git config editor=vim です）。下手するとちょっとしたコンフリクトを修正するために vimdiff が起動するまで 15 分くらい待たないといけないことがあって、 20 年くらい前の Photoshop 作業の現場¹みたいな感じになってた。これはかなりやばくて、生産性ががた落ちになる。 vimdiff が開くまでに待っている間に他のことやり始めて、気がつくと平気で夕方になってたりする。

fish-shell のバージョンを 2.7.0 に上げたことが原因かと思って、かつて快適に使えていた fish のバージョンに下げたりしてみたが解決しなかったが、以下の記事にたどり着いて $fish_user_paths への値の push をやめたところ解決した。

fish shellの起動が遅くなった時の解決方法 - Qiita

# TL;DR - fish shellの起動に3〜4秒ぐらいかかるようになった。 - `config.fish`の`$fish_user_paths`の設定方法に問題があった。 - この問題の原因と解決方法をまとめた。 # 何が...

qiita.com

fish-shell での PATH の通し方として以下のようなのがよく出てくる。 Homebrew で keg only なやつを入れたときにも表示される。

set -U fish_user_paths $HOME/Library/Python/2.7/bin $fish_user_paths

しかしこれをやると $fish_user_paths にどんどんパスが積まれていってしまう。どうもこれが原因で遅くなるようだった。自分の環境でも echo $fish_user_paths してみたところかなり酷いことになっていた…。

↑の Qiita 記事では set -U fish_user_paths するときに第三引数を消せとあったが、それでは根本的な問題の解決にならない（ Python やら Ruby やらいろんなものの実行ファイルを PATH に通したいはず）。自分は以下の方法で解決した。

set -x PATH /usr/local/bin $PATH

bash や zsh で export PATH=/usr/local/bin:$PATH とやるのと同じオーソドックスなやり方だと思う。

これだけではこれまでに散々肥えた $fish_user_paths は残ったままなので適当に set -U fish_user_paths '' とかやってあげると空になって起動が速くなる。

fish-shell の set -U はセッションをまたいでグローバルかつ永続的に設定される変数定義の方法っぽいので下手するとその環境で fish を使い始めてからずーっと残ってしまう可能性がある（端末を再起動したらリセットされるかも知れないけど）。

まとめ

• set -U は基本的にしない
• $fish_user_paths は設定ファイルの中では使わない
• PATH を通したいときは set -x PATH を使う

Mac の Day One を 2.1.8 にしたら日本語の文章を入力できなくなってしまった。正確には入力出来なくなるわけではないが、日本語を入力して変換したあと確定すると変換した文字列が選択済みの状態になり、続けて文字を入力しようとする消えてしまうというもの。こんな感じ。

Mac の Day One をアップデートしたら ATOK で入力し確定した部分が選択状態になってしまい、続けて入力すると前に書いてた部分がどんどん消えていくようになってしまった。つらい。 pic.twitter.com/HxEq8cjHUg

— 森井ゴ (@morygonzalez) April 27, 2017

なんか文章を書きたいと思っても入力できなくなるのきつい。最近は iPhone でも Mac でも読んだり書いたりできるのが便利で Vim を使わず Day One に直接文章を書くことが多くなっていた。書けないとなると結構ストレス溜まる。はよ直して欲しい。

追記（2017/05/08）

2017/05/04 に修正版リリースされてたっぽい。試してみたところ直ってた。

Lifehack (笑) 臭がしてこれまでキー入力拡張みたいなアプリケーションを使うのは敬遠してたんだけど（そもそもああいうのは IME がないアスキー文化圏の人向けだと思ってた）、 Pull Request 出すときのテンプレートとかを一発で出せたら便利だなと思ってその手のやつを使うことにしてみた。

有名どころだと TextExpander がある。試してみようとしたら何と月額課金に移行してて買い切りではなくなっていた。しかも結構高い（年額 $40）。いろいろ物色してたら昔何かの bundle で購入していた Typinator というやつがあって、こいつならアップグレード料金で使えるし買い切り型だったので使ってみることにした。新規で買っても EUR 24.99 で TextExpander の年間使用料より 1000 円くらい安い（24.99 EUR = 3061.5624 JPY）。

良く入力するやつを省入力できて便利

仕事で Zoom というビデオ会話ツールをよく使う。 Zoom には電話番号みたいに個人に紐付く固定の URL が存在してて、誰かと話したいときにそれを Slack 上に貼りつけて会話を始めたりする。この URL をいちいち Zoom を開いてコピペするのめんどいので ,zoom と打つと出せるようにしている。一瞬で MTG 始められて便利。

,dt と打って2017-03-11 のように今日の日付を表示させることも可能（入力キーや日付・時刻のフォーマットはカスタマイズできる）。こういう機能は ATOK にも付いているけどスペースキーを押したりリターンキーを押して確定したりしなくてよいのが快適。 ふむふむ～、ナルホディウスですぞ のような変換に何度も文節を調節したりしないといけないやつも ,naruho と打てば出せるようになってチャットが円滑に行えるようになった。

長めのやつも展開できて便利

冒頭に書いたように、 Pull Request 出すときに使ってる定型文みたいのがあって、過去の Pull Request からコピーしてきたりしていたのが一発で入力できるようになって異常に便利。 pullreq と入力するとシュバッと展開されるようにしている。こんな感じ。

ATOK に辞書登録するのとは違って改行を含んでいてもいいし、日本語入力モードに切り替えなくても良いのが便利。

inputrc で vi mode にしている Terminal (iTerm.app) で使うときの問題点

Typinator には GItHub みたいになってしまうのを抑制する機能がついてて、大文字が二文字連続したあとに小文字が入力されると自動的に二文字目を小文字に変換するという機能（ GItHub を GitHub に直してくれる）がついている。 Typinator は vi mode でシェルを操作しているとかは判別できないので勝手に補正してくれて上記のようなキーストロークが bbi と修正されてしまう。

Vimmer なのでシェルの操作モードを vi mode にしているのですけど、単語移動するときについつい

Shift + b Shift + b i

とか入力してしまうと Typinator が反応して bbi に補正されてしまってうざい。

設定に DOuble CAps Exception というのがあって例外設定できるみたいだったので BBi を追加してみたけどどうもうまく効いてないみたい…（ bbi に補正されてしまう）

さらに詳しく設定を調べてみると、アプリケーションごとにルールの有効・無効を切り替えられるっぽいので、 iTerm を使っているときは連続する大文字の小文字補正を行わないことにしてみた。これで様子を見てみよう。

301 Moved Permanently

www.ergonis.com