PaperTrailはどうやってActiveRecordのバージョン管理をしているか - Qiita
この記事はRails Advent Calendar 2014の21日目の記事です。 Qiitaでは投稿の履歴管理にpaper_trailというgemを使っています。本稿ではPaperTrailがどんな感じでイベント情報をDBに保存しているかを紹介しつつ、PaperTrailが作り出すversionオブジェクトの渡り歩き方を簡単に解説したいと思います。 PaperTrailを使ってみよう 前提 PaperTrailで管理している Item modelがあり、そのインスタンスを2回編集してから削除したとします。 コードで表現するならこんな感じです。 class Item < ActiveRecord::Base has_paper_trail end item = Item.create(body: 'foo') item.update_attributes(body: 'bar') ite
Reactjsのチュートリアルを読んで浮かんだ疑問とそれに対する答え - Qiita
Reactjsのチュートリアルを読んでみて、大雑把なReactjsの使い方を把握したのですが、疑問に思った点がいくつかあったので調べてみました。 前提 筆者のReactjs力がどれくらいかと言うと 存在は知ってたが、中身は全く知らなかった VirtualDom - なぜ仮想DOMという概念が俺達の魂を震えさせるのかを読んだ だけの状態です。つまりコンセプトは知っているが、細かい話は何も知らなかった状態です。その状態で前述のチュートリアルを読んだ感じです。 var CommentBox = React.createClass({ render: function() { return ( <div className="commentBox"> Hello, world! I am a CommentBox. </div> ); } }); React.render( <CommentBox
Qiitaの通知を表示できるChrome拡張を作った - Qiita
画面の上の方に出てくる通知を見れるChrome拡張を勉強がてら作りました。よければ使ってみて下さい。 Chrome Web Store - Qiita Notifications taka84u9/qiita-notifications クロール間隔は150秒です。 HTTP通信の履歴からAPIを予測して（つまり非公開APIを用いて）作っているので、突然APIが変わったりして動かなくなったりする可能性があります。 また、バグなんかがあったら、GithubのページかQiitaに書いてくれれば、極力対応します。 ソースコードはオープンですが、最初の実装がQiitaに過剰にアクセスする感じだったので、キャッシュをさせたりなんなりしていたら、だんだんコードを綺麗に保つのが面倒になってしまって、つまり、汚いです。 最初の仕事はリファクタリングですかね。 Register as a new user
vimgrepとQuickfix知らないVimmerはちょっとこっち来い - Qiita
「vim入門」系記事で解説されないためか、意外と使い方が知られていないvimgrep。 ファイルを開いては検索、開いては検索ってしてる？ grepするためにvimから出てる？ grep結果を見て改めてvimで開き直してる？ それ、vimgrep使えば256倍早くなる（かも）よ。 簡単なまとめ vimgrepは… ファイルをまたいで検索できる grepやgit-grepよりは遅いので巨大プロジェクトでは検索対象を絞ったほうがいい ワイルドカード使うと簡単に絞り込める 繰り返し同じ対象から検索する場合はargument listを使うと捗る gitリポジトリではgit-ls-filesと組み合わせる 該当箇所に素早く移動＆編集できる quickfix-windowと組み合わせると更に捗る この記事読むと分かること :vimgrepコマンドの使い方 :cwindowコマンドの使い方 :argsコ
GOPATH は適当に決めて問題ない - Qiita
TL;DR go get は Ruby でいう gem みたいなもん $GOPATH は自分の環境に合わせて好きに指定してよい 例えば $HOME/.go とか $HOME/go とか 好きに設定してもいいけど、一度設定したらそれをずっと使い続けた方がたぶんいい 現在では、GOPATHを明示的に設定しない場合は自動的に設定される。 Wikiより If no GOPATH is set, it is assumed to be $HOME/go on Unix systems and %USERPROFILE%\go on Windows. ことの始まり homebrewでGoをインストールしたらのっけから Go 1.1 から go get コマンドは $GOROOT をパッケージダウンロード先として使わなくなりなりました。 go get 使うには $GOPATH が必要です。 と言われて、
ActiveRecordを高速化するAdequateRecordは何をするものか - Qiita
TL;DR AdequateRecordはActiveRecordの機能の名前 新しいgemとかでは無い #find #find_by そして #find_by_XXXを2倍に高速化する 引用: AdequateRecord Pro™: Like ActiveRecord, but more adequate | Tenderlovemaking 内部的にはクエリ呼び出しの度にActiveRecordが生成するオブジェクトをキャッシュする 対象を#findなどに限っているのは、生成されるオブジェクトや条件が単純だから Rails 4.2.0 beta1 リリース 先日Rails 4.2.0 beta1がリリースされて、そのリリースブログの中にAdequate Recordなるものが ActiveRecordの動作 ActiveRecordの#whereなどを使ってDBからレコードを引っ張っ
GitHubのようなtextareaの補完機能を実装する - カーソル位置の取得 - Qiita
続編 JavaScript - Qiitaのtextarea自動補完がOSSになりました GitHubのコメントでは@と入力するとカーソルの下に入力補完が出現する。さらっとやっているが、実はこれが結構難しい。なぜ難しいのかというと、JavaScriptではカーソルが何文字目にいるかは分かるが、 カーソルのXY座標を取得するAPIが存在しない からだ。カーソル位置が分からなければ、適切な位置に補完候補を表示することができない。では一体どうすればいいのか？ 今回Qiitaではコメント欄でのメンションの補完機能を実装した。本稿では前述の問題を解決するために用いたテクニックを解説する。 ちなみにこのメンション補完機能はチーム用プライベートQiitaである「Qiita:Team」でも勿論使える。現在絶賛無料トライアル実施中なので、興味を持たれた方はそちらも使ってみて欲しい。 要約 textarea内
.zshrcで見かけるautoloadの意味と使い方 - Qiita
今回はこの autoload が何をするものなのか解説します。 autoloadはシェル関数を読み込む autoload はシェル関数を 自動読み込み するシェルの組み込み関数です。上記のスクリプトの場合、 compinit というシェル関数を自動読み込みします。 シェルコマンドは PATH に入っていればそれだけで実行可能でしたが、シェル関数の場合は関数を定義しなければ使えません。 autoload はファイルシステム上にある関数定義を読み込むための関数なのです。そして autoload 探索するディレクトリは FPATH に入っています。 余談ですが FPATH だと : 区切りの文字列、 fpath だと配列になります。PATH と path と同じですね。 シェル関数とシェルコマンドの違い autoloadを使ってみる % mkdir ~/functions % FPATH="${
中規模Web開発のためのMVC分割とレイヤアーキテクチャ - Qiita
TL;DR MVCもレイヤで捉えて関係性の設計をするといいのでは 普通のRubyオブジェクトを積極的に使いたいですね 「パーフェクト Rails」に期待しましょう 長くなって面倒くさくなり、途中から手抜き感が半端ないですが許してください この記事の位置付けなど 7 Patterns to Refactor Fat ActiveRecord Models - Code Climate Blog [翻訳] エリック・エヴァンスのドメイン駆動設計 エンタープライズ アプリケーションアーキテクチャパターン これらの参考文献を踏まえてRailsアプリケーションのリファクタリングをしていて、だいぶ方向性や考え方がまとまってきたので、これからチームに合流する人を想定読者に、Qiitaがどんな感じで作られているのかを文書化したものです。（参考文献の一覧は記事の最後にあります） 内容的には文献[2,3]を踏
A/Bテストよりすごい？バンディットアルゴリズムとは一体何者か - Qiita
オバマ大統領の再選に大きく寄与したことで大きな注目を集めているA/Bテスト。A/Bテストを導入した、することを検討している、という開発現場も多いのではないだろうか。 そんな中、Web上で次のような議論を見つけた。 20 lines of code that will beat A/B testing every time Why multi-armed bandit algorithm is not “better” than A/B testing 一言でまとめると「A/Bテストよりバンディットアルゴリズムの方がすごいよ」「いやいやA/Bテストの方がすごいし」ということだ。 で、バンディットアルゴリズムとは一体何者なのか？ そこでBandit Algorithms for Website Optimization (O'REILLY)を読んでみた。その結果分かったことを踏まえてざっくりと
Capistrano3のデプロイフレームワークの使い方 - Qiita
Capistranoはバージョン3から汎用的なデプロイフレームワークになりました。タスクのフックを利用することで簡単に自分のアプリケーション環境に特化したデプロイプロセスを記述することができます。 本稿では、この汎用化されたデプロイ機能の使い方に焦点を絞って解説したいと思います。より基本的なCapistrano3の解説は 入門 Capistrano 3 ~ 全ての手作業を生まれる前に消し去りたい | GREE Engineers' Blog がよくまとまっているので、そちらを参考にしてください。この参考記事では "5. Capistranoデフォルトタスクの消去" でCapistranoの新規導入時のコストを下げる目的で、このフレームワーク機能を消去しています。本稿はこのフレームワーク機能の使い方を解説するものです。 deployとframeworkの2つの抽象度が用意されている Capi
gem installでGitHubリポジトリにある最新版をインストールする - Qiita
って書いて bundle update spring を実行してね。 参考: https://github.com/jonleighton/spring/issues/143#issuecomment-17984728 みたいなことがある。だいたいの場合はこれでいいんだけど、ここで引用しているspringの場合、これで直るのは bundle exec spring だけで、 bundle exec 無しだと実行できない。（僕の勘違いかも知れないので、正しいやり方を知っている人は是非コメントで教えてください。） 我慢して古いバージョンをRubygemsから引っ張ってきてインストールしてもいいんだけど、やっぱりbundlerでインストールしてあるのと同じバージョンにしたい。 で、gemコマンドにはgitリポジトリを指定して直接インストールする機能が無いので、こういう場面ではspecific_i
Boxen使ってて許されるのは2013年だけだった - Qiita
Boxen使わなくても許されるのは2012年までだよね を書いたのも今は昔、1年間の運用の末にこの度Boxenを卒業しました。なぜBoxenをやめたのか、やめて今はどうしているのか、といった話を書きます。 Boxenのつらいところ ここで述べるBoxenの問題点の大部分は筆者のBoxenおよびPuppetに対する理解の低さが根底にあります。間違った使い方をしている可能性は十分にあり、適切に使っていればこのような問題は発生しないのかも知れません。しかしながら、深い理解がなければまともに使えないというのもどうかと思いますのでつらつらと並び立てたいと思います。 挙動を把握するのが難しい BoxenはPuppetの上で動作します。Puppetを便利に使うためのフレームワークみたいな位置づけだと思っています。 Rubyに詳しくなくても、RailsのDSLを組み合わせるととりあえず動くものを作れるよう
サーバが特定UAから接続可能であることをテストする - Qiita
serverspecを使うと簡単に特定ポートをlistenしていることを確認できるが、このポートに特定のUAでアクセスできることをテストするmatcherを書いた。 RSpec::Matchers.define :be_reachable_by do |ua| match do |port| if /(\d+)/ =~ port.to_s b = backend.backend_for('ssh') b.run_command("curl -A #{ua} localhost:#{Regexp.last_match(1)}").exit_status == 0 else false end end end
Node書くならEventEmitterについて知っとくべし - Qiita
Nodeの組み込みモジュール・サードパーティモジュール問わず広く使われるのが EventEmitter オブジェクト。 これはNodeで使われるデザインパターンの筆頭みたいなものなので、知っておかねばならない。 ドキュメント: Events ブラウザ上のJavaScriptで addEventListener を使ってイベントドリブンの開発を行うが、Node上でそれを行うのための機能を提供するのが EventEmitter。 例えば次のように使う var EventEmitter = require('events').EventEmitter; function asyncFunc() { var ev = new EventEmitter; console.log('in asyncFunc'); setTimeout(function () { ev.emit('done', 'fo
一日のGitコミットをMarkdownに変換するワンライナー - Qiita
echo "$(PROJECT=$(url=$(git config remote.origin.url) && url=${url#*github.com?} && echo ${url%.git}) && echo "hash | title" && echo "-----|------" && git log --since='12 hours ago' --author=$(git config user.email) --pretty="format:[%h](https://github.com/$PROJECT/commit/%h) | %s" | perl -nle "\$_ =~ s|#(\\d+)|[#\\1](https://github.com/${PROJECT}/pull/\\1)|g; print \$_")" | pbcopy 一応これが完成形ですが、ここま
js->coffee移行にあたって考えたこと - Qiita
個人製作のシステムのjsをcoffeeに完全移行したのでその雑感を書きます。あくまでも個人的な感想です。感じ方は人それぞれです。 ちなみに僕は勉強を兼ねて手で移行させましたが、js2coffeeというツールを使うと自動で変換してくれるらしいです。 先に結論 coffeeの方がいいと思う。 よくある批判に「js書けばいいじゃん」というのがあるけど、極端な話、「アセンブラ書けばいいじゃん」と高級言語が出てきた頃に言ってた人と主張の方向性は似てると思う。極端すぎるけど。 jsには落とし穴がいっぱいある。慣れてもたまにはまる。varを忘れたり「関数の頭で全部のvarを列挙する」というプラクティスに従ってたら、冗長になって管理するコスト高くなったり。 coffeeを使うとそういう余計な問題を意識しなくてよくなるのはとても大きい。 しかもjsでできることの全てをcoffeeでできる。工夫が必要になる場
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
簡単にトピックブランチだけでinteractive rebaseする - Qiita
特定ユーザにのみtty無しでのsudoを認める - Qiita
tmuxでSSH時に変更したwindow-nameを自動でもとに戻す - Qiita