職業プログラマの休日出勤

職業プログラマによる日曜自宅プログラミングや思考実験の成果たち。リアル休日出勤が発生すると更新が滞りがちになる。記事の内容は個人の意見であり、所属している（いた）組織の意見ではない。

Macを買い換えた

Macintosh

AppleWatchなど欲しいものは山ほどあるし、それらは我々のライフスタイルを変えるだけの十分な力を持っている。
だが、自分が日常生活の中で一番長い時間触れているのは確実にMacであり、2番目はWindows7機であるから、これらに資金を集中させた方が自分の生産性は上がるはずである、と判断した。

AppleWatchもMacも、欲しいもの全部買っちゃえよ！という声が聞こえたような気もするが、無い袖は振れない。

今まで使っていたもの

今までは MacBook Pro Early 2011 を使っていた。最初にthunderboltを搭載したモデルだ。
現行の非RetinaなMBPと同様に、13インチモデルではあるが重量は2.0kgを超える。
Australia の滞在中はほぼ常に持ち歩いていて、 Waterfall や Singleton などにも同行した。

2014年夏に内蔵HDDをSSDへ換装していたため寿命はまだまだ先だと思っていたが、新しいものは欲しくなったときが買い時。

用途

  • Webブラウジングやメールなど、一般的なもの
  • サーバ管理
  • iOS / Mac アプリ開発（Xcode）
  • Webアプリ開発（いろいろ使う）
  • 音声データの加工（初級）
  • 楽譜の作成

買い換えを考えるに至った理由

  • 2.0kg超というのはさすがに重いなーと感じるようになってきた。
  • 2基あるUSB2.0ポートのうちの1つが故障してしまっている。
  • 楽譜作成ソフトや音声データ加工ソフトが Yosemite に対応しているかどうか不明であったことから、OS は Mavericks のままにしていた。さすがに不都合が出てきたため Yosemite に移行したかった。しかし Mac が1台しか無い状況下で Yosemite に移行するのは危険過ぎるから、新しいハードウェアを導入して Yosemite での動作確認をしたかった。
  • MBP13" の画面に顔を近づけての長時間の作業につらさを感じるようになってきた。

これから使うもの

2台所有することにした。

1. Mac mini Late 2014 竹
2. MacBook Air 11" Early 2014

Mac mini がメインのマシン、MBAが外出時用、という位置付けである。
MBA は整備済み製品のものが税抜き7万円台で出ているのを偶然見つけたため、飛びついた。外出先での用途をサーバ管理と一般用途に絞ったため、デフォルトのスペックでも問題無いと判断した。Thunderbolt2 である必要も無いため、Early 2015 モデルにする必要は無かった。

複数台を使い分けるのは何かと不便だよ、という話は非常によく耳にする。しかし、それは2台の用途の重複部分が大きく膨らんでいる場合での話であって、上記のような用途の構成を取るのであれば大きな問題は無いはずである。そう信じたい。

他に候補に上がった構成

MBP Retina Early 2015 の1台に絞る案

当初はこの構成を最有力候補として考えていた。
しかし、

  • SSD を 512GB 以上にするには13"モデルの最上位機種を買わなければならない
  • HDD/SSD の交換すらできない端末に20万円超のお金を出すことには抵抗がある

と考えて購入に踏み切れずにいた。
高いお金を払うからには、その端末は長い期間使い続けたい。使い続けるにはやはりメモリとストレージの２種類は交換可能じゃないと安心して使えない。

自宅の据え置き機を iMac 21" にする案

机の上がスッキリするのは非常に大きな魅力であると感じて候補に入れていた。
しかし、 iMac 21" Early 2015 竹モデルを 16GB RAM / 1TB Fusion Drive 構成にすると税抜きで18万円弱。部品の交換ができないためMBPと同じ悩みを抱えてしまう。しかし、これはギリギリで許容できる範囲。
致命的なのは、カスタマイズすると納期が3週間ほど伸びてしまう点。これは物理的なアップルストアに行っても変わらない。もはや、店頭でカスタマイズできるような構造ではない、とのことだった。昔のマシンは店頭でメモリ変えたりやってくれてたのに、非常に残念である。

