WiiUとスプラトゥーンなどを買取してもらってきた

2015/6 にやっていたAmazonWiiUとスプラトゥーンのセット¥1,500割引セール。
そのときの購入から9カ月。

今はもう惰性で遊んでしまうので買取してもらってきた。
買取は地元のゲオに依頼。

WiiU本体は初期化と掃除済み。
そういえばWiiリモコンや付属のマリオカートは一切触らなかった。

買取価格

カッコ内は購入時の価格。


ざっくり、¥42,000 払って ¥36,000 返ってきた。
プレイ時間見ておくの忘れたけど、ゼノブレイドはエンディング時点で100時間だったし、スプラトゥーンはそれより少ないはずがない。
9カ月十分遊んでこれだけ戻ってくるのはかなりコスパのいい買い物だったのではないか。


スプラトゥーン from:kheiakiyama - Twitter Search

またこういうお祭りに参加したいな。

Splatoon (スプラトゥーン)

Splatoon (スプラトゥーン)


翔泳社のセールやってたので衝動買い

セールしてる!

www.shoeisha.co.jp


最近 Kindle 読んでないけど衝動買いした。
時間があるときに読んでみよう。
以下、買った本。


TCP/IPの絵本 ネットワークが面白くなる9つの扉

TCP/IPの絵本 ネットワークが面白くなる9つの扉

イノベーションのジレンマ 増補改訂版 Harvard business school press

イノベーションのジレンマ 増補改訂版 Harvard business school press

あなたのチームは、機能してますか?

あなたのチームは、機能してますか?

新エバンジェリスト養成講座

新エバンジェリスト養成講座

達人に学ぶDB設計 徹底指南書

達人に学ぶDB設計 徹底指南書

というアフィ記事。

初心者と PullRequest 駆動開発

Web界隈からすると今さらに見えるかもしれない。
職場で PullRequest 駆動開発に近い状況を作れないだろうか、と一部のプロジェクトで検証したり、広めたりしている。


まず言えるのはこれで効率が何倍にも高まるわけではないということ。
細切れの時間でもパフォーマンスが下がりづらくなるというのが効果だと思う。
いくつかのシステムを横断的に見る役割を担っているが、1日の中でシステムを行ったり来たりするとしんどい。
この、いわゆるコンテキストスイッチが緩和される。
リモートワークでもこれは顕著。たまの出張でもあまり差が出ない。


ここに挙げたメリットは、今の自分ならそれなりに感じられる。
しかし初心者にとっては正直効率がよくない。


それは PullRequest を送るまでの流れにある。
おおまかに分解すると以下のとおり。

  1. 期待結果を検討する
  2. テストを書く
  3. 実装する


そこそこの開発者であれば、これらの作業中に誰かに相談することは1回くらいで済むだろう。(もちろん規模にもよる)
これが初心者の場合は5, 6回と何度も手戻ることがありえる。
PullRequest を上げるころには、周囲の開発者がレビューを見なくとも内容をすべて理解しているということもざらだ。
初心者が多いチームでは手間を増やしてしまうだけに過ぎない。
ペアプロなどもっと密に作業して、早く「そこそこの開発者」になってもらうことを目指したほうがお互いのためだ。


まとめよう。
どのような状況であれば PullRequest 駆動開発が効果を発揮するか。
チーム内にそこそこの開発者が揃っていること。
細切れの時間が発生しやすい開発者が多いこと。


もちろん作業がワークフロー化されて理解しやすい、CI との相性がいい、といった効果もある。
しかし技術面に注目しすぎで、上にあげたような人の側面を忘れてはならないと思った。


GitHub実践入門 ~Pull Requestによる開発の変革 (WEB+DB PRESS plus)

GitHub実践入門 ~Pull Requestによる開発の変革 (WEB+DB PRESS plus)

ピープルウエア 第3版

ピープルウエア 第3版

