System.Exit - プログラミング

Wiki とか Google ノートブックみたいなのって、まあそれなりに使いやすくはあるんだけど、検索する際に画面遷移するのがちょっとウザイなと思ったので、画面遷移しなくてすむようなものを作りたかったという、ただそれだけ。
というか、編集と検索の機能を同一画面に置きつつ、操作的には完全に分離したようなものを作りたかった。
一つの画面でいろんなことができたらいいじゃん、みたいな発想。
いろいろできすぎるのも良くないと思うけど。

画面遷移によるストレスって以外と無視できない。
0.1 秒くらいで次の画面が表示されるんだったあまり気にならないかも知れないけど。

とか。

スクリーンショット

見た目こんな。

編集時。

検索時。

Rails で作った。
Haml も活用。

あとでソースとか公開する予定。
大したアレじゃないけど。

まだいろいろ足したい機能とか修正したいところとかがある。

追記:

ソース

my_memo.zip

…

ていうか、Haml 便利っすね Haml。

例えばこんな感じで View が書ける。

!!! XML
!!!
%html
  %head
    %title My_Memo
    = stylesheet_link_tag 'common'
    = javascript_include_tag :defaults
  %body
    #wrap
      #header
      #main
        #add_area
          - remote_form_for :new_memo, :url => {:action => :add}, :loading => "$('new_memo_text').value = ''" do |memo|
            = memo.text_area :text, :rows => 6
            = memo.submit 'Add'
        #memos_header
          = link_to_remote 'Reload', :url => {:action => :reload}, :loading => 'Element.update("memos", "")'
        #memos
          = render :partial => 'memos'
        #memos_footer
      #side
        #search_area
          Search
          = text_field_tag :search_text
          = observe_field(:search_text, :frequency => 1, :url => {:action => :search}, :with => "'search_text=' + value", :success => 'Element.update("search_results", "")')
        #search_results
        #search_area_footer
      #footer

ネストで HTML の階層構造を表現できる。
閉じタグとか意識する必要ない。
HTML の構造を作り替えたりする際に非常に楽。
上記のソースを普通に HTML (erb) で書くとするとソースコードの分量が 1.5 〜 2 倍近くになると思う。

Comments (0)

March 16, 2008

モナドもカリー化も忘れた

March 16, 2008 at 21:48 , Tags: プログラミング

プログラマの壁 - あどけない話

まず、プログラマになれるかなれないかの壁があるのでしょう。なれたとしても、ある機能を理解できるかどうかの壁があります。その機能が理解できたとしても、次の機能が分るとは限りません。

ここでは、壁になりそうな機能を思いつくままに挙げてみることにします。

プログラマの壁か。
正規表現はまだまだ全然使いこなせてない。
モナド。。。前に読んだ Haskell の本に出てきてたけど、忘れた。
カリー化も忘れた。

ふつうのHaskellプログラミングふつうのプログラマのための関数型言語入門
青木峰郎山下伸夫

ソフトバンククリエイティブ 2006-06-01
売り上げランキング : 12312

Amazonで詳しく見る by G-Tools

この本はわかりやすくておもしろくて良かったなぁ。内容ほとんど忘れたけど。
気が向いたらまた読もう。

Comments (0)

March 5, 2008

読書: アジャイルプラクティス

March 6, 2008 at 10:17 , Tags: プログラミング, 開発, 読書, 人間

↓読みました。

アジャイルプラクティス達人プログラマに学ぶ現場開発者の習慣
Venkat Subramaniam Andy Hunt 木下史彦

オーム社 2007-12-22
売り上げランキング : 453

Amazonで詳しく見る by G-Tools

非常に良い内容。
翻訳も読みやすくでいいですね。
この本は、ソフトウェア開発に携わる全ての人が読むべきなんじゃないでしょうか。
当然、読むだけじゃなく実践もしていかないとだめですけどね。

こういう本を読むとつくずくソフトウェア開発っておもしろいなぁって思う。
いや、でもソフトウェア開発に限らずだよな。

例えば、本書には天使と悪魔が出てくるんだけど、天使がこんなこと言ってる。

誰かの後ろ指をさすのではなく、自分のできる解決策に注力しなさい。大事なことは、意味のある成果をあげることです。

そうなんですよねー。
でも人って、せっぱ詰まってたり焦ってたり疲れてたりすると、すぐに人のせいにしたりしてしまうんですよねー。
まあ、難しい。
人間が社会的な生き物であるからこその難しさというか。
機械だとこういうこと起こらないからね。

