昨年の正月に自分、2010年振り返りと2011年の展望 | Like@Lunaticというポストしてますね。そのときにはこう書いています。

今年はこの私、三十歳になります。 今年はこうありたいと思うキーワードは「原点回帰」です。漢字一文字で表現するなら「捨」。 やりたいこと、というよりは「やらないこと」ですね。「いらないもの」をとにかく捨ててシンプルな状態を目指そうと、漠然と考えています。そして自分の原点と思えるポイントは大事にしたい。いい状態で三十路を迎えたいです。

では2011年を振り返ってみてどうなのか。 「捨」てることは意識的に行ったという自覚はあります。

その意識面で特に影響を受けた書籍は「お部屋も心もすっきりする持たない暮らし」「シンプルに生きる―変哲のないものに喜びをみつけ、味わう」です。どちらも女性向きに書かれている書籍ですが、ヤローが読んでも十分に有用な内容が書かれています。物質的にも精神的にも「入ってくるものが出ていくものより多くならないようにする」。このバランス感覚を心がけるようになりました。

その延長で、今までは気にならなかった「不要なモノ」がかなり気になるようになったので、衣類や書籍を中心にいまだかつてない勢いでモノを捨てました。特に実家の自室は、かなり片付きました。整理して空いたスペースは、今や家族のモノが置かれてしまっていたりするのですが…。

行動面で「捨てた」のは、ずっと続けてきた某ネットゲームをやめたこと。なんだかんだで7〜8年は続けてしまったゲームをやめました。震災でいろいろと世の中が変わったので、落ち着いてゲームなんてやっていられないよ、という気持ちになったのかもしれないけれど。いや、仕事に費やす時間が単純に増えただけか…。ゲームしなくなった分の時間で何かプライベートで有意義なことができているか、というとそうでもないので。

挑戦したこともたくさんあった

• 旧知の仲間とバンドを組んでライブをやった
• 英会話を始めた
• 近所をランニングするようになった
• 自分で弁当を作るようになった

仕事の面ではチームに向けて提案してきたことが導入されたり、使ったことないCMS使ったり、業務で書いたことない言語に挑戦したり、なんだか新しいことづくしでした。仕事量は増えたけど、退屈で理不尽上なプロジェクトに振り回されて病んでいた一昨年よりはずっといい年になりました。 昨年新しく提案したり新しく触れた技術に関するキーワードは

• PHP
• WordPress
• Sass
• Less
• SVN
• Git
• GitHub
• C
• C++
• OpenFrameworks
• SQL

など。現状現場でちゃんと使えてるのはSVN、Sass、WordPressくらい。PHPは実践でガシガシ書けるレベルになりたい。 優秀な新卒がチームに入ってきて、僕も負けてらんねーな、という具合にいい刺激にもなっています。

震災の影響で変わったこと

震災直後、弊社は一週間「自宅作業推奨」となったのですが、その間僕はMacBook片手に実家に帰っていました。実家でぐーたらしていたわけではありません。仕事は山盛りにあったので、ほぼ自室にこもって作業をしていました。そうして思ったのは「あ、自分、自宅で仕事できる人なんだ」ということ。それと「MacBook1台あれば基本的な仕事はほぼできる」という気づきもありました。自宅で仕事をする環境など、会社員になってから整えたことはなかったのですが、これが図らずも良い機会となり、MacBook片手にどこでも作業をするスタイルが固まってきました。

7月には、新しくなったMacBookAir(13 inch)を即座に購入。MacBook Air、軽すぎ、薄すぎです。A4の書類が入るバッグに突っ込んで、ほぼ毎日持ち歩いてます。便利すぎて元のMacBookには戻れません…。

職場でGoogle Appsを使うようになったこともあり、どこでも仕事ができるスタイルに拍車がかかっています。今流行っているらしい「ノマド」とかいうの、こういうこと？

震災のことについては、昨年ボランティアツアーに行った際に諸々書いたのでここでは省略。

