2016年のF1を見るかどうか悩み続けていたら開幕した話

毎年F1放送にがっかりしているF1ファンの皆さまこんにちは。koheisgです。

今年はついにBSフジでの録画放送も廃止

BSフジ、2016年のF1放送はなし 【 F1-Gate.com 】

今年はついにBSフジでの録画放送も廃止となり、日本国内でF1を見るためには有料放送の契約が必須となりました。 これを契機にCSを契約されたF1ファンも多いのではないでしょうか。

地上波での録画放送は数年前に廃止になっているので、 すでにF1を見ている人は限られた存在になっているかもしれません。

僕は現在CS契約をするかしないか非常に悩ましい決断を迫られているところです。 だって、CSの契約とか金持ちがやることでしょ。

お金持ちの条件とは

僕は子供の頃、友達の家を下記で金持ち判定していました。

ぶっちゃけ家にいる時間なんて対してないわけですよ。 F1という番組を見るだけのために、CS契約して月数千円ってバカみたいな話です。

それでもF1という娯楽は自分は大好きなので、CS契約するか否かを迫られているわけです。

今年のF1が面白いかで決める

そもそも、去年F1を決勝レースは録画したりあの手この手を振り絞って見ました。 でも、結果はメルセデスの圧勝。ハミルトンは早すぎだし、大したことないロズベルグにだって勝てそうにありませんでした。

その中で、フェラーリ勢がなんとか一矢報いるかどうかを見守るF1。 そんなF1なら正直、今年は見なくていいんじゃないかという気もしてきました。

今年のF1っておもしろいのだろうか。

今年はフェラーリのエンジンがかなり改善されたという噂でしたが、 ライコネンはエンジントラブルでリタイア、ベッテルはあと一歩のところで3位でした。

全くもって、メルセデスのミス待ちという感じで、今年もミスの少ないベッテルとハミルトンを早い車に乗せろ!とマッチがきっと言うはずです。 みんなが興味津々のホンダジャパンパワーも衰えの見えつつあるワールドチャンピオンの2人で、表彰台を狙えるか?というかつての日本人ドライバーがいい車に乗っていた時代を思わせる体たらくです。

今年のF1はみない

というか、フジテレビNEXTは契約しないで、いいんじゃないかなぁ。 僕は今日実況はF1officialで、youtubeの野良ライブで映像は見ていました。

これ実は最強だったりして、日本語の実況よりも英語の実況の方が何が起こっているかよくわかるし。

そうそうアロンソが怪我しなくて本当によかった

あの映像みたときは、ついに伝説が伝説になってしまうのかと思ってしまった。。

【動画】 フェルナンド・アロンソが大クラッシュ / F1オーストラリアGP 【 F1-Gate.com 】

ワーキングメモリで開発

ワーキングメモリとは

ワーキングメモリとは自分の脳内のメモのことです。 例えば、買い物に行ったときにメモがなくても、あれとこれとそれが必要と思って、 買い物を順番にすることができます。これがワーキングメモリです。

認知症予防で注目されている分野でもあります。

今自分が考えていること

GTDやチケット駆動開発をしていると、自分で覚えておくべきことは、 全て何らかの形でメモをとることになります。

チームで仕事を行うときのエビデンスにもなるし、自分の記憶に依存することなく物事を進めていくことができるため、非常に大事なことです。

しかし、あまりにも自分が何も覚えておらずチケットやTODOリストを見ないと何もできないくらいに馬鹿になっているような気がするのです。 顕著な例がプログラムを書く時で、あの標準メソッドってどんな引数の順番だったっけ?とgoogleを頼ることがあまりにも多いこと。 もっと、フロー状態に自分を持っていくためにはもっと “ググらないこと” を実現していかなければならないと思ったのです。

ググらない x メモらない で実現できること

例えばターミナルを開いている時は、開発や作業に集中できます。 ドキュメントを作っている時に仕様が全て頭に入っていれば、ドキュメントを書くことに集中できます。

自分の脳の容量を上げていけば、自分の開発スピードをあげることができるんじゃないかなぁ? と今実践しようと思っているところです。

