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精度も高く、編集に適している。
Extra with @driken
サポーターズプログラム限定のextraプログラム。
過去にあったのかわからないけど、多分自分がサポーターになってから初めて。
というか、RAWフィードが2015年年末からできるようになって、extraがわかりやすくなった。
あまりネタバレになるとサポーターズプログラム限定の意味がないので、いつも以上にザクッとしたメモ。
Guest
backspaceでおなじみの@drikinさん。以前、backspaceの特別編っぽい時に宮川さんがゲストで出ていたので、今回は逆。
その時も思ったけど、みんな知り合いなんだーっていう素直な感想と、やはりそういうエッジな世界は結構みんな知り合いで狭い世界なのかなってこと。
Podcast機材
podcast環境に関しては第一人者？の宮川さんがオススメする機材トーク。ヘッドセットも意外に良い選択肢らしい。
Rebuildファンとしては一度そういうのもやってみたいと思わなくはないなぁ。
Rebuildとマネタイズ
もうすぐ３年で、今度で４年目らしい。年月だけでもすごいし、実際に更新頻度を考えるとハンパない。いや、backspaceも頻度に関しては負けてないけどね。
backspaceはマネタイズが今年の目標らしい。確かにRebuildよりもbackspaceの方がガジェットの広告向けだと思う。買わせたいプレッシャーが強いというのも、よくわかるなぁ。
2015年買ったガジェット
ガジェットに関してダラダラトーク。
ZenPadとAppleTvはさらりと流して、Androidとカメラの話題に。
仕事柄、WiFiとカメラについては考えることが多いけど、確かに連携がうまくいってない現状（の機種）であれば、スマホとカメラで２回撮影するという宮川さんのコメントはわかるし、当然それが面倒というのがわかる。
速度的にWiFiが良いのもわかるけど、NFCを利用できるAndroidみたいに、タッチでつないで転送というのが利便性が良いのも、iOSになってしまうとちょっと話が変わってくる。
だいたい、WiFiがカメラホストでつないでしまうと、通常のアクセスポイントからは切断されるし、Webとか他のコネクションがおかしくなるだろうし、一時的な用途としては良いとしても、それが解決策にはどうしても思えない。
モバイルでの開発環境
あとは、モバイル端末からのリモートの話題を少し。
クラウドが進んで、端末がもうちょっと開発者よりのニーズをカバーできれば、iPadからsshでサーバにログインして仕事をしたりすることも、当然できるだろう。
モバイルOSのコンセプトとしてあまりOSネイティブなレイヤは触らせないので、実際にツールを使おうとするといろいろ制約があって現実的かどうかはわからないけど、できると便利だというのはとても賛同できる。
エディタ
最後は、エディタの話。
Webの記事を見ると、最近はAtomとかが目立つけど、個人的にはVim派も結構多い気がする。
Emacsが多いのはRebuild界隈のみのような気もするけど、Vimかそれ以外の新しいAtomみたいなエディタではなかろうか。
軽いのは大事という宮川さんのコメントは暗にAtomを非難しているけど、別の側面からすると、IDEの進化と近いところがあって、プラグインの優劣が多少の動作の機敏性を上回ってしまうところはあるような気がする。
もちろん、個人的に好きになのはVimなどの軽いものだけど、全体の傾向としてね。
# 124: Universal Sushi
124: Universal Sushi
Guest
今日はhakさん。内容的にはホリデーシーズンということもあり、RebuildのWebシステムをリニューアルしたということもあり、わりとゆるめの話題が多い印象。
Chrome
ホリデーで、宮川さんがChromeの通知を実装した話。
ここではっきりさせておきたいけど、ここにYO使ってますリスナーいます。
確かに指摘の通り、Rebuildの 通知しかこないという数人のうちの一人だけど。。。
Let's Encrypt
無料でSSLの証明書が取得できるらしい。こういう情報はサイト管理者とかだと重要な情報になるのかな。個人的にはあまり使う機会ないよね。
Rebuild Supporter
月$10でサポーターだったけど、それが年末だけ半額キャンペーン中。
そもそも、メールが来てdropboxをひらいてコピーとか、結構面倒だったので、それがとっても楽になって、かつRSSなのでovercastでもシームレスにダウンロード、再生できるようになったのでこれがとても便利。
overcastとかで再生するのは、倍速で聞くためには必須なので、mp3ファイルをスマホだけでハンドリングするのは厳しいし、ここの改善が一番嬉しい。
半額は魅力的だったので、ここだけの話、こっそり登録し直して$60払ってみました。なんか罪悪感を感じつつ。。。
確かにサポータープログラムなので、払える分は払いたいんだけど。
Tシャツ欲しい! もちろんステッカーも。
休みに入って、自分のホリデープロジェクトを進めるというのはいい習慣だよねと思う。日本だと仕事以外の時間は見たくない！というのが当たり前の価値観になっていると思うけど、本当に楽しい仕事であればそうじゃないということで、そういう前向きな習慣は真似したい。
なかなか子供がいると休日の方が忙しくて難しいという面もあるけど。
VR
2016年に幾つかのVR機が出るけど、どこまで出荷台数を伸ばして、一般に受け入れられるかという点について注目しているという話。
rebuild的には話題に結構のぼっているけど、まだまだ一般に広まるには時間がかかるのかな。
ゲームとか、そこまで没入してやるという習慣が、そもそもスマホのライトゲームユーザが増えた現在では少ないような気がする。ゲームやり始めると時間とられるしね。
Unreal Engine、Unity
hakさん特有のゲームフレームワークの話。
Unityは最近本も増えてきたから、一度使ってみたいとは思うけど、なかなか目的がないとハードルが高いよね。
Job Ladder
タイトルだけ見るとピンとこないけど、エンジニアのカテゴリ分けの話。
Ladderと呼ばれる、エンジニアのレベル分けがあって、それごとに期待されるものが明確に定義されているという話だけど、この辺は日本の企業は割と定義はされているんじゃないかな。
あくまで自分の知っている範囲だけど、内容を聞いている感じでは、特に目新しい感じはするけど、もしそれが実際の仕事に密にリンクしているのであればすごいな、という程度。
あとは、どの人がどのレベルかを公開するかどうかも、レベル分けの意味合いが変わってくると思う。評価制度と絡んでくると、あまり公開しないきがするけど、直接絡んでなければ当然みんな知っているので、求められる仕事内容の共通理解に利用しやすいのかもしれない。
聖闘士星矢のたとえは、見たことのある人しか分からない気がががが
Swift
hakさんの印象として、アセンブリに落とす手触りがわかりやすい言語なので、ミドルウェア以下の実装に合うのではという感じ。
少し触っただけでは、確かにその側面もあるとは思うけど、その意味でいえばGOの方がずっと優れているとは思う。まぁ、考え方が結構違うので、比較するのはどうなんだろうというのはあるけど。
Swiftへの期待値は高いけど、まだまだどういう領域で使われるかは未知数かな。
あとは、開発環境の進化にも期待したい。
iPhone、Bluetooth
ヘッドホンがなくなるかどうか、という話の流れ。
Bluetoothをしばらく使ったけど、意外に毎日使っていると安定性に欠けるときがあるので、有線の需要はもうしばらくありそうだなという感じ。
あとは、有線ではあるけど規格を変える？というような選択肢はあるのかな。
いきなりなくす、というのは結構激しい。
ちなみに、今充電しながら聞いているので、ライトニングでイヤホンを接続するしかなくなると、それはそれでしんどいなぁ。
Aftershow 124: Are We In A VM Yet
OnHub
無線LANのハブを変えた話。
たしかに画像を見るとおしゃれな感じだけど。。。
シュタインズゲート
一度見てみたいと思いつつ、まだ見れてない。
シミュレーション仮説
次の回で、ちょー電波系といわれるほど。
ぜひ直接聞いてみるといいと思います。