30歳になった

昨年で僕は30歳になりました。年齢故の焦りというのは正直、ありました。世間的な見られ方と実際の自分とのギャップとか、そんなことをちょっと考えるようなこともあるけれど、別に悩んではいません。30年も生きてくると「自分の変えられないところ」が分かってきたような気がします。「変えられるはずだ」とあがいた20代、「変えられないこともある」と気づく30代、というところでしょうか。

また、この年齢になって「老い」を自覚するようになりました。自分の身体的な絶頂期はもうとっくに過ぎ去ったのだ、ということですね。 分かりやすいところでいうと自分の顔付きが変わってきたということから、やたら肩がこるようになったとか、目が疲れて霞むことが多くなったとか、数年前まではなかった感覚を覚えるようになりました。まあこれは僕が単に他人より虚弱体質だからかもしれないけど。 ランニングをしたり、極力自炊をして自分にあったものを食べるようになったのも、体調を考慮してのこと。今後の人生でエネルギーいっぱいに活動していられる時間って、想像以上に短いんじゃないかと思うようになりました。

そして今年は

意識的にやることは増やしてあります。「本当に今やっておくべきこと」を考えた結果のことです。 大量のタスクに流されてあっぷあっぷと溺れてしまうのか、どうにかうまいことやって泳ぎきるのか、今年はそんな年になります。4月からいろいろと変わるので、今はそのための準備期間。準備をどれだけやるかで、4月からうまく泳げるかが決定しそうです。 さて、がんばろう。

今回のリニューアルでやったこと

1. 記事をMarkdownで書くことを前提とした
   • GitHubを使い始めてからMarkdownマンセーになったので
2. デザインはBootstrapをベースにする
   • Mardown前提ならある程度スタイルが最初から用意されているフレームワーク使った方が楽
   • ビジュアル面のデザインをする気力がないだけということもあるが
3. WordPressのテーマは”Twenty Eleven”を継承した子テーマに
   • これも楽をしたかっただけ
   • 最初はBootstrapに最適化したようなテンプレートを書こうと思ったけど、めんどくさくなって諦めた
   • Twenty ElevenをベースにBootstrap + αをくっつけるだけ、みたいなテーマを書いた
4. トップページに自分のツイートを表示して人気（ひとけ）を出す
   • ソーシャルサービスのデータを表示すれば、ブログを更新していなくても人気が出て寂しくないお。リアルタイムな雰囲気が出ていいんじゃないかと
   • 今のところTwitter APIをPHPで叩いてるだけ。WordPressのエントリーは普通にテンプレートで出力してる
   • 全部データを書き出した後に日付順にソートしてる。新しいものは上の方に、古いものは下の方に表示される
   • 今後、他サービスのAPIにも挑戦したい。Instagramの写真を展開したりとか。でもそうすると余計ブログを更新していないことがバレバレになるお
5. トップページのレイアウトにjQuery Masonryを使う
   • 今風にしてみたかっただけ
6. ソーシャルサービスのアイコンはIconDock.comより拝借
   • awesomeです。ありがとうございます。

今年の目標など

書こうと思ったら長くなりそうだったので別のエントリーにします。

というわけで本年もどうぞよろしくお願いいたします。

Visual mode+sを普通に使っていた僕にとってこれは手痛い変更。Visual選択してからShift押してsなんて、かったるくてやってられない。

しかし改めてドキュメントを読んでいると、ys+[なんたら]が強力であることが分かって、そっちに乗り換えるのが正しい使い方なんだろうなと思った。

例えばこれを

<h1>大見出し</h1>

こうしたいとする

<h1><a href="#">大見出し</a></h1>

今までは

vits<a href="#"<Enter>

とやっていた（Visual modeでタグの内側を選択してからsでsurround.vimを起動してタグを打ち込んでEnter）。 でも今はこうしなきゃいけない。

vitS<a href="#"<Enter>

