git勉強会 in Okinawa に行ってきた

2013/09/28 に git勉強会 in Okinawa があったので紛れ込んできました。
togetter は こんな感じ。


まずは git のハンズオン。資料はこんな感じでした。
ハンズオン形式は始めてでしたが、これは個人でやるタイプなのでひたすらもくもくでした。
割と見たことある内容なので資料を読んでました。
rebase で fixup にするとコメント無し squash にできそうなので便利そう。


次は @Tomohiro さんによる git を使った開発の話。

git は「複数人数で開発とかする上で使えそうなもの」であって、開発のスタイルとかに合わせて使っていこう、みたいな話とか。
例えば git-flow とか github-flow とかみたいに git を使うスタイルはいくつかあるらしくて、自分達に使えそうなものを取り入れていけば良いのでは的な話。
具体例として @Tomohiro さん達はスクラムしてたりします、とかとか言ってました。
github 使うなら huboard 使えばカンバン化できたりするよー、とかとか。
型に合わせるのも良いけれど必要なところだけ取ってけるともっと良いんだろーなー、とか思いましたまる。

あとは、環境な話とか。
vagrant を使えば環境構築のレシピをテキストベースで保存できる == git で管理可能ですよー、とか。
環境の依存とかも解決できるしロールバックもできるし良い感じそう。

packer を使って OS Install -> vagrant で上げて -> puppet でコマンドとかを入れる

とかしてるみたいです。
chef も良いけれど、 chef は割と厳密なファイル構成でファイルを書かないといけないらしくて、 puppet は単純な構成でも厳密な構成でもできるし良いよー、と。
とりあえずテキストベースで環境を構築できるしこうやって公開もできます、みたいな話。
便利そうなので次何か構築する時は使ってみたいなー、とか思ったり。


ハンズオンの二回目はコンフリクトの解消。
だけれど曰く「ちゃんとコミュニケーションできてたらコンフリクトなんて起きないよ」と。
ハンズオンでは積極的にコンフリクトして解消する作業。
「コンフリクトするのは怖くないよ」みたいな印象を持ってもらえば良いな、って形らしいです。

ちなみに、 rebase 派 と merge 派 は分かりあえないらしいです。
rebase は svn とかのユーザの感覚らしい。まっすぐなので。
merge はなんだろ。 mercurial かな。
ちなみに私は rebase からの merge --no-ff 派。
merge 時に conflict するのは面倒だけれど master に残すのは merge commit じゃないと面倒そうなので。
なので rebase -i で 1つにするほどでも無いけれど、master に 直 merge も嫌かなー、くらいのスタンス。



おまけで勉強会の時に飛んできた URL 群たち。

Git を学ぶ - @Tomohiro さんによる gist。 git を学ぶ上で便利そうな tips とか command とかの紹介。
あと、git-バルスでは「どうやるとgitがぶっ壊れるか学べるから良いよね」とのこと。
ちなみに加えて「まぁやらないですけれど」とのこと。

ChangeLog を支える英語 - yamane さんが投げてたURL。
commit message の先頭は大文字にしましょうねー、とか comment を書く上での tips 集。

git commit時のコメントを英語で書くための最初の一歩 | hiro345 - kanpe さんが投げてました。
これも tips 集みたいな感じ。ざっとしか目を通してません。
commit する前に確認すべきこと、みたいなのは良い感じだったよーな。

ChefとPuppetの比較 - こちらも kanpe さん。git じゃないけれど。実を言うとまだ目を通してない。


感想。

全体的にもくもくな感じでした。
コンフリクトのハンズオンの時に知らない人とあたればまた違ったのかもしれませんが。
というか私が知らない人と話してないだけか。
git そのものは知ってる知ってるみたいな反応してしまったし。でもほぼ個人でしか使ってないオチ。
個人的には仮想環境な話が聞けて良かったかなー、と。次に git を使った開発の実例とか。
git user (というかバージョン管理する人)が増えると良いなー、とか思いながらかんそーおしまい。

リファクタリング・ウェットウェア を読んだ

リファクタリング・ウェットウェア を読みました。

2009年の本らしいです。
なんで今読んだかと言えば、本屋でふらふらまわって立ち読みしてて見付けてしまったので。この辺は本屋流石ですね。

さてこっちも確か読み終わったのは昨日。
最近は一日数章読んで数日かけるスタイルかもしれない。単に一気に読み切る集中力が無いとも言う。

内容としては達人プログラマをちょっとアップデート + プログラマ臭が少し抜けた、みたいな印象。 達人プログラマは全部読んでないので憶測ですが。

