Category Archives: Web技術

Seasar Conference 2015に参加してLTをしてきました #seasarcon

2015/09/26、5年ぶりに開催された、
Seasar Conference 2015 Not 同窓会
に参加し、次のスライドでLT登壇してきました。

なぜLTをしたのか

僕はこれまでにもMayaa関係の勉強会登壇を繰り返してきました。

JJUG CCC 2013 Fall: テンプレートエンジンを利用してプログラマーとWebデザイナーが共同作業をする上で大切なこと
JJUG ナイトセミナー 2013/08: from JSP to Design-friendly Template Endine JSPからMayaaに移行した本当の話

このブログでも、Mayaaについての発信が多めです。

5年間Mayaaを使って思ったこと
Mayaaでm:idの解決の仕方を自分好みにカスタマイズする方法
MayaaなどRhinoを使っていてハマること。It is not a function, it is String
2年間Mayaaを使ってわかったこと その2
そろそろ2年間Mayaa使ってわかったことを書く
MayaaでHTML5のスマートフォンページを作る際にはまったこと
Mayaaファイルを命名規則から一括作成するEmEditorマクロ
MayaaでGuice2.0 AOPを使うとうまく動かない件〜解決編
MayaaでGuice2.0 AOPを使うとうまく動かない件

Mayaaは、自分が大変お世話になっているOSSで、不具合報告などでOSS活動にも関わらせていただくなど、技術者として成長させてもらった思い入れの強いライブラリです。

この日、作者である栗原 傑享さんや、現在メインコミッターを務められる須賀 幸次さんがいらっしゃるということで、彼らへの感謝の気持ちを表現したいという、実に個人的な動機がLTをした理由でした。

それにしては、Seasar Foundationの重鎮の方々に好意的に受け入れて頂いたようです。考えてみるとMayaaが生まれた土壌である、Seasarコミュニティの存在も肯定する内容でもあったからかなと思います。そういったわけでは、Seasarコミュニティーに対しても感謝の気持ちを明確に表すべきでした。この場を持って、感謝の意を表明致します。

なぜ今SeasarConなのか?

Seasar Conference は2010年を最後に開催されず、Seasar2も既に機能の追加が中断されていました。既に、JavaのトレンドはSpringやJava EEに移行しており、Seasarは時代の中でフェードアウトしたように見えていました。その中で、なぜ?今 Seasar Conference なのか?と多くの方が興味を持ったと思います。

蓋を開けてみると、5年前まで、あんなに先導的なメッセージを発信して日本のJava系エンジニアの最大のカリスマだったひがやすをさんが、どうも、中立的というか、大人な話し方をされている印象でした。まして、Seasar2のサポート終了(2016/09/26)を宣言される。あれあれ、なんか暗いぞ??

そこへ栗原 傑享さんの喝が入ります。どどどんな展開((((;゚Д゚))))ガクブル

5年間Seasar Conferenceが行われなかった裏で何が起きていたかについては、理事長の橋本さんのセッションで説明がありました。開催されなかった理由:

  • イベント駆動開発→開発駆動イベント→DIのメンテナンス終了、ワクワク感より調整の難易度が上回った
  • NPO運営はスポンサーに支えられている。ムーブメント、流行に乗る必要がある
  • NPO改名問題があった

NPO活動を行うにも、イベント一つ行うのも、裏での苦労が絶えないのだなあということが伝わりました。その一方で、福岡の方では「明星和楽」というイベントが行われ、これは「テクノロジーとクリエイティブ」にフォーカスしたイベントで、業界の流れがSIからスタートアップに向かう中での実験として成功だったそうです。

自分は新参者なので、知りませんでしたが、Seasarコミュニティを支えていた方々は、SIerの精鋭たちが中心であって、SeasarとSI・受託開発という枠組みは切っても切れない存在のようです。2010年頃には、ひがさんはSlim3をリリースしていてAppEngineなどでのスタートアップ志向にシフトしていたし、橋本さんの経営されるヌーラボは、Cacooなどのサービスを打ち出していたので、どちらかと言うと、サービス指向をもともと持っていた人たちだと思っていましたが、SIにおける、エンタープライズJavaからのニーズがSeasarの原点だったのです。

