hamburger-tech-nits

主にプログラミングのNITSな話

開発生産性の向上で何をどこまで改善できるのか

開発生産性について盛り上がっている記事が定期的にバズっている。開発生産性が上がること自体は良いのだが、開発以外の生産性も上げないと意味がなかったりするのであまり引っ張られないようにしたい。

特に自社のプロダクトを提供していると、開発だけ早くても利益に結びつかないケースもある。漠然と開発生産性を上げる取り組みをするのではなく、それを上げたいモチベーションを言語化して周囲と意識合わせをしたほうが成果に繋がりやすい。意外とそこ以外が重要だったりするから。

  • もうちょっと企画をもんだほうがいいケース
  • 意識して遅くすることで、学習機会につながるケース
  • 価値提供と顧客コミュニケーションの速度があっていないケース

and more...

僕自身作業速度よりもチームの健全性とプロダクト成長のバランスを重視するタイプだから、開発生産性を第一に掲げられると少しギャップが出る。なのでそういうトピックでチームの会話が発生したときはそういう価値観であることを説明するように気をつけたい。

複数バージョンのXcodeをインストールしているMacでCommandLineToolsのバージョンを切り替える

とあるツールのインストール中。

$ brew install tool 
Error: Your Xcode (13.4.1 => /Applications/Xcode13.4.1.app/Contents/Developer) is too outdated.
Please update to Xcode 14.3 (or delete it).
Xcode can be updated from the App Store.

業務の都合上複数バージョンのXcodeを利用していて、今使っているメインは13.4.1。新しいバージョンを見るようにすれば解決しそうだなと思いながら調査開始。

$  xcode-select -v
xcode-select version 2397.

$ xcodebuild -version
Xcode 13.4.1
Build version 13F100

13.4.114.3に変更すべく、パスを指定する。

$ sudo xcode-select -s /Applications/Xcode14.3.app/Contents/Developer
Password:

無事解決した

Sourcetreeでcommitメッセージにブランチ名を挿入する

過去記事

SourceTreeでブランチ名をコミットメッセージの先頭に自動挿入する - hamburger


commitメッセージにブランチ名を挿入することで、あとからログを追うときに作業ブランチ名を追いやすくしたいというのがモチベーション。issue番号をブランチ名に関連付けて開発しているときに便利。

commit-msgファイルを作成する

$ cd .git/hooks/
$ cp commit-msg.sample commit-msg

commit-msgファイルを編集する

#!/usr/bin/env ruby
message_file = ARGV[0]
message = File.read(message_file, :encoding => Encoding::UTF_8)

current_branch = `git branch | grep '*'`.chomp.sub('* ', '')
current_branch = current_branch[current_branch.rindex("/")+1 .. current_branch.length]

newmessage = message.sub(/branchname/, current_branch)

File.write(message_file, newmessage)

Sourcetreeの設定 > コミットで、メッセージテンプレートを編集

「プログラマー脳」を読んだ

雑なメモ → プログラマー脳

徐々に衰える記憶力その他をどうにかしたくて読んでみた。

認知プロセスを知り、それをフォローするTipsを学ぶような内容。

  • ノートにメモを書いたり印刷したコードにマーカー引いたり、アナログな方法が認知科学の面ではかなり有効
  • 思考能力を上げるためにワーキングメモリの不要な負荷を下げる。短期記憶で覚えられるのはせいぜい6つ程度。
  • チャンクによって情報を圧縮する。長期記憶にあるメンタルモデルを活用する。そのためにストックを増やしておく。メンタルモデルと関連付けるためにコメントを書いたり、それを想起しやすいコードを書く。

ワーキングメモリ・短期記憶・長期記憶の強化とそれぞれの連携を意識することで、いわゆるきれいなコードの基準が少しクリアになるかもしれない。

「縁の下のUIデザイン」を読んだ

ボタンから画面遷移、ユーザのメンタルモデルまで、大小色々なトピックに対して筆者の考察やブラッシュアップの過程を追体験できるような書籍。

コレ!という答えを提示しているわけではなく、あくまで状況に合わせて選択したらこれが良いかもしれない(が、他の案もありかもしれない)くらいの書き方をしてる。

良さげなゴールにアプローチする中で少しだけ良くするためのTIPSが散りばめられていて、トップレベルのデザイナーの仕事もエンジニアと似て職人芸っぽい部分があるのだなということがわかった。

エンジニアとしてデザインを語ると、色だったり形だったり表面的な部分に目が行きがちで本質的な部分の議論ができていないなと感じることがあったが、見ているレイヤーが何段階も違っていたのだと気づくことができた。


ソフトウェア開発者にはドキュメントとかデザインドックとかの形で検討プロセスを公開する文化が(一部界隈では)あり、そこでトレードオフや許容するリスクなんかも知ることができる。

この書籍のようにデザインの途中経過を表現するアウトプットを皆で見ることができれば、開発者とデザイナー(と他の職種の人々)は今以上に理解し合えるようになるんじゃないか。というか、普通に面白そうだし個人的に興味があるから色々聞いてみたい。

Flutter3.10でiOSデバイスをワイヤレスデバッグで利用する

iOS側の開発環境を揃える

自分のiPhoneはiOS16.4.1なので、Xcode14.3をインストールした。

Xcodeで接続設定をする

iPhoneを有線接続している状態でWindow > Devices and Simulators でDevicesタブを選択し、実機を表示させる。Connect via networkチェックボックスをONにする。

ビルドしてみる

Flutter3.10を利用していると、有線接続していなくとも登録したiPhoneがデバイス候補として表示される。