ikeike443のブログ

ソフトウェアビジネスに関心がある系のブログ

『Java最強リファレンス』をいただきました

Java

先日わざとらしく何気なく上記のようにTweetしたら、著者の @yuichielectric さんにご献本いただきました。ありがとうございます！


読ませていただきましたのでご紹介をば。

Java 最強リファレンス

Java 最強リファレンス

この本は名前の通りJavaのリファレンスです。通読するというよりは、用途に応じて参照するのが正しいでしょう。
この本が素晴らしいのは、基本的にすべての項をJava7, 8といった最近のバージョンをベースにして解説されているところです。*1
大変な労作です。

ラムダ式やメソッド参照、Optionalについても "Javaの基礎" という章で解説していますし、Streamについても一章割いてきちんと解説しています。
Fileの読み書きもJava8のStream APIを使った書き方を中心に紹介しているところが大変好印象で、新しいJavaの効率的な書き方がよくわかります。*2

Stream API の後ろで使われている Fork/Joinフレームワークの解説や、Fork/Join 自体の使い方にも触れているところもよいです。ScriptEngine(nashornですね)にもきちんと言及していて、いいリファレンスだと思います。

全体的に標準パッケージのみを解説の対象としているのも潔く、読みやすくなっていると思います。


惜しいのは Servlet にも触れているところかなあと思います。Servlet は JavaEEですし標準パッケージとは言いがたく、若干蛇足かなと思いました。Web 開発編みたいなものを別途出したほうがいいんじゃないかと思ったけど、Servletを入れないと売れない、っていう判断があったんだろうなあと邪推しました。。

Jettyのようなサードパーティのライブラリ説明をするのに、Mavenのようなビルドシステムの説明がないのは片手落ちな気がしましたし、セッションの説明についても http はステートレスだって書いてるそばからサンプルコードの中でsession.sethogeしており、セッションの永続化をどうするかについて特に説明がないのがちょっと気になりはしました。*3

ですが、気になったのはそこくらいで、Javaの包括的なリファレンスで、最新のJavaをベースに丁寧な解説があるのはとてもとてもポイントが高く、Java開発者であれば必携の書であると思います！

僕も現場の若手に薦めようと思っています。

Java 最強リファレンス

Java 最強リファレンス

@yuichielectric さん、執筆お疲れ様でした。そして出版おめでとうございます！

*1:この本自体はJava5〜8を対象にしています

*2:もちろん5,6,7の書き方も併記されています

*3:そのままだとステートフルになってしまうと思うのでセッションレプリケーションの解説をするか、外部ストレージ（RDBやmemcached）に永続化することを説明したほうがいいんじゃないかと思いました

auの誰でも割自動更新には気をつけよう

雑記

黙って更新されて、解除料を1万円以上取られます。
2年縛りが解けたあと、ぼやぼやしてるとまた2年縛りになるのでご注意を。
カスタマーセンターに電話して自動更新を解除することはできるっぽいので、早めに確認しておいたほうがいいでしょう。

合法のようですが、黙って更新するのは心象としてはとても悪いですね。

KDDIが逆転勝訴＝解約金条項は適法、携帯割引 2年縛り  : キジトラ速報

Jenkins + Maven3.2.1 で IllegalAccessError on AbstractMapBasedMultimap

CI Jenkins Java maven

メモ。時間があるときに調べる。
Maven3.2.1とJenkins1.581のCoreとで依存しているGuavaのバージョンが違っていることが遠因になっていくつかのプラグインが動かなくなっている。（下記参照）
[#JENKINS-22252] Maven 3.2.1: IllegalAccessError on AbstractMapBasedMultimap - Jenkins JIRA

JenkinsでMavenプロジェクトを作って静的解析をしていて下記のようなエラーが出ていたらこの問題に該当すると思って良さそう。PMD, CheckStyle, FindBugs全て同じ。静的解析以外でも問題が起きそうだけど、今のところ聞いてない。

java.io.IOException: Remote call on channel failed
	at hudson.remoting.Channel.call(Channel.java:748)
	at hudson.remoting.RemoteInvocationHandler.invoke(RemoteInvocationHandler.java:168)
	at com.sun.proxy.$Proxy7.execute(Unknown Source)
	at hudson.maven.MavenBuildProxy$Filter.execute(MavenBuildProxy.java:206)
	at hudson.plugins.analysis.core.HealthAwareReporter.registerResultsOnMaster(HealthAwareReporter.java:325)
	at hudson.plugins.analysis.core.HealthAwareReporter.postExecute(HealthAwareReporter.java:316)
	at hudson.maven.Maven3Builder$MavenExecutionListener.recordMojoEnded(Maven3Builder.java:628)
	at hudson.maven.Maven3Builder$MavenExecutionListener.mojoSucceeded(Maven3Builder.java:610)
	at hudson.maven.Maven3Builder$JenkinsEventSpy.onEvent(Maven3Builder.java:306)
	...
Caused by: java.lang.LinkageError: Failed to load com.google.common.collect.AbstractMapBasedMultimap
	at hudson.remoting.RemoteClassLoader.loadClassFile(RemoteClassLoader.java:326)
	at hudson.remoting.RemoteClassLoader.findClass(RemoteClassLoader.java:236)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:425)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
	at java.lang.Class.forName0(Native Method)
	at java.lang.Class.forName(Class.java:270)
	at hudson.remoting.MultiClassLoaderSerializer$Input.resolveClass(MultiClassLoaderSerializer.java:113)
	... 