Amazon のまとめて発送が効かないので理由を妄想した

僕は 2年くらい前から Amazon のプレミア会員だ。
配送料は無料だし、注文すれば翌日届く。


ただ、Amazon での注文は「まとめて発送」オプションをよく利用する。
というのも、Amazon ヘビーユーザーとしては宅配便事業者の方々には感謝していて、最近の ヤマト運輸の意見広告 なども見ていると応援したい気持ちになるからだ。


しかし、残念ながらほとんどのケースで個別に発送される。
これはなぜだろうか?


ググった限りでは商品の配送センターの違いによってまとめることができず、分割発送されてしまうことがあるらしい。
顧客重視の姿勢はもっともだが、少なくとも僕はそれほど早い配送を望んでいないことが大半だ。
ひょっとして Amazon は個別配送したい理由があるのではないか?


Amazon の送料無料は、Amazon が大量の流通と引き換えに、僕らのような個人よりもはるかに低い単価で宅配便事業者(今はクロネコ?)に依頼することで成り立っている。
スケールメリットというやつだ。


おそらくこのパッケージの数が Amazon にとっての取引材料になるのではないだろうか。
うまくまとめて1000個依頼するより、個別に3000個依頼するほうが、宅配便事業者との交渉を有利に運べる。
そういうことではないか。


これが事実だとすれば Amazon は配送センターを最適化しても、発送処理を最適化しないのにはうなずける。
最適なパッケージを考える必要もないので、ダンボールがムダに大きいままでも放置される。

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


どうだろうか。
理由はわからない。


こうして宅配便事業者のためだなんて主張すると怪しいが、
単純に何個もダンボールを開けるのは面倒だし、資源ゴミも増えるのがイヤだという面もある。
ユーザエクスペリエンスの向上のためにもどうにかしてもらえないだろうか。


ジェフ・ベゾス 果てなき野望?アマゾンを創った無敵の奇才経営者

ジェフ・ベゾス 果てなき野望?アマゾンを創った無敵の奇才経営者


RaspberryPi2 を初めていじってつまづいたところ

ラズパイに限った話ではなく、Raspbian というか Debian を使いこなせてないための問題も含む。
普段 CentOS しか使わないために勝手が違って苦しんだ。

CentOS との違い

パッケージ管理が yum じゃない

apt-get 使おう

標準エディタが nano

変えよう

crontabを編集するエディタを変更するには - murapong's blog

vi がなんか違う

vim-tiny 使おう

初期設定

直接ログイン時に日本語の文字化け

SSH では関係ないけど直接つなぐので。

» 解決!Raspberry Piの日本語が四角の文字化けになった時の初歩ミス。|コワーキングスペース管理人のブログ

jfbterm を ~/.bashrc に入れたら SSH で接続できなくなったのはいい思い出。
なんで固まるのかがよくわかってないが放置した。

ネットつながらない

はじめは Mac と直接LANケーブル接続し、その後家のルータ越しに接続するようにした関係で設定がわからなくなった。
はじめから本番環境で設定するのがよい。


最後に

どんどんつまづこう。


つまづいたっていいじゃないか にんげんだもの


自宅の温度湿度を RaspberryPi2 でログ取り始めた

はじめに

自分のコンテキストを書いておく。
電子工作経験はほぼなし。
10年前、パトランプのXFD体験イベントに参加した先輩からデバイス完成品を譲ってもらったレベル。
たぶんそのイベントはこのへん
電子工作のウデマエは1といって差し支えないだろう。

準備

買ったものは以下のとおり

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

結果

ログはこんな感じで確認できる。

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

それぞれ温度と湿度。

サーバー代を惜しんで RaspberryPi2 内にログを残している。
そのためログは自宅内でしか確認できない。


RaspberryPi はリビングの一角に設置している。

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

手前に向かって生えているのがDHT22センサー。

手順

