2015年12月21日月曜日

吾輩は「ふつう」である

吾輩は「ふつう」である。名前はまだ無い。
どこで生れたかとんと見当がつかぬ。
何でも薄暗いじめじめした所でカープ!カープ!カープ広島♪と泣いていた事だけは記憶している。
吾輩はここで始めてお好み焼きというものを見た。
しかもあとで聞くとそれは広島風お好み焼きというお好み焼きの中で一番崇高で高貴な食べ物であったそうだ。
このお好み焼きというのは時々広島焼きと呼んだ者を煮て食うという話である。
しかしその当時は何という考もなかったから別段恐しいとも思わなかった。
ただ鉄板の上に載せてヘラでスーと持ち上げた時何だかフワフワした感じがあったばかりである。
鉄板の上で少し落ちついて広島風お好み焼きを見たのがいわゆるお好み焼きというものの食べはじめであろう。
この時妙なものだと思った感じが今でも残っている。
第一具材をかき混ぜて装飾されべきはずの顔がつるつるしてまるでホットケーキだ。
その後関西風お好み焼きにもだいぶ逢ったがこんな片輪には一度も出会わした事がない。
のみならず具材の真中がそばが挟まれている。
そうしてそばの上に豚肉とキャベツが混ざり合い煙を吹く。
どうも咽せぽくて実に弱った。
これがお好み焼きのかけるオタフクソースというものである事はようやくこの頃知った。
このお好み焼きの食べ、しばらくはよい心持に坐っておったが、しばらくすると非常な速力で運転し始めた。

秋田 中略

ここで吾輩は彼のお好み焼き以外の食べ物を再び見るべき機会に遭遇したのである。
第一に逢ったのが広島風つけ麺である。
これは前のお好み焼きより一層強力な食べ物で吾輩を一口入れるや否やいきなり突き抜ける辛さが舌を抛ほうり出した。
いやこれは駄目だと思ったから眼をねぶって運を天に任せていた。
しかし熱いのと辛いのにはどうしても我慢が出来ん。
吾輩は再び広島風つけ麺の隙すきを見て平和公園へ這い出た。
すると間もなく職務質問を受けてまた投げ出された。
吾輩は投げ出されては這い上り、這い上っては投げ出され、何でも同じ事を四五遍繰り返したのを記憶している。
その時に広島風つけ麺と云う食べ物はつくづくいやになった。
この間広島風つけ麺の替え玉を偸すんでこの返報をしてやってから、やっと胸の痞が下りた。
吾輩が最後につまみ出されようとしたときに、この県の知事がサッカースタジアムはサンフレッチェ広島がV3したら建てるといいながら出て来た。
サポーターは垂れ幕をぶら下げて知事の方へ向けて「スタジアムは市民球場跡地に!!広島みなと公園は交通機関が貧弱なので困ります」という。
知事は鼻の下の黒い毛を撚ひねりながら吾輩の顔をしばらく眺ながめておったが、やがてそんなら市民球場跡地へ置いてやれといったまま奥へ這入ってしまった。
知事はあまり口を聞かぬ人と見えた。
かくして吾輩はついにこの広島県を自分の住家すみかと極める事にしたのである。


カッとなってやった。
今は公開している。

2015年12月20日日曜日

これからもIT勉強会(コミュニティ)は必要なのか本気出して考えてみた

とある雑誌の原稿を出したら編集さんに

「そーだいさん、コミュニティに対してもっと熱い想いあるでしょ?そういうの出してください。」

って言われまして。
原稿の校正納期今日なんだけどもっと自分自身を掘り下げる意味で表題の事を考えた。
なのでただのポエムです。

まず最近、大手岡山Web系セミナーに若手が少ないらしい。




参加者平均年齢が40代超えてるであろうDB勉強会からするとまだまだ若いじゃん?とか思ったり。
でもね、中の人がそういう危機感があるって事は「緩やかな死」を感じてるってことだと思うんですよね。
その危機感を中の人が感じてるのだから間違い無いと思う。
そして危機感をこうやって複数の人がアウトプットするのは大切だと思う。
あと緩やかな死とかコミュニティの継続についてはちょっと昔に考えた事があるので興味がある人はどうぞ。

IT勉強会について本気出して考えてみた

僕は同じような状況をバックエンドとかサーバーエンドと人たちのITコミュニティで感じてきた。
若い人が出てこないとか運営スタッフが変わらないとか。
でも僕は「コミュニティに育てて貰った」って強い感謝の想いがあるしそれを若い人に恩送りしたいと思ってる。
だから


  • 世代交代
  • スピーカーの機会を用意する
  • 参加費を無くして学生でも参加しやすくする
  • 学校とコラボ
  • 他のコミュニティとコラボ


などを試してる。
でも劇的な変化があったかと言うとまだない。
(少しは変化があったかなとは思うけど)
理由としてはやっぱ絶対的に対象の母数が足りてないし。
そもそも若い人が「データベースに興味を持つ」事自体難しい感じになってる。
だいたいデータベースって仕事なんですよ仕事。
仕事で初めて触るし。
仕事で苦しむ。
周りに詳しい人がいない。
だからある程度経験して中堅くらいになってからDB勉強会に来る。
って人が半分以上。
ただ僕よりも先輩には少数だけど@nuko_yokohamaさんみたいに「データベースが遊び」って人もいる。
他にもネットワークだったりDNSだったりlibraryみたいな僕が仕事だと思う所に興味を持って遊んでる人たちはいる。
これって昔は時代の「最先端の技術」がこういう「技術が遊びの人たち」と「技術をビジネスにしてきた人たち」によって「枯れた技術」になった事だと思うんだよね。
だからこそ僕はDBみたいな枯れた技術ってのは儲かる大切だと思うんだけど「目新しさは無い」ってわけ。
でね、これと同じことが最近Webでも起こってるのかなって思う時がある。
僕の大好きな岡山のエンジニアの@kazuhisa1976さんが

最近の若者に聞くとね、Webは仕事って言うの。
じゃあ休みの日は何のコード書いてるの?って聞くとスマフォアプリかUnityって言うのよ。

コレを聞いたらあぁなるほど!!ってなりました。
僕も小学校、中学校の将来の夢にはゲームプログラマになる!!って書いた人なんで憧れも含めて凄くわかる。
自分でアプリ作ってリリースしてレスポンスがある、そりゃ面白いですよ。
それがね、僕らの世代の「技術が遊びの人」はWebアプリだったんです。
多分、先輩方はメールや掲示板やネットワークやOSSだったりしたんだと思う。
つまりWebは「技術をビジネスにする人たち」によって枯れた技術になりつつある。
これは悲観することじゃなくて世の中のインフラとして認められたって事。
だからレイヤーが変わったというか流行り廃りがあったけど若者自体は業界には要る。
だけど僕らの観測範囲に居ないってだけなんだと。
これは僕は経済の神の手と一緒で人材の流動がある事は仕方ない事だと思う。
そして「技術が遊びの人」な若者が多いところでは新たなコミュニティが生まれてる。
実際に岡山でもコミュニティの再開発は生まれつつある。

第一回「岡山Androidもくもく会」
(今見たら若者じゃない強そうなおっさんが数名参加してたけど)

僕は凄くいいことだと思う。
僕がオープンラボ備後手伝ったりDB勉強会やりたいですって言った時に周りの先輩方は「おーやれやれ、どんどんやれ!」って言ってくれた意味が今ならわかる。
こういうコミュニティが生まれてくる事が重要だと思うし広い視野での業界の新陳代謝だからだ。
スタッフをするメンバーも一新されるだろうしイノベーションには多様性が必要だ。
ということでIT勉強会(コミュニティ)は必要か?って結論に対しては必要ならば新しく生まれてくるってのが結論。
だから僕達が必至になって今のコミュニティを継続する必要もないのかもしれない。
実際に元々岡山には日本Androidのの岡山支部があるけど最近の活動が少ない。
その実体からこうして新しいコミュニティが生まれている。
なのでコミュニティもイミュータブルな感じで代謝が止まったら捨てるくらいが新陳代謝が早くていいのかもしれない。

ここまでが僕が今年の夏くらいまで思ってた事。


■既存のコミュニティは緩やかな死を待つしか無いのか

もし本当に「緩やかな死を止めれない」のであれば残りのコミュニティの余生を楽しんだほうが良い。
そう考えるなら内輪ノリとか同窓会と批判されても来てくれる人たちに最適化して楽しんでもらえる方がいい。
そう悩んだりもした。
けど最近MySQLを触っててMySQL Casualの人たちを見たりJJUG CCCに参加してそれもまた違うなと思ってきた。
廃れた技術は緩やかな死を待つしか無いけど「枯れた技術」ってのは仕事で使うことが多々ある。
さっきのデータベースの例もだけど「仕事で初めて使った、辛い」みたいな人たちを救う場所が必要だ。
そういった人たちが助けを求め迷った時に「助け合う場所」の一つの選択肢がコミュニティだと思うしそのために継続されることは大きい意味がある。
多分、それを母体となるビジネス側も理解してるからJJUGだったりJPUGだったりに協賛金が集まるわけで。
だから「技術で遊ぶ」若者を見つけるのは難しいけど「技術を仕事にしてる」若者を救い上げる事はできるかなと。
その中で10人に1人はコミュニティに興味を持ってくれるかもしれないし100人に1人はコミュニティに関わろうと思うかもしれないし1000人に1人はそのソフトウェアのパッチを書くかもしれない。
そういうアウトプットを増やすことでコミュニティの新陳代謝は進むだろうし継続されていく。
そう考えると僕がJPUGのスピーカーというポジションで求められてるのはPostgreSQLの機能紹介でも事例紹介でも無く「苦しんでる人が助かる術」のアウトプット。
そんなアウトプットが仕事で使ってる人の心に刺さるアウトプットだと思うし求められてる。
そう考えて書いた資料が




たちで一定数以上の反響はあったと思う。
まだその反響に対してコミュニティに誘導する手法は模索中なのでそこは改善していく必要があるところ。

なので既存のコミュニティでも「枯れた技術」を扱っているIT勉強会(コミュニティ)は必要。
そのコミュニティが継続するには「技術が遊びの人」向けのコンテンツも大事だけどアンチパターン的なコンテンツが重要。
そして引っかかった「技術は仕事の人」から上手くコミュニティへ誘導して新陳代謝をしていく必要がある。
そもそもコミュニティの運営やスピーカーってコードを書く力とは直結しないから「技術は仕事の人」の方がコミュニティ運営には適してる事が多いんじゃないかなと漠然と思ったりしてる。
だから次は如何に誘導するか、だけどそれは如何に的確な小さな問題を与えるかだと思ったりしてる。

問題にチャレンジしてもらうために必要な事を考えてみた

そんな事を思いつつ、でも恩送りだけじゃなくて自分自身のステップアップも見据えなきゃいけない。
そんなことを考えながら書いた年の瀬のポエムでした。

2015年12月18日金曜日

MySQLの暗黙の型変換の話

この記事はMySQL Casual Advent Calendar 2015の18日目です。
昨日はwinebarrelさんの「binlog_cache_sizeにメモリを食われた話」でした。
こういった実践の話は非常に貴重なので勉強になりました。

さて「PostgreSQLと比べてMySQLのいいところ書く!」を書こうと思ってたのですが昨日こんなツイートを見かけました。





公式ドキュメントを見てみると…

NOT NULL として宣言された DATE および DATETIME カラムでは、次のようなステートメントを使用することで、特殊な日付 '0000-00-00' を検索できます。

SELECT * FROM tbl_name WHERE date_column IS NULL
ODBC では '0000-00-00' 日付値がサポートされていないため、一部の ODBC アプリケーションを取得する際に、これが必要になります。


なるほど。
一部のODBCに対する優しさなんですね!!

そして僕もつい先日、MySQLの暗黙の型変換の優しさを味わったのでご紹介します。

-- テーブルの構造 `hoge`

CREATE TABLE IF NOT EXISTS `hoge` (
  `id` int(11) NOT NULL,
  `val` varchar(255) NOT NULL
);

mysql> SELECT * FROM hoge;
+----+--------+
| id | val    |
+----+--------+
|  1 | ONE    |
|  2 | 2      |
|  3 | Three3 |
|  4 | 4Four  |
+----+--------+
4 rows in set (0,00 sec)