自宅の据え置き機を Mac Pro にする案

熱心な同僚氏から強く推奨されたが、さすがに GPU は2個もいらない、ということで却下。

外出時用端末を 新MacBook にする案

今から注文しても 3-5週間待ち とのことだったので断念。


（自分用メモ）自分がこれまでに使ってきたMacの覚え書き

（おまけ）廃棄するとき、どうするか？

本文中で言及したように、最近の Mac は HDD/SSD が交換不可能になっているものが大半を占める。
数年後、このようなマシンを廃棄するとき、どうやって廃棄すれば良いのだろうか？
何を心配しているかと言うと、HDD/SSD に残されたデータの機密性である。

そのマシンが稼働可能な状態であれば、Command-R 起動などでディスクユーティリティを使って、適切なセキュリティオプションを指定した上でボリュームを消去すれば良い。
ところが、例えばそのマシンの電源系が死んでしまった場合、どうやって廃棄すれば良いのか？
古いMacであればストレージだけ取り出して初期化なり物理的に破壊すれば良かったが、最近のものはそうも行かない。
Mac本体丸ごと金槌で破壊するのか？ いくら廃棄対象のMacとはいえそんな行動には移りたくない。魂が許さない。

そういった破壊活動が最小限にとどまるような機器を購入するというのが、現時点でのベストプラクティスなのではないかと考えている。

「急ぐ」を科学する

その他

日常的に使われる「急ぐ」という言葉。

「急いで」「至急」「ASAP」(As Soon As Possible : 可能な限り早く) …これらは人から言われてイラっとくる言葉の一部ではありますが、急いでと言われたら、実際に素早く目標へ到達できていることも結構あるものです。
でも、ちょっと考えてみて下さい。人間の日常生活の所作や仕事などが、たかが「意識する」程度のことでそんなに速くなるのでしょうか？ 気をつけるだけで速くなるというのなら、精神論だけ振りかざしてる連中のドヤ顔がもっと誇らしげになっていってしまうではありませんか。そんな様子はもう二度と見たくはありません。

「急いで」と言われたとき、あるいは自ら「急ぐよ」と言ったとき、我々の行動には一体どのような変化が起きるのか。
そういった考察を通して、どのような条件が整っていれば急ぐことができるのか解明していこうではありませんか！

例１：目的地へ「急ぐ」

はじめに、恐らく最も身近な例であろう、移動中に目的地へ急ぐときのことを考えてみましょう。

徒歩で移動中なのであれば、歩く速度を上昇させるか、走ったりすることがあります。普段使わないエネルギーを消費して急ぎます。
電車で移動中なのであれば、「スピード上げてよ」と心の中で思うしかありません。駅などで稀に、車掌さんや運転士さんに向かって「はよ発車せいやボケが」と怒鳴る生物が存在したりしますが、これは逆効果でしかありません。電車の運行に必要な係員という限りある資源がその愚か者のために浪費されてしまうからです。
自動車で移動中なのであれば、徒歩の時と同じように速度を上げるというのが一般的な手法ですが、事故を起こす／起こされる危険性が高まったり、速度制限に抵触するリスクが高まります。速度を上げ過ぎれば部品の消耗を早めることだってあるかもしれません。

また、どの移動手段でも共通して利用できる手段として、近道したり、より時間距離の短いルートを採用するというものがあります。これの実現には知識や情報が必要ですし、そもそもそのような手段は存在しないという場合もあります。

もちろん、他の移動手段に切り替えることを視野に入れることもありますし、寄り道したり素晴らしい景色を見たりするのを諦めることで急ぐことだってできます。

例２：「急いで」文章を書く

次に、急いで文章を書くときのことを考えてみましょう。

急いで書いたときに誤字脱字が多くなるという経験は多くの方が持っていることでしょう。場合によっては文章の中で辻褄が合わなかったり、説明になっていなかったりということだって発生するでしょう。他にも、必要な説明が丸ごと抜け落ちていたり、方言が混入していたりといったこともあります。まるで、どこかのブログの記事のようですね。（どこのブログだろう…。あれ、耳が痛いゾ…）

