2015-07-11

Pocketのもう読んでない記事を掃除するヤツ書いた

<a href="https://github.com/naoty/sweep">naoty/sweep</a>

普段、Pocketを使って「あとで読む」記事を管理している。ちょっとした時間に見つけた記事をPocketに追加しておいて、通勤時間などにiOSアプリで消化している。ただ、長い記事が増えてくるとだんだん消化しきれなくなってきて、消化しようというモチベーションが失せてくる。そこで、一定期間が経っても消化できていない記事を自動的に削除するツールを書いた。

使い方

まず、Pocketのdeveloperサイトに行ってアプリケーションを作成する。すると、Consumer keyが得られる。次に、Access tokenが必要なのだけど、これはmotemen/go-pocketを使ってOAuth認証を行い取得した。
Herokuボタンからデプロイする。ここで、上で取得したconsumer keyとaccess tokenを環境変数としてセットする。さらに、削除対象とする期限を環境変数で指定できる。デフォルトは24時間となっている。僕は72時間にしている。
Heroku schedulerのダッシュボードでsweepを実行するタイミングを設定する。

所感

先日、Herokuが公式にGoをサポートしたので、さっそくテストを兼ねてこういうものをGoで書いてみた。tools/godepの使い方を覚えなくてはいけないことを除けば、いつもどおりにHerokuにアプリケーションをデプロイできた。

個人的にちょっとしたCLI ツールをGoで書くことが増えたが、ちょっとしたジョブを定期実行させるときにGoでちょっとしたツールを書いてHeroku schedulerにやらせるという手法は非常にお手軽なので今後も機会がありそうだなと思った。

2015-06-20

コミット数が多いファイルを表示するコマンドを書いた

<a href="https://github.com/naoty/hot">naoty/hot</a>

インストール

$ go get github.com/naoty/hot

使い方

$ cd src/github.com/naoty/Timepiece
$ hot
24: README.md
17: Sources/NSDate+Timepiece.swift
15: Tests/NSDate+TimepieceTests.swift
10: Timepiece.xcodeproj/project.pbxproj
9: Timepiece.podspec
7: Sources/Duration.swift
7: Tests/DurationTests.swift
7: Tests/Int+TimepieceTests.swift
6: Sources/Int+Timepiece.swift
4: Sources/NSDateComponents+Timepiece.swift
2: .travis.yml
2: Tests/NSTimeInterval+TimepieceTests.swift
2: Timepiece.xcodeproj/xcshareddata/xcschemes/Timepiece OSX.xcscheme
2: Sources/NSTimeInterval+Timepiece.swift
1: Timepiece.xcodeproj/xcshareddata/xcschemes/Timepiece iOS.xcscheme
1: Timepiece.xcworkspace/contents.xcworkspacedata
1: .gitignore
1: LICENSE
1: Sources/NSCalendar+Timepiece.swift
1: Sources/NSCalendarUnit+Timepiece.swift
1: Sources/String+Timepiece.swift
1: Tests/NSCalendarUnit+TimepieceTests.swift
1: Tests/String+TimepieceTests.swift
1: Timepiece.playground/Contents.swift
1: Timepiece.playground/Sources/SupportCode.swift
1: Timepiece.playground/contents.xcplayground
1: Timepiece.playground/playground.xcworkspace/contents.xcworkspacedata
1: Timepiece.xcodeproj/Timepiece-Info.plist
1: Timepiece.xcodeproj/TimepieceTests-Info.plist
1: Timepiece.xcodeproj/project.xcworkspace/contents.xcworkspacedata

表示件数を-n <表示したい件数>で指定したり、パターンを指定してマッチしたファイルだけ表示することができる。

$ hot -n 5 "**/*.swift"
17: Sources/NSDate+Timepiece.swift
15: Tests/NSDate+TimepieceTests.swift
7: Sources/Duration.swift
7: Tests/DurationTests.swift
7: Tests/Int+TimepieceTests.swift

動機

仕事で1年以上開発が行われているコードベースを引き継ぐことになった。僕の仕事は既存のコードを理解しつつ、新たに機能を追加していくことだ。そこで、効率的に既存のコードベースの全体像を把握するため、このようなツールを作ることにした。どれが主要なファイルなのかコミットログから把握できる。

