2017年9月9日土曜日

凡庸な人間の生存戦略

やぁ。新しいブログに移行したんだ。
最近の事はそっちに書いてるよろしく。

じゃあなんで今日はこっちにブログ更新してるかだって?
なんとなく、誰も見ないだろうし誰も得しないけどただ「そーだい」と言う文脈を理解した人がコレを見た時、何かあるかもしれないと思って纏めてる。
でも別にそれを期待してるわけじゃない。
誰もいないゲーセンで対戦が起こるかも?と期待してるわけじゃなく、ただただ1コインのCPU戦をこなす、そんなレベル。

そーだいは凡人である

何を持って凡人か?
至って平均的な能力値だと思っている。


  • 瞬間的な発想力
  • 深掘りする推測力
  • 問題を解決する突破力
  • 長時間戦う体力


こういうの全部平均的なレベルだと思っている。
偏差値で言うと50~55くらい。
わかりやすい表現で言えば器用貧乏である。
その傾向は昔からあった。

しかし生き残っている

包み隠す言うなら、一万人をランダムで選んだ中でサバイバルしたら上位30%に生き残る程度には優れていると思っている。
ここでいうサバイバルは人生という意味だ。
しかし、上位10%には入れない。
じゃあなぜ10%に入れないか?別に能力的にステータスが高いわけでは無いからだ。
では逆になぜ生き残っているか?それはそーだいという人間が貪欲で野心家でそしてただただ自分の成長が興味対象であったからだ。
意外と自分にずっと正しく投資できる人は少ない。
自分の場合は上手く投資できて来た。それだけであるし、特別な能力も特別な方法もない。
しかし多くの人達はそんなにストイックでない。なぜなら自分への興味は大体二十歳前後で卒業し、アイデンティティは自己以外に向かうからだ。
そのきっかけは恋愛だったり挫折だったり、子供だったり色々あると思う。
でも僕は、そーだいという人間は今の今までストア主義なまま来てしまった。
いやあんま哲学的な事わかってないからストア主義だと思っているだけで違うのかもしれない。
その辺詳しい人が居たら教えてほしい。
とにかくストイックに自分に投資して、それが結果として評価されることが多かった、それだけである。

凡人の限界

ストイックに能力を伸ばしたり、効率よく利用すれば平均的な水準よりも上まで来ることはできる。
これは自分の経験則として言える。
しかしそこで頭打ちになってしまう。
此処から先の壁を超えるのは指数関数的にコストが上がっていくのでリソースが足りない。
だからこの先に「人生をかけても届かないな」と見えてきた辺りで方向転換をする。
そういうことを繰り返してきた結果、本当に器用貧乏になってしまった。

つまりそれって挫折なのでは

そう考えた時は何度もある。
しかし自己成長が目的である自分は明確に挫折と言えないのでは?という逃げ道と投資先の変更をずっと続けて来た結果、凡人でありながら自己成長を選ぶというストア主義のままここまで来てしまった。

凡庸のスキルでも複数あればゼネラリストなのでは?

そう信じてここまでやってきた。
しかし現実はそうでは無いらしい。
ゼネラリストの世界ではゼネラリストであることのスペシャリティを持った人がいる。
そういう人には一生追いつけない。
そのことが壁として大きく目の前に立ちはだかっている。
そういう意味では本当の挫折が近づいているのかもしれない。

そしてストイックに行くことの限界

30代になって、能力を伸ばすための土台に限界が来始めた。
昔ほどの記憶力が無い、体力の衰え、そういうところもあるがキャリア的にも新しいことにチャレンジしにくくなってきた。
20代での積み重ねが30代の選択肢を増やすと考えていたし、30代での方向性が40代のスペシャリティを決めるだろうとは思ってる。
なので取捨選択をする時期であることはわかっている

では何を選ぶか?

ここで結論めちゃくちゃ悩んでいる。例えば業務言えば経営者なのかエンジニアなのかマネージャーなのかセールスなのか。
多分どれを選んでも死なない程度には土台がある。しかしどれを選んでも大成するとは思えないのだ。
しかし決めなくてはならない。人生は有限だし、時間は必ず進むからだ。
人生は時間制限付きの問題集で次から次へと難題が降り掛かってくるとはよく行ったものだ。
選択までの残された時間はそんなに無いとは思っているがまだ決めれいない。

