嫁を作る技術

この記事は、 OIT Advent Calendar 2016の10日目の記事です。

 3年ぶりにブログを書きます。しかもAdvent Calendar。OITでAdvent Calendarをやろうという文化ができるのは本当にいいことだと思う。

Who are you?

 Kirika_K2という名前でTwitterをやってます。
 一応OIT Advent Calendarなので、OITとの関係を記しておくと2000年入学、2006年修士卒、HxSコンピューターサークル5代目代表です。現在はとあるSIerで研究職のような仕事をしています。(あと学祭の時に大量にハンバーガーを買い込むという意味の分からない伝統を始めた張本人でもある。本当に申し訳ない。学祭でサークルのブースに立ち寄った時は、資金援助させてもらうので、それで許してほしい。)

 今年はOITで大学院の講義を1つ受け持った関係もあって、odan君と繋がりができたので、Advent Calendarに書くことができました。今でも年3回は大学に行き、大学とはつながりを持っている身ですが、現役生に声をかけてもらえるのはとても嬉しいです。東京に来たときは声をかけてくれれば、ご飯ぐらいは奢ってあげたいと思う。(ただし現役生に限る)

 あと、こういうのを作ったこともある。今は誰でも編集可能なので、追加したい人は追加してくれると嬉しい。(もう5年前か。これ。)
togetter.com

今日は何の日?

 今日は何の日かというと、Advent Calendarにも宣言した通り、私の結婚記念日である。今年で5周年。
 正確には結婚式をやった日なのだけれども、当日はハッシュタグを作って、参列者がツイートしたりして楽しかったなぁ、と思う。
 ほとんどの人は一生に一回のことだと思うし、譲るところは譲りつつもお互いが納得できる結婚式をみんな挙げればいいと思う。

twitter.com

嫁を作る技術

 さて、本題なんだけど、「嫁を作る技術」といいつつも、本当はボケようと思っていて、Oculus Rift持ってきて、「未来に生きる日本人の嫁の作り方とはこうじゃー!!!」というのをやりたかったんだけれども、さすがに10日ちょっとでそこまでに至りつくには仕事も子育てもFF15も忙しく、結局着手することができなかった。来年に向けての反省としたい。そのため、ガチで、嫁を作る技術を語るしかなくなってしまった。

 ちなみに彼女を作る技術ではなく、嫁を作る技術である。そして技術と言いつつもただの振り返りである。
 そのため、ここには自分の結婚生活における振り返りの駄文が連なっているだけで、他の人に役立つ情報は一切ないかもしれない。

 これはちょっと自慢なんだけど、自分は付き合った期間も含めてここ8年、嫁と喧嘩をしたことが一度もない。結婚してからここ5年の嫁との生活を振り返って、何が良かったのか考えてみたいと思う。

出会いとか

 中高一貫で男子校で、そのままOITに入った自分は基本的に女性と話すという機会が殆どなかった。
 大学に入っても、それは同じで結局まともに話した女性は数えるほどしかいない。中学・高校の友達、大学の友達に関しては、むしろ自分が一番結婚が早かったぐらいで、社会人になったときに、会社の同期に紹介してもらったのが今の嫁である。

 重要なこととして、自分みたいに殆ど女性と繋がりがなかった人間が、女性と知り合うためには、友達の友達、職場で知り合った人、街コンなどの不特定多数のイベントのどれかを活用して出会うしかない。「親方!空から女の子が!」みたいな話や、どこかの田舎の女子高生と体が入れ替わって、お互いのことを深く知ることになるようなアニメのような展開は、まず訪れないので、諦めて積極的に動くべきである。

 当然、最低限の身だしなみとか清潔感のある服装、とかは遵守した上で…である。よく分からなければ、2万ぐらい握りしめて、どこかのセレクトショップに突撃して、話しやすそうな店員に上から下まで選んでもらえばいい。何回かやってると自分に似合う服、似合わない服が何となく分かるようになる。着古したTシャツとかは、首回りがヨレヨレになるので、部屋着として使うならともかく、そういう場で着る服としてはお勧めしない。

 そうすると、次の課題は何かというと、そういう機会があったとして、初対面の女性と何を話したらよいかという問題に直面する。
 ここで一番よくないのは無難にやり過ごすか、何もしゃべらずに終わることである。経験値をあげるために、無難な話題でも無難じゃない話題でもいいから、何か話そう。どうせ、そこで相手がドン引きするのであれば、どのみち長続きはしない。無難な話題としては、出身、相手の趣味等、無難じゃない話題で、いきなりガルパンや競プロの話をしても別に構わないんだけれども、相手に興味を持ってもらえなさそうなら、無理にする話題でもない。共通点を探すのでもいいし、興味津々で聞くもよし。
 会話はあくまでキャッチボールであることをお忘れなく。相手の取れない球を投げ続けても、うまくいかないです。

 そういう意味では、最近はアニメやゲームとかの話題も昔よりは振りやすくなってていいよね。
 あと、同じ趣味同士の接点で付き合うのは、個人的経験だと結構疲れる。
 ただ、共通の趣味があるというのはいいことなので、お互いが一緒に始められる新しい趣味を探すといいと思う。

