パルカワ2

最近はFlutterをやっています

Mac環境改善活動

ここ数年会社Macの開発環境がかなりいい加減でちゃんと設定してない状態だったので、久しぶりに整えるかという気持ちになったので整えた。

oh-my-zshをやめてZimに移行した

GitHub - zimfw/zimfw: Zim: Modular, customizable, and blazing fast Zsh framework

ターミナルを立ち上げるたびにずっと遅いな〜と思っていたので早いやつに移行しようという気持ちになって移行した。Sixeightさんのひさしぶりにzshに戻りました - ちなみに を参考にして色々設定した。ありがとうございます!

もっさりしてたけど、早くなったので良かった。

pecoをやめてfzfに移行した

GitHub - junegunn/fzf: A command-line fuzzy finder

pecoを愛用してたんだけど僕のiTerm2の設定だと色が若干見にくくて設定を直せばいいんだけどめんどくせ〜と思ってずっと放置してた。Sixeightさんの記事を読んでfzfを使ってみたら色も問題ないしpreviewとか出せて便利じゃんとなって移行した。

exaとかbatとかいれた

色がついてて綺麗!!!ただfzfのpreviewでexaを使ってるけど、colorを付けると文字がズレる問題があったのでオフにしてる。普通に使うぶんには困らないのでlsなど置き換えた。

Raycastで社内ドキュメントを検索できるようにした

Raycast

RaycastにNotion Extensionがあるんだけど、タイトル検索ではなかったりChromeの閲覧履歴を検索出来なかったり遅かったりしたので自分で作った。実は前から作ってたんだけど結構バグっていたり情報がなくて困ることがあったりしたので諸々直したりした。

SpotlightをやめてRaycastだけにした

元々はSpotlightとRaycastを併用していてアプリケーション検索はSpotlight, その他はRaycastを使うという感じで使い分けてた。前はRaycastだけだと満足出来なくて併用してた気がするけど理由は忘れてしまった。

RaycastのQuicklinksを設定する

ちゃんと設定すれば便利な気がするなと思ったので設定した。例えば特定のプロジェクトのFirestoreを開きたい時はRaycastのQuicklinksを設定しておいてそれを使って開くと早い、みたいな。ブラウザのブックマークを検索できるSearch Browser Bookmarksもあるけど、Search Browser Bookmarksを選択して検索するみたいなのがめんどくさいのでQuicklinksにした。

RaycastのExtensionをいれる

たくさん入れても忘れるので自分がよくやることを解決するものだけ入れて使わないコマンドはオフにした。

前はJIRAのExtensionとか入れてたけど結局使ってなかった。検索するよりボードの一覧を見ることが多いので自分が見るボードのQuicklinksを追加するみたいな感じで自分の行動に合わせるようにした。

まとめ

Raycast便利。ただScriptの結果をFilterしてアクションするみたいなfzf的なことが出来ない。AlfredはできるらしいのでAlfredのほうが便利かもしれない。あとRaycastのExtensionで日本語を打つとEnterキーで遷移してしまうバグがあるのがずっと直ってない。Alfredのほうが良い気がする。ただExtensionの開発が楽しいのでRaycast使ってる。

マウスピース最高!

社会人を10年くらいしているとやりたくない仕事は当然ある。そういう仕事をしている時に1 on 1とかすると「いま歯を食いしばってる」と僕は言ってる。

歯を食いしばるのってパッと見あんまり辛くなさそうだけど、長期間やっているといつの間にか歯はかけるし、顎は痛くなるし、頭痛はひどいし全然良いことがない。なので歯を食いしばるのをやめるか、食いしばっても問題ないようにする必要がある。

実際、寝ている時に歯を食いしばる人はマウスピースをして歯の食いしばりを軽減している。僕も寝ている時に付けていて頭痛がなくなったのでかなり最高

そういう感じで歯を食いしばってる時に息抜きになる仕事(プログラミング)をマウスピースとして用意することで歯の食いしばりも楽にしたら最高だと思う。

