トップ 最新 追記

誰も褒めてくれないから自画自賛する日記

nu-chon.org  「ぬ」あんてな  「ぬ」wiki  RSS
2000|01|02|03|04|05|06|07|08|09|10|11|12|
2001|01|02|03|04|05|06|07|08|09|10|11|12|
2002|01|02|03|04|05|06|07|08|09|10|
2004|01|02|03|04|05|06|07|08|09|10|11|12|
2005|01|02|03|04|05|06|07|08|09|10|11|12|
2006|01|02|03|04|05|06|07|08|10|11|12|
2007|01|02|03|04|05|06|07|08|09|10|11|12|
2008|01|02|03|04|05|06|07|08|09|10|11|12|
2009|01|02|03|04|05|06|07|08|09|10|11|12|
2010|01|02|03|04|05|06|07|08|09|10|11|12|
2011|01|02|03|04|06|07|
2012|01|03|05|06|08|09|
2013|01|08|09|
2014|01|03|05|08|12|
2015|01|04|09|10|
2016|01|
Sapporo RubyKaigi 02
Sapporo RubyKaigi 03
RubyKaigi
Sapporo RubyKaigi 2012
RubyKaigi 2013
2012年
6月
1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30

2012-06-06 [長年日記]

Design Pattern in Ruby 読了

元々、GoFパターンをすべて完璧に把握しているわけではないのですが、Ruby(とRails)でソースコードを書いている時にコーディング規約からロジックのデザインまで至る所で迷うことが多く、ちょっと古い本ですが、この本を読みました。

わかりやすく簡潔な英語で読み易かったです。しかも、オリジナルのGoFパターンに忠実に書いた後、Ruby風に徐々に書き換えていき最終的なパターンに至る、という一連の過程の中で、自分が不安に思っていたことに確信を与えてくれた箇所も多く、僕にとっては非常に勉強になった。

各パターンの最後に必ず、「すべきこと、やってはいけないこと」、「実際に世間で使われている例」、「まとめ」が書かれています。これらが各パターンが机上の話ではなく、現実に使うべきものであることを印象づけてくれました。また、「まとめ」では、その章で書かれていたことの簡単な説明に加え、後続の章で紹介するパターンはこれまでの章とはどこが違うのか、を簡潔に書かれていることから、各章の終わりでそのパターン毎に頭の中を整理した後に、次のパターンに進むことができました。

このように構成がルール化しているため、リファレンス的にも実用的な本だと思いました。これからも使える本です。

本書の

 I don't know what those new patterns will look like, but I do know that I can't wait to see them, 
 I also know that it is a great time to be a programmer.

という締めくくりが好きです。

Design Patterns in Ruby (Addison-Wesley Professional Ruby Series)(Russ Olsen)

本日のツッコミ(全5件) [ツッコミを入れる]

izumii19 [Iteratorパターンを勉強した時に実際に使う場面が思い浮かばなかったので、「実際に世間で使われている例」になんて..]

 [RubyのなかではIteratorというと一般的にはInternal Iteratorで、GoFのパターン本で書かれ..]