じゃあ誰かに背中推してほしいの?

そうかもしれない。けどまぁ誰も推してくれない。なぜならば多くの人は他者の責任を持ちたくないし、それでも自分を評価してくれる大切な人間関係をこれまで醸成してこなかった自分への報いでもある。

まとめ

なので答えが見つからないのでこのエントリーを書いた。
これを書くことで脳内を整理できたのは良かった。
しかし誰にも得るものの無い文章なのでこのまま閉じるのが正しいと思うがそれでも敢えて公開しよう。
それが自分が前に進むための布石になると信じて。

というわけで次の言葉無理矢理締める。

吾輩はそーだいである。答えはまだ無い。





それとは別に僕は凡庸だと認めた上で、それでも生き残ることについて悩んでる。

そーだいなるブログははてなブログに移行しました

やぁ。新しいブログに移行したんだ。
最近の事はそっちに書いてるよろしく。

2016年12月25日日曜日

そーだいなる一年を振り返る

このブログはそーだいなるアドベントカレンダー25日目です。
なお、そーだいなるアドベントカレンダーは今日始まり、今日で終わりです。


さて今年一年を振り返って見ましょう。

今年あったビッグイベント


# そーだい、記事を書く

Software Designの2月号と10月号の特集記事を書きました。
なかなか大変で産みの苦しみというモノを学びました。
記事としてはなかなか好評だったようで色んな人からありがたいお言葉をいただきました。
またJPUGの予算で特集記事を抜粋した抜刷本も出していただきました。
やっぱり自分が作ったものが形になるというのは嬉しいですね!!
同人の世界の楽しさがちょっとわかった気がします。
来年はもうちょっと頑張って本とかかけたら嬉しいなぁって思います。

# そーだい、CTOになる

元々フリーランスで仕事もらってた株式会社 オミカレのCTOとしてジョインしました。
CTOになることで変わった事、学んだ事、苦しんだ事、楽しかった事、色々あります。
会社を成長させることが自分の成長にも繋がったし順調に両方共成長出来たなと思います。
またチームという視点で見ても色んなチャレンジも出来ましたし、僕が手を離しても自立するチームに育ったと感じてます。
誰もが出来る経験ではないと思いますがポジションが人を育てるっていうのは本当にあるよなと思います。

#そーだい、ベストトーカーになる

今年も自分の開催したイベント以外でも色んなところで登壇させてもらいました。
去年も散々Javaエンジニアのための◯◯とかでCCCとか荒らしてましたが今年も◯◯のためのRDBな事で荒らしてきました。
例えば


  • PHPカンファレンス 北海道
  • YAP(achimon)C::Asia Hachioji 2016mid
  • PHPカンファレンス 福岡
  • PHPカンファレンス 大阪
  • Database Night Hokkaido 2016 Summer
  • PHPカンファレンス 東京
  • OSC東京


などです。
北海道には二回も行かせてもらいましたし、念願のPHPカンファレンスに登壇も出来ました。
PHPカンファレンスの4箇所とも全て登壇した人って僕以外だと誰が居るんだろ?
とても貴重な経験をさせていただきましたし、そのお陰様で多くの方とつながることができました。
僕は意外と小心者なのでなかなか声をかけに行かない人なのでオフラインで会う機会があれば是非、お声掛けください!!
あとスピーカーとして一定の評価をいただけたと言うのも嬉しかったです。
知り合いからは「良かったよ」と言われても具体的にどう良かったのかわからないし社交辞令も多くあります。
なのでベストトーカーをいただけたのは自信にもなりましたし心底嬉しかったです。
来年は「ベストトーカー?大した事ないな」って言われないようにより精進したいと思います。

# そーだい、KOFの全国大会に出る

KOF02は予選ブロック決勝で死亡
KOF98は予選ブロック一回戦で死亡
現場からは以上です。

こんなところですかね。
自分としての成長で言えば立場が変わり、マネージメントなどで学ぶことが多かったように思います。
逆に技術的なところで言えば貯金プレイがかなり大きく公私でPHPを書くことは殆どなかったので(私的にPythonとかちょいちょいあったけど)コードを書く量はかなり少なくなった一年でした。
でもMySQLは新しい驚きを常に提供してくれるし、PostgreSQLにはパラレルクエリが来たしDBAとしては楽しく学んだ一年だったなと思います。