仕様書を浸透させるために仕様書のあれこれを決めた

仕様書を浸透させるために何が必要か?

品質の作り込みをしていきたい・仕様を把握するコストが高いので仕様書を書くことを会社全体で浸透させたいと思っていて、そのために書く・読むの負担軽減が重要だと考えて以下をやることにした。

  • 仕様書の項目を減らす
  • 仕様書フォーマットの統一
  • 仕様書の命名規則を決める
  • 統一されたフォーマットに沿ったテンプレートの作成
  • 管理方法の明示化・単純化
  • 仕様書作成・更新・廃止プロセスの明示化
  • 仕様書の具体例の作成
  • 仕様書を書くときに迷いそうなときに参照するガイドの作成または作成の依頼

実は一回シンプルなフォーマットを決めたのだが、自分の進め方が悪くそれが全く浸透しなかった。その反省を踏まえて上記を考えた。

仕様書の話は、このあたりの話に関係する。

ちなみに仕様書は、Notionで記載している。

実際のフォーマット

解決したい問題となぜやるのか

  • 実際に起きている問題を記載する
  • 目標となる指標がある場合は、指標も書くと尚良

言語定義

  • 仕様書内で利用する言葉を定義し認識を揃える
  • 社員なら知っているであろうと思う言葉も記載することを推奨

ユーザーストーリー

  • ユーザーストーリーを記載し開発メンバーと何をつくるか認識を合わせ考慮漏れを発見する
  • ユーザーストーリーはデータベースで管理する
  • データベースのプロパティは任意で追加してもよいが、ステータスが開発が終わった時点で非表示または削除することを推奨

仕様詳細

  • システムの制約やロジックを記載する
  • 開発者が設計時に作成するもの・お客様やスタッフが知っているべき情報等は、ここには記載しない

システムの制約とロジック

  • システムに関する制約や価格の計算方法などのロジックの詳細を記載する
  • 文章が長くなる場合は、表にまとめて記載する
  • 実例を記載することを推奨

関連

  • 仕様書に関連するメンテナンスされないフロー情報やリンクを記載する
  • 具体的には、仕様作成時のメモ・FAQ・図・議事録・QA成果物・JIRAやFigmaのリンクなど

決め方

前回の失敗の反省を活かして自分の中でテーマを持って取り掛かった。

複数のプロダクトマネージャーを巻き込む

仕様書を書くという労働に責任を持つのはプロダクトマネージャーなので諸々決めるときに一人で決めずにプロダクトマネージャーと一緒に決めた。例えば、最初に仕様書の項目はプロダクトマネージャーと一緒に仕様書を実際に書いてみてこの項目は必要だねとか話したりしていた。

自分はソフトウェアエンジニアなので、この仕様書は書きやすいとか読みやすいと思ってもプロダクトマネージャーがそう思わない可能性はあってプロダクトマネージャーの意見のほうが重要だと考えたからそうした。話すことでシンプルになったりした。

小さく始める

フォーマットに関する事だと言語定義はユビキタス言語大統一データベースみたいなのを用意したい気持ちになっていたのだけど、まずは始めることを意識してそれは問題にぶち当たったら考えることにした。他にもユーザーストーリーに具体例を用いるとかそれを使ってテストの自動化だとか色々考えたけど今回はやめた。

あとは仕様書に関することを決めるときにプロダクトマネージャーを呼んでいたけど、全員呼ぶと話がまとまりにくそうなのと全員空いてる時間を見つけるのが大変なので全員は呼ばずに詳しそうな人か興味がありそうな人を自分含め3人以上になるように呼んでいた。

継続的にチームで改善していく

対話だ!!変化への対応だ!!

やらなかったこと

仕様書の浸透で必要なことに「心理的負担の軽減」というのも考えていて、仕様書という名前をやめてminispecにするとか考えたのだけど、心理的負担の軽減はチームで取り組むことによって軽減していくのがよいと思って一旦仕様書という名前ですすめることにした。

