タグ

2014年1月7日のブックマーク (10件)

  • traitで簡単にDCIを実装する - じゅんいち☆かとうの技術日誌

    モデルの表現方法の一つとしてDCIの実装方法を、いろいろと模索しています。 暗黙的型変換と型クラスを使ったDCIがよいと説明しましたが、traitだけでもっと簡単に実現できないか考えてみました(この方法はLean Architectureにも紹介されている実装方式です)。 traitで仕様を表現する traitは、仕様を表現するためのインターフェイスとしても使えるし、他のクラスなどに合成するための、再利用可能な実装(部分クラスなどと言われることがある)としても使えます。 DCIとは直接関係ない話ですが、まずtraitのインターフェイス的な使い方からいきます。 では、お決まりの銀行口座で説明(好きやなーw)。 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 // 銀行口座エンティティ // 不変条件: 残高の量は負数であってはならな

    atsushifx
    atsushifx 2014/01/07
  • Engadget | Technology News & Reviews

    Pick up the 9th-gen iPad with two years of AppleCare+ for only $298

    Engadget | Technology News & Reviews
    atsushifx
    atsushifx 2014/01/07
  • 「LLVM 3.4」リリース、C++14の全仕様をサポートへ | OSDN Magazine

    コンパイラ環境LLVM(Low Level Virtual Machine)を開発するLLVM Projectは6月18日、最新版となる「LLVM 3.4」をリリースした。C/C++フロントエンド「Clang」も新しくなり、自動フォーマットツールなどが加わっている。 LLVMは強力な最適化機能を特徴とするコンパイラフレームワーク。イリノイ大学の研究プロジェクトとしてスタートしたもので、任意のプログラム言語の静的/動的コンパイルをサポートするコンパイラの構築を目指している。ソースコードやターゲットに依存しないコアライブラリを中心に、C/C++/Objective-CコンパイラのClang、GCCと連携してAdaやFortranなどGCCがサポートする言語をLLVMでコンパイル可能にする「dragonegg」など多数のサブプロジェクトを持つ。 LLVM 3.4は2013年6月に公開されたバージ

    「LLVM 3.4」リリース、C++14の全仕様をサポートへ | OSDN Magazine
    atsushifx
    atsushifx 2014/01/07
  • APIオーケストレーション層

    Spring BootによるAPIバックエンド構築実践ガイド 第2版 何千人もの開発者が、InfoQのミニブック「Practical Guide to Building an API Back End with Spring Boot」から、Spring Bootを使ったREST API構築の基礎を学んだ。このでは、出版時に新しくリリースされたバージョンである Spring Boot 2 を使用している。しかし、Spring Boot3が最近リリースされ、重要な変...

    APIオーケストレーション層
    atsushifx
    atsushifx 2014/01/07
  • RESTの代替は必要か

    Spring BootによるAPIバックエンド構築実践ガイド 第2版 何千人もの開発者が、InfoQのミニブック「Practical Guide to Building an API Back End with Spring Boot」から、Spring Bootを使ったREST API構築の基礎を学んだ。このでは、出版時に新しくリリースされたバージョンである Spring Boot 2 を使用している。しかし、Spring Boot3が最近リリースされ、重要な変...

    RESTの代替は必要か
    atsushifx
    atsushifx 2014/01/07
  • ラルス・クリステンセン「黒田ブームは今も国内需要なんだよ」

    Lars Christensen “The Kuroda boom remains all about domestic demand” (The Market Monetarist, January 6, 2014) 去年日銀が過去に例のない金融緩和プログラムを開始ししたとき、ほとんどのコメンテーターはこれを日の輸出を後押しするための通貨戦争遂行の試みとみなしていたことを覚えているだろうか。僕はそれと違って日をデフレの罠から引き上げるのは「輸出経路」ではないだろうと強調した。僕はそれよりも国内需要の重要性を強調したんだ。 僕は去年5月に次のように言った。 現在日銀が行っている政策は、おそらく名目GDP成長を目覚ましく加速させ、実質GDP成長についても近いうちに加速させるだろうと僕は強く信じているけれど、成長へ主に貢献するのが輸出だということについては疑っている。その代わりに僕は、おそ

    ラルス・クリステンセン「黒田ブームは今も国内需要なんだよ」
    atsushifx
    atsushifx 2014/01/07
    アベノミクスの第一の矢、つまり金融政策は国内の景気刺激策であって通貨安狙いではないという話。それが有効ということは日本は流動性の罠に入っていたのではなく今までの金融政策が間違っていたということ
  • ペアリング対コードレビュー: 開発者文化の比較

    前職 と 現職 で、ペアプログラミング文化からコードレビュー文化への移行を経験した。文化の差に適合するのは興味深い経験だった。ちょっと気づいたことを書いてみよう。 (ペアプログラミング|コードレビュー)の(メリット|危険性)みたいな題名の記事はもう山ほどある。著者はどっちかの信奉者なわけだ。私は明確トレードオフがちょっとあるにせよ、どっちの戦略も有効であると認識している。このトレードオフについて、もうちょっとバランスのとれた議論をしてみようと思う。 用語の定義 まず、舞台を整えよう。”ペアプログラミング” とか”コードレビュー”という言葉は、人によってとらえ方が大きく異なることがある。 ペアプログラミング文化 といったとき、作業のほぼ100%をペア作業で行っているチームを指す。一つのタスクに二人の開発者が割り当てられ、同じ画面を共有して作業をする。開発者は両方コード構築のプロセスに関わって

    atsushifx
    atsushifx 2014/01/07
  • norikra を試す(1) - ようへいの日々精進XP

    はじめに Fluentd Casual Talks #3 で norikra の作者である @tagomoris さんのお話を伺ってからずっと試したいと思っていてやっと試せたのでアウトプット。 参考 Norikra 0.1を使ってみた Norikraで遊んでみた fluent-plugin-norikra #fluentdcasual Norikra in action http://esper.codehaus.org/ 5.1. EPL Introduction 5.2. EPL Syntax norikra とは 自分の認識、でも百聞は一見に如かず ちゃんと理解出来ていないけど...以下のような認識でいる。 ログ等のストリームデータを SQL ライクなツールを使って検索出来るツール 例えば、fluentd で処理しているログに対して SQL に似た感じの検索クエリを投げて結果を処理出

    norikra を試す(1) - ようへいの日々精進XP
    atsushifx
    atsushifx 2014/01/07
  • CSSLintのRulesの超訳 | Roughdraft.io

    訳注 これは超訳です。 CSSLintは「なんでこんなルールなんだ…」とイラっとすることが多いですけど、それぞれにそれなりに理由があります。まぁ勿論無視するべきなルールとかもあります。例えば見出し要素の再定義禁止とかはHTML5に対するCSSなら無理な話です。そんなわけでどんな理由なのかを簡単に訳しました。無視するかどうかは自分で決めましょう! この訳はCSSLintと同じライセンスで提供されます。 Possible Errors Beware of box model size 枠線とパディングはwidthやheight等に含まれないので、同時に指定すると多分君が思ってもみない結果になるよ。だから警告するんだ! Rule ID: box-model Require properties appropriate for display もちろんあるセレクタに対してどんなCSSプロパティを一

    CSSLintのRulesの超訳 | Roughdraft.io
  • 技術は発想やデザインの限界にならない

    当時の思い違い たとえば、一般的なエンジニアが何かを作ろうとすると、その個人の「技術的な限界=発想の限界」となりがちです。 ではデザイナーと呼ばれるような職能を持っているひとが、果たしてプロダクトを実装として理解すべきか、というと、それは分業上の実装サイドによるエゴ(こっちの都合もちゃんと考えて欲しい!的な)でしかないと思っていました。 多少、吹っ飛んだ話であっても、意図を失わずに現実的な実装に落とし込むのはコミュニケーションの問題であって、デザイナー職能の理解不足ではない、と。 コミュニケーションでも解決できる問題として、これは今も間違ってはいないはずですが。 しかし、これは適切なタイミングで、大きな青写真を描くための能力であり、デザイナー職能を全うする話とは違ったのです。 優秀とは 身の回りで優秀なデザイナーと呼ばれる諸氏は、ビジュアルを作るだけでなくステートの管理までよく考え、利用コ

    技術は発想やデザインの限界にならない
    atsushifx
    atsushifx 2014/01/07
    技術を限界にしてはいけないだろうな。大事なのはユーザーがプロダクトに対してどんな行動をするかであって、そのためにデザインや技術がある