ということであんまり纏まってないけど 飽きてきた 以上で今年一年のまとめとしたいと思います。
それでは皆様良いお年を。

PS. 年内でオミカレを退職し、CTOじゃなくなります。


2016年12月2日金曜日

PostgreSQL使いのためのSQLの使い方

この記事はPostgreSQL Advent Calendar 2016 の3日目の記事です。

やあ、みんなげんき?
僕は酔っ払いです(カラオケ屋の3次会でこれを書いてます)
今日はみんなにSQLをもっと知ってもらうために下のスライドをご紹介します。



※sampleで出てくるSQLを試せるようにDDLとか用意しました

そうです、これ。
今日のPGConf.Asiaの登壇資料です。
僕はMySQLもPostgreSQLも使う中で「SQLならもっと簡単に書けるのにアプリ側で頑張ってる」って現象を度々見ます。
そこをちょっとしたSQLの知識があればすごく楽出来るのでみんなにも是非覚えてください。
コレを読んで興味がある人は下記の本を読むとすごく勉強になると思います。





本当に上記の本はオススメ。
この先にインデックスチューニングとかパラメータチューニングとかDB設計があると思います。
そこまで興味がある方は是非DB勉強会の資料が参考になります。
MySQLもPostgreSQLもSQLServerもOracleDB(ちょっとだけ)あるので是非見てみてください。

中国地方DB勉強会

ということで現場からは以上です。
引き続き、PostgreSQL Advent Calendar 2016 をお楽しみください。

2016年11月9日水曜日

PHPカンファレンス2016でRDBアンチパターンの話してきた #phpcon2016

全国のそーだいふぁんのみなさん、お久しぶりです。
1ヶ月ほど更新がなかったのですが私は元気です。
表題の通り、PHPカンファレンス2016に遊びに行ってきたのでそのご報告です。
当日のスライドはこちら



今回はRDBアンチパターンということで以下の内容を話して来ました。
またスライドだけでは言葉足らずなので補足記事書きました。
下のリンクで補足記事に行けます




スライドだけでは説明しきれないのでぜひ動画を見てほしいです



それと当日のTwitterまとめ

DBの寿命はアプリよりも長い!DBを救える英雄になろう RDBアンチパターン入門 #phpcon2016 #phpcon2016_2 RDBアンチパターン

内容としてはもっと色々詰め込みたかったんですが60分では私の108式あると言われるアンチパターンをすべて伝えるには不可能でした。
どこかの機会で残りも伝えれればなと思います。
というわけで登壇内容については上記のそれぞれの補足説明を読んでください!!


ではここではメインは私の感想を書きます。


1 PHPカンファレンス2016 in 東京について


PHPカンファレンスは4つの地域全てで参加・登壇することが出来ました。
(もしかして全部でSpeakerしたの自分だけなのでは?)
特に東京は事前に伺って居たとおり規模がとても大きく会場も集客もすごかったです。
実際に私のフォロワーさんでも参加している人が多く、その半面、ご挨拶出来なかった人が多かったので残念です。
もっと分かりやすく挨拶できる場を設ければよかったなぁとちょっと反省しています。

カンファレンス本体で言えば当日についてはこれだけの規模をキレイに統制を取ってるので素晴らしいの一言です。
ただ事前準備のところでは


  • タイムテーブルの告知が遅く、地方勢としてはホテルの予約やスケジュール調整に悩んだ
  • 公式サイト等ではタイムテーブルにはタイトルしか無く、セッションの選び誤解やすれ違いがあったのでは無いかと懸念
  • 当日実際に見れるセッションに限りがあって、見るタイトルが事前に決めれなくて悩ましすぎた
  • そもそも自分の裏番組が見たくて見たくて自分のスライド作りのモチベ維持が難しかったw


