最終更新日: リフレクション 「自分自身を自分で変えちゃうのかょッ(仮)」 ■はじめに 何かが変化するとき、直接の原因となるものに外的要因と内的要因がある、ように思う。 たとえば、 輪ゴムが伸びる。 水が氷に変わる。 草や木が成長する。 細胞分裂。 [�T] 無機的なモノがその形を変える場合、えてして、外力が働く必要があるように思える。 [�U] 生命的なモノが変化する場合、そのモノを構成する分子間での協調的な動作の結果、自発的に全体の形が変る、気がする。 (何をもって「生命的」かというのは難しい問題ですが) さて、 [�T]はトップダウン的。中央集権的。[�U]はボトムアップ的。分散強調的。ともいえるだろうか? 我々が普段何か「モノづくり」というときには、[�T]トップダウン的につくる。それを構成している部品(モジュール)が何かを考えて、部品を作り、それら組み立てる。アイボ
RESTの基本的な発想は、HTTPメソッドでリソースをCRUDできるはずだ、というアイデア。 では、HTTPメソッドは、そもそもどんなものなのか? 「安全なメソッドと冪等{idempotent} なメソッド」でいくつか語られている。 「RESTful Webサービス」で「べき等」という概念が出てくる。 「べき等」とは、同じ操作を何度行っても同じ結果であること。つまり副作用がなく安全であることを意味する。 少なくとも、GETはべき等に使うならば、安全であると言える。 しかし、GETで、リソースの削除や更新を行う時も、実はよくある。 REST思想に従うならば、GETは副作用を起こしてはいけない。 POST、PUT、DELETEがリソースの更新で副作用を起こすように使うべき。 RailsはREST思想を忠実に反映している。 また、Strutsも「http://~/***.do」というURLを見る
第24回Ruby/Rails勉強会@関西へ行ってきた感想を書く。 【1】REST思想が解決しようとするもの moriqさんの講演。 REST思想をアーキテクチャの観点から非常に丁寧に深く解説してくれて、かなり概念が整理された。 Webシステムの特徴のひとつは、デプロイが独立していること。 つまり、クライアントのVerUpは、サーバーは無関係であること。 Railsの弱点は、デプロイにあると思う。 おそらく、JRubyがそれを解決してくれるはず。 REST思想のモチベーションは、セッションを汚さないこと。 できるだけ、画面の状態は、URLが指し示すリソースで持つ。 GET、POSTだけでなく、HTTPメソッドにあるPUT、DELETEを使って、セッションで保持しなくてもいいようにする。 少なくとも、注文ボタンの2度押し問題は、POSTメソッドでなく、PUTメソッドを使えば解決できる。 PUT
卒論もおわり時間に余裕もできたので,Ruby/Rails勉強会@関西 #24にいってまいりました.スタッフおよび参加者のみなさん,おつかれさまでした!今回は,いつもと少し毛色の違った内容(開発環境, 開発現場,Flexのはなし)でなかなか興味深かったですね. さて,今回は某氏に,最後のセッションのRuby初心者レッスンで書いたコードを,そのまま晒すべしとの指令うけているので,そのまま晒したいと思います.変数名などがいい加減ですが,1bitも変更してはいけないらしいので,気にしないでください. 第一問 テキスト解析 テキストを読み込み,以下の数を調べる. 文字数 単語数 行数 文字列の出現頻度 単語別出現頻度 ただし,対象のテキストはtext.txtというファイルに保存されています. 準備 ひとつひとつの問題ごとにスクリプトを書くのは面倒なので,irbで実行します.ただし,irbをまちがえて
2008年2月25日,アドビシステムズのRIA(リッチ・インターネット・アプリケーション)構築ツールFlexの最新バージョンである「Flex 3」製品群がリリースされました。従来のバージョンに比べて安定性や機能が向上した Flex 3 について,特徴となる新機能と強化点について簡単に紹介します。 Flex 3 SDK はあるルールの下で,Flex 2.0.1 SDKからバージョンアップされたようです。プロパティや関数名が変わるということはありませんが,機能の中身が変わっていたり,Flex 3 SDK では非推奨になっていたり,新しいプロパティや関数が追加されていたりします。大半は機能アップされ,バグもフィックスされていますが,中には Flex 2.0.1 の構造を維持したまま機能強化させるために,いびつな構造になってしまっているところもあります。 従来からの Flex ユーザーの中には「今
本連載では,DOM(Document Object Model)を使ったJavaScriptの新しいコーディング手法について紹介していきます。 近年,AJAXの台頭をきっかけに,JavaScriptを使ったブラウザのリッチ・クライアント化が進んできました。これまでは,サーバー側のプログラムでページを書き換えることで,ブラウザの表示に変化を与えてきました。しかし,現在では,ページの表示を変化させるだけであれば,ほとんどのことはJavaScriptのみで対処することが可能です。それを実現するのがDOMなのです。 ブラウザのリッチ・クライアント化により,JavaScriptに求められる要求は,複雑さを増すばかりです。本連載では,DOMの基礎を学び,DOMならではのコーディング手法について紹介していきます。 まず,第1回ではDOMとは何なのか,そしてDOMで何ができるのかを解説していきます。 DO
アドビシステムズは2008年2月25日に,RIA(リッチ・インターネット・アプリケーション)構築ツール「Flex 3」とともに,アプリケーション実行環境「AIR」の正式版(AIR 1.0)をリリースしました。AIRについてはベータ版のときから話題になっていることもあり,名前は聞いたことがある,という人は多いと思います。ただ,その“正体”を理解している人はさほど多くないのではないでしょうか。この記事では「Adobe AIR って何?」という人に向けて,AIRの基本的な仕組みや使い方について解説します。 デスクトップでFlashやHTML/Ajaxアプリを実行できる AIR は Adobe Integrated Runtime の略とされています。これを日本語に訳すと「アドビ統合実行環境」となります。ここで注意していただきたいのは,AIR 自体はアプリケーションではないということです。文字通り
原付を購入したら考えるのが任意保険です。 自賠責保険は強制保険なので原付をバイクショップで買えば、入ることが義務付けられているため絶対に入りますが任意保険は名前のとおりで加入はどちらでもOKとなっており、任意で加入する保険です。 任意保険は補償範囲が広い 自賠責保険というのは補償される範囲が「対人のみ」に限定されます。 事故によって相手にケガを負わせた場合に補償されるのが自賠責保険です。対人のみの補償のため、相手の車(物)への補償はありません。 当然ながら自分に過失があれば相手の車を直さなくてはなりませんが、そのときの損害賠償代は自賠責保険では一切補償されません。全額自己負担でカバーしなくてはなりません。 任意保険なら対物賠償があるため、加入していれば補償範囲内でカバーされます。 一般に任意保険へ入るときは、「対人・対物」は無制限ではいるため、相手と相手のモノの補償はカバーされるのが任意保
3月27日(木)午後7時にアドビさんからいつもの場所を借りて BlazeDSソースコード読み会を開きます。 プレゼンターはひがさんです〜♪ S2BlazeDS開発状況なども伺いたいですね。 内容は、Flex使い向けというよりかは、Java使い向けだと思っています。 BlazeDSのサンプルコード解説ではなく、BlazeDSそのもののソースを読みます。 いつもFlex3勉強会には多くのビジターがいらっしゃいますが、 今回も多くの方のご参加もお待ちしております〜。 BlazeDS Code Reading http://www.fxug.net/modules/bwiki/index.php?BlazeDS%20Code%20Reading%A1%F7%C5%EC%B5%FE%B3%AB%BA%C5
今日はRails勉強会で「ApolloでRailsを打ち上げよう!」という発表をした。 結果はRailsを打ち上げるまでは行かず、結局Flex+RubyAMFしかできなかった。 最後にslingshotの紹介をして、一応形は成したつもりだが、目標は選ぶべきだったかも。 でも、自分にとってかなり高めのハードルを課したことは、今思えば良かったなぁと思う。 さて、勉強会後の懇親会はいつものメタボライズ天国「くねんぼ」。 途中から賢人たちの助言を受けながらLiveCodingしたにもかかわらず、無理。 どうもRemoteObjectがうまくいかない。 <mx:RemoteObject>というタグを使って外部にあるサービスに アクセスするための機能を利用するのだが、FlexではうまくいくものがApolloではだめ。 ApolloではRemoteObjectが使えないのかとも考えるが、
At the end of my last post about RubyAMF I mentioned that I was particularly interested in how it could be used to extend Apollo applications using Ruby in the same way that Artemis makes it possible to extend Apollo with Java. Here’s why: It enables AMF3 communication between Flex and Ruby. It comes with its own webrick servlet, so deploying RubyAMF is dead simple (if you have Ruby installed). It
デザイナーとプログラマが、互いに意識しない。 yui-frameworksは、Flexアプリケーションを開発する上でのプレゼンテーションレイヤーのフレームワークです。 概要 yui-frameworksは、FlexにおけるView(mxml)とLogic(ActionScript)を完全分離することを主な目的としたFrameworkであり、以下のような特徴を持っています。 ViewとLogicの分離 デザイナとの分業を目的に、画面の定義を行うView(mxml)ファイルにはロジックを記述しなくてもよいように設計されています。 例えば、今まではButtonタグ内に「click="function名"」など、多少なりともmxmlにスクリプトを記述する必要がありましたが、 yui-frameworksでは、それさえも不要になっており、 mxmlで必要なのは、画面を構成するコンポーネントの配置と、
大森のニフティでRails勉強会があり行ってきました。 http://wiki.fdiary.net/rails/?RailsMeetingTokyo-0028 前半セッション Seaside Webアプリケーションを作るためのSmalltalkで実装されたフレームワーク。 開発環境は整っているが、サーバーを起動しなければならないので、レンタルサーバーとかには向かない。 面白いと思ったネタは、コンティニュエーション(継続)の永続化 アンケートの継続が出来ると、アンケートの回収率を上げることができるのではないか? 同様に、入会処理も継続できると入会率を上げることができるかもしれない。 Smalltalk(Squeak)は見た感じ、RubyとObjective-Cにちょっと似ている。 似ている理由は、どちらもSmalltalkの影響を受けている言語だから ライトニングトーク(LT) 告知は1週
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く