JJUG Night Seminar で Project Lambda ハンズオン してきた
参加したけど、事前にひとつくらい関数型勉強しとくべきでした。
7月25日 JJUG Night Seminar ~ Project Lambda ハンズオン ~(東京都)
JJUG Java 8 Lambda ハンズオン #jjug - Togetter
事前準備
櫻庭さんのブログで書かれてる通り、この勉強会の時点で公開されているJDK8にはProject Lambdaは入っておらず、特別にパッケージングされたのが公開されていたので、それを利用。ダウンロードしてパス通すだけなので特に問題なく。
Java in the Box Annex: JJUG Project Lambda Hands-on 事前準備
Project Lambda
関数型で言われるλ式とJavaでいうLambda式は異なるものらしい。以前実装しようとされていたが凍結されたClojureは、Oracleに吸収されたときにProject Lambdaとして復活しました。しかし、これの目的は並列処理をさせてマルチコアを遊ばせないためのものです。JavaのLambda式はこれを簡単に記述する方法。具体的には、実装すべきメソッドが1つだけのインタフェース(関数型インタフェース)を実装する無名クラスの簡易記述。
ハンズオン
講座30分+ハンズオン90分の予定が、講座が80分くらいかかり、ハンズオンが40分くらいになったので、かなり押し気味に。
課題は、今までの記述によるコードを、Lambda式で書き直すというもので5つ。コードは上記資料にも書いていますが、githubから取得するのが早いでしょう。
JJUG Project Lambda Hands-on Materials · GitHub
課題1: SwingDemo
ActionListener listener = new ActionListener() {
public void actionPerformed(ActionEvent event) {
label.setText(field.getText());
}
};
を次のように書き換える。
ActionListener listener
= event -> { label.setText(field.getText()); };
課題2: FizzBuzz
for (Integer num: numbers) {
// 省略
}
を次のように書き換える。
numbers.forEach( num -> {
// 省略
});
課題3: ScoreFinderのコンストラクタ
以下を記述する。
List
students = initStudents(); Integer maxScore = students.filter( s -> s.getGradYear() == 2011 )
.map(Student::getScore)
.reduce(0, (s1, s2) -> (s1>s2) ? s1: s2);System.out.println(maxScore);
私はここで断念。課題4は課題3に似ているけど再帰で書く問題で、時間がないからすぐに解答が公開されたのですが、これを見たときの気持ちが、こんなかんじ。
Lambda使うと、もう完全に別言語にしか見えない。「パパー、敷居たかいたかーいしてー!」「合計値の計算をするなら、Lambda式で再帰を書くと早い」「きゃっきゃっ」 #jjug
— 谷本 心さん (@cero_t) 7月 25, 2012
雑感
この方と同じこと考えました。
Lambdaのハンズオンを終えて至った結論が、Scalaやってみよう!な件。
— Munenori Hirakawaさん (@hiranasu) 7月 25, 2012
私はまだScalaもやってないのだけれど、ドキュメントとしてはそろってるので、まずはScala、あるいは別の関数型言語を学習後、Project Lambdaに再チャレンジですね。InfoQに比較記事があったので、こちらも確認。
うちのマシンだとProject Lambdaは処理が遅いです。
SCMBootCamp in Tokyo 3に初参加してきた
SCMBootCampはすぐに満席になってて参加できなかったんだけど、今回は早めに気付いたので参加できました。Git/Mercurial/Bazzarとあって、どれを体験するかは抽選だったのだけれど、なんとか第一希望のGitになりました。
7月21日 SCMBootCamp in Tokyo 3 #scmbc(東京都)
SCMBootCamp in Tokyo3 #scmbc - Togetter
基調講演
@flyingfoozyさんのお話。Mercurialの本を書かれてる方だけどそれに限らず、なぜ分散バージョン管理を利用したほうが良いのか、という内容でした。履歴管理部分だけをピックアップして0〜3世代に分けてひとつづつお話してくださったので、他の人にも説明しやすい分かりやすい内容でした。具体的な例はgihyo.jpで連載していた内容で行いました。
世代差で見る履歴管理ツール入門
Mercurialではじめる分散構成管理:特集|gihyo.jp … 技術評論社
演習
演習は数名に対して講師が一人付く体制で、3セットに分けて行いました。御題はチートシートの作成。といっても、リファレンス的なもので、コマンドと簡単な説明をみんなで同じファイルに対して書いていく、というもの。
第一セットでは、masterの同じファイルに随時追加していくという必ず競合が起こるやり方でした。
+ git checkout
+ マスターブランチに戻って、 git pull してみんなの作業を取得、
+ git merge
+ 競合をエディタで解消して、 git add
の繰り返しです。第一セットはゆっくりやっていたので良いのですが、第二セットでペースを上げていくと、pullからpushまでの間に他の人がコミットしてて失敗するということが置き、再度mergeするのでコミットグラフがまるで路線図のように!
Network Graph · STAR-ZERO/necomimi · GitHub
- 第1セット終了: bdd9400f19e0bd506628977eb4c1ee21f3dc0b1a (最初のオレンジの分岐がマージしたあたり)
- 第2セット終了: 91300cb95ec0e6fd579674601a899aa8524304a9 (他のリポジトリにフォークがされる前)
こんなことにならないためにrebaseを使うわけですが、第3セットはリポジトリをフォークして、フォーク元にpull requestをする演習をしたので体験する時間もなく。かわりにスタッフの@pocketberserkerさんが「rebaseで作り直すとこうなるよ」というのを作ってくださいました。上記グラフのpocketberserkerがそうで、一本線になりました。かなり大変だったみたいですが。「これ、rebaseの学習の良い例だよねー」という声があって、全くだなあと思いました。今回の宿題ですね。
講演
各人から集めた質問をもとに、スタッフや講師によるディスカッション的な感じでした。Gitを使いたいがWindows+Eclipseをやめられない人にはMacを与えればよい、というネタ的なものからブランチ戦略まで。
このとき挙がった資料で記録したもの。
- サルでもわかるGit入門〜バージョン管理を使いこなそう〜【プロジェクト管理ツールBacklog】
- 見えないチカラ: A successful Git branching model を翻訳しました
- http://standing-shoebill.appspot.com/bzr-startup-guide/scmbc-2.html
- http://www.amazon.co.jp/dp/4798112593
A successful Git branching modelは今のプロジェクトに適用するために参考にさせてもらっています。backlogは最近だったかな。チュートリアルもあるので、教材としてもかなり良いですね。
懇親会
他の用があったので参加できず。残念。だれかまとめてくれないかな。
念願のGradleトーキョーに参加した
Gradleトーキョー に参加しました。以前少人数で行われた 第一回Gradle勉強会 に参加したかったのに少人数で打ち切っていたので、念願の勉強会でした。
2012/07/18 Gradleトーキョー #jggug #gradle_ja #gradle_tokyo - Togetter
http://www.ustream.tv/channel/jggug#utm_campaign=togetter.com&utm_source=9324221&utm_medium=social
今回の勉強会はGradleメジャーバージョン・リリース記念ということで、 @mike_neck さん無双の会。開始まで何をするのか何も公開されてませんでしたが、かなりの人数がそろいました。実際の内容は、@mike_neckさんのやられてきたことを公開して、これからみんなで切磋琢磨していきましょう、という前回の勉強会(第一回Gradle勉強会)の同様の趣旨の拡大版だと感じました。なので同僚のMr.Kに参加してもらいたかったけど、今日は無理の様子だったので、一人で参加しました。
Gradle超入門
前回の勉強会(第一回Gradle勉強会)の資料を元に、みんなでコーディング!
Gradle入門
・・・なのだけど、みんな出来てたのかな?MavenRepositoryからライブラリを取得するところで止まってる人がちらほらいましたね。私は自前のemobileを利用していたので問題なく取得できていたのですが。けど、かなり前に公開された資料だったので、みんな試してるよね?無問題。
gradle-wrapper … 誰か教えて…
「bluepapa32 さんのブログみてね」以上・・・代わりに @toru_inoue さんが発表してくれました。今日の説明では、
- インストールしなくてもGradleが使える!
- 他の人の環境を整えるために活用できる!
というものでした。確かに、今の仕事のでも同僚がやってくれたのがそれでした。各人のeclipseプロジェクトのクラスパスをMavenRepositoryから最新版を取得したものを設定するとか、Jenkinsで利用するGradleやライブラリの設定とか。中身をちゃんと見てないので、明日見ます。
Gradleカスタムプラグインを書こう
@mike_nekoさんがこちらのブログで記述してますね。
Gradle カスタムプラグイン作ってみた
現在、.gitignoreを生成するためのプラグインを作っているそうです。確かにあれをいちいち作るのは面倒だし、私はeclipseを使っているのでeclipseのGroovyPluginをいじったほうが良いのかなあ/大変そうだなあ、と思って何もしてなくて、gradleプラグインとして作るっていうのは成る程と思いました。
今日の勉強会でコーディングされてたのはちょっと違くて、画面の切り替えが早くてよく分からなかったのですが、gradleのユーザーガイドに書いてあるやつかな?
第51章 カスタムプラグインの作成(@literaliceさんが訳してくれたドキュメント)
@bluepapa32さんもブログで書かれているので、ここら辺を参考にしながら一度チャレンジしてみますか。
欄外
懇親会はなかったけど、有志でやってたみたい。@mike_nekoさんが「お金ないけど」って言ってたけど、みんなから参加費として100円づつ貰えば十分なんじゃないかなあと思った。それくらい人いた。
あるのかどうか分からないけど、次の勉強会までには色々やっておきたいな。最近あんまりGradle触れてない。
第二回ペアプロ合コンに参加してしまった
ネタ&腕試しのつもりで申し込んだのに、選考通過したので参加しました。
男性枠: http://connpass.com/event/631/
女性枠: http://connpass.com/event/605/
togetter: http://togetter.com/li/338429
事前話
第一回目のときは「なにこれ?」と静観してました。申し込みのときに女性に対して男性の申し込みが3〜4倍あり、どういう選考基準で選んでるのかと思ってましたが、今回は言語が指定され、それに関する御題によって、選考するというものでした。御題は表示テキストをjQueryを使って書き換えるもので、5つありました。
jQueryは今まで使ったことなかったのですがJavascript自体は分かるので、そこまで大した問題でもなく、ぐぐれば分かる程度の問題でした。けど、それだけみんなとの差がつかないんじゃないかと思い、少しだけ手を加えることにしました。私がやったのは、要素追加の無限性の排除のみ。他にもやろうかと思ったけど、出題から提出期限が短いし、考えるのも面倒だったのでやめました。それでも選考通過したので、良かったのでしょう。
通過後にやっていたのは、jQueryの勉強です。当日の御題は、昔よくあったホームページを今風に作り直すというもので、御題のページは女性のみに事前に伝えて考えてきてもらう、というものだったので、女性に求められたものをすぐに表現できるようになっておこうかと思いました。が、結局jQueryの本を一通り読んだだけで何もせず、ペアプロなんだから当日ぐぐりながら一緒にやればいいんじゃないかと自分を思い込ませることにしました。
当日は1セット90分で、2セット行います。15年くらい前にあったFrameタグやTableタグをふんだんに使ったページを今風に作り直すというもので、2セット目は1セット目の続きでも良いし、最初から作り直しても良いというものでした。
最初に軽く挨拶して、お互いの技術力を確認し合ってから実装。お互い勉強段階もあって、どうするか悩んだけど、とりあえず、FrameやTableはすべて排除して、divに置き換え。その後、divの配置調整を行いました。スライド文字があると、横並びがうまく出来ないんですね。細かいトラップに翻弄されました。その後、メニューを格好良くしようとしてぐぐり、ここのサイトで紹介されてるコードを利用しました。
これ、すごく面白くて、メニューが上下にびよんびよん動くから、下の本文が上下移動するし、メニューをaタグで記述してたから、メニューをマウスでクリックするのが大変だという大きな欠陥を埋め込んでしまいました。まあ、そこは直しましたけど。そんなわけであっという間に終わりました。
休憩後、別の方とペアになり、第2セットが始まりました。最初から作り直そうとしたのですが、まずFrameとTableを削除したいよねって話になり、じゃあ先ほどの続きからやりましょう、ということになりました。今回のお相手はある程度自分で書かれてる方で私より大分詳しい。twitterで会話をしたことがあった方なので挨拶も早々に、変更イメージを出してもらって、それをぐぐりながら実装するというスタイルで進めました。
ここで利用したのは、BackstretchプラグインとCSSによる白抜き文字表現。Backstretchはウインドウのサイズに合わせて背景画像を拡大縮小してくれるプラグインで、画像のスライドショーもやってくれるそうなのですが、それはやめました。
Backstretch
FirefoxでもCSSで縁取り文字を表示する方法
なんか、色々やってたら、先ほどのメニューがうまく動かず・・・
本番
第一回経験者曰く、ペアプロはオマケで、その後の懇親会が本番らしいです。まあ、合コンですからね。といっても、他の人を呟きを見る限り、そうでもないような?私は男女でペアプロするだけだと思ってたし、体調も悪かったので、軽く飲食して早々に帰宅してしまいました。ここらへんの面白話はきっと他の参加者が書いてくれるでしょう。それを期待して。
余談
途中、スタッフやスポンサーの方から色んなお話がありました。
コロプラさんからSPECというWEBクリエイター採用のための試験制度があり、就業とは無関係に参加できるから挑戦してね、といわれました。マスコットキャラクターのクマやMacがもらえるそうです。
また、Forkwellという技術者のスキルを共有するサイトを聞きました。こういうのあるんですね。後でじっくり見ます。
懇親会の時にスタッフの方から、今回の選考基準(何で私が通過したのか)とか、次回使用する言語について聞きましたが、これはブログでは内緒。次回はどうするかなあ。もっと積極的にお話しに行くべきだったかもしれないが、今日の体調は最悪だったので、そんな気力も体力もなかった。残念。
DevOps Days Tokyo 2012
DevOps Days Tokyo 2012[日本語募集枠] - connpass に参加しました。
UStream: http://www.ustream.tv/user/opencloudcampus
Facabook: DevOps Days Tokyo 2012 - ホーム | Facebook
togetter: DevOps Days Tokyo 2012 - Togetter
※togetterは自分でまとめたので漏れがいっぱいあるかもしれません。
前書き
少し前にALMとDevOpsについて学び、興味を持っていました。私の立場としてはDevです。仕事で継続的デリバリー(に近い)環境を構築するため、他のところはどうしているのか知るために参加しました。
私の考えを言うと、DevelopmentとOperationが相互関係になればよいというのは昔からあったけど、いきなりそれをやるには問題が大きすぎるから、少しづつ活動を続けてきて、ようやくそのレベルが実現可能になってきたと捉えています。
長い時間かけて作って、ようやくリリースしたら、使いものにならないといわれた/不具合・要求(欲求)違いがたくさんあった−そういうのがあると新規開発・改修の作業が削られてしまう(あるいは残業がとんでもなく増える)。あるいはそれはまだ良いほうで、「あいつらが作るシステムは信用できないから」なんて後ろ指をさされてしまうかもしれません。細かい意識・価値共有ができていれば、そんなことは回避できていただろうに・・・
では、細かい意識・価値共有はどうすればできるでしょうか。それはすばやいリリースができることです。リリースしたものを使ってもらって、「ここ、いつもミスするからこういう風にできるといいんだけど」とか「こういうこともしたいんだけど」とか言われたときに「分かりました。来月のリリースに含めます」と言うと、おそらく言った本人は忘れてます。言った言葉は覚えていても、そのときの気持ちは別のものになっているでしょう。一応ものが出来てるから相手も了承してくれるでしょうが、「う〜ん、こうではないんだけどな」という気持ちが残っているかもしれません(あるいは、言った時点の要求・欲求は満たしていても、リリース後の時点ではもっと別の要求・欲求が生まれていて、それをごちゃ混ぜにしているかもしれません)。そのため、なるべく早い時期に意識共有・確認できる体制にして、それを運用することが苦にならない環境を構築する必要があります。
これを実現するために、ITSやCIなどのツールがあります。OSSで優秀なものが増えたため、それらをサポートできるエンジニアがいれば問題ありません。まずはDevelopmentがOperationや顧客からの声を受け止める環境を作ること。そして、それを継続的に行う環境を作ることが今後課題となります。
DevOpsって
イベント前日に「DevOpsの定義ないよね」ってことで、「運を開く=開運にしよう」ということになったそうです。なんだかよく分かりません。
イメージとしては、DevelopmentとOperationを分けていたことが、アイデアがお金になるまでの(時間などの)障害となっていたので、この障害をとっぱらってしおう、というものです。
DevOpsの考えは、改善を続ける、無駄をなくす、ムラをなくす、無理をなくす、というものです。DevelopmentとOperationのサイクルを作るのだから、何度やっても苦にならないものでなければならず、自動化する必要があります。自動化できないのであれば、業務を最適化して、自動化できる部分を模索します。この考えはJenkinsと同じです。
DevOpsの考えをなぞるには、THE LEAN STARTUP(邦訳:リーンスタートアップ)が参考になるそうです。また、これよりも先に The Four Steps to the Epiphany(邦訳:アントレプレナーの教科書)を読むことを勧められました。
ジョン氏のスライド: Devopsdays Tokyo 2012
全体的に
Chefの話が多かった気がします。Operationの自動化ですね。スクリプト=ドキュメントなので、運用の変化もバージョン管理することができます。
並河さんのお話: 「DevOps Days Tokyo 2012」でChefの話をしてきたので資料を公開します - 元RX-7乗りの適当な日々
cockbookの日本語訳: http://wiki.opscode.com/pages/viewpage.action?pageId=24019581
オープンスペース
CIについてのグループに参加しました。DevOps的に、アプリのCIではなく、インフラのCIに焦点を当てたので、やっぱりchefの話が出ました。じゃあ、サーバーの設定や設定、連携など、インフラがきちんと動くか確認しているか、という話になりました。最初の構築は確認されているので良いけど、その後書き換えられたときはどうか。shellやzabbixでチェックしているとの話もありました。shinagawa.redmine第三回でも同じような話がありましたね。
継続的インテグレーション、継続的デリバリのように、継続的チェック(CC)が必要で、どうすればいいか考えていかないとね、が総括です。
その他
- Chefユーザーグループ発足!
- CloudだとモニタリングツールはNagiosやZabbixより、 SENSU のほうが良いらしい
- http://rundeck.org/:titl=RUNDECK というプロセス自動化ツールが手軽に使えて便利そうだと思った
所感
DevOps体制を作るにはAgile, Cloudなどを受け入れていないと難しいのではないだろうかと思いました。中途半端にやると部分コストがかかってしまいそうです(Private Cloudばかりにするとか)。Agileって言っちゃうと色んなことを含んでしまうのですが、DevelopmentとOperation間以前に、Development内で体制が出来ているかということです。ここでいうDevelopmentは例えばProgrammerやTester、別のチームのProgramemrなど。責任の押し付け合いや部署のごたごたを出してくるような体制のところはまず無理でしょう。顧客に強力してもらえないプロジェクトだと困難でしょう。
DevOpsはサービスの提供・運用を行う上で良い体制だと思うので、確かに世界的に流行するかもしれませんが、体制のないAgile開発、なかなかに高価なCloud環境の日本(の一部、けれども大きな存在)でどうやれば良いのか、考えることは多そうです。
G*ワークショップが第21回とナンバリングされててた
G*ワークショップ に参加しました。前回、「もうナンバリングはやめようかと思ってます」と言ってましたが、ナンバリングされてました。
まとめブログ
- 第21回 G*ワークショップ に参加してきた #jggug - Diary of absj31 @shinyaa31さん
- 第21回 G*ワークショップ に参加してきた #jggug - みちしるべ @orange_cloverさん
お二方のブログがすばらしいので特に加筆することもなく。
きょんさんを拝見したのは初めてです。発表準備でPCにプロジェクタのコードをつけるように、頭にうさみみをつけるんですね。
後半のテスト戦略に関する資料(マインドマップ?)を削除してしまったから即興でやられてましたが、これが特に良かったと思います。完成した資料を見せてしゃべるより、しゃべりながらマインドマップを完成させていく様は、きょんさんの思考の流れを表現されていると感じました(マインドマップなだけにね)。プログラミングでいうと、ライブコーディングに近いかな。
Gradleはそろそろどういうものか分かってる人が増えてきているだろうから、手を動かすワークショップとかできるといいかもしれませんね。
私たちは英語のままでも大丈夫でしょうけど、「日本語ドキュメントがないと」っていう人たちに広めるためには、やっぱり日本語ドキュメントがあるとよいですね。
shinagawa.redmine第三回にも参加してしまった
shinagawa.redmine第三回に参加しました。今のところ、皆勤賞?
- セッション1 「Redmine 2.0リリース」@marutosijp
- セッション2 「他システムからの移行事例」 @tech_machii
- セッション3 「定量的プロジェクト管理ツールのデモ」@yohwada
非公式デモサイト→ http://ipf.redmine.jp/redmine
情報ページ→ http://sec.ipa.go.jp/tool/ipf/index.html
- セッション4 「Redmine.JPの中の話」@g_maeda
- ワークショップ
- LT1「Vim plugin for Redmine」 @basyura
- セッション5 「サーバ管理と三種の神器」 @tkusukawa
Redmine2.0
丁度この勉強会の週にリリースされました。バージョンアップ作業内容と注意したこととかについてのお話でした。そんなに詳しくないので詳細について言及できないのですが、分散バージョン管理の運用例として参考になりました。rebase便利!
Redmine1.4はRuby1.9対応したけど、Rails3対応してないので、環境によって多少不具合が確認されているようです。もしRedmine1.3以前を利用しているなら、2.0にバージョンアップしたほうが品質が保証できるそうです。
他システムからの移行事例
LotusからRedmineに移行した事例。Lotusの情報をあわせるためにデータを作ったり、Redmineを拡張したり、のお話。私はRedmine内のあるプロジェクトのデータを他のプロジェクトに振り分けるために調べた程度ですが、データ構造みると確かによく分かりますね。
定量的プロジェクト管理ツールのデモ
以前聞いたとき、「えっ?IPAがそういうことするの?」って半信半疑だったけど、もうリリースされてたみたいです。今までOSSだからとかの理由で拒んでる人に対する突破口になると良いのですが。
Redmine.JPの中の話
いつもお世話になってるサイトの中の人のお話。Redmineの日本語コミッターでもあるそうです。「ユーザがいいですか?ユーザーがいいですか?」は悩むところですね。
Redmineを社内に構築するとき、入門Redmineを買いましたが、必要なライブラリやgem(のバージョン)がよくわからず苦労しました。悪戦苦闘の後、なんとか構築できたと思ったら第二版が出て、その部分が大幅追記されてたので嬉しくなって即買っちゃったのは良い思い出。
ワークショップ
サーバ管理と三種の神器