# 128: Alien Sushi
128: Alien Sushi
Guest
毎度おなじみのhakさん。
低レイヤに強いエンジニアとして、今回はハードウェアを絡めた最適化の話があり、非常に有益な回だった。
様式美と言われつつある例え祭りも、安定のパフォーマンス。
Wikipedia: Rebuild
RebuildのWikipediaができたという話。見てみたけど、パッと見た感じ宮川さんのいう間違っている項目が結構ある、というのが発見できなかった。
宮川さんは本人のページもあって、そっちの話かもしれないけど、どの辺が間違っているのかはやっぱり興味があるかな。
まぁ、Rebuildについては特に厳密さが求められる項目というわけじゃないだろうから、宣伝の1つとして面白いページになればいいな。
Apple
決算が出たけど、上昇率が低下したということで株価が少し下がったらしい。
今度3/15に新しいiPhone 5SE?が出るという噂もあるし、iPad Air 3とかもほぼ決まりのようだけど、どうだろう。
Macについてのリニューアルもあるといいかな、個人的には。
iOS 9.3
複数ユーザの対応が、教育向けに入るらしい。
もちろん教育向けに便利なのはわかるけど、一般ユーザ向けにも対応してほしいかな。そうすれば家族で共有しやすかったり、ちょっと渡すのにゲストがあったりすると嬉しい。
もちろん、指摘の通り、OSとして想定していなければ、データ持ち方とか細かいところで影響が大きくなっちゃうかもしれないから、どこまで可能なのかはわからないけど。
Oculus Rift, PS4
ついに発売時期と値段が公開されたということで話題になったようだ。
家庭で使える手軽なVRということだったけど、実際に出てみると少し値段が高くなってしまったようだ。
個人的には、手軽に家で使うという感じではないけど、やっぱり一度は試してみたいという気もする。
もちろん、コンテンツ次第であるし、あとは個人的にすごい酔いやすいので、3D酔いしちゃうのであればそもそも使えないとか、日常的に使うにはまだまだ道のりは遠いかな。
CES
hakさん得意のチップ話。
細かい話は追いきれないけど、単純に流しながら聞いていると楽しい。
でも、単語が難しすぎて、型番まできちんと頭に入ってこない（笑
ZenFone Zoom
チップつながりではあるけど、3倍ズームをするためにプリズムを入れて入射光に直角に光学系を配置するらしい。
制約は創造を生むということかな。
ゲーム最適化
今日のメイン話。個人的にはちょうどフォーカスしていたトピックの1つだったので、すごく興味深かった。
参考で書籍を上げてくれていたけど、結構高価な本なのでひよりがち。
なかなか隙間時間で勉強するには重い話なので、時間をとってきっちり勉強したい話。
プロファイルをとるということは重要で、それによってバジェット（予算、性能目標）を決めて、それに応じて高速化、最適化するというのは正しい手順だろう。
ただし、速度については性能目標を決めることが難しいケースっていうのはないんだろうか。
例えば動画とかフレームとかで明確に決まっているものであれば当たり前だけど、一方で静止画の画像処理のようにどちらにしろ進捗バーがでるようなケースで、速ければ速いほどいい、みたいなシチュエーションもあるような気がする。
そのようなときに、どこまでを目標、しかもそれが妥当で達成可能な目標なのかを判断するというのは意外に難しい気がする。
もちろん、目標を決めないと達成したかどうかの判断も出来ないし、決めないといけないというのはわかるのだけど。。。
Aftershow 128: Block The Neighbor's House
この時自分もこっそりライブを聴いていたけど、リアルタイムにtwitterのトレンドタグにのり、スパムの山になったのを見れた。
本当、トレンドってスパムの山になるのであれば、あまり存在意義がないのかも・・・？あとはスパムをブロックするとかかな。トレンドをいくつもタグつけて投稿するのは、それ自体が怪しいからね。
CPU実験
宮川さんの貴重な大学時代に留年した話をまじえつつ。
本編で高速化やアーキテクチャの話をしたので、CPUのコンパイラを作ることはいい、という話。
自分は大学で信号処理系だったので、こういう純粋な情報工学的な話をもっと大学でやりたかったな、という気分によくなる。
最近、ちょこちょこコンパイラについて勉強することも増えた。
Fallout 4
ボストンを再現したhakさんがのめり込んでいるゲームの話。
リアル感がすごい綺麗に再現されているということで、その辺が面白いかはやはりやってみないとわからないけど、しばらく据え置き型のゲームをやらないうちに、クオリティーがすごい上がっているんだろうなという変な感慨がある。
Netflix
動画サービスに多いらしいけど、地域を判断して、サービス側でフィルタリングするという話。
プロキシを使ったワークアラウンドをNetflixが塞いで、騒ぎになったらしい。
こういうのは、実際に困っている人と、関係ない人の温度差が激しくなりがち。
ジョーク
あれだけ普通に英語を使っているhakさんや宮川さんでも、ジョークに限って言えば、コンテキストがシェアされない状況において理解できないこともあるというのが驚き。
まぁ、紹介されているジョークについては、ほとんど言語というよりは文化に近いので、理解できない人からすると、ほんとさっぱりなんだろうな。
チャントをチャント覚えよう 2016年 開幕版
いよいよ開幕ですね。
今年も多くの選手がやってきて、川崎華族からもチャントが発表されました。
開幕までにチャント歌えるようにしときましょう！
GK1 / チョン ソンリョン
川崎フロンターレ応援歌2016 GK1 チョン ソンリョン - YouTube
DF2 / 登里享平
DF3 / 奈良竜樹
川崎フロンターレ応援歌2016 DF3 奈良竜樹 - YouTube
DF4 / 井川祐輔
川崎フロンターレ応援歌2011 井川祐輔 - YouTube
MF5 / 谷口彰悟
MF6 / 田坂祐介
MF7 / 橋本晃司
川崎フロンターレ応援歌2015 MF 07 橋本晃司 - YouTube
DF8 / 小宮山尊信
川崎フロンターレ応援歌 08 小宮山尊信 - YouTube
FW9 / 森本貴幸
川崎フロンターレ応援歌2016 FW9 森本貴幸 - YouTube
MF10 / 大島僚太
川崎フロンターレ 16 大島僚太チャント - YouTube
FW11 / 小林悠
FW13 / 大久保嘉人
川崎フロンターレ応援歌2013 大久保嘉人 - YouTube
MF14 / 中村憲剛
MF15 / 原川力
川崎フロンターレ応援歌2016 MF15 原川力 - YouTube
DF17 / 武岡優斗
川崎フロンターレ応援歌2014 DF17 武岡 優斗 - YouTube
DF18 / エウシーニョ
川崎フロンターレ応援歌2015 DF 18 エウシーニョ - YouTube
MF19 / 森谷賢太郎
川崎フロンターレ応援歌2013 森谷賢太郎 - YouTube
DF20 / 車屋紳太郎
川崎フロンターレ応援歌2015 DF 20 車屋紳太郎 - YouTube
MF21 / エドゥアルド ネット
川崎フロンターレ応援歌2016 MF21 エドゥアルド ネット - YouTube
MF22 / 中野嘉大
川崎フロンターレ #22中野嘉大選手新チャント - YouTube
GK24 / 安藤駿介
［川崎フロンターレ］ＶＳアビスパ福岡戦 安藤専用チャント - YouTube
DF25 / MF25 / 狩野健太
川崎フロンターレ応援歌2016 MF25 狩野健太 - YouTube
MF26 / 三好康児
なし
FW27 / 大塚翔平
川崎フロンターレ応援歌2016 FW27 大塚翔平 - YouTube
DF28 / 板倉滉
なし
GK29 / 高木駿
なし
GK30 / 新井章太
30 新井章太チャント(歌詞+メロディ) - YouTube
※ リサイクル！？ カムさん懐かしい。。。
dockerについて雑感
ちょっとdockerを使う機会があったので、軽く雑感をメモ。
やってみた使い方
試行錯誤した結果、docker-composeをLinux（Ubuntu）で使うのが簡単そうという結論に至る。
Mac/WindowsのDockerについて
dockerは基本的にLinuxのコンテナ技術をベースにしているので、MacやWindowsではその機能を直接使えない。
そのため、現在出ているdocker-toolはVirtualBoxなどの仮想環境をベースに動いている。
自分の使っている環境では、VirtualBoxでのパブリックネットワークが使えないため、必然的にコンテナ（ゲストOS）がポートフォワードを使うことになり、サービス側で表示に使うポートと、HTTPリクエストで用いるポートが異なり、結果として表示がうまくいかないことがあり、解決できなかった。
これは元々、Vagrantを使って環境を構築した際から発生している問題で、Railsなどハックできるアプリであれば、内部的なポートとHTMLで表示に使うポートを無理やり変えたりして、つまりモンキーパッチを当てることで対応していたけど、意外にこれがしんどい。
なので、VirtualBoxの問題が解決しない間は、実質的にMac/Windowsでdockerを使うことが難しい。
やってみたこと
あたりを入れてみた。
コツをつかむまでは、Node.jpでERRになる、起動してもHTTPリクエストに応答しない、など問題が出た。
４つをいっぺんに起動してもサクサク動くことが確認できたので、やはり動作が軽量ということは正義だと思った。
ちなみに、まずは起動してみた程度なので、運用面についてはまだフォローできていない。
一番簡単だと思われる導入方法
結局、行き着いた結論は、docker-composeを使うと一番簡単にイメージを利用できることがわかった。
dockerの基本が分かっていない状態で利用すると、すぐに複数のコンテナを利用するサービスがうまく連携動作してくれない問題に行き着く。
それは、オフィシャルのインストール手順であったり、他のブログの記事であったりしてもそうだが、どうやらdockerの進歩、変化に記事が取り残されていることが多いようだ。
なので、現在の最新のdockerであれば使えるdocker-composeもインストールし、使うことで、安心してサービスとして起動することができそうだ。
- 使いたいサービスと"docker-compose.yml"を検索する
- ディレクトリを作り、そこに取得した"docker-compose.yml"をwgetなどでダウンロードする
- docker-compose up -dで起動する
だけで、上記のサービス起動はうまくいった。
割と公式リポジトリの中にすでにdocker-compose.ymlを持っていることが多く、問題なく使えそうだ。
ちなみに、docker-compose up -dを実行すると、カレントディレクトリにある"docker-compose.yml"を参照して起動してくれるよう。
docker−compose.ymlについても、開いてみると簡単な記法になっており、何をしているのかなんとなく理解できる。細かいところに手は届かなそうではあるけど。
MacでUbuntuを起動することについて
今回手頃なPCがなかったため、MacにUbuntuを入れてみた。
これが結構面倒で、HDDのパーティションを作った後に、USBブートのOSを入れて、UbuntuのISOイメージを入れて、無線LANデバイスドライバを入れて、USBブートから起動してインストールしていく。
この辺が参考になった。
コンテナOSについて
コンテナOSとして、MacやWindowsが使えるといいなと思って調べていたけど、Ubuntuベースだとそれは難しそうというのが現在調べた範囲。
ホストがWindowsの場合には、windowsserver/coreというMS公式イメージが使えるけど、内部でHyper−Vを使っているという説明になっているので、WindowsOS上でなければ使えないっぽい。
その辺の制約も、もうちょっと追って確認する必要がありそうだ。
# 127: Post-mature Optimization
127: Post-mature Optimization
Guest
久しぶりの森田さん。
前回のhigeponさんにかぶせる話もあり、高速化という興味深い話もあり、興味深い回になった。
f.lux
iOS のナイトシフト機能が9.3からつくようだけど、元々アプリで実現していたものらしい。
ブルーライト自体がどこまで実証されているのかはわからないけど、ある意味より人がスマホとかを見る時間が増えていくと、こういう人に優しい話もあるのかなと。見なければいいというのもあるので、人とディスプレイの落とし所なのかもしれない。
むかし、一時期PCのディスプレイに黒いフィルムを貼って目に優しいとかもあったけど、最近はブルーライトカットの眼鏡とかも流行っているらしい。
これからどういう方向に行くんだろうか。
Michael Stonebraker
DBの研究者でチューリング賞をとった人が、DBに関する論文に対して1つ1つコメントを出しているらしい。
世の中にはいろんな専門家がいて、きちんと違う視点で分析して、それを1意見として発信していくということは、とても重要なことだと思う。
どうしても最近の技術領域は上のレイヤーに偏っていたり、誰でもブラックボックスで使えるように整備されたりして、根本的な技術レイヤーが軽視されることが多いように思う。
先の高速化の話とか、そういうレイヤの重要性がもっと認知されて、人を教育する仕組みとかももっと充実すると良いと思う。
関連して、最近自分としてはコンパイラとか、そういう低レイヤの話も折に触れて勉強するように心がけている。
大人気ない大人、素敵。
GitHub
GitHubのイシューは使いづらいからどうにかしろというコメントが盛り上がっているらしい。
あまりGitHubのイシューですら使いこなしたことはないけど、通常のプロジェクトを覗いてみるとなかなかうまくインテグレーションできていない気がするので、使いにくいというのは確かにそうだろうなという感じ。
プロジェクト管理、という面で進化しすぎるのはあれだけど、最低限の機能は多分みんな必要だと思っていて、その最低限のラインはもっと上なんだろうなという程度。
JIRA
JIRA職人がいれば意外に機能するという話。
最近少しRedmineを見る機会があるけど、あれもあれで古かったり、機能としてデフォルトでは基本的なものがすっぽり抜けていたり、片手落ち感が強い印象。
高速化
hakさんの回につながる高速化の話題。
確かに以前森田さんって、リファクタリング奉行を自称していた気がする。そういうのが元々好きで、興味があるんだろう。
高速化にはある種定石みたいなのがいくつかあって、それをもっと体系的にすることで、より特殊技能ではなく、一般的な技術として定着していくことができるのではないかということ。
速さの定義をすることは、hakさんも言っていたけど、まず定義できてしまえばほとんどの作業は終わったも同然だけど、意外にこれも大変。
あとは、8割の時間は2割の場所でかかっているという法則も一般的だけど、現実的にはそんな銀の弾丸的な状況は多くなくて、全体的に少しずついろんなところで遅くなっていることが多いというのも納得感がある。
Speed is feature. スピードは機能、魅力の1つだから、速度を速くすることは製品の魅力を上げることに直結するというのもわかる。
実装を始めるとそこまでの意識で常にいることは難しいので、自分の普段の作業を振り返って、考えなくても意識できるようにならなきゃなぁ。
ツールに関してもいろんなプラットフォームですでにいろんなものがあるので、それを利用できるようにしておくことも、実際に作業を進む上では重要。
サーバサイドに限って言えば、以前クックパッドのブログにもあったけど、実際に近い規模や内容のデータを使って開発することで、開発している最中でも速度について意識できて、うっかり遅くなるようなことが減るということもあるらしい。
Aftershow 127: Reading Exercise
親不知
たまたまだけど、自分もこないだの年末に最後の親不知を抜いたこともあって、不思議な感覚で聞いていた親不知ネタ。
どうも話の流れとしていっぺんに複数本抜くのが基本という感じだったけど、宮川さんの言うように痛みがなかったり不便がなかったりするならば特に抜く必要はないんじゃないかと思う。
どうなのかわからないけど、結局虫歯になっちゃったので、全部抜くことになっちゃったんだけどね。
読書
読書は刺激がなさすぎるために、リラックスした状態で読書をすると寝てしまうという仮説。
確かに、確かに、それはわかるかも。
例えば子供を寝かしつけていて、横になっているだけで寝てしまう、とか、本当に刺激が無くなるとすぐ寝てしまうようになっている気がする。
よく疲れていると夜お風呂で寝落ちしていたりするし、それはさすがにびっくりする。。。
読書については、確かに集中力が必要というのはわかるけど、E-Bookだと読書が進むというのはわかるけど、森田さんが言っているように技術書のオーディオブックはない、というのと、最近は聞くようなシチュエーションではPodcastを聞いてしまうというのもある。
まぁ、でも、森田さんの話を聞いてみるとオーディオブックちょっと試してみようかな。
ランチインタビュー
Googleのランチインタビューは、本に書かれているのとは違って、特に選考とか評価とかはない、という話。本のちょっとした反論にもなっている。
そりゃ、会社によって違うので、ここの会社の事情とかがもっとシェアされてくれると嬉しい人も多いんじゃないかな。
エンジニアとして世界の最前線で働く選択肢 ~渡米・面接・転職・キャリアアップ・レイオフ対策までの実践ガイド | 竜 盛博 | 本 | Amazon.co.jp
多分この本だと思うけど、時間を見つけてちょっと読んでみようかな。
週報
続ける仕組みとして週報をやってみた話。
勉強とか趣味とかを続けるのに、人に報告するようなことを取り入れることでより続ける力を維持することができるのでは、というのは確かにわかる。
失敗パターンの大きな一つとして、一度止めた際に復帰できなくなるというのがあるという仮説のもとに、復帰しやすいことを考えていくと、週報というツールは良いのかもしれない。
週報という形式は１つあるけど、他の人と一緒に、たとえ違うことでも、一緒にやるということは良いのかもしれない。
話を聞いていると、そういう継続するためのサービスとかどっかでリリースされないかな、という気になってくる。
# 126: Anti-Democratic Product Management
126: Anti-Democratic Product Management
Guest
久しぶりの新キャラ、higeponさん。
次の回のmoritaさんと対比もあって、マネジメントなどの興味深い話が多かった。
テックリード
naoyaさんが以前話した、サーバント型とビジョン型の話の続き。
テックリードは、エンジニア班の班長のような、技術に特化してリードするような職種があるようで、それの紹介。
技術一本で行きたいエンジニアがまず目指すポジションとして適しているようだけど、会社によって名前が違うという話もあり。
サーバント型とビジョン型は時々対比で語られるけど、会話の中でも指摘されているように、どちらも別のベクトルで、どちらかという議論ではないけど、ビジョン型という意味のリーダーが日本の企業で不足しがちというのは実感としてわかる気がする。
また、naoyaさんが最近のリーダーは”いい兄貴”のように、サーバント型に力を入れ過ぎてしまって、ビジョン型の方向にあまり力を入れていないんじゃないか、という懸念は重要な指摘だと思う。
例えば、サッカーなどのスポーツでは、ビジョン型に特化したのが監督であって、サーバント型と呼ばれるようなものはスタッフであったりコーチであったり、他の人に明確に分担しているイメージがある。
ある意味、仕事だと曖昧になっているビジョンに対する考え方が、スポーツの世界ではより重要性が肌感覚で理解されているのかもしれない。
プロダクトマネジメント
プロダクトマネージャは、体系だった教育もないし、実績や実力を測ることも難しいけど、重要な職種であるという話。
うちの会社でも、プロダクトマネージメントという考え方自体がないので、本当にこういうシステム化されているととってもうまく製品開発がうまくいくんじゃないかなと錯覚してしまうけど、実際はおそらく人によったりで、多少の差はあれ、銀の弾丸ではないんだろうなと。
マイクロサービスは、グループが分裂して、影響範囲を局所化して、局所的な効率化を突き詰めた結果であって、ただの人の問題ではないかというのは確かにその通り。
ただ、マイクロサービスを効率的にやるのか、ただ単に境界を決めて仕事を減らすことに集中しすぎてしまう、というのはまた違うというのはある。
合議制はクリエイティブな決定ができない、というのはどこでも話題になるし、実際に日本企業、うちの会社とかもよく見る光景ではある。
だから、例えばアップルをよく例に出すけど、ジョブズのような趣味の良い人に決めてもらうというのは、確かにその通りである。
一方で、センスがいいということが明確にわかって、説得力があればいいけど、実際の現場で見ていると新しいものであればあるほどファジーなものも多くて、センスがいい人、ということを見極めること自体がとても難しい。
その辺、理屈としてはわかるけど、実際にセンスがいい人を選ぶことが大変だから、現実的には成立しないのでは、と思ってしまう。どうやっているのだろう、その辺。
合議制では全部のORをとる、というのも、あるあるすぎて、全然笑えない。
Aftershow 126: Everything Except Mayonnaise
英語の勉強法
最近話題になる英語の勉強法。自分としては結構興味がある。実践までできてないけど。。。
昔の英語の勉強法の、宮川さんのブログ記事は本当に有名だよね。すごいなぁ、東大生だから英語がちょっと出来るくらいは当たり前かもしれないけど。
頭を使わないでパッと出るようなフレーズをたくさん増やすのが、会話には重要というのは、言われてみるとその通り。ちょっと英語を使わないと、どんどんそういうフレーズが出てこなくなる。
宮川さんのいうように、最近自分でも英語のポッドキャストを時間を見つけて聞くようにしている。本当に何かの足しになればいい、程度だけど。
まぁ、宮川さんもhigeponさんも、やっぱりアメリカに住んでいて毎日使っていると、ある程度はやはり使えるようになるよね、というのはある。
宮川さんも毎日話すことが大事だと言っているし、そういう環境に置くということは、勉強そのものをやる事よりも、実は重要かもしれない。
自分は自分、他人は自分を気にしていない、というのは確かにアメリカに初めて行った時とか、すごく感じた。それがとても過ごしやすくて、気にしないで街を歩けるような感覚が、実は日本に向いてないのかなーとか思ったりした。
今でも、いつか海外で住んでみたいなと思う一端は、その辺にあるんだよね。
Pebble Time Round
スマートウォッチに興味のない自分としてはあれだけど、Pebble Time Roundの話。
実際に見る機会はないけど、完成度がそれくらいあるのであれば、Apple Watchと一緒にスマートウォッチの市場を牽引してもらって、今後の行く末を占うデバイスなのかもしれない。
# 125: Toothbrush Can Be Exciting
125: Toothbrush Can Be Exciting
体調崩したりで、更新が滞ってしまった・・・
Guest
新年あけましておめでとう、という感じで、いつものNさんとnaanさん。
今年も楽しい話をたくさん聞かせて欲しい。
Supporter's Program
年間プログラムにたくさん登録してもらったという話。
RAWがフィードになったのは個人的にはとても嬉しくて、mp3ダウンロードしてもovercastで取り込むのが面倒で、倍速で聞けない関係でなかなかうまく使えなかったけど、これでそのもの台が解決した。
あと、なんとなく感じるのは、元々の値段が月$10だったけど、これってApple Musicとかいろんなサービスの値段と同じくらいで、サポーターとして払いたいけど、相対的に少し高い印象があるような気がする。
その半額程度というのは、安いという観点から意外にも、純粋に他のサービスの値段とかの相場からして妥当感が結構あったような気がする。
英語
Rebuildに触発されて英語を一年間勉強した人の話。
聞いていると自分としても英語勉強しなきゃなって思うけど、それを一年間通じて勉強し続けるのはすごいと思うし、そうあるべきだと思う。
エンジニアとして必須だし、もし機会があれば海外で働いてみたいというのは密かな夢でもあるから、技術的な勉強の他に英語についてもっと勉強したいとは思う。
なかなかそういう時間と気合が続かないけれども。
Twitter For Mac
新しいMacアプリが出たらしいけど、Twitterのヘビーユーザーからするといまいちらしい。
ほとんど見るだけで使わない自分としては、オフィシャルのアプリはまぁまぁだけど、その辺は使う機能とか全然違うんだろうな。
iPad Pro
iPad Proみたいなデバイスになると、iOSで統一的に扱うのは無理があるのでは、という話。
確かに開発とか統一的な使い方という意味ではいいのかもしれないけど、実際にはアプリが最適化されていないことで良さが出せてないらしい。
便利は便利だし、ペンを使うとデザイナーとかには便利だけど、今後どこまでハードウェアに最適化されるのか、それによって市場の動向が変わってくるような気がする。
キーボードとかペンがある前提のインターフェースは、やっぱり別になるのは同意かな。
451
httpのステータスコードに、451という政治的な理由により表示できないということを返せるようになったという話。
確かに、サーバ側で理由を明示できるので、うまく使えば便利なのはわかるけど、現実的にはどこまで利用されるのか。
華氏451度という小説？からきているというのは、結構オシャレなコードをつけたんだな。
Android Java
GoogleとOracleの訴訟に関連して、次のAndroidではOSSになっているOpenJDKを使うようになったという話。
訴訟的にはどうせOracleはGoogleからお金をもらいたいだけだから、また次に別の理由を探すだけということだろうけど、Android開発という意味ではVMが変わる影響がどこにくるのか。
Javaのバージョンが変わる以外にも、本当に互換があるのか。意外なところに影響が出るもんじゃないのか。
個人的には、Nさんと同じようにGo言語を使うのに賛成かな。あれはいい言語。
Swift
Androidにインポートもいつかされるだろうけど、他にもLinuxとか、いろんな可能性を感じる。
教育用に使うという可能性は一定以上あるし、以前hakさんが言っていたようにCの手触りがわかりつつ、適度に抽象化されているというのはわかる。
そういう意味では、Javascriptとかよりも教育として良いというのは同意できる。
PHP
言語は手段だから、やりたいことを最短で実現できるような言語が一番良いという話。確かに、それは一理あって、やりたいことがあれば一番それに近い手段を使えばそれでいいというのはわかる。
一方で、宮川さんとかみたいにできる人はどの言語であっても、特に問題はないだろうけど、将来の投資という意味で、最初はちょっと大変だけど今後の勉強になるという理由で言語やライブラリを選ぶという理由もある気がするな。
要するにそのバランスだとは思うけど、最近はそういう視点で簡単にできるという以外の観点も大事にして何を使うかを考えている気がする。
Perl 6
ようやくリリースしたPerl 6の話。
仕様と実装がわかれているのは最近の流れではあるけど、確かに現実的にはわかりにくい。
結局動作が仕様という側面も無視できないので、リファレンス実装はどこかにあるべきな気がするし、それはそれであるようだ。
宮川さんはRubyとPerlどちらもやるのは、やっぱりすごい人は筆を選ばないということだなぁ。
Aftershow 125: I'll Become A Youtube
スターウォーズ
これだけ世間で騒がれているし、元々SFは好きなので一度見てみたいと思う。
とはいえ、実際に見ようと思うとどこから見ていいかわからないという問題がある。
誰か、この順序で見ればいいというおすすめ教えてくれないかな。
あとはスタートレックも一度見ておきたいな。
今年の抱負
2016年の抱負という意味では、きちんと一年間勉強するということかな。まずはRubyと、次にRailsと、あとは忘れないように細々と英語かな。
やっぱり、英語のポッドキャストを聞けるようになるというのと、話す機会をなんとか作るということかな。
あと、毎日コーディングかブログを書くというのを続けるというのはしたいね。毎日でなくても週に3でも4でも、続けるということをやっていきたい。
資格もとりたいけど、あまり欲張らないほうがいいかな。
RubyのC拡張を使って、RAWをデコードするgemを作りました。
RubyでRAWファイル*のデコードが出来るgemがなかったので作ってみました。
C拡張でdrawを呼ぶ
基本は、その道では有名なdcrawというライブラリを使いたかったけど、純粋なCで実装されているためにRubyのC拡張の機能を使って実装してみた。
Decoding raw digital photos in Linux
単純にCのコードを呼び出すだけとはいえ、せっかくなのでオプションをハッシュで受け取るようにしたいと思い、C拡張の機能を手探りで探し、変換するコードを書いてみました。
RubyのC拡張とか使うことないので、大変だったけどいい勉強になった。
if(opt != Qnil){
if(Qtrue == rb_hash_aref(opt, ID2SYM(rb_intern("debug_mode"))))
debug_mode = 1;
if(Qtrue == rb_hash_aref(opt, ID2SYM(rb_intern("print_message"))))
v[c++] = "-v";
if(Qtrue == rb_hash_aref(opt, ID2SYM(rb_intern("apply_awb"))))
v[c++] = "-a";
if(Qtrue == rb_hash_aref(opt, ID2SYM(rb_intern("tiff_mode"))))
v[c++] = "-T";
}
余談ですが、C拡張はruby/doc/にドキュメントがあるけど、ハッシュなどはそこに含まれていないので、実際にhash.cなどのソースを見ながらAPIを調べる感じでやっていったので、結構時間がかかった。
どこかにまとまったドキュメントとかあるんだろうか。
他のオプションもたくさんあるけど、まずは0.0.1としてppmとtiffとして出力するところをリリースしてみた。
使い方は、
require 'ruby-raw' filepath = "~/IMG_0001.CR2" opt = {:print_message: true} Rubyraw::Raw.new.decode(filepath, opt)
みたいに実行すると、ファイルと同じ場所にppmファイルとかを出力できるはず。
はず。
テストとリリース
コマンドは簡単だったので、
rake build rake test rake release
みたいにしてできるのは、素晴らしい。
- デジタル一眼レフカメラなどで出力されるRAWファイルと呼ばれる形式。通常は、ベイヤと呼ばれるセンサが取得した生のデータを保存しているため、JPGなどよりもbit精度も高く、編集に適している。