こんなtableがあったとします。
そこで次のように検索してみましょう。

mysql> SELECT * FROM hoge WHERE val = "0";
Empty set (0,00 sec)

mysql> SELECT * FROM hoge WHERE val = 2;
+----+-----+
| id | val |
+----+-----+
|  2 | 2   |
+----+-----+
1 row in set, 3 warnings (0,00 sec)


想定した感じですね。

mysql> SELECT * FROM hoge WHERE val = 4;
+----+-------+
| id | val   |
+----+-------+
|  4 | 4Four |
+----+-------+
1 row in set, 3 warnings (0,00 sec)


あれ?文字列がマッチしましたね…
あっ!これPHPの文字列からintにキャストした時と一緒か!?

mysql> SELECT * FROM hoge WHERE val = 3;
Empty set, 3 warnings (0,00 sec)


あれ?Three3が出ない…

SELECT * FROM hoge WHERE val = 0;
+----+--------+
| id | val    |
+----+--------+
|  1 | ONE    |
|  3 | Three3 |
+----+--------+
2 rows in set, 3 warnings (0,00 sec)


Why,MySQL People!!

そしたら我らが@yoku0825さんが次のように教えてくれました。

val = 0の場合、0を文字列にキャストするのではなく、valをDOUBLEにキャストして0と比較しています。
英字で始まるSTRINGはDOUBLEにキャストできずにキャスト後の値が0になりますが、123abcのような文字列は「できるところまでキャストする」ので、キャスト後の値は123になります。
つまり123 <> 0です
ってことで、「数字で始まらないval」のものだけが検索に引っかかるわけです。
そして逆に数字から始まらない文字列はWHERE val=0に該当するわけです。

勉強になりますね!!
ちなみに僕が暗黙の型変換僕がハマったのはPHPのSESSIONをDBに保存している場合に検索しようとすると引っかかりました。
DBにSESSIONを保存することは多々あって例えばEC-CUBEやMagic3などのCMSも保存してるのでみなさんも検索の時はご注意ください。

ということで僕のMySQLエキスパートへの道は遠いようですw
それでは最後はとみたさんのお言葉で締めあせていただきます。



みなさんも良いMySQLライフを!!

2015年12月14日月曜日

あなたとPostgreSQL 9.5、今すぐダウンロード

これはPostgreSQL Advent Calendar 2015の14日目の記事です。

昨日はtksyさんの「普段SQLServerを触っている人がPostgreSQLに入門するかも」でした。
tksyさんの体調が心配です。

さて今日は僕がPostgreSQLの本当のポテンシャルをお見せしましょう。
…と思ってたのですがここまでPostgreSQL9.5の話は0。
下手だなぁカイジ君、本当に読者がほしいのはコレ、PostgreSQL9.5の最新情報まとめ。
ということでPostgreSQL9.5の話をします。
PostgreSQLのポテンシャルについては明日の海外さんに期待してください。

1. PostgreSQL 9.5はいつ出るの?

出る出る詐欺進行中のPostgreSQL 9.5はいつ出るのでしょうか。
現在のPostgreSQL 9.5はBeta2です。
当初は年内に出る予定でしたが今の感じでは年明けと見せかけて海外勢のロングバケーション後で2月くらいかなと僕は思ってます。
実際のgit logを見るからには毎日激しく最後の追い込みがかかってるので年内リリースに微かな期待を持っても良いかもしれません。

PostgreSQL本体のgitのSumally

2. PostgreSQL 9.5で何が変わるの?

毎年PostgreSQLの新機能の話でスピーカー業で飯を食うのが僕の生業だったのですが今年はなんと一回も新機能ネタで話してません。
なので自分のスライドが無いので他人の褌で相撲を取ろうと思います!! 
ということでPostgreSQL界のダルシムこと@sawada_masahikoくんの資料が素晴らしいのでご紹介します。



あとPostgreSQL界のラーメンテロリストことぬこさんのブログも細かい情報がまとまっています。
リリース前のPostgreSQLを積極的に検証している情報が貴重です。

日々の記録 別館


3. で結局なにがオススメ機能なのよ

PostgreSQL新機能は色々あるんですけどもうコレだと思うんですよね。

INSERT ON CONFLICT構文


PostgreSQL9.5からMERGE文相当としてINSERT ON CONFLICT構文という機能が追加になりました。
これはMySQLのINSERT ON DUPLICATE KEY UPDATE構文相当の機能になります。
構文も非常に似ており

INSERT INTO table名 (column1, column2, column3) values (value1, value2, value3) 
     ON CONFLICT 制約名
     DO UPDATE SET ( カラム名 = 値 )

と書くことで同様の処理を実行できます。
MySQLと違うところは制約を書くことです。
これは冗長とも言えますが「primary keyなのかUNIQUE制約なのかを選べる」ということです。
今までORMでsave()というメソッドを実装するときに一旦SELECTでDBを検索したりUPDATEの例外を拾って処理していたようなところは全てこれで解決できます。
ついに念願のMERGE(UPSERT)文相当の機能が実装されたということになります。
この機能だけでも新バージョンを使う価値があると思います。
もうちょっと詳しく知りたい人は上記のぬこさんの検証結果を見てみてください。

PostgreSQL 9.5 UPSERTを試してみた

その他にもRow Level Securitなど目玉機能が盛り沢山のPostgreSQL 9.5。
是非、皆さんも試してみてください!!!

2015年12月7日月曜日

FuelPHPを快適に開発するためのNetBeansで設定まとめ

このブログはFuelPHP Advent Calendar 2015の7日目です。

昨日は@wataさんの「DBUnit拡張を使ったFuelPHPのテストを考える」でした。
今日はみんな大好きNetBeansの話します。
それでは早速行きましょう。

まずはNetBeansのダウンロードリンクです。

あなたとNetBeans、今すぐダウンロード


普段IDEを使ってない!って人はこちらも合わせてどうぞ。

PHPerがNetBeansを使いたくなる7つの理由


インストールが済んだら本題です。

1. ルーク、FuelPHPプラグインを使え!!

兎にも角にもまず入れるのはこれです。
@junichi_11さんが作っているこのプラグインを使いましょう。
@junichi_11さんがまとめてるブログはこちらです。

NetBeansではじめる FuelPHP


このプラグインを使うとNetBeans上からスケルトンを作ったり、正しくFuelPHPの補完や関数ジャンプ出来るようになります。
Coreのコードを読んだり、知らないメソッドを知るきっかけにもなるので是非ご利用ください。
僕がPHPStormに完全に移行出来ない理由はこのプラグインがあるからと言っても過言ではありません。
Symfony2書く時とかはもう完全にPHPStormなんですけどね。
完全無料環境なのでお財布に優しいです!!

2. その他の設定


■Windowsの人は必須


  • Show and change line ending
  • Change Line Ending on Save


Show and change line endingは改行コードをLFにしたり今の改行コードを表示したりします。
Change Line Ending on Saveはデフォルトの改行コードを指定して保存するときに一括して改行コードを変更して保存してくれます。
私はLF固定にしてます。
あとはここからはお好みですが私はvagrantプラグインを入れてNetBeans上からを操作できるようにしてます。
vagrantを操作するためだけにターミナルを開かなくていいので便利です。
更にwindowsはsshクライアントがデフォルトで入っていませんがvagrantへのsshは出来るようになります。
gitからvagrantの使い方まで知りたい!って人は@kenji_sさんの本を読むと全部書いてあります。



PHPUnitなどの設定はお好みでどうぞ。
個人的にはPHPUnitのバージョンにテストコードが依存することがあるのでvagrant側で実行する事多いです。
プロジェクトが一つでチームで同じバージョンを共有できる場合などはインストールしてIDE上で実行する方が便利だと思います。

3. インデントの乱れは心の乱れ

PSR-2に準拠しないとプルリクエスト送った時に怒られます(自分は怒られた事がある)
なのでフォーマットを指定しましょう。


  1. ツール→オプション→エディタ→フォーマット
  2. 言語を「PHP」
  3. カテゴリを「中括弧」
  4. クラス宣言とメソッド宣言を「改行」に変更




ちなみにPSR-2準拠だとインデントはタブでは無くスペース4つです。
そしてPHPの予約語は小文字で使用しなければなりません。
つまりNULLはnullです。
デフォルトは大文字なので変更が必要です。
やり方はNetBeansの設定ファイルを直接編集します。
Windowsでエディタで編集する場合は管理者権限が必要ですのでご注意ください。

  \インストールフォルダ\php\phpstubs\phpruntime\Core.php

私はデフォルトの場所にインストールしたので

  C:\Program Files\NetBeans 8.0.1\php\phpstubs\phpruntime\Core.php

です。
それを次の通り編集します。

define ('TRUE', true);
define ('FALSE', false);
define ('ZEND_THREAD_SAFE', false);
define ('ZEND_DEBUG_BUILD', false);
define ('NULL', null);

↓↓↓

define ('true', true);
define ('false', false);
define ('ZEND_THREAD_SAFE', false);
define ('ZEND_DEBUG_BUILD', false);
define ('null', null);

これで補完もバッチシです。


以上を設定すればプロジェクト作成時からFuelPHPの対応が完璧になったはずです。
快適なプログラミングライフをお楽しみください。

明日のFuelPHP Advent Calendar 2015@tanaka8comさんです。
楽しみですね!!

2015年12月4日金曜日

忘年会議を楽しむための3つのTips

この記事は大都会岡山 Advent Calendar 2015 4日目です。
明日に控えた忘年会議をより良く楽しむために大切な事をまとめます。
なお、私の主観で全て書くので責任は負いません。


■忘年会議って何?
Tipsに行く前にまずは忘年会議の説明をしておきます。

忘年会議

忘年会議は瀬戸内界隈のITコミュニティが年に一度、集まって酒を交えながら会議する場所です。
決しておもしろLTを見せびらかす場所でも転職しましたと報告する場所でもありません。
会議と言っても瀬戸内界隈で行われているオープンセミナーの日取りと実行委員会を決めるだけなので誰でも参加できます。
しかし残念ながら既に満席です。
最近人気すぎて3ヶ月くらい前には埋まってしまいます。
みんな早すぎて今年は広島勢が誰も参加しておらず、実行委員会の代表が実は居ないという問題が発生したりしてます。
来年参加しようと思ってる人はお早めに登録をオススメします。


というわけで忘年会議を楽しむためのTipsいきます。


1. 開幕を焦る者は渋滞を促す
忘年会議はバイキング形式なので各人で取ってくる必要があります。
60人を超える人が取りに行くと一気に大渋滞です。
そこでオススメは席が一緒になった人と担当を分けましょう。
食事を取る人と飲み物を取りに行く人を分けます。
これでまず並ぶ人が半分になります。
あとビールの冷蔵庫の前にいる人は積極的にビールのバケツリレーを行い、効率化しましょう。
料理を取りに行く人は一気に取り過ぎず最初の一回目はほどほどがオススメです。
どうせLT始まったら誰も見に行きません。
あとお腹すいたら二次会でラーメンを食べに行きましょう。
オススメのラーメンは山富士です。
僕は寺田さんと帰るつもりなのでほどほどで帰ります。

2. LTを制するものは座を制す
東京の懇親会のLTは技術9、ネタ1くらいの割合のLTですね。
岡山はネタ10、少なく見積もってもネタ7くらいです。
あっ僕は真面目な奴演る予定なので数に含めないでください。
TDD?知らない子ですね。
あと当たり前のようにマサカリ野次が飛び交います。
皆さんも空気読まずに野次を飛ばしてあげると登壇者が喜びます。
僕はガラスのハートなので勘弁して下さい。
多分マジ泣きします。
あと野次の相手をしてると5分あっという間です。
登壇者の精神力が問われる場となっています。
あと面白くなかったとしてもLTした人と話す機会が有るときは「面白かったです!」って言ってあげましょう。
「今回のはちょっと残念だったね」って言われるとマジ凹みします。
その後帰りの電車で真面目に反省会とか始まるので嘘でも面白かったと言ってあげましょう。