2010年から、2015年の間に震災やスマホブーム、ソシャゲブーム、クラウドの興隆を経て、今時「受託かスタートアップか」という議論自体が古臭いと思いますが、Seasarというコミュニティは、その原点と、その名前が足かせとなって、進むべき方向性に難儀していたそうです。こういうことを赤裸々に話してくれたことに大変感謝します。

個人的には、僕のような、当時接点を持てなかった者がかつてSeasarで有名だった方々と繋がることができたのが大変ありがたく思いました。懇親会にも参加させていただきましたが、これからどうするのかというような議論が活発になされているようです。解散か?改名か?なにかの転換があるのか?Seasarの次の動向に期待したいです。

栗原さんの海外のIT事情の発表が面白かった

Mayaaの開発者にして、グルージェントの創業者で、サイオスの幹部として、現在はシリコンバレーに生活されてスタートアップをされている栗原 傑享さんの発表は刺激的でした。

アメリカでは、徹底的に生活の効率化が行われて、公共インフラが民間企業の寡占状態にある。例えば、警察を呼べばお巡りは来ずに、メールアドレスを聞かれて、CoplogicというWebサイトから被害届を出すように言われる。そのCoplogicは民間企業!部屋を探すときはcraigslistが必須。Coplogicもcraigslistもナニコノ垢抜けないデザインは!

「少年野球はミスも出やすいですから、基本積極プレーで」(引用:MAJOR 2nd 第25話)

これがアメリカのスタートアップのメンタルのようです。僕たちは、FacebookやGoogleといった超巨大な企業しか知らないために、すごいイメージがありますが、あれはメジャーリーグ、シリコンバレーのスタートアップは大半が少年野球!(マイナーリーグですらないのか。。。)彼らはCSSも書かずに平気で2塁まで突っ込んでいくんだそうです。

このメンタルでくると、要件定義をして、スケジュールを引いて、アサインして……のやり方では間に合わないのは確かですね。

