情熱プログラマーを読んでやる気が出たという話。

勉強 読書

情熱プログラマー 読んだ。
「ソフトウエア開発者の幸せな生き方」という副題の通りの内容で、ただ単にコードを書くだけじゃなくて、いい環境でコードが書けるようなプログラマになろうというお話。
お題に沿った数ページのコラム？が続く形式なので、最近お疲れ気味で読書離れしていた私にはかなりよかった。
電車で読める位薄いですし。
かなり刺さる言葉が多かったのでメモしてみる。
読んだことでやる気も出てきたし、幸せに生きれるように頑張りすぎない程度に頑張るぞー。

メモ

  • 勤務先が属している業界の業界紙を読んでみる。
    • 社内のどこかにバックナンバーが、転がっていたりする
  • スペシャリストになる。
    • 書いたコードがコンパイルされてコンピュータが読めるようになる変換手順とか、何故動くのかの原理とか。
  • ベンダなんかどこだろうと関係ない、僕はシステムの設計方法を知ってるんだ！
  • 情熱を持てる仕事を見つける。
  • 「なぜ」、「どうして」を考える。ウィザードが何をしているか。そのコマンドは何をしてくれるのか。
  • ビジネスの仕組みを知る。
    • お金の流れ、どうやって利益を生み出すのか、生み出しているのか。
    • ビジネスの基本に関する本を読む。
    • 簿記の資格は取っとけとか言うし、お金の流れは知っとくべき。
  • 師匠を探す。
    • これは大事な気がする。
    • 私みたいに複数の師匠と出会えるのは幸せな事。
  • 師匠になる。
    • これは全然ダメ。
    • ずーっと一人なので業務上で新人に教えた事すらない。
    • コミュニティとかもあげられてるけど全然かな。
    • そもそもコミュニティとかで恩恵を受けたなら返さなきゃいかんよね。
  • ミュージシャンはステージの上では練習しない。
  • 自分が何者か。
    • ○○社の山pである以前にプログラマの山pであるのではないか。
  • 切迫感があれば生産性は簡単に2倍3倍になる。
    • そして、切迫感は自分で演出してもよい。
  • もっと仕事を楽しくできないかを考える。
  • できないことは「できない」とはっきり言う。
    • わからないことは「わかりません」とはっきり言う。
    • これは意識している。恥はかきすてだし、いくらでもかくべき。
  • あわてるな。
    • 起きた災難が自分自身や自信のキャリアに永続的な大打撃を与えることなんて滅多にない。
    • 自分のあわてっぷりを笑う。滑稽じゃないか。
    • そのまま第三者の目で状況を眺める。
  • 自分自身を売り込む。
    • 凄い事をした、凄いものを持っている。とアピールするべき。
    • 誰も見ていなければ、誰も知らなければ意味がないし、評価される訳が無い。
  • 説明できることがわかってもらうための第一歩。
    • わかりやすい文章を書こう。
    • そのためには日々少しずつでも文章を書く。
    • そして、それを批判的な目で分析する。
  • 自分の書いたソフトウェアに依存している会社があったら、どれだけ自分が重宝されるか。
  • コネを作る。
    • いい意味では使われにくいが、人は認められるのが好きだし、関心のある話題について語るのが好き。
    • どんな凄い人でも他人とのやり取りを好むことに変わりはない。
    • 人脈を作るために必要なのは謙虚さを少しだけ抑えること。
  • 既に時代遅れ。
    • 昨日の波の最前線に立っていても次の波には既に乗り遅れてる。
  • 尊敬できる人物、学びたいと思う人物に直接会う機会を探して話しかけてみる。
    • 気まずくてもやってみる。
    • むしろ気まずいなら尚更やってみるほうが良い。

Excelみたいな表を作れるjQueryプラグインHandsontableを使ってみた。

Javascript Excel

概要

画面上にExcelみたいななテーブルを作りたかったのでHandsontableを使ってみたのでメモ。

Handsontableとは、Excelみたいなテーブルが作れちゃうjQueryプラグイン。

  • Excelからのコピペ、セルの右下をドラッグでコピペ、行削除、セルの追加、UNDO、REDOとか色々できる。
    • Validationとかもできるみたい。
  • 色々できるけど設定で色々変更可能なのが嬉しい。
  • 色々変更可能だと設定がわからなくてうんざりしそうだけど、Wikiが見やすい上に充実してて私みたいなアンチ英語みたいな人でも細かく設定可能。
  • GitHubで☆3000↑と人気もあるみたい