3. 知らない人に積極的に話しかけてみよう
忘年会議は色んな県のエンジニアと会える貴重な場所です。
どうしても知ってる人と話し込んでしまいがちですが勇気を出して声をかけてみましょう。
大抵みんなシャイなので声をかけられるのを待ってます。
隣の席に知らない人がいたらまずは名刺交換を起点に話しかけたりすると良いでしょう。
あと人気者が数名います。
そういう知ってる人気者に群がってる知らない人に話しかけると大抵同じカテゴリの人なのでオススメです。
Twitterのアカウントの交換をするとその後の繋がりもできるので名刺交換だけで終わらず次のステップとしてもオススメです。
ただエンジニアには時折「リアルでは紳士なのにTwitterだとド変態」みたいな人がいます。
そういう時はそっとリムーブしてください。
決して「ツイートが多いのでリムーブして今後はリストで見ますね」などの連絡は避けましょう。
そっと、そっとリムーブでよろしくお願いします。


さて今回は忘年会議を楽しむための3つのTipsを紹介しました。
明日はいよいよ合同勉強会&忘年会議です。
参加される方は楽しんで来てください!!

2015年12月2日水曜日

負けたことがあるというのがいつか大きな財産になるのは自分次第

このエントリーは、カープとメガフォンと私 Advent Calendar 2015 の2日目 です。
昨日は@tsuchimさんの「今年は今までで一番カープを応援したかもしれない」でした。
明日は予定が埋まってないので誰かカープが好きな人でも好きじゃない人でも是非ともお願いします。

さて今年、サンフレッチェはリーグを二年ぶりに制覇する反面、カープはCSに行くことすら出来ませんでした。
この違いは何かと考えたところ、やっぱ勝負所の勝てるかどうかだなと感じています。
実際にCSのかかったカープ最終戦。中日に0封されてしまったカープ。
そもそもその前に二日酔いのヤクルトに勝ち切れない時点でうーんって感じですがこれが今年のカープの勝負弱さを表していたと思います。
今年は優勝候補とすら言われたカープ。
1点差で負けた数はセパ合わせて1位。
また延長戦の末負けた数もセパ合わせて一位。
沢村賞を取ったマエケンに最優秀防御率のジョンソンが居てこの結果です。
これはもう貧打でしか応えは無いと思います。
緒方監督には来年はスクイズしてでも点を取る気概で打線を考えていただきたい所存ですね。

さてそんなカープですが僕は来年は大瀬良に期待してます。
野村や中田廉など去年の活躍に対して今年は今ひとつだった選手の一人です。
本来なら先発でローテーションを投げる選手が急にセットアッパーを任せられたのだから難しいのもわかります。
そして最終戦のあの涙。
私はあの涙を今年は糧に大ブレイクして欲しいと思ってます。
打たれた事も負けた事も勝負事なので仕方ない。
来年、マエケンが抜けたあとのエースを担うのは私は大瀬良だと思ってます。
そんな大瀬良に私が大好きな名言の画像を貼ってこの言葉を送りたいと思います。

2015年12月1日火曜日