割と心理学とかそーいうもの寄りで、効率良く学ぶには、みたいな話とか。
心理学うんぬんで若干うさん臭いけれど、「うさん臭い話ですが」みたいな書き方されてる。根拠が不明瞭な分ちょっと違和感はある。ただ、こういう役に立ちそうな話ありますよ、みたいな感じ。

特に印象的なのがドレイファスのモデル。
「技術を修得するためにはこのような段階を持つ」みたいなの。
実際、これが正しいかとかは謎だけれど。

一応、具体的な学習例とかあるかな、とか思ったけれど割とアバウト。
方針は示してくれるので、本に書かれている通り「レシピ」チック。

「毎年言語を学べ」みたいに、達人プログラマの方が具体的なのかも。あれ。「学べ」って具体的かな?
学習の仕方とかも「目標立てよう」とか。確かに立てた方が良さそうだけれどどうしようーん。みたいな。いやそれも含めて自分で考えなアカンのか……。

うさん臭いうんぬんと言えば、脳の仕組みの活用とかいろいろあったり。別に否定してる訳じゃないけれど。いかに効率を上げるか、みたいなのが大量にあるから少しでも取り入れると良いんじゃないかなー、みたいなスタンスで読んでました。

あとは印象的な単語はエクソコーテクス。
実を言えば「エクソコーテクス」って 単語は憶えていなかった。
エクソコーテスが何かと言えば、外部脳、らしい。
本とかを丸暗記するんじゃなくて「この本にはアレが書かれてた」って憶えれば、その知識は活用できるし丸暗記の労力は減るよね。みたいな。
私が「エクソコーテクス」って単語を忘れたら恐らくこの記事を見るはず。ちゃんと「そういうものが残ってる」って憶えてればだけれど。

効率を高めるためのtips集みたいな感じだったかも。



というか Teem Geek といい リファクタリング・ウェットウェアといい、最初の章はインパクト強めなー。立ち読みを買わせる戦略か何かなのだろうか。

Teem Geek を読んだ

Teem Geek を読みました。xHago とかで評判が良かったので読みました。

というか読み切ってました。実を言うと数週間前くらいに読み終えて、感想を今書こうかとしてるところです。
割と記憶が薄れ気味なのでパラパラ捲ったり目次を読みながら書くことにします。

記憶薄れてるってことは微妙だったのか感あるので、まずは憶えてることから。
印象としてはやっぱり HRT 。

• Humility - 謙虚
• Respect - 尊敬
• Trust - 信頼

人と関わるんならこれを信条にしよう、みたいなもの。
確かにHRTを実践できると悪く思う人は減りそうだなー、とは思いました。
ただ、これができたら苦労しないよね、とか思ってしまうので私にはまだまだ精進が必要そう。

次に憶えてるエピソードは文化を大事にしよう、みたいな話。
ここで言う文化はコーディングスタイルとかで、オープンソースなソフトウェアに「とても良い機能だけれど文化が少し違う」ものを取り入れるかどうか、みたいな。
Teem Geek で出てきたエピソードでは、文化を優先するためにそのコードは取り入れてませんでした。そこまでするのかー、と印象に残ってます。
あとは天才の神話とか。「一人でやるには限度がある」とか「誰もが一人で籠って完璧なのを作り幻想を抱くが幻想だ」みたいな感じ。

この辺からパラパラ捲りつつ書きつつ。

全体的な印象としては オープンソースのコミュニティの失敗例と成功例、みたいな感じ。
「ギークでなくても本書のアドバイスは読む価値がある」って帯に書かれているんだけれど、やっぱり目線はギーク寄りなのかな、とか思う。
なんだろ。この文脈としての「ギーク」は「創造的なことをする」とか「複雑なことをする」とか「それ以外のことに苦痛を感じる」みたいなニュアンスかな。

ブログに感想を書いていて思ったのだけれど「そういう人達の処世術」とかみたいな意味合いっぽいな、とか。この本を一言で言うなら割とそれっぽい感。
最初の辺りに書かれているのが「チームワークについてどう思うか」で「誰も信じられない」とかだし。
この部分立ち読みして買ったのもあるのだけれど、割と冷静に見ると失礼だよなー、とか思う。いや確かにチームワークの思い出には苦いものが当然あるんだけれど。
そういう人に向けてるんだろーな、とか思いました。

ちなみにそういった内容エピソードとしては、チームワークの残念例とか、その対処とか、組織でこの先生きのこるには、とかとか書いてありました。
割とあるある事例紹介みたいなところもあるので、てっきり自分がギークなのかと思わせてしまう辺りも流石かもしれない。
そしてその事例に俺はこうしたぜ、的な。それこそ経験をまとめて本にしちゃいましたー、って流れなのかもしれない。