なぜ、このようなことが起きるのでしょうか？
一番大きな原因は、確認する時間、読み返す時間を削ってしまうからではないかと考えています。その次に大きなのは、ゴールを急ぐあまり、アウトラインをきちんと固める前に文章を書き始めるからではないでしょうか。
このあたり（原因の数々）については人それぞれの文章の書き方によるところは大きいでしょうけれども、急いで書いた文章の問題点というのは多くの人に共通しているように見えるものです。
いずれにしても、我々は文章の品質が低下するリスクを背負うことで、文章を速く書くことができるようになるのです。

「急ぐ」とはどういうことか

たった２つの例から結論を導き出すのはかなり乱暴かもしれませんが、急ぐのに必要なものとして次のようなものが考えられます。

  • 当初の想定よりもコスト（エネルギーや資金など）を費やす
  • 品質を下げる / 目標の一部分を諦める
  • 他の目標を諦めたり後回しにする
  • リスクを背負う
  • そもそも目的を達成する為の手段を変更する（これは有効ではない場合がある）

これらは代表的な例であって他にも色々あるでしょうけれども、こういう行動を取ってこそ、人間は急ぐことが可能になるのです。「急ごう」と思ったとき、意識しているから速くなるのではなく、これらの行動を取っているからこそ速くなるのです。

また、走る場合も文章を書く場合も、いずれも訓練を重ねることによって速度を上げることは可能です（限界はあるでしょうけれども）。実際には速度が上がる効果よりも、急ぐときに背負わなければならないコストやリスクを低減させる効果の方がずっと大きいでしょう。走る場合であれば、訓練することによってより少ないエネルギーで走ることができますし、文章を書く場合であれば、より整合性を取り易い構築法を訓練で身につけることができます。
そうやって日頃から備えておいた上で、急がなければならない状況下で力を発揮することは大変望ましいものです。

残念なのは、急がなければならない状況というのは大抵、こういう準備が整う前にやってくるということです。

急ぐチーム

ここまでは個人の活動を急ぐ際の話をしてきました。
話は変わって、次は組織の話をしたいと思います。

急ぐときに取り得る選択肢というのはほぼ個人のときと同じなのですが、組織の場合は考えなければならないことが１つ増えます。
それは、急ぐ手段に矛盾が生じにくいようにしなければならない、ということです。

例えば、「品質を下げて急ぐ」ことと「追加人員や残業代などの費用を追加負担して急ぐ」こととは、上手くやらなければ衝突してしまいます。
一見すると矛盾すること無く運用できそうな気もしますが、品質下げる派の出す見積（品質を下げる前提で少ない作業時間を見積もる）を他派の人が見て誤解（高い品質のまま少ない作業時間で実現可能であると思い込む）して破滅へ向かって行く、といったことは頻繁に発生するものです。

これは急ぐときに限った話ではなく集団行動では常につきまとう問題ではありますが、急がなければならないような状況でこそ、特に気を付けなければならないのです。

また、「チーム」「組織」といった表現を使っていますが、同じことは発注者・受注者の関係にもあてはまります。当事者はチームを組んでいるという意識を持っていないことも多いでしょうけれども、実際の動きはチームとしての動きになるのです。


さいごに

この長い文章を最後まで読んで下さった皆さん、そんなに暇ならもっと本業に時間を費やすことによって仕事を急ぐ必要も無くなるのではないでしょうか？

…というのは冗談で、こういった考察が皆さんの日常生活の改善につながれば幸いです。

急がば回れという言葉もありますが、回るだけなら猿でもできます。どう回るのかは何通りも考えられるものです。もちろん回らない方が良いことだってあるでしょう。
より良い道を選択できるようになりたいものです。

Cocoa勉強会関西 #cocoa_kansai でSVGの話をしました

iOS(iPhone/iPad) SVG Macintosh

おおよそ２ヶ月に１回のペースで開催されている Mac / iOS 開発関連の勉強会「Cocoa勉強会関西」第60回で、SVGの話をさせて頂きました。

内容はこのスライドをご覧下さい。しゃべった内容は、このスライドから容易に想像できるはず！