PHPerでDBな自分がJJUG CCCで遊びに行ってきた!(ついでに登壇してきた

国内最大のJavaの祭典、JJUG CCCに遊びに行ってきました。
JJUG CCCは1000人を超える参加者申し込みがあります。
これを無料のカンファレンスとして回してるJJUGは素直にすごいと思います。

ということで個人的な感想を書くのですが個別のセッションについては書きません。
どれも面白かったし色んな人がまとめてるので部外者から見たJJUG CCCについて書こうと思います。

私の登壇資料が気になる方はこちらです。

PostgreSQLアンチパターンの話をいっぱいしてきた。


■所感

会場がまず新宿!お洒落!!
スピーカーが豪華!PHPerの自分でも知ってる人ばかり!!!
そして会場に行くと人!人!!人!!!
何から何まで凄くて圧巻でした。
実は2年前にも一度JJUG CCCに遊びに行ったことがあるのですがあの頃より遥かにスケールが大きくなってました。
これはJavaの影響力というかコミュニティが大きくなっていること、重要なポジションに居ることを表していると思います。
また同じように変わったところとして感じたのは女性の参加が凄く増えてました。
Java女子部が出来たり女性スピーカーがLTも含めると数名居たりといった変化もJavaの窓口の広さを感じます。
前日にPostgreSQLカンファレンスがあり、そちらは女性が少なめだったので尚更そう感じたのかもしれません。
2年前にお邪魔してた時は「地方における勉強会事情」と言うテーマでパネルディスカッションさせていただきました。

JJUG CCC 2013 Spring R2-6 [BOF] 地方における勉強会事情

この時から僕が中国地方をの勉強会にどれだけ影響を与えて変えていけたかは怪しいですがJJUGは明らかに進化してるなと思いました。


  • 若手不足とコミュニティの高齢化
  • 女子参加のハードルの高さ
  • ハンズオンなどの参加型セッションの運用コストの高さ
  • てらだよしおリソース問題


どれも僕が居た時にパネルディスカッションの内容として話題にあがりました。
でも現在のJJUGを見てると


  • 若手のスピーカー・幹事雇用と参加者層の拡大
  • 女子部の発足
  • 企業を巻き込んだハンズオンの開催


てらだよしおリソース問題以外は解決してるように思えます。
てらだよしおリソース問題は寺田さんがMSに転職されたりでまた色々と状況が変わってます。
ですが人手不足は変わらないので寺田さんを超える愛されるエバンジェリストの登場が待たれます。
寺田さんの話は良いとしてそれ以外の問題をたった2年で解決しているのは本当にすごいと思います。
例えば若手の多いLL系の言語ならまだしもJavaという流行りとは言い難いコミュニティで行えた事がすごいです。
同じように若手不足に悩む日本PostgreSQLユーザ会ではまだまだ解決出来たとは言えていません。
これは若手が本当に必要か?という前提あるのですが世代交代は大きなコミュニティの転機の一つだと思います。
この世代交代を上手く超えていける基盤がJJUGにはある=10年も20年も続くコミュニティだと確信しています。
その他の女子部やハンズオンについて鈴木会長は

「勝手に他の人達がやりたいとすすんで行なってくれてる、だから特に何もしてないんですよ。」

と仰っていましたが個々にセルフマネージメント力があることが今のJJUGの強みなんだろうなと感じました
また来年以降もどんなJJUGが見れるのか楽しみになってきました。

■Javaコミュニティ





ホントみんなJava好きなんだなぁと思いました。
いや僕もPHP好きですよ。
大きな声で言いますけどデータベース好きですよ。
それを好きでもない人が見て「あぁ好きなんだなぁ、良いな。」と思ってもらえるかは自信がありません。
でもJavaコミュニティの人たちを見てると「あぁ好きなんだなぁ、良いな。」と純粋に嬉しく感じました。
これはJavaって言う一つの言語に拘らず幅広く受け入れてくれる懐の深さがそう感じさせてくれるのだと思います。
実際に僕はCCCで登壇した2回ともJavaの話は1Byteもありませんでしたし、普段からJavaのアウトプットはありません。
それでも暖かく受け入れてもらえるところがJavaコミュニティだと思います。
僕はそういうJavaコミュニティが大好きなんだなと再確認しました。

■そーだいに対する皆さんの反響について




















自分の思っているキャラコンセプトと世の中へ伝わるキャラコンセプトは必ずしも一致しないという例を体験しました。



ただの真面目なおっさんですみません。


ということで色んな方に会えて色んな刺激を貰えたイベントでした。
やっぱJavaコミュニティは最高だぜ!!

PostgreSQLカンファレンスに行ってきた

年に一度のお祭、PostgreSQLカンファレンスに行ってきました。
先週の金曜日なのでもう随分時間が立ってしまいましたがまとめです。
まず、セッションはなんと!全然!!!聞いてません!!!!!
でも一応朝一から行ってお手伝いはしました。



あとPostgreSQLカンファレンスは支部長は地元のお土産を持っていくというタスクがあります。
見事に7000円分相当を東京駅に忘れるというアクシデントがありました。
無事帰ってきたのですが本当に日本で良かったと思います!日本人最高!!
というわけで、全然セッション聞けてないのに忘れ物取りに行ったり仕事したりで忙しい時間でした。
本当は国府田さんとか海外さんとか須藤さんとか聞きたいセッションいっぱいあったのですが聞けなかったものは仕方が無いので下のまとめ読んどきます。

PostgreSQL Conference 2015 #pgcon15j のまとめ


ちなみに僕は最終時間のセッションだったのですがマサカリ尖そうな人は海外さんのセッションに丸っと行ったため誰もツイートしてませんw
資料が気になる方はこちらを見てください。

PostgreSQLアンチパターンの話をいっぱいしてきた。


PostgreSQLカンファレンス、何度行っても良いカンファレンスですし色んな人と話せて楽しかったです!!
次は3月にシンガポールで大きなPostgreSQLのカンファレンスがあるそうです。
CfPをちょうど募集中なので勉強会駆動海外旅行とか皆さんオススメです。

http://2016.pgday.asia/#callforpresentation

ということで今年も残り一ヶ月となりました。
ミカエルさんが言うとおりに今月中に本当にPostgreSQL 9.5が出るか楽しみにしたいですね!!

PostgreSQLアンチパターンの話をいっぱいしてきた。

見せてあげますよ、本当のPostgreSQLアンチパターンを。
とか言ってたわりに半分以上は削除フラグの話でした。
逆にそれが万人受けしたみたいでちょっとはてブいっぱい付いて承認欲求満たされました。
ということでスライドです。


190枚を超える超大作!!とか思ってたけど時間配分バッチシでした。
3回も実践すると3回目はアドリブ効かせたり出来て余裕がありました。
リハ大事w

で本題の伝えたいことですがあとがきツイートしてるのでまずそちらを。











特に最後のツイートが全てだと思ってます。
個人的な経験談を交えて紹介しましたがベースの話は全てこの3つの本を読めば理解できると思います。
あとはホントもっとみんなも経験の共有を積極的にしてほしいですね。
なのでslackやMLで是非「こんな事困ってるんだけど?」とか「これってどうなん?」ってのを投稿してください。
みなさんのお言葉お待ちしております。
あと、みんなに「そーだいさん、苦労されてるんですね」とか「グレて金髪になったんですか?」とか言われました。
大丈夫です、僕は今はMySQL使いです。

2015年11月30日月曜日

PyCon mini hiroshimaでPostgreSQLとPythonの話をしてきた

表題の通り、PyCon mini hiroshimaに参加してきました。
西本さんが中心となって行ったイベントですがPythonだけでなくエンジニアとして学びの多いイベントでした。
私も登壇したので下記の資料のリンクを貼っておきます。


connpassで講師の資料は公開されてるので興味の有る方は是非見てみてください。
connpass以外にも動画や当日のツイートのまとめなどもこちらからいけます。

PyCon mini hiroshima

どの講師もオススメですが私は特に石本さんの話や長谷場さんの話はPython関係なく学ぶところが多くオススメです。

ということで初めての中国地方でのPyConでした。
なぜか?中国地方ではRuby派が多く、Pythonのイベントが少ないと思います。
これを機に中国地方でもPythonのイベントが活発に行われ、交流が盛んになればいいなと思います。
また僕は最近Pythonを書く機会が減ってるので時間を見つけてPythonを書こうと思います。
興味がある人は岡山Python勉強会をチェックしてみてください。
ハングアウトでのRemote参加も可能ですのでお気軽に参加できます。
来年も続けてやるつもりなので是非コミュニティに登録をよろしくお願いします。

岡山Python勉強会

来年もPyCon mini hiroshimaはするらしいので今から楽しみです(*´ω`*)

2015年10月16日金曜日

@soudai1025がまほろば工房との想い出を語る

実は今日は最終出社日です。
@soudai1025、仕事辞めるってよ。」から2年と4ヶ月。
気がつけば早いもので株式会社 まほろば工房に来てそれだけの時間が過ぎました。
publicな場所で自分の職場を堂々と言える会社ってのは初めだったので今思うと良い転職だったなぁと思います。
そんなわけで感慨深いものがあるのでちょっと想い出語りします。

まほろばの想うところはいっぱいあるけど個人的に一番好きなのは

コミュニティ活動に対して積極的な支援があること


ですね。
僕はコミュニティが大好きだし、コミュニティに育ててもらったと思ってます。
そのコミュニティに対して会社が理解ある&支援があるってはもう仕事中にビール飲めるみたいな感覚です。
(ちなみに弊社は実際に仕事中にビール飲んでも問題無いです)
エンジニアの会社って言う会社はいっぱいあるとと思うけどまほろば工房は本当にエンジニアの会社です。
社長自体もJANOGの元会長だしNetWorkコミュニティのすごい人もいっぱいいます。
なので必然的にコミュニティ活動は重要な活動として支援してくれます。



このツイートとか社風をよく表していて例えばCROSS 2015は会社に交通費と宿泊費を出して貰いました。
ただ会社で行く場合は建前上、報告書とか必要です。
これは社長の方針として上手くネゴすることもスキルの一つと言うことかららしいです。
ちなみに出張報告書と言っても経費精算みたいなもんです。
JPUGの予算稟議の方が数倍厳しいです(それでも普通の会社の稟議より超緩いですが)
なので平日の勉強会参加は勿論、気軽に遠方の勉強会参加が出来るようになったのは本当に嬉しかったです。
更に凄い所は自分が「イベントやりたいけど金無いんで協賛オナシャス」に即答でスポンサーしてくれたこと。
実際に




の2回協賛してもらいました。
特に合同DB勉強会は





って事があったので本当にスポンサーしてもらってよかったと感謝しています。
コミュニティ活動をしたい、楽しみたいって人にとっては最高の環境だと思います。

あと好きなのは

裏福利厚生が充実してること


これは転職サイトとか会社ホームページからではわかんないですよね。
実際には





があります。
まぁでもエンジニアとしてやっぱ知りたいところは開発環境ですかね。



基本的に自由です。
Windowが多いですけどMac使ってる人もいます。
あと自分のノートPC持ち込んだりも出来ます。
実際に僕はキーボード(Realforce)やマウス(ロジクール)やモニタ(MITSUBISHI)を持ち込んでます。
そもそも会社でAmazon受け取りOKなので本などは会社に着くようにしてたりします。
ちなみに実際に使うことが多いのは


  • Linux(CentOSもUbuntuもあります)
  • PostgreSQL(僕の権限によりPGですがMySQLもあります)
  • PHP(フレームワークはFuelPHP使ってます)
  • ヤマハルータ(あとVyOS)
  • VM Wear(KVMとXenはちょろっとある)
  • Git(VCSはgitbucket)


ってな感じです。
僕はアプリケーションより下のレイヤーはまほろばに入って本当に鍛えられたと思います。
Linuxの基礎的な知識やカーネル周りの挙動は詳しい人が多いので勉強になります。
最近だとコンテナ化もやったりしました。
勿論デメリットもあります。



そうです、残念ながら篠崎愛はいないんです(´;ω;`)ブワッ

まぁ冗談はこれぐらいにして技術者として学ぶことが多い職場だと思います。
僕はちょいちょい社内ツールや会社ページのリプレースなんかで新しい技術を導入しました。
そういう技術選定権限の自由さは前職にはなかったので上から下まで学べたなと思います。

ということでエンジニアとして学ぶには良い会社だったと胸を張って言える会社です。

あと社会人、まほろばのチームの一員として。

僕はチーム最年少です。
入社時は20代でしたが今は30なので会社に20代がいません。
これはまほろばの課題だと思ってます。
僕が退社後、数名入社予定ですがみんな30代です。
技術要求度とかスキルマップ的に年齢層があがります。
そこはわかるのですが世代交代や技術継承も考えていかなきゃいけない課題です。
まだまだ暗中模索してる感の強いところなので今後パワフルな若手とか入ると期待してます。

メンバーの一員としてみたらみんな優しくて風通し良い会社です。
直属の上司は女性だったのですが本当に良くしていただいたと思います。
私の悪い癖で時々感情的に批判的な言動をする時があります。
そういう時も冷静に諭していただいて大人の対応とは何かを学ばせていただきました。
こういう精神的な成長がこの2年間で一番多かった気がします。
若い人が多いチームはそれはそれで面白いです。
ですが社会人として先輩から学ぶこともまだまだ多いなと感じました。
勿論、若い人から学ぶ事も沢山あります。
ですので「他者から学ぶ事に年齢は関係ない」です。
ですが孔子も論語で言ってますが年齢によって変わる思想もあると思います。
そういった人間的な意味でもまほろば工房は良いチームだなと思います。


ということで振り返った結果、本当に良い会社だったなぁの一言に尽きます。

ちなみに今後は一応方針は決まっています。
ですがまだ未定な所も多いのでしばらくは多分フリーでダラダラしてます。
元々昼は自宅で食べてたし家でもコードは書けるので生活環境は大きく変わりません。
なので暫くはTwitterに居るのは変わらないとは思いますw
でもこうやって会社でブログを更新することもなくなりますね...
(今思えばこのブログの大半は会社で更新されてるわけですが)
と最後は少しセンチメンタルな感じになりましたが今後もまほろば工房をよろしくお願いします。

ということで取り敢えず干し芋置いときます。

私は真に驚くべき欲しい物を見つけたが、この余白はそれを書くには狭すぎる


2015年10月12日月曜日

2大OSSデータベースのMySQLとPostgreSQLの違いについて話してきた

第32回 PostgreSQL 勉強会(2015年10月10日)で登壇してきました。
内容は前に書いたエントリーの


を元に発表してきました。
と言っても今回は参加者がPostgresSQLに詳しい前提だったのでMySQLを中心に話をしました。
実際の資料は下記のとおりです。
当日はビデオ撮影があったのでそのうち動画が上がると思います。

第32回 PostgreSQL 勉強会まとめ ~ togetter ~




流石に2時間は疲れました。
内容としては眠くならないように面白おかしく伝えようと思ったのですがなかなか難しかったです。
前半はMySQLとPostgreSQLの方向性の違いをメインにしました。
後半はMySQLは僕が実際にハマった事などをメインにしました。
個人的にはRDBの選択は適材適所以上の答えは無いと思ってます。
MySQLの並列処理性能やレプリケーションはPostgresSQLには足りないものです。
PostgresSQLの方が素晴らしいではなく住み分けだよと伝えたつもりです。
資料だけだとMySQLのDis話がメインなのですれ違いが無いようにここで補足しておきます。
実際にもっと深く知りたい人はMyNA会やPostgreSQLカンファレンスに来てもらえたらと思います。
ということでPostgreSQL勉強会デビューの話しでした。

####追記####



マサカリ訂正をいくつかいただいたので追記します。
間違った知識広がったらいけませんし。

1. トランザクションレベルのSERIALIZABLEの挙動の誤記
SERIALIZABLEの読み取りロックはNOって書いてますけどYESが正しいです。
PostgreSQLもMySQLもSERIALIZABLEにするとロックを獲得すると他トランザクションのSELECTに対してもロック待ちさせます。
SERIALIZABLEについては触れなかったので当日は誰も気づいてなかったぽいですが間違いです。

2. MySQLのInnoDBはREPEATABLE READはファントムリードしない
PostgreSQLはするのでそういうもんだと思ってました。
デフォルトのREPEATABLE READが堅いということになります。
MySQLすごい!!

3. @yoku0825さんからの指摘事項がいっぱい



















つまり、みんな@yoku0825をフォローしよう。
(いつもアドバイスありがとうございます)

#スライドの中で話題にした本並べときます







2015年10月6日火曜日

問題にチャレンジしてもらうために必要な事を考えてみた

私は人が成長するときは


  • 行動した時(そしてその最中)
  • 結果を振り返った時(失敗、成功を問わず)


の2つだと考えてます。
その2つを得るには問題にチャレンジすることが非常に重要です。
つまりチームやメンバーが成長していくためには如何にチャレンジを繰り返せるかです。
しかし元も子もない話をすると私は「崖から落とされたら勝手に這い上がってくる」タイプです。
ですから成長方法は基本的に崖から落とされて真っ向から突き進んで失敗したり解決したりして強くなってきました。
この手法を個人的にはサイヤ人ブートキャンプと言っていて、死にかけて強くなるので高速に成長します
ただし、用法用量を守らないと死にます(精神または物理で)
ですので他の人に勧められる方法ではないなと悩んでいます。
そして不幸な事に地球人が崖から落ちてしまう事もあります。
そんな時、助ける術も必要だなぁと最近良く考えているので整理してみます。

まず@razonさんが仰るとおり



がすべてを表しています。
私には階段が思いつきません。
そもそもこのツイートを見て「なるほど、階段って手があるのか!」と目からウロコだったほどです。
実際にはエレベータだろうが階段だろうが「そもそも登らない」だろうが選択肢はN択です。
なのでバカ正直に真っ向から登る必要は無いのですが私は真っ向から登って登れてしまうので発想が貧弱なのです。
「人間は経験したことしか想像できない」ものです。
だからこそ、このアウトプットを元に新たなインプットに期待してます。


と前置きが長くなりましたが本題。

アジェンダは


  1. チャレンジする人のメンタルモデル
  2. チャレンジの手法について
  3. 実際にチャレンジしてもらうには


です。
では早速本題に入ります。

1. チャレンジする人のメンタルモデル

チャレンジャーな人は活発的な人が多いとかそういうのは関係ないです。
ここは単純に

チャレンジした結果、成功した体験がある

って事に集約されると思ってます。
これは幼少期からこれまでの間の成功体験を元に問題解決を計ります。
大切なのは

成功体験の内容でチャレンジの手法が決まる

というところです。
これは2.に繋がるのですが冒頭でも触れた「人間は経験したことしか想像できない」というところにも繋がります。
逆説的ですが成功体験が無い場合、チャレンジをするメリットもわかりませんし、手法もありません。
これは卵が先か鶏が先かの難しい問題も秘めています。

2. チャレンジの手法について

1.でも触れたとおり、成功体験が重要です。
真っ直ぐ登って登れた人はまずは登ろうとします。
周囲に階段を作って成功した人を知っていれば階段を作り始めるかもしれません。
具体的には私は素直な子?でしたから問題については実力行使(物理)で突き進んできました。
ですので現在もよく崖から落ちたら真っ直ぐ崖を登り始めます。
これがチームの場合、大抵多くの人が「私には無理だ」と呆れてついてこれません。
これも過去何度も経験しました。
また素上りした結果、落石などのアクシデントやヒューマンエラーなどで何度も死にかけました。
その結果、最近は

  • 流石に素上り危ないから命綱を持とう
  • 一人では限界があるからサポートメンバーを持とう

などの選択肢を覚えてきました。
これが問題解決のノウハウとよべる部分です。
ですがこのノウハウは基本的には問題に真っ向勝負志向の人です。
階段派などにはこのノウハウを共有してもなかなかマッチしません。
つまりノウハウを共有しても必ずもすべての人に有益とは限りません。
そしてチームは多様性を持つべきですし色んな人がいます。
ですので往々にして多くの人にとって有益なノウハウとなりません。
これでは周囲はなかなかチャレンジできません。
ですのでビスマルクの

愚者は経験に学び、賢者は歴史に学ぶ

が大事だと思います。
つまりは他人の成功体験を知る
しかしこれは好きな女性が相手ならまだしもどうでもいいおっさんの場合は苦痛です。
しかも自分と考え方の指向性が違えば自分のノウハウとして蓄積しない(共感できない)ため尚更です。
なので情報収集のスタイルも十人十色だと思います。
ここでは私の代表的な情報収集スタイルをご紹介します。

・本を読む

ありきたりですが確実に情報を収集できます。
多くの手法を学ぶには一番手っ取り早いかもしれません。
また新書で出てることが多くちょっとした時間で読むことができます。
ただしデメリットが2つあって一つは基本的に良い話しかありません
罠や泥臭い話は映えないのでカットされがちです。
それと大分話を盛ってあることも多いので鵜呑みにすると痛い目をみます
誰もが若かりし青春時代、ニーチェを読み、ユングを読み、痛い厨二病時代があった思います。
また意識高い新卒にありがちなビジネス書や自己啓発本に毒されて応用が利かない時代もあったと思います。
人それぞれですが偏ると何事も毒になるので要注意です。

・飲み会に行く

基本的におっさんは自分の成功体験の昔話を若者にしたがるものです。
なので飲み会にホイホイ付いて行けば自然とその話を聞くこともできるでしょう。
これは自分に近い立場の人ほど自分に近い経験なので情報として有益です。
また成功体験と言ってもそのプロセスの詳細も聞けるので本には無い罠や泥臭い話も聞けます
ただしこのデメリットは


  • おっさんは酔っ払うと話がループする
  • 同じような話を毎回する
  • 途中から説教になる


があります。
なのである程度一通り聞いてしまうとそれ以上の情報収集は難しいです。
このリスク回避は非常に難しいのですが下記の方法を取ると評価を上げるチャンスになります。



もし会社の飲み会がつまらないなぁと思うなら上司の話を話半分に聞きながらやってみてください。
酔っ払いのおっさんほど効果抜群です。
20~30分前に行ってた事をオウム返しするだけでも十分です。
するとおっさんも「君は見込みがあるなぁ!」など言い出すでしょう。
そうなると次回の飲み代も出してくれるはずです。
今度はいい飲み屋知ってますよ!!とか言ってちょっと普段行かないお高いお店行ったりして有効活用しましょう。
おっと話が脱線しました。
会社の飲み会だけでなくエンジニアの集まる勉強会や地域の会合などにも同様の効果があります。
こちらは会社よりもメンバーの流動性が高いので多くの話を聞くことが出来るでしょう。
こういう場を上手く活用すれば現場の生の声を沢山得ることが出来ると思います。


私の場合はこの2つがメインの軸です。
なので機会があれば皆様の成功体験を聞かせていただければと思います。
また情報収集についても「こんな方法もあるよ」というのがあれば是非教えていただければと思います。


3. 実際にチャレンジしてもらうには

1と2の結論として


  • 本人(またはチームに)成功体験がある
  • その成功体験にマッチした手法がある


この2つが重要だと言う結論になりました。
しかしもう一つ重要な要素があります。

適切な大きさの問題

であることです。
みなさんもチャレンジする側が成熟していないのに大きい問題にぶつかり挫折する。
そんなシーンを見たことがあるのではないでしょうか。
この適切な大きさの問題については@snagaさんに面白い記事を紹介してもらいました。



ここでは成功体験の有無や手法など関係なく

適切な問題が生まれれば自然と解決する人が生まれる

という話題が出てきます。
これは私も経験があります。
つまりこの2つをまとめると


  • チャレンジさせたい人には適切な問題を与える
  • 解決したい問題を適切な問題に細分化し再配布する


これが成長するマネージメントのコツなのでは無いかと思います。
そうなると1の成功体験の有無は関係ないように見えます。
しかしこれは「自ら適切な問題は見出したり細分化する際に必要」なことなのです。
なので多くの成功体験を持った方がセルフマネージメントに長けた人になるのです。
また2の多くの成功手法を知る人が適切なチームマネージメントを行える人になるのです。
もっと視野を広げれば「適切な問題を生み出せる」事が経営者やリーダーとして適正なのではないでしょうか。

ということで以上の事を踏まえた上で私は今、「適切な問題を生み出す」とは何なのか考えています。

2015年9月15日火曜日

SlackにPostgreSQL部屋を作った

こないだ酒気帯びブログでこんな反響があった。



MySQLのSlackに参加してて積極的に意見交換されてて素晴らしいなと思っていたので即行動してみた。


PostgreSQL部屋に入るSlackin



しばらくは僕が管理人をしてますが上手いことみんなに権限をシェアしていけたらいいなと思ってます。
なんかSlack inが動いてないよーとか新しいチャネル欲しいよーとかあれば@soudai1025まで。
ほんとに気軽にご活用ください。
他愛もない話でもいいですしイベントの告知とかもありです。
ちょっと困った事とか日本語ドキュメントよくわからないとかも良いと思います。
それではみなさま、お待ちしております。

コミュニティに参加してよかったなと思うことをまとめてみた 〜 第11回 中国地方DB勉強会 in 広島 〜

今週末の9/19にはOSC広島、9/20には中国地方DB勉強会 in 広島があるのだけどDB勉強会は登壇するので資料を作りました。
その資料を敢えて先に公開します。
当日来る人はこの内容を呼んだ上で思うところをFAQでぶつけてくれると嬉しいです。



まとめてしまうとJPUGの宣伝と昔話とコミュニティに感謝の話です。
僕はエンジニアになって本当にコミュニティに育てて貰ったと思うし30代はその恩送りをしていく時期だと思ってます。
だからこそ地方のエンジニアは積極的にコミュニティに参加して欲しいと願っています。
以前にも真面目な話のエントリも書いたけど中四国地方は大切なターニングポイントの時期に来てると思ってます。
そんな時期に僕もそうだし、みんなにも考えるきっかけになってくれれば幸いです。
その上で「何か新しいことに踏みだそう」と思ってる方がいれば僕が押してもらったように僕も背中を押したいと思います。
そうやって恩は巡って行くものだと思うしコミュニティはそうやって形を変えていくものだと思うので。

ということで皆様にどこかのコミュニティでお会いできるのを楽しみにしています。

2015年9月5日土曜日

Webで役立つPostgreSQLの話をしてきた ~ OSC新潟2015 ~




初めての新潟行って来ました!!
15分しかなかったのでざっくりPostgreSQLの話をしました。



久々にチャレンジでした。
無事に15分で収まった(収まってないけど)のは奇跡でしたねw
また各項目の詳細はそれぞれ別々のイベントで細かく話したので纏めを置いておきます。




■第九回 中国地方DB勉強会 in 米子を開いてきた
(SQLの話をした時の資料がまとまってます)

■MyNA・JPUG合同DB勉強会 in 東京を開催してきた(FDWの話もしてきた)
FDWの話をした時の資料がまとまってます。
またNTTデータの澤田くんがナイスなJSONの話をしてるので是非一読してください!!

日本酒!お米!!新潟!!
OSCは全国で開催されているので気軽に旅行する理由になって最高ですね!!
そういえばちょうど次は広島で行われるそうです。
興味がある人は是非。

■OSC2015 Hiroshimaタイムテーブル
日程:2015年9月19日(土) 10:00-17:00(展示は10:00-16:00)
会場:サテライトキャンパスひろしま [アクセスマップ]
   (広島県民文化センター 5F)広島市中区大手町1丁目5-3
   広電最寄駅→紙屋町西 ・ 最寄バス停→紙屋町

費用:無料

ということで翌日はDB勉強会 in 広島も行われます。
合わせて旅行駆動勉強会参加をご検討してみてください。

2015年8月25日火曜日

MySQL使いの人がPostgreSQLを始めるときの罠をまとめてみた

昨日書いたエントリがなかなかいい感じに拡散された。

MySQL使いが知るべきPostgreSQLとの違いと変わらない一つのこと


で気付いた。
多分本当にMySQL5.7の罠が理由でPostgreSQLに移行する人は上のエントリを求めてない。
つまり本来ターゲットにすべき人は


  • SQLはORMが解決してくれるから違いなんて気にしない
  • ロジックはSQLではなくアプリケーションコード側が行う
  • DBはデータを置くストレージだ、いいね?


みたいな人だ。
前述のエントリでよしPostgreSQL使おう!!って人は多分MySQL使っても乗り越えていける人たちだ。
勿論そんな人達がPostgreSQLに来てくれるのは嬉しいし大歓迎。
それとは別にもっと窓口を拡げるために必要な移行時の罠をまとめておく。
これはMySQLと比較しながらPostgreSQLの事を書く。
だが初めてPostgreSQLを触る人は知っておいた方が良いことのまとめになるはずだ。


1. DBを作成するときの罠


一番最初にPostgreSQLをLinux等にインストールすると
service postgresql-9.4 initdb
をまずはすると思う。
その場合、PostgreSQLのデフォルトのロケールはOS側に設定されているロケールを使用する
つまり多くの場合は

ja_JP.UTF-8

となる。
これに伴いDBが壊れるということはない。
ただしソート順に影響する。
具体的には

日本語ロケールでは辞書順(カタカナ→ひらがな, 清音→濁音→半濁音) の順にソートされる

のだ。
多くのシステムの場合、これは想定外のソート順になる。
そのためDBを作成する際には

service postgresql-9.4 initdb --locale=C

service postgresql-9.4 initdb --no-locale
を指定することになる。
どちらも同義である。
こちらを行うことにより文字のバイナリ値を基準にしたソートになる。
絵文字でソートしたい場合も安心だ。
詳しくは下記のエントリを参考にして欲しい。

ロケール(国際化と地域化)



2. アクセス制御の罠


MySQLに対するアクセス制限はmy.cnfに
bind-address = 127.0.0.1
と書いたりMySQLのuserテーブルで指定したりする。
それに対し、PostgreSQLはDBをインストールしたフォルダ内のpg_hba.confで制御する。
こちらについては先日紹介したとみたさんのエントリでも紹介されている。

MySQLユーザーがPostgreSQLを触ってみたメモ


その際に気をつけてほしいことがある。
それはMETHODの指定である。

host    all    all    192.168.0.0/24    trust
としてあったとする。

これは192.168.0.1~192.168.0.255のIPアドレスからのアクセスはパスワード認証無しでアクセスできる設定だ。
もしこのDBが外に晒されており、全てのIPを表す0.0.0.0/0を指定した場合は自由にアクセスできる事になる。
PostgreSQLはdefaultでスーパーユーザーとしてpostgresというユーザが作成される。
この状態でpostgresユーザでアクセスすれば...結果は明白である。
笑い事に聞こえるかもしれないがEC2やVPSでDBを作っている場合に一時的にtrustを指定する人を見かける。
そして設定は明示的にに読み込みを行わなければならない。
ここに大きな罠があり


  1. 確認のためpg_hba.confに0.0.0.0/0 trustを指定して起動。
  2. テスト終了後、pg_hba.confを修正
  3. 再起動時や再読み込みを忘れる


とするとpg_hba.confは正しいのに誰でもアクセス出来る状態のままとなる。
せめてmd5を指定するようにしよう。

host    all    all    192.168.1.1/32    md5

詳しいpg_hba.confの説明等は公式documentを読んで欲しい。

19.1. pg_hba.confファイル


なお蛇足だがそもそもpostgresql.confの設定で

listen_addresses = '*'

を指定しないとdefaultではlocalhost以外からアクセス出来ない。
設定箇所が2箇所あるので要注意だ。


3. テーブル作成時の罠

MySQLからPostgreSQLに移行した時、仮にpgadmin3を使って型を指定しようとしたら驚くだろう。
余りにもデータ型の種類が多いからだ。
データ型についてはまず公式documentのリンクを紹介しておく。

第 8章データ型


君たちが欲しいのは


  • 数値型
  • 文字列型
  • 日付/時刻型


だと思う。
それぞれについて簡単に解説しておく。

●数値型

通常は


  • bigint  8byte整数
  • integer  4byte整数
  • smallint 2byte整数
  • numeric  MySQLのDECIMAL相当
    (MySQLではnumericはDECIMALのエイリアス)


で事足りると思う。
ただPostgreSQLにはこの他に論理値データ型として


  • boolean  1byte


がある。
勿論入るのは0 or 1 or NULL(許可した場合)だ。
SQLとしてはtrue or falseでもよい。
他にも柔軟に受け入れるので使う場合は公式documentをチェックされたい。

論理値データ型


そしてサロゲートキーを使いたい場合にMySQLはAUTO INCREMENTを指定すると思う。
AUTO INCREMENTはPostgreSQLには無い
その代わりシーケンスを作り、該当の整数型のdefaultにnextval(シーケンス名)を指定することで同義になる。
とは言ったもののその手順は煩雑だ。
そのため最初から


  1. 整数型の指定
  2. シーケンスの作成
  3. 該当シーケンスをdefaultに指定


を全て丸めてやってくれる型がある。
それがserial型だ。


  • bigserial   →  bigint
  • serial     →  integer
  • smallserial  →  smallint


なおPostgreSQLのシーケンスは最大値に行った場合にCYCLEの指定の有無で周回するか決まる。
CYCLEを指定しない場合はNO CYCLEとなり周回せずにエラーが発生する。
だがserial型で作った場合はCYCLEが指定されない=最大値になるとエラーが発生する。
また自分で設定すれば連番の取得の昇降やSTEP、MAXやMINも指定できる。
CYCLEを指定して周回するIDも作れる。
またAUTO INCREMENTと違い複数テーブル(またはカラム)からも参照、指定することが出来る。
シーケンスはMySQLには無い概念なので一度調べてみると設計の幅が広がるのでオススメだ。

●文字型

PostgreSQLの文字列型は


  • character varying 可変長
  • varchar      character varyingのエイリアス
  • character     空白を埋める固定長
  • char        characterのエイリアス
  • text        制限なし可変長


となる。
実際は可変長、固定長、制限なしの可変長だ。
多くの運用の場合、固定長を使うメリットがない。
なので可変長のcharacter varying(以下varchar)かtextを使うことになる。
またvarcharとtextの違いは制限の有無のみだ。
そのため参照速度だけで言えば制限のオーバヘッドの少ないtextの方が早い
また制限する場合は


  • varchar(n)


とnを指定することになるがnは文字長(文字数)だ。
バイトでは無いので注意が必要だ。
(MySQLの場合のVARCHARはバイト数)
(MySQLも文字数だった、yoku0825さんご指摘あざます!!あと誕生日もおめざす!!)



仕様として標準SQLに準拠しているのだがそもそも標準SQLの仕様に癖がある。
一度公式documentを拝読しておくと救われるかもしれない。

8.3. 文字型


またMySQLとの大きな違いとしてPostgreSQLの文字列型は文字の大小を区別する
('A' != 'a'である)
つまりMySQLのBINARY属性を指定した状態と同じ挙動である。
文字列に関してはMySQLと大きく違う仕様が多いので注意が必要だ。
(これは逆も然りでPostgreSQL使いがMySQLを使う際に多くの人がこの罠にハマる)
蛇足としてPostgreSQLの多くの関数は文字列を受け付ける際はvarcharを指定してもtextにCASTされる。
そういった理由からよく文字列型は全てtextを指定する設計も見かける。
その場合は不正なデータを入れられた時の予防やディスク容量計算が難しくなる。
適正な型指定はデータを守るのでCHECK制約と合わせて使いわけよう。
更にPostgreSQLには列挙型(enum)もある。

8.7.1. 列挙型の宣言


(MySQLにもEnumがあるらしい)



CHECK制約とは違いデータにソート順を持たせることが出来る。
覚えておいて損はないだろう。


●日付/時刻型

日付/時刻型は

  • timestamp  日付と時刻両方を持つ 例:2015-01-01 00:00:00
  • date     日付を持つ(時刻無し) 例:2015-01-01
  • time     時刻を持つ(日付無し) 例:00:00:00
  • interval   時間間隔       例:1 year 2 months 3 days 4 hours 5 minutes 6 seconds

がある。
timestampはMySQLのdatetime相当だ。
timestampとtimeについてはtime zoneを持たせることが出来る。
(これによりMySQLのtimestampを表現することが出来る)
指定した場合はUTCとして内部で持ち、表示の際に設定されたタイムゾーンに合わせて計算してくれる。
国内で使う場合はタイムゾーンを指定しないtimestamp without time zoneで問題ない。
またMySQLのtimestampのdefaultのようにUPDATE文の対象になった際に自動的に対象レコードの指定columnをCURRENT_TIMESTAMPで更新する機能は無い。
同じようにしたい場合はトリガーを書くことになる。
これは非常に便利なのでPostgreSQLにも欲しいところだ。
またintervalについては癖の強い型だ。
そのほかの日付/時刻データ型と合わせて公式documentを見ていただきたい。

8.5. 日付/時刻データ型



●配列型と範囲型

補足としてPostgreSQLは配列型と範囲型がある。
どちらも強力な機能だが乱用は毒にもなる。
公式documentと例を上げているエントリを紹介しておく。



4. ORMの罠

RoRを使う人は問題ないがPHPerはFrameworkのORMが対応してないことがある。
まさにFuelPHPの話だ。
私は標準のクエリビルダをラッパーし自作ORMを作成しているがこれは万人向けではない。
そのため、もしPostgreSQLに対応したORMが必要な場合はDoctrine2をオススメする。
ただし悲しいことに公式documentは英語しかない。
しかしDoctrine2はSymfony2のORMだ。
そのためSymfony2の公式documentを読むことで使い方を知ることが出来る。

Symfony2


FuelPHPでインストールする場合はComposerに対応しているので安心して欲しい。

FuelPHPでdoctrine2を使ってみた


またDoctrine2を利用すればスキーママイグレーションも出来る。
(FuelPHPの標準のスキーママイグレーションはMySQL専用なので動かない)



ここまで来た君は手元のアプリケーションからDBに接続し、自由にテーブル設計できたはずだ。
長くなったので今日はここまでとする。
この後、運用で困った事があればメーリングリストで聞いてみるといい。
きっと誰かが答えてくれるはずだ。

PostgreSQLユーザ会 メーリングリスト


それでは検討を祈る。

2015年8月24日月曜日

MySQL使いが知るべきPostgreSQLとの違いと変わらない一つのこと



私が尊敬してるDBスペシャリストの@yoku0825さんがこんな事言ってた。



@yoku0825さんはMySQLのスペシャリスト中のスペシャリストだ。
その@yoku0825さんがこんな事を言うなんて只事じゃない!!
で話になった元ネタはコレ。

日々の覚書: #yapcasia でMySQL 5.7の罠についてLTしてきました


要はMySQL5.7は「目指している正しい姿」になるために下位互換性を幾つかを捨ててるよって話だ。
その中には360日問題があるけどそれ言うと正しさとは?みたいな話になるので今回は話題にしない。
(デフォルトでパスワードが360日後に無効になるという仕様がデフォルトになったという話)
MySQLを使ってる人は@yoku0825さんのブログを一読したほうがいい。
必ず知らなかった罠が幾つか見つかると思う。
そのツイート見て



とブーメラン投げて見事に刺さってるので今から記事書く。
両サイドにはかなり厳しい話もするが俺の本音を聴いておけ(関白宣言)
まぁ歴史の長いRDBなのでお互いの比較記事は沢山ある。
なのでマルチスレッド(MySQL)とマルチプロセス(PostgreSQL)だとかVACUUMだって話はしない。
むしろ実際に使ってみた際の違いをにフォーカスする。

1. SQLの違い


基本的にMySQLでやっていたことはPostgreSQL出来る。
しかし関数の挙動の違いは幾つかある。
例えば時間から曜日に該当する数字に変換した場合に


  • MySQL → date_format(time,"%w") 0から始まり、日曜日に該当する
  • PostgreSQL → to_char(time,'D') 1から始まり、日曜日に該当する


など挙動に互換性がない場合も多い。
関数を使う場合は一度仕様を確認した方がいい。
幸い、PostgreSQLは有志によって日本語ドキュメントが充実している。
今はGithubで管理されてるので誤字脱字、表現の曖昧さなどはプルリクエストすることが出来る。

PostgreSQL日本語ドキュメント




MySQLを使ってた人はPostgreSQLを使うことでWindow関数など新たに知る機能が多いだろう。
MySQLしか触ったことが無く、OracleやMSDB等を触ったことが無いなら一度SQLの勉強をした方がいい。
必ず業務を効率化してくれるはずだ。
SQL勉強する人向けには最近読んだ本でPostgreSQLベースで書いてあって読みやすかった本をオススメしとく。



じゃあPostgreSQL優秀じゃん!大は小を兼ねるじゃん!!と言いたいところだがMySQLにしか無い文法もある。
MySQLにもPostgreSQLにもMerge文はSQL標準なのに実装されてない。
しかしMySQLには代替案として




がある。
これに準ずる機能はPostgreSQLには無い。
しかしWITH句とRETURNING句(MySQLには無い機能だね)を使えば一応PostgreSQLでも表現出来る。
第九回 中国地方DB勉強会 in 米子でこの話題は取り上げたので興味がある人は資料を見て欲しい。
このリンクの先に梶山さんのMySQL5.7の話が出てるのでそっち見て欲しい、いや見たほうが良い、絶対見るべきだ。
ただ事ある毎にPostgreSQLにMerge文相当が無いことをDis指摘していたら遂に9.5からそれ相当の構文が実装された。
これはMySQLの「INSERT...ON DUPLICATE KEY UPDATE構文」と似た構文で実装されている。

INSERT ... ON CONFLICT {UPDATE | IGNORE}構文


PostgreSQL9.5に興味が出た人はリリース予定の機能が以下にまとまってる。

What's new in PostgreSQL 9.5(英語)


英語なんて読めるか!って人は下記のブログをcheckするといいだろう。

日々の記録 別館


Twitterで行われるラーメン飯テロに耐えれるなら著者のぬこさんをフォローするのもいい。
あとはみかかな人たちが頑張ってるのでSlideShareをWatchすると幸せになれるかもしれない。
オススメのSlideShareのリンクを貼っておく。

10大ニュースで振り返るPGCon2015


おっと話が大分脱線してしまった。
話を戻すがPostgreSQLのSQLは


  • 文字結合が||で出来る
  • 日付操作がday +1で出来る


などどちらかと言えばOracleを意識した記述も多い。
ただ悪名高き(+)は無いしNULL = ""も無いのでそこは安心して欲しい
なのでわかりやすく例えるとしたら

ザ・キング・オブ・ファイターズの95の京と96の京くらい違う


といったところか。
新日本企画が産んだ名作格ゲー、ザ・キング・オブ・ファイターズを知らない若者は

細かいところは違うけど大体一緒でPostgreSQLの方が痒いところに手が届きやすい


くらいのニュアンスで居るといい。
つまりSQLに関してPostgreSQLに乗り換えて不満が出ることは少ないだろう。


2. 機能の違い


これもPostgreSQLの方が多い。
まずマテリアライズド・ビュー(以下マテビュー)がPostgreSQLにはある。
簡潔に言うとviewの結果を実体としてキャッシュするというものだ。
これでtmp_hogeみたいな中間テーブルを作る必要は無くなる。
ただし銀の弾丸ではない
乱用するとCPUやHDDリソースなどが死ぬ。
そのほかにもCHECK制約があるがこのへんはMySQLで慣れた人には使うシーンが想像出来ないと思う。
データにバグやヒューマンエラーで不正なデータが入って苦しんだ人は覚えておくいい。
次の新規設計時にDBがデータを守ってくれる。
どちらかと言えば


  • JOINのアルゴリズムが複数ある
  • 相関サブクエリが早い


と言う点がMySQLと比較すると直接的にパフォーマンスが上がりメリット感じるところだろう。
ただしUPDATE文に関してはPostgreSQLの方が遅い(場合が多い)
これは追記型アーキテクチャの壁なのでMySQLの方が有利な点だ。
しかしガンガンUPDATEを走らすようなシステムはロックを必要とするはずでロック待ちの方が速度に影響およぼす。
そのため直接的に問題になることは少ないはずだ。

さてここまで話をしたのはPostgreSQLの良いところだ。
勿論MySQLの方が有利な機能もある。
それはレプリケーションだ。
そもそも論としてMySQLとPostgreSQLはアーキテクチャが違うのだがPostgreSQLには自動フェイルオーバーはない。
PostgreSQLの場合はPacemakerなどのサードパーティを利用して実現することになる。
corosyncに苦い思い出がある人は機会があれば一緒に飲もう。
また自動フェイルオーバーはMySQL5.6からの機能だ。
MySQL5.6をまだCHECKしてない人は奥野さんのブログを見るといいだろう。

開発スピードアクセル全開ぶっちぎり!日本よ、これがMySQL 5.6だッ!!


とは行ってもPostgreSQLのレプリケーションに対する投資は素晴らしく今は追いつきつつあると行っても過言ではない。
以上の通り機能面でもSQLと同様の事が言える。
ここも安心してPostgreSQLを推せる内容だ。


3. GUIツールの違い


ここからはPostgreSQLのダメな所になる。
正直言ってPostgreSQLの管理や設定を一つのGUIで全て行うのは諦めた方がいい。
まずSQLエディタ(DBAツール)だがMySQL使いはWorkbenchを使ってると思う。
基本無料なので使ってない人は是非使った方がいい。
それに対してPostgreSQLはpgAdmin3になる。
残念ながら使いやすいとは言い難い。
例えばMacOS版は日本語入力がインラインではない。
この時点でリュウが使ったら殺意の波動に目覚めるレベルだ。
カプコンが産んだ名作、ストリートファイターを知らない若者はウメハラの背水の陣を見ておくといい。
そしてpgAdminは大切な場面で度々落ちる。
エクセル方眼紙を彷彿させると言えば共感してくれる方も多いだろう。
とにかく、PostgreSQLのGUI関連は弱い。
周囲に聞くとみんなコマンドラインの黒い画面でpsqlを直接操作しているらしい。
なので不満がコミュニティからあまり出ていないようだ。
しかし私は補完が利かない環境での開発は耐えれない若者なので代替案として以下のツールを使ってる。




どちらも無料で使え、ER図をリバース・エンジニアリングしたり出来る。
しかもPostgreSQLもMySQLにも繋げれるのでオススメだ。
0xDBEはIDEを開発してるJetBrains製でMacOSでもWindowsでも動くので是非試して欲しい。
A5:SQL Mk-2はmatsubaraさんが個人で開発されてる。
日本語だしExcelにテーブル定義書をリバース・エンジニアリング出来る。
これが無料なのが信じれないレベルのクオリティだ。
なおphpMyAdminに対抗したphpPgAdminも一応ある。
インストールしないことをオススメする。
とモダンなUIとは程遠いPostgreSQLだがPythonでpgAdmin4を作るという話が進んでる。
これがキラーアプリになってくれることを切に願っている。

4. ハードウェアでの違い


長くなってきたので簡潔に言う。
PostgreSQLはMySQLと違ってSSDにしたからといって何十倍の速度も出ない
(せいぜい数倍程度)
さらにFusion-ioは特にMySQLに特化してるのでその差は顕著だ。
PostgreSQLはHDDに特化してシーケンスに書き込もうとするのでそのオーバーヘッドの差が大きい。
もし、金の弾丸でPostgreSQLを殴るときはまずはメモリを増やそう。
PostgreSQLに限らずRDBの多くの問題は金で殴ってメモリを増やすと解決することが多い。
それでもダメな場合は優秀なDBエンジニアを用意しよう。
PostgreSQLはハードウェアを金で殴りにくいのは事実だ。

5. クラウド上での違い


やっとAWS RDSにPostgreSQLが去年追加された。
しかしまだ日本語の全文検索拡張はインストール出来ないしAuroraのPostgreSQL版も無い。
だがHerokuを初め、標準的な使い方であればPostgreSQLをsupportしてるところも出てきた。
国内だとニフティがRDSとしてPostgreSQLをサービスしている。
このへんはOSC 沖縄の時に話をしたので興味がある人はそちらを参考にして欲しい。

OSC沖縄でクラウドの選び方の話で登壇してきたので資料を公開する





随分と話が長くなってしまった。
本当はPostgreSQLには


  • PL/SQLの代わりにPL/PythonやPL/JavaScriptが使える
  • 外部テーブルラッパー(FDW)を使えばPostgreSQLのtableのようにMySQLを参照できる
  • MySQLと違いトリガーを行単位とクエリ単位が選べる(MySQLは行単位のみ)


などの話もしたかったがこのへんの話はまた別の機会にしようと思う。
なお、全然実践的じゃなかったし本当にMySQL派の人がPostgreSQLを使うときのハマリどころは皆無だった。
そこでお詫びにとみたさんの記事を紹介する。



最後になるがMySQLとPostgreSQLはライバル同士だ
しかしながらコミュニティ間はフレンドリーそのものだ。
他にライバル同士がこんなにフレンドリーなOSSコミュニティはあるのだろうか。
実際に合同勉強が開かれたりもする。

MyNA・JPUG合同DB勉強会 in 東京を開催してきた(FDWの話もしてきた)


私はそういうところがRDBのOSS界隈の好きなところである。
これを読んで興味を持った人は是非、DBのコミュニティに参加して欲しい。
MyNAもJPUGも暖かく迎えてくれるだろう。
それはどちらのコミュニティも変わらないことだ。


#### 2015/08/25追記 ####

好評だったので第二弾も作った

MySQL使いの人がPostgreSQLを始めるときの罠をまとめてみた

2015年8月10日月曜日

IoT時代を生き残るためにIPを扱うならPostgreSQL!!

皆様、時代はIoTと言われてますがIPv6使ってますか?
IPv4でも面倒くさい色々と苦労はあったと思います。
ですがIPv6になると

  • ソートとか大変(文字列ソートではダメ)
  • 検索とかもっと面倒くさい(範囲の検索とか)
  • 特定のIPの次のIPを取得するの面倒くさい(IPのインクリメントでの払い出しとか)

などIPv4の時に苦労した事がIPv6ではもっと大変になります。
例えばPHPだとip2long()って関数がありますがIPv6は非対応です。
なぜかと言うとIPv6だとlongに入り切らないからね!!
そうなるとソートとかインクリメントとか工夫が必要になります。
ですがPostgreSQLのネットワークアドレス型を使うと良きに計らってくれます。
ソートや検索はORDER BYやWHEREでOK!
インクリメントについては

SELECT '192.168.0.1'::inet + 1


とするとちゃんと"192.168.0.2"を返してくれます。
勿論IPv6にも完全対応!!

SELECT '2001:0db8:0000:0000:3456:0000:0000:0000'::inet + 1


"2001:db8::3456:0:0:1"が帰ってきます!
見ての通り省略記法にも対応されてます。
検索も内包を

SELECT inet '192.168.1.5' << inet '192.168.1/24'


と表現できます!!
(この場合は含まれるのでTRUEが返ってきます)
勿論WHEREに

SELECT * FROM ip_address
WHERE ip << inet '192.168.1/24'

のような記述で書けます! 他にも色んな書き方ができるので是非公式ドキュメントを一読してみてください。

公式ドキュメント

と言うことでこれからIoTに関わるとネットワークを管理する必要が増えてくると思います。
そのときは是非ともPostgreSQLを使ってみてください。

餃子の皮から作るか既成品を買って来るかの話

弊社は素晴らしいCのプログラマばかり。
僕はほとんどCを書かずLLの甘えた環境で富豪プログラミングするので社内で良くディスカッションになることがある。
それは

  ◯◯を0から作るか外部から持ってくるか

という話。
◯◯はLibraryだったりサービスだったり色々あるのだけど僕は車輪の再開発は極力しない派。
Libraryの学習コストを含めても0から作るより持ってきたほうが良い品質で早く出来るから。
でも社内では時々で0から作ったほうが早い(納期も速度も)という話が出てくる。
たしかに既存のLibraryをラッパーしたりそれを改修したりするぐらいなら作りなおした方が早いこともあるのだけど「正気か?」みたいな規模の時でも発生する。
しかも事実彼ら(Cプログラマ)はほぼ当初の予定通り工数で仕上げてくる。
この現象についていい名前無いかなぁって話をオープンセミナー香川の懇親会で話をしたら@blue48さんが

「それはね、餃子の皮だよ」

と表現して感銘を受けた。
確かに職人はスーパーに言って餃子の皮を買って来るより自分で作ったほうが早いし美味い。
逆に俺みたいなパンピーは餃子の皮を買ってきたほうが早いし美味い。
どちらが正しいとかじゃなくて餃子に関して言えば

・前者はそこでしか食べれないクオリティの高い餃子を提供できる
・後者は安い早いそこそこ美味い餃子を提供できる

なので方向性の違い。
でその方向性の違いなんだけどエンジニアにもそれは言えるよなぁと。
つまりは自分が何処でスペシャリティを発揮するか。

そうやって自分のエンジニアとしてのポジションを振り返った時に色々思うこともあるなぁと言うお話でした。

なお、妻は餃子の皮は作る派です。

2015年7月20日月曜日

第10回 中国地方DB勉強会 in 岡山をJAWS-UGと共催してDDDの話をしてきた #ChugokuDB #jawsug



今回のDB勉強会は僕の大好きなスーパーエンジニア カズさんのありがたいお言葉から始まりました。
ちなみに僕のGithubは真っ白でした。

ということで第10回 中国地方DB勉強会 in 岡山を開催してきました。
岡山は勉強会というコミュニティが成熟してきたなぁという実感が凄くありました。
例えば会場の準備、当日の担当の分担、めっちゃ低いドタキャン率。
どれも主催の私からすると本当に何もしなくてもイベントが進むレベルで聴衆者のような気分でした。
これは私達よりももっと先輩のひらさんやきよくらさんたちが積み上げて来た歴史が為せる技です。
この良き文化を引き継ぎ、もっと多くの地方に拡散していくのが私達の世代のミッションだなと思ったりしたのでした。

とちょっと話がそれましたが今回はJAWS-UGとの共催でした。
なのでAWSのセッションが半分、DB枠としてDDDの話が半分といった感じで総勢26名の参加がありました。
実務を通じた経験の話やAWSの最先端の話は非常に面白く、岡山特有のQ&Aの盛り上がりは流石の一言です。
そして毎度ながらご協力してくださった講師・スタッフの皆様、ありがとうございました。
そんな第10回の詳細は次のとおりです。

■登壇資料など
中国地方DB勉強会のポータルサイトにまとめました。

中国地方DB勉強会


※今回は動画の配信はありません

■メーリングリスト
次回の告知についてはMLやDoorKeeperを使います。
興味がある方はチェックしてみてください。

中国地方DB勉強会ML Google Group

DoorKeeper


■twitterのまとめ
Twitterについては@razonさんがまとめてくれています。

Twitterのまとめ


それと第11回はOSC広島の翌日に同会場で開催します。
シルバーウィークの5連休の初日がOSC、翌日が中国地方DB勉強会となっています。
勉強会駆動旅行に是非ご活用ください。
ただ、もう宿が埋まりつつあるようです。
参加希望の方はお早めにお申込みと宿泊場所の確保をよろしくお願い致します。

■第11回 中国地方DB勉強会 in 広島
■概要
日時: 2015-09-20(日)10:00 - 17:00
会場:広島県広島市中区大手町1-5-3 サテライトキャンパスひろしま 504号室


詳細はこちら
第11回 中国地方DB勉強会 in 広島

※セッション対象予定
柿木さん(地元枠):実務を通したDBの話
MySQL枠:調整中
きよくらさん(OITEC):SQL Serverの話
渡辺さん(地元枠):開発を通したDBの話
津田さん(地元枠):DBの面白い話
吉田さん(JPUG):DBの面白い話
曽根さん:コミュニティを通したDBの話

DBを通した幸せになった話(苦労した話)をテーマ(それ以外もありますが)やろうと思います。
前日のOSC広島にもJPUGは参加します。
こちらも面白いセミナーが目白押しなので是非参加してみてください。

オープンソースカンファレンス2015@広島

なお、懇親会は18:00~20:00で考えています。
交流含めて是非参加をご検討していただけたらと思います。

さていよいよ3年目に突入し、DB勉強会はJPUGやDBの枠に収まらず色んなコミュニティやソフトウェアのサラダボウルのような場所になっていければと思ってます。
初心者から上級者まで色んな人の交流の場としてもご活用ください。
なのでこれからも中国地方で楽しい勉強会として頑張って行きたいと思います。
それでは皆様のご参加、お待ちしております!!

2015年7月17日金曜日

オープンセミナー2015@香川でRDBとNOSQLの住み分けについて登壇してきた #osk2015



怒涛の登壇ラッシュ3週目。
うどんを食べに登壇するために香川県高松市に行って来ました。

はてブのホットエントリ入りもした当日の資料はこちらです(ドヤァ



最後にオススメの書籍を3冊紹介してます。
どれもオススメですがNOSQLの基礎知識はより詳しく実例を交えて情報がまとまっています。
データモデルについてはデータベース実践入門を読むことで正しい知識を得ることができます。
そしてSQLアンチパターンは苦手な事を無理矢理すると悲劇を生むことを教えてくれます。
どれもオススメなので興味があるかたは是非読んでみてください。
当日は動画撮影があったのでそのうち公開されると思います。







NOSQLとRDBの住み分けについては色んな方がお話されてます。
実際にNOSQLはシンプルな機能にフォーカスして特化してるソフトウェアがほとんどです。
だからこそ、このような全体を通した住み分けの理解が必要です。
その大前提の上で資料のまとめにもありますが


  • RDBで問題ない場合は無理にNOSQLを使わない
  • RDBが苦手な事を無理にRDBに当てはめない


ということが大切なことです。
この両方を念頭に置けばデータ層における適切なインフラ設計は自然と出来るのではないかと思います。
(そのためにそれぞれの得手不得手を知る必要もありますけどね)

また先月は東京でNOSQLとRDBで住み分けた後の世界の話をしてます。

MyNA・JPUG合同DB勉強会 in 東京を開催してきた

PostgreSQLの外部データラッパー(FDW)は住み分けた後の橋渡しとして面白いアプローチです。
こちらも合わせて見ていただけたらと思います。

ということで明日で私の登壇ラッシュが一段落落ち着きます。
明日は そもそも糞の上に何を載せても糞 設計や要件定義がしっかりしてないと実装でどんなに頑張っても辛いという話をしようと思ってます。
興味がある方は中国地方DB勉強会ハッシュタグ(#ChugokuDB)をWatchしてみてください!
僕はEVO(格ゲーの世界大会)があるのでそちらに注力します!!(ぉぃ

ということで、データ層の住み分けの話を香川でしてきました。
(うどん、マジで美味かったです)

OSC沖縄でクラウドの選び方の話で登壇してきたので資料を公開する



結果、沖縄時間を読み間違えて開門2時間前に会場についたのが私です(´・ω・`)

ということで今回はJPUGの講師枠としてOSC沖縄に登壇してきました。
沖縄に来るのは中学校の修学旅行以来なので家族で一緒に行って来ました。
その時の登壇資料はこちらです。


伝えたかったこととしては

・クラウドが便利なのはわかる、けどオンプレミスと比べて実際どうなの?
・OSより上を抽象化するPaaSでDBってどうなの?
・でPaaSやってる会社何個かあるけどどうなの?

の辺りを僕なりの回答で掘り下げて話しました。
特にクラウド利用の説明ってメリットばかりが乗っててデメリットの話が表に出てないと思います。
実際にはメリットとデメリットの組み合わせでインフラの選択が変わるのでその話が一番のメインでした。
私の周りではAWSが一番主力ですがケースバイケースでAzureだったりさくらクラウドだったりニフティだったりがマッチすることも多々有ります。
そういったチョイスするときの一つの指標にしていただければ幸いです。



こういった意見もあったのでやはりメリットばかりじゃなくデメリットの比較も大切だなと思いました。
あと沖縄はエンジニアのみんなも良い人ばっかりだし海は綺麗だし最高でした。
幸いに台風の影響なくバッチシ観光も出来たしやっぱJPUGは最高だぜ!!

MyNA・JPUG合同DB勉強会 in 東京を開催してきた(FDWの話もしてきた)

MyNA・JPUG合同DB勉強会 in 東京を開催してきました。
遂に東京進出!!中国地方に収まらないスケールのデカさを魅せつけてきました。
ただ初の関東開催ということで関東の洗礼を受けましたw



それでも平日の日中に雨が降っていたにも関わらず40名以上の参加者がありました。
本当に皆様、ご参加して下さりありがとうございました。
この勉強会は会場を貸していただいたDMM.com ラボ様MyNAの梶山さんのお陰で開催することが出来ました。
本当に良い経験が出来ました、ありがとうございます。
また所属しているまほろば工房には協賛費を出してもらいました。
お陰でドタキャンに怯える事無く、上手く乗り切る事が出来ました。
関東でイベントを開くときは


  • ドタキャンがあること前提で対応できる仕組みをつくる
  • お金の事に怯えなくて住むような事前準備


が非常に大切だなと思いました。
普段の地方開催だと懇親会はほとんどドタキャン無いで本当にその優しさを身をもって感じましたね。

■twitterのまとめ
Twitterについては@eielhさんがまとめてくれています。

MyNA・JPUG合同DB勉強会 in 東京 #ChugokuDB


■登壇資料など
他の講師の方の登壇資料も中国地方DB勉強会のポータルサイトにまとめました。

MyNA・JPUG合同DB勉強会 in 東京


今回は配信を行っていないので動画はありません。
当日のスーパーエンジニア講師のお話とスーパーエンジニア参加者のマサカリは来た人だけが味わえた特権ですね。
当たり前のようにPostgreSQLのコミッターやFDWのコントリビュータがいたり、MySQLエースやinnoDB作ってた人が居て全体的なレベルの高さがカオスでした

それと今回は講師業もしたのでスライド載せときます。
PostgreSQLの外部データラッパー(FDW)はNOSQLや他DBとのインターフェイスの一つの答えだと思ってます。
MySQLのストレージエンジンに似ていてやはり得意な事は得意なソフトウェアに任せるのが良いと思ってます。
その上でFDWが橋渡しをする、そんな想いを伝えたかったです。
ですがデモが糞みたいなデモで参加者には申し訳なかったです...
次回、汚名を返上する機会があればリベンジしたいですね。
ということで当日の資料はこちらです。



なので全体的に参加者のレベルも高く、正規化やRDBの基本的な話は理解されてる前提で講師も話をしてました。
本来は初心者から中級者向けをターゲットだったのでそういった参加者の方には難しい話だったと思います。
そこは僕のバランス取りとマーケティングが失敗しました。
何度やってもこういうバランス取りの答えが見えないので本当に難しいですね。

逆に懇親会はすごい人ばかりでただただ僕は色んな人の知見を勉強させて貰えました。
と言いながら勉強するフリをしながらひたすら余りそうなビールを消費するという貴重な経験をしました。
(結局1ケースほどビールが余ったのですが)


ということで色々と手探りでしたが結果的に大変有意義なイベントだったのではないかと思います。
コミュニティ主体のイベントは単体のコミュニティでやるものが多く、合同のイベントはもっとあって良いと思います。
このようなイベントは多くの化学反応を産むと思いますし、なによりも楽しいです。
これをキッカケにもっとDBに限らず色んなコラボが生まれて欲しいなぁと願っています。
また中国地方DB勉強会はそういったコラボを産む場所になれるように今年は頑張っていこうと思っています。
一緒に共催したい!!というコミュニティがありましたら是非ご連絡をよろしくお願いします。


ということで、soudai1025とイベントを開催したい!!という方、お待ちしております。
ホントまたこのイベントやりたいなぁ(*´ω`*)

2015年6月8日月曜日

第九回 中国地方DB勉強会 in 米子を開いてきた

第九回 中国地方DB勉強会 in 米子を開催してきました。
今回は初の米子開催!!ということで色々と手探りでしたが結果的に30名近い参加がありました。
これは米子現地スタッフの上村さんを始め、鳥取の方の勢いをすごく感じました!!
今回を企業として「株式会社 リゾーム」のパトラッシュさんと「日本Oracle」の梶山さんに来ていただきました。
実務を通じた経験の話やMySQLの最先端の話は非常に面白かったと好評でした。
他県の方も多く参加しており、大成功の勉強会だったと思います。
そして毎度ながらご協力してくださった講師・スタッフの皆様、ありがとうございました。
そんな第9回の詳細は次のとおりです。

■登壇資料など
中国地方DB勉強会のポータルサイトにまとめました。

第九回 中国地方DB勉強会


各講師の資料、そして今回はUstream配信をYouTubeに保存しております。
上記のポータルサイトからご参照ください。

■メーリングリスト
次回の告知についてはMLやDoorKeeperを使います。
興味がある方はチェックしてみてください。

中国地方DB勉強会ML Google Group

DoorKeeper


■twitterのまとめ
Twitterについては@eielhさんがまとめてくれています。

第9回 中国地方DB勉強会 in 米子 #ChugokuDB


■動画まとめ

中国地方DB勉強会 YouTube


それと第10回はJAWS-UGとの共催で岡山で開催します。
すでに申し込みが10名以上おり、埋まってしまいそうな勢いです。
参加希望の方はお早めにお申込みをよろしくお願い致します。

■第10回 中国地方DB勉強会 in 岡山 ~日本AWSユーザ会・PostgreSQLユーザ会(JAWS-UG・JPUG) 合同勉強会~
■概要
日時:2015年7月18日 (土) 10:00 - 18:30
会場:岡山県岡山市津島中1-1-1 岡山大インキュベータ
http://www.smrj.go.jp/incubation/od-plus/

詳細はこちら
第10回 中国地方DB勉強会 in 岡山 ~日本AWSユーザ会・PostgreSQLユーザ会(JAWS-UG・JPUG) 合同勉強会~

※セッション対象予定
AmazonWebServices 講師3名
ドメイン駆動設計  講師1名
その他、全員参加のハンズオンを予定しております。

クラウドの主流と言っても過言ではないAWSの話を3セッション予定しております。
また問題に対して如何に開発に落としこむか、というテーマでDDD(ドメイン駆動設計/Domain-driven design)の講師を呼びします。
セッションとハンズオンがありますのでこの機会にDDDに是非触れていただけたらと思います。

なお、懇親会は18:00~20:00で考えています。
交流含めて是非参加をご検討していただけたらと思います。

と今回でついに中国地方統一(全県開催)を果たしました。
次の岡山でDB勉強会も3年目になります。
これからも中国地方で楽しい勉強会として頑張って行きたいと思います。
それでは皆様のご参加、お待ちしております!!

2015年5月25日月曜日

6月、7月のイベントを告知しつつそーだいの予定を晒して見るテスト

今週末は娘の運動会で応援する僕が高まってます。
そんな中、ちょっとグーグルカレンダー整理してたらイベントが続くので参加イベントを告知。
てはわけでいきなりドーン!!


・6月6日(土) 中国地方DB勉強会 in 米子(登壇)
中国地方DB勉強会がついに初の鳥取開催。
これによりJPUG中国支部はその名に恥じぬ、中国5県全県制覇達成です。
コンテンツも豪華でめっちゃ楽しみです(*´ω`*)
僕はWebアプリで便利なRDBの使い方の話します。

・6月10日(水)~6月12日(金) interop
会社が出展するので行きます(予定)
セミナー聞きたいけどそしたら長期滞在になっちゃうので難しいかなぁ。
そういうところが関東勢裏山。
てなわけでまほろば工房って会社がブース出してるので遊びに来てくれると僕が喜びますw

・6月26日(金) MyNA・JPUG合同DB勉強会 in 東京
僕が開催出来うる最高のコンテンツをまとめたイベントです。
中国支部ですけど東京でやりますw
平日のド昼間なので選ばれし戦士しか参加出来ない感じですがコンテツはそこら辺の有償コンテンツよりも豪華になると思います。
いやマジ楽しみすぎる。
僕自身が聞きたい話、聞きたい人をせっかく東京に行くんだからと集めたイベントなので完全に俺得イベントです!!

・6月27日(土) 日本PostgreSQLユーザ会の総会出席
まだ夏セミナーのページ出来てなかった(´・ω・`)
前日のイベントはコレで東京行くのでせっかくなので!とやる感じです。
総会はいつもどおりマッタリこなしますが夏セミナーはPGConとかPostgreSQL9.5の話になるらしいです。
9.5はMerge文やJSONBの強化など超楽しみな機能追加が予定されてるので楽しみです!!
9.5の機能追加予定については確定ではないですけど下記のWikiにまとまってます。

What's new in PostgreSQL 9.5(英語)

・7月4日(土) オープンソースカンファレンス沖縄(登壇)
中学生以来の沖縄です。
RDSとかHerokuとか今や当たり前になりつつあるクラウド上でのDB運用についてお話します。
インフラの抽象化で今メリットが大きいのはネットワーク(DNSやLB含む)とDBだと思ってます
そんな感じの話するので興味がある方はぜひぜひ(*´ω`*)
あとはLT用意したほうがいいのかな?かな?

・7月8日(水)~7月 10日 (金) オフィスEXPO
会社が出展するので参加。
うちのPBX出します。
クラウド版もあるしもちろんオンプレミス版もあるので興味がある方は是非。
価格でも内容でもベンダーに負けてないですよ!!

・7月11日(土) オープンセミナー香川(登壇)
RDSとかBigQueryとかクラウドデータベースの話します。
その中でPostgreSQLを選ぶメリットが伝えれたらなぁって思ってます。

・7月15日(水)~7月17日(金) JANOG36
会社がゴールドスポンサーなので参加します。
北九州!北九州!!
実はJANOGは初参加なので楽しみです(*´ω`*)

・7月18日(土)中国地方DB勉強会 岡山(運営)
ページ作ってないけどDDDのハンズオンします。
さらに!AWSと共催です(*´ω`*)
AWSのセッションとDDDからテーブル設計に落としこむ講師のセッションとハンズオンです。
僕が今、一番推してるレイヤー全部入りみたいな内容ですw
これは午前中から楽しみな内容になる予定なので調整中ですが早く告知したいですね!!


とりあえず今ここで告知出来る確定事項はここまですね。
毎週イベントでおじさんwkwkしてきたぞ!!!
東京行ったり九州行ったりうどん食ったり沖縄行ったりと縦横無尽です。
現地でお会い出来る方はよろしくお願いします。


ということで今から資料作りますノシ