10分で GraphQL 入門 - Qiita
これは 6/28 に開催される GraphQL ナイト のための資料です ここまでで分かること クエリは独自言語みたい クエリを変えることで柔軟にデータをとってこれそう クエリと結果の見た目が似てるのは分かりやすそう（主観） でも facebook はなんで作ったの？ facebook の事情 数十億ユーザから膨大なリクエストがくる 新興国の低速なネットワークからのモバイル接続も多い アップデートされないモバイルアプリもサポートする つまり リクエスト回数は可能な限り減らしたい 後方互換を維持しながら API を開発したい 無駄なデータを送りたくない （大規模開発なので型安全も欲しい） 規模は違えど我々も同じような問題を抱えているのでは？ なぜ既存のものではダメだったのか？ より詳しくは昔の graphql.org のページを参照（internet archive） v.s. REST 複
RDB - 実例で学ぶ、JOIN (NLJ) が遅くなる理屈と対処法 - Qiita
"Nested Loop Joinしか取り上げて無いのにタイトルが大きすぎないか" と指摘を頂いたので、タイトルを修正しました。Merge JoinとHash Joinのことはまた今度書こうと思います。 「JOINは遅い」とよく言われます。特にRDBを使い始めて間がない内にそういう言説に触れた結果「JOIN=悪」という認識で固定化されてしまっている人も多いように感じています。 たしかに、JOINを含むようなSELECT文は、含まないものに比べて重たくなる傾向があることは事実です。また、本質的に問い合わせたい内容が複雑で、対処することが難しいものも存在します。しかし、RDBの中で一体どういうことが起きているのかを知り、それに基いて対処すれば高速化できることも少なくないと考えています。 本稿では、JOINの内部動作を解説した上で、Webサービスを作っているとよく出てくるJOIN SQLを例題に
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
結局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
Qiitaの画像アップロード機能も簡単に実装できる。そう、S3ならね。 - Qiita
QiitaとKobitoで画像アップロードができるようになりました。 その後ろ側をちょっぴり公開します。 件名からも分かるように、背後ではAWSのS3を画像ストレージに採用しています。 画像アップロード機能をリリースしました - The Official Qiita Blog Kobito v1.6.1リリース: ドラッグ&ドロップやスクリーンショット撮影で簡単に画像を添付できるようになりました! - The Official Qiita Blog 用語統一 サーバ はQiitaのサーバのことを指すことにします。（つまり、S3ではない、ということ） また クライアント は各ユーザのブラウザのことを指します。 要件 画像アップロード機能を実装するにあたっていくつかの要求がありました。 成りすましを防げる アップロードされたファイルを管理できる 自分達のサーバに負荷をかけたくない 変な画像のア
GitHubのようなtextareaの補完機能を実装する - カーソル位置の取得 - Qiita
続編 JavaScript - Qiitaのtextarea自動補完がOSSになりました GitHubのコメントでは@と入力するとカーソルの下に入力補完が出現する。さらっとやっているが、実はこれが結構難しい。なぜ難しいのかというと、JavaScriptではカーソルが何文字目にいるかは分かるが、 カーソルのXY座標を取得するAPIが存在しない からだ。カーソル位置が分からなければ、適切な位置に補完候補を表示することができない。では一体どうすればいいのか？ 今回Qiitaではコメント欄でのメンションの補完機能を実装した。本稿では前述の問題を解決するために用いたテクニックを解説する。 ちなみにこのメンション補完機能はチーム用プライベートQiitaである「Qiita:Team」でも勿論使える。現在絶賛無料トライアル実施中なので、興味を持たれた方はそちらも使ってみて欲しい。 要約 textarea内
A/Bテストよりすごい？バンディットアルゴリズムとは一体何者か - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? オバマ大統領の再選に大きく寄与したことで大きな注目を集めている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
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コ
なぜGoogleはJSONの先頭に while(1); をつけるのか - Qiita
Stack Overflowに面白い質問があったので紹介する javascript - Why does Google prepend while(1); to their JSON responses? - Stack Overflow 質問 Googleのサービス内で使われるJSONの先頭に while(1); てついているのは何故？ 例えばGoogle Calendarではカレンダーを切り替えるときに以下のような内容のデータがサーバから返される。 while(1);[['u',[['smsSentFlag','false'],['hideInvitations','false'],['remindOnRespondedEventsOnly','true'],['hideInvitations_remindOnRespondedEventsOnly','false_true'],['C
js->coffee移行にあたって考えたこと - Qiita
個人製作のシステムのjsをcoffeeに完全移行したのでその雑感を書きます。あくまでも個人的な感想です。感じ方は人それぞれです。 ちなみに僕は勉強を兼ねて手で移行させましたが、js2coffeeというツールを使うと自動で変換してくれるらしいです。 先に結論 coffeeの方がいいと思う。 よくある批判に「js書けばいいじゃん」というのがあるけど、極端な話、「アセンブラ書けばいいじゃん」と高級言語が出てきた頃に言ってた人と主張の方向性は似てると思う。極端すぎるけど。 jsには落とし穴がいっぱいある。慣れてもたまにはまる。varを忘れたり「関数の頭で全部のvarを列挙する」というプラクティスに従ってたら、冗長になって管理するコスト高くなったり。 coffeeを使うとそういう余計な問題を意識しなくてよくなるのはとても大きい。 しかもjsでできることの全てをcoffeeでできる。工夫が必要になる場
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
