新QiitaでReactをやめてhyperappを採用した背景 - Qiita
12/1 に Qiita のトップページをリニューアルしました。これまで React を使っていましたが、それをやめて hyperapp を採用しました。まわりを見てもあまり採用事例が見当たらないので、この記事では一体なんで今をときめく React ではなく hyperapp を選択したのか、どういうところが魅力的なのかについて プレゼンテーション層を実装するためのツールとして 学習コスト の観点から書きたいと思います。なおこの記事に書かれていることは全て個人の感想であり、はっきりいって個人の日記レベルです。 それと hyperapp の開発者が社内にいるという事情もあるので、そこら辺さっぴいて読んでください。 TL;DR プレゼンテーション層を実装するためのツールとして React は機能過多だし、機能不足 hyperapp は過不足ない 学習コスト 仮想 DOM は学ぶ価値のある知識
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
RDB - 実例で学ぶ、JOIN (NLJ) が遅くなる理屈と対処法 - Qiita
"Nested Loop Joinしか取り上げて無いのにタイトルが大きすぎないか" と指摘を頂いたので、タイトルを修正しました。Merge JoinとHash Joinのことはまた今度書こうと思います。 「JOINは遅い」とよく言われます。特にRDBを使い始めて間がない内にそういう言説に触れた結果「JOIN=悪」という認識で固定化されてしまっている人も多いように感じています。 たしかに、JOINを含むようなSELECT文は、含まないものに比べて重たくなる傾向があることは事実です。また、本質的に問い合わせたい内容が複雑で、対処することが難しいものも存在します。しかし、RDBの中で一体どういうことが起きているのかを知り、それに基いて対処すれば高速化できることも少なくないと考えています。 本稿では、JOINの内部動作を解説した上で、Webサービスを作っているとよく出てくるJOIN SQLを例題に
cartonでライブラリ管理してるperlプロジェクトでvimを良い感じにする - Qiita
project_root ├── local │ └── lib │ └── perl5 │ └── darwin-2level # macの場合 └── lib vimでperlを開くといろいろと良い感じにしてくれるが、多くの場合システムの @INC を使うため不都合を被る場面がでてくる。 thinca/vim-localrc 使うのは thinca/vim-localrc project_rootに.local.vimrcを作ってそこに色々と書いていく gfで正しいファイルに飛べない問題 vimはgfでカーソル以下にあるファイルに飛ぶ機能がある。perlを開いていればそのモジュールに飛ぶ。しかし @INC には入っていないので飛ぶことができない。 これを解決するのは .local.vimrc に下記のように書く。
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からレコードを引っ張っ
モデルの中でurl_helperを使う - Qiita
class Foo < ActiveRecord::Base include Rails.application.routes.url_helpers def base_uri foo_path(self) end end
bundleしてるgemのディレクトリにcdする - Qiita
# bundle cd [gem] _orig_bundle=$(which bundle) function bundle() { if [ "$1" = "cd" ]; then local gem if [ "$2" ]; then gem=$2 else gem=$($_orig_bundle list | awk '{ print $2 }' | percol) fi cd $($_orig_bundle show $gem) else $_orig_bundle $* fi } Gemfileがあるディレクトリで実行するとpercolが起動して、選択したgemのディレクトリにcdできる。（pecoを使ってる人は適宜置き換える） デモ 背景 githubのリポジトリを簡単に取ってこれるghqというツールとgem-srcを組み合わせるとbundle install 時に自動的にgh
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 が必要です。 と言われて、
中規模Web開発のためのMVC分割とレイヤアーキテクチャ - Qiita
TL;DR MVCもレイヤで捉えて関係性の設計をするといいのでは 普通のRubyオブジェクトを積極的に使いたいですね 「パーフェクト Rails」に期待しましょう 長くなって面倒くさくなり、途中から手抜き感が半端ないですが許してください この記事の位置付けなど 7 Patterns to Refactor Fat ActiveRecord Models - Code Climate Blog [翻訳] エリック・エヴァンスのドメイン駆動設計 エンタープライズ アプリケーションアーキテクチャパターン これらの参考文献を踏まえてRailsアプリケーションのリファクタリングをしていて、だいぶ方向性や考え方がまとまってきたので、これからチームに合流する人を想定読者に、Qiitaがどんな感じで作られているのかを文書化したものです。（参考文献の一覧は記事の最後にあります） 内容的には文献[2,3]を踏
Capistrano3におけるRailsのデプロイタスクの内部実装 - Qiita
CapistranoはRailsアプリケーション専用のデプロイツールとして生まれたという歴史的な背景から、今までRails用の機能がCoreモジュールに組み込まれていましたが、昨年リリースされたCapistrano3からはそういった特定のドメインに特化した機能がCoreから排除されて別のRubygemsとして提供されるようになりました。 本稿では、それらRailsデプロイまわりの機能について見ていきたいと思います。 参考 Capistrano3のデプロイフレームワークについては下記の記事を参照してください。 Capistrano3のデプロイフレームワークの使い方 - Qiita capistrano/railsとcapistrano/bundler 具体的にはRailsまわりの機能はcapistrano-railsとcapistrano-bundlerというRubygemsに分割されていま
Capistrano3のデプロイフレームワークの使い方 - Qiita
Capistranoはバージョン3から汎用的なデプロイフレームワークになりました。タスクのフックを利用することで簡単に自分のアプリケーション環境に特化したデプロイプロセスを記述することができます。 本稿では、この汎用化されたデプロイ機能の使い方に焦点を絞って解説したいと思います。より基本的なCapistrano3の解説は 入門 Capistrano 3 ~ 全ての手作業を生まれる前に消し去りたい | GREE Engineers' Blog がよくまとまっているので、そちらを参考にしてください。この参考記事では "5. Capistranoデフォルトタスクの消去" でCapistranoの新規導入時のコストを下げる目的で、このフレームワーク機能を消去しています。本稿はこのフレームワーク機能の使い方を解説するものです。 deployとframeworkの2つの抽象度が用意されている Capi
一日の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 一応これが完成形ですが、ここま
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
Rubocopをsyntasticを使ってVimから自動実行する - Qiita
NeoBundle 'scrooloose/syntastic' let g:syntastic_mode_map = { 'mode': 'passive', \ 'active_filetypes': ['ruby'] } let g:syntastic_ruby_checkers = ['rubocop'] syntastic_mode_map は 'active' もしくは 'passive' を指定します。 'active' だとバッファを保存するたびにsyntasticが走り、 'passive' の場合は :SyntasticCheck 実行時に走ります。 'active_filetypes' は保存の度にsyntasticを走らせるファイルタイプを指定します。 ２つをあわせると、基本的にsyntasticは走らせないけど、rubyのときだけは自動的に走らせる、という設定にな
Facebookみたいにtextareaの一部を強調する - Qiita
Facebookで人物を補完すると、その人物名の周りに枠が表示されて強調されますよね（gif画像参照）。 これのやり方を解説します。 TL;DR textareaの強調表示は、textareaを透明にして後ろにいい感じの背景を設置してるだけ textareaの中にDOMを入れても表示されない パッと考えるとtextareaの中にDOMツリーを入れるとそれが表示されるんじゃないか、と思うかも知れません が、ぜんぜんそんなことは無くて、そのまま文字列が表示されてしまいます。 ご存知のようにtextareaやinputは、他の要素のように子要素を表示するのではなく、自身のvalue属性の値を画面に表示する働きをします。value属性は文字列を格納するためのものなのでDOMを入れられないわけですね。 強調用のDOMを重ねあわせる textareaにはDOMをそのまま入れられないので、仕方がなく周り
Qiitaのtextarea自動補完がOSSになりました - Qiita
jQuery.textcomplete（デモ） GitHubのようなtextareaの補完機能を実装する - カーソル位置の取得 を書いたのも今は昔、いつか続きを書こう書こうと思いながら気がつけば5ヶ月が過ぎました なんか続きを書くのが面倒くさくなったのと、某日本最大レシピ共有サイトの技術部長の人から「OSSにして欲しい」という要請を人伝に受け取ったこともあって、OSS化した次第です。 ライセンス MITライセンス 簡単な使い方 簡単に説明します。詳しくは README を読んでください。 まず jQuery.textcomplete は名前からも分かるように jQuery プラグインになっているので、別途 jQuery が必要です。 <script src="path/to/jquery.js"></script> <script src="path/to/jquery.textcomp
schema.orgに準拠してクローラと会話しよう - QiitaのSEO事情（後編） - Qiita
前編ではHTML5のアウトラインを綺麗にする、というお話でした。アウトラインを綺麗にすれば、検索エンジンにコンテンツの階層構造がどうなっているのか、正しく教えることができます。 けどそれだけでは1つ1つのまとまりが一体何を表しているのかが不明です。 schema.orgに準拠することで、そこに何が書かれているのか、を検索エンジンに教えることができます。 schema.orgとは schema.org はGoogle, Microsoft, Yahoo!などの検索エンジンベンダーが集まってマークアップ方式を標準化している組織とその標準化された仕様を文書化しているサイトです。 例えば「ここは著者のことを書いています」「これは著者の名前です」「この記事が公開されたのはこの日時です」などなど、HTMLの機能だけでは伝えきれない詳細な情報をクローラに伝えるための手段が色々定義されています。 ちなみに
HTMLのアウトライン意識してますか？ - QiitaのSEO事情（前編） - Qiita
「最近Qiitaを検索結果でよく見るようになったなぁ」と感じる人はいませんか？ SEOを頑張ってるWebサービスは数多存在しますが、Qiitaもその中の1つです。 SEOっていうとやれキーワードがどうだこうだ、サイト内リンクがどうだこうだ、という話になってしまいがちですが（そういうのが不要と言っているわけではないですよ）、今回はQiitaがSEOの一環として行なっている数多の取り組みの中で、比較的Web上での言及数の少ない印象のある、HTMLのマークアップについて、外に出せる範囲で、前編と後編に分けて解説したいと思います。 後編はこちら 免責事項的な SEOというのは完全に結果論でしか語ることのできないものです。また時と共に効果的とされるテクニックは変わっていきます。この記事はQiitaの中の人が「効果あるんちゃうか」と試行錯誤しながらあれこれ行なっていることの一部を紹介するものであって、
結局jQuery.Deferredの何が嬉しいのか分からない、という人向けの小話 - Qiita
結局jQuery.Deferredの何が嬉しいのか分からない、という人向けの小話 一年ほど前に JavaScript - jQuery.Deferredを使って楽しい非同期生活を送る方法 - Qiita [キータ] という記事を書きました。 で、一年経って、ふと、「もっと分かりやすくjQuery.Deferredの便利さを説明できるんじゃないか」と思い立ってざざざっと書いてみました。 小話と言うにはちょっと長いけど。 -- jQuery.Deferredを使うと嬉しいのは、jQuery.Deferredの仕様を満たす部品同士を簡単に組み合わせることが可能だからです。中には処理を書き下すことができるとかコールバックのネストを防げるのがいいとか言う人もいますが、個人的にこっちのほうがよっぽど重要だと感じます。 例えるならレゴブロックです。レゴブロックはあの凸と凹を持ってるブロックを自由に組み合
この夏Google Analyticsが新しくなるって知ってた？Universal Analyticsを予習しよう - Qiita
この夏Google Analyticsが新しくなるって知ってた？Universal Analyticsを予習しようJavaScriptGoogleAnalytics 意外と認知度が低い感じですが、Google Analyticsがそろそろ新しくなりますよ！ 現在パブリックベータとして提供されているUniversal Analyticsが 予定では 7月中 に正式リリースになります。つまり今月！ 世の中見渡していると非エンジニアなウェブマスター向けの紹介記事が多い印象なので、ここではJavaScriptのインタフェースがどう変わったか、それを使ってエンジニアはどういうことができるようになるか、みたいな、よりエンジニア向けの話題を中心に書いてみたいと思います。 ソースは公式ドキュメントなので、より詳しく知りたい方はそちらを参照してください。 簡単なまとめ Universal Analytics
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
