$shibayu36->blog;

プログラミングの話や自分の考えを色々と書いています。特にperl、emacsや読んだ本の話が多いです。

iphone帯域制限された

土曜にカフェでひたすらkindleの漫画を読んでいたら、1日1GBを超えると三日間帯域制限されるというのに引っかかったらしく、むちゃくちゃ遅いインターネットをiphoneで経験している。

そもそも帯域制限がかかってるということに気づくまでが長くて

  • なぜかインターネットが非常に重いという体験をする
  • 何度もその体験を繰り返して、これはおかしいと思う
  • 帯域制限を疑って、1ヶ月7GB使ってないか確かめるが、1GBくらいしか使ってなかった
  • 1日待ってみるもののやはりおかしい
  • スピードチェックしてみると、体感だけでなくほとんど速度出てないことが分かる
  • 問い合わせることでようやく1日1GBという制限があることを知る

という感じだった。

適切なフィードバックがあれば、こんなフローなしで気づけたはずなので、なんらかのフィードバックが欲しかった、という気持ちになった。サービス作るときには気をつけたい。

Hubot + Heroku + Slack

Hubot触ってみようと思って、いろいろ動かして見たのでメモ。

Hubotのrepositoryを作る

https://github.com/github/hubot/tree/master/docs これのとおりに

hubot --create shibabot

とかすると作れる。

bin/hubot

とかして動けばひとまず良い。

Slackで動かすためにHerokuにデプロイする

SlackでHubotを動かすためには、

  • Hubot側でSlackのHubot Integrationのtokenなどを設定する
  • Slack側で、Hubotにメッセージを送るためのURLを指定する

の2つが必要。Slack側でURLを指定するために、どこかにデプロイするか、もしくは手元で動かしたのを外から見えるようにする必要がある。Herokuにデプロイするのが難しくなく、かつ無料分で可能なので、そちらで動かす。だいたいのことは https://github.com/tinyspeck/hubot-slack に書いてあるのでそれを参照すれば良い。

まずはSlack側でhubotのintegrationを有効にする。Add New IntegrationしてHubot選択すれば出来るはず。するとHUBOT_SLACK_TOKEN, HUBOT_SLACK_TEAMというのが現れるので、ひとまずhubot側の設定用にこれをメモしておく。

続いてHubotをHerokuで動かせるように設定する。これは、https://github.com/tinyspeck/hubot-slack#deploying-to-heroku を見ればすぐにできるはず。上でメモした情報を利用してherokuの環境変数とかを設定すればよいだけ。途中でHEROKU_URLを設定しているのは、hubotがidlingしないようにするためらしい。

最後にデプロイ先のURLをSlack側のHubot URLというところに埋めれば良い。例えばデプロイしたherokuのURLがhttp://soothing-mists-4567.herokuapp.comであれば、それを埋める。
f:id:shiba_yu36:20140915144235p:plain

ここまででうまく行っていれば、設定したSlack上でhubot helpとかコマンドを打つと返信してくれるはず。そしたらひとまず完成。もしうまく行ってなかったとすると、何か設定ミスなので、herokuのlogとかを見ると解決できるはず。以下のようなコマンドを打つと、herokuで動いているアプリのlogを出してくれる。

heroku logs

僕は最初Hubot URLにpathの/hubot/slack-webhookまで含めてしまい、おかしくなっていたのをログを見て解決できた。

まとめ

  • SlackでHubotを動かすには、メッセージを受け取る先のURLを指定しないといけない(最初はまった)
    • どこかにデプロイするか何かする必要がある
  • Hubotをherokuで動かすのは無料かつ簡単で便利

「初速思考」を読んだ

初速思考 30代で一気に突き抜ける人の集中戦略

初速思考 30代で一気に突き抜ける人の集中戦略

初速思考という本を読んだ。この本は「目に見える結果をまず出す」というのにこだわったほうがいいみたいなことが書いてあって、その方法についていろいろ書かれている本のようだった。