あと開発チームやプロダクトマネージャーが決めればいいと思うのでレビューの仕方とかも決めなかった。

まとめ

仕様書のあれこれを決めた。しかしこれで終わりではなく始まりだ!!!!!!!!!!!

open.talentio.com

open.talentio.com

DEEBOT N8+を買った

プライムデーで安くなっていたので買った。普段は69,800円くらいで買ったのは45,000円くらい。安くなっていたので結構勢いで買った。

前はルンバ876を持っていた。当時7万くらいで買ったけど今見たら5万くらいで売られてる。高い。 ルンバ876を今買う人はいないと思うけど、ランダムに動くので時間はかかるし、バコバコ突撃してくるし、清掃中の音はうるさいし、清掃予約はバグってて時間がズレまくって使い物にならないしで褒められるところはほぼなかったんだけど、ないよりはマシという感じだった。掃除機を買ったあとは、ほぼ使ってなくて置物状態だった。

DEEBOTは同僚に勧められて一番モリモリのDEEBOT X1 OMNIを買おうかなと思ったんだけど、プライムデーでも13万くらいしたのでやめておいた。でも次は一番モリモリを買うかも。

DEEBOT N8+は、ルンバ876と比較するとマップを作って掃除をするので効率的(2LDKを20分くらいで掃除する)だし、突撃してこないし、清掃中の音は結構静かだし気に入ってる。清掃予約はバグっていて1時間ずれてるのが気になるけど今問い合わせてる。アプリの出来は正直良いとは思えないけど、清掃予約したあとはそんな触らないので大した問題ではない。

掃除できてるかどうかで言えば、普通に出来ていて髪の毛が落ちてる率が減った。まあただDEEBOTだけで良いかというと微妙で扉の関係で掃除出来ない部分はあったりする。DEEBOTだからというよりはロボット掃除機の課題な気がする。なので買った掃除機は使ってる。ちなみに水拭きはまだ使ってないのでよくわからない。

びっくりしたのは、ゴミをステーションが自動回収してくれるんだけどその時の音は本当にびっくりするくらいでかい。最初聞いたときはでかすぎて一人で笑った。まぁでもずっとうるさいわけじゃなくて数十秒だけなのでまだいいかな。

追記:清掃予約の時間が1時間ズレるのは、タイムゾーンがずれているからだった。"スマート清掃に入る" をタップ → 右上の三点をタップ → "その他の設定"タブを選択 → タイムゾーン で設定できる。

メモアプリを探し続けてCraftに落ち着きそう

5年以上Bearを使っていたのだが、会社の方針でiCloudが使えなくなってしまい同期が出来なくなった。同期が出来ないと元々Macで書いたメモに対して川を眺めながら書き足したい時とか川で雑にメモを書いてから帰ってきてからiOSでメモしたものをMacで再度書き直したりしていて困っている。

このあたりを満たしたい

  • iCloud以外のなんらかの方法でMobileとDesktopが同期される
  • Mobile, Desktop共にさっと書き始められる
  • NotionやBearのようにプレビューと編集が同じエリアである
  • iOSアプリならiOSらしい動きをすること。AndroidWindowsは使ってないのでなくてもいい
  • 同期のリアルタイム性はあんまり気にしないが早いに越したことはない
  • Dark mode対応
  • Bearの使い心地をなるべく再現したいけど無理なら諦める
  • オフラインでも書けるといいけど優先度は低い