ざっくり以下のように行った。
詳細は後述。

  • 初期設定
  • センサー(DHT22/AM2302)取り付け
  • 温度湿度データ取得テスト
  • ログ保存
  • ログ取得

初期設定

ローカライズ

locale やタイムゾーンなどを日本に変更。
このあたりを参考に。
Raspberry Pi 2の文字コードを変更する(日本語の設定) - wide_snow’s blog

ネットワーク

巷では無線LANの事例が多いが、ケチって RaspberryPi2 は有線LANで利用する。

スターターキットでは etc/network/interfacesdhcp ではなく manual に設定されていたため、自分で一度 dhcp に変更した。
その際は問題が起きたが以下の記事によって解決した。
linux - DHCP failure when rebooting RPI 2 - Super User

その後static に変更して終わり。
Raspberry Pi 2 IPアドレスを固定(有線LAN)にする - カタカタブログ

センサー(DHT22/AM2302)取り付け

ケーブルなどを細かく買うのが煩わしかったので、買ったのはモジュール化済みの DHT22。

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

DHT22や互換性があるDHT11の情報はググれば多い。
が、モジュール化されたものの情報は見つからず、どう接続したらいいかわからなかった。
そこで基本をおさえることに。
下記サイトが大変わかりやすかった。

Raspberry Piで電子工作!Lチカ…の前にLピカ! | Device Plus - デバプラ


RaspberryPi のような機器では大きく分けて3つの接続先が用意されている。
電源、アース、入出力だ。
モジュールの + は電源、- はアース、out は出力、ということでそれぞれ 1, 9, 7 に接続した。

温度湿度データ取得テスト

GitHub に公開されているスクリプトを使ってテストする。

adafruit/Adafruit_Python_DHT · GitHub

サンプルのスクリプト example/AdafruitDHT.py を実行すると以下の結果が得られた。

Temp=20.3*  Humidity=37.3%

このスクリプトは以下サイトから知った。
Raspberry pi + pubnub で温度と湿度のリアルタイムグラフ表示 | ネットワークエンジニアを目指して - ブログ

このスクリプトを後で流用する。

ログ保存

GrowthForecast を使ってログの蓄積・可視化を行っている。

導入はこのへんを参考にすれば大体解決。


GrowthForecast の起動スクリプトは雑だが下のような形に落ち着いた。

世の中の記事を見ると GrowthForecast が小数対応する前の情報が多いが、今なら --enable-float-number オプションで小数が使える。


このスクリプトSupervisor に呼び出してもらう。

Supervisor の導入についてはこちらを参考。

GrowthForecast を CentOS 6.3 にインストールして Supervisor で管理する - 彼女からは、おいちゃんと呼ばれています

ログ取得

データ蓄積は、前述の example/AdafruitDHT.py を真似たスクリプトを cron で実行し、結果を GrowthForecast に投げることで解決する。


Adatemp.py 22 4 の 22 は DHT22、4 は RaspberryPi の7番が GPIO 4 なのでそれを指定している。
ここで実行している Adatemp.pyAdahumit.py は、AdafruitDHT.pycp してつくったスクリプト
それぞれファイルの最後から2番目の print を以下のように書き換える。

print '{0:0.1f}'.format(temperature)
print '{0:0.1f}'.format(humidity)

あとは作成したスクリプトを cron で実行すればいい。

最後に

ここまでの作業はすべて1日以内で完了した。
連休でちょっと試してみるにはほどよい作業量だと思う。
これが1万円でできるなんてすごい世の中になったものだと実感。

今後やってみたいこと。

  • どうせなら屋外にも設置する
  • 定期的に自分にプッシュ通知する


興味を持った方は下から購入してもらえると嬉しい。


Raspberry Piスターターパック (Pi2 用Standard)

Raspberry Piスターターパック (Pi2 用Standard)

Electron で Slack 風UIの HipChat クライアントを作っている話

