pythonからslackのApiを使ってみる(DMの内容ダウンロード)

slackでDMをダウンロードしたいなぁと思ったのでpythonで書いてみた
管理者権限でもDMはダウンロードできなさそうだったので

pythonあんま書いたことないからこれでいいのかわからん…

tokenは OAuth Tokens for Testing and Development | Slack とかで取得できます
channelは im.list method | Slack から取ってきます

MySQLの細かいTips

kamipoさんによるmy.cnfgithubにあがってるのでそっちのほうがスーパー参考になると思われる

ctrl + w で単語削除

$ vi $HOME/.editrc

bind "^U" vi-kill-line-prev
bind "^W" ed-delete-prev-word

bashなどはaaa bbb cccという文字列があった場合、ctrl + wで単語指定で削除できますが、MySQLプロンプトのクエリ上でも実現するための設定です。

よく select * from hoge where id = 10000; ってあった場合に10000だけ消したいとかって時に使う。

他にも以下のやつはよく使います。(標準で使えるはず…)

my.cnfの場所探し

$ mysql --help | grep my.cnf

複数あったら表示されて、左から順番に読み込まれる。

mysqlのプロンプト表示

# my.cnfに記載

[mysql]
prompt="[\u@\h](\d)> "

これを入れると[root@localhost](database)>みたいな表示になる

最低限はこれあれば大丈夫な気がするが、本番環境の場合は色変えたいとかあれば頑張ってみてもいいかもしれない。

スキーマ名の補完

# my.cnfに記載

[mysql]
auto-rehash

テーブル名の補完等ができるようになる

mysqlのsafe-updateについて

where句のつけ忘れたupdateとかdeleteとか悲しみに溢れる前に弾いてくれます

# my.cnfに記載

[mysql]
safe-updates

コマンドラインからMySQLを実行したい

$ mysql -uhoge -phoge database -e 'select * from hoge;'

コマンドラインから実行して加工したい時によく使う。 -Nもつけると結果からカラム名が削除されるのでなお加工しやすい。

explainについて

explainは死ぬほど記事があるので、そちらを読んでもらって自分があんま知らなかったことだけ記載。

explain EXTENDED

explain EXTENDED SELECT * FROM hoge where name = 'fuga'

explainに EXTENDEDをつけるとfilteredというカラムが追加される。これはテーブルに対して何%ぐらいがWHERE句などで絞り込まれるかの推測値が出力されるらしい。 (が、100以外見たことないのでよくわからん。。) MySQLのバージョンが5.7になるとExplainのデフォルトに載るらしい

explain format=json SELECT * FROM hoge where name = 'fuga'

ちなみにformatをjsonに指定すると、5.6でもfilteredのデータは載っかる

order by について

created_at の order by は撲滅しよう

スローログ周り

(あとでいい感じにするが、とりあえずリンクだけ)
日々の覚書: MySQLのスローログ関連のパラメーターが評価される順番

mysql > select start_time + INTERVAL 9 HOUR AS start,query_time,sql_text from mysql.slow_log where start_time > '2015-01-01 00:00:00' order by start_time desc;

RDSの場合、タイムスタンプUTCなので+9時間しておくと実際の時間と比較できてわかりやすい。 fileのほうがパフォーマンスいいとおもうけど、RDSでfileってできるんかな…

Githubの通知をいい感じに気付く

Githubの通知拾い方の設定を書いておく

notificationで気付く

スクリーンショット 2016-10-13 15.52.10.png ↑右上のこれ

  • githubのページを開いてると g + n を押せばnotificationのページを開けます
  • デフォルトだと、organizationになってるリポジトリに対して全部通知くるようになってるので、誰かがPullRequest飛ばしただけで通知が全部飛んで来るのが邪魔。
  • これを片っ端から not watching にする

スクリーンショット 2016-10-13 15.55.09.png

  • こうすると @なんとかもしくは、assignされたらやつだけ通知飛んでくるから、それだけ見てればレビュー依頼とか大体取りこぼししない

ただ、OSSで監視したいリポジトリとかは全部ウオッチする場合は入れてていい

