タグ

2017年1月7日のブックマーク (5件)

  • 階層構造を持つデータの可視化 - Qiita

    社会に存在するデータのうち、たとえばこのようなデータが該当する。 - コンピュータOSが管理するファイルシステムにおけるファイルとディレクトリの関係 - 書籍の構造(部、章、節) - レガシーな会社組織(社長、部長、課長) - 生物の分類法 - 文献学(philology) 表現方法 大きく三つに分ける。 隣接関係・ダイアグラム(Adjacency diagrams)...入れ子(nested) アイシクル・ツリー(Icicle Tree) サンバースト・チャート(Sunburst Chart) エンクロージャー・ダイアグラム(Enclosure diagrams)...入れ子(nested) ツリーマップ(Treemaps) サークルパッキング(Circle Packing) ノードリンク・ダイアグラム(Node-link diagrams)...積み重ね(stacked) Dendro

    階層構造を持つデータの可視化 - Qiita
  • 「なぜ関数プログラミングは重要か」を要約してみた(その1) - Okapies' Archive

    関数型プログラミング (functional programming) の利点を説く際によく持ち出されるのが、QuickCheck の開発者の一人である John Hughes が 1984 年に著した論文 "Why Functional Programming Matters" だ。「なぜ関数プログラミングは重要か」という題名で日語訳もされているので、読んだことがある人も多いと思う。 要旨としては、冒頭の1章および2章で述べられている「関数型プログラミングが優れているのは、高階関数と遅延評価という、モジュール同士を貼り合わせる強力な『糊』を持っているからだ」という話がほぼ全てで、以降はそれを具体例に基づいて説明する構成になっている。ただ、その具体例として「数値計算アルゴリズム」やら「ゲーム人工知能アルゴリズム」やらの話が延々と続くし、しかもコード例が Haskell の先祖にあたる

    「なぜ関数プログラミングは重要か」を要約してみた(その1) - Okapies' Archive
    kenichiice
    kenichiice 2017/01/07
    「関数型プログラミングが優れているのは、高階関数と遅延評価という、モジュール同士を貼り合わせる強力な『糊』を持っているからだ」
  • 俺のReduxがフレームワークなわけがない - Qiita

    今回は、いかにReduxがフレームワークではなくライブラリであるか、 というのを感じてもらう内容になっています。 Reduxは大変? 皆さんReduxに興味はありますか? Reduxの記事を読んでみたり、実際に試したことがある人は 「たくさん覚えるものがある」 「結構難しい」 「React使わないといけないし使い方が限定される」 そんな印象を受けたんじゃないでしょうか。 私は仕事React+Reduxを使っているんですが、なかなか難しいなぁと感じています。 ES2015、ReactWebpack、Babel、そのほかのReduxをサポートする様々なライブラリ・・・ 多くのものが合わさった結果、「Reduxは大変だ」という印象を抱くに至りました。 Reduxはすごく小さい 余計なものが多くあるせいで複雑に感じるRedux。 ですが、Reduxだけでコードを書くと、こんな風になります。 b

    俺のReduxがフレームワークなわけがない - Qiita
  • テスト計画の立て方 - Qiita

    テスト計画をどう立てていくか、ふつうのシステムエンジニアにとって分かりやすく考えてみたいと思います。 テスト工程は、一番ざっくりした分類で単体テスト、結合テスト、システムテストに別れるのが一般的です。 この工程は、あくまでもV字モデルに対応したインプットがどの前工程で作られたものを検証するかの基準であって、実際にどういう観点をどういう手順でテストするか、はそれぞれのプロジェクトで計画します。それがテスト計画になっていきます。 しかし、ただの工程の話と、実際におこなうテストの内容の違いが分かっていないと、テスト計画何するものぞ状態になって、ろくなテストが実施されないことになりますし、そのようなプロジェクトも多く存在します。 テストの世界標準には、ISO/IEC/IEEE 29119があり、これを見るとテスト工程(Test Level/Phase)とテスト種別(Test Types)の組で、テ

    テスト計画の立て方 - Qiita
  • Flux を使わずに React コンポーネント間のコミュニケーションを行う8つの方法 - Qiita

    注意 これは 8 no-Flux strategies for React component communication を意訳し、自分の解釈や補足を追加した記事になります。 実際に自分が React でコードを書いていて、疑問に思い調べた際に参考にしました(結局は Flux/Redux と 方法1. Props を使ったのですが)。 はじめに React で、最初の大きな問題の1つは「コンポーネントはどうやって他のコンポーネントとコミュニケーションするべきか」という事です。 コンポーネント2がクリックされた事をコンポーネント1に伝える最も良い方法は何でしょうか? これには、とてもたくさんの答えがあります。早かれ遅かれ、Flux が言及されるでしょう。 Flux アーキテクチャでコミュニケーション問題を解決できるでしょうか?Flux は必要でしょうか? この問題は Flux を使用するこ

    Flux を使わずに React コンポーネント間のコミュニケーションを行う8つの方法 - Qiita