他の使い方としては、例えば各ファイルのコミット数、循環的複雑度、テストカバレッジ等から、プロジェクト全体のバグの出やすさみたいなものを可視化できるかもしれない。

2015-06-14

「すごいHaskell たのしく学ぼう！」を読んだ

書評 Objective-C/Swift/iOS

すごいHaskellたのしく学ぼう！

作者: Miran Lipovaca
出版社/メーカー: オーム社
発売日: 2012/09/21
メディア: Kindle版
購入: 4人クリック: 9回
この商品を含むブログを見る

本書は一度は8章あたりで挫折したが、今回13章あたりまで読みファンクタ―、アプリカティブファンクタ―、モノイド、モナドといった概念がなんなのか理解とまでは言えないけど知ることができた。

一度は挫折したが今回またリベンジしようと思った理由は、今後モバイルアプリを開発していくにあたって関数型プログラミングの概念を理解して採り入れていくことが必要になってくると思ったからだ。Swiftはletによる不変型の宣言やOptional型などの文脈付きの型など関数型プログラミング言語としての側面をもっていると思う。また、データバインディング（SwiftBond/Bondなど）やJSONのパース（thoughtbot/Argoなど）といった場面で関数型プログラミングの概念が登場してきている。Swiftのポテンシャルを最大限に発揮して、堅牢で生産性の高いコードを書くには関数型プログラミングの知識が必要になってきていると最近感じている。

本書を読んだ結果として、データの構造について新しい視点を得ることができた。MaybeやEitherといった概念を"文脈"と呼んでいるのが自分の中にはなかった発想だった。例えば、MaybeとMaybe Intを区別して考えるのはとても抽象的だけど強力な考え方と思った。Maybeは「あるかもしれないし、ないかもしれない」という文脈を表し、Maybe Intは「Int型かもしれないし、何もないかもしれない」型を表している。これらを分けることで、文脈を保ったまま計算するという発想が出てくるのだと思う。文脈を保ったまま計算する段階として、本書ではFunctorやApplicative、そしてMonadが登場してきた。

Swiftでは、Haskellにおける型コンストラクタにあたる概念がない。Genericsを使うことでMaybeのような型を表現することはできるが、ある型が型引数をとるのかとらないのか、とるとしたらいくつとるのかを知る術はない（はず）。Haskellではそれらは種類という概念で説明されている。Maybeの種類はMaybe :: * -> *だし、Eitherの種類はEither: * -> * -> *となっているので、それぞれ型引数を1つと2つとることがわかる。HaskellのFunctorは種類が* -> *の型コンストラクタしかインスタンスにできないのだけど、こういう概念をSwiftで表現できない。

というわけで、Swiftで関数型プログラミングをするにはHaskellほどうまくはできないことがなんとなくわかった。Genericsなどで擬似的に表現するしかない。Functorのfmapを以下のように実装してみた。

extension Optional {
    func fmap<U>(f: T -> U) -> U? {
        switch self {
        case .Some(let value):
            return f(value)
        case .None:
            return .None
        }
    }
}

let maybeOne: Int? = 1
let maybeTen = maybeOne.fmap({ x in x * 10 })

SwiftのOptional<T>型はつまりT?型のことなのだけど、Optional型を拡張してfmapを追加している。return f(value)のところは暗黙的にU?型にラップしている。このように実装することで、Optional型のもつ「あるかもしれないし、ないかもしれない」という文脈を保ちつつ、中身の1というIntを計算している。

ここではFunctorだけを簡単に実装してみたが、これに加えてApplicativeとMonadを実装するとより抽象的な計算が可能になってくる。JSONのパースなどを実装する際にはApplicativeの操作が必要になってきそうな感じがする。自分はまだ関数型プログラミングの実装を実際にしたわけではないので、理解したとは到底いえない。パーサーの実装をしてみたり、上で紹介したライブラリのコードを読んでみることで関数型プログラミングを実践的に理解していきたい。

2015-05-30

naoty/todoとnaoty/nowisで定期的なtodoを管理できるようにした