導入方法

導入は簡単。

  1. jQuery、Handsontableのjsとcssを読み込む
  2. オプション設定
  3. データ設定
  4. 表示

Sampleページ（消えていたら↓をコピペしてください）

<!DOCTYPE html>
<html>
<head>
  <meta charset="utf-8">
  <title>Handsontable Sample</title>
  <link href="//cdnjs.cloudflare.com/ajax/libs/jquery-handsontable/0.10.2/jquery.handsontable.full.css" rel="stylesheet" type="text/css"/>
  <script src="//code.jquery.com/jquery-1.11.0.min.js"></script>
  <script src="//cdnjs.cloudflare.com/ajax/libs/jquery-handsontable/0.10.2/jquery.handsontable.full.min.js"></script>
  <script type="text/javascript">
    $(
      function() {
        var data = [
          ["", "Maserati", "Mazda", "Mercedes", "Mini", "Mitsubishi"],
          ["2009", 0, 2941, 4303, 354, 5814],
          ["2010", 5, 2905, 2867, 412, 5284],
          ["2011", 4, 2517, 4822, 552, 6127],
          ["2012", 2, 2422, 5399, 776, 4151]
        ];
        $('#example').handsontable({
          data: data,
          minSpareRows: 1,
          colHeaders: true,
          contextMenu: true
        });
      }
    );
  </script>
</head>
<body>
  <div id="example"></div>
</body>
</html>

メソッドの使い方。

↑で書いたメソッドページの一番上に書いてありますが、読み飛ばして困ったのでメモ。

// 指定行のデータを取得（配列）
$('#example').handsontable('getDataAtRow',0);

こんな感じで、handsontableの引数として文字列で指定します。メソッドの引数は続けて設定。

ちょっと困ったこと

  • 日本語で値を設定したら初期表示時のカラムサイズがうまく設定されない。
    • 一度入力するといい感じに設定されるんですが。。。
    • 明示的にカラムサイズ調節行えそうですがみつからなかったので私はcolWidthsオプションを指定して、サイズを固定しちゃいました。
colWidths: [80, 120, 80, 80, 80, 80, 80, 80],

社内で外部勉強会に人を誘う方法を知りたい

日記 勉強会

最近、割りと外部勉強会に参加しています。
その中で思うことは、「外部勉強会は楽しい！」ということ。
で、私だけで楽しむのもどうかと思うので社内の人とか誘ってみる訳ですが、中々一緒に参加できません。

社内でJava使っているので、Groovyとか見て触ってもらえば一発でハマると思いますし、
この間のGitHubKaigiに参加した時とかに思うわけですよ。
社内の人と一緒に来て、「こういう風にしたいよね。」とか、「あのプロジェクトに使えるね」とか言いたいわけですよ！

うちの会社は意識高い（笑）的な感じではないですが、こういうのに興味はあるけど、行くチャンスもないし、どうやって行くのかわからない。的な人が多いと思うので、結構来てくれそうなんですよ。
でも中々うまくいかない。

↓のような感じでメールも送ったりしてるんですが。

ってここまで書いて思ったのは、個人に向けて言ってないなと。
「○○さん行きましょう！」って言ってないなと。

あれですよね。
人が倒れてる時に、「誰か助けて！」って言うより「そこの赤い服着てるお兄さん助けて！」って個人に言うと効果がある。って奴ですよね。
後、参加後にこんなんやった、楽しかったメールも出してるんですけど、それも何らかの事話す時に混ぜ込んだ方がいいのかな。
「この間の○○で知ったんですけど、××は超便利っすよ！」とか？

あ、勿論全員が全員行くことはないと思いますし、勉強会なんかより大事なものは山のようにあります。
ただ、参加して得られるものは多いと思いますし、逆に参加しない事で得られないものって多いと思うんですよ。

みんな、勉強会行こうぜ！
とりあえず、2014/06/20にGroovyの勉強会あるから行こうぜ！

今日送ったメール晒してみる

各位

山pです。

世間ではiOSガー、Swiftガーとか言っていますが、そんな中GroovyがAndroidサポートを発表しました。
「GR8Conf Europe 2014」（http://gr8conf.eu ）とかいうイベントで発表されたらしいです。
（英語恐怖症なのでよくわからないですが、アイコン見るとG*系のイベントみたいです）