チームワーク面倒、とかって思ってしまったことある人向け本なのかもなー、とか思いつつ。

ハッカーズチャンプルーに行ってきた

2013/08/24 に ハッカーズチャンプルー なるイベントがありまして、ふらっと行ってきました。
プログラムはこんな感じ。

感想含む忘備録チックな感じで非常に長くなってしまった感。

カンファレンス

実はちょっと遅れて行きました。時計セットし忘れ。むむ。

きしださんな Java8 な発表は資料無しでブログとライブコーディングが資料な発表でした。
なんだかんだでブログにまとめてると後から役に立つのかな、とか。
して発表内容ですが、Java8 から lambda とか Optional とか入って良い感じになるよー、とのこと。内心では「それRubyだとあんなか」って感じで聞いてました。
けれど「Javaそのものは3年くらい遅くて、それがずっと続く感じだと思ってる」とのこと。そういうスタンスもあるのねー、とか思いました。

丸山さんの発表は、今までの時代とこれからの時代的なお話でした。特にWebアプリって何ぞ、みたいな感じ。印象に残ってるのは「WebPageはクライアント側のUpdateいらないよね」みたいな話。Packaged Web App は新しいモデル、みたいな感じなんだろうか。MVC的な感じとかとか。

CodeIQさんからはお菓子とか飲み物とか大量に貰いました。ごちそうさまです。
弁当もありがとうございました(これはスポンサーさんかな?)

dankogai さんはプログラミングってどう考えてるのみたいな話。FizzBuzzに焦点を当てて、一番単純なものから捻ったもの、はてはHaskellで書いたものまで見ていく、といった流れ。全編ライブコーディングでした。
ちなみにRubyの解説の時に当てられて答えられたのでちょっと満足。まとめとしては関数型は文脈に依存しないから並列にすると良い感じよねー、みたいな。というか Haskeller あまりいなかった。ってことはやっておく価値ありそうなんかなー、とか思いながら。

AWS な堀内さん、後藤さんは AWS使ってないこともあって事例とかはいまいちピンと来ず。そろそろ触れって感じでしょーか。

大石さんは相変らず時代劇な感じ。「安心を取るか安全を取るか」とか「情報はお金みたいなもの。重要だからって自社に全部置く? 普通は銀行に置かない?」みたいな話はなんか納得してました。あれくらい良い指摘ができるようになればそれこそクラウドを上司に認めさせられそうだなー、とか思いながら聞く。

PostgreSQL な永安さんは「すべき、べからずのn箇条。」nが何だったか憶えてない。というか一覧欲しい。
パラメタはデフォルトのままやめよう、とかあったのだけれど今のところデフォルトで十分動いちゃったりするので私にはまだ早い話だったかもしれない。
ただ、TLは大分「耳が痛い」的な話だったのでそのうち耳に染みるようになるのでしょうか。とりあえずバックアップ取らなきゃなー。

矢野さんな OKINAWA GIRL's lab のおはなしはガールズトークセッションと呼べば良いのかな。「腹を割って話さなきゃ」って言ってる通り、割と腹を割った話を会場でやってた印象。それを会社とかで言うと結構変わるのかなー、とか。いやまーとっくに言ってるかもしれないし、腹を割るってこのレベルじゃないのかもしれませんが。
とりあえず私としては、やっぱり話し合ってみなきゃ分からないよねー、みたいな印象を持ちました。こういう悩みとかあるよね、ってのを知ったのだけでも良かったのかもしれない。

米須 さんも相変らず。大事なことなのでn回良います。あのテンション良いと思います。
して、DevOps知らなかったので具体的には分からず。ただ、権限の切り分けは重要そうだな、と。
というか「本番で動かないでござる」が無くなるのならどうぞどうぞしてしまうかもしれない。

ビーチパーティー

なんとスポンサーさんの力によりバーベキュー無料。タダ飯。ありがとうございます。
yota さんが dankogai さんのサイン貰って doya-face してました。私は急いで来たから本を家に忘れてしまって貰えず。dankogaiさん来年サインください。
というかお話もできたのでなんかすごい。言い方アレかもしれないけれど、ブログの向こう側の存在が目の前に居る感じ。何事。
話しをしてると web application な脆弱性の話から system call な話になったり、 CPU architecture な話になったり、攻殻とか艦これが顔を覗かせたり。話題多いなー、と。
あとCodeIQな方とか Tokyo な方多かったですね。終電って何ですか。というか電車って何。
お酒もアリの場でしたけれど楽しめた感あります。
あと、 #世界の麦汁 さんが #世界の土下汁 になってました。おさけ良く分かりません。