Caused by: java.lang.IllegalAccessError: class com.google.common.collect.AbstractMapBasedMultimap cannot access its superclass com.google.common.collect.AbstractMultimap
	at java.lang.ClassLoader.defineClass1(Native Method)
	at java.lang.ClassLoader.defineClass(ClassLoader.java:800)
	at java.lang.ClassLoader.defineClass(ClassLoader.java:643)
	at hudson.remoting.RemoteClassLoader.loadClassFile(RemoteClassLoader.java:322)
	... 39 more

Workaroundとしては、Mavenプロジェクトをやめてフリースタイルプロジェクトで作るか、Mavenのバージョンを3.0.5くらいまで落とせば一応動く。細かいバージョンの組み合わせは試してないが、まあ3.0.5まで落とせば大丈夫っぽい、という程度の理解をしている。

これ結構直すのは面倒そうだなあ。JenkinsのGuavaバージョンをあげるのか、各プラグイン側でWorkaroundな修正を入れるのか。。

『プロフェッショナルのための 実践Heroku入門』を読んだ

雑記

もう2週間も経ってしまったが、RubyKaigi2014に参加してきました。Rubyは全然書いたことないのですが、最近Ruby絡みの仕事をすることになったので行ってみた感じです。

そこでHerokuの相澤さんに買わされたおすすめされた本がこちらです。


これがその時（買った時）のTweet。おっさん二人でむさいですな。。


相澤さんは律儀に僕の本の宣伝もしてくれました！ ありがとうございます！！


さてこの『プロフェッショナルのための 実践Heroku入門』ですが、クラウドの利用はすでにしていて、なんだったら他のPaaSも使ったことあるけど、Herokuはちょっとチュートリアルを触ったくらいで細かいことはわかりません、みたいな人にオススメです。Herokuの採用を検討している人も読むといいでしょう。

Herokuをつかって実際にサービスを立ち上げる際に気をつけるべき点や、よく詰まる点などが解説されています。

例えばPaaSならではのタイムアウト制限についても、単純なレスポンスのタイムアウト制限の話から、Herokuの仕組みを知っていないと理解しがたいSlugコンパイル時間の制限、Slugの容量制限の話まで、Herokuの仕組みについて触れながらわかりやすく説明してくれます。

実運用に入れば必ず気になる、カスタムドメインの設定の仕方やSSL導入の際の注意点、Heroku Postgresを使う際のポイントも解説されています。

また7章では実際にHerokuのテクニカルサポートをされている織田さんが、ありがちなトラブルについて具体例を上げながら解説してくれていて役に立ちます。

最後の9章はHeroku創業者の言葉であるThe Twelve-Factor Appの全訳です。全訳はWebでも読めますが、改めてこの本につけていることに大きなメッセージを感じます。
これはHerokuを使う使わないに限らず、モダンなソフトウェアが持っているべきものだと思います。熟読しましょう。

僕自身は前職ではHerokuもよく使っていましたし、Herokuを使って立ち上げたサービスとしては日本では結構早い時期に属するものに関わってたなあと今思い出しました。（更にいうとPlay2+Scalaだったしね）

転職してからはHerokuはじめいわゆるXaaSなものとは全く疎遠になりましたが、また触れる機会を持ちたいものです。。


最後に僕の本のアフィも貼っておきます。一緒に読むと効果的ですよ！

#DevLOVE 関西でお話させていただきました

雑記 CI

進め、現場のチーム開発 〜チーム開発実践入門〜 (DevLOVE関西Ver) - DevLOVE関西 | Doorkeeper におよびいただき、チーム開発についてお話させていただきました。恐縮です。ちなみに場所ははてなさんにご提供いただきました。ありがとうございます！

以前東京で行った 池田尚史氏に聞くチーム開発の極意 ～「進め，現場のチーム開発 ～チーム開発実践入門」レポート：レポート｜gihyo.jp … 技術評論社 の時の講演内容に事例を加えて少しラップアップを足したものです。


僕の発表の後、みんなでディスカッションを行いました。いろんな開発現場の方のいろんなケースを伺えて面白かったです。

台風が来ていたので勉強会は早めに切り上げ、近くの居酒屋で16時から飲んでおりました。。（恒例）

はてな新社長（！）の栗栖さんともご挨拶させていただき、一緒に串かつを頬張りました。

ステッカー欲しいな、って言ったらくれました！　言ってみるもんだ！