AndroidはJavaじゃないのでそのままじゃ動かなかったのです。（OracleとGoogleが訴訟とかやりあっていたりします。）
Groovyはどうなるのかなぁ？とか思っていましたが、とうとうサポートするみたいです。

そんな大注目の中、2014/06/20（金）にJGGUG（日本 Grails/Groovy ユーザーグループ）が勉強会やるみたいなので行きましょう！
しかも今回はLT大会なので、Groovyならこんな事もできる！と感動できるはずです。
今のところAndroidのLTは予定になりですが、Twitter上で振られてる人がいるので、必ず誰かやります。

■日程
2014-06-20（金）
19:00 - 21:00 
品川

■詳細
わいわいGroovy 〜 教えてG*小ネタ大会 - JGGUG G*ワークショップZ Jun 2014
http://jggug.doorkeeper.jp/events/11365

■参考URL
Groovy on Android
https://speakerdeck.com/melix/groovy-on-android

Groovy on Androidのサンプルを動かす
http://hotchemi.hateblo.jp/entry/2014/06/05/081330

groovyでAndroidアプリを開発
http://qiita.com/epy0n0ff/items/76a18a3e99041bf75e6f

Groovy on Androidのサンプルを動かす
http://qiita.com/hotchemi/items/b29c70168911b793394b

iOSのSwiftとAndroidのGroovy 
http://rejasupotaro.github.io/2014/06/05/49.html

※Swift程じゃないですが、Groovyも1日でこれだけ記事が書かれるほど人気あるんですよー

以上、よろしくお願い致します

GitHubKaigiに参加してきました。#githubkaigi

Git 勉強会

去る2014/06/01（日）にGitHubKaigiに参加してきました。
貰ったもの↓ステッカーが嬉しい！

私は申し込み開始2日目位？に申し込んだのですが、既に250人待ちとかいうことになっていたので期待していなかったのですが、
会場を大きくしてくれたのか開催前々日位に参加できることになりました。（それでも350人位はキャンセル待ちがいました。。。）

私自身はそれほどGitHubを使いこなしている訳ではないので、勉強のために参加！

詳細とか

参考URL

私が学んだこと

どちらかというと既に使っている人向けのセッションが多かったので簡単にまとめます。
↑の資料のとこでも書きましたが、私は普段GitHubをそれほど使っていないので「Github実践入門 ─ Pull Request による開発の変革」が一番勉強になったので、この辺りの内容が響いた。
GitHubKaigi Keynote - Speaker Deck

  • Pull Requestがあると、ちょっとした事を話しあえたりする。
    • ロジック、クラスやメソッド分割、変数名など
    • レビューが積極的に行われ、根付いていく

この辺がPull Requestがあるなしでの違い。

  • 習慣
    • 見る、読む、見られる、読まれる
  • 機械
    • 修正、拡張、学習
  • 品質
    • 2eye、over 4 eyes
  • 心理
    • 不安、安心、自信
  • GitHubはコード書いてないくせに声がデカイ人の化けの皮がはがれるシステム
  • Atom（GitHub製エディタ）はWindows対応は多分ずっと先。。。

以下メモ

Hello, Github Kaigi

  • GHEが21%
  • private repositoryは26%
    • 結構少ない
  • PRを受け取ったことがある人
    • 38%
  • PRを送ったことがある人
    • 57%
  • 会社でGithubを使って開発している人
    • 50%位
  • 会社でissueを使ってチケット管理している人
    • 10%位？結構少ない

Github実践入門 ─ Pull Request による開発の変革 (仮)

  • @HIROCASTER
  • 毎日github使ってる人
    • 8割〜9割
  • 今日の話は三本立て
    • Githubを利用していた開発の世界を知る
    • Githubを（利用:活用）する違いを知る
    • GitHub実践入門はガイドブック