メールのパターン

これはオレ使ってないけど、Githubのアカウントは個人が使ってるプライベートなメアドに全部通知が来るので、organizationで飛ぶメアドを切り替えるやり方

https://github.com/settings/notifications の1番したに該当のorganizationはこのメールに通知するって選択できるので、それで該当のメアドだけ hoge@fuga.co.jp にするってできる。

  • 会社に所属していたら、そのメアドだけ監視したいみたいなケースがあったらこっちのほうがいいかもしれない
  • https://github.com/settings/emails でメアド登録する必要があるが…

はてなブログ フォトコンテスト 2017夏

今週のお題はてなブログ フォトコンテスト 2017夏

f:id:okbm:20170827090951j:plain

最近撮ったやつで夏っぽい写真がなかった…。
京都の貴船神社

逆説のスタートアップ思考という本が最高によかった

逆説のスタートアップ思考 (中公新書ラクレ)

逆説のスタートアップ思考 (中公新書ラクレ)

本書は、これまで筆者が伝えてきたスタートアップに関するノウハウの中でも、特に起業前や初期のスタートアップにとって重要な3点、「アイデア」「戦略」「プロダクト」について集中的に解説します。  この他にも、チームや実行力、ファイナンスなど、スタートアップの成功にとって必要な要素はたくさんあります。しかし今回は、その中でもスタートアップに特有の、反直観的で逆説的な原則を理解してもらうために、「アイデア」「戦略」「プロダクト」の三つに焦点を絞りたいと考えています

という3点が主に紹介されているが、プロダクトに書いてあるところがめちゃくちゃよかったのでそこ中心にメモ

人の欲しがるものを作る

スタートアップにとってもっとも重要なことは、「人の欲しがるものを作る(Make Something People Want)」ことです。人はつい「自分の作りたいもの」や「誰かがきっと欲しがると決めつけているもの」を作ってしまい、時間を無為に過ごしてしまったあと、資金難に陥ってしまいます。  ポール・グレアムによれば、スタートアップが急速に成長するためには以下の二つの条件を満たす必要があるそうです。 【1】大勢の人が欲しがるものを作る 【2】それをすべての人に届ける

人が欲しがるものを作るってのは本当に大事で、自分でも誰かがきっと欲しがるモノを勝手に想像して作っていることがあると思います。
特に最初に機能が全然ない状態とかだと、これもいるだろうって勝手にいろいろ作って結局使われないモノを生み出しているケースが多いように感じます。

前に読んだプロジェクト炎上を防ぐ魔法のアイテム、100徳ナイフを買ったお話2でも似たようなことが指摘されています。

ちなみにポールグレアムハッカーと画家を書いた人で、Y Combinatorを設立していろんなスタートアップに投資してる。彼が書いたエッセイはいくつか和訳されてるので、そちらも参照してみてください。

会社が潰れる原因

多くのスタートアップが失敗する理由は資金難です。しかし資金難とはあくまで症状であって、原因ではありません。会社が潰れる原因は、お金の残っている間に顧客の欲しい製品を作れなかったことにあります。

スタートアップでは、資金調達ごとに約1・5年間、会社が生き長らえるだけのお金を得ると言われています。1・5年とは約78週です。もし1週間に1個の仮説しか検証できなければ、合計で78個の仮説しか検証できないということになります。たったそれだけの期間で、製品を作りながら、機能するビジネスモデルを見つけ、十分な数の顧客を獲得して、次のマイルストーンにたどり着く必要があります。そんな貴重な資源である「時間」を使って、どうやってリスクを減らせるのかをスタートアップは常に考えるべきです。

