Haskell 勉強会をやってみた

2014/03/26(Wed) - 2014/03/28(Fri) に Haskell 勉強会 in ie なるイベントをやってみました。
資料とかはこの辺。

Haskell 気になっている人達ですごいH本を読んでみよう、というイベントです。
Haskell は個性的っぽいので、どんな言語なのか知ってみよう、という趣旨でした。
加えて、 Haskell って何、勉強会って何するの、って人達もターゲットにしていて、勉強会とか良く分からなくても良いから来よう、というスタンスで人を集めてたりもしました。

参加者側の話

参加者は基本的にすごいH本を読んでもらって、分からないところを相談するなり、尋ねてもらうなり、というスタイルでした。

Haskell についてとか思ったこととか、参加者の感想とか

• Haskell すごい、って感想は来る
• 短かくかけるとか
• 綺麗とか
• でもHaskell何に使うの、という質問も飛んでくる
• 便利なのは分かった
• が、何に使うの
• IO が遠いとか(8章で Hello World だから)
• 型が便利
• 質問されたら「まず型を見よう」って言ってた
• で、だいたいはそれで説明可能だった
• 型便利

 

主催側の話

進め方としては、割といろいろやっている人とか上級生な人を上級者、Haskell に触ったことが無いとか下級生な人を初心者にして、ペアプロチックなペア読みをしてみよう、ってなアイディアを実行してみました。


実際やってみたペア読みについて

• 本が読める人どうしをペアにするともくもくになる
• まったく分かんない、って人をペアにすると良いのかも
• ペアによって進め方を自由にしていたので、進める速度も進め方も違う
• 他人がいる感はあるので、強制的に読むことができる

といった感じ。
なので新入生とかに向けてやると良いのかもしれない。

あと主催側で思ったこととか

• 時間の枠は割と可変にしてたのは良かった
• 遅刻対策とか
• 人によって来る時間が違うとか
• でも、時間長すぎるの結構きつい
• 10:00 - 18:00 を3日は結構しんどかった
• 午後だけとかにした方が良いのかな
• でも3日かけて8章読むのも結構厳しめだったし、勉強会でやることを考えた方が良いのかも。
• 短かいスパンでだーっとやる方向と、長いスパンで続ける方向な勉強会があるしなー、すごいH本はどっち向きかなー、とか
• 本を読むのは長い方が良いんかな、とか。

感想

Haskell おもしろいなー、って言ってくれてる人もいたのでそれで良いかな、と。
元々、初心者な人達の興味を広げるために、って趣旨だったので。
ただ、上級者の人達はもっと具体的に何ができるの、とかの話も気になると思うので、そこの解答は必要そう。

競技プログラマが知るべき97のこと を読んだ

最近 @_simanman さんと @kanpe777 さんと #ie_procon なる競技プログラミング勉強会をしているのですが、そこで紹介された薄い本。
競技プログラミングに関する TIPS 本です。
kanpe777 さんから借りて読みました。


印象に残っているのは

• 競技プログラミングはネトゲである
• float ではなく double を使う
• 定数倍高速化はムダ
• 100, 300, 600, 1000
• コーディング規約
• コードの綺麗さ
• 絨毯爆撃
• Editor な話で Vim が無い
• 摂動
• 自作ライブラリ、他人の自作ライブラリ
• 煩雑なデータ構造へのアクセサ

といった感じでしょうか。



それぞれについてちょっとコメントすると

競技プログラミングはネトゲである

• みんなが集まってクエスト(問題)を解いていくから、と。なんかそれっぽい。

float ではなく double を使う

• 精度の関係で double 安定らしいです。

定数倍高速化はムダ

• これはちょっと耳が痛い話。 
• 初心者がやりがちらしい話らしくて、定数倍程度のちまちました改善は基本的にムダらしい。 
• 計算量を見直すレベルじゃないとダメだとか。

100, 300, 600, 1000

• 競技プログラマには解いた問題によって実力の壁があるんだとか。 
• それが 100, 300, 600, 1000 らしくて、すごい方々は1000とか解いているらしい。
• 私は100も解いてない。うーむ。 

 

コーディング規約

コードの綺麗さ

• 競技プログラミングのコードは基本的に書いて終わりだから、綺麗さをどうしようかという話。 
• 競技プログラマのコードは汚いんじゃないか、みたいなイメージもあったりなんだりらしいけれど、競技のコードとそれ以外のコードは分けよう、とか。 
• あと、チーム戦なら競技でもちゃんと書いた方が良いし、自分のためにもちゃんと書こう、みたいな。

絨毯爆撃

• これは知らなかった。というかその発想は無かった。
• 撃墜フェーズで良いコーナケースを思い付いたら、それでひたすらに爆撃していくらしい。
• 大量得点 or 大量失点 の大博打らしいです。

Editor な話で Vim が無い

• 補完の関係では Visuatl Studio, Eclipse とか、構文チェックでは Eclipse, Visual Studio, Emacs + flymake とかが紹介されてました。 
• Vim も Makefile 書けば quickfix に syntax error 残るし、 quickrun とか quickrun + watchdogs とか syntastics とか入れたら捗りそうなのになー、とかって私見。

摂動

• 実数を扱う時には誤差を考慮したりするのだとか。知らない世界でした。

自作ライブラリ、他人の自作ライブラリ

• 競技で頻繁に使うたコードはライブラリにしたりするのだとか。
• 他人のライブラリと比較したり自分なりのアレンジを作ったりなんだりするらしい。

煩雑なデータ構造へのアクセサ

• これは良いなと思った。
• クラスを作るようなサイズで無い(とか時間が無い)構造体を定義する時とかに、それにアクセスするためだけのメソッドを定義する、というもの。
• triple の変わりの pair pair だと hoge.first.first とかになって分かりづらいので accessor(my_triple hoge) { return hoge.first.first } とか      