途中でShift+sは苦痛。 しかしこうできることが分かった。

ysit<a href="#"<Enter>

（タグの内側に対してsurround.vimを起動。タグを打ち込んでEnter）
久しぶりに「おおっ」と思った気づきなので、思わす記事を書いてしまった。

世間ではVim Advent Calendar 2011をやってるみたいです。Check it out!!

最初からこう言ってはなんだが、この記事を書くに当たって特に目的があるわけではない。現地での体験を報道したい訳ではないし、あわよくば読んでくださった方にボランティアに参加してもらいたい、なんて尊大なことは全く考えていない。ただ、自分の体験を文章にして公開したい、それだけだ。

ツアーに参加するきっかけ

TVニュースによる報道や、友人である柴田さんのブログ記事を見て、自分もこの目で被災地を見てこなければならない、という想いを持ったため。

なぜこのタイミングなのか

被災地をこの目で見たいという想いを持っていながら、なかなか行動に移すことはなかった。しかしとあるきっかけで決断に至る。そのきっかけの一つはスティーブ・ジョブズのスタンフォード大学卒業式での有名なスピーチにおける

“If you live each day as if it was your last, someday you’ll most certainly be right.”（邦訳：「毎日を人生最後の日だと思って生きてみなさい。そうすればいつかあなたが正しいとわかるはずです。」）

という言葉にインスピレーションを受けたことにある。このスピーチの動画（邦訳字幕付き）を観たきっかけは、彼の死によってネット上に溢れた情報の一つだったから。本当にしたいと思っていることをなりふり構わず実行するという信念を、僕はジョブズの言葉から感じ取った。 （彼の自伝を今読んでいる。丁度「Ⅰ」が読み終わったところだ。）

しかしあくまでこのエピソードはきっかけの一つに過ぎない、ということを重ねて書いておく。

参加にあたっての準備

助け合いジャパンのサイトを見てボランティアへの参加の仕方を知る。個人で参加するにはツアーがお手軽だ。スケジュールやツアーの内容からJTBが行っているボランティアバスツアーに参加することを選択。 活動に必要な所持品について、JTBから詳細な案内をメールでもらうが、自宅にないものがたくさん含まれていた。例えば

• インソール入り長靴
• 厚手のゴム手袋
• 防塵マスク
• 防塵ゴーグル

などは日常生活で使う機会もないし、どこにいけば売っているのかさえ知らなかった。ホームセンターなどで売っていることは分かったが、同時に都心には驚くほどホームセンターや作業用具店（ワークマンなど）がないということが分かる。東急ハンズに行けばなんとかなるのでは、と行ってみるも、東急ハンズには身につけるものはほとんど売っていないということに気づかされることとなった。 実家や知り合いを当たってみるも、思わしい結果を得られず、結局楽天市場から通販で購入することにした。購入に際して店からサイズからいろいろと悩むも、1週間ほどで全ての装備を取り寄せることに成功。これで準備は整った。

現地へ

記録が曖昧なところはあるが、スケジュールと活動内容は大体以下のような感じだった。

11/18（金）

• 22:30 丸の内鍛冶橋駐車場に集合
• 23:00 出発。ツアーバスは高速をひた走る。途中、SAで休憩を2回。道の駅での休憩を1回挟む。移動中に朝食を済ませる。 夜行バスで寝るのは至難の技。ツアー案内に「エアー枕、耳栓、アイマスクがおすすめ」とあったため、100円ショップでエラー枕のみ購入。（騒がしいところで寝るのは得意なので耳栓は必要なかった）しかしこのエアー枕、「ないよりマシ」程度にしか効果がない。首がかなり痛くなった。また、段差などによる車体の揺れで何度も目が覚めてしまい、熟睡することは全くできなかった。

11/19（土）

