EOS 6Dでフルサイズ機デビューを果たしたのでまずは報告
突然ですがEOS 6Dを買いました。エイプリルフールネタじゃありません。
Canon デジタル一眼レフカメラ EOS 6D・EF24-105L レンズキット 約2020万画素フルサイズCMOSセンサー DIGIC5+(プラス) EOS6D24105ISLK
価格.com で最安値となっていた店が偶然近くだったので、急いで電話で取り置いてもらい、現金払いで購入。
箱。
じゃーん。
「ボディが軽くてコンパクト」というのが売りみたいですが、Kiss X5からの移行なので、ボディだけでもちょっぴり重く感じます。
こちらはキットレンズの EF 24-105mm F4L IS USM。
キットにして購入するかどうか、正直かなり迷いました。
APS-C機からの移行なのでフルサイズ機で使えるレンズをほとんど持っていなかったのと、「まぁLレンズにしてはそこそこ」という評判を良く聞いていたので「必要になったときに10万近く払って単品で買う気はあまり起きないなぁ」と思い、思い切って購入しました。
もちろんキットレンズには、EF24-70mm F4L IS USM という選択肢もあって、価格的にも少し頑張れば手が伸びそうでこちらも迷いました。しかし、こちらのレンズはキットとしてのお得感が若干少ない(=まぁ評判が良ければあとで単品で買ってもよいかな)ような気がしたのと、まずはつぶしの効く標準ズームを揃えようと思い、24-70mm F4Lのほうは見送る方向に。24-105mm をすでに所有していたのであれば、24-70mmのほうを買っていたかもしれません。
取り付けたところ。ボディが重いというよりはレンズのほうに重量感を感じます。
参考までにEOS Kiss X5+SIGMA 30mm F1.4 を並べて置いてみたところ。違いがわかるかと思って並べてみたのですが、意外とわからない…。
フィルター径は77mm。デカいのでプロテクターも高めなのですが、早々に前玉に傷を入れたりなどしてしまったらショックで1か月くらい立ち直れなそうなので、保険だと思って迷わず購入です。
Kenko 77S PRO1D プロテクター(W)ワイド 252772
ついでなので、液晶用の保護フィルムも購入しました。バリアングル液晶ではないということもあり、ちょっとした衝撃で傷が付いてしまうのが心配ですよね。
液晶プロテクター Canon デジタル一眼レフカメラ EOS 6D用 KLP-CEOS6D
以下、いろいろと試し撮り。
「丁寧すぎる確認」の弊害
たまには真面目に、最近いろいろと考えていることをエントリにしてみたいと思います。
受託制作の仕事をしていると「クライアントとの仕様調整」というタスクはしょっちゅう発生します。
仕様調整の業務を担当する「Webディレクター」や「開発リーダー」に相当する方々。彼らの仕事の進め方も実に多種多様で非常に興味深く感じているのですが、たまに「確認がやたら丁寧すぎる」という種類の人に遭遇することがあります。
電話一本で出来る仕様確認の作業に対して、わざわざ丁寧にパワーポイントの資料を作り、その資料メールに添付して送付し、さらに電話で口頭説明し…。
で、そのような確認のしかたをしているディレクターの人に話を聞いてみると「仕様に齟齬があって作業が巻き戻ると大変だから、ちゃんと伝わっているかしっかり確認してるんです」という意見が決まって出てきます。
仕様をしっかり確認すること、そりゃあ大事さ
確かに、万が一仕様の勘違いがあった場合の巻き戻りリスクの大きい部分については、詳細にメリット／デメリットを並べてどうすべきかをしっかりとクライアントに選択してもらう必要があります。至極真っ当な話です。
実装しなければならない機能が丸々抜け落ちていたり、データベースの構造が大きく変わってしまうようなレベルの仕様の勘違いが発生したり、このようなことを繰り返して死の行進まっしぐら・・・というようなプロジェクトを、これまでにいくつも目にしてきました。
リスクマネジメントの問題
しかしながら「リンクを画面上におくのか、それとも画面下におくのか」とか「画面の項目をどの順番に並べるのか」とかいう非常に細かい内容についてまで、逐一詳細に確認しようとする人がたまーにいます。
細かい部分に対してくまなく詳細な確認を繰り返してたら永遠に終わらないのは明らかですよね。当然スケジュールは遅延。そういう人に限って「クライアントの仕様確認が遅かったからスケジュールに間に合わなかったんだ！！」という言い訳をすることが多い。いや、それそんなに大量に案を並べられたら、誰だって迷うでしょうに…。
（デザイン的なバランスはさておいて）「リンクを上に置くか下に置くか」を取り違えることによって生じる追加の手間はごくわずかですし、クライアントがわざわざそれにこだわる可能性もごくわずかで、「齟齬があった場合の手間」とのバランスを考慮しなければならない、という事実が往々にして見落とされている…という点が非常に残念に感じたりするのです。
これはまさに「リスクマネジメント」の領域の話で、「仕様の齟齬により作業の巻き戻りが発生する」というリスクにも大小あり、充分小さいリスクに対しては、あえて見過ごすという選択も必要になってくるのではと思います。
判断材料にノイズを増やすことの弊害
仕事柄iOSのアプリを実装することも多いのですが、iOSアプリのほとんどにおいて「前の画面に戻る」機能を持ったボタンは「画面の左上」に付いています。
「iOS SDKのUINavigationControllerの仕様がそうなってるから」とか「iOSのヒューマンインターフェースガイドラインにそういう記載があるから」とかいう理由に加え「大半のiOSアプリでは戻るボタンは左上に付いているから、iOSに慣れている大半のユーザはそれを自然なものとして捉えている」だあろうことは、容易に想像が付くはずです。
ところがそれに対し、「戻るボタンは左上に付けるか左下につけるか右上につけるか右下につけるか、はたまたメニューの中に戻るメニューを入れるか、それそれのメリット／デメリットは…」などと長々と資料を作りクライアントに見せてしまう。そんな明らかな筋が悪い確認の仕方をしてしまう人も、一部には存在します。
非常にまれなケースでは、戻るボタンの位置も確認の余地はあるかもしれません。「戻るボタンが左上にあることでなんらかの大きな誤解を招く恐れがある」とか「別の場所に置くことでより大事な意味合いを持たせたい」とか。
ただし多くのiOSアプリにおいては、そこにこだわりを持つことには大きな意味はなく、細かい仕様の確認をせずに戻るボタンを左上に置いた画面仕様を作り、「これはこういうもんだよね」でさらりと流してしまうのが普通かと思います。
それを逆に「立派な資料」で問いただされることにより、クライアントにとっては「大して重要でもない選択」が「とても重要な選択」に感じられてしまう可能性があります。
「戻るボタンを左下に付けることにもメリットはあるのか？？」とか「メニューの中にも戻る機能を付けておいたほうが便利なのでは？？」とか、本質とは外れた方向でクライアントの苦悩が増えてしまうのです。
このように「選択肢は多ければ多いほどよい」という考え方には、「余計な情報が含まれていて逆に判断を阻害する」という可能性は考慮されていないことが多いのでは、と思います。
「丁寧すぎる人」への対策はあるか
普段からこのような「丁寧すぎる確認」に慣れてしまった人にとって、「そこは手を抜いて簡単にやってしまえばいいのでは？」と意見を投げかけると、大抵はとても嫌な顔をされます。「自分がこんなに一生懸命やっているのに、お前は手を抜けというのか？」と言わんばかりの顔。
「クライアントの判断を阻害している」というデメリットも、「これだけ有益な判断材料を提供しているのに、まともに決められないクライアントが悪い」というような方向に考えてしまっているようで、自覚を促すのは困難を極めることが多いなぁと感じています。
「丁寧すぎる確認作業」はプロジェクト的には明らかに無駄な作業であり、「無駄なコスト」以上のなにものでもないと思うのですが、なんとか出来る対策がなかなか見つからないのは悩ましい限りであります。なんとかなるもんなら誰か教えて欲しいです。ほんと。
はてなダイアリープラスに申し込んだにも関わらず、更新頻度がガタ落ちしている私の近況について
先日私の誕生日があり、自分へのプレゼントと絡めてカメラ機材を一新しようと考えているのですが、貧乏性が働いてなかなか購入出来ないちっぽけな私です。どうもこんにちは。
昨年12月の某Advent Calendar以降、子育て関連のアクセスが急増しており、期待に応えて有益な情報を継続的に発信していこうと決意。自らの士気を高めるために「はてなダイアリープラス」を1年分申し込みました。
ところが、プラスを申し込む前に比べても更新頻度がガタ落ちしている現状。
一体この私になにがあったのか？いや、特に大変なことが起きたわけではないのですが、この場を借りて色々言い訳したいと思います。
子供の面倒はもちろん見ている
我が家の子供もいよいよ家の中を匍匐前進で動き回るようになりました。ちょっと目を離すと加湿機の電源コードを舐めていたり、布団の隙間に挟まって身動きが取れず泣いていたり、なかなかスリリングな日々を過ごしております。
とりいそぎ電源周りは危ないので、早めに対処しようと思い、コンセントキャップを購入し装着しています。
アカチャンホンポやベビーザらスでも探したのですが、逆に子供の興味を惹いてしまうような派手なデザインのものが多く、なんとなく逆効果になってしまいそうだったので、出来るだけ地味な見た目のものを選定しました。
現在は妻も休職中の為、今はある程度は面倒を任せてしまっているところも多いのですが、今年の4月にも復職予定のため、より一層忙しくなっていくことが予想されます。
仕事の拘束時間が増えている
最近仕事の役割がちょっぴり変わってきておりまして、週1〜2回程度の頻度で深夜の監視作業が入ったりなどしています。自宅作業なので早く帰宅出来るのは良いことなのですが、地味に時間を取られてしまうのが結構な悩み所です。
ドラクエ7おもしろい
ネット上での評判通り、すれちがい通信については「ひたすら石版を捨てるミニゲーム」と化しているところがあったりなど、あれだけ悪評が出回るのも仕方ないなぁとは思う一方、ゲーム本編に関しては、十数年前のPS版からいい感じでリメイクされており、通勤電車の行き帰り、昼休みなどを活用してモリモリと進めている今日この頃であります。カジノ楽しいよカジノ。
将棋の勉強もしてる
高校時代に部活動で将棋を勉強しておりまして、当時は部長で県大会もレギュラーで出場していたりなど、そこそこな感じで頑張っておりました。部活の引退をきっかけに15年ほどほとんど将棋を指していなかったのですが、2013年の一つの目標としてもう一度将棋の勉強をし直してみよう、と決意しました。
とはいえ子供もまだ小さく、休日に町道場に通う時間もなかなか取れないので、時間が空いているときに将棋倶楽部２４で対局したり、定跡書や詰将棋本を読んだりして、棋力の向上に努めています。
定跡本や詰将棋本は、いろいろ購入しているのですが、最近一番お世話になっている一冊を紹介したいと思います。
将棋連盟文庫 塚田正夫の詰将棋
塚田正夫名誉十段の詰将棋の名著。詰将棋はこの本を前から順番に解いており、現在9手詰の真ん中あたりまで来ています。数ある詰将棋の本には、あまりにも手が広すぎて全部読み切るまで精神力が続かないもの、実戦で絶対出て来そうもないような手が出てくるもの、などもあるのですが、この本に関してはそのようなことは全くなく、解けたときの爽快感がとても良い感じです。決して簡単な詰将棋ではないのですが、私のような級位者でもしっかり解いていける、オススメの詰将棋本です。
インターネットが無かった時代、ボクの出身地のような田舎では、詰将棋の本を探すのにも一苦労だったのですが、現在はこのような良質の本がAmazonで簡単に手に入る。本当に良い時代になったものですね。
たまには写真も撮っている
「カメラを新調しよう」という発言からも分かります通り、暇を見つけて写真を撮りに行ったりもしています。
初めて一眼レフカメラを買ってから1年。結局のところ風景／ポートレートがほとんどなので、買うのであればEOS 6Dあたりを狙っていこうかと思ってます。せっかくなので末永く使える「24-70mmレンズキット」とかをガツンと買いたいのですけど、値段が値段だけに家族の理解を得るのが大変なのですよねぇ。ちょっぴり困ってます。
Canon デジタル一眼レフカメラ EOS 6D・EF24-70L IS レンズキット 約2020万画素フルサイズCMOSセンサー DIGIC5+(プラス) EOS6D2470ISLK
結論
趣味が増えすぎて全く手が足りなくてやばい。
過去のはてなブックマークからランダムで1件選んでツイートするBot
「あとで読む」タグを付けて放置しっ放しのブックマークが数多く溜まっている現状を打破したいと思い、Twitterのbotを実装しました。
具体的には、はてなブックマークの全ブックマークの中からランダムで1件を選択し、その情報をTwitterにツイートします。
過去のはてなブックマークからランダムで1件選んでツイートするBot · GitHub
ブックマークの情報をどこから取得するか
フィードが提供されているのでこれを使います。
はてなブックマークフィード仕様 - Hatena Developer Center
全ブックマーク数の取得
フィードをRSS形式で取得した場合、 "opensearch:totalResults" 要素に全ブックマーク数が含まれています。
RubyのRSSライブラリではこの値は取得出来ないため、Nokogiriを使ってゴリゴリXMLとして読み込みます。
... <channel rdf:about="http://b.hatena.ne.jp/aquarla/"> <title>あくあーらのブックマーク</title> <link>http://b.hatena.ne.jp/aquarla/</link> <description>あくあーらのブックマーク</description> <opensearch:startIndex>1</opensearch:startIndex> <opensearch:itemsPerPage>20</opensearch:itemsPerPage> <opensearch:totalResults>3295</opensearch:totalResults> <items> ...
ブックマークの情報をランダムで1個だけ取得
全ブックマーク数をもとに、「n番目のブックマークを取得する」のnをランダムで決定し、当該ブックマークの情報をピンポイントで取得します。
はてなブックマークフィードのドキュメントには、 "of"パラメータを付けることでページングが可能と書いています。
http://b.hatena.ne.jp/aquarla/rss?of=20
ちなみに、ドキュメントに明記されていない（実際に動かしてみるとわかる）仕様がいくつかあって…。
- 1ページで取得出来る件数は20件固定。減らすことも増やすことも出来ない
- "of"パラメータは自動的に20の倍数に切り詰めて扱われる。（たとえば"of=30"を指定しても、20に切り詰めて扱われる）
title、link、description要素はRSSライブラリでも取得出来るのですが、ブックマーク数の取得にNokogiriを使っていてここで別のライブラリを持ち出すのもアレなので、そのままNokogiriでゴリゴリ取得してしまっています。
ブックマーク情報をツイート
取得したブックマーク情報（タイトル、URL、コメントなど）をTwitterにツイートします。
- ライブラリはなんでも良いと思うのですが、ここではRuby OAuth Gemを使っています。
- 文字列内に"@"が含まれていたりすると迷惑になるかもなので、ツイート前に予め取り除きます。
- タイトルやコメントが長すぎる場合は切り詰めます。あまりゴツいライブラリはrequireしたくなかったので、文字列切り詰めの処理部分だけをActiveSupportから無理やりパクってきました。それが嫌な人はActiveSupportをそのまま使いましょう。
ソースコード
#!/usr/bin/env ruby # -*- coding: utf-8 -*- require 'rubygems' require 'open-uri' require 'nokogiri' require 'oauth' # ActiveSupportのString#truncateを参考にする # String#mb_charsは、Ruby1.9前提であればそのままselfを返してよい class String def truncate(length, options = { }) text = self.dup options[:omission] ||= "..." length_with_room_for_omission = length - options[:omission].mb_chars.length chars = text.mb_chars stop = options[:separator] ? (chars.rindex(options[:separator].mb_chars, length_with_room_for_omission) || length_with_room_for_omission) : length_with_room_for_omission (chars.length > length ? chars[0...stop] + options[:omission] : text).to_s end def mb_chars self end end # 過去のブックマークからランダムに1個を選びツイートするbotクラス module HatenaBookmarkBot class Base # Twitterアクセスのための各種情報 CONSUMER_KEY = "XXXXXXXXXXXXXXXXX" CONSUMER_SECRET = "XXXXXXXXXXXXXXXXX" ACCESS_TOKEN = "XXXXXXXXXXXXXXXXX" ACCESS_TOKEN_SECRET = "XXXXXXXXXXXXXXXXX" # はてなブックマークのユーザー名 HATENA_BOOKMARK_USERNAME = "aquarla" # はてブRSSをXMLとして取得 # offsetを指定した場合は、offset件目以降を取得 def open_hatena_bookmark_rss(username, offset=nil) rss_url = "http://b.hatena.ne.jp/#{username}/rss" rss_url += "?of=#{offset}" if offset open(rss_url) do |file| yield file.read end end # XMLから現在の総ブックマーク数を取得 def bookmark_count(xml) namespaces = { 'opensearch' => 'http://a9.com/-/spec/opensearchrss/1.0/', } Nokogiri::XML.parse(xml).at('.//opensearch:totalResults', namespaces).text.to_i rescue -1 end # 文字列をツイート def tweet(status) consumer = OAuth::Consumer.new(CONSUMER_KEY, CONSUMER_SECRET, :site => 'https://api.twitter.com') access_token = OAuth::AccessToken.new(consumer, ACCESS_TOKEN, ACCESS_TOKEN_SECRET) access_token.post('/1.1/statuses/update.json', 'status' => status) end # 処理本体 def run # 1. はてブのRSSフィードから、ブックマークの全件数を取得 open_hatena_bookmark_rss(HATENA_BOOKMARK_USERNAME) do |xml| count = bookmark_count(xml) # 2. 全件のうち何件めをツイートするかをランダムに決定し、 index = rand(count) open_hatena_bookmark_rss(HATENA_BOOKMARK_USERNAME, index/20*20) do |xml2| namespaces = {"rss" => "http://purl.org/rss/1.0/"} item = Nokogiri::XML.parse(xml2).xpath("//rss:item[#{(index%20)}]", namespaces) title = item.xpath(".//rss:title", namespaces).text link = item.xpath(".//rss:link", namespaces).text description = item.xpath(".//rss:description", namespaces).text # 3. ブックマーク情報をツイートする # ツイートに@が含まれていると迷惑なので外すのと、 # ツイートが長すぎる場合はタイトル及びコメントを切り詰める status = if description.nil? || description == "" "#{title.truncate(100)} #{link}" else "#{description.truncate(50)} / #{title.truncate(50)} #{link}" end status.gsub!(/@/, "") tweet(status) end end end end end if $0 == __FILE__ HatenaBookmarkBot::Base.new.run end
おわりに
上記のプログラムを、どこかのサーバで定期的にcron実行するようにすればOK。
「あとで読む」を消化するために実装したbotですが、今まですっかり忘れていた事項をプッシュで配信してくれるので、意外と便利です。
遠い昔のブックマークをツイートすることも多く、色々と紛らわしいので、protectedでの運用を推奨します。
「Graph APIでプロフィール画像のURLを取得する方法」が色々変わっていたのでまとめてみる
1年半前あたりのエントリで、「Facebook Graph APIでユーザーのプロフィール画像（のURL）を取得する方法について紹介しました。
Facebook Graph APIでプロフィール画像のURLを取得する方法 - でぶぬる日記
ところが最新の事情は色々と変わってきているようなので、少しまとめてみたいと思います。
"redirect=false"パラメータを付ければ、pictureエントリポイントでも画像URLを取れる
以前は
https://graph.facebook.com/216311481960/picture
のようなURL呼び出しをすると、レスポンスにプロフィール画像のデータ自体が返ってきてしまっていた（正確にはステータスコード302で画像のURLにリダイレクトされていた）のですが、
https://graph.facebook.com/216311481960/picture?redirect=false
のように、"redirect=false"のパラメータを付けると、画像のURLが取得出来るように変更されていました。
その場合、以下のようなJSON形式でレスポンスが取得出来ます。
{
"data": {
"url": "https://fbcdn-profile-a.akamaihd.net/hprofile-ak-ash4/373042_216311481960_1625208104_q.jpg",
"is_silhouette": false
}
}
callbackパラメータを付けるとJSONPな感じになる。
redirectパラメータだけではなく、callbackパラメータでJSONPなレスポンスを返すのにも対応しているようです。
callbackパラメータに関数名を渡すと、"redirect=false"の指定がなくても画像URLを返す動作になるっぽい。
https://graph.facebook.com/216311481960/picture?callback=hoge
/**/ hoge({ "data": { "url": "https://fbcdn-profile-a.akamaihd.net/hprofile-ak-ash4/373042_216311481960_1625208104_q.jpg", "is_silhouette": false } });
※追記: callbackパラメータ自体はGraph API全般で動作するようです…ドキュメントのどこに書いてあるのだろう…。
fieldsパラメータを指定する方式でもURLは取得出来る。但しデータ形式がちょっと違う
Facebook Graph APIでプロフィール画像のURLを取得する方法 - でぶぬる日記
のエントリで紹介しているように、「ユーザ情報を取得するAPIに対してfieldsパラメータを指定する方法」でも、引き続きURLを取得することは出来るようです。
https://graph.facebook.com/216311481960?fields=picture,name
但し、以前とはJSONデータの形式がちょっぴり変わっている。
{
"name": "Bill Gates",
"id": "216311481960",
"picture": {
"data": {
"url": "http://profile.ak.fbcdn.net/hprofile-ak-ash4/373042_216311481960_1625208104_q.jpg",
"is_silhouette": false
}
}
}
"picture"の直下にJSONデータ（以前はURL文字列）が来るようになっているので注意が必要。
Facebookアプリのトークンを使っている場合は、古い動作に戻すことも可能（但し2013/2/6まで限定）
Facebookアプリのアクセストークンを使ってAPIを呼び出している場合は、これらの動作を以前のものに戻すことが出来るとのこと。
Facebook Developersのアプリ管理画面から[Apps]→[アプリ名]→[Advanced]を開き、[Migrations]の[Picture As Dictionary]を"Disabled"に変更する。
但しこの設定も移行期間用の対処ということで、2013/2/6までには使用できなくなるとのことで、根本的にFacebookアプリ側での修正が必要になるようです。
アクセストークンを使っていない場合は…既に新しい動作になってしまっているようなので諦めて大至急プログラムを直しましょう…。
コンビのディアクラッセというベビーカーを色々悩んで購入したのでその経緯について書く
正月ボケが抜けず更新が滞っておりました。どうもこんにちは。
昨年末の余韻を引き摺っているわけではないのですが、今回も子育て関連のお話です。
この前のエントリで「なかなかベビーカーが買えずに困っている」という話をしたのですが、ついに購入しました！
座席の位置が高く、下部のカゴに結構荷物を入れられます。
折り畳むとそこそこコンパクトになります。
コンビ ホワイトレーベル ディアクラッセ auto4cas EG YB-500 ノーブルアイビー GR
この車種を選ぶに至るまでに色々と夫婦で悩んでいたので、今回はその経緯について書きたいと思います。
軽いほうがよい
今回ベビーカーを購入する上で最大の検討ポイントとなったのは「ベビーカーの重量」です。
というのも、私が住んでいるのはマンションの3階。しかもエレベータはなし。
夫婦が二人とも揃っている場合は特に問題ないのですが、例えば妻が一人で子供をベビーカーに乗せて出かけるためには、子供とベビーカーを片手ずつに抱えて1階まで下りる必要があります。
それを考えると「妻が片手で持てる程度には軽い必要がある」というわけです。
重いほうが安定性・機能性は高い
しかし（当然と言えば当然なのですが）、便利な機能が増えれば増えるほど、ベビーカーの重量は増えていきます。そこが悩みどころ。
今回購入したコンビのディアクラッセの各モデルを見ても、フル機能が揃っている最上位モデルの本体重量はなんと8kgオーバーもあります。
アカチャンホンポで実物も触ってきたのですが確かに重く、男の私でも多少取り回しに面倒さを感じるくらいでした。
但し実際に広げて押してみると、重量があるほうが走行は安定している印象を受けました。ベビーカーを担いで運ぶことが少ない家庭であれば、重量のあるものを選ぶのが良いかとは思います。
「安定性／機能性」と「軽さ」のトレードオフ
結局のところ
- 本体重量が軽いものを選べば走行は不安定になるし機能も少ない
- 機能が多いものを選べば本体重量は重くなる
ということは明らかで、妻と二人で相当悩んだのですが、どうしても外せない要件を最低限満たした上で可能な限り軽量なものを購入しようという結論に至りました。
要件1. 大きいタイヤ
レンタルで使っていたベビーカーは、タイヤの大きさが小さめのものでした。
タイヤが小さいとベビーカー本体の重量も軽くなり、手で持ち運ぶのが簡単になります。
しかし、ちょっとした段差でも引っ掛かりやすくなったり、舗装してある道路の上でもガタガタ揺れたりして、赤ちゃんの機嫌を損ねる原因となります。
我が家の子供は特に振動に敏感で、少し大きく揺れただけでもすぐに泣きだしてしまうため、多少の軽さを捨ててでも「大きいタイヤ」は優先しておきたいところでした。
要件2. 前後輪とも回転出来る
例えば、同じコンビの軽量モデル、メチャカルファーストの場合、方向転換用に回転する車輪が片側固定、つまりハンドルが背面に向いているときの前輪となる2つの車輪のみとなっています。
そのため、ハンドルを対面式に切り替えると、前輪が回転せず、その代わりに後輪の向きを変えて左右に曲がるような形になってしまいます。
こちら、実際に押してみないと使いづらさはなかなかわかりづらいのですが、ハンドルを左右に不自然に切って曲がる形となってしまうため、微妙に取り回しづらい。
一方、コンビベビーカーの重量モデルの多くでは、前輪後輪の4輪全てが左右に回転するようになっています。
しかもそれだけではなく、ハンドルを切り替えた向きに合わせて後輪に相当する2輪が自動で固定されるという素晴らしい仕様。
子供の機嫌や太陽の向きに合わせて、背面／対面を臨機応変に使い分けることを想定していたので、この機能は是非とも欲しいものでした。
要件3. 他の機能はどうでもいい
それ以外にも、ディアクラッセの上位機種では幌の枚数が多かったり／足カバーが付いていたり／背中の部分がメッシュになっていたり、などなど色々な機能が付いているのですが、これらの全てが「出来るだけ軽く」という要件を上回るものではなかったため、すっぱりと切り捨てました。
まとめ
以上を検討した結果、コンビ ディアクラッセの一番下のモデルが最もニーズに合っているという結論に至りました。
重量も（軽量モデルには遠く及ばないのですが）本体重量6.7kg。店頭で担いでみたところ妻でもギリギリ許容出来る程度の重さとのことで、購入を決定。
紆余曲折はありましたが、やっと我が家でもベビーカーを購入出来たので、積極的にいろいろなところに外出していこうと思います！
乗せると高頻度で泣き出すのは相変わらずなのですけどね。。。困った。。。
年の暮れの間際にオチもなく淡々と2012年を振り返る
はじめに
どうもこんにちは、私です。今年も残すところあとわずかとなってきましたね。
Advent Calendarで多少は文章を書くのにも慣れてきたので、調子に乗って今年の総括エントリでも書いてみようかと思います。
今回はそこそこITエンジニア視点なのでご安心ください。ただしオチはないです。
なんやかんやで公開し忘れていた、時期外れの紅葉の写真とともにお送りします。
受託開発はダンピング極まってきてる感
これは太古の昔からずーーーっと言われてきていることではあるのですが。
受託のお仕事自体が減っているわけではなく、体感的には引き合いはむしろ増えているイメージもあるのですが、とにかく費用面で苦しい。まさに血の海です。「こんな単価だとまともにペイ出来るのはオフショアばりばりの業者くらいなんだろうなー」と思いつつも、そういう業者が平気な顔して仕事をかっさらっていく現状を眺めていると、零細企業の受託プログラマとして活動していくことへのある種の限界を実感してしまうこともしょっちゅう。
この手のレッドオーシャンな案件は無視してしまって、もう少し楽に稼げる案件を取ってくればいいじゃないかとは思うのですが、営業担当としてはとにかく楽に売上が上がる案件を狙いがちで、そのような見積依頼がバンバン飛んできておりました。それに合わせ、個人的には取りに行くつもりもないし、正論並べれば十中八九取れない案件の見積もりを消化試合的にこなしていくことが多かったのは、今年一番の反省事項ではあります。
そのようなダンピングの現状を踏まえ、「営業担当が売り込みやすいパッケージを企画して、提案型の営業を進めていこう」という前向きな風潮も一時期はあったのですが、「売れるものがあればぜひとも欲しいけど、考えるのは面倒くさいよね」的な雰囲気が周囲に蔓延していたということもあり、なかなかうまく回っていなかったというのは正直なところであります。ここらへんをなんとかしていきたくはあるのですが、来年以降運用作業諸々が降ってくることが確定しているため、あまり積極的な動きは出来なさそう、というかもう勘弁して下さいほんと。
会社もそんな状況なので、「気晴らしついでに副業のお小遣い稼ぎでも始めようかな〜」と思ったりなどして、某お仕事募集サイトを眺めていると「ポータルサイトの開発、時給1,000円」とか「スマホアプリ開発、時給1,200円」とかいった激安案件が平気でゴロゴロと転がっています。「このような案件を受注するくらいだったらコンビニの深夜バイトでも黙ってやっていたほうが色々な面で幸せになれるのではないか」と思いつつ、こんな案件でもホイホイ乗っちゃう学生バイトノリのプログラマが世間にはたくさん存在するということを想像しただけで、目から汗が止まらなくなってきます。
Facebookアプリは結局あまり来なかった
昨年あたりから「これからはFacebookがくる！」などと何処かから声が聞こえた関係で、Facebookアプリの案件にも何件か取り組んできたのですが、いずれもキャンペーン用の単発モノアプリで、「結局大したビッグウェーブは来なかったなぁ…」というのが正直な感想です。
Facebookアプリ開発のノウハウはそれなりに蓄積していたのと、「Facebookアプリ作ります」という看板を出していた会社は（想像していたよりも）少なかったということもあり、もう少し引き合いが来てくれたらよかったのですが、まぁそんなことをいまさら言ってもしょうがないですね。
とはいえ、「〜したついでにFacebookのウォールに投稿する機能」みたいなどうしようもない系のおまけ機能を実装することは増えているので面倒な世の中になった・・・じゃなくて喜ばしい限りです。はい。
スマホアプリ受託ももうダメかもしれない
スマートフォンアプリの開発も、今年に入って急激に引き合いが増えてきている一方、納期面での無茶な要求が多かったりとか、費用面での旨味が少なかったりとか、色々と苦慮した一年ではありました。こちらもレッドオーシャン。何処も彼処もスマホアプリ作りすぎですよほんと。
iPhoneアプリとAndroidアプリ、同時に作りたいけれども圧倒的に予算が足りないので、TitaniumやらPhoneGapやらを使うことが提案前から前提になっていたりするのが死亡フラグのはじまり。で、もちろんその程度であれば良いのですが、機能一覧だけ渡されて「コレ全部一ヶ月で作ってね♡」的な軽いノリでお願いされるケースが多すぎて、見積もりの段階で軽く吐血しかけるのが常です。
iPadなどのタブレットを、業務用の端末として活用するシーンはこれからもう少しは増えてくる（iOS6のアクセスガイド機能も活用出来るし）とは思うので、それ用のアプリ開発という面ではもうワンチャンあるかもしれません。けどさほど難しい思い付きでもないので、おそらくツーチャン以上はないだろういうのが実感です。残りワンチャンを活かしてもう少しだけ稼がせていきたいとは思います。
来年は何をしよう
ひとえにプログラマ的な視点から申し上げると、端末の断片化が激しいAndroidアプリ開発はヤバいフラグが満載だなぁというのをつくづく感じました。個人でアプリを開発するには非常に自由なプラットフォームであるとは思うのですが、受託案件でAndroidアプリを（成果物として許容されるレベルで）真面目に仕上げようとすると検証の手間がかかりすぎる。「カメラを使ったアプリは死亡フラグ」とかはよく言われてますけど、カメラ機能を封じたらわりと何も作れないじゃないっすかねぇほんと…。受託でやるなら是非ともiOSアプリがよいです。いやほんと。UIの作り込みの手間も少ないですし。
サーバサイドプログラミングでは、Ruby界隈がわりと幸せにプログラミング出来る環境が揃ってはいて、数年前から現在に至るまで積極的に採用し続けてはいるのですが、（ネット上でもどなたかが仰っていたような記憶があるのですが）Railsの「最新版が安定版だけど、全てのバージョンがベータ版」みたいなノリは本当になんとかならないものかなぁ、とは常々思っています。たとえばAsset Pipeline、お前のことだ。
一方「Ruby使えます」というプログラマはなかなか見つからないというのが現実なので、PHPも使い続けていく必要はあります。というよりむしろPHPがメインになっていきそうではあります。自分一人でRubyで実装しても、他の誰にもメンテナンスお願い出来ないのではあまりにもしんどいですからね。
それ以外でも、サーバサイドJavaScriptだったりとか、いくつか新しい技術にも興味があったりはするのですが、顧客から見える最終的なアウトプットは依然として「Webのシステム」でしかないということもあり、新しい稼ぎ口になるかと言われると現状はまだまだ微妙なのではないか、とは思っています。稼ぐ為の技術習得であればいくらでもどんとこいな構えなのですが、単に楽しいだけの技術となるとなかなか学習のモチベーションが沸いてこないのですよね正直。ゲームしたりとか写真撮ったりとか将棋の勉強したりとか子供の面倒みたりとか、技術以外にも楽しいことをたくさん知ってしまった今となっては、限られた時間を有効的に使っていきたいですね。え？関数型言語？大学時代にスパルタで教え込まれたせいでだいぶ懲りました。勘弁して下さい。
そもそも、この業界で仕事を始めてはや10年に到達しようとしているのですが、年数を重ねるに従いどんどん人間嫌いが悪化している感があり、受託のお仕事もそろそろ潮時かもなぁと薄々感じている今日この頃ではあります。仕事を選り好みできないのであれば大企業のSEを辞めた意味が全くないので、今後も積極的に選り好みしていきたいと思います。人間に接しなくて済むのであれば大抵の仕事は出来そうな気はするので、ぜひともよろしくお願いいたします。