この辺ですかね
ただボランティアベースのコミュニティですから無理強いするわけでは無いですし、その懸念点を差し引いても圧倒的に素晴らしいカンファレンスでした。
セッションに関しては録画がすでに公開されており、その苦労はイベント主催経験者としては大変な苦労だとお察しします。
早速ですが見れなかったセッション、全て拝見したいと思います!!
また個人的にはもっと一緒に飲みたかった人が沢山居ました。
ただ時間と場所の制約上、ご一緒出来なかった人が沢山いるのでまた来年も参加したいと思います!!

2 全国でのPHPカンファレンスの総括として

全国4箇所で登壇して思った事はPHPerのパワフルさと寛容さです。
PHPのカンファレンスでもRDBの話を普通させて貰えましたし、他にもPHPに囚われず色んなセッションがありました。
また参加者へ大きく門戸が開かれている印象で参加しやすく、また行きたい!と強く感じさせる運営・内容でした。
来年も遊びに行きたいと考えていますので(登壇するかは別として)各地の皆さん、どうぞよろしくお願いします。

3 登壇者として

PHPカンファレンスは普段のDBを知ってる人にDBの話やアプリケーションの話をするとは逆のアプローチで挑みました。
なので「自分にとっては当たり前でも相手が知らない大切な事」を話そうと努力しましたが何処まで伝わったでしょうか。
特に3箇所で話をした実行計画はそれが出来るだけで1枚も2枚も上のエンジニアになれます。
本当に昔に比べて今は簡単に実行計画が見れるようになったので使ってください。
RDBアンチパターンに関しては@tomzohさんの下記のツイートがキッカケで決めました。



実はPHPカンファレンスにはRDBアンチパターン以外にも


  • RDBデザインパターン
  • RDBチューニング


と2つのテーマで応募してたりします。
機会があれば何処かでまた話をしたいと思います。
気になる方はイベントに是非呼んでください!!
RDBアンチパターンについては好意的意見が多いようなのでやってよかったなぁと思います。
他のアンチパターンについてもどこかで機会があればアウトプットしていきたいと思います。


というわけで以上の3点、PHPカンファレンスのまとめでした。
他のカンファレンスについては次のとおりです


では皆さん来年のPHPカンファレンスで会いましょう!!

PHPカンファレンス2017


RDBアンチパターン - ロックの功罪

この記事はPHPカンファレンス東京での登壇資料の補足記事です。
当日の話はこちら。

PHPカンファレンス2016でRDBアンチパターンの話してきた #phpcon2016




第三章の強すぎる依存は要約すると


  • ロックは並列処理の際にデータを守るための機能
  • トランザクション分離レベルでの動作の違いは必ず学ぼう
  • ロックを取らない場合に悲劇が生まれるシーンの紹介
  • ロックはパフォーマンス遅延の理由になりやすい
  • ロックはRDBが暗黙的に取る事が多々ある
  • ロックの挙動はRDBによって結構違う


を話をしました。
ロックについては1番話をしたかったところです。
特に重要な項目について少し補足します。

■ロックの功績

実務においてPHPerに限らず多くの人は並列処理が苦手だなと感じています。
マルチスレッドで無くてもスライドで紹介したとおり、並列処理になる部分は多々あります。
それによって大きなバグを埋め込む事があるわけで実際にゲーム内での無限増殖や予約機能でのダブルブッキングなどが話題になります。
特にロック未取得によるバグはクリティカルになることが多いです。
逆にトランザクションが不要であればRDBの必要性が半減すると言っても過言では無いでしょう。
本当にRDBに置いて重要な機能の一つでACIDの根底にある部分なので適切に使ってもらいたいです。

ロックについても業務系ではロック未取得のバグ=即死案件だったりするので業務系では一般的な話だと思います。
しかし結構有名なEC系のフレームワークでも適切にロックを取ってなかったりするのでロックについてはまだまだ知られてないのかも?と感じています。
また動画でも述べましたがこれからは「並列・分散処理時代」だと予想しているのでみんなには是非これを機会に無知を既知にしていただきたいですね。


■ロックの罪