• 8:00 陸前高田市災害ボランティアセンター着。ボランティアセンターとはいっても、砂利敷きの広い空き地に祖末なプレハブ小屋が4〜5戸建てられただけのものであり、それを見て「ここは被災地なのだ」と改めて実感し、緊張感が増した。（記事冒頭の写真がその様子）
• 8:20 ボランティアセンター朝のミーティングが行われる
• 8:45 ボテンティアセンター発。バス移動で活動地へ。
• 9:20 活動地は陸前高田市今泉地区。依頼者の説明を聞く
• 9:45 活動開始。僕の担当は空き地（元宅地？）の草刈り。ひたすら、草を刈る。中腰、またはしゃがんで行う作業のため、足腰がかなり痛んだ。
• 12:00 昼休憩。バスに戻り、昼食を取る
• 13:00 活動再開。ひたすら草を刈る
• 14:20 活動終了。依頼者が現地を案内してくれるという。バスに乗り込み、市内見学へ。
• 15:30 ボランティアセンターに帰還。センタースタッフが消毒用アルコール、うがい薬を用意し参加者を手厚く迎えてくれる。ホットドリンクも振る舞ってくれた。ボランティアセンターには、資材を洗ったり手洗いうがいができる洗い場が用意されており、しかもお湯が出るようになっていた。ありがたいことである。この後、ボランティアセンターを後にし、宮城県気仙沼市にある宿へ
• 17:00 宿着。部屋割は、同性3人部屋。風呂に入って汗を流す
• 18:30 食堂にて夕食
• 19:30 自由時間（TVで日本シリーズ見て過ごした）
• 22:00 就寝

11/20（日）

• 5:45 起床。朝風呂に入る
• 6:30 食堂にて朝食
• 7:30 ツアーバスに集合
• 8:10 陸前高田市災害ボランティアセンター着
• 8:20 昨日同様、朝のミーティングが行われる
• 8:45 ボランティアセンター発。バス移動で活動地へ。
• 10:00 活動地は陸前高田市広田半島。元海水浴場があった付近だったようだが見る影もない。その近くの元宅地（現在では更地）にて瓦礫さらいをやる。僕は鋤（すき）でひたすらに土を掘ってはガラス片などをさらう。慣れない作業に、腰が悲鳴をあげる。しかし二日目となると参加者同士のコミュニケーションもスムーズなものとなっており、和やかな雰囲気の中で活動ができた。
• 11:20 活動終了
• 12:00 ボランティアセンターに帰還。再びスタッフに手厚い歓迎を受ける。
• 12:30 ボランティアセンター発。
• 14:10 岩手県一関市の入浴施設＆AEONにて自由時間。露天風呂に浸かって疲れを癒す（とはいえ昨日から3回目の入浴だが）
• 15:20 一関市発。東京への帰路へ。途中SAでの休憩を2回挟む。
• 21:50 東京駅前着

参加して感じたこと

景観

まずは何と言っても陸前高田市海岸部の景観の凄まじさ。TVなどの映像で、もしくはネットを通じて写真でこの景観を見た人もたくさんいると思うが、それが現実のものとして目の前に広がっているのだ。主立ったコンクリートの建物以外、全てが津波によって無くなっていた。街が根こそぎ消えてしまった、という印象さえ受けた。そして更地にはうずたかく積まれた瓦礫の山。（きっと半年程前に来ていたらまだ瓦礫が散乱しており、このように片付けられた状態ではなかったと思う） 人間社会というものは地球のほんの一つの側面に過ぎない、ということを改めて思い知らされた。 （被災地の様子を写真や動画で知りたいならYahoo!JAPANの東日本大震災 写真保存プロジェクトやGoogleの未来へのキオクを見るとよい）

一日目に活動した今泉地区はこの一部であるのだが、日中は終止、静けさの中で重機の動作する音が鳴り響いており、異様な雰囲気を醸し出していた。このような大地と海に雲間から陽光が指す様子は、神々しくさえ思えた。このインパクトは一生忘れることはないと思う。

現地の人々

