UPQ Phone A01 ホワイトが届いたので開封の儀

何かと話題が多い UPQスマホ、UPQ Phone A01 が届いたので開封の儀をはじめる。


www.dmm.com


箱は白を基調としてグリーンがアクセントカラーとなっている。
端末の色と同じ色なんだろうか。




箱を開けてみたところ。
iPhone以外のスマホ開けたことないけど、大体同じような構成だなあ。




付属品を全部出してみた。

  • 端末
  • USB充電器
  • ACアダプタ
  • 充電パック
  • クイックスタートガイド
  • 保証書




SIMカードやSDカードは用意してないが、充電バックを入れないと始まらないので端末をオープン。
リアカバーを開けたところ。
無理に開けようとすると平気で曲がりそうなので、落ち着いて爪で少しずつ開ける。




あとは電源をつけるだけ!!
起動直後はこんな感じ。




本体のストレージ容量は8GBだが、うち4.5GBが埋まっていた。
SDカード挿せばいいし、まあこんなもんでしょ。


f:id:khei-fuji:20150923215221p:plain



ということで開封の儀は終わり。


レビューについてはしばらく使ってからまとめることにする。
それにしても Android 童貞の自分には、スクリーンショットの取り方すらわからなくていろいろツライ。


アプリを作ろう!  Android入門 Android Studio版 Android5対応

アプリを作ろう! Android入門 Android Studio版 Android5対応

Electron が流行りつつあるけど何が嬉しいのかの予測

はじめに

先日の YAPC で一躍注目を集めた Electron

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入門 (アスキー書籍)

サーバサイドJavaScript Node.js入門 (アスキー書籍)

YAPC::Asia 2015 参加レポート

ブログを書くまでが YAPC::Asia ということなので、書きます。


esa.io

esa.io - 趣味から育てたWebサービスで生きていく // Speaker Deck


このセッションで勇気づけられた。
趣味が高じてシゴトになった、というシンデレラ・ストーリー。


実際 esa.io は使ったことがあるけどすごくよく、他の利用者も好評だった。
(ただギョームで導入する説得材料が弱くて試用期間でやめてしまった・・・すいません。)



esa.io はフィードバックの早さも好感が持てるし、
上のアイコンを見てわかるとおり、何より可愛い!
可愛いは正義!
(中の人が「トリっぽく演じてます」って話してたけど)


印象に残った発言。
「いろんなことを試していてたまたまうまくいったのが esa だった。」
趣味プログラミングを昇華させるにはもっと数を打つことだ。


HTTP2

HTTP/2時代のウェブサイト設計

HTTP2 時代の Web - web over http2


21, 22日と連続で行われた HTTP2 のセッション。
2つの構成は似ていたけど、講演者の得意分野が(たぶん)違うこともあり、フォーカスするポイントが違って理解が深まった。


個人的に気になったのは、趣味で作るサービスでも HTTP2 を使うようになっていくのかなーという点。
証明書の問題もあるけどサーバー料金も負荷という点で負担にならないかが気になる。


フロントからサーバー管理まで、浅いレベルでフルスタックエンジニアになりつつあるので、HTTP2 も H2O も試していきたいなあと思う。
そのためにも使いたくなるようなサービスを作らねば。


有名な方々

はじめて生 miyagawa さんを見れたのもよかった。
よくよく考えると聞いてる Podcast の方々すべてのセッションに出てた。
ミーハー心丸出し。

  • Rebuild.fm
  • Mozaic.fm
  • だんごゆっけの平和な話


最後に

これまでさんざんWeb界隈の方々に助けられてきたので、個人スポンサーした。
こういう試みいいと思う。
たくさんノベリティもいただいたし、実際元が取れてしまったのでは?という印象。


最後になりますが @lestrrat さん, @uzulla さんにはホテル予約のゴタゴタをサポートいただきました。
その節はお世話になりました。
たいへん助かりました!


スタッフの方々、スピーカーの方々、みなさまお疲れさまでした。
素晴らしいイベントをありがとうございました!


Rails でつくった FeedlyGraph を Sqale から DigitalOcean に移行した

はじめに

以前 Heroku から Sqale に移行した FeedlyGraph を DigitalOcean に移行したので、その経緯や作業を書く。


移行の経緯

Sqale のデプロイが今ひとつ理解しがたく、うまくいかなくなったことがきっかけ。
Sqale のウリはサーバー管理が不要であることで、Rails アプリは git デプロイできるようになっている。
が、ruby のバージョンを変更しようと検証してから、git デプロイがうまく動かなくなった。


その後は毎回手動で bundle install やアプリケーションの起動をしなければならなかった。
しかも bundle install すると、HDD 容量 5GB を超えるために古いバージョンの Gem を手動で消したり・・・といった具合。
これでは PaaS でもなんでもない。


アプリケーションとしての Rails 初心者である僕が、なおさらよくわかっていないインフラ周りをいじるのはしんどい。
加えて Sqale の仕組みを理解する余裕は到底なかった。


Sqale が悪いというわけではない。
正しい使い方をすればうまく動くのだと思う。
ただ自分にはわからなかった。
PaaS 全般に言えることだが、自分で管理もできる人がそのコストを委譲するために利用する、というのが正解なんだと思う。


あとはポジティブな理由がこんなところ

  • DigitalOcean を使ってみたかった
  • ギョームで使い始めた ansible を使いたかった


移行作業

ざっくり調べて、nginx + unicornホスティングするというのがスタンダードなやり方だというのがわかった。
それに沿った ansible の playbook の公開情報を探して、少しずつ試しながら構成を作っていった。
完成したのが以下。

github.com

GitHub で公開しているファイルでは、FeedlyGraph 独自の処理は除外してある。たとえば cron。

