2012/7/29(日) 映画「おおかみこどもの雨と雪」を見に行ってきました。
オフィシャルサイト
http://www.ookamikodomo.jp/index.htmlウチから最寄の映画館まで、自転車でたった５分くらいなのです。
なので、コンビニへ弁当買いに行くような気軽さで映画を見に行くことができます。
今日は最終の23:10～25:20レイトショーで見たんですが、最終は600円安いし、席も空いててGoodなのです。
監督は、「時をかける少女」や「サマーウォーズ」の細田守さんです。
この方、良い映画作りますよね～。「時をかける少女」や「サマーウォーズ」、私も好きです。
ちょっと前に金曜ロードショーで「サマーウォーズ」やってたんですが、見たことあるのに
今回も泣いてしまいました。。。
やっぱ歳取ると、涙腺弱くなるのよね。
で、そんときの金曜ロードショーのCMや終了後に、新作として「おおかみこどもの雨と雪」が
紹介されていたので、んじゃ見に行くかーと思った次第なのです。
感想ですが、良い映画でした！サマーウォーズのように男泣きはしなかったけど、(ﾉω･､) ｳｩ･･･のようなカンジに。。。
この映画、たぶん小さいお子さんをお持ちの方とか見たら、たぶん大分私と感想違うんでしょうねー。
テーマですが、
家族愛という単語が私は真っ先に浮かびました。AIRやCLANNADのような。
と思って公式サイト見たら、
親子の絆という言葉がありました。「絆」かぁ、確かにこの言葉がぴったりです。
小さいお子さんをお持ちの方は、是非見に行って何かを感じ取ってほしいと思いました。
しかし
母は強しという言葉があるが、この映画からは、特にそのフレーズを感じましたねー。
守るものがあると、こうも人は前向きに、強くなれるものなのか。。。
あと映画で描かれていた大自然にも惹かれました。誰でも、こんな雄大な自然に囲まれて生活してみたい、と
思ったことは、1度や2度はあるんじゃないでしょうか。
でも、きっと実際に住むとなると、それはそれで大変なんでしょうね。。。
パンフレットも映画館で買ったんで、帰ってから読んでたんですが、そーいやこの主人公の花さん、13年間の
子育てを経ても、まだ32歳だったんですね。。。
自分とほぼ同じ年齢なんで、軽くショックを受けました。。。
でもでも、一人の母と、二人のおおかみこどもの
生き様に、私もホント背筋が伸びる思いでした。
母も子供も、純粋で真っ直ぐで。。。すごく輝いてた！
買ったパンフレットです↑。表紙の絵、マジ良いよね！
是非是非、映画館に家族で足を運んでもらいたい名作です。
2012/7/22(日) 「第2回 スタートHaskell2」に参加してきました。
PARTAKE
http://partake.in/events/e2f99b6b-a96f-4819-80d5-c5d61d2b427c以下の書籍をテキストとした、セミナー形式と演習形式を組み合わせた勉強会なのです。
場所はこれまでと同じ IIJ 大会議室 (17階) です。
ウチからは総武線１本で行けます。３０分弱くらいかな。
通勤定期が使えるので、乗車料金は一駅分で済むのがいいですね。
この勉強会は昨年メインで実施された勉強会「スタートHaskell」の続編です。こちらも私、参加してました。
んで、書籍を新たにして今年6月から再び始まったのが「スタートHaskell2」です。
スタートHaskellは、去年私が始めて社外の勉強会に参加した、記念すべき最初の勉強会でした。
この勉強会の特徴は、セミナー形式でテキストをじっくり学習できるのと、演習時間が設けられているので
実際に手を動かして演習問題に取り組むことで知識をより深められるトコです。
運営も複数人で手掛けられておりスムーズで、Haskellの有識者も多く、とても素晴らしい勉強会です。
なによりも、
Haskellという関数型言語を気軽にしかも本格的に学べるトコがお気に入りです。
すごく刺激的ですね。普段の仕事だけだと、関数型言語なんて使う機会ないしなぁ。。。
前回の1章、2章に引き続き、今日は3章～5章が範囲でした。終盤には2名のLTもありました。
私も事前にテキスト読んで予習し、必要に応じてソースコードを写経して本日の勉強会に臨みました。
「3. 関数の構文」 発表者 @mizu_tama さん
↑クリックすると資料の公開先に飛べます↑
@mizu_tama さんの自己紹介によると、Haskellは始めてまだ1ヶ月くらいとのこと。
しかもHaskellを始めた理由が、TwitterのTLにHaskellという単語がたくさん流れれて、流行っていると
思って自分も始めてみたとのことw
Haskell始めたばかりでいきなり発表を志願したところを見ると、かなりチャレンジ精神旺盛なエンジニアさんに
思います。この心意気は同じエンジニアとして尊敬しますし、若さと行動力が羨ましくも思います。
3章の発表で議題になった内容を、自分の覚書も兼ねて書いてみます。
■GHCでは、パターンマッチでどのパターンにも合致しない場合は、警告が出る。
■Haskellは、アンダースコアを付けた変数は、捨てるという意味を表す。
この場合、この引数が使用されなくても警告は出ない。
■P.37の欄外注釈で紹介されているオプションで、-Wallは積極的に使うべし。-Werrorは好みに応じて使う。
TLで右記のURLが参考に紹介されてました。
http://www.kotha.net/ghcguide_ja/7.0.4/options-sanity.html■otherwiseはTrueと定義されている。
■caseはなるべく使わない。
■letとwhereは似ているが、whereの方が宣言的になるので良い。
@kazu_yamamoto さんの紹介URL ↓
http://www.haskell.org/haskellwiki/Declaration_vs._expression_style■whereの中で定義するローカル関数には、一般に型宣言は付けない。ただし、付けることも可能。
その場合は、whereで改行して次の行に関数の型宣言を書き、次の行に関数を書く。（P.45の3.3節最後）
「4. Hello再帰!」 発表者 @ko1kun さん
↑クリックすると資料の公開先に飛べます↑
↑のスライドにはない自己紹介スライドが使用されていたのですが、コレが面白かったですね～
今日の勉強会に行ってくる時の、@ko1kunさんとその奥さんとの会話とかw
あと、有名どころっぽいWebドメイン取りまくってたり。。。
落語が好きなようで、かなりユーモア溢れるトークです。
7/25追記
自己紹介スライドが追加公開されました！ コチラあと、かなり読書家なようで、いろんな本に書かれた再帰についてスライドで紹介されてたのが印象的です。
発表で取り上げてたフィボナッチ数列の再帰にしても、いろんな側面から自分なりに考察されてました。
こーゆう職人気質なエンジニアさん、私は好きですw
4章の発表でポイントになった覚書まとめ↓
■正格評価だと関数呼び出しでスタックを消費するが、遅延評価ではスタックを使わない。
→ スタックオーバーフローで差が出る
■世の中のHaskellに対する批判は大抵間違っているが、メモ化されるかどうかわからないという欠点はある。
(慣れればメモ化されるかどうかは見えるようになる）
→ これは私の頭ではなんのことか理解できなかった。。。ので調べないと。ToDo!
■竹内関数、というのが発表で出てきた。。。
→ 私は知らなかった。けっこう有名らしいので、あとで調べておこう。。。ToDo!
■Haskellのコーディング時、インデントで縦位置を揃えるためにタブ使うべきか否かの議論アリ
→ 少なくとも、ソースのなかにタブが入っているのは良くない、とのこと。
@kazu_yamamoto さんがツイートで紹介してくださった「Haskell Style Guide」↓
https://github.com/tibbe/haskell-style-guide■フィボナッチ数列の実装と実行速度について（@kazu_yamamoto さんがツイートで紹介）
・普通の速度のフィボナッチ数列
https://gist.github.com/3158648 ・素朴な fib が何故効率が悪いかの図
http://www.sampou.org/cgi-bin/haskell.cgi?Memoise
「5. 高階関数」 発表者 @S1E11 さん
↑クリックすると資料の公開先に飛べます↑
かなり直前まで発表スライドを作っていたが、間に合わなかったとのこと。。。
締切が近づいて焦る @S1E11 さんの悲哀に満ちたツイートが印象的でした。
でも、発表はうってかわって、かなり堂々と説明できていたところを見ると、入念に準備して学習してきた
感じが見て取れました。
一部、曖昧で説明をぼかしてたトコもあったけど。。。愛嬌で切り抜けてたしw
憎めないキャラ属性を持ってますねー。
5章の発表で議論になったとこを覚書で挙げます。
■リストからリストの生成をする場合は、foldr をつかう。
■ただし、逆順のリストを返すときはfoldl' を使う。
■数値にたたみ込むならfoldl' を使う。
■foldlは基本的に使わない。
■関数合成は一番右だけ $ にして、残りは . にすれば大体うまくいく。
（外側から括弧をほぐしていく）
・参考：@kazu_yamamotoさんのブログ
http://d.hatena.ne.jp/kazu-yamamoto/20100702/1278036842
3人の発表のあと、演習問題を解く時間が取られました。
・演習問題のページ：
http://wiki.haskell.jp/Workshop/StartHaskell/LYHGG/4章の演習で「偶数と奇数にわける」という問題があったのですが、コレ、時間内に歯が立たなかった。。。
問題自体は簡単なハズなんだけど、いざHaskellで解こうとすると、何をどう使えばいいのかすぐ出てこない。
やっぱ、関数型の解法に慣れるにはもっと勉強する必要があると痛感しました。
演習のあとはライトニングトーク(LT)の時間です。
LT1 「文芸的プログラミングについて」 発表者 @shokos さん 文芸的プログラミングは、スタートHaskellの初代の方の演習でけっこ使う機会あったので、イメージ湧きました。
これって、いわゆるTDD（テスト駆動開発）に該当するんでしょうね。
リファクタリングする場合には、特に文芸的プログラミングの要素は重要になってくると思います。
特に最近、仕事でアジャイルに関わることが多いので、尚更、文芸的プログラミングのありがたみを実感します。
LT2 「idのナゾ、constのヒミツ」 発表者 @kazu_yamamoto さん
↑クリックすると資料の公開先に飛べます↑
関数idは、先日参加した
TaPL読書会にも1章か3章あたりで関数として出てきてたように思います。
今日のLTでも話になってるし、やっぱidって用途あるんだろなー。ちなみに発表では以下が紹介されました。
■idは、関数を畳み込むときの初期値に使用できる。
■idは、Bool をそのまま返す述語として使用できる。
■constは、引数を無視する関数として使用できる。
このあと、
SKIコンビネータなるものが出てきました。
やべー、俺、全然ついていけてない。。。
みんな、このハイレベルでアカデミックな理論についていけてるんだろうか。。。
発表の @kazu_yamamoto さんは去年の「スタートHaskell」のテキストの原書を訳されてた方で、Haskellの知識は
ちょっと飛び抜けてますね。やっぱ、１つのこと徹底的に極めたエンジニアというのは強いですなー
今日も非常に有意義な時間を過ごさせていただきました。
発表者様と運営者様、ありがとうござました。次回も楽しみにしてます～
---
ハッシュタグ #start_haskell に関するツイートをゆかりんのーとで纏めてみました。
https://yukar.in/note/ckF3gL
2012/7/19(木) 「
アジャイルサムライ読書会 横浜道場 特別編 "アジャイルは組織を変えられるのか"」に参加してきました。
PARTAKE
http://partake.in/events/8b888e57-e3d3-4703-a456-4c042bcaf429
今日は特別編ということで、楽天の藤原さん
@daipresentsと及部さん
@TAKAKING22による講演があるとのこと。
実は、今日参加する直前まで、私はお二方のことは知りませんでした。
ですが、横浜道場で以前、偶然知り合った同じ会社の方からメールが飛んできて、
「今日道場行きますか？藤原さんの講演、以前のとても良かったから今日も行きたかった」
とのことでした。どうやら、以前に藤原さんの講演を聞いたことがあったようです。
藤原さんのブログとかいろいろ紹介いただいたので、私も（就業中に）目を通して
期待を更に大きくして参加しました。
・・・まずはじめに、この日の講演の感想を言っておきたい。
マジ感動した！お二方の素晴らしい講演内容もさることながら、藤原さんには
熱い語りに引き込まれ、ちょとジーンと
きてしまった程だ。
藤原さんと及部さんの講演スライドはslideshareで公開されていますので、↓に掲載しておきます。
「アジャイルリーダーシップと組織改革 ～楽天のアジャイル開発というリアル～」 @daipresents
デブサミの講演スライド↑に、今日は↓が最後に追加されてました。デブサミ後のエピローグ。
整理と自分への覚書を兼ねて、藤原さんの講演の流れを以下にまとめます。
社内でスピード重視派とTDD派ですごい議論になり、TDDは「最低限の範囲」でやるということに決まった。
→ この決定を
こっそり裏切った。
→ 好きなだけテストをやるようにした。
→ 規律が徐々に生まれてきた。
・まかせる
・チェックはする
・攻めの選択をする（リスクありきで攻める）
→ 3ヶ月くらいで成果が見えてきた。
・開発の時間： ＋23%
・ライブラリ数： 3.5倍 （5月～11月）
・開発に占めるUTの割合が40%までに大幅増加
→ UTの効果が凄くて、3ヶ月くらいで元が取れてしまった。
→ 今回のノウハウを社内展開しようとした。
・アジャイル
・継続的インテグレーション（CI）
・自動化
→ うまくいかなかった。。。
・雑なSIでJenkinsのAleretメールがと止まらない。
・伝わらない。
・始まらない
→ 新人研修でアジャイルやらせてみたら、うまくいった
→ 社内でできなかった理由は、
老害なのでは？
（新しい流れについてこれないエンジニアが、レガシーコードを量産し続けるみたいに）
→ うまくいかなかった原因の
仮説を立ててみた。
→ 仮説：忙しい
（
砂漠で道に迷った人に「自然って大事ですよ」って言っても伝わらないのと同じ）
→ じゃあどうすれば？まず、他部署との連携をやってみて、プロセスから現場を変えようとしてみた。
・QAにCIを注入
・プロセス改善
・育成協力
→ 失敗。。。（一緒にやってる感が全然ない）
→ 失敗した原因の
仮説を立ててみた。
・レポートラインが違う（部署間でそもそも目標が違う）
と、時系列に沿って行動と分析をされてました。なるほどなあ。
では、どうすればいいのか？という視点で話は更に続きます。
■成功を創る。
→ アジャイルを少しだけやってみて上手くいかなかった人が「アジャイルは使えない」と言うのが悔しいので。
■今の"普通"を全否定する。
→ 保守派や老害などに埋もれ、アタリマエと思い込んでいる考えを全否定すべし。
■見えないなら見に行く。
→ 現場に出て行って、改善をする。論より行動。
→ 現場の課題が見えてくる。
→ 実際に朝礼や見える化をやってみたり、アジャイルのイベントに行かせてみたりしたら、うまくいった。
（スピード感が出て、何よりも楽しいし、みんなで解決するという一体感が出た）
→ でも、やるだけではダメ。藤原さんのようなリーダーシップがある人が抜けても継続していけることが重要。
→ 重要なのは
人を育てるということ。
・コーチはいつかいなくなる
・
熱意が人を育てる→ チームとしての醸成が重要。
・介入してくるマネージャだと失敗する。
・一緒にやりたい、という気持ちになること
・
チームを勇気づけることが大事
・楽しかった、と言われるチーム作り
・仲間を増やす
・
メンバー全員が同じ方向を向くスライドの最後で、日露戦争のバルチック艦隊との最終決戦で全搭乗員を鼓舞するために使われたフレーズが
紹介されました。
皇国の興廃この一戦にあり、各員一層奮励努力せよ日露戦争をテーマにした司馬遼太郎の小説「坂の上の雲」にももちろん出てくるのですが、私、この小説が
超好きなのです。ちょっと前にドラマ化もされましたが、その前から読んでて、二周りは読み返したりしたほどです。
で、この「皇国の興廃この一戦にあり、各員一層奮励努力せよ」というフレーズも大好きで、満員の通勤電車で
この本読んでたんですが、小説のあまりの熱さに涙流しながら読んでました。恥ずかしながら。。。
やっぱ、こーいう
チームを勇気付ける言葉って大事ですよね。この発表で再認識しました。
奮い立たせるメッセージというか、共感というか、一体感というか。
こんなメッセージ性があれば、私だったら一発で同じ方向を向いて頑張れちゃう気がします。マジで。
藤原さんの講演の次は、楽天で藤原さんの後輩の、及部さんの講演です。
「アジャイルペーペーシップとチーム改革 ～楽天のアジャイル開発というリアル another story～」 @TAKAKING22
入社４年目ということで、若さ溢れる講演です。
俺が入社４年目だったころ、こんな志が高い青年だっただろうか、と反省つつ、羨ましさも感じます。
「改革」、「革命」、「改善」という３語を挙げ分析するというスタイルから入ったのは面白いですね。
講演からいくつかポイント抜いてみます。
■人は変化を嫌う。自分を変えるのは簡単だが、
隣の人を変えることは難しい。
だが、
自分が変われば、周りも変わった。■「改革」じゃなくて「改善」を目指す。（改革は善いことばかりとは限らない）
■王道でも覇道でもなく、邪道を目指す。
→ 道は１つではない。
改善していこうと目指すことが大事。
■いろんな
道があっていい。アジャイルでなくてもよい。アジャイルが目的ではない。
たしかに、アジャイルには「こーやったらアジャイル。これをやってないからジャイルではない」という
正解は無いと思いますし、明確に存在しない正解を求めすぎて柔軟性を失う弊害のほうが大きいと感じます。
なので、邪道でもよい、というのは納得できます。プロセスよりも、改善していこうとする気持ち大事。
吉羽さんも以前横浜道場の講演でおっしゃってましたが、「態度重要」というやつですね。
あと、「自分が変われば周りも変わった」というフレーズは強烈でした。
たしかに、会社がアジャイルを取り入れてくれない、とか、上司の理解がないから、とか理由つけて
やらないよりは、自分がやってみて周りを変えていくというのが大事と思います。
たとえば、藤原さんの講演にもあったように、こっそりやってみる、のもひとつの手かな、と。
できるところから一歩を踏み出すべし。
んで、講演の最後はまさかの猪木風で終焉。若さとユーモアに溢れ、及部さんのメッセージも凝縮されてた良い講演でした。
あと、講演のほかにも２回のディスカッションタイムがありました。
２回目のディスカッションで発表を担当したのですが、自分の言いたいことを全然伝えられなかったと反省。。。
というか、まとめる力が足りないと痛感。これは次回以降のTryだなぁ。
でも、他社のエンジニアさんと意見交換ができるディスカッションというのはやっぱいいですねー。
１回目のディスカッション時の、ウチの班の模造紙↑
22:00からは懇親会です。
ピザとビール飲みながら、楽天の藤原さんと及部さんへのＱ＆Ａが繰り広げられました。
このＱ＆Ａも面白かったですね。お酒も入って、より深い一幕を知れるひととき。
藤原さんが「6ヶ月で12回くらい心折れた！」とおっしゃってたのが印象的です。
Ｑ＆Ａの内容は道場主の
@tw_takubonさんが纏めて下さったページがあります。
https://github.com/agile-samurai-ja/support/wiki/Readingagilesamuraiinyokohama201207192012/7/26追記
藤原さんのブログで、懇親会のＱ＆Ａについて紹介されました。
→ アジャイルサムライ横浜道場で受け取った12の質問状 最後に、素晴らしい機会を提供くださった講演者様と運営者様、ありがとうございました。
また新しい特別編を期待してます。
参加者さんが纏めて下さったツイート一覧です。↓
2012/7/17(火) 「TaPL読書会 第1回」に参加してきました。
PARTAKE
http://partake.in/events/b42e1272-dcfc-44b2-93cf-aee790e07deeUstream
http://www.ustream.tv/recorded/24052808会場は株式会社ワークスアプリケーションズの1Fラウンジです。
JR新橋駅からほぼ１本道なのですが、歩いて１５分ほどかかるのです。
しかも、この日は今年一番の暑さだったらしく、群馬県の館林では39℃だそうな。。。
日は沈んでいるものの、これだけ暑いとさすがに汗だくになりますねー
さて、私がこの勉強に参加したいと思い立ったのは大きく３つの理由があります。
■１．関数型言語（特にHaskell）への興味
■２．英語のお勉強
■３．大学院生の頃のリベンジいちおう、簡単に紹介しておくと。。。
■１．関数型言語（特にHaskell）への興味去年は「スタートHaskell」という勉強会に参加していて、そして今年に入ってから
「スタートHaskell2」という勉強会に
引き続き参加しています。ここで出会ったHaskellという関数型プログラミング言語が、これまた興味深いのです！
普段はJavaをメインに使って仕事をしていますが、それ以外では、これまでC言語やC#, VB.NETといった
オブジェクト指向型あるいは手続き型の言語を中心に経験を積んできました。
（あと他にはJavascriptやPerl, ExcelVBAなども仕事で使ってます）
そんな私にとって、Haskellの思想を学んだときは一種のカルチャーショックを受けましたね。。。
そしてHaskellの特徴でもある型システムについても学んでみたい、と思った次第です。
■２．英語のお勉強最近、ウチの会社でも、
グローバル！ぐろーばる！ と盛んに言われるようになり、英語の習得が
避けられない状況になってきました。。。 上司や後輩も、最近海外出張とか海外研修に行ってるし。
んで、どうせ英語を勉強するなら、モチベーション高く学習したいなぁ、と。
それならば、自分が興味あるIT系の
原書を読む読書会を見つけ、参加すればいいんじゃないか！と思ったのです。
なんと単純な考え。。。
でも勉強って、やっぱモチベーションが大事だと思うのです。好きこそ物の上手なれ、です。
■３．大学院生の頃のリベンジ現在、このTaPL読書会以外にも、
名古屋大学でTaPLの勉強会が定期的に実施されています。
実は、私の母校なんです～
大学院の所属は情報科学研究科だったのですが、私も輪講で型システムをテーマにした原書を読みましたよ！
でも、
あえなく撃沈した苦い思い出しかありません。。。
しかも、輪講の本の名前は忘れましたが、
たぶんTaPLだったと思うのです。。。
だって、今読み直しても、すごく見覚えとかあるし！（もう10年近く前のことで記憶が定かではありませんが）
というわけで、今回は当時のリベンジなのです。今回この読書会に出会ったのは
運命とすら感じた。
大学の後輩もTaPL頑張っていることだし、私も頑張ろう！
で、でも、ついていけるかなぁ。。。
さて、オープニングは
@none_tokaさんによる1章「Introduction」の発表です。
なんと、大学院でもずっと型システムを研究されていたとのこと。
発表は全体的に非常にわかりやすく、いかにもTaPLを極めていることが窺い知れる内容でした。
なによりも、発表から
型システムに対する愛を感じた！
やっぱ、この難解な書籍を読み進める上で、有識者がいるのといないのとでは、大きな差が出ると思うんです・・・
1章の発表のポイントを、スライドから抜粋して以下に纏めてみます。
■プログラミング言語における型システムとは
→ プログラムが
「ある振る舞い」を行わないことを
文法レベルの分析で保証する手法の１つ
■型システムは、実行時の振る舞いを
静的に（コンパイル時に）近似計算しているとみなせる。
（静的型検査）■型システムの有用性
・型エラーを静的に検出
・言語の安全性（language safety）の一部を静的に保証
・実行の効率化（型システムにより、コンパイル時の最適化に有用な情報を収集できる）
・etc
■言語の安全性と型安全性は同じではない。（前者は、実行時検査でも可能な場合がある）
■型システムと言語の設計は連携して行うべし！
理由： 互いに文法／機能レベルで依存するから
普段使っているJavaにも型というものはあるが、この本で紹介されている型とは、ちょっと異なるようです。
型って、奥深い。。。
あと、発表の中にも出てきましたし本でもチラホラ出てくるMLというプログラミング言語ですが、私も
大学３年生の時に情報工学科の講義で受講しましたよー。科目名は確か「関数型プログラミング」という
名称だった気がする～。でも、もう10年以上も前になるのか・・・懐かしいです。
ちなみに当時の講義は↓の書籍が教科書として使用されました。
単位もちゃんと取得したけど、最後のほうの講義はけっこ難しくてついていけなかったんだよなぁ。。。
ただ関数型言語との出会いのインパクトは強烈でして、将来もう一度勉強するかもしれない、と思ってこの本、
大事にとっておいたんですよー。昨日押入れの段ボール箱を漁ったら、ちゃんと出てきました！
さて、次は
@ruiccさんによる３章の発表で、章題目は「Untyped Arithmetic Expressions」です。
この本、3章からDefinitionやTheoremやProofやExcerciseがいっぱい出てきて、いきなり難しいです。。。
この章のポイントは、帰納法や導出木による証明を理解できるかどうかにかかっている気がします。
@ruiccさんの発表で難解な箇所については@none_tokaさんが補足を入れる、という感じで進んできました。
やっぱ有識者がいるってのはデカいですね。。。
発表の中で詳しく見たトコは、3.4節のSemantic Styleですかね。次の3種類があるとのことです。
■１．Operatinal semantics （操作的意味論）
■２．Denotational semantics （表示的意味論）
■３．Axiomatic semantics （公理的意味論）
@none_tokaさん曰く、これらの違いについてはWikiを読めばよいとのこと。
あと重要なポイントは、3.5.3節の導出木（derivation tree）は、
下から上に向かって作るということです。
これ、私が大学時代の講義でハマッたポイントなんで、当時の苦い記憶を鮮明に思い出しましたよ。。。
自分は正直、3章でさえ、ついていくのに必死なレベルです。。。
うーむ、今回は3章までで時間になったので、次回参加するまでに復習するとしよう。
でも、たまには普段の仕事やプログラミングから離れて、こーいうアカデミックな勉強をするのも新鮮ですね。
次回の第2回は8/1に開催されるとのことで、ぜひ参加したいと思います。
最後に、会場を提供してくださったワークスアプリケーションズの関係者様、主催者様、ありがとうございました。
次回も楽しみにしてます。
・・・懇親会、出席しておけばよかったと悔やんでる。
2012/7/10(火) 「DBリファクタリング読書会 第二回」に参加してきました。
ATND
http://atnd.org/events/30394Ustream
http://www.ustream.tv/recorded/23893625第1回に引き続き、会場は日本オラクル青山センターです。私の会社からだと40分ほどで着きました。
スタッフの方々も含めると、20人弱くらいいたのかな。
データベースって、ソフトウェアエンジニアには避けられないテーマですよね。。。
データベースを使用しないシステムなんてありえないですから。
酷い設計のDBを目にしたことのあるエンジニアさんも多いのではないでしょうか。
私も、？？？な構造のテーブルを何回も目にしたことがあります。
そんなDBを時々目にしつつも、私がデータベース設計について更に大きく意識するようになったのは、
IPA情報処理技術者試験の
「データベーススペシャリスト」を取得したときでした。
試験問題が、徹底的に正規化を意識させるDB設計を求める出題になってて、
あの勉強をすると嫌でも相当鍛えられると思います。。。
あと、ウチの会社も
HiRDBってDBMS製品を作ってるので、なおさらDBMSを意識する機会は多いです。
ちなみに、日経コンピュータのパートナー満足度調査で、2012年度は
HiRDBが1位だったようです。
でも、OracleやSQL Serverよりユーザ数少ないし、1位って言ってもなぁ。。。
そんなこんなの私にとって、この勉強会は非常に興味深いものでした。
さて、勉強会のTOPは
@nippondanji さんによる講演「データベースの不吉な臭い」です。
MySQLのサポートエンジニアを長年担当されているとのことで、データベースに対する深い知見に基づいた、
とても興味深い内容でした。私の心に響いたフレーズをいくつか以下に挙げてみます。
■ほとんどの問題はテーブル設計に帰着する。リレーショナルモデルの知識は必須！
■リレーショナルモデルの利点
・アプリのコード量が減る
・データの整合性をデータベースで保証できる
・SELECTがストレートに
・パフォーマンスの向上
・データベースの変更が容易に
■DBの正規化をしないと、多くのコードはデータの整合性確認に費やされるハメになる。
■勇気を持ってデータベースをリファクタリングすべし。
でも、一番印象に残ってるのは、スライドに書かれた
大ババさまの一言でした。。。
ナウシカ、私も大ファンなんです。原作７巻セット、いまも大事に持ってます！
@nippondanji さんの講演後は、参加者さんと主催者さんがイスを寄せ合っての座談会です。
参加者みんなでポストイットに議論したい内容を書いて、そこからいくつかピックアップして
みんなで議論を進めていく進行方法でした。
この方法、かなり良いですねー。議論や意見交換が活発に行われて、とても有意義でした。
トリガーやストアドプロシージャの使いどころや応用方法、区分値テーブルの扱い、
外部キーの参照設定を貼るべきか否か、正規化と性能のバランス、などなど、非常に興味深い
テーマについて深く意見交換できました。
特に私にとっては、トリガーやストアドは使ったことなかったので、他のエンジニアさんの
経験や使いどころの話を聞くことができたのが凄くためになりました。
覚書として、議論した内容をいくつか羅列してみます。
■トリガーが多すぎると、そもそもDBの設計がマズいことを意識すべし。（カラム重複が多い可能性大）
■トリガーで監査証跡用のログを出す運用をしているが、更新処理とトリガーからのログ出力は
別トランザクションにしないと、ロールバック情報が監査証跡として残せなくなるので注意すべし。
■ストアドはDBMSの種類によって変わるので、使いすぎると移植性や保守性を落とす。
■ストアドを使うと、APサーバやバッチサーバではなく、DBサーバに負荷がかかることになる。
■ネットワークの負荷を減らしたいなら、ストアドも有効な選択肢となる。
■参照ONLYのテーブルならば、あえて正規化せず性能重視にすることもありえる。
■外部キーを設定すると性能が落ちるというのは都市伝説である！
■外部キーを設定することで、クエリの発行回数を減らせる。
■外部キーを設定しないと、親テーブルにデータがあるかどうかをアプリ側でSELECT発行する必要がある。
■巨大な区分値テーブル１つで様々なコードを扱っているようなマズい設計は、Oracleだと
パーティションテーブルを使うことで解決できるかもしれない。
途中から懇親会のピザも届いて、ビール飲んでピザ食べながらの座談会になりましたｗ
座談会の議論も白熱して、ふつーに懇親会の時間になっても議論が継続してましたね。
やっぱ、みんなデータベースに興味あるんだなぁ、と思うひとときでした。
懇親会の最後に未開封のワインが残ったので、持ち帰り用にじゃんけん大会になりました。
んで、なんと２本目のワインのじゃんけんで、一発勝ち抜き！白ワインげっとしましたー
思わぬお土産もゲットして、お酒好きな私としては大満足です。
とても有意義な時間をすごせて、参加してホント良かったなぁと思います。
次回もぜひ参加したいです。
ただ、個人的な要望ですが、第２火曜日は避けてもらえると嬉しいかも。。。
別件の勉強会と重なってしまうので。次は月曜日とかがいいなぁ
最後に、会場を提供してくださったOracleの
@yokatsukiさんはじめ関係者様、スムーズに運営してくださった
@akitsukadaさんはじめ主催者の皆様、ありがとうございました。次回も楽しみにしてます！
あ、あとツイートをtogetterで纏めました。
2012/7/8(日)
なんとなく思い立って、ブログを開設してみました。
最近、社外の勉強会に参加するようになって、いろいろなエンジニアさんが
ブログで情報発信している姿に触発されたのが、ブログ始めた主な原因の１つかな。。。
やはり、いろいろ学んだことを自分の中で溜め込むだけでなく、一人のエンジニアとして
情報発信しフィードバックを得ることが重要じゃないのか、と思う次第なのです。
と、もっともらしい理由をつけて↑書きましたが、気負うことなく、
日々感じたことを気ままに書いていこうと思います。
■今日の出来事今日は、Skype使ってオンラインで英会話できる
レアジョブの無料体験コースをやってみました。
最近、会社でグローバル化の波がけっこ凄くて、ちょと英語かんばって見ようかな、
という気持ちからです。
火曜日に会社でTOEIC受けたばっかなんですが、やっぱ大学までの英語力の財産である程度
得点できるものの、年々スコアが下がる一方で、このまま落ちていく一方なのは寂しいし悔しいし。。。。
ちなみに今日は初の無料体験で25分間、講師のフィリピン人の方と、自己紹介とか英語で会話しました。
やっぱ、自分が表現したい英語が口から出てこなくて、もどかしかったなぁ・・・
あと、やっぱ耳が慣れてなくて、何回も聞き返しちゃったし。
でも、とても刺激的でした。あと1回、無料体験を受講できるから、明日もやってみよう。
ということで、英語をちょとずつだけど、頑張っていこうかな。。。
チャレンジに年齢は関係ないよね！
-->