前回のエントリで紹介したnaoty/todoと今回作ったnaoty/nowisを組み合わせることで、定期的なtodoをコマンドラインで管理できるようにした。

<a href="https://github.com/naoty/nowis">naoty/nowis</a>

使い方

$ nowis saturday && echo 'Today is Saturday!'
Today is Saturday!

nowisコマンドは、現在時刻が引数で与えた曜日かどうかを判定して真なら終了コード0を返し偽なら1を返す。上のように&&で任意のコマンドと組み合わせることで、特定の曜日だけ実行できるようになる。

定期的なtodoの管理

nowisを組み合わせて定期的なtodoを管理するにはいくつか方法が考えられるが、zshの設定ファイルを使う。

# .zlogin

nowis sunday && todo add --once 部屋を掃除する
(nowis tuesday || nowis thursday) && todo add --once 燃えるゴミを出す

上のように設定することでzshにログインするたびに上のスクリプトが実行される。todo add --onceで既に存在する場合は追加しないようにできるので、これで特定の曜日になると自動的にtodo addされるようになる。

15分くらいで作ったので現状は曜日の判定しかできないけど、応用範囲が広そうなのでもうちょっと細かく判定できるようにするかも。

2015-05-23

自分専用のtodo管理ツールを書いた

最近、プライベートでの開発したいことや勉強したいことが増えてきたので、それらを管理するツールを書いた。

<a href="https://github.com/naoty/todo">naoty/todo</a>

使い方

$ todo add Go言語を勉強する
$ todo add todo管理ツールを書く
$ todo add ブログ記事を書く
$ todo list
[ ] 001: Go言語を勉強する
[ ] 002: todo管理ツールを書く
[ ] 003: ブログ記事を書く
$ todo done 1
$ todo done 2
[x] 001: Go言語を勉強する
[x] 002: todo管理ツールを書く
[ ] 003: ブログ記事を書く
$ todo clear
$ todo list
[ ] 001: ブログ記事を書く

その他、todoの削除や移動などができる（詳細はGitHubのページを参照）。個人的に便利だと思っている機能がtodoをmarkdownのtask list形式で出力する機能だ。

$ todo list -m
- [x] Go言語を勉強する
- [x] todo管理ツールを書く
- [ ] ブログ記事を書く

これを使ってQiita:Teamの日報に今日やったこと、やれなかったことを簡単にコピペできる。一日の作業フローはこうだ。

todo listで残タスクを確認する。
適宜todo addでタスクを追加したり、todo moveで順番を入れ替えて優先度を調整する。
完了したらtodo doneでタスクを完了させる。
一日の終わりにtodo list -mで作業内容を出力してQiita:Teamにコピペして、感想などを付け加えて日報として公開する。
todo clearで完了したタスクを消去する。

tips

todoはLTSV形式のファイルとして保存され、ファイルのパスはTODO_PATHという環境変数で指定できる（デフォルトはHOME）。なので、環境変数でDropbox内のパスを指定すれば簡単にtodoを同期できる。
zimbatm/direnvを使うと、プロジェクトルートにcdしたときにTODO_PATHを書き換えられるのでプロジェクトのスコープのtodoを別に管理できる。

実装

最近はGoが気に入っているので、コマンドラインツールを作るときはすべてGoで書いている。CLIを作る際のフレームワークはいくつかあるようだが、一番Starが多そうだったcodegangsta/cliを使っている。標準の出力とmarkdown形式の出力の切り替えを実装する際にinterfaceを使ってみた。ファイルの入出力にはioutilパッケージが手っ取り早かった。ファイルの扱いを通じてio.Writerインターフェイスについても理解が深まった。

done

$ todo done 1

2015-05-14

#potatotips でTimepieceについて発表した

雑記 Objective-C/Swift/iOS

potatotips

<a href="http://connpass.com/event/14143/">【第17回】potatotips(iOS/Android開発Tips共有会) (2015/05/13 19:00〜)</a>

資料

最近のTimepiece

GW前あたりから急激にバズってきた。一時GitHubのトレンドで1位になった。それまでは☆70くらいだったけど、もうそろそろ☆500になりそうな勢いだ。
それに伴っていくつかの要望をPull requestでいただいた。それらはほぼすべてmergeした。機能追加やバグ修正まで自分では見落としていた部分を指摘していただいて、多くの方に使われていそうだという実感がある。