izumii19 [ありがとうございます! 調べてみたらおっしゃる通り私がしっているのはExternal Iteratorのようです(..]

izumii19 [最後の1行は 「さらに2つのIteratorの違いを、これから勉強してみます」と書こうとしたんじゃないかな…]

 [> コレクションの中から順番に要素を1つずつ取得…みたいな単純なコードだったので パターン本には、そういう本が多い..]


2012-06-22 [長年日記]

オープンソースカンファレンス2012 Hokkaido に参加してきた

6/16に開催されました。 http://www.ospn.jp/osc2012-do/

例年通りに当日登場してブラブラしながら手の行き届いていないところをサポートする、という無責任かつ感謝され率の高い役割をしようと目論んでいたところ、オム子から召集令状が届き、当日のセミナー会場運営まわりの中間管理職的な仕事を頂きました。

この役割で重要なタスクは、朝のセミナールーム設営、夕方のセミナールームの片付けの先導役でした。

オム子のきめ細やかな事前準備のお陰で、僕は迷うこと無くタスクをこなすことができました。オム子の陰の見えない努力のおかげで、僕は大した努力もしていないにもかかわらず、多くの方々から感謝されました。これはなんという役得でしょう。いつも誰も褒めてくれないのに珍しくたくさん褒められたり感謝されたりしたので、今のところ鼻の高さが3mくらいになっています。

オム子、ありがとう! 来年も他人のふんどしで相撲を取らせてください!

セミナーについては、松井さんのソーシャルゲーム開発に関するセミナーのルーム担当にもなっていたので、お話を聞くことができましたが、現実をしっかり捉えたすばらしいチームビルディングが実践できていることに、嫉妬しました。

では、また来年。


2012-06-26 [長年日記]

Code is art

ここ数年、プログラミングをしていて感じていることを書こうと思いました。他の人達がすでに言っていることですし、時代遅れな内容でもあるけど、共感してくれる人がいたらいいな。

長いまえがき

僕は気の迷いか、大学院を休学(後に退学)して地元のIT系の企業に就職しました。最初の仕事は業務アプリケーションの作成でPHP(当時は4.1が登場したころ)を使いました。当時はメジャーなフレームワークも無く、マンモス本を頼りにスクラッチで書いていました。その業務は僕の上司、同僚(僕と同い年)と僕の3人のチーム体制でした。僕以外の二人は"プログラミング"に対し、構造やプログラミングスタイルに強い意識を持っていました。その時の僕は、二人が何を話しているのか、何が重要なのか、ほとんど理解していませんでした。彼らに比べれば初心者の僕にとっては、動くプログラミングを書くことだけが重要で、そのことだけに必死でした。でも、環境というのは偉大なもので、負けず嫌いの僕は、「彼らと対等に話ができるようになりたいなぁ」と思い、紹介してもらったJava系の雑誌や書籍を毎日わからないなりにも読みふけっていました。プログラミングの奥深さを垣間見ることができました。当時はそれだけでしたが、今から思うと重要な経験だったな、と思います。

その後、別のソフトウェアの業務もありましたが、ネットワーク周りのことに興味がある時期があったり、大量のLinux+Apacheのサーバ構築やメンテをしていた時期がありました。この間、プログラミングについては完全に興味の範囲外でした。

2005年ごろ、Ruby on Railsの人気が急上昇しました。Rubyは以前から多少使っていたことや、精神的に余裕があったのもあり、Railsに触れてみようと思いました。これがちょっとした転機だったかもしれません。その直後にいくつかWEBアプリケーションを作る仕事があったため、Railsを頻繁に使うようになりました。最初は「WEBアプリケーションもラクにかける時代になったものだなぁ」くらいで考えていたのですが、RailsやRubyの知識が増えていくうちに、「ラクにかけること、わかりやすいこと」の裏側にある設計思想や命名規則が気になるようになりました。自分が書くコードもRubyの標準ライブラリやRailsのAPIのようなセンスでプログラムが書けるようになりたいなぁ、と思うようになりました。

これ以降、他のプログラミング言語を掻い摘んでみたり、オブジェクト指向設計の本を読んだりするうちに、その思いがますます強くなりました。

綺麗なコードを書くために必要なもの、と僕が思ったこと

ソフトウェアはまず「動くこと」が最重要であることに変わりはありません。いくら綺麗なコードを書いても動かなければ・・・よく聞く笑い話です。以下は、あくまでも動くことを前提です。綺麗なコードとはなんでしょうね。

  • クラス、メソッド、変数の命名が読み手に優しい
  • 直感に反しない
  • 第三者が理解しやすい
  • (他多数)

僕には網羅できません(笑)。どれも間違っていないと思いますし、人によって重要視するポイントも違うでしょう。でも、これらを自分のものにするために共通的に必要なのは、「プログラミングするという行為に対する愛着」だと感じています。強い愛着があれば、自分が(現時点で)納得のいくコードのイメージをするんじゃないかな、と。そのイメージから理想を追い求めるんじゃないかな、と。理想に到達するために、勉強してテクニックや知識を身につけるようになるのではないかな、と。

ちなみに、デザインパターンなどのテクニックはこの自分の思いを表現する言葉だと思います。他人のコードを読んで得たテクニックや、書籍を読んで得るテクニックは、自分が書くソースコードの表現力を豊かにしてくれます。表現力としてテクニックが重要なことは、楽器演奏、絵画などのプロフェッショナルな芸術の世界でも同じですよね。

アートだなぁ

(突然話が飛ぶのは、僕の文章能力の問題ですが、笑)

このクラス、メソッド、一行、変数・・・、そのすべてに強い思いを込めたい。そのすべてに無駄なものを無くしたい。コードに、その時の思考やパッションを注入したい。そのために、自分の思考を的確に表現してくれるテクニックを身につけたい。自分が書いたソースコードを読んでくれた人が、そのコードから自分の思考を掴みとってもらいたい。そしてなにより、

 自分が書いたコードをもっと好きになりたい。

と感じるようになりました。

そんなこんなを妄想しているうちに、「プログラミングは自己表現」だなぁ、と自ずと思うようになりました。自己表現であるからには「僕が気持ちを込めて書いたソースコードです。」と胸をはって言いたいです。だから余計、自分が書いたソースコードは美しくあって欲しいし、その気持ちがソースコードを美しくするんじゃないかと感じています。

だから、「プログラミングはアート」だなぁ、と

そして、そこから生まれる「コードはアート」だなぁ、と

僕自身、まだまだテクニックも知識も足りません。「守破離」という言葉を引用すれば、僕はまだまだ「守」のレベルですが、これからもプログラミングという行為を大切にしていきたいなぁ、と思います。そして、一緒にプログラミングするチームのメンバーと、少しだけでもこの想いを共有できたらいいなぁ、と思います。(暑苦しいですがね!)

僕は素敵なアーティストになりたいなぁ。

というわけで、かなり宗教じみた独り言でした。(おわり)


2000|01|02|03|04|05|06|07|08|09|10|11|12|
2001|01|02|03|04|05|06|07|08|09|10|11|12|
2002|01|02|03|04|05|06|07|08|09|10|
2004|01|02|03|04|05|06|07|08|09|10|11|12|
2005|01|02|03|04|05|06|07|08|09|10|11|12|
2006|01|02|03|04|05|06|07|08|10|11|12|
2007|01|02|03|04|05|06|07|08|09|10|11|12|
2008|01|02|03|04|05|06|07|08|09|10|11|12|
2009|01|02|03|04|05|06|07|08|09|10|11|12|
2010|01|02|03|04|05|06|07|08|09|10|11|12|
2011|01|02|03|04|06|07|
2012|01|03|05|06|08|09|
2013|01|08|09|
2014|01|03|05|08|12|
2015|01|04|09|10|
2016|01|

2012年
6月
1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30

Copyright (C)2005-2015 nu-chon.org.