2015-10-14（水） 「【東京】JJUGナイトセミナー Javaアプリケーション開発の基本のキ（ログ出力、テスト篇）」に参加してきました。
DoorKeeper
https://jjug.doorkeeper.jp/events/32477Togetter
http://togetter.com/li/886876場所は日本オラクルです。
参加者は100人以上だったようです。私が定刻に会場に着いた時、既にほぼ満席で、最前列に座る羽目に・・・
前半のテーマは「ログ」。エンジニアなら、
- なんでこんなに似たようなライブラリがあるん？
- どこがどう違うん？
- どれ使ったらええのん？
と、一度は思ったことあるんじゃないでしょか。私もその1人です。
で、ずっとモヤモヤしてたんですが、この勉強会の告知を見てピキーンとなり、速攻申し込んだのでした。
あと、後半のせとさんはあちこちの勉強会でよくご一緒させてもらってます。
先日の
@t-wadaさんの横浜道場TDDの講演、せとさんも私もちょうど聴講してたんですが、これを受けてせとさんがどういうセッション構成にしてくるのか楽しみでした。
以下、個人メモ。
■ Javaのログ出力: 道具と考え方 ■ ログの語源- log = 丸太
- 帆船の時代、丸太（log)は船の速度標として使われていた。
■ ログ vs デバッガ- マルチスレッド環境とかだと、再現するのが難しい故障とか発生する。
- その場合はデバッグが難しいので、ログで発生状況を分析する。
■ ログの道具- Javaのログライブラリはたくさんあって、列挙されたライブラリのうち、Log4j2以外はどれもそこそこ使われている。
■ 役割が異なるライブラリ- (A)～(D)のうち、SLF4Jだけが「ログファサードライブラリ」で、残りの３つは「ログ出力ライブラリ」。
- 「ログファサードライブラリ」は、「ログ出力ライブラリ」の前にいる。
- (B),(C),(D)は同じ人が作った。(A)だけグラハムさんが作った。
■ ログ出力の階層- アプリがログを書くときに、直接ログライブラリを叩かない場合があって、間にログファサードライブラリをかます。
- ログファサードライブラリはログ出力ライブラリに処理を委譲する。
■ Javaログライブラリの歴史- 1999年までは、これといったログライブラリがなかった。
- Apache Tomcat 3.0では、ログ出力にSystem.err.printlnを使っていた。
- ソースのコメントに、「これはやっつけの実装だから修正しなければならない」と書いてあったらしい。
- Tomcatは、後にログライブラリを中に持つことになった。
- 1999年にLog4jが登場した。今に至るまで、一番よく使われているログ出力ライブラリ。
■ 階層化されたロガー- ロガーは、プログラムからログを出力するのを受け持つ。
- アペンダは、プログラムから渡されたログのテキストを外部リソースに書き込む。
- ロガーとアペンダは、くっつけたり外したりできる。
- Log4jも、ドット区切りのロガー名で階層化されている。
- ログ書き出し元をログ名にする。
- ロガーは親の設定を継承するのが基本。子は親の機能を継承する。子で親の設定を上書きできる。
■ MDC- 実行時文脈の値をいれておくスレッドローカルなHashMap。
- MDCは便利なので覚えてください。
- MDCは、文脈情報を覚える。MDCを使えば実行時文脈をログに出せる。
■ java.util.logging- 2000年に規格化を開始。
- ソースコードも、Log4jと比べ2箇所しか変わらず、だいたいおなじ。
- java.util.loggingよりもLog4jのほうが、ずっと長く使われた。
- java.util.loggingのログレベルには、CONFIGという謎のレベルがある。
- CONFIGとINFO、どっちがシビアやねん！あと、FINE, FINER, FINESTもよくわからん。
- 日本語のログが面白いので、試すのおすすめ。
- １つのログが2行で出力されるので、使いにくい。
- JVM全体で１つの設定しか持てない。Log4jなら、アプリ毎にLog4jのjarを突っ込めばいけた。
■ Commons Logging- 2001年に登場した便利ライブラリ。
- 特定のログ実装に依存するのはちょっと嫌だから、間に1個かまそう、という理由で始まったログファサードライブラリ。
- でも、Log4jやjava.util.loggingの切り替えには上手く使われなかった。
- SpringもCommons Loggingも採用しているが、正直イケてない。
- ログ実装の選択方法がぶっこわれてる。
■ Commons Logging 実現したかったこと- アプリごとに設定を変えてログを出力したい。
- どういうアプローチを取ったかというと、Context ClassloaderというJavaの仕組みを使った。
- Classloaderと戯れたことがある人なら分かるが、辛い・・・。大失敗した。
- Java EEコンテナでは、クラスローダ不一致によりNoClassDefFoundErrorが頻発した。
- Eclipseとかが使ってるOSGiコンテナは、Context Classloaderを使ってないので、そもそも動かない。
- 以上より、Commons Loggingは"失敗"といえる状況。
■ SLF4J- Simple Log Facase for Java
- Logbackはログ出力ライブラリだが、自前のログインタフェースを持たない。SLF4Jと組み合わせて使う前提。
- Log4jとだいたい同じだが、ログメッセージの引数にプレースホルダーが使えるようになっている。
- プレースホルダーで文字列連結がいらなくなるので、若干計算量が減る。
- クラスを動的に探索するのではなく、差し替えで静的バインディングする。
- ログの横取りをする仕組み。
- 2種類のjarが必要。他のログ実装へのバインディングのjarを、API(必須)のjarと組み合わせて使う。
- SLF4Jの静的バインディングの中身で、StaticLoggerBinderは５つか６つの実装がある。
- ハードコーディングで静的にバインディングする。
- ログを横取りするためのjarが個別に用意されている。
- Log4jのクラスを呼んでいるようで、SLF4Jのクラスを呼ぶ。
■ Logback- 独自のロガーインタフェースを持たず、SLF4J経由で呼び出す。
- 提供する機能に、「マーカー」がある。
■ Log4j2■ 使うべきログ関連ライブラリ- 共有ライブラリを作る場合は、SLF4Jにログを出すのが一番賢いやり方。
- MavenとかGradleとか使うとき、コンパイルスコープではログ実装ライブラリに依存しないようにすべき。
- testCompileの方にLogbackのjarを依存性として書く。
- アプリケーションを使う場合は、制約がなければ SLF4J+Logback が無難。
■ まとめ
テスト駆動開発ここが聞きたい TDDでお馴染み、せとさんのお話。せとさんの講演は何度か聞いたことありますし、せとさん主催のGOOS読書会にも出てました。
この日はTDDについて、テクニカルなネタよりもエモい要素を多めに、いろんな観点から説明されています。
ログの講演は個人的に初物だったので勉強も兼ねてメモ取りながら聞いてましたが、そんなわけで、せとさんの講演の方はゆったり聴講させていただきました。
個人的には、「組織パターン」の最初に出てくる「信頼で結ばれた共同体」という話が興味深かった。
せとさん曰く、これ読むだけでも価値があるとのこと。
あと、ハッとさせられたのが
「その場に居続けるには全力で走り続けなければならない」
というフレーズですね。鏡の国のアリスからの一節らしいですが、エンジニアの世界にもそのまんま当てはまる言葉です。
★感想：これまでログライブラリは、いろいろあるなぁと思いつつなんとなく使ってたんですが、この日の講演を聞いてすごく整理された。
複数のログライブラリを時系列で追っていくのは、ライブラリの背景とか互いの関係性がよくわかりますね。
あとTDDですが、先日の@t-wadaさんの講演の聞いた後にすぐ今回のせとさんということで、講演内容と主張を比較しながら考える良い機会になりました。
これだけ勉強会三昧な１日は初めてかもしれない。
登壇者さん、JJUG関係者のみなさま、ありがとーございました。
2015/10/6(火) アジャイルサムライ横浜道場 特別編「TDD (再)入門 - 初めての人と挫折した人へ」に参加してきました。
DoorKeeper
https://yokohama-dojo.doorkeeper.jp/events/31147以下の書籍をターゲットとした勉強会なのです。
Jonathan Rasmusson
オーム社
売り上げランキング: 10,743
場所はいつもの横浜市西公会堂です。
参加者は30人くらいでしょうか。特別会＆@t_wadaさんということもあって大入りです。いつもより会議室も大きかった。
この日の講演資料は横浜道場のFacebookに公開されていますが、グループに入っている人しか見れないようです。
https://www.facebook.com/groups/yokohamadojo/802470883203394/ちなみに表紙はこんなカンジ。
これまでのTDDのスライドをベースに、きっちりアジャイルサムライの要素をまぶしてくるところがまた素敵。
あと、和田さんのTDDの講演は何回か聞いたことがありますが、これだけじっくりTDDのデモを見たのは初めてでした。
とても勉強になったので、復習を兼ねて今さらながら当日取ったメモを起こしてみる。
注：
下記メモで和田さんの過去の発表スライド(slideshare)をところどころ挿入してますが、この日のスライドとは別物です。
あしからず。
---
■アジャイルサムライ 第5部の章構成
アジャイルサムライ14章のテーマはTDD。第5部は実践の章。
「アジャイルなプログラミングは重複を排除する」と言われるが、12章と14章で両方テストを扱っており重複してるように見える。
でも、著者のジョナサンはきちんと説明するために、意図的に練られた章構成となっている。
14章のTDDは、12章の「ユニットテスト」と13章「リファクタリング」の合わせ技の章となっている。
13章のリファクタリングでは、「既存の振る舞いを変えない」＝「テストが動くままにする」。
テスト自動化して、その中で構造を綺麗にするというプラクティスは強力。
これを日々のプログラミングにまぶすことが重要。日々の作業にリファクタリングをビルトインすること。
なのでアジャイルサムライはこの章構成になってる。ジョナサンはよく考えている。
■書籍「テスト駆動開発入門」
ケント ベック
ピアソンエデュケーション
売り上げランキング: 337,268
持ってる人？と和田さんが参加者に質問したら、4割くらいの人が「テスト駆動開発入門」の本を持っていた。
絶版で、復刊に向けて頑張っている。
この本がTDDの原典。著者はケント・ベックで、XPという本の著者でもあり、JUnitの開発者でもある。
■ 動作する綺麗なコード
偉大な本は偉大な書き出しから始まる。「動作するきれいなコードは、あらゆる理由で価値がある」
テスト駆動開発＝動作する綺麗なコードでありたい。
「動作する綺麗なコード」という言葉を分割すると、「動作する」と「綺麗な」に分けられる。
それぞれの反対も考えると４象限に分けられる。
ゴールは右上の「動作する綺麗なコード」。
何もないところを仮に左下の「汚い、（すぐには）動作しないコード」とする。
天才は一直線に左下から右上に行けるけど、僕らはそうではない。２つの道のどちらかを通る。
教科書的な答えは、オレンジの線を通るのが良いと言われる。良い設計を得て、そこからコードに落とす。
最近、オブジェクト指向では設計の復権が起きてるので、この道が増えてきている実感がある。
@t-wadaさんも大学でソフトウェア工学を学んでいたので、オレンジの道だった。キャリアの最初はオレンジの道だった。
でも、オレンジの道には罠がある。
「綺麗なモデル」って何か、分かる人は少ない。
"完璧な設計ができたら、コードを書いていい。完璧な設計ができないなら、手戻りの原因になるからコードは書くな。"
じゃあ、完璧な設計とは何か？と考え始めると、そこから進めなくなる・・・。沼地。完璧主義、羞恥心・・・。
現実世界は無限なリソースとスケジュールがあるわけではないので、コードを書き始めないと間に合わない、という焦げ臭い感じになってくる。
なのでコードを書き始める。すると真ん中の縦線を超えるところでいろんなことがわかる。
考え抜いてきた設計が、コード書いてみると、考えきれてないところがあったり。
最初に設計をきっちりやったけど、ここまで考える必要はなかったな・・・、と逆に気づいたり。
そうやって、手を動かすと気づくことがある。
実際に頭で動くと思ったものも、真ん中の縦線を超えることでいろいろわかってくる。フィードバックがやってくる。
残念ながらソフトウェア開発は「工学」になりきっていない。再現性をきちんと保てる状態ではない。
それは、周りの諸条件がガンガン変化するので、再現性は低くなるから。
最大のフィードバックを得られるのは、コードを書き始める時。現代のソフトウェア開発において、未だに真ん中の縦線のポイントは大事。
真ん中の縦線が大事なら、さっさとそこを越えよう、という青い線の道がでてくる。
こっちも沼地がある。１つは堕落。動いているからいいや、というのが出てくる。もう１つは、恐怖。堕落より重い。
汚いけど動くところまできた。でも、綺麗にする過程で動かなくなっちゃったらどうしよう・・・と考えることがある。
「動くコードには触れるな」という言葉は、いろんな現場で掟として言われてきた。
でも、現代の開発において、プログラミングはある時点で終わり、となることはない。ずっと手を入れないといけない。
コードに手を入れなくても周りの世界はどんどん先にいく。手を入れないと、セキュリティが野放しになっていく。
なので、現代においては、コードの凍結はありえない。手を入れるときに、恐怖と戦わないといけない。
現代の開発のフィードバック量を考えると、早めに左の「動かない」から右の「動作する」に行ったほうがいい。
右下（動作するけど汚いコード）から右上（動作する綺麗なコード）に持ち上げる力、道具があれば、青ルートのほうがいい。
その道具がリファクタリング。
既存のコードを、振る舞いを変えないまま、右下から右上へ。
■ TDDのサイクル
TDDはレッド、グリーン、リファクタリングのサイクル。
一番最初に最小限の設計を行う。最初に、プログラミングに着手できるくらいの設計をする。
紙に書くとか、やることリストを作るとか。
そこから、一番最初にやろうと思うものをピックアップする。それは一番価値あるものだったり、一番簡単なものだったり。
１個だけピックアップする。そのテストコードを書いて実行する。実装がまだないから、テストは失敗する。
実装が無い時にテストをして、コケるところから始める。そこでテストが通ってしまったら、そもそも何かがおかしい。
テストが失敗するの見届けたら、テストが通る最低限のコード書く。テストが通ると緑になる。
動作しているままで、テストが通り続けるまま、中を綺麗にするのがリファクタリング。
この1枚をいろんなスケールで繰り返すのがTDD。
■ アジャイルサムライとTDDアジャイルサムライでは、「レッドは設計についてしっかり考える出発点だ」と書かれている。
つまり、失敗するテストを書くことは詳細設計に近い。
リファクタリングで、コピペコードとか強引なコードを省いて、綺麗にする。
■ TDDと黄金の回転 これを「黄金の回転モデル」と名前を付けた。この言葉は「ジョジョの奇妙な冒険」に出てくる。名付け親は、今は亡き山城さん？
軌跡が大事。レッド、グリーン、リファクタリングの軌跡。
回転の軌跡が綺麗で、サイクルがうまく回っているほど、効果が出る。
回転が綺麗にならない、というのは、３本の矢印のどれかが短くなる。短くなるのはいつも決まって「リファクタリング」。
「リファクタリングは次のイテレーションでやろう」みたいな後回しが増えると、「きれい」な象限にいられる時間が短くなる。
リファクタリングが短くなる原因は、「リファクタリングはプレッシャーに弱い」という点。
リファクタリングは、機能を追加しないまま綺麗にする。「機能を追加しない」という点をお客さんに説明するのが難しい。
機能が追加されてないのに工数ばかりかかると、「なにやってんの？」となる。
「リファクタリング」というタスクが個別に出た時点でダメ。達成されなくなる。
「リファクタリング」を、他の人に説明するくらいの大きさのタスクになってしまったら負けムード。繊細。
でも、リファクタリングは大事。なので、日々のプログラミングの中にまぶしてやらないとうまく行かない。
「後でやる」はダメ。日々のプログラミングの中にまぶす。
これは部屋の掃除と一緒。出したものを戻す、というのは日々の作業。
それをやらないと後で「大掃除」になって、何も価値を生まないものが出てくる。
汚いコードは、単位時間あたりの機能追加が遅くなる。なので綺麗にすることは大事。
でも説明が大変なので、日々の作業にまぶしてビルトインする。
■ リファクタリングに関する書籍リファクタリングを独立テーマにした本がある。以下の２冊がおすすめ。
■ TDDのサイクル
TDDはサイクルである。さまざまなスケールでサイクルを繰り返す。
ユニットテストの外にも、受け入れテストのサイクルがある。
受け入れテストは、ストーリーをDoneにするために通らないといけないテスト。
受け入れテストの分野は、CucumberとかSeleniumなどのツールが最近は普及してきた。
■ TDDのサイクル その2
更に、受け入れテストの外にも「頻繁なリリースとデモ」というサイクルがある。
サイクルが多重になっている。アジャイルは自己相似形を好む。
■ テスト駆動開発のホットスポット最近、ケントベックはFacebookの技術顧問をやっているが、Facebookにテストの記事を書いている。
↑は、テスト駆動開発のホットスポットの図。TDDはどのようなもので、どこを住処にしているかを表している。
３つの軸がある。
(1) SCOPE
やろうとしていることの大きさ、影響の大きさを示している。
文法エラーが無い、というレベルから、社会にインパクト与える、というレベルまでの目盛りがある。
(2) CLARITY
明快さの軸。知らん→定量化→しきい値→バイナリ（２値）
(3) FREQUENCY
頻度の軸。
---
テスト駆動開発は、どこが住処かというと、
・影響範囲(SCOPE)はデプロイできるし、動くソフトウェア、くらい。金を生むかどうか、までは行っていない。
・頻度(FREQUENCY)は、TDDは数秒に１回くらいの頻度でテストを動かすので、頻度は最高レベル。
・明快さ(CLARITY)も、一番向こうまで振り切れている。動くか動かないか、の２値レベル。
これがTDDの居るところ。
■
デモ使っているプログラミング言語に挙手してもらったところ、どれも微妙だったので、Javascriptでやることに。
お題はFizzBuzz。海外では入社試験でよく使われる。
極度に緊張する場合だと、５％くらいの正答率だそうで、それに関する有名なブログがある。
宗教上の理由で、エディタはEmacsを使う（笑
■ストーリーの分割まず、お題のストーリーを分割する。分割、整理、並び替え。まず文で分割してみる。
1から100までの数をプリントするプログラムを書け。
ただし3の倍数のときは数の代わりに｢Fizz｣と、
5の倍数のときは｢Buzz｣とプリントし、
3と5両方の倍数の場合には｢FizzBuzz｣とプリントすること。
「１から１００までの数」と「「プリントする」という文は複雑なので、後回しにする。
お題に無いが、「その他の数のときはその数を返す」というのを文書化して、先頭に持ってくる。
「プリントする」は後回しにしたので、「返す」にする。そうするとテストできる感じがしてくる。
■ テストコードテストファイル名を考えるところから設計は始まっている。今日はFizzBuzzTestにしよう。
「その他の数の時はその数を返す」
それってなんだ？となる。頭でわかってても、文にしてみると、そういうのがわかってくる。
「その他」を、まず「１」にしてみよう。
テストコードは、まずゴールから書く。そのゴールのコードの上に、コードを付け足していく。
IDEを使うと、最初にゴールを書くと、足りない要素をガンガン指摘してくれる。
「１の時は1を返す」と「３の倍数の時はFizzを返す」で、型が合わない、と気づく。
なので、「文字列として返す、という仕様なんだな」ということに、テストコードを書き始めると早い段階で気づくことができる。
疑心暗鬼になったら、慎重な道を取る。
■ 仮実装による、テストのためのテストテストが疑わしいので、テストがちゃんと動くかな、というのも含めて、テストを通すための最低限の実装をする。
「１の時は1を返す」をreturn 1;と実装してみる。１が返るテストなのだから、実装で１を返す。
この、直値を返す実装を、「仮実装」と言う。疑心暗鬼な状態を解決するための実装。
プロダクトコードが１を返すだけのコードなんだから、もしテストが通らなかったら、テストコード側、つまりテストフレームワーク側がおかしいということになる。
「テストコードに間違いがあったらどうしよう」という疑心暗鬼に対し、テストコードのテストコードは、実装コードにさせる。
実装コードに誤りを意図的にいれて、テストが落ちることを確認する。
実装コードがおかしいのにテストが落ちない、というなら、テストコード側がおかしいはず。
■ ミューテーションテスティングと三角測量「ミューテーションテスティング」というのは、テストスイートの十分さを測定するための手法。
テストコードを先に書いて、次にプロダクトコードを return 1 と書いたのは、テストコードをテストするためだった。
これでテストのためのテストが終わったので、次は1以外の数値でもいけるようプロダクトコードを修正する。
これを「三角測量」という。１だけのテストだと安易過ぎるので、２という別のデータを使ったテストを足す。
別のデータを使ったテストを足すには、２パターンの足し方がある。
縦にAssertを増やすか、メソッドを増やすか。
■ Assertion Roulette アンチパターン縦にAssertを増やすと、テストが途中で失敗したら、残りのテストは実行されない。
どのAssertionでテストが落ちたのかわからなくなる。
なので、迷ったらテストメソッドを増やすこと。
テストごとにアサーションを１個に絞ることを目指してください。１：１対応にすると、どこで落ちたか探す必要がなくなる。
■ アジャイルサムライにおけるTDD三角測量はテスト駆動開発のローギアのチェンジ。なんらかの自信がないときに慎重にやる場合に使う。
アジャイルサムライにも、テストをグリーンにする話として
とにかくテストに成功するコードを書く。実装の最終形を思い描けるなら、一気に仕上げてしまえばいい。
そこまでの自信がなければ、まずはテストに成功する程度の実装だけで構わない。
とある。
よって、３の倍数のテストを１，２，３，６の順で試したのは、「テストに成功する仮実装＋三角測量」という手法で進めたためである。
それを経験したので、５の倍数のテストは、上の文章にあるように"一気に仕上げる"方法を取った。
テストを使って不安を明確に落とし込んでいくのがTDDだが、個人差が出る。
スキルのある人はガンガンいけるし、自信ない人は歩幅を小さくして前進すればよい。
自信が過剰なら、テストはちゃんと赤くなってくれる。
自信と歩幅とレッド／グリーンが揃っているのが、一番バランスが取れている時である。
赤くなるとおもったのに赤くならない、とか、フィードバックが自分の思ってる姿が一致してない、だと、バランスが取れてない。
それは個々人の状況によって変わる。
■ リファクタリング途中段階のテストコードは、個別の値に対してテストしてるだけ。不安を解消していっただけで、リファクタリングされていない。
なのでリファクタリングをする。
プロダクトコードだけでなく、テストコードもリファクタリングしないといけない。
Assetを羅列したテストコードを後で見ても、「あぁ、あの時は追い詰められてたんだな・・・」くらいしか読み取れない。
なので、覚えているうちにリファクタリングをする。
■ 仕様とテストコードの構造を合わせるテストコードに入れ子の階層構造を取り入れて、仕様とテストコードの構造を合わせる。
仕様と具体例との階層構造。
3の倍数のときはfizzを返す ３のときfizz
６のときfizz
５の倍数のときはbuzzを返す
５のときbuzz |
と、段階的構造化をする。でも、上記の構造化は対称性の破れがある。
３の倍数のテストは２件やったのに、５の倍数のテストは１件しない。
なので、せめて対称性をもたせよう。「１０の場合はbuzz」というのを追加する。
最低２件はテストしよう。
階層構造が無いような平らなテストで終わっては、チーム開発ではダメ。
自分の不安を解決する最初としては正しいが、チームや半年後の自分にとってはいいものではないので、階層化して整理すること。
■ おわりに
TDDのデモがすんごく参考になった。
さすがワイルドサバンナと言わざるをえない。尊敬するエンジニアの１人です。
あと、和田さんが影響を受けたというケント・ベックのTDD本、復刊されたらぜひ読んでみたいと思うのです。
和田さん、企画してくださったたくぼんさん、ありがとーございました。
2015/10/22(木) 「JS Board Shibuya #4 Raspberry Pi入門」に参加してきました。
connpass
http://jsbshibuya.connpass.com/event/20841/Togetter
http://togetter.com/li/890326場所は渋谷クロスタワーのビズリーチさんです。ちなみに先週の情報処理試験、この隣が試験会場でした。
参加人数は30人くらいでしょうか。
この日は脅威の出席率で、会場が満タン。急遽、別室が用意されたのでした。
ビズリーチさんは以前もデザインパターンの勉強会でお邪魔したことがあったんですが、勉強会を活発に開催されてますね。
この日も凄いなぁ、と思ったのは、私が会場に着いた時、既に別の勉強会がビズリーチさんの大広間で開催されていたことです。
大勢の聴講者がいて、大盛況だったようで。
つまり、この日はビズリーチさんで少なくとも２つの勉強会が並行されていたわけですね。しかも両方共、満席。
ちなみに私、ラズパイを触るのは1年ぶりくらい。
去年、知り合いが主催したラズパイの勉強会以来かなぁ↓。あの勉強会も楽しかった。
2014/5/31(土) 「[初心者向け]第一回ラズベリーパイ一緒に動かしてみようじぇ～」に参加しましたイベント前日に、ラズパイに固定IPアドレスを割り振る設定をしてから当日参加しました。
これで、ラズパイ用のディスプレイが不要になり、PCからVNCでリモートアクセスできるようになりました。
基本はもくもく会なので、さっそくラズパイを起動し、いじり始めます。
この日はラズパイ本体や各種ケーブル、工作キットなどの販売も会場で行われました。
↓で主催者さんが紹介している「FTDI変換アダプター」なるものが興味深かった。
私は買わなかったんですが、買っとけばよかったなぁ・・・
実際、隣席の方がこの日コレ買って、すぐにラズパイをPCから操作できるようになってたし。
ハンズオンではまず、前述した去年の勉強会でやった、PythonでのLチカを復習してみました。
ブレッドボードに抵抗と発光ダイオードを刺して、ケーブルでラズパイと接続して・・・
ちゃんと動きました！嬉しいですね～
次は下記のサイトで紹介されている、node.jsを使ったLチカに取り組みました。
ラズベリーパイのGPIOを、Node.jsで操作してLED光らせてみた！ラズパイにnode.jsをインストールするのに意外と手間取った・・・
スタッフさんに質問したりして、echoによるLチカまでできたところで時間切れとなりました。
★感想：やっぱ機械工作って楽しいですね～。工学部だった学生時代を思い出します。
会社ではソフトウェアばっかなんですが、久々にハードウェアを弄るのは新鮮です。
こーゆうイベント、ずっと継続して欲しいと思います。
あと、主催者さんとスタッフさん達に感謝ですね。
この日は物販を行ったり、参加者のために充電ケーブルを買いに100円ショップに走ったり、参加者のヘルプに入ったりと、至れり尽くせりの体制でした。
自分が楽しむ時間を犠牲にしてまでサポートに奔走する姿は、ちょっとこちらが申し訳なく思うくらいでした。感謝！
私もオス-メスのジャンパーケーブルを持ってくるの忘れたので、スタッフさんに無料で2本頂きました。
ありがとうございました。
次回イベントも既に発表されていますね。
私はこの日、多摩川のハーフマラソンに出走するので参加できず。
次々回以降に期待です。
主催者さん、スタッフさん、会場提供のビズリーチさん、ありがとうございました。
2015/10/8(木) 「理論から学ぶデータベース実践入門Night」に参加してきました。
connpass
http://connpass.com/event/20066/場所は渋谷の株式会社VOYAGE GROUPさんです。
参加者は９０人くらいでしょうか。
以下の書籍をターゲットとしたイベントなのです。
奥野 幹也
技術評論社
売り上げランキング: 56,530
ちなみに私、この書籍の読書会にも参加してます。
http://riron-db.connpass.com/この日のイベントにも、読書会の主催者さんはじめ４～５名参加してました。
@nippondanjiさん講演 以下、スライドに無い口頭補足部分を中心に、個人メモ。
---
■ 自己紹介 （P.3）- MySQLサポートエンジニア。パフォーマンスチューニングもサポートでやってる点が珍しい。
- 酷いクエリをたくさん見ることができた。「これはなんかおかしいぞ」というのが、この本を書く動機だった。
- 世の中、クソクエリが溢れすぎじゃないか。
- オープンソースではなく「自由なソフトウェア」の普及をライフワークにしている。これを語り出すと時間なくなるので次回。
- 健康第一で、有酸素運動をやってる。趣味はリカンベント。
■ リレーショナルモデルは枯れた理論なのに何で今さら？ （P.5）- データベースは関係理論など小難しい退屈な話が多い。
- エキサイティングな要素があんまりなくて、置き去り感があるんじゃないか、と感じていた。
■ 巷にあふれるあやふやな情報 （P.6）- RDBを本気で語ってる技術解説がない。しかも、無いだけじゃなくて、あやふやな情報が多いことに気づいた。
- バックグラウンドの理論がさっぱり抜けてる解説があまりにも多くて、それってどうなの？
- 正規化は第３正規形まででいい、という主張があるが、それはなんの根拠があって言っているのか？
- こういうの見てると、感情が高まってくる。
■ 皆さんに本書で伝えたいこと （P.10）- リレーショナルモデルがなんなのか、ちゃんと説明している本がない。
- C.J.Date先生の本が一番いいんじゃないかと思ってる。
- リレーショナルモデルの使い方がわかれば限界も見えてくる。
- 「理論から学ぶデータベース実践入門]」は入門書。さらなる勉強の取っ掛かりにしてほしい。
- 本書を読んでいて、誤植とか間違いに気づいたらTwitterなどで知らせていただけると助かる。
■ リレーショナルモデルは道具 （P.11）- 伝えたいことは、リレーショナルモデルは道具、あくまで手段ということ。
■ データモデルとは （P.13）- データモデルとは、データの論理的な表現方法。
- リレーショナルモデルはデータモデルの1種。
- 物理じゃない。データモデルでカラムストア、というと違和感がある。それって物理なので、データモデルじゃないよね。
- 論理は、データの意味。
■ データベースを単なる入れ物だと考えてはいけない理由 （P.17）- 「自分で書けば何でもできる」という考えは間違い。既存のものを利用してこそ真のコンピュータエンジニア。
- データモデルとかを知らないから、なんでも「自分で書けばなんでもできる」と言ってるだけじゃないか。
■ 一つのデータモデルでは足りない場合 （P.22）- どんな場合でもRDBを使えばいいとは思ってない。データモデルに適切なDBを選びましょう。そうしないとお互い不幸になる。
- １つのデータモデルですべてうまく行く、という銀の弾丸はない。
- １つの製品が複数のデータモデルを持つ「マルチモデル」というのもある。
- MySQLlもPostgreSQLも、Jsonを扱えるようになった。ただ、MySQLでJsonを扱うやつlはβ版。
■ リレーショナルモデルとは！ （P.24）- 集合に根ざしたデータモデル。
- テーブル同士の関係性（リレーションシップ）ではない。
■ リレーションとは （P.25）- テーブルには事実が格納されている。
- 現実世界にある物事に対する事実の集合がリレーション。
- つまり、テーブル≒リレーション。
■ 集合の性質 （P.26）- 集合はテーブルと比較すると、重複もNullもなくて、存在する値のみ存在していて、要素間に順序がない。
■ SQLにあってリレーショナルモデルにないもの （P.32）- リレーションは値だから、更新はない。
- リレーションの演算は繰り返しとかできない。
■ NULLの功罪 （P.35）- Nullは便利。リレーショナルモデルが扱えるものを超えられる。
- でも諸刃の剣。どうやって最小限のダメージで食い止めるか。
- Nullがあってもいいテーブルがある。そうしないとちゃんと表現できない場合がある。
- でもNullを許さないテーブルにNullがあると破綻する。
■ 分離レベルとデータの正しさ （P.40）- 分離レベルはトランザクションの概念であって、リレーショナルモデルの概念ではない。
- 分離レベルちゃんと理解しないと危ない状況になる。
- MySQLはREPEATABLE-READにすると、参照系はロックが付かない。参照はある瞬間のスナップショットだけど、最新ではない。
- MySQL はREPEATABLE-READでもファントムリードが起きない。これは本当に素晴らしい。
- READ-COMMITTEDは、使うのが難しい。範囲検索で問題がある。クエリ毎に見えるデータが違ってきてしまう。みんなはそれを理解して使っているのか・・・。自分でちゃんとロックとかしないと、不整合が起きる。
- READ-UNCOMMITTEDは、一体なんのために使うのか・・・？
- SQL標準と同じ分離レベルの名前がついてるのに振る舞いが違う、というのは本当に困る。
- ロッキングリード vs ノンロッキングリード。ロックかけるときとロックかけないときで、取ってくる値が違う。
■ クエリが効率になる （P.45）- １回のクエリで必要なデータが取れる。
- そうじゃなく、クライアントにたくさんデータ送ってアプリ側で取捨選択、だと、クライアント⇔サーバ間のトラフィックが大きくなる。
■ データモデルは論理的な表現 （P.49）- データモデルは論理、実装は物理。
- 実装を知らないと性能に予測できない。
- SQL標準は理想であって実装ではない。実装を知っておくことは重要。
■ Q&AQ.
最近では関数型とか出てきて、ラムダ計算に基づいている。
リレーショナルモデルは、論理演算とかの制約にひっぱられていることもあるのでは。
リレーショナルモデル以外に注目している理論あるか。
A.
グラフDBとか、いいものが出てくればいいな、と思っている。
XML型DBは最近、息してない。
ドキュメント型DBは、生暖かい目で見守ってる。
関数型も、リレーショナルモデルの宣言型に近いのでいいのでは。
LT大会その場で無料のピザとビールが振る舞われ、LT大会です。
ひらぽんさん tacke_jpさん hironomiuさん meijikさん aoyagikouheiさん ---
先頭のひらぽんさんと、Nullネタのmeijikさんは、前述した読書会でご一緒している方です。
笑いあり、役立つ内容ありと、どのLTも面白かったです。
アンチパターンに踏み込む内容もありましたが、奥野さん曰く、「分かって使っているのなら良いと考えている」とのこと。
★感想：著者の奥野さんから直に話が聞けるということで、読書会でリアルタイムで読んでいる私にとっては渡りに船なイベントでした。
DBというとSQLや正規化など正道を説明する本が多いのですが、この本は集合理論だったりNULLだったり履歴だったりと、切り口が非常に斬新です。
ということでこのブログ読んでるそこの貴方、
読書会にも是非参加して議論しましょう！
ピザ、美味しかった～
奥野さん、LT登壇された皆さん、企画運営の関係者さん、ありがとーございました。
2015/9/29(火) 「RESTful#とは勉強会10」に参加してきました。
DoorKeeper
https://rubychildren.doorkeeper.jp/events/31238会場は高円寺のヴァル研究所さんです。
前半はいつもどおり「Webを支える技術」の読書会、後半は郡山さんによるハイパーテキストに関するお話、という二段構成でした。
山本 陽平
技術評論社
売り上げランキング: 13,663
第１部 「Webを支える技術」読書会この日は「9.9 キャッシュ」から読み始めました。
RESTプロフェッショナルの川村さんが用意してくださった、この日のポイントはこちら。
https://gist.github.com/tkawa/f82642dbe3368b35462a以下、テーブルでのディスカッション時のメモ。
---
■ Content-Disposition- filenameパラメータにファイル名を指定すれば、そのファイル名でダウンロードできる。
- 例えばPDFの場合、filenameパラメータを指定しなければブラウザ内で表示されるが、filenameパラメータの指定があれば、そのファイル名でのダウンロードになる。
- Bエンコーディングは、base64エンコードのことらしい。
- filename="?UTF-8?B?..." のBは、Bエンコーディングを表すらしい。
■ 実体参照と文字参照- HTML5においては、p.159の5つ以外の文字実体参照（実体参照）、数値文字参照（文字参照）は使う必要がありません。UTF-8でそのまま記述すればよいとのこと。
- HTML5ではUTF-8を使用することが推奨されているが、Amazonのサイトの文字コードはShift_JISらしい。
- ⇒ 調べてみた。確かにShift_JIS。
■ キャッシュ用ヘッダ- no-cache ： キャッシュするな、という意味。
- max-age: 0 ： キャッシュはする。条件付きGETで304を返す可能性がある。
第２部 郡山さんによるハイパーテキストに関するお話2015/06/27
「PHPカンファレンス福岡」の基調講演の再演です。
この１年前のPHPカンファレンス関西でも同名のセッションが行われたようです。
以下、メモ。
---
■ Hypertext- 複数のテキストを相互に関連付け、結びつける仕組み。
- どれが始めか終わりかも決まってない。テキストを超えたテキスト。
- １６歳の私には、この熱い世界が理解できなかった・・・
■ タルムード（A.D.600）- タルムードでもハイパーテキスト構造が使われていた。
■ Information Overload- これは２０世紀初めのロンドンの地図。情報が多すぎて整理されていない。必要な情報が得られない。情報洪水。
- 情報は多ければ多いほどいいとは限らない。S/N比が下がってしまう。
■ 時系列 （P.９）- テキスト（文字）の登場で、情報伝達が１：１でなくなった。
- 本は一部の権力者のものだけだだったが、グーテンベルクの印刷革命がその状況を変えた。知識レベルの爆発が起こった。
- １９９３年に紙から電子にシフトした。
- メディアシフトは長い歴史で２回しかおこっていない。（音声⇒テキスト、テキスト⇒電子）
■ メンデルの「優性の法則」の発見 （P.11）- １８６５年に発見された。これは生命の最重要法則だったのに、埋もれちゃってた。
- １９００年に、３人が同じことを発見した。
- このように、知識が埋もれるような事態が印刷革命後に起きるようになった。人類の進歩が埋もれてしまうようになってきた。
■ 立ち向かう二人 （P.12）- このような状況に、二人が立ち向かった。クロスリファレンスに挑んだ。
■ H.G.Wells （P.13）- 「タイム・マシン」などの小説で有名な人で、平和主義者だった。彼がやろうとしたのが、世界的な知的統合。
- WORLD BRAINという書籍で発表した。従来の百科事典とは違う方法で、世界の知を１つにまとめようとしていた。
- この考えに影響を受けたのがPaul Otlet。
■ Paul Otlet （P.15）- 図書カードはPaulが発明した。たくさんの情報をインデックス化した。
- これを図書館レベルから人類レベルにしたらどうだろうか、と考えた。そして、それを本当にやった。
- それが「世界書誌目録」。
- 分類しただけでなく、サービスを始めた。
- クエリから取り出せるような組織を作った。アナログのサーチエンジンで有料の質問受付をやった。
- これの問題は、スケールできないこと・・・
- 更に、テキストだけでなく音声や画像もインデックス化できるんじゃないか、と考えた。
- 情報を集めて整理して配る、という考えは先進的だったが、世間からは忘れ去られた・・・
- 労働集約的な方法では無理だ、ということで、そこで出てきたのが次の３人。
■ Vannevar Bush （P.23）- アナログコンピュータの権威で、原子爆弾の推進者。
- 「AS WE MAY THINK」という論文を出した。
- （ググってみたらブログがヒットした。 山形浩生の「経済のトリセツ」 ブッシュ『as we may think』）
- 彼は、情報の核心である、記憶を入手するときの不自然性に着目した。
- 人間の思考は散文的で相互にリンクされている。でも、本は頭から順に並んでいて、人間の思考と違う。不自然だ。
- 人間の思考のようなものが必要だ、ということで、まったく新しい百科事典を考えた。それがMEMEX。
■ MEMEX （P.25）- MEMory EXtenderの略らしい。
- 項目同士がリンクで繋がっており、自分が思考した順番を記録できる。
- 後から見る人は、その順番で情報が現れる。
- このシステムは完全にアナログだった。
- 人の連想の記録を追加したり辿ることができた。
- 我々が考えるような知性の記録が必要なんだ。
- でも、MEMEXは実現できなかった。
■ Douglas Engelbart （P.27）- マウスの発明者。
- 知識を誰でも入手できることを人生の目標に定めた。
- 与えられたものを処理する計算機から、インタラクティブな集団知性へ。
- 1968年にNLSのデモを行い、聴衆の度肝をぬいた。対話型の知的作業、という概念を発表するだけでなく、デモまでした。
- このデモはYoutubeでも見れる。
- 約1000人の聴衆の中にアラン・ケイがいた。彼もこれを研究したが、失敗し、徐々に忘れ去られた。
- 時代が早すぎた。当時はインターネットのようなインフラがなかった。
■ Hypertext （P.30）- 1963年に"Hypertext"という言葉で表したのがTed Nelson．
- Project Xanaduを1960年からずっと開発していて、2014年にOpen Xanaduとしてリリースした。
- 紙をベースとしたメタファや、その模倣であるWebは間違っている、という考え。
- バージョンが管理されていて、リンク切れが無く、著作権などが保証されているのがOpen Xanadu。
- 思想をOPENにしている。
- 紙がベースという思想を壊したいというイノベーターだった。
■ Aspen Moview Map （P.34）■ Hyper Card （P.35）- ここまで紹介してきたシステムは、実用的というより学術的だった。
- 初めて商用的に成功したのがHyper Cardだった。
- カードをメタファにしたリンクシステムで、完全なオブジェクト指向の世界になっている。
- オブジェクトの中にロジックが入っており、リンクのノードとしてカードを使う。
■ Ward Cunningham （P.37）- Hyper Cardに影響を受けたのがWard Cunninghamだった。
- 彼はWikiを作った。「WIKI WIKI」というのはハワイのバスから取った名前。
■ Brendan Eich （P.38）- 彼がHyper CardにInspiereされて作ったのがJavaScriptだった。
■ Robert Cailliau （P.39）■ Tim Berners-Lee （P.40）- Hypertextを作りたい、と思ってWorld Wide Webを提案した先がLeeだった。
- 彼は1991年にWWWのサービスを始めた。
- LeeはWebの発明者だが、Hypercardから7年経っていた。
- P.43は、世界で最初のWeb文書。HTMLっぽくて、タグのリンクとかは当時から存在していた。
- このHTMLは、1991年から現在に至る25年間の進化の間も、ずっと有効だった。
■ Hypertext + Internet = WWW （P.45）- 写真の二人の、左はTim Berners-Leeで、右はWebの共同発明者。Tシャツの文字が面白い。
- Leeの功績はインターネットの上にHypertextを載せたこと。
■ 1995年 （P.46）- 1995年はちょうどいろんなことが起こった。JavaとかWindows95とか、あとPHP 1.0も。
■ サーバサイド言語の比率 （P.50）- PHPがサーバサイドの言語で81%を占めている。一つ言えるのは、「誰も無視できない」ということ。
- PHPは、真ん中にのHにHypertextを持ってきた謎の力で80%も取れているのでは（笑
■ さいごに- 25年前のaタグだけで世界中が繋がっている。Webが世界の知識を繋いでいる。
★感想：郡山さんのお話は私の知らない話ばかりで、とても興味深い内容だった。
RESTfulというテーマとは直接は関係ないものの、この勉強会で扱っている書籍「Webを支える技術」というテーマにぴったりの内容でした。
過去の偉人が何を考え、何を目指していたのか。歴史から学ぶということは大事。
あと、郡山さん、こーゆうネタに詳しいってのも凄い。どっから仕入れてきたんやろ。
郡山さんの熱いトークの元、Webの歴史を垣間見ることができたひとときでした。
こーゆう素敵な勉強会を企画してくださった勉強会運営者さん、川村さん、郡山さん、ありがとうございました。
おまけ