付き合ってるときとか

 そんな感じで、数か月デートとか一緒に遊びに行ったりして、半年ぐらい遊んでから、交際申し込んで付き合うことになりました。
 経験則的には、出会ってから付き合うまでの時間が短いと、別れるまでの時間も早いような気がする。
 お互い社会人で、相手は休みが不定期だったので、土曜日は夕方から会う、相手の土日が休みの時は旅行に行く。相手が平日に連休があるときは、自分も時々平日に休んで、一緒に旅行に行く、みたいな感じの付き合いで3年ぐらいやってました。

 あと、嫁は元々ゲームが好きだったので、よく一緒にゲームしたかな。モンハンP2Gとか。
 一緒に始めた趣味とかもあります。スノボとか、山登りとか。(山登りは結婚後にヤマノススメ見て、大学の同期と急に始めただけだけど)

一緒に住み始めたときとか

 3年も付き合えば、そろそろ結婚をみたいな感じにもなるんだけれども(自分も相手も年齢的には30手前だった)
 結局付き合う→結婚になるためには何らかのタイミングやきっかけが必要になって、自分はそれが引っ越しのタイミングだった。(社員寮を出るタイミング)
 どうせ引っ越すなら二人で住めるところに、だとしたら両家の挨拶、今までどのタイミングで結婚に踏み切るか、というのを考えるのが馬鹿らしくなるほどあっという間に決まってしまった。ちなみに、結婚に当たっては、二人の意志とかより、親族を含めた調整の方が面倒だったと、補足しておく。

結婚生活とか

 結婚生活においては、お金の管理をしっかりと決めよう、とか家事の分担を決めようとか、まあ色々なサイトでアドバイスがあるんだけれども、自分の場合は共稼ぎで、双方に収入があるので、そこはシンプルで、

・お金は家に決められた額を入れておく。貯金は各自でやっておく。(入れるお金は収入に応じる)
・家事は分担を決めない。その代わり気づいたらやる。お金で自動化できるものはなるべく自動化する(食洗機とか)

 あとは、家族用のクレジットカードを作って、生活用品はそれで買うように。明細の管理は毎月自分がチェックしてます。
 基本的な性格の一致不一致については、結婚前から見ているので、そこが揉めたことはあまりないです。

 あとはお互いの仕事の状況を見ながら、年に数回は旅行に行ったり、お互いがストレスたまらないようにうまくやっているつもり。

今後のこととか

 そんな感じで5年ほどやってきたんだけれども。結婚5年目にしてついに子供が産まれました。
 新しい家族が増えて、子供中心の生活になりつつも、これまで通り夫婦としてうまくやっていきたいと思ってます。

 そんな感じで、結婚記念日おめでとう。俺。これからもよろしく。嫁。

 質問とかあったらコメントで適当に答えます。

