面白い仕事ってなんだろう

昨日飲みの席で同僚に仕事がつまらないという話をした。

その時には今所属しているプロダクトの将来性が見えない的な理由を言った。

今自分はブラウザゲームを運営している。

ネイティブゲームに押されPV・売上は減少傾向。

言い方は悪いがいずれ死にゆくプロダクトをどう延命させるかが至上命題

……じゃあ売上が増加傾向ならいいの？

うーん、それも違うなあ。ブラウザゲームの新プロにいったとしても今抱えているモヤモヤが解決されるとは思えない。

じゃあなんでつまらないと感じるのだろう。

結論からいうと自分が使いたいというサービスではないということが大きいのかなと思う。

ブラウザゲームはネイティブゲームに比べるとどうしても表現力・操作性・アクション性で劣ってしまい、勝てない。

自分が積極的にプレイしたいゲームにはどうしてもなれない。

……じゃあネイティブゲームに異動する？

確かにネイティブだったら今よりは楽しくなるんじゃないかなと思いつつも、結局問題は環境だけではなく、自分の中にもあると思う。

自分がどういうことをしているときに楽しかったかちょっと考えてみよう











…と久しぶりにブログ更新したかと思えば重いやつですいません。。

自転車で山手線１周してみた結果ｗｗｗｗｗｗｗｗｗｗ

チョーおもしろかった。またやりたい


タイムは4時間弱(1/5くらい信号待ちな気が)
記録はこちら(途中で電池切れた)
Shibuya Takahiroさんのアクティビティ (2013.12.21 | サイクリング | 38.29 km | 03:04:12)

恵比寿スタートで反時計周りに回りました。
タイムは意識せず、サイクリングを楽しむをテーマに走行。
スタートしたのは16時で着いたのは20時前でした。

感想

久々のサイクリングだったので上野あたりで心折れかけましたがなんとか完走できました。
駅ごとに特徴があるのでサイクリング中も飽きることなく楽しめました。
僕は夕方から夜にかけて走りましたが、時間帯によって見える景色全然違うんだろうなーと思いました。
また別の時間帯で挑戦してみたいです。

印象に残った場所

  • 大塚と池袋の間

なにがすごいってまわりソープ街だらけなんですよね。なんで俺はこんなところを自転車で走ってるんだろうって思うと同時にちょっと興奮しました。

  • 新大久保

ホテル街があるのでいろいろなカップルがいました。明らか出会い系で会ったなって人やアジア系の女性連れてる人とか。kzだなーと思いながら走り抜けました

  • 新宿と渋谷

あのすごい人混みの中走ったのはちょっとおもしろかった。あそこは自転車でいく場所ではないなと実感。

  • 東京

ちょうど中間地点だったこともあり、イルミネーションに飾られたキレイ駅をみることで達成感を得られました。

運動後の温泉とビール

最高です。生きててよかった。

山手線一周とは編集

さくらVPSにmoshいれてみた

moshいれてみました。ロックのライブでやるアレではなくmobile shellのことです。
伊藤直也さんいわく「快適なssh」とのことで、回線が不安定な所でもエコー遅延など全く気にせず使えるし、Mac をスリープさせて復帰させたときもリモートホストにそのまま繋がりっぱなしのように見せかけてくれたりする。らしいです。

近頃の開発環境 : Mosh、z、tmux、Emacs、Perl について

まずmoshのインストール

Mosh
クライアントとサーバー両方に入れる。クライアントはmacなのでpkgファイルで一発。
問題はサーバー。centosだとrpm用のパッケージが用意されていないのです。

$ git clone https://github.com/keithw/mosh
$ cd mosh/
$ ./autogen.sh

autoconfがないと怒られたのでいれる