この話題を選択したキッカケ

Mac / iOS アプリいずれも、カスタムのUI部品全てをSVGで表現することができたらとても幸せになれるだろうなーと妄想していたのがキッカケです。その妄想に至るにあたっては、某Qえび先生の発言の影響を強く受けています。

頂いた質問その１：パフォーマンスはどうなの？

検証はしていないけど、XMLパースしたりとか何だとかやっている訳ですから、相当遅いはずです。ただ、ViewControllerのviewDidLoadとかで１回処理するだけであれば全然耐えられる範囲なのかなというのがテストアプリを作ってて感じたことです。
ボタンの TouchDown 時に凹ませる表示とかに留まらない、もっと動きのある表示変化で使うのは時期尚早ではないかと思います。

頂いた質問その２：他にもベクター画像を表示させる仕組みはあるのに、何故SVGなの？

テキストエディタで書けるから、というのが最大の強みです。
PostScriptを書いてPDFを作ってそれを表示させるという選択肢もありますが、まさかこのご時世にPostScriptを手で書く人は居ないですよね？！？！（うっ、耳が痛い…。。）

頂いた質問その３：SVGを描くツール、何が良いの？

会場でお答えした回答と少し異なりますが、

街の声




関連書籍

昨年12月の記事

の関連書籍欄をご覧下さい。SVG関連の良い本が揃ってますよ。

尊敬する人

その他

尊敬する人は誰ですか？どんな人ですか？

そんな質問は、日々いろんなところで飛び交っていることでしょう。
個人的には、その質問に対する回答をお伺いすることには本当に全く価値が無いと考えています。しかし！その人物を尊敬するに至った過程を教えて頂くことには非常に大きな価値があると考えます。その思考の過程からその人（回答者）の価値観を知ることができるからです。

あなたが尊敬する人物は、どんな人物ですか？

  • 偉業を成し遂げた人物
  • 名言を遺した or 発信した人物
  • 素晴らしい人格を備えた人物

一般的には、こういった人物が挙げられるのではないかなと思います。

筆者も例外ではなく、尊敬する人は？という問いに対して真っ先に思い浮かべるのは、やはり偉業を成し遂げた人物です。いろんな人物が頭に思い浮かびますが、その中でも特にこの人！というのは「自分が実際に挑戦したけれども成し遂げることができなかったことを成し遂げた人物」です。

偉業を成し遂げた人、もちろん尊敬しています。でも、自分にはできなかったことを成し遂げた人って、普通の気持ちとは異なる、もっと大きな尊敬の念を覚えること、ありませんか？ たとえその「偉業」の凄さが小さいものであったとしても、自分には不可能だったことをやってるんです。「本気でやっていればできていた」事項であればその感情が高まることはそんなにないかもしれませんが、本気で取り組んで失敗した事項では特別です。


じゃあお前が本気で取り組んで失敗したことって何だよ？という質問は来ると思うので、先に答えておきます。
もちろん複数ある訳ですが、その中の一つを紹介しておきましょう。
それは、テキストエディタを作ることです。テキストエディタと言えば、コンピュータを触る際に最も長い時間触れるものであって、それはそのまま人生の中で最も長い時間触れるものであるとも言えます。利用者のこだわりも出易く、テキストエディタを巡る言い争いは「宗教戦争」と呼ばれることもあるくらいです。人間たるもの、自分の好みのテキストエディタは持っておかなければなりません。好みのものが無ければ、自分で作るのが筋です。
（その思考が正しいかどうかは置いときつつ）そう思って、もう16年ほど昔のことではありますが、Mac上で動作するGUIのテキストエディタを自力で開発しようとしていたことがありました。当時、Mac OS 8 の頃はMacアプリの開発に必要な情報がネット上に必転がっているということはほとんど無く、大変つらいものでした。それだけではなく、処理の複雑さも、それまでに組んできたいかなるプログラムとも比較にならないものでした。

世の中で言及される歴史上の人物の数々の偉業に比べれば、テキストエディタを作ることなんて本当にちっぽけなものです。でも、自分にできなかったことというのは、自分にとっては非常に大きなことなのです。