大規模開発でも使えるRailsテクニック(1) 変更に強いメソッドを組む

 久々にブログを書きます。

 普段は大手SIerRuby開発をしているKirikaです。私の会社では4年ほど前からRubyをシステム開発に活用していくように取り組んでいます。当初はお客様、自社の人間を含めてRubyに向けられる視線は非常に懐疑的でありましたが、少しずつ実績を重ね、最近になって、ようやく大規模プロジェクトにも適用出来るという評価が得られるようになってきたと実感しております。

 私は現在Railsフレームワークを拡張して、独自の業務フレームワークを載せる仕事をしておりますが、私が2年間関わってきた大規模と呼べるプロジェクトの中で、Ruby / Railsのこういうところは大規模開発にも使えるよね、と思った点を更新していこうと思います。このブログを参照する方の中には、当たり前のようなことしか書かれていないと思われる方もいらっしゃいますでしょうが、ご容赦ください。

変更に強いメソッドを組む

 フレームワークの仕事でまず重要なのは、開発者にどのようなメソッドを提供するかを決定するところです。ここが決まれば、仮に実装がまだ出来ていなくて空の状態でも開発を進めることができます。開発者がどのように呼び出せば開発がしやすいかを考えるところが重要なのですが、私は呼び出しの箇所をとりあえず以下のように定義しておきます。

def convert(target, options = {}, &block)
  ...
end

 この書き方はRailsの中ではよく見かける書き方なので、知っている人にはあまり目新しい話ではないと思いますが、target引数には処理対象、optionsにはHashを定義して、パラメータの数を自由に増減できるように定義します。私の経験上、メソッドの呼び出しで必須パラメータとなるのは多くても3個程度で、それ以上になると呼び出し側でも煩雑になり、コードの可読性が落ちます。なるべく必須パラメータを減らしましょう。

 どこの開発でもありがちだとは思いますが、大抵最初に取り決めた要件では仕様を満たすことができなくなって、メソッドを拡張していくことになりますが、この形を取っていればoptionsにパラメータを1つ追加するだけで良いので、外部のインターフェースを変更する必要がなく、メソッドの実装をコピペして、別のメソッドを定義する必要がなくなりますw(自分の身内でそんなことをする人がいたら鉄拳制裁ですが…。)

 &blockは必ずしも必須というわけではありませんが、引数に開発者が独自にロジックを定義したいというケースはよくあります。Rubyにはlambdaがあるので、optionsの引数の一つとしてlambda式を指定する、という書き方でも良いのですが、可読性を考えるとブロックに指定したほうが見栄えは良いです。ただし1個しか使えないので、大切に使う必要があります。

 &blockを渡すメソッドを書くときは内部でblock.call、もしくはblock.yieldで呼び出します。callはブロック引数の個数をチェックする呼び出し、yieldはブロック引数の個数をチェックしない呼び出しです。開発者がブロックを定義する際にブロック引数の定義を固定したいのであればcall、そうでなければyieldを使うのが良いです。

def convert(target, options = {}, &block)
  ...
  block.call if block_given? # &もしくはblock.yield
end  

 他にlambdaを使ったテクニックとしては、パラメータの一要素の型で処理を切り替える、というものがあります。

 例えば、optionsに:messageという引数が使えたとして、当初は静的な文字列を出力するだけで良かったのに、開発が進んでくるとパラメータの値によって動的に値を返さなければならない、というようなケースはよくあると思います。

 例としてconvertメソッドというものがあって、messageオプションには処理が完了した時に出力するメッセージを定義できる、という仕様だったとして、開発者は既に以下のように呼び出している場合を考えてみましょう。

convert :title, :message => "converted!"

 この時、ある機能の呼び出しでは、動的に変更前、変更後のメッセージを動的に埋め込まなければならない、という事が決まった(もしくは発覚した)ということがあった場合のケースを考えてみます。Javaならオーバーロードが使えるので、同じメソッドを定義して解決すると思います。(そして、オーバーロードしたメソッドは大抵実装元がコピペされています。)

 Rubyはオーバーロードがありませんが、メソッドの中で引数の型を判定することで、オーバーロードと同じようなことができます。実装例としては以下のようなものです。