GTDとは少し考え方が違うのですが、inboxくらいは頭の中に入っていてもいいんじゃないかなぁと思う今日この頃なのでした。

参考リンク

ワーキングメモリ - Wikipedia ワーキングメモリ(作業記憶)トレーニング

php-nabeでext-installする場合

php-nabeのバージョン管理に僕はphp-nabeを愛用しています。 phpenvやphpbrewなど数ある中でこれを使っています。 phpを使わないでphpを管理したいという思想に惚れた訳です。

で、たまに php-nabe ext-install extname でphpの拡張がインストールできるのですが、 下記のようなエラーがよくでます。

$ php-nabe ext-install openssl
Cannot find config.m4.
Make sure that you run '/Users/kohei-sugi/.php-nabe/php-nabe/build/php-5.3.3/bin/phpize' in the top level source directory of the module

/Users/kohei-sugi/.php-nabe/php-nabe/bin/php-nabe: line 416: ./configure: No such file or directory

そんなときは、srcのファイルの中を覗きに行って、

mv config0.m4 config.m4

をしてあげて、もう一度実行するとOKです。

自分でコンパイルしたい欲求を程よく満たしてくれるので良いですよね。。 ただ、普通にyumでphp入れたとき見たいなお手軽感がないので、recipe的な機能を作って、 コンパイルオプションとかをデフォルトで選んだりできれば良さそうやなぁなんて思ってる今日このごろ。

historyを見たところ下記のようなextを良く入れているっぽい。

php-nabe ext-install php_pdo
php-nabe ext-install php_mysql
php-nabe ext-install php-fpm
php-nabe ext-install fpm
php-nabe ext-install php-mysql
php-nabe ext-install zbil
php-nabe ext-install intl
php-nabe ext-install apc
php-nabe ext-install pdo
php-nabe ext-install mysql
php-nabe ext-install pdo_mysql
php-nabe ext-install ext-pcntl
php-nabe ext-install pcntl
php-nabe ext-install mcrypt
php-nabe ext-install newrelic
php-nabe ext-install ext-newrelic
php-nabe ext-install ext-newrelic
php-nabe ext-install zlib
php-nabe ext-install zip
php-nabe ext-install mysqli
php-nabe ext-install curl
php-nabe ext-install php-cli
php-nabe ext-install cli
php-nabe ext-install cli
php-nabe ext-install php
php-nabe ext-install ext-curl
php-nabe ext-install curl
php-nabe ext-install openssl
php-nabe ext-install xdebug
php-nabe ext-install xdebug-2.2.7
php-nabe ext-install mbstring

version毎には一応、これらはちゃんとmacの中に入っているはずなのだけど、 その辺りをrecipe的に管理したい欲求なんですよねー。

recipe管理ができれば、仮想マシンの中でphp-nabeを使ってphpをインストールするときに、 同じようなextensionを何度もbuildしないで済むし、

phpのバージョンを新しくインストールした時なんかも、recipeのextensionを全部インストールしてねー みたいなことできるんじゃないかぁーなんて思っているわけです。

こういう風な仕組みになると、vagrantにもphp-nabeでprovisionをする方法が流行るんじゃないかなぁとか。 (聴いたところ手元でコンパイルするのはあまり好まれないらしい)

なんかいい方法あるかなー。

ブログをjekyllに移管のためにやったこと・やらなかったこと

jekyllにブログを変えてみました。 markdownで記事を書けるのはやはりすごい楽です。 お気に入りのエディタであるvimで書けることも素晴らしいです。 やったこと、やってないことをまとめておきます。

やったこと

bloggerで運営していたブログを移管しました。 一部labelページ以外を除いて、同じURLに移行しました。

bloggerで長らく運営していたこのブログですが、 bloggerのhtmlがなかなか弄りにくいことが主な要因です。

blogger自体テーマがあまり充実していないのと、良いテーマがあっても、 それをカスタマイズするのにhtmlのようなxmlを弄るのに疲れてしまいました。

wordpressという手段もあったのですが、静的サイトジェネレータに興味があったので、 今回のような形になりました。