色々試したけどCraftにした

  • Inkdropは編集画面とプレビュー画面が別で画像を貼った時に確認するためにプレビューに目を移動させるのがめんどくさい。NotionやBearに飼いならされてるので……
  • Noitionはさっと書きにくい
  • Joplinは編集とプレビューが分かれている。iOSアプリがスワイプで戻れなかったり使いにくく感じる
  • AgendaはBearと思想が違いすぎてちょっとむずかしく感じた
  • Scrapboxはさっと書きやすいし気に入ってる。Scrapbox記法とMarkdown記法が別ものなので、仕事ではコンテキストスイッチが必要で困った
  • Google KeepはScrapbox同様に公式ではMarkdownに対応していない
  • iA Writerは、リンクをクリックしても動かなかったりするので困った。あとiCloud以外での同期の仕方がわからなかった
  • Simplenoteは、画像のプレビューが出来ないっぽいので諦めた
  • Day OneはBearの前に使ってた。不満はほぼないけど、タグ周りがちょっと微妙だなぁ
  • Craftは、見た目綺麗だしBearのMarkdownをImportできる。ドキュメント量的には課金は必須な気がする。月$5だからBearと比べると高いけどBearが安すぎると思う。CraftならNotionでもいいんじゃないか感が出てくるけど、アプリがよく出来ていてさっと書く時の書きやすさはCraftのほうが上だと感じた

Craftのメモ

  • フォルダを選んでCommand + Nでドキュメント新規作成
  • Control + Nで日毎のクイックノート
    • 自前のショートカットと被ってしまった………
    • まあでも使わない気がする
  • タグもやろうと思ったらできるけど、フォルダ管理にする
    • 10X Notion, 10X Product Blog, Personal Blogとかアウトプットする先でフォルダを分ける
    • Bearのときもそうやっていた
    • BearだとURLにしていた
    • このあたりはもっといい方法あるかもなぁ
  • Craft eXtensionおもしろそう
  • BearからCraftにすべてのファイルをインポートしたけど、タグの情報は考慮されないから全部同じフォルダに入れるしかない…………
  • ちなみにこの記事もCraftで書いた。

20歳の自分に受けさせたい文章講義 を読んだ

なぜ読んだか

文章を書くことが仕事の一部なので良い文章を書きた〜〜いと思って読んだ。2017/2/7に買ってたらしい。

なにを得たか

  • 文章を書くためにまず書く
  • 接続詞を使うことで文章が支離滅裂かわかる
  • 視覚リズム、句読点・改行によって圧迫感をなくす
  • 聴覚リズム、読む時に句点を打つ・言葉の重複をなくす
  • 断定は強い。一方で反感を生むこともある
  • 日常文は導入が大事
  • 主張・理由・事実(順番は問わない)
  • 読者の椅子に座る、N年前の自分または特定の人の椅子
  • 読者は集中して読まない
  • 読者を動かすための納得アプローチ
    • 当事者意識を持たせる
    • 仮説を提示
  • 起承転結: 冒頭に自らの主張とは逆の話を持ってくる
  • 自分でツッコミをいれる
  • 目から鱗は3割
  • 推敲とは編集(切る・貼る・足す)
  • 論理性のチェック、図に出来るか

「話せるのに書けない!」人のための“文章の授業”と書かれていてそもそも話せないんだが…と思いながら読んだ。実際は話せるかどうかは関係なかった。 自分には特に後半が目から鱗が多く学びがありました。

まず書いてリファクタリングしていくという感じで、プログラミングじゃんと思いながら読んでいた。

「後回し」にしない技術 を読んだ

なぜ読んだか

仕事でクォーターの初めにこれをやろうという話をしていても結局できないみたいなことがここ最近続いていて、そろそろ後回しをやめたい気持ちになってきたので読んだ。

なにを得たか

  • 逆算スケジュール
  • 代替案を作る
  • 開始デッドラインを決める

まあそうだねという感じの内容だったんだけど、決心するの部分が主に参考になった。

仕事で理想の形を定義して現状と比較して現状から1歩ずつ進めていくというのはやっている。現状から理想の形にするには、どのように変更していくかを考えるときに、まず現状から次の段階を考えていたけど、理想の形から逆算的にスケジュールを決めるのはやったことがなかったのでやってみようと思った。

またクォーターの初めにこれをやろうと言って毎回できなくなっているのは当然理由があってそういうことが起きるのはしょうがないと思いつつ、そうなりうるのであれば代替案を用意しておけばよかったのかなーと読んでいて思った。