Githubを利用していた開発の世界を知る
  • 業務とかである場合とない場合
  • GitHubの世界へようこそ
  • Pull request
    • PR プルリ プルリク
  • よくあるせかい
    • しっくりこないけどなんとなく変数名をつける
    • 後で適切な名前を思いついたら変更しよう
    • 「後で」は一生こない！！
  • githubだとpushの際のコメントに書いておく
    • 他の開発者がレビュー
    • 良い変数名 + α をフィードバック
    • コードに反映
  • 2つの世界の差
  • 習慣
    • 見る、読む、見られる、読まれる
  • 機会
    • 修正、拡張、学習
  • 品質
    • 2eye、over 4 eyes
  • 心理
    • 不安、安心、自信
  • GitHubを使っている世界の中にも差がある。
  • 使っているだけの人、活用している人の差。
    • コードを管理する道具
    • コードの価値を高める道具
  • 活用している人になる
  • 使っているだけのPR
    • このメソッド名は抽象的すぎませんか？
    • このようなコメントだけ
  • 活用している人
    • このメソッド名は処理している内容に対して抽象的すぎませんか？
    • ○○××という名前のほうが具体的で良いと思うのですが。
    • なるほど、○○はクラスに付いているから××とかどうでしょ。
    • なるほど××でもいいですね！
  • っというように、対話して欲しい。
  • 指摘=簡単
  • 提案=難しい
  • 「なんだよこのコード！」というのはコードを理解してなくても書けなくても言える
  • コードをレビューする（ことになる）
    • 行動を起こすキッカケを作ることができる

  • 粗悪なコード
  • 会社や組織の耐性、
  • 現実と戦うワークフロー
  • コストのお話
  • GitHubを使うために学ぶことは多い
  • gitの操作、ブランチの概念
  • コミットメッセージだとかだとか。。。
  • 参考資料
    • YAPC::ASIA Tokyo 2013 2日目
    • GitHubでつくる、楽しい開発現場
    • 「GitHub実践入門」→ コレ読んでメソッド
      • 仕事でプルリク開発しましょう〜て時々あるけど、これ読んどけでOK
まとめ
  • GitHub != 目的
    • GitHubの先にあるものを獲得しなければならない
    • 開発効率？品質？
    • ビジネスの成功？ソフトウェア価値の向上？

はてなブログの開発フローと Github

開発の流れ
  • タスク管理
  • REDMEINE
    • メインの時代
    • タスクはREDMINE
    • pullrequest はGithub
    • 開発者が両ツール見る必要がある
    • 開発者の効率が上がらない
  • GitHub
    • Issuesのみの時代
    • ツールを一つに
    • タスク管理はissuesのみ
    • コードレビューはpullrequest
    • 効率アップ
  • 問題発生
    • チームの重要なものは何？
    • issuesには優先度・締め切りの仕組みは少ない
  • 今誰が何をやってるの？
    • issuesでは進行中のタスクを俯瞰できない
  • 開発者の効率は良い
  • マネージャがチームの俯瞰を出来ない
  • issuesメインに開発者効率は保つ
  • カンバン
  • issuesの役割
    • すべてのタスクはここに入っている
    • だれでも追加OK
    • 追加されたタスクは毎朝検討
  • カンバンの役割
    • issuesの中で重要なものだけ
    • マネージャが選択
    • 重要なものしか追加しない
    • 朝会しかみない
  • Githubとタスク管理
    • 開発者にとって一番効率のよいIssuesをメイン
    • ホワイトボードで重要なものを管理
    • スクラムまでいかないゆるいタスク管理
  • レビュー
    • PRしたけど、担当者は決まっていなかった。
  • 問題発生
  • PRの状態が分からない（のでレビューをためらう）
    • レビュー依頼中？
    • レビュー一度して修正中？
    • レビューもう終わってる？
  • レビューが消化されず、PRが凄い量に。
  • ベテランだけがひたすらレビューし続けるはめに。
  • ○GitHubのレビューツールは最高
  • ×しかし促進は少ない。
  • 解決案
    • レビュー状態をはっきり
    • レビュー依頼一覧をわかりやすく
  • 解決案として2つ導入
    • レビュー状態ラベル
      • issuesにラベルを貼り付ける
  • レビュータイム
    • 14時になったらBOTにレビュー依頼件数を知らせる。
    • レビュー依頼を消化する
  • リリース
    • GitHubとリリース
    • マネージャに確認
  • マネージャ確認せずにリリースしてしまった
    • 自動化しきれない部分でミス
  • 自動化しきれない部分を教えないと新人がリリースできない
  • リリース用PRにまとめる
  • 独自に作業手順書のテンプレートを作れる
  • git-pr-release
まとめ

ワークフローは改善し続けることが大事

OSS と GitHub (仮)

  • @amatsuda
  • github
  • sicuak coding
  • Social Coding 3部作
  • Social Codingではみんながコミット権をもっている。
  • 参政権をもらってるのに、選挙に行かないようなもの
本番
  • OSS and me
    • 職業プログラマ
    • 自分の仕事上の問題を解決する手段
    • 他人の問題を解決するOSS活動