世間の評価に左右されずに、自分の価値観をしっかりと持つことって大事なことだと思います（と自画自賛してみるテスト）。
尊敬する人物の偉業の大小は、その人の良し悪しを計るものさしには成り得ないものです。

手入力のSVGでクリスマスツリーを描こう☆

SVG

この記事は SVG Advent Calendar 2014 の24日目の記事です。前の日は SVG画像にRDFでメタ情報を記述する：CCライセンスや派生元作品など - 聴く耳を持たない(片方しか) でした。

このアドベントカレンダー、途中で飛んでしまっている箇所もありましたが、いよいよ千秋楽に突入しようとしております。皆さん、これまでに登場したSVGの技術、一通り試されましたでしょうか？ 楽しいものから役に立つもの、そして私達の人生の質を変えてくれるものまで、本当に様々な記事が投稿されましたね。

さて、この記事では、クリスマスツリーを手入力のSVGで描いてみたいと思います。例によって本文にはSVGのコードが表示されますが、ここまでSVGアドベントカレンダーを書いたり読んだりしてきた皆さんなら、心のキャンバスにSVGをレンダリングさせることができますよね？
ちょっと練習してみましょうか。

<?xml version="1.0"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
<svg xmlns="http://www.w3.org/2000/svg" version="1.1" width="320" height="240" viewBox="0 0 320 240">
	<rect stroke="none" fill="#202030" x="0" y="0" width="320" height="240"/>
</svg>

そう、そうです、心の眼でSVGのタグを見つめるのです…。
暗い未来、もとい、暗い矩形が見えてきました？ いい調子ですね！！

皆さんが本気で心眼を使うのなら、私だって本気でSVGタグを打ち込みましょう。
下書き無しのぶっつけ本番です！！
クリスマスイブの日、午後10時過ぎに書き始めました。日付が変わるまでに公開できるかな？？
この段落の時点で10時20分です。ちょっと不安ですが…

キャンバス

クリスマスツリーを描く訳ですから、当然、縦長のキャンバスを用意しないといけませんね。
私の心の中にあるクリスマスツリーは、縦横比が 2:1 です。
幅は300px程度にしておくと幸せになれる気がしてるので、ここでは横幅300px, 高さ600pxとしておきましょう。簡単にするために、viewBoxの幅と高さも同じにしておきましょうか。
ついでに、背景も描きましょう。背景は銀世界、 #f0f0f3 くらいの色が良いですかね。

ここまで登場した話からSVGを書くと、次のようになります。

<?xml version="1.0"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
<svg xmlns="http://www.w3.org/2000/svg" version="1.1" width="300" height="600" viewBox="0 0 300 600">
	<rect stroke="none" fill="#f0f0f3" x="0" y="0" width="300" height="600"/>
</svg>

まだ殺風景ですね。でも、これから良いツリーになりますよ、きっと！！

幹

葉っぱの部分やら電飾やらがクリスマスツリーの根幹であると思い込んでいる人は多いかもしれませんが、それは大きな間違いです。クリスマスツリーの根幹をなすのは、文字通り幹なのです。
どっしりと構えるような形状にしつつ、上にいくほど細くなるように3次のベジェ曲線を描きましょう。3次のベジェ曲線と言えば、path の C コマンドですね。
木の幹の色、明度はそんなに高くなく、赤が一番強くて、緑がその次に強い、という色にすると良い感じがしますね。ここでは #806030 としておきましょう。

こうなります。

<?xml version="1.0"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
<svg xmlns="http://www.w3.org/2000/svg" version="1.1" width="300" height="600" viewBox="0 0 300 600">
	<rect stroke="none" fill="#f0f0f3" x="0" y="0" width="300" height="600"/>
	<path stroke="none" fill="#806030" d="M120,590 C120,400 120,180 150,180 C180,180 180,400 180,590 Z"/>
</svg>

卑猥なものに見えてしまった皆さんの心は、汚れています。

葉っぱ