大体は hosts をいじれば事足りるはず。


参考資料

playbook 作成にあたって主にお世話になったサイトをまとめておく。

ansible の基本構成

iptables 周辺

トラブルシューティング


検証

ついでに ab でパフォーマンス検証してみた。

以下、 ab -n 2000 -c 100 http://yourhost.com で行った結果。

Sqale

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


DigitalOcean(nginx)

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 に軍配が上がった。


DigitalOcean(WEBrick)

ついでに 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 にデプロイしてしまい、しばらくデータ取得が正しく行われていなかった模様。

f:id:khei-fuji:20150816133236p:plain

利用者の方にはお詫び申し上げます。


入門Ansible

入門Ansible


MacBookPro を掃除した

はじめに

夏の暑さのためか、MacBookPro 2014 mid のファンがよく回るようになってきた。

気付けば購入してから、もうすぐ1年。

kheiakiyama.hateblo.jp

3年保証の AppleCare Protection Plan に入ってないため、保証はもうじき切れる。
それならカバーを開けて掃除しても失うものはないので、掃除した。


MacBook のネジ穴は通常のプラス・マイナスドライバーでは回らないため、専用のドライバーが必要。


掃除の手順

Mac の電源を落としてひっくり返す。

f:id:khei-fuji:20150801181023j:plain


ドライバーで10個のネジをすべて外す。

f:id:khei-fuji:20150801181244j:plain


カバーを開ける。
内側に接着箇所がいくつかあるらしく、ネジを全て外してもすんなりカバーは開かなかった。
排気口からドライバーを差し込んで、円を描くように少しずつ接着面をはがしていった。

f:id:khei-fuji:20150801182137j:plain


ホコリを取る。 エアダスターがあればなおよい。
一応、下の写真は掃除後だが、特に変わった様子はない。

f:id:khei-fuji:20150801181534j:plain


あとは外したときと同じ要領でネジを全てつければOK。


おわりに

1年は短いのか、使用環境がいいのか、それほどホコリが溜まっていたわけではなかった。
効果のほどもさほどなく、動画再生したらほどなくファンが回り始めた。
掃除も大事だけど、冷房が大事みたいだ。
こういうのも効果があるのかな?


【日本正規代理店品】Just Mobile Lazy Couch アルミニウム製ノートPC冷却スタンド JTM-ST-000001

【日本正規代理店品】Just Mobile Lazy Couch アルミニウム製ノートPC冷却スタンド JTM-ST-000001


スプラトゥーンを周回遅れで始めた人が上手い人に追いつくための方法

はじめに

僕のスペックを晒しておく。
ゲーム歴は PS2 が最後。

先月の Amazon のキャンペーンWiiU とスプラトゥーンを同時購入。今日でちょうど1ヶ月。

ウデマエは B+。
2週間前までは C+ で停滞してたが、そこからじわじわ上がってきたので、そのあたりをまとめる。


上手くなるためにやったこと

ヒーローモードのクリア

いわゆるストーリーモード。
基本的な操作を覚えるために開発者が用意してくれたものなのだから、やっておくに越したことはない、という思考でやった。
ブキも増えるし。


プレイ動画を見て真似る

ここが一番キモだと思う。
我流で上手くなるよりも、上手い人の真似をしたほうが上手くなる速度が早い。
僕は時間が豊富にある学生やフリーターではないので、最短距離を行きたい。


ニコ動のランキング上位の動画をチェックして、それからプレイする。
上手いプレイを見ると単純に面白いし、動きを見てると自分もできそうな気になってくる。
もちろんそんなに簡単ではないが、ちょっとずつ近づいている感覚はある。


動画は自分がよく使うブキに限らず、いろんなブキの動画を見ることにしている。
自分が使わないブキでは、「どういうプレイが嫌がられるか」がわかる。

過去に見てきた動画はこんな具合。


いろんなブキを使う

一通りのブキは使ってみることをオススメする。
もちろん得意なブキはあるとは思う。
自分の場合はシューターが得意でわかばシューター一択。


動画のところにも書いたけど、いろんなブキを使わないと「イヤな動き」がわからない。
スプラトゥーンでは、初心者の最初の壁を乗り越えるには「死なずに生き続けること」が大事なので、生存確率を高める動きを身につけたい。
そのためにもどういう動きをされたときに自分がやられるかがわかってくると、同じブキを相手にしたときに役に立つ。


おわりに

ということで、勉強やブログ更新をさぼっていた原因の7割を占めるスプラトゥーンについての記事を始めて書いた。
それではゲームに戻ろう。


そんなん言っているうちに A- に上がった。


Splatoon(スプラトゥーン)

Splatoon(スプラトゥーン)

開発現場をどのように改善するか

というテーマで社内勉強会をしたので、そのときのことを書いておく。


発表

speakerdeck.com

開発者をはじめてからの10年間で改善してきたことをまとめた資料。
あとはプロジェクトの経歴をまとめれば自分のエンジニア年表ができるので、自分にとっていい資料になった。


後日談

当日は自分の発表内容そのものというより、参加者が気になったことを聞き出してその周辺の話題を広げていく雑談形式で進めた。
結果、盛り上がった。


が、盛り上がればいいというわけではない。
監督者からすると、発表者の影響を受けた誰かが何らかの行動に結びつかないとならない。
これは発表者のコントロールできる範囲を超えているために、やるせなさを感じて社内勉強会を次第にやらなくなってしまう部分だと思う。


結局できることは、楽しい雰囲気を感じてもらって、自分もそうなりたいと思ってもらうしかない。
いっそ「楽しさ」に焦点を絞って、テクニカルな話を全くしなくてもいいのではないかという実験をしてみてもいいけど、どうせ開発者ならテクニカルな話題で盛り上がりたいなあと思う。