イベントの感想

最近はiOSではなくAndroidアプリ開発をしているので、iOS/Android両方楽しめて非常に良かった。
Timepieceを検討したけど採用を見送った方の意見を聞けたのが非常に良かった。そういう方の意見を聞ける機会は多くないからだ。いただいた要望について今実装方針を考えていて、ちゃんと形にしていきたい。
最近気になっているResultについての議論はとても勉強になった。naoty/SwiftCSVでエラー情報を扱う際にResultが使えそうだと思っていた。ただ、議論を聞いてオレオレResultが乱立しそうな流れがありそうだというのを知った。そうなると、ライブラリ提供者が実装するよりも利用者側でResultを定義する方が利便性を損ねないのでは、という意見に変わった。
ドキュメントだけではよく理解できなかったDagger 2については、あまりよくわかってなかった@Provideについて理解が深まった。Androidのテストについて意見交換をさせていただいて、自分の意見は間違ってなさそうだという確信を得られたのもよかった。
その他、Androidの@Nullable, @NonNullはすぐに使おうと思ったし、Lastlaneやdeliverといったワークフローを自動化するツールも実践的な内容で勉強になった。

2015-04-09

コミット毎に実行環境をビルドするoasisを書いた

Dockerの理解を深めるため、またGo言語の経験を積むためにoasisというツールを書いた。「とりあえず動いた」レベルの完成度であり、実用で使うにはもっと時間をかけて改善していく必要がある。

<a href="https://github.com/naoty/oasis">naoty/oasis</a>

これはコミット毎の実行環境をdockerのコンテナとして提供するリバースプロキシだ。例えば、以下のようにoasisを起動する。

% oasis start \
    --proxy master.oasis.local:8080 \
    --container-host 192.168.99.100 \
    --repository github.com/naoty/sample_rails_app

このときhttp://master.oasis.local:8080にアクセスすると、oasisは以下のようなことを行う。

--repositoryで指定されたリポジトリをgit cloneする。
サブドメインで指定されたリビジョン、ここではmasterにgit checkoutする。
リポジトリに含まれるDockerfileを使ってdocker buildする。
ビルドしたイメージをdocker run -P -dして、コンテナを起動する。
コンテナのホスト側ポート（例: 49154）を調べて、oasisへのアクセスを--container-hostで指定されたホスト上のコンテナ（例: 192.168.99.100:49154）にリダイレクトする。

f:id:naoty_k:20150409225939p:plain

実際にOSXで試す場合は、--proxy 127.0.0.1:8080のようなオプションで起動して、サブドメインの解決をPowに任せるといいと思う。

% cd ~/.pow
% echo 8080 > oasis

上のようにすると、http://*.oasis.devのように任意のサブドメインにアクセスできるようになり、8080ポートのoasisにポートフォワーディングされる。

所感

もともとは同僚の方が開発に携わっているmookjp/poolを見て、もうちょっとシンプルにセットアップできるようにしたいと思ったのがきっかけだった。実行ファイルをダウンロードして即実行できるようなものが理想だったので、Go言語を勉強しはじめこんなものを作ってみた。名前の「oasis」は最近ハマっているドミニオン・異郷に出てくるアクションカードであること、コンセプトのオリジナル実装であるpoolに雰囲気が似ていることから採った。

Go言語はとてもシンプルですんなり理解できたし、標準パッケージでリバースプロキシを簡単に実装できたため、短時間でここまで作ることができた。ちょっとしたツールを作るとき、これまではRubyでrubygemを書くようなことをしていたが、Go言語であればrubygemを書くほどのハードルの高さもなく、シンプルで生産性の高いコードを書いてそのまま配布することができていい感じだなと思った。

また、DockerについてもDocker Remote APIを触ってみたり、docker runの-pと-Pの違いを理解できたり、理解が深まったと思う。あんまり関係ないけど、サンプルアプリで使ったDockerfileはDocker Hubで配布された公式のrails用イメージを使ってるだけで、何も考えなくてよくて便利だった。