MURAOKA Taro

#10 からの派生

another implementation of "fetch-messages"

1

fetch-messages の別実装を書いてみました。 API自身とをイテレートするところと取得結果をファイルに書き出すところをそれぞれ抽象化して fetch-messages からどう使うかが見どころです。 ConversationsHistory の中身は書いてないですが そこは見せたい場所ではないので省略してます。 --- パッケージ解説 * internal/slackadapter/ - Slack API を実際に叩くところ。イテレート/ページネーションのためのユーティリティ関数を含む * internal/jsonwriter/ - JSONでの永続化層。実装はクッソ適当だがI/FがWriteとCloseとして切れてるあたりがみそ。あとで差し替えるときも楽。 * subcmd/fetchmessages/ - fetch-messages サブコマンドの実装位置。サブコマンド間のnamespaceが変に混ざらないように分けたほうが吉 そのほか `contex.Context` は今はこういものと覚えてほしいです。 タイムアウトとかキャンセルができたほうが良い 時間のかかることをするときに使います。...

https://golang.org/pkg/text/template/#hdr-Arguments いまテンプレートからどんなArgumentや関数が使えるかは go のコードを見るしかない。 これではテンプレートをいじるとき不便なので 列挙&一言レベルで良いのでドキュメントを書いたほうが良い。

一か月まるまる発言がないと `LogStore.HasNextMonth()` や `LogStore.HasPrevMonth()` がKeyを返さない。 MsgsMapの key を+1/-1 して Messages の有無をチェックしてるので ないとfalseが返っちゃう。

理想的な構成としては、 messageは単なる器でモデルにとどまるべき。 storeは名前とDBというかモデルをどう構造化して可能するかに注力するべき(repositoryってやつ)。 generatorはstoreからmessageなどのモデルを適宜取り出して、HTMLを作ることに注力すべき。 なのにいまはそれぞれがお互いの責任境界を越えていらんことしてる。 そのため、たとえばmessageがチャンネルのメッセージデータを読むときに スレッドを構築しているため日付順にファイルを読まないとならない みたいなおかしな制約が存在している。 ちなみにこれは store に message を突っ込むときに store が構造化の面倒をみるべきはなし。 --- これらをちゃんとあるべきところに分解してやる必要がある

Attachment での opengraph 他への対応

1

#35 からの派生。 いま Attachement はフロント側で ServiceName をみて twitter や GitHub で振り分けて出してる。 しかし known なサービスすべてに独自コード書くのはアホらしいので統一した手段が欲しい。 特に ThumbURL が無効なのが災いしてて、それをどこかからか補えればいい感じに表示できるんではなかろうか? その候補としては OpenGraph (`og:image`) か。 どこかのタイミングで ThumbURL のないやつの FromURL (これがないのはまれ) を取ってきて、HTMLなら OpenGraph 解析して、ThumbURL 他の必須パラメータを埋め込む、という案。...

#10 からの派生

Multiple Godoc buffer

1

Currently `:Godoc` opens a document in single buffer. But I want to open documents in multiple buffers sometimes.