$ cd /usr/local/src/
$ wget http://ftp.gnu.org/gnu/autoconf/autoconf-2.69.tar.gz
$ sudo wget http://ftp.gnu.org/gnu/autoconf/autoconf-2.69.tar.gz
$ sudo tar zxvf autoconf-2.69.tar.gz
$ cd autoconf-2.69
$ ./configure --prefix=/usr
$ sudo ./configure --prefix=/usr
$ sudo make
$ sudo make check
$ sudo make install

再度moshを入れようとすると今度はprotobufがないといわれたのでいれる

$ sudo wget https://protobuf.googlecode.com/files/protobuf-2.5.0.tar.gz
$ sudo tar zxvf protobuf-2.5.0.tar.gz
$ cd protobuf-2.5.0
$ sudo ./configure --prefix=/usr
$ sudo make
$ sudo make check
$ sudo make install

こんどこそmosh

$ ./configure
$ make
$ sudo make install

入った！

でもってサーバー側のポート60000と60001を開ける。

サーバー側でmoshを立ち上げる。

$ mosh-server
mosh-server: error while loading shared libraries: libprotobuf.so.8: cannot open shared object file: No such file or directory

といわれる。どうやらライブラリのパスが通ってないらしい。
bashrcにexport LD_LIBRARY_PATH=/usr/libを追加(そろそろzshにしたい…)。

$ mosh-server
MOSH CONNECT 60002 2ul5ETtQSA0Us3as+x9v5g

mosh-server (mosh 1.2.4a)
Copyright 2012 Keith Winstein
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

[mosh-server detached, pid = 21414]

いけた！でもこのサーバは60secアクセスしないと自動的に終了するそう。次にクライアントからmosh-clientでアクセスする。

$ MOSH_KEY=Sb4Lamc77YvSivMZWmMt1A mosh-client xxx.xxx.xxx.xxx 60001

入れた！
けど冗長すぎる…。
公式には

$ mosh chewbacca.norad.mil

で入れるって書いてあるけど、やると「mosh-server: error while loading shared libraries: libprotobuf.so.8: cannot open shared object file: No such file or directory」がでちゃうのよね…
ライブラリのパス通したのになぜだ…

追記

ldconfig打ったらできました！共有ライブラリを認識させるためには/etc/ld.so.confに追記するだけではなくldconfigコマンド打たなきゃいけなかったのですね…。
id:matsuboboさんありがとうございます！


参考文献

Sublime Text2でリモート先のファイルをサイドバーに表示させる方法

英語ですがここにのってます→Sublime SFTP Sidebar
上読めばわかるんですが日本語で書かれてるサイトがなかったので一応のせときます

＜追記＞
本格的にやるならsshfsでマウントしたほうが作業効率よいです

要約

  1. プラグイン「SFTP」をいれる
  2. 再起動してSFTPを有効にする
  3. ローカル上に同期用のディレクトリを作成する
  4. ２で作成したディレクトリをSublime Text2のサイドバーに表示させる
  5. サイドバーに表示されたディレクトリを右クリック→SFTP/FTP→Map to Remote
  6. リモートのconfigファイル作成＆保存
  7. サイドバーのディレクトリを右クリック→SFTP/FTP→Sync Remote -> Local
  8. configで指定したディレクトリ以下のファイルがすべてローカルに同期されます。

※間違っても「Local -> Sync Remote」にしないように！リモート先が空ディレクトリになっちゃうよ＞＜

configのオプションでupload_on_saveをtrueにすると保存と同時に同期(アップロード)され、sync_down_on_openをtrueにするとファイルを開くと同時にダウンロードされます。

リーダブルコード〜コードの再構成〜

無関係の下位問題を抽出する

  • 関数やコードブロックを見て「このコードの高レベルの目標は何か？」と自問する
  • コードの各行に対して「高レベルの目標に直接的に効果があるのか？あるいは、無関係の下位問題を解決しているのか？」と自問する
  • 無関係の下位問題を解決しているコードが相当量あれば抽出して別の関数にする
例
  • 高レベルの目標：与えられた地点から最も近い場所を見つける」
  • 「２つの地点(緯度経度)の距離を算出する
  • 関数に置き換える