面白いと思ったことはあんまりなかったのだけど、日々感じたことを1行で記録するって話だけ参考になると思った。日々のことを記録していき、次の手順で次の行動に繋げるという話。

  • 日々感じたことを1行でいいのでノートとかに記録しておく
    • たまたま書店で手にとった本を読んで実践したらすぐに役立った、とか
  • その体験から考えられる次の行動を書いておく
    • 忙しい時でも自分で知りたい内容を、本からピンポイントで学ぶだけで対策の一手が打てる

みたいなこと。大抵良かった悪かったで終わるとそのまま次も変わらず過ごしてしまうけど、次のアクションまで落としこんでおけると良いなと思った。これはKPTでTryをちゃんと出すみたいな話にも繋がりそう。例えば1行メモを取っておいて2週間に一回直近のものを眺めて自分だけでKPTを洗い出すってやり方とかもありそうと思った。


最近ひとまず忙しくて何も出来ない状態みたいな感じになりそうだったので、それに関係しそうな本をとりあえず読んでいった。だいぶ落ち着いてきたので、次にインバスケット思考的な本を読んだら一段落という感じになりそう。

Google SpreadsheetとQuery Language

Google Spreadsheetを使ってたら、Query Languageというのがあるということに気づいて非常に便利だったのでメモ。

Query Language Reference (Version 0.7) - Google Charts — Google Developers

Query LanguageというのはGoogle Spreadsheetの内容をSQLっぽい文法で絞り込んだり計算したりできるもの。

例として非常に雑な例を出すと、
f:id:shiba_yu36:20140913121221p:plain

  • 簡単なTODOリストをおいている
  • Sattus, Task名, 締切が書いてある
  • 「TODO全体」というシートに書かれている

というようなシートがあるとする。

このシートから

  • 別シートに、DOING状態になっているタスクを日付順に抜き出したい
  • 別シートに、Due dateを超えたタスクを抜き出したい

という2つのことをやりたいとすると、Query Languageで行うことができる。

別シートに、DOING状態になっているタスクを日付順に抜き出したい

別シートにDoingという名前を付けて、A1セルに以下のような文を書くと実現できる。

=QUERY('TODO全体'!A:C, "select * where A = 'DOING' order by C asc", -1)

f:id:shiba_yu36:20140913121235p:plain

1引数目に書いてあるのは、どのシートのどの範囲を対象にするかで、2引数目に書いてあるのはSQLっぽい文法でwhereとかで絞り込み、order byで並べ替えしてる。A列がstatusなのでDOINGで絞り込み、C列がDue dateなので昇順で並べ替えることで、実現できた。

別シートに、Due dateを超えたタスクを抜き出したい

これは現在の日付を取得するnow()と、それを日付に変換するtoDate()を利用するとできそうなのでやってみた。

別シートを作り、A1に以下のクエリを書く。

=QUERY('TODO全体'!A:C, "select * where C <= toDate(now())", -1)

f:id:shiba_yu36:20140913121029p:plain

すると上のようになった。普通にうまく行きそうだったが、なぜかうまく行かなかった。軽く理由を調べてみるとなぜかnow()関数が返す値が一ヶ月後の値になっていて、それにより今より1ヶ月後より前が抜き出されるみたいな結果になった。この部分についてはいろいろ調べてみたけどよく分からずうまく行ってない。ちなみにmonth(now())の値は一ヶ月後でなく当月の値になって、さらに分からなかった。普通にバグ??

まとめ

SQLっぽいのかけるといろいろ出来て便利。もちろん今回みたいな感じ以外でも普通にSUMとかAVGとか、group byでのグルーピングとかいろんな関数あるので、もうちょっといろいろできるはず。普通に数字が入っている表を簡単に集計したりするには便利そうだった。

「Googleアナリティクス 実践Webサイト分析入門」読んだ

読んだ。Googleアナリティクスの勉強はちょくちょくしているけど、機能が多すぎていまいち使いこなせない。この本を見ていると、本当にいろいろ機能あるんだなということが分かる。

自社製品のランディングページとか、自社で作るニュースサイトとかを運営していると、直接的に参考になりそう。大体これ読みながら実践すれば良さそうだった。基本的には流し読みしておいて使えそうなものをメモし、あとからリファレンス的に参照すると良さそう。

「イシューからはじめよ」を読んだ