この記事は Electron Advent Calendar 2015 - Qiita の1日目の記事です。

ここ最近作っているアプリについてまとめる。


アプリについて

HipChat をギョームで使っているが、巷では Slack が流行しており、乗り換えたい願望が高まっている。
しかし乗り換えにはコストの面でハードルがある。


そこでSlack風味なHipChatクライアントがあれば面白いかもと、作っている。
ただ作るだけでは面白くないので、未経験だった技術(Electron, AngularJS, gulp)を使っている。



まだまだいろんな機能が足りてないが、ちょっとメッセージを送る程度には使える。
HipChat 公式クライアントは最後に開いたRoom(SlackでいうところのChannel)がデバイス間をまたいで微妙に同期する仕様。
別PCで少しRoomを開き、元のPCで見ると開いていた大量のRoomが勝手に閉じられたりする。
こういう問題を回避するのに有効。


余談だが HipChat Webクライアントのコンソールのログで採用募集しててウケた。

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

Electron と AngularJS との相性

元々よくなさそうという話は見かけていた。

既に語られてる部分は省略し、実感したよくないところを書く。

設計のコンフリクト

AngularJS を使うメリットの一つに、どういう機能はどこで実装すればいいかが迷わなくて済むというものがある。
一方、Electron ではレンダリングプロセスとバックグラウンドプロセスが存在しており、レンダリング以外の仕事はバックグラウンドに持っていくことが推奨されている。もちろん AngularJS はレンダリングプロセスに存在する。

つまり AngularJS と Electron が設計面でコンフリクトしており、お互いの良さを打ち消し合ってしまうことになる。
(HipSlack v0.0.1 ではよくわかっておらず、平気でレンダリングプロセスを使いまくっている)

データバインディングのあやしい挙動

リモートオブジェクトをバインディングに使うと、同じ controller にバインディングしている textarea の日本語IMEの挙動がおかしくなる。


f:id:khei-fuji:20151129172305g:plain

IMEの変換中の文字列がバインディングに取り込まれてしまっている模様。

最低限のコードをまとめたサンプル

自動化

最初はわけもわからず generator-angular から grunt を使ってた。
いざ自分でいじろうと思ったら意味がわからず、gulp でイチから書き直した。

とはいっても gulp のプラグインを組み合わせただけ。

  • gulp lint で構文チェック
  • gulp serve でビルド、Electron 起動
  • gulp package で製品のパッケージ作成

これくらいできれば十分。(テストは!?)
これから始めるなら grunt より gulp がいいと思う。

今後

ES6 or TypeScript

素の JavaScript を書くとツライのでどうにかしたほうがいい。

HipSlack の開発では VisualStudioCode を使っている。
Microsoft/vscode · GitHub をVisualStudioCode で開いてみたところ、TypeScript の関数定義の移動がかなり使いやすかった。
まさに VisualStudio の名を受け継いでいる感じ。
ということで TypeScript に傾きつつある。

Push通知

チャットアプリなのにリアルタイムに更新されないとかありえない。
HipChat には Webhooks が用意されているので、それを使って push 通知したい。

ChromeでW3C Push APIを使ってみた - Qiita を参考に実装していた。
が、現在の Chromium のバージョンが低くてムリっぽい。

Registration failed - push service not available

AngularJS を捨てる

Electron と AngularJS の相性がよくないと実感できた。
React あたりに置き換えるのがよさそう。
もともと AngularJS を触りたくてやってただけなので全くこだわりはない。

自動アップデート

手軽にできそうなので気になっている。
このへんとか。
jenslind/electron-gh-releases · GitHub

参考資料

お世話になった記事。

最後に

Electron は MS が採用してきたりと、いわゆるWeb系ではない人(僕みたいなエンタープライズ系)でも関わりやすい、面白い技術だと思う。
なのでいろんな人が手を動かしてみるといいんじゃないかな。


明日は Quramy さんです。