汎用コードをたくさんつくる
  • 無関係の下位問題はutilディレクトリを用意しよう

一度に１つのことを

  • コードは１つずつタスクを行うようにしなければならない
  • 手順
    • コード行なっているタスクを列挙
    • タスクをできるだけ異なる関数に分割する

リーダブルコード〜表面上の改善〜

名前に情報を詰め込む

明確な単語を選ぶ
  • getはあまり明確でない。
    • GetPage(url)ではどこからとってきたのかわからないのでインターネットからとってくるならFetchPageやDownloadPageにする
  • size
    • HeightやNumNodes、MemoryBytesのように具体的にする
  • シソーラスを使ってもっといい名前がないかさがしてみよう
tmpやretvalなどの汎用的な名前を避ける
  • tmp_fileのようにする
  • 一時的な保存でなければtmp自体使用禁止
  • ループイテレータ
    • i、j、kではわかりにくいときがあるので、culb_i、members_i、users_iのようにする
    • もっと簡潔にci、mi、uiでもよい
名前に情報を追加する
  • idのフォーマットが大切ならidでなくhex_idに
  • 単位がミリ秒ならstart_ms
  • その他の例
    • password→palaintext_password(処理を剃る前に暗号化が必要なことがわかる)
    • comment→unescaped_comment(表示するまえにエスケープする必要あり)
    • html→html_utf8
    • data→data_urlenc
  • すべてに追加するのではなくバグになりそうなとこにだけ追加
スコープの大きな変数には長い名前をつける
  • 短い名前はスコープが数行の変数につけるべき
名前のフォーマットで情報を伝える
  • メンバ変数なら末尾にアンダースコアを加えるなど(例：offset_)

誤解されない名前

例：filter()
  • 選択するならselect、除外ならexclude
例：Clip(text, length)
  • 最後からlength文字削除する場合remove、最大length文字切り詰める場合truncate
  • lengthもmax_lengthに
    • バイト数か文字数か単語数かわからないのでmax_charsにするべき
範囲を指定するときはfirstとlastを使う
包含/排他的範囲にはbeginとendを使う(イベントの開始時刻、終了時刻など)
ブール値の名前
  • is、has、can、shouldなどをつけることが多い
ユーザーの期待に合わせる
  • 平均値を取得するメソッド名にgetMeanはよくない
    • getMeanがその場で平均値を計算する実装でコストが高かったとしても、ユーザーはgetMeanを呼び出してしまう
    • computeMeanのほうがよい
    • list.size()もcountSizeやcountElementsのほうがよい

美しさ

本に載ってるコード例を見よ

貫性のある簡潔な改行位置
メソッドを使った整列
縦の線をまっすぐに
一貫性を意味のある並び
  • 例
    • inputフィールドと同じ並び順にする
    • 最重要なものから重要度順
    • アルファベット順
宣言をブロックにまとめる

コメントすべきことを知る

すべきではないこと
  • コードを読んですぐわかることをコメントに書かない
  • 名前がひどければコメントをつけずに名前を変えろ
自分の考えを記録する
  • 例
    • 「このクラスは汚くなってきている。サブクラスResourceNodeを作って整理したほうがいいかもしれない」
  • コードの欠陥にコメントをつける
    • TODO: (あとでてをつける)
    • FIXME: (既知の不具合があるコード)
    • HACK: (あまりキレイじゃない解決策)
    • XXX: (危険！大きな問題がある)
定数にコメントをつける
  • 値を設定した理由などをかく
読み手の立場になって考える
  • コードを読んだ人が「え？」と思うところにコメント
  • ファイルやクラスには全体像のコメントを書く
  • コードブロックに概要を

コメントは正確で簡潔に

代名詞は避ける
関数の動作を正確に記述
入出力のコーナーケースに実例を使う
コードの意図をかく
  • 「listを逆順にイテレートする」ではなく、「値段の高い順に表示する」に