vim も zsh も捨てた - AnyType
プロジェクト移行期に入って暇な時間ができたので、開発環境をリフレッシュすることにした。vim や zsh の設定が少しずつ壊れてきていたのだった。 .vimrc や .zshrc を眺めてみると、かつて意識が高かった頃に施した設定が何のためのものだったのか忘れてしまっていた。別人が書いたスパゲティコードのようだった。 また vim や zsh の設定を検索して理解するべきなんだろうか。ここで覚えた知識はまたすぐに忘れてしまうんじゃないだろうか。設定が洗練されるほどに、それを更新する機会もまた少なくなってくる。設定が必要になるきっかけは忘れた頃にやってくるもんだ。 やり方を根本的に見直す時期なのかもしれない。新しいツールもいまなら選択できる。 まず、vim から atom に移行した。git のコミットメッセージやちょっとしたファイルの修正ではまだ vim を使うものの、細かい設定が必要にな
ghqを読んだ - AnyType
Goの勉強のため、普段からお世話になっているmotemen/ghqを読むことにした。なお、現在の僕のGoの知識はgotourを完走した程度だ。最初から現在のコミットを追いかけるのは骨が折れそうだったので、最初のコミットbad21c7df65ccefd74530d6fcc5f0707b63e0266から読むことにした。 Goのプログラムはmainパッケージのmain()から実行されるため、main.goのmain()から読む。 import { // ... "github.com/codegangsta/cli" } func main() { app := cli.NewApp() app.Name = "ghq" app.Usage = "Manage GitHub repository clones" app.Version = "0.1.0" app.Author = "motem
Railsにコントリビュートした - AnyType
軽い気持ちでpull requestを送ってみたら数十分後になんとmergeされてしまった。間違ってmasterブランチに送ってしまったため、おそらくrails 5で公開されることになる。 追加したのはrake initializerという簡単なrakeタスクで、railsの起動時に実行されるinitializerを実行順に出力する。 % rake initializer set_load_path set_load_path set_load_path set_load_path set_autoload_paths set_autoload_paths set_autoload_paths set_autoload_paths add_routing_paths add_routing_paths add_routing_paths add_routing_paths add_loca
`rails s`読んだ - AnyType
rails sでRailsサーバーが起動するまでに何が起きているのかを紐解くことでRailsとは何なのかを理解していきたい。今回読んでいくソースコードのコミットは2d9b9fb5b5f6015e66d3ad5cb96bc1ba117fd626だ。 TL;DR bin/rails sがユーザーによって実行される。 Gemfileで管理されるrubygemをrequireする。 Rails::CommandsTasks#serverを実行する。 config/application.rbをrequireする。 Railsを構成する各rubygemのrailtieをrequireする。 各rubygemのinitializerが登録される。 config.ruが実行される。 登録されたinitializerが実行される。 RailsアプリケーションがRackアプリケーションとして起動する。 コマ
Web API: The Good Partsを読んだ - AnyType
Web API: The Good Parts 作者: 水野貴明出版社/メーカー: オライリージャパン発売日: 2014/11/21メディア: 大型本この商品を含むブログ (1件) を見る 業務ではiOSアプリとバックエンドの開発を両方担当しているので、APIの設計を何回かやってきた。しかし、自分なりのやり方でやってきた部分が多かったので、最近発売されたWeb API: The Good Partsを読んでちゃんとした設計について学ぶことにした。 得られた学びをメモとして残す。 HATEOAS HATEOAS（Hypermedia As The Engine Of Application State）という設計方法を初めて知った。HATEOASではまず、サーバー側はレスポンスに関連するエンドポイントを含め次にアクセスするAPIを簡単に辿れるようにする。クライアント側は最初のエンドポイント以
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