web+db vol.50特集2の神Git記事なるものがある

  • GitHubでぷるり
    • コミッターの誰かがレビュー
    • コミッターの誰かがマージ
  • pull requestを積極的に歓迎
    • 射幸心を煽る
まとめ
  • ドキュメントがとても重要
  • コミットキレイに
  • 名前重要
  • GitHubで人のつながりを
  • フォローするだけじゃなくて、実際にあってみよう
  • アイコンは、画像と本人が一致するものが望ましい
  • とにかくコードを書こう
  • 毎日コードを書こう
  • なんでもいいからコードを書こう
  • 草をいっぱい生やそう
  • GitHubはコード書いてないくせに声がデカイ人の化けの皮がはがれるシステム
  • コードの下の平等
  • 必要なのは一歩を踏み出す勇気
  • ソーシャルコーディングは人間賛歌

How Github Works

  • GitHubの人がどうやってGitHubを作っているか
  • スライドに日本語で字幕を入れてもらっている。
  • 60%の人がリモートで働く社員。
  • リモートがデフォルト
  • 全てがURLを持つ必要がある。
  • 人間のような言葉で話す。
  • 絵文字は素晴らしい。
  • リモートでやるからこそコミュニケーションコストは低くならない。

※英語のセッションだったので、内容を追うことに精一杯でメモできず。。。
※Tweetを見てると、リモートで働くということに対してかなりいいセッションだったらしい。

Githubで雑誌記事を作る

  • どのように作っているのか
  • GitHubで原稿管理とやりとり
  • md2inaoというやつで変換している。
  • MarkdownからIndesignタグに変換している？
  • 雑誌・書籍作りは、ソフトウェア開発に近づけたほうがうまくいく
    • 著者さんの普段のワークフローに近い
    • 書籍もソフトウェアだから

Atom, the Programmable Text Editor

Qiita で人気の Git & GitHub ノウハウ（仮）

  • タイトルちょっと違うらしい
  • Qiitaの中の人
  • GitのTipsらしい。

中身は普段からGit使っていないとほぼ理解できず。。。
資料公開されるのでそこを見たほうがいい感じ。
また、資料自体は結構簡単に書いているので、Qiitaの該当記事へのリンクもある。

Rebuild.fm Live

  • Rebuild.fm
  • 週1位でやっているpodcastの番組
  • pull request駆動開発のお話。
  • podcastで公開されています。
  • モバイルとWebは同じ感じのbranch戦略にするのは難しい
  • 製品のライフサイクルとかによって変わるのでbranch戦略は一般解はない
  • GitHubが落ちてるとデプロイ出来ない問題。
    • ちゃんとした会社はGitHuub落ちた時に何とかする手段を用意している
  • Sqwiggleの話。

LT

メモなし。

Java Day Tokyo 2014に参加してきました #javadaytokyo

JJUG 勉強会

概要

2014年5月22日に開催されたJava Day Tokyo 2014に参加してきました。

去年は仕事のため参加できませんでしたが今年は仕事あるのに！有給使わないで！参加許可が出ました。
ただ、私用により昼前からの参加になってしまいましたが。。。（基調講演残り30分のとこで参加）

参考URL

自分が学んだことまとめ

自分が新たに学んだことは↓な感じ。

  • Java8は早い。何もせずにJava8にするだけでパフォーマンスアップする。（2/3位とか）
  • 新JavascriptエンジンNashornが結構楽しそう。
    • 7までのエンジンRhinoより2〜8倍早くなったとか言ってた気がする。
  • リファクタリングという別タスクになってしまうと、許可が必要で、許可はおりない。
  • テスト駆動開発入門復刊予定！
  • ラムダで使えるメソッド？はかなり充実してるっぽい。

特にNashornは楽しそう。
業務で使えるかどうかは置いといてとりあえずいじってみる予定。

後、Raspberry Pi購入したので、JavaとGroovy入れる！

以下メモ。

基調講演

私用によりラスト30分位から参加。

  • Dukeチェスロボット
  • ユーザグループの話
  • Javaが他のプログラミングとは違う。
  • エコシステムが違う
  • イノベーション
  • コミュニティ
  • 日本Javaユーザグループ
  • JJUGCCC
    • 367名参加
    • 年2回
    • 月1第4週の水曜日19〜
  • ユーザグループ
    • 他の人の経験から学ぶ事ができる。



