少なくとも東京よりは行きやすい。日帰りも十分可能だし。
あまり釣り度は高くなさげ。ただ、
・プログラミング言語としての“スジ”がよい
構造化プログラミングやオブジェクト指向プログラミングといった手法を習得しようとする場合,初心者のころからこうした機能をサポートする言語を使って概念を身に付けていれば,学習コストが少なくて済むことが期待できる。逆に,スジが悪い言語を初心者のころに使うことで,行儀の悪いプログラムを書く悪癖がついてしまうことを危惧する人もいるかもしれない。だが,最初はこうした機能を使わずにプログラミングをすることで,後でその機能を使ったときに,その効能やありがたみを実感できる可能性もある。
この項目丸ごと不適切な気が。
スジの悪い言語から入っても「あとでありがたみが分かる」効果があるんじゃね?てことを書いているのにその項目タイトルが「スジがよい」ってどないやねん。
ちゃんと校正してください。
それ以外はまぁ。「別に。」「特にないです。」
レンタルサーバのメンテが終了した。外からは全然分からないけど。(すっかり忘れてて朝繋がらなくてちょっとビビった。)
Rubyist Magazine - あなたの Ruby コードを添削します 【第 1 回】 pukipa.rb
Perl育ち(switch文がない)なのとリファレンスをよく読んでいなかったため、case .. when で正規表現マッチが行えることをまったく知らなかった。実際にはこれは case ではなく、Regexp の問題。
…が。これは Ruby 1.7 feature と書いてある1ので、1.6 を考慮する必要のある環境では使わない方がいいって判断して使ってないのかもしれない。あれー全然覚えてないな。
until, unless は使わないなぁ。ぱっと見て条件がどっちなのか分からないから。until はまだしも unless は譲れないと思う。「自然に読む」ことができない2し、not であることの意味が弱くなるから。同じ理由で後置するのもきらい。条件の存在が目立たなくなると目で追うときに混乱しやすい。
全体の構造的な部分は参考になるんだけど、細かい部分は「本人はすっきりしたかもしれないけど分かりにくくなっている」部分もあって3、採用するかどうかは現場判断て感じかなぁ。式の埋め込みは Ruby らしさの一つだけど、記号が増えていや。Perl じゃないんだから記号は増やしたくない。こういう考え方もまた Ruby らしさを実現するものではなかろうか。まぁ必ずしも埋め込むべきではないと断ってあるんだから、ネチネチとつつくようなポイントでもないんだけど。
いちばん気になったのは PukiWiki のパーサとしては実際には機能しない(かなり簡略化されている)のに PukiWikiParser というクラス名はどうなんだってところか。(読み始めた瞬間にものすごい期待が膨らんだのだ。)
いやぁ面白いな、これ。いろいろ書いたけど勉強になります。Ruby だけじゃなくて他の言語でもこういうのあったらいいかも。C や Java なんかだとすでに書籍であるのかな、というか C はそういう書籍を読んだことあったかも。
Rubyist Hotlinks 【第 10 回】 わたなべひろふみさん
自分の中では porter というよりは one liner 使いというイメージが強いわたなべさん。
すげぇ。このすっとぼけっぷり。さすが。
ぼくはですね。この人に憧れてメールの書き出しをかたくなに
渡辺です。
にしてるんですよ。本家は
わたなべです.
なんだけど、そこはあえて同じにならないようにするのです。ここポイントね。いや、別に名前なんだから当たり前じゃんと思うかもしれないけど、書き出しはお世話になっておりますとか、そういう書き方をする風土もあるでしょ? でもあれヤなの。watanabe desu. って書きたいんだよ!
Ruby がしばらく好きになれなかったとか、引数が減って嬉しい1とか、そういう細かいポイントが同じなのもとても嬉しいです。do .. end きらい2とか、本当にどうでもいいポイントですが。
今までのインタビューと違って大ネタがないまま終わりましたが(笑)、私は満足ですよ!
つかれた。本日の目標(現在 1:30)80%