flowの型情報をnpmパッケージで一緒に配布する - Qiita
TL;DR; flow 0.19.0 から .js.flow 拡張子がついたファイルがあればそれを見るようになった npm パッケージでは型情報を消した .js ファイルと、型情報を持った .js.flow ファイルを一緒に配布する 将来的に flow に特大の後方非互換な変更が入らない限り動くはず npmパッケージも型情報を使いたい 開発時に型情報を書いても、いざ配布するときにはそれを取り外してから配布する。取り外さないと、 flow を使っていないプロジェクトで require することが困難になってしまうためだ。 しかし、そのパッケージを使うときには flow を使いたい。flowtype/flow-typed に自分のライブラリの情報を載せるのが一つの手だが、開発段階で実装が流動的だと更新が面倒なのに加えて、そもそも DRY ではない。 せっかく開発時に書いた型情報を、 npm パ
RDB - 実例で学ぶ、JOIN (NLJ) が遅くなる理屈と対処法 - Qiita
"Nested Loop Joinしか取り上げて無いのにタイトルが大きすぎないか" と指摘を頂いたので、タイトルを修正しました。Merge JoinとHash Joinのことはまた今度書こうと思います。 「JOINは遅い」とよく言われます。特にRDBを使い始めて間がない内にそういう言説に触れた結果「JOIN=悪」という認識で固定化されてしまっている人も多いように感じています。 たしかに、JOINを含むようなSELECT文は、含まないものに比べて重たくなる傾向があることは事実です。また、本質的に問い合わせたい内容が複雑で、対処することが難しいものも存在します。しかし、RDBの中で一体どういうことが起きているのかを知り、それに基いて対処すれば高速化できることも少なくないと考えています。 本稿では、JOINの内部動作を解説した上で、Webサービスを作っているとよく出てくるJOIN SQLを例題に
中規模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)を読んでみた。その結果分かったことを踏まえてざっくりと
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
プルリクエストを自動補完してcheckoutする - Qiita
問題 プルリクエストのレビュー、動作確認をするためにローカルでcheckoutしたいが、ブランチ名を調べて入力するのが面倒くさい。別名をつけてcheckoutできるようにする方法があるが、プルリクエストの番号を調べる必要があってそれも面倒。 もっと簡単にcheckoutしたい!!! 解決策 プルリクエストの一覧からブランチを選択してcheckoutできるようにしました。 1. プルリクエスト一覧を取得する まずプルリクエスト一覧を取得します。そのためにprfetchというスクリプトを書きました。 手っ取り早く下記でインストールできます。 wget https://raw.githubusercontent.com/yuku-t/dotfiles/master/bin/prfetch chmod +x prfetch mv prfetch ~/bin # ~/bin はPATHに入っていると
一日の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 一応これが完成形ですが、ここま
結局jQuery.Deferredの何が嬉しいのか分からない、という人向けの小話 - Qiita
結局jQuery.Deferredの何が嬉しいのか分からない、という人向けの小話 一年ほど前に JavaScript - jQuery.Deferredを使って楽しい非同期生活を送る方法 - Qiita [キータ] という記事を書きました。 で、一年経って、ふと、「もっと分かりやすくjQuery.Deferredの便利さを説明できるんじゃないか」と思い立ってざざざっと書いてみました。 小話と言うにはちょっと長いけど。 -- jQuery.Deferredを使うと嬉しいのは、jQuery.Deferredの仕様を満たす部品同士を簡単に組み合わせることが可能だからです。中には処理を書き下すことができるとかコールバックのネストを防げるのがいいとか言う人もいますが、個人的にこっちのほうがよっぽど重要だと感じます。 例えるならレゴブロックです。レゴブロックはあの凸と凹を持ってるブロックを自由に組み合
GitHubのようなtextareaの補完機能を実装する - カーソル位置の取得 - Qiita
続編 JavaScript - Qiitaのtextarea自動補完がOSSになりました GitHubのコメントでは@と入力するとカーソルの下に入力補完が出現する。さらっとやっているが、実はこれが結構難しい。なぜ難しいのかというと、JavaScriptではカーソルが何文字目にいるかは分かるが、 カーソルのXY座標を取得するAPIが存在しない からだ。カーソル位置が分からなければ、適切な位置に補完候補を表示することができない。では一体どうすればいいのか？ 今回Qiitaではコメント欄でのメンションの補完機能を実装した。本稿では前述の問題を解決するために用いたテクニックを解説する。 ちなみにこのメンション補完機能はチーム用プライベートQiitaである「Qiita:Team」でも勿論使える。現在絶賛無料トライアル実施中なので、興味を持たれた方はそちらも使ってみて欲しい。 要約 textarea内
zshでログイン・ログアウト時に実行されるファイル - Qiita
今まではバカの一つ覚えのように何でもかんでも$HOME/.zshrcに書いていたけど、サーバ管理をよくするようになってきて、複数アカウントの共通設定とかをしたくなったので調べた。 順番 以下の$ZDOTDIRは指定されていない場合$HOMEになる。 ログイン時 /etc/zshenv $ZDOTDIR/.zshenv /etc/zprofile $ZDOTDIR/.zprofile $ZDOTDIR/.zshrc /etc/zlogin $ZDOTDIR/.zlogin ログアウト時 $ZDOTDIR/.zlogout /etc/zlogout 言うまでもなく、個人的な設定は$ZDOTDIRに、汎用的な設定は/etcに書く。 各種説明 zshenv 必ず実行される。/etc/zshenvは上書き不可で$PATHや$MANPATHの設定がされる。 $ZDOTDIR/.zshenvにはいかなる
Backbone.js入門 「Events」 - Qiita
閲覧上の注意 この記事で対象としているバージョン0.5.3は結構古いので注意してください。この記事でいえば、bindは無くなり、現在ではonやlistenToが使われています。 その他の割りと新しい情報は Backbone.js Advent Calendar 2012 などにあります。 （追記ここまで） ネタ切れ感が否めないBackbone.js Advent Calendarですが、今回から何回かに分けて懇切丁寧な入門記事を書いていこうと思います。 以下のように書き進めていく予定です。 Events View Model ViewとModelの連携 Collection ViewとModelとCollectionの連携 RouterとHistory なおここで扱うBackbone.jsのバージョンは0.5.3です。 Backbone.jsのドキュメントを開くとまず最初に解説されているの
js->coffee移行にあたって考えたこと - Qiita
個人製作のシステムのjsをcoffeeに完全移行したのでその雑感を書きます。あくまでも個人的な感想です。感じ方は人それぞれです。 ちなみに僕は勉強を兼ねて手で移行させましたが、js2coffeeというツールを使うと自動で変換してくれるらしいです。 先に結論 coffeeの方がいいと思う。 よくある批判に「js書けばいいじゃん」というのがあるけど、極端な話、「アセンブラ書けばいいじゃん」と高級言語が出てきた頃に言ってた人と主張の方向性は似てると思う。極端すぎるけど。 jsには落とし穴がいっぱいある。慣れてもたまにはまる。varを忘れたり「関数の頭で全部のvarを列挙する」というプラクティスに従ってたら、冗長になって管理するコスト高くなったり。 coffeeを使うとそういう余計な問題を意識しなくてよくなるのはとても大きい。 しかもjsでできることの全てをcoffeeでできる。工夫が必要になる場
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
よく実行するコマンドにキーバインドを割り当てると捗る話 - Qiita