10分で GraphQL 入門 - Qiita
これは 6/28 に開催される GraphQL ナイト のための資料です ここまでで分かること クエリは独自言語みたい クエリを変えることで柔軟にデータをとってこれそう クエリと結果の見た目が似てるのは分かりやすそう（主観） でも facebook はなんで作ったの？ facebook の事情 数十億ユーザから膨大なリクエストがくる 新興国の低速なネットワークからのモバイル接続も多い アップデートされないモバイルアプリもサポートする つまり リクエスト回数は可能な限り減らしたい 後方互換を維持しながら API を開発したい 無駄なデータを送りたくない （大規模開発なので型安全も欲しい） 規模は違えど我々も同じような問題を抱えているのでは？ なぜ既存のものではダメだったのか？ より詳しくは昔の graphql.org のページを参照（internet archive） v.s. REST 複
新QiitaでReactをやめてhyperappを採用した背景 - Qiita
12/1 に Qiita のトップページをリニューアルしました。これまで React を使っていましたが、それをやめて hyperapp を採用しました。まわりを見てもあまり採用事例が見当たらないので、この記事では一体なんで今をときめく React ではなく hyperapp を選択したのか、どういうところが魅力的なのかについて プレゼンテーション層を実装するためのツールとして 学習コスト の観点から書きたいと思います。なおこの記事に書かれていることは全て個人の感想であり、はっきりいって個人の日記レベルです。 それと hyperapp の開発者が社内にいるという事情もあるので、そこら辺さっぴいて読んでください。 TL;DR プレゼンテーション層を実装するためのツールとして React は機能過多だし、機能不足 hyperapp は過不足ない 学習コスト 仮想 DOM は学ぶ価値のある知識
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を例題に
CircleCIで任意のprivateリポジトリをcloneする - Qiita
自動的にCircleCIがいい感じに調整してくれるのでGitHubのprivateリポジトリをCircleCIでテストするのは簡単ですが、テスト過程で他のprivateリポジトリをcloneするにはちょっとした工夫が必要になります。 CircleCIにuser keyを登録する まずCircleCIの "Project settings" > "Checkout SSH keys" に行きます。 みたいなのがあるので、ボタンをクリックします。するとGitHubのOAuthページが表示され公開鍵への書き込み権限を要求されるので許可します。 これによりあなたのGitHubアカウントに新しい公開鍵が設定され、それに対応する秘密鍵がCircleCI上に登録されます。なので、あなたがアクセス権限を持つGitHub上のPrivateリポジトリにはこの時点で全てこのCircleCIのプロジェクトからはア
中規模Web開発のためのMVC分割とレイヤアーキテクチャ - Qiita
TL;DR MVCもレイヤで捉えて関係性の設計をするといいのでは 普通のRubyオブジェクトを積極的に使いたいですね 「パーフェクト Rails」に期待しましょう 長くなって面倒くさくなり、途中から手抜き感が半端ないですが許してください この記事の位置付けなど 7 Patterns to Refactor Fat ActiveRecord Models - Code Climate Blog [翻訳] エリック・エヴァンスのドメイン駆動設計 エンタープライズ アプリケーションアーキテクチャパターン これらの参考文献を踏まえてRailsアプリケーションのリファクタリングをしていて、だいぶ方向性や考え方がまとまってきたので、これからチームに合流する人を想定読者に、Qiitaがどんな感じで作られているのかを文書化したものです。（参考文献の一覧は記事の最後にあります） 内容的には文献[2,3]を踏
curlを捨ててhttpieを使おう - Qiita
jkbr/httpie : Github : HTTPie is a CLI, cURL-like tool for humans curl（see urlと発音するらしい本家のFAQによると開発陣は kurl と発音してるらしいです）はプログラムから使うには便利だけど、オプションがわかりにくい。 httpieはより直感的なcurl代替コマンド。よほどcurlに思い入れがない限りhttpieをおすすめする。 インストール 使用例 奥がcurlで、手前がhttpieを使った場合。見れば分かるようにhttpieは自動で色付けをしてくれるし、コマンドもかなり直感的だ。内部的にはPythonのrequestsというモジュールを使っている。Python組み込みのHTTPクライアントに辟易している人はそちらも調べてみるととても幸せになれる。 kennethreitz/requests : Github
なぜ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
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