JavaScript Running On JavaVM: Nashorn

D-1 13:30-14:20
JavaScript Running On JavaVM: Nashorn (新JavaScriptエンジン)

Java SE 8では、これまで同梱していたRhinoに代わり、Nashornという新しい JavaScriptエンジンが導入されました。このセッションでは、Nashornの生まれた経緯、特徴、将来に追加予定の機能などをご紹介します。また、このNashornを用いたサーバー・サイドJavaScriptフ レームワークであるAvatarやAvatar.jsについても簡単に紹介します。

#jdk2014_D1
  • Oracle Blogs 日本語のまとめ: 江草家について
    • の中の人 @OraBlogs_jp
  • Nashorn
  • JavaVMの上で動く
  • CompactProfiles 1でも動く
  • Rhinoの置き換え
    • らいの
    • 2〜4倍位のパフォーマンス
  • セキュリティ、パフォーマンス
  • 作りなおすよりかは1から作りなおすほうがいいんじゃね。
  • Javascriptで書けるものはJavascriptで書くよね。
    • 何とかの法則
  • JavaとJavascript間での相互呼び出し
  • $JAVA_HOME/bin/jjs
    • JRE配下にもあるよ
  • サポートしていないのは。。。
  • Java typrの参照を取得
  • Javaオブジェクトのプロパティアクセス
  • Lamda SAM Script関数の関係
  • スコープ及びコンテキスト
  • javascriptからJavaを呼ぶ時には
var ArrayList = Java.type('java.util.ArrayList')
var list = new ArrayList()
list.add("a")
  • まとめ
    • Javaと緊密に統合
    • バイトコードになる
    • 今後性能向上、機能追加、新しい仕様に対応
  • サーバーサイド
    • Avater.js、Avatarは鋭意開発中
    • 性能は今の所よくないという話だが、改善していく。
    • OPENJDK なので、みんな協力してね！

Java SE 8におけるHotSpotの進化

C-2 14:35-15:25
Java SE 8におけるHotSpotの進化
概要
Java SE 8の主要な機能としてLambda式、Date & Time APIなどが取り上げられることが多いですが、Java SE 8ではJavaVMに対しても様々な改良が施されています。本セッションでは、HotSpot VMにおける改良点などを分かりやすく紹介します。
  • バッグデイビッド
  • PermGenの廃止
  • Tiered Compilation
    • 色々変わったことはあるけど↑2つだけに絞って話す。
  • PermGen廃止
  • 悪いところ
    • サイジングが困難
      • ロードするクラスの数
      • ロードするクラスの大きさ
      • クラスのオーバーヘッド
    • デフォルトが小さい（64mb-85mb））
    • パフォーマンスへの悪影響
  • いいところ
    • あったけ？ｗ
  • metadataは自由に拡張が可能。
    • サイズの制限がない
    • 自由にサイズ変更が可能なので、ユーザが意識する必要性がない
  • GCシステムが管理する必要がない
    • GCのパフォーマンスがよくなる
  • アンロードをクラスローダの単位で行う
  • High Water Mark（高水位標）
    • Full GCが発生しないとMetaSpaceのコレクションが行われない
    • FullGCの頻度が低いシステムのメモリ使用量を制限する必要がある。
    • MetaSpaceのサイズがHWMを超えるとFULLGCが実行される
  • 調整する必要がある場合
    • FULL GCの頻度が高過ぎる時
    • メモリの使用量が大きすぎる時
  • Compressed Oops（圧縮参照）
    • 64bitマシンでも、オブジェクトのアドレスを32bitに格納する
    • javaヒープの使用量を節約
    • ヒープのベースアドレスからのオフセットを利用
    • さらにアドレスのLSBを省略
  • --XX:MaxMetaspaceSize
    • デフォルト=unlimited
    • MetaSpaceの最大サイズ（バイト数）を設定する
    • 実行時
  • --XX:MetaSpaceSize
    • デフォルト=21MB
    • 起動時にFullGCの頻度を減らすために大きくする
    • 起動時（初期値ってことかな。）
  • --XX:MinMetaspaceFreeRatio
    • デフォルト=40
  • --XX:MaxMetaspaceFreeRatio
    • デフォルト=70
    • 単位はパーセント
  • --XX:+UseCompressedClassPointers
    • 64bitではデフォルトで有効
  • --XX:CompressedClassSpaceSize
    • デフォルト=1G
    • 変更ができないため、デフォルト値が大きい
    • 起動時にはメモリをreserveするだけ
    • 必要に応じてcommitしていく

  • ツールも対応
    • jmap jstat jcmd なども対応
  • Tiered Compilations（「階層型コンパイル」）
    • JDK8の新機能ではない
    • 古い実装はHotSpotExpressで6u25までバックポートされました。
    • JDK8ではようやくデフォルトで有効
    • JDK8の新しい実装は従来のバージョンよりかなり充実
  • C1（-client）
    • コンパイル処理が早い
    • 生成されるコードが比較的速くない
  • C2（-server）
    • コンパイル処理に時間が掛かる
    • 生成されるコードが速い
  • 起動を早くしたい場合 C1
  • 起動後のパフォーマンスが必要な場合 C2
  • ↑の選ぶ必要を無くす
  • JMXで診断コマンドを実行
  • まとめ
    • 結果として、7→8にすることによってパフォーマンスは2/3位の速さになっているっぽい。
    • とりあえず8使っとけ。努力しなくてこんなに早くなるよ！