def convert(target, options = {}, &block)
original = self.__send__(target)
converted_string = ... # 例えばここで変換処理
case options[:message].class
when String, Symbol
p options[:message]
when Proc
p options[:message].yield(original, converted_string)
end end

 こうすることで、以下のようにどちらの書き方でも、メソッドは処理してくれるようになります。

convert :title, :message => "converted!"
convert :title, :message => lambda{|before, after|
 "#{before} convert to #{after}" }

 この辺りの書き方もRailsのソースを読んでいたらよく出てくる書き方なので、知っている人は多いかもしれませんね。

 このような実装をするときは、既存のソースコードをどんどん書き換えて行くので、RSpec等を使ってテストドリブンにした方が効率がいいです。

移転しました。

「Kirikaの非人間的生活」を閉鎖し、はてなブログに移転しました。

前の日記は全部インポートしましたので記事はそのまま見られると思います。

 

アンテナについてどうするかは検討中ですが、一時的に取り外しました。

しばらくは利用されたい方はhttp://a.hatena.ne.jp/Kirika/を利用してください。

 

一眼デビュー

 以前から使っていたEXILIM EX-Z40が、手持ちの携帯すら画質面で劣るようになってきたので、前々から欲しかった一眼に手を出してみることにしました。全くの初心者なので、あまり専門的なことは分かりませんが、選ぶ指標になれば。

  • 買ったカメラ

OLYMPUS マイクロ一眼 PEN E-P3 レンズキット シルバー E-P3 LKIT SLV

OLYMPUS マイクロ一眼 PEN E-P3 レンズキット シルバー E-P3 LKIT SLV

 友人がキヤノンやニコンの一眼レフを先に購入していたので、触らせてもらったのですが、自分は重い一眼レフを持って出かける姿を想像出来なかったので、前々から気になっていたOLYMPUS PENを購入することにしました。
 一眼を持つと結局レンズやカメラバッグ、その他アクセサリも持ち歩くことになるのですが、このサイズなら、あまり気にはならないレベル。重量はニコンのD7000と比較して、およそ半分。レンズを2,3本持って比較すると、約1kg弱の差になるのではないかと思います。
 画質面では本格的な一眼レフには劣るらしいのですが、元々コンデジから上がる人に取ってみれば入りやすい機種だと思います。

  • レンズ

 レンズについては殆ど知識がなかったので、人のレビューを見ながら以下の2本を購入。


OLYMPUS PEN レンズ M.ZUIKO DIGITAL ED 40-150mm F4.0-5.6 SLV

OLYMPUS PEN レンズ M.ZUIKO DIGITAL ED 40-150mm F4.0-5.6 SLV

 元々レンズキットで14-42mm F3.6-5.6がついていたので、広角単焦点レンズと望遠ズームレンズを1本ずつ購入しました。

広角単焦点レンズ(被写体10cmぐらいの位置から撮影)
f:id:Kirika:20120507224517j:image

望遠ズームレンズ(被写体1.5mぐらいの位置から撮影)
f:id:Kirika:20120507223625j:image

 結局何を撮りたいかというのが重要なのですが、同じような写真でもレンズを変えると随分表現できることが変わるのが一眼の面白いところではないかと思います。

 レンズの良し悪しについては焦点距離とか、F値とか、ボディとの相性とか色々あるみたいなのですが、自分は初心者なので、あまり多くは語らず、解説サイトで調べてもらえると助かりますw
【参考】
 http://www.coneco.net/hand/camera/slr.html

 望遠レンズといえば、こっちも気になっていたのですが、レビューのところに「野鳥を撮るのにオススメです!」と書かれていて、自分の用途にはあまり合っていなかったので、上の40-150mmにしました。もっとも40-150mmですら、今のところあまり出番がないですが…。

OLYMPUS PEN レンズ M.ZUIKO DIGITAL ED 75-300mm F4.8-6.7 SLV

OLYMPUS PEN レンズ M.ZUIKO DIGITAL ED 75-300mm F4.8-6.7 SLV

 ただ、こっちのレンズだと、一昨日のスーパームーンももっと大きく撮れたに違いない。
