タグ

ブックマーク / r7kamura.hatenablog.com (32)

  • APIデザインの極意 - ✘╹◡╹✘

    APIデザインの極意 Java/NetBeansアーキテクト探究ノート 作者: Jaroslav Tulach,柴田芳樹出版社/メーカー: インプレスジャパン発売日: 2014/05/23メディア: 単行(ソフトカバー)この商品を含むブログ (4件) を見る API設計は難しい "良い"APIを設計するのは難しく、APIの良し悪しを定量的に観測することは難しいとされている。後方互換性や拡張性、不具合の発生率などで曖昧に推し量ることはできるが、これは良い、これは悪い、とはっきり決め付けることは出来ない。そもそもAPIから「これ」と呼べるある側面を切り出すことも難しいと言える。また、APIの設計技法を学べる機会は多くないとしている。物事を感覚として認識することはできても、それを表現し他人に伝え信じてもらう方法を持たない場合が存在する。 API設計を芸術的取り組みにしてはいけない API設計の

    APIデザインの極意 - ✘╹◡╹✘
  • リゾートワーク - ✘╹◡╹✘

    1週間ほど休みとって沖縄旅行いってきた。 快適な空の旅 同乗者と空港でゆっくり朝ごはんべてたら普通に飛行機もう飛んじゃっててウケた。 ギークハウス沖縄 2日間泊めてもらったり近場の飯屋に連れて行ってもらったりとにかくお世話になった。 台風で落ちてきたココナッツ割ってべた。 屋上の見晴らしが良くて羨ましい。 東京に来る機会があれば卓球ハウスに是非。 レール 那覇空港から首里城付近まで、ゆいレールというモノレールが通っているので初日は主にこれで移動。 700円で24時間のあいだ乗り放題で重宝した。 主要なところしか通っていないのでモノレールだけでは行けないところもあるけど、 特にめっちゃここに行きたいみたいな願望は無くて漠然と沖縄吸いたいという感じだったから、 むしろレールが引いてあって便利だった。 首里城 観光地にしてはそこまで観光色が強くなくて印象が良い。 城壁 城壁好きなので一周出来

    リゾートワーク - ✘╹◡╹✘
  • 全てがJSONになる - ✘╹◡╹✘

    TL;DR JSON Schemaを使ってこういうことが実現可能になった。 ダミーAPIサーバの提供 ドキュメントの自動生成 APIクライアントの動的定義 APIサーバのバリデータの動的定義 APIサーバのレスポンスの自動テスト JSON Schemaとは JSON SchemaというのはあるJSONのデータ構造を記述するための方法および書式の仕様で、 JSON SchemaもJSONで記述される。 これを利用すれば、リソースベースの(=RESTfulライクな)APIの仕様が簡便に記述できる。 例えば、我々のAPIレシピとユーザというリソースを扱っていて、 それぞれCRUDのAPIを備えており、レシピはidとtitleとdescriptionという属性を持つ、 という旨をJSON Schemaで表現できる。 なんで最近ちょっと流行ってんの Mobile First、 Service Or

    全てがJSONになる - ✘╹◡╹✘
    heavenshell
    heavenshell 2014/06/10
    凄く参考になる。API サーバのモックまでは自分でも作ったけど、JSON Schema からのドキュメント生成までできてない。
  • XMPP界 - ✘╹◡╹✘

    XrcというRubyのXMPPクライアントライブラリをつくったので、XMPP界の知見を共有します。 WHY RubotyというBOT開発用のフレームワークを最近つくっていて、 これをSlackというチャットサービスで利用していた。 SlackにはXMPP GatewayIRC Gatewayが用意されており、 どちらかのプロトコルを利用すればBOTとして動作するにはひとまず十分だった。 Rubyで一般的なIRCライブラリと言えばnet-ircだけど、 自分でZirconというIRCクライアント用ライブラリを作って、 ruboty-slackでは最初はこれを使ってた。 IRCは雑に全部屋に適当にJOINしてくれたりするのでBOTとして運用するにはわりと楽だったんだけど、 メッセージに改行を簡単に含められないというところが気に入らなくてXMPPを検討することにした。 改行が含められないとどう

    XMPP界 - ✘╹◡╹✘
  • Railsアプリつくった - ✘╹◡╹✘

    最近APIサーバ用途でRailsアプリを1個つくったので振り返る。 概要 接続元はiOSやAndroidアプリとか、Webブラウザとか、別のWebアプリケーションとか。1ホストあたり秒間数百リクエスト、平均応答時間10msぐらい。Rails 4.1.0.rc2、Unicorn、Nginxを使ってる。正直Railsは全部入りで重いイメージがあったので何となく平均50ms以内程度であれば良いところだろうと思ってたけど、意外と速い。多分そもそもサーバの性能が良いんだと思う。実装時に気を付けたことは普段の開発と特に変わりない。いつもは大勢でワイワイ開発するものに少し手を加えるということが多いんだけど、今回は珍しく自分一人でつくったから目が行き届いてたのかもしれない。DBへの問合せの効率に気を配るとか、Rubyでの処理の無駄を省くとか、アプリケーションのプロセスに無駄なコードを読み込ませないとか、計

    Railsアプリつくった - ✘╹◡╹✘
  • 全自動モヒカンさん - ✘╹◡╹✘

    https://github.com/r7kamura/code_hunter Railsのコードを静的解析して指摘してくれるツールをつくりました。 使い方 Ruby 1.9 があれば使えます。 $ gem install code_hunter $ code_hunter --help Usage: code_hunter [options] --application-path= (default: ./) rails application root path --format= (default: yaml) output format (yaml or json) --no-brakeman (default: false) disable brakeman --no-pendaxes (default: false) disable pendaxes --no-rails-be

  • 雑なレビュー - ✘╹◡╹✘

    背景 レビューに時間を掛けているわりにあまり成果が出ていない 問題意識を感じる レビューという行為にもっと周りから理解があればいいのに、という風に考える 原因を外部に求めるのは良くないなと考え直す これまで自分が発言したコメントを読み返す 過度にフォーマル過ぎたり、コードの表層しか指摘していないところが多々あることが分かる 問題 GitHubのPull RequestやIssueでのコメントに、出来るだけ間違いや誤解が無いように気を付けられた丁寧な文章で書いてしまうことが多い。しかしながら、もっと普段互いに会話するときに使うような雑な言葉で書いて、コミュニケーションの量を増やした方が良いんだろうなと思う。 そもそもコミュニケーションの量が足りていないせいで、レビュアーがそのドメインについてあまり理解が得られず、問題の表面的な部分についてのみしか発言出来ないということが沢山ある。サービスごと

    雑なレビュー - ✘╹◡╹✘
    heavenshell
    heavenshell 2014/02/07
    "仮説として「コードレビューでの文章は丁寧でまとまったものより雑で頻度が高いものの方が良い」という風に考えて、一部の開発者へのレビューを雑めの会話で返すように努力してみてる。"
  • 技術力がないから - ✘╹◡╹✘

    つらいことがあったときに上手くいく呪文です。 人に唱えてダメージを与えることも出来る。

    技術力がないから - ✘╹◡╹✘
    heavenshell
    heavenshell 2014/02/02
    破壊力大きい
  • Ruby Patterns - ✘╹◡╹✘

    この記事には、Rubyを書いているときに「これは言語化されたり公式化されたりしていないけれど基的には必ずこのパターンに則ってプログラムを書いているな」ということをふと思い出したときにやってきてそのパターンを書く。多分3パターンぐらいで終わると思う。ウケが良ければ思い出す確率が高くなると思う。題材さえあれば何も考えずに書けるので、これを書くコストは全然高くない。 名前が"?"で終わるメソッドは必ずtrueまたはfalseのどちらかを返す trueとfalse以外(例えばnil)が返る可能性がある場合は、必ず式の先頭に!!を付けてtrueかfalseになるようにしてる。 このパターンを守ることがとても大事だという風には全く考えていないけど、もしhas_user?がuserを返すとして、has_user?という名前のメソッドがUserオブジェクトを返すというのは一体どういう意味を持っているのだ

    Ruby Patterns - ✘╹◡╹✘
  • client-side javascript - ✘╹◡╹✘

    JavaScriptのすごく初歩的なことでよくわからないので整理する。よくわかってなくてすごい恥ずかしい感じがするけど書いたら誰か何か教えてくれそうだし書く。client-sideのJavaScriptは、未だあまりよく分からずにもやもやしながら適当に書いてる。もやもや感が説明したいけどなかなか説明しづらい。 例 こういうタブをJavaScriptを使って実装する例を考える。タブをクリックすると、そのタブに切り替わるというやつ。 HTML CSS JavaScript Pattern 1 深く考えずに素朴に実装すると、こういう感じになる。clickイベントに与える無名functionの中に全部詰め込む。こういう風に書いてるJSのコードはよく見る。こういうの大量に書くのはすごい簡単だけど大量にこういうのが書かれてたら読むの辛い感じがする。 懸念 例えばこれまでRubyでコードを書いていたとき

  • DRY原則とテストの可読性 - ✘╹◡╹✘

    DRY原則に従おうとするほど、テストコードがどんどん読みづらくなる。 The RSpec Bookに答えがあるかと思って読んでみたものの、「あるある」と一言述べているだけだった。辛い。 テストコードが読みづらくなる例を示すために、1つRubyのライブラリをつくった。 値とパターンを与えてValidationを行う機能を提供するライブラリ。 実装60行、テスト120行なので、詳しく見たければすぐ読めると思う。 最近不意ながらキラキラネームの命名力が上がってきたと思う。 avalon - A validator implementation for Ruby https://github.com/r7kamura/avalon 冗長だが読みやすい例 letもsubjectもローカル変数も何も用いずに率直に書いたテストコード例がこちら。 冗長だが読みやすく、テストコードを見ればライブラリの使い

    DRY原則とテストの可読性 - ✘╹◡╹✘
  • Vimで挿入モードから抜ける時に英数入力に切り替える - ✘╹◡╹✘

    昨日からHHKBを使い始めたついでに、キー設定を色々入れ替えるためKeyRemap4MacBookというアプリを使い始めました。『Vimで挿入モードから抜ける時に英数入力に切り替える』というのが前からやりたくて、KaoriYaさんのMacVimだとそういう設定がvimrcで出来たんですが、CUIvimではIMを操作する良い方法が分からずに設定できていませんでした。このアプリで無理やり実現出来たので快適です。 設定方法 KeyRemap4MacBookは独自でXMLを書いて、あるキーを特定のキーと結び付けることが出来ます。またその設定が有効になるアプリも選択できます。今回の場合は、Terminal上でEscキーをEscキー+英数キーという設定にすればOKですね。Ctrl+Cも使うので同時に設定しておきます。 まずKeyRemap4MacBook Preference Paneからpriva

    Vimで挿入モードから抜ける時に英数入力に切り替える - ✘╹◡╹✘