ちなみに静的サイトジェネレータをjavascriptで作ろうとしたのですが、 そこは挫折してしまいました。。

なんでhugoじゃないの?とかなんでoctopressじゃないの? って質問があると思うので、書いておきます。

hugoじゃない理由

rubyでpluginを作れることとgithub pagesでメジャーな手段になったことくらいでしょうか。 hugoは正直魅力的なので、どこかで試してみたいとは思っています。

octopressじゃない理由

htmlを弄りやすいようにしたいことが、今回の動機でもあったので、 octopressはテーマは充実していますが、htmlがそんなに得意ではない自分ではoctopressのテーマは弄りにくいなぁと思いました。 あと、jekyllの方がdocsも充実しているように見えたのと、コード自体の見通しもよかったです。

その他検討したもの

フロントの実装がメインになる静的サイトジェネレータですから、javascriptで全てを統一するという夢は僕もみました。 javascriptのエコシステムでほとんどのものがそろっていますので、gulpで適当にビルドしたりデプロイしたりは容易い御用なはずです。

そこでmatalsmithというjavascript静的サイトジェネレータを検討していたのですが、 独自のpluginのインターフェースに実装していくのが、骨が折れてしまいました。

しかも、pluginのほとんどはnpmのエコシステムにありふれたものをpluginとしてラッパさせたもので、 少しjavascriptを書けばいろいろなことができそうだったのですが、それを書く手間をはぶけるcomponent型のシステムを作れば。。。

と考えたところで土つぼにはまってしまい、本来のブログを書くという目的を見失っていたところ、 ふと正気に戻り、jekyllという選択をした経緯があったりします。。

各記事のURLが変わらないように。。

sitemap.xmlを取得して、URLを抽出。 その抽出したURLに対して、phpunit gazzleで200が帰ることをテストで書く。 そして、 /etc/hosts を新環境に向く事を確認して、再度同じテストを回す。

URLが変わってしまった記事に対してはテストが落ちるので、ちょこちょこそれらを微調整していく。 まぁ、そんな感じです。

やれていないこと or 見送ったこと

tagの移管も本当はしっかりしたいのだけど、まだできていない。 本当は移管自体はできているのだけど、ちゃんと機能させれていない。

google tag managerで広告枠とanalyticsを管理したかったけど、とりあえずいつでもできるので後回しに。

slimを導入したかったのだけど、ちゃんとコンパイルできず。。 jekyll puluginの使い方などわかっていないところがあるので、その辺りがわかるようになったら再度挑戦って感じかな。 htmlは書きにくいけど、DreamWeaverに頼れば割と簡単にいろいろできそうだし。。

git cleanで.gitignore対象のファイルが消えてしまう話

とあるrubyのプロジェクトを進行中に不要なファイルがたまってきました。

$ git status -b -s
# master
?? a.rb
?? b.rb

上記のファイルは必要ないので、 git clean -fd を実行します。

$ git clean -fd
Would skip repository vendor/bundle/ruby/2.2.0/bundler/gems/slim-0726c443dfdd
Would remove vendor/bundle/ruby/2.2.0/bin
Would remove vendor/bundle/ruby/2.2.0/build_info
Would remove vendor/bundle/ruby/2.2.0/cache
Would remove vendor/bundle/ruby/2.2.0/doc
Would remove vendor/bundle/ruby/2.2.0/extensions
Would remove vendor/bundle/ruby/2.2.0/gems
Would remove vendor/bundle/ruby/2.2.0/specifications

oh!!!

vendor/bundle の中のgemが消えてしまいました。。 仕方なく bundle install するわけですが、なんで .gitignore の中に入っているはずの、 vendor/bundle 配下のファイルが消えてしまうのでしょう。

自分自身 .gitignore の書き方にあまり自信がなかったので、 いろいろ調べてみましたが、特に問題なし。

git clean -fdx

とかすれば、ignoreされているファイルを消すこともできるようですね。 が、今回の解決策とはなりません。。

解決策は .gitkeep をファイルに置くことでした。 vendor/.gitkeep をコミットすることで解決しました。