2017年9月9日土曜日

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

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

投稿者 時刻: 0 件のコメント:

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じゃなくなります。


投稿者 時刻: 0 件のコメント:

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 をお楽しみください。
投稿者 時刻: 0 件のコメント:

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したの自分だけなのでは？）
特に東京は事前に伺って居たとおり規模がとても大きく会場も集客もすごかったです。
実際に私のフォロワーさんでも参加している人が多く、その半面、ご挨拶出来なかった人が多かったので残念です。
もっと分かりやすく挨拶できる場を設ければよかったなぁとちょっと反省しています。

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


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


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

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


投稿者 時刻: 0 件のコメント:
ラベル: ,

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

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

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




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


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


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

■ロックの功績

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

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


■ロックの罪

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

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

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















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

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


登壇動画



投稿者 時刻: 0 件のコメント:

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


登壇動画



投稿者 時刻: 0 件のコメント:

RDBアンチパターン - 強すぎる依存 -

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

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




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


  • ORMやDBマイグレーションには強い制約と誓約がある
  • ORMやDBマイグレーションによるメリット・デメリットがある
  • ORMやDBマイグレーションを上手く活用するために必要なこと
  • ORMやDBマイグレーションはパフォーマンスによって利用が難しくなることがある
  • 強い依存性があるが依存しすぎると危ない


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

■制約と誓約

元ネタはHUNTER X HUNTERです。
一般的にはルールとマナーなどの言葉で置き換えれると思います。
スライドに書かれて居ない大切な事はこの2つを守るメリットです。

制約のメリット

制約は必ず守らなければいけないルールです。
つまり逆説的に制約というレールを轢いてその上を走るということです。
その為、一般的な最適解に辿り着きやすく、よくある事例ならすでに回答が用意されている事もあります。
そのため大きな失敗をする可能性が減り、レールの上を走っているときはとても生産性が上がります。

誓約のメリット

制約に対して誓約は強制力はありません。
例えで出したデザインパターンや命名規則などは強制では無いため、現場では統一されていないこともあります。
また文化として誓約が浸透している部分も多々あります。
例えば命名規則で言えばisで始まればboolを返すでしょうし、getなら戻り値を返すと言った感じです。
これによってコードの記述量が減ることは一般的には少ないと思います。
むしろデザインパターンを採用することで増える事もあるでしょう。
しかしこのような誓約を利用すると人間がコードを読んだり書いたりする際の生産性が上がります。
それは「勘が働く」からです。
メソッドの振る舞いが予測でき、クラス構造が想像出来るコードと出来ないコードで比較すればその差は歴然です。

以上の事からDBの抽象化をするツール群はDB層の本来の姿に対する強い制約と誓約から


  • ORMを意識したスキーマ設計
  • RDBMSを意識したクラス設計


を意識しなければなりません。
しかしその代わりに高い生産性を与えてくれています。
その為、昨今でこれだけ利用されていますし、私も活用しています。

■強すぎる依存の問題

ツール群には強い制約と誓約と引き換えに高い生産性を得ることが出来る事は伝わったかと思います。
しかしこの強い制約と誓約によって問題もあります。

1つ目はスライドにもある通り、RDBの持っているSQLや多くの機能が失う事。
具体的には守る部分では外部キー制約やCHECK制約（MySQLには元々無いけど）などを利用できません。
また型の選択肢も制約されるため、PostgreSQLのJSONB型や範囲型などのより適切な型を選択することも出来ません。
SQLの構文にはプログラムでは表現しにくい内容もあり、それを失うことでパフォーマンスやメンテナンス性を犠牲にすることも多々あります。
このように制約と誓約によってRDBの本来持っている機能を失っている事を忘れてはいけません。

2つ目はDBの抽象化は完全では無いということです。
メリットの部分でも書きましたが設計などで意識しないと効率良く利用できません。
またパフォーマンスによって、利用できなくなることもあります。
そのため、ツール群に依存しているとサービスがスケールアップの壁にぶつかる事があります。
その際に「新しい選択肢を取れるかどうか？」がそのエンジニアの価値につながるというお話も当日はしました。
気になる方は下記の動画をご拝聴いただければと思います。


ということで「強すぎる依存」について説明しました。
アンチパターンというよりは現状のアプリケーションエンジニアとデータベースエンジニアの中にあるギャップを説明した章となっています。
PHPカンファレンスはアプリケーションエンジニアが多く、このような話を聞く機会は少ないと思うので最初の掴みとしては良かったと思います。
またデータベースエンジニアからすると隣の別のレイヤーの話ですからこれを機にもう少し興味を持ってくれると嬉しいですね。

ということで補足としては以上です。
これを見て気になる人はぜひ動画を見てほしいです。
「強すぎる依存」の章だけなら15分程度なのでお時間が有る時に是非。

他の章の説明はこちらから行けます

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


登壇動画



投稿者 時刻: 0 件のコメント:
登録: 投稿 (Atom)