mackerel(https://mackerel.io/)、チョー気になる。使ってみたい。

プロダクトマネジメントとプロジェクトマネジメントまたはプロダクトマーケティング

雑記

Inspiredという本があって、数年前からWeb上で翻訳が進んでいたのは知っていた。

しばらく忘れていて、先ほどたまたま確認したら既に2年前に翻訳が終わっていた。
http://inspiredjp.com/toc/

この本にはソフトウェア企業に務めている人であれば誰でも悩むようなことが書かれている。

プロダクトマネジメントとプロジェクトマネジメントの違い、プロダクトマネージャーの重要性と不在、特にプロダクトマーケティングの不在。アジャイル開発との関係。カスタム開発*1とパッケージソフトあるいはインターネットサービス開発の違い。アジャイル開発はもともとカスタム開発の問題解決のために考案されているためか、プロダクトマネジメントについての考慮が抜け落ちている件、などだ。

僕もまだ読んでいる最中なんだけど、この話題はとても興味があり、悩みも多い。
プロダクトマネジメントとプロジェクトマネジメントの違いについては、8年前にSI企業からパッケージソフト企業に移ってきた時に一番考え方を変える必要があった分野だし、今でも自分で上手く扱えていない問題だと思っている。

日本に限らないと思うけど、ソフトウェアエンジニアの大半はSI企業で受託開発をしている人が多い。僕もそうだったし。なので、パッケージソフト開発の企業も、Webサービス開発の企業も、元々はSIで働いていました、という人がほとんどだ。SIからパッケージやWebサービスの企業に移ってきた人は僕も含めてみな最初はこの違い*2を理解できずに苦しむ人が多いように思う。

とりあえず、自分の頭を整理するためにプロダクトマネジメントとプロジェクトマネジメントについて表に書きあらわしてみた。*3
f:id:ikeike443:20140713000828p:plain

プロダクトマネジメントとしては、プロダクトマーケティングとプロダクトデベロップメントの両方のマネジメントが必要だろう。

プロダクトマーケティングは、市場創出を含めたマーケティングプランの作成実行と、ブランディングあたりをレスポンシビリティとするのかなと思う。

プロダクトデベロップメントはいわゆる製品開発の領域で、製品企画を考えたり、機能一覧を作ったりユーザーシナリオを整理したりという、要件定義っぽい分野を想定している。

どちらの職務も製品開発には必要なのだが、はっきり違う領域を扱わないといけないことがわかる。

プロジェクトマネジメントの方は、ビジネスリクワイアメントとデリバリーというふうに分けてみた。簡単に言うと、要件定義と進捗管理だ。WhatとHowって言ったほうがわかりやすいかな。

責任を負う期間も違っていて、プロダクトマネジメントはプロダクトのライフサイクルの終了までずっと面倒を見るイメージ。プロジェクトマネジメントはあくまでプロジェクトの終了までであって、プロダクトのライフサイクルにおける一部を担うのみ。


パッケージ・Webサービスの企業とSI企業をあえてマッピングしてみるとこんな感じだろうか。
f:id:ikeike443:20140713000850p:plain

SIの場合はプロダクトマネジメントという観点はあまりまたはほとんどないというのは納得していただけると思う。
パッケージ・Webサービス企業においてはアジャイル開発、特にスクラム（またはスクラムっぽい何か）を採用している企業が多いと思うので、プロダクトオーナー、スクラムマスターという用語を当てた。ここはウォーターフォールの場合はプロジェクトマネージャーが一人で兼ねるところだと思う。
表では、SI企業=旧来型のPMみたいに書いてしまったがこれは便宜上で、実際にはアジャイル開発をしているSI企業もいれば、ウォーターフォールで製品開発をしているパッケージソフトやWebサービスの企業も存在する。わかりやすく書いているだけなので、自分のところは違う、みたいに怒らないで欲しい。

ただ、おそらくなんだけど、パッケージ・Webサービスの企業においても、プロダクトマーケティングにレスポンシビリティを持って働いている人はほとんどいないのではないだろうか。
ほとんどの場合この領域はマーケティング部門が担当していることが多い。マーケティング部門はそのプロダクト専任のマーケティング担当では無いので、どうしてもマーケティングプランは通り一辺になってしまう可能性がある。（もちろん優秀なマーケの人が多い会社であればそれでも事足りることはあると思う）

このへん、みんなどういうふうにしているんだろう、ってのがすごく気になる。こんな話ができる勉強会とかあったら出てみたいなあと思った。

プロダクトマネジャーの教科書

プロダクトマネジャーの教科書

Inspired: How To Create Products Customers Love

Inspired: How To Create Products Customers Love

https://itunes.apple.com/jp/app/inspired-j/id532852475?mt=8
inspired-j

inspired-j

  • Mare Azzurro, Inc.
  • ビジネス
  • ¥1,400

*1:いわゆる受託開発や企業内システム開発のことを指している模様

*2:プロダクトマネジメントとプロジェクトマネジメントの違い

*3:表が画像になってるのは特に意味はない。。なんとなくCacooでかいてpngに書きだしたからこうなっただけ