機械ではない人間がいかにうまく協調作業できるか、ということをよくよく考えていかないといけないんですね。
そこで重要になってくるのってやっぱり人間の心理的な部分だったりするんですよ。
そういう意味で、本書に天使と悪魔が出てくるのは非常にわかすくて、的を得てると思う。
仕事中は常に、楽をしたい気持ちと、きちんと仕事を成し遂げたいという気持ちのあいだで心が揺れ動いてるんですよね。
本書は、そういった際に正しい行動をとるための指針になると思います。

というかまあ、実践あるのみですね。
本読むだけじゃ何の意味もないし。

いくつか引用。

伝説のジャズギタリスト、パット・メセニー曰く、「どんなバンドで演るときも、一番下手なプレイヤーでいろ。もし自分が一番上手いんだとしたら、それは別のバンドに移る時期だ。同じことは世の中のほとんどのことに当てはまると思う」

うん。
パット・メセニーが言ってるんだから間違いない。

「自分でもよくわかっていないことを、厳密にしても意味がない」
―― ジョン・フォン・ノイマン

ノイマンが言ってるんだから間違いない。

まず何よりも、巧妙であるよりも明瞭であれ。「意図を明確に表現するコードを書く」こと。

これはホントそう思う。

よく考えて選んだ意味のある名前を使って、コードを読みやすくしましょう。コメントはコードの意図や制約を示すのに使います。ひどいコードを取り繕うために使ってはいけません。

はい。

シンプルであることは、安直だとか未熟だとか、不足しているといったことを意味しない。むしろ全く反対だ。シンプルさは、やたらと複雑で後先を考えない解放よりも、はるかに実現が難しい。

いいこと書いてありますね。
そうなんです。
シンプルっていうのは無駄がないということで、無駄を極限までなくすっていうのは結構難しいことだったりするんですよね。

本物の洞察は、実際にコードを書くことからもたらされます。コーディングしないアーキテクトと一緒に仕事をしないように。システムの実態を知らずにまともに設計なんてできません。

だそうです。

Comments (2)

March 3, 2008

REST について

March 4, 2008 at 8:13 , Tags: プログラミング, REST, Web

とある REST 勉強会に参加してきた。

REST ってそもそもなんなのか。
「HTTP プロトコルにもともと備わっている機能を使って、もっとシンプルに Web サービスを作ろうとするもの」
という認識であってるかな。
ちゃんと本読もう。

普通、HTTP プロトコルで使われるのは GET と POST の二つのリクエスト方式。

でも実は、 HTTP プロトコルの仕様としては PUT と DELETE なんてのもあるらしい。
それら四つ（GET, PUT, DELETE, POST）を使ってもっとシンプルに WEB サービスを作れるんじゃないか、というのが事の発端。

えーと、四つのメソッドが使えるということは、一つの URL に対して四種類の操作が行えるということになり、URL が何らかのリソースを表すものであるととらえるなら、それに対してデータベースでいうところの CRUD が実現できる。
基本これだけで Web サービス作れるんじゃね？、みたいな発想。

あってる？

勉強会で話題になっていたのが「確認画面」にまつわる話。
「確認画面」ってあの、 mixi で日記を投稿する際に出てくるこういう画面とかのこと（ていうか、そもそもこの画面って必要なの？）。

REST の考えで行こうとすると、この「確認画面」の扱いが厄介。
「確認画面」を表示するためのリクエストそれ自体はリソースを作成したりも更新したりもしない。
つまり REST 的な操作の範疇に収まらない。
そもそも Web アプリケーションにおけるリクエストって、いろんな意味を持ちうるから、「リクエスト」イコール「データ操作」とはならないケースがそもそもそ存在する。
なので REST では全てを扱いきれないんじゃないかなぁ、と思うわけです。

あと、すごく個人的な意見。
アーキテクチャやその考え方がシンプルであることは良いことだと思う。
でも、マーチン・ファウラー曰く、ものごとには「本質的複雑性」と「偶発的複雑性」ってのがあってですねぇ、「本質的複雑性」の方はどうやったってそれ以上はシンプルにはできないんです。
REST の「確認画面」にまつわる話もそれと似たような問題であるような気がしたんですね。
下手するとシンプルにするつもりが余計に複雑になってしまいかねない。

というか、そもそも REST って Web API とかに限定される話だと思ってたんですけど、違うの？
ちゃんと本読もう。