少なくとも僕が出会った現地の人々は、この地の現状を受け入れ、前向きに復興に向かって歩いていた。 これは去年、僕の母方の祖母が亡くなった際に母が見せた態度を想起させた。母は葬儀で涙を見せはしたものの、実母の死というものを素直に受け入れていたと思う。彼女は次の日に変わらぬ振る舞いを見せていたのだった。 逆境に対して人がどう考え、行動するのかというテーマについて肌で感じることができた。

まとめ

復興支援活動には人力で行うには限界のある仕事もたくさんある。20人程の団体で一日ボランティア活動をして「これだけしかできないのか」という感想を持った。 ツアーの添乗員さんはこう言っていた。「この活動に効率は求めない。決して無理はしないでください。ボランティアの皆さんが復興支援に行くこと自体が、被災地の人々を勇気付けることになります。」

参加者は老若男女問わず様々な人がいた。学生さんから、定年退職後のお父さんまで。一人一人が震災に対しての問題意識を抱えており、自分にできることは何かを考え、ツアーに参加していた。中には何度も被災地に足を運んでいる人もいた。「まだまだたくさんやることがある」という意識からだという。

自分は、というとまた被災地に足を運ぶかどうか、今のところは分からない。感じたのは、現地で手を動かすよりも、もっとよく社会に貢献できる方法が僕にはありそうだ、ということ。

ボランティア活動でできることは、微々たるものかもしれない。しかしほんの少しでも前に進んで行くことが、復興に向けた一番の近道であること、これを被災者も支援を行う側も、きっと分かっているのだ。

前に進まなければ何も変わらない。

この言葉をもってこの記事の結びとさせていただきたい。

Macでのやり方はこちら
Help.GitHub – Set Up Git

SSH keyを登録するところがキモだが、コマンドまで全てちゃんとヘルプに書いてあるのでつまずいたところはなかった。拍子抜け。

最初に作ってみたレポジトリがこれ。
seckie/jQuery.ui.vScroll – GitHub

今年の春に作ったものだけど、今また案件で使う必要があって引っ張り出したら無駄なところがあったりしてちょっといじることになった。案件の制作物は当然会社のレポジトリに置くんだけど、これは個人的に作ったものだったりしたので、せっかくなのでGitHubに挑戦してみた。

まず自分の契約内容は以下

• 現在加入中のプランは「ホワイトプラン(i)」
• 基本使用料割引として「2年契約（キャンペーン）」
• パケット割引サービスとして「パケットし放題 for スマートフォン（キャンペーン）」

店員さんの案内によると、こうだ。

「2年契約（キャンペーン）」と「パケットし放題 for スマートフォン（キャンペーン）」はセット。どちらか一方だけをやめることはできない。

で、僕が今回やめたかったのは「2年契約（キャンペーン）」だ。ではそれとセットになる「パケットし放題 for スマートフォン（キャンペーン）」とは何か。

このサービスはパケット量によって1,029〜4,410円の料金が自動調節されるサービス。ほぼ使わなかった月は1,029円となる。通常の「パケットし放題フラット」というプランでは必ず料金は4,410円固定となる。ほぼ使わなかったとしても、4,410円。

つまり2年契約をやめるデメリットは、パケットサービスを使わなくても4,410円必ず取られる、という1点だけだ。そして、僕のようなヘビーユーザーは当然のように毎月Max料金までパケットサービスを使っているので、結果としてこれはデメリットにならない。

Softbankとの契約を今後2年続ける予定がないiPhoneユーザーは、契約更新月に2年契約をやめても全く問題ない、という結論に至ったのでこれを共有したかった次第。

…とはいえ、あくまでこれは2011年6月25日時点で、個人から発信されている情報です。現時点での正しい情報はSoftbank Shop、およびSoftbank公式サイトからご自身でご確認ください。

第10章の内容について、議論の対象となった部分を引用する。

10.3 変数の初期化のガイドライン

変数は最初に使用する場所の近くで初期化する