Javaアプリケーション開発におけるテストとTDDの実践

C-3 15:40-16:30
Javaアプリケーション開発におけるテストとTDDの実践
概要
JUnitを使ったユニット・テストの自動化はこの10年で広まり、多くの現場に導入されるまでにいたりました。当セッションでは、さらに先に進んだトピックである、DBをからめたテスト、Web UIを含めたテスト、統合テストの自動化、テスト駆動開発、CIツール、テスト・カバレッジの話など、Javaアプリケーション開発現場におけるテストとTDDの実践について知見を共有します。
  • JUnitは95%位使っている。
    • その後！についてリレートークで話していく。
  • JUnitテストしてるけど効果的なテストができているかは別。
    • 手作業したら負け！
  • 自動化のメリット
    • 手作業によるコストの削減・ミスの削減
    • コンピュータリソースを有効活用
    • 文句を言わずに繰り返し何度でも実行
    • 楽しい
  • ユニットテストは最高のパートナー
  • DBとかのテスト
    • モックで実行する派
    • 実際に繋げる派
  • 初期化-Setup
    • DBデータの初期化
      • 関連テーブルの削除
      • シーケンス
      • システム時間
      • 初期化にかかる処理時間
    • テスト用データの準備
  • 準備 Exercise
    • テスト対象オブジェクトの準備
    • 1つのメソッド（SQL）毎にテストを実行
  • 検証 Verify
    • モデルの検証
    • DBデータへの反映の検証
  • 後処理
    • 1つのテストで複数のことを検証しない
    • 次のテストの初期化に任せて何もしない
  • テスト方針
    • リアルDBを利用
    • フィクスチャはYAMLフォーマットで定義
    • 初期化処理でDBをセットアップ
    • 後処理ではDBを初期化しない
  • その他のポイント
    • フィクスチャ重要
    • ローカル実行
    • スローテスト
    • とかとか
  • 統合テストを自動化せよ
    • 統合テストへの道
    • DBとかAPPサーバとかUIを含む再実行可能な統合テストは？
  • 手動統合テスト
    • 膨大なExcelテスト仕様書
    • 膨大なテスト実行コスト
    • 即レガシー、触るな危険
  • 自動化された統合テスト
    • 手動テストの最小化
    • コスト削減
    • レガシー脱却
    • 楽しい
  • Arquillian
    • Arquillian · Write Real Tests
    • モックするな！
    • ホンモノに近いテストを使用
    • 本物の実行環境へデプロイ、本物の実行環境上でテスト
    • 公式？日本語でもOK。
    • blogとかもあがってきている。
    • Seleniumなども含まれて、インジェクションされてるらしい。
    • Mock is dead. Long live testing.
    • 何でもかんでもモックにするのはよくないよ！
      • 勿論必要な場合はあるけどね！
  • TDDの話
    • みんな知っているけど、やっていない。
  • TDDのサイクル
  • テストは品質をあげない。
    • テストを使用していくことで品質はあがる。
  • カバレッジ。
    • 書かれているコードに対してテストが行われている事を確認しているだけ。
    • バグは書かれていないコードで発生する（仕様漏れだとか。）
  • こだわるなかれ。
  • こだわるとすれば↓
    • 再現性が有る
    • 繰り返し可能
    • 互いに独立

Lambda式とストリームAPI、並列処理の詳細

