タグ

2016年12月13日のブックマーク (7件)

  • 中規模Web開発のためのMVC分割とレイヤアーキテクチャ - Qiita

    TL;DR MVCもレイヤで捉えて関係性の設計をするといいのでは 普通のRubyオブジェクトを積極的に使いたいですね 「パーフェクト Rails」に期待しましょう 長くなって面倒くさくなり、途中から手抜き感が半端ないですが許してください この記事の位置付けなど 7 Patterns to Refactor Fat ActiveRecord Models - Code Climate Blog [翻訳] エリック・エヴァンスのドメイン駆動設計 エンタープライズ アプリケーションアーキテクチャパターン これらの参考文献を踏まえてRailsアプリケーションのリファクタリングをしていて、だいぶ方向性や考え方がまとまってきたので、これからチームに合流する人を想定読者に、Qiitaがどんな感じで作られているのかを文書化したものです。(参考文献の一覧は記事の最後にあります) 内容的には文献[2,3]を踏

    中規模Web開発のためのMVC分割とレイヤアーキテクチャ - Qiita
  • 2016年、サーバーサイドエンジニアがゼロからReact/Reduxを学習したときの方法を振り返る

    こんにちは。スタジオ・アルカナのサーバーサイドエンジニアなっちゃん(@natsumican63)です。 この記事はReact Advent Calendar 2016の13日目の記事です。 それは2016年も後半へ差し掛かったある日のことでした… 上司「次の案件、この辺の技術使うから軽く勉強しておいてー」 つ React.js + Redux.js + redux-saga + Cordova + ES6 + Babel + OnsenUI + Gulp + Webpack ( ゚д゚) (つд⊂)ゴシゴシ (;゚ Д゚) !?!? (; ゚д゚)「…わ、わかりました」 ※「何でもやります!やらせてください!」が私の口癖なので、決して無茶振りしてくる弊社ではありませんよ!ほんとだよ!! 斯くして2016年、サーバーサイドエンジニアがはじめてフロントエンドへの門戸を開くこととなった際の学

    2016年、サーバーサイドエンジニアがゼロからReact/Reduxを学習したときの方法を振り返る
  • PICTでテストケースの組み合わせ爆発にさよならを - エンジニアをリングする

    Goodpatch Advent Calendar 2016 13日目の記事です! わたしはGoodpatchでProttというプロトタイピングツールのWebフロントエンドの開発を担当しています。 Prottでは、プロトタイプの再生に関する修正をしたあとは必ず全動作を網羅したテスト用プロジェクトでの動作確認を行っています。 ただ、すべての環境や条件を揃えた上でのテストにはなかなかの工数がかかってしまっていました。 この記事では、オールペア法という手法とPICTというCLIツールを使用してテスト工数を半分以下に削減した方法を紹介します。 単純に全組み合わせ 推奨環境としているOSやブラウザと3種類の再生モードを組み合わせると、テストすべき組み合わせは全部で20パターンになります。 (プレビューモードとプレゼンテーションモードは対PC、スタンドアロンモードは対モバイルのモードです。) - Ma

    PICTでテストケースの組み合わせ爆発にさよならを - エンジニアをリングする
  • The Twelve-Factor App (日本語訳)

    はじめに 現代では、ソフトウェアは一般にサービスとして提供され、Webアプリケーション や Software as a Service と呼ばれる。Twelve-Factor Appは、次のようなSoftware as a Serviceを作り上げるための方法論である。 セットアップ自動化のために 宣言的な フォーマットを使い、プロジェクトに新しく加わった開発者が要する時間とコストを最小化する。 下層のOSへの 依存関係を明確化 し、実行環境間での 移植性を最大化 する。 モダンな クラウドプラットフォーム 上への デプロイ に適しており、サーバー管理やシステム管理を不要なものにする。 開発環境と番環境の 差異を最小限 にし、アジリティを最大化する 継続的デプロイ を可能にする。 ツール、アーキテクチャ、開発プラクティスを大幅に変更することなく スケールアップ できる。 Twelve-F

  • LaravelでRequestとModelのインピーダンスミスマッチを解消するときのベストプラクティスを探る - Qiita

    はじめに このエントリーについて この記事は「Laravelでウェブアプリケーションをつくるときのベストプラクティスを探る」シリーズの番外編です。 他の記事は目次からアクセスしてください。 先日こちらの記事を読んで、そう言えば Request と Model のインピーダンスミスマッチをどうやって解消するのがベストプラクティスかなぁと思ったので、考えてみました。 Laravelで電話番号のバリデーションエラーメッセージの重複を避ける - Qiita 環境 PHP 5.6 Laravel 5.3 詳細 メインはあくまでもインピーダンスミスマッチの話なんですが、ついでに、長らく以下のようなデータの取り出し方が気持ち悪くてなんとかならないかなぁ、と思っていたので、それに対する対処でもあります。 何が気持ち悪いかっていうと、_token っていう、フレームワークの内側で使っている CSRF プロテ

    LaravelでRequestとModelのインピーダンスミスマッチを解消するときのベストプラクティスを探る - Qiita
  • LaravelでDBと連携したバリデーションを行う - Qiita

    class RegisterUserRequest extends FormRequest { public function authorize() { return true; } public function rules() { return [ 'email' => [ 'required', 'email', 'confirmed', Rule::unique('users')->ignore(false, 'canceled'), ], ]; } public function messages() { return [ // ]; } }

    LaravelでDBと連携したバリデーションを行う - Qiita
  • 「WebAPI 設計のベストプラクティス」に対する所感 - Qiita

    「翻訳: WebAPI 設計のベストプラクティス」を読んで色々と思うところがあったので書きました。 上記の記事は訳文でありますので、正しくは「Best Practices for Designing a Pragmatic RESTful API」に対する所感と述べた方が良いのかもしれませんが、日語で通して読めるよう Qiita に投稿された訳文に対する所感として書いています。 以下では「翻訳: WebAPI 設計のベストプラクティス」並びに「Best Practices for Designing a Pragmatic RESTful API」は「当該記事」と表現します。 観点 当該記事では「○○とした方がよい」との意見に対してそうすべき理由が明らかになっていないか、もしくは表現が曖昧な場合が目立っていると感じました。設計は実装のようにプログラム言語仕様が制約を与えられないため、意図

    「WebAPI 設計のベストプラクティス」に対する所感 - Qiita