ブックマーク / www.infoq.com (12)

  • TwitterによるReactベースのモバイルWebスタックはネイティブのパフォーマンスに匹敵する

    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が最近リリースされ、重要な変...

    TwitterによるReactベースのモバイルWebスタックはネイティブのパフォーマンスに匹敵する
  • ドメイン駆動設計でビジネスを駆動する

    ソフトウエア開発者はコードの設計と維持だけでなく、その経験を生かしてビジネスサイドに方向を与える能力も持ちつつある。ドメイン駆動設計(DDD)を使うことで、開発者は顧客の振る舞いを見つけビジネスの性質を変化させるための施策を推奨できる。 Jef Claes氏(http://jefclaes.be)はオフショアの開発者によって作られたアプリケーションを自分たちのチームで管理、拡張しやすいようにリファクタリングする仕事をした。新しいリファクタリングされたアプリケーションはオンラインギャンブルという氏の会社のビジネスのニーズにより整合的ではならない。氏はリファクタリングにDDDの方法論を導入した。集約、エンティティ、値オブジェクトを作り、状態の仕組みとしてイベントソーシングを採用した。結果、システムはビジネスの施策と会社の文化に変化を起こすような顧客の振る舞いを見つけたのだった。 InfoQは氏

    ドメイン駆動設計でビジネスを駆動する
  • 私がMVCフレームワークをもはや使わない理由

    数ヶ月前、私はなぜここにたどり着き、何が可能かを理解する旅に出ました。この旅は、私にアプリケーションアーキテクチャ、MVCという強烈な宗教に対する疑いをもたらしました。そして、リアクティブ、関数型プログラミングの真の実力に触れたのです。また、シンプルさに集中する旅でもあり、私たちの産業はうまくやっているという考えを捨てる旅でもありました。どんなことを見つけたか興味がある方もいるでしょう。 私たちの見ている画面の背後にあるパターンはMVC –Model-View-Controllerです。まだウェブがなくソフトウエアアーキテクチャも分厚いクライアントが単一のデータベースに原始的なネットワークでアクセスするのがせいぜい、という時代にMVCは生まれました。そして数十年後、MVCはまだ現役であり、衰え知らずでオムニチャネルアプリケーションの開発に使われています。 Angular2のリリースの前にM

    私がMVCフレームワークをもはや使わない理由
  • 大規模システムの保守における技術的負債とチームのモラル

    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が最近リリースされ、重要な変...

    大規模システムの保守における技術的負債とチームのモラル
  • Martin Fowler氏の語る“犠牲的アーキテクチャ"

    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が最近リリースされ、重要な変...

    Martin Fowler氏の語る“犠牲的アーキテクチャ"
    amazedkoumei
    amazedkoumei 2014/11/14
    具体的にはモジュール化しなさいってなってチンケな話に思えるけど、大事な部分は捨て去ることは悪いことじゃないんだよって考え方の部分ですよね
  • ShellShockの衝撃 -- バグの舞台裏

    原文(投稿日:2014/09/29)へのリンク 現在悪名高い、例のbashのバグCVE-2014-6271 は、後に「ShellShock」として知られるようになった。このバグはコードのリモート実行を許可してしまうもので、直接的または間接的にbashスクリプトを実行しているサーバに対し、巧妙に作成されたデータをネットワーク越しに送信することで起こる。最初のバグは修正されたが、後続の、解析ルーチンに関するゼロデイの懸念は2つ目の脆弱性CVE-2014-7169をもたらした。こちらの脆弱性は公開されてから週末にかけて修正された。しかし、この脆弱性はなぜ起こったのだろうか。また、この手のバグはこれが最後となるのだろうか。FreeBSDやNetBSDは、関数を自動的にインポートする機能をデフォルトで無効にした。将来の脆弱性を防ぐためだ。 問題が発生する理由は、Bashシェルにとある機能( バグでは

    ShellShockの衝撃 -- バグの舞台裏
  • Amazon、iOS向けMobile Associates 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が最近リリースされ、重要な変...

    Amazon、iOS向けMobile Associates APIを発表
  • NetflixのAPI最適化

    先月1ヶ月間に渡って、Netflixは同社が1年以上前に始めたAPI最適化に関する話を発表した。当初は通信を少なくしペイロードのサイズを小さくすることで性能の最適化しようとしていた[1]が、1年にわたる再設計の結果、APIの開発と運用を分散化しサービス層は非同期になった。再設計の第一の特徴はクライアントとサーバの責任の境界[2]を再定義したことだ。こうすることでコンテンツのフォーマッティングなどきめ細かいカスタマイズが可能になり、Netflixに接続する多様なクライアントデバイス間の差異(メモリ、キャパシティ、ドキュメント配信、モデル、ユーザインターフェース)に対処できる。 InfoQはNetflixのシニアソフトウエアエンジニアであるBen Christensen氏に設計の詳細について話を聞いた。 InfoQ: 1年前、性能最適化を始めたころのNetflix APIのアーキテクチャを教え

    NetflixのAPI最適化
  • Docker: Linuxコンテナを使ってアプリケーションの配置を支援する

    サーバアプリケーションの配置はますます複雑になっています。いくつかのPerlスクリプトをコピーするだけでインストールが完了する時代は終わりました。今日、ソフトウエアは多くの種類の要求を抱えています。 インストールするソフトウエアやライブラリの依存物("Python >= 2.6.3とDjango 1.2に依存する") 実行するサービスへの依存("MySQL 5.5とRabbitMQのキュー"が必要) 特定のOSに対する依存("64-bit Ubuntu Linux 12.04でビルドとテストをした") リソースの要件: 利用可能なメモリの最少量("1GBのメモリが必要") 特定のポートへのバインド("80と443を使う") 例えば、比較的シンプルなアプリケーションの配置を考えてみましょう。Wordpressです。典型的なWordpressのインストールでは、 Apache 2 PHP 5

    Docker: Linuxコンテナを使ってアプリケーションの配置を支援する
    amazedkoumei
    amazedkoumei 2014/02/13
    わかりやすかた
  • 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の代替は必要か
  • InfoQ: Tracking change and innovation in the enterprise software development community

    InfoQ Software Architects' Newsletter A monthly overview of things you need to know as an architect or aspiring architect. View an example

    InfoQ: Tracking change and innovation in the enterprise software development community
  • スクラムの先へ進む

    アジャイル初心者の多くは、スクラムアジャイルをはじめる。スクラムには明確な指針、ルール、プラクティスがあり、チームにアジャイルを導入するのに役に立つ。ところがスクラムもまた組織の中でさまざまな問題に直面し、多くの会社にとって成功を難しくする一因になっている。スクラムをやってきた人たちは自問する。どうすればよいのだろう? スクラムだけで十分なのだろうか? Jimmy Bogard氏は、なぜスクラムをやめたのか、なぜ彼のチームはスクラムで成功した後、そのコアプラクティスをいくつかやめることでパフォーマンスを改善できたのかについて、次のように説明する。 イテレーションはpullベースのアプローチほど効率的ではない。 タイムボックスで仕事をすること、割り当てて空きを埋めることには、何かしら心理的影響があります。明確なタイムボックスのイテレーションをやめて、できる限り早く納品することにのみ注力する

    スクラムの先へ進む
  • 1