Dotfilesについて最近考えていること

自分は、dotfilesリポジトリを作って、いろいろ管理するタイプの人間なのですが、最近のdotfilesの構成についてまとめようと思います。

自分のdotfilesでやっていることは、以下

  • 基本的なshellのセットアップ
  • 環境変数などのコマンドラインのセットアップ。
  • デスクトップアプリのインストール

もはや、dotfilesの領域を超えて、デスクトップの設定も行っています。

先日、OSのクリーンインストールしたのをきっかけに環境を見直しました。そのときに、セットアップを大幅にアップデートしたので、そのときに考えた基本設計です。

とりあえず、disposableに

レガシーソフトウェア改善ガイド読み終わった”でも触れたのですが、disposableな設計は良い品質を維持するために大切なことだと思うので、自らの環境にも導入しています。例えば、医療の場でも、使用する機器は患者ごとに、disposableにしていることがほとんどだと思いますし、常に新鮮に保つという意味でも良いプラクティスだと思っています。

また、今、ベストだと思っている環境はいずれ、古くなっていきます。したがって、どんどんアップデートできる環境を構築することが大切です。その意味で、パッケージマネジャーはほぼ必須です。ほぼ全てのソフトウェアをbrewかmasで管理しています。できるだけ、古い技術に依存せず、どんどん新しいものに入れ替えていけることを目指しています。

何をやるか

大まかに何を開発するかによって異なります。目的に合った環境を作るのが大事です。

例えば、iOSを開発するのであれば、それをベースに組み立てます。iOS開発に必要なのは、Xcode, Ruby, brew, zshell, git, slack, sketchあたりからいろいろと入れると思います。

実際は、Xcode, SlackはApp Storeから。Sketchはbrew caskで、Rubyはrbenv,  zshellはbrew, gitはデフォルトか、brewから入れるという感じになります。

これらは管理下に置きたいので、インストールスクリプトを書いて、自動化します。

例えば、こんな感じです。

brew bundle --file=- <<EOF
brew "go"
brew "peco"
cask "1password"
cask "sketch"
mas "Xcode", id: 497799835
EOF

このようなスクリプトを用意することで、一括でインストールできるようになります。

他にいろいろやってる人はその都度、設定を追加していきます。手を広げている人はその分、大変になります。自分もなんだかんだで、色々と入れています。

何をやらないか

無駄に管理するのもコストがかかって大変なので、必要ないものは割り切って、use/local以下に入れてしまうのも手です。env系が必要なのはバージョンごとの挙動を試さないといけない場合なので、そこまで必要ない場合は、env系で管理せず、デフォルトのを使うか、brewで引っ張ってこれるのをそのまま使います。

あとはミニマリストではないですが、ラップトップの中くらいは、自分の管理できる範囲で運用するというのも手です。

ということで、必要ないものは極力入れないようにしよう。他のコマンドのオプションで代用できたりしないかなど、考えてみる。たまにはデフォルト厨になるのも手です。

E.g.) Curlを使って何が出来るのか。emacsの基本機能を調べてみるなど。

ちなみに最近、筆者はemacsを捨てました。笑

気をつけていること

何かをインストールした時は、それが一時的なものか、必要かを考えて、必要なら、どんどん自動化してます。設定のスクリプトまで自動挿入されるように準備しています。

ソフトウエアがどう作られてるかや、どう動くのかといったことを理解するのも重要です。分かればわかるほど、コンパクトにまとめられると思います。

最後に

ちなみに、自分のdotfilesはこちらに公開しております。

もし興味がありましたら、見てみてください。

具体的にどう構築しているかは、後日まとめるかもしれないです。

BR

2017 Software List

By chance, I set up laptop from scratch these days.
While I was setting up, I streamlined setup process.

So, I think this post would be my reminder just in case I set things up again.

Applications

Xcode

I spend most of time in business days on Xcode.

Simplenote

I am texting on Simplenote.

SublimeText

If I have to hack other than iOS things, I usually use SublimeText.
I use vim as well, as secondary editor.

iTerm2

I chose iTerm2 instead of built-in terminal app.

Alfred

better than spotlight.

Skype

communication

Spectacle

shortcut utility tool.

Echofon

Twitter client.

Karabiner

key configurations.

SourceTree

Git GUI tool.

Spotify

Juke box

scripts

I am running bootstrap script.
I decided to adopt third party laptop setup.
Current setup is based on script that thoughtbot made.

Here is how I do

$ cd path-to-dotfiles
$ ./bootstrap.bash

Wrap up

Let’s automate and dive into development immediately.

Swiftをbuildした話

千里の道も一歩から(どこへ向かってるのか?)

Swift1を使う人は多いけど、日常的にSwift(as プログラミング言語)をbuildしている人はおそらく500人以下 (2017/1現在)。