他にもいろいろありましたがこんなところで。
細かい tips もあったりしたので、簡単に手に入るなら手元の置いておいても良いのかな、とか思いました。

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 (というかバージョン管理する人)が増えると良いなー、とか思いながらかんそーおしまい。

Cloud on the BEACH 2013 in 沖縄 へ行ってきた

Cloud on the BEACH 2013 in 沖縄 に行ってきました。

昼の部だけの参加で、昼からのビーパとか、前日あったらしい前夜祭とかは行ってないです。

AWSとかは使ったことがなくて、とりあず見に行ってみる、くらいの感じでした。
なんというかこういった関係の勉強会(?)に参加するのは初なので、その所感もいろいろ。

AWSについて聞いた印象をまとめると

• ポチるだけでインスタンスが立ち上がる
• だから場合によって増やしたり減らしたりとかも余裕
• ストレージだったりサーバだったりロードバランサだったりDBだったり、いろんなサービスがある

といった感じ。

なんというか、お手軽にいろいろ組み合せられる、ってイメージなのでレゴとかそういった印象がふと。

あと、お手軽すぎてサーバ構築する経験とか、運用経験が無くなるんじゃないか、と古い人間みたいな思想が思い浮かんだのですが

• ビジネスにとって、自社で受けもつにはリスクだったりする
• コストもかかるし
• 誰がメンテするのか
• 動いてるのが当然って言われて、何かあったら怒られちゃう

みたいな話もあって、ビジネスの面からすると自分で運用するのは割と悪い点が目立つ様子。

ただ、自分でやった経験が無いのも問題かも、という視点もあって、

• 教育的な意味合いでは一度は自分で構築する経験はしてよ
• 構築よりも、運用する方が大変なので運用する経験とかもして
• 会社はお金はあっても時間は無かったりするし、そういうのはクラウドで担保してるってこと

 とかって話もあるみたいです。
そういう意味ではC言語とかとLL言語にまつわる話っぽくも見えてきましたし、学校教育が実践で役にほげほげみたいな話にも見えてきましたが閑話休題。

そういうものも含めて、一番印象に残ったのは

作るのは楽しいから、作っちゃう人は多い。
けれど、その時間とかコストとかメンテとかを考えると、 作るんじゃなくて使う方が良い場合もある。
そういうところを合理的に判断して、どこまで作ってどこまで作った方が良いか判断しよう。

みたいな話でした。
自分で運用した方が良いんじゃ、って言い出しかけてた身としては耳が痛いなー、と。
サーバを自前で運用しないと知識付かない、っては言うけれど、OSとかってさも当然のようにあるもの使ってるでしょ?クラウドとは言ってもそれがインフラになっただけで、一部をアウトソースしてるだけだよね、と。

「つまりどの層で価値を創出するかだよね」
みたいな話も伺いました。
確かに非常に合理的だなー、と思わざるを得ない。

なんというか、みなさん大人だなー、といった印象を受けた勉強会(?)でした。まる。

ひさびさに Okinawa.rb Meet Up に行ってきた

ひさびさに Okinawa.rb Meet Up に行ってきました。

ブログに書くまでが勉強会らしいので書いてみます。

@_siman_ さんについてってひさびさにギー沖へ。
ひさびさすぎてボケーっとしてたら _siman_ さんが AtCoder の D問題難しいですよねみたいなことを@tompng さんとしてたので横で考えて唸ってました。唸るだけで全然分からない。

その後くらいから@kimihito_ さんが discourse のソース読もうぜー、してたので読んでるのを眺めてました。
@hanachin_ さんがテレビにMBA繋いでソース解説。 いつの間にかsubl使いに。あとdivvy。

discourceのソースが膨大だったので Gem 覗いたり、Chrome の Developer Tools で要素とかnetwork でアクセスが飛んでる URL から method 検索したりでいろいろ見たこと無い操作多し。WebWebしい感じ。

あとは @naopontan さんが Okinawa.rb in 北谷 的なやつでやったペアプロなあみだくじ 読みとか。ペンさんのデバッグがマッハ。

ペンさんといえばjsでそれっぽい背景を生成するの作ったよー、ってことでそれの解説をきみひとさんにしてるのを横で聞いてたり。数学ー。

ちなみにそのあと、あみだくじの実装が思い浮かんだのでついカッとなって実装して今では公開している 。

とりあえず一言まとめ

• siman さんが競技プログラマ
• はなちんさんが Gem master
• ペンさんがマッハ 
• きみひとさんがくるくるしててなんかソース読もう読もうしてる
• うあー、数学かー

んで、RubyなTipsということで正規表現のキャプチャをそのまま変数に入れたりできる方法をはなちんさんから紹介されるなど。
/(?<variable>< regexp>/ みたいな感じ。テキトーに書いた例題はこんな感じ。
なんか ?<> は String の #{} みたいな感じで読むと良いのかな。
あと、和暦西暦変換で H とか M とかで変換できるよ、みたいなのもあるらしいです。



それと、来週木曜から ryudai.rb やる、ということで偵察に来てた意味合いもあったのですけれどテレビ見てわいわいしてた感じ。なんかWebWebしい系多かった。
個人的には割と Rails or Ruby なら Ruby の方やってみようかなー、といった感じなので偵察失敗。Web分からないだけとも言う。
スパイは「偵察しに来た」とは言っちゃいけないなー。
ちなみに「良い本ありませんか」の答えは「Land of Lisp」でした。Lispかー。

さて意外と長くなったしリンク多いな。
blogger横幅大きくないかなー、どこで設定するのだろ。

とりあえずひさびさの Okinawa.rb はこんな感じでした、と。