前述のように、アメリカは公共インフラが徹底的に効率化され、民間企業の寡占状態にあります。この状況は、間違いなく未来の日本にもやってくる!今のうちにcraigslistをパクったら儲かるwwwまあ、100パーセント同じにはならないと思いますが。(^^;

個人的な考察:2010年から2015年という時代について思うこと

稚拙な考察ですが、2010年ごろ不況もあり、業務システムのIT化も既にコモディティ化が済んでしまった以降、今までの形態のSIerのニーズは減少し、クラウドなど黒船の到来によって、この世界は縮小するのは明らかでした。

では、多くのITエンジニアが職を失ったのかといえば全く逆で、未だに「エンジニアが足りない」と言っている。何が起きたかといえば、これまでよりも多くのことにWebやスマホなどのITが使われるようになった(リアルなお店でものが売れなくなった)と言われます。

しかし、この業界の流動性は非常に速く、今までみたいにじっくり良い物を作っていくより、手が早い方が求められました。そうすると、1からスクラッチでシステムを作るより、WordPressを改造して目的を実現するとか、既存の何かをいじって楽をできる方が重要で、そうなってくるともう言語やフレームワークがどうこう言っていられない。WordPressに乗っかるのか、Google Appsに乗っかるのか?

ただ乗っかっているだけだとプラットフォーマーに吸い取られる仕組みになっています。そこで自ら何らかのプラットフォーマーになるか、あるいはレベニューシェアなど成果にコミットする方向性がこれから成功する秘訣なのかなあと思います。

そう考えると、2010年と今とでも時代は全然違うなあと思います。

ここまで理解したところで、何もできていない自分に比べたら、Seasarの中心の方々は僕よりも何十倍も優秀な方々の集まりなので、一人ひとりはこの波の中で成功されているのでしょう。でも、Seasarという糊がなければ、彼らはつながらずSeasarは時代の流れの中で役割を終えようとしている中で、外部の者がどうこう言うことではありませんが、同窓会だったとしても十分に価値があったと思います。そこに行って、憧れの彼らが今どうしているのか、話を聞かせてもらえたことは、新参者の自分として、大変刺激的で大変貴重な一日でした。

今、自分の年齢はSeasarの人たちが活発に活動をされていた年齢くらいに位置します。同世代のエンジニアを見渡すとSeasarを作る人は出てこないだろうなあと思いますが、CEOやCTOを名乗っている友人もいますし、ある意味、スタートアップ時代を生きています。そんな中で、僕らは、一まわり上の方の貴重な経験をもっと吸収して、自分たちこそ時代を盛り上げていかなければならない時ではないでしょうか。

ねこ踏んじゃった系エントリ:Tomcatいじめたら意外と強かったこと #javaee

これは Java EE Advent Calendar 2014 の6日目です。昨日は tq_jappy さんの「Java SE 8とJava EE 7によるアプリケーションのモダナイゼーション~中間ふりかえり~」、明日は yamadamn さんです。

ServletだってJava EE、だったらTomcatだって。。。

Java EEと言えばWildFlyかGlassfishかあるいは商用アプリケーションサーバーで、CDIとかEJBとかJSF....を使うかっこいいやつを言うらしいです。。。でも僕はまだ使ったことがありません。

僕はまだTomcatを使っています。
Tomcatといえば「可愛くないねこ」
_人人人人人人人人人_
> 可愛くないねこ <
 ̄Y^Y^Y^Y^Y^Y^Y^Y ̄
「もっともかわいくないねこ」と言われる公式ロゴ
など、散々な言われ方をしています。。そんないじめなくてもいいのに!たしかに拡張性がありそうで意外とそうでもなかったり、ソース読むと袋小路に陥るなど、開発者に服従しないあたり、そう、とてもねこっぽい。挙動萌えじゃないですか。Mな僕は満足です!
※このエントリの筆者はねこを飼ったことがないので正しくないかもしれませんのでご容赦ください

Java EEのカレンダーにTomcatってどうなのかってことですが、ほら、Servetだって立派なJava EEの一部です。そして2日目のirofさんが

全部を使わなきゃいけないわけじゃありません。

っておっしゃってるじゃないですか!(Java EEを説明してみる #javaee - 2014-12-02 - 日々常々

Java EE全部使おうとしたら実はServletとJSPくらいで良かった、だから僕はJava EEを使っているのであって、TomcatがJava EEアドベントカレンダーに出てきても許してにゃん!

2014年の僕の中でのトピックは、Tomcatの戦闘力の高さ

今年の個人的なトピックは、わけあってTomcatの底力を思い知ったことでした。半端ないです。いじめて反撃食らった心境です。童謡にもあるでしょ踏んだらひっかくって!

ということで、試しに踏んでみたいと思います。

実験概要

この実験では、大量のwebアプリケーションを作ります。Webアプリケーションはこんな簡単なServletだけでいいです。

@WebServlet("/hello")
public class HelloServlet extends HttpServlet {
    protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
        response.setContentType("text/plain");
        response.setCharacterEncoding("UTF-8");
        PrintWriter writer = response.getWriter();
        writer.println("こんにちは世界");
    }
}

これをなんとかしてHello.warというwarファイルにしたとします。次にこんなスクリプトを書いて、大量生成します

> jrunscript -e "for(var i=0;i<1000;i++)cp('Hello.war','Hello' + i + '.war');"

実験:1000個のWebアプリケーションを一気にデプロイするのに必要な時間と消費メモリ

Tomcatはwarファイルをwebappsディレクトリ以下に配置すれば自動的にWebアプリケーションとしてロードします。なので大量に作ったwarファイルを一気にwebappsに移動してみましょう。

その時のログが以下の通り。

情報: Webアプリケーションアーカイブ H:\java\apache-tomcat-7.0.54\webapps\Hello992.war を配備します
12 04, 2014 12:07:33 午前 org.apache.catalina.startup.HostConfig deployWAR
情報: Deployment of web application archive H:\java\apache-tomcat-7.0.54\webapps\Hello992.war has finished in 47 ms
12 04, 2014 12:07:33 午前 org.apache.catalina.startup.HostConfig deployWAR
情報: Webアプリケーションアーカイブ H:\java\apache-tomcat-7.0.54\webapps\Hello993.war を配備します
12 04, 2014 12:07:33 午前 org.apache.catalina.startup.HostConfig deployWAR
情報: Deployment of web application archive H:\java\apache-tomcat-7.0.54\webapps\Hello993.war has finished in 31 ms
12 04, 2014 12:07:33 午前 org.apache.catalina.startup.HostConfig deployWAR
情報: Webアプリケーションアーカイブ H:\java\apache-tomcat-7.0.54\webapps\Hello994.war を配備します
12 04, 2014 12:07:33 午前 org.apache.catalina.startup.HostConfig deployWAR
情報: Deployment of web application archive H:\java\apache-tomcat-7.0.54\webapps\Hello994.war has finished in 31 ms
12 04, 2014 12:07:33 午前 org.apache.catalina.startup.HostConfig deployWAR
情報: Webアプリケーションアーカイブ H:\java\apache-tomcat-7.0.54\webapps\Hello995.war を配備します
12 04, 2014 12:07:33 午前 org.apache.catalina.startup.HostConfig deployWAR
情報: Deployment of web application archive H:\java\apache-tomcat-7.0.54\webapps\Hello995.war has finished in 31 ms
12 04, 2014 12:07:33 午前 org.apache.catalina.startup.HostConfig deployWAR
情報: Webアプリケーションアーカイブ H:\java\apache-tomcat-7.0.54\webapps\Hello996.war を配備します
12 04, 2014 12:07:33 午前 org.apache.catalina.startup.HostConfig deployWAR
情報: Deployment of web application archive H:\java\apache-tomcat-7.0.54\webapps\Hello996.war has finished in 31 ms
12 04, 2014 12:07:33 午前 org.apache.catalina.startup.HostConfig deployWAR
情報: Webアプリケーションアーカイブ H:\java\apache-tomcat-7.0.54\webapps\Hello997.war を配備します
12 04, 2014 12:07:33 午前 org.apache.catalina.startup.HostConfig deployWAR
情報: Deployment of web application archive H:\java\apache-tomcat-7.0.54\webapps\Hello997.war has finished in 32 ms
12 04, 2014 12:07:33 午前 org.apache.catalina.startup.HostConfig deployWAR
情報: Webアプリケーションアーカイブ H:\java\apache-tomcat-7.0.54\webapps\Hello998.war を配備します
12 04, 2014 12:07:33 午前 org.apache.catalina.startup.HostConfig deployWAR
情報: Deployment of web application archive H:\java\apache-tomcat-7.0.54\webapps\Hello998.war has finished in 31 ms
12 04, 2014 12:07:33 午前 org.apache.catalina.startup.HostConfig deployWAR
情報: Webアプリケーションアーカイブ H:\java\apache-tomcat-7.0.54\webapps\Hello999.war を配備します
12 04, 2014 12:07:33 午前 org.apache.catalina.startup.HostConfig deployWAR
情報: Deployment of web application archive H:\java\apache-tomcat-7.0.54\webapps\Hello999.war has finished in 32 ms

こんな感じで粛々とロードします。(Tomcatの最新安定版は8.x系ですが、これは実験した時のバージョンと同じで7系にしています。8でも同じだと思うけど試してません)

1分以内に全部のロードが終わりました。
その際のリソース使用量はこんな感じです。

徐々に上がって、メモリ使用量750MBあたりで安定

本当にデプロイされているのか、全部のアプリケーションにアクセスしてみましょう。

> jrunscript -e "for(var i=0;i<1000;i++)cat('http://localhost:8080/Hello' + i + '/hello');"

ねこだけにcat関数!サクッと値返してます!

こんにちは世界
こんにちは世界
こんにちは世界
こんにちは世界
こんにちは世界

※Windowsのコマンドプロンプトだと、文字化けします。文字コードがShiftJISじゃないとダメみたいです。

管理コンソールだってちゃんと機能します。ほら!
アプリ1000個くらいデプロイしても管理画面はさくっと機能します

最後に、アンデプロイです。これは、warファイルを消すと、それを検知して勝手に配備解除してくれます。解除の順番はばらばらで、配置よりはゆっくりですが、でも確実に配備解除されました。おりこうですね!

情報: コンテキストパス /Hello465 のWebアプリケーションの配備を解除します
12 04, 2014 12:12:42 午前 org.apache.catalina.startup.HostConfig undeploy
情報: コンテキストパス /Hello924 のWebアプリケーションの配備を解除します
12 04, 2014 12:12:43 午前 org.apache.catalina.startup.HostConfig undeploy
情報: コンテキストパス /Hello332 のWebアプリケーションの配備を解除します
12 04, 2014 12:12:44 午前 org.apache.catalina.startup.HostConfig undeploy
情報: コンテキストパス /Hello152 のWebアプリケーションの配備を解除します
12 04, 2014 12:12:45 午前 org.apache.catalina.startup.HostConfig undeploy
情報: コンテキストパス /Hello179 のWebアプリケーションの配備を解除します
12 04, 2014 12:12:45 午前 org.apache.catalina.startup.HostConfig undeploy
情報: コンテキストパス /Hello194 のWebアプリケーションの配備を解除します
12 04, 2014 12:12:46 午前 org.apache.catalina.startup.HostConfig undeploy
情報: コンテキストパス /Hello528 のWebアプリケーションの配備を解除します
12 04, 2014 12:12:47 午前 org.apache.catalina.startup.HostConfig undeploy
情報: コンテキストパス /Hello370 のWebアプリケーションの配備を解除します

同じ実験をGlassfishでやってみる

同じ実験をGlassfishでやってみようと思います。結果を知ってるんで、やりたくないんですけどね。
Glassfishも同じように下記の場所にwarをコピーすると自動でデプロイされる仕組みがあります。

/glassfish/domains/ドメイン名/autodeploy

それでは、さっきの方法で。。。。warを大量コピーしてみます。

[#|2014-12-04T01:10:31.968+0900|INFO|glassfish 4.0|javax.enterprise.system.tools.deployment.common|_ThreadID=119;_ThreadName=AutoDeployer;_TimeMillis=1417623031968;_LevelValue=800;|
  visiting unvisited references|#]

[#|2014-12-04T01:10:31.984+0900|INFO|glassfish 4.0|javax.enterprise.system.tools.deployment.common|_ThreadID=119;_ThreadName=AutoDeployer;_TimeMillis=1417623031984;_LevelValue=800;|
  visiting unvisited references|#]

[#|2014-12-04T01:10:31.984+0900|INFO|glassfish 4.0|javax.enterprise.system.tools.deployment.common|_ThreadID=119;_ThreadName=AutoDeployer;_TimeMillis=1417623031984;_LevelValue=800;|
  visiting unvisited references|#]

[#|2014-12-04T01:10:32.031+0900|INFO|glassfish 4.0|javax.enterprise.web|_ThreadID=119;_ThreadName=AutoDeployer;_TimeMillis=1417623032031;_LevelValue=800;_MessageID=AS-WEB-GLUE-00172;|
  Loading application [Hello234] at [/Hello234]|#]

[#|2014-12-04T01:10:32.062+0900|INFO|glassfish 4.0|javax.enterprise.system.core|_ThreadID=119;_ThreadName=AutoDeployer;_TimeMillis=1417623032062;_LevelValue=800;|
  Hello234は、547ミリ秒で正常にデプロイされました。|#]

[#|2014-12-04T01:10:32.062+0900|INFO|glassfish 4.0|javax.enterprise.system.tools.deployment.autodeploy|_ThreadID=119;_ThreadName=AutoDeployer;_TimeMillis=1417623032062;_LevelValue=800;_MessageID=NCLS-
DEPLOYMENT-00035;|
  [AutoDeploy]自動デプロイは正常に実行されました : H:\java\glassfish4\glassfish\domains\domain1\autodeploy\Hello234.war。|#]

[#|2014-12-04T01:10:32.077+0900|INFO|glassfish 4.0|javax.enterprise.system.tools.deployment.autodeploy|_ThreadID=119;_ThreadName=AutoDeployer;_TimeMillis=1417623032077;_LevelValue=800;_MessageID=NCLS-
DEPLOYMENT-00027;|
  Selecting file H:\java\glassfish4\glassfish\domains\domain1\autodeploy\Hello805.war for autodeployment|#]

[#|2014-12-04T01:10:32.531+0900|INFO|glassfish 4.0|javax.enterprise.system.tools.deployment.common|_ThreadID=119;_ThreadName=AutoDeployer;_TimeMillis=1417623032531;_LevelValue=800;|
  visiting unvisited references|#]

[#|2014-12-04T01:10:32.546+0900|INFO|glassfish 4.0|javax.enterprise.system.tools.deployment.common|_ThreadID=119;_ThreadName=AutoDeployer;_TimeMillis=1417623032546;_LevelValue=800;|
  visiting unvisited references|#]

[#|2014-12-04T01:10:32.546+0900|INFO|glassfish 4.0|javax.enterprise.system.tools.deployment.common|_ThreadID=119;_ThreadName=AutoDeployer;_TimeMillis=1417623032546;_LevelValue=800;|
  visiting unvisited references|#]

[#|2014-12-04T01:10:32.609+0900|INFO|glassfish 4.0|javax.enterprise.web|_ThreadID=119;_ThreadName=AutoDeployer;_TimeMillis=1417623032609;_LevelValue=800;_MessageID=AS-WEB-GLUE-00172;|
  Loading application [Hello805] at [/Hello805]|#]

[#|2014-12-04T01:10:32.640+0900|INFO|glassfish 4.0|javax.enterprise.system.core|_ThreadID=119;_ThreadName=AutoDeployer;_TimeMillis=1417623032640;_LevelValue=800;|
  Hello805は、563ミリ秒で正常にデプロイされました。|#]

Tomcatのときは数10msで1アプリ起動していましたが、こちらはロード数が多いと徐々に遅くなっていきます。最終的には1アプリ7秒ほどの時間を費やしていました。

[#|2014-12-04T01:43:19.334+0900|INFO|glassfish 4.0|javax.enterprise.web|_ThreadID=119;_ThreadName=AutoDeployer;_TimeMillis=1417624999334;_LevelValue=800;_MessageID=AS-WEB-GLUE-00172;|
  Loading application [Hello200] at [/Hello200]|#]

[#|2014-12-04T01:43:19.422+0900|INFO|glassfish 4.0|javax.enterprise.system.core|_ThreadID=119;_ThreadName=AutoDeployer;_TimeMillis=1417624999422;_LevelValue=800;|
  Hello200は、7,828ミリ秒で正常にデプロイされました。|#]

[#|2014-12-04T01:43:19.424+0900|INFO|glassfish 4.0|javax.enterprise.system.tools.deployment.autodeploy|_ThreadID=119;_ThreadName=AutoDeployer;_TimeMillis=1417624999424;_LevelValue=800;_MessageID=NCLS-
DEPLOYMENT-00035;|
  [AutoDeploy]自動デプロイは正常に実行されました : H:\java\glassfish4\glassfish\domains\domain1\autodeploy\Hello200.war。|#]

[#|2014-12-04T01:43:19.426+0900|INFO|glassfish 4.0|javax.enterprise.system.tools.deployment.autodeploy|_ThreadID=119;_ThreadName=AutoDeployer;_TimeMillis=1417624999426;_LevelValue=800;_MessageID=NCLS-
DEPLOYMENT-00027;|
  Selecting file H:\java\glassfish4\glassfish\domains\domain1\autodeploy\Hello251.war for autodeployment|#]

[#|2014-12-04T01:43:27.075+0900|INFO|glassfish 4.0|javax.enterprise.system.tools.deployment.common|_ThreadID=119;_ThreadName=AutoDeployer;_TimeMillis=1417625007075;_LevelValue=800;|
  visiting unvisited references|#]

[#|2014-12-04T01:43:27.086+0900|INFO|glassfish 4.0|javax.enterprise.system.tools.deployment.common|_ThreadID=119;_ThreadName=AutoDeployer;_TimeMillis=1417625007086;_LevelValue=800;|
  visiting unvisited references|#]

[#|2014-12-04T01:43:27.091+0900|INFO|glassfish 4.0|javax.enterprise.system.tools.deployment.common|_ThreadID=119;_ThreadName=AutoDeployer;_TimeMillis=1417625007091;_LevelValue=800;|
  visiting unvisited references|#]

[#|2014-12-04T01:43:27.280+0900|INFO|glassfish 4.0|javax.enterprise.web|_ThreadID=119;_ThreadName=AutoDeployer;_TimeMillis=1417625007280;_LevelValue=800;_MessageID=AS-WEB-GLUE-00172;|
  Loading application [Hello251] at [/Hello251]|#]

[#|2014-12-04T01:43:27.392+0900|INFO|glassfish 4.0|javax.enterprise.system.core|_ThreadID=119;_ThreadName=AutoDeployer;_TimeMillis=1417625007392;_LevelValue=800;|
  Hello251は、7,952ミリ秒で正常にデプロイされました。|#]

[#|2014-12-04T01:43:27.392+0900|INFO|glassfish 4.0|javax.enterprise.system.tools.deployment.autodeploy|_ThreadID=119;_ThreadName=AutoDeployer;_TimeMillis=1417625007392;_LevelValue=800;_MessageID=NCLS-
DEPLOYMENT-00035;|
  [AutoDeploy]自動デプロイは正常に実行されました : H:\java\glassfish4\glassfish\domains\domain1\autodeploy\Hello251.war。|#]

glassfishのロード時のvisualvm表示、GCが頻繁に走っているのか、ヒープ使用量のグラフが穏やかでない

結局、約35分にしてロードが終わりました。では、せっかくのアプリケーションサーバーなので管理コンソールを開いてみましょう。。。。

管理コンソールでアプリケーションクリック「長時間実行中のプロセスが検出されました。お待ちください...」と表示されて固まっている

画面が返ってこなくなりました

死んだ魚

勝ち誇るTomcat

でも、TomcatよりもGlassfishはずっと多くの機能を持っているんだから当然といったらそうですね。そもそもこの実験が業務で役立つことって相当レアケースかもしれません。それでも、僕は自分に合ったツールはやはりTomcatなのかなと思い直しました。そう、今なら言える!

_人人人人人人人人人人人人_
> Tomcatかわいい <
 ̄Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y ̄

WildFlyは実験を行った当時はまだリリースしてなかったので試していませんでした。機会があったらやってみようと思います。もしかするとUndertowは優秀らしいので、Tomcatよりも更によい結果をだすかもしれませんね!

本題とは関係ないおまけ:スクリプトにjrnscriptを多用したわけ

今回、WindowsでもLinuxでもMacでも同じコマンドラインを流用できるように、jrunscriptのワンライナーで記述しました。これは、JVM内包のRhinoまたはnashornを使ってシェルのように使えるもので、意外と知られていませんが、下記のドキュメントにあるシェル風のグローバル関数が使えます。
GLOBALS
(これ、見つけづらいところにあるので、毎回探しちゃいます。これからはこの記事を参照すれば探さなくて良くなりますね!)

例えば、今回やったように、cpでコピーしたり、catで簡易curlにしたりできます。これはちょっとしたインストーラのようなものを作るときに便利です。困ったらJavaAPIが使えるので、安心です。なので、僕は普段Windowsを使っていてWSHとかPowershellは苦手なので、ちょっとしたスクリプトを書くときに、jrunscriptをよく使います。

WebIDE ICEcoderをセットアップしてみた

次の時代はクラウド開発環境が来るはず!

先の記事では Hack (Hacklang) の開発はFBIDEが本命だと書きました。しかし、まだリリースされていないので、当面vimかemacsを使わざるを得ません。せめて、Web IDEの雰囲気を味わってみたいので、そこそこ知名度のあるICEcoderをインストールしてみました。後の自分用にその手順を記載します。

導入手順

http://icecoder.netの説明に従ってgithubから最新のコードをダウンロード

$ git clone git@github.com:mattpass/ICEcoder
Cloning into 'ICEcoder'...
Warning: Permanently added the RSA host key for IP address '192.30.252.131' to the list of known hosts.
Enter passphrase for key '/home/susumuis/.ssh/id_rsa':
remote: Counting objects: 6950, done.
remote: Total 6950 (delta 0), reused 0 (delta 0)
Receiving objects: 100% (6950/6950), 3.78 MiB | 796 KiB/s, done.
Resolving deltas: 100% (4136/4136), done.

下記のようにダウンロードされた

$ cd ICEcoder/
$ ls
CodeMirror-4.2  LICENSE.md  README.md  backups  editor.php  farbtastic  favicon.png  files.php  images  index.php  jshint  lang  lib  plugins  processes  test  test.php  tmp
$ cd /etc/nginx/

nginxで公開する。

$ sudo vim sites-available/icecoder

下記のように編集した。今回は80番ポートは使用せず、httpsだけで配信する。とりあえずオレオレ証明書作っとく。

server {
        listen 443;
        server_name 公開するドメイン;
        root ICEcoderのディレクトリ;
        index index.php;

    include hhvm.conf;
        ssl on;
        ssl_certificate /etc/ssl/certs/icecoder.crt;
        ssl_certificate_key /etc/ssl/certs/icecoder.key;
        ssl_session_timeout 5m;
        ssl_protocols SSLv3 TLSv1;
        ssl_ciphers ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv3:+EXP;
        ssl_prefer_server_ciphers on;
        location / {
                #try_files $uri $uri/ =404;
                try_files $uri $uri/ /index.php;
        }
}

オレオレ証明書の作り方は毎回忘れるので簡単にメモっとく。

$ cd
$ sudo openssl genrsa 2048 > icecoder.key
$ openssl req -new -key icecoder.key > icecoder.csr

Country Name (2 letter code) [AU]:JP
State or Province Name (full name) [Some-State]:Tokyo
Locality Name (eg, city) []:Tokyo
Organization Name (eg, company) [Internet Widgits Pty Ltd]:組織名
Organizational Unit Name (eg, section) []:susumuis
Common Name (e.g. server FQDN or YOUR name) []:ドメイン名
Email Address []:

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:
$ openssl x509 -days 3650 -req -signkey icecoder.key < icecoder.csr > icecoder.crt
Signature ok
subject=/C=JP/ST=Tokyo/L=Tokyo/O=組織名/OU=susumuis/CN=ドメイン名
Getting Private key
$ rm icecoder.csr
$ sudo mv icecoder.* /etc/ssl/certs/
$ cd /etc/nginx/sites-enabled/
$ sudo ln -s //etc/nginx/sites-available/icecoder icecoder
$ sudo /etc/init.d/nginx reload
Reloading nginx configuration: nginx.

調べながらやったのでここまでで1時間くらいかかった。lnコマンドはどっちが先かとか毎回調べてしまうの何とかしたい。

この状態でWebでアクセスしたら

Couldn't create config-icecoder_*******.php. Maybe you need write permissions on the lib folder?

とか言われました。パーミッションが正しくないらしい。これはこれで、ちゃんとユーザと権限が適切になっている証拠なので、必要なディレクトリだけwww-dataユーザに権限を渡せば良い。

$ cd ICEcoder/
$ chown -R www-data .
$ chmod g+w backups/ lib/ plugins/ test/ tmp/

こうしてアクセスしてみると下記のようにパスワードを求められる。

初期画面

パスワードを入力するとログイン後の画面が表示された。

ログイン後

初期状態ではICEcoder自体のソースコードが表示されるようだ。これでは使いづらいので、プロジェクトルートのようなフォルダを作ってルートディレクトリをそのフォルダに指定するような設定が必要だろう。