一言で言えばデッドロックとロック待ちによるパフォーマンス遅延です。
しかしこれが複数アクセスの時に発生するもので意外と開発中は目に見えなかったりします。
またシナリオテストでも単体では問題なく負荷を捌けるのに本番ではロック待ちが発生する場合があります。
これは複数のシナリオが影響している場合などで事前に予想が難しかったりします。
そんな背景から私が実際にチューニングをする際でも最適解を出すのが難しいケースの一つがロック待ちです。
スライドにもありますがロックはRDBやトランザクション分離レベルによって暗黙的取るケースが違います。
そのためそれぞれのミドルウェア固有の知識が必要でバージョン違いもあったりするのでしっかりと実際の挙動を知ることが大切です。
デバック方法もそれぞれ違ったり、対処法もそれぞれ違うので難しいところではあります。
特にDB設計に依存しやすく「原因は分かったが対処が難しい」ケースが多々あります。

これらのことから一度ロック待ちでハマると闇が深いので事前に防げるような知識が大切です。
ただ複数のRDBに詳しくなるのは大変です。
なので使っているRDBのロック待ちの調べ方とトランザクション分離レベルによる挙動に違いについては知っておくと良いと思います。
この辺、Webには大小違いはあれど情報は多いのですが書籍には意外となってないなぁと思います。
オススメの書籍があれば是非教えてください。
私も勉強したいと思っています!!

それと最後にご指摘を受けたので合わせて掲載します。
こちらもご確認ください。















みんな@yoku0825さんをフォローしよう!!
ということで補足としては以上です。
他の章の説明はこちらから行けます

PHPカンファレンス2016でRDBアンチパターンの話してきた #phpcon2016


登壇動画



RDBアンチパターン - 隠された状態 -

この記事はPHPカンファレンス東京での登壇資料の補足記事です。
当日の話はこちら。

PHPカンファレンス2016でRDBアンチパターンの話してきた #phpcon2016




第二章の強すぎる依存は要約すると


  • RDBを利用する際はリレーショナルモデルが大切
  • 事実を保存をすることが大切
  • レコードに状態を保存すると危険
  • しかし事実を保存する事に拘り過ぎて状態が隠れるともっと危険
  • 状態を保存したい→事実の歴史を保存する


を話をしました。
特に重要な項目について少し補足します。

■事実と状態

リレーショナルモデルの話は@nippondanjiさんの資料が沢山あってとても為になるので読みましょう。


そして理論的な話は奥野さんの本が超オススメです。
一章を乗り越えれれば(そこが1番難しい話なので…)あとはスーッと読めると思います。
超良書なのでぜひ読んで欲しいです。



ここについては珍しい手法とか新しいアーキテクチャの提案じゃなくて「業務系」と呼ばれる界隈では一般的な話です。
金融系だとINSERTとSELECTだけで表現するのは一般的だし業務系出身の私はそれが当たり前だと思ってました。
しかしWebサービスのDB設計を見ると意外とそうではありませんでした。
理由はパフォーマンス上の制限だったりアプリケーション上の制限だったりするのですが1番は「その手法を知らない」というのが1番多かったです。
そのため、今回は敢えてこの話をアンチパターンとして紹介しました。
多分、JJUG CCCやPostgreSQLカンファレンスだと響かない内容だったと思いますがPHPカンファレンスにはマッチしたと思います。
この辺は受託開発してる人は特に気にして欲しいです。
何故なら作ったシステムを作った人たちがずっとメンテナンスする可能性の高いスタートアップと違って、作ったら終わりの場合が多いからです。
なので3年後、5年後に「ある日突然DBの問題が発生する」時にとても苦労するし、例外対応時に全く対応出来なくて苦労するからです。
だからこそ受託開発を行うWebエンジニアの方々にはDB設計を学んでほしいですね。

またDB設計についてはもう何十年も議論されて経験が積み重なって書籍になっています。
オススメの本は沢山あるのですがまずはSQLアンチパターンを呼んでいないならぜひ読みましょう。



ということで「隠された状態」について説明しました。
実はこの問題は完璧に対応するにはとても難しい話です。
パフォーマンスとトレードオフ、仕様変更への対応などで長い目で見た問題が発生しやすいところです。
だからこそ、出来る人はとても貴重で価値が高いといえるので是非是非興味を持って勉強してみてください。
また詳しい人は設計の話、どんどんアウトプットしてほしいですね。
私も沢山の経験に基づいたDB設計の話が聴きたいです!!

ということで補足としては以上です。
他の章の説明はこちらから行けます

PHPカンファレンス2016でRDBアンチパターンの話してきた #phpcon2016


登壇動画