ということなので、とりあえず、ビルドしてみれば何かがわかるかもしれないということでビルドしてみました。

用意

  • Mac OS X Sierra and Xcode 8
  • Python2.x(SystemのものでOK). Python3.xは動かないので注意

あと、

brew install cmake ninja

あとはREADMEに沿って、ビルドして行く。

作業

READMEに書いてあるんですが、まずはroot directoryを作りましょう。

$ mkdir swift-resources

みたいな感じです。この中に大量のリソースがcheckoutされます。

全部うまく行くとこんな感じになるはず

swift-resources
	├── build
	├── clang
	├── cmark
	├── compiler-rt
	├── llbuild
	├── lldb
	├── llvm
	├── swift
	├── swift-corelibs-foundation
	├── swift-corelibs-libdispatch
	├── swift-corelibs-xctest
	├── swift-integration-tests
	├── swift-xcode-playground-support
	└── swiftpm

最終的に自分が実行したコマンドは

$ cd swift
$ utils/build-script -r

です。-rはdebuginfo付きのリリースビルドという意味らしいです。

ビルドすると、上記のようにbuildというディレクトリがswift-resourcesの中に作られます。
もしも、ビルドに失敗した、buildディレクトリを削除してから再コンパイルしましょう。
buildの中にはキャッシュファイルなどがあるので、何回も同じエラーが出てしまうことがあります。

コマンド実行後はじっくり待ちましょう。Machineが貧弱な場合、最悪1時間くらいかかります。2

いよいよ、自前のswiftが完成します。場所はbuild/Ninja-RelWithDebInfoAssert/swift-macosx-x86_64/binというところにあります。

build/Ninja-RelWithDebInfoAssert/swift-macosx-x86_64/bin
	├── Benchmark_DTrace
	├── Benchmark_Driver
	├── Benchmark_GuardMalloc
	├── Benchmark_O
	├── Benchmark_Onone
	├── Benchmark_Ounchecked
	├── Benchmark_RuntimeLeaksRunner
	├── complete-test
	├── lldb-moduleimport-test
	├── sil-func-extractor
	├── sil-nm
	├── sil-opt
	├── sil-passpipeline-dumper
	├── sourcekitd-repl
	├── sourcekitd-test
	├── swift
	├── swift-api-digester
	├── swift-api-dump.py -> path-to/swift-resource/swift/utils/swift-api-dump.py
	├── swift-autolink-extract -> swift
	├── swift-demangle
	├── swift-format -> swift
	├── swift-ide-test
	├── swift-llvm-opt
	├── swift-reflection-dump
	├── swift-reflection-test-macosx-x86_64
	├── swift-remoteast-test
	└── swiftc -> swift

ここにswiftがあるというわけです。
作業的には、ビルドに時間がかかるという以外に特に難しいところはありません。

感想

ビルド時間が長すぎるので、開発するには何らかの自動ビルドは必須だと思われます。リモートでは、swift-ciというのが動いてるっぽい。
次はproject fileをxcodeで開いてみるかな。

iTunesConnect 冬季休暇中

iTunesConnectの冬季休暇中です。
12月23日から27日まで。

Winter Holiday Schedule

submission以外のiTunesConnectの操作はできます。

先週から、かなりアプリの駆け込みアップデートが多かったですね。

最近気づいたんですが、iPadのアプリの申請には12.9inchのスクリーンショットが必要になっていました。しばらくiPad触ってなかった証拠。笑

If your app supports iPad, a 12.9-Inch Display screenshot is required.

Screenshot Properties

[Feedback] Swift3.1 Release Process

My Feedback to Swift 3.1 Release Process.

Agile

Swift 3.1 release process looks agile.

Development team will release snapshots every small milestone.
All chages are merged into master branch and snapshots are dispatched from swift-3.1-branch, and GM will be on it. I prefer having release branch.

Apple adopted agile development in swift project. It’s cool!

Source Compatibility

Many people would have complained about compatibility between versions.
Upgrading 2 to 3 is painful, even though swfit 3 api design is beautiful.
In 3.1, source compatibility is featured in this blog post.

swift3 cod is going to be compilied swift3.1 compilier.
It is natural. This is just minor update.

Directed by managers

It looks like that Managers have strong authorities for release.
Pull requests are checked or evaluated by them.

[3行] Server APIs Work Group

My Feedback to Server APIs Work Group

Swift Blog まとめ

10月25日のブログより。

  • Server APIs work groupをサーバーアプリを作りたいコミュニティのために作った。
  • Swiftだけで簡単にlow levelのサーバー機能を実装するフレームワークを提供する。
  • 詳しくはこちら. https://swift.org/server-apis/

以上。

言及されているWeb Application Frameworkたち