Qiitaのトップページのフィードの設計 - ✘╹◡╹✘
@ainame user.articles.preload(:comments, :stocks_count) みたいにstocks_countのようなassociationを生やしており、stocks_countの内部実装はPreloaderが弄られていてIDだけ取ってる— 内製フレームワーク (@r7kamura) 2015, 8月 23 @ainame これを抽象化するために、Article.has_many(:stocks, counter: true) みたいにすると、article.stocksとarticle.stocks_countがほぼ同じSQLで同時に定義されるようになってる— 内製フレームワーク (@r7kamura) 2015, 8月 23 @ainame それを実現している実装がこれです / k0kubun/activerecord-precount https:
天下一bot武闘会で発表しました - ✘╹◡╹✘
「流行りの Chat Ops に隷属させられているチャット bot たちよ集え! おみくじ、雑談……まるで実務には役に立たないが粋な仕事をこなしてくれる bot たちの知られざる実態を紹介しあいます。」という主旨の会が行われ、Qiitanについて発表させてもらいました。非常にコンテキストの共有が難しいテーマの中、うまく意思疎通できたかどうかは分かりませんが、何か得るものがあったならば幸いです。Rubotyについての話もできると良かったですが、また機会があればそのうちどこかで話したいと思います。 発表で紹介したリンク http://github.com/r7kamura http://qiita.com/r7kamura r7kamura/ruboty r7kamura/ruboty-alias r7kamura/ruboty-cron r7kamura/ruboty-google_cale
『進化するアカデミア「ユーザー参加型研究」が連れてくる未来』読んだ - ✘╹◡╹✘
進化するアカデミア 「ユーザー参加型研究」が連れてくる未来 作者: 江渡浩一郎,ニコニコ学会β実行委員会出版社/メーカー: イースト・プレス発売日: 2013/06/14メディア: Kindle版この商品を含むブログ (6件) を見る 『進化するアカデミア「ユーザー参加型研究」が連れてくる未来』を読んだ。ニコニコ学会βができるまでをドキュメンタリーのように追いかけながら、実行委員達が、自らの関心分野や研究対象、経験や知識を踏まえながら、研究や学会の在り方についての考えを綴っている。いかにニコニコ学会βが画期的かという話は置いといて、読書中に残したメモから雑多な感想を書いておく。 パターン・ランゲージ この本を読んだそもそもの起点は、年始に パターン・ランゲージ: 創造的な未来をつくるための言語 を読んだことによる。クリストファー・アレグザンダーは、近代建築において失われつつある「生き生きと
HerokuのつくってるAPI関係の便利なやつ - ✘╹◡╹✘
JSON Schema for the Heroku Platform APIでも紹介されているように、HerokuのAPIはJSON schemaで記述されたAPIの仕様を返すようなAPIがあって(ややこしい)、Auto-generating a Go API client for Herokuのようにこれを利用してAPIクライアントを自動生成するようなこともやってる(単なるアート作品じゃなくて実際に運用されているので偉い)。Herokuが出してるAPI関連作品の1つにcommittieというのがあって、JSON schemaを利用してAPIの仕様を定義して、それをRack middlewareで利用しようというもの。前に試しに似たようなのつくってたので良いのが出てきて良かった。 Committieは大きく分けて3種類の機能を提供していて、1つは本番環境で普通に使うやつで、リクエストをv
REST APIドキュメント生成パターン - ✘╹◡╹✘
REST API用のドキュメントを生成するときにどうやってるかについて雑記を残しとく。 概要 実装とドキュメントの乖離を避けるためには、同じ意味情報を二箇所以上に定義することを避ける必要がある。そのための方法として、実装それ自身か、もしくは実装が参照している何らかのメタデータを元にしてドキュメントを生成したり、テストの実行結果からドキュメントを生成するというパターンがある。 テストから Cookpadでは、autodocというライブラリを利用して、RSpecでテストを実行している途中で得られたメタデータからドキュメントを生成している。これはテストの実行結果からドキュメントを生成するパターン。 これは実現方法としてはかなり特殊な部類。このパターンが最も効果的に働くのは、ドキュメント生成のために余分な開発コストはあまり掛けたくないが、テストは真面目に書いている OR 真面目に書いてほしい、とい
Railsの性能測定用プラグイン peek/peek - ✘╹◡╹✘
peek/peekという、パフォーマンス測定を目的としたRails用プラグインのコードを読んだ。rack-miniprofilerを知っている人はそういう類のもの。peekはGitHubやGitHub Enterpriseで利用されている。peekの構造は、リクエストIDごとに情報を保存する機能、リクエストIDを元に情報を取得する機能、そして情報を描画する機能の3つの部分に分解できる。 リクエストIDごとに情報を保存する この処理は、HTMLを返却するためのリクエストの処理中に行われる。リクエストの処理中に実行される様々な処理について、それらの実行時間や実行回数を計測し、計測結果を保存する。保存先は、故意に設定しなければメモリ (厳密にはとあるクラスオブジェクトのインスタンス変数) に保存されるが、保存先をRedisやMemcacheに変更することもできる。 リクエストIDを元に情報を取得
自分のコード綺麗って思ってんの？ - ✘╹◡╹✘
guideline.gem https://github.com/r7kamura/guideline 恐怖体験があって、震え上がり、少しでも綺麗なコードが書けるようなGemつくってる。複雑過ぎるメソッドや、使われていないメソッドが定義されていないかとか、長過ぎる行を書いてないかとか、簡単なチェックを自動化できる。こういうコードは綺麗ではないみたいなことがふわっと言われているよりは、綺麗ではないコードというのがコードで表現されている方が安心感があると思った。もしコーディングルールとして文書化したのでみんな守ろうみたいな感じにしても、コードを書くときに常にそれを覚えていなければ意味がないし、常にそういうことを気にしながら、ずっと緊張しながらコードを書かないといけない。そういう風に常に何かに気を配りながら作業するというのは、意識は高いけど、疲れるから極力やりたくないし、そもそも新しくその文化に
ストリーム表現とその変換 - ✘╹◡╹✘
データをストリームとして表現する方法と、ストリームを変換する方法を紹介する。 ストリームはメッセージが流れる川である Pub/Subメッセージングモデルでメッセージを流すためのオブジェクトのことをストリームと呼ぶことにする。ストリームにはメッセージをPublishでき、またメッセージを受け取ったときの処理をSubscribeできる。例えばキーボードからの入力をPublishして、内容をコンソールに出力するような処理をSubscribeできる。 kamo.jsでストリームを表現する ストリームについて説明するために、kamo.jsというストリームを表現するためのライブラリをつくった。kamo.jsは、ストリームを作成するためのkamo.Streamというコンストラクタ関数を提供する。このコンストラクタ関数から作成されたオブジェクトは、publishとsubscribeというメソッド(※プロパ
APIデザインの極意 - ✘╹◡╹✘
APIデザインの極意 Java/NetBeansアーキテクト探究ノート 作者: Jaroslav Tulach,柴田芳樹出版社/メーカー: インプレスジャパン発売日: 2014/05/23メディア: 単行本（ソフトカバー）この商品を含むブログ (4件) を見る API設計は難しい "良い"APIを設計するのは難しく、APIの良し悪しを定量的に観測することは難しいとされている。後方互換性や拡張性、不具合の発生率などで曖昧に推し量ることはできるが、これは良い、これは悪い、とはっきり決め付けることは出来ない。そもそもAPIから「これ」と呼べるある側面を切り出すことも難しいと言える。また、APIの設計技法を学べる機会は多くないとしている。物事を感覚として認識することはできても、それを表現し他人に伝え信じてもらう方法を持たない場合が存在する。 API設計を芸術的取り組みにしてはいけない API設計の
Ruby + Bot = Ruboty - ✘╹◡╹✘
https://github.com/r7kamura/ruboty RubotyというRuby製のChatterbotをつくった。 Herokuで動かす Herokuにデプロイすれば無料で動く。 Slackというチャットサービスで動かすならこういう感じ (部屋名とかは適宜変える): $ mkdir mybot $ cd mybot $ echo 'source "https://rubygems.org"' >> Gemfile $ echo 'gem "ruboty"' >> Gemfile $ echo 'gem "ruboty-slack"' >> Gemfile $ echo 'bot: bundle exec ruboty' >> Procfile $ bundle install $ git init $ git add . $ git commit -m "Initial
全てが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
XMPP界 - ✘╹◡╹✘
XrcというRubyのXMPPクライアントライブラリをつくったので、XMPP界の知見を共有します。 WHY RubotyというBOT開発用のフレームワークを最近つくっていて、 これをSlackというチャットサービスで利用していた。 SlackにはXMPP GatewayとIRC Gatewayが用意されており、 どちらかのプロトコルを利用すればBOTとして動作するにはひとまず十分だった。 Rubyで一般的なIRCライブラリと言えばnet-ircだけど、 自分でZirconというIRCクライアント用ライブラリを作って、 ruboty-slackでは最初はこれを使ってた。 IRCは雑に全部屋に適当にJOINしてくれたりするのでBOTとして運用するにはわりと楽だったんだけど、 メッセージに改行を簡単に含められないというところが気に入らなくてXMPPを検討することにした。 改行が含められないとどう
Chronoつくった - ✘╹◡╹✘
* * * * * T T T T T | | | | `- wday --- 0 .. 6 | | | `--- month -- 1 .. 12 | | `----- day ---- 1 .. 31 | `------- hour --- 0 .. 23 `--------- minute - 0 .. 59 https://github.com/r7kamura/chrono Rubyでcron形式の構文を利用するために、Chronoというライブラリをつくった。開発動機はRubotyというHubotクローンで利用するためで、チャットからcron形式でジョブを登録することで定期的に発言をしてくれるような機能をつくろうと考えてた (こういうやつ)。 既存のもの clockwork - A clock process to replace cron rufus-scheduler - J
Railsアプリつくった - ✘╹◡╹✘
最近APIサーバ用途でRailsアプリを1個つくったので振り返る。 概要 接続元はiOSやAndroidアプリとか、Webブラウザとか、別のWebアプリケーションとか。1ホストあたり秒間数百リクエスト、平均応答時間10msぐらい。Rails 4.1.0.rc2、Unicorn、Nginxを使ってる。正直Railsは全部入りで重いイメージがあったので何となく平均50ms以内程度であれば良いところだろうと思ってたけど、意外と速い。多分そもそもサーバの性能が良いんだと思う。実装時に気を付けたことは普段の開発と特に変わりない。いつもは大勢でワイワイ開発するものに少し手を加えるということが多いんだけど、今回は珍しく自分一人でつくったから目が行き届いてたのかもしれない。DBへの問合せの効率に気を配るとか、Rubyでの処理の無駄を省くとか、アプリケーションのプロセスに無駄なコードを読み込ませないとか、計
前進してる感 - ✘╹◡╹✘
「目で見て手で触って 自分が何やってるのかちゃんとわかることを仕事にしたいと思ったんだ 弁当屋は作って買ってもらって食べてもらうっていうのが すごいシンプルで具体的でしょ それが楽しいんだ お給料安いけど気分はいいよ」(『にこたま』1巻94頁 著者:渡辺ペコ) さっき読んだ漫画で、登場人物がこういう台詞を言う場面があった。人間が働く理由については疑問が沢山ある。これについては自分のことすら分からない。たまたまある方面に適性があって、学ぶ機会があって、経済的な事情に合致した、その結果に過ぎないという風に考えることもできる。この方面に興味を持ったことすら、周囲の環境がたまたまそうであったからかもしれない。 誰かが決定論という言葉を教えてくれたけど、その言葉を知ったこと自体にあまり意味はなかった。ただ、強く信じられる確かなものが欲しいという欲求があることは分かった。自分が何をやっているのか分かる
雑なレビュー - ✘╹◡╹✘
背景 レビューに時間を掛けているわりにあまり成果が出ていない 問題意識を感じる レビューという行為にもっと周りから理解があればいいのに、という風に考える 原因を外部に求めるのは良くないなと考え直す これまで自分が発言したコメントを読み返す 過度にフォーマル過ぎたり、コードの表層しか指摘していないところが多々あることが分かる 問題 GitHubのPull RequestやIssueでのコメントに、出来るだけ間違いや誤解が無いように気を付けられた丁寧な文章で書いてしまうことが多い。しかしながら、もっと普段互いに会話するときに使うような雑な言葉で書いて、コミュニケーションの量を増やした方が良いんだろうなと思う。 そもそもコミュニケーションの量が足りていないせいで、レビュアーがそのドメインについてあまり理解が得られず、問題の表面的な部分についてのみしか発言出来ないということが沢山ある。サービスごと
Ruby Patterns - ✘╹◡╹✘
この記事には、Rubyを書いているときに「これは言語化されたり公式化されたりしていないけれど基本的には必ずこのパターンに則ってプログラムを書いているな」ということをふと思い出したときにやってきてそのパターンを書く。多分3パターンぐらいで終わると思う。ウケが良ければ思い出す確率が高くなると思う。題材さえあれば何も考えずに書けるので、これを書くコストは全然高くない。 名前が"?"で終わるメソッドは必ずtrueまたはfalseのどちらかを返す trueとfalse以外(例えばnil)が返る可能性がある場合は、必ず式の先頭に!!を付けてtrueかfalseになるようにしてる。 このパターンを守ることがとても大事だという風には全く考えていないけど、もしhas_user?がuserを返すとして、has_user?という名前のメソッドがUserオブジェクトを返すというのは一体どういう意味を持っているのだ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