リスト10-2: 悪い初期化（Visual Basic）

' すべての変数を宣言する
Dim accountIndex As Integer
Dim total As Double
Dim done As Boolean

' すべての変数を初期化する
acountIndex = 0;
total = 0.0
done = False
...

' accountIndexを使用するコード
...

' totalを使用するコード
...

' doneを使用するコード
While Not done
...

…中略

リスト10-2の例では、done変数を宣言した後、done変数を使用するコードが実行されるまでに、done変数が変更される可能性がある。

…中略

もう1つの問題は、すべての初期化を1か所にまとめると、done変数は最後の方でしか使用されないにもかかわらず、すべての変数がルーチン全体で使用されるという印象を与えることだ。

…中略

これは、「関連する作業を1つにまとめる」という近接の法則の一例である。

なるほどなるほど。しかし僕は普段の業務でプログラミング言語らしきものはJavaScriptしか使わないので、JavaScriptに置き換えて考えよう。

var accountIndex = 0,
    total = 0,
    done = false;
// accountIndexを使用するコード
...

// totalを使用するコード
...

// doneを使用するコード
while(!done) {
    
}
...

これが本書で「悪い例」とされているコードをJavaScriptに置き換えたコードだ。しかし関数の先頭で var hoge = 0, fuga = false; のようにして変数をまとめて宣言（＆初期化）するのはJavaScriptではよく見られるコードだ。あのjQueryですらそのような記法を多用している。
JavaScript: The Good Partsによると

ほとんどの言語では、変数は一般的に最初に利用される場所で定義するのが最も良い方法だ。しかしこれは、ブロックスコープを持たないJavaScriptでは好ましくない。すべての変数は、それぞれの関数の先頭で定義したほうが良い。

とある。そう、JavaScriptはブロックスコープを持たない（{}でくくられた部分限定の変数スコープ）といういわゆる変態言語であり、変数のスコープを生成するのは関数ブロックのみだ。それが理由で、変数はまとめて関数の先頭で宣言するという記法がベストプラクティスとされている。

さてしかし、Code Complete第2版による「変数は最初に使用する場所の近くで初期化する」ほうがよいという理屈の続きはこうだ。

10.4.1 変数の参照はまとめて

変数を参照してから次に参照するまでのコードは、「脆弱性の窓」（無防備な時間帯）である。その窓では、新しいコードが追加されたり、何気なく変数が変更されたり、変数に含まれていなければならない値が忘れられてしまったりする。変数の参照は、常に近いところにまとめて局所化するのが望ましい。

…中略

これを測定する方法は、変数の「持続間隔」を計算することである。

…中略

リスト10-6: 1と0の持続間隔（Java）

a = 0;
b = 0;
c = 0;
b = a + 1;
b = b / c;

この場合、bの1つ目の参照と2つ目の参照の間にコードが1行あるので、その持続間隔は1である。bの2つ目の参照と3つ目の参照の間にはコードがないので、その持続間隔は1である。bの2つ目の参照と3つ目の参照の間にはコードがないので、その持続間隔は0である。

…中略

リスト10-6では、bの平均持続間隔は (1 + 0) / 2 = 0.5 である。変数の参照を近くにまとめると、コードの読み手がコードをセクションごとに読んでいけるようになる。

…中略

10.4.2 変数の「寿命」はできるだけ短く

変数の持続間隔に関連して、変数の「寿命」という概念がある。変数の寿命とは、変数が存続する期間内に存在するステートメントの合計である。

…中略

変数の持続間隔とは異なり、変数の寿命は、最初に参照されてから最後に参照されるまでの変数の使用回数を計算に入れない。変数が最初に1行目で参照され、最後に25行目で参照された場合、変数の寿命は25（ステートメント）である。

…中略

変数の持続間隔と同様に、変数の寿命もできるだけ短くする、つまりステートメントの数を少なくすることが目標となる。持続間隔と同様に、ステートメントの数を少なくすると、脆弱性の窓が小さくなるという利点がある。