最近やることがたくさんあってどうしたら良いか分からなかったので、同僚の薦めもあって「イシューからはじめよ」を読んだ。結構面白かった。

イシューからはじめよ―知的生産の「シンプルな本質」

イシューからはじめよ―知的生産の「シンプルな本質」

この本には、やるべきことがたくさんあった時に、タスクをやる効率をどんどん上げていくという方向にまず走るのではなく、その中で重要なイシューを見極めてそれを重点的に取り組むべきである、というようなことが書かれていた。とにかくやるのではなく、まずやることを見極めよみたいな感じ。確かに忙しい時はとにかくやるとなりがちだけど、とにかくやっててもあんまり成果が上がらないことがあるので、まず見極めないといけないと思った。

この本の中で

  • 悩まずに考える
  • 「これは何に答えを出すものなのか」を明確にしてから問題に取り組む
  • 一次情報を死守

という言葉が印象に残ったので、それについて書く。

悩まずに考える

この本の中に、悩むと考えることは違うことで、悩むのではなく考えるべきだと書かれてあった。

この本では、

  • 悩む = 答えが出ない前提で「考えているふり」をすること
  • 考える = 答えが出る前提で、建設的に考えること

という風に定義付けていて、違いは答えが出るか出ないかというところにある。


自分を省みてみると、最近は単にぼんやりと「何かがうまくいってない、困った」とか思っているだけで、実際にそれに対して考えているつもりだったけど、答えを出そうとしていたわけではなくて単に落ち込んでいるだけみたいな感じだったので、今から考えると単に悩んでいただけなんだなと思った。

また、10分ほど考えて埒が明かないようであればそれは悩んでいる可能性が高いので、一度考えるのを止めたほうがいい、と書いてあって、悩んでるのか考えているのかよく判断できない時点ではこういう基準を持っておき判断するのは良いなと思った。

「これは何に答えを出すものなのか」を明確にしてから問題に取り組む

何かを行う前に、必ず「これは何に答えを出すものなのか」を明確にしてから問題に取り組んだほうがいいと書いてあった。これは上で書いた悩むな考えろみたいなのとつながるところがあって、先に何の答えをだそうとしているのか意識しておくことで、自然と悩むというところにいかなくなりそうと思った。

実際に仕事でも、なにかやり始めたはいいものの時間が経つにつれ、その目的が見失われ、ただTODOだけが残るということがある。例えば、今の導線などでは初心者ユーザが最初に何をすべきか見失うことを解消するために、サイトリニューアルをしようとと思い立った時に、それを明確にしておかないと最終的にサイトリニューアルというTODOだけが残り、目的が見失われるというような感じ。

タスクの大小はあるけど、どのようなものでも、「目的が初めから無い」は避けたいし、「目的が見失われる」のも避けたい。そのため、必ず「これは何に答えを出すものなのか」を明確にしてから問題に取り組むにしたい。

一次情報を死守

何をするか見極めるため、もしくはイシューに対して良いアウトプットを出すために、必ず誰にもフィルタされていない一次情報を死守するべきだと書いてあった。現場で何が起こってるか見て肌で感じないと、そもそも理解できないような事柄があるので、そうするべきだということらしい。

一次情報というのは、例えば

  • Webサービスを作っている場合、そのユーザへのインタビューとか
  • 企業向けサービスを作っている場合、顧客へのインタビューとか

などがあたり、他の人がまとめたレポートとかは二次的情報にあたる。


レポートとか報告とかそういうのを見ただけで「分かった気になる」ということが、たまにある気がしたので、これは気をつけないといけないと思った。

まとめ

これまで自分は変に全部きちんとやろうとしすぎて忙しくなっていると思った。ちゃんとやることを絞れていると思ってたけど、そうではなかったのかも。これからそのあたりを軽減するために、タスクをこなす前に見極めるという姿勢を取っていこうと思った。

他に近いネタを扱っているように見えたインバスケット思考の本や、他にもおすすめされた初速思考って本も読んでみたい。

初速思考 30代で一気に突き抜ける人の集中戦略

初速思考 30代で一気に突き抜ける人の集中戦略

twitter
hatena
rss
Social Icon ブログパーツ