かんそう

素敵なチャンプルーでした。
是非来年も開催して欲しいですねー。
ってな訳で皆々様方、ありがとうございました。

Monad のようで Monad じゃないものを書いてみた

最近は すごいH本読んだり とか Haskell ってたのですが Monad が謎だったので試しに書いてみました。

結論から言えば Monad 則を満たしていないので、「Monad の instance にできてしまった何か」なのですが。
ってな訳で HookMonad なるものを作ってみた話。

HookMonad

a -> a な関数と a な値を持つデータ構造を定義。
>>= で関数を適用する際に a -> a の関数を適用してから関数を適用する、ってものにしてみました。

適用してみる想定として座標を考える。名前は nonMinusPoint とかにしてみました。
座標用のデータ構造で、値が 0 以下になったら 0 にしてくれる、って代物。
「プログラマブルセミコロン」のたとえを聞いて最初に思いついたものがコレ。
毎回 「0 以下なら……」 的なロジックが必要無さそうなので良いのかなー、と。
ソースはこんな感じ。

どう処理してるのか

Hook に a -> a な f として「0 以下なら 0 にする」lambdaを渡してます。
そうして >>= で関数を適用したい時はその lambda を適用してから関数を適用させる、と。
それを単純に使うために nonMinusPoint とかって名前を付けておく。
値を操作する関数 add とか multi には 「値が 0 かどうか」的なロジックはいらない。はず。
(とは言っても nonMinusPoint を結局使うので、毎回 lambda 書いてるのとあまり変わらない気もするけれど)
そうすると、 >>= で関数を適用する分には値が 0 以上になることが保証されそう。
あと、 Maybe の「失敗するかもしれない演算」みたいに「マイナスになるかもしれない演算」があったとしても確実に 0 以上であることが保証される。
だから add とかじゃなくて「0 以上でないと使えない関数」を定義した方が良いのかも。

 

ちなみにこれはMonadじゃない

ただし前述したけれどこれは Monad 則を満たしてません。
ちなみにMonad 則は以下。

return a >>= f ≡ f a
m >>= return ≡ m
(m >>= f) >>= g ≡ m >>= (\x -> f x >>= g)

1はどうにか満たしてるはず。
2は無理。return の型を合わせるために id を使ってるので、 m >>= return すると a -> a な関数が id に変わっちゃう。
3はどうだろ。たぶん満たしてそうだけれど反例が思いつかないだけかもしれない。

さらに問題点

もともとは「数値演算をしたら non zero にする」みたいなものを作りたかったので

Hook f n >>= g = fmap f $ g n

とかにしたかった。
だけれど >>= の型は

(>>=) :: Monad m => m a -> (a -> m b) -> m b

なので、 埋め込んでる a -> a な関数を m b に fmap しようとしてダメ、って言われる。
あと HookMonad が Functor じゃないと f を数値演算後に適用できないのだけれど、 fmap の型も

fmap :: Functor f => (a -> b) -> f a -> f b

ってなってるので、 Hook (a -> a) b になっちゃってダメ。
さらに、 return に id を使ってるので、汎用性を高めるために return を使ってるようなコードだとかえって a -> a な f が id になっちゃって埋め込んでたのが消えちゃう。
完全に Monad則 の 2 がダメになっています。
ってな訳でいろいろ問題点は多し。
ただ、「演算のたんびに何かする」ことはできたので良いのかなー、とか思っています。
まー、>>= に与える関数の中でも nonMinusPoint とか書いてるから「毎回何かする」部分を毎回書いちゃってる説もありますが。
(いやでも nonMinusPoint にすることで型が Hook になるので Hook なコードを書いてたら 型チェックされる ==  非ゼロ保証 だし良いのか? うーん)

なんか良いこと

あと書いててすごいなー、と思ったこと。
この Hook ですが deriving Show してません。
どうしてかと言えば関数を持ってるから deriving だと無理。
だから getValue を定義して、値だけを取り出すようにしないと ghci で値を見られませんでした。
その getValue の中でも f を適用するようにしたので、最後の最後だけ処理後に 0 以下かどうかのチェックができてます。
あと、コメントアウトしてるのは ghci で実行してみた例なのですが、 foldl でガンガン処理していけるっぽいです。
あと途中結果を見るために scanl を使ってみたのだけれどそのままだと見られない。
scanl は計算途中の内容を List にして返すので、その List に対して fmap で getValue かけたらきちんと見られました。
ちゃんとした Functor すごいなー、とか。
あと scanl で計算結果の途中を見ると、 0 以下になるところで 0 になってるっぽい。

ってなわけで Monad のようで Monad じゃない何かを書いてみました。