スタートアップとか関係ないけど、基本的にプロダクトは仮説と検証を速く繰り返すモノだと思って日々仕事をしている。 (コードを書かなくて検証できるのであればそれが理想なんだけど…

で、1番共感できたのがこちらの記事
いち早く70%〜80%程度の完成度で人に見せられるものを作ることがいかに重要か、という話

仮説と検証のバランスって難しくて、本番にリリースする前にまず社内でもいろいろ会話してるので、実際めんどくさいのは社内でも検討する必要があるところ。

  1. 社内で検討
  2. 検討してみて、OKだったらリリースするが、微妙だったらまた1に戻る
  3. リリースしてみて数字が微妙だったら、1に戻る

本番リリースしてみて、微妙だったら直すサイクルが速ければいいんだが、初回に大きなリリースをやろうとするとやたらめったら1の社内検討にめちゃくちゃ時間がかかることが多い。

前職でゲーム作ってたときも完璧な仕様書は存在しないという前提で、とりあえず最初にクソみたいなコードでもいいから、さっさと動くモノを作って見せていた。 なぜなら人間が脳内に描いてる想像通りのモノが絶対に出来上がらないし、実際に動いてるモノを見ると別のアイデアが出てきて仕様が変化するから。

ここが微妙に遅いだのここが微妙にずれてるだの100%調整が入るし、そもそもこれ思ってたんと違うみたいなことにもなりかねない。
そうした時にめちゃくちゃ時間かけてキレイなコードで書いてたとしても、時間がもったいないケースが多い。
爆速でキレイコードを書けるスキルが自分にはないといってしまえば終わりなんだが、データ構造だけはしっかりやっていればあとはなんとでも直せると思ってるので、最初はとにかく70,80%程度のやつを20%ぐらいの時間で作って見せてた。
動いてるモノでOKもらってから、リファクタリングなりテストコード書くなりして品質はあとでいくらでも上げれると信じてる。

※前にそういう変化が嫌いだから、あえてデータ構造を変えれないぐらいのガチガチにして仕様変化は無理ですって戦うエンジニアさんいたけど、あれはあれで凄かったな…

セールスについて

Googleのような優れたテクノロジを持つ企業ですら、優秀なエンジニアを雇いながらも一方でセールスを高給で雇っていることから、優れた製品だけでは十分な収益を効率的に上げられないことが分かるのではないでしょうか。  泥臭いセールスを嫌うスタートアップも多々見かけます。そんなスタートアップほどマーケティングをすることでセールスの代わりをしようとしますが、マーケティングに頼るスタートアップは結果的に失敗することが多くあります。なぜなら、マーケティングでは顧客からの手痛い反応が返ってこないからです。  スタートアップの初期において重要なのは早く失敗することです。セールスは顧客と直接向き合うため、製品への手痛いフィードバックや反応を直接感じることができます。そしてそのセールスの失敗経験を活かして早く製品を改良できます。

この辺改善出来たらいいなぁと思ったので、引用。
最初に書いてた人が欲しがるものを作る の次はそれをすべての人に届ける ってあったように届けるのもすごく大事。

一流の料理さえ作っても食う客がいないと成り立たないよねってなんかの本に書いててそれを思い出した。
優れたプロダクトを作っても誰にも届かないのであれば自己満足にすぎない。

その他

その他にも創業者は何をするべきなのかとかいろいろ書いてておすすめです。

創業者の知り合いですら使ってくれないのなら、その製品はおそらく流行りません 優れた製品を作り、それを優れた方法でセールスするまでが、創業者の役割です サポートを創業者自身が行うことで、顧客に愛されるよりよい製品を長期的に作っていくことが可能となります 顧客とCEOが個人的なつながりを持つことができるのはスタートアップだけです。

2016年にはてぶした記事の棚卸し

はてなブックマーク棚卸し - naoyaのはてなダイアリー というのを知ってから1年間にはてぶした記事をざっと眺めてる。

去年は504個ブックマークしたみたいだが、その中で読んでみて面白かったやつ35記事を自分のためにリンクを貼っておく。
こうしてみるとチーム開発系の記事が多い気がするなぁ…。

続きを読む

2016年ベストショットを振り返る #2016bestshot

トピック「2016bestshot」について ノリで参加です。

そういえば、写真についてブログ書いたの初めてかもしれない。写真は 500px にアップしてるので、それを持ってくる
大体が canon kiss x7 / sigma 17-50mm f2.8 で撮ってます

IMG by okabe masayoshi on 500px.com

三宅島

続きを読む