A-4 16:45-17:35
Lambda式とストリームAPI、並列処理の詳細
概要
Java SE 8におけるクラス・ライブラリ拡張の目玉は、Stream APIです。この新しい APIはLambda式を中心に設計されており、並列プログラミングが簡単に実装できるようになるだけではなく、よりスマートなコーディング・スタイルを提供します。

本セッションは、Stream APIを利用したフィルタ、マップといった基本的な操作から、より難しいリダクション、グルーピング、コレクションといった操作まで紹介します。また、並列処理についても詳しく紹介します。通常、並列処理を有効にするために、"parallel()"メソッドを追加することで実現できます。しかし単に"parallel()"メソッドを追加する方法には問題があります。たとえば並列処理を行った結果、間違えた結果を返す場合や、想定したパフォーマンスが得られない等のいくつかの落とし穴があります。実際にいくつかの落とし穴のコードを示しながら、その問題をどのようにして解決するかについても説明します。

このセッションは英語だったこと、A-2？からの連続セッションだったことからあまり理解できなかった。。。
ただ、内容はわからなかったもののコードが多かったので実際のラムダの使用方法を見ながら概要はわかった感じ。

  • @FunctionalInterfase
  • 英語はイマイチだったけど、コードを追うことで旧コードからラムダ及びストリームを使用したコードへの変化はわかりやすい。
  • ラムダの中ではローカル変数は変えられない。
  • オブジェクトの中身ならば変えれるが、並列処理した場合に困る。
  • common Collectors
    • というのがラムダの中で使えるらしい。
  • StreamsAPIはラムダの仕様を中心に考えられています。
    • StreamAPIによってアプリケーションの作り方が変わっていきます、

おまけ

Groovyのsumメソッドは空のListで実行するとnullが返ってくる

Groovy memo

GroovyではCollectionクラスにsumメソッドがあります。

assert [1,2,3,4,5,6].sum() == 21

普通に使っている分にはいいですが、空のListだとnullが返ってきたので驚きました。。。

assert [].sum{} == null

で、Twitterで呟いたら。。。

凄い人から返事がきた。
こんな風にやればいいっぽい。

assert [].inject(0) { x,y -> x+y } == 0

実コードではsumにクロージャ渡してたので、同じようにListとクロージャ渡すようにして解決しました。

def sum = {l,c->l.inject(0) { x,y -> x + c(y) }}

【東京】 JJUG&JGGUG 共催ナイトセミナ 「4.30 2時間で分かる！次世代ビルドツールの本命Gradleの全貌」に行ってきた #jjug #jggug

JJUG JGGUG 勉強会

導入編

  • 現在の最新版は1.12でバージョン1の最終版。
    • 次のリリースはバージョン2になる。
  • Gradle本執筆中！
    • いつ発売予定って言ってたっけ？？
  • GradleはAnt/Maveのいいとこ取り。
  • 標準化と柔軟性の両立
  • ビルドスクリプトはGroovyで記述
    • どこぞのXMLなんかより余程見やすい！
    • for、ifなどが使えるのでやりたいことがすぐ書ける！
  • Make → Ant → Mavenと進化してきたビルドツールの決定版
  • Gradleがインストールされていなくてもラッパーをバージョン管理システムに入れておけばおｋ
  • Androidの次のビルドツールがGradleに決定

基礎編

  • プラグイン機構による疎結合な構造
  • マルチプロジェクトも簡単
    • フラットレイアウト
    • 階層レイアウト

発展編

  • Gradleは会社でこそ使うもの
  • 信頼性の高いビルド
  • 気軽なカスタマイズ
  • 既存環境の活用
  • 試験機能だけどGradleのバージョン毎のビルド結果の差分が取れる
  • 既存のAntタスクを利用
  • 既存のbuild.xmlはそのまま利用可能
  • 既存の社内リポジトリを利用
  • 既存のpom.xmlはbuild.gradleに変換可能

資料のアジェンダコピペ

  • 導入編
    • Gradle概要
    • Gradleの利用方法
  • 基礎編
    • Gradleの基礎
    • Javaプロジェクト with Gradle
    • マルチプロジェクト with Gradle
  • 発展編:会社で使うGradle
    • 信頼性の高いビルド
    • 気軽なカスタマイズ
    • 既存環境の活用

発表資料とか

次世代ビルドツール本命Gradleの全貌 #jjug #jggug - YouTube

参考URL

  • 公式

Gradle Build Tool

  • 公式ドキュメント日本語訳

Gradle User Guide