MyNA(日本MySQLユーザ会)会 1月に行ってきたッ。

遅刻して参加!

yokuさんのLT芸を見に来ましたよっと。

MySQL即効クエリチューニング（Think IT Books）

｢MySQLerの7つ道具の話｣
(slideどこだ??
(これでいいのかな。

MySQLerの7つ道具 from yoku0825

www.slideshare.net

今日の驚き。
innotopが本にのった!!

innotopが本にのった!!

innotopが本にのった!!

innotopが本にのった!!

あたくし、innotopが好きなのです。

tmax & dstat
innotop仕事してる感ある。<<わかる。
メンテナさんが変わったりなんだりで開発が停滞していたけれどJST1/21で再スタートしていたのだそうだ。
よかったよかった。

(そういえばgh-ostってどうなんだろ。
(ぐぐってみたけれどあまり記事がないや｢gh-ost github｣

4年前のMySQL初心者な自分に贈りたい本とかなんとか。

Explain EXTENDED
optimizer後とか見れる
なんで重いのか見れたりする。

visual explain!!
optimizer_trace << 書き換えている途中が見れる。
20kくらいあるんだと。

performance_schema
autoresizeで、勝手にメモリ食いやがる。

show engine performance status

alter tableの進捗が見れるようになった!<<すげぇ。
(fast index creation = index張る時に全体いじってたのを一部だけいじって対応するやつ。

Use Our Brain!!

タイトル通りチューニングに特化な内容。
いろいろ調べることなく、コレ一冊で勘所が押さえられる感じでとてもよい本!!
今回ツールのお話でしたが本の中には、チューニングのやり方まで書かれているのでかなりよい。

つづいて梶山さん

やさしく学べるMySQL運用・管理入門【5.7対応】の紹介??
黒板本。
確しかに新卒向けに良さそう。

発表は、ボツネタ供養!!

MySQL版あの人は今。

プライバシーのために没!!

歴史に消えたストレージエンジン!!

Falcon
BDB
DB2
この辺くらいならわかる!

以上、遅刻していってしまたけれど、楽しかったぜい。

Regional SCRUM GATHERING Tokyo2017に行ってきた。

@fullvirtueさんが「講演内容を1枚に書く？描くことで、見てもらえやすいだろう。」とやっていた1枚まとめが大変素晴らしと思って
早速真似して自分でもやってみた。
あまり上手く出来ているわけじゃないけれど、描くことで今でも覚えている。

RSGT2017全部のまとめ

Scrum / DevOps の導入を加速するグローバルマインドセット　～８つの習慣 その１ ～

※8つの習慣について具体的に一枚まとめに書いてはいないので以下のスライドを参照するとよし。
講演者のブログ
http://simplearchitect.hatenablog.com/entry/2017/01/16/080245
スライド
https://docs.com/ushio-tsuyoshi/8469/scrum-devops
過去の同テーマのスライド？
https://docs.com/ushio-tsuyoshi/363c32c5-1277-48c0-a02d-1e750ef19a8c

缶詰屋さんの課題解決にスクラムを使ってみた

結果的にスクラムになってる！なのがいいと思う！

最短で成果を上げる！強いスクラムチームの作り方

シン・未来会議 - スクラムチームを支える組織づくり -

Pitfalls of Scrum -- My findings from coaching / スクラムの落とし穴 〜アジャイルコーチが遭遇するよくある問題とその解決方法

つらい問題に出会ったら

ゲーム開発を盛り上げる技術とチームを支え続ける原動力

エンジニアの技術力評価は難しい？ - 5年間運用してきた相互評価制度の改善の歴史 -

アジャイル・メトリクス実践ガイド

今回一番衝撃的だった気づきは、(この1枚まとめもかなり良い刺激だったけれど。)
「スプリントにはready状態になったものをいれること」
なんだかんだ横断的だったりして並行作業でスプリントを開始していたりして、
ちょくちょく完了しきらないっていう事象があったんだけれど、
よく考えたらそりゃそうよね、完了できないスプリント状態にしていたんだもの。
これなかなか気づかないポイントな気がする。

それから、8つの習慣。
agileって、スーパーマンなメンバーが揃わないとそうそうなしえないと思っていて。
(ウォーターフォールは逆にそうでもないという印象がある。)
しかし、そのスーパーマンっていうわけではなく、揃えなければ行けないのは西洋文化の価値観、習慣である。
という話にはとても合点がいった。
自分が出来るか出来ないかは問題じゃなく、大変そうな人がいれば声をかける、助ける。
っていう習慣があるとか、まさにagileじゃん。
日本だと、出来るできないみたいなのを考えたり、セクションに囚われたりしてそういうった習慣がないなと。
他にもこの習慣は、今まで思っていたスーパーマンに対する言語化であって、認識がとても進んだお話だった。

今回もとても気づきのあるRSGTでした！
運営の皆様に感謝！！

「TECH TALKS -ソウゾウ×グノシー×エウレカ 技術トップが語るこれからのエンジニア組織-」に行ってきた。

ちょっと日付が経っているのですが参加してきました。

久しぶりに組織のお話。
学びがあったので、ちょっとザクザク絞って箇条書きにしてみた。

組織、チームのフェーズに合わせてマネージャーを合わせていくのはよいなと。

それでいうとCTOはチームの立ち上げ時に基礎づくりってのは有る手。
その後は、チームを大きくしていくのが得意な人に託す。
0→1
1→10
10→100
みたいなフェーズ訳の話も思い出す。

インセプションデッキは、マネージャーを置かなくてもチームを動かすことができるとか。

最近インセプションでっきやってないなー。

基本少人数チーム。

関係ないけれど、LeSSを勉強してみたい。

PJを対ユーザーよくしようというのがPJの責任者。

システムを良くしようというのが横軸の責任者。
やっぱりPJまたぎつつチームにがっつり入るのは大変だよなー。

そもそもあんまりリファクタやらない。

ユーザーメリットがなければやらない。

これは面白いなって思ったこと。

抽象的なものを投げられる人をリーダーにする。
この表現はなるほどと思った。
そこからエンジニア観点でタスクを形成して進められる人は強いなーと。

また開催されたら参加したい。

第5回CodeIQ感謝祭「食欲とプログラミングの秋」に行ってきた。

ほんのちょっとずつ、時間取れ始めたかなぁと。
またブログを書き始めてみる。
振り返ってみると、4年くらい書いてなかったのね。

09月24日に開催された｢CodeIQ感謝祭｣について、参加した振り返りを以下の流れで。

• 感想まとめ
• キーワード
• 各々の振り返り << だらだら長いやつ。

感想まとめ

• 初参加!!
• 採用とエバンジェリスト話に興味をひかれていってきました。
• とても良かった!
• ずっとホールにいたので今度はブースとか懇親会とか参加しよう。

キーワード3つ

• スキルも大事だけれど、カルチャーはより大事

スキルは伸ばせる。
カルチャーはなかなか変えられない。

• 自分ごと化

当事者意識とも

• 探求力

質問力ではなく探求力という言葉がオススメ

残りは備忘録的にツラツラと書き残しておく。
※あ、ちなみに自分の勝手な解釈が交じるので、講演内容とは違う所がままあると思います。

エンジニアはプロジェクトマネジメントを知るべきか知らざるべきか。

ボクの答え

「知るべき。」という自分の答えは先に言っておく。

知って、正しく進むプロジェクトなのか否かを判断するべき。
可能であれば、自分でプロジェクトマネジメントをすべき。
もっと可能であればプロジェクトマネジメントしながらエンジニアリングもすべき。
※自分のエンジニア欲求とプロジェクトの成功の為に。

エンジニアリングのスペシャリストという目指すのもあるが、
どんなスペシャリストでも解決できない物もあると思う、
それは時間とお金と人。よくいう有限なリソースですね。

どんなスペシャルであったとしても、
適切に調整されたプロジェクトでなければ、
こなしきれない問題もあると思うのですよ。
一般的にはね。

※いや、もしかしてそれをも凌駕するスペシャリストなのかもしれない。
「どんな無理難題でもそれを超越し周りに成果を及ぼす人」だ。そんな人がいれば、
その人に合わせたマネジメントを行うだけだ。

エンジニアがいくら頑張ってもプロジェクトという観点では越えられない壁があるのではないか？
※逆にプロジェクトマネジメントがいくら頑張っても越えられない壁もあると思うけどね。
青い銀行とかね。
と思うわけです。

つか、エンジニアリングに降りてくる前に、その前で訂正するほうが費用対効果が大きいわけですよ。(不確実性コーン！！

とはいっても、プロジェクトマネジメントをしたからといって成功するわけでもないのですけれどね。

偶然成功することもある、が成功するセオリーというものもある。

じゃあプロジェクトマネジメントができれば幸せか？
というわけではない。
プロジェクトマネジメントもやはり専門領域で、
エンジニアリングと並行するのはとても大変である。
そうなってしまうと、自分の好きなエンジニアリングを諦めなくてはならなくなってしまう？そういったこともあるだろう。
(実際、今の自分はそんな感じ。

だがしかし、自分の成功よりもチームの成功。という観点もある。
だよね、そこは自分が納得するものを選ばなければいけないわけだ。

そんな「決め」の問題のなかで、どうすべきか？？

自分の定義する成功に対して、論理建てて行動すべきかと思う。

自分勝手に考える。
やたら頑張る。

ではなく、今までのでの人類の知見があるのだがからそれを知り、
利用するでもよいし、捨てるでもいい。
しかし、それを利用しない手はないんじゃないかと。

結局何をすべきか。

「世の中に不満があるなら自分を変えろ、それが嫌なら耳と目を閉じ口を塞いで孤独に暮らせ。 」

攻殻機動隊の言葉は有名よね。

※自分を変えろというよりも、周りを変えろ。
とか思ったりもするんですけれども

自分の欲求があるなら、それに従うべき。と思う。
「楽に働きたい」でもいいし。
「多くの人に楽しんでもらいたい。」でもいいし。
などなど、なんでもいい。

ただ、それを実現する手段として、適したものは何なのか。

今一度考えて欲しい。

それは、エンジニアなのですか？
それともまた別の手法ですか？？

自分の欲求がたとえ「技術一本勝負！！」などであっても、それを実現するためには、
マネジメントが必要だったりしませんか？(自由を勝ち取る為の、周りへの情報共有、マネジメント。)

まとめ

考えだしたらきりがないし、ボクはPMは知っているべき。
という偏見から書きなぐっている所があるので、なんとも申し訳ないのだが。

結果を実現するための手段、スキルは多く深く持つべき。

と思うのです。
それだけ実現の可能性がますと思うから。

ルール以外はノールール。

「AはBだから…Cだよね。って勝手に思っていませんか？」

shibuya.pm行ってまいりました。

http://shibuya.pm.org/blosxom/techtalks/201506.html

※以下、talkとは別に項目が立っております。

■nginxの奥深さをいまさら感じた
トラフィック抑えて高速化
gzip_static　gzipしたり展開してくれる

その他楽しいオプションいぱーい。
https://speakerdeck.com/cubicdaiya/nginxfalsepahuomansutiyuningu

■Perlingual がすごい
perl のソースを なでしこに!!（phpやjsにも置換できるよ。）
http://e8y.net/post/120535406440/shibuya-pm-17-acme-perlingual（勉強会のブログ）
http://perlingual.koneta.org/（デモページ）

デモおもしろいよ!

■GazelleはISUCON用
前回優勝のkazeburoさん作

2014優勝してきたよ
http://blog.nomadscafe.jp/2014/11/isucon4-isucon.html

ベンチとか紹介とかgitとか
http://blog.nomadscafe.jp/2014/11/gazelle-new-simple-and-fast-plack-handler-for-performance-freaks.html
https://github.com/kazeburo/Gazelle/wiki/Benchmark

■h2o @kazuho
ちょっぱやhttpサーバー
http://blog.kazuhooku.com/

■one source code で「複数のサービスに対応するが schema 構成は微妙にに違います」という要件に直面したら開発はどうすればいいのか、僕なりに何日か考えた上でのややベターな結論のようなもの - @Yappo

これ、資料ないんですけれど、自分にはとてもよいきっかけになるお話だった。

想像するに、スキン替え的なことが必要なときにどうするかとか、
自作のモジュールの仕様変更をどうしようかと考えているのでよかった。

･環境変数とかグローバルで処理分岐させるのよくない。
･メソッドもあまり。
･クラス、名前空間をわけて管理ぐらいがちょうど良い。
だそう。

その方のISUCON2014の体験談
http://blog.yappo.jp/yappo/archives/000846.html

■その他
技術スライド英語で書こうぜ。
http://tagomoris.hatenablog.com/entry/2015/06/01/210425

Test::Prettyを早速使ってみた。

cpanm Test::Pretty
perl -MTest::Pretty foo.t
    ✓  foo_test1
    ✓  foo_test2
    ✓  foo_test3
    ✓  foo_test4
    ✓  foo_test5

Test::Moreのテストそのまま使えて見た目キレイ!!