Python Web フレームワークを作った話 - glasses factory
久々に記事を書くわけですが日本語を忘れています。 前置きはさておき、タイトルの通り Python 用 Web フレームワークを作ったわけです。 Shimehari : moderate framework for Python. http://shimehari.hageee.net 具体的にどういう使い方ができるのか、どういうコードを書けばいいのかといったことはドキュメントや公式サイトで解説しているので、 この記事ではなぜ作ったかだとか、今後どうして行きたいだとかそういった内部事情?的なことを書いていこうと思います。 欲しかったから作った 作った理由としてはそれに尽きます。 他の誰でもなく自分が欲しかったから自分の欲しい物を作っただけです。 Python で何か作るとき ちょっとした規模の物なら flask、 しっかり作るなら django という選択肢が割とメジャーなのでは
Python製テンプレートエンジンあれこれとJinja2 - YAMAGUCHI::weblog
はじめに こんにちは、Python界のタオパイパイです。いろいろなコミュニティで行われているアドベントカレンダーですが、今年初めて参加してみました。 Python Web フレームワーク アドベントカレンダー2010 : ATND 今年はPython系では「Python Web フレームワーク アドベントカレンダー2010」と銘打ってWebフレームワーク系の話をするようなのですが、自分はそもそもWebフレームワークをそんなに知らない。困った！というわけでWebアプリケーションフレームワークには必ずあるテンプレートエンジンについて調べました。 どんなテンプレートエンジンがあるのか そういえば俺もよく知らんなと思ってとりあえずいろんなエントリから調べてみましたよ。全部挙げたらきりがないので、とりあえずGoogleのヒットが多いものを挙げてみました。普通にフレームワーク名になってしまっているもの
Twitterが分散フレームワーク「Gizzard」公開！ Scalaで書かれたShardingを実現するミドルウェア
Twitterが分散フレームワーク「Gizzard」公開！ Scalaで書かれたShardingを実現するミドルウェア Twitterは独自に開発した分散フレームワークの「Gizzard」をオープンソースとして公開しました。GizzardはScalaで書かれたJavaVM上で動作するミドルウェアで、PHPやRubyといったWebアプリケーションからの要求を自動的にデータベースに分散することで、大規模で可用性の高い分散データベースを容易に実現するためのものです。 Gizzard：フォルトトレラントな分散データベースを実現 The Twitter Engineering Blog: Introducing Gizzard, a framework for creating distributed datastores Twitterのブログにポストされた「Introducing Gizzard
Part2 Webアプリケーション・フレームワーク入門
Rubyで書かれたWebアプリケーション・フレームワーク，Ruby on Railsが話題になってからすでに1～2年がたちますが，今でもフレームワークは高い注目を集めています。でも，ちょっとしたWebサイトなら，フレームワークなんて使わなくても自分で書いたほうが速いよ！と思っている人もいるかもしれません。Webアプリケーション・フレームワークを使うことで，いったいどのようなメリットがあるのでしょうか？ 一言でいうなら「手抜きができる」ということです。最近のフレームワークは，Webアプリケーションを構成するのに不可欠なコードを自動生成する機能を備えています。データの「読み，書き，変更，削除」を行う簡単なデータベース・アプリケーションなら，コードを1行も書かずに作ることも可能です。こうしたWebアプリケーションを一から書いたことがある方なら，「読み，書き，変更，削除」の機能を実装するだけでも結
tokuhirom blog
Blog Search when-present<#else>when-missing. (These only cover the last step of the expression; to cover the whole expression, use parenthesis: (myOptionalVar.foo)!myDefault, (myOptionalVar.foo)?? ---- ---- FTL stack trace ("~" means nesting-related): - Failed at: ${entry.path} [in template "__entry.ftlh" at line 3, column 25] - Reached through: #include "__entry.ftlh" [in template "entry.ftlh" at
「RESTful MVC」なアーキテクチャの話
最近、増井君と私でアーキテクチャの話をすることが多いのだが、そんなディスカッションの中で気に入っているのは左の図のようなアーキテクチャ。 もちろん、核となるのはビジネスロジックを含んだModelの部分。そこをしっかりと実装し、内部構造を隠す粒度の荒いインターフェイスを定義し、外から何をされてもデータの整合性が壊れない様にすることは何よりも大切。 そして、そのModel層へのインターフェイスを特定の言語に依存したクラスやAPIではなく、HTTP上でJSON（XMLでもかまわない）をやりとりするだけの RESTfulなWeb Serviceにすることがミソ。こうすることによりにより、どんなに締め切りに負われようが、誰がControllerを実装しようが「ずるができない」ように作っておく（ずる＝本来使うべき外部インターフェイスだけでなく、Model内部に直接アクセスして依存関係を作ってしまう事）
Web アプリの MVC 設計まとめ - もやし日記
MVC 設計について考えていたときに、ちょうどその辺りの話をされている方々が居たので、今の考えをまとめてみました。 目次 前提 肥大化するコントローラを避ける ビジネスロジックをどこに書けば良いのか コントローラとモデルの間にもう一つの層があるとうまくいく？ まとめ 前提対象は Web アプリケーションで、画面数（ビューの数）は数個〜100個程度の規模です。WordPress、Twitter、37signals のサービスのようなものを作ろうとするとき、どういう MVC 設計をしていくかについて考えます。巨大なシステム、金融系システム、基幹系システムなどを作る場合とは異なる考え方もあると思います（そもそも MVC を使わない、など）。 肥大化するコントローラを避ける例えば、八百屋さんで「６０円で仕入れたリンゴ１つを１００円で売った」こと（Sales Transaction）を記録する場合を
O/Rマッピング技術の進化が皮肉にも助長している「えせMVC症候群」
昨日の「Ruby on Railsの『えせMVC』の弊害」というエントリー。若干「釣り」の要素が含まれたタイトルが功を奏したのか、たくさんのフィードバックがいただけた。そんな中で見えて来たのは、この問題はRailsに限った話ではなく、業務用アプリケーションで使われているJavaや.Netの世界でもよく見られる問題だということ。 その「問題」とは、ActiveRecordに代表されるO/Rマッピングの技術の進化が、本来のMVC（そしてオブジェクト指向そのもの）のメリットを無視した「えせMVC」な設計を助長している、という問題である。 ・MVCやオブジェクト指向を表面的にしか理解していないエンジニアが増えている（ここが根本的な問題） ↓ ・SQLを自分で記述しなくて良いO/Rマッピングはとても魅力的（これはこれで別の問題を含んでいるが、このエントリーではあえて突っ込まない） ↓ ・O/Rマッピ
Ruby on Railsの「えせMVC」の弊害
先日のエントリーでも少し触れたが、Ruby on Railsの最大の問題点は、それが持つ「一見そのフレームワークがMVCの形をとりながら、MVCの最も大切なところを外している『えせMVC』である」点にある。MVC（Model View Controller）がなぜ必要かを根底の部分でちゃんとと意識せずにRailsアプリケーションを作ると、後々ひどい目に会うので注意が必要である。 その意味では「RailsでMVCを学ぶ」などもっての他だし、「JavaにもRailsと同じようなフレームワークを作って業務用アプリの開発を効率化しよう」などという発想もとても危険である。 ということで、今日はまずはMVCの解説から。 MVCの発想の根底には、「モジュール化と情報の隠蔽により、プログラムがスパゲッティ化するの（コード間の相互依存関係が複雑に入り込んでしまってにっちもさっちも行かない状態になること）を避
HTML5時代の「運営しやすいアーキテクチャ」の話
増井君と二人でPhotoShareというサービスを立ち上げてもう１５ヶ月になるが、いろいろと学んだことがある。その中でもつくづく思うのは、サービスを作り上げる段階よりも、運営のことを考えた設計が大切なこと。つまり、メンテナンスしやすい、テストしやすい、多少のミスをしても大丈夫、こまめなアップデートがしやすい、作業分担がしやすい、などなどである。 そんななかで強く感じるのは、「AJAXを見た目や使いやすさの面だけに利用するだけでなく、『運営しやすいサービス』を作るのに利用できないか」ということである。 私のイメージするアーキテクチャを図にするとこんな感じになる。 まず一番の特徴は、テンプレート等を利用したHTMLのダイナミックな生成をすべてやめて、データ（JSONもしくはXML)だけをダイナミックに生成するようにし、HTMLはスタティック・ファイルをサーバー側に置いておく（上の図で、CSS,
ついに出た！最新Perlフレームワーク「Ark」徹底解剖 記事一覧 | gihyo.jp
運営元のロゴ Copyright © 2007-2024 All Rights Reserved by Gijutsu-Hyoron Co., Ltd. ページ内容の全部あるいは一部を無断で利用することを禁止します。個別にライセンスが設定されている記事等はそのライセンスに従います。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
初めてのCatalyst入門（1） PerlによるWebフレームワークCatalystとは？