流石にこの短時間では1枚1枚書くのも難しいので、大雑把に書いてしまいましょう。
色は、木の幹と同様に明度はそれほど高くなく、緑にちょっと青を足しただけの色にしましょうか。 #207a4c くらいがいいですね。
形は、基本的には三角形なんですが、頂点は尖らせずに、円弧を用いて丸みを持たせるのが良いですね。円弧と言えば、path の A コマンドを使うのが良いですね。

こうなります。

<?xml version="1.0"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
<svg xmlns="http://www.w3.org/2000/svg" version="1.1" width="300" height="600" viewBox="0 0 300 600">
	<rect stroke="none" fill="#f0f0f3" x="0" y="0" width="300" height="600"/>
	<path stroke="none" fill="#806030" d="M120,590 C120,400 120,180 150,180 C180,180 180,400 180,590 Z"/>
	<path stroke="none" fill="#207a4c" d="M20,570 A10,10 0 0 0 20,580 H280 A10,10 0 0 0 280,570 L155,140 A7,7 0 0 0 145,140 Z"/>
</svg>

なかなか良いツリーっぽくなってきましたね！！！！！１１１１

装飾

これだと単なる木ですので、クリスマスらしい装飾を施したいと思います。装飾なので、ちりばめたいですよね？そんなときに使うのが use タグです。部品の再利用ができるんですよ！！

装飾の構成要素は、★印にしましょうか。 use タグを使う際には平行移動させるので、簡単にするために、座標平面の原点を中心とする半径10の円周上の、0°、72°、144°、216°、288°、の5点を上手い具合につないで★印にしましょう。そんなに適当に線を引いても★印作れるの？と思ったあなた、fill-rule の仕様 を眺めておいてくださいね。

さすがに三角関数を暗算するほどには感覚が研ぎ澄まされているとは言い難く、計算はGoogle先生にお願いすることにしましょう。「sin 144deg」で検索すると度数法で三角関数の計算をしてくれるんですよ。知ってました？
色は黄色、 #ffff60 くらいがいいですね。
あとは、 use タグを使う際に xlink 名前空間を使う必要があるので、名前空間の宣言も svg タグに加えておく必要がありますね。

こうなります。

<?xml version="1.0"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" version="1.1" width="300" height="600" viewBox="0 0 300 600">
	<rect stroke="none" fill="#f0f0f3" x="0" y="0" width="300" height="600"/>
	<path stroke="none" fill="#806030" d="M120,590 C120,400 120,180 150,180 C180,180 180,400 180,590 Z"/>
	<path stroke="none" fill="#207a4c" d="M20,570 A10,10 0 0 0 20,580 H280 A10,10 0 0 0 280,570 L155,140 A7,7 0 0 0 145,140 Z"/>
	<defs>
		<path id="christmas-star" stroke="none" fill="#ffff80" d="M10,0 L-8.09,5.88 L3.09,-9.51 L3.09,9.51 L-8.09,-5.88 Z"/>
	</defs>
	<use xlink:href="#christmas-star" transform="translate(180, 50)"/>
	<use xlink:href="#christmas-star" transform="translate(100,100)"/>
	<use xlink:href="#christmas-star" transform="translate(220,150)"/>
	<use xlink:href="#christmas-star" transform="translate(270,200)"/>
	<use xlink:href="#christmas-star" transform="translate(170,250)"/>
	<use xlink:href="#christmas-star" transform="translate(150,300)"/>
	<use xlink:href="#christmas-star" transform="translate(100,350)"/>
	<use xlink:href="#christmas-star" transform="translate(210,400)"/>
	<use xlink:href="#christmas-star" transform="translate( 70,450)"/>
	<use xlink:href="#christmas-star" transform="translate(230,500)"/>
	<use xlink:href="#christmas-star" transform="translate(180,550)"/>
</svg>

描いた結果

さあ、ここまでタグを手打ちしてきた結果、皆さんの心のキャンバスには美しいクリスマスツリーが描かれていますか？
ここらへんで、答え合わせをしておきましょうかね。
答えは、こうですよ！

リア充爆発


おや、クリスマスツリーの中央に、何か黒くて小さな汚れが見えますね…。
もしかして、私の心が汚れているだけなのでしょうか？
皆さんには、見えますか？？