f:id:Kirika:20120507225926j:image

 次は金環日食の撮影にチャレンジしようかな、と思いつつも減光フィルタが高いのでちょっと躊躇しています。

  • その他

 レンズ買ったら、レンズプロテクターを買うことと解説サイトにもよく書かれていて、嫁のお父さんからも強く勧められたので、レンズプロテクターも買いました。3個で約5000円ぐらい。

Kenko PRO1D 46Sプロテクター(W) 324653

Kenko PRO1D 46Sプロテクター(W) 324653

 SDカードもEye-Fiにチャレンジしてみよう、と思って試してみました。
 確かに転送は楽ですが、ちょっと遅いし、電池も食うので普通のSDカードでも良かったかも。

 ただ、撮ったその場でスマートフォンに転送できたり、無線LANから撮影地点を記録してくれたりできるので、もう少し面白い使い方がありそう。しばらくは色々試してみようと思います。

Eye-Fi Pro X2 8GB EFJ-PR-8G

Eye-Fi Pro X2 8GB EFJ-PR-8G

 他にもレンズケースやカメラケースなどを入れると、ちょっとばかりお金を使いすぎてしまった感じですが、新しい趣味の初期投資だと思って、色々楽しみたいと思います。

クラス変数の甘い罠

 最近クラス変数を使ったプログラムで大きくハマったのでメモ。
 クラス変数にアクセスする方法としては、@@の修飾子を使ったアクセス方法とclass_variable_set, class_variable_getを使ったアクセスがあるのだが、この2つのアクセスの意味が微妙に異なることを最近まで知らずに、大きくハマってしまった。

 下記のプログラムでは、クラス内でクラス変数にアクセスするものと、モジュール内でクラス変数にアクセスするものを用意して、クラスからモジュールをincludeするようなプログラムを書く。

 module C 
   def self.included(mod) 
     mod.class_eval do 
       @@c = 5 
       class_variable_set(:"@@cc", 6) 
     end 
   end 
 end 
  
 class A 
   include C 
   @@a = 1 
   class_variable_set(:"@@aa", 2) 
 end 
  
 p A.class_variables 
 p C.class_variables 

 この時の実行結果は以下のようになる。


[:@@cc, :@@a, :@@aa]
[:@@c]

 これはclass_variable_setによるアクセスは呼び出されたレシーバのクラスに紐付くのに対して、@@によるアクセスは記述されたクラス・モジュールに紐付くからだと思われる。
 つまり、A.class_eval{ @@c }はNameErrorとなってしまう。

 しかも、上記の挙動は1.9.2のものだが、ruby 1.8.7ではまた違う挙動になることが分かった。こっちの場合は、更に良く分からない……。


["@@cc", "@@aa", "@@a", "@@c"]
["@@c"]

 有効な解決策としては、クラス変数を使わず、クラスのコンテキストに紐付くクラスインスタンス変数を使うのが一般的には良いとされている。プログラム上パッと見分けがつく、クラス変数の方が扱いやすいんだけど、どうにかならないものか……。

Ruby本を書きました

 去年の6月〜8月頃に書いていたRuby本がようやく販売されることになりました。

Ruby公式資格教科書 Ruby技術者認定試験 Silver/Gold対応 (EXPERT EXPASS)

Ruby公式資格教科書 Ruby技術者認定試験 Silver/Gold対応 (EXPERT EXPASS)

 自分は6章担当で添付ライブラリ周りのことについて書いています。

FlashBuilder 4.5

 久々にFlashBuilderを触ってみたらAndroidアプリやiPhoneアプリも作れるようになっていたので、手元のFlexBuilder3をアップデートすることにしました。
 
 過去の日記を見なおしてみると、Flexを始めたのは今から2年半程前。仕事でFlexを使う機会があり、おもしろかったのでこれからFlexを本格的に勉強していこうと思った矢先にRubyな部署に異動することになり、結局ちょっとFlexなアプリを作っただけで、結局その後、ほとんど使わなくなってしまっていたのでした。
 
 明日は、久々にFlash Builderと戯れようかと思います。
 

Adobe Flash Builder 4.5 Standard Windows/Macintosh版

Adobe Flash Builder 4.5 Standard Windows/Macintosh版