表題のとおり。
最近オブジェクト指向って言葉を聞かないし話さなくなった気がする。
そこで理由を少し考えてみた。
コードレビューしてて「オブジェクト指向」という言葉を使ったときの久しぶり感がすごかった。
ここしばらく話題に上がっている「マリオメーカー問題」
これを回避するための Chrome Extensions をつくった。
あくまでも個人用途です。
先日この記事を書いたばかりだが、以下の問題があった。
UPQが出荷済スマホを全て回収、技適マークの記載ミス - ケータイ Watch
回収ということになったので開封の逆、封緘した。
（対義語がわからなくてググッてしまった）
自宅に届いた封書。
中身は今回の件の説明、スマホの返送用セット
返送の手順書。
データのバックアップ取っておいてね、と注意深く書いてある。
細かい話だけど「パッケージ貼付用ラベル」ってのが微妙にわかりづらかった。
単純に箱って書いてくれればいいのに。
パッケージに貼った。
この後携帯を佐川急便で送った。
佐川急便か・・・近くに営業所ないんだよな。。ヤマトなら徒歩5分程度であるからそっちがよかったが、しゃーない。
— kheiakiyama (@kheiakiyama) 2015, 9月 29電話で集荷を依頼するには登録が必要とか、佐川急便めんどくさいな。持ち込むか。
— kheiakiyama (@kheiakiyama) 2015, 9月 29さていつ返ってくるやら。
どうでもいいけど UPQ Phone グッズが Amazon にそれなりにあって驚く。
何かと話題が多い UPQ のスマホ、UPQ Phone A01 が届いたので開封の儀をはじめる。
箱は白を基調としてグリーンがアクセントカラーとなっている。
端末の色と同じ色なんだろうか。
箱を開けてみたところ。
iPhone以外のスマホ開けたことないけど、大体同じような構成だなあ。
付属品を全部出してみた。
SIMカードやSDカードは用意してないが、充電バックを入れないと始まらないので端末をオープン。
リアカバーを開けたところ。
無理に開けようとすると平気で曲がりそうなので、落ち着いて爪で少しずつ開ける。
あとは電源をつけるだけ！！
起動直後はこんな感じ。
本体のストレージ容量は8GBだが、うち4.5GBが埋まっていた。
SDカード挿せばいいし、まあこんなもんでしょ。
ということで開封の儀は終わり。
レビューについてはしばらく使ってからまとめることにする。
それにしても Android 童貞の自分には、スクリーンショットの取り方すらわからなくていろいろツライ。
アプリを作ろう! Android入門 Android Studio版 Android5対応
Electron: Building desktop apps with web technologies - YAPC::Asia Tokyo 2015
やってみた系の記事やハウツー記事がやたら目につくようになった。
もっぱらWindows系で、最近MS系のWeb開発者にジョブチェンジした身からすると、Electron のどこがいいのかが今ひとつわからなかった。
それがいくつか予測できてきたので、何が嬉しいのかを忘れないように書いておく。
誰かに聞いたわけじゃないので僕の単なる想像。
日常的に使うWebサイトを何個もブラウザで開いておくよりも、アプリのほうが使い勝手がいい。
Web系開発者にとって HTML + CSS + JavaScript(npm) で作れるなんて願ったり叶ったりだ。
今のスキルセットの延長線上で作れる。
今は亡き IE6 をはじめ、残念なブラウザに対応しなければならない苦痛。
素晴らしいライブラリによって緩和されていたけど、やらなくていいならそれに越したことはない。
Electron は Chromium を利用しているため、それだけ対応すればいい。
互換性を考えなくていいなんて優しい世界だ。
外してたら指摘ください。
サーバサイドJavaScript Node.js入門 (アスキー書籍)
ブログを書くまでが YAPC::Asia ということなので、書きます。
esa.io - 趣味から育てたWebサービスで生きていく // Speaker Deck
このセッションで勇気づけられた。
趣味が高じてシゴトになった、というシンデレラ・ストーリー。
実際 esa.io は使ったことがあるけどすごくよく、他の利用者も好評だった。
（ただギョームで導入する説得材料が弱くて試用期間でやめてしまった・・・すいません。）
【お知らせ】 diary/2015/08/21/YAPC::Asia 2015でesaについて発表してきました #yapcasia #yapcasiaA - https://t.co/QctT2jqulj
— esa_io (@esa_io) 2015, 8月 21
esa.io はフィードバックの早さも好感が持てるし、
上のアイコンを見てわかるとおり、何より可愛い！
可愛いは正義！
（中の人が「トリっぽく演じてます」って話してたけど）
印象に残った発言。
「いろんなことを試していてたまたまうまくいったのが esa だった。」
趣味プログラミングを昇華させるにはもっと数を打つことだ。
HTTP2 時代の Web - web over http2
21, 22日と連続で行われた HTTP2 のセッション。
2つの構成は似ていたけど、講演者の得意分野が（たぶん）違うこともあり、フォーカスするポイントが違って理解が深まった。
個人的に気になったのは、趣味で作るサービスでも HTTP2 を使うようになっていくのかなーという点。
証明書の問題もあるけどサーバー料金も負荷という点で負担にならないかが気になる。
フロントからサーバー管理まで、浅いレベルでフルスタックエンジニアになりつつあるので、HTTP2 も H2O も試していきたいなあと思う。
そのためにも使いたくなるようなサービスを作らねば。
はじめて生 miyagawa さんを見れたのもよかった。
よくよく考えると聞いてる Podcast の方々すべてのセッションに出てた。
ミーハー心丸出し。
これまでさんざんWeb界隈の方々に助けられてきたので、個人スポンサーした。
こういう試みいいと思う。
たくさんノベリティもいただいたし、実際元が取れてしまったのでは？という印象。
最後になりますが @lestrrat さん, @uzulla さんにはホテル予約のゴタゴタをサポートいただきました。
その節はお世話になりました。
たいへん助かりました！
@lestrrat @uzulla お騒がせしました。対応ありがとうございました！ / この件は「入金確認できた人には特に連絡していない」ということで解決。 / YAPC でホテル予約のキャンペーンに申し込み、たぶん振込したけど特にレスポンスがないのは安心していいんだろうか。
— kheiakiyama (@kheiakiyama) 2015, 8月 14
スタッフの方々、スピーカーの方々、みなさまお疲れさまでした。
素晴らしいイベントをありがとうございました！
パレタセラーナ・グランレセルバ【原木生ハム約4.5キロ・台・ナイフ付き】 生ハム原木カッティングセット
以前 Heroku から Sqale に移行した FeedlyGraph を DigitalOcean に移行したので、その経緯や作業を書く。
Sqale のデプロイが今ひとつ理解しがたく、うまくいかなくなったことがきっかけ。
Sqale のウリはサーバー管理が不要であることで、Rails アプリは git デプロイできるようになっている。
が、ruby のバージョンを変更しようと検証してから、git デプロイがうまく動かなくなった。
その後は毎回手動で bundle install やアプリケーションの起動をしなければならなかった。
しかも bundle install すると、HDD 容量 5GB を超えるために古いバージョンの Gem を手動で消したり・・・といった具合。
これでは PaaS でもなんでもない。
アプリケーションとしての Rails 初心者である僕が、なおさらよくわかっていないインフラ周りをいじるのはしんどい。
加えて Sqale の仕組みを理解する余裕は到底なかった。
Sqale が悪いというわけではない。
正しい使い方をすればうまく動くのだと思う。
ただ自分にはわからなかった。
PaaS 全般に言えることだが、自分で管理もできる人がそのコストを委譲するために利用する、というのが正解なんだと思う。
あとはポジティブな理由がこんなところ
ざっくり調べて、nginx + unicorn でホスティングするというのがスタンダードなやり方だというのがわかった。
それに沿った ansible の playbook の公開情報を探して、少しずつ試しながら構成を作っていった。
完成したのが以下。
GitHub で公開しているファイルでは、FeedlyGraph 独自の処理は除外してある。たとえば cron。
大体は hosts をいじれば事足りるはず。
playbook 作成にあたって主にお世話になったサイトをまとめておく。
ついでに ab でパフォーマンス検証してみた。
以下、 ab -n 2000 -c 100 http://yourhost.com で行った結果。
Server Software: ngx_openresty/1.2.6.6 Requests per second: 46.28 [#/sec] (mean) Time per request: 2160.926 [ms] (mean) Time per request: 21.609 [ms] (mean, across all concurrent requests) Transfer rate: 295.76 [Kbytes/sec] received
Server Software: nginx/1.8.0 Requests per second: 120.99 [#/sec] (mean) Time per request: 826.492 [ms] (mean) Time per request: 8.265 [ms] (mean, across all concurrent requests) Transfer rate: 766.74 [Kbytes/sec] received
マシンの性能自体は DigitalOcean に軍配が上がった。
ついでに rails server で起動した場合も試してみた。
Server Software: WEBrick/1.3.1 Requests per second: 87.30 [#/sec] (mean) Time per request: 1145.541 [ms] (mean) Time per request: 11.455 [ms] (mean, across all concurrent requests) Transfer rate: 554.13 [Kbytes/sec] received
やはり nginx + unicorn のほうがリクエストをさばく能力は高い模様。
Sqale は AWS の Tokyo リージョンを利用していると思われるため、レイテンシが有利。
それでも DigitalOcean はシンガポールを選べばそこまで遅いと感じることはなく、日本からの利用にも十分耐えられることがわかった。
また、ansible の playbook を作ったことで、ふと思い返していじるときでも、サーバーの見通しがつきやすくなった。
インフラをコード化するメリットはこういう面でもあると思う。
あとはコスト面。
サーバーの維持費が ¥940/month から $5/month になった。
やはり個人でサーバー持つには Windows はキツイ。Linux 一択だ。
最後にお詫び。
移行作業中に間違って Sqale にデプロイしてしまい、しばらくデータ取得が正しく行われていなかった模様。
利用者の方にはお詫び申し上げます。
