タグ

フレームワークに関するnagolingのブックマーク (7)

  • イントロダクション | BEAR.Sunday

    BEAR.Sundayとは BEAR.Sundayは、クリーンなオブジェクト指向設計と、Webの基原則に沿ったリソース指向アーキテクチャを組み合わせたPHPのアプリケーションフレームワークです。 このフレームワークは標準への準拠、長期的な視点、高効率、柔軟性、自己記述性に加え、シンプルさを重視します。 フレームワーク BEAR.Sundayは3つのフレームワークで構成されています。 Ray.Diは依存性逆転の原則に基づいてオブジェクトの依存をインターフェイスで結びます。 Ray.Aopはアスペクト指向プログラミングで質的関心と横断的関心を結びます。 BEAR.Resourceはアプリケーションのデータや機能をリソースにしてREST制約で結びます。 フレームワークは、アプリケーション全体に適用される制約と設計原則です。一貫性のある設計と実装を促進し、高品質でクリーンなアプリケーションの構

  • Webアプリケーションの構成に関する予備知識 - Qiita

    自分の担当したWebアプリケーションを引き継ぐ際に、予備知識として説明したことのまとめ 注意事項 もともと明確に定義されていない概念や、簡単に説明するため正確さを犠牲にした部分が多い 間違っていることを前提に、疑いながら読むのがベター アプリケーションの層構造 アプリケーションを構成するオブジェクトには非常の多くの種類がある アプリケーションの(より良い)構成をオブジェクト単位で考えるのは難しいので、もっと粒度の大きい単位で考えたい アプリケーションをいくつかの層(オブジェクトの所属するグループ)に分割し、層単位でアプリケーションの構成を考える View層(ビュー層) レスポンスをクライアントにとって都合のいい形(i.e. 画面)に変換する層 View層のオブジェクトは Controller層のオブジェクトから利用される DomainModel層のオブジェクトを利用して、ユーザーに表示した

    Webアプリケーションの構成に関する予備知識 - Qiita
  • レガシーな独自フレームワークから脱却してRailsへ徐々に移行している話 - メドピア開発者ブログ

    みなさんこんにちわ。 メドピアでエンジニアをやっている内田と申します。 現在メドピアではPHPで作られたレガシーな独自フレームワーク (以下FW) からRailsへと移行するプロジェクトが進んでいます。 今回は移行に向けて行ったことについて共有したいと思います。 移行の計画 メドピア株式会社では、医師限定のコミュニティサイト「MedPeer 」を運営しています。 「MedPeer 」サービス内では、薬剤評価掲示版、症例相談、Forum、ニュースなど、医師同士が情報交換をするための、機能の異なる複数のサービスを提供しています。 それらサービスの内部では7年前に作られたPHPの独自FWが採用されており、コードが肥大化したことで機能の変更や追加がとても困難になっていたことが課題でした。 そうした課題を解決するために、アーキテクチャの見直しを含めたリプレースがエンジニアの主導で計画されました。 様

    レガシーな独自フレームワークから脱却してRailsへ徐々に移行している話 - メドピア開発者ブログ
  • Slimフレームワークの利用(フック処理、Cookieの利用、Sessionの利用など) - 俺 Pedia

    この記事は「低予算でも闘う企画担当者の為の鎮魂歌 Advent Calendar 2015」の8日目の記事です。 今回も引き続きマイクロフレームワークであるSlimの説明を行います。 前回は最も基的なルーティング、パラメータ、ビュー(レンダリング)について簡単に説明しました。 今回はフック処理、Cookieの利用、Sessionの利用について紹介します。 ① フック処理 例えば認証が必要なアプリケーションを作成する場合、そのコンテンツの表示を行う前にあらかじめ認証状態を確認する必要があります。 そういった場合に利用するのがフック機能です。 フック機能ではあらかじめ設定されたフックポイントを利用する事で簡単に処理をフックする事が可能です。 例えば具体的なフック処理は次のようなものです。 このコードでは「/」「/mypage」「/login」の3つのパスに応じたルーティングが定義されています

    Slimフレームワークの利用(フック処理、Cookieの利用、Sessionの利用など) - 俺 Pedia
  • superagentとaxiosの使い分け - Qiita

    モバイルファクトリー Advent Calendar一日目担当の@nekobatoです。 フロントエンドなので、ナウなフロントエンドっぽいライブラリ紹介でもします。 はじめに 周りに「フロントエンドでXHRライブラリ何使ってる?」と聞くと フレームワークに生えてるのを使ってるよ(Angularなど) ←一番多い superagentだよ ←二番目に多い require('http')だよ ←!? JQueryだよ ←最近少ない 素のXHRだよ ←マジかよ 程度に大別される印象です。 私が普段使っているVue.jsだと、request周りは標準で生えていないのでsuperagentを使うことが多いのですが、最近場面によってはaxiosを使うこともあったりします。 axiosとは、Angularの$http serviceに影響を受けたXHRライブラリで、書き方が似たようなものになっています。

    superagentとaxiosの使い分け - Qiita
  • JSライブラリ/フレームワークの良い、悪いメモ - 素人がプログラミングを勉強していたブログ

    ※ただのメモで、未来志向なのであまり真に受けてはいけない。 良いっぽい React.js 早速い/コンポネント志向/APIの設計がいい。JSXと他のトランスパイラの組み合わせという問題はある Promise ネイティブに入った、誰もが使ってる TypeScript ES6時代でも存在意義のある言語。TypeScript互換のFacebook Flowの動向に注目 Backbone.js ModelとEventを使う/Viewは使わなくていい Lodash Underscore.jsをよくしたやつ Gulp Gruntより良いという意味で。browserifyまわりがうまく動かない問題があってnpm runのほうがいいという噂もあるがまあ良いに分類してもいい EventEmitter Custom EventはDOMにくっ付いてる感があるのでロジック志向の物にはEventEmitter使った

    JSライブラリ/フレームワークの良い、悪いメモ - 素人がプログラミングを勉強していたブログ
  • I am mitsuruog | 進化の早いフロントエンドの世界についていくために、スタイルガイドを有効活用しているという話

    フロントエンドの世界では、日々新しいフレームワークやライブラリが生まれています。 初めてそういった新しいものを習得する場合に、なるべくなら近道したいと思うのが人の気持ちだと思います。 まず大変なのが、Hello World から実際のプロダクトやプロトタイプで利用する場合で、これは初めてで何もわからない土地を一人で散策するような感覚にも似ています。 今日、紹介するのは私が進化の早いフロントエンドの世界で、より早く未開の土地に慣れるためにスタイルガイドを有効活用しているという話です。 ちなみにこの記事はFrontrend Advent Calendar 2014 - Qiitaの 6 日目の記事です。 5 日目はじめての CSS 設計 - Qiita(@moschann) 7 日目CSS のプリプロセスとポストプロセス、そして Rework と PostCSS(@morishitter) 良

    I am mitsuruog | 進化の早いフロントエンドの世界についていくために、スタイルガイドを有効活用しているという話
  • 1