タグ

ブックマーク / satoshi.blogs.com (5)

  • Python入門:デコレータとは

    前から常々思っていることだが、何かについて勉強する一番効率的な方法はそれを誰かに教えること。人に教えようとすると、それなりに準備をしなければならないし、自分の頭の中を整理しなければならない。また教える過程でするどい質問をされたり間違いを指摘されて、さらに勉強を強いられることもある。 私がこの手の「入門編エントリー」を書くのは、ほとんどの場合「自分自身の理解をより深めたい」ことが一番の目的であるが、ブログの場合、教室などと違って「その道の達人」みたいな人たちがツッコミを入れてくれるケースもしばしばあるので、そのメリットは何倍にもなる。 先日のクロージャに関するエントリーなどは良い例で、「そんな用途にはmemoizeというデコレータが便利」などの指摘がいただけだけであれを書いた価値があるというもの。 そこで、今日はPythonのデコレータに関して。デコレータがPythonという言語に導入された

  • 東電、黒塗り資料を提出しておきながら「事実の解明を待たずに批判するな」

    TBSが「震災報道スペシャル 原発攻防180日間の真実」という番組を放映したが、それに対して東電が反論をホームページに掲載した(参照)。特に興味深いのはIC(緊急冷却装置)の操作に関する部分。 「ICの操作も含め、停電しても適切に対応すればメルトダウンも水素爆発も防げた」と断じていますが、これらの原因やメカニズム、ICの操作等の詳細などについては、現在、国の事故調査・検証委員会などで調査が進められております。そうした中で、事実の解明を待たずに、推定や憶測などによって、「人災」と結論づけた報道がこのたびなされたことは甚だ遺憾であり、誤解につながる可能性が大きいと言わざるをえません。 確かに、事故当時のICの操作については、それが手順書どおりに行われたのか、そしてそもそもその手順書が適切なものだったのかが事故調査・検証委員会によって進められている。しかし、東電が国に提出した手順書は、知的財産と

    東電、黒塗り資料を提出しておきながら「事実の解明を待たずに批判するな」
    oinume
    oinume 2011/09/24
    まったくありえないわ。
  • 「RESTful MVC」なアーキテクチャの話

    最近、増井君と私でアーキテクチャの話をすることが多いのだが、そんなディスカッションの中で気に入っているのは左の図のようなアーキテクチャ。 もちろん、核となるのはビジネスロジックを含んだModelの部分。そこをしっかりと実装し、内部構造を隠す粒度の荒いインターフェイスを定義し、外から何をされてもデータの整合性が壊れない様にすることは何よりも大切。 そして、そのModel層へのインターフェイスを特定の言語に依存したクラスやAPIではなく、HTTP上でJSON(XMLでもかまわない)をやりとりするだけの RESTfulなWeb Serviceにすることがミソ。こうすることによりにより、どんなに締め切りに負われようが、誰がControllerを実装しようが「ずるができない」ように作っておく(ずる=来使うべき外部インターフェイスだけでなく、Model内部に直接アクセスして依存関係を作ってしまう事)

    「RESTful MVC」なアーキテクチャの話
  • JavaFX Script 入門、とりあえず言語仕様に目を通してみた

    CNetでも報道された通り、Sunが独自のスクリプト言語JavaFX Scriptを発表した。テクノロジーの優劣だけで決まるものではないので、この試みがうまく行くかどうかは何とも予測しがたいが、とりあえず言語仕様が公開されたので目を通してみた。 私なりに興味深いと思った点は以下の5つ(ただし、私なりの拡大解釈が多少入っている可能性もあるので要注意)。 1.宣言型のUIをサポートしていること 宣言型大好き人間の私としては、この方向性は大賛成(ちなみに、UJMLも宣言型のUI言語^^)。"押してね!"というラベルがついたボタンを表示するには、こう書けば良い。 Frame { content: Button { text: "押してね!" action: operation() { System.out.println("押してくれて、ありがとう"); } } visible: true } 2

  • マルチ・スレッド(multi-thread)プログラミングの落とし穴、その1(かもしれない)

    ここのところ技術系ブロガーの間で話題になっている、「C10K問題(参照1、参照2)」は、ひとことで言えば、多くのウェブ・サーバーで採用されているmulti-threadやmulti-processに頼った(もしくは頼りすぎた)多重処理というアーキテクチャーのスケーラビリティに対する極めてまっとうな警告である。 この話は、決して最近になって始まった話ではなく、パソコン業界ではパソコンのOSにpreemptiveなマルチタスクが導入されはじめた90年代の前半から、さらに遡ると、DECを中心にテクノロジーが進化したミニコンの時代から、ソフトウェア・エンジニアたちの間で盛んに討論されてきたテーマである(さすがに、メインフレーム時代の話は私は知らない)。 十数年を経た今でも、いまだに決着が付いていないこの問題は、私の大好きなテーマの一つでもあるし、もし私が博士号をこれから取得しようとするのであれば、

  • 1