…中略

寿命を短くするもう1つの利点は、コードを正確に把握できることである。変数に10行目で値を代入し、45行目まで使用しない場合、2つの参照の間に空いている空間は、変数がその間に使用されていることを暗示する。

…中略

変数の寿命が短いと、コードが読みやすくなる。読み手が一度に頭に入れなければならないコードの行数が少なければ少ないほど、コードは理解しやすい。

変数には「平均持続間隔」と「寿命」という概念があるという。そしてそれらが短くなった方がコードの読み手にとって読みやすいコードになるという。

去年、僕がとある案件で数千行に及ぶJavaScriptを書いた際、最も頭を悩ませたのはコードを頭に入れることだった。機能を追加・修正するために一度に頭に入れなければならないコードが多すぎたため、開発が進めば進む程、コードの修正は困難を極めた。

プログラミング初心者が誰しも一度はぶつかる壁なのかもしれない。コードの分割をはじめとする、コードの設計の重要性を肌で感じた瞬間だった。
だからこそ、上記の「読み手が一度に頭に入れなければならないコードの行数が少なければ…」というくだりに深く納得したのだった。

さて、ではJavaScriptにおいて「変数の寿命を短くする」ことと「関数の先頭ですべての変数を宣言する」ことは両立するのだろうか？これについて隣席の@keiskeyの意見はこうだった。

関数1つの長さ自体を短くしてしまうのがいいのでは。Google Closure Libraryのコードを見ていると、中身が2行しかないメソッドに長々とした名前が付いていたりする。そんな長い名前を付けるんだったら直接コードを書いてしまえばいいやん、と思うけど、「変数の寿命」のポリシーをもって書かれていると考えると合点がいく。

なるほど…と再び納得するとともに、「この話、共有してよかった」と思った。

例えば上述（リスト10-2）のコードを一つの関数だと考えるとこうなる。

function Account() {
    var accountIndex = 0,
        total = 0,
        done = false;
    // accountIndexを使用するコード
    ...

    // totalを使用するコード
    ...

    // doneを使用するコード
    while(!done) {
        
    }
    ...
}

この関数をクラス風に書き直し、機能分割するとこういう感じになる。

function Account() {
    // コンストラクタ
    ...
}
Account.prototype = {
    getAccountIndex: function() {
        var accountIndex = 0;
        // accountIndexを使用するコード
        ...
        return accountIndex;
    },
    getTotal: function() {
        var total = 0;
        // totalを使用するコード
        ...
        return total;
    },
    checkStatus: function() {
        var done = false;
        // doneを使用するコード
        while(!done) {
            ...
        }
    }
}

prototypeにぶら下げたメソッド1つ1つを短くまとめて上手に機能分割することが、限りなく正解に近いのではないかと思った次第。

僕はプログラマと呼ばれる職種ではないのだけれど、プログラミングに関わる人間として、こういった考察はとてもおもしろいと感じる。また何か同じような話があったら書いていきたい。

会場はWild Side Tokyoという新宿の靖国通り沿いのライブハウス。
全部で5バンドくらいが出演するようで、ラルクアンシェルやエックスのカバーバンドなどが出るとか・・・（詳細未決）

THE YELLOW MONKEYのカバーバンドは、ほぼ同じメンバーで2度目のライブです（前回は約2年半前）。
私は普段からバンド活動を行っている人間ではないので、上手な演奏ができるとは我ながら到底思いませんが、精一杯楽しもうと思います。今の生活スタイルだと普段から楽器をやることは困難なのですが、良い機会があればやりますよ、というスタンスでたまーにバンドやっています。
メンバー中で私が最年少、かつ現役で普段からバンドをやっていないのが私だけ、という非常に恐縮な状況なのですが・・・頑張ります。

もし「観に行きたいかも」なんて少しでも思った方は気軽に遊びに来てください。